>
> # 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.
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.
> 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.
Daniel
> So, in terms of the advertised routes and deciding who to advertise a
> route onto, it is taking only the 'best' path via 6 into consideration.
>
> Does this make sense to anyone? It seems seriously borken to me...
>
> Also, the mpath code probably should have been implemented using the
> existing aggregation code...
>
> regards,
> --
> Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
> Fortune:
> I have discovered the art of deceiving diplomats. I tell them the truth
> and they never believe me.
> -- Camillo Di Cavour
>
> _______________________________________________
> Quagga-dev mailing list
> [email protected]
> https://lists.quagga.net/mailman/listinfo/quagga-dev
>
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
