Subnet Match
Check which prefixes in a list contain a given IPv4 address, with longest-prefix match highlighted the way a router would resolve it.
Result
Evaluation
| Prefix | Range | Result |
|---|---|---|
| 0.0.0.0/0 | 0.0.0.0 - 255.255.255.255 | match |
| 10.0.0.0/8 | 10.0.0.0 - 10.255.255.255 | match |
| 10.5.0.0/16 | 10.5.0.0 - 10.5.255.255 | match |
| 10.5.9.0/24 | 10.5.9.0 - 10.5.9.255 | match |
| 10.5.9.128/25 | 10.5.9.128 - 10.5.9.255 | MATCH (longest) |
| 192.168.0.0/16 | 192.168.0.0 - 192.168.255.255 | no match |
About Subnet Match
Given an address and a set of prefixes, this tool answers two different questions at once: which prefixes contain the address, and which one a router would actually choose. Those are not the same answer, and confusing them is behind a lot of "but the route is right there" incidents.
Longest-prefix match
A routing table lookup ignores order and picks the most specific matching entry. If 10.0.0.0/8 and 10.5.9.128/25 both contain the destination, the /25 wins regardless of protocol, metric or where it sits in the table. Administrative distance and metrics only break ties between routes of the same prefix length.
Why ACLs behave differently
Access lists and firewall rule sets are evaluated top to bottom and stop at the first match. A broad permit placed above a specific deny makes the deny unreachable - the exact opposite of routing behaviour.
Common use cases
- Working out which route a destination will take before making a change.
- Checking whether a customer address falls inside an allocated block.
- Verifying that a firewall address group really covers the host you were asked about.
Edge cases and gotchas
- 0.0.0.0/0 matches everything - it will always appear as a match and is only chosen when nothing more specific exists.
- A prefix with host bits set (10.5.9.130/24) is normalised to its network address before comparison.