作者：游子興 / 臺灣大學計算機及資訊網路中心資訊網路組資深專員
Unknown Unicast Flood在網路世界中其實一直存在，也是網管人員需要特別關注與瞭解的議題，本文先透過原理的說明與實際設備之測試，瞭解Unknown Unicast Flood發生的全貌與可能造成的影響。
Broadcast/Multicast/Unicast
封包之傳輸型態可分為三種類型，Broadcast廣播、Multicast群播、Unicast單播。個別之傳輸方式可參考圖1。
圖1. https://vectormine.com/item/unicast-broadcast-and-multicast-file-sharing-differences-outline-diagram/
Switch vs. Hub
Switch網路交換器與舊式Hub之差異，在於Switch會隨時監聽每個介面進過之封包，並維護一份介面與網路實體位址(Mac Address Table)對應之表格如圖2。當有封包需要轉送時，可依據封包之目的網路實體位址，參考Mac Address Table後轉送至對應之介面即可。而傳統之Hub設備因為無此表格可參考，因此封包之傳遞需要轉送至所有介面，將可能造成封包碰撞後傳輸效能較低及安全隱私問題。
圖2
Unknown Unicast Flood發生原因
使用Switch網路交換器時，當發生需轉送之封包目的網路實體位址，經查詢”介面與網路實體位址(Mac Address Table)對應之表格”卻不存在時，此時就發生Unknown Unicast Flood，封包將如同Hub設備運作一般轉送至所有介面。
至於為何會發生此種情況？那又需要介紹在路由器設備之閘道Gateway有另一個表格稱為ARP Table如圖3。這個表格在記錄IP位址與Mac Address之對應關係。
圖3
發生原因1：“ARP Table” vs. “MAC addr Table” Timeout時間不同
在Cisco網路設備之預設值中，Mac Address Table記錄Timeout為5分鐘，ARP Table記錄Timeout卻可維持4小時，也就是當一台連網設備關機離線5分鐘後，Mac Address Table已經無此筆記錄存在，但ARP Table記錄卻仍可繼續維持3小時55分，此時若有封包之目的位址需轉送至此設備，即會發生L3 Gateway收下此封包後，造成L2 Switch發生Unknown Unicast Flood之情況。
發生原因2：Spanning-tree Topology Change(TC)
這個情況發生的起因比較複雜，原因在於有加入Spanning-tree之網路設備中，當任一個Switch交換器之任一個介面發生Up/Down時，Root Bridge會發送 Spanning-tree Topology Change(TC)通知所有Spanning-tree成員，此時收到此通知之Switch必須在15秒內清空“MAC addrs Table”，因此在一個Layer2環境內只要有任一個設備開關機，都可能隨時導致“MAC addrs Table”被清空而發生Unknown Unicast Flood之情況。
發生原因3：IP-MAC Binding
還有另一種情況，就是有些網管為了管控IP之使用，避免IP被盜用，會綁定IP與對應合法設備之Mac Address，一般稱為IP-MAC Binding，此筆記錄在 ARP Table上永遠存在不會消失，此時只要該設備不在線上，就會發生Unknown Unicast Flood，會造成網路容易遭受異常封包之攻擊。
Unknown Unicast Flood 後續衍生現象
當有Unknown Unicast Flood發生時，在相同Layer2環境下之所有設備皆會收聽到此目的MAC address非自己的封包，正常設備會直接丟棄，除非在封包側錄模式Promiscuous Mode下，才會將此封包收進系統並存檔。
經實際測試發現有部分網路設備、無線AP或作業系統，在某些情況下會將目的 MAC address非自己的封包收進來並進行處理，如此將衍生三種狀況：
1.IP-MAC Binding失效
2.無線AP收到封包目的IP同網段：發出ARP request (Broadcast)，Timeout後回覆ICMP Host Unreachable to Src IP。
3.無線AP收到封包目的IP不同網段：送給Default Gateway(Unicast)，Gateway再次進行Routing(Unknown Unicast Flooding)，反覆進行至TTL=0(Route Loop)後回覆ICMP TTL expired (Type:11 Code:0) to Src IP。
本文因為篇幅之關係，僅先介紹第一種”IP-MAC Binding失效”，另兩種留待之後文章再詳述。
IP-MAC Binding失效
目前發現造成IP-MAC Binding失效，有下列三種情況：
1.網卡@Promiscuous Mode
2.網路設備允許多個合法MAC addrs
3.IP分享器/無線AP Bug
- IP-MAC Binding 失效：網卡@Promiscuous Mode
經測試作業系統Windows、FreeBSD，當網卡於封包側錄模式Promiscuous Mode 時，IP-MAC Binding 將失效無作用，並與防火牆是否開啟無關。目前發現如下之作業系統與對應之版本皆有此現象：
Windows 7、Windows 10、Windows 11
FreeBSD v12.2 v13.2
補充測試時需使用的指令如下：
Linux/FreeBSD如何進入Enter Promiscuous Mode：
ifconfig <網卡> promisc
圖4
Linux/FreeBSD如何Leave Promiscuous Mode：
ifconfig <網卡> -promisc
圖5
- IP-MAC Binding失效：網路設備允許多個合法MAC addrs (Cisco 網路設備)
經實際測試Cisco Catalyst 2960、Cisco Catalyst 3750 系列，可允許收下與目前實際使用介面MAC address不同之封包，但並非所有MAC address皆允許，而是允許一段有限範圍之 MAC address，此情況實測時也將設備韌體Firmware升級至最終版，仍然有相同之現象，可說明此現象並非系統Bug造成，而是系統預設之行為。
以下詳述Cisco網路設備允許之MAC address範圍起迄，Cisco Catalyst 2960/3750在每個實體介面都有一個預先保留之MAC Addr網卡位址，如下圖6
圖6
經實際測試，於路由器Gateway綁定ARP之MAC Address允許範圍介於081f.f376.dc00 ~ dc40之間，也就是第一個實體介面至Vlan 1之網卡位址。
總數：16 x 4 + 1 = 65
測試於Gateway 綁定並未接線之Fa0/1介面網卡位址，ARP之設定語法如下：
(config)# arp 140.112.237.100 081f.f376.dc01 arpa
也就是當發生Gateway之ARP Table綁定之網卡位址與目前實際設定IP之Vlan網卡MAC Addr不同時，該Cisco設備仍然可正常連線至管理介面使用，包含ping、Telnet等功能。
另外測試Cisco新出的Catalyst 9300系列，則無此現象發生。
- IP-MAC Binding失效：網路設備允許多個合法MAC addrs (Mikrotik網路設備)
實測另一個廠牌之網路設備Mikrotik，測試型號：HEX S、RB450G，也有類似的情況，詳細說明如下。
設定bridge所包含的介面包含ether1 ~ 5，如圖7
圖7
其中Bridge所使用之MAC address與IP address，如圖8
圖8
依照官方文件所述，Mikrotik之Bridge使用之MAC address，預設為第一個加入之介面MAC address，如圖9
圖9
測時實際Uplink接線使用ether4，其MAC Address如下圖10
圖10
此時ARP Table @Gateway顯示正確學到之Bridge IP and MAC Address，如圖11
圖11
L2 Switch 有學到 MAC Address 來自 Te7/0/25，如圖12
圖12
此時測試在Gateway將IP-MAC Binding to ether4
(config)# arp 140.112.237.100 2cc8.1b70.e01c arpa
圖13
此時Ping 140.112.237.100仍可正常回應，進行封包側錄，結果發現Ping Request之Dst MAC與Reply之Src MAC不相同之特殊情況，如下圖14.
圖14
結論
Unknown Unicast Flood在網路世界中其實一直存在，也是網管人員需要特別關注與瞭解的議題，本文先透過原理的說明與實際設備之測試，瞭解Unknown Unicast Flood發生的全貌與可能造成的影響。