华为H3C实战 | 第17章 ACL 与路由策略

📚 本系列共 43 篇（第 17 / 43 篇）　·　第二卷 路由与广域网篇 —— 让数据找到路

← 上一篇：第 16 章 IPv6 基础配置与地址自动配置 　下一篇：第 18 章 WLAN 体系与基本概念 →

本章导读：小区保安记不住每张脸，但可以定一张规则表逐条比对——这是 ACL。路由策略更进一步：不光决定放不放行，还能改属性影响全网选路。两者的共同点是——配错了通常不报错，只是静默不生效。

本章结构：

• 17.1 功能原理与业务场景 —— ACL（对数据报文）与路由策略（对路由条目）的本质区别对照表：作用对象、调用点、匹配依据全不同
• 17.2 华为设备配置详解 —— 配前三个问题（这 ACL 给谁用/默认动作/匹配顺序）、四个模板（高级 ACL 包过滤、时间范围 ACL、前缀列表 + route-policy 控制 OSPF→BGP 重发布、策略路由 PBR）、route-policy 的 node 与 if-match 匹配动作四个进阶要点
• 17.3 H3C 设备配置详解 —— 华为与 H3C 的核心差异总结，外加一次完整的策略设计演练
• 17.4 命令对照表 —— 两家并排
• 17.5 配置验证 —— display acl 逐条看匹配计数，是唯一的真相来源
• 17.6 排错与故障树 —— “先撤掉所有 ACL 试试” → 查匹配计数 → 查**通配符掩码（反掩码）**写没写反 → 查时间范围与设备时钟
• 17.7 新手踩坑 —— 反掩码写反、以为 route-policy 没匹配上会默认放行（实际是最终拒绝）
• 17.8 流量镜像（端口镜像） —— 排障的"眼睛"：镜像 ≠ 阻断、方向 inbound/outbound/both 怎么选（排障永远用 both）、VLAN Tag 带不带、华为 observe-port 与 H3C mirroring-group 两套配置、万兆镜像到千兆口会丢包
• 17.9 本章小结 —— 要点清单 + 自测题

重点提示：业务不通又找不到原因，直接按 17.6 第 1 步"撤掉 ACL 试试"，一刀切下去就能判定是不是 ACL 的事。第二条铁律：filter-policy 不影响直连路由，route-policy 没命中任何 node 就是拒绝——这两条记不住，时间全花在怀疑人生上。如果 ACL 排查完还是不通，就去 17.8 配镜像抓包——它是判断"报文到底发没发出去、回没回来"的唯一直接证据。 关联章节：ACL 常出现在 NAT（第 14 章）、包过滤和路由过滤里，机制在本章；filter-policy 用在 OSPF/BGP 上见第 11、12 章；防火墙的安全策略是 ACL 思路的进阶版（第 26、27 章）；端口侧的流量控制见第 9 章。

17.1 功能原理与业务场景

17.1.1 这功能是干嘛的（通俗版）

一个小区有几千户人家，门口保安不可能记住每户每个人的脸，但他可以先定几条规则：本小区业主刷卡进、外卖员登记后进、快递员只许在工作时间进 3 号楼、装修队周一至周五 9 点到 18 点能进、其他一律不让进。保安不是靠"记住谁"，而是靠一张规则表 + 逐条比对来干活。

访问控制列表（ACL，Access Control List）就是这张规则表。它由若干条规则组成，每条规则描述"什么样的报文算匹配"，并给出"匹配后是放行（permit）还是拒绝（deny）"。设备收到一个报文，就从上到下逐条比对，命中哪条就按哪条处理，后面的不再看。

路由策略（Routing Policy）则是在此基础上更进一步：它不只决定"放不放行"，还能决定"要不要改"。就像保安不只能拦人，还能给符合条件的访客换个胸牌颜色、指定走哪个门——路由策略可以给路由改属性（改优先级、加 AS 路径、打团体属性），从而影响整个网络怎么选路。

17.1.2 在网络里怎么落地（设计视角）

先分清两个容易混的概念：ACL 是"包过滤的规则表"，路由策略是"路由信息的加工流水线"。两者用的匹配工具（ACL、前缀列表）有重叠，但作用对象完全不同：

按匹配能力，华为与 H3C 的 ACL 都分成三个大类，编号区间是硬规矩，写错区间设备会直接报错：

规则匹配有几条铁律，先记住再往下看：

1. 自上而下逐条匹配，命中即停。所以"精确的规则放前面、宽泛的规则放后面"。
2. 匹配顺序有两种模式：配置顺序（config）和自动排序（auto）。自动排序按"精度"重排规则，容易让人误判，新手一律用配置顺序，看到的顺序就是生效的顺序。
3. 末尾隐含一条"拒绝所有"。所以只写 permit 规则时，没被匹配到的流量会被丢掉——这是最常见的"配了 ACL 反而全断"的原因。
4. ACL 被引用后才有意义。建了 ACL 没人调用，等于没建；调用点决定它是过滤报文还是过滤路由。

再往下，路由策略的核心工具是前缀列表（ip-prefix）。它和 ACL 的区别是：ACL 只能匹配"地址范围"，前缀列表能同时匹配"网段 + 掩码长度范围"，比如"只匹配掩码长度在 24 到 28 之间的 192.168.0.0/16 的子网"。这个能力在路由过滤里非常关键。

本章的典型落地场景有三个，后面每节都会用到：

• 场景一：限制某个部门只能访问特定的服务器端口（高级 ACL + 接口过滤）。
• 场景二：OSPF 重发布进 BGP 时只允许特定网段、并给路由打上团体属性（前缀列表 + route-policy）。
• 场景三：内网两条出口链路，让某个网段强制走其中一条（策略路由 PBR）。

适用版本：华为 VRP V200R019 及以上（S5700/AR6000 系列）；H3C Comware V7（R2610 及以上）。

17.2 华为设备配置详解

17.2.0 配置前必须先想清楚的三件事

在敲第一条 acl number 之前，先把下面三个问题回答清楚。这三个问题想不明白，配出来的 ACL 一定是"看着对、就是不生效"。

问题一：这个 ACL 到底给谁用。同一个 acl number 3000，挂在接口 traffic-filter 上就是"过滤经过的报文"，被 nat outbound 引用就是"圈定哪些源地址要被翻译"，被 traffic classifier 引用就是"挑出哪些报文要走特殊路径"。ACL 本身不带"用途"，用途由调用点决定。所以设计的第一句话应该写成"我要在 GE0/0/1 的入方向，把办公网访问服务器区的流量按端口放行或拒绝"——而不是"我要建一个 ACL 3000"。前者能落地，后者容易配完就忘。

问题二：默认动作想清楚了吗。ACL 末尾隐含一条"拒绝所有"，这件事有两个方向的后果：如果你想要的是"白名单"（只放行某些，其余拒），那正好，写几条 permit 就完事；如果你想要的是"黑名单"（只拒绝某些，其余放），那必须自己补一条 rule permit ip 兜底，否则全断。新手十次"配了 ACL 就全断"，八次是没有兜底规则、两次是通配符掩码写反。

问题三：匹配顺序和规则精度怎么排。规则是自上而下、命中即停，所以原则是"精确在前、宽泛在后"。但这里有个进阶陷阱：如果两条规则都能匹配同一个报文，而你在中间插入了一条新规则，新规则的位置决定它能不能生效。生产环境维护 ACL 的正确做法是规则序号留间隔（5、10、15、20……而不是 1、2、3），将来要插规则时正好有号可用，不用推倒重排。

17.2.1 命令行基础速览（本章会用到的那几条）

华为的 ACL 命令在 VRP V200R019 之后有一段过渡：老写法是 acl number 3000 然后进 [HUAWEI-acl-adv-3000] 视图，新写法是 acl name XXX advance。两种都能用，本章统一用老写法（兼容性最好），并在差异处标注。

17.2.2 完整配置模板

模板一：高级 ACL 做包过滤。需求：办公网 192.168.10.0/24 只允许访问服务器区 192.168.20.10 的 Web（80）和邮件（25、110）端口，其他访问服务器的流量全部拒绝，但允许访问互联网。

# 进入系统视图
system-view
sysname HUAWEI

# 创建高级 ACL 3000，按配置顺序匹配
acl number 3000
 match-order config

 # 规则 5：先放行到邮件服务器的 25 端口
 rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.10 0 destination-port eq 25

 # 规则 10：放行到邮件服务器的 110 端口
 rule 10 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.10 0 destination-port eq 110

 # 规则 15：放行到 Web 服务器的 80 端口
 rule 15 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.10 0 destination-port eq 80

 # 规则 20：拒绝办公网访问服务器区的其他所有流量
 rule 20 deny ip source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255

 # 规则 30：其余流量放行（含访问互联网）
 rule 30 permit ip

 quit

# 在内网接口入方向调用
interface GigabitEthernet0/0/1
 traffic-filter inbound acl 3000
 quit

save

模板二：时间范围 ACL。需求：只在工作日 8:00~18:00 允许访客网段访问内网办公服务器，下班后一律禁止。

# 先定义时间范围：工作日 8:00~18:00，关键字 working-day 两家通用
time-range WORK_TIME 08:00 to 18:00 working-day
time-range OFF_HOUR 18:00 to 08:00 daily

# 在 ACL 规则上引用时间范围
acl number 3001
 rule 5 permit tcp source 172.16.5.0 0.0.0.255 destination 192.168.20.10 0 destination-port eq 443 time-range WORK_TIME
 rule 10 deny ip source 172.16.5.0 0.0.0.255 destination 192.168.20.0 0.0.0.255
 rule 20 permit ip source 172.16.5.0 0.0.0.255
 quit

# 挂到接口
interface GigabitEthernet0/0/2
 traffic-filter inbound acl 3001
 quit

时间范围依赖设备时钟，先配 NTP 或手工改时间，否则规则永远匹配不上或一直匹配，这是时间 ACL 最隐蔽的坑。

模板三：前缀列表 + route-policy 控制 OSPF 到 BGP 的重发布。需求：OSPF 内部有 192.168.0.0/16 下的很多子网，重发布进 BGP 时只允许掩码长度 16~28 的网段，且给这些路由打上团体属性 65001:100。

# 前缀列表：允许 192.168.0.0/16 下掩码 16 到 28 的网段
ip ip-prefix PERMIT_LAN index 10 permit 192.168.0.0 16 less-equal 28

# 加一条精确拒绝，防止后面漏项
ip ip-prefix PERMIT_LAN index 20 deny 0.0.0.0 0 less-equal 32

# 路由策略：只 permit，动作是打团体属性
route-policy RP_TO_BGP permit node 10
 if-match ip-prefix PERMIT_LAN
 apply community 65001:100
 quit

# BGP 里引用这个策略做重发布过滤
bgp 65001
 peer 172.16.0.1 as-number 65002
 import-route ospf 1 route-policy RP_TO_BGP
 peer 172.16.0.1 advertise-community
 quit

save

模板四：策略路由 PBR。需求：192.168.10.0/24 的流量强制走链路 A（GigabitEthernet0/0/2，下一跳 172.16.1.1），其余流量按路由表走。

# 用 ACL 匹配需要特殊走法的源网段
acl number 3010
 rule 5 permit ip source 192.168.10.0 0.0.0.255
 quit

# 流量行为：指定下一跳
traffic behavior BEHAVIOR_TO_ISP_A
 redirect ip-nexthop 172.16.1.1
 quit

# 流量分类：关联 ACL
traffic classifier CLASS_TO_ISP_A operator or
 if-match acl 3010
 quit

# 流量策略：把分类和行为绑起来
traffic policy POLICY_TO_ISP_A
 classifier CLASS_TO_ISP_A behavior BEHAVIOR_TO_ISP_A
 quit

# 在入接口上调用
interface GigabitEthernet0/0/1
 traffic-policy POLICY_TO_ISP_A inbound
 quit

save

17.2.3 逐行讲解

关于 route-policy 的几条细节，必须一次讲透：

node 与匹配动作的关系。每个 node 其实有四种状态：permit 匹配上、permit 没匹配上、deny 匹配上、deny 没匹配上。行为完全不同——permit 匹配上就等于"最终放行并改属性"；permit 没匹配上就去看下一个 node；deny 匹配上等于"最终拒绝"；deny 没匹配上也是看下一个 node。所以写 permit node 10 + deny node 20 + permit node 30 是常见套路，但如果所有 node 都没匹配上，最终结果是拒绝——这一点很多人以为"没匹配上就默认放行"，那就全错了。

show 的顺序。路由策略里 if-match 是"与"，同一个 node 里写两个 if-match ip-prefix 就要求两个都满足，几乎不可能命中。想表达"或"，得写两个 node。

关于 filter-policy。它是在协议层面过滤路由：export 过滤发出去的，import 过滤收进来的。filter-policy ip-prefix X export 的语义是"只发匹配 X 的路由"，注意是"只发匹配的"，没有写允许的默认是拒绝。

