Route Table Longest Match Checker

A destination address can belong to several routes at once. An IPv4 address inside 10.44.80.0/24 also belongs to 10.44.0.0/16 and the default route 0.0.0.0/0. Forwarding begins by keeping the matching route with the longest prefix, because more prefix bits describe a smaller and more specific address range.

The prefix decision comes before a metric or administrative preference. A broad route with a lower metric does not beat a longer matching prefix. Metrics, route source, platform precedence, or equal-cost multipath matter only when two or more eligible routes reach the same winning prefix length.

IPv4 and IPv6 are separate address families. An IPv4 default route cannot carry an IPv6 destination, and an IPv6 prefix cannot win an IPv4 lookup. A table may contain both families, but the forwarding question must be answered within the destination's family.

A static route-table comparison explains selection logic, not live reachability. The chosen next hop can still be down, filtered, recursively unresolved, policy-routed differently, or overridden by a platform rule that is absent from the entered rows.

How to Use This Tool:

Start with the exact destination and a route-table extract from the device or platform being reviewed.

1. Enter one IPv4 or IPv6 Destination IP.
2. Paste route rows with the prefix first, or include a CSV header for prefix, next hop, metric, preference, source, state, and note columns.
3. Choose the Equal-prefix rule that best represents the target platform. Use AWS VPC-style precedence only for an AWS-oriented comparison.
4. Enable Host-bit normalization when route-table hygiene matters, and include inactive routes only for a deliberate planning comparison.
5. Read the winning prefix and next hop, then review excluded, normalized, or invalid rows before relying on the result.

Interpreting Results:

The winner is the eligible same-family route with the greatest prefix length. Broader matching routes remain useful evidence because they show the fallbacks that would become active if the specific route were removed.

• No route match means no eligible entered prefix contains the destination; check for a missing default route or an excluded inactive row.
• Winner identifies one selected prefix. ECMP winner identifies several routes that share the winning prefix, preference, and metric under the ECMP policy.
• Invalid, Other family, and Inactive rows did not participate in the normal lookup.
• A blackhole or discard route can win correctly and still explain why traffic is intentionally dropped.

Verify the selected next hop on the real device or cloud platform. A deterministic table result does not test next-hop health, recursive resolution, interface state, or the actual forwarding information base.

Technical Details:

Classless Inter-Domain Routing (CIDR) represents an address range as a network address and prefix length. Matching compares only the leading prefix bits. A route with host bits set is normalized to its network address before containment is tested.

Lookup and Rule Core:

1. Parse the destination as a 32-bit IPv4 or 128-bit IPv6 address.
2. Parse up to 250 route rows, normalize each CIDR to its network prefix, and reject invalid metrics, preferences, masks, and addresses.
3. Keep valid routes from the destination's address family. Exclude inactive rows unless the planning option includes them.
4. Retain routes whose normalized range contains the destination.
5. Sort matching routes by prefix length from greatest to smallest.
6. Apply the selected equal-prefix policy only among routes at the winning prefix length.

The AWS option is a bounded source-class model. It does not reproduce every AWS route-table type, prefix-list tie, health rule, or service-specific exception. Its result depends on accurate source labels in the entered data.

Parsing and Normalization:

Route text may contain up to 200,000 characters; rows above the first 250 are reported and excluded. Rows may use CIDR notation, the words default or any, or an IPv4 address followed by a contiguous dotted-decimal mask. Blank lines and lines beginning with # are ignored. A recognized header can use common alternatives such as destination, network, gateway, cost, distance, protocol, or status.

A missing metric becomes 0. A missing preference uses a source-based default, including 0 for local or connected, 1 for static, 20 for eBGP, 90 for EIGRP, 110 for OSPF, 115 for IS-IS, 120 for RIP, 150 for propagated or VPN, and 200 for iBGP; an unrecognized source defaults to 100. Explicit preferences must be 0 to 255, and explicit metrics must be 0 to 4,294,967,295.

Host-address CIDRs are always normalized for matching. The review option adds a warning and calls out the original form; it does not change which network the prefix represents.

Limitations, Privacy, and Accuracy Notes:

This is a static forwarding-model review, not a query to a router, kernel, or cloud account.

• Policy routing, virtual routing tables, recursive next-hop lookup, BGP attributes, tunnel health, and vendor-specific exceptions are outside the entered model.
• Inactive routes are excluded by default. Including them is useful for planning but can produce a route that would not forward traffic now.
• Destination and route rows are processed in the browser; no live route table is fetched.

Worked Examples:

References:

• RFC 1812: Requirements for IP Version 4 Routers, RFC Editor, June 1995.
• RFC 7285: Application-Layer Traffic Optimization Protocol, RFC Editor, December 2014.
• How route priority works, Amazon Web Services.
• How to trace an IPv6 route with traceroute, Simplified Guide.