Ruteo de subredes IPv4 — Cuando las operaciones binarias te hacen cuestionar tus decisiones profesionales

At some point in your career, someone will ask you to “just set up the networking” for a VPC, a Kubernetes cluster, or a Docker network. You’ll open the AWS console, see a field that says CIDR block, and type 10.0.0.0/24 with the confidence of someone who absolutely knows what they’re doing.

Then you’ll spend the next 45 minutes on a subnet calculator wondering why you can’t add more than 254 hosts.

You are not alone. IPv4 subnetting is one of those topics where the actual math is simple, but the way it’s taught — using binary notation and terms like “bitwise AND operation” — makes reasonable people consider new careers in ceramics. This guide cuts through the noise. By the end, you’ll understand subnet masks, CIDR notation, why /24 y /16 are very different things, and how to calculate host ranges without converting anything to binary. And when you need to verify your work, the Convertidor IPv4 handles the tedious network address calculation for you.

What an IPv4 Address Actually Is

An IPv4 address is a 32-bit number written in four decimal groups called octets. 192.168.1.100 means 192 in the first octet, 168 in the second, 1 in the third, 100 in the fourth. Each octet can be 0–255, because each is 8 bits wide (2⁸ = 256 possible values).

What you need to understand — without touching binary — is that every IPv4 address has two logical parts: the network portion and the host portion. The subnet mask is what tells you where one ends and the other begins.

Subnet Masks: The Dividing Line

A subnet mask looks exactly like an IP address: 255.255.255.0 is the most common one you’ll see. Under the hood, it’s always a sequence of 1s followed by 0s in binary — those 1s cover the network part of the address, and those 0s cover the host part.

255.255.255.0 in binary is 11111111.11111111.11111111.00000000 — that’s 24 ones. Apply it to 192.168.1.100 and you’re saying: the first 24 bits (192.168.1) are the network. The last 8 bits (.100) identify the specific host within that network. This is exactly what /24 means in CIDR notation. You’re just counting the 1s.

CIDR Notation: Same Thing, Less Writing

CIDR — Classless Inter-Domain Routing, which you’ll immediately forget and never need to say out loud — is shorthand for a network address plus its mask.

192.168.1.0/24 means:

• Network address: 192.168.1.0
• Subnet mask: 255.255.255.0 (24 bits set to 1)
• Usable host range: 192.168.1.1 a 192.168.1.254
• Total usable hosts: 254 (256 minus 2 — network address and broadcast are reserved)

10.0.0.0/16 means:

• Network address: 10.0.0.0
• Subnet mask: 255.255.0.0 (16 bits set to 1)
• Usable host range: 10.0.0.1 a 10.0.255.254
• Total usable hosts: 65,534

El / number tells you how many bits are locked in as “network.” The remaining bits are free for hosts. Fewer locked bits = more hosts = bigger subnet.

Why /24 Isn’t /16: A Practical Example

You’re creating a VPC on AWS. You pick 10.0.0.0/24 because it looks normal. You get 254 usable IPs. You have four teams, each needing a subnet with up to 50 hosts. You try to carve it into /26 subnets and… run out of space faster than expected.

Then your colleague says “why didn’t you use /16?” and disappears.

10.0.0.0/16 gives you 65,534 usable IPs, which you can divide into 256 subnets of 254 hosts each, or 1,024 subnets of 62 hosts each. The /16 is your master network; the /24s are subnets carved inside it.

The mental model: a larger CIDR prefix number (/24, /26, /28) means a smaller network with fewer hosts. A smaller CIDR prefix number (/8, /16) means a larger network with more hosts. It’s counterintuitive until it clicks, and then it’s obvious forever.

Host Count Formula (No Binary Required)

The formula is straightforward:

Usable hosts = 2^(32 − prefix) − 2

El 32 − prefix gives you the number of host bits. Raise 2 to that power for total addresses. Subtract 2 for the network and broadcast addresses.

• /24: 2⁸ − 2 = 254 hosts
• /25: 2⁷ − 2 = 126 hosts
• /26: 2⁶ − 2 = 62 hosts
• /28: 2⁴ − 2 = 14 hosts
• /16: 2¹⁶ − 2 = 65,534 hosts

You can do this in your head for common prefixes, or skip it entirely and use the Convertidor IPv4 to get the full breakdown instantly.

Common Subnet Reference Table

Bookmark this. You’ll come back to it every time you configure a VPC or Docker network.

CIDR	Máscara de subred	Direcciones Totales	Hosts Utilizables	Common Use
/8	255.0.0.0	16,777,216	16,777,214	Large private networks
/16	255.255.0.0	65,536	65,534	VPC master networks
/20	255.255.240.0	4,096	4,094	Large AWS/GCP subnets
/24	255.255.255.0	256	254	Standard LAN, small subnets
/25	255.255.255.128	128	126	Half a /24
/26	255.255.255.192	64	62	Small team subnets
/27	255.255.255.224	32	30	Very small subnets
/28	255.255.255.240	16	14	Firewalls, NAT gateways
/30	255.255.255.252	4	2	Point-to-point links
/32	255.255.255.255	1	1 (itself)	Single host routes

Real-World Patterns: VPCs, Docker, Kubernetes

AWS VPCs

The standard pattern is a /16 master VPC (10.0.0.0/16) carved into /24 subnets per availability zone and purpose (public, private, data). This gives you up to 256 subnets with 254 usable hosts each — more than enough for most applications. If your workloads are large, use /20 subnets instead and get 4,094 hosts per subnet.

One AWS-specific gotcha: AWS reserves 5 IP addresses per subnet, not the standard 2. The first four addresses and the last one are reserved for the network address, VPC router, DNS, future use, and broadcast respectively. So a /24 in AWS gives you 251 usable IPs, not 254.

Docker Networks

Docker’s default bridge network uses 172.17.0.0/16. When you create a custom network, Docker allocates from the 172.16.0.0/12 range by default. Override it explicitly:

docker network create --subnet=10.10.0.0/24 my-network

El /24 is intentional — you don’t want Docker consuming your entire address space with one internal network. If you’re running multiple Docker networks that need to talk to each other or to VPN-connected hosts, make sure their ranges don’t overlap.

Kubernetes

Kubernetes has two separate CIDR ranges: the pod network (typically 10.244.0.0/16 with Flannel, or 192.168.0.0/16 with Calico) and the service network (typically 10.96.0.0/12). These must not overlap with each other or with your node network. If they do, you’ll spend quality time debugging why pods can’t reach services and DNS resolution is inconsistent.

When planning Kubernetes networking, use the Convertidor IPv4 to verify that your pod CIDR, service CIDR, and node subnet don’t overlap before you write that Helm values file. Five minutes of network address calculation upfront beats an hour of kubectl exec debugging later.

IPv4 Subnetting Without the Suffering

The concepts above are enough to configure networking confidently. The implementation detail — “what’s the host range for 172.31.32.0/20?” — is where most people hit a wall and reach for a subnet calculator. That’s the right instinct.

El Convertidor IPv4 gives you network address, broadcast address, host range, subnet mask, and CIDR notation all from a single input. Paste in your IP and prefix, get back everything you need for your VPC configuration, security group rules, or firewall allowlist. No account required, no nonsense.

Keep it in a tab. You’ll use it more than you expect.

También te puede interesar