Thank ghu we aren't homenet! Wires are dead! :) I will incorporate your comments later today. Until then, there's pictures and data now up at:
http://blog.cerowrt.org/post/failing_over_faster/ I am quite puzzled as to how long it takes to fail over even in the good cases. I guess I gotta take some packet captures. On Mon, Apr 25, 2016 at 11:47 AM, Juliusz Chroboczek <[email protected]> wrote: >> 8+ years ago, with ahcp and babel, and a network configured to use >> that with a single static ip address on both the ethernet and wifi, I >> could do that. My own networks were setup that way, anyway... I did it >> all the time. It was wonderful. I never had to think about it. > > Dave, the plan is to do exactly that with shncpd and babeld -- think of > shncpd as ahcpdv2. Please try running babeld and shncpd (-M) on the host, > and if it doesn't work as well as ahcpd, we'll fix it. > >> It was massively disconcerting to attempt to move back into the >> "regular" world where wifi and ethernet were treated as distinct, >> where taking an interface offline lost its address, > > Right. One difference between ahcpd and shncpd -M is that the former uses > a single address, while the latter uses one address per interface. The > workaround is to keep the interface up, even if it is unconnected. > Since -M is out of spec anyway, I can be convinced to change that. > >> where taking a new /64 was considered mandatory, > > That's what -M is for. > >> and no host changes allowed, > > We're not Homenet, Dave, we're independent researchers. Just because > Homenet rejects something doesn't mean we shouldn't do the right thing. > My personal opinion is that having reasonable support for unchanged hosts > is a goodness, but we shouldn't shy from designing better hosts. > >> I've harped on a need for atomic updates, but I still think that >> a userspace routing daemon simply can't react fast enough to a change in >> an ethernet routing table to prevent no-route messages being sent to one >> or more flows on a busy link when it goes down. > > Higher-layer protocols should be able to survive ICMP unreachable by > retrying after a few jiffies. TCP certainly does, and if your protocol > doesn't, it's a bug in the protocol. > >> A newer problem that I haven't thunk much about before was that babel >> aims for a stable route, so if I have 3 routes - one stable, but >> lousy, and both the better routes flap twice in under 60 seconds or >> so, we end up choosing the stablest route, sometimes for a very long >> time. > > Yes, over the years babeld has been tuned to prefer stable routes. Have > you tried playing with -M? I'm quite open to changing its default value. > > -- Juliusz -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
