On Thu, Jun 26, 2014 at 01:18:01PM +0200, Juliusz Chroboczek wrote: > Ah, I see. You're performing routing both in the VPN (tinc) and in Babel, > and the two routing algorithms are interacting in unpleasant ways. > Ideally, you wouldn't do that -- you'd use the VPN for point-to-point > links only, and let Babel take care of the routing.
Actually, there is a way to tell Tinc *not* to route anything, thus using it only for building connections between routers. This is why we may get a non-transitive Ethernet segment, exactly like 802.11 in ad-hoc mode. But Babel speakers may still see a high number of neighbours. In addition, multicast is emulated using unicast, which amplifies the control traffic. I'm still experimenting with this, it might be a good idea to limit the number of VPN connections. Actually, this is kind of funny: the better Tinc will be at building connections, the more trouble Babel will have handling so many neighbours. > If for some reason you insist on routing inside tinc and want Babel to > take care of the resulting mess, you could modify Babel to send multiple > unicasts instead of a single multicast (for updates only -- hellos still > need to be multicast). I'd be willing to accept a patch that does that > (configured by setting the maximum number of unicasts before we switch to > multicast) assuming it's clean enough and avoids code duplication. I thought about doing that for IHUs, since they're conceptually unicast, but actually sent as multicast: this is inefficient when multicast is emulated. But the optimisation is probably not worth it for a realistic number of neighbours. Regarding updates, I don't quite understand. Don't we want to send them to *all* neighbours anyway? > Perhaps related, Ray Hunter said the following on the Homenet list: > > Multicast has issues on some link topologies (e.g. where it has to be > emulated), and in situations where devices attempt to sleep for as long > as possible. So even though link-local multicast may be part of the IPv6 > base spec, it may be desirable to avoid use of multicast traffic where > possible. e.g. a routing protocol could perform initial neighbor > discovery using multicast, but then switch to unicast when maintaining > individual neighbor associations on the longer term, or for exchanging > information with specific neighbors. Interesting. It might also be useful for 802.11, where multicast packets use the lowest bitrate possible, which occupies the link for a longer time.
pgpzRKzUGOL6g.pgp
Description: PGP signature
_______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
