[119404] in North American Network Operators' Group
Re: Juniper M120 Alternatives
daemon@ATHENA.MIT.EDU (Paul Cosgrove)
Wed Nov 18 09:05:41 2009
In-Reply-To: <20091117173246.GE51443@gerbil.cluepon.net>
Date: Wed, 18 Nov 2009 14:04:17 +0000
From: Paul Cosgrove <paul.cosgrove.nanog@gmail.com>
To: Richard A Steenbergen <ras@e-gerbil.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
