Unknown Unicast Flooding – Understanding Unknown Unicast Flooding

ciscojuniperSecurityswitch

I'm focusing currently on the "Unknown Unicast Flooding", and the proposed solutions from Cisco.

I really need deep information about:

Cisco Blocking Unknown Unicast Flooding (UUFB)
Unknown Unicast Flood Rate-limiting (UUFRL)
Port Unicast and Multicast Flood Blocking
Unknown Unicast Forwarding (from Juniper)

I have already the concept they are used to block/limit unicast flooding attacks, however I'm intrested on how they work, the algorithms behind the process, any specific RFC, mechanisms and approaches !

I search about those concept, but what I found is just how configure them without go deep in their algorithms.

Yours sincerely,

Best Answer

There really isn't a lot to this subject, you can block unknown unicasts or you can rate limit them to a particular percentage of the bandwidth. Juniper does have an interesting third option, but I'm not sure how useful it really is. There are no RFCs, each vendor is able to handle (or not) this subject in a different, possibly proprietary, way.

The Cisco configuration documents are usually pretty good about explaining how things work.

For how Cisco Cisco UUFB and UUMB works: Configuring Unknown Unicast Flood Blocking (UUFB)

By default, unknown unicast and multicast traffic is flooded to all Layer 2 ports in a VLAN. You can prevent this behavior by using the UUFB and UMFB features to prevent or limit this traffic. The UUFB and UMFB features block unknown unicast and multicast traffic flooding at a specific port, only permitting egress traffic with MAC addresses that are known to exist on the port. The UUFB and UMFB features are supported on all ports that are configured with the switchport command, including private VLAN (PVLAN) ports.

For how Cisco UUFRL works: Configuring Traffic-Storm Control

Traffic storm control (also called traffic suppression) monitors incoming traffic levels over a 1-second traffic storm control interval and, during the interval, compares the traffic level with the traffic storm control level that you configure. The traffic storm control level is a percentage of the total available bandwidth of the port. Each port has a single traffic storm control level that is used for all types of traffic (broadcast, multicast, and unicast).

Note •The router supports multicast and unicast traffic storm control only on Gigabit Ethernet LAN ports.

•The router supports broadcast traffic storm control on all LAN ports.

•Traffic storm control does not suppress spanning tree packets. Except for spanning tree packets, traffic storm control does not differentiate between control traffic and data traffic.

Traffic storm control monitors the level of each traffic type for which you enable traffic storm control in 1-second traffic storm control intervals. Within an interval, when the ingress traffic for which traffic storm control is enabled reaches the traffic storm control level that is configured on the port, traffic storm control drops the traffic until the traffic storm control interval ends.

Juniper has similar UUFB and UUFRL, but it also has a feature which allows a VLAN to forward all unknown unicast frames to a specific port (trunk), and each VLAN can use a different port in order avoid overloading a particular trunk: Understanding Unknown Unicast Forwarding

To prevent a storm, you can disable the flooding of unknown unicast packets to all VLAN interfaces by configuring one VLAN or all VLANs to forward all unknown unicast traffic to a specific interface. This channels the unknown unicast traffic to a single interface.

Related Solutions

Cisco – Is ‘switchport protected’ supposed to block unicast flooding

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

Cisco: storm-control unicast

So does storm-control unicast only measure the pps rate (or bps rate) of frames that are for destinations not in the CAM tables, or all destinations that aren't a broadcast or multicast address (so just the total number of unicast frames)?

I have to confess that I mistakenly trusted the Nexus doc below which said only unknown unicast is rate-limited; however, that's definitely wrong for Cisco IOS. The reality is (at least on IOS platforms) that unicast storm control affects all unicast traffic; the Cisco Nexus doc I quoted said it only affected traffic that was unknown unicast. I will endeavor to test on Nexus at a later date.

In an effort to atone for my mistake, I built a quick screencast of what happens when I:

Configure a Cisco IOS switch with unicast storm-control to throttle at 1Mbps.
Use speedtest_cli.py to start a unicast download from speedtest.net
Reconfigure the switch without unicast storm control
Download from speedtest.net again...

Hit your refresh button to restart the screencast at the beginning

storm-control screencast

Bottom line

Unicast storm-control affects all unicast traffic in Cisco IOS
Unicast storm-control is applied on traffic inbound to the switchport

My Original quote from the Nexus docs, which I applied to the OP's Cisco 2960

~~Quoting the Nexus Storm Control Docs (emphasis mine):~~

~~"You can use the traffic storm control feature to prevent disruptions on Layer 2 ports by a broadcast, multicast, or unknown unicast traffic storm on physical interfaces. "~~

Storm control operates the same way across Cisco platforms; if the destination-mac-address is not in the CAM table, then then the switch must flood it out all ports in the Vlan (except the one it came in on). Suffient quantities of this kind of traffic would trigger your Unicast Storm Control thresholds.