ras at e-gerbil
Nov 16, 2009, 8:46 PM
Post #16 of 24
(1767 views)
Permalink
|
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 [at] e-gerbil> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
|
