S5570最堆叠组端口开启802.1x异常

这个报错字面是"ACL 资源不足"，但结合你给的信息——两台堆叠、Slot1 开 802.1x 正常、Slot2 才报、全局只有一条 SSH 限制 ACL——基本可以锁定不是 ACL 真用完，而是 Slot2 的硬件 TCAM 里"某一类"region 被占/分配不均，802.1x 要在 Slot2 上申请的 rule 下不去。S5570S-54S-EI 这种盒式堆叠，ACL 硬件资源是按 slot 独立算的，Slot1 和 Slot2 各有一份 TCAM，全局一条 ACL 看着少，但如果这条 ACL 在 Slot2 上也挂了一份，再加上 802.1x 自身要占的 freerule（DHCP/DNS 未认证放行、EAPOL 放行等），Slot2 那边的某个 region 就可能先触顶。
先把报错语义对一下
DOT1X_NOTENOUGH_ENABLEDOT1X_RES官方释义就是 "在接口上 enable 802.1x 时，设备要给这个口下硬件 ACL rule（EAPOL 放行 + 未认证时段 DHCP/DNS 的 free-rule 等），Slot2 的 TCAM 申请不到，enable 失败"。
Slot1 能开成功 → Slot1 的 TCAM 还有余量；Slot2 开不了 → Slot2 那份被占/分区的锅。
为什么"只有一条 SSH ACL"还会不够
H3C 盒式堆叠下，ACL 硬件资源 per-slot 独立，几个隐形消耗项你核对下：
SSH 那条 ACL 是怎么挂的——这是最大嫌疑
如果是 packet-filter 3xxx inbound挂到接口/VLAN/全局 → 走硬件 TCAM，每台 slot 都要占一份
如果是 ssh server acl 3xxx/ telnet server acl 3xxx→ 控制面，不走 TCAM，不占硬件
你这条 SSH 限制如果是前者，Slot1 + Slot2 各占一份，本身没问题，但会挤占 802.1x 要用的 region
802.1x 自身隐性占用（每台 slot 每启用一个口都要）：
EAPOL（01-80-C2-00-00-03）放行 rule
未认证用户 DHCP/DNS 的 free-rule（即使你没开 EAD，这部分底层也会预占）
如果你还配了 guest VLAN / auth-fail VLAN，每口再叠一条
S5570S-54S-EI + R1129 这代，盒式堆叠跨 slot 的 ACL region 分配有个已知特性：部分 region（尤其是 L2/L3 混合类，802.1x freerule 走的就是这类）在 Slot2 上默认分给的量比 Slot1 小，端口一多就容易在 Slot2 先爆。R1129 之后有补丁调整过 region 配比，但要看你具体小版本。
5 分钟自检定位
# 看 Slot2 的 ACL 硬件资源分布（关键）
display acl resource slot 2
# 或老命令
display qos-acl resource slot 2

# 看 SSH 那条 ACL 挂哪儿了
display packet-filter interface GigabitEthernet2/0/16 # 如果挂了接口
display packet-filter vlan xx # 如果挂了 VLAN
display current-configuration | include ssh server # 看是不是控制面方式
display current-configuration | include packet-filter # 全局扫一遍
display acl resource slot 2里关注 Remaining​ 列，哪一类（L2 / L3 / EAPOL / Free-rule 对应的 region）先到 0，就是被卡的那类。
改法三档
🎯 最快治标：SSH ACL 换成控制面方式（如果原是 packet-filter）
# 假设原 SSH 限制 ACL 是 2000，原配置如果是：
# interface xxx / packet-filter 2000 inbound ← 占 TCAM

# 改成控制面：
undo packet-filter 2000 interface xxx inbound # 原挂接口的删掉
ssh server acl 2000 # 控制面，不占硬件 TCAM
telnet server acl 2000 # 如果用 telnet 也一并改
这一条腾出来的 TCAM 一般就够 Slot2 把 802.1x 开起来了，成本低，优先试。
🔧 中段：802.1x 侧省资源
如果 802.1x 暂时不用 guest VLAN / auth-fail VLAN / EAD，先把非必要项关掉，减少每口预占的 freerule 数：
dot1x guest-vlan disable # 没用就关
undo dot1x auth-fail vlan # 没配就确认是 undo 状态
端口下如果配了 dot1x port-method macbased，每 MAC 还要占 rule，端口下终端多的话改 portbased省：
interface GigabitEthernet2/0/16
dot1x port-method portbased
🚑 兜底：Slot2 重启重同步 / 升补丁
如果上面两条做完 display acl resource slot 2还是某类 Remaining=0，但 Slot1 同类还有剩，那就是 region 分配不均的已知问题：
先试 reboot slot 2让 Slot2 重新向堆叠主同步 TCAM 分区，有时能拉回一部分
R1129 这代 S5570 EI 后续有小版本（1129Pxx）调过堆叠 ACL region 配比，实在不行找 400 要对应补丁，Release Note 里搜 "802.1x ACL resource slot" 能看到修复条目
应急验证
改完 SSH ACL 挂载方式后，先在 Slot2 随便找个空口试：
interface GigabitEthernet2/0/16
dot1x
不报 DOT1X_NOTENOUGH_ENABLEDOT1X_RES就说明 TCAM 腾出来了，再批量铺。

