From: Frank Jimenez (franjime@xxxxxxxxx)
Date: Sun Feb 25 2001 - 23:05:24 GMT-3
Here is my (admittedly unofficial) view on this.
The important point here is to obtain the results asked for on the exam. For e
xample, if the exam is asking for you to advertise two IPX SAPs called 'SERVER1
' and 'SERVER2', then I wouldn't risk the farm on setting up two SAPs called 'S
1' and 'S2'. You have to be precise where it's called for.
Similarly, in the Frame Relay scenario described below, if the lab question sta
tes that you only use specific PVCs, then I wouldn't count on "Well, it's suppo
sed to be disabled in 12.0" to buy you any points. Similarly, if the lab quest
ion states that you can use any method you want, then go forth and dynamically
map. If there's any question on what the lab is looking for, then ask the proc
tor. My guess would be that the answer to half the questions that are asked of
the proctor is "Go back and read the question carefully."
To review: READ the lab question and produce the results asked for. Nothing mo
re and nothing less.
Frank Jimenez, CCIE #5738
franjime@cisco.com
<.sig for rent, great rates available!>
At 07:38 PM 02/25/2001 -0600, Devon Watkins wrote:
>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