On Tue, Aug 25, 2015 at 03:01:05PM +0200, Toke Høiland-Jørgensen wrote: > > Also note that unreachable routing entries should not be propagated to > > core. > > This is actually done to satisfy a requirement of the Babel protocol: > Temporary blackholing is used to avoid routing loops. Quoting section > 3.5.5 of RFC6126: > ... > Now, if the protocol can't propagate an infeasible route to the core, > how do I satisfy this requirement?
Didn't know that. You could propagate the unreachable route in the sense that it will work. But usually it is not a good idea - e.g. some other protocol could have regular routes for the same network, or there could be some covering route. BTW, the argumentation in 3.5.5 of RFC 6126 seems a bit strange to me. It essentially says that unreachable routes are added to avoid transient routing loops before Babel converges. But transient routing loops until convergence is a common behavior for IGPs (both RIP, OSPF and IS-IS do that), while blackholing may be far less expected behavior, esp. if it is for several minutes, which is far longer time than usually necessary for protocol convergence. It seems more like local policy setting than something which should be part of protocol specification. > > I am bit worried about liveness of neighbors and ordering of hooks. > > Say an iface disappears. First you probably get babel_neigh_notify(), > > which does nothing, then you get babel_if_notify(), which will do > > kill_iface() and babel_flush_neighbor(), which unregisters data from > > the neighbor (bn->neigh->data = NULL), but such neighbor is likely to > > be already disposed. > > Noted. Is there a description somewhere of what hooks are called on what > events (and in what order)? Section 2.6 of the programmer's manual only > has fairly short descriptions (in particular, what events trigger > neighbour state changes?), and there are no ordering information. It is true that this part is probably not described anywhere in depth. There are some notes in nest/protocol.h that are not propagated to the documentation. For the rest, you can use the source, but sometimes even the source is 'wrong'. > > Do you have any kind of multihop unicast communication in Babel, or > > everything is single-hop to neighbors? > > Babel only sends packets to link-local addresses of neighbours (and > almost all packets can be either unicast or multicast). However, a node > can forward seqno request packets to a different neighbour; but this is > again only done by link-local unicast. In that case you have always non-NULL babel_iface.iface and you could remove some vestigial code from RIP, like: bif->iface ? bif->iface->name : "(dummy)" -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
signature.asc
Description: Digital signature
