Hi all, I have plan to replace my Centos5.7 VM with newer version. The VM works as our network gateway.
I want to ask from your experience, will it be a bad decision? My concern is that since the Mac Address of the gateway will change, will it disrupt the network? How fast the Switches can recognize the new mac? Any other pitfall?
Thanks Fajar.
On 11/30/11 12:59 AM, Fajar Priyanto wrote:
How fast the Switches can recognize the new mac? Any other pitfall?
within seconds. or faster. and the client's ARP caches expire nearly as fast.
its not the switches you care about as much as the DHCP leases for your clients. if you can copy the dhcp leases file over, that will save a lot of grief.
On Wed, Nov 30, 2011 at 5:09 PM, John R Pierce pierce@hogranch.com wrote:
On 11/30/11 12:59 AM, Fajar Priyanto wrote:
How fast the Switches can recognize the new mac? Any other pitfall?
within seconds. or faster. and the client's ARP caches expire nearly as fast.
its not the switches you care about as much as the DHCP leases for your clients. if you can copy the dhcp leases file over, that will save a lot of grief.
Thanks John, I feel a bit relief hearing that. More over, the gateway is a pure one, no dhcp, no other services.
Vreme: 11/30/2011 10:13 AM, Fajar Priyanto piše:
On Wed, Nov 30, 2011 at 5:09 PM, John R Piercepierce@hogranch.com wrote:
On 11/30/11 12:59 AM, Fajar Priyanto wrote:
How fast the Switches can recognize the new mac? Any other pitfall?
within seconds. or faster. and the client's ARP caches expire nearly as fast.
its not the switches you care about as much as the DHCP leases for your clients. if you can copy the dhcp leases file over, that will save a lot of grief.
I would suggest installing new gateway as new system, leaving old one to work until new one is ready. That way if something goes wrong you will still have old one to revert to. Just do not give in working IP's until you are ready to switch over.
On 11/30/2011 10:09 AM, John R Pierce wrote:
On 11/30/11 12:59 AM, Fajar Priyanto wrote:
How fast the Switches can recognize the new mac? Any other pitfall?
within seconds. or faster. and the client's ARP caches expire nearly as fast.
its not the switches you care about as much as the DHCP leases for your clients. if you can copy the dhcp leases file over, that will save a lot of grief.
If you want to plug the new system in the same port the old system was plugged in before then depending on the switch and how it is configured it can take 30-60 seconds to change the switch port to a forwarding state. During that time the switch will send put out STP requests to determine if the newly attached device is also a switch. Once these time out it will assume the new device is a regular system and change the port to a forwarding state.
You can prevent this by enabline something like "PortFast" for that port which tells the switch to simply assume that only regular devices will be connected to that port and to immediately change the port to a forwarding state.
See for example: http://www.omnisecu.com/cisco-certified-network-associate-ccna/what-is-spann...
Regards, Dennis
On Wed, Nov 30, 2011 at 2:59 AM, Fajar Priyanto fajarpri@arinet.org wrote:
Hi all, I have plan to replace my Centos5.7 VM with newer version. The VM works as our network gateway.
I want to ask from your experience, will it be a bad decision? My concern is that since the Mac Address of the gateway will change, will it disrupt the network? How fast the Switches can recognize the new mac? Any other pitfall?
Switches normally flood all ports until a new mac is identified so they will work as soon as the link comes up (which may take a few seconds for spanning tree). However, routers to adjacent subnets may cache their arp table for up to 20 minutes. You might have a problem with inbound connections if you don't clear the arp table on whatever is connected as the next hop.
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.
On Wed, Nov 30, 2011 at 11:22 PM, Lamar Owen lowen@pari.edu wrote:
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.
Thanks all for all the insights from your experience. Much appreciated. I will do it during weekend when no users are working. (this creates the saying about sysadmin: people work, we work. people rest, we still work).
On Wednesday, November 30, 2011 10:32:24 AM Fajar Priyanto wrote:
Thanks all for all the insights from your experience. Much appreciated.
You're quite welcome. Please let us know how it went.
I will do it during weekend when no users are working. (this creates the saying about sysadmin: people work, we work. people rest, we still work).
Indeed. In my specific case, I schedule myself for Saturday work for this purpose, and schedule a day off during the week to compensate. But I also know that my situation isn't representation of the general IT condition.
Hope it goes well.
-
Dennis Jacobfeuerborn -
Fajar Priyanto -
John R Pierce -
Lamar Owen -
Les Mikesell -
Ljubomir Ljubojevic