1

While digging into logs (debug spanning-tree event has been enabled) in order to troubleshoot communication losses after topology changes. I was able to notice once I triggered a TC, one specific access switch (connecting devices that are actually suffering from communication loss) is outputting every 2 minutes (and for hours) the following lines:

029156: Apr 17 2020 09:29:18: STP sync:  Send ALL port data to all other switches... 
029157: Apr 17 2020 09:29:18: STP sync:  NULL sync_data -- nothing to send 
029235: Apr 17 2020 09:31:18: STP sync:  Send ALL port data to all other switches... 
029236: Apr 17 2020 09:31:18: STP sync:  NULL sync_data -- nothing to send 
029273: Apr 17 2020 09:33:18: STP sync:  Send ALL port data to all other switches... 
029274: Apr 17 2020 09:33:18: STP sync:  NULL sync_data -- nothing to send

...
and so on for hours

No other logs about RSTP are showing up (port changing states during sync process for example). This switch is having only one uplink (Point2Point) to its distri switch. Other ports are edges. The same level of log was triggered at the same time on the distri switches but no RSTP logs at all are showing in this distri switch. Since there is only one P2P on the access, I was expecting this Sync signals to be sent from the distri switch but it seems not.

Can you help me to understand what's going on here? This RSTP Sync received every 2 minutes is quite curious isn't it?

From Cisco forum, I found this topic https://community.cisco.com/t5/switching/stp-state-sync-events-multicast-flooding/td-p/1708358 where they eventually think about a 802.1W bug... how can I confirm this?

Note: both switches are running IOS 15.2(4)E6

Improve this question
3
  • Have you made sure that all STP ports are configured correctly? This looks a bit like BPDUs are expected but missing. I'd use debugging to make sure that BPDUs are actually received from all connected switches. – Zac67 Apr 19 '20 at 8:13
  • I think so. The glogal spanning tree conf includes spanning-tree portfast edge bpduguard default. The specific STP port (uplink to the distri) is having switchport mode trunk and spanning-tree link-type point-to-point. – mouch Apr 19 '20 at 9:07
  • About the debug, that is indeed the very next step to apply. Will go for it as soon as I'm back in the office. I was thinking about enabling debug spanning-tree switch state, debug spanning-tree switch rx decode and debug spanning-tree switch rx process on top of the already existing debug spanning-tree event. That should be sufficient to give more hints. – mouch Apr 19 '20 at 9:09
2

After running some tests these logs are actually generated by activating debug spanning-tree synchronization. I noticed they are actually sent whenever a switch did not received/triggered synchronization proposal (RSTP proposal/agrement handshake) during 2 minutes.

They can be considered as a RSTP synchronization "watchdog" if the proper debugging is on.

Improve this answer
1
  • Always turn off debugging (undebug all) when done with troubleshooting. This can slow the network, and it drives of the device CPU usage. – Ron Maupin♦ Apr 28 '20 at 22:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.