In computer networking, a unicast flood is when a switch receives a unicast frame and treats it as a broadcast frame, flooding the frame to all other ports on the switch.

Background
The term unicast refers to a one-to-one transmission from one point in the network to another point.  Conventionally, unicast is considered more secure because the frame is delivered solely to the intended recipient and not to multiple hosts.  This diagram illustrates the unicast transmission of a frame from one network host to another:

When a switch receives a unicast frame with a destination address not in the switch’s forwarding table, the frame is treated like a broadcast frame and sent to all hosts on a network:

Causes
The learning process of transparent bridging requires that the switch receive a frame from a device before unicast frames can be forwarded to it. Before any such transmission is received, unicast flooding is used to assure transmissions reach their intended destination. This is normally a short-lived condition as receipt typically produces a response that completes the learning process. The process occurs when a device is initially connected to a network, or is purged from the forwarding information base.  An entry is purged when the device is moved from one port to another (causing the link status to change on the original port) or after a MAC table entry expires due to inactivity (5 minutes is the default on Cisco switches).

A switch that has no room left in its address cache will flood the frame 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.  The solution to prevent this is to have the switch configured with a MAC address timeout longer than the ARP timeout.  For example, set the MAC timeout to 360 seconds and the ARP timeout to 300 seconds.

Devices other than switches may create unicast floods as well.  A router which has a bridge interface but does not have the destination frame's address in the bridge cache will flood the frame out to all bridge members.

Misconfigured features of the networks may lead to unicast flooding as well.  If there are two layer 2 paths from Host A to B and Host A uses path 1 to talk to Host B, but Host B uses path 2 to respond to Host A, then intermediate switches on path 1 will never learn the destination MAC address of Host B and intermediate switches on path 2 will never learn the destination MAC address of Host A.

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 frames to be flooded out of all ports until the addresses are learned by the switch.

Remedies
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:
 Switch(config-if)# switchport block unicast

Other techniques involve isolating hosts at Layer 2, which blocks intra-LAN communication not destined to specific nodes providing a shared service (e.g. a router).  A handy tool for this are protected ports (ports which are forbidden to communicate with other protected ports), available in lower end switches:
 Switch(config-if)# switchport protected
A more robust, cross-switch solution than 'switchport protected' is the use of Private VLANs.

To block flooding on a Linux machine modern enough to have iproute2 installed, you can control the flooding in the devices bridge by running bridge link set dev phy6 flood off.  To set a MAC timeout larger than the ARP timeout, these commands can be issued:
 brctl setageing br0 330; echo 300 > /proc/sys/net/ipv4/neigh/br0/gc_stale_time

Most modern switches -- high and low end -- support flooding protection.l

Effects on Networks
When a network is experiencing unicast flooding, network performance is degraded.  Here is a graph of a bridge before and after adjusting the size of the bridge address cache:
 
80% of the frames were flooded out never to be received by the destination address, while 20% was valid traffic.  In high volume networks, the flooded traffic may cause ports to saturate and lead to packet loss and high latency.

Another side effect of exhausted address tables is the compromise of data.  The security considerations are discussed in the MAC flooding—one of several causes of unicast floods.  If an end user is running a packet sniffer, the flooded frames could be captured and viewed.

See also
 Broadcast, unknown-unicast and multicast traffic

References

Internet architecture
컴퓨터 네트워킹에서 유니캐스트 플러드(unicast flood)는 스위치가 유니캐스트 프레임을 수신하고 이를 브로드캐스트 프레임으로 취급하여 스위치의 다른 모든 포트로 프레임을 플러딩하는 경우이다.

배경 
유니캐스트라는 용어는 네트워크의 한 지점에서 다른 지점으로의 일대일 전송을 의미한다. 일반적으로 유니캐스트는 프레임이 여러 호스트가 아닌 의도된 수신자에게만 전달되기 때문에 더 안전한 것으로 간주된다. 이 다이어그램은 한 네트워크 호스트에서 다른 호스트로의 프레임 유니캐스트 전송을 보여준다.

스위치가 스위치의 포워딩 테이블에 없는 대상 주소가 있는 유니캐스트 프레임을 수신하면 프레임은 브로드캐스트 프레임처럼 취급되어 네트워크의 모든 호스트로 전송된다.

