Wired Intelligent Edge

Hi all!

I need to migrate some VLANs [*] - currently routed by a Core Aruba 5400R zl2 switch - to a new Core formed by a VSX Cluster of Aruba 8360...is it possible by deploying a VRRP approach stretched between the Aruba 5400R zl2 and the whole VSX Cluster?

On the VSX Best Practice Guide I've read that: "VSX active-gateway and VRRP at SVI context" but I believe this is intended when the VRRP is enabled between VSX members and the Active Gateway feature is enabled on SVIs too...does that restriction extend to the scenario where VRRP is enabled between a Core Router and the VSX Cluster (with the Active Gateway feature necessarily enabled too)?

The above question arises because by temporarily activating VRRP between the Aruba 5400R zl2 and the entire VSX Cluster I would be able to migrate some VLANs (SVIs) between the two without any noticeable disruption and, after that, disable the VRRP remaining with some SVIs on the old Core and some other on the new one (the VSX).

Currently, the Aruba 8360 VSX Cluster is operating just at Layer 2 level...but it will necessary be reconfigured with SVIs and Active Gateway feature enabled to act with the VRRP and being the new Router for those SVIs.

Both the Aruba 5400R zl2 and the VSX are currently interconnected via Layer 2 links and, de facto, the VSX is just an extension of the Aruba 5400R zl2.

[*] Some and not all because the main purpose of this migration is to divide the duties of those Cores (Aruba 5400R zl2 will be the Router for some VLANs and the VSX for all remaining others), in the medium terms Cores will be separated by means of a Firewall.

The idea of using VRRP seems not too unreasonable, at least just for the purpose of migrating some VLANs (SVI) from a Core to the VSX. A side note: the Perimeter Firewall to RoW (Internet included) is currently connected only to current Core and knows only that Core but the plan will necessarily include a new dedicated physical downlink to the VSX through a dedicated Transit VLAN so the Perimeter Firewall will know the new Router and the SVIs behind it.

I admit I've to deeply reorganize some ideas around this approach...the fact is that I wasn't able to find another approach to separate some SVIs on different Cores without a main disruption on a highly used production network running some sensitive services.

Hello parnassus,

I was just thinking that if you just need to migrate some vlans for routing on the new VSX why don't you just check if this can be done using the DHCP service with the new gateway (VSI on the VSX) ip address setting and they will be changed over time. This way you can keep only Active gateway on the VSX and not mix it with VRRP.
This is just a quick thought I do not know all the details and of course may not be suitable for your environment.

------------------------------
-Alex-
------------------------------

Original Message:
Sent: Jul 14, 2022 06:41 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hi all!

I need to migrate some VLANs [*] - currently routed by a Core Aruba 5400R zl2 switch - to a new Core formed by a VSX Cluster of Aruba 8360...is it possible by deploying a VRRP approach stretched between the Aruba 5400R zl2 and the whole VSX Cluster?

On the VSX Best Practice Guide I've read that: "VSX active-gateway and VRRP at SVI context" but I believe this is intended when the VRRP is enabled between VSX members and the Active Gateway feature is enabled on SVIs too...does that restriction extend to the scenario where VRRP is enabled between a Core Router and the VSX Cluster (with the Active Gateway feature necessarily enabled too)?

The above question arises because by temporarily activating VRRP between the Aruba 5400R zl2 and the entire VSX Cluster I would be able to migrate some VLANs (SVIs) between the two without any noticeable disruption and, after that, disable the VRRP remaining with some SVIs on the old Core and some other on the new one (the VSX).

Currently, the Aruba 8360 VSX Cluster is operating just at Layer 2 level...but it will necessary be reconfigured with SVIs and Active Gateway feature enabled to act with the VRRP and being the new Router for those SVIs.

Both the Aruba 5400R zl2 and the VSX are currently interconnected via Layer 2 links and, de facto, the VSX is just an extension of the Aruba 5400R zl2.

[*] Some and not all because the main purpose of this migration is to divide the duties of those Cores (Aruba 5400R zl2 will be the Router for some VLANs and the VSX for all remaining others), in the medium terms Cores will be separated by means of a Firewall.

The idea of using VRRP seems not too unreasonable, at least just for the purpose of migrating some VLANs (SVI) from a Core to the VSX. A side note: the Perimeter Firewall to RoW (Internet included) is currently connected only to current Core and knows only that Core but the plan will necessarily include a new dedicated physical downlink to the VSX through a dedicated Transit VLAN so the Perimeter Firewall will know the new Router and the SVIs behind it.

I admit I've to deeply reorganize some ideas around this approach...the fact is that I wasn't able to find another approach to separate some SVIs on different Cores without a main disruption on a highly used production network running some sensitive services.

Hello Alex! Thanks for answering! Well...my purpose is to migrate (some of) the SVIs - exactly as they currently are - from one Core (a standalone switch) to another one (a VSX Cluster) thus without changing any IP addresses.

Let me say I have various 10.100.x.0 /24 network segments routed by the standalone Aruba 5400R zl2 switch.

Each network segment is tied to a specific VLAN id with a SVI so, as example, 10.100.0.0 /24 has VLAN 1000 with 10.100.0.254 as its Gateway, 10.100.1.0 /24 has VLAN 1001 with 10.100.1.254 as its Gateway...and so on...up to, say, the latest network segment 10.100.255.0 /24 associated to VLAN 1255 and 10.100.255.254 as its Gateway.

Let me suppose I need to move some of the SVIs (not all, just a subset of them) into a new Router R2 directly connected (L2) to the current Router R1: I'll need a mechanism to transfer - example - the routing of the VLAN 1100 network segment 10.100.100.0 /24 (which owns the SVI 10.100.100.254) from the Aruba 5400R zl2 standalone switch to the VSX Cluster and this, among many other things, will imply that the 10.100.100.254 Gateway IP address - which needs to remain the very same during and after the transfer (No DHCP in those specific DC network portion) - will pass under the control of the VSX Cluster (with Active Gateway enabled configured with the SVI address set to 10.100.100.254 and each VSX Member configured with a reserved IP address such as the 10.100.100.251 associated to VSX Primary and the 10.100.100.252 associated to VSX Secondary for that VLAN) leaving the control of the Aruba 5400R zl2.

All the above remembering that R2 currently isn't routing and it is just a Layer 2 extension of the R1.

To simplify the whole picture I can say that the R1 (Aruba 5400R zl2) shall remain the Router of - let me say - all network segments belonging to the main root 10.100.0.0 /16 network while the R1 (VSX Cluster) shall become the Router of - let me say - all network segments belonging to the main root 10.200.0.0 /16 network BUT, actually, both those main root networks (with all their numerous /24 segments) are routed only by R1.

The reality is a little bit more complex because there isn't a straight distinction between the two main root networks (the routing of some /24 segments belonging of the first main root network needs to be transferred to R2 too) and so I should take care about each /24 segment almost individually.

From the PoV of the clients (edge devices and server systems) insisting on those /24 network segments the used approach should be the one providing the least possible disruption time or no disruption at all (if possible).

To clarify I'm speaking about dividing (the routing of) a DC Network which is currently serving DC+Campus assets into a DC Network serving the routing of DC systems and a Campus Network serving the routing of Campus edge devices...and the assets I can work with are (and are limited to) (a) the R1 Aruba 5400R zl2, (b) the Aruba 8360 VSX Cluster that will become the future R2 Router and (c) a Perimeter Firewall which is - actually - the NHG Next Hop Gateway for RoW configured as the Router of last resort on the R1...and, in between, it should also take care of becoming the NHG for the next-to-come Router R2 (I know there is a lot more behind and around to discuss about...but my very first doubt is how to partly migrate the routing duties).

Hello parnassus,

I would create one test vlan to test the vrrp (it should be working, I have not tested this) between 5400 and 8360 VSX. After that there could be again the same type of step if you would like to switch to Active Gateway as it is exclusive you need either Active gateway or VRRP at SVI level. But if there is no way to get proper maintenance window (which will make it really easy as you will just change the ip addresses and will start using active gateway) at least you will be able to migrate some of the traffic through the VSX.

