I use the rxcost parameter to give a mild bias to the 5.x ghz radios. In the test deployment I found it necessary to bump up rxcost in proportion to the radio's quality and intent. so I ended up with rxcost of 1024 and 1023 for wndr3800s rxcost of 768 for picostation 2HPs (used by users) rxcost 256 for the directional nanostation M5 backbone This gave the m5 radios preference and only in case of failure do things fall back to the 2HPs and wndr3800s. Otherwise the m5s would prefer a direct connection to a lousy radio vs a 2 hop or more route that used good radios and ethernet. I'm not saying this is correct, but it worked. redistribute kernel works correctly for dhcpv4 inserted default routes. It does not appear to work correctly for RA inserted ipv6 routes, nor has it been tested for other forms of ipv6 routes as yet. WIP.
While arguably the wrong thing (babel should do something sane upon receipt of a ECT(3)) I am trying to analyze the behavior of the multicast queue which is buried deep in the stack, far below where it can be seen easily. It is my intent to monitor codel behavior by (in part) observing ECT(0) being asserted on babel packets via an ip6tables rule. In fact I intended to track all sorts of ECN behavior via iptables rules in the upcoming test series.
I note that this experimental package also contains a patch to mark babel packets as ECN capable, when in reality they are not, at present. In the words of Juliusz: "that's a horrible kludge. You're applying AQM to locally-originated data in order to compensate for the lack of backpressure, and then falsely asserting ECN in order to bypass the AQM policy." As for the first statement, queues are necessary at multiple layers in the stack, so I can think of no effective means of supplying backpressure at insertion time that will work. I can think of means of supplying congestion related drop indications to babel, but that is as yet, unimplemented. As to the second objection, yes this is bypassing AQM policy, however, at some point, using ECN marking in babel could be used for something. The udp markings can be easily obtained with pktinfo in userspace, and I do need to produce a patch for that. In the interim, the problem I am trying to solve is that when a rate change happens in wifi, it is abrupt and can take a long time (with the fq_codel aqm rapidly ramping up packet drop) to drop the backlog back to a normal level for the new rate. IMHO it is better to have a radio continue to function rather that potentially stop entirely because it dropped a bunch of babel packets while seeking a new equilibrium.
Conflicts: net/quagga/Makefile Denis contributed some fixes to the default babeld.conf file
* redistribution is specific not to an interface, but to a routing process * the right redistribution type for Cero is "connected", everything else is off by default * delist interfaces ge00 and gw00 to match default configuration of standalone babeld
* comment a hanging multiline string out * update package description * libgcrypt and libgpg-error are dependencies of quagga-libzebra only * quagga-libzebra is a default dependency and should not be listed extra times * isisd, ospfd, ospf6d, ripd, ripngd and babeld are not functional without a zebra process (provided by "quagga" package)
codel does allow for bursts, but anything larger than a few hundred packets is crazy for gigE and below - and in pathological situations the default 10k limit (15MB) can run you out of ram, so... arbitrarily limit to 600 max.
Slightly more robust error checking put in for debloat to work aright again in cero... but I do wish there was a sys or proc interface to all this stuff or some other stable output format for ethtool.
Blackholing makes sense for core routers, less sense for corporate/home/mesh routers, where getting net unreachable messages back is rate limited and desirable for happy eyeballs.