Short answer: Diagnose BGP by finding the first broken handoff: session, address family, received route, accepted path, best path, routing table, forwarding table, then advertisement to the next peer. An Established session proves neither that the needed prefix was accepted nor that packets will follow it.[1][2][3]
This guide uses a small dual-provider lab and a repeatable evidence worksheet. Work on one exact prefix, one direction and one VRF at a time; do not begin by resetting every neighbor.
1. The BGP troubleshooting decision tree
Use this worksheet during an incident. The order below is a suggested diagnostic method, not a vendor state machine.
- Scope: Record the affected source, destination, prefix length, VRF, address family and timestamp.
- Session: Is the intended peer Established? If not, examine transport and OPEN negotiation before route policy.
- Reception: Does the sending peer advertise the exact prefix? Can the receiving device expose pre-policy routes?
- Acceptance: Does the route survive import policy and loop checks?
- Selection: Is the path valid, is its next hop reachable, and is it best among BGP candidates?
- Installation: Does that best path win in the routing table, and is the forwarding entry usable?
- Export: Is the route eligible and permitted for advertisement to the next peer?
- Delivery: Does an actual sourced flow succeed in both directions?
Do not treat these as interchangeable route lists. FRRouting distinguishes accepted neighbor routes, pre-policy received routes and advertised routes; a prefix can appear in one view but not another.[3]
2. Idle, Active, OpenSent and Established: what to investigate
BGP's state machine includes Idle, Connect, Active, OpenSent, OpenConfirm and Established. Active is a connection-establishment state, not a synonym for healthy routing.[1]
For a session that never establishes, check the route to the peer using the actual peering source, TCP port 179 reachability, source-address agreement, remote AS and any authentication or TTL requirements. A ping sourced from a different interface is not the same test.[2]
Suggested Cisco IOS/IOS XE collection set; syntax and available fields vary by release:
show ip bgp summary
show ip bgp neighbors 192.0.2.1
show ip route 192.0.2.1
show ip interface brief
show logging
ping 192.0.2.1 source 192.0.2.2
Suggested interpretation, not captured device output:
- Repeated connection failures: compare source and destination addresses with the peer's configuration and security rules.
- A received NOTIFICATION: preserve its code, subcode and timestamp before changing anything.
- Repeated up/down transitions: correlate both routers' logs with interface and transport events.
- Established with the wrong address family: investigate the negotiated family rather than only the global neighbor status.
Cisco's basic troubleshooting guide covers session source/TTL, TCP issues, flapping and AFI/SAFI problems; it explicitly notes that the illustrated commands target IOS/IOS XE.[2]
3. Established but zero prefixes: inspect both ends
Use an exact route as the unit of evidence. For example, ask whether 198.51.100.0/24 was exported by ISP-A, received by EDGE, accepted by EDGE, then selected. “The peer is up” answers none of those later questions.
An explicit Cisco network ... mask ... origination statement needs the matching route in the routing table. Check prefix length as well as address; a covering route or a collection of more specifics is not automatically the required exact entry.[4]
In FRRouting, when bgp ebgp-requires-policy applies, missing import or export policy can block exchange while the session remains up; (Policy) in summary output and neighbor details are useful clues. Default behavior depends on the selected configuration profile.[3]
Recommended checks:
! Cisco IOS/IOS XE: inspect route and export on the sender
show ip route 198.51.100.0 255.255.255.0
show ip bgp 198.51.100.0 255.255.255.0
show ip bgp neighbors 192.0.2.2 advertised-routes
show ip prefix-list
show route-map
! FRRouting: inspect accepted and exported routes
show bgp ipv4 unicast summary
show bgp ipv4 unicast neighbors 192.0.2.1 routes
show bgp ipv4 unicast neighbors 192.0.2.1 advertised-routes
Pre-policy inspection needs care: on FRRouting, retaining unmodified received updates with inbound soft reconfiguration uses extra memory; route refresh can support policy reevaluation without storing that full copy. Confirm the release's capabilities before enabling extra storage on a large table.[3]
4. A contained Cisco-style lab configuration
Scope: This is an original, deliberately small IPv4 unicast example, not a production Internet template. Documentation prefixes and private AS numbers must stay inside the lab. Interface addressing and the peers' reciprocal configurations are prerequisites. Commands have not been executed on a router for this article.
ISP-A AS 65001 ----- 192.0.2.1/30
|
192.0.2.2/30
EDGE AS 65000
203.0.113.2/30
|
ISP-B AS 65002 ----- 203.0.113.1/30
EDGE Loopback10: 10.10.10.1/24
Both ISPs originate lab destination 198.51.100.0/24.
Goal: accept only that destination, prefer ISP-A, keep ISP-B as a candidate, and export only the locally connected lab subnet.
interface Loopback10
ip address 10.10.10.1 255.255.255.0
!
ip prefix-list LAB-DEST seq 10 permit 198.51.100.0/24
ip prefix-list LAB-OWN seq 10 permit 10.10.10.0/24
!
route-map FROM-A permit 10
match ip address prefix-list LAB-DEST
set local-preference 200
!
route-map FROM-B permit 10
match ip address prefix-list LAB-DEST
set local-preference 100
!
route-map TO-ISP permit 10
match ip address prefix-list LAB-OWN
!
router bgp 65000
bgp router-id 10.255.0.1
neighbor 192.0.2.1 remote-as 65001
neighbor 203.0.113.1 remote-as 65002
address-family ipv4 unicast
network 10.10.10.0 mask 255.255.255.0
neighbor 192.0.2.1 activate
neighbor 203.0.113.1 activate
neighbor 192.0.2.1 route-map FROM-A in
neighbor 203.0.113.1 route-map FROM-B in
neighbor 192.0.2.1 route-map TO-ISP out
neighbor 203.0.113.1 route-map TO-ISP out
exit-address-family
The route-policy pattern uses Cisco prefix lists and route maps; use the vendor documentation to validate syntax on the intended image before applying it.[2][4]
Walk one prefix through the lab
Expected logic, conditional on both neighbors originating the destination and all earlier selection criteria being equal:
- ISP-A offers
198.51.100.0/24; FROM-A accepts it and assigns LOCAL_PREF 200. - ISP-B offers the same prefix; FROM-B assigns 100.
- With reachable next hops and no overriding local preference mechanism, the A path should win the BGP comparison.
- Confirm that this candidate also appears as the active route and resolves in forwarding.
- TO-ISP should export only
10.10.10.0/24; neither learned destination should transit through EDGE to the other provider.
LOCAL_PREF expresses preference within the AS; higher preference is favored. It does not instruct a remote AS which route to use.[1]
Verification and a safe fault-injection exercise
show ip bgp 198.51.100.0 255.255.255.0
show ip route 198.51.100.0 255.255.255.0
show ip cef 198.51.100.1 detail
show ip bgp neighbors 192.0.2.1 advertised-routes
show ip bgp neighbors 203.0.113.1 advertised-routes
show route-map FROM-A
show ip prefix-list LAB-DEST
Acceptance criteria for this lab:
- Both expected sessions are up and both destination candidates are visible.
- The selected BGP path uses A, and the active route and forwarding lookup agree.
- Each export view contains the local lab subnet and not the other ISP's destination route.
- A sourced test reaches a responding endpoint inside the destination subnet; that endpoint has a return route to the chosen source.
For a controlled lab fault, replace LAB-DEST's permit with 198.51.100.0/25 in a saved test copy. Reevaluate the inbound policy using the image's documented soft-refresh procedure. The /24 should stop matching. Restore the exact /24, reevaluate again and compare the same checkpoints. Do not perform this exercise on a live transit policy.
5. Route visible, but not installed: separate BGP from RIB and FIB
An unreachable BGP next hop is a different failure from losing to another routing protocol. Cisco documents next-hop reachability as a path-installation issue and gives IGP/static reachability or a deliberately placed next-hop-self as possible remedies.[2]
Collect these views on the same router and in the same routing context:
show ip bgp 198.51.100.0 255.255.255.0
show ip route 192.0.2.1
show ip bgp rib-failure
show ip route 198.51.100.0 255.255.255.0
show ip cef 198.51.100.1 detail
Cisco's r marker can indicate RIB-failure: the BGP route lost installation to an equal-prefix route with lower administrative distance. That route can still be BGP-best, and IOS can still advertise it.[5]
Do not confuse this equal-prefix comparison with longest-prefix forwarding. Record the exact mask on both candidates before explaining a difference as administrative distance.
bgp suppress-inactive is not a generic repair. Cisco documents a next-hop-related qualification: its example suppresses inactive routes whose BGP and routing-table next hops differ, while an inactive route with matching next hops remains advertised. Diagnose first, then decide whether the intended advertisement behavior needs changing.[5]
Suggested incident question: “Which entry wins for the exact prefix, and which forwarding adjacency will this destination actually use?” Do not stop at a best-path marker.
6. Route installed, but not advertised
Check the sender's advertised-routes view before asking the receiver to change policy. Cisco's non-advertisement guide shows how to trace local origination, network-mask matching and export evidence.[4]
For classic iBGP, routes learned from an internal peer are not simply re-advertised to another internal peer; route-reflection designs change the distribution model. Check the actual peer roles before diagnosing this as an export-filter fault.[1]
Suggested export checklist:
- Confirm the exact route exists in the intended table.
- Inspect its selected-path status and any inactive-route export behavior.
- Read the entire outbound policy, including unmatched-route behavior.
- Compare policy objects with the actual prefix length.
- Check whether this is ordinary iBGP propagation or a reflector-specific case.
- Obtain receiver-side evidence after sender-side advertisement is confirmed.
Avoid adding a broad permit-all rule just to make the symptom disappear. In the lab above, exporting an ISP-learned destination to the other ISP violates the stated design even if it makes a route counter increase.
7. What troubleshooting can change about traffic
Outbound: In the lab, import policy changes the preference of routes used to send traffic toward 198.51.100.0/24. This is local/AS-side selection, not a claim about the remote return path.[1]
Inbound: Local export determines which reachability information is offered; the receiving AS still makes its own policy decision. Treat inbound engineering as something to verify externally, not something proven by a local best-path flag.[1]
Cannot control: An Established session and an accepted advertisement do not prove end-to-end application delivery. Include an actual flow test in the worksheet, and investigate return routing, firewall/NAT state and path-specific behavior separately when routing evidence is consistent.
Recommended dual-ISP test record: source address, destination, ingress provider, egress provider, active route, observed flow result and timestamp. Keep outbound and return-path observations in separate fields.
8. Modern fabrics: ask which table the route reached
EVPN adds another important handoff: a route can be distributed by BGP but still need the appropriate Route Target import into an EVI. RFC 7432 distinguishes route distribution from importing eligible EVPN routes into the service.[6]
For an EVPN/VXLAN incident, extend the worksheet with RD, Route Targets and intended service context. Do not use an IPv4-unicast summary alone as evidence about the EVPN address family.
FRRouting provides EVPN-specific views; one documented filtering case retains a route in the global EVPN RIB without importing it into the corresponding service table. This is a concrete example of why “I can see the BGP route” is not enough.[3]
! FRRouting inspection examples; verify syntax for your release
show bgp l2vpn evpn summary
show bgp l2vpn evpn route
show bgp vni
Recommended fabric workflow: collect underlay reachability evidence, then EVPN route evidence, then service-import evidence, then endpoint forwarding evidence. In an ACI-managed environment, use the supported controller/device troubleshooting workflow rather than pasting this standalone IOS lab configuration onto managed nodes.
9. A reusable incident checklist
Copy this into the change ticket or incident notes:
Timestamp / timezone:
Affected source and destination:
Exact prefix and mask:
VRF / AFI / SAFI:
Neighbor and actual peering source:
Session state / last reset reason:
Sender export evidence:
Receiver accepted-route evidence:
Pre-policy evidence available? If not, say so:
Selected BGP path and next-hop resolution:
Active routing entry and forwarding adjacency:
Next-peer export evidence:
Forward and return-flow test:
Smallest proposed change / rollback:
Same measurements after change:
Prefer one hypothesis and one reversible change at a time. Save the pre-change outputs. Use a documented soft policy reevaluation where appropriate, and reserve hard session resets for a justified maintenance or recovery action.
Interview answer: a concise version
I separate session establishment from route acceptance, best-path selection, routing-table installation and advertisement. First I verify the peer and address family, then trace one exact prefix through import policy and next-hop resolution. If BGP has a best path but forwarding differs, I check RIB-failure and the forwarding table. Finally I verify export on the sender and receipt on the next router. I do not reset the session as my first diagnostic step.[2][3][5]
Summary
Use the first failed handoff to narrow the investigation. Preserve the exact prefix, family and routing context in every command. A useful fix must satisfy both the route-policy design and an observed flow test; increasing a received-prefix counter alone is not the acceptance criterion.
Related reading
- BGP Convergence Explained: BFD, PIC, Graceful Restart and Failover
- BGP Filtering Explained: Prefix Lists, AS-Path Filters and Maximum-Prefix
- BGP NEXT_HOP Explained: Next-Hop Reachability, next-hop-self and Troubleshooting
- BGP Best-Path Selection Explained: How Routers Choose a Route
- BGP EVPN Explained: VXLAN Routes, Route Types and Troubleshooting
Sources
- [1] https://www.rfc-editor.org/rfc/rfc4271.html
- [2] https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/218027-troubleshoot-border-gateway-protocol-bas.html
- [3] https://docs.frrouting.org/en/latest/bgp.html
- [4] https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/19345-bgp-noad.html
- [5] https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/213286-understand-bgp-rib-failure-and-the-bgp-s.html
- [6] https://www.rfc-editor.org/rfc/rfc7432.html
Post a Comment