Introduction
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:
- The 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. You need to check your configurations.
- Unicast is broken due to one of these reasons:
- 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.
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 presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
Network Diagram
Use this network diagram as an example for the first three causes:
Conventions
The Neighbor Statement Is Incorrect
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
Here are the configurations:
| R1-AGS | R6-2500 |
|---|---|
interface Loopback0 ip address 2.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 1.1.1.1 255.255.255.255 10.10.10.2 | interface Loopback0 ip address 1.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 2.2.2.2 255.255.255.255 10.10.10.1 |
Debugs on Router R1-AGS:
BGP: 10.10.10.2 open active, local address 2.2.2.2 TCB00135978 created TCB00135978 setting property 0 16ABEA TCB00135978 bound to 2.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 1.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 2.2.2.2:11039 from 10.10.10.2:179 BGP: 10.10.10.1 open active, local address 1.1.1.1 TCB001E030C created TCB001E030C setting property TCP_WINDOW_SIZE (0) 194F7A TCB001E030C setting property TCP_TOS (11) 194F79 TCB001E030C bound to 1.1.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 1.1.1.1 remote-as 400 neighbor 1.1.1.1 update-source Loopback0 ! ip route 1.1.1.1 255.255.255.255 10.10.10.2 | router bgp 400 neighbor 2.2.2.2 remote-as 400 neighbor 2.2.2.2 update-source Loopback0 ! ip route 2.2.2.2 255.255.255.255 10.10.10.1 |
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 1.1.1.1 4 400 3 3 1 0 0 00:00:26 0
Note: If a BGP session is not establlished after a router reloads, configure the neighbor soft-reconfiguration statements under BGP in order to soft reset.
No Routes to the Neighbor Address Exist or the Default Route Is Used to Reach the Peer
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 1.1.1.1 4 400 0 0 0 0 0 never Active
Here are the configurations:
| R1-AGS | R6-2500 |
|---|---|
interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Serial1 ip address 10.10.10.1 255.255.255.0 ! router bgp 300 neighbor 1.1.1.1 remote-as 400 neighbor 1.1.1.1 ebgp-multihop 2 neighbor 1.1.1.1 update-source Loopback0 | interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Serial0 ip address 10.10.10.2 255.255.255.0 ! router bgp 400 neighbor 2.2.2.2 remote-as 300 neighbor 2.2.2.2 ebgp-multihop 2 neighbor 2.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: 1.1.1.1 open active, delay 9568ms BGP: 1.1.1.1 multihop open delayed 19872ms (no route) BGP: 1.1.1.1 multihop open delayed 12784ms (no route)
Debugs on Router R6-2500:
BGP: 2.2.2.2 open active, delay 6531ms BGP: 2.2.2.2 multihop open delayed 14112ms (no route) BGP: 2.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.
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 was used.
| R1-AGS | R6-2500 |
|---|---|
router bgp 300 neighbor 1.1.1.1 remote-as 400 neighbor 1.1.1.1 ebgp-multihop 2 neighbor 1.1.1.1 update-source Loopback0 ! ip route 1.1.1.1 255.255.255.255 10.10.10.2 | router bgp 400 neighbor 2.2.2.2 remote-as 300 neighbor 2.2.2.2 ebgp-multihop 2 neighbor 2.2.2.2 update-source Loopback0 ! ip route 2.2.2.2 255.255.255.255 10.10.10.1 |
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 1.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.
The update-source Command Is Missing Under BGP
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 1.1.1.1 4 400 0 0 0 0 0 never Active
Here are the configurations:
| R1-AGS | R6-2500 |
|---|---|
interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Serial1 ip address 10.10.10.1 255.255.255.0 ! router bgp 400 neighbor 1.1.1.1 remote-as 400 ! ip route 1.1.1.1 255.255.255.255 10.10.10.2 | interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Serial0 ip address 10.10.10.2 255.255.255.0 ! router bgp 400 neighbor 2.2.2.2 remote-as 400 ! ip route 2.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 2.2.2.2:179 BGP: 1.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 1.1.1.1:179, advertising MSS 536 TCP0: state was CLOSED -> SYNSENT [11042 -> 1.1.1.1(179)] TCP0: state was SYNSENT -> CLOSED [11042 -> 1.1.1.1(179)] TCP0: bad seg from 1.1.1.1 -- closing connection: seq 0 ack 4099938542 rcvnxt 0 rcvwnd 0 TCP0: connection closed - remote sent RST TCB0016B06C destroyed BGP: 1.1.1.1 open failed: Connection refused by remote host
Debugs on Router R6-2500:
BGP: 2.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 2.2.2.2:179, advertising MSS 556 TCP0: state was CLOSED -> SYNSENT [11018 -> 2.2.2.2(179)] TCP0: state was SYNSENT -> CLOSED [11018 -> 2.2.2.2(179)] TCP0: bad seg from 2.2.2.2 -- closing connection: seq 0 ack 2248020754 rcvnxt 0 rcvwnd 0 TCP0: connection closed - remote sent RST TCB 0x194800 destroyed BGP: 2.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 1.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.
Here, the update-source command is configured on both routers.
| R1-AGS | R6-2500 |
|---|---|
interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Serial1 ip address 10.10.10.1 255.255.255.0 ! router bgp 400 neighbor 1.1.1.1 remote-as 400 neighbor 1.1.1.1 update-source Loopback0 ! ip route 1.1.1.1 255.255.255.255 10.10.10.2 | interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Serial0 ip address 10.10.10.2 255.255.255.0 ! router bgp 400 neighbor 2.2.2.2 remote-as 400 neighbor 2.2.2.2 update-source Loopback0 ! ip route 2.2.2.2 255.255.255.255 10.10.10.1 |
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 2.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 2.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 1.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 |
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
