From: Daniel Cisco Group Study (danielcgs@imc.net.au)
Date: Tue Apr 22 2003 - 06:38:31 GMT-3
Thanks for sharing more valuable insight into this issue....
Daniel
-----Original Message-----
From: Glenn Goldie [mailto:ggoldie2@lineone.net]
Sent: Tuesday, 22 April 2003 02:05
To: Mike Williams
Cc: CCIELab@Groupstudy.com
Subject: Re: Frame Relay: Map disables Inverse Arp? SOLVED!!!
Hi Mike,
I thought you were on to something as I was scratching my head about
this a few weeks ago and never really resolved it. I was thinking the
same as you, perhaps a change in later IOS or something. Anyway after
seeing your post I tried similar setup at the weekend. R1 and R3 with a
PVC each only to R2 in a FR hub/spoke fashion.
Router1 -----------------Router2-----------------Router3
dlci 100 101 HQ 201 dlci 200
ip 192.1.1.1 192.1.1.2 192.1.1.3
spoke hub
spoke
Using only inverse-arp the HQ R2 could see each spoke. The spokes could
only see the HQ (normal).
Then on R3, I put in a map statement to point to R1 (spoke to spoke)
through DLCI 200. I figured if your findings were correct then after
rebooting the HQ router, it should only be able to pick up the
inverse-arp mapping to R1. But it still actually picked up both mappings
after a reboot.
Then I put in a map statement on R2 hub to it's own interface address
using DLCI 201 (the same PVC back to R3). Therefore I have static maps
for the PVC at both ends. After rebooting both routers neither of them
seemed to be using inverse-arp for the PVC connecting them. The hub
router still picked up the R1 spoke.
I concluded that both routers have to have static maps in order for
inverse arp to be disabled between them and cause a problem. But with
some more playing around I found that wasn't 100% correct either. It is
mostly but I did find an exception.
Using debug frame packet I could watch inverse arp requests come in or
be initiated and sent out and also replies to requests sent out. This is
what I found :
1: Whenever you have a static map for a particular dlci, inverse arp is
indeed disabled on said router for that protocol/dlci - OUTGOING
REQUESTS ONLY that is.
2: The remote router will still send an inverse arp request and the
local router will still REPLY and install a dynamic map for the remote
router at the same time.
That is why in your first experiment after adding a static map and
rebooting R6, it still learned the address of R2. Because R2 initiated
inverse arp and while R6 will not start any inverse arp conversation it
will still listen/learn and reply. Then when you added the static map on
R2, neither router was then initiating inverse arp exchanges and
therefore neither of them could learn any peer addresses for the common PVC.
I suspect if you had then removed the static map from R6 but left it on
R2 and then rebooted them, they would have both learned each others
addresses again.
I'll use my example network above again :
1: Static map configured only on R3, outgoing inverse arp requests are
disabled on R3 for dlci 200.
2: No static maps configured on R1 or R2, inverse arp enabled for R1 and
R2 all dlcis.
3: When the pvc comes up R1 and R2 will both initiate inverse arp on the
101-100 PVC. They will learn each others addresses.
4: R2 will also initiate inverse arp on the 201-200 PVC. R3 will keep
quiet until it receives the request from R2 after which it will reply
and enter R2's address into its own FR map table at the same time. I'm
not sure if they exchange a few packets to do the arp stuff, it looks
like it.
5: So the result is that R1 has a dynamic map to R2, R2 has a dynamic
map to both R1 and R3, and R3 will have a dynamic map back to R2 plus
whatever the static map configured is. This means we havn't really seen
the effects of inverse arp being disabled on R3 yet.
Now consider this :
6: On R3, clear the frame relay inverse arp cache .
7: R3 will NOT re-learn the dynamic map back to R2. Inverse Arp is
disabled on R3 for protocol/dlci 200 so it will not ask R2. R2 already
has a map entry to R3 so it does not send any more inverse arp requests
to R3. Now we have a problem.
8: Cause the PVC between R2/R3 to go down (pull a cable or shut down an
interface).
9: R2 will have the dynamic map to R3 removed from its table due the the
PVC going INACTIVE or DELETED.
9: Allow the PVC between R2/R3 to come back up
10: R2 will again initiate an inverse arp request out dlci 201 when it
becomes ACTIVE and both R2/R3 will learn each others addresses again and
install dynamic maps to each other. This can take a couple of mins if R2
sends the inv-arp request before R3 realises the link is back up. R2
will repeat the request after a min or so it seems by which time R3 is
ready to reply..
A reboot of either R2 or R3 at Step 8 (instead of pulling a cable) will
cause the same result but sometimes I noticed the initiating end would
get the remote address but the remote address would not get the
initiating ends address. Possibly because when the router boots the
interfaces can go up/down a couple of times before becoming stable. I
think the first time the interface on the rebooting router pops up inv
arp is performed, then the rebooting router resets the interface and
loses its mapping, but when the interface comes up nice and stable the
remote end already has a dynamic mapping and doesn't ask again.
To make the point even clearer :
11: Put a static map on R2 for its own interface address to dlci 201 -
this disables outgoing inverse arp requests on dlci 201. Now both R2/R3
have inverse arp disabled on their common PVC. Again, there is no
immediate problem as both R2 and R3 already have dynamic maps to each other.
12: Cause the PVC to go down and come up and you will see that they do
not relearn each others addresses. Neither of them is initiating inverse
arp requests on their common PVC.
13: Now on R2 change the mapping for its own interface address to use
dlci 101 instead of 201. Now inverse arp is disabled on R2 for dlci 101
and on R3 for dlci 200.
14: Shut interface again, wait for dynamic map to be deleted, and bring
it back up
15: Now all routers should have dynamic maps again (not spoke to spoke).
R1 will still initiate inverse arp to R2 so they will learn each others
addresses. Inverse arp is disabled on R3 but R2 will initiate inverse
arp on dlci 201 (as it is only disabled for dlci 101) and therefore
R2/R3 will learn each others addresses.
16: Put a static map on R1 dlci 100 and clear fr arp then you'll see
R1/R2 not dynamically mapping.
As I said there are a couple of times where one end will lose its
dynamic map and then you could run into trouble so best to follow the
usual rule if you map one address to a dlci then map all addresses for
that protocol/dlci.
Rgds,
Glenn .
Mike Williams wrote:
>Hey all, sorry for the waste of bandwidth. But I figured this
>out.....(and besides it's text, which takes virtually no bandwidth =).
>And I have to say that the answer to this makes sense, but isn't very
>well presented, even by Caslow.
>
>In my previous post I showed the frame mappings on R6 (that showed a
>dynamic mapping to 150.50.100.2) and then I rebooted and it CAME BACK
>even tho I had a frame map on that same DLCI. What I didn't show you
>was the config on the other end (R2) which WAS:
>
>R2#show run int s1.256
>
>interface Serial1.256 multipoint
> ip address 150.50.100.2 255.255.255.224
> frame-relay interface-dlci 105
> frame-relay interface-dlci 106
>
>I eventually realized that when I setup R2 to ping it's own interface I
>had to map it's local IP (150.50.100.2) to one of the DLCI's on this
>subinterface, making the config look like this:
>
>R2#show run int s1.256
>
>interface Serial1.256 multipoint
> ip address 150.50.100.2 255.255.255.224
> frame-relay map ip 150.50.100.2 106
> frame-relay interface-dlci 105
> frame-relay interface-dlci 106
>
>Then it struck me, that by doing this, it would disable inverse arp for
>DLCI 106. So I went to R6 and repeated my previous experiment. This
>time after I rebooted, I no longer had the dynamic mapping for
>150.50.100.2.
>
>So what the textbooks SHOULD say is: "When you do a frame map statement
>on one router, it disabled the inverse arp so that any REMOTE router
>that CONNECTS via this DLCI cannot do dynamic mappings. However, using
>a frame map on a given router DOES NOT prevent that same router from
>dynamically mapping IPs learned via that same DLCI that you are using
>the frame map statement on." Again to quote Caslow's book, ". . .
>inverse arp will be disabled for that specific protocol only for the
>DLCI referenced in the frame-relay map statement." However this doesn't
>prevent said router from learning mappings on this DLCI. Geez... what a
>pain. Now if I can only figure out this Be, Bc, Tc crap, I can move on
>to more fun/frustrating lab scenarios. LOL.
>
>Output from the "new" experiment is below (if you wish to compare to
>that in my previous post):
>
><---------- begin output ------------->
>
>R6#sh frame map
>Serial1 (up): ip 150.50.100.2 dlci 601(0x259,0x9490), dynamic,
> broadcast,, status defined, active
>Serial1 (up): ip 150.50.100.5 dlci 601(0x259,0x9490), static,
> broadcast,
> CISCO, status defined, active
>Serial1 (up): ip 150.50.100.6 dlci 601(0x259,0x9490), static,
> CISCO, status defined, active
>R6#ping 150.50.100.6
>
>Type escape sequence to abort.
>Sending 5, 100-byte ICMP Echos to 150.50.100.6, timeout is 2 seconds:
>!!!!!
>Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/40 ms
>R6#wr mem
>Building configuration...
>[OK]
>R6#reload
>Proceed with reload? [confirm]y
>00:49:53: %SYS-5-RELOAD: Reload requested
>System Bootstrap, Version 5.3(10) [tamb 10], RELEASE SOFTWARE (fc1)
>Copyright (c) 1994 by cisco Systems, Inc.
>
>ccie4u_term>x6
>Translating "x6"
>Translating "x6"
>% Unknown command or computer name, or unable to find computer address
>ccie4u_term>6
>[Resuming connection 6 to ipr6 ... ]
>C4500 processor with 65536 Kbytes of main memory
>
>program load complete, entry point: 0x80008000, size: 0x2b9e04
>Self decompressing the image :
>########################################################################
>########################################################################
>########################################################################
>############################## [OK]
>program load complete, entry point: 0x80008000, size: 0x9a1a34
>Self decompressing the image :
>########################################################################
>########################################################################
>########################################################################
>########################################################################
>########################################################################
>########################################################################
>########################################################################
>########################################################################
>########################################################################
>########################################################################
>########################################################################
>########################################################################
>####################### [OK]
>
> Restricted Rights Legend
>
>Use, duplication, or disclosure by the Government is
>subject to restrictions as set forth in subparagraph
>(c) of the Commercial Computer Software - Restricted
>Rights clause at FAR sec. 52.227-19 and subparagraph
>(c) (1) (ii) of the Rights in Technical Data and Computer
>Software clause at DFARS sec. 252.227-7013.
>
> cisco Systems, Inc.
> 170 West Tasman Drive
> San Jose, California 95134-1706
>
>
>
>Cisco Internetwork Operating System Software
>IOS (tm) 4500 Software (C4500-A3JK9S-M), Version 12.2(2)T4, RELEASE
>SOFTWARE (fc3)
>TAC Support: http://www.cisco.com/tac
>Copyright (c) 1986-2002 by cisco Systems, Inc.
>Compiled Sat 09-Feb-02 21:48 by yiyan
>Image text-base: 0x600089C8, data-base: 0x61322000
>
>
>Compliance with U.S. Export Laws and Regulations - Encryption
>
>This product performs encryption and is regulated for export
>by the U.S. Government.
>
>This product is not authorized for use by persons located
>outside the United States and Canada that do not have prior
>approval from Cisco Systems, Inc. or the U.S. Government.
>
>This product may not be exported outside the U.S. and Canada
>either by physical or electronic means without PRIOR approval
>of Cisco Systems, Inc. or the U.S. Government.
>
>Persons outside the U.S. and Canada may not re-export, resell,
>or transfer this product by either physical or electronic means
>without prior approval of Cisco Systems, Inc. or the U.S.
>Government.
>
>cisco 4700 (R4K) processor (revision C) with 65536K/4096K bytes of
>memory.
>Processor board ID 03446045
>R4700 CPU at 133Mhz, Implementation 33, Rev 1.0, 512KB L2 Cache
>G.703/E1 software, Version 1.0.
>Bridging software.
>X.25 software, Version 3.0.0.
>SuperLAT software (copyright 1990 by Meridian Technology Corp).
>TN3270 Emulation software.
>2 Ethernet/IEEE 802.3 interface(s)
>2 Serial network interface(s)
>1 ATM network interface(s)
>128K bytes of non-volatile configuration memory.
>16384K bytes of processor board System flash (Read/Write)
>4096K bytes of processor board Boot flash (Read/Write)
>
>
>
>Press RETURN to get started!
>
>
>00:00:11: %LINK-3-UPDOWN: Interface Ethernet0, changed state to up
>00:00:11: %LINK-3-UPDOWN: Interface Ethernet1, changed state to up
>00:00:11: %LINK-3-UPDOWN: Interface Serial0, changed state to down
>00:00:11: %LINK-3-UPDOWN: Interface Serial1, changed state to up
>00:00:12: %SYS-5-CONFIG_I: Configured from memory by console
>00:00:13: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0,
>changed state to down
>00:00:13: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1,
>changed state to down
>00:00:13: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0,
>changed state to down
>00:00:13: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1,
>changed state to up
>00:00:13: %SYS-5-RESTART: System restarted --
>Cisco Internetwork Operating System Software
>IOS (tm) 4500 Software (C4500-A3JK9S-M), Version 12.2(2)T4, RELEASE
>SOFTWARE (fc3)
>TAC Support: http://www.cisco.com/tac
>Copyright (c) 1986-2002 by cisco Systems, Inc.
>Compiled Sat 09-Feb-02 21:48 by yiyan
>00:00:13: %SYS-6-BOOTTIME: Time taken to reboot after reload = 69
>seconds
>00:00:14: %LINK-5-CHANGED: Interface Ethernet0, changed state to
>administratively down
>00:00:14: %LINK-5-CHANGED: Interface Ethernet1, changed state to
>administratively down
>00:00:14: %LINK-5-CHANGED: Interface ATM0, changed state to
>administratively down
>00:00:15: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0, changed
>state to down
>R6#
>R6#
>R6#sh run int s1
>Building configuration...
>
>Current configuration : 239 bytes
>!
>interface Serial1
> ip address 150.50.100.6 255.255.255.224
> encapsulation frame-relay
> fair-queue
> clockrate 125000
> frame-relay map ip 150.50.100.5 601 broadcast
> frame-relay map ip 150.50.100.6 601
> frame-relay interface-dlci 601
>end
>
>R6#sh frame map
>Serial1 (up): ip 150.50.100.5 dlci 601(0x259,0x9490), static,
> broadcast,
> CISCO, status defined, active
>Serial1 (up): ip 150.50.100.6 dlci 601(0x259,0x9490), static,
> CISCO, status defined, active
>R6#
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:36:00 GMT-3