Symptoms
When a Cisco BGP neighbor relationship fails to come up, you will typically observe one or more of the following indicators:
- The BGP neighbor state is permanently stuck in Idle, Active, or Connect when running
show bgp summary
orshow ip bgp summary
- The Up/Down column shows never or repeatedly resets within seconds, indicating a flapping or refused session
- Syslog messages referencing BGP NOTIFICATION errors, TCP connection failures, or MD5 authentication rejections
- Routes expected from the peer are absent from the BGP table when running
show ip bgp
orshow bgp ipv4 unicast
- Traffic blackholing, asymmetric routing, or missing prefixes in the global routing table affecting production traffic
A quick first check is always
show bgp summary:
Router# show bgp summary
BGP router identifier 10.255.0.1, local AS number 65001
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.255.0.2 4 65002 0 0 0 0 0 never Active
10.0.1.5 4 65003 0 0 0 0 0 never IdleState Active means the local router is actively attempting to open a TCP connection to the peer but has not yet succeeded — the TCP handshake is either failing or being refused. State Idle means BGP is not even attempting a connection, which usually points to a missing route to the neighbor, an administrative shutdown, or a repeated connection failure causing the router to back off. Both states demand immediate investigation using the methodology in this article.
Root Cause 1: ASN Mismatch
Why It Happens
BGP uses the Autonomous System Number (ASN) as a fundamental part of its peer identification. When two routers exchange BGP OPEN messages to establish a session, each OPEN message carries the sender's ASN. The receiving router compares that value against what was configured locally with the
neighbor remote-ascommand. If the values do not match, the router sends a BGP NOTIFICATION message with error code 2 (Open Message Error), subcode 2 (Bad Peer AS), and immediately tears down the session. The connection never progresses past the OpenSent state.
This is one of the most frequent misconfigurations encountered in production, especially following ASN migrations, peering with new service providers, or when a peer renumbers their network.
How to Identify It
Check the syslog buffer for BGP NOTIFICATION messages:
Router-A# show logging | include BGP
%BGP-3-NOTIFICATION: sent to neighbor 10.255.0.2 2/2 (Open Message Error/bad peer AS) 2 bytes 65002
%BGP-5-ADJCHANGE: neighbor 10.255.0.2 Down BGP Notification sentVerify what each side believes the peer's ASN to be:
Router-A# show bgp neighbors 10.255.0.2 | include remote AS
BGP neighbor is 10.255.0.2, remote AS 65002, external linkRouter-B# show bgp neighbors 10.255.0.1 | include remote AS
BGP neighbor is 10.255.0.1, remote AS 65099, external linkRouter-A expects Router-B to be AS 65002 and correctly identifies itself as AS 65001. Router-B expects Router-A to be AS 65099 — but Router-A is AS 65001. This single-digit discrepancy prevents the session from ever forming.
How to Fix It
Correct the
neighbor remote-asstatement on whichever side has the incorrect value. In this example, Router-B has the wrong ASN for Router-A:
Router-B# configure terminal
Router-B(config)# router bgp 65002
Router-B(config-router)# no neighbor 10.255.0.1 remote-as 65099
Router-B(config-router)# neighbor 10.255.0.1 remote-as 65001
Router-B(config-router)# end
Router-B# show bgp neighbors 10.255.0.1 | include BGP state
BGP state = Established, up for 00:00:08After correcting the ASN, the session should negotiate and transition through OpenSent → OpenConfirm → Established within a few seconds.
Root Cause 2: TCP Port 179 Blocked
Why It Happens
BGP relies entirely on TCP port 179 for its transport layer. Before any BGP OPEN, UPDATE, or KEEPALIVE messages can be exchanged, a standard TCP three-way handshake must complete successfully between the two peers. If an ACL, firewall rule, Zone-Based Firewall (ZBF) policy, or external stateful firewall is blocking TCP port 179 in either direction, the TCP session will never establish. BGP will remain permanently in the Active or Connect state, periodically retrying and failing.
This is frequently encountered when BGP is deployed across a firewall segment, when security hardening is applied to transit interfaces, or when a new peer is added to the BGP configuration without updating the corresponding ACLs on intervening devices.
How to Identify It
Test TCP reachability directly using telnet to port 179:
Router-A# telnet 10.255.0.2 179 /source-interface Loopback0
Trying 10.255.0.2, 179 ...
% Connection timed out; remote host not respondingA timeout — rather than an immediate reset — strongly suggests a stateless ACL or stateful firewall is silently dropping the packet. Check any ACL applied to the relevant outbound interface:
Router-A# show ip interface GigabitEthernet0/1 | include access list
Inbound access list is TRANSIT-IN
Outbound access list is not set
Router-A# show access-list TRANSIT-IN
Extended IP access list TRANSIT-IN
10 permit icmp any any
20 permit tcp any any established
30 deny tcp any any eq 179
40 permit ip any anyLine 30 is explicitly denying TCP destination port 179 — the BGP port is blocked inbound on this interface, preventing the peer's TCP SYN-ACK from reaching the local BGP process.
How to Fix It
Add a permit statement for TCP port 179 scoped to the known peer address before the deny rule:
Router-A# configure terminal
Router-A(config)# ip access-list extended TRANSIT-IN
Router-A(config-ext-nacl)# no 30
Router-A(config-ext-nacl)# 25 permit tcp host 10.255.0.2 host 10.255.0.1 eq 179
Router-A(config-ext-nacl)# 26 permit tcp host 10.255.0.2 eq 179 host 10.255.0.1
Router-A(config-ext-nacl)# 30 deny tcp any any eq 179
Router-A(config-ext-nacl)# endAlways permit both directions: the remote peer may initiate the TCP SYN to destination port 179, or it may respond to a local SYN with source port 179. Both patterns must be allowed for reliable BGP operation.
Root Cause 3: Wrong Update-Source Configuration
Why It Happens
When BGP neighbors are configured using loopback IP addresses — a recommended best practice for session resilience — the local router must be explicitly instructed which source IP address to use when originating BGP TCP connections. By default, IOS and IOS-XE source BGP packets from the IP address of the best outgoing physical interface toward the destination. If the peer has a neighbor statement configured for the loopback IP (e.g., 10.255.0.1) but incoming TCP connections arrive from the physical interface IP (e.g., 10.1.12.1), the remote router finds no matching neighbor entry and silently drops the connection. The originating router sees the session fail and retries indefinitely in the Active state.
How to Identify It
Check which local address BGP is currently using for the peering session:
Router-A# show bgp neighbors 10.255.0.2
BGP neighbor is 10.255.0.2, remote AS 65002, external link
BGP state = Active
Local address: 10.1.12.1
Local host: 10.1.12.1, Local port: 47823
Foreign host: 10.255.0.2, Foreign port: 179The local address is 10.1.12.1 (the physical interface IP) — not the loopback 10.255.0.1. Router-B has a neighbor statement only for 10.255.0.1, so it rejects connections from 10.1.12.1 with a TCP reset. Confirm the update-source is absent:
Router-A# show running-config | section router bgp
router bgp 65001
neighbor 10.255.0.2 remote-as 65002
(update-source is missing)How to Fix It
Add the
update-sourcecommand referencing the loopback interface on both sides:
Router-A# configure terminal
Router-A(config)# router bgp 65001
Router-A(config-router)# neighbor 10.255.0.2 update-source Loopback0
Router-A(config-router)# end
Router-B# configure terminal
Router-B(config)# router bgp 65002
Router-B(config-router)# neighbor 10.255.0.1 update-source Loopback0
Router-B(config-router)# endVerify the local address changes to the loopback immediately after the configuration is applied:
Router-A# show bgp neighbors 10.255.0.2 | include Local address
Local address: 10.255.0.1Root Cause 4: Multihop Not Configured for eBGP
Why It Happens
External BGP (eBGP) sessions default to a Time to Live (TTL) value of 1 on outgoing TCP packets. This is an intentional design decision: eBGP is built for directly connected peers, and a TTL of 1 ensures that the BGP packet can traverse exactly one hop before the TTL expires and the packet is discarded. When loopback addresses are used for eBGP peering, or when the eBGP peer is reached through one or more intermediate routers, BGP packets hit TTL=0 before reaching the destination and are dropped by the intermediate router. The BGP session remains permanently in the Active state with no error message on the originating router to clearly identify the cause.
Internal BGP (iBGP) uses TTL 255 by default and is not affected by this constraint.
How to Identify It
Confirm the peer is reachable at the IP layer but BGP still will not come up:
Router-A# ping 10.255.0.2 source Loopback0 repeat 5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 msCheck how many hops are between the two loopbacks:
Router-A# traceroute 10.255.0.2 source Loopback0
1 10.1.12.2 2 msec 2 msec 1 msec
2 10.255.0.2 3 msec 2 msec 3 msecTwo hops are required. Confirm the current TTL limit BGP is enforcing:
Router-A# show bgp neighbors 10.255.0.2 | include hop
External BGP neighbor may be up to 1 hop away.TTL is set to 1 but 2 hops are required — every BGP packet expires at the first transit hop and never reaches the peer's BGP process.
How to Fix It
Configure
ebgp-multihopon both routers with a TTL equal to or greater than the actual hop count. For two hops, a value of 2 is sufficient:
Router-A# configure terminal
Router-A(config)# router bgp 65001
Router-A(config-router)# neighbor 10.255.0.2 ebgp-multihop 2
Router-A(config-router)# end
Router-B# configure terminal
Router-B(config)# router bgp 65002
Router-B(config-router)# neighbor 10.255.0.1 ebgp-multihop 2
Router-B(config-router)# endAlways use the minimum hop count necessary. Setting
ebgp-multihop 255is a common shortcut but removes a meaningful security control. Set it precisely to the known hop count of your topology.
Root Cause 5: TTL Security (GTSM) Misconfiguration
Why It Happens
Generalized TTL Security Mechanism (GTSM), configured via
neighbor ttl-security hops, is a BGP hardening feature that instructs the router to silently drop any incoming BGP TCP segments whose TTL value is less than 255 minus the configured hop count. For example, with
ttl-security hops 1, only packets with TTL ≥ 254 are accepted. To achieve this, GTSM also sets the outgoing TTL to 255 rather than the default eBGP value of 1.
Problems arise when GTSM is configured asymmetrically: one side has it enabled and the other does not. The side with GTSM enabled sends packets with TTL 255 (which the non-GTSM side accepts), but the non-GTSM side sends packets with TTL 1, which the GTSM-enabled side drops because TTL 1 is far below the minimum threshold of 254. The session fails in one direction only, which can be confusing to diagnose. Additionally,
ttl-securityand
ebgp-multihopare mutually exclusive in most IOS versions — attempting to configure both simultaneously will generate an error.
How to Identify It
Check whether GTSM is configured on the BGP neighbor and what threshold is enforced:
Router-A# show bgp neighbors 10.0.1.2 | include TTL
External BGP neighbor may be up to 1 hop away.
TTL security: enabled, hop count: 1, minimum expected TTL: 254Router-B# show bgp neighbors 10.0.1.1 | include TTL
External BGP neighbor may be up to 1 hop away.
(TTL security not configured on this side)Router-A is expecting incoming BGP packets with TTL ≥ 254. Router-B sends packets with default TTL of 1, which Router-A discards. Watch the connection drop counter increment:
Router-A# show bgp neighbors 10.0.1.2 | include Connections
Connections established 0; dropped 6
Last reset neverHow to Fix It
Either mirror the GTSM configuration on both sides, or remove it from the misconfigured peer. To match it on Router-B:
Router-B# configure terminal
Router-B(config)# router bgp 65002
Router-B(config-router)# neighbor 10.0.1.1 ttl-security hops 1
Router-B(config-router)# endTo remove it from Router-A if GTSM is not a deliberate policy requirement:
Router-A# configure terminal
Router-A(config)# router bgp 65001
Router-A(config-router)# no neighbor 10.0.1.2 ttl-security hops 1
Router-A(config-router)# endRoot Cause 6: Loopback Address Unreachable
Why It Happens
Loopback-based BGP peering is highly recommended because loopback interfaces are not tied to a physical link — if one physical path fails but alternate paths exist, the BGP session can survive the failure. However, this topology only works if each router has a valid IP route to the peer's loopback address installed in its routing table. That route must arrive via an IGP (OSPF, EIGRP, IS-IS) or an explicit static route. If the route is absent — because the loopback was never added to the IGP process, the IGP adjacency is down, a network statement is too narrow, or a redistribution policy is filtering the prefix — TCP will never connect and BGP will remain in the Active state.
How to Identify It
Attempt a sourced ping from the local loopback to the peer's loopback:
Router-A# ping 10.255.0.2 source Loopback0
.....
Success rate is 0 percent (0/5)Check the routing table for the peer's loopback prefix:
Router-A# show ip route 10.255.0.2
% Network not in tableThe route is completely absent. Investigate the IGP to understand why:
Router-A# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
(empty output)No OSPF neighbors are forming, so no loopback routes are being learned. Or, if OSPF is running but the loopback is excluded from the process:
Router-B# show running-config | section router ospf
router ospf 1
network 10.1.12.0 0.0.0.255 area 0
(loopback 10.255.0.2/32 is not covered by any network statement)How to Fix It
Option 1 — Add the loopback subnet to the OSPF process on Router-B so the prefix is advertised to Router-A:
Router-B# configure terminal
Router-B(config)# router ospf 1
Router-B(config-router)# network 10.255.0.2 0.0.0.0 area 0
Router-B(config-router)# endOption 2 — Use a static route on Router-A pointing to Router-B's loopback via the known physical next-hop:
Router-A# configure terminal
Router-A(config)# ip route 10.255.0.2 255.255.255.255 10.1.12.2
Router-A(config)# endAfter the route is installed, verify reachability before expecting BGP to converge:
Router-A# show ip route 10.255.0.2
Routing entry for 10.255.0.2/32
Known via "ospf 1", distance 110, metric 2
Last update from 10.1.12.2 on GigabitEthernet0/1, 00:00:04 ago
Router-A# ping 10.255.0.2 source Loopback0 repeat 5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/3 msRoot Cause 7: BGP MD5 Authentication Mismatch
Why It Happens
BGP supports MD5 TCP segment authentication via the
neighbor passwordcommand. When configured, each TCP segment in the BGP session is signed with an MD5 hash derived from the password. If one side has a password configured and the other does not, or if both sides have different passwords, the TCP MD5 signature verification fails. The kernel discards the segment silently and the BGP session never establishes. This is particularly tricky to diagnose because the failure occurs at the TCP layer before any BGP messages are exchanged.
How to Identify It
Router-A# show logging | include BADAUTH
%TCP-6-BADAUTH: No MD5 digest from 10.0.1.5(179) to 10.0.1.1(52341) tableid 0
%TCP-6-BADAUTH: Invalid MD5 digest from 10.0.1.5(179) to 10.0.1.1(52341) tableid 0The first message means Router-A expects MD5 but Router-B is not sending it. The second means both sides are sending MD5 but the hash values do not match — a password mismatch.
How to Fix It
Ensure both sides are configured with the exact same password. BGP passwords are case-sensitive:
Router-A(config)# router bgp 65001
Router-A(config-router)# neighbor 10.0.1.5 password Str0ng$ecret99
Router-B(config)# router bgp 65003
Router-B(config-router)# neighbor 10.0.1.1 password Str0ng$ecret99Root Cause 8: Neighbor Not Activated in Address Family
Why It Happens
On IOS-XE routers using explicit address-family blocks, a neighbor must be activated within the specific address family (e.g.,
address-family ipv4 unicast) using the
activatecommand before prefix exchange can occur. The BGP session itself may reach the Established state — the TCP and BGP control plane connection works — but no prefixes are exchanged because the address family negotiation fails or the neighbor is simply not enabled for that AFI/SAFI. This manifests as an Established session with 0 received prefixes.
How to Identify It
Router-A# show bgp ipv4 unicast summary | include 10.0.0.2
10.0.0.2 4 65002 50 48 0 0 0 00:41:15 0
Router-A# show running-config | section address-family ipv4
address-family ipv4
neighbor 10.0.0.3 activate
(neighbor 10.0.0.2 is missing from this block)How to Fix It
Router-A(config)# router bgp 65001
Router-A(config-router)# address-family ipv4 unicast
Router-A(config-router-af)# neighbor 10.0.0.2 activate
Router-A(config-router-af)# endPrevention
The majority of BGP neighbor establishment failures are preventable with disciplined configuration practices and proactive monitoring. Apply the following controls in your environment:
- Always use loopbacks with explicit update-source. Every BGP neighbor statement using a loopback IP must be paired with
neighbor X.X.X.X update-source Loopback0
. Make this a mandatory checklist item in your BGP change procedure. - Verify end-to-end loopback reachability before configuring BGP. Before committing any neighbor statement, confirm that
ping <peer-loopback> source Loopback0
returns 100% success. If it fails, fix the IGP first. - Standardize multihop and TTL security values in peer templates. Use
template peer-policy
or peer-group configurations to enforce consistentebgp-multihop
andttl-security
values. This prevents the asymmetric GTSM misconfiguration scenario. - Audit ACLs before adding any new BGP peer. For every new neighbor, check all ACLs and ZBF policies on the peering interface and any transit devices. Explicitly verify that TCP port 179 is permitted in both directions.
- Maintain an ASN registry. Keep a documented ASN and IP addressing table accessible to all network engineers at a known internal location such as wiki.solvethenetwork.com. Reference it during every BGP change review.
- Test with soft-clear before hard-clear. When verifying a fix, use
clear ip bgp X.X.X.X soft
rather than a hard reset. Hard resets drop and re-establish the TCP session; soft resets only refresh the BGP table. - Enable BGP session monitoring. Alert on any BGP neighbor that transitions away from Established. SNMP trap on
bgpBackwardTransition
, or use streaming telemetry if available on your platform. - Use
neighbor shutdown
for maintenance, not configuration removal. Taking a session down cleanly withneighbor X.X.X.X shutdown
preserves the full configuration for quick re-enabling and avoids re-entry errors.
Frequently Asked Questions
Q: What is the difference between BGP state Idle and BGP state Active?
A: Idle means BGP is not attempting any connection at all — usually because there is no route to the peer, the session is administratively shut down, or BGP is backing off after repeated failures. Active means BGP is actively sending TCP SYN packets trying to open a connection but has not yet received a SYN-ACK back. Active is a transient state that becomes permanent when something (an ACL, a missing route, a TTL issue) prevents the TCP handshake from completing.
Q: Can I run ebgp-multihop and ttl-security on the same neighbor?
A: No. These two commands are mutually exclusive in IOS and IOS-XE. Attempting to configure both on the same neighbor will result in an error:
%BGP: Cannot configure both ebgp-multihop and ttl-security. Use
ttl-securityfor directly connected eBGP peers as a security hardening measure, and use
ebgp-multihopwhen the eBGP peer is reachable over multiple hops such as via loopback peering.
Q: How do I reset a BGP session without fully tearing down the TCP connection?
A: Use a soft reset:
clear ip bgp X.X.X.X softto reset both inbound and outbound, or use
soft in/
soft outto reset only one direction. Soft resets re-apply inbound or outbound route policies without dropping the TCP session or the peer relationship. A hard reset (
clear ip bgp X.X.X.X) drops the TCP connection entirely and causes a full BGP reconvergence.
Q: Why does BGP use TCP instead of UDP?
A: BGP uses TCP (port 179) because TCP provides reliable, ordered delivery of large UPDATE messages containing routing tables. BGP does not need to handle its own retransmission logic, sequencing, or fragmentation — TCP handles all of this. A single BGP UPDATE can carry thousands of prefixes, making reliable delivery critical. The cost is that a TCP session failure (due to a transient network event) results in a full BGP session teardown and reconvergence.
Q: How long should it take for a BGP session to reach Established after fixing the root cause?
A: In most cases, a corrected BGP session will move through Connect → OpenSent → OpenConfirm → Established within 5 to 30 seconds. The exact timing depends on the BGP connect timer (default 32 seconds if the peer was previously in a back-off state), the TCP retransmit timer, and whether the
bgp fast-external-falloverfeature is active. If the session does not come up within 60 seconds of a fix, re-check for secondary issues.
Q: What is the BGP hold timer and can it cause the session to not establish?
A: The hold timer determines how long a router waits for a KEEPALIVE or UPDATE before declaring the peer dead. During the OPEN message exchange, both sides negotiate the hold timer to the lower of the two configured values (default 180 seconds, with a KEEPALIVE sent every 60 seconds). A hold timer mismatch alone will not prevent a session from forming, but a hold timer of 0 (which disables keepalives) configured on only one side can cause the other side to drop the session. Verify with
show bgp neighbors X.X.X.X | include hold.
Q: Does iBGP also require update-source and multihop configuration?
A: The
update-sourcecommand is equally important for iBGP when using loopback addresses for peering — without it, iBGP packets will be sourced from the physical interface and rejected by the peer. However, iBGP does not require
ebgp-multihopbecause iBGP already uses TTL 255 by default, which allows packets to traverse any number of hops within the AS.
Q: Can BGP operate without a running IGP?
A: Yes, but only for directly connected peering or when static routes are used to provide reachability to peer addresses. In practice, production BGP deployments using loopback addresses depend on an IGP (OSPF or EIGRP) to distribute loopback routes within the AS. Without an IGP or static routes, loopback-based BGP peering will always fail with an unreachable peer.
Q: How do I verify which prefixes a BGP neighbor is actually sending to me?
A: Use
show bgp ipv4 unicast neighbors X.X.X.X received-routesto see all routes the peer has sent before local inbound policy is applied. Use
show bgp ipv4 unicast neighbors X.X.X.X routesto see routes after the inbound policy is applied and installed. Note that
received-routesrequires
neighbor X.X.X.X soft-reconfiguration inboundto be configured, or you can use
show bgp ipv4 unicast neighbors X.X.X.X receivedon platforms that support route refresh.
Q: What is BGP graceful restart and does it affect neighbor establishment?
A: BGP Graceful Restart (RFC 4724) allows a BGP speaker to retain forwarding state during a control-plane restart, preventing traffic blackholing during router reload or process restart. It is negotiated in the BGP OPEN message via capabilities advertisement. A misconfigured or unsupported graceful restart capability can occasionally cause capability negotiation issues, but this rarely prevents session establishment entirely. Disable it with
no bgp graceful-restartif you suspect it is contributing to a session problem.
Q: How do I use BGP peer templates to avoid these misconfigurations at scale?
A: IOS-XE supports peer session and peer policy templates. Define a session template with the common session-level attributes such as
update-source,
ebgp-multihop,
ttl-security, and
password, then inherit it on each neighbor:
neighbor X.X.X.X inherit peer-session PEER-SESSION-TEMPLATE. This ensures every peer gets a consistent baseline configuration and eliminates the risk of forgetting a critical command on a per-neighbor basis.
Q: The BGP session keeps flapping every few minutes. What should I check first?
A: A flapping BGP session that briefly reaches Established before dropping points to a different class of problem than a session that never comes up. Common causes of flapping include: hold timer expiry due to high CPU or congestion dropping KEEPALIVE packets, interface instability on the peering path, MD5 authentication failures caused by a password being changed on one side only, and route policy misconfigurations causing notification messages to be sent. Start with
show bgp neighbors X.X.X.X | include notificationand
show logging | include BGPto find the notification error code that is terminating each session.