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/
