From: Jason Gardiner (gardiner@xxxxxxxxxx)
Date: Wed Feb 06 2002 - 13:30:53 GMT-3
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