Unicast flooding
It refers to the unintentional behavior of a switch treating a unicast
packet as a broadcast packet; The cause of flooding is that the destination MAC
address of the packet is not in the L2 forwarding table of the switch. Normally
occurs when the router needs to deliver a packet; it has an ARP entry for a
destination host, but the switch has no CAM entry. The result is a packet that needs to be
flooded to all of the ports in the VLAN In order to locate that MAC address
port/VLAN.
Common reasons for destination MAC address not being known to the switch:
Cause 1: Asymmetric Routing.
With asymmetric routing, transmit and receive packets follow different
paths between a host and the peer with which it communicates, at some point in
the packet delivery path a Switch may not have that MAC address destination on
its CAM table and would need to flood the frame in order to discover which
port/MAC address is.
Cause 2: Spanning-Tree Protocol Topology Changes.
Since TCNs are triggered by a port that is transitioning to or from the
forwarding state we may remember that what TCN does is to age out the CAM table
in order to relearn the Active MAC address,
A final cause of unicast floods are topology changes. When a link state
changes on a network port which participates in rapid spanning tree, the
address cache on that switch will be flushed causing all subsequent packets to be
flooded out of all ports until the addresses are learned by the switch.
Cause 3: Forwarding Table Overflow.
Another possible cause of flooding can be overflow of the switch forwarding
table. In this case, new addresses cannot be learned and packets destined to
such addresses are flooded until some space becomes available in the forwarding
table. New addresses will then be learned. This is possible but rare,
A switch that has no room left in its address cache will flood the packet
out to all ports. This is a common problem on networks with many hosts. Less
common is the artificial flooding of address tables—this is termed MAC
flooding.
Another common cause are hosts with ARP timers longer than the address
cache timeout on switches—the switch forgets which port connects to the host.
Remedies -
There are several remedies discussed in the links above. But for many situations, a low end switch
needs to be replaced with a higher end switch—one that has a larger address
table and one that can block unicast floods. Blocking unicast floods on a Cisco
switch is easy to do, but it is not enabled by default. After ensuring that
timeouts and/or security features have been configured to maintain table
entries on client access ports longer than typical host ARP cache timeouts,
this command is used to quiet down the unicast floods on those ports
By default unknown unicast traffic is flooded to all Layer 2 ports in a
Vlan. We can use UUFB and UMFB, features to prevent or limit this traffic.
The UUFB [unknown unicast flooding blocking] and UMFB [unknown multicast flooding blocking ] 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.
Router(config-if)# switchport
--> Configures the port for Layer 2 switching.
Router(config-if)# switchport block {unicast | multicast} -->Enables
unknown unicast or multicast flood blocking on the port.
Note: Enter the switchport block multicast command only on ports where all
unknown multicast flooded traffic needs to be completely blocked. UMFB disrupts
protocols that make use of local subnetwork multicast control groups in the
224.0.0.0/24 range, for example:
•ARP
•IPv6 neighbor discovery (IPv6 ND)
•Network Time Protocol (NTP)
Do not enter this command on nonreceiver (router) ports or host ports that
rely on dynamic ARP. Use IGMP snooping or other rate-limiting options to
restrict, rather than completely block, unknown multicast flooded traffic.
Other techniques involve isolating hosts at Layer 2, which blocks intra-LAN
communication not destined to the router. A handy tool (available in lower end
switches ) is the
Switch(config-if)# switchport protected
or a more robust, cross-switch solution than 'switchport protected' is the
use of Private VLANs.
Related topics-
Comments
Post a Comment