Cisco BGP Neighbor Down: Troubleshooting Guide

When a BGP neighbor goes down on a Cisco router, finding the root cause can take hours of SSH sessions, show commands, and log analysis. This guide covers common causes and how to diagnose them — manually and with Inishi.

Quick Diagnosis with Inishi

If you're using Inishi, just ask:

"Why is the BGP neighbor 10.0.0.2 down on router-01?"

Inishi will:

1. Gather BGP state, interface status, and logs
2. Correlate the data to find root cause
3. Show you the evidence
4. Suggest next steps

Skip the manual troubleshooting below and try Inishi free → (opens in a new tab)

Manual Troubleshooting

Step 1: Check BGP Neighbor State

router-01# show ip bgp summary
BGP router identifier 10.0.0.1, local AS number 65000
BGP table version is 142, main routing table version 142
3 network entries using 432 bytes of memory
3 path entries using 264 bytes of memory

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.2        4 65001       0       0        1    0    0 never    Idle
10.0.0.3        4 65002   14523   14521      142    0    0 2d12h    3

Key indicators:

• Idle — BGP not attempting to connect
• Active — BGP trying to connect but failing
• Connect — TCP connection in progress
• OpenSent / OpenConfirm — BGP messages being exchanged

Step 2: Check Interface Status

router-01# show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0     10.0.0.1        YES manual up                    up
GigabitEthernet0/1     10.1.0.1        YES manual up                    down
Loopback0              192.168.1.1     YES manual up                    up

If the interface to the BGP peer is down, that's your problem.

Step 3: Check Connectivity

router-01# ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

No connectivity = BGP won't establish.

Step 4: Check BGP Configuration

router-01# show running-config | section router bgp
router bgp 65000
 bgp router-id 10.0.0.1
 neighbor 10.0.0.2 remote-as 65001
 neighbor 10.0.0.2 update-source GigabitEthernet0/1

Common config issues:

• Wrong remote AS number
• Wrong update-source interface
• Missing network statements
• Route-map blocking advertisements

Step 5: Check Logs

router-01# show log | include BGP
*Jan 15 14:32:05.123: %BGP-5-ADJCHANGE: neighbor 10.0.0.2 Down Interface flap
*Jan 15 14:32:05.124: %BGP-3-NOTIFICATION: sent to neighbor 10.0.0.2 6/4 (cease)

Common Causes and Fixes

1. Interface Down

Symptoms:

• Neighbor state: Idle
• Interface status: down/down

Diagnosis:

show interface GigabitEthernet0/1

Common fixes:

• Check physical cable
• Check SFP module
• Verify port is not shut down (no shutdown)
• Check for CRC/input errors (physical layer issue)

2. Mismatched AS Numbers

Symptoms:

• Neighbor state: Idle or Active
• Logs show Bad AS or Peer closed session

Diagnosis:

show running-config | include remote-as

Fix: Verify the AS number matches what the peer is configured with:

router bgp 65000
 neighbor 10.0.0.2 remote-as 65001  ! Verify this matches peer's local AS

3. Update-Source Mismatch

Symptoms:

• Neighbor state: Active
• TCP connection times out

Diagnosis:

show ip bgp neighbor 10.0.0.2
  BGP state = Active
  Last reset 00:05:32, due to Active open failed

Fix: Ensure both peers use the same update-source (usually Loopback):

neighbor 10.0.0.2 update-source Loopback0

4. Authentication Mismatch

Symptoms:

• Neighbor state: Active
• Logs show MD5 authentication failed

Diagnosis:

show ip bgp neighbor 10.0.0.2 | include password

Fix: Verify MD5 password matches on both peers:

neighbor 10.0.0.2 password 7 <encrypted-password>

5. ACL Blocking BGP

Symptoms:

• Neighbor state: Active
• TCP port 179 blocked

Diagnosis:

show access-lists
show ip interface GigabitEthernet0/1 | include access

Fix: Add permit statement for BGP traffic:

access-list 100 permit tcp host 10.0.0.2 host 10.0.0.1 eq bgp
access-list 100 permit tcp host 10.0.0.2 eq bgp host 10.0.0.1

6. Hold Timer Expired

Symptoms:

• Neighbor state: was Established, now Idle
• Logs show Hold time expired

Diagnosis:

show ip bgp neighbor 10.0.0.2 | include timer

Common causes:

• High CPU on either peer
• Packet loss between peers
• Control plane policing dropping BGP

Fix:

• Check CPU utilization
• Verify path quality
• Adjust hold timer if needed (not recommended without understanding impact)

Prevention: Automated Monitoring

Instead of waiting for users to report issues, set up proactive monitoring:

With Inishi

Inishi can monitor BGP neighbor state and alert you before users notice:

1. Enable health polling for your routers
2. Inishi checks BGP state every 5 minutes
3. Get alerts when neighbors flap or go down

Set up monitoring → (opens in a new tab)

With Syslog

Configure syslog to send BGP events to your monitoring system:

router-01(config)# logging trap informational
router-01(config)# logging host 10.0.100.1
router-01(config)# logging source-interface Loopback0

Summary

Let Inishi Do the Work

Manual troubleshooting works, but it's slow. With Inishi:

• Ask "Why is BGP down?" in plain English
• Get root cause analysis in seconds
• See proposed fixes before they run
• Keep a full audit trail

Start your free trial → (opens in a new tab) — 14 days, 5 devices, no credit card required.