From: Serran (groupstudy@swiftdsl.com.au)
Date: Sat Mar 20 2004 - 21:06:40 GMT-3
yes i agree.. no arp frame-relay has no effect in stopping inverse-arp
requests AND is not needed in conjunction with no frame-relay inverse-arp
command.
cheers for pointing that out Brian.
although, it seems that ptmp sub intf's do inherit the command from the
physical intf... as i could not see any inarp requests with debug
frame-relay packet (using 12.2(15)T8).
For example: No inverse-arp requests will originate from s0/0.256
interface Serial0/0
no ip address
encapsulation frame-relay
no frame-relay inverse-arp
!
interface Serial0/0.24 point-to-point
ip address 150.50.24.2 255.255.255.0
frame-relay interface-dlci 104
!
interface Serial0/0.256 multipoint
ip address 150.50.100.2 255.255.255.224
frame-relay map ip 150.50.100.2 106
frame-relay map ip 150.50.100.5 105 broadcast
frame-relay map ip 150.50.100.6 106 broadcast
!
rgds
Serran.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Brian McGahan
Sent: Sunday, 21 March 2004 3:44 AM
To: 'Packet Man'; ccielab@groupstudy.com
Subject: RE: Lab Tip question?
The "no arp frame-relay" command has no affect. It is misdocumented
in certain places that it stops the replies to inverse-arp requests. This
is not true. A simple test of configuring "no arp frame-relay" and enabling
the interface will show that is does not prevent dynamic mappings from being
created.
There are exactly three ways to stop frame relay inverse-arp:
1. "no frame-relay inverse-arp"
This disables the generation of InARP requests for all protocols out
all DLCIs assigned to the interface. This command is only locally
significant to the interface it is configured on, and it not inherited by
multipoint subinterfaces if it is configured on a main interface.
2. "no frame-relay inverse-arp [protocol] [dlci]"
This disables the generation of InARP requests for the specified
protocol and DLCI pair.
3. "frame-relay map [protocol] [dlci]"
This disables the generation of InARP requests for the specified
protocol and DLCI pair.
AFAIK there is no way to prevent a router from responding to a frame
relay InARP request.
Also, there is no way to stop the router from learning VC
information from the frame relay cloud. DLCI information is advertised from
the frame relay cloud to the end node via LMI. Inverse-ARP and LMI do not
have any direct relationship.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Packet Man
> Sent: Friday, March 19, 2004 3:50 PM
> To: dswink@cisco.com; ccielab@groupstudy.com
> Subject: RE: Lab Tip question?
>
> Hey Dave,
>
> From all the practice labs which have a requirement such as "do not use
> any
> Dlci's except those specified", I've gotten into the habit of entering "no
> frame inverse-arp". But, I don't recall ever trying to confirm that
> unused
> DLci's don't even appear in output of "show fram pvc".
>
> As best as I can recall, one of those commands prevents an interface from
> requesting the remote ip address while the other command prevents an
> interface from responding to a request. Is that correct?
>
> If so, which command does which?
>
> Thanks
>
> BTW, This is the type of discussion I was hoping my Lab Tips concept would
> generate. And, the wording of the tip I've added to my Tips file is, "If
> only specified DLCI's are allowed, enter "no fram inv" and "no arp fram"
>
> Is there a better or more accurate way to state it?
>
>
> >From: "Dave Swink (dswink)" <dswink@cisco.com>
> >Reply-To: <dswink@cisco.com>
> >To: "'Packet Man'" <ccie2b@hotmail.com>
> >Subject: RE: Lab Tip question?
> >Date: Fri, 19 Mar 2004 14:39:53 -0600
> >
> >Yeah, this is intended as a lab-centric tip only, not real-world. There
> >could theoretically be a requirement that unspecified DLCIs not even
> >appear in your "show frame-relay pvc".
> >
> >I got into the habit of using no arp frame-relay when I was frustrated
> >with trying to kill unwanted DLCIs. If you configure the commands to
> >prevent inverse arp after turning the interface up, you will need to
> >reboot the router to get rid of them. It was a belt & suspenders thing.
> >If no frame inverse-arp does the job by itself, that is great.
> >
> >Dave Swink, CCIE #11678
> >
> >-----Original Message-----
> >From: Packet Man [mailto:ccie2b@hotmail.com]
> >Sent: Friday, March 19, 2004 2:12 PM
> >To: dswink@cisco.com
> >Subject: Lab Tip question?
> >
> >Hey Dave,
> >
> >Thanks for your suggestion. I assume this tip applies to the situation
> >where static f/r map statements are configured and no dynamic mapping is
> >
> >wanted. Yes?
> >
> >If that's the case, I've always found that no frame inverse-arp was
> >sufficient to achieve that result. Therefore, under what circumstances
> >would the "no arp frame-relay" be required?
> >
> >Thanks
> >
> >
> > >From: "Dave Swink (dswink)" <dswink@cisco.com>
> > >Reply-To: <dswink@cisco.com>
> > >To: "'Packet Man'" <ccie2b@hotmail.com>, <lkgilles_ccie@yahoo.com.au>,
> >
> > > <ccielab@groupstudy.com>
> > >Subject: RE: Where's your Lab Tips contribution?
> > >Date: Fri, 19 Mar 2004 13:54:33 -0600
> > >
> > >Configure "no arp frame-relay" and "no frame-relay inverse-arp" before
> > >turning up a frame relay interface.
> > >
> > >Dave Swink, CCIE #11678
> > >
> > >-----Original Message-----
> > >From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> > >Packet Man
> > >Sent: Friday, March 19, 2004 1:16 PM
> > >To: lkgilles_ccie@yahoo.com.au; ccielab@groupstudy.com
> > >Subject: Re:Where's your Lab Tips contribution?
> > >
> > >OK, so now you gotten some great (my personal opinion) lab tips, what
> > >lab
> > >tip(s) do you have to contribute?
> > >
> > >
> > > >From: Lee Gillespie <lkgilles_ccie@yahoo.com.au>
> > > >To: Packet Man <ccie2b@hotmail.com>
> > > >Subject: Re: Lab Tips
> > > >Date: Fri, 19 Mar 2004 11:00:32 -0800 (PST)
> > > >
> > > >Gotcha, I was just afraid there was some kinda reason it wouldnt
> >work.
> > >A
> > > >lot of labs I have done have the requirment "make the BGP peers as
> > >stable
> > > >as possible" which I assume means peer to the Loopback.
> > > >
> > > >
> > > >
> > > >Packet Man <ccie2b@hotmail.com> wrote:
> > > >Only because it takes more time to configure. And, if it isn't
> > >required,
> > > >why
> > > >spend the time and introduce the possibility of typo's and other
> > >potential
> > > >misconfig's?
> > > >
> > > >
> > > > >From: Lee Gillespie
> > > > >To: Packet Man
> > > > >Subject: Re: Lab Tips
> > > > >Date: Thu, 18 Mar 2004 14:50:42 -0800 (PST)
> > > > >
> > > > >Why dont you use Loopbacks for iBGP peering?
> > > > >
> > > > >Packet Man wrote:Hi all,
> > > > >
> > > > >I've created a "Lab Tips" file of small items - factoids,
> >reminders,
> > > > >suggestions, etc, I tend to forget. This is something I can refer
> >to
> > > > >constantly when I'm doing practice labs or just have a few minutes
> >to
> > > > >spare.
> > > > >
> > > > >Here's a snippet from my Tips file.
> > > > >
> > > > >BGP
> > > > >Hard code router-id
> > > > >Don't use loopbacks for ibgp peering unless explicitly required
> > > > >Look for nei ... next-hop-self requirement especially on F/R hub
> >and
> > > > >ethernets
> > > > >Disable bgp client to client reflection when clients are fully
> >meshed
> > > > >Turn off auto-sum & sync unless explicitly required
> > > > >Reset BGP sessions using hard reset rather than soft reset.
> > > > >Know how to config nei xxxx local-as in combo with RR.
> > > > >Know all ways to config dampening
> > > > >
> > > > >I'm sharing this with GS because I suspect many candidates might
> >also
> > >
> > > >have
> > > > >something like this. And, I thought that with all the great brain
> > >power
> > > > >among GS subscribers we could all help each other by adding tips to
> > >such
> > > >a
> > > > >file.
> > > > >
> > > > >Here's my definition of what makes for a good tip.
> > > > >
> > > > >1) A tip may not in any way violate the NDA
> > > > >2) A good tip should be something that might be easily forgotten
> > >because
> > > > >it's not that often encountered or somehow different from the
> > >ordinary.
> > > >For
> > > > >example, when configuring ISIS over frame relay, don't forget to
> > >enter
> > > >the
> > > > >"fram map clns broadcast" statement. For me, this is a good tip
> > > > >because I personally don't practice ISIS that often and I seem to
> > >almost
> > > > >always forget that command.
> > > > >
> > > > >3) A good tip must be short and clear because the whole idea behind
> > >this
> > > > >file is to provide a quick reminder of various networking facts
> >that
> > >can
> > > > >come in handy during the actual lab.
> > > > >
> > > > >4) A good tip must should not waste time going into the "why" of
> >the
> > >fact
> > > > >or
> > > > >all the various permutations. For that, anyone interested can
> > >research
> > > >the
> > > > >"why" of the fact on their own.
> > > > >
> > > > >5) A good tip for one person might not be at all useful to someone
> > >else.
> > > >We
> > > > >each tend to remember and forget different things. But, for
> >example,
> > >over
> > > > >time the BGP tips section may include 30 items and while I doubt
> >all
> > >30
> > > > >items will be useful to all people, I'm sure that 5 or 10 or 15 of
> > >the
> > > >tips
> > > > >will be useful to many people - just that it won't be the same 5 or
> > >10 or
> > > > >15
> > > > >tips.
> > > > >
> > > > >6) A good tip must be potentially relevant to a ccie R&S candidate.
> > > > >Therefore, I ask that Off Topic comments be submitted elsewhere -
> > >Let's
> > > > >keep
> > > > >posts with the subject "Lab Tips" focus on just that.
> > > > >
> > > > >It's my hope that over time, with the input of a lots of people
> >here,
> > >
> > > >this
> > > > >lab tips file will grow to include tips that cover every topic
> > > >potentially
> > > > >on the R&S lab exam. And, that as a result, we can each add the
> >most
> > > > >personally valuable tips from this group effort to our own lab tips
> > >file.
> > > > >
> > > > >Right now, my tips file has no entries for voice. So, I'd like to
> > >start
> > > >off
> > > > >by asking people to submit their voice config tips. Of course, tips
> > >on
> > > >any
> > > > >potential lab are also welcomed.
> > > > >
> > > > >Here are some other potential tips topics I hope people feel free
> >to
> > > >submit
> > > > >tips to.
> > > > >
> > > > >Redistribution
> > > > >
> > > > >ATM
> > > > >
> > > > >3550
> > > > >
> > > > >OSPF
> > > > >
> > > > >NAT
> > > > >
> > > > >HSRP
> > > > >
> > > > >F/R
> > > > >
> > > > >ISDN
> > > > >
> > > > >QOS
> > > > >
> > > > >Multicast
> > > > >
> > > > >NTP
> > > > >
> > > > >Voice
> > > > >
> > > > >Eigrp
> > > > >
> > > > >Please add your tip under the appropriate heading and send back to
> > >GS.
> > > > >
> > > > >Hope this helps lots of people.
> > > > >
> > > > >Packet Man
> > > > >
> > > > >_________________________________________________________________
> > > > >MSN Toolbar provides one-click access to Hotmail from any Web page
> >
> > >FREE
> > > > >download! http://clk.atdmt.com/AVE/go/onm00200413ave/direct/01/
> > > > >
> > > >
> > >
> > >_______________________________________________________________________
> > > > >Please help support GroupStudy by purchasing your study materials
> > >from:
> > > > >http://shop.groupstudy.com
> > > > >
> > > > >Subscription information may be found at:
> > > > >http://www.groupstudy.com/list/CCIELab.html
> > > > >
> > > > >Do you Yahoo!?
> > > > >Yahoo! Mail - More reliable, more storage, less spam
> > > >
> > > >_________________________________________________________________
> > > >Is your PC infected? Get a FREE online computer virus scan from
> >McAfee.
> > > >Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> > > >
> > > >Do you Yahoo!?
> > > >Yahoo! Mail - More reliable, more storage, less spam
> > >
> > >_________________________________________________________________
> > >Get rid of annoying pop-up ads with the new MSN Toolbar FREE!
> > >http://clk.atdmt.com/AVE/go/onm00200414ave/direct/01/
> > >
> > >_______________________________________________________________________
> > >Please help support GroupStudy by purchasing your study materials from:
> > >http://shop.groupstudy.com
> > >
> > >Subscription information may be found at:
> > >http://www.groupstudy.com/list/CCIELab.html
> > >
> >
> >_________________________________________________________________
> >MSN Toolbar provides one-click access to Hotmail from any Web page -
> >FREE
> >download! http://clk.atdmt.com/AVE/go/onm00200413ave/direct/01/
> >
> >
>
> _________________________________________________________________
> Find a broadband plan that fits. Great local deals on high-speed Internet
> access. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Apr 01 2004 - 08:15:42 GMT-3