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.