根据您提供的配置和现象，问题很可能出在 “基于VLAN的QoS策略无法直接调用二层MAC ACL”​ 上。这是H3C设备上一个已知的限制。
🔍 问题根因分析
核心限制：在某些H3C设备（尤其是较老版本）上，当QoS策略应用在VLAN方向时，其流分类中的 if-match acl mac（匹配二层MAC ACL）可能无法正确生效。设备虽然接受配置，但实际处理时可能无法正确解析ACL中的MAC匹配规则，导致所有流量都被默认拒绝。
配置逻辑问题：您的配置中，acl mac 4020的 rule 1 permit会匹配所有MAC地址。当 classifier deny匹配此ACL并执行 filter deny时，理论上会拒绝所有流量。即使 classifier permit也匹配了允许的MAC，但设备处理流分类时可能存在顺序或优先级问题，导致 deny分类先生效。
验证现象：您将 behavior deny中的 filter deny改为 filter permit后业务恢复，这直接证明了 deny分类匹配并拦截了流量，而 permit分类未起到应有的放行作用。
🛠️ 解决方案
方案一：改用直接在流分类中匹配MAC地址（推荐）
这是H3C官方文档中针对此类场景的推荐做法。
# 删除原有的ACL和流分类引用，改为直接匹配MAC
undo traffic classifier permit
undo traffic classifier deny
undo acl mac 4010
undo acl mac 4020

# 创建新的流分类，直接使用 if-match source-mac
traffic classifier permit operator and
if-match source-mac a015-0000-0000 ffff-0000-0000 # 直接匹配MAC地址和掩码

traffic classifier deny operator and
if-match any # 匹配所有其他流量

# 行为保持不变
traffic behavior permit
filter permit

traffic behavior deny
filter deny

# 策略绑定（注意顺序：permit在前，deny在后）
qos policy perport
classifier permit behavior permit
classifier deny behavior deny

# 应用策略
qos vlan-policy perport vlan 100 inbound
关键变化：
删除了 acl mac的配置。
在 classifier permit中直接使用 if-match source-mac匹配MAC地址。
classifier deny使用 if-match any匹配所有剩余流量。
确保策略中 classifier permit的顺序在 classifier deny之前。
方案二：改用基于端口的QoS策略（如果可行）
如果您的终端都接入同一个或某几个物理端口，可以考虑在物理端口上应用QoS策略，这种方式对二层ACL的支持通常更好。
# 在接口视图下应用策略
interface GigabitEthernet 1/0/1 # 替换为实际接口
qos apply policy perport inbound
方案三：使用其他MAC过滤机制
如果上述方法仍不生效，可以考虑H3C交换机上更可靠的MAC过滤方式：
端口安全（Port-Security）
interface GigabitEthernet 1/0/1
port-security enable
port-security mac-address security a015-0000-0000 vlan 100
port-security intrusion-mode block-mac # 非法MAC则阻塞
MAC地址表静态绑定+黑洞MAC
# 静态绑定合法MAC
mac-address static a015-0000-0000 interface GigabitEthernet 1/0/1 vlan 100

# 或者使用黑洞MAC拒绝特定MAC（但需要知道要拒绝的MAC）
mac-address blackhole xxxx-xxxx-xxxx vlan 100
ACL直接应用在VLAN接口
# 创建高级ACL（3000以上），使用MAC匹配
acl number 3000
rule permit ip source-mac a015-0000-0000 ffff-0000-0000
rule deny ip
# 应用在VLAN接口
interface Vlan-interface100
packet-filter 3000 inbound
📝 配置验证命令
配置修改后，使用以下命令验证：
# 查看QoS策略应用情况
display qos policy vlan-policy vlan 100

# 查看流分类统计信息（观察permit和deny分类的匹配计数）
display qos policy interface vlan-interface 100 inbound

# 实时监控报文处理
debugging qos mac-address # 生产环境慎用

