From: William Chen (kwchen@netvigator.com)
Date: Sat Mar 20 2004 - 23:26:04 GMT-3
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