Wildcard Mask Calculator for ACLs and OSPF

What a wildcard mask is and why it looks backwards

A wildcard mask tells a router which bits of an address to compare and which to ignore. A 0 bit means the bit must match; a 1 bit means don't care. That is the exact opposite of a subnet mask, where the 1 bits identify the network portion, which is why the wildcard is often called an inverse mask.

The reason the convention exists is that an access list is a pattern matcher, not an interface configuration. A subnet mask answers “where does this network end?” A wildcard answers “which bits do I bother to look at?” The second question is more general: it can express patterns that are not networks at all, such as every odd-numbered address in a range, which a subnet mask cannot describe. Cisco IOS uses wildcards in numbered and named access lists, in OSPF and EIGRP network statements, and in route-map match clauses.

The conversion itself is a subtraction you can do in your head once you have seen it a few times: subtract each octet of the mask from 255. A /24 has mask 255.255.255.0, so the wildcard is 0.0.0.255. A /26 has mask 255.255.255.192, so the wildcard is 0.0.0.63. If you need the prefix and mask themselves rather than the inverse, the subnet mask and CIDR converter handles that direction, and the IPv4 subnet calculator gives the full properties of the resulting network.

The arithmetic, bit by bit

Wildcard = 255.255.255.255 − subnet mask. The subtraction runs octet by octet and never borrows, because every octet of a subnet mask lies between 0 and 255. It is the bitwise complement written in decimal, which is convenient because mask octets only ever take nine values: 0, 128, 192, 224, 240, 248, 252, 254 and 255. Their complements are 255, 127, 63, 31, 15, 7, 3, 1 and 0.

Matched addresses = 2 raised to the number of 1 bits in the wildcard. Each ignored bit is free to be 0 or 1, so each one doubles the set of addresses that match. A wildcard of 0.0.3.255 has 2 + 8 = 10 one-bits, so it matches 2¹⁰ = 1,024 addresses. This is the calculation that catches errors: if the count is not what you expected, the mask is wrong regardless of how plausible it looks.

The range comes from clearing and setting the ignored bits. The lowest matching address has every don't-care bit set to 0; the highest has every one set to 1. When the 1 bits are all at the right-hand end — a contiguous wildcard — every address between those two endpoints matches, and the pattern is exactly a subnet. When they are not contiguous, the endpoints are still correct but the matches are a repeating pattern inside them.

Prefix length = 32 − ignored bits, and this only means anything for a contiguous wildcard. A wildcard of 0.0.0.254 ignores seven bits but leaves bit 0 significant, so no prefix length and no subnet mask describes it. The calculator reports that rather than inventing a mask.

One detail that trips people up on the command line: the router ignores the address bits that the wildcard marks as don't-care, so 10.1.2.3 0.0.0.255 and 10.1.2.0 0.0.0.255 behave identically. Writing the ignored bits as zeros is a convention for readability, not a requirement, and this calculator normalises to it.

How to check the result before you paste it

Read the address range first, not the mask. The mask is the thing you are likely to have got wrong; the range is the consequence you can verify against intent. If you meant to permit one building's /24 and the range covers four of them, the mask is one bit off.

Then check the address count against the prefix you expected. Every step down in prefix length doubles it: a /24 matches 256, a /23 matches 512, a /22 matches 1,024. A count that is not the power of two you expected is a discontiguous mask, which is almost always a typo — 0.0.0.254 instead of 0.0.0.255 is a single character and a completely different pattern.

Be careful with what the statement does not say. An access list ends with an implicit deny any, so a list containing only permits blocks everything else; if you are filtering rather than selecting, that is the intended behaviour, and if you are matching traffic for QoS or NAT it usually is not. A standard ACL matches on source address only, which is why an extended ACL takes two address-and-wildcard pairs.

For OSPF, remember what the network statement actually does: it selects interfaces whose primary address falls inside the range and enables OSPF on them, placing them in the stated area. It does not advertise a prefix. A statement wider than you intended will enable the protocol on interfaces you did not mean to include — including, on some platforms, ones facing customers. Many operators avoid the ambiguity entirely by configuring ip ospf 1 area 0 on each interface instead, which needs no wildcard at all.

Prefix, subnet mask and wildcard mask reference

Mask and wildcard sum to 255 in every octet, so you can read the table in either direction.

Mistakes that produce a wrong access list

• Typing the subnet mask where the wildcard belongs. access-list 10 permit 10.0.0.0 255.255.252.0 ignores the first 22 bits and matches on the last 10 — a pattern that still matches 4,194,304 addresses, so it looks like it works until traffic you did not intend is permitted.
• Forgetting the implicit deny. Every access list ends with an invisible deny any. A list with one permit entry blocks everything else, which is right for filtering and wrong for classification.
• Assuming a standard ACL can match a destination. Standard lists carry one address and one wildcard, and they match the source only. Use an extended list when the destination matters.
• Using a discontiguous wildcard by accident. A single mistyped digit turns 0.0.0.255 into 0.0.0.254 or 0.0.0.253, which matches a repeating pattern instead of a block. The address count in the results is the fastest way to spot it.
• Writing an OSPF network statement wider than intended. The statement enables OSPF on every interface whose address falls in the range, so a /8-wide wildcard can bring up adjacencies on links that should never run the protocol.
• Reordering entries without re-reading them. Access lists are evaluated top to bottom and stop at the first match, so a broad permit above a narrow deny makes the deny unreachable.

Where wildcards are used, and where they are not

Wildcard masks are Cisco IOS syntax, and they appear in numbered and named access lists, OSPF and EIGRP network statements, and match ip address clauses in route maps. Cisco ASA firewalls take an ordinary subnet mask instead, which is a classic source of confusion when an engineer moves between the two platforms on the same day. Juniper, Arista and Linux iptables all use prefix notation directly.

Prefix lists are the other place this arithmetic surfaces. A prefix list matches route prefixes rather than host addresses, and it uses ge and le qualifiers instead of a wildcard, so it can express “any prefix inside 10.0.0.0/8 that is a /24 or longer” — something no wildcard can say, because a wildcard sees only addresses and not mask lengths. If you find yourself trying to build that with an ACL, the answer is a prefix list.

To design the address plan the ACL is going to protect, use the VLSM subnet design calculator, and to check how many hosts a given prefix carries use the IPv4 host count calculator. On IPv6 there is no wildcard at all: IPv6 access lists take a prefix directly, which the IPv6 subnet calculator works out for you.

A closing habit worth keeping: after generating an entry, verify it on the device rather than trusting the paste. show access-lists displays hit counts per line, and a line with zero hits on a rule you expect to be busy is the same signal as a wrong address count here — the pattern does not match what you think it matches.