Contents

Introduction

Prerequisites

Requirements

Components Used

Conventions

Background Information

Network Diagram

Problem

Neighbor Statement Is Incorrect

Solution

Problem

No Routes to the Neighbor Address Exist or the Default Route Is Used to Reach the Peer

Solution

Problem

Update-source Command Is Missing Under BGP

Solution

Related Information

Introduction

This document describes issues that keep BGP neighborship from correctly being established.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Background Information

BGP routers can exchange routing information only when they establish peer connection between them.

The BGP peer establishment begins with the creation of a TCP connection between the devices.

After TCP connection established, the BGP devices attempt to create a BGP session by the exchange of BGP Open messages, where they exchange BGP version, AS number, hold time and BGP identifier.

On the process of BGP peer establishment, several things can prevent a BGP neighborship from correctly being established. This document discusses some of these possible reasons for this issue:

- Neighbor statement is incorrect.

- No routes to the neighbor address exist , or the default route (0.0.0.0/0) is being used to reach the peer.

- The update-source command is missing under BGP.

- A typing error resulted in the wrong IP address in the neighbor statement or the wrong autonomous system number. Check your configurations.

- Unicast is broken, some of the reasons are:

- Wrong virtual circuit (VC) mapping in an Asynchronous Transfer Mode (ATM) or Frame Relay environment in a highly redundant network.

- Access list is blocking the unicast or TCP packet.

- Network Address Translation (NAT) is running on the router and is translating the unicast packet.

- Layer 2 is down.

- The lack of the ebgp-multihop command is a common mistake that keep peers from appearing. This issue is discussed in the second example.

Network Diagram

Use this network diagram as an example for the first three causes:

Network Diagram

Problem

Neighbor Statement Is Incorrect

The show ip bgp summary  command on Router R1-AGS shows the session is active.

R1-AGS(9)#show ip bgp summary

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.10.10.2      4   400       0       0        0    0    0 never    Active

The configurations are:

R1-AGS

R6-2500

interface Loopback0

ip address 10.2.2.2 255.255.255.255

!

interface Serial1

ip address 10.10.10.1 255.255.255.0

!

router bgp 400

neighbor 10.10.10.2 remote-as 400

neighbor 10.10.10.2 update-source Loopback0

!

ip route 10.1.1.1 255.255.255.255 10.10.10.2

interface Loopback0

ip address 10.1.1.1 255.255.255.255

!

interface Serial0

ip address 10.10.10.2 255.255.255.0

!

router bgp 400

neighbor 10.10.10.1 remote-as 400

neighbor 10.10.10.1 update-source Loopback0

!

ip route 10.2.2.2 255.255.255.255 10.10.10.1

The debug ip bgp  and debug ip tcp transactions  commands show the TCP connection failing.

Debugs on Router R1-AGS:

BGP: 10.10.10.2 open active, local address 10.2.2.2

TCB00135978 created

TCB00135978 setting property 0 16ABEA

TCB00135978 bound to 10.2.2.2.11039

TCP: sending SYN, seq 3797113156, ack 0

TCP0: Connection to 10.10.10.2:179, advertising MSS 1460

TCP0: state was CLOSED -> SYNSENT [11039 -> 10.10.10.2(179)]

TCP0: state was SYNSENT -> CLOSED [11039 -> 10.10.10.2(179)]

TCP0: bad seg from 10.10.10.2 -- closing connection: seq 0 ack 3797113157 rcvnxt 0 rcvwnd 0

TCP0: connection closed - remote sent RST

TCB00135978 destroyed

BGP: 10.10.10.2 open failed: Connection refused by remote host

TCP: sending RST, seq 0, ack 1965664223

TCP: sent RST to 10.1.1.1:11016 from 10.10.10.1:179

Debugs on Router R6-2500:

TCP: sending RST, seq 0, ack 3797113157

TCP: sent RST to 10.2.2.2:11039 from 10.10.10.2:179

BGP: 10.10.10.1 open active, local address 10.1.1.1

TCB001E030C created

TCB001E030C setting property TCP_WINDOW_SIZE (0) 194F7A

TCB001E030C setting property TCP_TOS (11) 194F79

TCB001E030C bound to 10.10.1.1.11016

TCP: sending SYN, seq 1965664222, ack 0

TCP0: Connection to 10.10.10.1:179, advertising MSS 1460

TCP0: state was CLOSED -> SYNSENT [11016 -> 10.10.10.1(179)]

TCP0: state was SYNSENT -> CLOSED [11016 -> 10.10.10.1(179)]

