[j-nsp] Spanning Tree Inconsistent State

[Ben Dale]

Hi Crist,

It is certainly possible to have blocked ports on a root bridge - consider a case where the switch is patched to itself.

Having a root port is a little unusual though?!!.  

Restarting RSTP is going to cause a topology change or two amongst your neighbours so try to do it during low traffic.

It might be worth using LLDP to trace out physical connections too just to make sure there isn't a cabling issue.

Ben

On 03/10/2013, at 9:50 AM, Crist Clark <cjc+j-nsp at pumpky.net> wrote:

> I am a little confused about the spanning tree state on an EX4200 VC,
> running 11.4R5.5.
> 
> 
> 
> {master:0}
> cjc at dmz4200> show spanning-tree bridge
> 
> STP bridge parameters
> Context ID                          : 0
> Enabled protocol                    : RSTP
> Root ID                           : 32768.88:e0:f3:77:53:81
> Hello time                        : 2 seconds
> Maximum age                       : 20 seconds
> Forward delay                     : 15 seconds
> Message age                       : 0
> Number of topology changes        : 20
> Time since last topology change   : 3661899 seconds
> Topology change initiator         : xe-0/1/0.0
> Topology change last recvd. from  : 88:e0:f3:74:51:6a
> Local parameters
>   Bridge ID                       : 32768.88:e0:f3:77:53:81
>   Extended system ID              : 0
>   Internal instance ID            : 0
> 
> {master:0}
> cjc at dmz4200> show spanning-tree interface
> 
> Spanning tree interface parameters for instance 0
> 
> Interface    Port ID    Designated      Designated         Port    State  Role
>                        port ID        bridge ID          Cost
> ge-0/0/0.0     128:513      128:513  32768.88e0f3775381     20000  FWD    DESG
> ge-0/0/47.0    128:560      128:560  32768.88e0f3775381     20000  FWD    DESG
> xe-0/1/0.0     128:609      128:609  32768.88e0f3775381      2000  FWD    ROOT
> xe-0/1/2.0     128:611      128:611  32768.88e0f3775381      2000  FWD    DESG
> ge-1/0/0.0     128:625      128:625  32768.88e0f3775381     20000  FWD    DESG
> ge-1/0/47.0    128:672      128:672  32768.88e0f3775381     20000  FWD    DESG
> xe-1/1/0.0     128:721      128:776  32768.50c58dac4c81      2000  BLK    ALT
> xe-1/1/2.0     128:723      128:723  32768.88e0f3775381      2000  FWD    DESG
> 
> 
> So what I'm confused about is that the "show spanning-tree bridge" output
> says that this switch is the root bridge, yet the per-interface output
> indicates that there are ROOT and ALT ports. Also, the bridge ID for the
> ROOT port is the switch itself? Whereas the ALT port is what I would
> expect, except that it again seems to contradict the idea that this switch
> is the root bridge.
> 
> 
> 
> I think my RSTP on this switch is in some messed up state? When I turn on
> traceoptions for rstp, I see sucpicious stuff like,
> 
> 
> Oct  2 11:26:59.532378 PISM: Port xe-1/1/0.0: IMPOSSIBLE EVENT/STATE
> Combination Occured
> Oct  2 11:26:59.532396 PISM: Event routine returned FAILURE
> Oct  2 11:26:59.532414 MSG: RstPortInfoMachine function returned FAILURE!
> 
> Oct  2 11:26:59.532441 RECV: PortReceiveStateMachine Action returned
> FAILURE!
> 
> Oct  2 11:26:59.532467 MSG: RstPortReceiveMachine function returned FAILURE!
> 
> Oct  2 11:26:59.532493 MSG: RstHandleInBpdu function FAILED!
> 
> Is there a low risk way to reset RSTP on a production switch?
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>