FAQ and import/export (was: Re: Problem with bird 1.3.9 on mips/linux)

[Hans van Kranenburg]

 01/24/2013 08:56 PM, Ondrej Zajicek wrote:
> On Thu, Jan 24, 2013 at 02:07:13AM +0100, Hans van Kranenburg wrote:
>> Anyway, I'm only on this list for about two weeks, but if this is a
>> question that would pop up more often, then it could be a great idea to
>> start a FAQ page on http://bird.network.cz/ , below the mailing list,
>> wiki etc.. that would answer this question as wel as...
> 
> There is a FAQ page in BIRD wiki:
> 
> https://redmine.labs.nic.cz/projects/bird/wiki/FAQ
> 
> Perhaps we could add a direct link on the main web page.

Ah, I think that would be a good idea yes. I tried to register and add a
FAQ but it seems editing is not allowed for new accounts, so here's a
small contribution for the FAQ to review and add: :-)

Q: When I configure an IPv6 blackhole route on Linux, the route doesn't
get added to the linux routing table. Instead, when enabling debugging,
I see the following in syslog: "Netlink: No such device". What does this
mean, and how do I blackhole IPv6 traffic?

A: The Linux kernel does not (yet) support blackhole for IPv6 routes. A
commonly used alternative is to use an unreachable route, which gets
added like 'unreachable 2001:db8:1337::/48 dev lo' instead. If you want
to blackhole traffic without sending out icmp errors on linux, you can
route it to a dummy device. Just modprobe dummy, (and/or add dummy to
/etc/modules). This will add a dummy0 interface to your system by
default, so you can route traffic into it. In BIRD configuration this
can be done using e.g. route 2001:db8:1337::/48 via "dummy0"

>> Another FAQ candidate:
>>
>> "Why do I have to specify import at a protocol for whatever I want to
>> export from there, and export for whatever I want the central routing
>> table to import from the protocol I'm configuring?" <- no need to
>> comment on this I guess...
> 
> Well, it is from the point of view of the routing table not from the point of
> view of the protocol. I am not sure which one is more intuitive, but for a
> BGP protocol 'export to the protocol' also means 'export to the peer',
> so POW of the routing table is probably more important.

It's like looking at a Necker cube. :-)

I'll try to explain the view I had while struggling with it. From the
documentation I learned: BIRD has one (or more) central routing tables
that protocols push .oO(export) routes to and receive .oO(import) routes
from: "When the routing table gets a route from a protocol" (the
protocol exports routes to the routing table), "some protocols [..]
receive [..] entries in routing tables" (they import routes from the
routing tables)

protocol kernel {
    import none;
    export all;
}

So I think: ah, protocol kernel wants to export something to that
central routing table! I learned about the central routing table, so
kernel is importing none from it, and exporting all it knows to it, so
other protocols can use it.

The main reason for confusion that is that import and export are defined
*inside* the protocol declaration...

What I did expect in this case was something like:

protocol static static_bgp {
    route 10.0.0.0/8 blackhole;
}

protocol bgp some_bgp {
    neighbor etc etc...
}

routing table default {
    from static_bgp import all;
    to some_bgp export where proto = "static_bgp";
}

I'm not suggesting that this should ever be implemented, just using it
as example, so others who see the necker cube the other way first, might
read this and learn it's not done this way in BIRD.

And then, after *headdesk*-ing and re-RTFM again (because it's not
possible to suck up the complete documentation the first day you're
playing with bird) I had to re-organize my mind and look at the necker
cube the other way...

So instead of thinking the protocols are importing routes from the
central table and exporting stuff to it, I need to think about the
protocols like... kernel wants to export routes from BIRD to the os
kernel routing table, and bgp wants to export routes from BIRD to bgp
peers... bgp can import routes from peers to BIRD etc... etc... When
thinking of BIRD as a whole this makes more sense than only thinking
about the internals of it.

-- 
Hans van Kranenburg - System / Network Engineer
T +31 (0)10 2760434 | hans.van.kranenburg at mendix.com | www.mendix.com