TCP0: bad seg from 10.10.10.1 -- closing connection: seq 0 ack 1965664223 rcvnxt 0 rcvwnd 0

TCP0: connection closed - remote sent RST

TCB 0x1E030C destroyed

BGP: 10.10.10.1 open failed: Connection refused by remote host

Solution

In order to remedy this situation, either correct the loopback address in the neighbor statement, or remove the update-source command from the configuration.

In this example, the address is corrected.

R1-AGS

R6-2500

router bgp 400

neighbor 10.1.1.1 remote-as 400

neighbor 10.1.1.1 update-source Loopback0

!

ip route 10.1.1.1 255.255.255.255 10.10.10.2

router bgp 400

neighbor 10.2.2.2 remote-as 400

neighbor 10.2.2.2 update-source Loopback0

!

ip route 10.2.2.2 255.255.255.255 10.10.10.1

A look at the show ip bgp summary  command shows Router R1-AGS is in the established state.

R1-AGS(9)#show ip bgp summary

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.1.1.1         4   400       3       3        1    0    0 00:00:26        0

Problem

No Routes to the Neighbor Address Exist or the Default Route Is Used to Reach the Peer

The show ip bgp summary  command on Router R1-AGS shows the session is currently active.

R1-AGS(9)#show ip bgp summary

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.1.1.1         4   400       0       0        0    0    0 never    Active

The configurations are:

R1-AGS

R6-2500

interface Loopback0

ip address 10.2.2.2 255.255.255.255

!

interface Serial1

ip address 10.10.10.1 255.255.255.0

!

router bgp 300

neighbor 10.1.1.1 remote-as 400

neighbor 10.1.1.1 ebgp-multihop 2

neighbor 10.1.1.1 update-source Loopback0

interface Loopback0

ip address 10.1.1.1 255.255.255.255

!

interface Serial0

ip address 10.10.10.2 255.255.255.0

!

router bgp 400

neighbor 10.2.2.2 remote-as 300

neighbor 10.2.2.2 ebgp-multihop 2

neighbor 10.2.2.2 update-source Loopback0

If you run debug commands, it shows there is no route to the neighbor.

Debugs on Router R1-AGS:

BGP: 10.1.1.1 open active, delay 9568ms

BGP: 10.1.1.1 multihop open delayed 19872ms (no route)

BGP: 10.1.1.1 multihop open delayed 12784ms (no route)

Debugs on Router R6-2500:

BGP: 10.2.2.2 open active, delay 6531ms

BGP: 10.2.2.2 multihop open delayed 14112ms (no route)

BGP: 10.2.2.2 multihop open delayed 15408ms (no route)

Solution

The solution is to include a route to the next hop in the BGP neighbor statement. Use a static or dynamic route depending on the situation.

In an internal BGP (iBGP) environment where you have more control, you can propagate the route dynamically using a routing protocol.

In an external BGP (eBGP) situation, it is recommended to configure a static route to reach the next hop.

Note: Use the neighbor ebgp-multihop command only when the IP address you are peering to on your eBGP peer is not directly connected.

In this example, a static route is used.

R1-AGS

R6-2500

router bgp 300

neighbor 10.1.1.1 remote-as 400

neighbor 10.1.1.1 ebgp-multihop 2

neighbor 10.1.1.1 update-source Loopback0

!

ip route 10.1.1.1 255.255.255.255 10.10.10.2

router bgp 400

neighbor 10.2.2.2 remote-as 300

neighbor 10.2.2.2 ebgp-multihop 2

neighbor 10.2.2.2 update-source Loopback0

!

ip route 10.2.2.2 255.255.255.255 10.10.10.1

The show ip bgp summary  command shows Router R1-AGS is in the established state.

R1-AGS(9)#show ip bgp summary

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.1.1.1         4   400       3       3        1    0    0 00:00:26        0

Note: A default route is never going to be used to establish a BGP session (iBGP/eBGP), and you see the same (no route) output in the debugs, although you are able to ping the BGP neighbor. The solution is again to add a route to the BGP neighbor.

Problem

Update-source Command Is Missing Under BGP

The show ip bgp summary  command on Router R1-AGS shows the session is active.

R1-AGS(9)#show ip bgp summary

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.1.1.1         4   400       0       0        0    0    0 never    Active

The configurations are:

R1-AGS

R6-2500

interface Loopback0

ip address 10.2.2.2 255.255.255.255

!

interface Serial1

ip address 10.10.10.1 255.255.255.0

!

router bgp 400

neighbor 10.1.1.1 remote-as 400

