Advanced BGP and Route Reflectors. When a network grows beyond a handful of routers, the old way of doing things — connecting every router to every other router — becomes a nightmare of complexity and wasted resources. Understanding route reflectors is crucial for the 350-501 exam because they are the primary tool Cisco uses to scale BGP in service provider networks, and the exam tests your ability to design and troubleshoot them.
Jump to a section
A simple way to picture Advanced BGP and Route Reflectors
7 regional newspapers in a national chain each need to share their biggest local stories with every other paper in the chain. Each paper has its own editor, and they all report to a central headquarters. If every paper had to phone every other paper directly to share a story, the total number of phone calls would be 7 times 6, or 42 calls. For 100 papers, that would be 9,900 calls — an impossible tangle.
So the chain appoints a few senior editors — let's say two — as central hubs. Each local paper only phones its assigned senior editor. That senior editor then phones the other senior editor, who passes the story on to their local papers. Now the total calls drop to just 7 local-to-senior calls, plus 1 call between the two senior editors, for a total of 8 calls.
This maps precisely to BGP route reflectors. The local newspapers are BGP routers. The stories they share are IP routes. Without route reflectors, every router must peer with every other router (a full mesh). That is the 42-call mess. With route reflectors, only the chosen route reflector clients talk to their route reflector server (the senior editor), and the servers propagate routes among themselves. This mirrors our 8-call system. The central headquarters represents the BGP autonomous system — the unified organisation owning all the routers.
BGP, or Border Gateway Protocol, is the protocol that the internet uses to exchange routing information between large networks called Autonomous Systems (AS). An AS is a collection of routers under a single administrative control, like an ISP (Internet Service Provider).
In its simplest form, BGP requires that all routers inside an AS — called iBGP (internal BGP) routers — are fully connected to each other. This is called a full mesh. For a network with N routers, a full mesh means N*(N-1)/2 individual BGP sessions (called peerings). Peering is just a fancy word for two routers agreeing to exchange routes directly.
For 5 routers, a full mesh requires 10 peerings. That is manageable. For 50 routers, it requires 1,225 peerings. For 500 routers — which is common in a large ISP — it requires 124,750 peerings. Each peering consumes router memory (to store the session state) and CPU (to process updates). A full mesh does not scale.
Route reflectors solve this problem. A route reflector is a BGP router that is allowed to advertise routes learned from one iBGP peer to another iBGP peer, breaking the full-mesh rule. In a standard iBGP setup, a router that learns a route from an iBGP peer will not advertise that route to any other iBGP peer — that is the rule. A route reflector has a special rule: it can re-advertise routes.
A route reflector design has three roles:
Route reflector server: the central router that reflects routes.
Route reflector client: a router that peers only with the route reflector server, not with other clients.
Non-client peer: a router that peers with the route reflector but is not a client. These are typically other route reflectors or routers in other parts of the network.
The key rule for a route reflector server is how it handles incoming routes:
If a route comes from a non-client peer, the server advertises it only to its clients and other route reflectors (not back to non-clients).
If a route comes from a client, the server advertises it to all other clients, all non-client peers, and other route reflectors.
If a route comes from an external BGP (eBGP) peer (a router in a different AS), the server advertises it to all clients and non-clients.
These rules prevent routing loops. A routing loop is a situation where a packet bounces between routers forever because they keep pointing to each other. The route reflector rules ensure that there is always a clear, loop-free path.
Route reflectors are hierarchical. You can have multiple route reflector clusters in a single AS. A cluster is a group consisting of one route reflector server and its clients. To prevent loops between clusters, each route reflector adds its unique Cluster ID to the route advertisement. If a route reflector sees its own Cluster ID already in a route, it knows the route has already passed through its cluster and should not be processed again.
Confederations are an alternative to route reflectors. They break a single large AS into multiple sub-ASes (also called member-ASes). Each sub-AS runs eBGP between itself and other sub-ASes, but iBGP inside itself. This reduces the iBGP mesh problem because each sub-AS is smaller. However, confederations are more complex to configure and are less commonly used than route reflectors. The 350-501 exam expects you to understand both, but route reflectors are the primary focus.
The main reason route reflectors exist is to reduce the number of BGP peerings, which reduces the load on routers and makes the network easier to manage. They are the standard way to scale BGP in modern service provider networks.
Identify the Need for Scaling
Count the number of iBGP routers in your AS. If the number N results in N*(N-1)/2 peerings exceeding your router's memory or CPU capacity, you need route reflectors. For example, 100 routers need 4,950 peerings, which is too many.
Design the Route Reflector Hierarchy
Select which routers will be route reflector servers based on network topology, redundancy, and traffic flows. Typically, you choose one or two core routers per location as servers. Decide which routers are clients (usually distribution or access routers). Plan for redundancy — two route reflectors in the same cluster is common.
Configure the Route Reflector Server
On the chosen server router, enter BGP configuration mode and use the command 'neighbor <ip-address> route-reflector-client' for each client peer. Optionally, set a cluster ID with 'bgp cluster-id <value>' if you have multiple servers in the same cluster. The server will now reflect routes according to the three rules.
Configure Each Client Router
On each client router, configure a standard iBGP peering session pointing only to the route reflector server's IP address. No special client command is needed. The client does not know it is a client — it just sends and receives routes from the server as if it were a normal iBGP peer.
Verify Route Propagation
Use commands like 'show ip bgp' and 'show bgp neighbors <ip> routes' on the server to confirm routes are being received from clients and advertised to other peers. Check that routes from a client appear on other clients via the server. Verify the Originator ID and Cluster List attributes with 'show ip bgp <prefix>' to ensure loop prevention is working.
Troubleshoot Common Issues
If a route is missing, check the route reflector rules: did the route come from a client or non-client? Is the cluster ID correctly configured on all servers? Check that the 'next-hop-self' command is not conflicting with route reflection rules. Use 'debug ip bgp updates' carefully in a lab to see the reflection process in action.
Imagine you are a network engineer at "GlobalConnect", a mid-sized ISP with 200 routers spread across three major cities: London, Frankfurt, and Singapore. Each city has a core router that connects to the other cities, and dozens of smaller distribution routers that connect to customers. GlobalConnect uses BGP to exchange routes between these routers and with other ISPs.
Without route reflectors, every one of those 200 routers would need a BGP session to every other router. That is 19,900 sessions. Your router configuration files would be enormous, the CPU on each router would be constantly processing BGP updates, and troubleshooting a single route would mean checking hundreds of sessions.
So you implement route reflectors. You designate the core router in each city as a route reflector server. In London, that core router peers with all 60 distribution routers in Europe. In Frankfurt, the core router peers with 50 distribution routers. In Singapore, the core router peers with 40 distribution routers. The three core routers then peer with each other as non-clients.
Now, when a customer in London advertises a new IP route (say a new block of public IP addresses), the London distribution router sends it to the London route reflector server. The London server then:
Advertises that route to all its other European clients.
Advertises it to the Frankfurt and Singapore route reflector servers (as non-clients).
The Frankfurt server then advertises it to all its clients in Frankfurt.
The Singapore server does the same.
The total BGP sessions drop from 19,900 to about 150 (60 + 50 + 40 client sessions, plus 3 inter-cluster sessions, plus sessions to external ISPs). You have saved an enormous amount of router resources.
What does an IT professional actually do with this? You will:
Plan the route reflector hierarchy: decide which routers become servers and which become clients. This requires understanding traffic flows and redundancy — you do not want a single point of failure.
Configure the route reflector server on the designated router using the command 'neighbor <IP> route-reflector-client' under the BGP configuration mode.
Configure each client router with a simple BGP peer relationship only to the route reflector server.
Test the configuration by checking that routes are propagated correctly using commands like 'show ip bgp' and 'show bgp neighbors'.
Troubleshoot problems. A common issue is a missing route due to the Cluster ID loop prevention — if you add a new route reflector in the same cluster without setting a unique Cluster ID, it might silently drop routes.
In larger networks, you might implement multiple route reflectors in the same cluster for redundancy, and you must configure the Cluster ID explicitly.
This is not theory. Every major ISP in the world uses route reflectors. The 350-501 exam expects you to be able to design, configure, and troubleshoot this exact scenario.
The 350-501 exam tests Advanced BGP and Route Reflectors heavily. Expect at least 3-5 questions on route reflectors and confederations, often in the context of network scalability or troubleshooting. The exam writers love to set traps around the peering rules and loop prevention mechanisms.
Key exam topics and what you must memorise:
The full mesh requirement for iBGP: every iBGP speaker must peer with every other iBGP speaker unless route reflectors or confederations are used.
The route reflector client and server configuration command: 'neighbor <ip> route-reflector-client' on the server side only. The client side has no special configuration — it just peers normally.
The three route advertisement rules for a route reflector server: from a client, from a non-client, from an eBGP peer. Memorise the exact behaviour for each.
The Cluster ID: a 4-byte value (usually the router-id of the route reflector) that prevents inter-cluster loops. If you have multiple route reflectors in the same cluster, you must explicitly set the same Cluster ID on all of them.
The Originator ID: an attribute added by the route reflector that identifies the original router that injected the route into the iBGP. This prevents loops inside a cluster.
The difference between route reflectors and confederations: route reflectors change the rules inside one AS; confederations split one AS into multiple sub-ASes. Confederations require eBGP configuration between sub-ASes, which is more complex.
Know the 'bgp cluster-id' command and its use case.
Common traps on the exam:
They will give you a scenario with routers R1, R2, R3, R4 where R1 is the route reflector, R2 and R3 are clients, R4 is a non-client. They will ask: "If R2 sends a route to R1, which routers does R1 forward it to?" The answer is: R3 (client) and R4 (non-client). But not R2 (the sender). They often include an answer like "only to clients" to trick you.
They might describe a routing loop and ask why it is occurring. The answer is often that the Cluster ID was not configured correctly on a second route reflector in the same cluster.
A question about the number of iBGP sessions: they give you N routers and ask for the number of sessions without route reflectors. The formula is N*(N-1)/2. They might use a high number like 100 routers to make you calculate.
They might ask: "Which BGP attribute is used by route reflectors to prevent routing loops within a cluster?" The answer is: Originator ID (for inside the cluster) and Cluster List (for inter-cluster).
A configuration-based question: "You see 'bgp cluster-id 1.1.1.1' in the config. What is this?" The answer: It sets the cluster ID for a route reflector cluster, typically used when multiple route reflectors exist in the same cluster.
To prepare, you should be able to draw a small topology and trace the route advertisement flow for different scenarios. Practise writing out the three rules from memory. The exam expects precision — a single wrong word about "to all iBGP peers" vs "to all clients" costs you marks.
In iBGP, every router must peer with every other router (full mesh) unless you use route reflectors or confederations.
A route reflector server uses the 'neighbor <ip> route-reflector-client' command to designate a peer as a client.
Routes from a client are advertised to all other clients and all non-client peers by the route reflector.
Routes from a non-client are advertised only to clients by the route reflector, not to other non-clients.
The Cluster ID prevents routing loops between different route reflector clusters within the same AS.
Confederations split an AS into sub-ASes, using eBGP between sub-ASes and iBGP inside each sub-AS, reducing the iBGP mesh.
A route reflector client does not need any special configuration beyond a normal BGP peer relationship to the server.
The Originator ID attribute is set by the route reflector to identify the original router that sourced a route into iBGP.
These come up on the exam all the time. Here's how to tell them apart.
Route Reflector
Operates within a single AS by changing iBGP advertisement rules.
Configuration is simpler: just one command on the server per client.
Uses Originator ID and Cluster List for loop prevention.
Confederation
Splits one AS into multiple sub-ASes (member-ASes).
Configuration is more complex: requires eBGP configuration between sub-ASes.
Uses standard eBGP loop prevention (AS-path checking) between sub-ASes.
Route Reflector Client
Only peers with the route reflector server, not with other clients.
Routes from a client are advertised to all other clients and non-clients by the server.
Client configuration is identical to a normal iBGP peering.
Route Reflector Non-Client
Peers with the route reflector server but is not a client (often another route reflector).
Routes from a non-client are advertised only to clients by the server, not to other non-clients.
Non-client configuration includes a normal iBGP peering with the server, but no special role definition.
Originator ID
A BGP attribute added by the route reflector to identify the original router that injected the route into iBGP.
Prevents loops within a single cluster.
Set automatically by the route reflector based on the originator's router ID.
Cluster ID
A BGP attribute that identifies the route reflector cluster.
Prevents loops between different clusters.
Manually configured with 'bgp cluster-id' or defaults to the route reflector's router ID.
iBGP Full Mesh
Requires every iBGP speaker to peer with every other iBGP speaker.
Number of peerings scales as N*(N-1)/2, impractical for large networks.
No additional configuration needed beyond standard iBGP peering.
Route Reflection
Requires only client-to-server peerings, reducing total peerings significantly.
Scales linearly with the number of clients.
Requires route-reflector-client configuration on the server.
Mistake
Route reflectors are a type of router that is physically different from other routers.
Correct
Any router running BGP can be configured as a route reflector. It is a software role — you just add a command to make a normal router act as a route reflector server.
People confuse the conceptual role with a hardware requirement because terms like 'server' and 'client' imply different hardware, but in networking these are just configuration roles.
Mistake
A route reflector client must also be configured as a 'client' on its own configuration.
Correct
Only the route reflector server needs the 'neighbor route-reflector-client' command. The client just has a normal BGP peering statement pointing to the server. The server marks the client relationship, not the client.
The term 'client' suggests the client side must do something special, but in BGP route reflection, the 'client' is defined by the server's configuration.
Mistake
Route reflectors advertise all routes to all peers equally.
Correct
Route reflectors follow strict rules: routes from a client go to all other clients and non-clients; routes from a non-client go only to clients; routes from eBGP go to all iBGP peers. They do not blindly re-advertise everything.
Beginners often think route reflectors are just 'repeat everything to everyone', missing the nuanced rules that prevent loops.
Mistake
Confederations and route reflectors are interchangeable.
Correct
They solve the same scalability problem but work differently. Route reflectors modify the iBGP advertisement rules within a single AS. Confederations break the AS into smaller sub-ASes and use eBGP between them. They can even be used together, but they are not drop-in replacements.
Both reduce the full mesh requirement, so people assume they are the same thing. But the configuration, terminology, and behaviour are different.
Mistake
The Originator ID and Cluster ID are the same thing.
Correct
The Originator ID identifies the router that originally injected the route into the iBGP domain. The Cluster ID identifies the route reflector cluster. Both prevent loops but at different levels — Originator ID inside a cluster, Cluster List between clusters.
Both are loop-prevention attributes added by route reflectors, leading to confusion about which does what.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, route reflectors do not change how BGP selects the best path. They only change how routes are advertised within the AS. The best path selection on each router still uses the standard BGP attributes (AS-path, local preference, MED, etc.).
Yes, you can. To prevent loops, you must configure the same 'bgp cluster-id' on all route reflectors in that cluster. The cluster ID is a 4-byte value that identifies the cluster; if a route reflector sees its own cluster ID in a route's Cluster List, it discards the route to prevent loops.
A route reflector client is defined by the server using the 'route-reflector-client' command. The client itself does not need any special configuration. The difference is that the server will re-advertise routes from a client to other clients and non-clients, whereas for a normal iBGP peer (non-client), the server only advertises routes from clients and eBGP peers, not from other non-clients.
No, you do not explicitly disable anything. By configuring a route reflector, you are essentially opting out of the full mesh rule for the clients. The route reflector server will handle the route advertisement in a way that does not require clients to be directly connected to each other. The routers that are not clients (other route reflectors) must still peer with each other if they are in different clusters.
Yes, this is called hierarchical route reflection. A router can be a client of a higher-level route reflector and act as a server for its own lower-level clients. This is common in very large networks to create a hierarchy of clusters.
Without an explicit cluster ID, each route reflector uses its own router ID as the cluster ID. This causes each server to treat routes from the other server as coming from a different cluster, which can lead to route loops or suboptimal routing. You must set the same cluster ID on all servers in the same cluster.
Route reflection itself does not introduce security vulnerabilities, but it does mean that routes are propagated more widely within the AS. This increases the risk of a misconfigured or malicious client injecting bad routes that get reflected to many routers. Standard BGP security practices like prefix filtering, BGP TTL security (GTSM), and RPKI still apply.
You've finished Advanced BGP and Route Reflectors. Continue through the 350-501 study guide to build a complete picture of the exam.
Done with this chapter?