Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

question about arping

We have our main site and DR site.

We have a bridged subnet from the main site to the DR site.

The routers across the wan connection are the bridge interfaces and the default gateways for the brdged subnbet.

There is a windows machine that under normal operation is in the Main site.

If it fails, the DR site machine is brought live with the same IP address.

My questions is regarding arp.

The router that is holding the arp table for this machine ( the bridged interface and default gateway)has a 4 hour arp timeout.

If the machine does not do anything, then this arp table stays intact for 4 hours correct?

so, if I take down the main site machine and bring up the dr side machine, the DR side router refreshes its arp table as soon as the mashine is brought up on the dr side.

But the main site is not refreshed for 30 seconds to a minute later.

Not a big deal but I am curious.

Is the netbios traffic enough to refresh the arp table on the dr side?

what traffic would be required to update the arp table, broadcast traffic ?

If so, whay does the main site side take so long, if it is a bridged connection, it should get the same brocasts.

maybe not instantly, but sooner than 30-60 seconds correct?


Re: question about arping

hello wilson

The main issue here is the ARP timing out ! There are timeouts configured, and I really dont recommend changing these values.. The way it happens is.. when a server is plugged onto the network, the nic broadcasts and the switch associates its mac address (after it gets the IP), in its ARP table... The value in the ARP table stays, till the ARP timer expires or someone manually clears the ARP !

If a second server is plugged in with the same IP address, and if the ARP already exists, it will term it as "duplicate MAC/IP" and will not allow the second server to come on the network..

As said earlier, the solution for your problem will be to manually clear the ARP table after you change the IP address on your server.. The DR backup anyway requires manual intervention, and you should do this as a mandatory step.. The other way is to have Layer 3 links between the DC/DR, and you can have automatic routing happening, by simply doing a NAT for the server on the DR end !!!

Hope this helps.. all the best..


New Member

Re: question about arping

Thanks for the reply.

here is what was happening:

The two sites are bridged, so both sides are in the same broadcast domain and in the same subnet and VLAN.

The Main site had the server up and routers on both sides had the ip address associated to the same mac-address of the server on the Main site side.

When the server on the main site side was taken down and the server on the DR site was brought up,

The DR side saw this immidiately and refreshed the arp table on the DR side.

The main site held the old mac address for about 30 seconds, then refreshed on its own.


if the arp table does not get refreshed by the second server with the same IP Address and differnet mac address (mentioned in your post "duplicat MAC/IP"), what refreshed it?

And why did it take 30 seconds for the Main site side to get mac address from the DR side when the DR side refreshed immidiately?

Hall of Fame Super Silver

Re: question about arping

With all due respect to my colleague Raj, I do not believe that a Cisco router does duplicate address detection (nor duplicate address rejection) on traffic passing through the router. Duplicate address detection is more a function of hosts than it is of routers.


With most OS when a device is brought up it will transmit a gratuitous ARP to announce its MAC and associated IP. If the DR server sends this gratuitous ARP then it should update the ARP in the routers. I am puzzled by the delay in updating the ARP table by the main site router. If the segments are bridged I would expect the same frame that updated the DR side would have been delivered to the main site and both should have updated at the same time. I wonder how you detected the 30 second delay. I would suggest that the best test would be to make sure that both routers have clocks that are really synchronized by having them running NTP to a common source and then running debug arp. The timestamps of the frame that updates would show how much delay, if any, there was.



Re: question about arping


I was presuming the connectivity going through a switch which would do a layer2 lookup for the frames based on mac address table... These r the problems of having a layer 2 WAN connectivity for DC and DR.. I would advice Wilson to move to a layer 3 WAN...

Thanks a ton for a wonderful explanation. Hats off to you


New Member

Re: question about arping

Thanks for the reply rick.

I noticed the delay by having a telnet session open on both routers and observing what was happening.

I suspected an arp issue because they had had trouble with this failover process before.

I was watching both arp tables in the routers while the one server was brought down and the other brought up.

I could see the DR table almost instanty update when the server was brought online and the Main site side have the delay.

Originally the complaint was that there was no comminucation from the Main site to the DR server when the failover process was initiated, but actually, they were not waiting long enough (the 30 seconds).

Once the arp table on the Main site server updated with the new mac-address, the communication was restored from the Main site to the new server in the DR side.