[j-nsp] BGP Blackhole communities

[Chris Morrow]

On 10/20/10 15:24, Richard A Steenbergen wrote:
> 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.

4) reset next-hop as you ship the route internally to IBGP neighbors
(see ... the Wayne Gustavus's (verizon) talk from NANOG32 in Reston:
<http://www.nanog.org/meetings/nanog32/presentations/soricelli.pdf>)

there are, as RAS is pointing out, many ways to skin this cat.

-chris