Network Troubleshooting #1: Why Two Devices in the Same VLAN Cannot Communicate? — Switchport Protected

As a network engineer, you can face a surprising scenario in daily life: Devices can access the outside world (the internet) without any problems, but they cannot talk to the neighbor device right next to them.

At first, this looks like a subnet mask problem, a wrong gateway configuration, or a NAT/PAT error. However, the real reason can be a small configuration on the local Switch layer.

In this post, we’ll look at a troubleshooting scenario from the PM Networking channel. I shared the topology created from scratch on Cisco Packet Tracer below. Examine the topology, and then let’s start thinking like a network engineer step by step. We’ll check and eliminate possible errors (Subnet, NAT, Routing), and find the real problem with a focused troubleshooting process.

Topology and Scenario

In our scenario, we have 4 computers (PC0, PC1, PC2, PC3), a Router0 managing our local network, an ISP Router simulating the internet world, and a 2960 Switch connecting all local devices together.

Network Block: 192.168.10.0/24

PC0 — PC3 IP Addresses: 192.168.10.1–192.168.10.4

Default Gateway: 192.168.10.100 (Router0 LAN interface)

Internet Destination: 8.8.8.8 (ISP Loopback interface)

Current Status: All computers can ping the internet (8.8.8.8) without any problems. PC2 and PC3 can talk to everyone on the network. However, PC0 and PC1 cannot communicate with each other at all.

Check the screenshot below; it shows ping results. PC0 can’t communicate with PC1; it can communicate with PC2 & PC3 can. The same thing happens to PC1.

PC0 & PC1 computers can ping the internet (8.8.8.8) without any problems like the others:

Thinking Like an Engineer: Let’s Eliminate the Possibilities! — Troubleshooting Time

Instead of executing commands to solve the problem blindly, we should analyze the situation and eliminate the possibilities one by one.

[embed]

Suspect #1: Incorrect Subnet Mask or Gateway?

One possibility that comes to mind is that the network engineer configured the wrong subnet mask or gateway address on the computers.

Elimination: If the subnet mask or gateway were incorrect, PC0 and PC1 wouldn’t be able to access the internet (8.8.8.8). However, our devices can successfully send packets to the outside world. Therefore, the IP configuration is perfectly correct.

Suspect #2: NAT/PAT or Routing Error on the Router?

Is it possible that the NAT (Network Address Translation) or Default Route (ip route 0.0.0.0 0.0.0.0) is misconfigured on Router0?

Elimination: Since the end devices have internet access, we can confirm that NAT and static routing on Router0 are running smoothly. Besides, the problem is within the local area network (LAN); the packets are dropping before they even reach the router.

Suspect #3: Different VLAN Situation?

Is it possible that PC0 and PC1 cannot see each other because they are on different virtual networks (VLANs)? Let’s open the Switch CLI screen to check the situation by writing down the command below:

show vlan brief

Elimination: The output shows that all ports (Fa0/1, Fa0/2, Fa0/3, Fa0/4) belong to VLAN 1 (Default) by default. Meaning, the devices share the same broadcast domain. We can eliminate this possibility too.

The Source of the Problem: Switchport Protection (Protected Port)

Having eliminated all standard protocols at the local layer, it is time to check the switch’s port-based specific configurations. To find out what’s really going on, we will run show running-config command and look closely at the port settings for both FastEthernet 0/1 and FastEthernet 0/2. Open the Switch’s CLI again:

enable

show running-config

As you can see from the results we obtained, the switchport protected setting is defined under both interfaces.

Important Technical Note: In Cisco architecture, the Protected Port feature is used to prevent devices within the same VLAN from communicating with each other at Layer 2 (the simplest form of Private VLAN logic). While protected ports can communicate with unprotected ports, two protected ports can never exchange data with one another. This is why PC0 and PC1 can access the internet (since the router port is not protected), but the pings they send to each other are blocked by the Switch (Request timed out).

Solution and Verification

Now that we have diagnosed the issue, applying the solution is extremely simple. We’ll access these two interfaces on Switch0 CLI and remove the protection command using the no prefix. Open the Switch’s CLI:

For PC0:

enable

configure terminal

interface fastEthernet 0/1

no switchport protected

exit

For PC1:

configure terminal

interface fastEthernet 0/2

no switchport protected

end

write

The Result

Let’s run another ping test from PC0 to PC1’s IP address (192.168.10.2) & visa versa:

Ping test from PC0 to PC1:

ping 192.168.10.2

Ping test from PC1 to PC0:

ping 192.168.10.1

Happy ending! Our packets are now reaching the destination without any loss. This was a great troubleshooting example. I’d like to express my gratitude to PM Networking! See you in the next troubleshooting scenario, byeeee!