< Free Open Study >

Syntax Description

• ip-address— Neighbor’s IP address.

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

• number— Neighbor’s autonomous system number (1 to 65534).

Purpose: This form of the neighbor command is the most important. This command is used to configure an internal BGP (IBGP) or external BGP (EBGP) TCP session with another router. Routing information cannot be exchanged without a proper neighbor configuration. When configuring BGP, either in a customer’s network or on the CCIE exam, we suggest that you first establish and verify that the neighbor relationships have been established. A common mistake is to attempt to enter a complete BGP configuration, which might include route exchange, route filtering, attribute manipulation, and route redistribution. If the configuration does not produce the intended results, it is usually very difficult to debug due to the configuration complexity. The preferred method is to configure BGP in steps, with the neighbor command being the first step. If neighbors are properly configured, you can continue to satisfy the other requirements.

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

Configuration Example 1: EBGP Neighbor

EBGP is used between neighbors in different autonomous systems. Typically, EBGP neighbors are directly connected, as shown in Figure 8-22. If the neighbors are not directly connected, bgp multihop can be used (see sections 8-8 and 8-9). For this example, the neighbors are directly connected. The following configuration illustrates the use of the neighbor command to establish an EBGP relationship.

Figure 8-22. EBGP Neighbor Relationship

Router A

router bgp 1

 neighbor 10.1.1.2 remote-as 2

__________________________________________________________________________

Router B

router bgp 2

 neighbor 10.1.1.1 remote-as 1

You need to set only two variables in order to establish a BGP session: the remote neighbor’s IP address and the remote neighbor’s autonomous system number, as shown in the preceding configuration. Therefore, you can make only two mistakes using this command.

Verification

To verify that the neighbor relationship has been established, use the show ip bgp neighbors command (see section 14-90):

RtrA#show ip bgp neighbors

BGP neighbor is 10.1.1.2,  remote AS 2, external link

 Index 0, Offset 0, Mask 0x0

  BGP version 4, remote router ID 10.1.1.2

  BGP state = Established, table version = 2, up for 00:17:01

  Last read 00:00:01, hold time is 180, keepalive interval is 60 seconds

  Minimum time between advertisement runs is 5 seconds

  Received 24 messages, 0 notifications, 0 in queue

  Sent 24 messages, 0 notifications, 0 in queue

  Connections established 2; dropped 1

Connection state is ESTAB, I/O status: 1, unread input bytes: 0

Local host: 172.16.1.3, Local port: 179

Foreign host: 172.16.1.7, Foreign port: 11001

The important elements that are illustrated are the BGP neighbor’s IP address, autonomous system number, link type, and BGP state.

Troubleshooting

1. Ping the neighbor. If the ping is unsuccessful, you do not have a BGP problem.

2. If the ping is successful, you have improperly configured either the neighbor’s IP address or autonomous system number.

   If the neighbor relationship is not being established, only two things could be wrong, assuming that there are no physical layer problems. If you can ping the neighbor, you should be able to establish a BGP connection. Either the neighbor IP address or the remote-as number is incorrect. A correct configuration would produce the following debug output during the establishment of the BGP connection:

RtrB# debug ip bgp events

BGP: 10.1.1.1 went from Idle to Active

BGP: scanning routing tables

BGP: 10.1.1.1 went from Active to OpenSent

BGP: 10.1.1.1 went from OpenSent to OpenConfirm

BGP: 10.1.1.1 went from OpenConfirm to Established

BGP: 10.1.1.1 computing updates, neighbor version 0, table version 1, starting 0

BGP: 10.1.1.1 update run completed, ran for 0ms, neighbor version 0, start vers

Notice that the BGP state transitions from Idle to Active to OpenSent to OpenConfirm to Established.

If the wrong AS number is used but the neighbor’s IP address is correct, the neighbors can establish a TCP session, but they will disagree on the AS number, and the connection will be closed. The following debug output is produced when the incorrect AS number is used for the neighbor:

BGP: 10.1.1.1 went from Idle to Active

BGP: 10.1.1.1 went from Active to Idle

BGP: 10.1.1.1 went from Idle to Connect

BGP: 10.1.1.1 went from Connect to OpenSent

BGP: 10.1.1.1 went from OpenSent to Closing

BGP: 10.1.1.1 went from Closing to Idle

If the neighbor IP address is incorrect, it really doesn’t matter what AS number is used. The neighbors will never establish the TCP connection in order to exchange AS information. The following debug output is produced when an incorrect neighbor IP address is used:

BGP: 10.1.1.3 went from Idle to Active

BGP: scanning routing tables

BGP: 10.1.1.1 went from Active to OpenSent

BGP: 10.1.1.1 went from OpenSent to Closing

BGP: 10.1.1.1 went from Closing to Idle

Configuration Example 2: IBGP Neighbor

IBGP is used between neighbors in the same AS. IBGP neighbors do not need to be directly connected in order to establish a neighbor relationship. Also, the neighbor’s IP address does not need to be the address assigned to a physical interface. We recommend that you use loopback addresses when establishing IBGP sessions. Section 8-33 examines techniques for using loopback addresses with IBGP. For this example, the objective is to demonstrate configuring IBGP neighbors and verifying the configuration. Figure 8-23 shows the scenario for two routers in the same AS. This example uses the IP address of a physical interface in the neighbor command.

Figure 8-23. IBGP Neighbor Relationship

Router A

router bgp 1

 neighbor 10.1.1.2 remote-as 1

__________________________________________________________________________

Router B

router bgp 1

 neighbor 10.1.1.1 remote-as 1

Notice that the only differences from the EBGP configuration are the remote AS number that is used on Router A and the BGP process number on Router B.

Verification

To verify that the neighbor relationship has been established, use the show ip bgp neighbors command (see section 14-90):

RtrA#show ip bgp neighbors

BGP neighbor is 10.1.1.2,  remote AS 1, internal link

 Index 0, Offset 0, Mask 0x0

  BGP version 4, remote router ID 10.1.1.2

  BGP state = Established, table version = 2, up for 00:17:01

  Last read 00:00:01, hold time is 180, keepalive interval is 60 seconds

  Minimum time between advertisement runs is 5 seconds

  Received 24 messages, 0 notifications, 0 in queue

  Sent 24 messages, 0 notifications, 0 in queue

  Connections established 2; dropped 1

Connection state is ESTAB, I/O status: 1, unread input bytes: 0

Local host: 172.16.1.3, Local port: 179

Foreign host: 172.16.1.7, Foreign port: 11001

The link type is now internal because we have established a BGP session between two routers in the same autonomous system. As with EBGP, the only errors that can occur are using the wrong neighbor IP address or using the wrong neighbor AS number.

Troubleshooting

Troubleshooting for IBGP neighbors is identical to troubleshooting EBGP neighbors. Remember, if you can ping the neighbor, you should be able to establish an IBGP connection if it’s configured properly.

< Free Open Study >