Quick reference
| Stage | Question | Evidence |
|---|---|---|
| Transport | Can peers communicate? | TCP 179; source and peer context |
| Established | Is BGP exchanging messages? | State / uptime / prefix count |
| Received | Did this peer send the prefix? | Received route view / retention |
| Accepted | Did import policy allow it? | Policy and hidden/rejected reason |
| Selected | Is a usable path eligible? | Attributes and next-hop resolution |
| Installed | Did it reach RIB and FIB? | Route and forwarding entry |
| Advertised | Did export policy send it? | Neighbor-specific advertisement |
What to understand first
BGP uses TCP and a finite-state machine: Idle, Connect, Active, OpenSent, OpenConfirm and Established. Active means an attempt to establish transport, not a healthy forwarding session.
Import/export policy is directional. A neighbor being established says nothing about whether the required prefix is permitted in the right address family.
Best-path rules include attributes and implementation-specific behavior. Cisco weight is local to the device; LOCAL_PREF is normally carried within the AS. Neither replaces next-hop reachability.
Received route visibility depends on retention and command semantics. Absence from one display can require checking policy, refresh capability and the sender before drawing conclusions.
Commands and interpretation
Inspection commands are read-only unless explicitly labeled otherwise. Capture commands start collection; configuration-mode commits change device state.
Cisco IOS XE
Read-only EXEC
show ip bgp summary
show ip bgp 192.0.2.0
show ip bgp neighbors 198.51.100.1 advertised-routes
show ip route 192.0.2.10
show ip cef 192.0.2.10Inspect: Inspect the actual prefix, attributes and next hop; compare advertisement with installed forwarding.
Junos
Read-only operational
show bgp summary
show route receive-protocol bgp 198.51.100.1
show route 192.0.2.0/24 detail
show route advertising-protocol bgp 198.51.100.1Inspect: Compare receipt, activity and export. Use hidden-route inspection and instance-specific tables when needed.
Worked example · Illustrative, not a device capture
Illustrative missing-route evidence
Neighbor: Established
Wanted prefix: 192.0.2.0/24 received
BGP next hop: 198.51.100.9
Route to next hop: missingPeer transport can work while the received path has an unresolved next hop. Check the intended underlay or next-hop policy.
Changing LOCAL_PREF will not repair missing next-hop reachability. These observations are deliberately simplified.
Troubleshooting sequence
- Confirm peer/source addresses, ASNs, TCP reachability and address family.
- Ask whether the sender advertises the exact prefix, then inspect receipt at this peer.
- Check import policy and next-hop resolution before debating path preference.
- Compare selected BGP path with the RIB and FIB in the affected VRF/instance.
- Inspect export to the next neighbor and test forward and reverse application traffic.
Common mistakes
- Resetting all peers to refresh one route without an approved plan.
- Confusing received, accepted and active routes.
- Assuming one vendor best-path list applies unchanged to another.
Acceptance checks
- Required prefixes are accepted, installed and exported as intended.
- Unwanted routes remain rejected; counters and policy evidence support it.
- Application paths and planned peer-loss behavior meet the target.
Primary references
Vendor documentation and protocol specifications support this guide. The diagrams, scenarios and troubleshooting sequences are Wolex-authored.