Cannot Ping Between VLANs: Find the Inter-VLAN Break
A ping that fails between two VLANs tells you nothing about where it failed. The path runs from the host's own IP settings, through its access port and VLAN, across one or more trunks, to whatever device owns both gateway addresses; any one of them can be the break. Work them in that order: each check clears a layer, not a command. This page finds the fault; router-on-a-stick and SVIs on a Layer 3 switch are where the build is written up. Start at the host, because the two most common faults live there and cost nothing to rule out.
Practice on hands-on CCNA & CCNP labs.
Read the symptom before you read the config
Three pings, in order, split the problem: your own gateway, a gateway in the other VLAN, then the remote host. Which one fails first names the half of the path to open. Your own gateway puts the fault between the host and that gateway interface; the other gateway puts it on the routing device; only the remote host puts it on the far side or in a filter.
One rule sits under all of it: test from the hosts. A ping sourced on the routing device uses its own interface in the VLAN as the source, so it never consults a host's mask or default gateway — where the fault most often lives. It does not skip the trunk or the access port: on a router-on-a-stick the trunk is the router's only path out. A device that reaches every host while every PC fails usually points at the hosts — but not always: a Layer 3 switch reaches every host over its own connected SVIs whether or not ip routing is on, and with it off it routes nothing between them. Same symptom, and the cause is the switch.
| What you see | What it means | Check first |
|---|---|---|
| The PC cannot ping its own gateway | Anywhere from the host to this VLAN's gateway interface — mask, access port, VLAN, trunk, or a missing or wrongly tagged gateway | The host's mask and gateway, then show vlan brief on its switch |
| The gateway answers, the other VLAN does not | Your side of the path is intact; the far side or the return path is not | Ping the other VLAN's gateway address, then that VLAN's place on the trunk |
| One VLAN routes, another does not | Something in the path is per-VLAN: an allow-list, a tag, or a missing gateway | show interfaces trunk at both ends, then the subinterface or SVI for the dead VLAN |
| No VLAN reaches any other VLAN | Nothing is routing at all | ip routing on a Layer 3 switch, or the parent interface on a router |
| One host fails, the rest of its VLAN is fine | The fault belongs to that port or that host, not to the design | The port's access VLAN, the host's mask and gateway, then port security |
| Pings work in one direction only | There is no return path, or one direction is being dropped | The destination's own gateway and mask, then ACLs and its host firewall |
Step 1 — Rule out the host
Two host settings break inter-VLAN traffic and nothing else, which is why they survive so long: the default gateway, which must be the address the routing device holds in this VLAN's subnet, and the mask, which must be the subnet's real mask.
A wrong mask is the one that hides. A host at 192.168.20.50 with 255.255.0.0 instead of 255.255.255.0 still reaches its own VLAN and its gateway, but it believes 192.168.10.50 is on its own link, so it ARPs for that address instead of using the gateway. The rest is the gateway's call: IOS leaves ip proxy-arp on by default, so the router normally answers with its own MAC and the ping works, hiding the fault. Where proxy ARP is off, nothing answers and the failure is off-subnet only — the one people blame on the trunk. Read the mask; never infer it from a ping.
A missing default gateway fails one step earlier: same-VLAN traffic works, and anything off-subnet is refused by the host's own stack before a frame leaves the NIC. A gateway address that is wrong but on-subnet fails differently: the host ARPs for it instead, so the host's ARP table settles it rather than the ping. A host address in the wrong subnet for its VLAN fails both ways and is easiest to spot against the addressing plan.
Then ping this VLAN's gateway from the host. If it answers, the access port, the VLAN, the trunk and this VLAN's gateway interface are all proved in one packet, and steps 2 and 3 can be skipped. If it does not, the break is anywhere from the host to that gateway interface — a gateway that is missing, shut, or tagged for the wrong VLAN is unreachable across a perfectly healthy trunk — so work steps 2 and 3 next because they are cheap, not because Layer 2 is proved guilty. Read the host's ARP table while you are here: a gateway entry with no MAC means nothing answered.
# Linux or Alpine host — address, mask, default route
$ ip address show eth0
$ ip route show
$ arp -an
# Windows host
C:\> ipconfig /all
C:\> arp -a
# Then, from the host, its own gateway
$ ping -c 5 192.168.20.1The host facts to confirm before you open a switch: address, mask, default route, then a ping to its own gateway.
Step 2 — show vlan brief: does the VLAN exist, and is the port in it
One command answers both halves. Each row is a VLAN that exists on this switch, with its status and the access ports assigned to it.
Read it for three things. The VLAN you need has a row at all — switchport access vlan 20 may create VLAN 20 for you, depending on image and VTP mode, but a VTP client cannot create it and a later no vlan 20 strips it out from under the port, so read the row rather than assume. Its status reads active; a suspended VLAN is still listed, still dead, and its ports go inactive. And the host's port sits in that VLAN's row rather than VLAN 1, because an unassigned access port stays in VLAN 1 — the most common cause of "the PC cannot reach its gateway".
One thing that looks wrong and is not: trunk ports appear in no VLAN row. This output lists access ports only, so the uplink to the router or to the next switch is simply absent from it.
When the port is listed in the wrong VLAN, or listed nowhere, show interfaces GigabitEthernet0/3 switchport gives the fuller answer — the operational mode and the access VLAN actually in effect, which matters when the mode is dynamic and the port negotiated into something you did not intend. The VLAN and trunking cheat sheet carries both commands.
SW1# show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/3
10 SALES active Gi0/2
20 ENGINEERING active
999 NATIVE active
! Fix: put the port in its VLAN
SW1(config)# interface GigabitEthernet0/3
SW1(config-if)# switchport mode access
SW1(config-if)# switchport access vlan 20Illustrative, not captured. VLAN 20 exists but holds no port, and Gi0/3 — the Engineering PC — is still in VLAN 1. The trunk is absent from every row, which is normal.
Step 3 — show interfaces trunk: is it a trunk, and is the VLAN on it
Run this at both ends of every link between the host and its gateway, not just the one nearest the problem. An interface missing from the output is not trunking, whatever its config line says: a port left at the default, or one whose negotiation the far end declined, carries a single VLAN untagged and drops the rest without a message.
The command prints four blocks and only the last is the truth. "Vlans allowed on trunk" is what you typed; each block below narrows it by what exists on this switch and what spanning tree is forwarding, so a VLAN allowed but never created shows in the first list and not in the last. Compare the bottom block against the VLANs the design says this link carries.
The allow-list is the classic trap, because switchport trunk allowed vlan 30 replaces the list instead of extending it. One line typed without add strips every other VLAN off the trunk, and the symptom is precisely "VLAN 10 works, VLAN 20 does not". On a live trunk, switchport trunk allowed vlan add 30 is the only safe form.
An access port where the router expects a trunk breaks the whole design rather than one VLAN: frames arrive untagged, no encapsulation dot1q subinterface matches them, and nothing routes. Access port versus trunk port covers what the two modes do to a frame, and why one of them cannot serve a router with several gateways on one cable.
SW1# show interfaces trunk
Port Mode Encapsulation Status Native vlan
Gi0/1 on 802.1q trunking 999
Port Vlans allowed on trunk
Gi0/1 10,999
Port Vlans allowed and active in management domain
Gi0/1 10,999
Port Vlans in spanning tree forwarding state and not pruned
Gi0/1 10,999
! Fix: add the VLAN, never retype the list
SW1(config)# interface GigabitEthernet0/1
SW1(config-if)# switchport trunk allowed vlan add 20Illustrative, not captured. VLAN 20 is absent from the allowed list, so VLAN 10 routes and VLAN 20 is stranded at Layer 2.
Step 4 — The device that owns the gateways
When the host reaches its own gateway and nothing beyond, the path to that gateway is proved and the question becomes whether the routing device holds a working interface in the other VLAN — and whether it routes at all.
Ping each gateway address from one host. Every gateway lives on the same device, so a host that reaches 192.168.20.1 but not 192.168.10.1 has told you that VLAN 10's gateway interface is missing, shut, in the wrong subnet, or — on a Layer 3 switch — down for want of a live port in VLAN 10, without your going near a VLAN 10 host. That proves the interface, nothing else: a router subinterface replies from its own address whether or not the trunk carries its VLAN, so it never clears the allow-list. Then read show ip route there: a subnet with no connected route has no working gateway.
Router-on-a-stick: the tag, not the number
Start with show ip interface brief. The physical parent interface must be up/up, and it normally carries no address of its own. Subinterfaces inherit the parent's state, so one shutdown there takes every VLAN down at once — that is the fault behind "no VLAN reaches any other VLAN" on a router.
Then read the tag. encapsulation dot1q <vlan> binds a subinterface to a VLAN; the number after the dot is a label and binds nothing. A subinterface numbered .20 but tagged 200 reads as correct in every summary listing and routes nothing, which is how this fault survives three passes over a config. show interfaces GigabitEthernet0/0.20 prints the VLAN ID it is tagged for, and show vlans lists every subinterface with its tag.
Each subinterface holds the gateway address for its VLAN's subnet, and that address has to be the one the hosts in that VLAN point at. A subinterface that is up, correctly tagged and addressed in the wrong subnet gives you a gateway nobody can reach.
R1# show ip interface brief | include GigabitEthernet0/0
R1# show interfaces GigabitEthernet0/0.20
R1# show vlans
! The tag binds the subinterface, not the number after the dot
R1(config)# interface GigabitEthernet0/0.20
R1(config-subif)# encapsulation dot1q 20The three reads that settle a router-on-a-stick, and the line that corrects a wrong tag.
Layer 3 switch: SVIs up is not the same as routing
ip routing is the one people forget, and its symptom is unmistakable: every host reaches its own gateway and nothing crosses. Without it the switch simply holds an address in each VLAN and forwards between none of them. show run | include ip routing settles it in one line — never infer it from an SVI that shows up/up.
An SVI has its own up/up rule. It stays down until the VLAN exists on the switch and something in that VLAN is up: an access port in it, or a trunk that carries it. A freshly built interface vlan 20 on a switch whose VLAN 20 has no live port is down for a reason that has nothing to do with the SVI's own configuration.
With routing on and the SVIs up, each VLAN's subnet appears in show ip route as a connected route. A VLAN missing from that list has no gateway on this device, and that is the thing to fix before looking anywhere else.
SW1(config)# ip routing
SW1(config)# interface vlan 20
SW1(config-if)# ip address 192.168.20.1 255.255.255.0
SW1(config-if)# no shutdown
SW1# show run | include ip routing
SW1# show ip interface brief | include Vlan
SW1# show ip route connectedTurning routing on, and the three reads that prove it. The full build belongs in the SVI guide, not in a repair.
Step 5 — ACLs, and the native VLAN case
Two faults get this far because they leave the path intact and drop the traffic anyway.
An ACL on the gateway interface
An inbound ACL on a subinterface or an SVI is invisible to every check above. The tell is asymmetry: hosts reach their own gateways, one direction crosses and the other does not, and a ping sourced on the routing device often succeeds. show ip interface GigabitEthernet0/0.20 | include access list names what is applied in each direction, and show ip access-lists prints a per-line match count. Trust that count on a router. On a Layer 3 switch the filtering happens in hardware and the count can sit flat while the ACL still drops, so prove it there by pulling the ACL off the interface.
Check the hosts too. A host firewall can drop ICMP from outside its own subnet while the host is otherwise healthy, which reads as "the other VLAN cannot reach it" and is not a network fault at all. Do not assume the default either way — prove it by testing a service the host definitely answers, from a host in its own VLAN and from one in yours.
A native VLAN mismatch
Native VLAN frames cross a trunk untagged, and that has two different consequences worth keeping apart.
Between two switches, a mismatch does not break one VLAN — it tries to merge two, each end dropping the other's untagged frames into a different VLAN. On Cisco gear running PVST+ or Rapid-PVST, spanning tree normally catches that first and blocks the VLANs involved as a PVID inconsistency, so those VLANs go dead rather than merging; the merge is what you get where per-VLAN spanning tree is not running at both ends. CDP logs a native VLAN mismatch, but do not wait for a log: show interfaces trunk prints the native VLAN per port, so the two ends side by side are the diagnosis.
On a trunk to a router it does break exactly one VLAN. A plain encapsulation dot1q 10 subinterface is waiting for a tag that native-VLAN frames never carry, so VLAN 10 is dead while every other VLAN routes normally — a symptom that looks like an allow-list problem and is not. Either mark that subinterface with encapsulation dot1q 10 native, or keep user VLANs off the native VLAN entirely. Setting the native VLAN covers that choice and the hardening that goes with it.
When it is one-way, or intermittent
One-way is a return-path problem until proved otherwise, so ping from both ends first. Then read the ARP table on the routing device. An incomplete entry for the destination means the gateway asked and nothing answered, which puts the fault on the destination's side: its access port, its VLAN, or the host being down. A complete entry with the ping still failing moves the search to the destination host's own gateway and mask, or to a filter in front of it.
Intermittent has a short list. A duplicate address — a second device, or a leftover SVI on another switch holding the gateway IP — sends half the flows to the wrong place, and IOS logs a duplicate-address message naming the MAC that claimed it. A Layer 2 loop makes one MAC appear on two ports in turn, which IOS reports as a MAC flap. And per-VLAN spanning tree can block a VLAN on the uplink you assume it uses, so show spanning-tree vlan 20 earns a look whenever one VLAN behaves differently.
One "failure" that is not one: on a Cisco device, the first packet of a ping set often drops while ARP resolves the next hop. Judge a test by the packets after the first.
The order, in one pass
Run it top to bottom and stop at the first check that fails — each one clears everything below it.
- Verify the repair from both hosts, in both directions — a fix proved one way can leave a return-path fault in place.
- Re-run
show interfaces trunkafter any allow-list edit; it shows whether the edit extended the list or replaced it.
- On the host: address, mask, default gateway. A wrong mask survives a ping to the gateway, and proxy ARP can hide it off-subnet too, so read it rather than infer it.
- From the host: ping its own gateway. Success clears the access port, the VLAN assignment and the trunk in a single packet.
show vlan briefon the access switch: the VLAN exists, its status is active, and the host's port is in its row rather than in VLAN 1. Trunk ports are absent from this output by design.show interfaces trunkat both ends of every trunk in the path: the link is trunking, and the VLAN appears in the bottom block, not merely on the allowed line.- On the routing device: parent interface up, one interface per VLAN, the right
encapsulation dot1qtag or a live SVI, the gateway address the hosts point at, a connected route per subnet, andip routingif it is a Layer 3 switch. - Only then ACLs, the native VLAN, and the firewall on the host at the far end.
Which design you are repairing changes the last step
Everything up to step 4 is identical on both inter-VLAN designs, because the host, the VLAN and the trunk do not care what terminates them. Step 4 splits: a router-on-a-stick fails at a subinterface tag, a parent interface or an address, while a Layer 3 switch fails at ip routing, an SVI with no live port in its VLAN, or a missing connected route.
Knowing which one you are looking at saves searching a router for a command that only exists on a switch: subinterfaces on one physical link means the first, interface vlan interfaces mean the second. The VLAN study path lays the two designs side by side.
Frequently asked questions
I can ping my own gateway but not the other VLAN. Where is the fault?
Reaching your gateway proves your access port, your VLAN and the trunk that carries it. It does not prove the host's mask: a too-short prefix reaches the gateway normally, and whether it also breaks off-subnet traffic depends on proxy ARP at the gateway. The fault is past that point: the other VLAN's gateway interface, that VLAN's place on the trunk, an access list on the routing device, or the remote host's own gateway and mask. Ping the other VLAN's gateway address next, because it lives on the same device and should answer.
Why does one VLAN route while another does not?
Because something in the path is per-VLAN. The usual three are a trunk allow-list that omits the VLAN, a missing subinterface or SVI for it, and a subinterface carrying the wrong 802.1Q tag. Check the trunk at both ends first, since one omitted VLAN at one end kills it in both directions.
Does the router subinterface number have to match the VLAN ID?
No. The encapsulation dot1q command is what binds a subinterface to a VLAN, and the number after the dot is only a label. Matching them is the near-universal convention, because a subinterface numbered .20 that is tagged for VLAN 200 reads as correct in every summary listing and still routes nothing.
My SVIs are up and I still cannot route between VLANs. Why?
A Layer 3 switch does not route by default. Without the global ip routing command the switch holds an address in each VLAN and forwards between none of them, so every host reaches its own gateway and nothing crosses. Confirm the command is in the running configuration rather than inferring it from an SVI that shows up and up.
Can a native VLAN mismatch stop one VLAN from routing?
On a trunk to a router, yes. Native VLAN frames cross the trunk untagged, and a subinterface configured with a plain encapsulation dot1q tag never matches them, so that one VLAN dies while every other VLAN routes. Add the native keyword to that subinterface, or keep user VLANs off the native VLAN. Between two switches the same mismatch behaves differently: per-VLAN spanning tree usually blocks that port for the VLANs involved in the mismatch, so those die on that link while the rest of the trunk keeps forwarding.
Practice the diagnosis on a graded lab
Build and verify inter-VLAN routing on real Cisco IOS in CML — several of these hand you a path that is already broken — then upload the config for a grade.
Practice on real Cisco IOS
Build it on real Cisco IOS and get instant pass/fail grading on your own config.