Bug#549696: Bridge maxwait
Santiago Garcia Mantinan
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.
Setting different timings from the ones that I was using makes sense,
current kernels allow us to see bridge parameters even though stp is
disabled, so we can make better calculations and divide by two the times for
the non stp case, and even on this case one can see if the interfaces are
forwarding or not, so we can wait until maxwait or at least one interface is
forwarding.
Why this all makes sense... well, see the tests...
With a definition like this:
iface br0 inet static
...
bridge_ports eth1
bridge_stp off
bridge_maxwait 0
We do:
dis:~# time ifup br0
real 0m27.238s
user 0m0.060s
sys 0m0.148s
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).
After disabling openntpd's ifup scripts ifup would exis inmediatly but we
can see that the bridge still takes some time to forward...
dis:~# ifup br0;ping 192.168.1.90
PING 192.168.1.90 (192.168.1.90) 56(84) bytes of data.
From 192.168.1.180 icmp_seq=9 Destination Host Unreachable
From 192.168.1.180 icmp_seq=15 Destination Host Unreachable
From 192.168.1.180 icmp_seq=18 Destination Host Unreachable
64 bytes from 192.168.1.90: icmp_req=21 ttl=64 time=0.285 ms
If we look at the interface on the bridge to see what it is doing while I'm
pinging 192.168.1.90:
dis:~# ifup br0;tcpdump -n -i eth1
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
21:42:11.424263 IP 0.0.0.0 > 224.0.0.1: igmp query v2
21:42:11.424283 IP6 fe80::213:8fff:fea7:afb4 > ff02::1: HBH ICMP6, multicast listener querymax resp delay: 1000 addr: ::, length 24
21:42:17.556261 IP 0.0.0.0 > 224.0.0.1: igmp query v2
21:42:17.556283 IP6 fe80::213:8fff:fea7:afb4 > ff02::1: HBH ICMP6, multicast listener querymax resp delay: 1000 addr: ::, length 24
21:42:32.680263 ARP, Request who-has 192.168.1.90 tell 192.168.1.180, length 28
21:42:32.680624 ARP, Reply 192.168.1.90 is-at 00:05:5d:79:5b:56, length 46
21:42:32.680641 IP 192.168.1.180 > 192.168.1.90: ICMP echo request, id 5479, seq 22, length 64
21:42:32.680919 IP 192.168.1.90 > 192.168.1.180: ICMP echo reply, id 5479, seq 22, length 64
As you can see, the ARP of the ping is forwarded after 21 seconds.
So, my proposal would be:
Try to calculate MAXWAIT on the safe side, I still have to see why it
sometimes takes a little longer than expected, I'm seeing 2 seconds the
interface is disabled, then in the case of nostp it starts listening for the
defined forwarding time, and then goes forwarding, that would mean 17
seconds not 21, so I'll have to investigate a little more on this.
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.
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, ...
That do you think about this?
Regards...
--
Manty/BestiaTester -> http://manty.net
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stephen Hemminger
Latest kernel (2.6.39) ignores forwarding delay unless Spanning Tree
is enabled. Long term plan is to use RSTP so forwarding delay
will disappear (2.6.42?)
--
Marco d'Itri
> 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
Santiago Garcia Mantinan
This explains why on Debian's latest unstable kernel (2.6.38 based) I
still had the forwarding delays, anyway, the implementation I'm
looking for will look at the forwarding time that is set and calculate
the wait based on that, and anyway that is only the maxwait, if any of
the ports goes forwarding it will stop waiting.
> is enabled. Long term plan is to use RSTP so forwarding delay
> will disappear (2.6.42?)
Talking of wich... I long ago (April 2008) replied to your request of
the inclusion of the rstp daemon on Debian to give it more exposure
but seems that your answer never came back to me, I even contacted you
later on May without a reply as well. As I told you then I'm open to
either sponsor your package or package it myself if this is still
needed. I haven't looked at this lately do we have something official
that can be tested/packaged/whatever?
Regards...
--
Manty/BestiaTester -> http://manty.net
--
Stephen Hemminger
Santiago Garcia Mantinan <ma...@manty.net> wrote:
> > Latest kernel (2.6.39) ignores forwarding delay unless Spanning Tree
>
> This explains why on Debian's latest unstable kernel (2.6.38 based) I
> still had the forwarding delays, anyway, the implementation I'm
> looking for will look at the forwarding time that is set and calculate
> the wait based on that, and anyway that is only the maxwait, if any of
> the ports goes forwarding it will stop waiting.
>
> > is enabled. Long term plan is to use RSTP so forwarding delay
> > will disappear (2.6.42?)
>
> Talking of wich... I long ago (April 2008) replied to your request of
> the inclusion of the rstp daemon on Debian to give it more exposure
> but seems that your answer never came back to me, I even contacted you
> later on May without a reply as well. As I told you then I'm open to
> either sponsor your package or package it myself if this is still
> needed. I haven't looked at this lately do we have something official
> that can be tested/packaged/whatever?
>
> Regards...
There is a Fedora package.
--