BGP Route Reflector.
BGP comes in two flavors: internal BGP (iBGP) and external BGP (eBGP). iBGP connects routers within an AS, while External BGP (eBGP) connects routers in different Autonomous Systems.
To understand BGP Route Reflector, it’s important to understand how iBGP advertises network paths to neighbors.
eBGP uses the AS_PATH attribute to avoid routing loops. The router will discard the route if it sees its own AS number on the list. iBGP, on the other hand, is used entirely within the AS and requires a different approach. iBGP uses the split-horizon rule, which means that if a BGP router receives a route from iBGP peering, it does not advertise that route to other iBGP peers.?
Because of how iBGP route advertisement works, administrators need to work around it to ensure full connectivity. The three options for doing that are as follows:
Importance of BGP Route Reflectors
Scalability
As networks grow, managing the exponential increase in BGP sessions becomes a challenge. Route reflectors simplify the architecture, significantly reducing the number of necessary BGP sessions. This reduction, in turn, reduces the administrative overhead and streamlines network operations.
Flexibility
Route reflectors allow for flexible topology configurations. Network administrators can strategically place route reflectors based on factors such as network load, geographical distribution, and redundancy requirements. This flexibility enables more efficient data flow and enhances network performance.
Redundancy and Resiliency
Deploying multiple route reflectors enhances redundancy and resiliency. If one route reflector fails, others can continue to function, providing uninterrupted service and ensuring network stability.
What is the role of routers in BGP Route Reflector Configuration?
The role of routers in BGP Route Reflector Configuration is as follows-
The Route Reflector, also known as the Server, is responsible for reflecting BGP routes. The server receives BGP updates, stores them, and then reflects those updates to other routers accordingly. It also communicates with non-client routers directly or through client routers.??
These are BGP routers that form a peering relationship with a Route Reflector. They advertise their routes to the Route Reflector, which then reflects these routes to other clients. Client routers do not peer directly with each other; instead, they peer with the Route Reflector. We need to configure the router as a client.?
These are BGP routers that do not peer directly with other non-client routers. They receive BGP routes from Route Reflectors, either directly or through client routers.?
Based on the types of routers, we can have the following cases: -
Case – 1
If a route comes from a Client, the Route Reflector reflects it to all other clients and non-clients.?
Case – 2
If a route comes from a non-client, the Route reflector reflects it to all the clients but not the non-clients.?
Case – 3
If a route comes from an eBGP peer, the Route reflector reflects it to all the clients and non-clients.?
Routing Information Loops
Let's look at the three BGP attributes used to prevent routing information loops when using route reflectors.
CLUSTER_ID
To prevent a route reflector being a single point of failover, multiple RRs can be configured. However, this presents a potential issue around advertisement loops between RRs. To have multiple RRs within the same cluster, all RRs in the same cluster can be configured with a 4-byte CLUSTER_ID so that an RR can discard routes from other RRs in the same cluster.
CLUSTER_LIST
But what if what our RR to be part of multiple clusters? In this case, the RR will use different CLUSTER_IDs for the relevant RR neighbours and appended its CLUSTER_ID to the CLUSTER_LIST attribute. When the RR receives an UPDATE that contains the router's CLUSTER_ID within the CLUSTER_LIST, the update is discarded.
ORIGINATOR_ID
When the route reflector reflects a path, it assigns router ID of the advertising router using the ORIGINATOR_ID attribute. If any router then receives an UPDATE that includes a path that contains an ORIGINATOR_ID matching its own router ID, the UPDATE is ignored
How to configure a BGP Route Reflector?
For this walkthrough, let’s use a simple configuration with three routers and a single Route Reflector in the middle.
To create this configuration, start with the following commands.?
R1(config)#router bgp 100
R1(config-router)#neighbor 10.1.1.2 remote-as 100
R3(config)#router bgp 100
R3(config-router)#neighbor 10.2.2.2 remote-as 100
R2-RR(config)#router bgp 100
R2-RR(config-router)#neighbor 10.1.1.1 remote-as 100
R2-RR(config-router)#neighbor 10.1.1.1 route-reflector-client
R2-RR(config-router)#neighbor 10.2.2.3 remote-as 100
R2-RR(config-router)#neighbor 10.2.2.3 route-reflector-client
As shown in the snippet above, only the configuration on the Route Reflector is different. We specify R1 and R3 as our RR clients in this case.?
Next, run these commands to configure a loopback address on R1 to prove that we can advertise it to R3 through our Route Reflector.?
R1(config)#router bgp 100
R1(config-router)#network 5.5.5.5 mask 255.255.255.255
The “show” command below shows that the Route Reflector received a route from an RR client. We can further check if R3 knows about the 1.1.1.1 loopback address.
R2-RR#show ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.5/32, version 2
Paths: (1 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
Local, (Received from a RR-client)
10.1.1.1 from 10.1.1.1 (10.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
R2-RR#show ip bgp neighbors 10.2.2.3 advertised-routes
BGP table version is 2, local router ID is 10.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 5.5.5.5/32 10.1.1.1 0 100 0 i
Total number of prefixes 1
Finally, the commands below demonstrate that R3 has learned about the loopback address, and the interesting fields to note are the “Originator” and “Cluster list” t.
The Route Reflector has introduced the Originator to cope with loops in the network as we are bypassing the split-horizon rule now. In our example, this is the IP address of R1. An iBGP router will not accept a route if it contains its own Originator IP address.
The other ‘Cluster list’ field is simply the Router ID of the Route Reflector. A single cluster refers to the Route Reflector and all of its clients.
R3#show ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.5/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
Local
10.1.1.1 (inaccessible) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal
Originator: 10.1.1.1, Cluster list: 10.2.2.2
rx pathid: 0, tx pathid: 0
Sources
Managing Partner | Business Development | Telecom & IT Professional | Project Management.
6 个月Good technical write up but isn’t the best of practice within a large enterprise setup.. BGP in general ( either iBGP or eBGP) basically is to provide shortest possible routes and load balance outbound or inbound traffic. And this are manually administered by BGP attributes. ( weight, local preference, originate, route length, etc). iBGP is best practiced with edge routers of a large enterprise setup with multiple IP transit providers. That way quality of service is controlled.
Network Operations Center (NOC) Engineer | Network Security | Leadership Development
6 个月A good read Theophilus Bittok
Network Engineer | JNCIE x 3 (SP, ENT, DC)
6 个月Gonna have to disagree with you that the amount of BGP sessions becomes unmanageable. With simple scripting it's pretty easy to do full meshes again and not really worry about how many you have going on. Another thing that is spoken about is that BGP route reflection (while a fantastic tool in itself and I will never say it shouldn't be used) also removes network state/entropy. This can often times make it difficult to properly load balance traffic in BGP. It's all about what your use cases are. You're right though that BGP route reflection definitely makes life easier for most network operations though. That is absolutely true. But please know that the issue of too many BGP sessions is basically not a problem anymore with some very simple scripting.
Excellent explanation
Network Engineer and System Administrator - Cisco Certified Network Professional Enterprise (Encor+Enarsi) - Still Learning...CCNP Service Provider and DataCenter technologies in progress. Thinking in CCIE.
6 个月Great explanation! ??