Understanding Network Infrastructure · Part 3 · How does traffic reach other networks and the Internet?
How does a router choose a path for a packet?
How routing uses the RIB, FIB, and adjacency information to select an egress interface
A router forwards a packet by finding the destination IP's most specific matching prefix in the FIB. The FIB holds the control plane's selected RIB routes and their next hops, resolved into actual interfaces and neighbor information. We follow prefix comparison, RIB selection, FIB installation, neighbor resolution, and the return path to explain why a visible route does not always mean traffic can get through.
A router receives a packet. In which context does it look up the destination IP for routing?↑
In ordinary IP forwarding, a router looks up an incoming packet's destination IP in the FIB. It does not search for 203.0.113.20 as one complete text string. It compares the address with prefix ranges to find a match.
Some policies also consider the source IP, Layer 4 port, and ingress interface—for example, policy-based routing or SD-WAN policy. Without such exceptions, ordinary route selection starts with the destination IP. Establishing this baseline helps distinguish ACLs, NAT, and QoS from the routing lookup itself.
Suppose a 203.0.113.20-bound packet arrives on a VLAN 10 interface. The router uses that interface's VRF to select the FIB. The same prefix in another VRF is not a candidate in this routing context. Tunnel decapsulation can trigger another lookup using the inner destination. To identify the table used, record the capture location and the packet's current header.
Policy-based routing can use the source address, DSCP, Layer 4 ports, or the ingress interface to override the default next hop. In some firewall implementations, service routing controls how the firewall itself reaches external services. SD-WAN policy can also steer transit traffic. A destination-based route lookup that differs from the actual egress interface does not, by itself, prove the routing table is wrong. Identify the VRF and policy applied to this packet, then compare the ordinary FIB result.
Ordinary IP routing uses the destination IP as its lookup key. The source IP matters to the return path, security policy, and policy-based routing, but it is not the initial key for a normal destination-based FIB lookup. Record the ingress interface, VRF, destination, applied policy, and actual egress interface to verify that the intended table was used.
Sources for this section IETF RFC 1812 · IETF RFC 1122
A RIB-selected route must reach the FIB before packets can use it↑
Connected, static, OSPF, and BGP sources can offer different routes to the same prefix. The control plane gathers these candidates in the routing information base, or RIB, and selects routes according to the device's rules and policies.
Selected routes are installed in the forwarding information base, or FIB. The FIB is optimized for packet forwarding, avoiding repeated protocol calculations for every packet. RIB and FIB names and implementations vary, but separating route calculation in the control plane from packet forwarding in the data plane helps narrow a fault quickly.
| Function | Main question | Typical information |
|---|---|---|
| RIB | Which route should we use? | Prefix, route source, metric, next hop |
| FIB | Where should this packet go? | Prefix lookup result, egress interface |
| Adjacency | How should we transmit it on the link? | Next-hop MAC, encapsulation information |
A new OSPF route does not immediately redirect every packet. The protocol database's candidate must pass RIB selection, and the selected prefix must be installed in the FIB. A hardware router may then need to program line-card or ASIC forwarding tables. A control-plane log can show the new route while a delayed or failed data-plane update leaves packets using the old route or a discard entry.
Conversely, a brief protocol session disruption may not stop forwarding if graceful restart or FIB retention keeps packets moving. That does not mean the control plane is healthy; the data plane is temporarily using the last known information. Collect the protocol database, RIB, FIB, and interface counters for the same time window. Compare route calculation results with the prefixes and next hops in the RIB/FIB, and check changes in interface counters to distinguish failures in learning, selection, installation, and actual forwarding.
Normally, RIB changes reach the FIB, but resource shortages, programming errors, policy, or hardware-offload problems can leave them inconsistent. An OSPF LSA, a BGP prefix, and a RIB route are evidence of different stages. For an actual forwarding failure, inspect the FIB entry and adjacency to connect control-plane learning with data-plane forwarding.
Sources for this section IETF RFC 1812 · IETF RFC 3222
When several prefixes match, use the most specific route↑
203.0.113.20 belongs to 203.0.113.0/24, 203.0.0.0/16, and 0.0.0.0/0. The router selects /24, which matches the most leading bits of the destination. This is longest prefix match.
For each packet, the router searches routes already installed in the FIB for the most specific destination match. A lower-cost /16 does not beat a matching /24. Choosing which route to install when several sources advertise the same prefix is an earlier control-plane task. Keep that candidate selection separate from the per-packet lookup.
If the FIB contains 0.0.0.0/0, 203.0.113.0/24, and 203.0.113.16/28, then 203.0.113.20 uses /28. Even a slower next hop or higher metric does not make /28 compete with /24 on metric. The more specific prefix matches the packet's destination more closely. A single-host /32 route that redirects or discards traffic takes precedence over a broader aggregate for the same reason.
This matters for failures and security policy too. A valid summary route can coexist with an incorrectly advertised, more specific prefix that draws traffic to another site. An RTBH /32 can send just one host's traffic to a null next hop. When inspecting route tables, do not stop at the default route: request the lookup result for the exact destination. Unlike visually scanning a prefix list, the device's lookup can show ties and recursive resolution too.
A summary from a higher-preference protocol can lose traffic to a lower-preference protocol's more specific prefix. A default route alone therefore cannot tell you which exit a particular destination uses. Query the FIB for the exact destination, including any host route (/32), policy exception, or tunnel-endpoint route.
Sources for this section IETF RFC 1812
What to look for Compare the arriving packet's destination address with the prefixes in the routing table and select the longest matching prefix. When the packet is sent to the selected next hop, its IP addresses remain unchanged, while its link-layer addresses change for that segment. The diagram illustrates route selection and header changes, not the internal implementation of a trie lookup structure.
↔ Scroll horizontally to explore the diagram.
For the same prefix, compare route sources and metrics↑
For an identical prefix offered by a static route and OSPF, the device compares preferences between route sources. Some vendors call this administrative distance; others use terms such as preference. Values and selection details vary, so no single vendor's numbers should be treated as universal Internet rules.
Within a routing protocol, the protocol's metrics and attributes determine its best paths. OSPF cost and BGP path attributes have different meanings and comparison rules. Whether multiple equal-cost paths can be installed, and how many, depends on the device and configuration.
For 10.20.30.0/24, both static configuration and OSPF may supply a route. The device compares them using source preference. The cost OSPF uses to select its best candidate is not the same value used to compare different sources. Inspect each protocol's selection, the chosen RIB route, and the installed FIB forwarding information in turn.
Multiple equal-cost paths in the FIB can share flows by hash. But differences in MTU, latency, or traversal of stateful devices can affect application performance and return traffic. Unequal-cost sharing may require a specific protocol or vendor feature. Changing route-source preference can affect more than one prefix; it may change the winning routes across a network. Express intended exceptions with narrowly scoped policy and test them under failure scenarios.
If the device and configuration permit it, routes with equal preference and cost can be installed together as ECMP. BGP attribute ordering and vendor preference defaults can be complex. Rather than memorize one universal sequence, inspect candidate routes, rejection reasons, and final RIB/FIB entries. State which source should take priority instead of relying on defaults.
Sources for this section IETF RFC 1812 · IETF RFC 3222
A selected route still needs a next-hop interface and MAC address before packets can leave↑
A selected route such as 203.0.113.0/24 via 192.0.2.1 is not the end of the lookup. The router must determine how to reach 192.0.2.1 and resolve the egress interface. This is recursive lookup. If the next hop cannot be resolved, a route visible in the RIB may fail to install properly in the FIB or may not forward packets.
For Ethernet output, the neighbor table's ARP or IPv6 Neighbor Discovery information supplies the next-hop MAC. If it is missing, neighbor resolution must happen first. Completing an IP route lookup is not enough: the egress link also needs a valid Layer 2 header before the packet can leave.
If a BGP route specifies 203.0.113.0/24 via 192.0.2.9, the router resolves 192.0.2.9 to a reachable interface using another route. The recursive chain may name another next hop, but must ultimately reach a connected interface. If an intermediate route disappears, the original BGP prefix can remain in the protocol table while FIB installation fails or is marked unresolved.
For Ethernet output, the final next-hop IP needs resolved ARP or ND information to build a header. If no entry exists, the router sends resolution packets and may queue or discard data packets meanwhile. An interface being up, a route existing, and a neighbor being resolved are separate conditions. If next-hop ping fails, distinguish a missing route, unanswered ARP, and a policy blocking only ICMP, using captures and adjacency state.
A missing next-hop route or a recursive lookup loop can make a parent prefix unusable even if it appears in the RIB. While ARP is incomplete, packets may wait for neighbor address resolution and are dropped if resolution fails. If the route to the tunnel destination disappears or points into the tunnel itself, forwarding through the logical next hop can also fail. Do not stop at the destination route's listed next hop: follow the recursive chain through to the final adjacency state.
Sources for this section IETF RFC 1812 · IETF RFC 1122 · IETF RFC 3222
The routing table has a route, but traffic fails? Check the FIB and adjacency↑
Scenario: The routing table shows a route to 203.0.113.20, but ping traffic does not get through.
- Look up the longest matching prefix for the destination. Do not judge by the default route alone.
- Record the selected route's source, metric, next hop, and egress interface.
- Check that the next hop has a valid connected or recursive route.
- Verify that the FIB contains the same route, without a discard or exception state.
- Inspect the neighbor table and ARP/ND packets to check whether Layer 2 adjacency resolution completes.
- Finally, check ACLs, policy-based routing, VRFs, and other features that affect whether forwarding is permitted or which routing context is used.
Run a route lookup for the exact destination and record the VRF, matching prefix, source protocol, next hop, and egress interface. Repeat the lookup for each recursive next hop until you reach a connected network. Check the FIB or hardware forwarding output for matching prefix and adjacency IDs. Compare the neighbor table's MAC and state with interface drop counters. This turns “a route exists” into specific conditions required for forwarding.
Use packet captures or sampling to determine whether traffic appears at the ingress interface but not the egress interface, narrowing the fault to a possible router-internal drop. If it leaves but never reaches the next router, inspect Layer 1/Layer 2 and the intervening link. Before changing policy, preserve ACL, PBR, VRF leak, and null-route hit evidence, then change one condition. Retest with a new flow using the same 5-tuple, checking FIB counters and the actual response. A changed control-plane display alone is not proof of recovery.
This procedure separates “route exists” into four types of evidence: the protocol database, RIB, FIB, and link forwarding. Record how far consistent values can be traced to distinguish a protocol problem from FIB programming or Layer 2 neighbor resolution.
Sources for this section IETF RFC 1812 · IETF RFC 3222
What to look for in the diagram Trace requests and responses from a host through multiple routers and ISPs, using the orange and green arrows. Read each device's next forwarding target alongside the failure example below, where the lack of a usable return route creates a blackhole for the response.
↔ Scroll horizontally to explore the diagram.
Glossary↑
Sources and verification
- IETF RFC 1812 — IPv4 router forwarding and route selection requirements
- IETF RFC 1122 — Internet host requirements for the IP layer and gateway handling
- IETF RFC 3222 — FIB terminology, routing information installation time, and forwarding performance metrics
The names and implementations of the RIB, FIB, and adjacency information, route-source preferences, and equal-cost path limits vary by platform. This article distinguishes RFC forwarding principles from common implementation models.