On Wed, 2 Dec 2015, Daniel Walton wrote:
# sh ip bg 10.7.0.0/24
BGP routing table entry for 10.7.0.0/24
Paths: (4 available, best #4, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
192.168.145.2 192.168.145.3 192.168.145.6
64563 {64561,64562,64565,64567,64568}
192.168.145.3 from 192.168.145.3 (192.168.145.3)
Origin IGP, localpref 100, valid, external, multipath
Community: 64563:1
Extended Community: RT:64561:1 RT:64562:1 RT:64563:1 RT:64565:1
RT:64567:1 RT:64568:1 SoO:64561:2 SoO:64562:2 SoO:64563:2 SoO:64565:2
SoO:64567:2 SoO:64568:2
Last update: Wed Dec 2 09:55:33 2015
64562 {64561,64567,64568}
192.168.145.2 from 192.168.145.2 (192.168.145.2)
Origin IGP, localpref 100, valid, external, multipath
Community: 64562:1
Extended Community: RT:64561:1 RT:64562:1 RT:64567:1 RT:64568:1
SoO:64561:2 SoO:64562:2 SoO:64567:2 SoO:64568:2
Last update: Wed Dec 2 09:55:32 2015
64566 64567
192.168.145.6 from 192.168.145.6 (192.168.145.6)
Origin IGP, localpref 100, valid, external, multipath
Community: 64566:1
Extended Community: RT:64566:1 RT:64567:1 SoO:64566:2 SoO:64567:2
Last update: Wed Dec 2 09:53:32 2015
64565 64567
192.168.145.5 from 192.168.145.5 (192.168.145.5)
Origin IGP, localpref 100, valid, external, multipath, best
Community: 64565:1
Extended Community: RT:64565:1 RT:64567:1 SoO:64565:2 SoO:64567:2
Last update: Wed Dec 2 09:53:03 2015
That looks like it's multipathing over /all/ the paths to 7, including the
longer 3-hop paths. Also, the aggregates don't really make sense, do they?
The AS_SET only counts as 1 hop though (no matter how man ASNs are in
it) so "64563 {64561,64562,64565,64567,64568}" and "64566 64567" both
have an as-path length of 2.
Sure, the aggregate has an AS_PATH length hop of 2 - that's not the issue.
The issue is the mpath aggregate seems to include the paths 2 and 3
judging by the left-most AS and the 'from...' - which are the 3-hop paths.
I can't look at zebra, cause I'm running multiple bgpds, but I'm guessing
this means bgpd would have installed a route with 2 and 3 as nexthops.
Now, I know some people who are interested in non-shortest-path
load-spreading, but I didn't think this patch was supposed to implement
that.
Though, that means it transmogrifies the original routes, rather than
creating a new one and suppressing the sub-routes (as aggregates might
do)? Hmm...
On a related note, quagga's behavior to create an AS_SET as a result of
using multipath is problematic. We've seen some cases where resetting
the as-path length in the middle of a clos topology causes routes to
flap. They are more recent patches but we have patches to flip this
behavior but with a knob to enable the old behavior should the customer
want to generate the as-set.
How else would you include the ASes being aggregated in the AS_PATH,
without changing the length?
It is advertising this aggregate back to the neighbours from whose routes
the aggregate was constructed:
# sh ip bgp neighbors 192.168.145.2 advertised-routes *> 10.7.0.0/24
192.168.145.4 0
{64561,64562,64563,64565,64566,64567,64568} i
# sh ip bgp neighbors 192.168.145.3 advertised-routes
*> 10.7.0.0/24 192.168.145.4 0
{64561,64562,64563,64565,64566,64567,64568} i
# sh ip bgp neighbors 192.168.145.5 advertised-routes
# sh ip bgp neighbors 192.168.145.6 advertised-routes
*> 10.7.0.0/24 192.168.145.4 0
{64561,64562,64565,64566,64567,64568} i
I would say this is expected, we don't do outbound as-path filtering
(there is a #define to enable it though) because the other side may have
"allowas-in" configured.
Bit dangerous though. If for any reason the other side doesn't drop it
(their configuration, or someone patches Quagga to get rid of the AS_SETs
say...), we may get loops.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
That's the thing about people who think they hate computers. What they
really hate is lousy programmers.
- Larry Niven and Jerry Pournelle in "Oath of Fealty"
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev