From: JOSE ANGEL MARTINEZ DE LA VARA (jamartinez@xxxxxxxxxxxxxxxx)
Date: Wed Feb 06 2002 - 14:29:13 GMT-3
Yes, I also think we have to test a little bit more befored being sure about
this. Perhaps the dynamic entry you are having comes from the inarp request
sent by the other side of the pvc. I'll test on this tomorrow too.
But after all, don't you think that if a frame relay map disables inverse
arp then it would appear in the show runn output? I mean, the 'no
frame-relay inverse-arp' statement should appear when the frame relay map is
entered, don't you think so?
Thanks
Jose Angel
-----Mensaje original-----
De: Przemyslaw Karwasiecki [mailto:karwas@ifxcorp.com]
Enviado el: miircoles, 06 de febrero de 2002 17:37
Para: Jason Gardiner
Cc: JOSE ANGEL MARTINEZ DE LA VARA; Muhamamd Durrani;
ccielab@groupstudy.com
Asunto: Re: Frame Relay Map Vs Inverse Arp !
Can you please tell us what IOS you are using?
Look, from my previous posting:
The only (protocol,DLCI) is (IP,201).
There is static map there (to 10.10.1.3).
It doesnt prevent dynamic map for 10.10.1.1
The only possibility is, (as pointed by Jaeheon Yoo tonight),
that this map is created when "far end" is doing inverse arp.
I will investigate it later.
Thanks,
Przemek
> > r2#sh fram map
> > > Serial0 (up): ip 10.10.1.1 dlci 201(0xC9,0x3090), dynamic,
> > > broadcast,, status defined, active
> > > Serial0 (up): ip 10.10.1.3 dlci 201(0xC9,0x3090), static,
> > > CISCO, status defined, active
> > > r2#reload
> > > Proceed with reload? [confirm]
> > >
> > > 19:02:16: %SYS-5-RELOAD: Reload requested
> > >
> > > After reload:
> > > r2#sh fram map
> > > Serial0 (up): ip 10.10.1.1 dlci 201(0xC9,0x3090), dynamic,
> > > broadcast,, status defined, active
> > > Serial0 (up): ip 10.10.1.3 dlci 201(0xC9,0x3090), static,
> > > CISCO, status defined, active
> > >
On Wed, 2002-02-06 at 11:30, Jason Gardiner wrote:
> Static maps only disable inverse-arp for the protocol and dlci spcified in
> the map:
>
> Tod#sh fram map
> Serial0/0 (up): ip 10.10.10.1 dlci 201(0xC9,0x3090), dynamic,
> broadcast,, status defined, active
> Serial0/0 (up): ip 10.10.10.5 dlci 203(0xCB,0x30B0), dynamic,
> broadcast,, status defined, active
> Serial0/0 (up): ip 172.16.1.1 dlci 201(0xC9,0x3090), dynamic,
> broadcast,, status defined, active
>
>
> Notice that all DLCIs are mapped through inverse-arp, as shown by the
> 'dynamic' keyword. Now, I'll set up a static map on DLCI 201:
>
> Tod#conf t
> Enter configuration commands, one per line. End with CNTL/Z.
> Tod(config)#int s0/0
> Tod(config-if)#fram
> Tod(config-if)#frame-relay map ip 10.10.10.2 201 broad
> Tod(config-if)#end
> 6w5d: %SYS-5-CONFIG_I: Configured from console by console
>
>
> And clear the inverse-arp map:
>
> Tod#clear frame-relay-inarp
>
>
> Wait several minutes:
>
> Tod#sh fram map
>
> Serial0/0 (up): ip 10.10.10.2 dlci 201(0xC9,0x3090), static,
> broadcast,
> CISCO, status defined, active
> Serial0/0 (up): ip 10.10.10.5 dlci 203(0xCB,0x30B0), dynamic,
> broadcast,, status defined, active
>
>
> And you can see, the dynamic mappings to 201 are no longer present.
>
>
>
>
>
> On Wednesday 06 February 2002 10:44, Przemyslaw Karwasiecki wrote:
> > I am leaning more and more toward conclusion that statement
> > in Caslow, about side effect of static maps disabling dynamic
> > inverse arp is not correct.
> > At last not in IOS 12.1.12a
> >
> > About race condition:
> > I was just desperatly trying to find out some logical explanation
> > which will be consistent with Caslow statement.
> > This also explain why I was doing reload instead "clear ..."
> > Caslow mentioned reload, so I was blindly doing reload.
> >
> > Anyway -- thank you very much about excellent explanation
> > that interface after power on is in shutdown state, so any
> > race conditions are very unlikly, (if not impossible -- no shutdown
> > is parsed as last interface parameter)
> >
> > ---
> > Bottom line:
> > Unless I am explicitely asked for configuration without
> > frame-relay maps, i will put them, just not to take a risk that
> > this 11.3 I have never tested in my lab is "Caslow compliant" :-)
> >
> > Thanks,
> >
> > Przemek
> >
> > On Wed, 2002-02-06 at 04:18, JOSE ANGEL MARTINEZ DE LA VARA wrote:
> > > Hi,
> > >
> > > I think in that statement Caslow is wrong. Also in my lab Inarp is
> > > running when using maps, and that really makes sense. Think about your
> > > hub-and-spoke topology, the hub can use inverse arp to get all
addresses,
> > > but the spokes cannot. You have to configure the map statements to
the
> > > other spokes, but how can the router know that those statements are to
> > > the spokes and the hub or just the spoke, or none of them? I think it
is
> > > better the way it si because it is your active decision to disable
inarp
> > > when you know there are the right maps configured as static.
> > >
> > > Perhaps in the past enabling maps could disable inarp, but that's not
> > > very fair and Cisco guys could have changed it in 12.1.
> > >
> > > About race betwen config parser and inverse arp ... as you know
inverse
> > > arp runs over frame relay, and by default and before config parsing
there
> > > is hdlc on every interface and all are shutdown. When the config
parser
> > > gets to the interface and selects encapsulation frame relay it
> > > inmediately gets the map command so I think there is not eneugh time
for
> > > the inarp message to be sent or even for an lmi to be received, don't
you
> > > think so? And another thing: why don't you erase the frame relay maps
> > > table with 'clear frame-relay-inarp' command instead of reloading?
There
> > > will be no races at all with the config parser.
> > >
> > > Good luck with your tests and please tell us your conclusions.
> > >
> > > Jose Angel
> > >
> > > -----Mensaje original-----
> > > De: Przemyslaw Karwasiecki [mailto:karwas@ifxcorp.com]
> > > Enviado el: martes, 05 de febrero de 2002 23:20
> > > Para: Muhamamd Durrani
> > > Cc: ccielab@groupstudy.com
> > > Asunto: Re: Frame Relay Map Vs Inverse Arp !
> > >
> > >
> > > Hello,
> > >
> > > My understanding of this problem/phenomenon is as folow:
> > > 1) you are assigning encapsulation and IP address
> > > to serial interfaces on the spoke routers
> > > 2) spoke router learn by inverse arp (enabled by default)
> > > about IP address of a hub router and keeps this map
> > > in nonpersistent (RAM) memory
> > > 3) you create static map from spoke to another spoke
> > > using as L2 address DLCI from your spoke to hub router
> > > -- acording to Bruce Caslow book, this configuration
> > > statement disables inverse arp on this particular DLCI.
> > > But you alredy have, in nonpersistent memory, map from
> > > your spoke to your hub.
> > > 4) you save your config (normal, usual wr mem)
> > > 5) you reload spoke router
> > >
> > > ---
> > >
> > > 6) before spoke router has opportunity to learn
> > > via inverse arp maping between IP of your hub, and DLCI
> > > to your hub, configuration statement with static map is
> > > parsed, effectivelly stoping inverse arp on this DLCI.
> > >
> > > ---
> > >
> > > 7) Final effect
> > > -- after reload your spoke cannot ping hub router.
> > >
> > > Now, to be technically correct, it is difficult to
> > > answer your question, because there is no sentence
> > > in your original post with question mark,
> > > but if your confusion is comming from the simple fact
> > > that router is performing dynamic inverse arp
> > > even when static map is present (against Caslow p.118),
> > > I have to tell you that I am confused as well.
> > >
> > > In my lab behaviour is exactly as in yours:
> > >
> > > Before reload:
> > >
> > > r2#sh fram map
> > > Serial0 (up): ip 10.10.1.1 dlci 201(0xC9,0x3090), dynamic,
> > > broadcast,, status defined, active
> > > Serial0 (up): ip 10.10.1.3 dlci 201(0xC9,0x3090), static,
> > > CISCO, status defined, active
> > > r2#reload
> > > Proceed with reload? [confirm]
> > >
> > > 19:02:16: %SYS-5-RELOAD: Reload requested
> > >
> > > After reload:
> > > r2#sh fram map
> > > Serial0 (up): ip 10.10.1.1 dlci 201(0xC9,0x3090), dynamic,
> > > broadcast,, status defined, active
> > > Serial0 (up): ip 10.10.1.3 dlci 201(0xC9,0x3090), static,
> > > CISCO, status defined, active
> > >
> > > r2#sh run int s0
> > > Building configuration...
> > >
> > > Current configuration : 120 bytes
> > > !
> > > interface Serial0
> > > ip address 10.10.1.2 255.255.0.0
> > > encapsulation frame-relay
> > > frame-relay map ip 10.10.1.3 201
> > > end
> > >
> > >
> > > Any comments on this?
> > > Is Caslow wrong in his statement that static frame relay map
> > > disables inverse arp on this DLCI?
> > > Or this is kind of race condition and inverse arp is faster
> > > then config parser?
> > >
> > > Thanks for your feedback,
> > >
> > > Przemek
> > >
> > > On Tue, 2002-01-22 at 00:41, Muhamamd Durrani wrote:
> > > > Hi All !!
> > > >
> > > > I am running hub and spoke scenario ...all are using
> > > > physical interfaces and all PVC's are up !!!
> > > >
> > > > I am using map for spoke to see each other !!!
> > > > and spokes are using inverse-Arp to resolve HUB ip
> > > > with local DLCI
> > > >
> > > > According to bruce caslow !
> > > > If Frame relay Map is configured for a particular
> > > > protocol and particular DLCI ..Inverse ARP for that
> > > > particular DLCI is disabled automatically !!!!
> > > >
> > > > condition:
> > > > if we saved Map statement into startup config :
> > > >
> > > > Is there any specific command to save MAP statement to
> > > > startup config !!!!!
> > > >
> > > > cause i write my config into NVRAm and reload my
> > > > router my router still running Inverse Arp to resolve
> > > > HUB ip !!!!
> > > >
> > > > Any clue !!! Am I missing something !!!
> > > >
> > > > Regards,
> > > >
> > > >
> > > >
> > > >
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:13 GMT-3