Network & Infrastructure / BGP Policy & Internet Edge
BGP next-hop recursion: a valid path that never reaches the FIB
Trace an FRRouting BGP prefix from selected path through next-hop resolution and the Linux FIB before changing route preference.
Start hands-on practice · เริ่มภาคปฏิบัติ ↓Practical guide · คู่มือลงมือทำ
Download worksheet · ดาวน์โหลดขั้นตอนDetailed practical guide
Prepare your workspace and inputs
Get the exact failing prefix, BGP next hop and intended underlay from the topology owner. Documentation addresses 203.0.113.0/24, 192.0.2.2 and 203.0.113.10 below must be replaced with the lab values. The diagnostic commands do not modify routing.
Platform context: FRRouting on a permitted Linux lab router, vtysh and iproute2; IPv4 unicast in the default VRF. Adapt commands through the deployed platform documentation for another vendor or VRF.
Scenario to reproduce or investigate
A BGP session is established and a prefix is visible in the BGP table, but traffic follows a default route. BGP receipt, best-path selection, RIB installation and kernel forwarding are different observations.
- Actual target and platform release
- Exact inputs or substituted values
- Baseline result
- Per-step expected and observed output
- Failure encountered and corrective action
- Final acceptance and recovery state
-
Inspect the exact BGP path and recursive next hop
Read the prefix and next-hop tracking state in FRR. Record the chosen next-hop address, validity and best-path indicators together with any competing path. Do not infer next-hop reachability merely from an established neighbor session.
Command, configuration or input
vtysh -c 'show bgp ipv4 unicast 203.0.113.0/24' vtysh -c 'show ip nht'Expected result · ผลที่ควรเห็นThe path record identifies whether the intended path is valid and selected, and next-hop tracking supplies the relevant resolution evidence.
If it fails · เมื่อไม่ผ่านIf the prefix is absent, investigate address family and import policy first. If command syntax differs, use the installed FRR help and release documentation instead of substituting a vendor command blindly.
-
Compare the routing decision with kernel forwarding
Read the FRR route to both the prefix and next hop, then inspect the kernel route selected for a representative destination. Keep all commands in the same VRF and network namespace. The default-VRF Linux route below is not a substitute for a VRF-specific query.
Command, configuration or input
vtysh -c 'show ip route 192.0.2.2' vtysh -c 'show ip route 203.0.113.0/24' ip route get 203.0.113.10Expected result · ผลที่ควรเห็นThe next hop resolves through the intended underlay and the kernel lookup selects the expected egress for the representative address. Any discrepancy is recorded at its actual layer.
If it fails · เมื่อไม่ผ่านIf the next hop resolves only through an unintended default or another VRF, fix the underlay design in the lab. If FRR selects the route but the kernel does not, inspect installation and namespace evidence before changing BGP local preference.
-
Apply only the demonstrated underlay or policy correction
Save the relevant routing configuration and choose a correction supported by the observed cause: restore the intended underlay route, correct a wrong next-hop policy or repair the scoped installation issue. Use the lab change process to apply that exact delta. Repeat the three table checks and the actual permitted application transaction in both directions, including an unrelated prefix as a regression control.
Command, configuration or input
Record: original path | next-hop dependency | changed configuration lines | new FIB result | forward transaction | return transaction | unrelated-prefix checkExpected result · ผลที่ควรเห็นThe intended prefix reaches the correct FIB path and its application works without creating a recursive default dependency or changing unrelated destinations.
If it fails · เมื่อไม่ผ่านIf a prefix appears in the FIB but application traffic fails, investigate return routing, filtering and service health. Do not label FIB installation alone as end-to-end recovery.
Check the result before marking this passed
The route’s BGP validity, next-hop resolution, FRR RIB and Linux FIB agree for the same context, and representative forward/return transactions plus an unrelated-prefix control pass after the scoped correction.
Record the observed result and evidence location in the downloaded worksheet. Mark unresolved or untested conditions explicitly.
Recovery and cleanup
The diagnostic phase changes nothing. Before a lab correction, record the exact prior configuration and trigger rollback if the expected next hop, return path or unrelated-prefix check regresses; recheck the restored state rather than assuming command acceptance means recovery.
Apply to actual work and known limits
These are FRR/Linux diagnostic commands and a cause-driven change process. No live router or FRR lab was available here, so a specific corrective configuration is deliberately not invented without the observed topology and release.
Background, explanations and original notes
Problem and scope
An edge router receives a preferred BGP prefix, but traffic follows a default route or is dropped. The session remains established, which makes transport health a misleading success signal.
Collect the evidence
Compare the received path, selected BGP path, next-hop resolution, main routing table and forwarding entry in the same VRF. Record recursive next hops and any unresolved connected dependency.
Explain the result
BGP selection and forwarding installation are separate decisions. An unreachable next hop can invalidate a path; another protocol can also win the routing-table preference comparison.
Plan the fix
Repair the actual underlay reachability or intended next-hop policy. Avoid changing administrative preference merely to hide a recursion failure or accidental cross-VRF lookup.
Check the result and rollback
Confirm the exact prefix in the FIB and test representative application traffic in both directions. Roll back if the correction creates a recursive default dependency or changes unrelated destinations.