Advertising multiple paths per prefix to a peer means that the peer must maintain more entries in its RIB-IN than would be the case without add-path. The memory and CPU resources associated with these extra paths may not be justified if the peer cannot take advantage of them. Operators may therefore want precise control over the number of paths per prefix to send to particular peers.
The new add-paths CLI node (BGP, group or neighbor level) has address family-specific commands to set the maximum number of paths to send per prefix.
To ensure routing consistency in cases where an add-path speaking router has a mix of add-path and non add-path peers and where the number of paths to send for a particular prefix can vary by add-path peer, the following behavior should be enforced: if the advertising router advertises n paths for prefix XYZ to peer1 and m paths to peer2, and n < m, then all the paths advertised to peer1 must be included in the paths advertised to peer2. Suppose the LOC-RIB has N paths for prefix XYZ. The preceding behavior can be guaranteed if:
the N paths are sorted in strict order of their preference by the BGP decision process: p1 (overall best path found during step 1 of BGP decision process with ADD-PATH), p2, p3, …, pN (a path found during step 2 or 3 of BGP decision process with ADD-PATH)
p1 (only) is advertised to non add-path peers, add-path peers that indicate a send-only capability and add-path peers for which the configured path-limit is 1
(p1, p2) is advertised to add-path peers for which the configured path-limit is 2
(p1, p2, p3, …, pN) is advertised to add-path peers for which the configured path-limit is N, or else the path-limit is configured as max (default)