pjhtech Tools
Cisco · Cisco IOS XE

Cisco IOS XE BGP Commands: Neighbors, Prefixes and Advertisements

Quick answer #

Use show ip bgp summary for session status, then inspect the relevant neighbor and one affected prefix. Separate three questions: is the session established, does BGP hold the expected path, and did that path become the route used for forwarding? A positive answer to one does not settle the others.

Scope: IOS XE 17.x IPv4 unicast in the global routing context. Do not apply these default-context examples unchanged to VPNv4, EVPN, IPv6 or VRF address families. BGP support and scale depend on platform and licensing.

Read-only commands #

Read-only commands
Cisco IOS XE · Authorized EXEC mode; context specified below

Read-only
show ip bgp summary
Read-only

Replace these example values: 192.0.2.2.

show ip bgp neighbors 192.0.2.2
Read-only

Replace these example values: 192.0.2.2.

show ip bgp neighbors 192.0.2.2 routes
Read-only

Replace these example values: 192.0.2.2.

show ip bgp neighbors 192.0.2.2 advertised-routes
Read-only

Replace these example values: 203.0.113.0, 255.255.255.0.

show ip bgp 203.0.113.0 255.255.255.0
Read-only

Replace these example values: 203.0.113.25.

show ip route 203.0.113.25

Optional pre-policy view #

Optional pre-policy view
Cisco IOS XE · Authorized EXEC mode; context specified below

Read-only

Replace these example values: 192.0.2.2.

show ip bgp neighbors 192.0.2.2 received-routes

The optional view requires the relevant received-route information to be retained, commonly through inbound soft reconfiguration. If unavailable, do not enable extra route storage or reset a session merely to complete this checklist.

Workflow #

  1. Confirm that the neighbor and address family belong to the affected service. Record the remote AS, session state and uptime. An established session with zero accepted prefixes is a different problem from a session that never establishes.
  2. Inspect one expected prefix. Compare the peer's accepted routes with the local BGP entry. Read inbound policy when an expected advertisement is absent from the accepted set.
  3. Inspect outbound advertisements toward the relevant peer. This is local evidence; it does not prove the remote router accepted or installed the advertisement.
  4. Compare the BGP entry with the main routing-table lookup. Record the best-path selection, next-hop reachability and any indication that another route won installation.
  5. When the route is installed, continue through forwarding, access controls and the return path. Avoid treating a successful control-plane exchange as a complete application test.

Interpretation pitfalls #

In the usual summary output, a number in the State/PfxRcd column represents a prefix count for an established neighbor. A word such as Active is a state, not a statement that the session is healthy. Always read the full column heading and neighbor detail.

The accepted-routes and received-routes views serve different purposes. An absent pre-policy view does not establish that the peer sent nothing. Likewise, a prefix present in BGP may lose to another route source or have an unusable next hop.

Evidence to save #

Capture the peer details, exact prefix, accepted or advertised view, and routing-table result with a timestamp. Do not clear BGP to refresh a screenshot: resetting a working session can withdraw usable paths and destroy useful timing evidence.

Useful tools and references #

  • CIDR aggregation calculator: Inspect the address coverage of a proposed summary; calculation alone does not establish that the summary should be advertised.
  • CIDR list comparison: Compare exported prefix lists for missing or extra address coverage while retaining BGP attributes for separate review.

Sources

Documentation reviewed: 8 October 2026