Juniper M120 Alternatives

Paul Cosgrove paul.cosgrove.nanog at
Wed Nov 18 14:04:17 UTC 2009

On Tue, Nov 17, 2009 at 5:32 PM, Richard A Steenbergen <ras at>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.


More information about the NANOG mailing list