Route Table Longest Match Checker
Check IPv4 or IPv6 route-table rows against a destination, rank longest-prefix matches, apply tie-break policy, and audit next-hop winners before changes.{{ result.summaryTitle }}
| 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 }} |
Introduction:
Longest-prefix matching is the rule routers use to choose the most specific route that contains a packet destination. A route for 10.44.80.0/24 beats 10.44.80.0/20 for 10.44.80.25 because the /24 fixes more leading address bits. If no more-specific route matches, a broader aggregate or default route can still carry the traffic.
This matters whenever route tables overlap. A default path, a regional summary, a site subnet, and a host route can all be valid at the same time, but only one prefix length is most specific for a given destination. Misreading that order can send traffic to a backup path, hide a missing subnet route, or make a static exception look less important than it really is.
Route lookup should be read as a forwarding check, not a full proof of network health. The selected next hop still has to exist, the interface or cloud target still has to work, and platform-specific policy can decide which equal-prefix route is installed before forwarding begins. Longest-prefix analysis answers the narrower question: given these rows and this destination, which prefix should win under the selected tie-break rule?
The useful result is an operational explanation of why a route wins or loses. It helps during firewall change review, cloud route-table checks, migration cutovers, dual-stack testing, and incident triage when a packet appears to follow a broader or less expected path.
Technical Details:
A route prefix describes a contiguous address range. The prefix length says how many leading bits must match between the destination address and the route network. IPv4 routes compare 32-bit addresses, while IPv6 routes compare 128-bit addresses. Rows from the other address family cannot match the destination and should be treated as ignored evidence, not as backup routes.
The forwarding lookup begins by finding every active same-family prefix that contains the destination. The most specific candidate is the one with the largest prefix length. A default route is simply the shortest possible prefix, 0.0.0.0/0 for IPv4 or ::/0 for IPv6, so it wins only when no longer matching prefix is available.
Rule Core:
The core match can be expressed as a masked comparison. The destination belongs to a route when the destination and route address share the same network bits for that prefix length.
After all matching prefixes are known, route selection sorts them by prefix length first. Equal prefix lengths are then resolved by the selected policy. This separation is important: metric, preference, row order, source type, or equal-cost handling should not let a broader /16 beat a matching /24.
| Stage | Rule | Result cue |
|---|---|---|
| Parse destination | Accept one literal IPv4 or IPv6 destination address. | Rows from the other address family are listed but cannot win. |
| Parse prefixes | Accept CIDR rows, default or any, and IPv4 dotted-mask rows such as 10.44.80.0 255.255.255.0. |
Invalid prefixes stay visible as errors in the ledger. |
| Apply state | Exclude inactive, disabled, down, rejected, suppressed, or withdrawn rows unless inactive rows are included for planning. | The normal view models forwarding; the planning view can compare staged candidates. |
| Find coverage | Keep same-family rows where the destination lies between the normalized network start and end address. | Matching rows form the candidate set. |
| Choose prefix | Sort matching candidates by descending prefix length. | The longest matching prefix wins before equal-prefix rules are considered. |
| Resolve tie | Apply the selected same-prefix policy only among rows with the winning prefix length. | One next hop, a blackhole route, or an equal-cost set is reported. |
Host bits are normalized before matching. For example, 10.44.80.25/24 is evaluated as 10.44.80.0/24. When host-bit flagging is enabled, that correction appears in the audit so the route inventory can be cleaned up even though the lookup still has a deterministic answer.
| Policy | Equal-prefix order | Best use |
|---|---|---|
Router table |
Lower preference, then lower metric, then earlier row. | General router-style checks where administrative preference and metric are both present. |
Metric only |
Lower metric, then earlier row. | Tables where all equal-prefix routes have 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, then static, prefix-list, propagated or VPN, BGP, then other sources, with preference and metric as later ties. | Cloud route-table reviews that need static or local targets to beat propagated rows at the same CIDR. |
First row |
Earlier row after prefix length. | Spreadsheet or vendor exports where row order is the only available equal-prefix evidence. |
The route source can provide a default preference when the row does not include one. Common sources such as local, connected, static, BGP, EIGRP, OSPF, IS-IS, RIP, propagated, VPN, and iBGP are mapped to ordinary preference-style values, with unknown sources treated neutrally. These values help model route-table evidence, but real devices and cloud platforms can still have their own installation rules before a row appears in the forwarding table.
| Result surface | What it returns | How to read it |
|---|---|---|
Match Ledger |
Every parsed row with normalized prefix, address range, next hop, rank, status, and reason. | Use it to prove why broader, inactive, invalid, and other-family rows did not win. |
Tie-Break Audit |
Destination parse, route corpus counts, longest-prefix evidence, selected policy, winning next hop, and default-route usage. | Use it as the short explanation for a change ticket or incident note. |
Prefix Match Ladder |
A chart of same-family route prefix lengths with winner, matched, no-match, and inactive states. | Use it to spot whether the chosen path is a narrow override, a summary, or a default route. |
JSON |
Structured inputs, route counts, winning routes, ledger rows, audit rows, ladder data, and errors. | Use it when the lookup evidence needs to be archived or compared outside the page. |
Everyday Use & Decision Guide:
Start with one destination address and paste the route rows in the same order as the router, cloud console, ticket, or spreadsheet. Include a header when you have one. The useful columns are prefix, next hop, metric, preference, source, state, and note, but a simple positional list still works when the first field is the prefix.
Leave Router table selected for a normal first pass. It keeps longest prefix as the first rule and then uses preference, metric, and row order for equal-prefix routes. Switch to AWS-style source priority for a VPC route-table review with local, static, prefix-list, and propagated routes. Use Equal-cost next hops when several identical-cost rows should remain winners together instead of being collapsed to one row.
- Use the overlap sample to check ordinary IPv4 summaries and static overrides.
- Use the AWS-style sample when static and propagated rows share the same destination CIDR.
- Use the dual-stack sample to confirm that IPv6 rows are evaluated separately from IPv4 rows.
- Keep inactive rows excluded for forwarding checks. Include them only when modeling staged routes or candidate changes.
- Turn on host-bit flagging when route rows come from hand-edited notes and need cleanup evidence.
The main stop-and-verify cue is a winner that surprises you. If a default route wins, check whether the expected more-specific prefix is missing, inactive, malformed, or from the wrong address family. If a blackhole, discard, reject, or null target wins, treat the result as an intentional drop path until the route-table owner confirms otherwise.
Another common mistake is treating metric as a global override. Metric helps only after the destination has matched the same prefix length under the selected policy. A /24 route with a high metric still beats a matching /20 route with a low metric because the /24 is more specific.
For change review, read the summary first, then confirm the winning row in Match Ledger and the reason in Tie-Break Audit. Use the ladder chart when the table is long enough that a visual prefix-length check is faster than scanning every row.
Step-by-Step Guide:
- Enter the packet destination as one IPv4 or IPv6 literal address.
- Paste route rows with one route per line. Keep comments on separate lines beginning with
#. - Choose the same-prefix policy that matches the route table you are modeling.
- Open advanced settings only when inactive-row planning or host-bit cleanup is part of the review.
- Check the summary winner, then use
Match Ledgerto confirm which broader rows lost. - Use
Tie-Break Auditwhen you need a compact explanation of the selected route. - Open
Prefix Match Ladderfor a quick view of route specificity across the same address family. - Copy or download the table or structured output only after the parse errors and warning rows have been reviewed.
Interpreting Results:
Winner means one active same-family row contains the destination and ranks first after longest-prefix and equal-prefix policy rules. ECMP means several rows share the same winning class and should be treated as an equal-cost set under the selected policy. Matched means the row contains the destination but lost to a more specific route or to an equal-prefix tie-break.
Ignored often points to a useful clue rather than bad data. An IPv4 route cannot match an IPv6 destination, and an IPv6 route cannot match an IPv4 destination. In dual-stack reviews, ignored rows confirm that both families were present but only one family was relevant to the destination being tested.
Inactive rows are excluded from normal forwarding checks. If including inactive rows changes the winner, the lookup should be labeled as planning evidence rather than current forwarding evidence. Error rows should be fixed before relying on the result because an invalid prefix may be the missing route that would have changed the answer.
A clear lookup still does not verify next-hop reachability, route propagation state, firewall policy, NAT behavior, or platform health. Treat the selected route as a routing-table explanation and then confirm the live device, VPC, VPN, or fabric evidence before making a production change.
Worked Examples:
IPv4 summary with static override
A destination of 10.44.80.25 matches 0.0.0.0/0, 10.44.0.0/16, 10.44.80.0/20, and 10.44.80.0/24. The /24 route wins because it has the longest prefix. Its higher metric does not matter against broader matching prefixes.
Same CIDR in a cloud route table
If two rows both use 172.31.0.0/24, longest-prefix matching cannot separate them because the prefix length is identical. With the AWS-style policy, a static gateway target can beat a propagated VPN route at the same CIDR. With the general router policy, preference and metric decide the equal-prefix order.
Dual-stack table
A destination of 2001:db8:44:80::25 can match ::/0, 2001:db8:44::/48, and 2001:db8:44:80::/64. IPv4 rows such as 10.44.80.0/24 stay visible in the ledger but are ignored for that IPv6 lookup.
FAQ:
Does administrative preference beat longest prefix?
No for rows already being compared as forwarding candidates with different prefix lengths. The longest matching prefix is selected first. Preference and metric help resolve rows at the same prefix length under the selected policy.
Why did the default route win?
The destination was not covered by any active, valid, same-family route with a longer prefix. Check for a missing subnet route, a disabled row, an invalid CIDR, or an IPv4 and IPv6 mismatch.
Can this check ECMP?
Yes. The equal-cost policy keeps same-prefix rows together when their winning attributes match. The result reports an equal next-hop set instead of forcing a single row.
Are route rows sent anywhere?
No server-side processing is needed for this lookup. The pasted route rows are parsed and evaluated in the browser session, and export actions use the result already present on the page.
Why does the tool normalize host bits?
Route inventories sometimes contain host-bearing CIDRs such as 10.44.80.25/24. Normalization evaluates the real network, 10.44.80.0/24, while the host-bit audit warns that the source row should be cleaned up.
Glossary:
- CIDR
- Classless Inter-Domain Routing notation, written as an address plus prefix length, such as
10.44.80.0/24. - Longest prefix match
- The route lookup rule that prefers the matching prefix with the largest prefix length.
- Preference
- A route priority value used by the checker for same-prefix ranking. Lower values are preferred.
- Metric
- A route cost value used after prefix length and, depending on policy, after preference. Lower values are preferred.
- ECMP
- Equal-cost multipath, where multiple next hops remain valid winners for the same destination and prefix.
- Default route
- The
/0route that covers destinations without a more-specific matching prefix.