My machine is into a ring loop with other two switches running RSTP. My switch is NOT the root bridge.
Log:
1038911701.406963: bridge_bpdu_rcv: ifindex 6, len 60
1038911701.411766: MSTP_IN_rx_bpdu: br0:mrvl4 received RST BPDU
1038911701.446256: PISM_to_RECEIVE: br0:mrvl4:0
1038911701.451015: PISM_to_SUPERIOR_DESIGNATED: br0:mrvl4:0
1038911701.455493: PISM_to_CURRENT: br0:mrvl4:0
1038911702.021584: PISM_to_UPDATE: br0:mrvl4:0
1038911702.026330: PISM_to_CURRENT: br0:mrvl4:0
1038911702.204368: PISM_to_UPDATE: br0:mrvl4:0
1038911702.209114: PISM_to_CURRENT: br0:mrvl4:0
1038911703.199645: MSTP_OUT_tx_bpdu: br0:mrvl4 sending RST BPDU
1038911703.224464: MSTP_OUT_set_state: br0:mrvl4:0 entering learning state
1038911703.232292: set_port_role: port mrvl4 role 3
1038911703.245552: bridge_bpdu_rcv: ifindex 6, len 60
1038911703.250359: MSTP_IN_rx_bpdu: br0:mrvl4 received RST BPDU
1038911703.284849: PISM_to_RECEIVE: br0:mrvl4:0
1038911703.289604: PISM_to_NOT_DESIGNATED: br0:mrvl4:0
1038911703.294079: PISM_to_CURRENT: br0:mrvl4:0
1038911703.313165: MSTP_OUT_set_state: br0:mrvl4:0 entering forwarding state
When I open the loop between the two other switches my switch receives a BPDU at
1038911701.406963 as reported into logs but the MSTPd daemons needs
more that 1s to answer with itsown BPDU!
The problem is that the state machine goes to
PISM_to_SUPERIOR_DESIGNATED and then nothing happens till
bridge_one_second() function is called due internal timeout.
Note: my switch never becomes the root bridge after loop opening.
Thanks in advance,
Rodolfo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For the information to anyone interested:
SVN revision 37 contains patch which solves the issue. Now state machines are running in loops until all states stabilized. Previously only one run of state machines was done in response to each event, which in some cases meant that we needed several one-second events to push additional runs until all transitions completed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I posted this issue on the bridging MailList but got no answers so I
try to repost it here! :) You can find my old posts here:
http://lists.linuxfoundation.org/pipermail/bridge/2012-October/008014.html
My machine is into a ring loop with other two switches running RSTP. My switch is NOT the root bridge.
Log:
1038911701.406963: bridge_bpdu_rcv: ifindex 6, len 60
1038911701.411766: MSTP_IN_rx_bpdu: br0:mrvl4 received RST BPDU
1038911701.446256: PISM_to_RECEIVE: br0:mrvl4:0
1038911701.451015: PISM_to_SUPERIOR_DESIGNATED: br0:mrvl4:0
1038911701.455493: PISM_to_CURRENT: br0:mrvl4:0
1038911702.021584: PISM_to_UPDATE: br0:mrvl4:0
1038911702.026330: PISM_to_CURRENT: br0:mrvl4:0
1038911702.204368: PISM_to_UPDATE: br0:mrvl4:0
1038911702.209114: PISM_to_CURRENT: br0:mrvl4:0
1038911703.199645: MSTP_OUT_tx_bpdu: br0:mrvl4 sending RST BPDU
1038911703.224464: MSTP_OUT_set_state: br0:mrvl4:0 entering learning state
1038911703.232292: set_port_role: port mrvl4 role 3
1038911703.245552: bridge_bpdu_rcv: ifindex 6, len 60
1038911703.250359: MSTP_IN_rx_bpdu: br0:mrvl4 received RST BPDU
1038911703.284849: PISM_to_RECEIVE: br0:mrvl4:0
1038911703.289604: PISM_to_NOT_DESIGNATED: br0:mrvl4:0
1038911703.294079: PISM_to_CURRENT: br0:mrvl4:0
1038911703.313165: MSTP_OUT_set_state: br0:mrvl4:0 entering forwarding state
When I open the loop between the two other switches my switch receives a BPDU at
1038911701.406963 as reported into logs but the MSTPd daemons needs
more that 1s to answer with itsown BPDU!
The problem is that the state machine goes to
PISM_to_SUPERIOR_DESIGNATED and then nothing happens till
bridge_one_second() function is called due internal timeout.
Note: my switch never becomes the root bridge after loop opening.
Thanks in advance,
Rodolfo
Hello, Rodolfo!
Sorry for the delay, the crappy SourceForge e-mail notification got a hiccup again and I haven't got notification about your forum post :(
BTW, I did answer to the bridge mailing list:
http://lists.linuxfoundation.org/pipermail/bridge/2012-October/008015.html
Anyway, first of all please update mstpd to the SVN revision 36 and see if the problem persists. In revision 36 a critical bug was fixed.
Looking forward to hearing about results of testing!
Vitalii
For the information to anyone interested:
SVN revision 37 contains patch which solves the issue. Now state machines are running in loops until all states stabilized. Previously only one run of state machines was done in response to each event, which in some cases meant that we needed several one-second events to push additional runs until all transitions completed.