簡介
本文檔描述了Azure平台的一個已知問題,該問題導致由於處理亂序片段錯誤而導致資料包丟失。
症狀
受影響的產品:託管在Azure上的Catalyst 9800-CL無線控制器或託管在Azure上的身份服務引擎。
SSID設定:配置為使用中央身份驗證的802.1x EAP-TLS。
行為:在使用基於EAP-TLS的SSID的Azure平台上託管的9800-CL時,您可能會遇到連線問題。客戶端在身份驗證階段可能會遇到困難。
ISE伺服器出錯
錯誤代碼5411,指示請求方在EAP-TLS證書交換期間已停止與ISE的通訊。
詳細日誌分析:
以下是其中一個受影響配置的圖示:在9800無線控制器中,為802.1x設定SSID,並將AAA伺服器配置為EAP-TLS。當客戶端嘗試身份驗證時,特別是在證書交換階段,客戶端傳送超過無線控制器上最大傳輸單位(MTU)大小的證書。9800無線控制器接著將此大型封包分段,並將分段順序傳送到AAA伺服器。但是,這些片段未能以正確順序到達實體主機,因此導致封包捨棄。
以下是在使用者端嘗試連線時來自無線控制器的RA追蹤:
進入L2身份驗證狀態和EAP進程的客戶端已啟動
2023/04/12 16:51:27.606414 {wncd_x_R0-0}{1}:[dot1x] [19224]:(資訊):[Client_MAC:capwap_90000004]進入請求狀態
2023/04/12 16:51:27.606425 {wncd_x_R0-0}{1}:[dot1x] [19224]:(資訊):[0000.0000.0000:capwap_90000004]傳送EAPOL資料包
2023/04/12 16:51:27.606494 {wncd_x_R0-0}{1}:[dot1x] [19224]:(資訊):[Client_MAC:capwap_90000004]傳送的EAPOL資料包 — 版本:3,EAPOL型別:EAP,負載長度:1008,EAP-Type = EAP-TLS
2023/04/12 16:51:27.606496 {wncd_x_R0-0}{1}:[dot1x] [19224]:(資訊):[Client_MAC:capwap_90000004] EAP資料包 — 請求,ID:0x25
2023/04/12 16:51:27.606536 {wncd_x_R0-0}{1}:[dot1x] [19224]:(資訊):[Client_MAC:capwap_90000004] EAPOL資料包傳送到客戶端
2023/04/12 16:51:27.640768 {wncd_x_R0-0}{1}:[dot1x] [19224]:(資訊):[Client_MAC:capwap_90000004]收到的EAPOL資料包 — 版本:1,EAPOL型別:EAP,負載長度:6, EAP-Type = EAP-TLS
2023/04/12 16:51:27.640781 {wncd_x_R0-0}{1}:[dot1x] [19224]:(資訊):[Client_MAC:capwap_90000004] EAP資料包 — 響應,ID :0x25
當無線控制器向AAA伺服器傳送存取要求,且封包大小低於1500位元組(這是無線控制器上的預設MTU)時,會收到存取質詢,而不會出現任何複雜情況。
2023/04/12 16:51:27.641094 {wncd_x_R0-0}{1}:[radius] [19224]:(資訊):RADIUS:將訪問請求傳送到172.16.26.235:1812 id 0/6,len 552
2023/04/12 16:51:27.644693 {wncd_x_R0-0}{1}:[radius] [19224]:(資訊):RADIUS:接收自id 1812/6 172.16.26.235:0, Access-Challenge, len 1141
有時,客戶端可能會傳送其證書以進行身份驗證。如果封包大小超過MTU,會在進一步傳送之前將其分段。
2023/04/12 16:51:27.758366 {wncd_x_R0-0}{1}:[radius] [19224]:(資訊):RADIUS:傳送訪問請求到172.16.26.235:1812 id 0/8,len 2048
2023/04/12 16:51:37.761885 {wncd_x_R0-0}{1}:[radius] [19224]:(資訊):RADIUS:已啟動5秒超時
2023/04/12 16:51:42.762096 {wncd_x_R0-0}{1}:[radius] [19224]:(資訊):RADIUS:ID 0/8重新傳輸到(172.16.26.235:1812,1813)
2023/04/12 16:51:32.759255 {wncd_x_R0-0}{1}:[radius] [19224]:(資訊):RADIUS:ID 0/8重新傳輸到(172.16.26.235:1812,1813)
2023/04/12 16:51:32.760328 {wncd_x_R0-0}{1}:[radius] [19224]:(資訊):RADIUS:已啟動5秒超時
2023/04/12 16:51:37.760552 {wncd_x_R0-0}{1}:[radius] [19224]:(資訊):RADIUS:ID 0/8重新傳輸到(172.16.26.235:1812,1813)
2023/04/12 16:51:42.762096 {wncd_x_R0-0}{1}:[radius] [19224]:(資訊):RADIUS:ID 0/8重新傳輸到(172.16.26.235:1812,1813)
我們注意到封包大小為2048,超過預設MTU。因此,沒有來自AAA伺服器的響應。無線控制器將持續重新傳送訪問請求,直到達到最大重試次數。由於沒有響應,無線控制器將最終重置EAPOL進程。
2023/04/12 16:51:45.762890 {wncd_x_R0-0}{1}:[dot1x] [19224]:(資訊):[Client_MAC:capwap_90000004]在客戶端上發佈EAPOL_START
2023/04/12 16:51:45.762956 {wncd_x_R0-0}{1}:[dot1x] [19224]:(資訊):[Client_MAC:capwap_90000004]進入init狀態
2023/04/12 16:51:45.762965 {wncd_x_R0-0}{1}:[dot1x] [19224]:(資訊):[Client_MAC:capwap_90000004]在客戶端上發佈!AUTH_ABORT
2023/04/12 16:51:45.762969 {wncd_x_R0-0}{1}:[dot1x] [19224]:(資訊):[Client_MAC:capwap_90000004]進入重新啟動狀態
此程式處於循環中,並且客戶端僅停滯在身份驗證階段。
在無線控制器上捕獲的嵌入式資料包捕獲顯示,在與小於1500位元組的MTU進行多次訪問請求和質詢交換後,無線控制器將傳送一個大於1500位元組的訪問請求,該請求包含客戶端證書。此較大封包將進行分段。但是,沒有響應此特定訪問請求。無線控制器將繼續重新傳送此請求,直到達到最大重試次數,之後EAP-TLS會話將重新啟動。此事件序列不斷重複,表明客戶端嘗試進行身份驗證時出現EAP-TLS環路。請參閱下面提供的無線控制器和ISE的併發資料包捕獲,以瞭解更清楚的資訊。
無線控制器EPC:
WLC上的封包擷取
我們觀察到無線控制器正在傳送對特定訪問請求ID = 8的多個重複請求
附註:在EPC上,我們還注意到有一個對其他ID的重複請求。這就引出了一個問題:是否應該出現這種重複?對於這種重複是否應該出現,答案是肯定的。原因是在選擇了「Monitor Control Plane」選項的情況下,從無線控制器的GUI擷取擷取。因此,觀察幾個RADIUS封包的範例是正常的,因為這些封包是導向到CPU。在這種情況下,訪問請求必須同時包含源和目標MAC地址設定為00:00:00。
傳送到WLC上CPU的Radius存取要求
實際上只有具有指定來源和目的地MAC位址的存取要求才能從無線控制器發出。
傳送到AAA伺服器的Radius訪問請求
有問題的Access請求(由ID = 8標識),這些請求被多次傳送,並且沒有從AAA伺服器看到響應。進一步調查後,我們發現對於Access-request ID=8,UDP分段是由於大小超出MTU造成的,如下所示:
WLC封包擷取時發生分段
分段的資料包 — I
分段的資料包 — II
重組封包
為了交叉驗證,我們檢查了ISE日誌,發現無線控制器上已分段的訪問請求根本未被ISE接收。
ISE TCP轉儲
在ISE終端捕獲
Azure Side Capture with analysis:
Azure團隊對Azure內的物理主機執行捕獲。在Azure主機內的vSwitch上捕獲的資料表明UDP資料包的到達順序有誤。由於這些UDP片段的順序不正確,Azure正在丟棄它們。下面是同時從Azure端和無線控制器捕獲的訪問請求ID = 255,其中明視訊記憶體在資料包順序錯誤的問題:
無線控制器上的封裝封包擷取(EPC)會顯示分段封包從無線控制器中離開的順序。
WLC上分段封包的序列
在實體主機上,封包到達的順序不正確
Azure End上的捕獲
由於資料包以錯誤的順序到達,並且物理節點被程式設計為拒絕任何亂序幀,因此資料包會被立即丟棄。這種中斷會導致身份驗證過程失敗,使客戶端無法進入身份驗證階段。
無線控制器端建議的解決方法:
從版本17.11.1開始,我們正在實施對Radius/AAA資料包中的巨型幀的支援。此功能允許c9800控制器避免將AAA封包分段,前提是在控制器上設定了以下組態。請注意,要完全避免這些資料包的分段,必須確保每個網路躍點(包括AAA伺服器)都與巨型幀資料包相容。對於ISE,從3.1版本開始支援巨型幀。
無線控制器上的介面組態:
C9800-CL(config)#interface
C9800-CL(config-if) # mtu
C9800-CL(config-if) # ip mtu [1500 to 9000]
無線控制器上的AAA伺服器配置:
C9800-CL(config)# aaa group server radius
C9800-CL(config-sg-radius) # server name
C9800-CL(config-sg-radius) # ip radius source-interface
以下簡要說明無線LAN控制器(WLC)上的MTU(最大傳輸單元)設定為3000位元組時Radius封包。 小於3000位元組的資料包無需分段即可無縫傳送:
WLC上的封包擷取(增加MTU)
透過以此方式設定組態,無線控制器可以傳輸封包,而不會將其分段,且完整傳送封包。但是,由於Azure雲不支援巨型幀,因此無法實施此解決方案。
解決方案:
- 從無線控制器的封裝封包擷取(EPC)中,我們觀察到封包是以正確的順序傳送的。然後,接收主機便有責任正確重組這些請求並繼續處理,在這種情況下,Azure端不會發生此類操作。
- 要解決UDP資料包順序錯誤的問題
enable-udp-fragment-reordering,需要在Azure上啟用該選項。
- 您必須向Azure支援團隊尋求有關此問題的幫助。Microsoft已承認此問題。
附註:必須注意的是,此問題並非只有無線LAN控制器(WLC)獨有。 不同的RADIUS伺服器(包括ISE、Forti Authenticator和RTSP伺服器)上也遇到類似的有序的UDP資料包問題,尤其是當這些伺服器在Azure環境中運行時。