摘要：今天就通过一个真实案例，深入剖析ACL配置中的“致命陷阱”，并给到你安全配置清单，帮你避开“一条命令毁全网”的悲剧。
“刚配完ACL，整个VLAN的用户全上不了网！”
“明明只拦一个IP，结果全网瘫痪……”
访问控制列表（ACL）是咱们工作中控制流量、保障安全的利器。
但它的“威力”也意味着高风险——
一条规则写错，就可能引发全网访问中断。
尤其在汇聚层或核心层部署ACL时，影响范围广，恢复不及时，可能导致业务长时间中断。
今天就通过一个真实案例，深入剖析ACL配置中的“致命陷阱”，并给到你安全配置清单，帮你避开“一条命令毁全网”的悲剧。
# 创建ACL 3000
[Huawei] acl 3000
[Huawei-acl-adv-3000] rule 5 deny ip source 192.168.10.100 0.0.0.0 destination any
[Huawei-acl-adv-3000] rule 10 permit ip source any destination any
[Huawei-acl-adv-3000] quit
# 在Vlanif 10接口入方向应用ACL
[Huawei] interface Vlanif 10
[Huawei-Vlanif10] traffic-filter inbound acl 3000
✅ 192.168.10.100 确实无法上网
❌ VLAN 10内所有用户（包括192.168.10.1）都无法上网！
❌ 用户之间也无法互访！
一条规则，导致整个VLAN业务中断。
这是ACL最常被忽视的默认行为！
当你创建一个ACL时，系统会在最后自动添加一条隐式规则：
deny ip any any
即：拒绝所有未明确允许的流量。
在上述案例中，ACL逻辑看似正确：
rule 5: 拒绝 192.168.10.100 访问任何地方
rule 10: 允许任何人访问任何地方
但问题出在——
permit ip source any destination any 并不能匹配所有流量！
ip 类型ACL：只匹配三层IP流量，不包含：
ARP（二层广播，用于IP→MAC解析）
ICMP重定向
OSPF、BGP等路由协议
当ACL应用在Vlanif接口后：
用户开机 → 发送ARP请求：“谁是192.168.10.1？”
ARP是二层广播帧，不属于ip协议
不匹配 rule 10（因为不是IP流量）
匹配隐式 deny ip any any → 被丢弃！
网关无法响应arp → 用户拿不到网关MAC → 无法通信
✅ 结论：
ip 类型ACL会意外拦截ARP，导致用户无法获取网关，全网中断。
# 方法一：先放行ARP，再控制IP流量
[Huawei] acl 3000
[Huawei-acl-adv-3000] rule 5 permit arp source-mac any destination-mac any # 允许所有ARP
[Huawei-acl-adv-3000] rule 10 deny ip source 192.168.10.100 0.0.0.0 destination any
[Huawei-acl-adv-3000] rule 15 permit ip source any destination any
[Huawei-acl-adv-3000] quit
# 方法二：只在出方向限制外网访问，不影响内网和ARP
[Huawei] interface Vlanif 10
[Huawei-Vlanif10] traffic-filter outbound acl 3000 # 改为出方向
这样，ARP请求（入方向）不受影响，只拦截该IP的出站流量。
display traffic-filter applied-record
# 查看ACL匹配计数（看是否被命中）
display acl 3000
# 查看ARP表是否正常学习
display arp all | include 192.168.10
# 抓包确认ARP是否被拦截
capture-packet interface Vlanif 10 destination flash:/arp.pcap
# 然后用Wireshark分析
记住三条铁律：
永远记得隐式 deny ip any any在Vlanif接口用ACL，必须 permit arp先测试，再上线，配置留退路 最后忠告：
当你敲下 traffic-filter 命令时，
请多问自己一句：
“这条规则，会不会把网关的ARP也拦了？”
多一秒思考，少一小时抢救。
来源：网络工程师俱乐部一点号