Course contents

Module 2: Scaling iBGPLesson 2.1 (1 of 3 in this module)4 of 11 in the Advanced BGP course

Redundant route reflectors and cluster IDs

Two route reflectors, cluster lists and originator IDs.

Advanced · 20 min read

You'll learn to design a pair of route reflectors, configure the cluster ID, and explain what each choice of cluster ID trades away.

A single reflector is a single point of failure

One route reflector keeps the mesh small but ties every client's view of the network to one router. If it fails, clients stop learning each other's routes. The usual fix is two reflectors, with every client peering with both.

Two reflectors with one cluster ID
Two reflectors with one cluster IDTwo route reflectors RR1 and RR2 share cluster ID 9.9.9.9. Each client peers with both.RR1cluster 9.9.9.9RR2cluster 9.9.9.9C1C2C3C4Every client peers with both reflectors

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Clients keep two copies of every route, one from each reflector. A shared cluster ID makes the reflectors drop each other's copies, which saves memory.
Two route reflectors and their clients
Two route reflectors and their clientsRR1 at 10.255.0.1 and RR2 at 10.255.0.2 are route reflectors in AS 64500. Each of the clients C1, C2 and C3 peers with both reflectors. The two reflectors peer with each other. If RR1 fails, every client still has a session to RR2 and keeps receiving routes.AS 64500RR110.255.0.1RR210.255.0.2iBGPC110.255.0.11C210.255.0.12C310.255.0.13

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Each client has two sessions, one per reflector. A single reflector would be a single point of failure for every route in the AS.

Configure two reflectors

router bgp 64500 bgp cluster-id 9.9.9.9 neighbor CLIENTS peer-group neighbor CLIENTS remote-as 64500 neighbor CLIENTS update-source Loopback0 neighbor 10.255.0.11 peer-group CLIENTS neighbor 10.255.0.12 peer-group CLIENTS address-family ipv4 unicast neighbor CLIENTS route-reflector-client neighbor 10.255.0.11 activate neighbor 10.255.0.12 activate

RR1. RR2 uses the same lines with the same cluster ID. Each client has an ordinary iBGP session to both reflectors.

Look at the cluster list on a client to see which reflectors a route has passed through.

Illustrative Cisco IOS XE output written for this lesson, not a router capture
C1#show ip bgp 203.0.113.0
BGP routing table entry for 203.0.113.0/24, version 12
Paths: (2 available, best #1, table default)
  64501
    10.255.0.1 (metric 20) from 10.255.0.9 (9.9.9.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 1.1.1.1, Cluster list: 9.9.9.9
  64501
    10.255.0.1 (metric 20) from 10.255.0.10 (9.9.9.2)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 1.1.1.1, Cluster list: 9.9.9.9
The client holds a copy from each reflector, with the same originator and cluster list. If one reflector fails, the other copy remains.

Shared or separate cluster IDs

With a shared cluster ID, a reflector that sees its own cluster ID in a route's cluster list drops that route. The two reflectors do not store each other's copies, which saves memory. The risk is that a client with a broken session to one reflector may not get everything it needs.

Shared and separate cluster IDs
Shared and separate cluster IDsWith the same cluster ID the reflectors drop each other copies. With different IDs both copies are kept.Shared IDSaves memoryLess redundancy if a clientloses one reflectorSeparate IDsMore memoryBoth copies are keptvs

On small screens, swipe sideways or focus the diagram and use the arrow keys.

The choice trades memory for resilience.

With separate IDs, each reflector keeps the other's copy, so routes survive more failure cases, at the cost of memory. Whichever you choose, apply it consistently and keep the clients peering with both.

Technical reference: RFC 4456, BGP Route Reflection. Output above is illustrative.

How reflectors avoid loops

Two attributes stop reflected routes from looping. ORIGINATOR_ID holds the router ID of the router that first advertised the route into the AS. CLUSTER_LIST records each cluster ID the route has passed through. A router discards a route that lists its own router ID as originator or its own cluster ID in the list.

Loop prevention with two attributes
Loop prevention with two attributesThe reflector adds its cluster ID and the originator is recorded once.Client advertisesa route to RR1RR1 reflectsadds ORIGINATOR_ID,CLUSTER_LISTRR2 sees own IDif shared:route droppedClientsuse the other copy

On small screens, swipe sideways or focus the diagram and use the arrow keys.

A reflector that sees its own cluster ID drops the route.

Optimal route reflection

A route reflector runs best-path selection once and sends that single result to all of its clients. The reflector chooses by its own IGP cost to each next hop, so a client in another part of the network may be sent an exit that is nearest the reflector, not nearest to itself. This gives suboptimal forwarding and can lengthen the path across the AS.

Optimal route reflection (ORR) lets the reflector run best-path selection from the point of view of a chosen router, called the root, and send each group of clients the result computed for their own location. The reflector needs the IGP topology to do this, so it is normally used with a link-state IGP, and the clients need no change.

router bgp 64500 address-family ipv4 unicast bgp optimal-route-reflection ORR-GROUP-A 10.255.0.1 neighbor 10.255.0.21 optimal-route-reflection ORR-GROUP-A end

Reflector. Clients in group A are sent the best path as seen from 10.255.0.1, the group's root router. The names and addresses are examples. Check the exact command and platform support in the Cisco documentation for your software release.

Technical reference: Cisco, BGP optimal route reflection. Output and commands above are illustrative.

Check your understanding

Predict · scenario 1

Two reflectors share cluster ID 9.9.9.9. What does a reflector do with a route whose cluster list contains 9.9.9.9?

Predict · scenario 2

If no cluster ID is configured, what is used?

Predict · scenario 3

Why must each client peer with both reflectors?

FAQ

What is the default cluster ID?
The reflector's router ID. Two reflectors with different router IDs therefore have different cluster IDs unless you configure them to match.
Should two reflectors share a cluster ID?
It is a trade. A shared ID saves memory because each reflector drops the copy sent by the other, but a client that loses its session to one reflector may miss routes. Separate IDs keep both copies.
Do the reflectors peer with each other?
Usually yes, as non-clients of one another. With a shared cluster ID they ignore each other's reflected routes, which is why clients must peer with both.