skip to content

A router access-list entry meant to match 172.16.32.0/20 was written with 255.255.240.0 where a wildcard mask belongs — what does it match, and what should it be?

level: seniorimportance: should knowfreq 24%

answer

  1. an access-list convention, not CIDR
  2. zero bit means must match
  3. 255 minus each mask octet
  4. a swapped mask inverts the meaning

basics

~20 s

A wildcard mask marks bits to ignore: 0 must match, 1 is don't-care, so 172.16.32.0/20 needs 0.0.15.255. Written as 255.255.240.0, it ignores the network bits instead, matching scattered .0 addresses everywhere and only 172.16.32.0 from the intended block.

solid answer

~40 s

A wildcard (inverse) mask is a router access-list convention, not part of CIDR: each `0` bit says "must equal the base address" and each `1` says "ignore". For a contiguous prefix it is the bitwise complement of the subnet mask — 255 minus each octet — so `/20` becomes `0.0.15.255`. With `255.255.240.0` in that position the meaning inverts: the first two octets and the top four bits of the third are ignored, while the low four bits of the third octet must be `0000` and the last octet must be `0`. That matches every address ending in `.0` whose third octet is a multiple of 16, anywhere in the address space, and from `172.16.32.0/20` only `172.16.32.0` itself. A permit entry silently stops matching the intended traffic; a deny entry fails open.

go deeper

for a junior

Recall that a wildcard mask is the inverse of the subnet mask, 255 minus each octet, and that a 0 bit means must match.

for a middle

Convert any prefix to its wildcard and back, and explain why the two notations have opposite bit polarity.

for a senior

Trace what a swapped mask actually matches, predict whether the rule fails closed or fails open, and catch it in review before it ships.

for a principal

Weigh standardising filters on prefix-length notation wherever implementations allow it, keeping non-contiguous wildcards as reviewed exceptions rather than habits.

## What a wildcard mask is, and what it is not A **wildcard mask**, also called an **inverse mask**, is a convention used by many router and switch implementations in **access lists** (ordered permit/deny rules) to say which address bits a rule cares about. It is **not part of CIDR**: RFC 4632 defines prefixes by length, and no RFC in the IPv4 addressing set defines the wildcard form. The rule is per bit: - a wildcard bit of `0` means the packet's bit **must equal** the base address's bit; - a wildcard bit of `1` means the bit is **ignored** — any value matches. A **subnet mask** has the opposite polarity: `1` marks a network bit that must match, `0` a host bit that is free. For any contiguous prefix, therefore, the wildcard is simply the bitwise complement of the mask. ## Converting a prefix to its wildcard 1. Write the subnet mask for the prefix length. 2. Subtract each octet from 255. 3. Pair the result with the prefix's network address as the base. | Prefix length | Subnet mask | Wildcard mask | |---|---|---| | `/12` | `255.240.0.0` | `0.15.255.255` | | `/20` | `255.255.240.0` | `0.0.15.255` | | `/24` | `255.255.255.0` | `0.0.0.255` | | `/26` | `255.255.255.192` | `0.0.0.63` | | `/30` | `255.255.255.252` | `0.0.0.3` | So the correct entry for `172.16.32.0/20` is base `172.16.32.0`, wildcard `0.0.15.255`. ## Tracing the swapped mask Now evaluate base `172.16.32.0` with `255.255.240.0` in the wildcard position, octet by octet: | Octet | Base | "Wildcard" | Bits that must match | Effect | |---|---|---|---|---| | 1 | 172 | 255 | none | any value | | 2 | 16 | 255 | none | any value | | 3 | 32 = `00100000` | 240 = `11110000` | low four bits | low nibble must be `0000` | | 4 | 0 | 0 | all eight | must be exactly 0 | The entry matches any address `A.B.C.0` where C is a multiple of 16 — `10.9.48.0`, `192.168.16.0`, and so on, across the whole address space. Inside the intended block, third octets 32 through 47, only 32 has a low nibble of `0000`, and only the address ending in `.0` passes, so the intended `/20` contributes exactly **one** match: `172.16.32.0`. The operational effect depends on the action: 1. In a **permit** entry, almost all of the intended traffic no longer matches and falls through to later entries, often an implicit final deny, so the service breaks. 2. In a **deny** entry, the block the rule was written to stop is not stopped — the filter **fails open** — while unrelated `.0` addresses elsewhere are caught. 3. Either way, implementations typically accept the entry without complaint, because any 32-bit value is a well-formed wildcard. ## Non-contiguous wildcards Because the wildcard is evaluated bit by bit, implementations generally accept **non-contiguous** wildcards, which no subnet mask or prefix length can express. Base `10.0.1.0` with wildcard `0.0.254.255` requires only the lowest bit of the third octet to equal 1, so it matches every `10.0.X.Y` with an **odd** X — 128 separate `/24`s in prefix terms. This is an implementation feature, occasionally useful and hard to review. CIDR masks, by contrast, must be contiguous: RFC 4632 calls contiguity the one remaining constraint on a mask, and RFC 1812 explains that discontiguous masks are not permitted because they make routing ambiguous. ## Catching the mistake in review - A wildcard whose first octet is `255` is almost always a pasted subnet mask; the correct wildcard for any prefix of `/8` or longer starts with `0`. - Convert every base-plus-wildcard pair back to a prefix length; if it does not convert cleanly, ask whether non-contiguity was intended. - Check that the base address has a zero in every bit the wildcard ignores — in other words, that it is the prefix's network address. - Where an implementation accepts prefix lengths in filters, prefer them. RFC 4632 §5.3 says implementations that filter route advertisements must allow masks or prefix lengths in filter elements, and a length cannot be inverted by accident. - Note that some implementations use subnet masks in one configuration context and wildcards in another, which is exactly how the two get swapped.

  • Can a wildcard mask express a match that no CIDR prefix can?
    Yes. Because it is evaluated per bit, a wildcard can be non-contiguous. Base `10.0.1.0` with wildcard `0.0.254.255` matches every `10.0.X.Y` whose third octet is odd — 128 separate `/24`s as prefixes. It is an implementation feature with no CIDR equivalent, and such entries are hard to review, since CIDR masks must be contiguous (RFC 4632).
  • Why does RFC 4632 push route filters toward prefix lengths?
    RFC 4632 §5.3 says implementations that filter route advertisements must allow masks or prefix lengths in filter elements, replacing classful lines like `accept 172.16.0.0` with `accept 172.16.0.0/16`, and notes the value of matching a prefix plus its more-specifics. A length uses the same notation as the routing table and cannot be inverted by accident, so filter and route can be reviewed side by side.

saying these in an interview costs you the question

  • Claims wildcard masks are defined by the CIDR specification.
  • Believes wildcard bits set to 1 must match the base address.
  • Says swapping mask and wildcard merely widens the match slightly.
  • Complements only the last octet, writing 0.0.0.15 for a /20.
  • Assumes a wildcard mask must be contiguous, like a subnet mask.