[j-nsp] BGP Prefix-Limit On A Session

Richard A Steenbergen ras at e-gerbil.net
Wed Feb 25 20:08:53 EST 2004


On Wed, Feb 25, 2004 at 04:41:51PM -0600, Kashif.Khawaja at Broadwing.com wrote:
> Hi All,
> 
> Just wanted to confirm something. "Injected" in the text below refers to
> prefixes accepted into the BGP table? Prefixes that passed the import
> policies?

One of the fairly negative aspects of not having an explicit "neighbor
prefix-list" command (as Cisco implements it) is that there is really no
safe way to implement a prefix-list filter on a customer/peer/whatever,
and still use the prefix limit as a safety net on top of that.

For example, say you have a customer who normally announced 20 routes via
BGP. You have an explicit prefix-list (well, policy-statement with a
series of route-filter statements, as the prefix-list statement is
horribly crippled by the lack of modifiers like orlonger etc) allowing all
20 routes, and you have an additional safety net of a 100 entry
prefix-limit. Now say one day the customer hoses something and starts
leaking 1000 routes from one of their peers or other transits. Even though
you have the prefix filter in place and are effectively limiting them to
20 routes, you're still going to trip the prefix limit. At least with
Juniper you don't necessarily have to tear down the entire session, but
that doesn't solve the underlying problem.

The entire prefix-list/limit system drives me nuts personally, and is
probably the biggest reason why it is horribly inconvenient to use Juniper
in a BGP-speaking-customer attach device role.  Having to use a
policy-statement to do prefix-filtering and then not being able to re-use
that list for packet filtering etc is certainly pretty darn annoying.
Having a customer session torn down because they accidentally leak some
routes even when your prefix filtering would catch them is fairly annoying
too. 20 lines of config per neighbor if you want to limit v4, v6, and
multicast routes, that's pretty annoying. Bouncing BGP sessions when you
go to add a prefix limit because the commands that set the prefix-limits 
are under the commands that set negotiated NLRI's to be advertised, 
OOOOOOOOH that'll drive you up a wall real quick. :)

I'm sure Juniper has a reason for doing it the way they do it, and there 
is no discounting that being able to do everything in a policy-statement 
is a simple and powerful way to implement almost anything, but the sooner 
they fix some of the above the happier I'll be. :)

-- 
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)


More information about the juniper-nsp mailing list