Mailing List Archive

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?

Limit the Number of Prefixes on a BGP Peering
You can limit the number of prefixes received on a BGP peering and log rate-limited
messages when the number of "injected" prefixes exceeds a set limit. You can also tear
down
the peering when the number of prefixes exceeds the limit.

Thanks!
-Kashif.
+++The information transmitted is intended only for the person or entity to which it is
addressed and may contain confidential and/or privileged material. Any review,
retransmission, dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and destroy any copies of this
document.+++

And what do you want to confirm exactly...?

Erik

On Wed, 2004-02-25 at 23:39, Kashif.Khawaja@Broadwing.com wrote:
> Hi All,
>
> Just wanted to confirm something.
> +++The information transmitted is intended only for the person or entity to which it is
> addressed and may contain confidential and/or privileged material. Any review,
> retransmission, dissemination or other use of, or taking of any action in reliance upon,
> this information by persons or entities other than the intended recipient is prohibited.
> If you received this in error, please contact the sender and destroy any copies of this
> document.+++
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
--
---
Erik Haagsman
Network Architect
We Dare BV
tel: +31.10.7507008
fax: +31.10.7507005
http://www.we-dare.nl

Hi Kashif,

AFAIK, this is an absolute figure, counting the amount of routes sent by
the peer and it doesn't take filtered routes into account.

Cheers,

Erik

On Wed, 2004-02-25 at 23:41, Kashif.Khawaja@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?
>
> Limit the Number of Prefixes on a BGP Peering
> You can limit the number of prefixes received on a BGP peering and log rate-limited
> messages when the number of "injected" prefixes exceeds a set limit. You can also tear
> down
> the peering when the number of prefixes exceeds the limit.
>
> Thanks!
> -Kashif.
> +++The information transmitted is intended only for the person or entity to which it is
> addressed and may contain confidential and/or privileged material. Any review,
> retransmission, dissemination or other use of, or taking of any action in reliance upon,
> this information by persons or entities other than the intended recipient is prohibited.
> If you received this in error, please contact the sender and destroy any copies of this
> document.+++
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
--
---
Erik Haagsman
Network Architect
We Dare BV
tel: +31.10.7507008
fax: +31.10.7507005
http://www.we-dare.nl

Kashif.Khawaja@Broadwing.com writes:


Kashif,

> Hi All,

> Just wanted to confirm something. "Injected" in the text
> below refers to prefixes accepted into the BGP table?

Yes.

> Prefixes that passed the import policies?

And also prefixes that did not pass import policies.

The default behaviour for processing a received BGP path ('keep
none/all' change this):

1) perform a set of basic checks (as-path loop detection, etc). If the
test fails discard the route... doesn't get installed in the routing
table, etc.

2) perform import policy. If the policy fails the route still gets
stored in the routing table but w/ a preference that makes it
unusable. This is done so that when import policy is changed, the
router can locally reevaluate policy for routes that it has rejected.

This entries that do not pass import policy do consume resources and
such are counted against prefix-limit parameters.

o "keep all" instructs the router to keep paths that fail test 1)
o "keep none" " " " " " " reject paths that fail test 2)

But i would advise against fiddling w/ those... unless you really
must.

Pedro.

On Wed, Feb 25, 2004 at 04:41:51PM -0600, Kashif.Khawaja@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@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

On Wed, Feb 25, 2004 at 03:54:23PM -0800, Pedro Roque Marques wrote:
> This entries that do not pass import policy do consume resources and
> such are counted against prefix-limit parameters.

Might it be useful for people using prefix limits as a "don't leak and
destroy the internet" safety net rather than a "don't announce 1 million
routes and suck up all my ram" safety net to have the option of which one
(or both) to check on the prefix limit?

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

ras@e-gerbil.net (Richard A Steenbergen) writes:

> On Wed, Feb 25, 2004 at 04:41:51PM -0600, Kashif.Khawaja@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.

There are totally orthogonal issues...

'prefix-list' vs 'policy-statement route-filter' is purelly a question
on syntax. Lets not rehash this one at the moment...

The important question is: do the routes that are rejected by the
policy still consume resources or not... if they do they need to be
counted against a prefix-limit, if they don't ("keep none") they
aren't.

prefix-limit is supposed to keep your box from rolling over by
exaustive resource comsumption from a peer.

Pedro.

On Wed, Feb 25, 2004 at 05:17:20PM -0800, Pedro Roque Marques wrote:
> prefix-limit is supposed to keep your box from rolling over by
> exaustive resource comsumption from a peer.

Ah the joys of developers vs operators. I don't think there are any
network operators who would give that as the reason for using prefix
limits. :)

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

Richard,

Your comments are certainly appreciated. It would be most
helpful if you could work with your Juniper account team to
codify your requirements and have them file an Enhancement
Request so we might be able to provide the functionality you
want in a future release.

-----Original Message-----
From: juniper-nsp-bounces@puck.nether.net
[mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of Richard A
Steenbergen
Sent: Wednesday, February 25, 2004 6:20 PM
To: Pedro Roque Marques
Cc: Kashif.Khawaja@Broadwing.com; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] BGP Prefix-Limit On A Session


On Wed, Feb 25, 2004 at 05:17:20PM -0800, Pedro Roque Marques wrote:
> prefix-limit is supposed to keep your box from rolling over by
> exaustive resource comsumption from a peer.

Ah the joys of developers vs operators. I don't think there are any
network operators who would give that as the reason for using prefix
limits. :)

--
Richard A Steenbergen <ras@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
http://puck.nether.net/mailman/listinfo/juniper-nsp

On Wed, Feb 25, 2004 at 09:20:21PM -0500, Richard A Steenbergen wrote:
> On Wed, Feb 25, 2004 at 05:17:20PM -0800, Pedro Roque Marques wrote:
> > prefix-limit is supposed to keep your box from rolling over by
> > exaustive resource comsumption from a peer.
>
> Ah the joys of developers vs operators. I don't think there are any
> network operators who would give that as the reason for using prefix
> limits. :)

Oh, there are. And actually I think Juniper is 110% right and IOS
is wrong or at least suboptimal there.

IOS max-prefix limits with soft-reconfig inbound leaves your box
pretty vulnerable to resource exhaustion.


Regards,
Daniel

On Wed, Feb 25, 2004 at 06:26:52PM -0800, Paul Goyette wrote:
> Richard,
>
> Your comments are certainly appreciated. It would be most
> helpful if you could work with your Juniper account team to
> codify your requirements and have them file an Enhancement
> Request so we might be able to provide the functionality you
> want in a future release.

Yeah yeah yeah I know. :)

I'm not trying to harp on this issue, and please no one at Juniper take
offense, but I'm curious how many operators out there agree or disagree
with me on this point. This seems like as good a place as any to ask,
since Juniper using operators tend to be the clueful ones anyways.

Are there any operators out there who place the importance of prefix
limits providing protection of routing resources from someone announcing a
million routes above or anywhere near the importance of using prefix
limits to catch "common" leaks by peers/customers/etc which would result
in suboptimal routing?

Is this particular disconnect between developers and operators perhaps one
of the reasons why every operator I know would LOVE to see auto-adjusting
prefix limits that follow the "normal" number of prefixes announced by a
peer, and yet no vendor has ever tried to implement it (that I know of
anyways)?

Food for thought at any rate.

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

On Wed, 25 Feb 2004, Richard A Steenbergen wrote:

> Are there any operators out there who place the importance of prefix
> limits providing protection of routing resources from someone announcing a
> million routes above or anywhere near the importance of using prefix
> limits to catch "common" leaks by peers/customers/etc which would result
> in suboptimal routing?

I would like that obviously, but then again I may be one of the few people
who don't want other peoples routers exploding my network.

>
> Is this particular disconnect between developers and operators perhaps one
> of the reasons why every operator I know would LOVE to see auto-adjusting
> prefix limits that follow the "normal" number of prefixes announced by a
> peer, and yet no vendor has ever tried to implement it (that I know of

It just wasn't that important compared to what else we had on the deveng
plate, and thats what weekly script runs are for.

/vijay

* Thus spake Richard A Steenbergen (ras@e-gerbil.net):

> Are there any operators out there who place the importance of prefix
> limits providing protection of routing resources from someone announcing a
> million routes above or anywhere near the importance of using prefix
> limits to catch "common" leaks by peers/customers/etc which would result
> in suboptimal routing?

We use it to protect the resources as a sanity check. Prefix limits
are set to 200% of the number routes in the list which is auto-generated
by a script using routes properly registered in the IRR. This gives the
customer some leeway for minor leaks and/or room to grow without taking
out our routers. There are plenty of routers out there running a fine
line in terms of resources as companies squeeze more and more out of
every piece of gear.

>
> Is this particular disconnect between developers and operators perhaps one
> of the reasons why every operator I know would LOVE to see auto-adjusting
> prefix limits that follow the "normal" number of prefixes announced by a
> peer, and yet no vendor has ever tried to implement it (that I know of
> anyways)?

I agree with Vijay, this can be done using scripts and we don't see
the number of routes that are advertised by customers wildly swinging
up or down from day to day so the auto-sensing feature while interesting,
probably doesn't help any more than scripts. We would hope that someone
that is going to start announcing a significantly larger amount of routes
due to a legitimate reasons would work with their provider to prepare for
such an event.

thanks
-cp

On Wed, Feb 25, 2004 at 10:33:01PM -0500, Craig Pierantozzi wrote:
>
> I agree with Vijay, this can be done using scripts and we don't see
> the number of routes that are advertised by customers wildly swinging
> up or down from day to day so the auto-sensing feature while interesting,
> probably doesn't help any more than scripts. We would hope that someone
> that is going to start announcing a significantly larger amount of routes
> due to a legitimate reasons would work with their provider to prepare for
> such an event.

Ok I may lose this one on the basis of scripting. Personally I am of the
belief that every time a perl script logs into a router, baby jesus crys.
But thats just me. :)

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

On Wed, Feb 25, 2004 at 10:35:57PM -0500, Richard A Steenbergen wrote:
> On Wed, Feb 25, 2004 at 10:33:01PM -0500, Craig Pierantozzi wrote:
> >
> > I agree with Vijay, this can be done using scripts and we don't see
> > the number of routes that are advertised by customers wildly swinging
> > up or down from day to day so the auto-sensing feature while interesting,
> > probably doesn't help any more than scripts. We would hope that someone
> > that is going to start announcing a significantly larger amount of routes
> > due to a legitimate reasons would work with their provider to prepare for
> > such an event.
>
> Ok I may lose this one on the basis of scripting. Personally I am of the
> belief that every time a perl script logs into a router, baby jesus crys.
> But thats just me. :)

Poke around this mib (in recent sw):

enterprises.2636.5.1.1.2.6.2.1.7

- Jared


--
Jared Mauch | pgp key available via finger from jared@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.

On Wed, 2004-02-25 at 22:35, Richard A Steenbergen wrote:
> Ok I may lose this one on the basis of scripting. Personally I am of the
> belief that every time a perl script logs into a router, baby jesus crys.
> But thats just me. :)

At the other end of the spectrum, I would like nothing more than to
issue `request system software add jperl` and let my routers pull from
my data sources, instead of the other way around. :-)

--
Jeff at Reflected Networks

#-----Original Message-----
#From: Richard A Steenbergen [mailto:ras@e-gerbil.net]
#Sent: Wednesday, February 25, 2004 9:47 PM
<snip>
#Are there any operators out there who place the importance of prefix
#limits providing protection of routing resources from someone
#announcing a
#million routes above or anywhere near the importance of using prefix
#limits to catch "common" leaks by peers/customers/etc which
#would result
#in suboptimal routing?

I have to partially disagree with you Richard. I support the JunOS behavior
here, and do implement both an explicit prefix-list (aka.
policy-statement/route-filter) based on IRR data, and a prefix-limit based
on registered routes +overhead. This is for the reasons already mentioned.
As far as the BGP session bounce when adding the prefix-limit, I completely
understand your point.

There is also much pain involved when a BGP group contains multiple peers
who share a common export-policy, but adding a prefix-limit to one of the
peers, where it didn't exist before causes unchanged peers' BGP session to
reset as well.

I am aware that this will always happen wrt to export-policy changes, and
how JunOS internally groups based on a common set of attributes that control
export policy (for scalability). However, It didn't make much sense that
this would be related to prefix-limits as well. I am told that behavior was
a bug, and was due to be fixed at some point? Can anyone at Juniper confirm
that?

#
#Is this particular disconnect between developers and operators
#perhaps one
#of the reasons why every operator I know would LOVE to see
#auto-adjusting
#prefix limits that follow the "normal" number of prefixes
#announced by a
#peer, and yet no vendor has ever tried to implement it (that I know of
#anyways)?

This is a wonderful idea! Obviously not difficult, either.

-Ben

> I am aware that this will always happen wrt to export-policy
> changes, and how JunOS internally groups based on a common set
> of attributes that control export policy (for scalability).
> However, It didn't make much sense that this would be related
> to prefix-limits as well. I am told that behavior was a bug,
> and was due to be fixed at some point? Can anyone at Juniper
> confirm that?

As far as I know, this is not a bug. When you add the peer's
new attribute, you differentiate that peer from the rest within
the group. As a result, internally the group is "split" into
two groups, one with the new attribute and one without it. If
the "other" peers end up in the newly created group, you will
see the described behavior, since they are actually moved from
one group to another. If the "other" peers remain in their
original group (and thus it is the "modified" peer that moves)
you will not see this behavior, since the "other" peers don't
move.

Wed, Feb 25, 2004 at 10:35:57PM -0500, Richard A Steenbergen:
> Ok I may lose this one on the basis of scripting. Personally I am of the
> belief that every time a perl script logs into a router, baby jesus crys.
> But thats just me. :)

is there some logic behind that statement; do tell why.

On Thu, Feb 26, 2004 at 09:41:50AM -0500, bbird@epik.net wrote:
> There is also much pain involved when a BGP group contains multiple peers
> who share a common export-policy, but adding a prefix-limit to one of the
> peers, where it didn't exist before causes unchanged peers' BGP session to
> reset as well.

Yeah, this is a long-standing internal broken design of JunOS. Actually,
I'd say the engineers who wrote the code made it a little bit too easy
for themselves. Same goes for changing export policy chain of the first
neighbor of a peer group etc. Or changing metric-out or whatever. There
is absolutely NO reason to reset the BGP session unless actual session
parameters have changed or capability negotiation has to reoccur.
Sadly, I had a very hard time to get this point across to Juniper folks.
But finally, ER6574 was opened to fix senseless session resets - but
that's now more than a year ago and no change yet.

We'll see when this is finally being fixed... until that, I don't
want to hear _anything_ about "carrier grade reliability" anymore.
:-)


Best regards,
Daniel

On Thu, Feb 26, 2004 at 06:57:31AM -0800, Paul Goyette wrote:
> As far as I know, this is not a bug.

It is.

> When you add the peer's new attribute, you differentiate that
> peer from the rest within the group. As a result, internally
> the group is "split" into two groups, one with the new attribute
> and one without it. If the "other" peers end up in the newly
> created group,

... which is a purely internal thing ...

> you will see the described behavior, since they are actually moved
> from one group to another.

... which is a purely internal thing ...

There is technically no reason at all to reset sessions, so if JunOS
resets, it's IMNSHO a bug.

You are just describing that the programmers were too lazy to properly
port the session context to the new internally created group and
preferred to just reset all sessions to "clean up" the internal data
structures after the change. :-)


Best regards,
Daniel

#-----Original Message-----
#From: Paul Goyette [mailto:pgoyette@juniper.net]
#Sent: Thursday, February 26, 2004 9:58 AM
#To: juniper-nsp@puck.nether.net
#Subject: RE: [j-nsp] BGP Prefix-Limit On A Session
#
#> I am aware that this will always happen wrt to export-policy
#> changes, and how JunOS internally groups based on a common set
#> of attributes that control export policy (for scalability).
#> However, It didn't make much sense that this would be related
#> to prefix-limits as well. I am told that behavior was a bug,
#> and was due to be fixed at some point? Can anyone at Juniper
#> confirm that?
#
#As far as I know, this is not a bug. When you add the peer's
#new attribute, you differentiate that peer from the rest within
#the group. As a result, internally the group is "split" into
#two groups, one with the new attribute and one without it. If
#the "other" peers end up in the newly created group, you will
#see the described behavior, since they are actually moved from
#one group to another. If the "other" peers remain in their
#original group (and thus it is the "modified" peer that moves)
#you will not see this behavior, since the "other" peers don't
#move.

I completely understand that behavior (even though I don't always agree with
it). I understood that behavior only pertained to export policy, no? The
way I understand it is, JunOS organizes peers into operational groups for
the purpose of consolidating bgp updates and export policy evaluation. This
being done for scalability. Let me clarify...

What I am concerned with is 'family inet any prefix-limit'. I don't see how
that knob relates to export-policy, at all. However, it produces similar
behavior, where unchanged peers are bounced when a prefix-limit is applied
to a neighbor in the same group (5.3R2.4...I know, I know...). When I
originally opened a TAC case (which history has been removed) on it, I was
told that adding a prefix-limit should not affect other sessions in the same
bgp group, and would be fixed at a later date.

I can "almost" understand why JunOS would reset the BGP session where a
newly added prefix-limit is applied. I would have to do my research, but I
didn't think that prefix-limit was a session negotiated parameter (could be
wrong here). So even resetting the session being changed, with respect to
prefix-limit, doesn't even make much sense to me. But I see no reason why
unchanged peers should be reset, when adjusting a locally significant
attribute that doesn't pertain to export policy.

-Ben Bird

bbird@epik.net writes:

>
> There is also much pain involved when a BGP group contains multiple peers
> who share a common export-policy, but adding a prefix-limit to one of the
> peers, where it didn't exist before causes unchanged peers' BGP session to
> reset as well.
>

Modifying prefix-limit does not, afaik, reset the session, much less
other peers.

However, prefix-limit is configured under address family. If you where
to modify the address families for a peer then you would probably see
the behaviour you describe.

btw: 6.3 tries to be smarter than previous releases in this regard. If
you do change the export parameters of the first neighbor in the
group, that neighbor will get reset now, and the unchanged neighbors
will stay up.

Pedro.

bbird@epik.net writes:

>
> What I am concerned with is 'family inet any prefix-limit'. I don't see how
> that knob relates to export-policy, at all. However, it produces similar
> behavior, where unchanged peers are bounced when a prefix-limit is applied
> to a neighbor in the same group (5.3R2.4...I know, I know...). When I
> originally opened a TAC case (which history has been removed) on it, I was
> told that adding a prefix-limit should not affect other sessions in the same
> bgp group, and would be fixed at a later date.

Please note that if you have
group foo {
family inet any;
neighbor 1.2.3.4 {
family inet unicast { xyz; }
}
}

This means that neighbor 1.2.3.4 does not have inet multicast enabled,
just unicast.

I don't know if this was the case, but it is often not a well
understood detail.

Pedro.