S4 "show spantree stats active" behavior

  • 0
  • 1
  • Question
  • Updated 2 years ago
  • Answered
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 ?
Photo of Tino

Tino

  • 656 Points 500 badge 2x thumb

Posted 2 years ago

  • 0
  • 1
Photo of Christoph

Christoph

  • 1,862 Points 1k badge 2x thumb
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.
Photo of Daniel Coughlin

Daniel Coughlin, Employee

  • 2,772 Points 2k badge 2x thumb
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.
Photo of Mike D

Mike D, Alum

  • 3,852 Points 3k badge 2x thumb
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