8-27 neighbor ip-address peer-group-name route-reflector-client

8-27 neighbor { ip-address peer- group - name } route-reflector-client

Syntax Description:

• ip-address Neighbor's IP address.

• peer-group-name Name of the peer group. See section 8-19.

Purpose: IBGP neighbors do not propagate routing information learned from one IBGP neighbor to another IBGP neighbor. Therefore, if you are running IBGP, every IBGP speaker must have a connection to every other IBGP speaker in the AS. This becomes a scaling problem as the number of IBGP speakers increases . The number of IBGP connections for n speakers is ( n ( n -1))/2. Table 8-1 lists the number of connections needed for 2 to 10 IBGP speakers.

Table 8-1. IBGP Connections Needed for a Full Mesh

Number of IBGP Speakers	Number of Connections
2	1
3	3
4	6
5	10
6	15
7	21
8	28
9	36
10	45

A route reflector is one technique to overcome the scaling issue with IBGP. One or more routers serve as a route reflector, and other routers are clients to the route reflector. Route reflectors reflect routes learned from a route reflector client to the other clients . With one route reflector, the number of logical connections needed for n IBGP speakers is n -1.

Cisco IOS Software Release: 10.0. Peer group support was added in Release 11.0.

Configuration Example 1: Single Route Reflector

Assume that the network in Figure 8-27 requires IBGP for the exchange of routing information. Without a route reflector, we would need three BGP neighbor connections. We can reduce the number of BGP connections to two by using a single route reflector.

Figure 8-27. Route Reflector

 Router A  interface Loopback0   ip address 172.16.1.1 255.255.255.255   !   interface Ethernet0   ip address 172.17.1.1 255.255.255.0   !   interface Serial0   ip address 10.1.1.1 255.255.255.252   !   router ospf 1   network 10.0.0.0 0.255.255.255 area 0   network 172.16.0.0 0.0.255.255 area 0   network 172.17.0.0 0.0.255.255 area 0   !   router bgp 1   neighbor 172.16.1.3 remote-as 1   neighbor 172.16.1.3 update-source Loopback0   __________________________________________________________________________  Router B  interface Loopback0   ip address 172.16.1.3 255.255.255.0   !   interface Serial0   ip address 10.1.1.2 255.255.255.252   clockrate 64000   !   interface Serial1   ip address 10.1.2.1 255.255.255.252   clockrate 64000   !   router ospf 1   network 10.0.0.0 0.255.255.255 area 0   network 172.16.0.0 0.0.255.255 area 0   !   router bgp 1   neighbor 172.16.1.1 remote-as 1   neighbor 172.16.1.1 update-source Loopback0    neighbor 172.16.1.1 route-reflector-client    neighbor 172.16.1.2 remote-as 1   neighbor 172.16.1.2 update-source Loopback0    neighbor 172.16.1.2 route-reflector-client    __________________________________________________________________________  Router C  interface Loopback0   ip address 172.16.1.2 255.255.255.255   !   interface Ethernet0   ip address 172.17.1.2 255.255.255.0   !   interface Serial0   ip address 10.1.2.2 255.255.255.252   !   router ospf 1   network 10.0.0.0 0.255.255.255 area 0   network 172.16.0.0 0.0.255.255 area 0   network 172.17.0.0 0.0.255.255 area 0   !   router bgp 1   neighbor 172.16.1.3 remote-as 1   neighbor 172.16.1.3 update-source Loopback0  

Notice that only the route reflector needs additional configuration. Loopback addresses were used in this configuration. See section 8-33 for a discussion of IBGP and loopback addresses.

Verification