一条重要提醒：filter-policy 与 route-policy 的"默认动作"方向不同。filter-policy 配了之后是"允许匹配的，拒绝其余"；route-policy 是所有 node 都不匹配时"拒绝"。两者都不写兜底规则时，前者会把路由过滤得只剩匹配项、后者会把路由全滤掉。

17.2.4 route-policy 的四个进阶要点

要点一：if-match 的多种类型可以组合，但要分清"与"和"或"。同一个 node 内多条 if-match 是"与"，跨 node 是"或"。举例：想表达"匹配 192.168.20.0/24 且下一跳是 172.16.0.1"用一条 node 里写两个 if-match；想表达"匹配 192.168.20.0/24 或者掩码长度等于 32"就用两个 node。写错的表现是"策略配了但路由一条没变"或者"策略把不该过滤的路由滤掉了"，都很难凭肉眼发现。

要点二：apply 的执行时机。apply 只有在 node 的动作是 permit 且匹配成功时才执行；deny 节点里的 apply 是不执行动作直接拒绝。这一点在写"黑名单 + 改属性"的组合时要小心，你无法在 deny 节点里顺便改点东西再放行。

要点三：ip-prefix 与 ACL 的选择。能用前缀列表就别用 ACL 做路由过滤。原因是 ACL 的 rule permit ip source 192.168.0.0 0.0.255.255 只能匹配地址范围，无法限制掩码长度，所以它会同时放行 192.168.0.0/16、192.168.20.0/24、192.168.20.30/32 全部路由——在路由过滤里这几乎一定是错的。前缀列表天然带"掩码长度"维度，是路由过滤的正确工具。

要点四：策略验证的"三段式"。一是策略挂上了没有（在协议视图 display this 里能看到 import-route ospf 1 route-policy RP_TO_BGP）；二是重发布进来的路由有没有带上属性（display bgp routing-table 看 Community 列）；三是邻居收到没有（在对端设备上看 display bgp peer verbose 的路由收发计数，收到了但没有生效往往是下一跳不可达）。

下面这一段是完整的属性验证命令，配完就敲一遍，别等出问题再补：

# 查看重发布进 BGP 的路由与属性
display bgp routing-table

# 只看带指定团体属性的路由
display bgp routing-table community 65001:100

# 查看对端邻居的收发路由数量与状态
display bgp peer verbose

验收标准三句话：挂载点对、命中计数涨、业务现象符合预期。缺一条都不算配完。

17.3 H3C 设备配置详解

H3C Comware V7 的 ACL 与路由策略与华为高度同构，主要差异在命令视图名字和参数写法上。最容易记串的三处：H3C 用 acl basic / acl advanced（华为用 acl number），H3C 的 route-policy 里匹配前缀列表用 if-match ip-prefix 但前缀列表命令是 ip prefix-list（多一个空格），H3C 的策略路由用 qos policy 而不是 traffic policy。

模板一：高级 ACL 做包过滤（与华为完全同一需求）：

# 进入系统视图
system-view
sysname H3C

# 创建高级 ACL 3000
acl advanced 3000
 rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.10 0 destination-port eq 25
 rule 10 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.10 0 destination-port eq 110
 rule 15 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.10 0 destination-port eq 80
 rule 20 deny ip source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255
 rule 30 permit ip
 quit

# 在内网接口入方向调用，H3C 用 packet-filter
interface GigabitEthernet1/0/1
 packet-filter 3000 inbound
 quit

save force

模板二：时间范围 ACL。H3C 用 time-range 直接定义名称与时段，工作日关键字与华为一样写 working-day（单数，两家的官方示例都是单数）：

# 定义工作日 8 点到 18 点的时间范围
time-range WORK_TIME 08:00 to 18:00 working-day

# 在规则上引用
acl advanced 3001
 rule 5 permit tcp source 172.16.5.0 0.0.0.255 destination 192.168.20.10 0 destination-port eq 443 time-range WORK_TIME
 rule 10 deny ip source 172.16.5.0 0.0.0.255 destination 192.168.20.0 0.0.0.255
 rule 20 permit ip source 172.16.5.0 0.0.0.255
 quit

interface GigabitEthernet1/0/2
 packet-filter 3001 inbound
 quit

⚠ 版本差异：time-range <名字> <起> to <止> working-day 这个写法华为与 H3C 一致，关键字都是 working-day（单数）。这方面两家没有差异，别被网上的二手资料误导成「H3C 要用复数」。 出处：

• H3C：01-ACL配置 原文 [DeviceA] time-range work 08:0 to 18:00 working-day；01-ACL配置（V7 另一版本） 原文 Device time-range work 08:00 to 18:00 working-day。两处官方示例均为单数。
• 华为：ACL 配置命令 原文 time-range test 8:00 to 18:00 working-day。 结论：两家都写 working-day，本章原稿曾误写为 working-days（复数）并声称「写单数会报错」，已按官方原文更正。

模板三：前缀列表 + route-policy 控制重发布。H3C 的前缀列表命令是 ip prefix-list，匹配时用 index：

# 前缀列表：允许 192.168.0.0/16 下掩码 16 到 28 的网段
ip prefix-list PERMIT_LAN index 10 permit 192.168.0.0 16 less-equal 28

# 兜底拒绝，防止默认放行
ip prefix-list PERMIT_LAN index 20 deny 0.0.0.0 0 less-equal 32

# 路由策略：H3C 的 node 视图里用 if-match ip-prefix
route-policy RP_TO_BGP permit node 10
 if-match ip-prefix PERMIT_LAN
 apply community 65001:100
 quit

# BGP 中引用
bgp 65001
 address-family ipv4 unicast
  peer 172.16.0.1 as-number 65002
  peer 172.16.0.1 enable
  import-route ospf 1 route-policy RP_TO_BGP
  peer 172.16.0.1 advertise-community
  quit
 quit

save force

模板四：策略路由 PBR。H3C V7 走的是 QoS 框架：traffic classifier + traffic behavior + qos policy，接口下 qos apply policy 调用。

# 用 ACL 匹配需要特殊走法的源网段
acl advanced 3010
 rule 5 permit ip source 192.168.10.0 0.0.0.255
 quit

# 流量行为：指定下一跳
traffic behavior BEHAVIOR_TO_ISP_A
 redirect next-hop 172.16.1.1
 quit

# 流量分类
traffic classifier CLASS_TO_ISP_A operator or
 if-match acl 3010
 quit

