（AD-Campus 多 Leaf 同时 RADIUS up/down、EIA 主进程未重启，这个是典型集群侧后端组件阻塞 / 消息积压、Kafka/DB 慢、防火墙会话老化场景，不是单台 Leaf 问题）

日志里的 RADIUS Server UP/DOWN，是 H3C 设备RADIUS 服务器探测超时→标记 Down；后续报文收到回应→标记 Up，不是 EIA 服务重启。多台 Leaf 同一时间点震荡，直接锁定Leaf 到 EIA 集群这条转发路径、EIA 集群内部组件，不是单台 Leaf 本地配置。

多台 Leaf同一时间报 RADIUS 服务器 UP/DOWN，EIA 组件本身没有重启，这个现象基本不是 EIA 应用进程挂了，是Leaf 到 EIA 的 Underlay/Overlay 传输链路侧丢包、时延抖动，触发 Comware RADIUS 服务端探测机制：多次 RADIUS 探测报文无应答 → 标记服务器 Blocked（DOWN）；等到 quiet 定时器到期，自动恢复为 UP，反复循环H3C。

AD-Campus 里所有 Leaf 共用 EIA 这一组 RADIUS 地址，所以链路震荡时所有 Leaf 同步打出日志，是典型特征。

根因优先级排序

1. Underlay / 到 EIA 的三层链路丢包、时延大（最高概率） EIA 一般部署在 Spine 上层或者独立服务器区，Leaf 访问 EIA 走 Underlay IGP（OSPF）。如果 Spine、服务器接入交换机、EIA 前端防火墙存在：端口错包、CRC、带宽拥塞、CPU 高、QoS 队列丢包，UDP 1812/1813 RADIUS 报文极易丢包（UDP 无重传）。

RADIUS 机制：NAS 连续发探测 / 认证报文，多次超时无应答，就置服务器 DOWN；quiet 时间到自动恢复 UP，产生你看到的日志。

2. 中间防火墙 / 安全策略限流、会话老化拦截 RADIUS UDP EIA 前端防火墙对 1812/1813 UDP 做了会话短老化、或者开启了 UDP 限流、攻击防护，突发认证流量时丢弃 RADIUS 探测包。
3. EIA 侧资源瓶颈（Pod 没重启，但 CPU/IO/ 数据库卡顿） EIA 容器 Pod 状态是 Running，但是底层数据库、uam 认证进程 CPU 打满、数据库慢查询，报文收到但是处理超时，无法回响应报文，Leaf 侧判定服务器 DOWN。EIA 页面组件状态看不出来，需要进后台看 pod 资源、数据库负载。
4. RADIUS 方案探测参数配置过紧（AD-Campus 模板下发） NCE 自动下发的 radius scheme 重传次数、超时时间偏小，轻微丢包就震荡；radius server quiet时间太短，快速反复 UP/DOWN。

现场排查步骤

1. 选一台 Leaf 长 ping EIA 的 RADIUS IP，带发包统计：ping -c 1000 -vpn-instance xxx x.x.x.x，看有没有随机丢包；同时display radius scheme查看服务器状态、重传次数、timeout、quiet 定时器。
2. 检查 Leaf→Spine→EIA 路径所有中间设备：接口 CRC 错包、CPU 利用率、端口 buffer 丢包。
3. EIA 前端防火墙：确认 UDP 1812、1813 没有限流、短会话老化、IPS/DoS 拦截。
4. 登录 EIA 后台查看 eia-uam、数据库 pod 的 CPU、内存、磁盘 IO，确认是应用处理慢，不是进程重启。
5. 临时调大 RADIUS 探测参数验证（NCE 模板里修改，重新下发给 Leaf）：加大 timeout、重传次数，拉长 quiet-time，规避轻微链路抖动误判。

区分关键点

• 单台 Leaf 震荡：该 Leaf 上联链路问题；
• 全部 Leaf 同一时间一起震荡：EIA 上行汇聚链路、EIA 服务器本身负载、前端防火墙策略问题（就是你当前场景）