< Free Open Study >

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 them—Routers A, D, and H—are 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.

< Free Open Study >