Mailing List Archive

On Wed, Feb 25, 2004 at 09:46:33PM -0500, Richard A Steenbergen wrote:

: 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.

It has become the standard way of thinking to apply prefix limits to
the "accepted routes" not to the "received routes" ala brand C's way
of doing things. This has merit as a way to not break the Internet,
but does little to stop the customer/peer from breaking your own
router. So.. I would say that Juniper is lacking in a feature to
stop the Internet from breaking, but has enhanced their software
feature set over that of Cisco by implementing a way to protect the
router.

What should they do? -- Give us both.

I would love to set max accepted prefix on a customer to 20% that of
the count of routes in their prefix-list, while setting the received
prefix limit to 200% of that count.

This would save my router from massive memory consumption, while
allowing the customer to announce a sane number of usable routes.

If I set the current Juniper method to 20% above my customer and he
gets knocked down when my router is not affected I am not providing
quality service. My customer pays me for connectivity, not to be a
nazi about his momentary sending me 100 extra routes which I'm not
even accepting anyways.


: 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 personally don't like this idea/would not use it, but if others
find it useful, then by all means, request it as a feature.

: Food for thought at any rate.

Absolutely.

--mikeb

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

--
Mike Benjamin = mikeb@mikeb.org

On Thu, Feb 26, 2004 at 08:58:59AM -0800, Pedro Roque Marques wrote:
> 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,

WHY a reset? NOTHING regarding session parameters changed when the
export chain is modified!

> and the unchanged neighbors will stay up.

OK, so we're halfway thru. :-)


Regards,
Daniel

dr@cluenet.de (Daniel Roesen) writes:

> On Thu, Feb 26, 2004 at 08:58:59AM -0800, Pedro Roque Marques wrote:
> > 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,
>
> WHY a reset? NOTHING regarding session parameters changed when the
> export chain is modified!
>

I'm not sure that you really want to have an answer as to the question
"why a reset"... but i'll assume you'd like to understand the rational
behind it.

All peers in a group share rib-out entries. When you split a group by
modifying export policies rib-out entries are no longer applicable to
both groups... the new group needs to create new rib-out entries, and
the old ones are no longer valid.

The complexity of implementing this results in a rather non trivial
exercise.

In terms of the overall reliability of the application, you most
likely get a better result out of predictable session resets than
unpredictable rpd crashes as result of the added complexity.

While from a provider point of view, i understand that you may wish to
have the system handle configuration changes w/ minimum disruption
possible, there is a cost to it.

JunOS(*) current choice is torwards one set of tradeoffs. You are
welcome to agree or disagree w/ it, but it is a rational choice that
is made. As with all engineering choices it has advantages and
drawbacks.

regards,
Pedro.

(*) Not that anyone needs to be reminded, but... i don't speak for
Juniper, much less in this mailing list. This just represents my
current understanding, which may be flawed.

On Thu, Feb 26, 2004 at 07:23:39PM -0800, Pedro Roque Marques wrote:
> While from a provider point of view, i understand that you may wish to
> have the system handle configuration changes w/ minimum disruption
> possible, there is a cost to it.

Pedro,

I think that there is something that is important to
insure is properly represented here.

There are a large number of vendors that are offering
"high availability", as well as a number of redundancy features.

i think that as one views the need to result with
a stable network, the disruptive nature of BGP resets
works against network stability.

I think that as we need routers to have ever increasing
stability and uptimes, the need to avoid some disruptive behaviour
within software will become more of a "market force". This
is just my $.02, but I suspect others will agree with me here.
(See the current nanog discussions about the internet as
critical infrastructure, and how reliable must it be, etc..)

- jared

> JunOS(*) current choice is torwards one set of tradeoffs. You are
> welcome to agree or disagree w/ it, but it is a rational choice that
> is made. As with all engineering choices it has advantages and
> drawbacks.
>
> regards,
> Pedro.
>
> (*) Not that anyone needs to be reminded, but... i don't speak for
> Juniper, much less in this mailing list. This just represents my
> current understanding, which may be flawed.

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