nanog mailing list archives

Re: Juniper M120 Alternatives


From: Paul Cosgrove <paul.cosgrove.nanog () gmail com>
Date: Wed, 18 Nov 2009 14:04:17 +0000

On Tue, Nov 17, 2009 at 5:32 PM, Richard A Steenbergen <ras () e-gerbil net>wrote:

On Tue, Nov 17, 2009 at 09:24:24AM -0600, Jack Bates wrote:
Richard A Steenbergen wrote:
They've definitely been improving it over the years though, so much that
I almost never trigger a session reset on me unintentionally any more.

They must have. This was new to me and came as a shock. I don't think
I've ever seen my m120 behave any different than my cisco when it comes
to flapping BGP. Things have just worked as I expected them to. Not that
I go screwing with underlying interface configs or changing a peer from
one group to another or changing the asn; at least not on a live
session. These things would seem to indicate that the session might be
subject to reset.

Perhaps it just behaves for normal users and not power users. :)

But those things won't trigger session resets on Cisco, so it often comes
as a shock. Also, one might very well expect that changing the peer-as on
a neighbor is going to cause a reset, but if you didn't know from
experience you might not expect that renaming a group or changing an
underlying interface MTU would do it too.

The issue is that there is a fundamental design difference between Cisco
and Juniper. Cisco lets you configure anything you want in a line by line
basis, but it doesn't immediately apply those changes until you command
it to do so. Juniper's philosophy is that you make a bunch of changes to
a candiate configuration, "commit" to apply those changes, and then you
can expect those changes to take effect (or at least begin trying to take
effect) immediately.

Personally I think the Juniper design philosophy is "better". Besides the
obvious stuff like being able to rollback your config, think about how
non-deterministic it is when you update a route-map but forget to soft
clear the BGP session. The routes that have been exchanged so far will
retain their old policy, while any new updates you receive after the
route-map change will receive the new policy, leaving the session in an
inconsistent state that will slowly and unpredictably change over time as
routing updates come in. The trade-off is that you lose the ability to do
non-impacting changes, where you make a change but know that it hasn't
actually taken effect yet, and won't until the next time the session
bounces. What Juniper is trying to do really is a good thing, I just wish
it could tell me before I commit what is and isn't going to flap. :)



The design differences you describe there relate more to traditional IOS vs
JUNOS, rather than IOS XR vs JUNOS.  IOS XR uses candidate configurations,
commit, rollback etc.

Paul.


Current thread: