Route Table Longest Match Checker

Destination IP:

Use one literal address, such as 10.44.80.25 or 2001:db8:44:80::25.

Route table rows:

Enter one route per line; the checker normalizes CIDR networks and ranks matching rows by specificity first.

Rows stay local and overwrite the current table.

Same-prefix policy:

Choose how rows with the same destination prefix should be resolved.

Check route lookup inputs

{{ error }}

Host-bit warnings:

When enabled, host-address CIDR entries are still normalized but called out in the audit.

Inactive route ranking:

Leave off for normal forwarding checks; turn on only when comparing candidate or staged routes.

Row	Prefix	Range	Next hop	Rank	Match result	Copy
{{ row.row }}	`{{ row.prefix }}`	{{ row.range }}	{{ row.nextHop }}	{{ row.rank }}	{{ row.status }} {{ row.reason }}

Check	Status	Evidence	Action	Copy
{{ row.check }}	{{ row.status }}	{{ row.evidence }}	{{ row.action }}

No valid same-family routes are available for the ladder chart.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A single packet destination can fit inside several route entries at the same time. A broad default route, a regional summary, a site subnet, and a narrow static exception may all cover one address. Longest-prefix matching chooses the route with the most fixed leading bits, so 10.44.80.0/24 is more specific than 10.44.80.0/20 for a destination such as 10.44.80.25.

The rule is simple, but route-table reviews are often messy because forwarding decisions sit behind several kinds of evidence. A route may be present but inactive, a copied CIDR row may contain host bits, two rows may share the exact same prefix, or an IPv4 route may be pasted next to IPv6 routes in a dual-stack table. Cloud route tables add their own same-prefix priorities, while routers often separate route installation from packet forwarding. The longest prefix decides among matching installed or eligible rows; administrative preference, metric, source priority, or row order matter only after the relevant rows have the same prefix length.

Prefix length: The number after the slash. Larger numbers describe smaller address ranges and therefore more specific routes.
Default route: 0.0.0.0/0 for IPv4 or ::/0 for IPv6. It catches traffic only when no longer matching route applies.
Equal prefix: Two or more rows use the same destination CIDR. A separate tie rule is needed because specificity alone cannot choose one.
ECMP: Equal-cost multipath, where several same-prefix, same-cost next hops may remain valid winners together.

A broad route with a lower metric does not beat a narrower route that contains the destination.
A route from the wrong address family is valid table evidence, but it cannot carry the current packet.
A default route is a fallback, not a preferred shortcut over a more specific match.

Longest prefix route ladder where a slash twenty-four route wins over broader matches.

Overlaps are not an error by themselves. Aggregates keep tables compact, default routes provide a fallback, and narrow prefixes make exceptions possible during migrations, outages, or segmented cloud deployments. The mistake is treating a route table like a top-to-bottom checklist. Unless a platform says otherwise for identical destinations, the destination address is first compared against each route range, then the most specific covering prefix is chosen.

A route lookup is still only one part of troubleshooting. The chosen next hop can be unreachable, a firewall can block traffic later, policy routing can redirect packets, and a cloud target can be unhealthy. Longest-prefix analysis answers a narrower but important question: given these route rows and tie rules, which route should carry this destination?

How to Use This Tool:

Start with one destination address and a route-table snapshot from the device, cloud console, change request, or spreadsheet you are checking.

Enter one literal Destination IP, such as 10.44.80.25 or 2001:db8:44:80::25. IPv4 and IPv6 rows are evaluated separately.
Paste Route table rows. A header row is optional, comments beginning with # are ignored, and useful columns include prefix, next hop, metric, preference, source, state, table, and note.
Select the Same-prefix policy that matches the evidence you are modeling. Longest prefix is always evaluated first; the policy only decides rows with the same winning prefix length.
Use the sample buttons to reset the inputs to overlapping IPv4, AWS-style equal-prefix, or dual-stack examples when you want a known comparison case.
Turn on Host-bit warnings when pasted route rows may contain host addresses, such as 10.44.80.25/24, instead of clean network addresses.
Turn on Inactive route ranking only for planning or staged-route comparison. Leave it off when checking normal forwarding from active rows.
Review Match Ledger first, then use Tie-Break Audit and Prefix Match Ladder to explain the winning route to someone else.

Fix destination or prefix errors before relying on the result. Invalid rows are kept visible so the input problem is clear, but they cannot be treated as forwarding candidates.

Interpreting Results:

