On Tue, Nov 17, 2009 at 01:28:06AM +0100, Daniel Roesen wrote:
PS: and of course JUNOS still undeterministically resetting unrelated BGP sessions for no good reason when modifying BGP configuration - so one is well-advised to do ANY configuration changes in the area of BGP within a maint window as it might happen that you configure a peering session and whoops there goes your IBGP mesh... or all your other peerings, or, ...
Well to be fair, the session resetting on config change behavior is actually quite deterministic (being EASY to determine is not part of the requirements, technically speaking :P), and most of the resets really do have perfectly good reasons. I'll certainly go with "really annoying and often a giant pain in the @#$%^&*" though. 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. The things to watch out for are: a) any time you change the update replication by moving a neighbor between groups, renaming groups, or significantly changing the export policy chain. b) any time you change a major part of the underlying interface configuration for an eBGP session, such as mtu or vlan tagging config. c) any time you change something about the bgp session which really does require a session reset to take effect, such as a new ASN, new endpoint address, new mbgp family configuration, new md5 password, new tcp mss, etc. You can actually safeguard yourself from a lot of the accidental reset behaviors while implementing other features at the same time by using commit scripts (i.e. as a side-effect of my scripts which exist for other reasons, I automatically protect myself against changes to the policy chain or family configuration which might cause unintended session flaps), though I'll certainly admit this is well into the category of "power user" and not appropriate for most people. They are making some progress though, you can actually turn NSR on and off now without flapping your sessions, which is certainly an improvement over the serious logic flaws in earlier versions (where you couldn't turn off NSR without flapping every session, but you also couldn't commit w/NSR enabled and the backup RE offline, effectively locking you out of config changes without a total box flap if you didn't have both RE's running). It would certainly be a lot more user friendly if they could tell you what sessions would be reset as part of a "commit check" process though. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)