H3C S7510E的V5版本ACL是不是默认permit

S7510E V5 路由策略引入静态路由全部放行问题完整解析
一、先纠正核心误区：不是 ACL 默认 permit 导致的，是 route-policy 本身匹配逻辑缺陷
ACL 分两种使用场景，默认动作完全不一样
场景 1：接口报文过滤 packet-filter：ACL 末尾隐式permit any，未匹配规则的报文允许通过；
场景 2：route-policy if-match acl（路由过滤）：ACL 作为匹配工具，没有匹配上任何 rule 的路由，直接判定匹配失败；ACL 末尾不存在隐式 permit。
你的故障和 ACL 默认动作无关，根源是 route-policy 缺少兜底拒绝节点。
你当前配置的完整匹配逻辑（关键）
plaintext
route-policy FW_SERVER permit node 10
if-match acl 3100
路由匹配 ACL3100 四条 permit 网段 → 命中本 node，允许引入 OSPF；
路由不匹配 ACL3100 任何一条 → 本 node 匹配失败，进入 route-policy 下一个 node 继续匹配；
你的 route-policy 只写了 node 10，没有任何后续 deny 节点；
路由策略全局隐含规则：走完所有 node 都没匹配成功，路由直接拒绝？—— 这里你出现相反现象，说明你漏看两点：
① 静态路由存在下一跳 / 网段命中 ACL 但你误以为没命中；
② 最常见：route-policy 缺少兜底 deny 节点，很多人误以为单 node 就能过滤，实际单 node 只能放行匹配路由，不匹配的路由不会被拦截，不是 ACL 的问题。
二、完整拆解你的配置逻辑缺陷
现有配置问题
ios
acl number 3100 name Server_from_Fw
rule 10 permit ip source 192.168.9.0 0.0.0.255
rule 20 permit ip source 192.168.19.0 0.0.0.255
rule 30 permit ip source 192.168.20.0 0.0.0.255
rule 40 permit ip source 192.168.22.0 0.0.0.255

route-policy FW_SERVER permit node 10
if-match acl 3100

ospf 1
import-route static route-policy FW_SERVER
node 10 是permit模式，仅放行 ACL 匹配的 4 个网段；
所有不匹配 ACL 的静态路由，走完 node10 后无其他节点，按标准逻辑应该被拒绝；
现在不匹配网段也能引入，只有两种可能：
可能性 A（最高概率）：静态路由网段命中了 ACL 规则，你判断失误
ACL 3100 是高级 ACL，if-match acl 匹配路由时，匹配路由的目的网段；你写的source字段实际匹配路由前缀。
检查所有静态路由目的网段，是否有不在你预期但落在这 4 个网段内的子网。
可能性 B：route-policy 缺少兜底 deny 节点，历史残留空 permit 节点
设备内存在route-policy FW_SERVER permit node 100（无 if-match），无 if-match 的 permit 节点会放行所有路由，导致过滤失效。
可能性 C：ACL 匹配混淆源 / 目的，静态路由下一跳匹配了 ACL 而非前缀
高级 ACL 做路由匹配时匹配路由目的网段，如果静态路由下一跳属于这 4 段，不会命中；仅目的网段匹配才生效。
三、标准修复配置（必须加兜底 deny 节点，一劳永逸）
完整可复制配置，仅允许 ACL3100 网段引入，其余全部拦截
ios
system-view
# 原有配置保留不变
acl number 3100 name Server_from_Fw
rule 10 permit ip source 192.168.9.0 0.0.0.255
rule 20 permit ip source 192.168.19.0 0.0.0.255
rule 30 permit ip source 192.168.20.0 0.0.0.255
rule 40 permit ip source 192.168.22.0 0.0.0.255

route-policy FW_SERVER permit node 10
if-match acl 3100
# 新增兜底拒绝节点，所有不匹配node10的路由全部丢弃
route-policy FW_SERVER deny node 100

ospf 1
import-route static route-policy FW_SERVER
关键：新增node 100 deny，所有没匹配 node10 的静态路由走到 node100 直接拒绝，彻底解决全部放行问题。
四、现场排查验证命令（定位为什么不匹配网段能引入）
查看 route-policy 完整节点，检查是否存在空 permit 节点
ios
display route-policy FW_SERVER
输出中如果有 node 大于 10 且 permit、无 if-match，就是残留节点放行所有路由。
查看静态路由明细，核对目的网段是否命中 ACL
ios
display ip routing-table protocol static
对比每条静态路由目的网段，确认是否落在 3100 ACL 四条规则内。
查看 ACL 匹配计数，确认哪些网段命中规则
ios
display acl 3100
看每条 rule 的匹配次数，计数增长代表有路由命中这条规则。
验证路由策略过滤效果（测试单条路由是否被拦截）
ios
display route-policy check FW_SERVER ip-prefix 192.168.1.0 24
# 替换为你不希望引入的静态网段，看返回结果deny/permit
五、极简总结
故障根因不是 ACL 默认 permit：路由过滤场景 ACL 无末尾隐式允许；报文过滤场景 ACL 才默认 permit；
核心问题：route-policy 只配置放行节点，缺少兜底 deny 节点，或存在空 permit 残留节点放行全部路由；
修复核心：在 route-policy 末尾增加deny node 100，所有未匹配 ACL 的静态路由直接拦截；
补充排查：核对静态路由目的网段是否意外匹配 ACL 规则、检查 route-policy 是否存在多余 permit 节点。

一、 为什么其他静态路由还能被引入？

二、 V5 版本的“默认 Permit”误区从何而来？

1. 包过滤场景（Packet-filter / Traffic-filter）：当 ACL 绑定在接口上用于数据流的包过滤时，系统缺省的报文过滤动作确实是 Permit（允许未匹配上的报文通过）。
2. 路由策略/QoS 场景：正如前文所述，ACL 用在路由策略、QoS 等控制类功能时，末尾隐含的动作是 Deny（拒绝所有）。

 排查建议