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 <r...@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp