9

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?

Mike Pennington
  • 29,876
  • 11
  • 78
  • 152
Shane Madden
  • 615
  • 5
  • 15
  • 1
    Hi Shane, [the correct solution for this situation is normally to make your ARP timer slightly lower than the CAM timer](http://networkengineering.stackexchange.com/questions/2192/best-practice-for-the-combination-of-hsrp-and-ecmp). It is a reasonable question about [switchport protected](http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_53_se/command/reference/cli3.html#wp1948678) but probably not the best way to conquer the problem... – Mike Pennington Aug 18 '13 at 10:28
  • @MikePennington Gotcha, makes sense. Everything's working great with the timers matching at the moment, I'm just wondering why the inconsistency between the documentation and the observed behavior. – Shane Madden Aug 18 '13 at 18:25
  • Was `switchport protected` configured on all switchports in the vlan? Any chance we could see the configs and a diagram of the path between the two hosts? – Mike Pennington Aug 19 '13 at 10:57
  • @MikePennington Yeah, it's configured on all of the ports on that vlan except the uplink. The next hop router (which the problem traffic flows through) is the switch that this switch uplinks to. Configs would be tricky, but I can grab specific parts of interest if needed. – Shane Madden Aug 20 '13 at 02:02

1 Answers1

5

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.

switchport protected is used to enforce privacy within a vlan... the command prevents ports from talking to other ports configured with switchport 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 protected is 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 unicast does stop unknown unicast flooding; however, see below for why I think you shouldn't need this command.

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.

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:

Setting the timers to match is working great as a workaround - I just don't understand why the flooding isn't happening as expected.

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.

3550_switch(config-if)#switchport block unicast
3550_switch(config-if)#switchport block multicast
Community
  • 1
Mike Pennington
  • 29,876
  • 11
  • 78
  • 152
  • Let me clarify: `switchport protected` is implemented in this case as an isolation mechanism between systems that shouldn't be able to communicate. The traffic in question ingresses to the switch on a non-protected port, and is failing to unicast flood the protected ports on the vlan - and connection failures are occurring because of that. Setting the timers to match is working great as a workaround - I just don't understand why the flooding isn't happening as expected. – Shane Madden Aug 22 '13 at 02:54
  • @ShaneMadden, you were correct to expect unicast flooding on the protected switchport. See my edit. – Mike Pennington Aug 22 '13 at 09:29
  • Right - any thoughts on what's causing the failure to flood? I can't come up with many ideas other than IOS bug. – Shane Madden Aug 23 '13 at 06:18