Demystifying VLANs and Subnets: A Practical Guide for Medium-Sized Networks

When a growing office still runs like a small office, the network usually feels fine until the first real problem hits: broadcast noise, shared printers that are hard to isolate, guest Wi-Fi that can see too much, and one misbehaving device that makes troubleshooting miserable. That is where /22 how many ips planning, VLAN design, and subnet sizing start to matter together.

/22 total IPs	1,024 addresses as of August 2026
/22 usable hosts	1,022 hosts as of August 2026
/24 total IPs	256 addresses as of August 2026
/23 total IPs	512 addresses as of August 2026
/27 total IPs	32 addresses as of August 2026
Broadcast addresses reserved	1 per subnet as of August 2026
Common use case	Medium-sized office, clinic, campus, or branch network as of August 2026

Why Segmentation Matters More as Networks Grow

A flat network works when there are only a few systems and everyone shares the same traffic space. Once an office adds phones, printers, guest Wi-Fi, cameras, and building controls, the same flat design becomes noisy, harder to secure, and harder to troubleshoot.

Segmentation is the practice of splitting a network into smaller, controlled pieces so traffic, access, and risk are easier to manage. The business payoff is simple: fewer broadcasts, cleaner fault isolation, and fewer “everything is slow” incidents that are really caused by one segment or device class.

“If everything can talk to everything, troubleshooting becomes guesswork and security becomes hope.”

Medium-sized environments feel this pain first because they accumulate device types faster than they accumulate documentation. A clinic may have workstations, VoIP phones, label printers, imaging systems, guest tablets, and IoT devices for access control. A campus building may have shared labs, dorm Wi-Fi, visitor access, and AV systems all in one address space if the design was never revisited.

According to the CISA Zero Trust Maturity Model, strong segmentation supports better control and containment when a device or user is compromised. That is why segmentation is not extra complexity. It is usually the thing that keeps complexity from spreading everywhere.

VLANs vs. Subnets: What Each One Actually Does

VLAN is short for Virtual Local Area Network, and it is a Layer 2 separation method on switching infrastructure. A VLAN decides which devices share the same broadcast domain, which means it controls who hears the same local broadcasts and who stays isolated at the switch level.

Subnet is an IP addressing boundary at Layer 3. It determines how addresses are grouped, how routing works, and how policies can be applied between networks. In other words, VLANs shape the switching domain, while subnets shape the IP domain.

That difference matters because people often assume a VLAN is a complete security boundary. It is not. A VLAN keeps traffic separated at Layer 2, but if routing and policy are allowed, traffic can still move between segments. The same misunderstanding happens in reverse when people think a subnet automatically gives switch isolation. It does not.

VLAN	Controls which devices share the same Layer 2 segment and broadcast domain.
Subnet	Controls IP addressing, routing, and Layer 3 policy boundaries.

In practice, VLANs and subnets are often paired one-to-one because that keeps the design readable. A user VLAN gets a user subnet, a guest VLAN gets a guest subnet, and a printer VLAN gets a printer subnet. That one-to-one mapping makes DHCP, routing, and firewall rules much easier to maintain.

The Cisco CCNA v1.1 (200-301) course is especially relevant here because subnetting, VLANs, and inter-VLAN routing are core networking skills that every technician needs before they can design or troubleshoot segmented networks effectively. Cisco® documents on VLAN operation and switching behavior also reinforce this model in practical terms through the Cisco website.

How Do VLANs and Subnets Work Together in a Real Network?

They work together by separating traffic at the switch and organizing IP communication at the router or Layer 3 switch. The cleanest design pattern is to assign one VLAN to one subnet, then route between them only where business need and policy allow it.

That pairing makes day-to-day administration much easier. A DHCP scope maps to one subnet, switchports map to one VLAN, and firewall rules can reference a known segment instead of a vague mix of devices. When something breaks, you know where to look.

Here is a simple example from a 250-user office:

• VLAN 10 for staff laptops and desktops in 10.10.10.0/24
• VLAN 20 for voice endpoints in 10.10.20.0/24
• VLAN 30 for guest Wi-Fi in 10.10.30.0/24
• VLAN 40 for printers in 10.10.40.0/27
• VLAN 50 for cameras and IoT devices in 10.10.50.0/24

When a staff laptop needs to reach a printer, the traffic leaves the staff subnet, goes to the Layer 3 gateway, and is permitted only if a route and policy allow it. A guest device on the guest VLAN might be allowed only to reach the internet, not internal servers. That is the point of segmentation: communication happens by design, not by accident.

For planning, the question is not “Can these devices technically reach each other?” The real question is “Should they?” That is why NIST guidance around least privilege and boundary protection remains highly relevant in network design.

How many IP addresses are in a /22?

