Does having switchport protected configured on an interface prevent unicast flooding for a MAC address the switch hasn't learned?
The information that I'm seeing conflicts — the wikipedia page on unicast flooding cites protected mode as a mechanism to block flooding, while Cisco's documentation says that switchport protected doesn't matter, and that switchport block unicast would still be needed to prevent flooding.
However, I recently ran into an issue where on a 2950G running some relatively ancient 12.1(22) code, unicast flooding seemed to be completely broken for a protected port — the aging time on the switch was 5 minutes, while the router's ARP timeout was 30 minutes, and the one TCP connection utilizing this interface had a tendency to sit dormant for 10 minutes at a time – and be non-functional when waking up after 10 minutes in this case.
Captures run on the host showed no unicast flooding when it was expected, and increasing the MAC aging timer on the switch to match ARP completely resolved the problem.
Is this behavior undefined or inconsistent in older IOS versions, or is this just a bug in this old code?
Best Answer
switchport protectedis used to enforce privacy within a vlan... the command prevents ports from talking to other ports configured withswitchport protected. This command reduces flooding as a side-effect of using it on all ports in a Vlan, but it does much more than "just" remove flooding from a switchport. Honestly, I think there are better ways to accomplish your goals.switchport protectedis useful if you're aggregating colocation customers in the same vlan; this command is one way to offer privacy between the customers without the complications of private vlans. The wikipedia article you mentioned, says you can "bounce" traffic off the default gateway (which should not be on a protected switchport) to reach those other destinations...switchport block unicastdoes stop unknown unicast flooding; however, see below for why I think you shouldn't need this command.As I mentioned in my comment, if there is any potential for an asymmetric routed path in this network, you either need unknown unicast flooding, or you need to match the CAM and ARP timers to ensure that CAM entries don't age out before the ARP entries.
In most cases, matching the ARP and CAM timers is the right way to fix the situation, but the choice is yours...
EDIT to respond to the comments:
Quoting from "CCIE Practical Studies, Volume 2", page 115 by Karl Solie, Leah Lynch, Charles Ragan:
If unknown unicast and multicast traffic is forwarded to a protected port, there could be security issues. To prevent unknown unicast or multicast traffic from being forwarded from one port to another, you can configure a port (protected or nonprotected) to block unknown unicast and multicast traffic.