Hi!
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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