A /22 subnet contains 1,024 total IP addresses and 1,022 usable host addresses. The reason is simple: IPv4 leaves one address for the network ID and one for the broadcast address in each subnet.

If you are planning a growing site, a /22 is often a useful middle ground. It is larger than a /24, which tops out at 254 usable hosts, and smaller than a /21, which may be more address space than a medium-sized environment needs.

Here is the practical comparison people usually want when they search for /22 how many ips:

• /24 gives 256 total addresses and 254 usable hosts.
• /23 gives 512 total addresses and 510 usable hosts.
• /22 gives 1,024 total addresses and 1,022 usable hosts.
• /27 gives 32 total addresses and 30 usable hosts.

If you are trying to choose between a /24 vs /23 subnet, the right answer depends on whether the segment needs room for future growth. A /27 subnet is better for tightly controlled resources like printers or management devices, while a /22 is often better for a user population that may expand by department or floor.

How do you plan a segmentation strategy for a medium-sized network?

You start with business use cases, not VLAN IDs. The first pass should identify who needs access, what they use, and how much trust the device class deserves. That gives you a design that reflects operations instead of forcing operations to fit the network.

1. Inventory the environment. List users, printers, phones, cameras, access points, guest devices, servers, and management systems. Note which ones are managed, which ones are shared, and which ones should never be exposed broadly.

2. Group by function and trust. Employees, guests, voice endpoints, IoT devices, and printers usually belong in separate segments because they have different risk profiles and traffic needs. A scanner in a clinic does not belong in the same segment as a finance workstation just because both are in the same building.

3. Assign one VLAN and one subnet per segment. This keeps DHCP, routing, and policy rules easy to understand. A consistent one-to-one model is not mandatory, but it is usually the easiest to support.

4. Reserve space for growth. Leave room for additional departments, extra phones, and temporary devices. If a segment is already near capacity, design for the next phase now instead of waiting for an outage.

5. Define traffic rules before deployment. Decide which segments may reach printers, DNS, domain controllers, call servers, or management tools. Policy should be written before the first switchport is changed.

The Microsoft Learn documentation on networking, DHCP, and Windows server services is a useful reference when you are deciding how clients will get addresses and how services should remain reachable after segmentation. That is especially helpful in mixed environments with Active Directory, print servers, and cloud-connected endpoints.

What are the most common VLAN and subnet design patterns?

The most useful design patterns are the ones that separate traffic by purpose and trust level. You do not need a VLAN for every room. You need segments that make policy and troubleshooting easier.

User VLAN

A user VLAN is for employee workstations and laptops that need standard internal access. This segment usually has access to common services like DNS, file shares, authentication, and approved web applications. It should not have broad access to management interfaces or sensitive infrastructure unless the business explicitly requires it.

Voice VLAN

A voice VLAN is for IP phones and related voice endpoints. Voice traffic often benefits from QoS treatment and a predictable path to call control systems. Keeping phones separate also helps prevent random user traffic from competing with time-sensitive voice packets.

Guest VLAN

A guest VLAN should usually be internet-only. Guests do not need access to internal printers, file servers, or management systems, and the policy should make that obvious. If guests can reach internal resources, the guest network is not really segmented.

IoT and building systems VLAN

An IoT VLAN works well for cameras, badge readers, sensors, HVAC controllers, and similar devices. These devices often have weaker security controls, limited update options, and highly specific traffic needs. They should be isolated so a compromise does not become a quick path to the rest of the network.

Printer or shared-services VLAN

A printer VLAN is often overlooked, but it solves a lot of real problems. Printers are shared, hard to secure, and frequently over-permissioned. Keeping them in a separate segment lets staff print while limiting what printers can initiate on the network.

In official CIS Benchmarks guidance, reducing exposed services and narrowing trust boundaries are recurring themes. That lines up well with segmenting devices by purpose instead of mixing everything into one shared space.

How do you size subnets without painting yourself into a corner?

Subnet sizing should reflect realistic device counts plus headroom. If a department currently has 60 endpoints and is likely to reach 90 in the next year or two, a /26 is probably too tight and a /24 may be a better fit. The point is not to maximize address efficiency at all costs. The point is to avoid constant renumbering.

Here is the tradeoff in plain terms. Smaller subnets are easier to understand and can reduce waste, but they become painful when growth arrives. Larger subnets reduce the chance of running out, but they can make broadcasts and operational scope bigger than necessary if they are used too broadly.

A good address plan is readable. Use a consistent range for each site or building, and make the function visible in the third or fourth octet if your scheme allows it. For example, a site might use 10.20.10.0/24 for users, 10.20.20.0/24 for voice, and 10.20.30.0/24 for guests.

Document static reservations for infrastructure early. Gateways, network management hosts, printers, and servers should not be mixed randomly into DHCP pools without a plan. That way, the next administrator can tell at a glance what belongs where.

