The purpose of this article is to set up redundant iBGP Route Reflectors.
A route reflector is designed to lower the complexity level of iBGP networks that usually require full mesh. Route reflectors allow you to break a basic iBGP rule: pass an internal BGP route to another iBGP peer. This will imply the use of two new BGP attributes: CLUSTER_LIST and ORIGINATOR_ID.
iBGP mesh formula:
total(connections) = r(r-1)/2, where r are routers A small ISP with 10 routers: total = 10(10-1)/2 total = 45 connections
An iBGP cluster is made of: one or several route reflectors and its clients. This concept of cluster is done to create advanced and hierarchical design in complex long distance BGP deployments.
A route reflector can have three types of peers (2 internals + 1 external):
– EBGP (different ASN)
– client (with the route-reflector-client command)
– non-client (simple iBGP peer)
These relationships comply with the following rules:
– EBGP routes are sent to EBGP peers, clients and non-clients
– client routes are announced to EBGP peers, clients and non-clients
– non-client routes are reflected to all clients and EBGP peers but not non-clients (iBGP rule)
So, why setup two redundant RRs ?
Because RRs have an important and central role in a iBGP network, having just one RRs is a single point of failure.
Two new BGP attributes are brought by the RFC 4456 – Route Reflection.
CLUSTER_LIST (optional, non-transitive)
The CLUSTER_LIST represents the reflection path (= all the RRs that the route went through). Each RR prepends its CLUSTER_ID in the CLUSTER_LIST. This attribute prevents loops between clusters. It is useful in BGP designs that involves multiple clusters and multiple RRs.
ORIGINATOR_ID (optionnal, non-transitive)
It indicates the router-id of the neighbor from which the route was learnt. It is a loop prevention mechanism (recall that route reflection breaks the iBGP loop prevention rule). When a route is received by a router, the ORIGINATOR_ID is compared with the local router-id and if they are the same, the route is ignored (that’s why it is important to keep router IDs unique in a domain…).
Note that these two new attributes are added by route reflectors.
Now, let’s configure our network (configurations are available below):
router bgp 65001 no synchronization bgp router-id 22.214.171.124 bgp log-neighbor-changes neighbor RRCLI peer-group neighbor RRCLI remote-as 65001 neighbor RRCLI update-source Loopback0 neighbor RRCLI route-reflector-client neighbor RRCLI soft-reconfiguration inbound neighbor 126.96.36.199 peer-group RRCLI neighbor 188.8.131.52 peer-group RRCLI neighbor 184.108.40.206 peer-group RRCLI neighbor 220.127.116.11 peer-group RRCLI neighbor 18.104.22.168 peer-group RRCLI neighbor 22.214.171.124 remote-as 65001 neighbor 126.96.36.199 update-source Loopback0 neighbor 188.8.131.52 soft-reconfiguration inbound no auto-summary
A route reflector client (R4)
router bgp 65001 no synchronization bgp router-id 184.108.40.206 bgp log-neighbor-changes network 220.127.116.11 mask 255.255.255.0 neighbor REDRR peer-group neighbor REDRR remote-as 65001 neighbor REDRR update-source Loopback0 neighbor REDRR soft-reconfiguration inbound neighbor 18.104.22.168 peer-group REDRR neighbor 22.214.171.124 peer-group REDRR no auto-summary
If the CLUSTER_ID is not set with the command bgp cluster-id, the IOS will take the router-id value. If you want two RRs in a cluster you will need to modify this value to a common value (e.g.: bgp cluster-id 1). However this creates a problem in a particular scenario where multiple failures occur.
So, in order to ensure RRs redundancy, the most widely-employed solution is to set two iBGP clusters.
##RR1 router bgp 65001 bgp cluster-id 1 neighbor 126.96.36.199 shutdown ##RR2 router bgp 65001 bgp cluster-id 1 neighbor 188.8.131.52 shutdown
R2 still has a peering with RR1 and R3 still has a peering with RR2. Does each other see their prefixes 184.108.40.206 and 220.127.116.11 ?
R2#sh ip route bgp 18.104.22.168/24 is subnetted, 1 subnets B 22.214.171.124 [200/0] via 126.96.36.199, 00:26:32 188.8.131.52/24 is subnetted, 1 subnets B 184.108.40.206 [200/0] via 220.127.116.11, 00:26:32 18.104.22.168/24 is subnetted, 1 subnets B 22.214.171.124 [200/0] via 126.96.36.199, 00:26:32 R2#sh ip bgp neighbors 188.8.131.52 advertised-routes BGP table version is 51, local router ID is 184.108.40.206 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 *> 220.127.116.11/24 0.0.0.0 0 32768 i Total number of prefixes 1 R3#sh ip route bgp 18.104.22.168/24 is subnetted, 1 subnets B 22.214.171.124 [200/0] via 126.96.36.199, 00:01:41 188.8.131.52/24 is subnetted, 1 subnets B 184.108.40.206 [200/0] via 220.127.116.11, 00:01:41 18.104.22.168/24 is subnetted, 1 subnets B 22.214.171.124 [200/0] via 126.96.36.199, 00:01:41 R3#sh ip bgp neighbors 188.8.131.52 adver BGP table version is 53, local router ID is 184.108.40.206 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 *> 220.127.116.11/24 0.0.0.0 0 32768 i Total number of prefixes 1
No. Still advertised but not propagated. Why ? Because of the CLUSTER_LIST attribute. If a router sees its CLUSTER_ID inside the CLUSTER_LIST it will think there is a loop and will ignored the route, breaking our redundancy. So setting the same cluster-id on two RRs is a bad idea !
##RR1 router bgp 65001 bgp cluster-id 1 neighbor 18.104.22.168 shutdown ##RR2 router bgp 65001 bgp cluster-id 2 neighbor 22.214.171.124 shutdown R2#sh ip bgp 126.96.36.199 BGP routing table entry for 188.8.131.52/24, version 60 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer Local, (received & used) 184.108.40.206 (metric 3) from 220.127.116.11 (18.104.22.168) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 22.214.171.124, Cluster list: 0.0.0.1, 0.0.0.2 R3#sh ip bgp 126.96.36.199 BGP routing table entry for 188.8.131.52/24, version 62 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer Local, (received & used) 184.108.40.206 (metric 3) from 220.127.116.11 (18.104.22.168) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 22.214.171.124, Cluster list: 0.0.0.2, 0.0.0.1
Check the routes received by a RR:
R4#sh ip bgp 126.96.36.199 BGP routing table entry for 188.8.131.52/24, version 58 Paths: (2 available, best #2, table Default-IP-Routing-Table) Flag: 0x820 Not advertised to any peer Local, (received & used) 184.108.40.206 (metric 3) from 220.127.116.11 (18.104.22.168) Origin IGP, metric 0, localpref 100, valid, internal Originator: 22.214.171.124, Cluster list: 0.0.0.2 Local, (received & used) 126.96.36.199 (metric 3) from 188.8.131.52 (184.108.40.206) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 220.127.116.11, Cluster list: 0.0.0.1 R4#sh ip route 18.104.22.168 Routing entry for 22.214.171.124/24 Known via "bgp 65001", distance 200, metric 0, type internal Last update from 126.96.36.199 00:32:56 ago Routing Descriptor Blocks: * 188.8.131.52, from 184.108.40.206, 00:32:56 ago Route metric is 0, traffic share count is 1 AS Hops 0
Note that the RR does not change the next-hop. Consenquently you need to run an IGP to ensure the connectivity.
Download configuration files here.
RFC 4456 – BGP Route Reflection