はじめに
このドキュメントでは、シーケンス違反のフラグメントの誤処理によるパケット損失を引き起こす、Azureプラットフォームの既知の問題について説明します。
症状
該当製品:AzureでホストされているCatalyst 9800-CL Wireless ControllerまたはAzureでホストされているIdentity Service Engine。
SSID Setup:中央認証を使用する802.1x EAP-TLS用に設定されます。
実施:Azureプラットフォームでホストされている9800-CLをEAP-TLSベースのSSIDで使用している場合、接続の問題が発生する可能性があります。認証フェーズ中にクライアントで問題が発生する可能性があります。
ISEサーバ上のエラー
EAP-TLS証明書の交換中にサプリカントがISEとの通信を停止したことを示すエラーコード5411。
詳細なログ分析:
影響を受ける設定の1つを次の図に示します。9800ワイヤレスコントローラでは、SSIDが802.1x用に設定され、AAAサーバがEAP-TLS用に設定されています。クライアントが認証を試みると(特に証明書交換フェーズ中)、クライアントはワイヤレスコントローラの最大伝送ユニット(MTU)サイズを超える証明書を送信します。次に、9800ワイヤレスコントローラはこの大きなパケットをフラグメント化し、フラグメントをAAAサーバに順次送信します。ただし、これらのフラグメントは物理ホストに正しい順序で到着せず、パケットのドロップにつながります。
クライアントが接続を試みているときのワイヤレスコントローラからのRAトレースを次に示します。
L2認証状態に入るクライアントとEAPプロセスが開始される
2023/04/12 16:51:27.606414 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [Client_MAC:capwap_90000004]要求の状態を開始しています
2023/04/12 16:51:27.606425 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [0000.0000.0000:capwap_90000004] EAPOLパケットを送信しています
2023/04/12 16:51:27.606494 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [Client_MAC:capwap_90000004]送信済みEAPOLパケット – バージョン: 3,EAPOLタイプ: EAP,ペイロード長: 1008, EAPタイプ= EAP-TLS
2023/04/12 16:51:27.606496 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [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]: (info): [Client_MAC:capwap_90000004] Received EAPOL packet - Version : 1,EAPOL Type : EAP, Payload Length : 6, EAP-Type = EAP-TLS
2023/04/12 16:51:27.640781 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [Client_MAC:capwap_90000004] EAP Packet - RESPONSE, ID : 0x25
ワイヤレスコントローラがAAAサーバにアクセス要求を送信し、パケットサイズが1500バイト(ワイヤレスコントローラのデフォルトのMTU)未満である場合、アクセスチャレンジは問題なく受信されます。
2023/04/12 16:51:27.641094 {wncd_x_R0-0}{1}: [radius] [19224]: (info): RADIUS: Send Access-Request to 172.16.26.235:1812 id 0/6, len 552
2023/04/12 16:51:27.644693 {wncd_x_R0-0}{1}: [radius] [19224]: (info): RADIUS: Received from 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]: (info): RADIUS: Send Access-Request to 172.16.26.235:1812 id 0/8, len 2048
2023/04/12 16:51:37.761885 {wncd_x_R0-0}{1}: [radius] [19224]: (info): RADIUS: Started 5 sec timeout
2023/04/12 16:51:42.762096 {wncd_x_R0-0}{1}: [radius] [19224]: (info): RADIUS: Retransmit to (172.16.26.235:1812,1813) for id 0/8
2023/04/12 16:51:32.759255 {wncd_x_R0-0}{1}: [radius] [19224]: (info): RADIUS: Retransmit to (172.16.26.235:1812,1813) for id 0/8
2023/04/12 16:51:32.760328 {wncd_x_R0-0}{1}: [radius] [19224]: (info): RADIUS: Started 5 sec timeout
2023/04/12 16:51:37.760552 {wncd_x_R0-0}{1}: [radius] [19224]: (info): RADIUS: Retransmit to (172.16.26.235:1812,1813) for id 0/8
2023/04/12 16:51:42.762096 {wncd_x_R0-0}{1}: [radius] [19224]: (info): RADIUS: Retransmit to (172.16.26.235:1812,1813) for id 0/8
パケットサイズが2048で、デフォルトのMTUを超えていることがわかります。そのため、AAAサーバからの応答はありません。ワイヤレスコントローラは、最大再試行回数に達するまで、アクセス要求を永続的に再送信します。応答がないため、ワイヤレスコントローラは最終的にEAPOLプロセスをリセットします。
2023/04/12 16:51:45.762890 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [Client_MAC:capwap_90000004] Posting EAPOL_START on Client
2023/04/12 16:51:45.762956 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [Client_MAC:capwap_90000004] init状態に入ります
2023/04/12 16:51:45.762965 {wncd_x_R0-0}{1}: [dot1x] [19224]: (info): [Client_MAC:capwap_90000004]クライアントに!AUTH_ABORTをポストしています
2023/04/12 16:51:45.762969 {wncd_x_R0-0}{1}: [dot1x] [19224]: (情報): [Client_MAC:capwap_90000004]再起動状態に入ります
このプロセスはループ状態になり、クライアントは認証フェーズだけでスタックします。
ワイヤレスコントローラでキャプチャされたEmbedded Packet Capture(EPC)は、複数のアクセス要求と1500バイト未満のMTUでのチャレンジ交換の後、ワイヤレスコントローラがクライアントの証明書が含まれている1500バイトを超えるアクセス要求を送信したことを示しています。この大きなパケットはフラグメンテーションの対象になります。ただし、この特定のアクセス要求に対する応答はありません。ワイヤレスコントローラは、EAP-TLSセッションが再起動する最大再試行回数に達するまでこの要求の再送信を続行します。この一連のイベントは繰り返し発生し続け、クライアントの認証試行中にEAP-TLSループが発生していることを示しています。より明確な理解のために、次に示すワイヤレスコントローラとISEの両方からの同時パケットキャプチャを参照してください。
ワイヤレスコントローラEPC:
WLCでのパケットキャプチャ
ワイヤレスコントローラが特定のアクセス要求ID = 8の複数の重複する要求を送信していることがわかります
注:EPCでは、他のIDに対して1つの重複する要求があることにも気付きます。これにより、「このような重複は予想されますか。」という質問が表示されます。この重複が予想されているかどうかの答えは「はい」です。これは、「Monitor Control Plane」オプションを選択した状態で、ワイヤレスコントローラのGUIからキャプチャが取得されたためです。その結果、RADIUSパケットの複数のインスタンスがCPUに送信されるため、これらが観察されるのは正常です。このような場合、アクセス要求は送信元と宛先の両方のMACアドレスが00:00:00に設定された状態で表示される必要があります。
WLC上のCPUにパントされるRADIUS access-request
指定された送信元および宛先MACアドレスを持つアクセス要求だけが、実際にはワイヤレスコントローラから送信される必要があります。
AAAサーバに送信されるRADIUSアクセス要求
ID = 8で識別される問題のアクセス要求。複数回送信され、AAAサーバから応答が見つからなかった要求です。さらなる調査の結果、次に示すように、Access-request ID=8の場合、MTUを超えるサイズが原因でUDPフラグメンテーションが発生していることが判明しました。
WLCパケットキャプチャでフラグメンテーションが発生する
断片化パケット – I
断片化パケット – II
再構成されたパケット
クロス検証のために、ISEログを確認し、ワイヤレスコントローラでフラグメント化されたアクセス要求がISEでまったく受信されていないことが判明しました。
ISE TCPダンプ
ISE側のキャプチャ
分析を使用したAzure Side Capture:
Azureチームは、Azure内の物理ホストでキャプチャを実行しました。Azureホスト内のvSwitchでキャプチャされたデータは、UDPパケットが正しくない順序で到着していることを示しています。これらのUDPフラグメントは正しい順序ではないため、Azureによって破棄されます。次に、Azureエンドとワイヤレスコントローラの両方からのキャプチャを示します。これは、アクセス要求ID = 255に対して同時に取得され、パケットが順不同の問題が明確に示されています。
ワイヤレスコントローラ上のEncapsulated Packet Capture(EPC)は、フラグメント化されたパケットがワイヤレスコントローラから発信されるシーケンスを表示します。
WLCでのフラグメント化されたパケットのシーケンス
物理ホストで、パケットが正しい順序で到着していません
Azureエンドのキャプチャ
パケットが誤った順序で到着し、物理ノードが不正なフレームを拒否するようにプログラムされているため、パケットはただちに廃棄されます。この中断により認証プロセスが失敗し、クライアントは認証フェーズを経過することができなくなります。
ワイヤレスコントローラ側から推奨される回避策:
バージョン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バイト未満のパケットは、フラグメンテーションを必要とせずにシームレスに送信されました。
MTUが増加したWLCでのパケットキャプチャ
このように設定することで、ワイヤレスコントローラはパケットをフラグメント化せずに送信し、そのままの状態で送信します。ただし、Azureクラウドはジャンボフレームをサポートしていないため、このソリューションは実装できません。
ソリューション:
- ワイヤレスコントローラのEncapsulated Packet Capture(EPC)から、パケットが正しい順序で送信されていることがわかります。次に、受信側ホストが適切に再構成して処理を続行する責任があります。この場合、Azure側では処理は行われません。
- 順序が正しくないUDPパケットの問題に対処するには、Azureで
enable-udp-fragment-reordering
のオプションをアクティブにする必要があります。
- この問題に関するサポートについては、Azureサポートチームにお問い合わせください。Microsoftでは、この問題を確認しています。
注:この問題がワイヤレスLANコントローラ(WLC)だけの問題ではないことに注意してください。 順序が入れ替わったUDPパケットに関する同様の問題が、特にAzure環境内で動作する場合に、ISE、Forti Authenticator、RTSPサーバなどの異なるRADIUSサーバで発生しています。