交換式園區網路中的單播泛洪
簡介
本文討論交換式網路中單點傳播封包泛洪的可能原因和影響。
必要條件
需求
本文件沒有特定需求。
採用元件
本文件所述內容不限於特定軟體和硬體版本。
慣例
如需文件慣例的詳細資訊，請參閱思科技術提示慣例。
問題定義
LAN交換機使用轉發表(第2層(L2)表、內容可定址儲存器(CAM)表)根據幀的VLAN編號和目的MAC地址將流量定向到特定埠。當傳入VLAN中沒有與幀的目的MAC地址對應的條目時，（單播）幀將傳送到相應VLAN中的所有轉發埠，從而導致泛洪。
有限泛洪是正常交換過程的一部分。但是，在某些情況下，持續泛洪可能會對網路效能造成負面影響。本文檔說明泛洪可能會引起什麼問題，以及某些流量可能持續泛洪的最常見原因。
請注意，大多數現代交換機（包括Catalyst 2900 XL、3500 XL、2940、2950、2970、3550、3750、4500/4000、5000和6500/6000系列交換機）在每個VLAN上維護L2轉發表。
泛洪的原因
泛洪的根本原因是資料包的目的MAC地址不在交換機的L2轉發表中。在這種情況下，資料包將從其VLAN中的所有轉發埠泛洪出去（接收該資料包的埠除外）。下面的案例分析顯示了交換機不知道目的MAC地址的最常見原因。
原因1：非對稱路由
大量泛洪流量可能會使低頻寬鏈路飽和，從而導致網路效能問題或連線此類低頻寬鏈路的裝置的連線完全中斷。請看下圖：
在上圖中，VLAN 1中的伺服器S1正在向VLAN 2中的伺服器S2運行備份（批次資料傳輸）。伺服器S1的預設網關指向路由器A的VLAN 1介面。伺服器S2的預設網關指向路由器B的VLAN 2介面。從S1到S2的資料包將遵循以下路徑：
-
S1 - VLAN 1 -交換機A -路由器A - VLAN 2 -交換機B - VLAN 2 - S2（藍線）
從S2到S1的資料包沿以下路徑傳輸：
-
S2—VLAN 2—交換機B—路由器B—VLAN 1—交換機A—泛洪到VLAN 1—S1（紅線）
請注意，透過這種配置，交換器A不會在VLAN 2中「看到」來自S2 MAC位址的流量（因為來源MAC位址將由路由器B重新寫入，且封包只會到達VLAN 1）。這意味著每次交換機A需要將資料包傳送到S2 MAC地址時，資料包都會泛洪到VLAN 2。交換機B上的S1 MAC地址也會發生同樣的情況。
此行為稱為非對稱路由。資料包遵循不同的路徑，具體取決於方向。非對稱路由是泛洪的兩個最常見原因之一。
單播泛洪的影響
返回上述示例，結果是S1和S2之間的資料傳輸資料包將主要泛洪到交換機A上的VLAN 2和交換機B上的VLAN 1。這表示交換器B上VLAN 1中的每個連線連線埠（在本範例中為工作站W），都會接收S1和S2之間的所有封包交談。假設伺服器備份需要50 Mbps的頻寬。此流量量將使10 Mbps鏈路飽和。這將導致與PC的完全連線中斷，或大大降低其速度。
這種泛洪是由於非對稱路由引起的，當伺服器S1傳送廣播資料包(例如地址解析協定(ARP))時可能會停止。交換機A將此資料包泛洪到VLAN 1，交換機B將接收並獲取S1的MAC地址。由於交換機不會經常接收流量，因此該轉發條目最終會老化，從而恢復泛洪。同樣的過程也適用於S2。
有多種方法可以限制非對稱路由引起的泛洪。請參閱以下文件以瞭解更多資訊：
通常的方法是使路由器的ARP超時和交換機的轉發表老化時間彼此接近。這將導致ARP資料包被廣播。重新學習必須在L2轉發表條目老化之前進行。
可能會發生此類問題的典型案例是當有備援第3層(L3)交換器(例如具有多層交換器功能卡(MSFC)的Catalyst 6000)設定為使用熱待命路由器通訊協定(HSRP)進行負載平衡時。在這種情況下，一台交換機對於偶數VLAN是活動的，另一台則對於奇數VLAN是活動的。
原因2：生成樹協定拓撲更改
泛洪引起的另一個常見問題是生成樹協定(STP)拓撲更改通知(TCN)。TCN用於在轉發拓撲更改後更正轉發表。這是避免連線中斷所必需的，因為在拓撲更改後，以前透過特定埠可訪問的某些目標可能會透過不同的埠進行訪問。TCN透過縮短轉發表老化時間運行，因此如果不重新學習地址，地址將老化，並發生泛洪。
TCN由轉換到轉發狀態的埠觸發。在TCN之後，即使特定目的MAC地址已過期，由於將重新獲取地址，在大多數情況下也不會發生長時間泛洪。如果TCN以較短的間隔重複發生，則可能會發生此問題。交換器會不斷快速老化轉送表，因此泛洪幾乎會一直持續。
通常，TCN在配置良好的網路中非常少見。當交換機上的埠接通或斷開時，一旦埠的STP狀態變為轉發或從轉發變為轉發，最終就會出現TCN。當連線埠抖動時，會發生重複的TCN和泛洪。
啟用了STP portfast功能的埠在進入或離開轉發狀態時不會導致TCN。在所有終端裝置埠（如印表機、PC、伺服器等）上配置portfast應將TCN限制在低數量。如需TCN的詳細資訊，請參閱本檔案：
注意：在MSFC IOS中，存在一種最佳化，當各個VLAN中存在TCN時，該最佳化將觸發VLAN介面重新填充其ARP表。這可以限制發生TCN時的泛洪，因為會出現ARP廣播，並且主機在回覆ARP時會重新獲知主機MAC地址。
原因3：轉發表溢位
泛洪的另一個可能原因是交換機轉發表溢位。在這種情況下，無法獲知新地址，發往這些地址的資料包將被泛洪，直到轉發表中有一些空間可用。然後，將學習新的地址。這是有可能的，但非常罕見，因為大多數現代交換機都有足夠大的轉發表，可以容納大多數設計的MAC地址。
轉發表耗盡也可能是由於網路受到攻擊，一台主機開始生成每個來自不同MAC地址的幀。這將佔用所有轉發表資源。一旦轉發表飽和，其他流量將會泛洪，因為新的學習無法進行。透過檢查交換機轉發表可以檢測到此類攻擊。大多數MAC地址將指向同一埠或埠組。透過使用埠安全功能，可以限制在不可信埠上獲知的MAC地址的數量，從而防止此類攻擊。
執行Cisco IOS®或CatOS軟體的Catalyst交換器組態指南包含稱為設定連線埠安全或設定連線埠型流量控制的章節。有關詳細資訊，請參閱Cisco交換機產品頁上交換機的技術文檔。
註：如果為埠安全配置的交換機埠發生單播泛洪，且條件為「Restrict」以阻止泛洪，則會觸發安全違規。
Router(config-if)#switchport port-security violation restrict
注意：發生這種安全違規時，設定為「restrict」模式的受影響連線埠應捨棄來源位址不明的封包，直到您移除足夠數量的安全MAC位址，捨棄到低於最大值為止。這會導致SecurityViolation計數器增加。
注意：如果交換器連線埠變成「關閉」狀態，而不是發生此行為，您需要設定Router(config-if)#switchport block unicast，以便停用特定交換器連線埠進行單點傳播泛濫。
如何檢測過度泛洪
大多數交換機未實施特殊命令來檢測泛洪。運行Cisco IOS系統軟體（本地）版本12.1(14)E和更高版本或Cisco CatOS系統軟體7.5或更高版本的Catalyst 6500/6000 Supervisor引擎2和更高系列的交換機實現了「單播泛濫保護」功能。簡而言之，此功能允許交換器監控每個VLAN的單點傳播泛洪量，並在泛洪超過指定量時採取指定動作。操作可以是syslog、限制或關閉VLAN -系統日誌對於泛洪檢測最有用。當泛洪超出配置的速率且配置的操作為syslog時，將列印類似於以下內容的消息：
%UNICAST_FLOOD-4-DETECTED: Host 0000.0000.2100 on vlan 1 is flooding to an unknown unicast destination at a rate greater than/equal to 1 Kfps
指示的MAC地址是此交換機上資料包泛洪的源MAC。通常需要知道交換機正在泛洪到的目標MAC地址（因為交換機透過檢視目標MAC地址進行轉發）。適用於Catalyst 6500/6000 Supervisor Engine 2及更高版本的Cisco IOS （原生）版本12.1(20)E將實作顯示發生泛洪的MAC位址的功能：
cat6000#sh mac-address-table unicast-flood
Unicast Flood Protection status: enabled
Configuration:
vlan Kfps action timeout
------+----------+-----------------+----------
55 1 alert none
Mac filters:
No. vlan souce mac addr. installed on time left (mm:ss)
-----+------+-----------------+------------------------------+------------------
Flood details:
Vlan souce mac addr. destination mac addr.
------+----------------+-------------------------------------------------
55 0000.2222.0000 0000.1111.0029, 0000.1111.0040, 0000.1111.0063
0000.1111.0018, 0000.1111.0090, 0000.1111.0046
0000.1111.006d
然後，可以執行進一步調查，以檢視MAC地址0000.2222.0000是否應該將流量傳送到目標MAC地址部分列出的MAC地址。如果流量是合法的，則需要確定交換機不知道目的MAC地址的原因。
透過捕獲在減速或中斷期間在工作站上看到的資料包蹤跡，可以檢測是否發生泛洪。通常，埠上不應重複出現不涉及工作站的單播資料包。如果發生這種情況，就有可能發生洪災。當出現各種泛洪原因時，資料包蹤跡可能看起來不同。
使用非對稱路由時，可能會有封包傳送到特定的MAC位址，但即使在目的地回覆之後也不會停止泛洪。使用TCN時，泛洪將包括許多不同的地址，但最終應停止然後重新啟動。
隨著L2轉發表溢位，您可能會看到與非對稱路由相同的泛洪。不同之處在於，可能會有大量的異常資料包，或者有不同源MAC地址的正常資料包數量異常。
相關資訊
意見