On Tue, 10 Nov 2015, Daniel Walton wrote:
Routing loops in BGP are typically caused when you have one node that is
forwarding down a path but is not advertising that path to his peers (ie
multipath scenario and the whole multipath-relax knob). The proposed
bestpath change does not cause that to happen....
Agreed, those kinds of routing loops won't occur.
I think it is a safe change.
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?
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.
That's not a good sign.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
"It ain't so much the things we don't know that get us in trouble. It's the
things we know that ain't so."
-- Artemus Ward aka Charles Farrar Brown
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
