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.