简介
本文档介绍Azure平台的一个已知问题,该问题导致由于处理无序分段错误而导致数据包丢失。
症状
受影响的产品:托管在Azure上的Catalyst 9800-CL无线控制器或托管在Azure上的身份服务引擎。
SSID设置:配置为使用中央身份验证的802.1x EAP-TLS。
执行:使用托管在Azure平台上的9800-CL以及基于EAP-TLS的SSID时,可能会遇到连接问题。客户端在身份验证阶段可能会遇到困难。
ISE服务器出错
错误代码5411,指示请求方在EAP-TLS证书交换期间已停止与ISE的通信。
详细日志分析:
下面是其中一个受影响配置的图示:在9800无线控制器中,为802.1x设置SSID,为EAP-TLS配置AAA服务器。当客户端尝试进行身份验证时,特别是在证书交换阶段,客户端发送超过无线控制器上最大传输单位(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存在单个重复请求。这就引出了一个问题:是否期望出现这种重复?至于是否应该出现这种重复,答案是肯定的。原因是捕获是从无线控制器的GUI获取的,并且选中了“Monitor Control Plane”(监控控制平面)选项。因此,观察RADIUS数据包的几个实例是正常的,因为它们被定向到CPU。在这种情况下,必须看到源和目标MAC地址都设置为00:00:00的访问请求。
Radius访问请求传送到WLC上的CPU
只有具有指定源和目标MAC地址的访问请求才能实际从无线控制器发出。
发送到AAA服务器的Radius访问请求
有问题的访问请求(由ID = 8标识)被多次发送并且未从AAA服务器看到响应。进一步调查后,我们发现对于Access-request ID=8,UDP分段是由大小超出MTU造成的,如下所示:
WLC数据包捕获发生分段
分段数据包 — I
分段数据包 — II
重组数据包
为了交叉验证,我们检查了ISE日志,发现无线控制器上分段的访问请求根本未被ISE接收。
ISE TCP转储
在ISE端捕获
带分析的Azure Side Capture:
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
下面简要介绍当无线局域网控制器(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环境中运行时。