Mailing List Archive: add-path on XR

Hi everyone,

I am currently looking at getting BGP info from routers for different
purposes. The servers (iBGP, RR-client) should see more than just the
best-path, so simply enable add-path for this neighbor, right?

On JunOS (where I have done something like this before) you can simply
set the number of paths the neighbor should receive:

> set [...group/neighbor/afi...] add-path send path-count 6

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

So that looks like it enables the capability for all iBGP peers, and in
the process resets all sessions? (yay, fun) But there is no
configuration per neighbor. Am I missing something?

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?

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

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

Thanks,
Sebastian

_______________________________________________
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/

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/