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:
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. You can 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