Winning route selected means at least one active row from the same IP family contains the destination. The primary result is the winning prefix, or an equal-cost set when the selected policy leaves multiple next hops tied. No active route match means no eligible same-family route covers the destination under the current settings.

Route lookup result interpretation cues
Ledger status	Meaning	What to check next
Winner	The row is the best active same-family route after longest-prefix and same-prefix rules.	Verify that the next hop, interface, or cloud target is healthy.
ECMP	More than one row remains tied under the selected equal-cost policy.	Confirm that equal-cost forwarding is intended on the platform being reviewed.
Matched	The destination is inside the route range, but the row lost to a more specific or better equal-prefix row.	Read the reason column before changing metrics or preferences.
Inactive	The row was excluded because its state looks inactive, disabled, down, rejected, suppressed, or withdrawn.	Enable inactive ranking only when comparing staged or disabled candidates.
Ignored	The route is valid but belongs to the other IP family.	Check whether the route table was expected to be dual-stack.
Error	The prefix could not be parsed as CIDR, an accepted default value, or an IPv4 dotted-mask row.	Correct the row before using it as evidence.

The Tie-Break Audit explains the lookup in plain stages: destination parsing, route corpus quality, longest prefix, same-prefix policy, winning next hop, and default-route use. When host-bit warnings are enabled, the audit also calls out rows normalized from host-style CIDR entries.

A lower metric on a broader route does not beat a longer matching prefix. If the result looks wrong, compare the Prefix, Range, and Rank columns before changing administrative preference or metric values.

Technical Details:

A route prefix describes a contiguous address range. IPv4 prefixes are measured across 32 bits, while IPv6 prefixes are measured across 128 bits. A destination belongs to a prefix when the destination and the route network share the same leading bits for the prefix length. Rows from the other address family can remain useful evidence for the table, but they cannot match the current destination.

Longest-prefix matching is a range and specificity problem, not a text-sorting problem. The route address is first normalized to its network address, the address range is calculated from the prefix length, and the destination is tested against that range. Among the matching active candidates, the row with the largest prefix length is the most specific route. A default route has prefix length zero, so it is the least specific match.

Rule Core:

The essential prefix test can be written as a masked comparison. The mask keeps the leading prefix bits and clears the host bits before the destination and route network are compared.

matches = (destination & mask) = (route & mask)

winner = matching candidate with the maximum prefix length

Route lookup decision order
Stage	Rule	Result cue
Parse destination	Accept one literal IPv4 or IPv6 address.	An invalid destination stops the lookup until corrected.
Parse prefixes	Accept CIDR rows, `default`, `any`, and IPv4 address plus dotted-mask rows.	Invalid prefixes remain visible as error rows.
Normalize networks	Clear host bits outside the prefix before calculating the route range.	Host-bit warnings identify rows that need cleanup.
Apply state	Exclude inactive-looking rows unless inactive ranking is enabled.	Normal mode models forwarding; planning mode compares staged rows.
Find coverage	Keep same-family rows whose range contains the destination.	These rows form the candidate set.
Choose prefix	Sort matching candidates by descending prefix length.	The longest matching prefix wins before tie rules are used.
Resolve tie	Apply the selected same-prefix policy only within the winning prefix length.	The result is one next hop, a blackhole route, or an equal-cost set.

Host-bit normalization keeps the calculation deterministic. For example, 10.44.80.25/24 covers the same network as 10.44.80.0/24 after the host bits are cleared. The lookup can still use the normalized route, but the warning is useful because real device and provider exports usually expect route destinations to be network addresses.

Same-Prefix Policy:

Equal-prefix rows need a second rule because their address ranges are identical. The policy should match the route-table evidence being reviewed, especially when comparing router exports with cloud route tables.

Same-prefix tie-break policies
Policy	Equal-prefix order	Best use
Router table	Lower preference, then lower metric, then earlier row.	General router-style checks where both administrative preference and metric are present.
Metric only	Lower metric, then earlier row.	Tables where equal-prefix routes already share the same administrative preference.
Equal-cost next hops	Rows with the same winning prefix, preference, and metric remain together.	ECMP reviews where several next hops should carry the same destination.
AWS-style source priority	Local or connected, static, prefix-list, propagated or VPN or Direct Connect, BGP, then other sources; preference and metric break later ties.	Cloud route-table checks where source priority matters after a CIDR tie.
First row	Earlier row after prefix length.	Spreadsheet or vendor exports where row order is the only equal-prefix evidence.

Input and Output Fields:

