CCNA online course

Wildcard Masks Explained for Cisco ACLs and OSPF

Learn how Cisco wildcard masks work, calculate inverse masks from subnet masks, and use them in standard ACLs, extended ACLs, and OSPF.

A wildcard mask is a 32-bit IPv4 matching value used by Cisco IOS features such as access control lists (ACLs) and OSPF. It tells IOS which address bits are required to match and which bits may vary.

Wildcard masks are related to subnet masks, but they serve different purposes. A subnet mask separates the network portion of an address from the host portion. A wildcard mask compares address bits.

Wildcard Bit Meaning Compared with Subnet-Mask Bit Meaning

Bit value | Subnet mask | Wildcard mask | Matching effect

0 | Network bit or fixed portion | Must match | The corresponding address bit is compared

1 | Host portion or variable portion | Ignored | The corresponding address bit may be either 0 or 1

How wildcard-mask matching works

Compare the configured address and the candidate address one bit at a time. Wherever the wildcard contains a binary 0, the candidate bit must equal the configured address bit. Wherever the wildcard contains a binary 1, IOS ignores the candidate bit.

For example, consider an address of 192.168.10.25 with a wildcard mask of 0.0.0.0:

Configured address: 192.168.10.25   11000000.10101000.00001010.00011001
Wildcard mask:     0.0.0.0          00000000.00000000.00000000.00000000
Candidate address:  192.168.10.25   11000000.10101000.00001010.00011001

Every wildcard bit is zero, so every address bit must match. This selects exactly one host.

At the other extreme, a wildcard mask of 255.255.255.255 is all ones in binary:

Wildcard mask: 255.255.255.255   11111111.11111111.11111111.11111111

Every bit is ignored, so the address pair matches every IPv4 address. Cisco IOS commonly represents these two cases with the host and any keywords.

Common Cisco IOS Wildcard Shorthand

Intent | Full address and wildcard form | Keyword form when supported

Single host | 192.168.10.25 0.0.0.0 | host 192.168.10.25

Any IPv4 address | 0.0.0.0 255.255.255.255 | any

Calculating a wildcard mask from a subnet mask

For a conventional, contiguous network prefix, calculate the inverse wildcard mask by subtracting each subnet-mask octet from 255:

wildcard octet = 255 - subnet-mask octet

For 255.255.255.0, the calculation is:

255 - 255 = 0
255 - 255 = 0
255 - 255 = 0
255 - 0   = 255

Subnet mask:     255.255.255.0
Wildcard mask:   0.0.0.255

The same operation can be performed in binary by inverting every bit. A subnet-mask zero becomes a wildcard one, and a subnet-mask one becomes a wildcard zero.

Subnet mask:   11111111.11111111.11111111.00000000
Wildcard mask: 00000000.00000000.00000000.11111111

This inverse operation is convenient for normal prefix-based matching. It does not mean that wildcard masks must be contiguous. Cisco IOS can also use patterns in which zero and one bits are interspersed.

Subnet-mask to wildcard-mask reference

Subnet Mask to Wildcard Mask Reference

CIDR prefix | Subnet mask | Wildcard mask | Number of variable address bits

/8 | 255.0.0.0 | 0.255.255.255 | 24

/16 | 255.255.0.0 | 0.0.255.255 | 16

/24 | 255.255.255.0 | 0.0.0.255 | 8

/25 | 255.255.255.128 | 0.0.0.127 | 7

/26 | 255.255.255.192 | 0.0.0.63 | 6

/27 | 255.255.255.224 | 0.0.0.31 | 5

/28 | 255.255.255.240 | 0.0.0.15 | 4

/29 | 255.255.255.248 | 0.0.0.7 | 3

/30 | 255.255.255.252 | 0.0.0.3 | 2

/31 | 255.255.255.254 | 0.0.0.1 | 1

/32 | 255.255.255.255 | 0.0.0.0 | 0

Example: converting a /26

A /26 has subnet mask 255.255.255.192. Inverting the mask gives:

