On Wed, 20 Apr 2011 00:36:26 +0200 Santiago Garcia Mantinan <ma...@manty.net> wrote:
> 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? 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?) -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
