Mailing List Archive

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


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

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?!

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

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.

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.

-Sebastian


[1]
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/217097-bgp-path-selection-in-ios-xr.html
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Very old thread, but I was digging around and found it, so thought I'd
answer, in case no one did:

On 5/10/22 13:27, Sebastian Neuner wrote:

> But on IOS XR, I can only find global options to enable the capability
> and set a general limit for the number of paths, like this:
>
>> router bgp 65000
>>  address-family ipv6 unicast
>>   additional-paths send
>>   maximum-paths ibgp 6

"maximum-paths" only applies to Multipath, not Add-Paths.


> So that looks like it enables the capability for all iBGP peers, and
> in the process resets all sessions? (yay, fun)

Add-Paths is a non-default capability. If it has not been previously
enabled, the session is torn down so it can be negotiated with the neighbor.


> But there is no configuration per neighbor. Am I missing something?

To support the capability, that is at the AF level.

After IOS XR 7.3.1, per-neighbor level is supported for path selection.
But the capability remains at the AF level, AFAICT.


>
> There are some knobs in the route-policy. I found stuff like
>
>> route-policy monitoring-out
>>   set path-selection all advertise
>
> But how does that work? Do all iBGP neighbors without "path-selection"
> options in their out-policy continue to only receive the best path?
> And the monitoring-servers receive "maximum-paths"-many paths?

It means that for any neighbors who are advertising their ability to
receive additional paths, you will be able to send them all available
paths with that policy.


>
> Would configuring that still reset all iBGP neighbors? Or just the
> ones where the policy sets "path-selection" parameters?

No. Path selection policies and their advertisement does not reset BGP
sessions. BGP sessions are only reset when you need to negotiate
Add-Path capability exchange.


>
> And why is the documentation for those products of the last few years
> in general such a catastrophe?

I'm guessing most people don't use Add-Paths as much as they do
Multipath, so perhaps why.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/