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