# QoS 策略：把分类和行为绑起来
qos policy POLICY_TO_ISP_A
 classifier CLASS_TO_ISP_A behavior BEHAVIOR_TO_ISP_A
 quit

# 在入接口上调用
interface GigabitEthernet1/0/1
 qos apply policy POLICY_TO_ISP_A inbound
 quit

save force

H3C 另外还提供一套 policy-based-route（策略路由）体系，结构与华为的 traffic policy 不同，更接近"路由策略"的写法：

# 定义策略路由节点：匹配 ACL 3010 的流量，把下一跳指到 172.16.1.1
policy-based-route PBR_LOCAL permit node 10
 if-match acl 3010
 apply next-hop 172.16.1.1
 quit

# 在接口上应用（处理该接口收到的报文）
interface GigabitEthernet1/0/1
 ip policy-based-route PBR_LOCAL
 quit

注意 H3C 有两套策略路由，视图与命令都不一样，别混用：

出处：H3C《07-策略路由配置》原文示例——[SwitchA] policy-based-route aaa permit node 5 / [SwitchA-pbr-aaa-5] apply next-hop 1.1.2.2 / [SwitchA] interface vlan-interface 11 / [SwitchA-Vlan-interface11] ip policy-based-route aaa，见 H3C 07-策略路由配置 、H3C 08-策略路由配置 。

⚠ 版本差异：H3C 的 policy-based-route 与华为的"本地策略路由"（policy-based-route）命令名相近但细节不同；H3C V7 的接口应用命令是 ip policy-based-route <名字>。V5 老设备提示：V5 里策略路由同样是 policy-based-route 体系。

一个必须知道的华为侧行为：redirect ip-nexthop 指定的下一跳如果 ARP 学不到，报文会按原始转发路径走，重定向静默不生效——这是华为官方配置注意事项里写明的。所以 PBR 配完一定用 tracert 验证实际路径，而不是只看配置存在。 出处：华为 redirect ip-nexthop 命令参考 、通过流策略实现策略路由 验证命令已核实：display traffic policy 与 display traffic-policy applied-record 两条命令都存在（华为命令参考 IS-IS/QoS 章节索引中均列出）。出处：NetEngine AR1000V V300R021 命令参考 。 time-range 周期关键字已核实：华为官方命令参考全文中出现的关键字为 working-day（3 次）、daily（20 次）、off-day（2 次）；working-days（复数）出现 0 次——再次印证两家都用单数。本章用到的 working-day 与 daily 均已在官方示例中出现。出处同上一行。

17.3.1 华为 H3C 核心差异总结

把上面四个模板逐条对照，能看出两家的设计哲学差别：华为把"包过滤"和"策略路由"分成两套独立体系（traffic-filter 和 traffic policy），H3C 则把策略路由并入 QoS 框架（qos policy）。这不是谁对谁错，是两家的产品演进路径不同。给零基础读者的实用建议是：先把华为那套学会，因为它的概念模型更清晰；学 H3C 时重点记三个替换：traffic-filter → packet-filter、traffic policy → qos policy、traffic-policy → qos apply policy。

三者的对应关系还可以再往下拆一层：华为的 traffic classifier 对应 H3C 的 traffic classifier，两者语法几乎一样，都是 operator or / operator and 加 if-match；华为的 traffic behavior 对应 H3C 的 traffic behavior，差别只在 redirect 后面的参数写法。真正不同构的是最外层：华为叫"流量策略（traffic policy）"，挂在接口上用 traffic-policy；H3C 叫"QoS 策略（qos policy）"，挂在接口上用 qos apply policy。所以从华为转 H3C 的人，最容易在最后一步"挂不上去"上卡住——前面的分类、行为、策略都建对了，就是接口上那条命令想不起来。

另外还有两个容易忽略的差异：

第一，ACL 规则的默认动作。两家都是"末尾隐含拒绝"，但华为在 display acl 输出里会显式打印一条 rule 1000 deny ip 之类的隐含规则（具体编号视版本），H3C 有些版本不打印。所以看 H3C 的 display acl 时没看到拒绝规则，不代表没有拒绝。

第二，路由策略的默认动作。两家都是"所有 node 都不匹配 = 拒绝"，但 H3C 的 route-policy 在部分版本里允许配 apply 动作但不写 if-match 时表现为全匹配，这点在写"给所有路由打团体属性"的规则时格外要注意——华为要求 if-match 才生效，H3C 有的版本不写就是匹配全部。

17.3.2 一次完整的策略设计演练

把上面四个模板串起来，看一个真实场景怎么从需求走到配置。需求：某公司有办公网 192.168.10.0/24、研发网 192.168.11.0/24、访客网 172.16.5.0/24、服务器区 192.168.20.0/24，双出口接入两家运营商，要求：

• 研发网访问服务器区不受限，办公网只能访问服务器的 80/443，访客网工作时间内可访问服务器的 443；
• 所有访问互联网的流量，办公网走运营商 A，研发网走运营商 B；
• 服务器区的网段只允许向运营商宣告，不允许向内网其它网段泄漏。

逐条拆解成设备配置：

# 第一步：访客网只允许在工作时间访问 443，其余拒绝
time-range WORK_TIME 08:00 to 18:00 working-day
acl number 3001
 rule 5 permit tcp source 172.16.5.0 0.0.0.255 destination 192.168.20.10 0 destination-port eq 443 time-range WORK_TIME
 rule 10 deny ip source 172.16.5.0 0.0.0.255 destination 192.168.20.0 0.0.0.255
 rule 20 permit ip source 172.16.5.0 0.0.0.255
 quit

# 第二步：办公网只能访问服务器的 80/443
acl number 3002
 rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255 destination-port eq 80
 rule 10 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255 destination-port eq 443
 rule 15 deny ip source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255
 rule 20 permit ip
 quit

# 第三步：两个出口的流量分类，办公网走 A、研发网走 B
acl number 3010
 rule 5 permit ip source 192.168.10.0 0.0.0.255
 quit
acl number 3011
 rule 5 permit ip source 192.168.11.0 0.0.0.255
 quit

# 第四步：两条策略路由，分别指定下一跳
traffic behavior TO_ISP_A
 redirect ip-nexthop 172.16.1.1
 quit
traffic behavior TO_ISP_B
 redirect ip-nexthop 172.16.2.1
 quit
traffic classifier CLS_A operator or
 if-match acl 3010
 quit
traffic classifier CLS_B operator or
 if-match acl 3011
 quit