S5570S-54S-EI IRF 堆叠 slot2 开启 802.1X 报错 ACL 资源不足完整排查
一、报错日志核心含义
plaintext
DOT1X/3/DOT1X_NOTENOUGH_ENABLEDOT1X_RES: -Slot=2; Failed to enable 802.1X on interface GigabitEthernet2/0/16 due to lack of ACL resources.
翻译：2 号堆叠单板硬件 ACL/TCAM 资源耗尽，无法分配 802.1X 内置隔离 ACL 表项，端口开启 dot1x 失败。
关键底层机制（IRF 堆叠最核心关键点）
IRF 堆叠单板硬件资源完全隔离：slot1 主设备、slot2 备机各自独立拥有 TCAM/ACL 硬件表项，资源不跨板共享；slot1 资源充足不代表 slot2 资源够用。
802.1X 端口开启时，芯片自动下发内置 ACL 规则：
未认证流量隔离、Guest VLAN、Critical VLAN、免认证 Free IP 全部依赖硬件 ACL 表项；
每开启一个 dot1x 端口，单板会预占用多条 IFP 入方向 ACL 资源；
你仅配置一条全局 SSH ACL，但其他隐性业务大量占用 slot2 单板 ACL 资源，把硬件表项耗尽，导致新增 dot1x 端口分配失败。
二、slot2 单板 ACL 资源占用排查命令（现场优先执行）
1. 查看单板全局 ACL/TCAM 资源总占用（区分 slot1/slot2）
plaintext
# 查看整机各单板ACL硬件资源
display qos-acl resource slot 2
# 查看单板剩余ACL表项
display acl resource slot 2
重点字段：IFP ACL Used（入方向 ACL 已占用）、Remaining剩余条目，slot2 剩余条目为 0 / 极少就是根因。
2. 排查 slot2 单板哪些业务消耗 ACL 资源（高频占用项）
高消耗 ACL 业务清单（S5570 V7 R1129）
端口全局packet-filter inbound接口 ACL 过滤；
MQC 流策略qos apply policy绑定在 slot2 端口；
IPSG IP 源防护、ARP 防攻击、端口安全；
全局控制平面 ACL packet-filter control-plane；
已开启的 802.1X、MAC 认证、Portal 端口；
堆叠 IRF Peer-Link、M-LAG、静态聚合安全策略。
查看 slot2 端口绑定的流策略 / 报文过滤
plaintext
# 查看slot2所有接口应用的ACL过滤
display packet-filter interface GigabitEthernet 2/0/*
# 查看slot2所有端口QoS流策略
display qos policy interface GigabitEthernet 2/0/*
# 查看全局控制平面ACL
display current-configuration | include packet-filter control-plane
三、分步骤释放 slot2 单板 ACL 资源（解决开启 dot1x 失败）
步骤 1：清理 slot2 无用接口 ACL、流策略
下线闲置端口的packet-filter报文过滤
plaintext
interface GigabitEthernet 2/0/X
undo packet-filter inbound
删除 slot2 端口无用 QoS 流策略
plaintext
interface GigabitEthernet 2/0/X
undo qos apply policy all inbound
移除全局控制平面多余 ACL 规则，仅保留最小必要 SSH 防护
plaintext
system-view
control-plane
undo packet-filter inbound acl XXX
步骤 2：优化 802.1X 配置，减少 ACL 资源额外消耗
1）关闭非必要隔离功能（节省 ACL 表项）
若现场不需要 Guest VLAN、Critical VLAN、Auth-Fail VLAN，全部删除，这三类功能会额外占用多条 ACL：
plaintext
interface GigabitEthernet 2/0/16
undo dot1x guest-vlan
undo dot1x auth-fail vlan
undo dot1x critical vlan
2）统一认证方式，减少动态 ACL 下发
使用dot1x authentication method eap单一认证，避免混合 MAC+802.1X 双重认证（双重认证会翻倍占用 ACL 资源）。
3）开启 802.1X 资源复用优化（V7 版本支持）
plaintext
system-view
dot1x resource-reuse enable
作用：复用空闲 ACL 表项，减少单端口预占用资源。
步骤 3：IRF 堆叠资源均衡优化（根治 slot2 资源耗尽）
业务端口均衡分配，不要所有接入端口集中在 slot2 单板；
若无法调整布线，升级设备固件到 R1129P08 及以上修复 IRF 单板 ACL 资源分配 BUG；
老版本 R1129 存在堆叠备板 ACL 资源回收不彻底，长期配置后残留占用。
步骤 4：验证资源释放后开启 802.1X
plaintext
# 再次查看slot2剩余ACL资源
display qos-acl resource slot 2
# 剩余条目充足后，进入端口开启dot1x
interface GigabitEthernet 2/0/16
dot1x
不再提示资源不足即修复完成。
四、补充常见误区解答
误区 1：只配置一条 SSH 全局 ACL，为什么资源还会耗尽？
全局 ACL 仅占用全局资源，接口绑定的 packet-filter、MQC、802.1X、IPSG 是按单板分别占用硬件 TCAM，单条全局 ACL 不影响单板端口 ACL 容量。slot2 大量接入端口开启安全特性，会单独耗尽本板资源。
误区 2：slot1 所有端口开 dot1x 正常，slot2 不行？
IRF 硬件资源物理隔离，两块单板 TCAM 表项独立，slot1 负载低、slot2 安全特性多，资源提前耗尽，和全局配置无关。
误区 3：是否有命令扩大单板 ACL 容量？
硬件 TCAM 规格固定，无法扩容，只能清理占用资源的业务、精简安全配置释放表项。
五、长期规避方案
IRF 堆叠业务端口均匀分布两块单板，避免单块板承载大量 dot1x 接入；
不批量在端口配置多余 Guest/Fail/Critical VLAN，按需开启；
减少端口下 MQC 流策略、packet-filter 报文过滤；
升级交换机固件至 R1129P08，修复堆叠单板 ACL 资源不自动回收的底层 BUG；
定期执行display qos-acl resource slot X监控各单板 ACL 剩余资源。

根据你的描述，问题出在 Slot 2 的 ACL 硬件资源不足。

虽然你只在设备上配置了一条限制 SSH 访问的 ACL，但 802.1X 功能在启用时，本身会消耗大量的 ACL 资源来实现报文上送、用户授权等功能。在堆叠环境中，每个成员设备（Slot）的 ACL 资源是独立计算的。你只在 Slot 2 上开启 802.1X 时报错，说明 Slot 2 的 ACL 硬件资源（可能是 PCL ACL 或类似表项）已经被占满，没有足够空间分配给 802.1X 功能。

🔍 第一步：诊断，确认具体资源瓶颈

1. 查看具体的ACL资源使用情况
   请在设备上执行以下命令，重点关注 Slot 2 的输出：

   text

   display acl resource slot 2

   或者

   text

   display qos-acl resource slot 2

   重点关注：输出中 Remaining（剩余）或 Free（空闲）资源极低的表项，尤其是 PCL ACL 这类与策略相关的表项。这会帮你定位具体是哪种类型的ACL资源耗尽。

2. 检查系统日志
   查看是否有其他ACL资源不足的提示：

   text

   display logbuffer

🛠️ 第二步：解决，释放 ACL 资源

1. 清理无用 ACL
   检查并删除设备上所有未使用的 ACL（包括你提到的 SSH ACL 和其他可能存在的 ACL）。

   text

   system-view undo acl [acl-number | name acl-name]

   如果 display acl resource 输出显示某个 ACL 占用了大量资源，可以考虑优化规则，比如通过修改反掩码来合并多条规则，以减少资源占用。

2. 重启设备（可行方案）
   这是一个比较直接有效的方法。当 ACL 资源因各种原因被碎片化占用时，保存配置并重启设备可以清空所有下发的 ACL，使资源恢复到初始状态。

   text

   save reboot

   注意：重启会导致业务中断，请在维护窗口操作。

3. 优化 802.1X 的 Free IP 配置（如果使用了该功能）
   如果你配置了 dot1x ead-assist free-ip，每条单独的 IP 规则都会消耗 ACL 资源。建议将零散的 Free IP 合并为网段进行配置，以减少 ACL 条目数。

4. 尝试调整 ACL 资源分配模式（高级操作）
   部分 H3C 交换机支持调整 ACL 资源分配模式。如果上述方法都无效，可以查阅设备手册，确认是否支持以下命令：

   text

   system-view acl resource allocation slot 2 [调整参数]

   注意：此操作风险较高，务必在充分了解影响并参考官方文档后再执行。

💎 总结与建议

总的来说，核心原因是 802.1X 所需的 ACL 资源在 Slot 2 上已经耗尽。

建议按以下顺序操作：

1. 首先执行 display acl resource slot 2，确认是哪种具体资源耗尽。

2. 优先尝试清理无用 ACL 或重启设备，这通常是解决问题最快的方法。

3. 如果问题依旧，请提供 display acl resource slot 2 的完整输出，以便进行更深入的分析。