#NetApp ONTAP LACP behavior during switch migration (MLAG → Spine-Leaf)

1 messages · Page 1 of 1 (latest)

arctic rain
#

Hi I have a NetApp ONTAP cluster connected to two ToR switches using LACP (ifgrp). The switches currently operate as a pair (MLAG/vPC style), but the network team is planning to migrate the fabric to a spine-leaf topology, where each switch will become an independent leaf connected to the spine.
The proposed migration plan is:

  1. Power down Switch 1 and reconnect its uplinks to the spine
  2. Reconfigure Switch 1 as a leaf and power it on with ports disabled
  3. Enable ports on Switch 1 and shut the ports on Switch 2 at the same time
  4. Power down Switch 2 and reconnect its uplinks to the spine
  5. Reconfigure Switch 2 as a leaf and power it on with ports enabled
    On the NetApp side we currently have an LACP ifgrp (e.g. a0a) across the two switches.
    My question:
    Will this process cause any client impact (NFS/SMB/iSCSI) or LIF disruption due to the LACP configuration?
    Since LACP expects the links to be in the same port-channel/MLAG pair, I’m wondering if taking down one switch and later breaking the pair could cause issues from the NetApp perspective.
    Has anyone done a similar migration or know how ONTAP behaves in this situation?
brave quest
#

so your final config (between the leaf switches) will not be LACP anymore? If not, then there will be a disruption as the link will not come online without a switch speaking LACP on the other side. In that case you would want to move to two single links in one broadcast domain and distribute the LIFs among those

#

to be 100% non-disruptive I would suggest to use temporary uplinks (1 port per node) to some other switch, move all LIFs (IP Addresses) over there, then reconfigure whatever you need on the switch and ifgrp side of things, then move the LIFs back and dismantle the temporary uplinks

fathom cove
#

Alternatively, you could move your lifs to one node, and have the network guys reconfigure an LACP group for the now "unused" ports to be on a single switch, then move all the lifs to the node with the new single-switch LACP config, and do the same with the opposite node. Then just "revert" everything back to normal.
Then when they take each switch down separately, your lifs will just migrate to the node that still has switch connectivity.
You will still have almost the same redundancy, but with a bit more load on the controller that has a switch available, should one switch fail in the future.

brave quest
#

yeah...or go all-in and migrate to a BGP config 😉

novel glade
#

I will try to send more later, but what should happen is that the two "LEAFS" can still form the vPC. I have many deployments with ACI. Or are they just going to DCNM? in which case, they could/should leave those "leafs" in a vPC

novel glade
#

If you must split, I would do something like this (assuming each node has 2 ports to each switch)

  1. remove two ports from each node (going to switch1) from ifgrps (ifgrp remove-port)
  2. Connect/configure switch1.
  3. Make new 2-port Port-Channel on switch1 for each netapp
  4. Configure VLANs as needed
  5. Configure new ifgrp on each netapp (a0b, dist=port,mode=lacp) and add ports
  6. verify it works.
  7. wait a few minutes. Verify correct Broadcast-domain behavior
  8. If #7 is working, then migrate/re-home all lifs on a0a* to a0b*
  9. shutdown/delete ifgrp a0a
  10. do your thing(s) with switch 2
  11. recreate a0a with two ports .
  12. basically do 3-8 above for a0a
  13. Modify some lifs to reside on a0a and others to reside on a0b

What if you have a single link to each switch?
then skip all the ifgp stuff.

  1. remove one port from each node (going to switch1) from ifgrps on each node (ifgrp remove-port)
  2. Connect/configure switch1.
  3. Configure VLANs as needed
  4. verify it works.
  5. wait a few minutes. Verify correct Broadcast-domain behavior
  6. If #5 is working, then migrate/re-home all lifs on a0a* to eXy (eSLOTXportY)
  7. shutdown/delete ifgrp a0a
  8. do your thing(s) with switch 2
  9. basically do 3-5 above for eXz (eSLOTXportZ)
  10. Modify. some lifs to reside on eSLOTXportY and others to reside on eSLOTXportZ
arctic rain
#

How about below plan:

Current Connectivity
Switch1
node1:e1b
node2:e1b
Switch2
node1:e7b
node2:e7b
Port mapping:
node1:e1b → switch1
node1:e7b → switch2
node2:e1b → switch1
node2:e7b → switch2
All interfaces are currently members of ifgrp a0a (LACP).

Phase 1 – Switch1 Reconfiguration

  1. Fail over LIFs from node2 to node1, making node1 the active node.
  2. Remove the Switch1 facing ports from the LACP interface:
    remove node1:e1b from ifgrp a0a
    remove node2:e1b from ifgrp a0a
    Connectivity will continue through switch2.
  3. Network team completes Switch1 reconfiguration.
  4. Reintroduce node2 connectivity via Switch1:
    add node2:e1b to ifgrp a0a
    remove node2:e7b from ifgrp a0a
  5. Test connectivity.
  6. If everything is stable, fail over all LIFs from node1 to node2 so node2 becomes the active node.
  7. Test connectivity.

Phase 2 – Switch2 Reconfiguration

  1. Remove Switch2 facing ports from the LACP interface:
    remove node1:e7b from ifgrp a0a
    remove node2:e7b from ifgrp a0a
  2. Network team completes Switch2 reconfiguration.
  3. Begin restoring LACP membership:
    add node1:e7b to ifgrp a0a
  4. Test connectivity.
  5. Restore full LACP configuration:
    add node1:e1b back to ifgrp a0a
    add node2:e7b back to ifgrp a0a
  6. Verify that LACP returns to full status.

Final Step:
Fail back all LIFs to their home nodes and verify normal operation.

novel glade
#

you have not mentioned what kind of switches and if they will be able to continue to do LACP after the migration. The first post did not seem confident that LACP will be available post migration.