On Wed, Dec 2, 2015 at 9:58 AM, Paul Jakma <[email protected]> wrote:
> 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.
>
Can you grab the "show ip bgp 10.7.0.0/24" from 192.168.145.3
and 192.168.145.2? They are the ones creating the aggregate.
> 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?
You don't, you just advertise the AS_PATH of the bestpath.
> 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.
To do as-path loop detection outbound though would be very expensive
because you would have to make the peer's ASN a factor in update-group
selection (today we consider if they are eBGP or iBGP but do not have to
take the actual ASN into account). This would cause us to have to create
many more update-groups which would hurt performance because we could not
do as much update replication.
Cisco has been doing this (TX the path back to the neighbor who sent it to
us) since update-groups went in...I never saw it create a loop.
Daniel
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
