|
Check the logs below to identify STP flaps in the network. STP flaps can impact users heavily, resulting in dropped pings and higher latency for clients.
- Validate the inter-switch physical links and make sure the ports are not going down-up frequently. Check the event logs on the FortiGate GUI -> Log & Report -> System Events -> FortiSwitch Events.
- Know the network topology well. Once understood, identify the participating ports for STP. Check the topology view in the FortiGate GUI -> Wifi & Switch Controller -> Managed FortiSwitches.
- Core FortiSwitches i.e. directly connected to FortiGate should act as a root bridge and all other FortiSwitches should see the core FortiSwitch as a root bridge. Check the command 'diag stp instance list' on the Core FortiSwitches. Start the troubleshooting from the core FortiSwitch.
For example, in the following output, the core Fortiswitch is acting as a root bridge but TCN events received and triggered are not stable. It shows the FortiSwitch received TCN 14 minutes previously, which signifies that some other Switch is broadcasting itself as the root bridge.
diagnose stp instance list
MST Instance Information, primary-Channel:
Instance ID 0 (CST)
Config Priority 20480
Bridge MAC 84398fxxxxxx, MD5 Digest 9999b43d77cxxxxxxxxxx1c4a487
Root MAC 84398fxxxxxx, Priority 20480, Path Cost 0, Remaining Hops 20
(This bridge is the root)
Regional Root MAC 84398fxxxxxx, Priority 20480, Path Cost 0
(This bridge is the regional root)
Active Times Forward Time 15, Max Age 20, Remaining Hops 20
TCN Events Triggered 2453 (0d 0h 14m 9s ago), Received 1717 (0d 0h 14m 7s ago)
-
Check logs on the core FortiSwitch(es) and access FortiSwitch(es). If there is an STP flap, an ISL FortiLink trunk interface should be seen changing the STP role between root and designated. Refer to the following example from an access FortiSwitch:
The following output will list the trunks:
show switch trunk
The following output lists only STP logs:
execute log filter view-lines 1000
execute log filter field subtype spanning_tree
execute log display
1: 20zz-0y-0X 14:11:15 log_id=0105008255 type=event subtype=spanning_tree pri=notice vd=root user="stp_daemon" action="role-change" unit="primary" switch.physical-port="_FlInK1_MLAG0_" instanceid="15" event="role migration" oldrole="designated" newrole="root" status="None" msg="primary port _FlInK1_MLAG0_ instance 15 changed role from designated to root"
5: 20zz-0y-0X 14:11:09 log_id=0105008255 type=event subtype=spanning_tree pri=notice vd=root user="stp_daemon" action="role-change" unit="primary" switch.physical-port="_FlInK1_MLAG0_" instanceid="15" event="role migration" oldrole="root" newrole="designated" status="None" msg="primary port _FlInK1_MLAG0_ instance 15 changed role from root to designated"
execute log filter reset
-
Check the below output on Core FSW(s) to understand at what ports STP packets are received. Based on point 1, it is possible to know what ports should participate in STP. If any other ports with STP packets are seen, it is recommended to investigate why STP packets are seen on that port.
diagnose switch pdu-counters list
primary CPU counters:
packet receive error : 0
Non-zero port counters:
port1:
LACP packet : 67347
STP packet : 575010
LLDP packet : 728848
port2:
LACP packet : 67392
STP packet : 4066
LLDP packet : 738388
Clear pdu-counters and then monitor as well.
diagnose switch pdu-counters clear
-
Once the port has been identified where STP packets should not be seen, check the LLDP neighbor and find out what is connected to that port. Depending on the network, some of the following further steps can be taken:
- Disconnect the port.
- Disable STP.
- Make sure both sides run the correct STP settings.
- Make sure the same STP protocol (FortiSwitch runs MSTP by default) is used on both sides or that both sides are compatible. For an example, see the FortiLink guide.
LLDP command: The following example shows a third-party switch connected to port46 that could be causing the issue.
get switch lldp neighbors-summary
port46 Up Nexus 120 BR - Ethernet1/40
-
If the issue persists, raise a TAC ticket for further debugging. Attach the outputs of the following to the ticket:
- Topology view in FortiGate GUI -> Wifi & Switch Controller -> Managed FortiSwitches.
- FortiGate config.
- Output from the FortiGate CLI command 'exec switch-controller get-conn-status'.
- Outputs from the following commands on the Core FortiSwitch(es) 'diag debug report' and 'show full-config'.
|
