Network segmentation failures almost always come down to four layers: switch port VLAN membership, trunk tagging, Layer 3 gateway (SVI or router subinterface), and firewall policy between subnets. Verify each layer in order using ping, traceroute, and the switch CLI, then correct the first mismatch you find before retesting.
Symptoms
- Devices in VLAN A can ping their own gateway but nothing in VLAN B
- Traceroute to another subnet dies at the first hop or the core router
- Some hosts on a VLAN get a DHCP lease, others pull a 169.254.x.x APIPA address
- Inter-VLAN traffic works one direction only (asymmetric routing or NAT hairpin)
- ARP table on the switch shows the client MAC on an unexpected VLAN
Common Causes
Access port in the wrong VLAN
The switchport is set to an access VLAN that no longer matches the intended segment, usually after a patch change or a copy-paste config error on a new port.
Trunk pruning or missing allowed VLAN
An uplink trunk does not carry the VLAN in question because it was pruned, omitted from the allowed list, or the native VLAN differs on each end.
Missing or misaddressed SVI
The Layer 3 switch has no interface Vlan defined for the segment, the SVI is administratively down, or its IP does not match what clients use as their default gateway.
Firewall zone or ACL blocking the flow
An east-west rule between zones drops the traffic, or a stateful firewall sees only one direction of the conversation and discards return packets.
DHCP relay not configured
Clients in a remote VLAN never reach the DHCP server because ip helper-address is missing on the SVI, so they fall back to link-local addressing.
Step-by-Step Fix
- Confirm the failure and pin down where it breaks
From an affected client, ping its own gateway, then a host in the target subnet, then run tracert (Windows) or traceroute (Linux/macOS). If the gateway responds but the next hop does not, the problem is routing or firewalling, not the local segment. - Verify the switchport VLAN and operational state
On the access switch, run show interfaces status and show vlan brief. Confirm the port is up, in the correct access VLAN, and not err-disabled. For Cisco, show interfaces GigX/Y switchport reveals the operational access VLAN versus the configured one. - Check trunk links between switches
Run show interfaces trunk. Every VLAN you expect to cross the uplink must appear under Vlans allowed and active. Native VLAN must match on both ends, otherwise CDP will log a mismatch and tagged frames will leak. - Inspect the Layer 3 gateway for each subnet
On the router or L3 switch, run show ip interface brief and confirm each interface Vlan is up/up with the correct IP and mask. Verify ip routing is enabled globally. show ip route should list every subnet as directly connected. - Test routing between segments from the gateway itself
Ping from the L3 device to a host in each VLAN. If the gateway can reach both sides but clients cannot cross, the issue sits above Layer 3, typically a firewall rule, a client-side host firewall, or a missing return route on the far subnet. - Review firewall policy for inter-VLAN traffic
On the firewall, check the rule base for a policy that permits the required ports between the source and destination zones. Enable logging on the suspect rule, generate traffic, and read the hit counter or session table to see whether the packet is allowed, dropped, or never arrives. - Fix DHCP and DNS reachability across segments
On each SVI that serves clients, add ip helper-address pointing at the DHCP server. Confirm the scope on the server matches the subnet and gateway. For DNS, ensure clients receive an internal resolver that is itself reachable across the segment boundary. - Document the change and retest end-to-end
After each fix, retest with ping and a real application flow, not just ICMP. Save the running configuration, note what was changed and why in your change log, and clear ARP or MAC tables if stale entries persist.
Common segmentation symptoms mapped to their most likely cause and first fix
| Symptom | Likely cause | First action |
|---|---|---|
| Client gets 169.254.x.x address | DHCP relay missing on SVI | Add ip helper-address on the interface Vlan |
| Ping to gateway works, ping across VLANs fails | Firewall policy or missing route | Check firewall logs, then show ip route |
| Only some ports in a VLAN work | Wrong access VLAN on specific ports | Verify with show interfaces status |
| VLAN missing on remote switch | Trunk allowed list pruned | Adjust switchport trunk allowed vlan |
| Intermittent loss between subnets | Asymmetric routing or duplicate IP | Check ARP tables and routing metrics |
| CDP native VLAN mismatch log | Native VLAN differs on trunk ends | Align switchport trunk native vlan |
Prevention
- Standardise VLAN IDs, subnet ranges, and SVI addressing in a single source-of-truth document
- Use descriptive port descriptions and interface Vlan names so intent is obvious at the CLI
- Back up switch and firewall configs automatically before every change window
- Monitor trunk allowed-VLAN lists and SVI status with SNMP or a NMS to catch drift early
FAQ
Do I need a Layer 3 switch, or will a router on a stick work?
Both approaches route between VLANs. A router-on-a-stick uses one physical link with 802.1Q subinterfaces and is fine for low-throughput sites. A Layer 3 switch handles inter-VLAN routing in hardware at line rate and scales better once you have more than a handful of VLANs or gigabit traffic between them.
Why can I ping across subnets from the switch but not from a client?
The switch itself sits inside every directly connected subnet, so it always has a valid source interface. Clients depend on their configured default gateway, correct subnet mask, and a firewall policy that permits the flow. Check the client's IP configuration, then work outward to the firewall rule base.
Is it safe to allow all VLANs on every trunk?
It works, but it is not recommended. Carrying unnecessary VLANs increases broadcast scope, complicates troubleshooting, and weakens segmentation as a security control. Prune trunks to only the VLANs each uplink actually needs, and keep the native VLAN consistent and unused for data.
Need a second pair of eyes on a stubborn segmentation issue? Request a network review with our engineers.