22 Route Reflectors

Route Reflectors (RR) solve the iBGP full-mesh scalability problem. A route reflector is allowed to break the iBGP split-horizon rule in a controlled way, re-advertising (reflecting) routes between iBGP peers so a full mesh is no longer required.

The problem they solve

The iBGP split-horizon rule (note 09) says a route learned from one iBGP peer is not re-advertised to another iBGP peer, which forces a full mesh that grows as n(n-1)/2. A route reflector is permitted to reflect routes between iBGP peers, eliminating the need for full mesh.

Roles

• Route Reflector (RR): the router configured to reflect routes.
• Client: an iBGP peer that the RR reflects for. A client does not know it is a client; it needs no special configuration. Only the RR designates who its clients are, using neighbor <ip> route-reflector-client.
• Non-client: an ordinary iBGP peer of the RR that is not a client. Non-clients still peer in a full mesh among themselves and with the RR.

The three reflection rules

• A route learned from a non-client iBGP peer is reflected only to clients.
• A route learned from a client is reflected to all clients and non-clients, except the client that originated it.
• A route learned from an eBGP peer is reflected to all clients and non-clients.

A consequence: two non-clients do not receive each other’s routes through the RR (the RR does not reflect between non-clients), so non-clients still need direct peering among themselves.

Topology flexibility

• A cluster can have more than one RR, for redundancy (avoiding a single point of failure).
• An RR can itself be a client of another RR (hierarchical / nested RRs, for large designs).
• Non-clients can exist alongside clients within the same environment.

Loop-prevention attributes

Because the RR breaks split-horizon, and AS-PATH does not change inside the AS, two attributes were created to prevent loops:

• Originator ID: added by the RR, set to the Router ID of the router that originated the route within the AS. If the route returns to the originator, it recognizes its own Router ID and discards it.
• Cluster List: a list of the Cluster IDs the route has passed through. The Cluster ID equals the RR’s Router ID by default. If an RR sees its own Cluster ID in the list, it discards the route (it has already passed through it).

These two mechanisms replace the loop protection that a full mesh provided implicitly.

Verification

show ip bgp <prefix> shows whether a route was received from an RR client, including Originator ID and Cluster List information in the detailed output.

Clients need no special config

Only the RR is configured (with route-reflector-client per client). The client routers are ordinary iBGP routers and are unaware of their role. This is a common exam point.

Self-check

Q1 — What problem do route reflectors solve?

A) Inter-AS loop prevention
B) The iBGP full-mesh scalability problem, by reflecting routes between iBGP peers
C) Next-hop unreachability
D) eBGP multihop peering

Respuesta

B is correct. RRs are allowed to re-advertise routes between iBGP peers, breaking split-horizon in a controlled way so a full mesh is no longer needed.

• A) False — inter-AS loops are handled by AS-PATH.
• C) False — next-hop issues are solved by next-hop-self.
• D) False — multihop is an eBGP feature.

Q2 — Where is the route-reflector-client command configured?

A) On every client
B) Only on the route reflector
C) On both the RR and its clients
D) On the eBGP neighbor

Respuesta

B is correct. Only the RR designates its clients. Clients are ordinary iBGP routers and are unaware of their role.

• A) False — clients need no special configuration.
• C) False — it is configured on the RR only.
• D) False — it is an iBGP RR feature, not an eBGP one.

Q3 — A route learned from a non-client iBGP peer is reflected to whom?

A) To all clients and non-clients
B) Only to clients
C) Only to non-clients
D) To no one

Respuesta

B is correct. A route from a non-client is reflected only to clients. This is why two non-clients still need direct peering.

• A) False — that is the rule for eBGP-learned or client-learned routes.
• C) False — non-clients are not reflected to for a non-client-sourced route.
• D) False — clients do receive it.

Q4 — Which attributes prevent loops in a route-reflected environment?

A) Weight and Local Preference
B) Originator ID and Cluster List
C) MED and Origin
D) AS-PATH and Next-Hop

Respuesta

B is correct. Originator ID (the originating router’s Router ID) and Cluster List (the Cluster IDs traversed) replace the loop protection that a full mesh gave implicitly.

• A) False — those are best-path attributes, not RR loop guards.
• C) False — MED and Origin are best-path attributes.
• D) False — AS-PATH does not change inside the AS, which is why the two RR attributes were needed.