traffic policy PBR_DUAL
 classifier CLS_A behavior TO_ISP_A
 classifier CLS_B behavior TO_ISP_B
 quit

# 第五步：服务器区路由只向单方向发布，用前缀列表精确限定
ip ip-prefix SRV_ONLY index 10 permit 192.168.20.0 24
ip ip-prefix SRV_ONLY index 20 deny 0.0.0.0 0 less-equal 32

# 第六步：接口上调用
interface GigabitEthernet0/0/1
 traffic-filter inbound acl 3001
 traffic-filter inbound acl 3002
 quit
interface GigabitEthernet0/0/3
 traffic-policy PBR_DUAL inbound
 quit

save

这个演练要说明三件事。第一，同一个接口可以挂多个 ACL，前提是它们针对的流量互不重叠，否则第一条命中即停的规则会吞掉后面的判定。第二，策略路由只影响"从哪个口出去"，不影响"这个报文能不能进来"——能不能进来靠 traffic-filter，两者要分开设计。第三，前缀列表的双向兜底（一条 permit + 一条 deny 所有）是路由过滤的安全带，永远两条一起写。

17.4 华为 / H3C 命令对照表

17.5 配置验证

ACL 是否生效，看匹配计数是最硬的证据。华为用 display acl all：

display acl all

期望看到每条规则后面有匹配计数在增长：

Basic ACL 3000, 5 rules
Acl's step is 5
 rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.10 0 destination-port eq www (128 matches)
 rule 20 deny ip source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255 (37 matches)
 rule 30 permit ip (1021 matches)

重点看三个数字：放行规则有匹配、拒绝规则有匹配、兜底规则有匹配，说明 ACL 真的在起作用而且规则顺序是对的。如果拒绝规则的计数是 0，多半是前面的放行规则把流量都吸走了。

接口上调用得对不对，用 display current-configuration interface 看：

display current-configuration interface GigabitEthernet0/0/1

期望输出里有 traffic-filter inbound acl 3000 这一行。H3C 上对应 packet-filter 3000 inbound。

验证时间范围是否生效，先看时钟再等一会儿看计数：

# 确认设备时间在时间范围内
display clock

# 再看 ACL 匹配计数，时间范围外计数应该不增长
display acl 3001

验证前缀列表，用 display ip ip-prefix（H3C 是 display ip prefix-list）：

display ip ip-prefix PERMIT_LAN

期望看到 index 10 permit 192.168.0.0/16 greater-equal 16 less-equal 28 这样的展开描述——注意这里必须同时出现 greater-equal 和 less-equal，只写 less-equal 时设备会把 greater-equal 默认成前面的前缀长度 16。

验证路由策略是否真的改了属性，去邻接的路由表里看：

display bgp routing-table community

期望能看到从本端发出的路由带有 65001:100 团体属性。如果看不到，先查 advertise-community 有没有配。

验证策略路由生效，用 tracert 从内网 PC 出去，看第一条跳是不是 172.16.1.1，而不是按路由表算出的下一跳。

17.6 排错与故障树

ACL 和路由策略的排错有一个共同的致命问题：配置错了通常不报错，只是静默不生效。所以必须靠"匹配计数 + 逐段抓包"来定位。故障树如下：

现象：某个业务不通
 ├─ 1. 先把 ACL 全部撤掉试试
 │   └─ 撤掉就通了 → 100% 是 ACL 问题，往下走
 ├─ 2. 看 ACL 匹配计数
 │   ├─ 所有规则计数都不涨 → ACL 没被调用 / 调错了接口 / 方向反了
 │   └─ 某条规则计数暴涨 → 规则顺序或匹配条件写错
 ├─ 3. 检查通配符掩码
 │   ├─ 0.0.0.255 表示前 24 位固定、后 8 位任意（想成"反掩码"就不会错）
 │   └─ 写反了 → 匹配范围完全不对，计数会异常
 ├─ 4. 检查时间范围
 │   ├─ display clock 看设备时间对不对
 │   └─ 时间范围外的规则永远不匹配
 └─ 5. 路由类问题单独走查
     ├─ filter-policy 只在协议层面生效，不影响直连路由
     ├─ route-policy 没匹配上 = 最终拒绝（不是默认放行）
     └─ BGP 团体属性要 advertise-community 才传出

通配符掩码陷阱要展开说。这是新手最常错的一处。ACL 里写的 0.0.0.255 是通配符掩码（wildcard mask），不是子网掩码。它的语义是"该位为 0 表示必须匹配，为 1 表示不关心"。所以 192.168.10.0 0.0.0.255 的意思是"前 24 位必须等于 192.168.10，最后 8 位任意"，等价于 192.168.10.0/24。而 192.168.10.0 255.255.255.0 的意思是"前 8 位固定、后 24 位任意"，等于匹配了 192.x.x.x 整个 A 类范围——这个错误极难从配置文件表面看出来，只能靠计数和 ping 定位。

一个隐蔽的坑：ACL 的空规则。新建的 ACL 里如果只有 permit 没有 deny，末位隐含拒绝所有。但如果只有一条 deny ip 没有 permit，那就是拒绝所有。更隐蔽的是，引用一个空 ACL（一条规则都没有）时，行为取决于调用点的实现：有些版本空 ACL 等于"全放行"（因为没有任何规则匹配，走隐含规则之前的判定逻辑），有些版本等于"全拒绝"。所以永远不要引用空 ACL。

怎么一眼看出 ACL 规则顺序错了。用一个简单的判据：去查匹配计数最大的那条规则是哪条。正常设计里，匹配计数最大的应该是兜底的 permit ip（它要兜住所有上网流量），其次是精确的放行规则。如果某条 deny 的计数排在最前面、而且远超其他规则，基本可以断定它排在了本该放行的规则前面，或者它的通配符范围写得过大。这个判据不需要抓包、不需要登到 PC 上，一条 display acl all 就能得到结论，是现场排查最快的招。

抓包是最后手段，但不是唯一手段。设备上还有几个不花钱的辅助手段：一是 display traffic-filter applied-record，能直接列出"哪个接口的哪个方向调用了哪个 ACL"，一次看清全部挂载点，避免漏挂或重挂；二是 reset counters interface 之后观察接口出入方向和丢包计数，能判断包是被丢了还是根本没来；三是策略路由场景下，从内网 PC 上 tracert 到外网，第一条跳即是实际出口，比看配置文件直观得多。

四类典型现象与结论对照表，现场有个这张表就能少走弯路：

17.7 新手踩坑与注意事项

