Layer 2 ARP problem

[Vasileios Bouloukos MSc, ITIL, CCIE]

Hi!

I am going to transfer 2 Cisco switches from two routers which are directly connected e.g. R1/R2  to other two routers e.g R3/R4.

These switches have connected servers which point to the VRRP IP and are in service.

I am trying to have the minimum downtime during the migration of the VRRP IP from R1/R2 to R3/R4.

So, the R3,R4 routes use IP from the same subnet pool as R1/R2. The servers will have see the same VRRP IP as default gateway.

First task is to shutdown the R1/R2 interfaces. Then, I will configure the same VRRP IP to the new R3/R4 routers.

I was wondering that since the new VRRP IP has a new MAC IP when the servers will update their ARP table with the new MAC IP of the VRRP?

I mean that since the servers will sent traffic all the time I can not expect to the servers MAC address entry to expire or sent an ARP broadcast (after 4h?).

If I ping the servers with source IP the VRRP of the R3/R4 routers will this force the servers to update their ARP table?

In this case I also do not have to clear the old MAC entry from the switches?

I do not have access to the servers and the solution to shut their interfaces and then to not shut is not feasilbe.

Please your advice...rating all the helpful answers and appreciate your help in advance!

Vasilis

[Rolf Fischer]

Vasilis,

VRRP will broadcast a Gratuitous ARP, so the servers learn the new MAC-Address immediately.

Source:

http://tools.ietf.org/html/rfc3768

And if you don't change the VRRP Group, the virtual MAC-Address will even remain the same: 00-00-5e-00-01-

Indeed you could try to minimize your downtime by

(R1 = "old" master; R2 = "old" backup; R3 = "new" master; R4 = "new" backup)

- change the priority of R2 so that it becomes master

- shutdown R1 (now backup)

- activiate R3, make sure it becomes master (priority R2)

- shutdown R2 (now backup again)

- activate R4

HTH

Rolf

[Vasileios Bouloukos MSc, ITIL, CCIE]

Thank you!

I have to use a new VRRP group since the R1/R2 old routers were CISCO and configured with HSRP.

The new routers R3/R4  are not CISCO and do not support HSRP.

So I will configure a new VRRP group to R3/R4 with the same VRRP IP as the old HSRP IP.The VRRP will broadcast a  gratuitous ARP request containing the virtual router MAC address (according to the RFC that you provided) and the servers will update the arp table.

Please correct me if i am wrong.

Thanks,

Vasilis

[Rolf Fischer]

In this case the virtual MAC-address has to be relearned in any case, because its format is totally different in HSRP.

And of course my hint for speeding up won't work.

Nevertheless, with a short downtime (shutdown HSRP Interfaces and acitvate/initialize VRRP) the servers should learn the new MAC-Address by the Gratuitous ARP and communication can go on.

In the worst case you can clear the ARP table of the servers (Windows:  arp -d ; verify: arp -a)

[Vasileios Bouloukos MSc, ITIL, CCIE]

I want to avoid the worst case scenarion since the servers are not under my administrition and I could not clear the arp...

(otherwise the problem could not exist )

I have to be sure for the next "with a short downtime (shutdown HSRP Interfaces and acitvate/initialize VRRP) the servers should learn the new MAC-Address by the Gratuitous ARP and communication can go on"

[Rolf Fischer]

Well, testing it with a virtual machine (Win 2003 Server) and GNS3 I lost 3 pings ...

The Gratituos ARP ist used by HSRP as well as by VRRP to dectect duplicate addresses and to infrom the connected endsystems about the changes - you can rely on this.

But in our world there's always an "if", right?

Maybe the servers are running an exotic operating system or some kind of security feature which make them act in an unexpected way.

I don't believe that but it's always a good idea being prepared for the worst case ;-)

[Vasileios Bouloukos MSc, ITIL, CCIE]

Thank you!

I have also tested this setup with GNS. It is true, just a few icmp lost packets.... but unfortunatelly I can not really trust the GNS for Layer 2 problems.

That is true...we, the engineers,  spent a large amount of time for this damn "if" (rollback procedures, standby engineers, alternative configurations, workarounds etc...)