Subnet Mask Bitwise

What Is a Subnet Mask?

A subnet mask is a 32-bit number that tells a router or a host which part of an IP address belongs to the network and which part belongs to the host. Every device on an IP network needs one, and the way it works is pure bitwise logic. When I first started working with networks, I found that the concept clicked only once I stopped thinking of subnet masks as dotted-decimal numbers and started thinking of them as binary bitmasks — because that's exactly what they are.

A subnet mask looks like an IP address — 255.255.255.0, for example — but it is not an address. It is a pattern of bits: every bit that is 1 means "this bit in the IP identifies the network," and every bit that is 0 means "this bit in the IP identifies a specific host on that network." In binary, 255.255.255.0 is 11111111.11111111.11111111.00000000. The first three octets (24 bits) are all ones — they define the network. The last octet is all zeros — it defines the host. I've explained this to dozens of junior engineers over the years, and the single best way to check understanding is to watch them perform one bitwise AND by hand.

I calculate subnet masks in my head often when setting up VPN tunnels and Docker networks. A /24 is 255.255.255.0 (24 leading ones), a /16 is 255.255.0.0 — once you understand that the CIDR notation is simply the count of consecutive 1-bits, the rest is easy.

The Bitwise AND: IP Address & Subnet Mask

The router's forwarding decision boils down to a single bitwise AND. When a packet arrives with a destination IP, the router ANDs that IP with the subnet mask configured on each interface. If the result matches the interface's network address, the packet belongs to that subnet and is forwarded locally. If no match is found, the packet goes to the default gateway.

Let me walk through this with a concrete example. When I configure a device on 192.168.1.0/24, I assign it an IP like 192.168.1.37 with mask 255.255.255.0. To determine the network portion, I align the IP and mask bit by bit and apply AND:

Every bit where the mask has a 1 passes through unchanged. Every bit where the mask has a 0 is forced to 0. The result — 192.168.1.0 — is the network address. The portion that got zeroed out — 00100101 or decimal 37 — is the host identifier. I routinely use this mental model when troubleshooting connectivity: if two devices have the same network address after ANDing with their mask, they are on the same broadcast domain and should be able to talk directly without a router.

CIDR Notation in Binary

CIDR (Classless Inter-Domain Routing) notation — /24, /16, /8 — is simply a shorthand for how many leading 1s are in the subnet mask's 32-bit binary form. I find CIDR far more intuitive than dotted-decimal once you internalize the binary mapping, because the number tells you exactly how many bits belong to the network.

The host count is determined by the remaining bits. If the mask has N zeros, there are 2N - 2 usable host addresses (subtracting the network address where all host bits are 0 and the broadcast address where all host bits are 1). A /24 has 8 host bits, so 28 - 2 = 254 usable addresses. A /30 has only 2 host bits, giving exactly 2 usable addresses — the minimum for a point-to-point link. I memorize these by keeping the binary pattern in mind rather than trying to remember decimal numbers.

Custom Subnets and Subnetting by Hand

When you need to divide a network into smaller subnets — for separate departments, VLANs, or cloud VPCs — you are performing a bitwise operation on the mask itself. You borrow bits from the host portion and move them into the network portion, increasing the prefix length and creating smaller subnets.

Let me walk through a scenario I encounter often. You have 10.0.0.0/16 and need 8 subnets of equal size. To get 8 subnets, you need 3 additional bits (2³ = 8). Borrow 3 bits from the host side, and the new mask becomes /19 — that is 16 + 3 = 19 ones.

The borrowed bits become part of the network address in the third octet. Because the mask's third octet is now 11100000 (224 in decimal), the subnet increments by 32 (which is 2⁵, the value of the lowest borrowed bit). I've watched many engineers struggle with this until they write out the binary — once you see the bits marching in groups of three across the octet boundary, the "magic number" method of subnetting makes perfect sense.

Troubleshooting Subnet Mask Issues with Binary

Over the years, I've debugged countless subnet mask misconfigurations, and the root cause almost always traces back to a binary mismatch. Here are the three most common pitfalls I've seen, and how to spot them using bitwise reasoning.

1. Mask Mismatch Between Peers

Two devices on the same switch might have IPs in the same range but different subnet masks. Device A has 192.168.1.50/24 and device B has 192.168.1.60/28. Device A thinks the network is 192.168.1.0 with 254 hosts. Device B thinks the network is 192.168.1.48 with 14 hosts. Device A will ARP for 192.168.1.60 directly; device B, computing the network as 192.168.1.60 AND 255.255.255.240, gets 192.168.1.48 and may ARP for its gateway instead. The result? Intermittent connectivity that looks like a cable problem. I always reach for the binary representation of the mask first when I see this pattern.

2. Wrong Default Gateway

The default gateway must be on the same network as the host. If the gateway's IP AND the host's mask does not equal the host's network address, traffic cannot leave the subnet. This is a pure bitwise check that takes two seconds with a calculator.

3. Overlapping Subnets

In cloud environments (AWS VPC, Azure vNet), overlapping subnets cause routing nightmares. Two VPCs peered with 10.0.0.0/16 and 10.0.128.0/17 overlap because the /16 encompasses addresses that the /17 claims. The AND operation reveals this: 10.0.0.0 AND 255.255.0.0 = 10.0.0.0 and 10.0.128.0 AND 255.255.128.0 = 10.0.0.0 — they share the same /16 base, so VPN tunnels will have ambiguous routes. I plan VPC CIDRs on a binary spreadsheet these days to avoid this exact problem.