How to Implement Network Segmentation for Better Security

Most enterprise networks do not become risky overnight. They become risky the way cities become crowded: one new building at a time. A new SaaS integration here, a new warehouse switch there, a “temporary” vendor VPN that never gets removed, a lab subnet that quietly becomes production. For a while, everything still works. Then one day an endpoint gets compromised, a misconfigured service starts answering on the wrong interface, or a contractor plugs into the wrong port—and suddenly the question is not “what happened?” but “how far can this spread?”

Network Segmentation is how we stop small problems from becoming enterprise-wide incidents. On Cisco infrastructure, a practical VLAN strategy gives us clean boundaries, predictable traffic paths, and enforceable policy. The goal is not complexity. The goal is control: we decide what can talk to what, where, and why.

Prerequisites and assumptions

Before we touch configuration, we need to be explicit about the environment. Segmentation fails most often not because VLANs are hard, but because assumptions are implicit and drift over time.

• Platform scope: Cisco IOS or IOS XE for access/distribution switching, and a Cisco IOS/IOS XE Layer 3 device (multilayer switch or router) for inter-VLAN routing. The exact feature set varies by model and license, but the approach remains consistent.
• Access method: Console or SSH access with privilege level that allows configuration changes (enable and configure terminal).
• Change control: We schedule a maintenance window for VLAN creation, trunk changes, and gateway moves. Even “safe” VLAN changes can cause brief link renegotiations or STP reconvergence.
• Current-state capture: We must capture current VLANs, trunks, spanning-tree state, and routing before changes. This is our rollback reference.
• Addressing plan: We must have an approved IP plan per VLAN (subnet, default gateway, DHCP scope, DNS, and any required static reservations). If DHCP is centralized, we must know where the DHCP server lives and whether we will use DHCP relay (ip helper-address).
• Security policy: We must know which flows are required between segments (for example: users to DNS, users to application tier, application tier to database tier, management to infrastructure). If we do not know required flows, we will either break business traffic or leave the environment permissive.
• Persistence: On Cisco devices, changes persist only after we save the running configuration to startup configuration. We will explicitly save at controlled points.
• Out-of-band management: Ideally we have OOB access (console server) in case we lock ourselves out with management VLAN or ACL changes.

Design first: a practical VLAN strategy for enterprises

We are going to keep the strategy practical: a small number of VLANs that map to real trust boundaries, not a sprawling taxonomy that nobody can maintain. The segmentation model below is a strong baseline for many enterprises and scales cleanly.

• VLAN 10 – User: Corporate endpoints (workstations, laptops via wired access).
• VLAN 20 – Server: Application servers and infrastructure services that should not be directly reachable from user networks except where explicitly allowed.
• VLAN 30 – Voice: IP phones (keeps QoS and voice security clean).
• VLAN 40 – Guest: Internet-only access, no reachability to internal networks.
• VLAN 99 – Management: Switch management SVIs, infrastructure management tools, and administrative access paths.
• VLAN 999 – Blackhole: An unused VLAN for parking unused ports.

We will enforce policy at the Layer 3 boundary (SVIs or routed interfaces) using ACLs. This is the simplest enterprise-friendly control point on Cisco when we are not introducing additional firewalls or SDN policy engines. We will also harden Layer 2 behavior: prune trunks, disable DTP, set a non-user native VLAN, and lock down unused ports.

Step 1: Capture the current state and establish a rollback reference

We are about to collect the current VLAN, trunk, spanning-tree, interface, and routing state. This matters because segmentation changes are often distributed across multiple devices; having a before snapshot lets us quickly identify what changed and revert safely if needed.

enable
terminal length 0
show version
show running-config | include hostname|ip routing|vtp|spanning-tree
show vlan brief
show interfaces trunk
show spanning-tree summary
show ip interface brief
show ip route
show access-lists

We now have a baseline of what VLANs exist, which ports are trunks, what STP is doing, whether Layer 3 routing is enabled, and whether ACLs already exist. If we later see unexpected behavior, we can compare against this snapshot instead of guessing.

Step 2: Create VLANs and name them consistently

We are going to define the VLANs on the switching infrastructure. Naming is not cosmetic in enterprise operations; it reduces mistakes during incident response and change reviews. If we run VTP in the environment, we must be deliberate—many enterprises prefer VTP transparent mode to avoid accidental VLAN propagation.

configure terminal
vtp mode transparent
vlan 10
 name USER
vlan 20
 name SERVER
vlan 30
 name VOICE
vlan 40
 name GUEST
