Menu

Slow RSTP transaction

2012-10-30
2012-12-10
  • Rodolfo Giometti

    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

     
    • Vitalii Demianets

      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

       
  • Vitalii Demianets

    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.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.