------------------------------
-Alex-
------------------------------

Original Message:
Sent: Jul 14, 2022 07:43 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hello Alex! Thanks for answering! Well...my purpose is to migrate (some of) the SVIs - exactly as they currently are - from one Core (a standalone switch) to another one (a VSX Cluster) thus without changing any IP addresses.

Let me say I have various 10.100.x.0 /24 network segments routed by the standalone Aruba 5400R zl2 switch.

Each network segment is tied to a specific VLAN id with a SVI so, as example, 10.100.0.0 /24 has VLAN 1000 with 10.100.0.254 as its Gateway, 10.100.1.0 /24 has VLAN 1001 with 10.100.1.254 as its Gateway...and so on...up to, say, the latest network segment 10.100.255.0 /24 associated to VLAN 1255 and 10.100.255.254 as its Gateway.

Let me suppose I need to move some of the SVIs (not all, just a subset of them) into a new Router R2 directly connected (L2) to the current Router R1: I'll need a mechanism to transfer - example - the routing of the VLAN 1100 network segment 10.100.100.0 /24 (which owns the SVI 10.100.100.254) from the Aruba 5400R zl2 standalone switch to the VSX Cluster and this, among many other things, will imply that the 10.100.100.254 Gateway IP address - which needs to remain the very same during and after the transfer (No DHCP in those specific DC network portion) - will pass under the control of the VSX Cluster (with Active Gateway enabled configured with the SVI address set to 10.100.100.254 and each VSX Member configured with a reserved IP address such as the 10.100.100.251 associated to VSX Primary and the 10.100.100.252 associated to VSX Secondary for that VLAN) leaving the control of the Aruba 5400R zl2.

All the above remembering that R2 currently isn't routing and it is just a Layer 2 extension of the R1.

To simplify the whole picture I can say that the R1 (Aruba 5400R zl2) shall remain the Router of - let me say - all network segments belonging to the main root 10.100.0.0 /16 network while the R1 (VSX Cluster) shall become the Router of - let me say - all network segments belonging to the main root 10.200.0.0 /16 network BUT, actually, both those main root networks (with all their numerous /24 segments) are routed only by R1.

The reality is a little bit more complex because there isn't a straight distinction between the two main root networks (the routing of some /24 segments belonging of the first main root network needs to be transferred to R2 too) and so I should take care about each /24 segment almost individually.

From the PoV of the clients (edge devices and server systems) insisting on those /24 network segments the used approach should be the one providing the least possible disruption time or no disruption at all (if possible).

To clarify I'm speaking about dividing (the routing of) a DC Network which is currently serving DC+Campus assets into a DC Network serving the routing of DC systems and a Campus Network serving the routing of Campus edge devices...and the assets I can work with are (and are limited to) (a) the R1 Aruba 5400R zl2, (b) the Aruba 8360 VSX Cluster that will become the future R2 Router and (c) a Perimeter Firewall which is - actually - the NHG Next Hop Gateway for RoW configured as the Router of last resort on the R1...and, in between, it should also take care of becoming the NHG for the next-to-come Router R2 (I know there is a lot more behind and around to discuss about...but my very first doubt is how to partly migrate the routing duties).

Hi Alex! this would be a good approach.

