Longest Prefix Match

Longest Prefix Match compares a packet's destination IP address against destination prefixes in the applicable forwarding table. A prefix consists of an address and a prefix length, such as 10.20.0.0/16. The length identifies how many leading bits must match. A longer matching prefix describes a smaller address range and is therefore more specific. IPv4 and IPv6 use the same principle, but their routes belong to separate address families and are evaluated independently.

Suppose a routing table contains 0.0.0.0/0 toward an internet gateway, 10.0.0.0/8 toward a hybrid connection, and 10.20.0.0/16 toward a private network attachment. Traffic for 10.20.5.7 matches all three destinations, but the /16 route wins. Traffic for 10.30.5.7 matches the /8 and default routes, so the /8 wins. The default route is the least specific IPv4 route and is used only when no more-specific applicable route matches.

Route selection must be evaluated at each routing boundary. In AWS, a subnet's associated VPC route table first determines whether traffic goes toward a peering connection, transit gateway, virtual private gateway, or another supported target. If traffic reaches a transit gateway, the transit gateway route table associated with the ingress attachment determines its next hop. A correct route in one table does not compensate for a missing or incorrect route in another. Return traffic also needs a valid path, although its route need not be identical to the forward path.

Distinguish forwarding lookup from learning and selecting routes. BGP exchanges reachability information, and route propagation makes eligible learned routes available in configured routing tables. Neither process replaces longest prefix matching. A learned /24 can be preferred for matching destinations over a static /16. When routes have the same destination prefix, however, prefix length cannot distinguish them; route-source priority and platform-specific selection rules apply. For example, AWS VPC and Transit Gateway route tables prefer a static route over a propagated route for an identical destination prefix. AWS also defines special routing rules for certain targets and destinations, including VPC local routing, so not every theoretically possible override is supported.

For a hybrid design, consider a transit gateway table containing 172.16.0.0/16 toward a Direct Connect gateway attachment and 172.16.40.0/24 toward a VPN attachment. Traffic to 172.16.40.10 takes the VPN path despite the broader Direct Connect route. This can intentionally steer a branch network, but it can also unexpectedly move traffic onto a higher-latency or differently priced connection. BGP path attributes for the /16 do not make it outrank the matching /24 during forwarding lookup.

More-specific routes provide precise traffic steering, while summarized routes reduce route count and operational complexity. Excessive exceptions consume route quotas, complicate troubleshooting, and can create asymmetric paths through stateful firewalls. Summaries also require care: an aggregate can continue attracting traffic even when a component network is unreachable. A selected route with an unavailable target, or an explicit blackhole route, does not generally cause forwarding to retry a less-specific route. Failover requires the relevant route to be withdrawn, replaced, or otherwise changed by the platform's supported mechanisms.

When troubleshooting, identify the destination address, inspect the table actually used at each hop, find every matching prefix, and then evaluate the longest match and any same-prefix priority rules. Check route propagation settings, BGP advertisements, route state, and the return path. Finally, verify security groups, network ACLs, and appliance policies separately: selecting a route does not authorize traffic. Longest prefix matching also does not make VPC peering transitive or turn an unsupported connectivity topology into a supported one.