Route Reflectors
This section illustrates a practical use of route reflectors and peer groups. In Figure 12-13, RTG and RTA form a route reflector cluster, where RTG is the route reflector. RTF, RTE, and RTD form another cluster where RTF is the route reflector. RTG and RTF are part of a peer group called REFLECTORS; if there are other route reflectors, all should IBGP peer in a full mesh. RTF puts all its clients in a peer group called CLIENTS, where common policies can be applied.
Figure 12-13. Route Reflectors
Clients are identified on the route reflector servers by configuring route-reflector-client following the neighbor x.x.x.x parameter. Traditionally, there was an IOS limitation that required client-to-client reflection to be disabled if the clients were members of a BGP peer group. This is no longer a restriction. Full IBGP mesh will be maintained inside the RTF-RTD-RTE cluster, and the clients will peer only with the associated route reflector. Example 12-67 shows the configuration for RTF.
Example 12-67. Route Reflectors: RTF Configuration
router bgp 3 no synchronization network 172.16.65.0 mask 255.255.255.192 network 172.16.50.0 mask 255.255.255.0 network 172.16.25.0 mask 255.255.255.0 network 172.16.30.0 mask 255.255.255.0 neighbor REFLECTORS peer-group neighbor REFLECTORS remote-as 3 neighbor CLIENTS peer-group neighbor CLIENTS remote-as 3 neighbor CLIENTS route-reflector-client neighbor 172.16.25.2 peer-group CLIENTS neighbor 172.16.30.2 peer-group CLIENTS neighbor 172.16.50.2 peer-group REFLECTORS no auto-summary |
Because RTF provides the only available internal path out of the cluster, RTD and RTE are configured as clients of RTF, and RTF is configured as the route reflector. Together, the three routers comprise what's referred to as a cluster in route reflection terminology. From RTD and RTE's perspective, the BGP peering session with RTF is a normal IBGP session. In other words, the client need not be aware that it is a client. (Note that this was one of the requirements for designing route reflection—that the clients need not know that they're clients.) Examples 12-68 through 12-70 show the configurations for RTD, RTG, and RTA, respectively.
Example 12-68. Route Reflectors: RTD Configuration
router bgp 3 no synchronization network 172.16.90.0 mask 255.255.255.0 network 172.16.30.0 mask 255.255.255.0 neighbor 172.16.30.1 remote-as 3 neighbor 172.16.30.1 next-hop-self neighbor 192.68.20.2 remote-as 2 neighbor 192.68.20.2 filter-list 10 out no auto-summary ip as-path access-list 10 permit ^$ |
Example 12-69. Route Reflectors: RTG Configuration
router bgp 3 no synchronization network 172.16.112.0 mask 255.255.255.0 network 172.16.50.0 mask 255.255.255.0 network 172.16.70.0 mask 255.255.255.0 neighbor 172.16.50.1 remote-as 3 neighbor 172.16.70.1 remote-as 3 neighbor 172.16.70.1 route-reflector-client no auto-summary |
Example 12-70. Route Reflectors: RTA Configuration
router bgp 3 no synchronization network 172.16.220.0 mask 255.255.255.0 network 172.16.70.0 mask 255.255.255.0 neighbor 172.16.20.1 remote-as 1 neighbor 172.16.20.1 filter-list 10 out neighbor 172.16.70.2 remote-as 3 neighbor 172.16.70.2 next-hop-self no auto-summary ip as-path access-list 10 permit ^$ |
The BGP table in Example 12-71 shows how RTD sees some of the routes that are being reflected into its own cluster.
Example 12-71. Route Reflectors: RTD BGP Table
RTD#show ip bgp 172.16.220.0
BGP routing table entry for 172.16.220.0/24, version 52
Paths: (1 available, best #1)
Local
172.16.70.1 (metric 192) from 172.16.30.1 (172.16.220.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator : 172.16.220.1, Cluster list: 172.16.65.1, 172.16.112.1
|
Note how RTD sees the originator of route 172.16.220.0/24 as 172.16.220.1, which is the ROUTER_ID of RTA. The route also carries a cluster list that contains the ROUTER_IDs of all the route reflectors it passed through.
In the case where multiple route reflectors are configured inside the cluster, all the route reflectors need to be configured with a common CLUSTER_ID. This is needed to detect routing loops that might occur between clusters. For example, if RTE were to be configured as a route reflector, the configurations for RTF and RTE would need the additional router command bgp cluster-id number. Example 12-72 shows the configuration for RTF.
Example 12-72. Multiple Route Reflectors: RTF Configuration
router bgp 3 no synchronization network 172.16.65.0 mask 255.255.255.192 network 172.16.50.0 mask 255.255.255.0 network 172.16.25.0 mask 255.255.255.0 network 172.16.30.0 mask 255.255.255.0 neighbor REFLECTORS peer-group neighbor REFLECTORS remote-as 3 neighbor CLIENTS peer-group neighbor CLIENTS remote-as 3 neighbor CLIENTS route-reflector-client neighbor 172.16.25.2 peer-group CLIENTS neighbor 172.16.30.2 peer-group CLIENTS neighbor 172.16.50.2 peer-group REFLECTORS bgp cluster-id 1000 no auto-summary |
The CLUSTER_ID is a number identifying the cluster. Each cluster must be assigned a unique value. This is needed in order to avoid looping in case RTF and RTE are both configured as route reflectors in the same cluster. Note that it's good practice to configure a CLUSTER_ID even if you're using a single route reflector. When you configure a CLUSTER_ID, no route reflector clients can be configured on the router. Therefore, if one isn't already defined, you must unconfigure all the existing clients, configure the CLUSTER_ID, and then reconfigure the clients. Therefore, defining the CLUSTER_ID value upon initial configuration is a good idea.