Blocking Unknown Unicast Flooding

@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...

Paulo,

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.

Regards, Fredrik

@Paulo:

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.

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?

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.

Setttler -

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.

2JMILLERMO

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?

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

thankx

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.

Hi,

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?

Thanks,
Ionut

Hi,

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?

Regards,

Wei Kee

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.

Paul

Hi Paul,

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

1. Host C connect to the Switch on a Unicast Blocked Port, ARP Requests, First MAC Adress Register - OK
2. Host send Traffic, MAC Adress exists in the Table - OK

but...

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 ?

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.