Subnet mask:     11111111.11111111.11111111.11000000
Wildcard mask:   00000000.00000000.00000000.00111111

Subnet mask:     255.255.255.192
Wildcard mask:   0.0.0.63

The final six wildcard bits are one, so those six host bits may vary. For network 192.168.10.64/26, use 192.168.10.64 0.0.0.63. The first 26 bits are fixed, and the final six bits can represent addresses in that /26 range.

To validate a conversion, check both methods: subtract each subnet-mask octet from 255, then confirm that the binary mask has zeroes in fixed positions and ones in variable positions.

Host, subnet, network, and any-address matches

These patterns cover most beginner and operational use cases:

  • One host: use the host address with 0.0.0.0, such as 192.168.10.25 0.0.0.0.
  • One conventional subnet: use the subnet's network address and the inverse of its subnet mask, such as 192.168.10.64 0.0.0.63 for 192.168.10.64/26.
  • Every IPv4 address: use 0.0.0.0 255.255.255.255, or any where supported.

When building a conventional subnet rule, use the correct network address rather than an arbitrary host address. For example, a /24 rule should normally begin with 192.168.10.0, not 192.168.10.25.

Noncontiguous wildcard masks

A wildcard mask does not have to look like the inverse of a normal subnet mask. A noncontiguous wildcard mask contains matched and ignored bits in an interspersed pattern.

Consider a final-octet wildcard of 5:

Wildcard decimal: 5
Wildcard binary:  00000101

The zero positions are fixed and the one positions are ignored. Therefore, for a configured final octet of x, bits 7 through 3 and bit 1 must match the configured value, while bits 2 and 0 may vary. The matching values are determined by changing only the ignored positions. Because those positions are not grouped at the end, the result is not a conventional subnet range.

To analyze any noncontiguous rule:

  1. Convert the configured address octet and wildcard octet to binary.
  2. Mark every wildcard zero as required and every wildcard one as flexible.
  3. Keep the required bits fixed.
  4. Generate every combination of the flexible bits to predict the matching pattern.

Noncontiguous matching is specialized. It can be useful for a carefully designed bit pattern, but it reduces readability and increases the risk of accidental matches. Prefer conventional subnet-based rules or several clearly documented entries when those alternatives express the policy.

Wildcard masks in standard IPv4 ACLs

A standard IPv4 ACL primarily matches the source address. Its address is followed by a wildcard mask, or by the host or any shorthand.

Example cases:

access-list 10 permit host 192.168.10.25
access-list 11 permit 192.168.10.0 0.0.0.255
access-list 12 deny any

A named standard ACL is usually easier to read and maintain:

ip access-list standard ALLOW-LAN
 permit 192.168.10.0 0.0.0.255
interface gigabitEthernet0/1
 ip access-group ALLOW-LAN in

ACL entries are processed from top to bottom. The first matching entry determines the result. At the end is an implicit deny, meaning traffic not matched by an earlier permit is denied. Standard ACLs are commonly placed near the destination because they cannot distinguish among destination networks or services; exact placement still depends on the intended policy and topology.

Wildcard masks in extended IPv4 ACLs

An extended ACL can match protocol, source address, destination address, and service criteria such as TCP or UDP ports. Source and destination addresses have independent wildcard masks.

ip access-list extended WEB-ACCESS
 permit tcp 10.10.0.0 0.0.255.255 host 172.16.1.10 eq 443
interface gigabitEthernet0/1
 ip access-group WEB-ACCESS in

This entry permits TCP traffic from the 10.10.0.0/16 source range to exactly 172.16.1.10 on HTTPS port 443. The source wildcard is 0.0.255.255; the destination uses the host shorthand, equivalent to 172.16.1.10 0.0.0.0.

Extended ACLs are commonly placed close to the source so unwanted traffic can be stopped early. Always account for direction, interface, and the order of entries. A broad deny before a specific permit prevents that permit from ever being reached.

ACL and OSPF Wildcard-Mask Usage

Feature | What the address and wildcard match | Configuration consequence | Key caution

