[j-nsp] Spanning Tree Inconsistent State

[Peter Tavenier]

Seems to be something strange indeed. On the root switch all the interfaces should be in DESG state. 
Maybe shutting down port xe-1/1/0.0 helps this weird state, that is the port which is in a "IMPOSSIBLE EVENT/STATE"
You could also try to restart the eswd process (Ethernet switching daemon), that's where spanning tree processing happens, but that is definitely impacting. 

Best regards,
Peter Tavenier

> Op 3 okt. 2013 om 01:50 heeft Crist Clark <cjc+j-nsp at pumpky.net> het volgende geschreven:
> 
> 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