From: Przemyslaw Karwasiecki (karwas@xxxxxxxxxxx)
Date: Wed Feb 06 2002 - 12:44:35 GMT-3
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