It started simple. A laptop on the management network could not reach its own gateway. It could reach every other VLAN just fine.

This is the story, the tests that helped, and what I would try first if it happened again. The exact root cause was never proven. A clean reconfiguration of the router and the switch later on made the problem disappear.

What Was Broken

• Laptop on management VLAN 99 at 10.0.99.199
• Could not reach the gateway 10.0.99.1
• Could reach gateways on other VLANs 10.0.10.1, 10.0.20.1, 10.0.30.1, 10.0.40.1
• Switch port for the laptop was untagged VLAN 99
• SFP plus uplink carried tagged VLANs to the router

The thing that stood out. The client was blind to its own subnet but could talk to other subnets.

What Looked Right

• Switch VLAN 99 set with the correct PVID on the access port
• Trunk on SFP plus showed VLAN 99 tagged toward the router
• Router interface for management had the right address 10.0.99.1/24
• Router could ping the laptop
• ARP on the laptop showed the correct MAC for 10.0.99.1

Layer two and the trunk looked healthy. The router and the switch could see each other. The laptop still said no route to host when pinging 10.0.99.1.

What The Network Showed

Early hypothesis. Trunk and access mismatch on the router uplink.

• Removed a stray bridge entry in a tagged list
• Set the router uplink PVID to the default for a trunk
• Verified the switch access port stayed untagged for VLAN 99

This cleaned up the config but did not change behavior.

Then I measured on both sides.

• Packet capture on the switch saw the laptop send broadcast traffic
• Packet capture on the router saw broadcast from the laptop on VLAN 99
• Neither capture showed unicast ICMP from the laptop to 10.0.99.1
• The laptop could ping 10.0.99.255 and see replies
• The laptop returned no route to host on unicast to 10.0.99.1

That pointed away from trunks and toward the client’s routing decisions.

What The Client Showed

• Restarting the interface did not help
• A new macOS network Location did not help
• The routing table on the laptop showed invalid or reject entries for the local subnet at different points in time

There was a tempting path here. Some notes in my log pointed to third party software on macOS. In hindsight that was not correct. Two machines with different app mixes showed similar symptoms at different times. I do not want to overfit the data.

What Finally Happened

I moved on to other projects and worked around the issue. Later I rebuilt the router and the switch configs from scratch. Same VLANs. Same addressing plan. Same physical links.

The problem did not come back.

I wish I had a single command to blame. I do not. The best honest summary is this. I removed any chance of a mislearned or stale state anywhere between the access port and the router interface.

Tests That Helped

If you ever see a client reach other VLANs but not its own subnet, these checks gave the most signal.

• On the client
  • netstat -rn and look for reject or invalid marks on the local subnet
  • arp -an for the gateway MAC
  • Ping the broadcast x.x.x.255 to confirm L2 reachability
• On the switch
  • Confirm PVID on the access port and that VLAN is untagged
  • Confirm the trunk tags that VLAN toward the router
  • Mirror the access port and capture to see if unicast leaves the client
• On the router
  • Capture on the management interface and watch for unicast from the client
  • Confirm the interface and subnet address match what DHCP hands out

What I Would Do Differently Next Time

• Save a full snapshot of router and switch configs before and during changes
• Mirror the access port and the uplink at the same time to compare frames
• Keep a tiny set of repeatable eval pings and ARP checks to rerun after each change
• Reset state sooner if captures show a split view between broadcast and unicast

Open Questions

• Why did the client claim no route to host for its own subnet while other subnets worked?
• Could an obscure bridge or VLAN table state have blocked unicast while allowing broadcast?
• Did a stale learning entry on a link cause selective delivery that only a full rebuild cleared?

I cannot prove any of those today. When your client cannot reach its own gateway but can reach other VLANs, split your tests by broadcast and unicast and trace them both. It keeps you honest and saves time even when the ending is a mystery.