vlan 99
 name MGMT
vlan 999
 name BLACKHOLE
end

We have created the VLANs locally and set VTP to transparent to prevent unintended VLAN distribution. The VLAN database now contains our segmentation building blocks.

We will verify that VLANs exist and are correctly named.

show vlan brief

The output should list VLANs 10, 20, 30, 40, 99, and 999 with the expected names. If a VLAN is missing, we correct it now before touching trunks or access ports.

Step 3: Harden trunks so VLANs only exist where they are needed

We are about to adjust trunk behavior. This is where many environments accidentally re-create broad reachability: a trunk that carries every VLAN everywhere becomes a silent backplane for lateral movement. Our goal is to explicitly allow only required VLANs on each trunk, disable DTP negotiation, and set a non-user native VLAN to reduce VLAN hopping risk.

First, we identify trunk ports so we do not guess interface names.

show interfaces trunk

Now we will apply a hardened trunk template to a specific trunk interface. We will show one interface example; in production we repeat this per trunk, adjusting the allowed VLAN list to match what that uplink actually needs.

configure terminal
interface GigabitEthernet1/0/48
 description UPLINK_TO_DISTRIBUTION
 switchport mode trunk
 switchport nonegotiate
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,30,40,99,999
 spanning-tree guard root
end

This trunk is now explicitly a trunk (no negotiation), uses VLAN 999 as the native VLAN, and only carries the VLANs we listed. Root guard helps prevent an access switch from accidentally becoming the STP root due to misconfiguration or an unexpected device.

We will verify trunk state and allowed VLANs.

show interfaces trunk
show spanning-tree interface GigabitEthernet1/0/48 detail

We should see the interface in trunking mode with the correct native VLAN and allowed VLAN list. If VLANs are missing, endpoints in those VLANs will lose connectivity across that uplink, which is exactly why we verify immediately after each trunk change.

Step 4: Configure access ports for users, servers, voice, and guest

We are going to place endpoints into the correct VLANs at the edge. This is where segmentation becomes real: the same physical switch can host multiple trust zones, but only if ports are explicitly assigned and hardened. We will also park unused ports in a blackhole VLAN and disable them to reduce the chance of rogue connections.

User access port baseline

We will configure a typical user port in VLAN 10 and enable basic edge protections. PortFast reduces convergence delay for endpoints, and BPDU Guard shuts the port if a switch is plugged in, which prevents accidental loops and unauthorized switching.

configure terminal
interface GigabitEthernet1/0/10
 description USER_DESK_10
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
 spanning-tree bpduguard enable
 storm-control broadcast level 1.00
 storm-control multicast level 1.00
 storm-control unicast level 1.00
end

This port is now an access port in VLAN 10 with edge protections enabled. Storm control helps contain broadcast/multicast/unicast flooding events that can otherwise degrade an entire VLAN.

We will verify the VLAN assignment and operational state.

show interfaces GigabitEthernet1/0/10 switchport
show spanning-tree interface GigabitEthernet1/0/10 detail

Voice + data port baseline

We will configure a port that supports an IP phone with a workstation behind it. The data VLAN remains VLAN 10, and the voice VLAN is VLAN 30. This keeps voice devices in their own segment while still allowing the workstation to remain in the user segment.

configure terminal
interface GigabitEthernet1/0/11
 description PHONE_PLUS_PC_11
 switchport mode access
 switchport access vlan 10
 switchport voice vlan 30
 spanning-tree portfast
 spanning-tree bpduguard enable
end

The port now tags voice traffic into VLAN 30 while keeping the attached workstation in VLAN 10. This separation supports both security policy and QoS design later.

We will verify the voice VLAN configuration is present.

show interfaces GigabitEthernet1/0/11 switchport

Server access port baseline

We will place server-facing ports into VLAN 20. In many enterprises, servers are either on access ports or on trunks for virtualization hosts. We will start with the simplest and safest: an access port in the server VLAN.

configure terminal
interface GigabitEthernet1/0/20
 description SERVER_20
 switchport mode access
 switchport access vlan 20
 spanning-tree portfast
 spanning-tree bpduguard enable
end

This server port is now isolated into the server segment at Layer 2. Any reachability from users to servers will be decided at Layer 3, where we can enforce policy.

We will verify VLAN membership.

show interfaces GigabitEthernet1/0/20 switchport

Unused ports: blackhole and shutdown

We are going to remove opportunity. Unused ports are a common entry point for unauthorized devices. Parking them in VLAN 999 and shutting them down is simple, auditable, and effective.

