On Fri, Jun 27, 2014 at 11:39 AM, Juliusz Chroboczek <[email protected]> wrote: >> the two captures are at: http://snapon.lab.bufferbloat.net/~cero2/babcap/ > > There's nothing obviously wrong. Here's an example of a source-specific > TLV (the one at time 06:20.362230 in the wifi capture):
So this does imply some sort of memory corruption issue on parsing that "martian" packet? > 0d 16 02 20 00 00 06 40 65 8a 00 e0 40 00 20 01 04 70 82 36 02 61 02 00 > > Type = 0d (13) > Length = 16 (32) > AE = 02 > Flags = 20 > Plen = 00 > Omitted = 00 > Interval = 0640 (16s) > Seqno = 658a > Metric = 00e0 (224) > Prefix = (empty) (::) > Src Plen = 40 (64) > src Omitted = 00 > src Prefix = 20 01 04 70 82 36 02 61 (2001:0470:8236:0261:0261::) > Sub-TLV: 02 00 (diversity empty) > > Matthieu, do you have any ideas? > > Other than that, nice network (you're probably the only person in the > world who thinks /27 is a round number). I'm seeing some wildcard 32 is a round number! It stemmed from 3 observations: 1) 802.11s has an upper limit of 32 stations (as best as I recall) 2) wifi seems to in general also have a practical upper limit of 32 stations 3) cerowrt has 8 interfaces, and dedicating a /24 to a given box thus seemed logical. (lan, wan, secure wifi 2.4ghz, secure wifi 5ghz, guest wifi 2.4, guest wifi 5, adhoc 2.4 and 5) As per 2, however, it turns out there is a great deal of churn on dhcp lease assignments from devices "passing through", and the conventional APs use /24s to allow for longer dhcp leases. I would certainly like merely to export the /24 (and ipv6 /61) to the universe from each box but have never figured out how. Secondly I wouldn't mind also filtering out the announcements of the 172.20 and 172.21 networks to separate out the lab from production better. But as you know I adore complexity for the sake of complexity. :) Breaking stuff in the lab, trying out extremes, seeing what happens when you have a large routing table, wondering about weird martians, is all "interesting". Recently I got babeld running on an edgerouter pro (8 gigE ethernet interfaces), and made it possible to run the whole lab through it. It was wonderful to just plug it in every-which-way, and get babel to prefer using it via setting a slightly lower rxcost for it - cerowrt's switches are capable of gigE, but only forwarding at 300mbit, the edgerouter can do 8gbit. So I plugged it in, using dhcp to get addresses from the 4 main cero boxes in the lab, used this conf file ubnt@ubnt:~$ cat /etc/babeld.conf interface eth0 wired true rxcost 95 interface eth1 wired true rxcost 95 interface eth2 wired true rxcost 95 interface eth3 wired true rxcost 95 and boom, the whole network switched over to going through the edgerouter. I turn it off (it has a noisy fan) and for sane values of "boom", the whole network switches over to going through the wan or adhoc ports. Compared to what would have happened if I'd tried vlans or some other bridging solution, this was marvelous. The biggest headache on the whole setup is ensuring absolutely everything gets a unique ip. Hopefully (once bug 422 is fixed and hnetd lands) I will update the whole deployment, add 3-5 source specific ipv6 gateways, and push ipv6 out to the whole net. That should break some other stuff up... > diversity sub-TLVs, which means that you're mixing Babel-Z3 with plain > Babel, which can cause sub-optimal routing (the Z3 routers will tend to > avoid the plain routers). Well, the deployed stuff (172.20) is running a mix of quagga and an older babeld. The lab stuff (172.21) is mostly running babels. I was not aware however that -z3 was not universal on the net, I was under the impression that I had turned it on everywhere. > > -- Juliusz -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
