From: Chuck Larrieu (chuck@xxxxxxxxxxxxx)
Date: Sun Feb 25 2001 - 23:02:20 GMT-3
See my post on my "lazy theory of history" ;->
I myself tend to be a minimalist. I do not put anything into a configuration
unless it serves a greater good.
On the other hand, there is the issue of "best practice" versus "the Lab". I
had this discussion with the group at the ASET Lab, when I was there a few
days ago. The opinion of several was that in the Lab one should only do that
which is specifically called for. On the other hand, I am sure all of us
have heard tell of folks being penalized for not doing certain things which
were not specifically called for. What's a poor soul to do?
Do you automatically put loopback interfaces on all your routers, even
though you are not specifically told to do so? Best practice versus the Lab
requirement.
Do you use the no frame-relay inverse-arp if there is nothing specific one
way or another regarding it. ( this would also include an instruction about
"no dynamic frame-relay mappings should occur" or words along those lines )
I can think of plenty of things that would be fair to test me on, and plenty
of things that at this point in time I could expect to be docked on. But I
would sure hate to think that I could be docked for following best practice,
even though it is not specifically stated that I should do so or for failing
to use certain commands and configuration techniques that some may deem
useful but which are not specifically called for.
Add this one to "lab strategy" .
Chuck
-----Original Message-----
From: Devon Watkins [mailto:devon_watkins@yahoo.com]
Sent: Sunday, February 25, 2001 5:39 PM
To: 'Chuck Larrieu'
Cc: 'CCIE Group'
Subject: RE: Frame Relay Inverse-Arp + Map Statement
Maybe I am missing something. We all agree that in SOME circumstances static
mappings will turn off inverse arp on a frame-relay interface. Apparently it
does not do this all the time. If a customer has a requirement not to use
any DLCI's in anyway except for xxx and yyy, then why would you NOT use no
frame inverse? (assuming the customer decides that "using" a dlci means that
is show up in a sho frame map).
I guess what I am saying is that as long as you don't count on the
"automagic" functionality you should be okay. I don't think it would be wise
to count on ANY functionality that you do not control when taking the lab.
Does this match the general consensus or is there a situation where using no
frame inverse arp would be detrimental (in a lab scenario, not meaning real
life support issues)?
Devon
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Chuck Larrieu
Sent: Sunday, February 25, 2001 7:02 PM
To: David Antonsen; Nigel Taylor; Andy Needham; ccielab@groupstudy.com
Cc: Rob Warnke
Subject: RE: Frame Relay Inverse-Arp + Map Statement
Let me guess - this is not a bug it is a feature.
Just wish that the documentation CD articles were updated to reflect this
change. I did not find anything in any of the version release notes that I
checked. I see some good. But in the case that JD reported, I gotta wonder
if there are some bad things that happen as a result.
Well, add another "pitfall" to the list. ;->
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
David Antonsen
Sent: Sunday, February 25, 2001 6:19 PM
To: Nigel Taylor; Andy Needham; ccielab@groupstudy.com
Cc: Rob Warnke
Subject: RE: Frame Relay Inverse-Arp + Map Statement
Intresting Nigel, I went for my exam in January and the proctor didn't give
me my frame-relay points because I didn't explicitly type "no frame-relay
inverse-arp". When I told him that inverse-arp is disabled by default, he
agreed, but he still saw dynamic maps when he did show frame relay map. He
couldn't explain it either. He wanted to see it explicitly turned off as it
still showed up with dynamic routes.
=- Dave
----Cisco Systems---
David Antonsen
Systems Engineer
Office (631) 391-2055
Pager (800) 365-4578
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Nigel Taylor
Sent: Sunday, February 25, 2001 6:33 AM
To: Andy Needham; ccielab@groupstudy.com
Subject: Re: Frame Relay Inverse-Arp + Map Statement
Andy,
We recently had a pretty decent thread on this a couple of weeks
ago. A couple of the folks that attended "Mentortech's ECP1" class at the
time returned and informed us of Bruce and Val's thoughts on this issue.
Apparently as of 12.0, frame-relay inverse-arp is now longer disabled with
the use of map commands.
What is being was being said was in making use of the frame map command the
general rule is to disable it manually with the "no frame inverse-arp"
command. However, In my preparation I plan on following the very specific
requirements of the lab and what I've been practicing.
What have most of you folks been doing...?
HTH
Nigel.
----- Original Message -----
From: Andy Needham <andy.needham@tesco.net>
To: <ccielab@groupstudy.com>
Sent: Sunday, February 25, 2001 5:59 AM
Subject: Frame Relay Inverse-Arp + Map Statement
>
> I figured I knew Frame-Relay issues until today !!
>
> I have a scenario whereby I am running a Frame-Relay Switch with 4
> Remote Spokes.
>
> R1 (s0) 172.1.4.1 ---------> (s0) FrameSwitch
> R2 (s0) 172.1.4.2 ---------> (s3) FrameSwitch
> R3 (s0) 172.1.4.3 ---------> (s1) FrameSwitch
> R4 (s0) 172.1.4.4 ---------> (s2) FrameSwitch
>
> The Frame Network is partial mesh, no PVC's are configured between
> R1 and R3, R2 and R3.
>
> FrameSwitch Config :
>
> interface Serial0
> frame-relay route 112 interface Serial3 121
> frame-relay route 114 interface Serial2 141
> !
> interface Serial1
> frame-relay route 134 interface Serial2 143
> !
> interface Serial2
> frame-relay route 141 interface Serial0 114
> frame-relay route 142 interface Serial3 124
> frame-relay route 143 interface Serial1 134
> !
> interface Serial3
> frame-relay route 121 interface Serial0 112
> frame-relay route 124 interface Serial2 142
> !
>
> Physical Interfaces are being used at all 4 spokes and in order to
> create
> a full mesh I have configured Map statements at R1, R2 and R3.
>
> So great, everything works, all Networks available from all Routers. I
> now
> reload the Routers and expect my Network to run into problems.
>
> According to Caslow 2nd Edition, Page 118, "if the Router is reloaded,
> Inverse-Arp
> will be disabled for any DLCI that is used with a frame-relay map
> Statement"
>
> The Routers reload, the network comes up, all networks are visible !!.
> The Static
> and Dynamic Maps are still valid.
>
> Is this an IOS level issue (I am running 12.0.8) or am I completely
> missing the point ?.
>
> Thanks,
>
> Andy
>
> R1 S0 Config :
> !
> interface Serial0
> ip address 172.1.4.1 255.255.254.0
> no ip directed-broadcast
> encapsulation frame-relay
> no ip mroute-cache
> no fair-queue
> frame-relay map ip 172.1.4.3 114 broadcast
> end
>
> R2 S0 Config :
> !
> interface Serial0
> ip address 172.1.4.2 255.255.254.0
> no ip directed-broadcast
> encapsulation frame-relay
> no ip mroute-cache
> no fair-queue
> frame-relay map ip 172.1.4.3 124 broadcast
> end
>
> R3 S0 Config :
> !
> interface Serial0
> ip address 172.1.4.3 255.255.254.0
> no ip directed-broadcast
> encapsulation frame-relay
> no ip mroute-cache
> no fair-queue
> frame-relay map ip 172.1.4.1 134 broadcast
> frame-relay map ip 172.1.4.2 134 broadcast
> end
>
> R4 S0 Config :
> !
> interface Serial0
> ip address 172.1.4.4 255.255.254.0
> no ip directed-broadcast
> encapsulation frame-relay
> no ip split-horizon eigrp 1
> no ip mroute-cache
> no fair-queue
> end
>
>
>
>
>
>
>
>
>
>
>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:29:01 GMT-3