Blocking Unknown Unicast Flooding
By stretch | Friday, June 4, 2010 at 2:55 a.m. UTC
When an Ethernet switch receives a frame destined for a MAC address not in its address table, the default behavior is to flood the frame out all other ports as though it was a broadcast. Only after learning of the address as the source of an incoming frame will it be entered into the address table with its corresponding port, allowing future frames destined for this address to be forwarded normally as unicasts.
This is done to ensure that a quiet host (one which has not sent any traffic within the address table aging period) will receive frames destined for it. However, this may not be the desired behavior, particularly on highly secured networks. There is a feature on Cisco Catalyst switches known as port blocking which can be employed to alter this default behavior. An administrator can enable unicast and/or multicast blocking on a switch port to suppress the flooding of frames destined for an unknown unicast or multicast MAC address out of that port. A simple one-line configuration is required for each type of destination address:
Switch(config-if)# switchport block unicast Switch(config-if)# switchport block multicast
One might wonder whether multicast blocking interferes or interacts somehow with IGMP snooping. The Catalyst 3560 configuration guide notes:
Only pure Layer 2 multicast traffic is blocked. Multicast packets that contain IPv4 or IPv6 information in the header are not blocked.
A few quick tests further verify that IPv4 multicast traffic was not blocked either with or without IGMP snooping enabled.
Posted in Switching
June 4, 2010 at 3:06 a.m. UTC
Good explanation Stretch! :)
June 4, 2010 at 3:57 a.m. UTC
If unicast queries are blocked, what will happen then when a valid host connects to the switch or another switch in the same LAN? would not he be able to receive any type of unicast frames? I don't catch the meaning of the block unicast command.
June 4, 2010 at 6:20 a.m. UTC
@Paulo Colomés : The unicast blocking features blocks only "silent" hosts. As soon as an active host send traffic on the network, the switches learn the MAC@ of the host and populates its forwarding table. This way, 2 active hosts have no problem to exchange.
I wonder also if the multicast blocking feature can be used in replacement of RGMP ?(kind of IGMP for the routers !). I experiment some multicast flooding on switches that connect many routers, but the RGMP feature isn't available...
June 4, 2010 at 8:15 a.m. UTC
The same basic Ethernet principle applies. If the host moved switches and stay completely quiet, i.e. don't send a single frame traffic will not know that the host has moved and can't reach that host.
However given the "chatty nature" of Windows and other operating systems, it is almost guaranteed that the host will send a broadcast and thus notifying the switches in that Vlan, who then updates their mac-address table to reflect that the host has moved port. Port Blocking rarely causes problems in "normal networks" but as usual you want to test this in your specific network first.
June 4, 2010 at 8:35 a.m. UTC
Assume that the switchport to Host B (= Port 2) has the command "switchport block unicast" configured on it.
Now when an Ethernet frame comes in from Host A (= Port 1) with an unknown Destination MAC Address, it now only floods it to Host C and Host D.
June 4, 2010 at 12:33 p.m. UTC
Thank you for a great article (as usual), but I'm missing one thing. If we block unicast do we have to configure a static entry in address-table or with blocking the unicast will also turn off the aging period?
...or how else will the switch learn MAC address of a new device that is not in address table?
June 4, 2010 at 12:42 p.m. UTC
As soon as the host initiate some traffic the switch will learn the host's MAC address. Before this, the host will not receive any unicast traffic.
On a new network, all hosts will start sending ARP requests so the switch will start learning all of the MAC address.
June 4, 2010 at 12:51 p.m. UTC
Normally when a switch receives a frame with an unknown unicast MAC address it will flood it out every port. This is done to make sure that the host receives the frame. This command only tells the switch "do not flood that frame out this port". It doesn't block the learning of MAC addresses so as soon as a host on that port sends a frame his MAC will get added to the CAM as normal. Any further frames destined for that host's MAC will be sent out that port as normal.
June 4, 2010 at 1:09 p.m. UTC
THNX 4 reply...you've entered the same issue I was trying to address (I didn't include all the details so it's my fault)...let's see the scenario I've had in mind.
In the first step you connect a new device to the port with "switchport block unicast" and the device (let's say server) isn't sending any frames - the switch doesn't learn its MAC. In the next step you want to contact that server - but since it's not int he address table and learning is also blocked and you want to prevent this situation, how do you do that?
June 4, 2010 at 3:16 p.m. UTC
Settler, I think the assumption is that usually a server is very chatty to begin with so this never really becomes a problem.
June 4, 2010 at 3:53 p.m. UTC
When would be a good time not to implement this configuration?
June 5, 2010 at 9:41 a.m. UTC
what happend if switch reload ? how the switch learning behavior will work , that is this option will work after complete learning , if yes ? how could new hosts added to switch
June 6, 2010 at 6:29 p.m. UTC
This is a good feature to use when setting up protected ports on your LAN.
interface range FastEthernet 0/30 - 39 switchport mode access switchport protected switchport block unicast switchport block multicast
I recently posted an "Introduction to Private VLANS" on my blog that covered this.
June 6, 2010 at 8:30 p.m. UTC
You write: "When an Ethernet switch receives a frame destined for a MAC address not in its address table, the default behavior is to flood the frame out all other ports as though it was a broadcast." Isn't it the case that the frame is broadcasted only along the spanning tree?
June 6, 2010 at 8:33 p.m. UTC
@RG: Of course. It's also only broadcast out only interfaces in the same VLAN, and only interfaces in an up state. This is all implied when we talk about Ethernet switching.
June 7, 2010 at 6:03 p.m. UTC
Does this affect DHCP discovery and offer traffic?
June 9, 2010 at 3:27 p.m. UTC
I wonder what happens if you have blocked unicast forwarding on all your switch ports, the CAM memory is full and your switch is still receiving frames...Those last frames will probably be dropped. Am I making a correct assumption here?
June 10, 2010 at 8:57 a.m. UTC
every change in STP will cause packet drop, because switches along new root path won't know MAC addresses which are not connected directly to them. Ok, STP change is not a good thing, but it is something you should be aware of.
June 11, 2010 at 7:25 a.m. UTC
If i got this correct. Assume there is one workstation (assume Host A) that is really "silent", other host will not be able contact this machine once the MAC table in the switch are purged.
Will Wake On Lan be a problem when we block this flooding?
June 1, 2011 at 9:29 a.m. UTC
Wei kei, wake on lan is a known broadcast address, not an unkown unicast address, so it shouldnt.
September 22, 2011 at 6:55 p.m. UTC
Jeremy, your posts are coming in quite handy these days!
When you say "When an Ethernet switch receives a frame destined for a MAC address not in its address table, the default behavior is to flood the frame out all other ports", don't you mean "out all other ports in its configured vlan?"
I have been trying to clear up a debate we have been having at work...
Unknown unicast frames are broadcast out all ports in their vlan, not all ports in the entire switch, right?! By all ports, I also mean trunk links that allow that vlan.
It has also been suggested that these are flooded out the native vlan as well, so any ports that are not configured for a vlan.
May 5, 2012 at 4:28 p.m. UTC
A vlan represents basically a broadcast domain
Consequently, a broadcast would be sent only to ports in the same vlan, not on the ports of another vlan
May 11, 2012 at 9:58 p.m. UTC
- Host C connect to the Switch on a Unicast Blocked Port, ARP Requests, First MAC Adress Register - OK
- Host send Traffic, MAC Adress exists in the Table - OK
After 300 Seconds the MAC Adress automaticly from the CAM Table.
What happens with a new Session After 301 Seconds and in this case without a new MAC Registration over an ARP Request or other Communication ?
May 23, 2012 at 12:21 a.m. UTC
In answer to many of the above questions, usually you do not want to turn on "switchport block unicast" unless you are also turning on port-security learning or a dot1x feature that will keep MAC addresses in the CAM longer than a normal timeout, or you are adjusting the CAM timeout such that it is longer than the ARP cache timeout of hosts on the network (including the router.)
However, if you do it on a chatty host, you may very well never notice the occasional dropped packet, if you even drop any.
November 26, 2014 at 2:38 a.m. UTC
I was searching for an explanation of specifics on unknown uni-cast frame forwarding. I now know WHAT it is... specifically, a broadcast. Even an explanation WHY this is logical. I do not want to confuse anyone on the Why's that I had, so I spare you all...
March 2, 2015 at 10:52 p.m. UTC
Configure Mac address timeout to match dhcp leasetime in a dhcp network. That will always keep the switch aware of the mac behind the port.