On Wednesday, November 30, 2011 03:59:58 AM Fajar Priyanto wrote:
> How fast the Switches can recognize the new mac? Any other pitfall?
There are a couple of things I've run into, mostly in failover situations or in situations where a machine was moved from one switch to another.
ARP cache timeouts are an issue for seamless failover; VMware, to use one example of which I am very familiar, does a gratuitous ARP *reply* when doing vmotion from one host to another, and this seems to make the transition very short. I have had cisco routers in particular hang on to ARP caches for a very long time; they aren't necessarily supposed to, but I've seen them hold on well past the configured ARP cache expiry (meaning a bug in IOS) and then requiring either a reload or a manual clearing of the ARP cache to pick it back up.
I've also seen cisco Catalyst switches (mostly older ones, like Catalyst 5000 and 5500 series with SupIII/NFFC) hang on to MLS CAM entries if the gateway is replaced with a flow in progress and refuse to let go for a long time. This could conceivably impact any MLS-based catalyst switch, including 6500 series.
I also have some 3Com Superstack II switches that have issues with hanging on to CAM entries long after a machine was moved. The longest CAM expiry I've seen has been about three hours, but that was quite a while back when I had an ATM core in my network here (3Com CoreBuilder/CellPlex 7000 core, SS II's and Cisco Catalyst 5500's (with the LANE card; and I typically used the Truckee-based OC12 LANE cards for the various LANE servers since they had the best BUS performance, two orders of magnitude faster than the CB7000's) on the edge). It was less disruptive in those days to just reboot the core and let everything reacquire and let PNNI reroute the VC's for the LANE components.
So be prepared to clear ARP caches (since gratuitous ARP is sometimes seen as an attack vector, although it works quite well for VMware vMotion, DRS, and HA) and CAM/TCAM entries if things go awry.
The RPMforge/repoforge repository includes the 'garp' package; on the new gateway you could have this garp package installed, and then run garp with the IP address of the old gateway immediately after stopping the old gateway's interface, and that might work. But caution is advised, and YMMV, of course.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
