On Sun, Jan 17, 2016 at 12:19:08PM +0100, Toke Høiland-Jørgensen wrote:
Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> writes:
Please don't make this configurable, it only breaks interoperability. Section 4 of RFC 6126 is very clear about the maximum size of a Babel packet:
Noted. Snatched that from the RIP implementation; thought it might be nice to be configurable in the same way. Guess I was wrong... ;)
Hi I still prefer to keep these options in the code. They are consistent with options in RIP and OSPF interface statements and although bad usage of these options may break compatibility, they are useful for handling some exceptional situations. Some examples are interoperatility with potential broken implementations (there is a RIP implementation that sends packets of size 560 although maximum per RFC is 540), networks where optimal packet length is lower than IP MTU (some tunnels or networks with L2 fragmentation), or situations where BIRD does not properly account for IP overhead because of admin-configured IP options like IPSec). Although the code should use proper length from RFC by default, so the function babel_iface_update_buffers() should do: uint rbsize = ifa->cf->rx_buffer ?: MAX(ifa->iface->mtu, BABEL_MIN_MTU); uint tbsize = ifa->cf->tx_length ?: MAX(ifa->iface->mtu, BABEL_MIN_MTU); Instead of uint rbsize = ifa->cf->rx_buffer ?: ifa->iface->mtu; uint tbsize = ifa->cf->tx_length ?: ifa->iface->mtu; Where BABEL_MIN_MTU is 540 (512 adjusted for IP and UDP headers).
+static struct babel_source * +babel_find_source(struct babel_entry *e, u64 router_id) +{ + struct babel_source *s; + WALK_LIST(s, e->sources) + if (s->router_id == router_id) + return s; + return NULL; +}
We've recently found out that in large networks, a large amount of CPU time (40%) in babeld was taken by walking the source table -- I recommend using a more efficient data structure here. (Source creation/flushing is rare, but searching for a source is very common.)
Yeah, saw that thread. Punted on doing something about it here; guess I'll see if I can figure out how the Bird hash table works... Bah! Who needs such big networks anyway?
I did not read mentioned thread, but note that here the function babel_find_source() iterates only through sources for one propagated prefix. So the problematic situation is a big L2 network with many associated routers in it, propagating the same prefix for it? I have one more general question. Is ETX cost algorithm really a reasonable idea? It seems to me that in many cases it will lead to oscillations, because packet loss in wireless networks usually depends on traffic load. It seems to me that dynamic cost algorithms based on packet loss should at least use some hysteresis. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."