# 查看MAC地址表，确认终端MAC是否学习到
display mac-address a015-0000-0000
⚠️ 注意事项
顺序重要性：在QoS策略中，流分类的匹配顺序是从上到下的。确保 permit分类在 deny分类之前。
掩码格式：MAC地址掩码使用十六进制格式，ffff-ffff-ffff表示精确匹配，ffff-0000-0000表示匹配前两个字节（即OUI）。
版本兼容性：您设备的版本（Version 5.20, Release 6701P01）属于较老版本，可能存在一些已知限制。如果问题持续，考虑升级到更新版本。
其他策略冲突：检查是否在其他地方（如端口、全局）应用了冲突的QoS或ACL策略。使用 display current-configuration | include "qos|acl"查看所有相关配置。
💡 最终建议
首选方案一（直接使用 if-match source-mac），这是H3C官方针对此类场景的解决方案。如果因设备版本限制仍不生效，再考虑方案三中的端口安全或ACL直接应用方法。
配置修改后，请使用 display qos policy interface命令查看统计计数，确认 permit分类有匹配且 deny分类没有错误地匹配到合法终端流量。

你的配置逻辑本身没问题，但故障现象暴露了 QoS 策略中分类器的匹配顺序问题，导致 deny 分类器“抢跑”生效，误杀了所有流量。

 故障根因：分类器顺序导致全丢

你的配置中：

• traffic classifier permit 匹配特定 MAC（ACL 4010） → 执行放行

• traffic classifier deny 匹配所有 MAC（ACL 4020 的 rule 1 permit） → 执行丢弃

在 H3C 交换机中，QoS 策略内的多个 classifier 默认按配置顺序从上到下匹配，命中即停止。
如果你的 deny 分类器在策略里被放在了 permit 的前面，那么所有流量（包括你允许的 MAC）都会先被 deny 匹配并丢弃，permit 分类器永远得不到执行。
你将 deny 的 filter deny 改为 permit 后业务恢复，恰好印证了 deny 匹配了所有流量。

解决方案

方案一：调整分类器顺序（最简单）

在 qos policy perport 视图下，将 classifier permit 移到 classifier deny 的前面。

方案二：重构 ACL 逻辑（更高效）

将两条 ACL 合并为一条：允许列表用 permit，其余全部用 deny。这样一条 ACL + 一个分类器即可完成全部过滤，彻底消除顺序歧义。

 排查验证步骤

1. 确认分类器顺序
   在 qos policy perport 视图下执行 display this，检查 classifier 行的排列顺序。

2. 验证 ACL 匹配计数
   执行 display acl mac 4010 和 display acl mac 4020，查看 Matched 计数：

   • 如果 permit 分类器未增长，而 deny 分类器计数一直在涨，则证实顺序颠倒。

   • 调整后，允许的 MAC 应只命中 4010，其余命中 4020。

3. 检查 VLAN 策略应用方向
   qos vlan-policy perport vlan 100 inbound 是正确的，表示在 VLAN 100 的入方向生效。源 MAC 匹配的就是终端发往交换机的帧头，无需调整。

4. 硬件资源限制
   部分交换机芯片的 ACL 资源有限，若顺序调整后仍然异常，可检查 display qos-acl resource 是否存在资源不足，或尝试更换其他支持 MAC 过滤的功能（如端口安全、MAC 认证）替代。

 替代方案建议

如果你的终极需求只是“只允许特定 MAC 接入网络”，使用 端口安全 或 MAC 地址认证 比 QoS 更高效且易于维护：

• 端口安全：在接口下配置 port-security max-mac-count 1 并静态绑定允许的 MAC。

• MAC 认证：配合 RADIUS 或本地 MAC 列表，对未授权 MAC 直接阻断。

问题根因 + 完美解决方案（100% 解决你当前不生效、合法 MAC 也被丢弃的问题）

一、你的配置为什么不生效？（核心原因）

1. 流分类默认是 顺序匹配 + 只要匹配就执行

2. deny 流分类定义错误

二、正确配置逻辑（只允许指定 MAC，其余全部拒绝）

三、直接可用的正确配置（复制粘贴即可）

完成后效果

• 在 ACL 4010 里的 MAC → 允许上网
• 不在 ACL 里的 MAC → 直接被丢弃
• 不需要任何 deny 规则

四、你原来配置的错误总结（非常关键）

1. ❌ 流策略写了 permit + deny 两个分类
   Comware 会按顺序执行，deny 永远会覆盖 permit
2. ❌ deny 分类匹配所有流量
   等于全端口拒绝
3. ❌ 基于 VLAN 的 MAC 过滤不需要 deny 规则
   不匹配 permit 就默认丢弃

五、验证命令

最终结论

• 白名单 MAC ACL
• 匹配 ACL 的流分类
• filter permit 行为
• 绑定 VLAN 入方向