A clean IP plan is not about saving addresses. It is about making the network understandable six months later when the original designer is not the person fixing the outage.

For standards-based planning, IETF addressing principles and subnetting conventions remain the technical foundation for how IPv4 networks are organized, routed, and documented.

What needs to be allowed for routing between VLANs?

Inter-VLAN routing is the Layer 3 function that lets devices in one VLAN communicate with devices in another VLAN. A Layer 3 switch or router handles that traffic by forwarding packets between subnets based on route and policy rules.

Not every segment should be able to talk to every other segment. That default-deny approach is usually better than opening broad access and trying to close it later. For example, user devices may need access to printers and approved application servers, but guest devices should usually be blocked from internal systems entirely.

Common examples of permitted routing include:

• Staff to printers for print jobs and device status.
• Phones to call services for registration and signaling.
• IT admin workstations to management systems for monitoring and maintenance.
• IoT devices to specific controllers for telemetry and control.

Everything else should be explicitly justified. This is where ACLs, firewall rules, and policy-based controls do their real work. A segment can have a route and still be blocked by policy, which is exactly what you want when the traffic is not necessary.

For technical policy design, the OWASP Top 10 is not a subnetting guide, but it is a useful reminder that exposure control matters. The same security logic applies at the network layer: reduce unnecessary paths, and you reduce the attack surface.

How do you build stronger security boundaries with VLANs and subnets?

Segmentation reduces lateral movement. If one endpoint becomes compromised, the attacker should not automatically gain access to the rest of the environment. That is the real security value of VLANs and subnets when they are designed correctly.

Think about the difference between a trusted internal workstation and an unmanaged IoT device. A workstation may be patched regularly, enrolled in endpoint protection, and controlled by policy. A camera may be hard to patch, difficult to monitor, and connected through a vendor-specific interface. Both should not be treated the same way.

Security boundaries work best when the network design matches the risk model:

• Trusted internal users get access to approved internal resources.
• Guests get internet access only.
• IoT devices get the minimum access needed to function.
• Management systems are isolated and tightly controlled.

That model aligns well with NIST Cybersecurity Framework principles around protecting assets and limiting blast radius. It also makes audit conversations easier because the logic is visible in the network design instead of hidden in a pile of exceptions.

How should DHCP, DNS, and shared services work across segments?

Most VLANs or subnets need their own DHCP scope so devices receive the correct address, gateway, and DNS settings. That keeps address assignment clean and prevents clients from being dropped into the wrong network by mistake.

DHCP is the service that hands out IP addresses automatically, and it becomes especially important once multiple subnets exist. Each scope should match the VLAN it serves, with reserved ranges for infrastructure and static devices where needed.

Services like DNS, domain controllers, print servers, and management tools often need to be reachable across segments. That means the routing rules must allow access to exactly what is needed and nothing more. A user VLAN may need DNS and authentication, but it should not get blanket access to management interfaces.

Also pay attention to service placement. If all critical services are in one subnet and all clients are in another, you will add routing and policy complexity everywhere. If possible, place shared services in a well-protected services segment and publish only the necessary ports and flows to the rest of the network.

Common failure points after segmentation include orphaned DHCP scopes, stale static addresses, and devices that still point to old gateways or DNS servers. Those problems are avoidable if you plan the cutover carefully and verify each segment one at a time.

The Microsoft DHCP documentation is useful for validating scope design, relay behavior, and client assignment details in Windows-heavy environments.

What are the operational best practices for keeping segmentation manageable?

The best segmentation design is the one that survives staff turnover. That means clear naming, consistent numbering, and documentation that explains why each segment exists. If the next engineer cannot tell the difference between VLAN 20 and VLAN 200, the design is too opaque.

Use names that encode purpose. Examples like USERS, VOICE, GUEST, IOT, and PRINTERS are easier to maintain than obscure labels that only make sense to the original installer. The same rule applies to subnets and DHCP scopes.

• Keep diagrams current. Show VLANs, subnets, gateways, and key service locations.
• Standardize templates. Reuse switchport, trunk, DHCP, and ACL patterns.
• Pilot changes first. Validate one site, floor, or department before broad rollout.
• Plan rollback steps. Know how to restore prior gateway and access settings quickly.
• Review quarterly. Adjust the design as devices and services change.

Change control matters because segmentation usually touches core dependencies. If you alter gateways, DHCP, and access policies at the same time without a rollback path, troubleshooting becomes harder than the original problem. That is why change windows and test plans are worth the effort.

ISC2® research and workforce guidance consistently point to the need for operational discipline in security work. Networking teams benefit from the same mindset: standardize what you can, document what you change, and verify what you expect.

What mistakes should you avoid when designing VLANs and subnets?

