Implementing RTBH filtering / BGP tagging

[Henrique de Moraes Holschuh]

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