configure terminal
interface range GigabitEthernet1/0/30 - 47
 description UNUSED_PARKED
 switchport mode access
 switchport access vlan 999
 shutdown
end

Those ports are now administratively down and placed into a non-routable blackhole VLAN. If someone plugs in, nothing happens until the port is intentionally enabled and assigned.

We will verify that the ports are down and in VLAN 999.

show interfaces status | include Gi1/0/3|Gi1/0/4
show vlan brief

Step 5: Enable inter-VLAN routing with SVIs and gateways

We are about to create Layer 3 interfaces (SVIs) for each VLAN on the Layer 3 device. This is the point where segmentation becomes enforceable: traffic between VLANs must pass through these gateways, where we can apply ACLs. We will also ensure routing is enabled.

First, we confirm whether IP routing is enabled on the device.

show running-config | include ^ip routing
show ip interface brief

If ip routing is not present on a multilayer switch, inter-VLAN routing will not occur. We will enable it and then define SVIs with clear gateway IPs.

configure terminal
ip routing

interface Vlan10
 description GW_USER
 ip address 10.10.10.1 255.255.255.0
 no shutdown

interface Vlan20
 description GW_SERVER
 ip address 10.10.20.1 255.255.255.0
 no shutdown

interface Vlan30
 description GW_VOICE
 ip address 10.10.30.1 255.255.255.0
 no shutdown

interface Vlan40
 description GW_GUEST
 ip address 10.10.40.1 255.255.255.0
 no shutdown

interface Vlan99
 description GW_MGMT
 ip address 10.10.99.1 255.255.255.0
 no shutdown

end

We have enabled Layer 3 routing and created default gateways for each VLAN. Each SVI will come up only if the VLAN exists and there is at least one active port in that VLAN (or the VLAN is carried on an active trunk). If an SVI stays down/down, it is usually a Layer 2 reachability issue, not an IP issue.

We will verify SVI status and routing readiness.

show ip interface brief | include Vlan
show ip route connected

We should see the VLAN interfaces in an up/up state (once VLANs are active) and connected routes for each subnet. This confirms the device is ready to route between segments—now we must control that routing with policy.

Step 6: Add DHCP relay where DHCP is centralized

If DHCP servers are not in each VLAN, clients will not receive addresses unless we relay DHCP requests to the server. We are going to configure ip helper-address on the SVIs that need it. This is a common enterprise pattern when DHCP is hosted in the server segment.

First, we confirm whether clients are expected to use a centralized DHCP server and identify its IP address from existing configuration.

show running-config | include helper-address
show running-config | include dhcp

Now we will add a helper address to the user and voice VLANs, pointing to a DHCP server in the server VLAN (example: 10.10.20.10). We only do this where needed.

configure terminal
interface Vlan10
 ip helper-address 10.10.20.10
interface Vlan30
 ip helper-address 10.10.20.10
end

DHCP broadcasts from VLAN 10 and VLAN 30 will now be relayed to the DHCP server at 10.10.20.10. This change is persistent once saved and is easy to audit on the SVI configuration.

We will verify helper configuration is present.

show running-config interface Vlan10
show running-config interface Vlan30

Step 7: Enforce segmentation with Layer 3 ACLs on SVIs

We are about to apply access control at the inter-VLAN boundary. VLANs alone separate broadcast domains, but they do not prevent routing between them once SVIs exist. ACLs are where we turn segmentation into security.

We will implement a practical baseline policy:

• User VLAN (10): allow DNS and DHCP to infrastructure, allow required application access to server VLAN, deny direct access to management VLAN, and deny everything else to internal networks by default.
• Guest VLAN (40): deny access to all internal RFC1918 networks, allow internet (handled by upstream routing/NAT/firewall).
• Management VLAN (99): allow administrative access to network devices, deny inbound from user/guest by default.

First, we confirm existing ACLs so we do not collide with names or inadvertently override a production policy.

show access-lists

User VLAN inbound policy

We will create an extended ACL and apply it inbound on VLAN 10. Inbound on the SVI means it filters traffic as it enters the gateway from the user segment, which is typically where we want to control user-initiated lateral movement.