!

ip route 10.1.1.1 255.255.255.255 10.10.10.2

interface Loopback0

ip address 10.1.1.1 255.255.255.255

!

interface Serial0

ip address 10.10.10.2 255.255.255.0

!

router bgp 400

neighbor 10.2.2.2 remote-as 400

!

ip route 10.2.2.2 255.255.255.255 10.10.10.1

If you run debug commands, it shows the TCP connection fails.

Debugs on Router R1-AGS:

TCP: sending RST, seq 0, ack 2248020754

TCP: sent RST to 10.10.10.2:11018 from 10.2.2.2:179

BGP: 10.1.1.1 open active, local address 10.10.10.1

TCB0016B06C created

TCB0016B06C setting property 0 16ADEA

TCB0016B06C bound to 10.10.10.1.11042

TCP: sending SYN, seq 4099938541, ack 0

TCP0: Connection to 10.1.1.1:179, advertising MSS 536

TCP0: state was CLOSED -> SYNSENT [11042 -> 10.1.1.1(179)]

TCP0: state was SYNSENT -> CLOSED [11042 -> 10.1.1.1(179)]

TCP0: bad seg from 10.1.1.1 -- closing connection: seq 0 ack 4099938542 rcvnxt 0 rcvwnd 0

TCP0: connection closed - remote sent RST

TCB0016B06C destroyed

BGP: 10.1.1.1 open failed: Connection refused by remote host

Debugs on Router R6-2500:

BGP: 10.2.2.2 open active, local address 10.10.10.2

TCB00194800 created

TCB00194800 setting property TCP_WINDOW_SIZE (0) E6572

TCB00194800 setting property TCP_TOS (11) E6571

TCB00194800 bound to 10.10.10.2.11018

TCP: sending SYN, seq 2248020753, ack 0

TCP0: Connection to 10.2.2.2:179, advertising MSS 556

TCP0: state was CLOSED -> SYNSENT [11018 -> 10.2.2.2(179)]

TCP0: state was SYNSENT -> CLOSED [11018 -> 10.2.2.2(179)]

TCP0: bad seg from 10.2.2.2 -- closing connection: seq 0 ack 2248020754 rcvnxt 0 rcvwnd 0

TCP0: connection closed - remote sent RST

TCB 0x194800 destroyed

BGP: 10.2.2.2 open failed: Connection refused by remote host

TCP: sending RST, seq 0, ack 4099938542

TCP: sent RST to 10.10.10.1:11042 from 10.1.1.1:179

Solution

In order to solve this problem, either configure the update-source command on both routers, or remove the update-source command and change the neighbor statement on both routers.

These are examples of both solutions.

The update-source command is configured on both routers:

R1-AGS

R6-2500

interface Loopback0

ip address 10.2.2.2 255.255.255.255

!

interface Serial1

ip address 10.10.10.1 255.255.255.0

!

router bgp 400

neighbor 10.1.1.1 remote-as 400

neighbor 10.1.1.1 update-source Loopback0

!

ip route 10.1.1.1 255.255.255.255 10.10.10.2

interface Loopback0

ip address 10.1.1.1 255.255.255.255

!

interface Serial0

ip address 10.10.10.2 255.255.255.0

!

router bgp 400

neighbor 10.2.2.2 remote-as 400

neighbor 10.2.2.2 update-source Loopback0

!

ip route 10.2.2.2 255.255.255.255 10.10.10.1

The show ip bgp summary   command shows Router R1-AGS is in the established state.

R1-AGS(9)#

show ip bgp summary

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.2.2.2         4   400       3       3        1    0    0 00:00:26        0

You only have to use the update-source command when someone is peering to your loopback address. This is true for an iBGP peer and an eBGP peer.

Here, the update-source command is removed and the neighbor statement is changed on both routers.

R1-AGS

R6-2500

interface Loopback0

ip address 10.2.2.2 255.255.255.255

!

interface Serial1

ip address 10.10.10.1 255.255.255.0

!

router bgp 400

neighbor 10.10.10.2 remote-as 400

interface Loopback0

ip address 10.1.1.1 255.255.255.255

!

interface Serial0

ip address 10.10.10.2 255.255.255.0

!

router bgp 400

neighbor 10.10.10.1 remote-as 400

The show ip bgp summary  command shows Router R1-AGS is in the established state.

R1-AGS(9)#show ip bgp summary

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.10.10.2      4   400       3       3        1    0    0 00:00:26        0

Related Information

- BGP Support Page

- Cisco Technical Support & Downloads