For the CCNP ENCOR exam, troubleshooting BGP requires a methodical approach that moves through the OSI layers. Unlike IGPs, BGP won't even attempt to start a session if TCP Port 179 is blocked or if there is no underlying IP reachability.
Here is the professional workflow for troubleshooting BGP neighbor issues.
1. The BGP State Machine Check
First, identify exactly where the process is failing by using show ip bgp summary.
Idle: The router is searching the routing table for a route to the neighbor.
Active: The router is attempting to initiate a TCP connection with the neighbor but failing.
Established: The session is up and prefixes are being exchanged.
2. Layer 3 Reachability (The "Idle" State)
If the neighbor is in Idle, the router doesn't know how to reach the neighbor's IP address.
Example Scenario: R1 (1.1.1.1) trying to peer with R2 (2.2.2.2) via Loopbacks.
The Problem: R1 has no route to
2.2.2.2.The Fix: Ensure an IGP (OSPF/EIGRP) or a static route exists.
PlaintextR1# ping 2.2.2.2 source loopback 0 # If this fails, fix the routing table before touching BGP.
3. TCP & Security (The "Active" State)
If the neighbor is in Active, the routers can "see" each other, but the TCP 3-way handshake is failing.
Common Culprits:
Access Control Lists (ACLs): Ensure TCP Port 179 is permitted in both directions.
Source Interface Mismatch: If peering via Loopbacks, you must tell the router to use the Loopback IP as the source.
Fix:
neighbor 2.2.2.2 update-source Loopback0
EBGP Multihop: By default, EBGP packets have a TTL of 1. If peering via Loopbacks or across multiple hops, the packet expires before it arrives.
Fix:
neighbor 2.2.2.2 ebgp-multihop 2
Authentication Mismatch: Password MD5 hashes must match exactly.
Fix: Check
neighbor [IP] password [STRING]on both sides.
4. BGP Capability Mismatch
Even if TCP is established, BGP might stay in OpenSent or OpenConfirm if the parameters don't match.
AS Number Mismatch: Verify the
remote-asconfigured on R1 matches therouter bgp [AS]on R2.BGP Identifier (Router ID): If two routers have the same Router ID, the session will flap or fail.
5. Troubleshooting Example: The "Stuck in Active" Lab
Imagine you are at the ENCOR exam console. R1 and R2 are EBGP neighbors connected via their physical Gi0/1 interfaces.
Step 1: Check Summary
R1# show ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 200 0 0 1 0 0 never Active
Step 2: Check IP Connectivity
R1# ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5)
Conclusion: Layer 3 is fine. The issue is BGP-specific.
Step 3: Check Configuration
R1# show run | section bgp
router bgp 100
neighbor 2.2.2.2 remote-as 200
R2# show run | section bgp
router bgp 200
neighbor 1.1.1.1 remote-as 100
Observation: The IPs and AS numbers look correct.
Step 4: Deep Dive into the Neighbor State
R1# show ip bgp neighbors 2.2.2.2
BGP neighbor is 2.2.2.2, remote AS 200, external link
BGP version 4, remote router ID 0.0.0.0
BGP state = Active
Last read 00:00:05, last write 00:00:02, hold time is 180, keepalive interval is 60 seconds
Step 5: Check for ACLs or Misconfigurations
You find that R2 is using a Loopback interface for its Router ID, but R1 is expecting the connection from the physical interface IP.
The Resolution:
If you find the state is flapping, check the logs:
R1# show logging | include BGP
If you see "Connection refused by remote host", it's almost always a source-interface mismatch or an ACL on the remote router.
Summary Checklist for ENCOR
| Check | Command |
| Ping | ping [neighbor-ip] |
| TCP Port | telnet [neighbor-ip] 179 |
| Source IP | show run (Look for update-source) |
| TTL | show run (Look for ebgp-multihop) |
| Password | show ip bgp neighbors [IP] (Look for auth errors) |
