On Apr 20, Santiago Garcia Mantinan <ma...@manty.net> wrote: > I'm getting ready the new version of the bridge-utils and so I'm thinking > again about this bug, the tests to me seem quite clear, either I disable > MAXWAIT for all the cases (no matter if stp is enabled or disabled) or I > keep MAXWAIT with reasonable times, and 0 doesn't seem a reasonable time. > > Disabling MAXWAIT by default doesn't make any sense to me, if the user wants > that he can set MAXWAIT to 0 and that's it.
> Why is this... I had installed openntpd and it was trying to do network work > before the bridge was forwarding (yes, the bridge won't forward inmediately > even if you have stp set to off, it has to wait at least the forwarding > time, by default it is 15 seconds if I recall well). It does with older kernels, but there is no reason to do it and this was recently removed (check the bridge mailing list). > Try to calculate MAXWAIT on the safe side, I still have to see why it Or you can look at /sys/class/net/$IFACE/bridge/forward_delay . > If the state info is available (current kernels do have this available) then > never wait for MAXTIME but only until one of the interfaces is forwarding. Looks like a good idea. > If somebody doesn't want to wait he has several options, one would be to > lower the forwarding times carefully (lowering them too much can cause > troubles) or disable waiting setting MAXWAIT to 0 on the bridge definition, > but knowing that network won't be available until a later time, which means > that dhcp won't probably work, mounting network filesystems at boot time > won't either, ... All these things need to cope with a non-working network anyway: even if the system does not use a bridge and partecipates in the STP, the switch port on the other side may probably does and will not forward frames immediately after the port goes up. -- ciao, Marco
signature.asc
Description: Digital signature
