On Mon, 19 Mar 2012, Gregg Berkholtz wrote: > What I believe needs to happen w/ BIRD, and the Linux Kernel route tables: > 1) Create and maintain a non-default Linux kernel route table, to > accomplish blackholing at our gateways (working great). Also wanting to > have BIRD to monitor this non-default route table, and :666 tag+announce > upstream any /32 entries within our 199.127.224.0/22. > > 2) BIRD imports the non-default kernel route table (seems to be working > ok). > > 3) For each "protocol bgp *Upstream*", use an export filter to identify > and tag relevant "blackhole" route entries with a specific RTBH community > (e.g. 6939:666)...this is what I'm struggling with.
I am not sure I understood exactly what you're trying to do, but... If you create a /32 discard route (using static), say, for 192.0.2.1, and in the import filter, set the nexthop of blackholed routes to that, bird should be smart enough to recursively resolve 192.0.2.1 to discard, and install a discard route instead of one to 192.0.2.1. I did not test the above, but bird certainly was happy enough to install unreachable routes (and not routes to an unreachable gateway) when I set the nexthop to an unreachable ip by mistake... So, if it doesn't do it for discard already, it is probably a valid feature request :-) A less optimized way is to have a dummy0 interface (you need support to the dummy network device compiled in or load the module), assign 192.0.2.1/24 to it, and send blackholed traffic to 192.0.2.2. This _is_ slower than a discard route, the packet will actually go across the entire forwarding stack to be finally sent to an interface that just discards it, instead of being discarded earlier in the stack. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
