From: Serran (groupstudy@swiftdsl.com.au)
Date: Sun Mar 21 2004 - 00:24:45 GMT-3
" Multipoint subinterfaces do not inherit the "no frame-relay inverse-arp"
from the major interface. However, if you don't specify static map in the
multipoint interface, all DLCIs default go to major interface."
yep thats right! thanks for that William... explains why I wasnt inverse
arping when I removed one of the static maps on the ptmp.
cheers
Serran.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
William Chen
Sent: Sunday, 21 March 2004 1:26 PM
To: Serran; 'Brian McGahan'; ccielab@groupstudy.com
Subject: Re: Lab Tip question?
Hi
Sorry, make some mistake in my previous mail:
Here is the correct configuraion to test:
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 interface-dlci 105
frame-relay interface-dlci 106
!
The command " frame-relay interface-dlci" moves the DLCIs to the
multipoint interface, and InARP is enabled by default in multipoint
interface.
Best Regards,
William Chen
----- Original Message -----
From: "Serran" <groupstudy@swiftdsl.com.au>
To: "'Brian McGahan'" <bmcgahan@internetworkexpert.com>;
<ccielab@groupstudy.com>
Sent: Sunday, March 21, 2004 8:32 AM
Subject: RE: Lab Tip question?
> Even if i remove 1 static map from the ptmp sub intf.. i still get no
> inverse-arps (should have pointed this out in the original email).
>
> rgds
> Serran
>
> -----Original Message-----
> From: Brian Dennis [mailto:bdennis@internetworkexpert.com]
> Sent: Sunday, 21 March 2004 11:26 AM
> To: 'Serran'; 'Brian McGahan'; ccielab@groupstudy.com
> Subject: RE: Lab Tip question?
>
>
> No the command in not inherited by the subinterfaces. InARP is not needed
> for a P2P subinterface since layer 3 to layer 2 mapping is automatic. The
> multipoint subinterface in your example has only two DLCI's assigned and
> since both have static layer 3 to layer 2 mappings, InARP for IP is
disabled
> for them.
>
> Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
> bdennis@internetworkexpert.com
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987
> Direct: 775-745-6404 (Outside the US and Canada)
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Serran
> Sent: Saturday, March 20, 2004 4:07 PM
> To: Brian McGahan; ccielab@groupstudy.com
> Subject: RE: Lab Tip question?
>
> 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
>
> _______________________________________________________________________
> 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
>
> _______________________________________________________________________
> 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
>
> _______________________________________________________________________
> 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