1. 用子网掩码当通配符用——0.0.0.255 才是掩码 24，255.255.255.0 是翻了个天，错误极难发现。
2. 忘写末尾 permit——ACL 末尾隐含拒绝，只写 deny 规则等于把对应的流量全部拒掉，包括本该放行的。
3. ACL 建了没调用——建完 ACL 一定要在接口或其它功能里引用，否则它只是一张纸。
4. 调用方向搞反——inbound 是"从接口进来的方向"，outbound 是"从接口出去的方向"，改完配置务必用计数验证。
5. 编号区间写错——基本 ACL 里写 destination 会直接报错，反过来高级 ACL 用 rule permit source x 只匹配源地址时行为正确但容易被误读，建议一律用高级 ACL。
6. 时间范围写了但设备时间不对——先配 NTP，display clock 确认时区与时间都正确。
7. 前缀列表不加 less-equal——这是路由过滤的头号杀手，导致"过滤后只剩一条路由"。
8. route-policy 没匹配上就当放行——错，没匹配上最终是拒绝，必须有兜底 node。
9. BGP 团体属性没加 advertise-community——本地打上了标记，邻居收不到。
10. 策略路由与路由表打架——PBR 优先级高于路由表，配了 PBR 的那部分流量不再看路由表，写完必须 tracert 验证一遍。
11. 改 ACL 时直接删规则——删掉一条 permit 后底下的 deny 会立刻生效，业务可能瞬间全断，改前先 display 截图。
12. 不同版本的默认匹配顺序不同——有的版本 auto 排序会打乱，一律显式写 match-order config。
13. ACL 规则只增不删——历史规则越堆越多，最后没人敢动。正确做法是每次变更都同步更新注释和归档，一年清理一次。
14. 在交换机上做策略路由期待"所有流量都改走"——PBR 只对入方向调用的那部分流量有效，回程流量仍然按路由表走，单向策略路由会导致回包走另一条链路。要么两边都配，要么改用路由层面的方案（改优先级、改 cost）。
15. 把 ACL 当成表来"读"而不当成流程来"跑"——看配置时要在脑子里从上往下走一遍报文，先问"这个源 IP 会命中第几条"，才能看出顺序问题。

17.8 流量镜像（端口镜像）

17.8.1 这功能是干嘛的（通俗版）

你怀疑家里的水管漏水，但管子埋在墙里看不见。怎么办？在管子上接一个三通阀，把水复制一份引到一个桶里，你在桶那儿慢慢观察——水照样往原来的方向流，你只是多了一份"样本"。

流量镜像（Port Mirroring / Mirrored Traffic）就是给网络接口接一个"三通阀"。交换机把某个接口进出的报文原样复制一份，从另一个指定接口送出去，你在那个接口上接一台装了 Wireshark 的电脑，就能看到全量报文。

三个关键点先记住：

• 镜像 ≠ 阻断。它只是复制，不影响原流量的转发。想拦流量得用上一节讲过的 ACL。
• 镜像 ≠ 抓本机。你在自己电脑上抓包，只能抓到发给你的、以及广播报文；镜像能让你看到"别人的流量"——这才是它能做排障和审计的原因。
• 镜像有成本。复制出来的报文一样占带宽，配不好还会把业务拖慢。

三大用途：

17.8.2 核心概念

先分清四个角色，这是配镜像最容易搞混的地方：

方向怎么选，这是新手第一个大坑：

举个具体的：用户投诉"网页打不开"，如果你只抓 inbound，你会看到用户的 TCP SYN 包发出去了；但你看不到服务器有没有回 SYN-ACK。只抓一半，就断不了案。所以排障第一动作永远是 both。

VLAN 标签行为。这是第二个大坑。镜像出来的报文到底带不带 VLAN Tag？

如果分析设备（比如普通 PC 上的 Wireshark）不认 VLAN Tag，你抓到的报文可能显示不出正常的 IP 层；反之，如果你需要看到 Tag 来判断 VLAN 问题，就必须保留 Tag。这一点必须在上线前确认，配错了现象是"能抓到包但解析不出来"。

17.8.3 华为设备配置详解

华为的端口镜像分两步：先定义观察端口（全局），再在源端口上引用它。

第一步：定义观察端口。在系统视图下配，给这个"三通阀"分配一个索引号：

# 进入系统视图
system-view
sysname HUAWEI

# 定义观察端口 1：把 GigabitEthernet0/0/24 作为镜像出口
observe-port 1 interface GigabitEthernet0/0/24

官方命令格式是 observe-port [ observe-port-index ] interface interface-type interface-number，索引号可省（省了默认 1）。

第二步：在源端口上开启镜像。进到要被监控的那个接口，指定抓哪个方向：

# 监控 GigabitEthernet0/0/1，双向抓包
interface GigabitEthernet0/0/1
 port-mirroring to observe-port 1 both
 quit

官方格式：port-mirroring to observe-port observe-port-index { both | inbound | outbound }。

一个完整例子（监控接入口的同时，把镜像从 24 口送给分析机）：

system-view
sysname HUAWEI

# 1) 定义观察端口（接分析电脑的口）
observe-port 1 interface GigabitEthernet0/0/24

# 2) 在要监控的接入口上开启双向镜像
interface GigabitEthernet0/0/1
 port-mirroring to observe-port 1 both
 quit

# 3) 一次监控多个口：重复第 2 步即可，多个源端口可以共享同一个 observe-port
interface GigabitEthernet0/0/2
 port-mirroring to observe-port 1 both
 quit

save

第三步（进阶）：流镜像——只镜像"符合条件"的流量

上面的做法是"整个口全抓"，流量大的时候会给观察口造成巨大压力。如果只想看"某个网段访问某个服务器的流量"，就要用流镜像（ACL 方式），思路和上一节的 traffic policy 完全一样：

# 1) 用高级 ACL 圈出要镜像的流量（复用 17.2 讲过的高级 ACL）
acl number 3000
 rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.10 0 destination-port eq 80
 quit

# 2) 定义流量行为：动作为"镜像到观察端口 1"
traffic behavior MIRROR_WEB
 mirror to observe-port 1
 quit

# 3) 定义流量分类：匹配上面那条 ACL
traffic classifier CLASS_WEB operator or
 if-match acl 3000
 quit

# 4) 组装成流量策略
traffic policy POLICY_MIRROR
 classifier CLASS_WEB behavior MIRROR_WEB
 quit

# 5) 在源端口入方向调用
interface GigabitEthernet0/0/1
 traffic-policy POLICY_MIRROR inbound
 quit

