Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Comments inline. Thank you for discussing this.

#-----Original Message-----
#From: Pedro Roque Marques [mailto:roque@juniper.net]
#Sent: Friday, December 12, 2003 2:18 AM
#To: bbird@epik.net
#Cc: pr@isprime.com; ras@e-gerbil.net; juniper-nsp@puck.nether.net
#Subject: bgp config changes (was: autonomous-system N loops L)
#
#bbird@epik.net writes:
#
#> -----BEGIN PGP SIGNED MESSAGE-----
#> Hash: SHA1
#>
#> I also agree.
#>
#[...]
#> I was informed by JTAC, this is an "artifact of the design".
Since
#> JunOS creates an internal group structure, based on common
#> attributes/options that affect import policy, the peers can be
#> internally regrouped, so to speak.
#
#Just a correction. It is export policy. An operational group (as
#oposed to configuration template) must have a coherent export
policy.

Thank you for the correction. I now recall it pertaining to export
policies. But it still remains that neighbors, with unchanged
configurations, were being reset for one of the reasons you've
stated.

The reason I mentioned import policy, is because of an event that was
originally attributed to the behavior you've described. The policy I
changed on a neighbor, was a prefix-limit filter. And upon making
that change, I discovered other neighbors being reset. In the
configuration template, the prefix-limit is neither import nor export
policy. However, I equate this to a test condition on import, more
than an export policy. I was later advised, that this shouldn't have
occurred, and wouldn't if I upgraded to something newer (speaking
only of the prefix-limit).

#
#This is because BGP updates to a group are replicated among peer
group
#members, an export policy is evaluated only once. It is more than
just
#an implementation quirk. It is essential for scaling purposes.

This *might* make sense architecturally, based on scalability and
software design, etc. However, the operational inconsistencies
between the configuration template, and the operational group cause
unpredictable (or very difficult to predict) results. What I think
Juniper should do (outside of redesign that piece), is inform the
operator, when making changes to the configuration template. Let us
know which peers would be reset, as a result. This is deterministic,
at some level. Why not let the computer figure it out and tell us?
And, of course, notify prior to making the change, or give us a way
to test, as Richard S. pointed out.

#
#As far as sessions resets are concerned, you can always expect a
reset
#if you change a parameter that is negotiated on session
#establishement. Remember that the idea in JunOS is that the
#operational state should always reflect the config. i.e. JunOS
doesnt
#leave the session in a state that doesnt match the config. While in
#some cases the behaviour may be unexpected it has its advantages
#also.

This makes sense. And I can easily determine these conditions.
However, we are experiencing session resets to unchanged peers, where
the export policy changes made, cause no adjustment to parameters
negotiated on session establishment. This is for either the changed
or unchanged peers. Your paragraph below explains why.

#
#I agree that in some circumstances the behaviour is less than
#ideal. If you do change the export policy of the 1st (in config)
order
#peer of a group, the group is modified to follow the config you
apply
#to the 1st peer and the remaining peers in the group that do not
match
#its export policy are reset.

This behavior is almost unacceptable, in my opinion (not worth
much...I know). If re-tooling this to be more user friendly isn't
likely. Then, at least, tell the operator what is going to happen,
before it does. As I see it, the code knows which peers are going to
be removed from their groups and thus reset, as a result of the
changes about to be committed. But, I still don't see why the peer
needs reset, simply because of the bucket change, as long as session
negotiated parameters aren't affected. It seems like this is being
done just because.

#
#However if you deactivate the peer first and then modify its export
#policy this will not happen. I hope you can use that as a workaround
#while we don't get around to do something smarter in the code.

Let the software do this. Peers are going down either way. Why not
minimize impact. Having the default behavior reset the peer I am
changing, is much less shocking to the operator, than dumping other
seemingly unchanged peers.

#We have also been asked by several customers to document the current
#behaviour bettter...
#
# Pedro.
#

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBP9mC8NFQh6ARB7TZEQKOKQCfVKc7XGG94GT890WYVAhqshZqCB4An3y2
8HqNRq9AkEqydRlk6OlOcNWc
=Eh2C
-----END PGP SIGNATURE-----

On Thu, Dec 11, 2003 at 11:18:15PM -0800, Pedro Roque Marques wrote:
> As far as sessions resets are concerned, you can always expect a reset
> if you change a parameter that is negotiated on session
> establishement.

Correct, but JunOS resets sessions even if nothing of that kind
is changed.

Even simply changing the export chain of the first neighbor of
the group resets all other sessions. There is absolutely no technical
reason, nor "has its advantages". Actually, I'd flatly call it a
serious bug. So far, JTAC disagreed. See 2003-0121-068 for
a discussion on why we think that enabling/disabling global
"remove-private" must not reset all BGP sessions of a router.
ER6574 was opened to fix this, and PR31609 to better document the
current behavior. PR31609 was closed with no committed-in release
date, but current (JunOS 6.1) documentation still has no warning.

> However if you deactivate the peer first and then modify its export
> policy this will not happen. I hope you can use that as a workaround
> while we don't get around to do something smarter in the code.

Changing anything that does not affect BGP _session_ parameters
_MUST_NOT_ reset a session. Anything else is a bug and introduces
artificial downtime for customers which is technically not necessary.

> We have also been asked by several customers to document the current
> behaviour bettter...

See PR31609... :-)


Best regards,
Daniel

On Fri, Dec 12, 2003 at 03:56:51AM -0500, bbird@epik.net wrote:
>
> The reason I mentioned import policy, is because of an event that was
> originally attributed to the behavior you've described. The policy I
> changed on a neighbor, was a prefix-limit filter. And upon making
> that change, I discovered other neighbors being reset. In the
> configuration template, the prefix-limit is neither import nor export
> policy. However, I equate this to a test condition on import, more
> than an export policy. I was later advised, that this shouldn't have
> occurred, and wouldn't if I upgraded to something newer (speaking
> only of the prefix-limit).

Oooh, another good point. Honk if you miss Cisco's style of having
prefix-lists available seperately from route-maps. I for one sure do.

The ability to do prefix filtering in policy-statements is certainly a
good thing, no question there, but it is not a true replacement for the
equivilent of Cisco's "neighbor x.x.x.x prefix-list whatever" filtering.
Creating a policy-statement per customer and using route-filter statements
is nasty, and creates unnecessary complications for IRR based prefix-list
generation scripts.

You cannot use a Juniper "prefix-list" for this either, since jnpr's
prefix lists are actually... lists of prefixes... and don't let you do any
"orlonger" type processing. I always found this an incredibly annoying
damper in the otherwise handy ability to use use a prefix-list in a
firewall term, since you still have to duplicate the entire list in both a
policy route-filter list and a prefix-list...

My kingdom for a prefix-list which supports the route-filter type prefix
modifiers, and a "neighbor x.x.x.x prefix-list" statement...

--
Richard A Steenbergen <ras@nlayer.net> http://www.nlayer.net/
GPG Key ID: 0xDA93CCE6 (D8E1 B8DD 486F B161 FA92 C2C5 113E BA5E DA93 CCE6)
nLayer Communications, Inc. Chief Technical Officer

On Fri, Dec 12, 2003 at 08:40:52PM +0100, Daniel Roesen wrote:
>
> Changing anything that does not affect BGP _session_ parameters
> _MUST_NOT_ reset a session. Anything else is a bug and introduces
> artificial downtime for customers which is technically not necessary.

Here here... Or at the VERY least, give us some warning so we know to
expect a flap and have the option of holding a change until a maint window
or until any existing damping penalties expire.

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

> You cannot use a Juniper "prefix-list" for this either, since
> jnpr's prefix lists are actually... lists of prefixes... and
> don't let you do any "orlonger" type processing. I always
> found this an incredibly annoying damper in the otherwise
> handy ability to use use a prefix-list in a firewall term,
> since you still have to duplicate the entire list in both a
> policy route-filter list and a prefix-list...

An ER has been opened for this. It would allow a prefix-list to be
applied within a policy as 'from prefix-list foo orlonger'. This would
allow a single prefix-list to be used in a firewall and a policy and
have them both represent the "complete" subnets.

FWIW,
Joe

> -----Original Message-----
> From: juniper-nsp-bounces@puck.nether.net
> [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of
> Richard A Steenbergen
> Sent: Friday, December 12, 2003 4:18 PM
> To: bbird@epik.net
> Cc: Pedro Marques; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] RE: bgp config changes (was:
> autonomous-system N loops L)
>
>
> On Fri, Dec 12, 2003 at 03:56:51AM -0500, bbird@epik.net wrote:
> >
> > The reason I mentioned import policy, is because of an
> event that was
> > originally attributed to the behavior you've described.
> The policy I
> > changed on a neighbor, was a prefix-limit filter. And upon making
> > that change, I discovered other neighbors being reset. In the
> > configuration template, the prefix-limit is neither import
> nor export
> > policy. However, I equate this to a test condition on import, more
> > than an export policy. I was later advised, that this
> shouldn't have
> > occurred, and wouldn't if I upgraded to something newer
> (speaking only
> > of the prefix-limit).
>
> Oooh, another good point. Honk if you miss Cisco's style of
> having prefix-lists available seperately from route-maps. I
> for one sure do.
>
> The ability to do prefix filtering in policy-statements is
> certainly a good thing, no question there, but it is not a
> true replacement for the equivilent of Cisco's "neighbor
> x.x.x.x prefix-list whatever" filtering.
> Creating a policy-statement per customer and using
> route-filter statements is nasty, and creates unnecessary
> complications for IRR based prefix-list generation scripts.
>
> You cannot use a Juniper "prefix-list" for this either, since
> jnpr's prefix lists are actually... lists of prefixes... and
> don't let you do any "orlonger" type processing. I always
> found this an incredibly annoying damper in the otherwise
> handy ability to use use a prefix-list in a firewall term,
> since you still have to duplicate the entire list in both a
> policy route-filter list and a prefix-list...
>
> My kingdom for a prefix-list which supports the route-filter
> type prefix
> modifiers, and a "neighbor x.x.x.x prefix-list" statement...
>
> --
> Richard A Steenbergen <ras@nlayer.net>
> http://www.nlayer.net/
> GPG Key ID: 0xDA93CCE6 (D8E1 B8DD 486F
> B161 FA92 C2C5 113E BA5E DA93 CCE6)
> nLayer Communications, Inc. Chief
> Technical Officer
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/junipe> r-nsp
>

Richard A Steenbergen writes:


> Oooh, another good point. Honk if you miss Cisco's style of having
> prefix-lists available seperately from route-maps. I for one sure
> do.

So... if you define a policy statement w/ just one term, which is a
route-filter term that lists the prefixes and does accept/deny, what
is the difference between that and prefix-lists ?

You can include it in policy statements i.e. a policy can reference
another policy and you can include this via policy algebra in import
statements... i.e. you can have

neighbor 1.2.3.4 import [prefix-filter && generic-policy]

where prefix-filter is

policy-statement prefix-filter {
term a {
from {
route-filter 10/24 orlonger;
[...]
}
then accept;
}
then reject;
}

I see no difference between this and the cisco prefix-list behaviour.

Pedro.

On Fri, Dec 12, 2003 at 04:18:22PM -0500, Richard A Steenbergen wrote:
> You cannot use a Juniper "prefix-list" for this either, since jnpr's
> prefix lists are actually... lists of prefixes... and don't let you do any
> "orlonger" type processing. I always found this an incredibly annoying
> damper in the otherwise handy ability to use use a prefix-list in a
> firewall term, since you still have to duplicate the entire list in both a
> policy route-filter list and a prefix-list...

$ fgrep prefix-list vendor/juniper/JunOS-featurerequests
- "from prefix-list bla exact" && ""from prefix-list bla orlonger" etc.
- ability to use prefix-lists for snmp access control

:-$


Regards,
Daniel

On Fri, Dec 12, 2003 at 01:37:17PM -0800, Joe Soricelli wrote:
> An ER has been opened for this.

Nice! Hopefully one item on my feature-request list less soon. :-)

> It would allow a prefix-list to be applied within a policy as
> 'from prefix-list foo orlonger'.

Ideally, it should allow all the "exact", "orlonger", "longer" etc.
qualifiers.

> This would allow a single prefix-list to be used in a firewall
> and a policy and have them both represent the "complete" subnets.

Especially, it allows to use the same IRR-generated prefix list
to filter accepted prefixes from BGP customers (match exact), and use
the same prefix-list to accept more-specifics (match longer) for
remote-triggered blackholing or traffic engineering purposes and
treat them differently to the normal IRR-accepted prefixes.

Would be another step ahead IOS. :-)


Regards,
Daniek

On Fri, Dec 12, 2003 at 02:35:28PM -0800, Pedro Roque Marques wrote:
> Richard A Steenbergen writes:
>
>
> > Oooh, another good point. Honk if you miss Cisco's style of having
> > prefix-lists available seperately from route-maps. I for one sure
> > do.
>
> So... if you define a policy statement w/ just one term, which is a
> route-filter term that lists the prefixes and does accept/deny, what
> is the difference between that and prefix-lists ?
>
> You can include it in policy statements i.e. a policy can reference
> another policy and you can include this via policy algebra in import
> statements... i.e. you can have
>
> neighbor 1.2.3.4 import [prefix-filter && generic-policy]
>
> where prefix-filter is
>
> policy-statement prefix-filter {
> term a {
> from {
> route-filter 10/24 orlonger;
> [...]
> }
> then accept;
> }
> then reject;
> }
>
> I see no difference between this and the cisco prefix-list behaviour.

In the short term, because it annoys the hell out of scripts which try to
automatically manage the prefix-filter policy, and its application against
a specific neighbor. Specifically, it is difficult to use dynamic names
and make certain that the old name is removed and the new name is inserted
in the correct position and without serious fowlups in the event of a
human error on the import statement before the script begins.

But in the long term, because it is messy and not well organized. Yes I
know simplicity and elegance are not usually motivating factors in the
design of routers, but why not take the opportunity to kill two birds with
one stone and add the ability to re-use the same list in a firewall term
as well?

Prefix filtering is an almost universally common task. The simple and
elegant design is to define a list of prefixes, with modifiers which
include what type of more specifics to match, and then re-use that list by
reference where appropriate throughout the configuration. If you are
*certain* that the majority of the routers out are at some point going to
prefix-filter a neighbor, why make everyone write a policy-statement to do
it and then a lot of "import [ prefix-filter && generic-policy ]" mess,
when you can just put it in a logical place like "neighbor x.x.x.x
prefix-filter"?

Wouldn't it just be all around better (not to mention easier for the Cisco
converters AND more logical) if you could define:

prefix-list dynamicname {
10.0.0.0/24 orlonger;
10.1.0.0/24 orlonger;
}

And then apply it with:

neighbor 1.2.3.4 prefix-filter input dynamicname;

And match it in a firewall term with:

from prefix-list dynamicname;

Oh and before anyone says anything about "why do you need to match the
same list you've used in prefix-filtering in a firewall term, can't you
just use uRPF?", one of the specific applications I have seen for this
involves using IRR built packet filters to do source spoofing prevention
on BGP speaking networks. You can allow the customer to register all the
routes they will be sourcing from, even if you are not the best forwarding
path for whatever reason, and still limit source addresses to a much much
narrowing range than simply uRPF loose.

--
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 Sat, Dec 13, 2003 at 03:28:04AM +0100, Daniel Roesen wrote:
> On Fri, Dec 12, 2003 at 04:18:22PM -0500, Richard A Steenbergen wrote:
> > You cannot use a Juniper "prefix-list" for this either, since jnpr's
> > prefix lists are actually... lists of prefixes... and don't let you do any
> > "orlonger" type processing. I always found this an incredibly annoying
> > damper in the otherwise handy ability to use use a prefix-list in a
> > firewall term, since you still have to duplicate the entire list in both a
> > policy route-filter list and a prefix-list...
>
> $ fgrep prefix-list vendor/juniper/JunOS-featurerequests
> - "from prefix-list bla exact" && ""from prefix-list bla orlonger" etc.

You wouldn't want the ability to mix "exact" and "orlonger" or even a
specific range in the same prefix-list?

I do agree that putting it outside the prefix-list has some advantages
though. For example, one application which pops to mind that I've had
users hounding me about is the null route community, and the ability to
announce it on any IP in their set of registered routes all the way up to
a /32 without compromising the security of my network or others by
allowing /32s to be announced as "non-null route".

Thus you might have regular import for BGP routes which is done:

from prefix-list blah upto /24;

And then for null route community imports (which you would probably want
to set no-export, or say change next-hop to something aimed at a dsc
interface with a filter that automatically forwards of a policied amount
of packets over a pre-configured LSP to an analysis box for DoS tracking,
or any number of other things):

from prefix-list blah upto /32;

Personally I'd like to have the modifiers available both inside and
outside the prefix-list, with a value outside the list overriding.

> - ability to use prefix-lists for snmp access control
>
> :-$

On a completely unrelated subject, if you don't already have it (though
somehow I suspect you do :P), make sure to add automatically tuning prefix
limits which track the normal number of prefixes + some configurable
amount or percentage of burst, and block anything past that as "abnormal"
without the need to constantly scan peer prefix-limits adjusting for
growth.

>
>
> Regards,
> Daniel
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp

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