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 <r...@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