Maybe enabling VRRP to be effective only for one VLAN (a test VLAN), prepare the VLAN interface and Active Gateway configurations on VSX side (to be fast in enabling them serially, first the VLAN interface then the Active Gateway) and enable VRRP on R1 and VSX would be one reasonable route to follow (but...does the VRRP require the IPv4 Routing and the VLAN Interface SVI to be already enabled prior to be effective on the VSX? it seems a Catch 22 situation...or this means that just one VSX Member should have the SVI of the VLAN we're going to migrate? and so only when VRRP is not necessary anymore - thus disabled for that VLAN - we can finally activate the Active Gateway feature for that VLAN Interface on the VSX?).

I'm worried because I believe I'll not have any "human usable maintenance windows" to perform all the above...I agree with you that having an appropriate maintenance window will permit to avoid any too complicated pseudo automatic approach which should include some "semi-automatic" routing switchover...and it will became just a matter of manually moving the routing (SVI addresses) from the R1 to R2 (with an R2 already ready for taking the Router role so with Active Gateway and all other bells and whistles).
Original Message:
Sent: Jul 14, 2022 08:24 AM
From: Alexander Maroukian
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hello parnassus,

I would create one test vlan to test the vrrp (it should be working, I have not tested this) between 5400 and 8360 VSX. After that there could be again the same type of step if you would like to switch to Active Gateway as it is exclusive you need either Active gateway or VRRP at SVI level. But if there is no way to get proper maintenance window (which will make it really easy as you will just change the ip addresses and will start using active gateway) at least you will be able to migrate some of the traffic through the VSX.

------------------------------
-Alex-

Original Message:
Sent: Jul 14, 2022 07:43 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hello Alex! Thanks for answering! Well...my purpose is to migrate (some of) the SVIs - exactly as they currently are - from one Core (a standalone switch) to another one (a VSX Cluster) thus without changing any IP addresses.

Let me say I have various 10.100.x.0 /24 network segments routed by the standalone Aruba 5400R zl2 switch.

Each network segment is tied to a specific VLAN id with a SVI so, as example, 10.100.0.0 /24 has VLAN 1000 with 10.100.0.254 as its Gateway, 10.100.1.0 /24 has VLAN 1001 with 10.100.1.254 as its Gateway...and so on...up to, say, the latest network segment 10.100.255.0 /24 associated to VLAN 1255 and 10.100.255.254 as its Gateway.

Let me suppose I need to move some of the SVIs (not all, just a subset of them) into a new Router R2 directly connected (L2) to the current Router R1: I'll need a mechanism to transfer - example - the routing of the VLAN 1100 network segment 10.100.100.0 /24 (which owns the SVI 10.100.100.254) from the Aruba 5400R zl2 standalone switch to the VSX Cluster and this, among many other things, will imply that the 10.100.100.254 Gateway IP address - which needs to remain the very same during and after the transfer (No DHCP in those specific DC network portion) - will pass under the control of the VSX Cluster (with Active Gateway enabled configured with the SVI address set to 10.100.100.254 and each VSX Member configured with a reserved IP address such as the 10.100.100.251 associated to VSX Primary and the 10.100.100.252 associated to VSX Secondary for that VLAN) leaving the control of the Aruba 5400R zl2.

All the above remembering that R2 currently isn't routing and it is just a Layer 2 extension of the R1.

To simplify the whole picture I can say that the R1 (Aruba 5400R zl2) shall remain the Router of - let me say - all network segments belonging to the main root 10.100.0.0 /16 network while the R1 (VSX Cluster) shall become the Router of - let me say - all network segments belonging to the main root 10.200.0.0 /16 network BUT, actually, both those main root networks (with all their numerous /24 segments) are routed only by R1.

The reality is a little bit more complex because there isn't a straight distinction between the two main root networks (the routing of some /24 segments belonging of the first main root network needs to be transferred to R2 too) and so I should take care about each /24 segment almost individually.

From the PoV of the clients (edge devices and server systems) insisting on those /24 network segments the used approach should be the one providing the least possible disruption time or no disruption at all (if possible).

To clarify I'm speaking about dividing (the routing of) a DC Network which is currently serving DC+Campus assets into a DC Network serving the routing of DC systems and a Campus Network serving the routing of Campus edge devices...and the assets I can work with are (and are limited to) (a) the R1 Aruba 5400R zl2, (b) the Aruba 8360 VSX Cluster that will become the future R2 Router and (c) a Perimeter Firewall which is - actually - the NHG Next Hop Gateway for RoW configured as the Router of last resort on the R1...and, in between, it should also take care of becoming the NHG for the next-to-come Router R2 (I know there is a lot more behind and around to discuss about...but my very first doubt is how to partly migrate the routing duties).

Hi,
As a startingpoint this is important: "Although active gateway and VRRP are no longer globally exclusive in a VSX configuration, active gateway
and VRRP are still exclusive on an SVI. A workaround is to configure VRRP on one SVI (SVI A), and configure
active-gateway on the other SVI (SVI B)." From the VSX guide.

So if you want to use active gateway on a SVI on the VSX cluser you cant use VRRP on this SVI and you must do a hard switchover of the routinginterface from the old core to the new.

If you want to use VRRP you just configure VRRP on all three devices and changes the priority to move the routing to the desired device. If you want to use active gateway on this SVI at a later point, you must remove the VRRP config and configure active gateway. 

This conclude if you want to use active gateway on the VSX core you end up wit a small downtime anyway.

------------------------------
Arne Opdal
------------------------------

Original Message:
Sent: Jul 14, 2022 08:55 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hi Alex! this would be a good approach.

Maybe enabling VRRP to be effective only for one VLAN (a test VLAN), prepare the VLAN interface and Active Gateway configurations on VSX side (to be fast in enabling them serially, first the VLAN interface then the Active Gateway) and enable VRRP on R1 and VSX would be one reasonable route to follow (but...does the VRRP require the IPv4 Routing and the VLAN Interface SVI to be already enabled prior to be effective on the VSX? it seems a Catch 22 situation...or this means that just one VSX Member should have the SVI of the VLAN we're going to migrate? and so only when VRRP is not necessary anymore - thus disabled for that VLAN - we can finally activate the Active Gateway feature for that VLAN Interface on the VSX?).

I'm worried because I believe I'll not have any "human usable maintenance windows" to perform all the above...I agree with you that having an appropriate maintenance window will permit to avoid any too complicated pseudo automatic approach which should include some "semi-automatic" routing switchover...and it will became just a matter of manually moving the routing (SVI addresses) from the R1 to R2 (with an R2 already ready for taking the Router role so with Active Gateway and all other bells and whistles).
Original Message:
Sent: Jul 14, 2022 08:24 AM
From: Alexander Maroukian
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hello parnassus,

I would create one test vlan to test the vrrp (it should be working, I have not tested this) between 5400 and 8360 VSX. After that there could be again the same type of step if you would like to switch to Active Gateway as it is exclusive you need either Active gateway or VRRP at SVI level. But if there is no way to get proper maintenance window (which will make it really easy as you will just change the ip addresses and will start using active gateway) at least you will be able to migrate some of the traffic through the VSX.

------------------------------
-Alex
Original Message:
Sent: Jul 14, 2022 07:43 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hello Alex! Thanks for answering! Well...my purpose is to migrate (some of) the SVIs - exactly as they currently are - from one Core (a standalone switch) to another one (a VSX Cluster) thus without changing any IP addresses.

Let me say I have various 10.100.x.0 /24 network segments routed by the standalone Aruba 5400R zl2 switch.

Each network segment is tied to a specific VLAN id with a SVI so, as example, 10.100.0.0 /24 has VLAN 1000 with 10.100.0.254 as its Gateway, 10.100.1.0 /24 has VLAN 1001 with 10.100.1.254 as its Gateway...and so on...up to, say, the latest network segment 10.100.255.0 /24 associated to VLAN 1255 and 10.100.255.254 as its Gateway.

Let me suppose I need to move some of the SVIs (not all, just a subset of them) into a new Router R2 directly connected (L2) to the current Router R1: I'll need a mechanism to transfer - example - the routing of the VLAN 1100 network segment 10.100.100.0 /24 (which owns the SVI 10.100.100.254) from the Aruba 5400R zl2 standalone switch to the VSX Cluster and this, among many other things, will imply that the 10.100.100.254 Gateway IP address - which needs to remain the very same during and after the transfer (No DHCP in those specific DC network portion) - will pass under the control of the VSX Cluster (with Active Gateway enabled configured with the SVI address set to 10.100.100.254 and each VSX Member configured with a reserved IP address such as the 10.100.100.251 associated to VSX Primary and the 10.100.100.252 associated to VSX Secondary for that VLAN) leaving the control of the Aruba 5400R zl2.

All the above remembering that R2 currently isn't routing and it is just a Layer 2 extension of the R1.

To simplify the whole picture I can say that the R1 (Aruba 5400R zl2) shall remain the Router of - let me say - all network segments belonging to the main root 10.100.0.0 /16 network while the R1 (VSX Cluster) shall become the Router of - let me say - all network segments belonging to the main root 10.200.0.0 /16 network BUT, actually, both those main root networks (with all their numerous /24 segments) are routed only by R1.

The reality is a little bit more complex because there isn't a straight distinction between the two main root networks (the routing of some /24 segments belonging of the first main root network needs to be transferred to R2 too) and so I should take care about each /24 segment almost individually.

From the PoV of the clients (edge devices and server systems) insisting on those /24 network segments the used approach should be the one providing the least possible disruption time or no disruption at all (if possible).

To clarify I'm speaking about dividing (the routing of) a DC Network which is currently serving DC+Campus assets into a DC Network serving the routing of DC systems and a Campus Network serving the routing of Campus edge devices...and the assets I can work with are (and are limited to) (a) the R1 Aruba 5400R zl2, (b) the Aruba 8360 VSX Cluster that will become the future R2 Router and (c) a Perimeter Firewall which is - actually - the NHG Next Hop Gateway for RoW configured as the Router of last resort on the R1...and, in between, it should also take care of becoming the NHG for the next-to-come Router R2 (I know there is a lot more behind and around to discuss about...but my very first doubt is how to partly migrate the routing duties).

Hi Arne! Thank you for kicking in! very appreciated (I really appreciate any contribution!).

"As a starting point this is important: "Although active gateway and VRRP are no longer globally exclusive in a VSX configuration, active gateway and VRRP are still exclusive on an SVI. A workaround is to configure VRRP on one SVI (SVI A), and configure active-gateway on the other SVI (SVI B)." From the VSX guide. So if you want to use active gateway on a SVI on the VSX cluster you cant use VRRP on this SVI and you must do a hard switchover of the routing interface from the old core to the new."

OK I understood that and I'm now definitely aware of this restriction.

I believe the SVI A (VRRP enabled + AG not configured) and SVI B (VRRP disabled + AG enabled) approach isn't the best way to proceed because I need to avoid changes at SVI level during the routing switchover.

"If you want to use VRRP you just configure VRRP on all three devices and changes the priority to move the routing to the desired device. If you want to use active gateway on this SVI at a later point, you must remove the VRRP config and configure active gateway."

The idea of deploying VRRP born while thinking a way of transparently move SVI between Routing Switches...the fact I want to concurrently use the Active Gateway feature at VSX Cluster level is due more to the fact that when I think about VSX and IP Routing on it, I automatically think about AG too...but...rethinking the whole approach...that requirement wouldn't be something to deploy immediately (at least AG could not be enabled exactly during the SVI routing migration...for sure it could be deployed after that and after that VRRP is no more necessary because all required SVIs are already migrated to the VSX Cluster)...so re-reading your sentence "If you want to use active gateway on this SVI at a later point, you must remove the VRRP config and configure active gateway." and considering this latter approach, how small the required downtime could be considering that VRRP config should be disabled first for all migrated SVIs and AG configuration would be consequently deployed (enabled) for all SVIs? is it a matter of being "fast enough" at CLI (with copy&paste commands already well prepared)?

Eventually I will open another thread about deploying VRRP with three Routing Switches because I realize I'm going a little bit OT with respect to the thread's subject, pardon.
Original Message:
Sent: Jul 15, 2022 01:57 AM
From: Arne Opdal
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hi,
As a startingpoint this is important: "Although active gateway and VRRP are no longer globally exclusive in a VSX configuration, active gateway
and VRRP are still exclusive on an SVI. A workaround is to configure VRRP on one SVI (SVI A), and configure
active-gateway on the other SVI (SVI B)." From the VSX guide.

So if you want to use active gateway on a SVI on the VSX cluser you cant use VRRP on this SVI and you must do a hard switchover of the routinginterface from the old core to the new.

If you want to use VRRP you just configure VRRP on all three devices and changes the priority to move the routing to the desired device. If you want to use active gateway on this SVI at a later point, you must remove the VRRP config and configure active gateway. 

This conclude if you want to use active gateway on the VSX core you end up wit a small downtime anyway.

------------------------------
Arne Opdal

Original Message:
Sent: Jul 14, 2022 08:55 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hi Alex! this would be a good approach.

Maybe enabling VRRP to be effective only for one VLAN (a test VLAN), prepare the VLAN interface and Active Gateway configurations on VSX side (to be fast in enabling them serially, first the VLAN interface then the Active Gateway) and enable VRRP on R1 and VSX would be one reasonable route to follow (but...does the VRRP require the IPv4 Routing and the VLAN Interface SVI to be already enabled prior to be effective on the VSX? it seems a Catch 22 situation...or this means that just one VSX Member should have the SVI of the VLAN we're going to migrate? and so only when VRRP is not necessary anymore - thus disabled for that VLAN - we can finally activate the Active Gateway feature for that VLAN Interface on the VSX?).

I'm worried because I believe I'll not have any "human usable maintenance windows" to perform all the above...I agree with you that having an appropriate maintenance window will permit to avoid any too complicated pseudo automatic approach which should include some "semi-automatic" routing switchover...and it will became just a matter of manually moving the routing (SVI addresses) from the R1 to R2 (with an R2 already ready for taking the Router role so with Active Gateway and all other bells and whistles).
Original Message:
Sent: Jul 14, 2022 08:24 AM
From: Alexander Maroukian
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hello parnassus,

I would create one test vlan to test the vrrp (it should be working, I have not tested this) between 5400 and 8360 VSX. After that there could be again the same type of step if you would like to switch to Active Gateway as it is exclusive you need either Active gateway or VRRP at SVI level. But if there is no way to get proper maintenance window (which will make it really easy as you will just change the ip addresses and will start using active gateway) at least you will be able to migrate some of the traffic through the VSX.

------------------------------
-Alex
Original Message:
Sent: Jul 14, 2022 07:43 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hello Alex! Thanks for answering! Well...my purpose is to migrate (some of) the SVIs - exactly as they currently are - from one Core (a standalone switch) to another one (a VSX Cluster) thus without changing any IP addresses.

Let me say I have various 10.100.x.0 /24 network segments routed by the standalone Aruba 5400R zl2 switch.

Each network segment is tied to a specific VLAN id with a SVI so, as example, 10.100.0.0 /24 has VLAN 1000 with 10.100.0.254 as its Gateway, 10.100.1.0 /24 has VLAN 1001 with 10.100.1.254 as its Gateway...and so on...up to, say, the latest network segment 10.100.255.0 /24 associated to VLAN 1255 and 10.100.255.254 as its Gateway.

Let me suppose I need to move some of the SVIs (not all, just a subset of them) into a new Router R2 directly connected (L2) to the current Router R1: I'll need a mechanism to transfer - example - the routing of the VLAN 1100 network segment 10.100.100.0 /24 (which owns the SVI 10.100.100.254) from the Aruba 5400R zl2 standalone switch to the VSX Cluster and this, among many other things, will imply that the 10.100.100.254 Gateway IP address - which needs to remain the very same during and after the transfer (No DHCP in those specific DC network portion) - will pass under the control of the VSX Cluster (with Active Gateway enabled configured with the SVI address set to 10.100.100.254 and each VSX Member configured with a reserved IP address such as the 10.100.100.251 associated to VSX Primary and the 10.100.100.252 associated to VSX Secondary for that VLAN) leaving the control of the Aruba 5400R zl2.

All the above remembering that R2 currently isn't routing and it is just a Layer 2 extension of the R1.

To simplify the whole picture I can say that the R1 (Aruba 5400R zl2) shall remain the Router of - let me say - all network segments belonging to the main root 10.100.0.0 /16 network while the R1 (VSX Cluster) shall become the Router of - let me say - all network segments belonging to the main root 10.200.0.0 /16 network BUT, actually, both those main root networks (with all their numerous /24 segments) are routed only by R1.

The reality is a little bit more complex because there isn't a straight distinction between the two main root networks (the routing of some /24 segments belonging of the first main root network needs to be transferred to R2 too) and so I should take care about each /24 segment almost individually.

From the PoV of the clients (edge devices and server systems) insisting on those /24 network segments the used approach should be the one providing the least possible disruption time or no disruption at all (if possible).

To clarify I'm speaking about dividing (the routing of) a DC Network which is currently serving DC+Campus assets into a DC Network serving the routing of DC systems and a Campus Network serving the routing of Campus edge devices...and the assets I can work with are (and are limited to) (a) the R1 Aruba 5400R zl2, (b) the Aruba 8360 VSX Cluster that will become the future R2 Router and (c) a Perimeter Firewall which is - actually - the NHG Next Hop Gateway for RoW configured as the Router of last resort on the R1...and, in between, it should also take care of becoming the NHG for the next-to-come Router R2 (I know there is a lot more behind and around to discuss about...but my very first doubt is how to partly migrate the routing duties).

Anyway to be able to reuse the routed IP address on the 5400 as the VRRP VIP it must be removed from the interface in the first place. Then assign a new IP to the SVI on 5400, configure VRRP with the original IP.

So here we go again with a minor down time ;-)
Depending on equipment in the network your devices need the ARP to time out because of new mac on the router, more downtime ;-)

I would do it simple, remove the IP on the old core, enable the desired solution on the new with downtime.
Prepare config changes so it works on first attempt, prepare what to do with strange devices which dont update their ARP table, and go for downtime. 


------------------------------
Arne Opdal
------------------------------

Original Message:
Sent: Jul 15, 2022 04:05 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hi Arne! Thank you for kicking in! very appreciated (I really appreciate any contribution!).

"As a starting point this is important: "Although active gateway and VRRP are no longer globally exclusive in a VSX configuration, active gateway and VRRP are still exclusive on an SVI. A workaround is to configure VRRP on one SVI (SVI A), and configure active-gateway on the other SVI (SVI B)." From the VSX guide. So if you want to use active gateway on a SVI on the VSX cluster you cant use VRRP on this SVI and you must do a hard switchover of the routing interface from the old core to the new."

OK I understood that and I'm now definitely aware of this restriction.

I believe the SVI A (VRRP enabled + AG not configured) and SVI B (VRRP disabled + AG enabled) approach isn't the best way to proceed because I need to avoid changes at SVI level during the routing switchover.

"If you want to use VRRP you just configure VRRP on all three devices and changes the priority to move the routing to the desired device. If you want to use active gateway on this SVI at a later point, you must remove the VRRP config and configure active gateway."

The idea of deploying VRRP born while thinking a way of transparently move SVI between Routing Switches...the fact I want to concurrently use the Active Gateway feature at VSX Cluster level is due more to the fact that when I think about VSX and IP Routing on it, I automatically think about AG too...but...rethinking the whole approach...that requirement wouldn't be something to deploy immediately (at least AG could not be enabled exactly during the SVI routing migration...for sure it could be deployed after that and after that VRRP is no more necessary because all required SVIs are already migrated to the VSX Cluster)...so re-reading your sentence "If you want to use active gateway on this SVI at a later point, you must remove the VRRP config and configure active gateway." and considering this latter approach, how small the required downtime could be considering that VRRP config should be disabled first for all migrated SVIs and AG configuration would be consequently deployed (enabled) for all SVIs? is it a matter of being "fast enough" at CLI (with copy&paste commands already well prepared)?

Eventually I will open another thread about deploying VRRP with three Routing Switches because I realize I'm going a little bit OT with respect to the thread's subject, pardon.
Original Message:
Sent: Jul 15, 2022 01:57 AM
From: Arne Opdal
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hi,
As a startingpoint this is important: "Although active gateway and VRRP are no longer globally exclusive in a VSX configuration, active gateway
and VRRP are still exclusive on an SVI. A workaround is to configure VRRP on one SVI (SVI A), and configure
active-gateway on the other SVI (SVI B)." From the VSX guide.

So if you want to use active gateway on a SVI on the VSX cluser you cant use VRRP on this SVI and you must do a hard switchover of the routinginterface from the old core to the new.

If you want to use VRRP you just configure VRRP on all three devices and changes the priority to move the routing to the desired device. If you want to use active gateway on this SVI at a later point, you must remove the VRRP config and configure active gateway. 

This conclude if you want to use active gateway on the VSX core you end up wit a small downtime anyway.

------------------------------
Arne Opdal

Original Message:
Sent: Jul 14, 2022 08:55 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hi Alex! this would be a good approach.

Maybe enabling VRRP to be effective only for one VLAN (a test VLAN), prepare the VLAN interface and Active Gateway configurations on VSX side (to be fast in enabling them serially, first the VLAN interface then the Active Gateway) and enable VRRP on R1 and VSX would be one reasonable route to follow (but...does the VRRP require the IPv4 Routing and the VLAN Interface SVI to be already enabled prior to be effective on the VSX? it seems a Catch 22 situation...or this means that just one VSX Member should have the SVI of the VLAN we're going to migrate? and so only when VRRP is not necessary anymore - thus disabled for that VLAN - we can finally activate the Active Gateway feature for that VLAN Interface on the VSX?).

I'm worried because I believe I'll not have any "human usable maintenance windows" to perform all the above...I agree with you that having an appropriate maintenance window will permit to avoid any too complicated pseudo automatic approach which should include some "semi-automatic" routing switchover...and it will became just a matter of manually moving the routing (SVI addresses) from the R1 to R2 (with an R2 already ready for taking the Router role so with Active Gateway and all other bells and whistles).
Original Message:
Sent: Jul 14, 2022 08:24 AM
From: Alexander Maroukian
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hello parnassus,

I would create one test vlan to test the vrrp (it should be working, I have not tested this) between 5400 and 8360 VSX. After that there could be again the same type of step if you would like to switch to Active Gateway as it is exclusive you need either Active gateway or VRRP at SVI level. But if there is no way to get proper maintenance window (which will make it really easy as you will just change the ip addresses and will start using active gateway) at least you will be able to migrate some of the traffic through the VSX.

------------------------------
-Alex
Original Message:
Sent: Jul 14, 2022 07:43 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hello Alex! Thanks for answering! Well...my purpose is to migrate (some of) the SVIs - exactly as they currently are - from one Core (a standalone switch) to another one (a VSX Cluster) thus without changing any IP addresses.

Let me say I have various 10.100.x.0 /24 network segments routed by the standalone Aruba 5400R zl2 switch.

Each network segment is tied to a specific VLAN id with a SVI so, as example, 10.100.0.0 /24 has VLAN 1000 with 10.100.0.254 as its Gateway, 10.100.1.0 /24 has VLAN 1001 with 10.100.1.254 as its Gateway...and so on...up to, say, the latest network segment 10.100.255.0 /24 associated to VLAN 1255 and 10.100.255.254 as its Gateway.

Let me suppose I need to move some of the SVIs (not all, just a subset of them) into a new Router R2 directly connected (L2) to the current Router R1: I'll need a mechanism to transfer - example - the routing of the VLAN 1100 network segment 10.100.100.0 /24 (which owns the SVI 10.100.100.254) from the Aruba 5400R zl2 standalone switch to the VSX Cluster and this, among many other things, will imply that the 10.100.100.254 Gateway IP address - which needs to remain the very same during and after the transfer (No DHCP in those specific DC network portion) - will pass under the control of the VSX Cluster (with Active Gateway enabled configured with the SVI address set to 10.100.100.254 and each VSX Member configured with a reserved IP address such as the 10.100.100.251 associated to VSX Primary and the 10.100.100.252 associated to VSX Secondary for that VLAN) leaving the control of the Aruba 5400R zl2.

All the above remembering that R2 currently isn't routing and it is just a Layer 2 extension of the R1.

To simplify the whole picture I can say that the R1 (Aruba 5400R zl2) shall remain the Router of - let me say - all network segments belonging to the main root 10.100.0.0 /16 network while the R1 (VSX Cluster) shall become the Router of - let me say - all network segments belonging to the main root 10.200.0.0 /16 network BUT, actually, both those main root networks (with all their numerous /24 segments) are routed only by R1.

The reality is a little bit more complex because there isn't a straight distinction between the two main root networks (the routing of some /24 segments belonging of the first main root network needs to be transferred to R2 too) and so I should take care about each /24 segment almost individually.

From the PoV of the clients (edge devices and server systems) insisting on those /24 network segments the used approach should be the one providing the least possible disruption time or no disruption at all (if possible).

To clarify I'm speaking about dividing (the routing of) a DC Network which is currently serving DC+Campus assets into a DC Network serving the routing of DC systems and a Campus Network serving the routing of Campus edge devices...and the assets I can work with are (and are limited to) (a) the R1 Aruba 5400R zl2, (b) the Aruba 8360 VSX Cluster that will become the future R2 Router and (c) a Perimeter Firewall which is - actually - the NHG Next Hop Gateway for RoW configured as the Router of last resort on the R1...and, in between, it should also take care of becoming the NHG for the next-to-come Router R2 (I know there is a lot more behind and around to discuss about...but my very first doubt is how to partly migrate the routing duties).

Hi Arne! you're uncovering the Pandora's box...and I'm going OT!

I'm not totally sure that the first minor downtime:

"Anyway to be able to reuse the routed IP address on the 5400 as the VRRP VIP it must be removed from the interface in the first place. Then assign a new IP to the SVI on 5400, configure VRRP with the original IP. So here we go again with a minor down time ;-)"

is mandatory.

The VLAN id and its L3 interface (SVI) need to be present (and they are) before configuring the VRRP VRID (Virtual Router ID) or, at least, this is what I generally found reading about VRRP implementations on HP ProCurve/Aruba.

Looking at an example [*] of configuring a Core Switch Core-1 to become VRRP Master with VRID Owner role for a particular VLAN, it doesn't show any special reconfiguration of the SVI on that VLAN (am I wrong?), that's the sequence documentation reports:

Core-1(config#) ip routing
Core-1(config#) router vrrp
Core-1(vrrp)# enable
Core-1(vrrp)# vlan 201
Core-1(vlan-201)# untag a1-a10
Core-1(vlan-201)# ip address 20.0.0.1/24
Core-1(vlan-201)# vrrp vrid 1
Core-1(vlan-201-vrid-1)# owner
Core-1(vlan-201-vrid-1)# virtual-ip-address 20.0.0.1/24
Core-1(vlan-201-vrid-1)# enable

and that's the sequence on the Core Switch Core-2 to become VRRP Backup with the VRID Backup role for the very same VLAN Id:

Core-2(config#) ip routing
Core-2(config#) router vrrp
Core-2(vrrp)# enable
Core-2(vrrp)# vlan 201
Core-2(vlan-201)# untag a1-a10
Core-2(vlan-201)# ip address 20.0.0.2/24
Core-2(vlan-201)# vrrp vrid 1
Core-2(vlan-201-vrid-1)# backup
Core-2(vlan-201-vrid-1)# virtual-ip-address 20.0.0.1/24
Core-2(vlan-201-vrid-1)# enable

so it seems that, at least looking at above example, the VLAN 201 and its SVI 20.0.0.1 need to be just defined and operating before (a) enabling VRRP and (b) configuring the VRRP VRID for that VLAN.

The VRRP VRID is configured to use the very same IP used on the existing VLAN's SVI (this on the Core with the VRID Owner Role - the VRRP Master), maybe the problem kicks in on the VRRP Backup switch that need to carry the Owner role for the SVIs I want to transfer the routing to (in my case I'm not going to have another Aruba 5400R zl2 so I need to study the VRRP configuration process on ArubaOS-CX).

[*] this is an example was freely taken from Aruba 3810M/5400R zl2 Management and Configuration Guide for ArubaOS-Switch 16.11 but this can be seen also here.

"I would do it simple, remove the IP on the old core, enable the desired solution on the new with downtime. Prepare config changes so it works on first attempt, prepare what to do with strange devices which don't update their ARP table, and go for downtime."

I agree with you, I prefer the KISS approach but, sometime, there are nasty restrictions and things require too convoluted solutions (prone to errors and potentially capable of hitting unexpected corner cases)...in the end I'm going to fight for applying the simplest possible approach (granting the minimum possible downtime).

I understood that, even if I reach the point where - with no appreciable downtime/disruption - the routing of required SVIs is transferred to the VRRP Backup core switch (supposedly the VSX Primary switch) and for those VLANs the VRID has finally the Owner role, there will necessarily be the problem of disabling the VRRP configuration on both ends in favor of the Active Gateway (on the VSX Cluster side) and this will require a Downtime...so, in the end, it seems that I can't avoid a minimum disruption.
Original Message:
Sent: Jul 15, 2022 04:19 AM
From: Arne Opdal
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Anyway to be able to reuse the routed IP address on the 5400 as the VRRP VIP it must be removed from the interface in the first place. Then assign a new IP to the SVI on 5400, configure VRRP with the original IP.

So here we go again with a minor down time ;-)
Depending on equipment in the network your devices need the ARP to time out because of new mac on the router, more downtime ;-)

I would do it simple, remove the IP on the old core, enable the desired solution on the new with downtime.
Prepare config changes so it works on first attempt, prepare what to do with strange devices which dont update their ARP table, and go for downtime. 


------------------------------
Arne Opdal

Original Message:
Sent: Jul 15, 2022 04:05 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hi Arne! Thank you for kicking in! very appreciated (I really appreciate any contribution!).

"As a starting point this is important: "Although active gateway and VRRP are no longer globally exclusive in a VSX configuration, active gateway and VRRP are still exclusive on an SVI. A workaround is to configure VRRP on one SVI (SVI A), and configure active-gateway on the other SVI (SVI B)." From the VSX guide. So if you want to use active gateway on a SVI on the VSX cluster you cant use VRRP on this SVI and you must do a hard switchover of the routing interface from the old core to the new."

OK I understood that and I'm now definitely aware of this restriction.

I believe the SVI A (VRRP enabled + AG not configured) and SVI B (VRRP disabled + AG enabled) approach isn't the best way to proceed because I need to avoid changes at SVI level during the routing switchover.

"If you want to use VRRP you just configure VRRP on all three devices and changes the priority to move the routing to the desired device. If you want to use active gateway on this SVI at a later point, you must remove the VRRP config and configure active gateway."

The idea of deploying VRRP born while thinking a way of transparently move SVI between Routing Switches...the fact I want to concurrently use the Active Gateway feature at VSX Cluster level is due more to the fact that when I think about VSX and IP Routing on it, I automatically think about AG too...but...rethinking the whole approach...that requirement wouldn't be something to deploy immediately (at least AG could not be enabled exactly during the SVI routing migration...for sure it could be deployed after that and after that VRRP is no more necessary because all required SVIs are already migrated to the VSX Cluster)...so re-reading your sentence "If you want to use active gateway on this SVI at a later point, you must remove the VRRP config and configure active gateway." and considering this latter approach, how small the required downtime could be considering that VRRP config should be disabled first for all migrated SVIs and AG configuration would be consequently deployed (enabled) for all SVIs? is it a matter of being "fast enough" at CLI (with copy&paste commands already well prepared)?

Eventually I will open another thread about deploying VRRP with three Routing Switches because I realize I'm going a little bit OT with respect to the thread's subject, pardon.
Original Message:
Sent: Jul 15, 2022 01:57 AM
From: Arne Opdal
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hi,
As a startingpoint this is important: "Although active gateway and VRRP are no longer globally exclusive in a VSX configuration, active gateway
and VRRP are still exclusive on an SVI. A workaround is to configure VRRP on one SVI (SVI A), and configure
active-gateway on the other SVI (SVI B)." From the VSX guide.

So if you want to use active gateway on a SVI on the VSX cluser you cant use VRRP on this SVI and you must do a hard switchover of the routinginterface from the old core to the new.

If you want to use VRRP you just configure VRRP on all three devices and changes the priority to move the routing to the desired device. If you want to use active gateway on this SVI at a later point, you must remove the VRRP config and configure active gateway. 

This conclude if you want to use active gateway on the VSX core you end up wit a small downtime anyway.

------------------------------
Arne Opdal

Original Message:
Sent: Jul 14, 2022 08:55 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hi Alex! this would be a good approach.

Maybe enabling VRRP to be effective only for one VLAN (a test VLAN), prepare the VLAN interface and Active Gateway configurations on VSX side (to be fast in enabling them serially, first the VLAN interface then the Active Gateway) and enable VRRP on R1 and VSX would be one reasonable route to follow (but...does the VRRP require the IPv4 Routing and the VLAN Interface SVI to be already enabled prior to be effective on the VSX? it seems a Catch 22 situation...or this means that just one VSX Member should have the SVI of the VLAN we're going to migrate? and so only when VRRP is not necessary anymore - thus disabled for that VLAN - we can finally activate the Active Gateway feature for that VLAN Interface on the VSX?).

I'm worried because I believe I'll not have any "human usable maintenance windows" to perform all the above...I agree with you that having an appropriate maintenance window will permit to avoid any too complicated pseudo automatic approach which should include some "semi-automatic" routing switchover...and it will became just a matter of manually moving the routing (SVI addresses) from the R1 to R2 (with an R2 already ready for taking the Router role so with Active Gateway and all other bells and whistles).
Original Message:
Sent: Jul 14, 2022 08:24 AM
From: Alexander Maroukian
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hello parnassus,

I would create one test vlan to test the vrrp (it should be working, I have not tested this) between 5400 and 8360 VSX. After that there could be again the same type of step if you would like to switch to Active Gateway as it is exclusive you need either Active gateway or VRRP at SVI level. But if there is no way to get proper maintenance window (which will make it really easy as you will just change the ip addresses and will start using active gateway) at least you will be able to migrate some of the traffic through the VSX.

------------------------------
-Alex
Original Message:
Sent: Jul 14, 2022 07:43 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hello Alex! Thanks for answering! Well...my purpose is to migrate (some of) the SVIs - exactly as they currently are - from one Core (a standalone switch) to another one (a VSX Cluster) thus without changing any IP addresses.

Let me say I have various 10.100.x.0 /24 network segments routed by the standalone Aruba 5400R zl2 switch.

Each network segment is tied to a specific VLAN id with a SVI so, as example, 10.100.0.0 /24 has VLAN 1000 with 10.100.0.254 as its Gateway, 10.100.1.0 /24 has VLAN 1001 with 10.100.1.254 as its Gateway...and so on...up to, say, the latest network segment 10.100.255.0 /24 associated to VLAN 1255 and 10.100.255.254 as its Gateway.

Let me suppose I need to move some of the SVIs (not all, just a subset of them) into a new Router R2 directly connected (L2) to the current Router R1: I'll need a mechanism to transfer - example - the routing of the VLAN 1100 network segment 10.100.100.0 /24 (which owns the SVI 10.100.100.254) from the Aruba 5400R zl2 standalone switch to the VSX Cluster and this, among many other things, will imply that the 10.100.100.254 Gateway IP address - which needs to remain the very same during and after the transfer (No DHCP in those specific DC network portion) - will pass under the control of the VSX Cluster (with Active Gateway enabled configured with the SVI address set to 10.100.100.254 and each VSX Member configured with a reserved IP address such as the 10.100.100.251 associated to VSX Primary and the 10.100.100.252 associated to VSX Secondary for that VLAN) leaving the control of the Aruba 5400R zl2.

All the above remembering that R2 currently isn't routing and it is just a Layer 2 extension of the R1.

To simplify the whole picture I can say that the R1 (Aruba 5400R zl2) shall remain the Router of - let me say - all network segments belonging to the main root 10.100.0.0 /16 network while the R1 (VSX Cluster) shall become the Router of - let me say - all network segments belonging to the main root 10.200.0.0 /16 network BUT, actually, both those main root networks (with all their numerous /24 segments) are routed only by R1.

The reality is a little bit more complex because there isn't a straight distinction between the two main root networks (the routing of some /24 segments belonging of the first main root network needs to be transferred to R2 too) and so I should take care about each /24 segment almost individually.

From the PoV of the clients (edge devices and server systems) insisting on those /24 network segments the used approach should be the one providing the least possible disruption time or no disruption at all (if possible).

To clarify I'm speaking about dividing (the routing of) a DC Network which is currently serving DC+Campus assets into a DC Network serving the routing of DC systems and a Campus Network serving the routing of Campus edge devices...and the assets I can work with are (and are limited to) (a) the R1 Aruba 5400R zl2, (b) the Aruba 8360 VSX Cluster that will become the future R2 Router and (c) a Perimeter Firewall which is - actually - the NHG Next Hop Gateway for RoW configured as the Router of last resort on the R1...and, in between, it should also take care of becoming the NHG for the next-to-come Router R2 (I know there is a lot more behind and around to discuss about...but my very first doubt is how to partly migrate the routing duties).

Hi,
Your goal is to move the routed interface away form the 5400 - read up the RFC https://datatracker.ietf.org/doc/html/rfc3768
The path you are thinking to walk down is a quite bumpy road I think. ;-) And it's not a road I would recommend. 

Today there is just a single core device and the requirement for uptime can't be absolute, and the downtime per VLAN could be small if prepared correctly.

With a lot of small increments and introducing a new temporary protocol (VRRP), to me it looks like creating a pitfall. Doing a clear break and getting from "old" to "new permanent" in one step is the path I would take.

From the RFC:

IP Address Owner       The VRRP router that has the virtual router's
                          IP address(es) as real interface address(es).
                          This is the router that, when up, will respond
                          to packets addressed to one of these IP
                          addresses for ICMP pings, TCP connections,
                          etc.

   Virtual Router Master  The VRRP router that is assuming the
                          responsibility of forwarding packets sent to
                          the IP address(es) associated with the virtual
                          router, and answering ARP requests for these
                          IP addresses.  Note that if the IP address
                          owner is available, then it will always become
                          the Master.

------------------------------
Arne Opdal
------------------------------

Original Message:
Sent: Jul 15, 2022 09:18 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hi Arne! you're uncovering the Pandora's box...and I'm going OT!

I'm not totally sure that the first minor downtime:

"Anyway to be able to reuse the routed IP address on the 5400 as the VRRP VIP it must be removed from the interface in the first place. Then assign a new IP to the SVI on 5400, configure VRRP with the original IP. So here we go again with a minor down time ;-)"

is mandatory.

The VLAN id and its L3 interface (SVI) need to be present (and they are) before configuring the VRRP VRID (Virtual Router ID) or, at least, this is what I generally found reading about VRRP implementations on HP ProCurve/Aruba.

Looking at an example [*] of configuring a Core Switch Core-1 to become VRRP Master with VRID Owner role for a particular VLAN, it doesn't show any special reconfiguration of the SVI on that VLAN (am I wrong?), that's the sequence documentation reports:

Core-1(config#) ip routing
Core-1(config#) router vrrp
Core-1(vrrp)# enable
Core-1(vrrp)# vlan 201
Core-1(vlan-201)# untag a1-a10
Core-1(vlan-201)# ip address 20.0.0.1/24
Core-1(vlan-201)# vrrp vrid 1
Core-1(vlan-201-vrid-1)# owner
Core-1(vlan-201-vrid-1)# virtual-ip-address 20.0.0.1/24
Core-1(vlan-201-vrid-1)# enable

and that's the sequence on the Core Switch Core-2 to become VRRP Backup with the VRID Backup role for the very same VLAN Id:

Core-2(config#) ip routing
Core-2(config#) router vrrp
Core-2(vrrp)# enable
Core-2(vrrp)# vlan 201
Core-2(vlan-201)# untag a1-a10
Core-2(vlan-201)# ip address 20.0.0.2/24
Core-2(vlan-201)# vrrp vrid 1
Core-2(vlan-201-vrid-1)# backup
Core-2(vlan-201-vrid-1)# virtual-ip-address 20.0.0.1/24
Core-2(vlan-201-vrid-1)# enable

so it seems that, at least looking at above example, the VLAN 201 and its SVI 20.0.0.1 need to be just defined and operating before (a) enabling VRRP and (b) configuring the VRRP VRID for that VLAN.

The VRRP VRID is configured to use the very same IP used on the existing VLAN's SVI (this on the Core with the VRID Owner Role - the VRRP Master), maybe the problem kicks in on the VRRP Backup switch that need to carry the Owner role for the SVIs I want to transfer the routing to (in my case I'm not going to have another Aruba 5400R zl2 so I need to study the VRRP configuration process on ArubaOS-CX).

[*] this is an example was freely taken from Aruba 3810M/5400R zl2 Management and Configuration Guide for ArubaOS-Switch 16.11 but this can be seen also here.

"I would do it simple, remove the IP on the old core, enable the desired solution on the new with downtime. Prepare config changes so it works on first attempt, prepare what to do with strange devices which don't update their ARP table, and go for downtime."

I agree with you, I prefer the KISS approach but, sometime, there are nasty restrictions and things require too convoluted solutions (prone to errors and potentially capable of hitting unexpected corner cases)...in the end I'm going to fight for applying the simplest possible approach (granting the minimum possible downtime).

I understood that, even if I reach the point where - with no appreciable downtime/disruption - the routing of required SVIs is transferred to the VRRP Backup core switch (supposedly the VSX Primary switch) and for those VLANs the VRID has finally the Owner role, there will necessarily be the problem of disabling the VRRP configuration on both ends in favor of the Active Gateway (on the VSX Cluster side) and this will require a Downtime...so, in the end, it seems that I can't avoid a minimum disruption.
Original Message:
Sent: Jul 15, 2022 04:19 AM
From: Arne Opdal
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Anyway to be able to reuse the routed IP address on the 5400 as the VRRP VIP it must be removed from the interface in the first place. Then assign a new IP to the SVI on 5400, configure VRRP with the original IP.

So here we go again with a minor down time ;-)
Depending on equipment in the network your devices need the ARP to time out because of new mac on the router, more downtime ;-)

I would do it simple, remove the IP on the old core, enable the desired solution on the new with downtime.
Prepare config changes so it works on first attempt, prepare what to do with strange devices which dont update their ARP table, and go for downtime. 


------------------------------
Arne Opdal

Original Message:
Sent: Jul 15, 2022 04:05 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hi Arne! Thank you for kicking in! very appreciated (I really appreciate any contribution!).

"As a starting point this is important: "Although active gateway and VRRP are no longer globally exclusive in a VSX configuration, active gateway and VRRP are still exclusive on an SVI. A workaround is to configure VRRP on one SVI (SVI A), and configure active-gateway on the other SVI (SVI B)." From the VSX guide. So if you want to use active gateway on a SVI on the VSX cluster you cant use VRRP on this SVI and you must do a hard switchover of the routing interface from the old core to the new."

OK I understood that and I'm now definitely aware of this restriction.

I believe the SVI A (VRRP enabled + AG not configured) and SVI B (VRRP disabled + AG enabled) approach isn't the best way to proceed because I need to avoid changes at SVI level during the routing switchover.

"If you want to use VRRP you just configure VRRP on all three devices and changes the priority to move the routing to the desired device. If you want to use active gateway on this SVI at a later point, you must remove the VRRP config and configure active gateway."

The idea of deploying VRRP born while thinking a way of transparently move SVI between Routing Switches...the fact I want to concurrently use the Active Gateway feature at VSX Cluster level is due more to the fact that when I think about VSX and IP Routing on it, I automatically think about AG too...but...rethinking the whole approach...that requirement wouldn't be something to deploy immediately (at least AG could not be enabled exactly during the SVI routing migration...for sure it could be deployed after that and after that VRRP is no more necessary because all required SVIs are already migrated to the VSX Cluster)...so re-reading your sentence "If you want to use active gateway on this SVI at a later point, you must remove the VRRP config and configure active gateway." and considering this latter approach, how small the required downtime could be considering that VRRP config should be disabled first for all migrated SVIs and AG configuration would be consequently deployed (enabled) for all SVIs? is it a matter of being "fast enough" at CLI (with copy&paste commands already well prepared)?

Eventually I will open another thread about deploying VRRP with three Routing Switches because I realize I'm going a little bit OT with respect to the thread's subject, pardon.
Original Message:
Sent: Jul 15, 2022 01:57 AM
From: Arne Opdal
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hi,
As a startingpoint this is important: "Although active gateway and VRRP are no longer globally exclusive in a VSX configuration, active gateway
and VRRP are still exclusive on an SVI. A workaround is to configure VRRP on one SVI (SVI A), and configure
active-gateway on the other SVI (SVI B)." From the VSX guide.

So if you want to use active gateway on a SVI on the VSX cluser you cant use VRRP on this SVI and you must do a hard switchover of the routinginterface from the old core to the new.

If you want to use VRRP you just configure VRRP on all three devices and changes the priority to move the routing to the desired device. If you want to use active gateway on this SVI at a later point, you must remove the VRRP config and configure active gateway. 

This conclude if you want to use active gateway on the VSX core you end up wit a small downtime anyway.

------------------------------
Arne Opdal

Original Message:
Sent: Jul 14, 2022 08:55 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hi Alex! this would be a good approach.

Maybe enabling VRRP to be effective only for one VLAN (a test VLAN), prepare the VLAN interface and Active Gateway configurations on VSX side (to be fast in enabling them serially, first the VLAN interface then the Active Gateway) and enable VRRP on R1 and VSX would be one reasonable route to follow (but...does the VRRP require the IPv4 Routing and the VLAN Interface SVI to be already enabled prior to be effective on the VSX? it seems a Catch 22 situation...or this means that just one VSX Member should have the SVI of the VLAN we're going to migrate? and so only when VRRP is not necessary anymore - thus disabled for that VLAN - we can finally activate the Active Gateway feature for that VLAN Interface on the VSX?).

I'm worried because I believe I'll not have any "human usable maintenance windows" to perform all the above...I agree with you that having an appropriate maintenance window will permit to avoid any too complicated pseudo automatic approach which should include some "semi-automatic" routing switchover...and it will became just a matter of manually moving the routing (SVI addresses) from the R1 to R2 (with an R2 already ready for taking the Router role so with Active Gateway and all other bells and whistles).
Original Message:
Sent: Jul 14, 2022 08:24 AM
From: Alexander Maroukian
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hello parnassus,

I would create one test vlan to test the vrrp (it should be working, I have not tested this) between 5400 and 8360 VSX. After that there could be again the same type of step if you would like to switch to Active Gateway as it is exclusive you need either Active gateway or VRRP at SVI level. But if there is no way to get proper maintenance window (which will make it really easy as you will just change the ip addresses and will start using active gateway) at least you will be able to migrate some of the traffic through the VSX.

------------------------------
-Alex
Original Message:
Sent: Jul 14, 2022 07:43 AM
From: Davide Poletto
Subject: VRRP between an Aruba 5400R zl2 and a VSX Cluster: is it possible?

Hello Alex! Thanks for answering! Well...my purpose is to migrate (some of) the SVIs - exactly as they currently are - from one Core (a standalone switch) to another one (a VSX Cluster) thus without changing any IP addresses.

Let me say I have various 10.100.x.0 /24 network segments routed by the standalone Aruba 5400R zl2 switch.

Each network segment is tied to a specific VLAN id with a SVI so, as example, 10.100.0.0 /24 has VLAN 1000 with 10.100.0.254 as its Gateway, 10.100.1.0 /24 has VLAN 1001 with 10.100.1.254 as its Gateway...and so on...up to, say, the latest network segment 10.100.255.0 /24 associated to VLAN 1255 and 10.100.255.254 as its Gateway.

Let me suppose I need to move some of the SVIs (not all, just a subset of them) into a new Router R2 directly connected (L2) to the current Router R1: I'll need a mechanism to transfer - example - the routing of the VLAN 1100 network segment 10.100.100.0 /24 (which owns the SVI 10.100.100.254) from the Aruba 5400R zl2 standalone switch to the VSX Cluster and this, among many other things, will imply that the 10.100.100.254 Gateway IP address - which needs to remain the very same during and after the transfer (No DHCP in those specific DC network portion) - will pass under the control of the VSX Cluster (with Active Gateway enabled configured with the SVI address set to 10.100.100.254 and each VSX Member configured with a reserved IP address such as the 10.100.100.251 associated to VSX Primary and the 10.100.100.252 associated to VSX Secondary for that VLAN) leaving the control of the Aruba 5400R zl2.

All the above remembering that R2 currently isn't routing and it is just a Layer 2 extension of the R1.

To simplify the whole picture I can say that the R1 (Aruba 5400R zl2) shall remain the Router of - let me say - all network segments belonging to the main root 10.100.0.0 /16 network while the R1 (VSX Cluster) shall become the Router of - let me say - all network segments belonging to the main root 10.200.0.0 /16 network BUT, actually, both those main root networks (with all their numerous /24 segments) are routed only by R1.

The reality is a little bit more complex because there isn't a straight distinction between the two main root networks (the routing of some /24 segments belonging of the first main root network needs to be transferred to R2 too) and so I should take care about each /24 segment almost individually.

From the PoV of the clients (edge devices and server systems) insisting on those /24 network segments the used approach should be the one providing the least possible disruption time or no disruption at all (if possible).

To clarify I'm speaking about dividing (the routing of) a DC Network which is currently serving DC+Campus assets into a DC Network serving the routing of DC systems and a Campus Network serving the routing of Campus edge devices...and the assets I can work with are (and are limited to) (a) the R1 Aruba 5400R zl2, (b) the Aruba 8360 VSX Cluster that will become the future R2 Router and (c) a Perimeter Firewall which is - actually - the NHG Next Hop Gateway for RoW configured as the Router of last resort on the R1...and, in between, it should also take care of becoming the NHG for the next-to-come Router R2 (I know there is a lot more behind and around to discuss about...but my very first doubt is how to partly migrate the routing duties).

Hi Arne! Yes, absolutely agree with you.

I was just investigating the potential usage of VRRP to transfer (for some selected SVIs) the routing duties from the existing Routing Core to a new one (and moving away the SVI from existing Core and keeping them on the new one is clearly the second phase, possible only once the second Router started to perform routing when it is forced to do so for those VLANs only [*]) but I understood that - now it is pretty evident - it is going to be a quite challenging road and, as said, I prefer a KISS, error-prone approach.

[*] the (silly?) idea behind that is that, at some point, I will be able to force the VRRP Backup Routing Switch (the VSX Primary in my case) to take the VRRP Owner role only for some selected SVIs (the ones that will be moved out from the VRRP Master Routing Switch where they should be left under the VRID Backup role). This implies that one can not only config at first but also drive (when one wants) the switchover of Owner/Backup roles per single VRID (per single SVI), a thing I supposed it is possible but I've never studied before. Maybe I'm doing a lot of confusion...outing duties).

Edit:

Your sentence: "Today there is just a single core device and the requirement for uptime can't be absolute, and the downtime per VLAN could be small if prepared correctly." is very interesting...and I agree with you about that 100%...but the pivotal point around this concept and around which we are moving is that it's not the expected uptime (or the required uptime) considering a standalone routing switch but the fact that, even a standalone routing switch (properly configured from the HW/SW standpoint <- remember that an Aruba 5400R zl2 supports dual MMs and redundant Power Supplies and backplane faults are seldom seen), is easily capable of getting users used to such of exceptional uptime (3 Years? 5 Years? 7 Years? 9 Years? with no issues at all)...that's to say that it's not what users expect from the network but it's the network that, operating flawlessly, get the users to be used to such long uptimes (to the point that such very long uptime with no downtimes could become a requirement but just as a side effect! the line of reasoning, at some point, became: "In the last 5 Years the network never wend down, never. So if you plan a routing migration you should operate in a way to provide no downtime at all because we're not used to" or something like that). It's a little bit extreme but, trust me, it's also quite real.