Juniper M120 Alternatives

Tue Nov 17 17:32:47 UTC 2009

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

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)