<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic EOS run both VRRP v2 and v3 at same time for migration as per RFC5798 in ExtremeSwitching (EOS)</title>
    <link>https://community.extremenetworks.com/t5/extremeswitching-eos/eos-run-both-vrrp-v2-and-v3-at-same-time-for-migration-as-per/m-p/66035#M2064</link>
    <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;This is the same question I have posted in relation to VOSS, but posting here to cover EOS:&lt;/P&gt;&lt;OEMBED url="https://community.extremenetworks.com/extremeswitching-vsp-233220/run-both-vrrp-v2-and-v3-at-same-time-for-migration-as-per-rfc5798-7829726"&gt;&lt;/OEMBED&gt;&lt;P&gt;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:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Milliseconds failover vs seconds&lt;/LI&gt;	&lt;LI&gt;IPv6 support&lt;/LI&gt;	&lt;LI&gt;Increase v2 limitation of 254 instances on VSP&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;RFC 5798 states the following, in summary says to migrate you should run both VRRP v2 and v3 at the same time:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;EM&gt;&lt;EM&gt;“VRRPv3 Support of VRRPv2&lt;/EM&gt;&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;&lt;EM&gt;As mentioned above, this support is intended for upgrade scenarios and is NOT recommended for permanent deployments.&lt;/EM&gt;&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;&lt;EM&gt;An implementation MAY implement a configuration flag that tells it to listen for and send both VRRPv2 and VRRPv3 advertisements.&lt;/EM&gt;&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;&lt;EM&gt;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.&lt;/EM&gt;&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;&lt;EM&gt;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. &amp;nbsp;Also, a Backup should ignore VRRPv2 advertisements from the current Master if it is also receiving VRRPv3 packets from it. &amp;nbsp;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.”&lt;/EM&gt;&lt;/EM&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;Initially I would add the v2 + v3 configuration on EOS, but fall-back to VOSS if its not supported.&lt;/P&gt;&lt;P&gt;The plan would go something like this:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Stretch the VLAN being migrated between EOS and VOSS&lt;/LI&gt;	&lt;LI&gt;Shutdown VLAN interface on Core 2 of EOS switch&lt;/LI&gt;	&lt;LI&gt;Configure that same L3 VLAN interface in VOSS but as VRRP v3&lt;/LI&gt;	&lt;LI&gt;Shutdown VLAN interface on Core 1 of EOS switch, now routing only on VOSS&lt;/LI&gt;	&lt;LI&gt;Configure the other L3 VLAN interface on other VOSS switch so have full gateway redundancy&lt;/LI&gt;	&lt;LI&gt;Remove stretch VLAN&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;This allows me to move the L3 from EOS to VOSS with no downtime.&lt;/P&gt;&lt;P&gt;So I have actually done this same process before in a very large network, same hardware EOS →&amp;nbsp;VOSS.&lt;/P&gt;&lt;P&gt;In that migration though I simply reconfigured the EOS cores from v2 to v3 on a live critical network with no service interruption:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Set all the VRRP priorities so core 1 was master&lt;/LI&gt;	&lt;LI&gt;Removed and replaced&amp;nbsp;all the VRRP config on core 2 to be v3&lt;/LI&gt;	&lt;LI&gt;Changed all the VRRP priorities on core 2 to now be master&lt;/LI&gt;	&lt;LI&gt;Removed and replaced&amp;nbsp;all the VRRP config on core 2 to be v3&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;Configuring EOS from v2 to v3&amp;nbsp;didn’t require me to interop the versions, and it worked, but feel it is perhaps not the best way to do it.&lt;/P&gt;&lt;P&gt;So question is: how do I enable both VRRP v2 and v3 at the same time for each VLAN interface?&lt;/P&gt;&lt;P&gt;Many thanks in advance&lt;/P&gt;</description>
    <pubDate>Thu, 07 Jan 2021 17:40:49 GMT</pubDate>
    <dc:creator>Anonymous</dc:creator>
    <dc:date>2021-01-07T17:40:49Z</dc:date>
    <item>
      <title>EOS run both VRRP v2 and v3 at same time for migration as per RFC5798</title>
      <link>https://community.extremenetworks.com/t5/extremeswitching-eos/eos-run-both-vrrp-v2-and-v3-at-same-time-for-migration-as-per/m-p/66035#M2064</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;This is the same question I have posted in relation to VOSS, but posting here to cover EOS:&lt;/P&gt;&lt;OEMBED url="https://community.extremenetworks.com/extremeswitching-vsp-233220/run-both-vrrp-v2-and-v3-at-same-time-for-migration-as-per-rfc5798-7829726"&gt;&lt;/OEMBED&gt;&lt;P&gt;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:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Milliseconds failover vs seconds&lt;/LI&gt;	&lt;LI&gt;IPv6 support&lt;/LI&gt;	&lt;LI&gt;Increase v2 limitation of 254 instances on VSP&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;RFC 5798 states the following, in summary says to migrate you should run both VRRP v2 and v3 at the same time:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;EM&gt;&lt;EM&gt;“VRRPv3 Support of VRRPv2&lt;/EM&gt;&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;&lt;EM&gt;As mentioned above, this support is intended for upgrade scenarios and is NOT recommended for permanent deployments.&lt;/EM&gt;&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;&lt;EM&gt;An implementation MAY implement a configuration flag that tells it to listen for and send both VRRPv2 and VRRPv3 advertisements.&lt;/EM&gt;&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;&lt;EM&gt;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.&lt;/EM&gt;&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;&lt;EM&gt;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. &amp;nbsp;Also, a Backup should ignore VRRPv2 advertisements from the current Master if it is also receiving VRRPv3 packets from it. &amp;nbsp;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.”&lt;/EM&gt;&lt;/EM&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;Initially I would add the v2 + v3 configuration on EOS, but fall-back to VOSS if its not supported.&lt;/P&gt;&lt;P&gt;The plan would go something like this:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Stretch the VLAN being migrated between EOS and VOSS&lt;/LI&gt;	&lt;LI&gt;Shutdown VLAN interface on Core 2 of EOS switch&lt;/LI&gt;	&lt;LI&gt;Configure that same L3 VLAN interface in VOSS but as VRRP v3&lt;/LI&gt;	&lt;LI&gt;Shutdown VLAN interface on Core 1 of EOS switch, now routing only on VOSS&lt;/LI&gt;	&lt;LI&gt;Configure the other L3 VLAN interface on other VOSS switch so have full gateway redundancy&lt;/LI&gt;	&lt;LI&gt;Remove stretch VLAN&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;This allows me to move the L3 from EOS to VOSS with no downtime.&lt;/P&gt;&lt;P&gt;So I have actually done this same process before in a very large network, same hardware EOS →&amp;nbsp;VOSS.&lt;/P&gt;&lt;P&gt;In that migration though I simply reconfigured the EOS cores from v2 to v3 on a live critical network with no service interruption:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Set all the VRRP priorities so core 1 was master&lt;/LI&gt;	&lt;LI&gt;Removed and replaced&amp;nbsp;all the VRRP config on core 2 to be v3&lt;/LI&gt;	&lt;LI&gt;Changed all the VRRP priorities on core 2 to now be master&lt;/LI&gt;	&lt;LI&gt;Removed and replaced&amp;nbsp;all the VRRP config on core 2 to be v3&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;Configuring EOS from v2 to v3&amp;nbsp;didn’t require me to interop the versions, and it worked, but feel it is perhaps not the best way to do it.&lt;/P&gt;&lt;P&gt;So question is: how do I enable both VRRP v2 and v3 at the same time for each VLAN interface?&lt;/P&gt;&lt;P&gt;Many thanks in advance&lt;/P&gt;</description>
      <pubDate>Thu, 07 Jan 2021 17:40:49 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremeswitching-eos/eos-run-both-vrrp-v2-and-v3-at-same-time-for-migration-as-per/m-p/66035#M2064</guid>
      <dc:creator>Anonymous</dc:creator>
      <dc:date>2021-01-07T17:40:49Z</dc:date>
    </item>
  </channel>
</rss>