원인 
트랜스패어런트 브리징의 러닝 프로세스에서는 유니캐스트 프레임이 장치로 전달되기 전에 스위치가 장치에서 프레임을 수신해야 한다. 이러한 전송이 수신되기 전에 유니캐스트 플러딩은 전송이 의도한 대상에 도달하도록 보장하는데 사용된다. 일반적으로 수신 측은 러닝 과정을 완료하는 응답을 생성하므로 일반적으로 짧은 라이프 타임을 갖는다. 이 프로세스는 장치가 처음에 네트워크에 연결되거나 한 포트에서 다른 포트로 이동 될 때 또는 장치가 일반적으로 전달 테이블에서 제거 될 때 5분 동안 활동이 없을 때 발생한다.

주소 캐시에 공간이 없는 스위치는 프레임을 모든 포트로 흘려보낸다. 이것은 호스트가 많은 네트워크에서 흔히 발생하는 문제이고, 주소 테이블의 인위적인 플러딩은 덜 일반적이며 MAC 플러딩 이라고 한다.

또 다른 일반적인 원인은 호스트의 ARP 타이머가 스위치의 주소 캐시 보관 시간 보다 긴 경우로, 스위치는 호스트에 연결된 포트의 MAC 주소를 알 수 없게 된다.

스위치 이외의 장치도 유니캐스트 플러드를 생성할 수 있다. 브리지 인터페이스가 있지만 브리지 캐시에 대상 프레임의 주소가 없는 라우터는 프레임을 모든 브리지 구성원으로 흘려보낸다.

네트워크의 기능이 잘못 구성되면 유니캐스트 플러딩이 발생할 수도 있다. 호스트 A에서 B 로의 2 개의 레이어 2 경로가 있고 호스트 A가 경로 1을 사용하여 호스트 B와 통신하지만 호스트 B가 경로 2를 사용하여 호스트 A에 응답하는 경우 경로 1의 중간 스위치는 대상 MAC 주소를 인식하지 못한다. 경로 2의 호스트 B와 중간 스위치는 호스트 A의 대상 MAC 주소를 인식하지 못한다.

마지막 유니캐스트 플러드의 원인으로 토폴로지 변경이 있을 수 있이다. 신속한 스패닝 트리에 참여하는 네트워크 포트에서 링크 상태가 변경되면 해당 스위치의 주소 캐시가 플러시되어 스위치가 주소를 학습할 때까지 모든 후속 프레임이 모든 포트로 흐른다.

해결 
위의 링크에서 논의된 몇 가지 해결 방법이 있다.    그러나 많은 상황에서 로우 엔드 스위치는, 더 큰 주소 테이블을 가지고 있고 유니 캐스트 플러드를 차단할 수 있는 하이 엔드 스위치로 교체해야 한다. Cisco 스위치에서 유니 캐스트 플러드를 차단하는 것은 쉽지만 기본적으로 활성화되어 있지 않다. 일반적인 호스트 ARP 캐시 시간 초과보다 오래 클라이언트 액세스 포트에서 테이블 항목을 유지하도록 시간 초과 및 / 또는 보안 기능이 구성되었는지 확인한 후 이 명령을 사용하여 해당 포트에서 유니캐스트 플러드를 차단한다.
 Switch (config-if) # switchport block unicast
다른 방법으로는 계층 2에서 호스트를 격리하는 것이 포함하며, 이는 라우터로 향하지 않는 내부 LAN 통신을 차단한다.

편리한 도구(로우 엔드 스위치)는
 Switch (config-if) # switchport protected
또는 'switchport protected'보다 더 강력한 교차 스위치 솔루션은 사설 VLAN을 사용하는 것이다.

네트워크에 미치는 영향 
네트워크에 유니 캐스트 플러딩이 발생하면 네트워크 성능이 저하된다. 다음은 브리지 주소 캐시의 크기를 조정하기 전후의 브리지 그래프이다.

20%의 프레임만 유효하게 전달 되고 프레임의 80 %가 플러드 아웃되어 목적지 주소로 수신되지 않는다(첫 번째 참조 이미지). 대용량 네트워크에서는 플러드된 트래픽으로 인해 포트가 포화 상태가되어 패킷 손실과 높은 대기 시간이 발생할 수 있다.

소진된 주소 테이블의 또 다른 부작용은 데이터 손실이다. 보안 고려 사항은 유니캐스트 플러드의 여러 원인 중 하나인 MAC 플러딩에서 설명한다. 최종 사용자가 패킷 스니퍼를 실행하는 경우 플러드 된 프레임을 캡처하고 볼 수 있다.

참고 문헌 

인터넷 구조