configure terminal
ip access-list extended VLAN10-IN
 remark Allow DHCP to DHCP server (if centralized)
 permit udp any eq 68 host 10.10.20.10 eq 67
 remark Allow DNS to internal DNS resolvers
 permit udp any host 10.10.20.53 eq 53
 permit tcp any host 10.10.20.53 eq 53
 remark Allow HTTPS to application servers (example: app VIP or subnet)
 permit tcp any 10.10.20.0 0.0.0.255 eq 443
 remark Block access to management VLAN
 deny ip any 10.10.99.0 0.0.0.255
 remark Block access to other internal networks by default
 deny ip any 10.0.0.0 0.255.255.255
 deny ip any 172.16.0.0 0.15.255.255
 deny ip any 192.168.0.0 0.0.255.255
 remark Allow remaining traffic (typically to internet via upstream)
 permit ip any any
exit

interface Vlan10
 ip access-group VLAN10-IN in
end

We have created a user-segment policy that permits only explicitly required internal services, blocks management access, blocks broad internal RFC1918 reachability, and allows everything else (commonly internet-bound traffic). This is a baseline; in mature environments we tighten the “permit ip any any” to only the upstream egress path or specific destinations, but this baseline avoids breaking general browsing while still preventing lateral movement.

We will verify the ACL is applied and watch hit counts as traffic flows.

show running-config interface Vlan10
show access-lists VLAN10-IN

Guest VLAN inbound policy

We will restrict guest traffic from reaching internal networks. Guest should be treated as untrusted. We will apply the ACL inbound on VLAN 40 so internal destinations are blocked at the first hop.

configure terminal
ip access-list extended VLAN40-IN
 remark Block all access to internal RFC1918 networks
 deny ip any 10.0.0.0 0.255.255.255
 deny ip any 172.16.0.0 0.15.255.255
 deny ip any 192.168.0.0 0.0.255.255
 remark Allow remaining traffic (typically to internet via upstream)
 permit ip any any
exit

interface Vlan40
 ip access-group VLAN40-IN in
end

Guest traffic is now prevented from reaching internal address space. What remains is typically routed toward the internet through upstream security controls (firewall/NAT). This is a clean, enforceable boundary that does not depend on endpoint behavior.

We will verify application and hit counts.

show running-config interface Vlan40
show access-lists VLAN40-IN

Management VLAN protection

We will protect management by ensuring it is not reachable from user and guest segments (already denied in VLAN10-IN and VLAN40-IN). Now we also ensure that management access to the network devices is explicit and that device VTY access is restricted to the management subnet.

We will apply an access-class to VTY lines so only management subnet can SSH in. This reduces the chance that a compromised user endpoint can attempt device login from the user VLAN.

configure terminal
ip access-list standard MGMT-SSH-SOURCES
 permit 10.10.99.0 0.0.0.255
 deny any
exit

line vty 0 4
 access-class MGMT-SSH-SOURCES in
 transport input ssh
end

VTY access is now restricted to the management subnet, and SSH is enforced as the remote access method. This is a direct reduction in attack surface and is easy to validate during audits.

We will verify VTY configuration and ACL presence.

show running-config | section line vty
show access-lists MGMT-SSH-SOURCES

Step 8: Switch management hardening aligned to segmentation

We are going to align device management with the management VLAN. This ensures that switch management traffic does not share the same segment as users or guests. We will also set a default gateway for Layer 2 switches so they can be managed across subnets.

On a Layer 2 access switch, we configure the management SVI and default gateway pointing to the Layer 3 gateway in VLAN 99.

configure terminal
interface Vlan99
 description SWITCH_MGMT
 ip address 10.10.99.11 255.255.255.0
 no shutdown
ip default-gateway 10.10.99.1
end

The access switch now has a management IP in VLAN 99 and knows how to reach other networks via 10.10.99.1. This makes management predictable and keeps administrative access off user segments.

We will verify management interface status and reachability.

show ip interface brief | include Vlan99
ping 10.10.99.1

Step 9: Verification plan that works in production

We are going to verify segmentation from three angles: Layer 2 correctness, Layer 3 gateway correctness, and policy enforcement. This is how we avoid the common trap of “it pings, so it’s fine” while policy is silently wrong.

Layer 2 verification

We will confirm VLAN presence, port membership, and trunk VLAN propagation.

show vlan brief
show interfaces trunk
show mac address-table dynamic

If endpoints are in the right VLANs, we should see MAC addresses learned on the expected access ports and VLAN IDs. If a VLAN is missing on a trunk, MAC learning will look “local only” and inter-switch reachability will fail.

Layer 3 verification

We will confirm SVIs are up, routes are present, and the device is routing as expected.

show ip interface brief | include Vlan
show ip route connected
show ip arp

Up/up SVIs and connected routes confirm the gateway is active. ARP entries confirm real hosts are using the gateway and that Layer 2 adjacency exists.

