AC 服务模板 packet‑filter + map‑configuration 下发 ACL 问题解析（V7 FIT‑AP）

关键点：wlan service‑template下的packet‑filter过滤动作，实际执行点在 AP，不是 AC；ACL 配置必须下发到 AP 本地才能生效H3C。

(1) ACL 报文过滤在哪里执行？

✅无论本地转发、还是隧道（集中）转发，service‑template packet‑filter的过滤动作都发生在 AP 上H3C。

• 本地转发：终端流量 AP 直接转发，在 AP 上做 ACL 过滤；
• 隧道（集中）转发：无线终端报文在 AP 完成 ACL 过滤之后，才封装进 CAPWAP 隧道发给 AC；下行方向，CAPWAP 解封装之后，在 AP 做 outbound 过滤，再从空口发给终端。

注意区分另外一类：AC 上WLAN‑ESS接口下firewall packet‑filter，这个才是在 AC 设备上过滤。和服务模板下 packet‑filter 不是同一个功能，不要混淆H3C。

(2) 既然过滤在 AP，为什么 AC 上能敲 packet‑filter 命令？

1. AC 的服务模板只是记录引用哪一条 ACL 编号 / 名字，ACL 规则本体不会自动跟随服务模板下发 APH3C。
2. 必须依靠map‑configuration（configuration‑profile）把完整 ACL 规则批量推送到 AP 本地 Flash，AP 本地有这套 ACL 规则，服务模板上的 packet‑filter 引用才能真正生效；如果不下发 ACL 到 AP，packet‑filter 配置在 AP 上存在，但 ACL 规则缺失，过滤不会工作H3C。

现象：AC 上看配置完整，但 AP 没有 map‑configuration 下发 ACL，AP 侧执行display acl看不到这条 ACL，过滤直接失效。

完整逻辑梳理

1. AC：wlan service‑template xxx 执行packet‑filter 3000 inbound，只是告诉 AP：“你要用 ACL3000 做入方向过滤”，AC 不会把 acl 3000 的 rule 自动推给 AP。
2. AC 通过configuration‑profile（map‑configuration）把acl number 3000 rule xxx整套规则下发 AP。
3. AP 上线，加载 profile，本地生成 ACL3000；AP 的无线服务模板生效，在 AP 芯片层面完成报文过滤。

两个容易踩坑点

1. 只在 AC 写 ACL、服务模板调用 packet‑filter，忘记 map‑configuration 下发 ACL 给 AP：AP 本地无 ACL 规则，过滤完全不生效。
2. 不要把service‑template packet‑filter和WLAN‑ESS接口firewall packet‑filter混淆：
   • service‑template packet‑filter：AP 侧执行，适用于本地 / 集中转发；
   • interface WLAN‑ESS firewall packet‑filter：AC 侧执行，只针对隧道转发流量，本地转发流量不走 WLAN‑ESS，完全不生效。

核查命令

简短小结

1. 服务模板packet‑filter的 ACL 过滤在 AP 上执行，不是 AC，集中转发也是先过滤再封装 CAPWAP 隧道H3C。
2. AC 上的 packet‑filter 仅记录引用 ACL 编号；ACL 规则本体必须依靠 map‑configuration (configuration‑profile) 下发到 AP 本地，否则过滤无效。
3. AC 上 WLAN‑ESS 接口下 firewall packet‑filter 才是 AC 上过滤，只对隧道转发生效。

补充：该特性限制，无线服务模板 packet‑filter 只识别源 / 目的 IP、端口、协议，ACL 里面 time‑range、logging 等部分属性 AP 不识别，不会生效H3C。

集中转发在AC上生效，本地转发在AP上生效。

关于你的两个问题，核心结论是：ACL的过滤动作实际发生在AP上，而不是AC上。AC上的packet-filter命令只是一个“引用指令”，真正的规则本体必须通过map-configuration下发到AP才能生效。

 问题（1）：ACL过滤报文是在AP上还是AC上？

过滤动作发生在AP上，并且无论采用本地转发还是集中转发，都是如此。

• 本地转发：终端流量由AP直接转发，AP在本地对报文执行ACL过滤。

• 集中转发（隧道转发）：无线终端的报文在AP上完成ACL过滤之后，才被封装进CAPWAP隧道发送给AC。下行方向，CAPWAP解封装后，同样是在AP上执行outbound过滤，再从空口发给终端。

这里需要特别注意区分一个容易混淆的功能：AC上WLAN-ESS接口下的firewall packet-filter才是在AC设备上执行的，它只对隧道转发的流量生效，与无线服务模板下的packet-filter是两套不同的机制，不要混为一谈。

 问题（2）：既然在AP过滤，为什么还要把ACL下发到AP？

这正是H3C无线架构中一个关键的设计逻辑：AC的服务模板只负责“引用”，不负责“同步”。

具体来说：

• AC侧只记录引用关系：你在wlan service-template下执行packet-filter 3000 inbound，这条命令的作用仅仅是告诉AP：“你需要用ACL 3000来做入方向过滤”。AC并不会自动把acl 3000的规则内容推送给AP。

• AP需要本地的ACL规则才能执行过滤：AP在收到服务模板的引用指令后，会去查找自己本地的ACL 3000。如果AP本地没有这条ACL的规则，过滤动作就会因为“无规则可依”而完全失效。AC上配置看起来完整，但AP侧执行display acl 3000却看不到任何规则，过滤自然不生效。

• map-configuration是规则下发的唯一途径：由于AP无法自动从AC同步ACL规则，就必须依靠map-configuration（或configuration-profile）将完整的ACL规则内容批量推送到AP的本地Flash中。AP上线后加载这些配置，本地生成ACL 3000，服务模板的引用才能真正生效。