On Wed, Nov 11, 2015 at 10:20 AM, Paul Jakma <[email protected]> wrote: > On Wed, 11 Nov 2015, Daniel Walton wrote: > > but quagga is doing this check earlier then I could see you getting into a >> situation similar to the one you describe below. So then you would need a >> bestpath knob that controls where in the decision algorithm this comparison >> happens. There are already so many knobs in bgp...this might be more >> trouble than it is worth (and confusing for the end user). >> > > Agreed on BGP already having way too many knobs to twiddle. :) > > How about a followup patch that provides a knob to disable this comparison >> in bestpath? >> > > Hmm, that still allows for operators to mismatch it and have subtle probs? > It took a long time for BGP engineers and academics to understand > oscillation and figure out how to provably prevent it. Most operators > probably would struggle to even recognise it if it happens, never mind > debug. > > I wonder could we add a capability to describe the routing decision steps > and their ordering, e.g. as a list of code-points (each code-point being > some recognised decision process), and refuse to connect when there is > divergence in the min(length(their list),length(our list)) initial set of > that list. (i.e. it doesn't matter if one speaker implements additional > tie-breakers, as long as both are agreed on the sequence before that). > > That would let changes to the decision ordering be made and rolled out in > a planned fashion, without risk of undetected weird problems, at least.
That is a much much bigger can of worms that would have to go through IETF which can take a really long time. Donald and I were chatting about this....I think we are overcomplicating this knob: - We've had this behavior for 2 years and have not had any customers hit any issues with it - On the off chance that the stars aligned and a prefix oscillated back and forth between A--B one could always set local-pref, origin, etc (any attribute that is compared earlier than cluster-list length) to stabilize that prefix. I think the odds of that happening would be slim though, just because the IGP cost to the nexthop would likely cause A to always choose the E path. So we can avoid adding a new knob and we already have a way to work-around this corner case scenario. Daniel
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