Verify that the IBGP sessions are being established with the route reflector by examining the IBGP neighbors on Router B:

 rtrB# BGP neighbor is 172.16.1.1,  remote AS 1, internal link  Index 1, Offset 0, Mask 0x2  Route-Reflector Client  BGP version 4, remote router ID 172.16.1.1   BGP state = Established, table version = 3, up for 00:28:24   Last read 00:00:26, hold time is 180, keepalive interval is 60 seconds   Minimum time between advertisement runs is 5 seconds   Received 31 messages, 0 notifications, 0 in queue   Sent 31 messages, 0 notifications, 0 in queue   Prefix advertised 0, suppressed 0, withdrawn 0   Connections established 1; dropped 0   Last reset 00:28:34, due to RR client config change   0 accepted prefixes consume 0 bytes   0 history paths consume 0 bytes Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: 172.16.1.3, Local port: 11026 Foreign host: 172.16.1.1, Foreign port: 179 BGP neighbor is 172.16.1.2,  remote AS 1, internal link  Index 2, Offset 0, Mask 0x4  Route-Reflector Client  BGP version 4, remote router ID 172.16.1.2   BGP state = Established, table version = 3, up for 00:28:21   Last read 00:00:22, hold time is 180, keepalive interval is 60 seconds   Minimum time between advertisement runs is 5 seconds   Received 31 messages, 0 notifications, 0 in queue   Sent 31 messages, 0 notifications, 0 in queue   Prefix advertised 0, suppressed 0, withdrawn 0   Connections established 1; dropped 0   Last reset 00:28:33, due to RR client config change   0 accepted prefixes consume 0 bytes   0 history paths consume 0 bytes Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: 172.16.1.3, Local port: 11027 Foreign host: 172.16.1.2, Foreign port: 179 

Configuration Example 2: Multiple Route Reflectors

Multiple route reflectors can be used in an AS to further scale the network. Figure 8-28 has nine routers. Three of themRouters A, D, and Hare acting as route reflectors. Router A has route reflector clients B and C, Router D has route reflector clients E and F, and Router H has route reflector clients I and J. A full IBGP mesh is required between Routers A, D, and H, as shown in the following configurations.

Figure 8-28. Multiple Route Reflectors

 Router A  router bgp 1   neighbor (IP address for Router B) remote-as 1   neighbor (IP address for Router B) route-reflector-client   neighbor (IP address for Router C) remote-as 1   neighbor (IP address for Router C) route-reflector-client   neighbor (IP address for Router D) remote-as 1   neighbor (IP address for Router H) remote-as 1   __________________________________________________________________________  Router B  router bgp 1   neighbor (IP address for Router A) remote-as 1   __________________________________________________________________________  Router C  router bgp 1   neighbor (IP address for Router A) remote-as 1   __________________________________________________________________________  Router D  router bgp 1   neighbor (IP address for Router E) remote-as 1   neighbor (IP address for Router E) route-reflector-client   neighbor (IP address for Router F) remote-as 1   neighbor (IP address for Router F) route-reflector-client   neighbor (IP address for Router A) remote-as 1   neighbor (IP address for Router H) remote-as 1   __________________________________________________________________________  Router E  router bgp 1   neighbor (IP address for Router D) remote-as 1   __________________________________________________________________________  Router F  router bgp 1   neighbor (IP address for Router D) remote-as 1   __________________________________________________________________________  Router H  router bgp 1   neighbor (IP address for Router I) remote-as 1   neighbor (IP address for Router I) route-reflector-client   neighbor (IP address for Router J) remote-as 1   neighbor (IP address for Router J) route-reflector-client   neighbor (IP address for Router A) remote-as 1   neighbor (IP address for Router D) remote-as 1   __________________________________________________________________________  Router  I   router bgp 1   neighbor (IP address for Router H) remote-as 1   _________________________________________________________________________  Router J  router bgp 1   neighbor (IP address for Router H) remote-as 1  

There are three clusters of routers. The first cluster contains Routers A, B, and C. The second cluster contains Routers D, E, and F. The third cluster contains Routers H, I, and J. Each cluster is configured with one route reflector and two clients in the same fashion as Configuration Example 1. The route reflectors need to be configured using a full IBGP mesh using normal IBGP connections or a nonclient peer connection. Route reflectors advertise routes based on the following rules:

• Advertisements received from nonclient peers are reflected to the route reflector's clients.

• Advertisements received from client peers then reflect to all nonclient and client peers (except the one from which the advertisement was received).

• Advertisements received from EBGP neighbors are reflected to all client and nonclient peers.

Troubleshooting

1. Verify that the BGP neighbors are in the Established state using the show ip bgp neighbors command.

   If the neighbor relationship is not in the Established state, see section 8-23. For IBGP and loopbacks, see section 8-33.

2. Verify that clients are actually clients and that nonclients are nonclients using the show ip bgp neighbors command.