From: NET HE (he_net@hotmail.com)
Date: Sat Feb 14 2009 - 13:24:25 ARST
I don't think your solution is wrong. Best Regards, Net (Xin) He
Date: Sat, 14 Feb 2009 20:32:40 +0530Subject: Re: Wordings game again ..
helpFrom: gauravmadan1177@gmail.comTo: he_net@hotmail.comCC:
karim.jamali@gmail.com; ccielab@groupstudy.com
I understand what u r saying .. this is not wrong .
my query was .. is my sol of PPPoFR wrong ?
On Sat, Feb 14, 2009 at 8:10 PM, NET HE <he_net@hotmail.com> wrote:
There are 2 functions for "frame-rel inverse-arp", -proactively advertise
out its own IP address -proactively query remote site's IP address and "no
frame-relay inverse-arp" doesn't disable answering to the ip query from remote
sites. So in your case,
[A] Use only physical interfaces to configure FR between R1 and R2[B] Do not
use frame-relay map CLI[C] R2 shoud not send frame-relay inverse-arp request
out FR cloud I would disable frame-relay inverse-arp on R2, but keep
frame-relay inverse-arp enabled on R1. Therefore, R2 will not proactively
advertise out its IP address, as well as sending out query for remote-site's
IP address. But R1 will proactively advertise out its ip-dhci mapping, as well
as sending out query for remote-site's ip-dlci mapping, which will be ansered
by R2. As a result, R2 will know ip-dlci mapping for R1 because of R1's
proactive advertisement, and R1 will know ip-dlci mapping for R2 because of
R2's answer. Lab it up will help you. Hope it helps.Best Regards, Net (Xin)
He > Date: Sat, 14 Feb 2009 19:10:45 +0530> Subject: Re: Wordings game again
.. help> From: gauravmadan1177@gmail.com> To: karim.jamali@gmail.com> CC:
ccielab@groupstudy.com
> > Thats what i though also> wanted some comments from the group as well ..
hence drafted a mail .> thnx> > > > On Sat, Feb 14, 2009 at 6:56 PM, karim
jamali <karim.jamali@gmail.com>wrote:> > > Hey,> >> > With physical
frame-relay interfaces two choices exists (inverse-arp and> > static
mapping).> > Since both are not allowed and the physical frame-relay is
imposed,the only> > solution is PPP over Frame-Relay/> >> > I dont see
anything wrong with your choice of solution.> >> > Regards,> >> > On Sat, Feb
14, 2009 at 12:46 PM, GAURAV MADAN <> > gauravmadan1177@gmail.com> wrote:> >>
>> Hi> >>> >> Althogh I know of solution ; sometimes its the wording that i
dont> >> understand ... This time I had a task stating :> >>> >>> >> R1
------------ Fr --------------------- R2> >>> >>> >> [A] Use only physical
interfaces to configure FR between R1 and R2> >> [B] Do not use frame-relay
map CLI> >> [C] R2 shoud not send frame-relay inverse-arp request out FR
cloud> >>> >> My interpretation> >> ---------------------------> >> [A] i cant
use p2p or p2multipoint sub interface> >> [B] alright .. clear .. i cant use
map> >> [C] i will issue "no frame-rel inverse-arp" on R2 ..> >>> >>> >> I
came with following sol (PPPoFR)> >>> >> Rack1R2(config-if)#do sh run int
s0/0/0> >> Building configuration...> >> Current configuration : 230 bytes> >>
!> >> interface Serial0/0/0> >> no ip address> >> ip pim sparse-mode> >>
encapsulation frame-relay> >> no fair-queue> >> frame-relay traffic-shaping>
>> frame-relay interface-dlci 201 ppp Virtual-Template1 <<<<<<<> >> class
TEST> >> no frame-relay inverse-arp> >> end> >>> >>> >> Same on R1 as well>
>>> >> 1) I have not used sub int . its on main interface only> >> 2) No map
statement used .> >> 3) I am not sending inverse arp req as well> >>> >>> >>
Which requirement have I violated ? Please suggest> >>> >> Best Regards> >>
Gaurav Madan> >>> >>> >> Blogs and organic groups at http://www.ccie.net> >>>
>> _______________________________________________________________________> >>
Subscription information may be found at:> >>
http://www.groupstudy.com/list/CCIELab.html> >>> >>> >>> >>> >>> >>> >>> >>>
>> >> > --> > KJ> > > Blogs and organic groups at http://www.ccie.net> >
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:44:11 ARST