BGP Troubleshooting

Use a repeatable workflow to isolate BGP transport, neighbor, advertisement, policy, best-path, and forwarding problems without resetting a healthy session.

Begin with BGP summary and TCP reachability

Start with show ip bgp summary. An established neighbor normally shows the number of received prefixes in the State/PfxRcd column. Idle, Active, Connect, OpenSent, or OpenConfirm indicate that the session has not completed. Record the state, uptime, messages, and last-reset reason before making changes.

BGP uses TCP port 179. Verify IP reachability to the configured neighbor address and source the test from the same address BGP uses. For directly connected external BGP, check interface addressing and TTL. For loopback peering, configure the intended update source and ensure both routers can route to the remote loopback. Firewalls, access lists, CoPP, and asymmetric routing can permit ICMP while still blocking TCP 179.

Common issues

  • Neighbor Adjacency Issues: Incorrect neighbor IP, AS number mismatch, ACL blocking, or authentication issues.
  • Route Not Advertised: Network command missing, synchronization issues, or policy filtering.
  • Path Selection Issues: Incorrect path attributes or policy application.

Neighbor session states

  • Idle: The process is waiting to start or has rejected the attempt. Check configuration, shutdown state, reachability, and recent reset messages.
  • Active: The router is repeatedly trying to establish TCP. Check routing to the neighbor, TCP 179, source address, TTL, and remote configuration.
  • OpenSent or OpenConfirm: TCP is up but BGP negotiation is incomplete. Compare remote AS numbers, address families, capabilities, and authentication.
  • Established with zero prefixes: The session is healthy, but no route passed advertisement and policy checks.

Useful evidence includes show ip bgp neighbors, show tcp brief, interface counters, and platform logs. An AS mismatch, bad MD5 key, invalid TTL, duplicate router ID, or neighbor shutdown usually leaves a specific message.

Why a prefix is not advertised

A BGP network statement does not create a route. The exact prefix and mask must already exist in the local routing table unless the platform configuration intentionally aggregates or redistributes it. Confirm the route with show ip route, then inspect the local BGP table and the routes advertised to the neighbor.

Review outbound route maps, prefix lists, filter lists, communities, aggregation, and maximum-prefix controls. For iBGP, remember the split-horizon rule: a route learned from one iBGP peer is not advertised to another iBGP peer unless the design uses route reflectors or a full mesh. For eBGP, next-hop and address-family activation also matter.

Why a received route is not installed

A route can appear in the BGP table without becoming the best BGP path or entering the IP routing table. Use show ip bgp <prefix> to inspect validity, next-hop reachability, weight, local preference, AS path, origin, MED, and selection messages. An inaccessible next hop makes a path invalid.

If BGP selects a best path but the routing table uses another route, compare administrative distance and prefix length. A more-specific route always wins forwarding, while a route from another protocol may beat BGP for the same prefix. Also verify route recursion and any RIB-failure explanation reported by the platform.

Check policy in both directions

Do not assume a neighbor sent what the local router should accept. Compare the local route, advertised route, received route, and accepted BGP route as four separate stages. Soft inbound route refresh lets the router reapply an updated policy when both peers support the capability, avoiding a disruptive hard reset.

Before changing a route map, check its sequence order and match counters. A permit statement with an unmatched condition does not permit everything, and an implicit deny at the end can remove all remaining prefixes. Validate community formatting and whether a community is sent to the peer when policy depends on it.

Useful commands

  • show ip bgp summary: Verifies BGP neighbor status.
  • show ip bgp: Displays entries in the BGP routing table.
  • show ip bgp neighbors [address] advertised-routes: Shows routes advertised to a specific neighbor.
  • show ip bgp neighbors [address] received-routes: Shows routes received from a specific neighbor.
  • show ip bgp <prefix>: Explains available paths, the selected path, and next-hop validity.
  • show ip route <prefix>: Confirms which route is installed for forwarding.
  • show route-map and show ip prefix-list: Checks policy order and match counters.
  • clear ip bgp <neighbor> soft in: Reapplies inbound policy when route refresh is supported.

Avoid clear ip bgp * during diagnosis because it resets every peer and can cause widespread route withdrawal. If a hard reset is unavoidable, limit it to the affected neighbor, record the reason, and use an approved maintenance window.

End-to-end verification

  1. Confirm the neighbor is Established and stable.
  2. Verify the exact prefix exists at its source and enters the local BGP table.
  3. Confirm outbound policy permits it and the expected neighbor receives it.
  4. Verify inbound policy, best-path selection, next-hop reachability, and routing-table installation.
  5. Test forwarding and the return path, not only control-plane presence.

Continue with BGP path attributes for best-path inputs, BGP routing policies for filtering, or the BGP configuration guide for a clean baseline.