So what is the culprit here? What would it take to add an order of magnitude?I start running into trouble with 1000+ routes using 1Mbit mcast. Sooner if I seriously slam the network with flent or something else that abuses mcast like mdns. YMMV.
This being a Freifunk-Network, there is not going to be much planning of the structure beyond mere basics. Until now I just hoped we could get away with having 10K+ routes in one network which would translate into 3k+ clients when considering many nodes and 3 IPv6 addresses for each client which seems to be a reasonable amount when taking into account a clat-address per client and IPv6 privacy extensions. There are approaches to reduce the amount of routes per client including using nat66 on each node. You certainly are making it sound like there should be put some thought into reducing the amount of routes. This will be the next step after we have more than just a few nodes / clients inside the same network.As for aggregation and filtering: Most of my Aps have at minimum, ethernet, and two channels - usually four, including the meshy links. The meshy links are ptp, so I've generally "wasted" an entire /22 ipv4 network to talk to the Aps. ipv6 /62s. The lab component of my network, for example, has two main links to the production net, and the gateways only announce the subnet it is on (172.22.0.0/16). This cuts the churn seen outside the network when I do crazy things like reboot the whole thing. The biggest problem I've run into, is that meshy links, are, meshy - and I've lost track of the number of times where I had a well defined /16 network in the lab suddenly leak all the meshy /32 bits over the worst possible link - because I plugged something in that was adhoc (and poorly) connected to the outside network that I shouldn't have. Lede creates one /48 ULA by default per AP, and then more /60s. I've had a tendency to try to share one /48, but more recently I was trying to go native ipv6 and disabled the ULA generation entirely. I don't bridge anything except sometimes on the last Aps on a link (which don't announce babel on that bridge). Bridging can do weird things to daemons that want also to be measuring the individual links. So in your network design I'd try to identify your backbone links and try upfront to rationally partition the network numbering scheme, and still, periodically try to optimize it. It makes no sense to export all the churn the last hop of a meshy, yet leaf network can have to the whole network. I'd simulate what you plan, and then slam it with traffic from every point with a tool like flent, and deploy cake or htb+fq_codel on the ISP up/downlinks.
BTW: the Freifunk networks use an autoupdater. This might just solve your tree-climbing-problem in the long run...
Cheers Christof
I'm working these days, on making netem better emulate wifi's behaviors. I'm not satisified with it yet.
Note that babeld currently sends updates as a single burst when the upate interval expires (the same is true of Toke's implementation of Babel, as far as I'm aware). For very large networks, it would be good to split updates into one-packet pieces that are sent throughout the update interval. I'd be glad to accept a patch that does that.
* making babel trigger updates on newly appeared routes
I've gone through different approaches for scheduling updtes, and the current master is more aggressive with scheduling updates. I'd need to check to make sure, but I believe it already does what you suggest. If you have time, could you please check if current master improves things; if it doesn't, we need to work together to improve the implementation (no protocol changes will be needed).
You could also try Toke's implementation, which is very well written.
* communicating the appearance of a route across the network outside babel and inserting that at the gateway
I'm not sure what you mean.
What do you think about those approaches?
Please try current master. If not, we'll need to think together about redesigning our approach to sending triggered updates.
-- Juliusz
_______________________________________________ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
-- () ascii ribbon campaign - against html e-mail /\ against proprietary attachments
signature.asc
Description: PGP signature
_______________________________________________ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
