>
> The other issue is where path weights evaluate non-transitively in
> preference pairwise (or other subset) - even if there is a well-defined
> prefered route when evaluated collectively. Non-full mesh topologies, i.e.
> reflection, can lead to non-transitive sub-set preference evaluations and
> oscillation.
>
> E.g. where you have paths A,B,C. A may be preferred from {A,B,C} and
> {A,B}, B from {B,C}, but C from {A,C}. Combined with reflectors, where each
> reflector may have only a partial view, such non-transitive preferences can
> lead to oscillation.
>
> Raising cluster-list above the ID checks is quite safe if done in concert,
> as each check has a clear, transitive, partial ordering at all nodes.
>
> (Further, cluster-list is monotonically increasing with path distance,
> Flavel and Roughan have noted and shown, based on Sobrinho's routing
> algebra work, that this then guarantees stably converging iBGP, if raised
> above MED. Including in scenarios where BGP topology and IGP are not
> aligned).
>
> The question then is, can raising cluster-list above the router-ID cause
> issues if not done in concert - i.e. introduce any non-transitivities into
> the preference ordering that weren't there before?
>I would think so, if you have one implemenation checking cluster-list length at the second to last step: http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html 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). > E.g. if it comes down to stage 6 (stage 11 in Quagga's code) then it > possible that the originator-ID check prefers C. I'd hesitate to claim that > the preferences always remain transitively ordered. Take: > > -A---B- > > We just need B to be updated, to eval cluster-list length first, and for > there to be clients to the left past A whose cluster-list length is shorter > than any clients to the right past B, while A prefers originator-id first > and such a client is past B. > > E.g. C and E send in an adv for some prefix to reflectors A and D, with B > in between: > > E-A---B--X-Y-C > > B is updated with the new patch. > > 1. A chooses E, B chooses XYC - they advertise > > 2. A chooses XYC from E,XYC based on originator-id C; withdraws E from B > 2. B chooses E from E,XYC based on CL length; withdraws DC from A > > 3. A chooses E, B chooses XYC - they advertise > > That one's a bit racy and depends on them advertising and processing going > at the same rate. They may well happen to fall into a stable state if > there's any mismatch. However, it doesn't seem inherently stable, and could > from stability still go back to instability after a routing event. > Good point....this looks very similar to MED oscillation. How about a followup patch that provides a knob to disable this comparison in bestpath? Daniel
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
