[j-nsp] BGP Blackhole communities

[Richard A Steenbergen]

On Wed, Oct 20, 2010 at 05:03:19PM +0200, Jonas Frey (Probe Networks) wrote:
> Hi,
> 
> its easy:
> 
> - you need "multihop" on internal bgp sessions

On external BGP sessions you mean. The issue is that by default JUNOS 
doesn't let you arbitrarily rewrite next-hops on regular EBGP learned 
routes, which is how you would implement network wide BGP blackholing 
(rewriting the nexthop to a value that is routed to discard on every 
router). There are three main ways you can work around this:

1) Configure multihop on all of your customer EBGP sessions, so that you 
can rewrite next-hop when a blackhole community is matched. The biggest 
downside here is that this breaks "fast external failover" (or whatever 
term Juniper uses for the behavior), where if link state on the external 
interfae drops, the EBGP session is immediately dropped. Without this 
feature you may be blackholing traffic for 60 seconds or more, while you 
wait for BGP hold-timers to expire.

2) Configure "accept-remote-nexthop", a recent feature specifically 
designed to address this issue. But, be very careful with this one, as 
there was a bug in early implementations which caused rpd to crash under 
some conditions when an interface with a configured EBGP neighbor using 
this feature flapped. We hit this one a few times, it was PR 500062 
(though it seems to still be marked hidden). Supposedly fixed in 9.6S5 
and newer.

3) Use dedicated EBGP multishop sessions for customers to inject BGP 
blackhole routes, usually to a centralized route server. This is the 
method we use, as it still has a few major advantages.

One big problem with the other options is that you may want to implement 
different prefix-length limitations for regular routes (e.g. only allow 
upto /24) vs blackhole routes (where you probably want to allow upto 
/32). In the old days of JUNOS there was no way to do this short of 
maintaining two separate "route-filter" lists for each customer (if you 
wanted to do length modifiers like upto/orlonger), which was really 
obnoxious. I finally talked them into adding the prefix-list-filter 
command which lets you add modifiers to a prefix-list match reference, 
but this is still feature incomplete. For example, you can't do things 
uplike "upto", only "orlonger", which may not be sufficient to 
implement proper prefix filtering. 

You can bypass this entire debacle by just using a separate dedicated 
session for the customer blackhole sessions. Instead of having to 
duplicate your prefix-lists for every BGP neighbor on every router, you 
only have to add one new session/policy per ASN. This type of setup also 
makes it easier for you customers to not accidentally screw up and 
blackhole their production traffic, which is actually not as uncommon as 
you might think. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)