arp table question

[grunky]

I have a 2621XM running c2600-io3-mz.122-17a.bin arp tables.

The 2621 has a radio(not a .11a/b/g) access unit attached directly to eth1. From the access unit a subscriber radio is configured - both radios are configured to act as bridges. Attached to the subscriber unit is a customer router.

Today we put in a new subscriber unit. Once configured we could ping the radio and telnet to it, same with the customer router. After a time we noticed this subscriber unit had a bad power supply - so we duplicated the settings and replaced the radio. We could agian ping the customer router but not the new radio. The customer did have connectivity even though the subscriber unit wasn't reachable from the customer router or the 2621.

Upon looking at the 2621's arp table we noticed the ip of the subscriber unit had the old mac address from the bad radio, the age was 70minutes. Once we did a 'clear arp-cache' we could ping the new radio.

My question is this - why didn't the 2621 pick up the mac of the new radio? The old radios mac stayed valid for over an hour dispite the presence of a new host with that ip and a different mac address.

Having the arp table cleared on a periodic basis to avoid these problems sounds bad.

Any suggestions as to why this behavior was happening and how to avoid this.

[mark-obrien · Accepted solution]

The old MAC addressed stayed in the ARP table because the router has no way of knowing that it changed. It ARPed previously and kept the results in the ARP table. Unless the router's own interface goes down, the only ways for the old ARP entry to go away is for it to age out, for the radio to send a packet on its own with the new MAC address, or to be manually cleared. You don't see this happen on normal LANs when hosts are replaced because once a replacement host comes on line it immediately gets busy on the network and all ARP tables are updated.

HTH and Happy New Year.

Mark

[grunky]

Ok - thanks Mark. Since the radio is acting as a bridge and does send out any packets originating from its own address that makes scense the arp tables wouldn't be updated.

Looking over the interface

Ethernet1/0 is up, line protocol is up

Hardware is AmdP2, address is 0009.e878.d810 (bia 0009.e878.d810)

Description: Connection to BreezeCom su's

Internet address is 192.168.80.254/24

MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:22, output 00:00:00, output hang never

--snip--

This problem would of gone away in 4 hours. Now I know more as to why this was happening.

Lowering the arp table timeout - or using the host from console would also fix this.

Thanks.