流行为里的命令格式是 mirror to observe-port { both | inbound | outbound }（不带方向时按配置位置决定）。

第四步：验证

# 看观察端口配在哪、参数是什么
display observe-port

# 看各接口的镜像关系
display port-mirroring

# 看流镜像（ACL 方式）的实际生效情况，能看到命中计数
display traffic-applied interface GigabitEthernet0/0/1 inbound

display observe-port 的典型输出（注意 Untag-packet 和 Forwarding 两行，它们决定了镜像报文带不带 Tag、观察口是否还做正常转发）：

 ----------------------------------------------------------------------
 Index : 1
 Untag-packet : No
 Forwarding : No
 Interface : GigabitEthernet0/0/2
 Vlan : 10

出处：

• observe-port [ observe-port-index ] interface interface-type interface-number、port-mirroring to observe-port observe-port-index { both | inbound | outbound }：华为命令参考（references/huawei/EDOC1100333406.txt、EDOC1100420127.txt 等，VRRP/镜像相关章节）
• mirror to observe-port { both | inbound | outbound } 与 display observe-port、display traffic-applied 输出样例：references/huawei/EDOC1000069579.txt（Sx300 典型配置案例，第 46999~47010 行附近）
• display port-mirroring：多份命令参考中出现（references/huawei/ 共 65 处）

17.8.4 H3C 设备配置详解

H3C 的组织方式和华为不同：不单独定义"观察端口"，而是先建一个"镜像组"，再往组里填源端口和目的端口。

本地镜像组配置（最常用）：

# 进入系统视图
system-view
sysname H3C

# 1) 创建本地镜像组 1
mirroring-group 1 local

# 2) 指定源端口及方向（可一次写多个端口）
mirroring-group 1 mirroring-port gigabitethernet 1/0/1 gigabitethernet 1/0/2 both

# 3) 指定目的端口（接分析设备的口）
mirroring-group 1 monitor-port gigabitethernet 1/0/24

save force

官方还推荐一个动作：在目的端口上关闭 STP。原因很实在——目的端口只往外发镜像报文、不参与正常转发，让它参与生成树计算没有意义，还可能因为 BPDU 处理影响镜像：

# 在目的端口上关闭生成树（H3C 官方配置举例中的做法）
interface GigabitEthernet 1/0/24
 undo stp enable
 quit

接口视图下的另一种写法（当源端口/目的端口分散时更好用）：

# 在接口视图里把自己指定为镜像组 1 的源端口
interface GigabitEthernet 1/0/1
 mirroring-group 1 mirroring-port both
 quit

# 在接口视图里把自己指定为镜像组 1 的目的端口
interface GigabitEthernet 1/0/24
 mirroring-group 1 monitor-port
 quit

H3C 的流镜像：思路和华为一样（分类→行为→策略→应用），但行为里的命令不同——华为是 mirror to observe-port 1，H3C 是 mirror-to interface <接口名>：

# 1) 流分类：匹配要镜像的流量
traffic classifier tech_c operator or
 if-match acl 3000
 quit

# 2) 流行为：动作为"镜像到指定接口"
traffic behavior tech_b
 mirror-to interface gigabitethernet 1/0/3
 quit

# 3) QoS 策略：把分类和行为绑起来
qos policy tech_p
 classifier tech_c behavior tech_b
 quit

# 4) 应用到接口入方向
interface GigabitEthernet 1/0/1
 qos apply policy tech_p inbound
 quit

验证：

# 看所有镜像组的配置（官方配置举例中最常用的验证命令）
display mirroring-group all

H3C 官方命令参考中 display mirroring-group 还支持按组号或按类型查看（如 display mirroring-group <组号>），但本章语料（references/h3c/ 下的镜像配置文档）中只出现了 display mirroring-group all 这一种写法，故正文只给这一条；需要按组查看时以设备 display mirroring-group ? 补全为准。

display mirroring-group all 的典型输出：

Mirroring group 1:
    Type: Local
    Status: Active
    Mirroring port:
        GigabitEthernet1/0/1  Both
        GigabitEthernet1/0/2  Both
    Monitor port: GigabitEthernet1/0/3

重点看三行：Type 应为 Local（远程镜像会是 Remote Source/Remote Destination）、Status 应为 Active（不是 Inactive）、Mirroring port 后面的 Both 就是方向。

出处：

• mirroring-group group-id local、mirroring-group group-id mirroring-port interface-list { both | inbound | outbound }、mirroring-group group-id monitor-port interface-list、display mirroring-group { group-id | all | local }：H3C 07-镜像配置 、H3C 11-镜像配置 （已存为 references/h3c/2083533_mirror_cfg.txt、2754346_mirror_cfg.txt）
• 接口视图写法 [DeviceC-GigabitEthernet1/0/2] mirroring-group 2 monitor-port、目的端口 undo stp enable：同上文档的远程目的镜像组示例
• 流镜像 mirror-to interface gigabitethernet 1/0/3 与 display mirroring-group all 输出样例：同上

17.8.5 华为 / H3C 命令对照表

两个最该记的差异：

1. 组织方式不同。华为是"全局定义观察口 1 → 多个源口引用它"；H3C 是"建镜像组 1 → 往组里填源和目的"。逻辑上等价，但配置的先后顺序和视图完全不同，抄配置必翻车。
2. 流镜像的关键字：华为 mirror to observe-port <索引>，H3C mirror-to interface <接口名>。注意 H3C 是连字符 mirror-to，华为是空格 mirror to。

17.8.6 典型场景与注意事项

场景一：排障抓包（最常用）

用户投诉某台 PC 上不了网。标准动作：找到这台 PC 接的接入交换机端口 → 双向镜像到观察口 → 笔记本接观察口开 Wireshark → 让用户重现问题。抓到的报文能直接回答三个问题：请求发出去了吗？（inbound 有包）服务器回了吗？（outbound 有包）回的什么错？（看 TCP RST / ICMP 不可达）。

场景二：接安全探针/态势感知

IDS 需要看全流量。这时镜像口要接专用设备，而且要注意带宽匹配。

场景三：合规审计

需要在出口镜像所有上网流量做留存。这类场景对带宽和存储的要求都高，通常配合抽样比率使用。

六个必须知道的坑：

1. 观察口绝不能同时当业务口用。如果观察口上还跑着业务，镜像流量会和业务流量混在一起发出去，把企业网的正常转发打乱。华为的 display observe-port 输出里那个 Forwarding : No 就是在说"这个口不做正常转发"。观察口必须是空闲口。