Route table checker fields and outputs
Area	What it contains	Why it matters
Route rows	Prefix and next hop, with optional metric, preference, source, state, table, and note columns.	Extra columns improve tie-break explanations without changing the longest-prefix rule.
Match Ledger	Each row's normalized prefix, range, next hop, rank, status, and reason.	Use it to see which broad routes matched but lost.
Tie-Break Audit	Parsing quality, candidate counts, winning prefix, selected policy, winning next hop, and default-route use.	Use it as the short explanation for a change review or incident note.
Prefix Match Ladder	A chart of same-family route prefixes by prefix length and match status.	Use it to spot the most specific matching route visually.
JSON	Inputs, route counts, winning routes, ledger rows, audit rows, chart data, and errors.	Use it when you need a structured record for a ticket or repeat check.

Limitations, Privacy, and Accuracy Notes:

The result models prefix containment and the selected tie rules for the rows you provide. It does not test interface state, neighbor reachability, tunnel health, firewall policy, NAT, policy-based routing, BGP path attributes beyond the selected source-style policy, or whether a route is actually installed in a live forwarding table.

Use current route-table evidence when troubleshooting live traffic.
Keep inactive ranking off for normal forwarding checks.
Use platform documentation when equal-prefix rules are provider-specific.
Treat blackhole, null, discard, or reject next hops as intentional drop routes, not healthy forwarding paths.
Verify the selected next hop or target in the actual network before closing an incident.

The lookup is performed in the browser. Treat pasted route inventories as sensitive if you copy a browser URL, reload a query-filled page, export a file, or paste production next hops into a shared ticket.

Worked Examples:

Overlapping IPv4 Routes

With destination 10.44.80.25, the default route, 10.44.0.0/16, 10.44.80.0/20, and 10.44.80.0/24 all cover the packet. Match Ledger marks 10.44.80.0/24 as the winner because /24 is the longest matching prefix, even if broader rows have lower metrics.

AWS-Style Equal Prefix

With destination 172.31.0.15, two 172.31.0.0/24 rows can both match. Because their prefix length is identical, Same-prefix policy decides the winner. Under AWS-style source priority, a static route can beat a propagated VPN route at the same CIDR.

Dual-Stack Table

With destination 2001:db8:44:80::25, IPv4 rows are Ignored because they cannot match IPv6 traffic. The IPv6 2001:db8:44:80::/64 row wins over broader IPv6 prefixes such as 2001:db8:44::/48 or ::/0.

Host Bits in a Route Row

A pasted row such as 10.44.80.25/24 is normalized to 10.44.80.0/24 before matching. With Host-bit warnings on, the audit calls out the cleanup issue while still showing the deterministic lookup result.

FAQ:

Does a lower metric beat a longer prefix?

No. Prefix length is evaluated before metric among matching routes. Metric is only used after the rows have the same winning prefix length under the selected policy.

Why was an IPv4 or IPv6 row ignored?

The row belongs to the other IP family. IPv4 routes cannot carry IPv6 destinations, and IPv6 routes cannot carry IPv4 destinations, even when they appear in the same pasted table.

When should inactive routes be included?

Include inactive routes for planning, staged-route comparison, or post-change review. Leave them excluded when checking normal forwarding behavior from active rows only.

What does a blackhole winner mean?

A blackhole, null, discard, or reject route is still a route choice. If it wins, traffic for the destination is intentionally dropped by that selected route.

Does the checker know every vendor route-selection rule?

No. It models longest-prefix matching and the selected same-prefix policy. Vendor installation logic, protocol attributes, health checks, and policy routing still need platform-specific review.

Glossary:

Prefix length: The number of leading address bits that define the route network, such as /24 or /64.
Longest-prefix match: The forwarding rule that prefers the most specific matching route.
Default route: The broadest route, 0.0.0.0/0 or ::/0, used only when no more-specific route matches.
Administrative preference: A route-selection value used to choose among equal-prefix rows or installation candidates, with lower values usually preferred.
ECMP: Equal-cost multipath, where multiple same-cost next hops can remain winners together.
Host bits: Address bits outside the network prefix that should be zero in a clean route destination.

References:

RFC 1812: Requirements for IP Version 4 Routers, RFC Editor.
RFC 4632: Classless Inter-domain Routing (CIDR), RFC Editor.
How route priority works, Amazon Web Services.
Route tables and AWS Site-to-Site VPN route priority, Amazon Web Services.
Configure Route Selection for Routers, Cisco.