Subnet/CIDR

When a network is small, putting a handful of devices into one address range does not seem to cause much trouble. But once user PCs, servers, management devices, printers, and external links are all mixed into the same address space, it becomes hard to explain which systems should talk directly and which traffic should be forced through a router or firewall. A mistake or attack in one area can spread straight into another, and even simple isolation requests become awkward when everything already sits in one flat network. The bigger problem appears during growth and interconnection. If the whole environment was planned as one large block, the moment you try to split departments, separate server zones, connect a branch office, add VPN access, or link to cloud networks, address overlap and vague boundaries start to hurt. Redesigning at that point means touching running devices' IPs, routes, and firewall rules at the same time. Subnets and CIDR exist to divide the network before that chaos arrives, based on role and future growth.

Early internet addressing divided networks into fixed-size Class A, B, and C blocks. That looked simple, but it fit real organizations badly. Some networks received far more addresses than they needed, while others had to request more blocks as soon as they grew. As those smaller networks accumulated, routing tables also grew, increasing the burden on routers across the internet. CIDR was introduced to solve that problem. It treats address space as something to size according to need and something that can be aggregated to keep routing scalable. That same logic still applies in enterprise networks, data centers, ISP networks, and cloud environments today. Designing /24 or /20 subnets is not mainly about using a cloud feature; it is about modern network design that reduces waste, controls routing scale, and leaves room for future interconnection.

The core of subnetting is where you place the boundary between the network portion and the host portion of an IP address. In CIDR notation, /24 means the first 24 bits are the network address and the remaining 8 bits are host addresses, giving a single subnet up to 256 addresses. With /20, 12 bits are available for hosts, allowing up to 4,096. Within the same subnet, devices communicate at Layer 2 (Data Link, Ethernet frames) directly. To reach a device in another subnet, traffic must pass through the default gateway, where the routing table determines the path. Subnetting is therefore not just splitting IP numbers; it is deciding which devices talk directly and which have a router as a gateway between them. That gateway is what makes it possible to apply different security rules and routing policies to each subnet.

Subnets and VLANs both logically divide a single physical network for isolation. The difference is which layer they operate at. Subnets separate at Layer 3 (Network, IP) based on address ranges, while VLANs separate at Layer 2 (Data Link, Ethernet switch) based on ports or tags. Subnets are a tool for routing and address design; VLANs are a tool for splitting broadcast domains on physical switches. In practice, the two are used together rather than separately. Mapping one VLAN to one subnet provides both Layer 2 isolation and Layer 3 address separation at the same time. In cloud environments, you rarely deal with VLANs directly, and subnets serve as the basic unit for both security and routing boundaries. In on-premises environments, however, subnets alone may not provide sufficient isolation without VLANs.

Subnet design is the skeleton you should set before the rest of the network grows around it. In office networks, it separates user segments, server segments, and management networks. In data centers, it creates routing and firewall boundaries between zones such as web servers and databases. In cloud environments, the same idea appears again when you divide externally reachable segments from internal-only ones. The key decision is where direct communication ends and where traffic must cross a router. A common operational mistake is sizing subnets only for today's device count, or doing the opposite and dumping everything into one oversized range. The first choice causes address exhaustion during expansion or redundancy work; the second enlarges both the security blast radius and the failure domain. Address overlap with branches, VPN links, other data centers, or cloud VPCs also makes routing messy or impossible. Good subnet design is not a server placement chart. It is an address structure that can survive future separation, routing, and growth.