On Wed, 2 Dec 2015, Donald Sharp wrote:
Paul -
I believe that this patch should fix your issue:
https://github.com/CumulusNetworks/quagga/commit/f4eeff72d5be6c1065f11face168a4bcd832de78
From my notes it should apply cleanly to master.
Hmm, with this patch it's still not converging, still choosing strange
next-hops and still unstable.
On 4:
*= 10.1.0.0/24 192.168.145.5 0 64565
{64561,64563,64567} i
* 192.168.145.6 0 64566 64567 64561 i
*= 192.168.145.2 0 64562 64561 i
*> 192.168.145.3 0 64563 64561 i
Still advertising an aggregate via 5. ???
A while later:
*= 10.1.0.0/24 192.168.145.2 0 64562 64561 i
*> 192.168.145.3 0 64563 64561 i
I think at least the aggregation it's doing is screwed up (the as-path
aggregation code has a good few unit tests and does reliably detect common
AS_PATH prefixes and aggregate everything there-after, AFAIK).
On the code, the curreny approach should work surely?
It scanned through and built a multi-path list. Clearing the list if a new
route was better than the prior. Adding routes to that list that info_cmp
indicated were equal or better.
That /should/ work if there's an order over the routes. Which there should
be, if we exclude non-deterministic preference checks (e.g.
already-selected) or badly defined attributes (MED - not involved here),
the previous best_selection approach /ought/ to have worked. So it should
work in this test-case, at least.
There seems to be a deeper problem here in the mpath code, certainly
affecting at least the relaxed case where it seems to be mixing stuff up
regardless of what the higher level route-selection stuff is doing (???).
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
I'm not offering myself as an example; every life evolves by its own laws.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
