-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for the help and suggestions, we have a working configuration that now imports and uniquely tags/announces blackhole specific kernel route entries.
For the archives, here's a basic working "example" config. I opted to get away from statically configuring blackhole routes within BIRD itself, as existing tooling adds/removes kernel route table entries on the linux-based router, and keeping this within kernel routing tables is a simpler approach for us. If using a Linux 2.6 kernel based router, and when tracking blacklisted IPs via a 2nd route table: To blacklist 192.0.2.44/32, run: ~$ sudo ip route add blackhole 192.0.2.44/32 table 10 Using the below configuration, within 10 seconds BIRD will detect a new addition to kernel routing table 10, and: 1) Auto-add a corresponding blackhole entry to your kernel's master routing table...truly blacklisting the IP on your router. 2) Announce 192.0.2.44/32 with a BGP tag of 64665:666 to your upstream provider, enabling you to leverage a customer blackhole community config (e.g. RTBH portion of RFC3882). Relevant portions of bird.conf: "... # Scans and learns of blackhole routes from table 10, every 10 seconds table blackholes; protocol kernel blackhole { table blackholes; kernel table 10; scan time 10; learn; import all; export all; } # Merges kernel route table 10 into the kernel's active/master routing table protocol pipe { table master; peer table blackholes; mode transparent; import filter { print "Importing blackhole list."; accept; }; } filter bgp_out_upstream { # Limit to blackholed routes if (proto = "blackhole" ) then { # Limit to /32 netmask if net.len = 32 then { bgp_community.add((64665,666)); # Replace 64665 with your upstream's ASN printn "Nulling "; print net; accept; } } if net ~ [192.0.2.0/24] then accept; # Replace 192.0.2.0/24 with your local netblock(s) reject; } protocol bgp upstream { ... export filter bgp_out_upstream; ... } ..." Hope this helps others, Gregg Berkholtz Datacenter consulting, hosting & support since 1995 www.tocici.com | 503-488-5461 x17 | AS14613 On Mar 20, 2012, at 3:25 PM, Ondrej Zajicek wrote: > On Tue, Mar 20, 2012 at 11:42:05AM -0700, Kelly Cochran wrote: >>> Or much simpler solution - remove secondary tables, add blackhole routes >>> to bird config as static routes (in static protocol) and have everything >>> in the master table. >> > >> Which is exactly what I wound up doing when testing this sort of thing >> internally. Soft config reloads won't bounce the session when you >> change items in the static protocol. Good use for an include, generate > > BTW, even 'hard' reconfiguration will not restart the session if there is > no change in the BGP session protocol (and its filters). The difference > between soft/hard reconfiguration in BIRD is just whether filter changes > are considered. > >>> BTW, in the filter bgp_out_he(), i guess you want accept all routes with >>> proto = "blackhole", otherwise only your routes would be exported (and i >>> suppose blackholed IPs are foreign). >> > >> Blackholed IPs would actually have to be local. This mechanism is >> common for dropping a DDoS at your upstream's borders, and not just your >> own border, as it's presumably not something you can effectively >> mitigate internally. Remote IPs would be S/RTBH, and that's not usually >> seen in transit networks due to the nature of what that would require to >> affect only the requestor of the blackhole, and not the network as a >> whole. (VRFs for everyone! Wait... that requires how much RAM? >> Nevermind...) > > Yes, i thought more about S/RTBH. > > BTW, to implement other side of RTBH we would probably need to support > explicit change of received BGP route destination to > unreachable/blackhole/prohibit type. This currently could by done by > some tricks, so explicit filter operator for that would be useful, i > suppose. > > -- > Elen sila lumenn' omentielvo > > Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) > "To err is human -- to blame it on a computer is even more so." -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk9zYNkACgkQw+5R43T/iWXgUgCfcH5j2/vF2i40C4RHf5o5gKIV 5C0AoJlSRUJmzzVlAyitQTSWR8NrYmaj =bn0k -----END PGP SIGNATURE-----