分段疑難排解：影響使用Azure的c9800無線控制器

簡介

本文檔描述了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環境中運行時。