Join Telegram Study Group ▷
BGP Route Reflectors
Lessons Learned:
iBGP Route Reflection
Eliminates the need for a full mesh
-only need peering(s) to the RR(s)
As with OSPF DR and IS-IS DIS, minimize prefix replication
--Send one update to the RR
--RR sends the update to its “clients”
Loop prevention through Cluster-ID
--RR discards routes received with its oven Cluster-ID
--Does not modify other attributes such as next-hop
The whole principle in Route-Reflection can be regarded as DR in OSPF. Where there is a centralized device, it is used to minimize the amount of control plane routing information sent throughout the network.
Using a full-mesh iBGP peer, the administrative overhead of maintaining all peers is high. This is also a large amount of control plane information that the router needs to process because it sends all duplicate updates to all peers in the network. With routing reflections, we can centralize peer arrangements so that clients send a copy of their route updates to RR, and then the RR can turn to and send them to all clients in the network.
Note: You can have more than one RR network, which depends only on your redundant target being a network-based physical topology.
With the RR, we have broken the IBGP PEERS undefined cycle-prevention mechanism, and if you learn a route from the iBGP neighbor, then you will not be allowed to publish it to another iBGP neighbor. We now need to implement another form of cyclic prevention-in RR-it appears in the form of a Cluster-ID.
When RR receives an update from the client and then forwards it to another client or another ibgp peer.
The router-id of RR (also known as Cluster-ID) will be added to the update in the cluster list.
If RR receives updates with its own Cluster-ID in the cluster list, it automatically filters out these updates.
Route Reflector Peerings.
Route Reflectors can have three types of peers
EBGP Peers
-Neighbors in different AS (routers different from local AS)
Client Peers
--iBGP peers with # route-reflector-client (routers that have the RR-Client configured in their neighbor command)
Non-Client peers
--ibgp peers without #route-reflector-client (regular ibgp neighbors – W/O the client command configured)
The importance of dividing these peers into these three independent roles is that the RR will differentiate the routing updates based on the updated source and the updated location.
Route Reflector Update Processing
The way of RR processes updates depends on which type of peer it comes from.
EBGP learned the route.
--Can be advertised to EBGP peers & clients & Non-clients
Client learned routes
--can be advertised to EBGP peers, clients, and Non-clients
Non-Client learned routes
--can be advertised to EBGP peers and Clients (This is the only restriction)
RR placement based upon these rules.
Key point: remember that the RR will not advertise routes between two non-client peers.
There are cases where there are multiple RR’s inside the same AS to avoid single points of failure.
Large Scale Route Reflection
Larger scale BGP designs cannot be serviced by only a single RR
--Single RR is a single point of failure.
RR “Clusters” allow redundancy and hierarchy
--Cluster is defined by the clients a RR servers
--RRs in the same cluster using the same cluster-ID
Inter-Cluster peering’s between RRs can be a client or non-client peering’s.
--Depends on the redundancy design
Note: RRs will usually select only ONE best path on a per route basis.
This selection will eventually enter the routing table and then what routes can be advertised.
Topology RR:
The first thing we need to do is to verify we have underlying reachability. For this exercise, I’ll user EIGRP AS 100
Since I will be using the loopbacks as the update source on each router, I will advertise them into my IGP.
Note: if you have any questions about the BGP router reflectors, and you can contact us by clicking the button. SPOTO will give you the best service.
R1#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/22/32 ms
R1#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R1#
Then we need to configure R1 – who will be the RR:
R1:
router BGP 100
no synchronization
BGP log-neighbor-changes
network 1.1.1.0 mask 255.255.255.0
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 update-source Loopback1
neighbor 2.2.2.2 route-reflector-client
neighbor 3.3.3.3 remote-as 100
neighbor 3.3.3.3 update-source Loopback1
neighbor 3.3.3.3 route-reflector-client
no auto-summary
Then we’ll configure each other Router as RR Clients and point them both to the RR as the neighbor.
R2:
router bgp 100
no synchronization
bgp log-neighbor-changes
network 2.2.2.0 mask 255.255.255.0
neighbor 1.1.1.1 remote-as 100
neighbor 3.3.3.3 remote-as 100
no auto-summary
!
R3:
router bgp 100
no synchronization
bgp log-neighbor-changes
network 3.3.3.0 mask 255.255.255.0
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-source Loopback1
neighbor 2.2.2.2 remote-as 100
no auto-summary
!
We should now verify the config via #sh IP BGP
R1:
R1#sh IP BGP
BGP table version is 18, the local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 0.0.0.0 0 32768 i
r>i2.2.2.0/24 2.2.2.2 0 100 0 i
r>i3.3.3.0/24 3.3.3.3 0 100 0 i
R1#
R2#sh ip bgp
BGP table version is 18, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
r>i1.1.1.0/24 1.1.1.1 0 100 0 i
*> 2.2.2.0/24 0.0.0.0 0 32768 i
r>i3.3.3.0/24 3.3.3.3 0 100 0 i
R2#
R3#sh ip bgp
BGP table version is 18, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
r>i1.1.1.0/24 1.1.1.1 0 100 0 i
r>i2.2.2.0/24 2.2.2.2 0 100 0 i
*> 3.3.3.0/24 0.0.0.0 0 32768 i
R3#
In this case the r> next to the prefix does not mean RIB failure, it means it was learned from the Route-Reflector.
We can verify the RR is working correctly – I’ll add a loopback interface to R3 and add it's prefixed into BGP-
network 6.1.1.0 mask 255.255.255.0
We should now see this route or the RR:
R1#sh IP BGP
BGP table version is 19, the local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 0.0.0.0 0 32768 i
r>i2.2.2.0/24 2.2.2.2 0 100 0 i
r>i3.3.3.0/24 3.3.3.3 0 100 0 i
*>i6.1.1.0/24 3.3.3.3 0 100 0 i
Also on R2:
We can see the route with a next hop of 3.3.3.3 and learned from the Loopback of R1 – the RR
R2#sh ip route 6.1.1.0
Routing entry for 6.1.1.0/24
Known via "bgp 100", distance 200, metric 0, type internal
Last update from 3.3.3.3 00:30:32 ago
Routing Descriptor Blocks:
* 3.3.3.3, from 1.1.1.1, 00:30:32 ago
Route metric is 0, the traffic share count is 1
AS Hops 0
About SPOTO
SPOTO focus on online IT Certification training for 16 years. SPOTO offers 100% real and valid Cisco CCNA, CCNP, CCIE, ISC, Amazon AWS, Microsoft, and other IT exam practice tests. If you’re still worried about to prepare and pass the Cisco exam, try SPOTO now. SPOTO tutors will help you get the CCIE number at the first try.
