Header Only - DO NOT REMOVE - Extreme Networks

Log where spanning tree TCN's are coming from.


Userlevel 5
Currently in the process of correcting a spanning tree mis-configuration, predominantly caused by ports not correctly configured as edge ports.

Currently seeing a lot of spanning tree TCN's on the core, but need to workout whereabouts, or what port are they coming in from.

Currently have the following added to the defaultfilter

configure log filter DefaultFilter add events STP.SendClntTopoChgMsg[/code]

Which is producing the following log entries multiple times:

11/12/2015 15:48:00.06 Send topology change notification type 2 for STPD STP_Data[/code]

Have tried enabled various other logs like stp dump and trace logs, but nothing is telling where they are coming from.

Aside from a packet capture, is there anyway to do this?

Many thanks in advance.

2 replies

Userlevel 5
and the answer is:

configure log filter DefaultFilter add events STP.State.Topology

[/code]

So with both commands deployed:

configure log filter DefaultFilter add events STP.SendClntTopoChgMsg
configure log filter DefaultFilter add events STP.State.Topology[/code]

You now get a log something like the below, which shows the TCN and what port (46) that it was detected on.

11/13/2015 09:19:37.19 Send topology change notification type 2 for STPD STP_PS_Data
11/13/2015 09:19:37.19 [STP_Data:11] FDB Flushed due to topology Change
11/13/2015 09:19:37.14 [STP_Data:11] Topology Change propagating
11/13/2015 09:19:37.14 [STP_Data:7] FDB Flushed due to topology Change
11/13/2015 09:19:37.14 [STP_Data:7] Topology Change propagating
11/13/2015 09:19:37.14 [STP_Data:6] FDB Flushed due to topology Change
11/13/2015 09:19:37.14 [STP_Data:6] Topology Change propagating
11/13/2015 09:19:33.18 [STP_Data:46] Topology Change Detected (TC)[/code]

All I then needed to do was do the same on the switch that link goes too. This is properly a lot easier to find as you can marry the TCN on that switch with a port going up and down, which you couldn't do on the core.
Userlevel 7
Martin Flammia wrote:

and the answer is:

configure log filter DefaultFilter add events STP.State.Topology

[/code]

So with both commands deployed:

configure log filter DefaultFilter add events STP.SendClntTopoChgMsg
configure log filter DefaultFilter add events STP.State.Topology[/code]

You now get a log something like the below, which shows the TCN and what port (46) that it was detected on.

11/13/2015 09:19:37.19 Send topology change notification type 2 for STPD STP_PS_Data
11/13/2015 09:19:37.19 [STP_Data:11] FDB Flushed due to topology Change
11/13/2015 09:19:37.14 [STP_Data:11] Topology Change propagating
11/13/2015 09:19:37.14 [STP_Data:7] FDB Flushed due to topology Change
11/13/2015 09:19:37.14 [STP_Data:7] Topology Change propagating
11/13/2015 09:19:37.14 [STP_Data:6] FDB Flushed due to topology Change
11/13/2015 09:19:37.14 [STP_Data:6] Topology Change propagating
11/13/2015 09:19:33.18 [STP_Data:46] Topology Change Detected (TC)[/code]

All I then needed to do was do the same on the switch that link goes too. This is properly a lot easier to find as you can marry the TCN on that switch with a port going up and down, which you couldn't do on the core.

Looks like you beat the community to a response 🙂
Thanks for coming back with the answer.

Reply