Matt Schmitz/ August 22, 2017

I ran into an interesting issue recently, which was caused by use of the switchport protected command….

So I use a pair of Cisco 2960-8TC-L switches at home, for both my home network and lab. A few months back I ran a bunch of ethernet cabling within my house, which all terminated in a patch panel in the basement. I was able to migrate/consolidate enough of my ports so that I could dedicate one of the 2960s to the patch panel. I had eight ports on my switch, and eight ethernet drops in my house – one of which ran back to my lab network for internet.

Usually when I configure something like this, I want to try and take security into consideration as much as possible. I have a Synology NAS on my home network, which contains enough of my personal backups that I would want to keep this inaccessible from a typical house-guest. So by default, I made the following configuration standards on the ports connected to my patch panel:

  • Any unconnected ports were added to my guest VLAN (which only has internet access)
  • Any ports that needed to be in my home VLAN were configured with port security, sticky MAC, and maximum 1 MAC allowed
  • All ports were configured as switchport protected (except the uplink)

The concept of protected switchports should be fairly simple: Any port configured with switchport protected is not permitted to communicate with any other port configured with switchport protected. A protected switchport is only permitted to communicate with a non-protected port (in this case, my uplink/trunk to my other 2960). I added this mostly as a safeguard against a potentially malicious house-guest.

However, once I actually began to use my patch panel ports, I began to experience a very interesting issue. For example, I purchased a home security camera which by default used a wireless connection. The location of the camera unfortunately made the wifi connection a bit more unreliable than I would like for a security camera. So I went ahead and ran a cable to the nearest ethernet drop.

The IP camera uses my Synology NAS as a backend storage for any recordings. It was able to connect and stream video on the wireless connection, but the video was choppy. Once I plugged in the ethernet cable the connection actually got worse than it already was. From my Synology – the camera would become unresponsive for a while, then you could reach it again for a few moments, then back to unresponsive (about 60-70% packet loss). If I disabled the wireless NIC entirely, the camera would be completely unresponsive. However, this whole time I was able to reach the camera with no issues from my laptop which was connected via wireless (my AP uses the same switch as the Synology).

The NAS is connected to the 2960 in my lab, which is connected to the patch-panel-2960 via a single trunk port. From the Synology, I could still see ARP entries for my wired camera – I just couldn’t reach it via ping or http. I spent a good hour or two trying a number of things: clearing ARP entries, double checking my trunk port configs, and I also upgraded the firmware on the IP camera. Nothing seemed to work. It made even less sense that anything else connected to the Synology-side switch could hit the camera with no problems.

It’s worth noting that no ports on the Synology-side 2960 were configured with switchport protected – only the ports on the patch panel side. So I finally tried removing the switchport protected command off of the IP camera port – and magically it all started working.

The protected switchport config worked exactly as I would have expected for traffic between ports on the same switch – however, it seemed to act against what I would have expected once it crossed a trunk to another switch. It was especially odd that it only seemed to crop up between the Synology and the IP camera.

Oh well, I guess the only way you really learn something is by breaking it, right? I hope this might help someone who finds themselves in a similar situation…

About Matt Schmitz

Herding packets since 2007. Perpetually trying to automate myself out of a job. I believe that all problems can be solved by implementing more IPv6. Disclaimer: All opinions posted here are my own, and do not represent any vendor or current/former employer.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.