Policy verification

We will confirm ACLs are applied and that they are actually matching traffic. Hit counts are our first signal that policy is doing real work.

show running-config interface Vlan10
show running-config interface Vlan40
show access-lists VLAN10-IN
show access-lists VLAN40-IN

If hit counts remain at zero during active use, the ACL may be applied in the wrong direction, on the wrong interface, or traffic may be bypassing the intended gateway path.

Step 10: Save configuration and confirm persistence

We are about to write the running configuration to startup configuration. Without this step, a reboot or power event will revert the device and silently remove segmentation controls.

write memory
show startup-config | include vlan 10|interface Vlan10|ip access-list

The configuration is now persistent across reboots. The verification command confirms that key elements (VLANs, SVIs, ACLs) exist in startup configuration, not just in running state.

Troubleshooting

SVI is down/down

• Symptom: show ip interface brief shows Vlan10 as down/down.
• Likely causes: VLAN not created, VLAN not allowed on trunk, no active access ports in that VLAN, trunk misconfigured.
• Fix: Verify VLAN exists and is active, then verify trunk allowed VLAN list includes it.

show vlan brief
show interfaces trunk
show spanning-tree vlan 10

Clients in a VLAN cannot get DHCP addresses

• Symptom: Endpoints remain on APIPA/169.254.x.x or fail to obtain an address.
• Likely causes: Missing ip helper-address, wrong DHCP server IP, ACL blocking DHCP, DHCP scope missing for that VLAN.
• Fix: Confirm helper address on the SVI and ensure ACL permits DHCP relay traffic.

show running-config interface Vlan10
show access-lists VLAN10-IN

Users cannot reach a specific internal service after segmentation

• Symptom: Only certain apps fail; general internet access still works.
• Likely causes: ACL missing required permit (port/protocol), service moved to a different subnet, DNS points to a new IP not covered by permits.
• Fix: Identify the destination IP/port and add a narrowly-scoped permit above the denies, then re-verify hit counts.

show access-lists VLAN10-IN

We locked ourselves out of switch management

• Symptom: SSH to the switch fails after applying VTY access-class or moving management to VLAN 99.
• Likely causes: Management workstation not in VLAN 99, missing routing to VLAN 99, VTY access-class too restrictive, wrong default gateway on Layer 2 switch.
• Fix: Use console/OOB access, confirm VLAN 99 SVI and gateway, then correct the VTY ACL or management IP settings.

show running-config | section line vty
show ip interface brief | include Vlan99
show running-config | include ip default-gateway

Common mistakes

• Mistake: Allowing all VLANs on every trunk.
  Symptom: Segments exist on paper, but lateral movement is still easy and VLANs appear everywhere.
  Fix: Prune trunks with explicit allowed VLAN lists per uplink and verify with show interfaces trunk.
• Mistake: Creating SVIs without enforcing policy.
  Symptom: After adding gateways, users can reach servers and management networks unexpectedly.
  Fix: Apply inbound ACLs on user and guest SVIs and verify hit counts with show access-lists.
• Mistake: Forgetting to save configuration.
  Symptom: After a reboot, VLANs/ACLs/SVIs revert and segmentation disappears.
  Fix: Run write memory and confirm key lines exist in show startup-config.
• Mistake: Misplacing the native VLAN or leaving it as a user VLAN.
  Symptom: Unexpected untagged traffic behavior, increased risk of VLAN hopping scenarios, confusing packet captures.
  Fix: Set native VLAN to an unused VLAN (like 999) and ensure it is not used for endpoints.
• Mistake: Applying ACLs in the wrong direction.
  Symptom: ACL hit counts stay at zero while traffic is clearly flowing, or traffic is blocked in unexpected ways.
  Fix: Re-check ip access-group ... in vs out on the correct SVI and validate with hit counts.

How do we at NIILAA look at this

This setup is not impressive because it is complex. It is impressive because it is controlled. Every component is intentional. Every configuration has a reason. This is how infrastructure should scale — quietly, predictably, and without drama.

At NIILAA, we help enterprises design segmentation that matches real business boundaries, deploy it safely across Cisco environments, enforce it with clear policy, and keep it maintainable as the network grows. That includes VLAN strategy, trunk and edge hardening, inter-VLAN controls, management-plane protection, verification plans, and operational runbooks that survive staff changes and audits.

Website: https://www.niilaa.com
Email: [email protected]
LinkedIn: https://www.linkedin.com/company/niilaa
Facebook: https://www.facebook.com/niilaa.llc