BGP (Border Gateway Protocol) is the routing protocol of the Internet, and in the CCNA 200-301 exam, you must be able to troubleshoot why a BGP peer won't form. This is a critical skill because BGP is used in enterprise networks for MPLS VPNs, Internet connectivity, and SD-WAN overlays. A BGP session that fails to establish can cause complete loss of connectivity, and the exam tests your ability to systematically diagnose the issue using show commands and knowledge of BGP states. Exam objective 3.6 covers BGP neighbor relationships and troubleshooting.
Jump to a section
Imagine two diplomats from neighboring countries trying to establish a formal alliance. First, they must agree on a meeting place (IP connectivity) — if one diplomat is in a different building, they can't even start. Once in the same room, they must agree on a common language (BGP version) — one speaks only French, the other only German, so they can't communicate. Next, they must verify each other's credentials (authentication) — if the passwords don't match, they refuse to shake hands. Then they must agree on the rules of engagement (hold timer and keepalive intervals) — one expects a handshake every 10 seconds, the other every 90 seconds, so one gives up waiting. Finally, they must agree on whose turn it is to speak (router ID and update-source) — if both think they are the same person (same router ID), they get confused. Each of these steps corresponds to a BGP state: Idle, Connect, Active, OpenSent, OpenConfirm, and Established. If any step fails, the session stays stuck in an earlier state, and the alliance never forms. The diplomat's assistant (the network engineer) must check each step with a checklist (show commands) to find where the breakdown occurs.
What is BGP Peer Formation?
BGP (Border Gateway Protocol) is a path-vector routing protocol used to exchange routing information between autonomous systems (AS). Before BGP can exchange routes, it must first establish a TCP connection (port 179) and then negotiate BGP capabilities. The process involves six states: Idle, Connect, Active, OpenSent, OpenConfirm, and Established. If any state transition fails, the session will not reach Established, and no routes are exchanged.
BGP States and Transition Steps
Idle: Initial state. BGP refuses all incoming connections. After a start event (e.g., neighbor command configured), BGP resets a connect-retry timer (default 60 seconds) and transitions to Connect.
Connect: BGP waits for the TCP connection to complete. If successful, it sends an OPEN message and transitions to OpenSent. If the TCP connection fails, it transitions to Active.
Active: BGP tries to initiate a TCP connection. If successful, it sends OPEN and goes to OpenSent. If the connect-retry timer expires, it goes back to Connect. This back-and-forth between Connect and Active indicates a TCP connectivity problem.
OpenSent: BGP has sent an OPEN message and is waiting for an OPEN from the peer. The OPEN message includes BGP version, AS number, hold time, router ID, and optional parameters. If the OPEN is received and matches parameters, BGP sends a KEEPALIVE and transitions to OpenConfirm.
OpenConfirm: BGP waits for a KEEPALIVE or NOTIFICATION. If KEEPALIVE is received, the session is Established. If NOTIFICATION is received, it falls back to Idle.
Established: BGP can exchange UPDATE messages. The hold timer (default 180 seconds) is maintained by receiving KEEPALIVE messages every 60 seconds (default keepalive interval).
Common Reasons for Peer Not Forming
IP Connectivity Issues: No route to the neighbor. The TCP three-way handshake cannot complete. Check with ping and traceroute. Use show ip bgp summary to see the state; if it's stuck in Active or Idle, suspect connectivity.
Incorrect BGP Configuration: Mismatched AS numbers (the remote AS must match the neighbor's configured local AS). Wrong neighbor IP address. Missing neighbor <ip> remote-as <asn> command.
EBGP Multihop Not Configured: For EBGP peers not directly connected (more than one hop away), you need neighbor <ip> ebgp-multihop <ttl>. Default TTL for EBGP is 1, so packets are dropped.
Update-Source Mismatch: BGP uses the best local IP to source TCP packets. If the neighbor expects a specific source IP (e.g., loopback), you must use neighbor <ip> update-source <interface>.
Router ID Duplication: Two BGP peers cannot have the same router ID. The router ID is derived from the highest loopback IP or highest physical IP, or set manually with bgp router-id <ip>.
Authentication Mismatch: If neighbor <ip> password <string> is configured on one side but not the other, or passwords differ, the session will fail. BGP uses MD5 authentication in TCP header.
TTL Security (GTSM): If neighbor <ip> ttl-security hops <count> is configured, packets with TTL less than 255 - hops are dropped. Mismatch causes failure.
Hold Timer Mismatch: BGP negotiates the hold timer: each side proposes its configured hold time, and the smaller value is used. However, if one side's configured hold time is 0 (meaning no keepalives), the session may reset if the other side expects keepalives.
Maximum Prefix Limit: If the neighbor sends more prefixes than the configured maximum-prefix limit, BGP sends a NOTIFICATION and tears down the session.
Access List Blocking TCP 179: An ACL on the router or a firewall between peers might block TCP port 179.
Verification Commands
show ip bgp summary – Shows neighbor IP, state, uptime, prefixes received.
show ip bgp neighbors <ip> – Detailed info: BGP version, router ID, timers, capabilities, messages.
debug ip bgp updates – Shows UPDATE messages (use with caution).
debug ip bgp keepalives – Shows KEEPALIVE exchange.
debug ip bgp events – Shows state transitions.
Example output of show ip bgp summary:
Router# show ip bgp summary
BGP router identifier 10.0.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
192.168.1.2 4 65002 0 0 0 0 0 never IdleIf the state is Idle, the session never started. If Active, TCP connection failed.
Step-by-Step Troubleshooting
When a BGP peer won't form, follow these steps:
1. Check IP connectivity with ping from the source interface that BGP uses.
2. Verify BGP configuration: show running-config | section router bgp.
3. Check show ip bgp summary for state.
4. If stuck in Active, check for ACLs blocking TCP 179.
5. Verify AS numbers, router IDs, update-source, and ebgp-multihop.
6. Check for authentication mismatch.
7. Check maximum-prefix and any BGP policies that might send NOTIFICATION.
8. Use debugs to see exactly where the failure occurs.
Check IP Connectivity
Use `ping` from the BGP source interface to the neighbor's BGP destination IP. For EBGP, ensure the TTL is sufficient (default 1, so must be directly connected or use ebgp-multihop). For IBGP, the destination must be reachable via IGP. If ping fails, troubleshoot routing or ACLs. Use `traceroute` to see where packets are dropped. Example: `ping 192.168.1.2 source loopback0`.
Verify BGP Configuration
Run `show running-config | section router bgp` to confirm the neighbor statement, remote AS, update-source, ebgp-multihop, password, and any other parameters. Ensure the local AS matches the neighbor's remote-as and vice versa. Check that the router ID is unique. If using loopbacks for IBGP, ensure `neighbor <ip> update-source loopback0` is configured on both sides.
Check BGP Summary and State
Use `show ip bgp summary` to see the state of each neighbor. If the state is Idle, the session is not attempting to connect. If Active, TCP connection failed. If OpenSent or OpenConfirm, there is a parameter mismatch. Look at the 'State/PfxRcd' column. Also note the 'Up/Down' time. If the state flips between Connect and Active, TCP connectivity is intermittent or blocked.
Examine BGP Neighbor Details
Run `show ip bgp neighbors <ip>` for detailed information. Look for: BGP state, last error, messages sent/received, hold time, keepalive interval, router ID, and capabilities. The 'BGP state' line shows the current state. The 'Last reset' field indicates why the session went down (e.g., 'BGP Notification sent', 'Peer closed the session'). Check 'External BGP neighbor' for EBGP multihop count.
Check ACLs and Firewalls
Ensure that TCP port 179 is not blocked between the peers. Check interface ACLs with `show ip access-lists` and `show running-config | include access-list`. Also check if there is a firewall between routers. Use `telnet <ip> 179` from the router to test TCP connectivity to port 179. If telnet fails, an ACL or firewall is blocking.
Verify BGP Timers and Authentication
Use `show ip bgp neighbors <ip>` to see the configured hold time and keepalive interval. The hold time must be at least 3 seconds (default 180). If one side has hold time 0, it expects no keepalives, which may cause the other side to reset. For authentication, ensure both sides have the same password. Use `show ip bgp neighbors <ip> | include password` to see if password is configured (the actual password is hidden). A mismatch causes a NOTIFICATION with error code 'Authentication failure'.
Use Debug Commands (if necessary)
As a last resort, use `debug ip bgp events` and `debug ip bgp keepalives` to see state transitions and keepalive exchanges. `debug ip bgp updates` shows UPDATE messages. Be cautious on production routers. Look for error messages like 'BGP: 192.168.1.2 passive - reset' or 'BGP: 192.168.1.2 active open failed - connection refused'.
In enterprise networks, BGP is commonly used for Internet connectivity (eBGP to ISP) and MPLS VPNs (iBGP between PE routers). A typical scenario: a company has two ISPs for redundancy. The BGP session to ISP1 fails to establish. The network engineer first pings the ISP's router IP from the WAN interface. If ping fails, the issue is Layer 1 (cable, optics) or Layer 2 (VLAN mismatch). If ping succeeds, they check BGP configuration: the remote AS must match the ISP's AS number. Often, the ISP requires the session to be sourced from a specific IP (e.g., a loopback) using update-source. Without it, the session may come from the WAN interface IP, which the ISP doesn't recognize, causing the session to stay in Active. Another common scenario: iBGP between routers in a data center. The routers use loopback interfaces for iBGP peering. If the IGP (e.g., OSPF) doesn't advertise the loopback routes, the TCP connection fails. The engineer must ensure the loopbacks are reachable via the IGP. A third scenario: BGP authentication. A security policy requires MD5 passwords on all BGP sessions. If one side has a typo in the password, the session fails with a 'BGP Notification sent' error. The engineer must coordinate with the peer to verify the password. Performance considerations: BGP sessions can be flapped if the hold timer is too low (e.g., 3 seconds) causing instability. Cisco recommends default timers. At scale, a single misconfigured peer can cause CPU spikes due to constant reconnection attempts. Best practice is to use neighbor <ip> shutdown to disable the session while troubleshooting, then no shutdown after fixing. Misconfiguration consequences: a missing ebgp-multihop on an eBGP multihop session causes the session to never establish, leading to loss of Internet connectivity. A duplicate router ID causes both peers to reject each other, resulting in a complete BGP outage.
The CCNA 200-301 exam tests BGP troubleshooting under objective 3.6 'Configure and verify BGP neighbor relationships and peerings'. You will be given a scenario with a BGP session that won't form and must identify the cause. The most common wrong answers candidates choose are: (1) 'The BGP process is not running' – while possible, the exam usually focuses on configuration mismatches. (2) 'The neighbor is not configured' – but the scenario will show a neighbor statement; the issue is often a missing parameter like update-source. (3) 'The AS number is wrong' – this is a common trap; candidates confuse local AS with remote AS. Remember: the neighbor remote-as is the AS of the neighbor, not your own. (4) 'The router ID is the same' – this is a real issue, but candidates often overlook it because they assume router IDs are unique. The exam may show two routers with the same router ID (e.g., both have loopback 0 with 10.0.0.1). You must know that BGP uses router ID to detect loops; duplicate IDs cause the session to reset. Specific values to memorize: default hold time = 180 seconds, keepalive = 60 seconds, connect-retry = 60 seconds, ebgp-multihop default TTL = 1. Command outputs to recognize: show ip bgp summary shows state as Idle, Active, etc. show ip bgp neighbors shows 'BGP state = Active'. Calculation traps: none for BGP peer formation, but you may need to calculate the hold time after negotiation (the smaller of the two configured hold times). Decision rule for scenario questions: First, check if the state is Idle (configuration issue) or Active (TCP connectivity issue). If Idle, look for missing neighbor command, wrong AS, or duplicate router ID. If Active, check IP connectivity, ACLs, ebgp-multihop, and update-source. If OpenSent/OpenConfirm, check timers, authentication, and maximum-prefix. Elimination strategy: remove options that blame Layer 1 if ping works; remove options that blame BGP process if the router is running BGP; remove options that mention OSPF if the issue is clearly between BGP peers.
BGP peer formation has six states: Idle, Connect, Active, OpenSent, OpenConfirm, Established.
Default hold timer is 180 seconds; keepalive interval is 60 seconds.
Default connect-retry timer is 60 seconds.
EBGP multihop requires the 'ebgp-multihop' command; default TTL is 1.
Router ID must be unique; can be set with 'bgp router-id' command.
Use 'show ip bgp summary' to check neighbor state quickly.
Use 'show ip bgp neighbors <ip>' for detailed troubleshooting.
These come up on the exam all the time. Here's how to tell them apart.
EBGP
Peers are in different AS numbers
Default TTL=1 (directly connected required unless ebgp-multihop)
Routes have AD of 20
Next-hop is changed by default
Can load balance with multiple paths
IBGP
Peers are in the same AS number
No TTL restriction (can be multiple hops away)
Routes have AD of 200
Next-hop is not changed by default
Requires full mesh or route reflectors
Mistake
BGP peers must be directly connected.
Correct
EBGP peers are directly connected by default (TTL=1), but can be multihop with 'ebgp-multihop'. IBGP peers can be any number of hops away as long as they are reachable via IGP.
Candidates confuse EBGP and IBGP requirements.
Mistake
If BGP state is Active, the problem is always a missing route.
Correct
Active state indicates TCP connection failure, which could be due to missing route, ACL blocking port 179, or incorrect update-source. But also could be due to peer not configured or peer in Idle state.
Candidates oversimplify the cause.
Mistake
BGP authentication uses a shared secret in the BGP OPEN message.
Correct
BGP authentication uses MD5 in the TCP header (TCP MD5 option), not in the BGP payload. The password is never sent in plaintext.
Candidates assume it's similar to OSPF or EIGRP authentication.
Mistake
The hold timer is always 180 seconds and cannot be changed.
Correct
The hold timer can be configured with 'neighbor <ip> timers <keepalive> <hold>'. The actual hold time used is the smaller of the two peers' configured hold times.
Candidates memorize default but forget configurability.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Idle state means BGP is not attempting to connect. Common causes: (1) The neighbor command is missing or misconfigured. (2) The BGP process is not enabled (router bgp <AS>). (3) The neighbor is administratively shutdown (neighbor <ip> shutdown). (4) The router ID is not set and no interface IPs exist. (5) The neighbor is in a VRF that doesn't match. Check 'show running-config | section router bgp' and 'show ip bgp summary'. Exam tip: If the state is Idle, look for configuration errors, not connectivity.
Active state indicates that BGP is trying to initiate a TCP connection to the peer but has not succeeded. This typically means the peer is not reachable, or an ACL is blocking TCP port 179, or the peer is not configured to accept connections. It could also mean the peer is in Idle state. The session will alternate between Connect and Active if TCP keeps failing. Exam tip: Use 'telnet <peer-ip> 179' to test TCP connectivity.
Use 'show ip bgp summary' – the first line shows 'BGP router identifier'. Alternatively, 'show ip bgp neighbors <ip>' shows the router ID. The router ID is the highest loopback IP, or highest physical IP, or configured with 'bgp router-id <ip>'. If two peers have the same router ID, the session will not establish. Exam tip: Duplicate router ID is a common exam trap.
Both affect the TTL of BGP packets. 'ebgp-multihop <hops>' sets the TTL to <hops>+1, allowing the session to work over multiple hops. 'ttl-security hops <count>' sets the expected TTL to 255 - count, dropping packets with lower TTL. They are mutually exclusive. Exam tip: If you see 'ttl-security' configured, ensure the neighbor is within the expected hop count.
If authentication is configured on one side but not the other, or passwords differ, the session will fail. Use 'show ip bgp neighbors <ip> | include password' to see if password is configured (the password itself is hidden). The error message will be 'Authentication failure' in debugs. Exam tip: Always ensure passwords match exactly, including case.
Default hold timer is 180 seconds, and keepalive interval is 60 seconds. The actual hold time used is the smaller of the two peers' configured hold times. If one peer has hold time 0, it expects no keepalives, but the other peer may reset the session. Exam tip: Memorize these defaults – they are often tested.
Flapping (repeatedly going up and down) can be caused by: (1) Unstable physical link. (2) BGP hold timer too low. (3) Maximum prefix limit exceeded. (4) Route flap damping. (5) Authentication mismatch. Check 'show ip bgp neighbors <ip>' for 'Last reset' reason. Use debugs to see the exact cause. Exam tip: Flapping often indicates a timer mismatch or prefix limit.
You've just covered Troubleshoot: BGP Peer Won't Form — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?