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@mendix.com | www.mendix.com