Subnets /24, /26 and /27: learning CIDR with practical examples
Published on 2026-10-26 by frfrand
Calculate IPv4 ranges and number of usable addresses
A /24 mask seems like a strange number until you need to distribute addresses for VPSs, containers, and private networks. With CIDR you can calculate subnets without memorizing a 256-row table.
Let's turn it into a procedure you can use on a real VPS. The goal is to understand why it works, how to test it, and what problem appears if one part is misconfigured.
What CIDR /24 /26 /27 means and when you need it
In IPv4, a /n prefix indicates how many bits identify the network. /24 leaves 8 bits for hosts (256 addresses); /26 leaves 6 (64 addresses); /27 leaves 5 (32 addresses). In conventional IPv4 networks there are addresses reserved for network and broadcast, so usable ones are usually two less.
Before changing anything in production, note the current status: IP, domain, port, affected service, and time of the last deploy. An isolated modification is easy to verify; five simultaneous changes make it harder to reconstruct what happened.
Configuration or example commands
# Ejemplos de rangos IPv4
192.168.10.0/24 -> 192.168.10.0 ... 192.168.10.255
192.168.10.64/26 -> 192.168.10.64 ... 192.168.10.127
192.168.10.128/27 -> 192.168.10.128 ... 192.168.10.159
# En Linux: dirección y prefijo actuales
ip -4 addr show
ip -4 route showDomains, IPs, routes, and names are illustrative. Do not copy an entire configuration over the current one without comparing first. In examples that include ports or firewall, make sure to keep administrative access.
How I would do it step by step
- Preparation. Identify the network prefix, not just the address of a device.
- Step 2. Calculate the block size as
2^(32-prefix)for IPv4. - Step 3. Find the start of the block according to its boundaries: /26 advances by 64 in the last octet.
- Step 4. Separate network, broadcast, and assignable addresses in conventional subnets.
- Verification. Check routes and firewall rules before connecting two segments.
When finished, verify the actual operation from another connection. For example, for an API it is not enough to open the browser: run a read request, a write to a test database, and check the process logs.
Example of a real project
In a lab infrastructure you have a /24 network and want to separate a group of 50 devices from another of 25. You could plan a /26 and a /27, as long as routes, gateways, and overlaps are correctly defined.
The lesson is simple: an infrastructure configuration does not live isolated from the application. The frontend, the server, the database, and the workers connect, so measuring where the failure starts is more useful than restarting everything.
The mistake I would avoid
Do not assume that CIDR equals security. Two subnets can communicate via a router or firewall. Also, do not copy private address examples into a network that already has them assigned without checking for conflicts.
When working with client servers, keep a backup or rollback procedure before changes that affect data, network, or certificates. And if you don't know what permissions an operation needs, avoid running it as root just to stop errors from showing.
How does it relate to ArduMaker?
When managing multiple VPS and services, understanding CIDR helps plan private access to databases and proxies. ArduMaker can manage the servers, but segmentation must respect routes and permissions.
In a typical case you can create a VPS for the application, deploy from Git, associate an HTTPS domain, and manage the backend and necessary databases. The tools help centralize operations, but you need to understand which port and process fulfills each function.
Questions that arise when you try it
How do I know if the failure is DNS or the service? Check resolution first, then connection to the port, and finally the application response. That order avoids confusing different problems.
Can I expose a database to make it easier to maintain? Better design private access or authenticated tunnels when possible. Exposing a port does not replace engine permissions or the firewall.
What should I document? The expected configuration, how to verify it, and how to return to the previous state. That document helps you more than a list of commands without context.
References
In summary: a good network or server configuration is one that you can explain, verify, and recover when something fails.