Run both VRRP v2 and v3 at same time for migration as per RFC5798

[Anonymous]

Hi,

In the process of migrating an S-Series core to VSP. The S Series is running VRRP v2, but would like to make use of v3 to take advantage of the following:

• Milliseconds failover vs seconds
• IPv6 support
• Increase v2 limitation of 254 instances on VSP

RFC 5798 states the following, in summary says to migrate you should run both VRRP v2 and v3 at the same time:

“VRRPv3 Support of VRRPv2

As mentioned above, this support is intended for upgrade scenarios and is NOT recommended for permanent deployments.

An implementation MAY implement a configuration flag that tells it to listen for and send both VRRPv2 and VRRPv3 advertisements.

When a virtual router is configured this way and is the Master, it MUST send both types at the configured rate, even if sub-second.

When a virtual router is configured this way and is the Backup, it should time out based on the rate advertised by the Master; in the case of a VRRPv2 Master, this means it must translate the timeout value it receives (in seconds) into centiseconds.  Also, a Backup should ignore VRRPv2 advertisements from the current Master if it is also receiving VRRPv3 packets from it.  It MAY report when a VRRPv3 Master is *not* sending VRRPv2 packets: that suggests they don't agree on whether they're supporting VRRPv2 routers.”

I know in EXOS VRRP v2 and v3 are enabled by default, so would help support a migration. EOS and VOSS I can’t seem to find the support.

I’m going to add a similar post to the EOS section of the forum, and initially this is where I would probably enable both versions rather then on VOSS, but covering my bases if EOS doesn’t support it.

The plan would go something like this:

• Stretch the VLAN being migrated between EOS and VOSS
• Shutdown VLAN interface on Core 2 of EOS switch (WISH VOSS SUPPORTED THIS!!)
• Configure that same L3 VLAN interface in VOSS but as VRRP v3
• Shutdown VLAN interface on Core 1 of EOS switch, now routing only on VOSS
• Configure the other L3 VLAN interface on other VOSS switch so have full gateway redundancy
• Remove stretch VLAN

This allows me to move the L3 from EOS to VOSS with no downtime.

So I have actually done this same process before in a very large network, same hardware EOS → VOSS.

In that migration though I simply reconfigured the EOS cores from v2 to v3 on a live critical network with no service interruption:

• Set all the VRRP priorities so core 1 was master
• Removed and replaced all the VRRP config on core 2 to be v3
• Changed all the VRRP priorities on core 2 to now be master
• Removed and replaced all the VRRP config on core 2 to be v3

This incurred no down time but wasn't really following the letter of the RFC, and this time around working on a more critical system I want to get the process interoperable correctly.

Configuring EOS from v2 to v3 didn’t require me to interop the versions, and it worked, but feel it is perhaps not the best way to do it.

So question is: how do I enable both VRRP v2 and v3 at the same time for each VLAN interface?

Many thanks in advance

Here is where I have asked the duplicate question but on EOS instead:

[Anonymous · Accepted solution]

Hi Sam,

Thanks for getting back. It was more that RFC5798 states that for migration from VRRP V2 to V3 it allows for both versions to be run at the same time, which EXOS switches support.

I was hoping for similar functionality in VOSS / VSP’s to allow me to transition smoothly from one to the other i.e. older network running v2 and new network running v3. Using the function in RFC5798 for VRRP it describes would have allowed both old and new VSP network to intercommunicate as I transition from v2 to v3 with out any loss.

So it seems VOSS doesn’t support this, but coincidently I just did the migration like so without any loss:

• EOS: VRRP v2 running on both cores
• EOS: Shutdown VLAN interface on one core
• VOSS (VLAN stretched between two): Configured VRRP v3 on one of the new cores as a mirror of the one just shutdown on the EOS side.
• EOS: Shutdown the VLAN interface on the remaining core
• VOSS: Configured VRRP v3 on the remaining core
• Removed the VLAN that was being stretched between the legacy and new cores

This seemed to work really well, and not a single packet was dropped in the transition.

One thing that I would really like to request to assist with migrations like these, is the ability to shutdown and no shut VLAN interfaces in VOSS 🙂

Anyway, thanks for getting back.

Cheers,

Martin

[SamPirok]

Hi Martin, thanks for your patience while I looked in to this for you. It looks like the VRRP version can be selected per VLAN, however you cannot run both v2 and v3 on the same VLAN. VRRPv3 doesn’t listen to VRRPv2 advertisements. Is that what you were looking for?