On Wednesday 14 December 2011 02:16:13 Stephen Hemminger wrote: > On Tue, 13 Dec 2011 11:36:25 +0200 > > Vitalii Demianets <vitas@xxxxxxxxxxxxxxxxx> wrote: > > If there is a slave in blocking state when stp is turned off, that slave > > will remain in blocking state for indefinitely long time until interface > > state changed. We should push all blocking slaves into forwarding state > > after turning stp off. > > > > Signed-off-by: Vitalii Demianets <vitas@xxxxxxxxxxxxxxxxx> > > Maybe. But if the port was in the blocking state then STP must have > decided there was a loop in the network if that port was used. > Therefore blindly putting the port into forwarding state could cause > disastrous network flood. > > > The user can force the port back out of blocking state (via sysfs). > 1) That blocking state in the absence of STP is not stable. It will eventually flip to forwarding sooner or later on the first call of br_port_state_selection(). For example, when user changes MAC address on another slave. Or even worse - when any other slave of the bridge changes its carrier state. Don't think user wants such unpredictable state changes. 2) There is also another drawback of not pushing ports into forwarding state after turning off USER_STP mode. Possible scenario is: a) bridge in USER_STP mode, all ports are in non-forwarding state (blocking, learning) b) user turns off STP. Without the patch ports are not advanced to the forwarding state and are left in the states they are (the timers do not work because of USER_STP mode) c) The bridge stays in no-carrier state until something happens (carrier state transition on one of the slaves, MAC address change etc) You can say again that in the above two cases user can manually set the state of the slaves to forwarding. But to account all possible cases one should always unconditionally do it for all the slaves each time when stp is being turned off. So why not to automate the task? 3) The initial intention of the code in br_stp_stop() was to get ports out of blocking state when stp is being turned off. It fails to achieve the goal, and patch just fixes it. 4) If user turns stp off he clearly indicates that she wants all ports to work in stateless mode and that he will deal with possible network loops on himself. Should we in that case guess network topology basing on loose assumptions and leave ports in unstable blocking state (and they will flip eventually to the forwarding state in unpredictable times as mentioned above)? -- Vitalii Demianets _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/bridge