The biggest mistake is over-segmenting without a reason. If every device class gets its own tiny subnet and every exception requires custom rules, the network becomes hard to support. Good segmentation should reduce confusion, not create it.

The second major mistake is going the other direction and building one oversized subnet that recreates a flat network. That usually brings broadcast growth, troubleshooting headaches, and weak security boundaries back into the environment. If a segment contains too many unrelated device types, it is probably too broad.

Other common errors include:

• Mixing trust levels in the same VLAN because it was faster.
• Using physical location as the only rule instead of business function.
• Ignoring DHCP, DNS, and routing dependencies until after rollout.
• Forgetting management access for switches, controllers, or service consoles.
• Not documenting allowed flows between segments.

A segmentation project should begin with a map of who needs to reach what. If you do not know the dependencies, you will discover them during outages. That is the most expensive time to learn them.

The Verizon Data Breach Investigations Report consistently shows that weak boundaries and credential misuse remain major security themes. That is one more reason to separate sensitive resources from general user traffic instead of assuming the internal network is inherently safe.

What is a practical step-by-step design approach?

A practical segmentation design starts with what you already have and then moves toward the structure you want. The goal is not elegance on paper. The goal is a network that is easier to operate on a Monday morning when something stops working.

1. Inventory devices, users, services, and traffic patterns. Build a simple list of endpoints, note whether they are managed or unmanaged, and identify which services they depend on. This is where hidden dependencies show up, such as printers that still rely on old DNS entries or phones that need call server access.

2. Group endpoints by function and trust level. Separate staff, guests, voice, printers, IoT, and administrative systems into logical categories. That grouping gives you a design pattern to follow instead of trying to solve every device as a special case.

3. Assign VLAN IDs and subnets using a consistent scheme. Keep the numbering predictable so the design is easy to support. For example, you might use 10s for users, 20s for voice, 30s for guests, and 40s for printers across all sites.

4. Define routing and access rules for each segment. Decide what each segment can reach, then enforce it with ACLs or firewall policy. Default-deny between sensitive segments is usually safer than opening traffic broadly and relying on memory later.

5. Test DHCP, connectivity, and service access. Verify that clients get the right gateway, DNS server, and address range. Then test real workflows such as printing, calling, browsing, and authentication from each segment.

6. Review and refine the design. As the organization adds departments, new devices, or another site, revisit the plan and adjust the address space before it becomes cramped. Segmentation should grow with the business instead of fighting it.

Hands-on network skills taught in Cisco CCNA v1.1 (200-301) map well to this process, especially the practical parts of configuring, verifying, and troubleshooting network behavior. That makes it easier to move from theory to an actual deployable design.

What does a real-world segmentation plan look like for a 250-user office?

A 250-user office is large enough to benefit from segmentation but still small enough that design mistakes are visible quickly. A sensible layout might split traffic into staff, voice, guest, printers, and IoT segments, with each group assigned its own VLAN and subnet.

Example design:

• Staff in 10.50.10.0/24 for desktops and laptops.
• Voice in 10.50.20.0/24 for IP phones.
• Guest in 10.50.30.0/24 for visitor Wi-Fi with internet-only access.
• Printers in 10.50.40.0/27 for shared printers and scanners.
• IoT in 10.50.50.0/24 for cameras, badge readers, and conference room systems.

Why separate conference rooms? Because they often host unmanaged laptops, wireless presentation gear, and devices that move around between rooms. Why separate printers? Because printers are shared endpoints with limited security controls and very specific access needs. Why isolate guest Wi-Fi? Because guest traffic should never be allowed to wander into internal resources by default.

That design makes troubleshooting easier immediately. If printing fails, the problem is likely in one segment, one gateway rule, or one service path. If guest Wi-Fi is slow, it will not affect staff addressing or voice registration.

This is also where address planning helps long term. If the staff segment grows from 150 devices to 220, a /24 may still be fine. If the office adds another floor or merges with another department, a /23 or /22 can prevent a painful renumbering project later.

Conclusion

VLANs and subnets are not just networking theory. In a medium-sized environment, they are the difference between a flat network that gets harder to support every month and a segmented design that stays readable, secure, and easier to troubleshoot.

The practical rule is straightforward: use VLANs to separate switching domains, use subnets to organize IP addressing, and tie both to business function and trust level. When you plan growth early, reserve address space wisely, and document access rules clearly, the network becomes simpler to operate instead of more complicated.

If you are building or revisiting a segmented design, start with inventory, map the traffic, and assign one VLAN and one subnet per real use case. Then validate DHCP, routing, and access control before you scale it out. That approach is exactly the kind of hands-on thinking reinforced in Cisco CCNA v1.1 (200-301) training and in real network operations work every day.

CompTIA®, Cisco®, Microsoft®, AWS®, EC-Council®, ISC2®, ISACA®, and PMI® are trademarks of their respective owners.