Technical Tip: STP Behavior Observation Post Root Bridge Reboot FortiSwitch
| Description | This article describes that one time, the STP root port flap was seen on a non-root bridge FortiSwitch after the STP root Bridge FortiSwitch rebooted. |
| Scope | FortiSwitch 1xx series, v7.4.x. |
| Solution | Consider the setup below:
Once the ROOT BRIDGE FortiSwitch1 is rebooted and it comes online, there will be a STP convergence, and the NON-ROOT BRIDGE FortiSwitch2 port1 becomes the ROOT port, which is expected. After 3 minutes and 15 seconds, the port1 on NON-ROOT BRIDGE FortiSwitch2 changes STP role from ROOT to designated and then back to ROOT, without any Topology Change Notification.
Verify the logs on FortiSwitch2:
2025-03-10 07:29:09 log_id=0105008255 tz=-0700 type=event subtype=spanning_tree pri=notice vd=root user="stp_daemon" action="role-change" unit="primary" switch.physical-port="port1" instanceid="0" event="role migration" oldrole="designated" newrole="root" status="None" msg="primary port port23 instance 0 changed role from designated to root"
After 3 minutes STP flap:
2025-03-10 07:32:13 log_id=0105008255 tz=-0700 type=event subtype=spanning_tree pri=notice vd=root user="stp_daemon" action="role-change" unit="primary" switch.physical-port="port1" instanceid="0" event="role migration" oldrole="root" newrole="designated" status="None" msg="primary port port1 instance 0 changed role from root to designated"
Again, changes to correct the role 'root' and topology remain stable.
2025-03-10 07:32:13 log_id=0105008255 tz=-0700 type=event subtype=spanning_tree pri=notice vd=root user="stp_daemon" action="role-change" unit="primary" switch.physical-port="port1" instanceid="0" event="role migration" oldrole="designated" newrole="root" status="None" msg="primary port port1 instance 0 changed role from designated to root" |
