Enforce UDLD on switch-switch trunk links

[Navidg]

Hi Legend

We have identified slow Spanning Tree Protocol (STP) convergence within our network infrastructure, and I believe that changing the UDLD (Unidirectional Link Detection) setting from Alert only to Enforce on our Meraki switch-switch trunk links may help address this issue.

Any ideas?

Thanks

[alemabrahao]

I suggest you to open a support case.

[GIdenJoe]

If you have not seen any UDLD messages saying you have unidirectional links you should have no problems in that regard.  Changing to enforce will only shut those links down if they are unidirectional.

Slow STP convergence in RSTP can only happen in a count to infinity problem and that can only happen in a ring topology which I hope you are not running.

[Navidg]

Hi Jo

Thanks for your help,

Thank you for your help;
We have only Meraki switches.
Currently, our network follows a star topology, where the Meraki switches operate at Layer 2, and we have a Palo Alto device at the edge. We have redundant locations (A and B) with separate internet connections and Palo Alto devices installed. All other cabinets across the organization have direct links to both A and B locations. The purpose of this setup is to ensure network continuity in case of any issues at one location, where traffic will be redirected to the other location.

Slow STP Convergence Scenario (UDLD alerts): My concern regarding slow STP convergence arises in scenarios such as a power outage in building A, where the network system attempts to connect to building B.

[GIdenJoe]

Then how is your core switching setup?
Normally these days if you have two separate locations where all your access switches are connecting to then you would have a long distance stack in place (if you are running purely Meraki, then that would be MS425 series of switches).  All access switches have active active links to both core switches and the Palo Alto firewalls should be connected to an access layer stack at each location.

Then if an entire location would fail the secondary Palo would take over sending gratuitous ARP to say it is now serving as gateway to the internet.  Since all your access switches are dual uplinked using multichassis port-channels (aggregations) you would not have any outage on the switching side.

If you however deviated from this design we would like to know.  Preferably with a quick visio drawing using hierarchical logical drawing, not subway map type links.

UDLD however is limited to a single link and is actually meant to be used on fiber links only because you usually have multiple physical fiber strands in most fiber links where one part goes upstream and the other downstream.  UDLD is meant to shut down your link (enforce mode) if it detects one of the directions is not working.  Since if it wouldn't do that you could have a unidirectional loop if STP messages no longer reach the other switch and opening an alternative path completing the loop.

So the fiber links running between your switches must have UDLD enforce on if you want to avoid this unidirectional loop.

[PhilipDAth]

Are you using more vendors than just Meraki switches?

If you are using Cisco Enterprise switches, configure them to use mst.

spanning-tree mode mst

If other vendors use single instance RSTP, use that.  If they create a spanning tree instance per VLAN (like Cisco Enterprise) configure them for MST instead.

Ports between switches should be configured as trunk ports.  Ports to end devices should be configured as access ports.

A convergence time issue is 99% likely to be due to the configuration, rather than a cable fault, in particular a uni-directional cable fault.

Chances are if you follow the above you will get rid of your convergence time issue.

[Navidg]

Hi there

Thank you for your help;
We have only Meraki switches.
Currently, our network follows a star topology, where the Meraki switches operate at Layer 2, and we have a Palo Alto device at the edge. We have redundant locations (A and B) with separate internet connections and Palo Alto devices installed. All other cabinets across the organization have direct links to both A and B locations. The purpose of this setup is to ensure network continuity in case of any issues at one location, where traffic will be redirected to the other location.

Slow STP Convergence Scenario (UDLD alerts): My concern regarding slow STP convergence arises in scenarios such as a power outage in building A, where the network system attempts to connect to building B.

[Navidg]

Thanks for the replay;

1. Each switch cabinet within our network has a direct link (Fiber) to Location A. However, the connectivity to Location B varies as follows:

a. Direct Connectivity: Some switch cabinets are directly connected to cabinets in Location B, establishing a direct link between these cabinets.

• b. Indirect Connectivity: Other switch cabinets in our network do not have a direct connection to cabinets in Location B. Instead, they can access Location B through a chain of interconnected switch cabinets within the organization

   

[Navidg]

Last time, the failover went well but failback took about 15 minutes.