2. 带宽不匹配会大量丢包。如果你镜像一个万兆口到千兆观察口，万兆流量灌进千兆口，超出部分直接丢弃，你抓到的包是残缺的——排障时据此得出的结论可能完全错误。镜像前先算：源口峰值流量是多少？观察口和 Wireshark 机器的接收能力够不够？

3. 镜像方向配反，什么都抓不到。想抓"用户发上来的请求"却配了 outbound，结果只有一个方向，看起来像"没抓到包"。排障一律先用 both。

4. VLAN Tag 行为没对齐，抓到了但解析不出来。上线前先用几条 ping 验证一下 Wireshark 能不能正常解析。

5. 堆叠/IRF 环境下跨设备镜像。华为 iStack/CSS 与 H3C IRF 都可以跨成员口镜像，但需要确认型号支持，且镜像流量会在堆叠线缆上传输、占用堆叠带宽。跨设备镜像前先查产品文档的限制。

6. 镜像叠加流策略可能互相影响。同一个口既配了流量策略又配了端口镜像时，两者可能都生效、也可能有优先级关系，具体要看产品实现。配之前先想清楚"我到底要全抓还是要抓一部分"：

七个常见故障对应的排查方向：

适用版本：华为 VRP V200R019 及以上（S5700/S6700 系列，observe-port/port-mirroring 语法以交换机产品线为准，路由器产品线命令可能不同）；H3C Comware V7（R2610 及以上）。

⚠ 待核实：待核实 华为路由器产品线（AR 系列）的端口镜像命令与交换机是否一致（本章命令以 S 系列交换机文档为准，路由器可能使用不同的观察口配置方式），以及 S 系列不同版本中 observe-port 索引号的取值范围

⚠ 待核实：待核实 华为 iStack/CSS 与 H3C IRF 环境下跨成员设备镜像的具体配置方式与型号限制，本章仅给出风险提示未给配置

17.9 本章小结

• ACL 是"规则表 + 逐条比对 + 命中即停"，末尾隐含拒绝；路由策略是"匹配 + 改属性"，所有 node 都不匹配时最终拒绝。
• 基本 ACL 只匹配源 IP（20002999），高级 ACL 匹配五元组（30003999），二层 ACL 匹配 MAC/VLAN（4000~4999），编号区间写错直接报错。
• 通配符掩码是"反着写"的掩码，0.0.0.255 = /24，这是新手最容易踩的坑。
• 前缀列表比 ACL 多一个"掩码长度范围"能力，用 less-equal / greater-equal 表达，过滤路由必学。
• 华为用 traffic-filter 做包过滤、traffic policy 做策略路由；H3C 用 packet-filter 做包过滤、qos policy 做策略路由。
• 验证的硬证据永远是"匹配计数"，配置写得再对，计数不涨就是没生效。

一套可以照抄的 ACL 命名与维护规范。给新手一个能长期不乱的工程习惯，比记住一百条命令更有用：

一个完整的排错示例，把本章工具串起来。现象：某部门反映"打印机能 ping 通但打不出来"。这个故障一次用到了 ACL 与策略两类工具，值得完整走一遍。

第一步，别急着登设备，先在 PC 上确认现象边界：ping 打印机IP 通，说明三层可达、ACL 没拦 ICMP；telnet 打印机IP 9100 不通，说明 9100（打印端口）这个 TCP 连接建不起来。此时已经能定位到"某条 ACL 只放行了 ICMP 没放行 9100"或"策略路由把打印流量导到了错误路径"。

第二步，在网关设备上查 ACL 的匹配计数：

# 看哪条规则吃掉了打印流量
display acl all

如果 9100 那次连接对应的规则计数一直是 0，说明报文根本没走到这条 ACL，问题在策略路由或路由层面，不在 ACL；如果某条 deny 的计数在涨，那就是它拦的，直接检查该规则前后顺序。

第三步，如果 ACL 计数不涨，就去看策略路由把流量导到了哪儿：

# 华为：看接口上应用的流量策略
display traffic-policy applied-record

# 从 PC 上 tracert 到打印机，看实际走的下一跳

tracert 的首跳如果与路由表算出来的不一致，就是 PBR 在起作用。到这里问题就清楚了：要么补一条 ACL 放行 9100，要么调整 PBR 的匹配范围。

这个例子想说明的是：ACL 与策略路由都会"静默"改变流量的命运，唯一的可靠线索是匹配计数和实际路径。配的时候多写一行注释、改的时候多看一眼计数，比事后翻配置文件省力得多。

自测题

1. rule permit ip source 192.168.10.0 0.0.255.255 这条规则匹配的是哪个范围？它和 192.168.10.0 0.0.0.255 有什么本质区别？
2. 一个 ACL 里只有三条 permit 规则，没有 deny 规则，会有什么后果？
3. 前缀列表 ip ip-prefix TEST permit 192.168.0.0 16 less-equal 24 能匹配 192.168.5.0/24 吗？能匹配 10.0.0.0/8 吗？为什么？
4. 华为和 H3C 分别用什么命令在接口上调用 ACL 做包过滤？
5. 为什么说"route-policy 所有 node 都没匹配上 = 拒绝"？这对写策略有什么影响？

1. 匹配的是 192.168.0.0 ~ 192.168.255.255 这个大范围（前 16 位固定）；192.168.10.0 0.0.0.255 才是只匹配 192.168.10.0/24。区别在于通配符掩码的位含义：0 表示必须匹配、1 表示任意。
2. 没被三条 permit 规则匹配到的流量会撞上末尾隐含的 deny，被立即丢弃，表现为"配了 ACL 反而全断"。
3. 能匹配 192.168.5.0/24（在 192.168.0.0/16 下且掩码 24 恰好等于 less-equal 上限）；不能匹配 10.0.0.0/8，因为前缀不在 192.168.0.0/16 范围内。
4. 华为 traffic-filter inbound acl 3000；H3C packet-filter 3000 inbound。
5. 因为 route-policy 的隐含默认动作是 reject，所以任何一类路由如果想被放行，必须至少要有一个 node 能匹配到它，否则会被静默丢弃。实践里要写专门的 permit 兜底 node。

关于本书：《华为 / H3C 网络设备典型功能配置详解》—— 面向国内高校/企业网络环境， 华为 VRP 与 H3C Comware 双厂商并排配置的实操教材，共 43 章。 全书所有命令尽量有官方出处，查不到的显式标注「待核实」。 返回系列目录