ACL 该挂在聚合口还是成员口
ACL 挂在逻辑聚合口上对全组生效，这是唯一能保证策略完整覆盖的位置。若只在个别物理成员口上配置，流量按哈希分散后会出现部分受控、部分不受控的情况，症状随机且极难复现。聚合组使用全局编号的 ACL，配置时注意规则编号段与挂载方向，并在成员口加入聚合组之前清理历史遗留策略。
基本信息
| 挂载位置 | 聚合口：Eth-Trunk / Port-channel / Bridge-Aggregation |
|---|---|
| 匹配方向 | 入方向用 traffic-filter inbound，出方向按平台支持情况 |
| 规则编号 | 按平台编号段，如华为高级 ACL 3000-3999 |
| 成员口 | 加入聚合组前应清理历史 ACL，避免双重过滤 |
| 生效特点 | 逻辑口策略随成员增减自动覆盖全组 |
典型使用场景
- 限制某网段经聚合链路上行访问特定服务的端口，如阻断 445 端口横向访问
- 服务器聚合口上做源地址白名单，只放行登记过的业务网段
- 安全审计前核对聚合链路策略完整性，同时看逻辑口与成员口
- 扩容新增成员口时确认策略随逻辑口自动生效，无需逐口重配
- 排查策略时有时无的问题，先确认规则挂在逻辑口而非单个成员口
配置与核对
配置与核对
acl number 3000
rule 5 deny tcp source 192.168.30.0 0.0.0.255 destination 10.0.0.0 0.0.0.255 destination-port eq 445
rule 100 permit ip # 末尾显式放行，避免误伤其他流量
interface Eth-Trunk1
traffic-filter inbound acl 3000 # 挂在逻辑口，全组生效
display acl 3000 # 核对规则命中计数输出逐列读法
| 列 | 含义 | 正常与异常 |
|---|---|---|
| rule 编号 | 规则序号，按由小到大匹配 | 顺序写错会让宽放行规则遮蔽后面的拒绝规则 |
| Matches | 该规则的命中次数 | 业务正常但计数长期为零，说明流量没走这条链路或被前置规则拦截 |
| 挂载信息 | 显示 ACL 应用在哪个接口与方向 | 成员口残留同一规则说明历史配置未清理 |
ACL 末尾务必显式写出放行或拒绝规则：依赖平台隐含拒绝时，新增业务流量容易被静默丢弃，且计数上看不出是哪条规则拦的。
部分平台对聚合逻辑口的出方向过滤支持有限，出方向策略实施前先查相应版本的配置手册确认支持范围。