Routing tables — what an entry actually is

The routing table is the kernel’s answer to “where does this packet go?”. Every forwarding decision the kernel makes reads one entry from this table and follows the next-hop. The routing engineer who does not understand the table — every field, every state, every interaction with the dynamic routing daemon — cannot debug routing incidents because every debugging command they run returns a row of the table and they cannot read it.

This lesson is the operator’s foundation in the routing table: the fields, the sources, the difference between the kernel FIB and the FRRouting RIB, and the failure modes that surface as routing incidents.

What is in a routing-table entry

A routing-table entry in the Linux kernel has seven fields. The operator who knows all seven by heart can read any output and know exactly what the kernel will do with a packet.

The ip route show output uses a column-aligned format. A real-world example:

default via 192.0.2.1 dev eth0 proto static metric 100
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.50
10.0.0.0/24 via 192.0.2.10 dev eth0 proto bgp metric 20
blackhole 10.10.0.0/16
unreachable 192.0.2.128/25

The four lines show four different entry types:

• A default route via 192.0.2.1, statically configured, with metric 100.
• A connected route for 192.0.2.0/24 (added by the kernel when the interface came up).
• A BGP-learned route to 10.0.0.0/24 via 192.0.2.10.
• A blackhole route to 10.10.0.0/16 (discarded silently).
• An unreachable route to 192.0.2.128/25 (rejected with ICMP unreachable).

The kernel FIB vs the FRRouting RIB

VyOS has two routing tables, in two different places:

• The kernel FIB (ip route show) — what the kernel forwards packets based on. Plain text, easy to read, but cannot be modified directly by routing protocols (they install via netlink).
• The FRRouting RIB (vtysh show ip route) — what FRRouting knows about. More information, including the source protocol, the metric, the best-path selection criteria, and the time the route was last updated.

The two are related but not identical. FRRouting learns routes from BGP, OSPF, IS-IS, RIP, and the kernel; it runs best-path selection on each protocol’s candidates and installs the “best” route into the kernel FIB via netlink. The kernel FIB is a strict subset of the FRRouting RIB plus the kernel’s own entries (connected, static).

flowchart LR
  subgraph "FRRouting RIB"
    B1["BGP table"]
    O1["OSPF LSDB"]
    S1["Static config"]
    Z["Zebra daemon"]
  end
  subgraph "Kernel FIB"
    K1["Connected routes\n(admin distance 0)"]
    K2["Static routes\n(admin distance 1)"]
    K3["Best routes from each protocol"]
    K4["Blackhole / unreachable"]
  end
  B1 --> Z
  O1 --> Z
  S1 --> Z
  Z -->|"netlink"| K3
  K1 --> K2
  K2 --> K3
  K3 --> K4

A route that exists in FRRouting but not in the kernel means FRRouting chose not to install it. Most commonly, the route is in FRRouting’s BGP table but FRRouting’s best-path algorithm rejected it (or the BGP inbound filter rejected it before best-path ran).

A route that exists in the kernel but not in FRRouting is the opposite direction: a connected, static, or kernel-level entry that the routing engine knows about but did not originate.

Administrative distance and protocol preference

The Linux kernel assigns each route an administrative distance (AD) based on its source. The lower AD wins when two routes cover the same prefix.

The AD is the kernel’s answer to “which source do I trust more for this prefix?”. A static route (AD 1) always beats an OSPF route (AD 110) for the same prefix. iBGP (AD 200) always loses to eBGP (AD 20) for the same prefix.

The operator who sees “the route I configured is not being used” is almost always losing to AD. The fix is either removing the competing entry, changing the AD (rare, with the metric keyword), or accepting that the AD is correct and the dynamic route is the right answer.

Reading the routing table in production

The diagnostic commands:

# Full kernel FIB
ip route show

# Specific prefix
ip route show 10.0.0.0/24

# What the kernel would do with a packet
ip route get 8.8.8.8

# All routing tables
ip route show table all

# A specific table
ip route show table main
ip route show table local

# Detailed
ip -d route show

# Counters (on Linux 4.4+)
ip -s route show

ip route get 8.8.8.8 is the most useful single command. It performs the lookup the kernel would do for a packet and returns the next-hop, the egress interface, and the route that won. If the answer is RTNETLINK answers: Network is unreachable, the kernel has no route to that destination at all — the routing table is the problem. If the answer is a route with a next-hop, the kernel has a route and the issue is elsewhere (Layer 2, firewall, NAT).

flowchart TB
  P["Packet to 8.8.8.8"] --> L1{"Lookup in\nlocal table"}
  L1 -->|match| L1a["Return local\n(deliver locally)"]
  L1 -->|no match| L2{"Lookup in\nmain table"}
  L2 -->|match| L2a["Return next-hop + dev"]
  L2 -->|no match| L3["Network is unreachable"]

The lookup walks the tables in a defined order. On a VyOS router the default tables are local (kernel-installed routes for the router’s own IPs) and main (everything else).

Failure modes

Routes that disappear

A route that was in the FIB and now is not:

• The interface went down (ip link show dev eth0 to verify).
• The dynamic protocol withdrew the route (vtysh show ip bgp ... or vtysh show ip ospf neighbor to verify).
• The static route was removed by an administrator or by an automation script.
• A routing-protocol session reset (show log to verify).

Routes that conflict

Two routes to the same prefix with different next-hops:

• The lower-AD route wins. The other route is installed in FRRouting’s RIB but not in the kernel FIB.
• Use ip route show <prefix> to see which routes exist for the prefix. The lowest AD wins.

Routes that point to the wrong place

A route that points to a next-hop that no longer exists or is unreachable:

• ip route get <dst> shows the route’s next-hop.
• ip neigh show <next-hop> shows the kernel’s neighbour state for that next-hop.
• If the neighbour is FAILED, the route is installed but the kernel cannot forward — the issue is Layer 2, not routing.

Routes that nobody installed

A prefix the operator expected to be in the routing table that is not there:

• The dynamic protocol did not advertise it.
• The inbound filter rejected it.
• The best-path algorithm chose a different route.
• The redistribution filter removed it.
• Check vtysh show ip bgp <prefix> and vtysh show ip ospf database.

Validation

The validation sequence for “the route is wrong”:

1. The route exists: ip route show <prefix> returns the expected entry.
2. The route is the best: vtysh show ip bgp <prefix> (if BGP) shows the route with *> (best path).
3. The next-hop is correct: ip route get <dst> returns the expected next-hop and egress interface.
4. The next-hop is reachable: ip neigh show <next-hop> returns REACHABLE or STALE.
5. The interface is up: ip link show dev <ifname> returns state UP.
6. The path is healthy: traceroute <dst> or tracepath <dst> confirms the path works end-to-end.
7. The firewall allows it: conntrack -L -s <src> -d <dst> shows the connection being tracked.
8. The application works: actual end-to-end test from a host.

If every check passes, the routing table is fine. If traffic still does not flow, the issue is not routing.

Cross-course references

• The Linux course’s V-Linux-NetConfig covers the kernel routing table from the host perspective.
• The lesson on administrative distance in this part covers the AD ordering in depth.
• The lessons on BGP, OSPF, and redistribution in later parts cover how dynamic routes enter and exit the table.

Quiz

Production discipline

The routing table is the routing engineer’s primary instrument. Every debugging session begins with reading the table. Every configuration change ends with reading the table to confirm the change is effective. Every incident report asks “is the route there?” before asking “is the route correct?”.

Plan the routing table once. Document the AD expectations. Validate the AD conflicts. Then routing either works or fails predictably.