[c-nsp] add-path on XR

[Mark Tinka]

On 9/9/22 11:06, Sebastian Neuner via cisco-nsp wrote:

>
> Hi all,
>
> I got no replies and that might be because nobody cares, or it might 
> be because nobody knows how to do it on XR. Googling for something and 
> finding posts without solution is always annoying, so here's what I 
> found. This is all on 7.5.2.
>
>> route-policy monitoring-out
>>  set path-selection all advertise
>> end-policy
>
> => can't be attached at the neighbor-out attach point

Possible since IOS XR 7.3.1, but convoluted. See here:

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/217097-bgp-path-selection-in-ios-xr.html#anc16


> You can use "destination" to filter for the destination prefix, but 
> you can also use it to match a path type (best, backup, multipath, 
> all), like this: "if destination is-best-external then ...". Not sure 
> why they chose a syntax with two meanings for "destination". Weird.
>
> But: you can only advertise paths to neighbors that are marked for 
> RIB-out. You can set a policy with "set path-selection all advertise" 
> to mark all paths for RIB-out:
>
>> router bgp X
>>  address-family ipv6 unicast
>>   additional-paths send
>>   additional-paths selection route-policy send-all-paths
>
> As soon as a neighbor negotiates the capability (neighbor has 
> "receive" enabled), it will receive *all* paths by default, for all 
> the prefixes you advertise. To filter this, you'd have something like 
> this in your neighbor-out policy:
>
>> route-policy CUSTOMER-out
>>   if destination is-all then
>>     drop  # "is-all" matches all *additional* paths, not the best-path
>>   else
>>     pass
>>   endif
>> end-policy 

Yes, very convoluted compared to IOS XE and Junos.

The only IOS XR boxes in our network are a handful of ASR9001's that are 
promptly being replaced the the Juniper MX204.

I sent all available paths to those ASR9001's, equipped with 8GB of RAM, 
and they ran out of ideas at 4,000,000 routes RIB.


>
> Weird design choices all over the place IMO. But that might be just 
> me. Is it a Cisco-thing to always advertise everything to everyone by 
> default?!

Not in IOS XE.

But the IOS XR setup is a lot more convoluted, that's for sure. But it 
appears to be possible to constrain this with some clever RPL work.


>
> So what if you want to advertise add-paths only to specific peers? I 
> know, I know, very rare use case.

The BCP makes this a requirement, even if it may be rare.


>
> You can advertise the capability to all neighbors and filter 
> ("destination is-all") in all neighbor-out policies where you don't 
> want it. But that's a lot of work and changes, it's complex, and error 
> prone.

Agreed.


> The good news is: you can send the capability to specific neighbors 
> and don't have to change filters for the others. But not how you'd think.
>
> So, if we can enable it globally under the address-family, we might 
> enable it for just one neighbor? What do you think this does?
>
>> router bgp X
>>  neighbor X
>>   address-family ipv6 unicast
>>    additional-paths send
>
> Wrong, this doesn't exist.
>
> Sooo, the next one exists, but what does this do?
>
>> router bgp X
>>  neighbor X
>>   capability additional-paths send
>
> Wrong, it doesn't do anything. At least in my lab it did nothing. 
> Maybe I held it wrong? Maybe it's a bug? Idk.
>
>> router bgp
>>  neighbor X
>>   capability additional-paths send disable
>
> Now this one disables advertising the capability for this neighbor and 
> address-family... idk? All? Probably all.
>
> So you can globally enable "additional-paths send" and disable it for 
> every neighbor (or in a neighbor-group, which might be convenient).
>
> All in all this one-liner in JunOS translates to something like that 
> on my IOS XR boxes:
>
>> router bgp X
>>  address-family ipv4 unicast
>>   additional-paths send
>>   additional-paths selection route-policy add-path-selection
>>  address-family ipv6 unicast
>>   additional-paths send
>>   additional-paths selection route-policy add-path-selection
>>  neighbor-group ibgp
>>   capability additional-paths send disable
>>  neighbor-group ebgp
>>   capability additional-paths send disable
>>  neighbor X
>>   ! no "use neighbor-group ibgp" here!
>>   description Looking Glass
>>
>> route-policy add-path-selection
>>   set path-selection all advertise
>> end-policy
>
>
> To find all this info, I needed to read the documentation, which is 
> pretty much non-existent, open two TAC cases, read a troubleshooting 
> guide[1] which is actually documentation and not a troubleshooting guide.
>
> IMO several weird design choices combined with a lack of documentation 
> makes this pretty frustrating. The good news is: nothing of this will 
> reset neighbor sessions and you can manually clear them to renegotiate 
> capabilities whenever.
>
> Hope this saves someone a headache.

How did you get on, in the end?

Mark.