On Mon, 9 Nov 2015, Donald Sharp wrote:
From: Pradosh Mohapatra <[email protected]>
A fat tree topology running IBGP gets into two issues with anycast
address routing. Consider the following topology:
R9 R10
x x
R3 R4 R7 R8
x x
R1 R2 R5 R6
| | | |
10/8 10/8 10/8 S
Let's remind ourselves of BGP decision process steps:
1. Highest Local Preference
2. Shortest AS Path Length
3. Lowest Origin Type
4. Lowest MED (Multi-Exit Discriminator)
5. Prefer External to Internal
6. Closest Egress (Lowest IGP Distance)
7. Tie Breaking (Lowest-Router-ID)
8. Tie Breaking (Lowest-cluster-list length)
9. Tie Breaking (Lowest-neighbor-address)
Without any policies, steps 1-6 will almost always evaluate identically for
all paths received on any router in the above topology. Let's assume that
the router-ids follow the following inequality: R1 < R2 < R5 < R6. Owing to
the 7th step above, all routers will now choose R1's path as the best. This
is undesirable. As an example, traffic from S to 10/8 will follow the path
S -> R6 -> R7 -> R9 -> R4 -> R2 -> 10/8 instead of S -> R6 -> R7 -> R5 -> 10/8.
Furthermore, once R7 (& R8) chooses R1's path as the best, it would withdraw
its path learned through (R5, R6) from (R9, R10). This leads to inefficient
load balancing - e.g. R9 can't do ECMP across all available egresses -
(R1, R2, R5).
The patch addresses these issues by noting that that cluster list is always
carried along with the routes and its length is a good indicator of IBGP
hops. It thus makes sense to compare that as an extension to metric after
step 6. That automatically ensures correct multipath computation.
You're not the first to notice that Cluser-List is a monotonically
increasing metric with propogation and reflects the topology much better
than, say, router-id. See, e.g., Flavel and Roughan, who built on the
routing-algebra analysis work and noted Cluster-List could allow routes to
be consistently ordered, even in the face of routes with MEDs, and so
solve some oscillation issues, by moving Cluster-List up ahead of MED. I
saw their paper and tried to bring that to the attention of IDR, but
without much luck. See:
https://tools.ietf.org/html/draft-jakma-idr-stable-bgp-rr-00
Basically, if we're going to do this, I'd move Cluster-List up even
further to 4, because that provably eliminates any possibility of MED
oscillation too.
As the draft notes, certain uses of MED for internal steering would be
better done with a new iBGP attribute defined to be monotonically
increasing.
Unfortunately a partial deployment of this in a generic topology (note:
fat-tree/clos topologies work fine) may lead to potential loops. It needs
to be looked into.
This is a big big issue. Adding an option to change the metric evaluation
order per-node, without any cross-iBGP co-ordination in the protocol, is
guaranteed to lead to screw-ups - potentially hard/non-obvious to debug.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
The hardest thing in the world to understand is the income tax.
-- Albert Einstein
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
