Greetings, I'm a big fan of Bird, which I've been using for various experiments, where I've found it very powerful and really fast (and way less buggy than Juniper). Thanks for all your great efforts!
I apologize if this topic keeps coming up and you are sick of it, but I'm just hoping to document, via this email, a little more detail about mutually recursive routes, which is why there is not more than one (1) level of route recursion for BGP routes. Very stupidly, I ran into an issue recently because I naively configured Bird to install routes learnt in a route reflector scenario into the kernel routing table (FIB). After rereading the BGP RFC about "Mutually recursive routes (routes resolving each other or themselves) also fail the resolvability check." it became clear this was correct behaviour. (face palm) (I must admit that while there is no real need, and it would be non-RFC compliant, it would be kind of cool/sneaky to have a flag to allow multiple levels of recursion, either globally, in kernel protocol section, or maybe on a per BGP neighbour basis. In my scenario installing the routes would actually be fine.) Anyway, to help other fools like me, I wonder if we could add an additional comment to the "gateway direct|recursive" section at http://bird.network.cz/?get_doc&f=bird-6.html#ss6.2, perhaps something like "Please remember that as per https://tools.ietf.org/html/rfc4271#section-9.1.2.1 - Route Resolvability Condition, specifically 'Mutually recursive routes (routes resolving each other or themselves) also fail the resolvability check.'" Documenting here for others to find via search, because it took me a moment. Diagram looks like this: Bird RR -- a.a.a.a/30 -- router1 -- b.b.b.b/30 -- router2 -- c.c.c.c/24 RFC compliant warning shown in the Bird log file: 2014-12-11 12:42:45 <TRACE> router2: State changed to up 2014-12-11 12:42:45 <TRACE> router2: Sending UPDATE 2014-12-11 12:42:45 <TRACE> router2: Sending UPDATE 2014-12-11 12:42:45 <TRACE> router2: Sending End-of-RIB 2014-12-11 12:42:45 <TRACE> router2: Got UPDATE 2014-12-11 12:42:45 <WARN> Next hop address b.b.b.2 resolvable through recursive route for a.a.a.a/30 2014-12-11 12:42:45 <TRACE> router2 > added [best] c.c.c.c/24 unreachable 2014-12-11 12:42:45 <TRACE> kernel1 < added c.c.c.c/24 unreachable 2014-12-11 12:42:45 <TRACE> core < added c.c.c.c/24 unreachable 2014-12-11 12:42:45 <TRACE> router2 < rejected by protocol c.c.c.c/24 unreachable 2014-12-11 12:42:45 <TRACE> core: Sending UPDATE Why this happens: 1. BGP comes up between Bird RR and router1, via direct network. 2. Bird learns b.b.b.b/30 from router1, and installs the route. 3. BGP then comes up between Bird and router2, as the neighbour is reachable via the route learnt in step2. 3. Bird learns c.c.c.c/24, but rejects the route because it is mutually recursive, per RFC. The fix, which is exactly how router reflectors are normally setup, is to: 1. Install some kind of IGP route for router2 via a.a.a.a/30. e.g. Install a static route, like default or more specific, towards router1. The static route can be installed by Bird, or you can just put it in the kernel ('ip route add ...'). protocol static { route 0.0.0.0/0 via a.a.a.2; #default route route b.b.b.b/30 via a.a.a.2; #or a more specific route import all; export all; }; e.g. Run up OSPF, (or ISIS via Quagga?) between Bird and router1. 2. Don't use the kernel protocol to avoid routes being installed into the FIB/kernel, or filter the BGP routes learnt going into protocol kernel. If in fix step 1 you installed a kernel static, then you will want to learn that so Bird knows about it. This issue has been discussed before in the mailing list, however the reason wasn't fully expanded upon. http://bird.network.cz/pipermail/bird-users/2012-October/003223.html Timo: " What's the problem with using iBGP routes for recursive lookups (when using iBGP as IGP)? The message even says that the route is resolvable. " Elen: " BIRD does not allow recursive routes to depend on another recursive route. If your iBGP is configured to generate non-recursive routes (using 'gateway direct' option), then recursive routes (from another BGP) could depend on that routes, but i am not sure if such setting could be useful, esp. it does not work if you want to use the same iBGP session for both recursive and non-recursive routes. " Timo: " Let me rephrase my question: Why does BIRD not allow recursive routes to depend on another recursive route. What could go wrong if it was allowed? " Elen: " It is mainly for simplicity of some implementation issues and preventing problems like mutually recursive routes. " Other key words for search engine: - bgp route won't install - bgp multihop routes not installed - bird ibgp routes not installed - bird ebgp routes not installed - bird router routes not installed - bird route reflector error Kind regards, Dave Seddon
