Arp Address cached interferring with service guard

[rbinc]

I currently have service guard for HP that moves a particular package (ie my syslog server) to another server in case of emergency. however, when it moves to a new server, my devices cannot communicate to it because the switch (cisco 4006) still has the old mac address cached. is thre anyway i can clear this automatically or anythign i can set that doesn't freak out my devices so they can still communicate?

thanks

Jenn

[thisisshanky]

Are both servers in same segment (or vlan) ? do they have different ip addresses ? Are the servers in a cluster ? Are the clients configured to switch over to the new server, in case of non reachability ?

[rbinc]

yes, they are both on the same vlan. the service has the same ip. when the service moves the IP goes with it. yes, the servers are in a cluster. no, because the service is listening on that IP.

[thisisshanky]

Tweak the following setting on the cam table of the 4006.

set cam notification enable

set cam notification added enable

set cam notification interval

The time can be set to 0 seconds, to make the switch notifiy of the change in mac address immediately on the specified ports. But this does have an impact on the switch performance. So tweak this setting with care.

For additional reference check this link

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat4000/7_4/cmd_ref/set_a_d.htm#41624

[t.baranski]

Are you sure its not the hosts that have the old MAC address cached instead of the switch? Or does the switch have an L3 routing blade and hence act as a router? I ask because if the switch isn't acting as a router, it won't care about the MAC change -- switches only look at destination MAC addresses when forwarding packets.

If it is indeed the case that the switch (router) keeps the old ARP entry cached after the change, there's not much you can do. Generally failover protocols send out gratuitous ARPs immediately after a failover condition to eliminate these types of problems with stale ARP entries. If service guard can't do this, the only other option that I can think of is setting a very low ARP timeout on the switch (the default is 4 hours on most/all Cisco devices).