S4 "show spantree stats active" behavior

[Tino]

We are stetting up two s4 cores with a 4 x 1Gb lag between the two cores. We are using single instance rstp for spanning tree. core 1 priority 4096 and core 2 priority 8192.

When the two cores come up, the lag negotiates and we observe the following on the "show spantree stats active command":
core-jen-1(su)->show spantree stats active
Spanning tree instance - 0
Designated Root MacAddr - 20-b3-99-57-d5-b2
Designated Root Priority - 4096
Designated Root Cost - 0
Designated Root Port - 0
Root Max Age - 20 sec
Root Hello Time - 2 sec
Root Forward Delay - 15 sec
Bridge ID MAC Address - 20-b3-99-57-d5-b2
Bridge ID Priority - 4096
Bridge Max Age - 20 sec
Bridge Hello Time - 2 sec
Bridge Forward Delay - 15 sec
Topology Change Count - 4
Time Since Top Change - 00 days 01:25:20
Max Hops - 20
SID Port State Role Cost Priority
--- ---------- ---------------- ----------- -------- --------
0 ge.2.47 Blocking Disabled 2000000 128
0 lag.0.10 Forwarding Designated 10 128

We are scratching our heads about the ge.2.47 that is showing as blocking and disabled.
The lag ports are ge.2.47, ge.2.48, tg.4.23 and tg.4.24
the lag looks good and is running at 4Gb
On the other core also shows ge.2.47 as Blocking. The port is actually up and dormant:core-jen-1(su)->show port status ge.2.47 Port Alias Oper Admin Speed Duplex Type (truncated) Status Status (bps) ------------ ---------------- -------- ------- ------ ------- ------------------ ge.2.47 lag.0.10 dormant up 1.0G full 1000-sx lc 1 of 1 ports displayed, 1 port(s) with oper status 'up' or 'dormant'.
I am assuming ge.2.47 was the first port to come up in the lag but the info on the output is confusing.

I have tried different firmware as well, at the moment we are running:

core-jen-1(su)->show version
Copyright (c) 2016 by Extreme Networks, Inc.
Slot Model Serial # Versions
------ ---------------- -------------------- -------------------------
2 SG8201-0848-F8 15051692595L Hw: 2
Bp: 01.03.03
Fw: 08.61.01.0018
4 SK8008-1224 14421346595L Hw: 1
Bp: 01.03.03
Fw: 08.61.01.0018
Could someone let me know how to clear the entry or is this expected ?

[Mike_D]

Hi Tino,

Think of the "show spantree stats active" command this way:

"Show spanning tree statistics for all ports that have seen bpdu activity since last boot".

Its not reporting state. Its reporting stats. But it sure as snot looks like state. I cant disagree there.

And I cant tell you why it's there - but it probably has every right to be there. (Which in no way qualifies as 'expected')

The design intent I'm sure was to provide supporting configuration info and what amounts to 'non-forwarding reason' to add context to historical data. History it the tricky part of this output.
That port info describes a physical link that no longer exists.
On the S-series switch, once a physical port joins a LAG it loses its 'port-ness' and inherits aggregation attributes. vlan association, CoS settings, path cost, mac address etc. All items from its former days as a physical port are now gone (with a very few exceptions) and in their place are attributes of the link aggregation group. That port has become 25% of a 4 Gb LAG.
But once there was a port. And stp activity. And your output is (for better or worse) the proof.

Unfortunately the data cant be cleared without resetting the switch.

On the other hand this gives me a chance to suggest my very favorite stp command - in case its not already in your tool-box.
"show spantree debug"
and the bonus
"clear spantree debug"

I hope the output starts to look a little less strange to your eyes.

For what its worth I'll ponder the 'blocking on both sides' story and make up a story of my own about what may happened to leave the link partners in that errr... position.
Which may lead nowhere. Then again - maybe this will all make sense by next week.

LAG is sticky. If 2.47 was part of another LAG between these two switches (different keys, lag id etc) there would be risk of the old lag again talking shape on ge.2.47 while the other ports join forces as the newly configured lag. and with 2 lags comes block or alternate or silliness.

maybe this port joined the LAG but due to a speed mismatch or maybe duplex problem - was unable to become a forwarding member of the LAG.
I think i remember dormant blocking can result from speed mismatch among lag members.
Sometimes spit-balling is just unproductive. I need to read up on lag.

Best,
Mike

[Daniel_Coughlin]

To add to what Christoph wrote.

It is a good Idea to leave spanning tree enabled on the physical ports of the lag to prevent loops should one of the port leave the lag for some reason. As long as the physical port stay dormant and the lag is forwarding you should be fine.

[Christoph]

it's a normal behaviour that ports are active in a LAG are in STP blocking state. Your virtual port, the LAG is in forwarding state, so every thing works fine.