[c-nsp] Add-Path Selection on IOS-XE (maybe also on other platforms)

Robert Raszuk robert at raszuk.net
Mon Oct 29 19:31:29 EDT 2018


Have you considered just using Diverse Path from both RRs instead of
add-paths ? RFC 6774

That way you will have two paths not 4 on the clients and no problem you
are facing :-)

Cheers,
R.


On Tue, Oct 30, 2018 at 12:25 AM Christian <plymouth78 at gmail.com> wrote:

> Hi list,
>
> considering my following situation, which seems to me pretty ordinary:
>
> Two RRs responsible for a domain of iBGP clients.
>
> Two iBGP clients share for redundancy reasons the same customer via eBGP,
> sometimes also by other protocols or even just statics/connected networks
> of customers.
>
> Now when those RRs receive and send all possible paths to all iBGP clients,
> each customer is represented with four prefixes on the receiving client:
> two next-hops, and two RRs = four paths.
>
> Now, the problem is that I can't figure out how to install a proper backup
> path. The paths are redundant in terms of next-hop, yes. But they are not
> in terms of the Route-Reflector. This means that both, the best
> and backup/repair path are both used from the RR with the smaller IP
> address. Consequently, when a RR fucks up or just in case you need to flap
> the BGP sessions by adding/remove address-families for example, there is no
> fast convergency, as both paths from the same RR are programmed in the FIB
> while prefixes learned from the remaining RR session are not programmed.
>
> Is there any mechanism I'm apparently missing to make the criteria of
> redundant advertiser/RR also a criteria of redundancy/PIC?
>
> In case that this is not considered in IOS, what is an alternative approach
> to make use of add-path by considering this?
>
> Thanks / Kind regards
> Chris
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


More information about the cisco-nsp mailing list