Route Reflectors, Non-Client Peers and an Unresolvable Next Hop

This is reflection scope, not a filter. A route reflector follows two rules: a route received from a client is reflected to all other clients and to all non-clients; a route received from a non-client is reflected only to clients, never to other non-clients. Non-clients are assumed to have a direct iBGP session to every other non-client in the AS - that is the definition of a non-client in the original design, where clients are the only routers relieved of the full mesh.

BR-1 is a non-client of both RRs. Its route is reflected to the fourteen clients and stops there. BR-2 and the eight aggregation PEs never see it, and because no direct iBGP session exists between BR-1 and BR-2 (the setup states none), the route cannot hop between non-clients either. The default route is doing exactly what it should: covering a hole.

Options:

1. Make the ten PEs clients of both RRs. Simplest and most scalable, at the price of a larger client set on the RRs - the exact cost the design was trying to avoid. Two RRs with 24 clients each is small by any modern standard, and this is the recommendation.
2. Build a full mesh among the ten non-clients. 45 sessions maintained by hand, and it must be extended every time a PE is added, which is precisely the operational debt route reflection exists to remove.
3. Add a third RR pair dedicated to the non-clients, or keep one border as a client of the other. Both work but add topology to reason about.

Do not treat this as a bug in the RRs. Check the reflector's view with show router bgp routes 198.51.100.0/24 on the RR and confirm the route is present and unmodified - the missing advertisements are not policy-dropped.

The route is present but unusable: BGP has received it with next hop 10.0.0.25, and next-hop resolution fails because 10.0.0.25 is not in the IGP database. BGP does not tunnel next hops over the session that carried the route - it asks the routing table for a route to the next-hop address, and gets nothing. The route stays in RIB-In and is marked as not usable rather than dropped, which is why it looks 'there' in a listing but absent from the route table and never forwarded to the FIB.

There is a second, quieter clue: the session itself is up because it runs over a directly connected link, so nothing in the session state suggests a problem. Session-up is not reachability.

Fixes, in order of preference:

1. Put 10.0.0.25 into the IGP (or the IGP for its area, with redistribution if PE-25 is in a stub area). This is the correct fix, since a PE system address that is not routable across the backbone will cause the same failure for LDP/RSVP, VPN next hops and every service that resolves to it.
2. Configure next-hop-self on the RRs' client-facing group as a temporary measure. Every client then resolves the next hop as the RR's own loopback, which is in the IGP. The side effect is that all reflected routes appear to come from two next hops, which destroys IGP-cost-based exit selection and creates a false dependency on the RRs' forwarding path - a design change, not a patch.
3. A static route on the clients is a trap: it removes the symptom and leaves a PE that no other protocol can reach.

Confirm the diagnosis with show router route-table 10.0.0.25 on a client, then show router bgp routes 10.25.0.0/16 detail to see the next-hop validity flag.

By default a route reflector advertises only its best path for a prefix to a given peer (after applying its own policy). A client therefore receives one path per prefix from each RR, and if that path dies at the far end the client learns nothing until the withdrawal propagates - the backup path was never sent. With two RRs a client holds at most two paths, and if both RRs select the same best path, it effectively holds one.

The mechanism is BGP Additional Paths (RFC 7911). SR OS supports add-paths with send/receive capability negotiated per address family, so the RR advertises more than one path for a prefix and the client can keep a real backup. Two things to get right:

• Negotiation is symmetric in practice. The receiver must be willing to accept additional paths; enabling send on the RR and leaving receive off on the client produces nothing, and the session will simply not negotiate the capability. Roll it out on both ends, family by family.
• Scope it, do not open the tap. Advertising every path for every prefix multiplies RIB-In on clients and CPU on the RRs. Use a policy on the RR to send a limited number of additional paths (typically one or two, and preferably only for prefixes that matter), and check memory and update rates on the RR before and after.

Also verify the failover actually happens: kill the primary next hop and confirm the client installs the backup without waiting for the RR to withdraw anything. If the client still has to wait for a withdrawal, add-paths is not negotiated, and the capability check in the session detail output will say so.