A subnet mask is the host's local-versus-remote decision boundary
An IPv4 subnet mask is a 32-bit value paired with an IPv4 address. In normal CIDR subnetting, the mask begins with contiguous 1 bits and ends with 0 bits. The 1s identify the network prefix; the 0s identify host space. That boundary determines whether the host tries to deliver directly on the local link or sends the traffic to its default gateway.
The familiar decimal values come directly from leading binary 1s
A partial mask octet can contain only leading 1s followed by 0s in standard CIDR. That produces 128, 192, 224, 240, 248, 252, and 254.
| Binary | Decimal | Prefix bits in octet |
|---|---|---|
| 10000000 | 128 | 1 |
| 11000000 | 192 | 2 |
| 11100000 | 224 | 3 |
| 11110000 | 240 | 4 |
| 11111000 | 248 | 5 |
| 11111100 | 252 | 6 |
| 11111110 | 254 | 7 |
| 11111111 | 255 | 8 |
Swipe horizontally to see the mask table.
Count the 1 bits to convert dotted decimal to prefix length
255.255.255.0 is /24 because the mask contains 24 leading 1s. 255.255.255.192 is /26. 255.255.248.0 is /21.
/24
255.255.255.0
8 host bits
/26
255.255.255.192
6 host bits
/21
255.255.248.0
11 host bits
A host derives the network by ANDing the address with the mask
Bitwise AND preserves a bit only when both input bits are 1. Because host positions in the mask are 0, those positions become 0 in the network result.
This is the mathematical reason the host can identify its own subnet.
The mask decides whether the destination is delivered directly or sent to the gateway
The host applies the prefix to its own address and to the destination. Matching prefixes mean local delivery. Different prefixes mean the host normally uses its default gateway.
The mask and gateway solve different parts of the forwarding decision
Mask
Is the destination local or remote?
Gateway
Where should remote traffic go next?
ARP
Which local MAC should receive the frame?
A correct gateway cannot compensate for a wrong mask if the host never decides to use the gateway.
A too-broad mask can make a remote destination look local
Suppose 10.10.10.50 should use /24 but is configured /16. The host now thinks 10.10.20.8 is local and tries to ARP for it directly.
If there is no local Layer 2 path to that address, communication fails even though the gateway itself may be healthy.
A too-narrow mask can make a local destination look remote
The opposite error sends traffic toward the gateway even when the destination really belongs on the local link. Depending on the router and network design, that traffic may be rejected or handled inefficiently.
The same host address can belong to very different local ranges
Take 192.168.50.130. Under /24, it is in 192.168.50.0/24. Under /26, it is in 192.168.50.128/26. Under /27, it is in 192.168.50.128/27.
| Address/prefix | Network | Traditional broadcast |
|---|---|---|
| 192.168.50.130/24 | 192.168.50.0 | 192.168.50.255 |
| 192.168.50.130/26 | 192.168.50.128 | 192.168.50.191 |
| 192.168.50.130/27 | 192.168.50.128 | 192.168.50.159 |
Swipe horizontally to compare prefixes.
256 minus the interesting mask octet gives the subnet block size
For /26, the mask octet is 192, so the block size is 64. For /27, 256 − 224 = 32. These boundaries let you find the network without writing every bit.
Prefix length also controls the number of addresses in the subnet
Host bits equal 32 minus the prefix length. A /26 leaves 6 host bits and therefore contains 64 total addresses. A /29 leaves 3 host bits and contains 8 total addresses.
| Prefix | Mask | Host bits | Total addresses |
|---|---|---|---|
| /24 | 255.255.255.0 | 8 | 256 |
| /25 | 255.255.255.128 | 7 | 128 |
| /26 | 255.255.255.192 | 6 | 64 |
| /27 | 255.255.255.224 | 5 | 32 |
| /28 | 255.255.255.240 | 4 | 16 |
| /29 | 255.255.255.248 | 3 | 8 |
| /30 | 255.255.255.252 | 2 | 4 |
Swipe horizontally to see address counts.
The interesting octet can be the third octet or earlier
A /20 is 255.255.240.0, so the third-octet block size is 16. A /22 is 255.255.252.0, so the block size is 4.
The gateway normally has to be reachable as a local next hop
If the client is 192.168.40.130/26, then 192.168.40.129 is local while 192.168.40.1 is not. The host must be able to resolve the gateway locally before it can use that router as its first hop.
The mask determines whether ARP targets the destination or the gateway
If the destination is local, the host ARPs for the destination itself. If the destination is remote, the host ARPs for the gateway. A wrong mask can therefore make the host ARP for the wrong target.
A client can receive an IP address and still be on the wrong subnet
DHCP often supplies the address, mask, gateway, and DNS information. If a client is placed in the wrong VLAN or reaches the wrong DHCP scope, it can receive a complete-looking configuration that is wrong for the intended network.
The mask creates the connected route that shapes every later forwarding decision
Configuring an address and mask normally creates an on-link route for the local subnet. A wrong mask changes that connected route and therefore changes which destinations bypass the default route.
Remote address is incorrectly treated as local
Observed: 10.10.10.50/16 ARPs directly for 10.10.20.8.
Interpretation: under /16, the host believes 10.10.20.8 is local. If the intended design is /24, the mask is too broad.
The gateway sits outside the client's actual subnet
Observed: 192.168.40.130/26 uses gateway 192.168.40.1.
Interpretation: the client belongs to 192.168.40.128/26, so .1 is outside the normal local range. Fix the addressing plan before blaming upstream routing.
The client receives the wrong DHCP scope
Observed: neighboring clients use 10.20.30.0/24, but one client receives 10.20.40.0/24 with gateway 10.20.40.1.
Interpretation: the client may be in the wrong VLAN or DHCP scope even though its own mask and gateway are internally consistent.
Only some destinations fail after a mask change
Observed: nearby hosts work, but destinations across the intended subnet boundary fail.
Interpretation: compare the configured prefix to the design. A wrong mask creates selective local-vs-remote misclassification rather than necessarily breaking every destination.
Use subnet-mask evidence to select the next artifact
| Evidence | Interpretation | Next artifact |
|---|---|---|
| APIPA | Expected DHCP configuration missing | DHCP/VLAN path |
| Gateway outside subnet | Addressing plan invalid | IP/prefix/gateway config |
| ARP for remote host | Host thinks destination is local | Mask and route table |
| Correct subnet, gateway ARP fails | Layer 2/gateway issue | ARP/MAC/VLAN/SVI |
| Gateway works, remote IP fails | Move upstream | Route/NAT/WAN/firewall |
Swipe horizontally to see the troubleshooting matrix.
Use the same sequence on every subnet-mask scenario
This order prevents visual guesswork from decimal addresses.
Seven subnet-mask mistakes to avoid
- Assuming addresses that look similar must be in the same subnet.
- Confusing the subnet mask with the default gateway.
- Counting decimal octets instead of prefix bits.
- Forgetting the interesting octet may be the third octet or earlier.
- Assuming any DHCP lease must be the correct lease.
- Assuming a route entry proves the mask is correct.
- Jumping to DNS before confirming the local-vs-remote decision.
The subnet mask is easiest to trust when you can see the network bits stay fixed
Take 192.168.12.77/26. A /26 means the first 26 bits belong to the network and the final 6 bits belong to the host. In the fourth octet, the mask is 11000000. That means only the first two bits of the fourth octet are part of the network. Every address whose fourth octet begins with those same two network bits belongs to the same /26 block.
This is why /26 boundaries fall at 0, 64, 128, and 192. The decimal block pattern is just a compact way of representing the binary boundary.
Two addresses can look close in decimal and still require the gateway
Visual similarity is not enough. A client at 192.168.12.77/26 and a server at 192.168.12.140/26 share the first three octets, but they are in different /26 networks. The client is in 192.168.12.64/26; the server is in 192.168.12.128/26.
This is one of the most useful exam distinctions because it prevents the common mistake of treating “same first three octets” as proof of local delivery.
Compare a failing client with a working client before changing the network
When a subnet-mask problem is suspected, compare the failing endpoint with a known-good device that should be in the same VLAN. Check the IP range, prefix length, gateway, DNS values, and route table. If the working device has /24 and the failing device has /16, that difference is high-information evidence.
The gateway value is identical, yet behavior differs because the mask controls whether the gateway is used at all.
A capture can prove the host's local-versus-remote decision
If a client is trying to reach a destination that should be remote, capture the first packets. Repeated ARP requests for the destination itself indicate that the host believes the destination is local. ARP requests for the gateway indicate that the host believes the destination is remote.
This turns subnetting from abstract arithmetic into visible packet behavior. It also gives you a way to distinguish a wrong-mask decision from a later routing or firewall failure.
Use mask, gateway, ARP, and route evidence together
A workstation is configured as 172.20.18.70/20 with gateway 172.20.16.1. It can reach devices in the 172.20.16.0–31.255 range but fails to reach 172.20.40.10. That behavior is expected: /20 creates 16-value blocks in the third octet. The local network for 18 is 172.20.16.0/20; 40 belongs to a different block.
If the capture instead shows ARP requests for 172.20.40.10, the configured mask is not actually /20 or another local route is influencing the decision. That is the level of reasoning a strong subnet-mask answer should reach: calculate the boundary, predict the forwarding behavior, then verify it with evidence.
24 Subnet Mask digital flashcards
Practice CIDR conversion, binary mask values, bitwise AND, local-vs-remote behavior, wrong-mask symptoms, common masks, gateway validity, ARP decisions, and troubleshooting.