Hi Michael, in order to troubleshoot the current scenario (you're suspecting that the current
single green physical link - the only member of the current Port Trunk logical interface - has issues) why not considering to exploit the current - ready - Port Trunk logical interface by simply adding new members (the red physical links)?
It will be a transparent addition (if the red physical links and the green physical link share the very same speed, media type and duplex mode on each side) and, more importantly, you will be able to transparently disable the "offending" green physical link in favor of the two red physical links newly added, that's clearly to test if removing the green and adding the reds has a positive impact or not. No VLAN memberships changes are required.
If, on the other hand, your goal is to completely change the composition and operating mode (from
trunk to
lacp) of the Port Trunk involved between your two Aruba 5400R zl2 switches then your plan for a new Port Trunk logical interface (of type lacp instead of type trunk) is very understandable: to avoid disruption you can pre-configure it completely - up to allowing required VLANs tagged and untagged as required (mirroring what is configured on the actual) - just remember to do that with physical member interfaces disabled first (so no RSTP will kick in to block the consequent loop caused by the two Port Trunk logical interfaces being enabled at the same time).
There is probably a way to migrate your interconnection from a Port Trunk logical interface to another (with same or different port performances) in a basically hitless way, working on RSTP priority of the involved Port Trunk logical interfaces (on both ends concurrently) and letting the RSTP to move traffic from using one Port Trunk (to be dismissed) to using the alternate Port Trunk (the new desired one). I was never forced to do that - so I've not tested in on ArubaOS-Switch OS based switches - but I recall it was discussed (and proved to be feasible) on Comware OS based switch series in a migration attempt from 2x1Gbps LACP LAG to a 2x10Gbps LACP LAG described
here.
Otherwise you would schedule a maintenance window to do all the work if some disruption can be tolerated.
If I were you I'll probably try - first of all - to better figure out if there are really physical issues on the current green link before moving along to an alternate configuration of the uplink.
------------------------------
Davide Poletto
------------------------------
Original Message:
Sent: Sep 27, 2021 11:50 AM
From: Michael Naylor
Subject: migrating VLANs to a new path
------------------------------
Michael Naylor
Original Message:
Sent: Sep 27, 2021 11:21 AM
From: Davide Poletto
Subject: migrating VLANs to a new path
Hi Michael, could you better explain who is connected with who? you name two Aruba 5406R zl2 Switches (interconnected with a single link uplink, is it right?) but also you name a Datacenter...where you need to build a dual links Port Trunk? between your two 5400R zl2 or between them and the Datacenter? a simple drawing of your network topology would be of help (current/desired scenarios).
------------------------------
Davide Poletto
Original Message:
Sent: Sep 27, 2021 08:30 AM
From: Michael Naylor
Subject: migrating VLANs to a new path
Hello,
I'm hoping to solicit some info/recommendations for a problem that I've encountered.
Our core is made up of 5406Rzl2 switches, with a few VLANs that span the entire campus. It is those VLANs that are in question. RPVST is our STP of choice.
Between two of these switches, we only have a single link (trk1) and that link has been experiencing some (I'm assuming physical) issues. This is the last leg of those VLANs to our datacenter and, consequently, when the link experiences issues, our servers and storage get a bit angry.
I would like to build a new path, trunking two links together using LACP, and migrate the VLANs over to it.
My question is, when I bring up this new link, will it immediately cause issues and block the other link? My assumption is, because we use RPVST, that it will not and I can add the VLANs one at a time to this new path.
Any thoughts or suggestions are appreciated and, of course, let me know if I'm way off base.
-Mike
------------------------------
Michael Naylor
------------------------------