Standard ACL | Source IPv4 address | Permit or deny based mainly on source | Cannot distinguish destination or port

Extended ACL | Protocol, source address, destination address, and ports | Filter specific traffic flows | Entry order, direction, and implicit deny matter

OSPF network statement | Local interface IPv4 addresses | Activates OSPF on matching interfaces and assigns an area | It selects local interfaces; it does not simply advertise a remote network

Wildcard masks in OSPF network statements

In classic Cisco IOS OSPF configuration, a network statement contains an address, wildcard mask, and area. IOS compares the statement with local interface addresses. Every matching interface is enabled for OSPF and placed in the specified area.

router ospf 1
 network 10.1.1.0 0.0.0.255 area 0

The statement matches local interfaces whose addresses fall within the 10.1.1.0/24 range. It does not mean that the router automatically advertises every remote address in that range.

For one precise interface, use an exact host match:

router ospf 1
 network 10.1.1.1 0.0.0.0 area 0

For a subnet-style interface range, use the inverse mask:

router ospf 1
 network 10.1.1.0 0.0.0.255 area 0

Modern IOS variants may support interface-based OSPF configuration, which activates OSPF directly under an interface. That approach can be clearer, but wildcard-mask knowledge remains important for CCNA exams and existing configurations. See Configure OSPF for related OSPF configuration concepts.

A repeatable address-matching procedure

Use this method whenever a wildcard rule is unclear:

  1. Write the configured address in binary.
  2. Write the wildcard mask in binary beneath it.
  3. Write the candidate address in binary.
  4. Compare the candidate and configured bits only where the wildcard bit is zero.
  5. Ignore every position where the wildcard bit is one.

For a conventional rule, the flexible bits usually form a trailing block and the result looks like a subnet. For a noncontiguous rule, matching addresses may appear to lie outside a conventional subnet because only selected bit positions are fixed.

To predict the complete pattern, count the wildcard's one bits. If there are n ignored bits, up to 2^n bit combinations can match, subject to the address space being evaluated. For example, a /26 inverse wildcard has six one bits, so 64 address values share the fixed first 26 bits.

Common mistakes and best practices

  • Do not enter a subnet mask where IOS expects a wildcard mask. A /24 subnet mask is 255.255.255.0; its usual wildcard mask is 0.0.0.255.
  • Use the network address for conventional subnet rules. The /26 network beginning at 192.168.10.64 is written as 192.168.10.64 0.0.0.63.
  • Do not confuse the two extremes. 0.0.0.0 means every bit must match; 255.255.255.255 means every bit is ignored.
  • Prefer named ACLs, comments, and clear formatting where the IOS version supports them.
  • Keep entries specific before entries broad. Review first-match processing and the implicit deny.
  • Verify before deployment. Use show commands and controlled test traffic rather than relying only on visual inspection.

Verification and troubleshooting

ACL verification

show access-lists
show ip access-lists
show running-config | section ip access-list

Check the configured address and wildcard pair, sequence order, hit counters, interface attachment, and traffic direction. If a rule matches too many addresses, it may contain a subnet mask instead of its inverse, or an unintended wildcard one. If traffic reaches the implicit deny, add or correct a policy entry only after confirming the intended behavior.

OSPF verification

show ip ospf interface brief
show ip ospf interface
show ip ospf neighbor
show ip protocols

If OSPF does not activate on an expected interface, verify its IPv4 address, operational state, and the bit-by-bit match against the network statement. If too many interfaces activate, the wildcard range is too broad. Narrow the statement, use an exact host match, or configure OSPF directly under the intended interface where appropriate.

Testing noncontiguous rules

Convert the relevant octet to binary, mark fixed and ignored positions, and enumerate representative matching and nonmatching values. Document the intended bit pattern. If operators cannot predict the result quickly, replace the rule with conventional subnet rules or explicit entries when feasible.

Related learning

Review OSI Reference Model for broader networking terminology and OSPF Route Summarization for related OSPF address planning. For traffic-filtering design, continue with standard versus extended ACL concepts and interface placement.