Wired Intelligent Edge

last person joined: 12 hours ago 

Bring performance and reliability to your network with the Aruba Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of the ArubaOS-Switch and ArubaOS-CX devices, and find ways to improve security across your network to bring together a mobile first solution.
Expand all | Collapse all

migrating VLANs to a new path

This thread has been viewed 21 times
  • 1.  migrating VLANs to a new path

    Posted Sep 27, 2021 08:30 AM

    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.


    Michael Naylor

  • 2.  RE: migrating VLANs to a new path

    Posted Sep 27, 2021 11:21 AM
    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

  • 3.  RE: migrating VLANs to a new path

    Posted Sep 27, 2021 11:50 AM
    Datacenter at the top. The links in question are between the two 5406 switches. There are 6 VLANs that span this link as well as through other 5406 across campus to our other datacenter (not displayed here).
    The green link is the current scenario with failing link. Just a trunk [trunk A1 trk1 trunk]
    We have now created the red links with no spanned VLANs and I've verified the integrity of the path by bringing up the interfaces.
    I would like to...
    1. Create the LACP trunk with links disabled.
    2. Enable the trunk link.
    3. Move VLANs to the new link (tagged vlan 1-4)
    4. Remove VLANs from the old link (no tagged vlan 1-4)

    Could I do this one VLAN at a time without causing disruption to the others? How long will things take to reconverge? It can't be any worse than the issues that the current flapping link causes at random.

    Michael Naylor

  • 4.  RE: migrating VLANs to a new path

    Posted Sep 27, 2021 05:40 PM
    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

  • 5.  RE: migrating VLANs to a new path

    Posted Sep 28, 2021 08:18 AM
    Thanks for the suggestions and insight.
    We had more issues with the single link last evening, so we took advantage of the "network issues" to finish the job. I already set things up as you suggested and just had to enable the physical interfaces and move the VLANs over. Very little (if any) noticeable churn.We now have two links bonded together using LACP and feel much more confident about the situation.

    Michael Naylor

  • 6.  RE: migrating VLANs to a new path

    Posted Sep 28, 2021 06:06 PM
    Hello Michael, glad you fixed!

    Davide Poletto