跳到正文
Lutong's Homepage

华为H3C实战 | 第42章 企业双出口冗余与链路选路

📚 本系列共 48 篇(第 42 / 48 篇) · 第六卷 实战与附录篇 —— 把它们拼起来

← 上一篇:第 41 章 酒店无线与有线统一接入  下一篇:第 43 章 数据中心服务器接入与高密组网 →


本章导读:一家做跨境电商的公司,办公在 A 市,仓储在 B 市,两边都接了电信和联通两条宽带。老板的要求听起来简单:“网别断,电信的网站走电信、联通的网站走联通。“真做起来会发现这句话背后有五个互相牵制的问题:怎么按目的选路、怎么在 3 秒内发现链路死了、NAT 怎么配才不会来回跳、防火墙放哪、以及分公司怎么安全连进来。

本章结构:

  • 42.1 项目背景与需求 —— 需求清单与四项硬指标
  • 42.2 网络拓扑与地址规划 —— 拓扑图、IP 规划、路由域划分
  • 42.3 关键设计决策 —— 策略路由 vs 浮动静态、BFD vs NQA、防火墙位置、NAT 顺序
  • 42.4 华为完整配置 —— 分模块,逐块标注对应章节
  • 42.5 H3C 完整配置 —— 同构拓扑的 H3C 版
  • 42.6 验证清单 —— 逐项打勾,含故障切换实测
  • 42.7 本项目踩过的坑 —— 五个真实故障
  • 42.8 本章小结

42.1 项目背景与需求

42.1.1 现状与痛点

这家跨境电商公司在过去两年里经历了三次"断网事故”,每一次都直接烧钱:

时间 事故 损失
去年 3 月 电信光缆被施工挖断 客服系统 4 小时不可用,当天订单履约延迟
去年 11 月 联通线路抖动(时断时续) 视频会议断续,与供应商的谈判中断
今年 2 月 单条出口流量打满 全公司卡了 2 小时,因为有人跑大文件同步

现在的情况是:两条宽带都接了,但是"一主一备"的粗放用法——主线路断了靠人手动改默认路由,运维半夜被叫起来是常事。

42.1.2 需求清单

把老板的要求翻译成可验收的技术指标:

# 需求 技术指标 优先级
1 电信资源走电信、联通资源走联通 按目的地址段的策略路由,命中率可查 P0
2 主链路断了自动切 中断到切换完成 ≤ 3 秒 P0
3 全部内网用户能上网 源 NAT,两条链路都要能用 P0
4 对外服务能被访问 服务器映射(NAT Server),优先走电信 P1
5 分公司安全互联 IPSec VPN,走互联网加密隧道 P1
6 防止个别用户占满带宽 按用户/应用限速 P2
7 出口流量可分析 端口镜像 + 抓包 P2

42.1.3 为什么"3 秒内切换"是最难的一条

这条指标不是拍脑袋定的,它有明确的业务依据:VoIP 和视频会议能容忍的中断时间是 3~5 秒,超过就会出现"喂喂喂?“的断连。

而"3 秒内发现链路故障"恰恰是传统做法的死穴:

  • 靠接口 down 判断:光模块不发光或对端设备断电时接口会 down,但运营商线路中断时,本地接口往往是 up 的——光猫还在发光,只是对端收不到。这种情况下接口状态完全不报错。
  • 靠静态路由 + 优先级:只有等默认路由失效才切,而默认路由不会自己失效。
  • 靠 OSPF 等协议:如果运营商不跑动态路由,就没法用。

所以必须用主动探测机制:定期发包探测对端是否存活。这就是本章要重点讲 BFD / NQA / ip-link 的原因。

42.2 网络拓扑与地址规划

42.2.1 物理拓扑

                        [Internet]
                       /            \
            电信(主) /              \ 联通(备)
                     /                \
              +-----+------+      +----+--------+
              | 光猫 CT     |      | 光猫 CU      |
              +-----+------+      +----+--------+
                    | 10.100.1.0/30    | 10.101.1.0/30
                    |                  |
        +-----------+------------------+-----------+
        |          FW1 防火墙(出口)                |
        |  Untrust 区:两个出口接口                  |
        |  Trust 区:接内网核心                      |
        +--------------------+---------------------+
                             | 10.200.1.0/30
                     +-------+-------+
                     |  CORE 核心    |
                     |  交换机       |
                     +---+-------+---+
                         |       |
                +--------+       +---------+
                |                          |
        [办公 VLAN 10]              [服务器 VLAN 20]
        [仓储 VLAN 11]              [分公司 IPSec]

42.2.2 逻辑拓扑:两个"路由域”

   【内网域】
   办公/仓储终端 --VLAN--> CORE --默认路由--> FW1 --Trust区

   【出口域 - 电信】
   FW1 --10.100.1.1--> 光猫CT --公网--> 电信资源

   【出口域 - 联通】
   FW1 --10.101.1.1--> 光猫CU --公网--> 联通资源

   【分支域 - IPSec】
   FW1 <==加密隧道==> 分公司防火墙(B 市,静态 IP)

42.2.3 IP 地址规划

用途 网段 网关 说明
办公 VLAN 10 192.168.10.0/24 192.168.10.1 约 200 人
仓储 VLAN 11 192.168.11.0/24 192.168.11.1 扫码枪、WMS 终端
服务器 VLAN 20 192.168.20.0/24 192.168.20.1 对外 Web/邮件
核心-FW 互联 10.200.1.0/30 .1 (CORE) / .2 (FW) 三层互联
FW-电信光猫 10.100.1.0/30 .1 (FW) / .2 (光猫) FW 侧是 .1
FW-联通光猫 10.101.1.0/30 .1 (FW) / .2 (光猫) 同上
IPSec 隧道地址 169.254.100.0/30 .1 (总部) / .2 (分支) 隧道内互联
分支内网 10.50.0.0/16 — B 市仓储

42.2.4 电信/联通资源段从哪来

“电信资源走电信"这件事,前提是你得知道哪些 IP 是电信的。实际有三种拿法:

方式 做法 适用
静态前缀表 官方发布"电信 IP 段列表”,逐条写进 ACL 小规模,段数不多
动态更新 定期下载运营商前缀库,脚本生成 ACL 大规模,需要自动化
运营商告知 只对关键业务系统(如某些专网)单独指定 业务方明确指出目标时

本章案例用方式一,选取几个代表性的段做示范:

资源 代表网段(示例) 走出
电信 IDC 106.0.0.0/8、180.0.0.0/8 电信
联通 IDC 110.0.0.0/8、210.0.0.0/8 联通
其他 默认 电信(主)

⚠ 务必说明:上面 106.0.0.0/8 这类是示意用的段,真实项目必须用运营商官方发布的最新前缀表,不要凭记忆写。写错的后果是"该走电信的流量走了联通”,表现为某些网站特别慢,很难查。

42.3 关键设计决策

42.3.1 决策一:策略路由(PBR)还是浮动静态路由

方案 原理 能否按目的选路 复杂度
浮动静态路由 两条默认路由不同优先级,主失效切备 ❌ 不能,只能全有或全无 低
PBR(策略路由) 按 ACL 匹配目的地址,指定下一跳 ✅ 能 中
PBR + 浮动静态 PBR 管"走哪条",浮动静态管"挂了切到哪" ✅ 能 高

最终选择:PBR + 浮动静态组合。

  • PBR 负责"选路":命中电信 ACL 的走电信下一跳,命中联通 ACL 的走联通下一跳。
  • 浮动静态负责"兜底":PBR 的下一跳不可达时,流量回落到按路由表转发,由浮动静态路由决定走哪条。

代价:PBR 的匹配顺序很关键(先匹配先走),ACL 段写多之后维护成本高,需要定期更新。

这是实现"3 秒切换"的核心。三个机制对比:

机制 探测方式 最快收敛 厂商支持 适用
BFD 双向持续发控制包 毫秒~百毫秒级 两家都支持 对端也支持 BFD 时最优
NQA 主动发 ICMP/UDP 探测 秒级(取决于配置) 两家都支持 对端是运营商设备、不一定支持 BFD
ip-link 华为私有的链路探测 秒级 华为 华为设备专用,配置简单

最终选择:NQA(ICMP 探测 + 联动静态路由)。

理由是:运营商光猫/BRAS 通常不支持 BFD。BFD 要求两端都配,运营商侧你改不了。所以只能用"自己发 ICMP 探测"的 NQA,探测目标是运营商网关或公网某知名地址。

代价:NQA 的最快收敛取决于配置的频率和判定次数。本案例配 frequency 3(每 3 秒探测一次)+ probe-count 3(连续 3 次失败判定不可达),理论最坏发现时间是 9 秒——这超过了 3 秒的指标。

所以进一步优化:把探测频率调到 1 秒、判定次数 3 次,最坏 3 秒发现。这就是"3 秒指标"的具体落地方式。

42.3.3 决策三:防火墙放在出口还是旁挂

位置 拓扑 优点 缺点
出口串接 内网 → FW → 光猫 所有流量必经防火墙,安全边界清晰 防火墙是单点,必须双机热备
旁挂 核心直接连光猫,FW 旁挂 不占转发路径 需要策略路由把流量"引"到防火墙,配置复杂且易漏

最终选择:出口串接。因为跨境的业务对安全要求高(等保),流量必须被完整审计。单点问题用双机热备解决(见第 29 章)。

42.3.4 决策四:NAT 在哪一层做,顺序怎么排

这是最容易出错的一环。数据包从内网出去,要依次经过:

   源 NAT(内网→公网)  →  安全策略检查  →  路由(决定走哪条链路)  →  发出

   ⚠ 关键问题:如果先做源 NAT 再做策略路由,
      策略路由看到的源地址已经是公网地址,匹配不到内网 ACL!

最终选择:明确的处理顺序 —— 策略路由在 NAT 之前生效。

不同厂商对这个顺序的实现不一样:

厂商 机制 注意
华为 安全策略里可以引用策略路由(policy-based-route),在 NAT 之后的路由查找阶段生效 需要在安全策略里显式放行
H3C 策略路由 policy-based-route 应用在接口上,与 NAT 的先后由设备内部流程决定 需实测确认

做法:在防火墙上配置两套策略路由——一套匹配内网源段(192.168.0.0/16),一套匹配公网源段(NAT 后的地址池),保证无论顺序如何都能命中。

42.3.5 决策五:双出口的四种"进化形态"(先想清楚自己在哪一级)

很多项目一上来就说"要做智能选路",但双出口其实有四个成熟度档位,档位越高配置越复杂、收益也越明显。先判断客户该停在哪一档:

档位 做法 能解决什么 典型代价
一档:热备 两条线,主挂了切备 只解决"不断网" 备线平时闲置,浪费一半带宽
二档:分流 PBR 按目的地址分流,两条都在用 提升访问速度、充分利用带宽 ACL 要维护,配错会绕远路
三档:动态选路 探测每条线的时延/丢包,动态选更优的 能应对"线路通但慢" 需要支持该能力的设备/功能
四档:应用级策略 按应用类型分流(视频走A、下载走B) 体验最优 需要应用识别能力,成本最高

本案例选择二档(分流)+ 一档(热备)的组合。理由是:客户的实际痛点就两个——“断网"和"部分网站慢”,二档足够解决;三档和四档需要更贵的设备或更复杂的功能,在这个规模下投入产出比不划算。

这个判断很重要:集成项目里最常见的失误是"客户说要做智能选路,方案商直接上四档方案",预算翻倍,客户还不一定用得到。先问清"你最痛的是什么",再决定档位。

42.3.6 决策六:ACL 资源段怎么维护才不会烂掉

PBR 依赖 ACL 里的资源段列表,而这个列表的维护是个长期问题:

维护方式 做法 问题
手工维护 每季度人工核对运营商发布的段 容易忘,一忘就是半年
脚本自动生成 定期下载前缀库,生成 ACL 并下发 需要开发和审批流程
只在必要时维护 只对"确实很慢的关键系统"单独指路 覆盖面窄但维护成本低

本案例选择"混合":核心业务系统(如某些电商平台的 API)用精确 IP 单独指路,其余靠默认路由。放弃了"全量精确分流",因为维护成本大于收益。

经验值:ACL 条目超过 200 条之后人工维护基本不可行,必须上脚本或换用支持"资源库"功能的设备。项目初期就该把这个成本跟客户说清楚。

42.3.7 决策七:IPSec VPN 走哪条链路

分公司要和总部建 IPSec 隧道,隧道本身也要走互联网。问题来了:隧道放在电信上还是联通上?

方案 做法 优点 缺点
固定走电信 隧道源地址绑电信接口 简单 电信断了隧道就断,没有冗余
双隧道(主备) 建两条 IPSec 隧道,一条走电信一条走联通,用路由优先级 有冗余 配置量翻倍

最终选择:双隧道主备。主隧道走电信,备隧道走联通,用静态路由的优先级控制。代价是两边都要维护两套 IKE/IPSec 配置。

42.4 华为完整配置

42.4.1 模块一:核心交换机(第 3、8、11 章)

核心交换机负责内网三层转发、DHCP 和到防火墙的路由。

system-view
sysname CORE

# VLAN 规划
vlan batch 10 11 20

# 办公网关
interface Vlanif10
 ip address 192.168.10.1 255.255.255.0
 quit
# 仓储网关
interface Vlanif11
 ip address 192.168.11.1 255.255.255.0
 quit
# 服务器网关
interface Vlanif20
 ip address 192.168.20.1 255.255.255.0
 quit

# 到防火墙的互联口
interface Vlanif200
 ip address 10.200.1.1 255.255.255.252
 quit

# 默认路由指向防火墙
ip route-static 0.0.0.0 0.0.0.0 10.200.1.2
# 到分公司内网的路由(经 IPSec 隧道,下一跳是防火墙隧道地址)
ip route-static 10.50.0.0 255.255.0.0 10.200.1.2

# DHCP 服务
dhcp enable
ip pool office
 network 192.168.10.0 mask 255.255.255.0
 gateway-list 192.168.10.1
 dns-list 114.114.114.114
 quit
ip pool warehouse
 network 192.168.11.0 mask 255.255.255.0
 gateway-list 192.168.11.1
 dns-list 114.114.114.114
 quit

第 8、11 章要点:这里只有一个内网域,不需要 OSPF——一台核心 + 一条默认路由足够。不要为了"看起来专业"硬上 OSPF,单出口的内网用静态路由最稳、最好排错。

42.4.2 模块二:出口安全区域(第 27 章)

system-view
sysname FW1

# 安全区域
firewall zone trust
 add interface GigabitEthernet1/0/1
 quit
firewall zone untrust
 add interface GigabitEthernet1/0/2
 add interface GigabitEthernet1/0/3
 quit

# 接口地址
interface GigabitEthernet1/0/1
 description to-CORE
 ip address 10.200.1.2 255.255.255.252
 quit
interface GigabitEthernet1/0/2
 description to-CT-telecom
 ip address 10.100.1.1 255.255.255.252
 quit
interface GigabitEthernet1/0/3
 description to-CU-unicom
 ip address 10.101.1.1 255.255.255.252
 quit

第 27 章要点:华为防火墙默认策略是拒绝所有,配完区域和地址后如果没写安全策略,内网一个包都出不去。这是新手第一天必然踩的坑。

42.4.3 模块三:出口地址与 NQA 探测(第 10 章)

先把两条链路的"存活探测"配好——这是 3 秒切换的基础。

# 电信链路探测:每 1 秒探测,连续 3 次失败判定不可达
nqa test-instance admin ct
 test-type icmp
 destination-address ipv4 10.100.1.2
 frequency 1
 probe-count 3
 timeout 1
 start now
 quit

# 联通链路探测
nqa test-instance admin cu
 test-type icmp
 destination-address ipv4 10.101.1.2
 frequency 1
 probe-count 3
 timeout 1
 start now
 quit

nqa schedule admin ct start-time now lifetime forever
nqa schedule admin cu start-time now lifetime forever

✅ 已核实:nqa test-instance <管理员> <实例名> + test-type icmp + destination-address ipv4 + frequency + probe-count + start now,为华为官方配置示例中的写法,出处 references/huawei/EDOC1000069579.txt(Sx300 典型配置案例)。

3 秒指标怎么来的:frequency 1(每秒探测一次)× probe-count 3(连续丢 3 次判定断开)= 最坏 3 秒发现。如果把 frequency 配成 5 秒,理论最坏就是 15 秒,直接违约。

42.4.4 模块四:浮动静态路由 + NQA 联动(第 10 章)

# 主路由:默认走电信,捆绑 NQA 探测
ip route-static 0.0.0.0 0.0.0.0 10.100.1.2 track nqa admin ct
# 备路由:优先级更低(数值更大),电信挂了才生效
ip route-static 0.0.0.0 0.0.0.0 10.101.1.2 preference 70 track nqa admin cu

✅ 已核实:ip route-static ... track nqa <管理员> <实例名> 为官方示例写法(ip route-static 0.0.0.0 0.0.0.0 10.1.10.1 track nqa user test1),出处 references/huawei/EDOC1000069579.txt。

preference 70 的含义:华为静态路由默认优先级 60,数值越小越优先。主路由不写 priority(默认 60),备路由写 70,就实现了"主优先、备兜底"。

42.4.5 模块五:策略路由 PBR(第 18 章)

这是"电信走电信、联通走联通"的核心。

# ---------- 匹配电信资源段 ----------
acl number 3100
 description CT-resources
 rule 10 permit ip destination 106.0.0.0 0.255.255.255
 rule 20 permit ip destination 180.0.0.0 0.255.255.255
 quit

# ---------- 匹配联通资源段 ----------
acl number 3200
 description CU-resources
 rule 10 permit ip destination 110.0.0.0 0.255.255.255
 rule 20 permit ip destination 210.0.0.0 0.255.255.255
 quit

# ---------- 流分类 ----------
traffic classifier ct-res operator or
 if-match acl 3100
 quit
traffic classifier cu-res operator or
 if-match acl 3200
 quit

# ---------- 流行为:重定向到指定下一跳 ----------
traffic behavior to-ct
 redirect ip-nexthop 10.100.1.2
 quit
traffic behavior to-cu
 redirect ip-nexthop 10.101.1.2
 quit

# ---------- 流策略:按顺序组合 ----------
traffic policy dual-wan
 classifier ct-res behavior to-ct
 classifier cu-res behavior to-cu
 quit

# ---------- 应用在 Trust 区入方向 ----------
interface GigabitEthernet1/0/1
 traffic-policy dual-wan inbound
 quit

✅ 已核实:traffic classifier / traffic behavior / redirect ip-nexthop / traffic-policy 为华为官方 PBR 写法(redirect ip-nexthop 10.3.1.1 //对匹配的报文重定向到10.3.1.1),出处 references/huawei/EDOC1000069579.txt(Sx300 典型配置案例,含完整 PBR 示例)。

匹配顺序很重要:流策略里 classifier 的排列顺序就是匹配顺序,先匹配先执行。所以粒度细的(具体 IP)要放前面,粒度粗的(整个网段)放后面。

42.4.6 模块六:源 NAT 与服务器映射(第 14、28 章)

# ---------- 源 NAT:内网访问互联网,两个出口都要 NAT ----------
nat address-group 1
 mode pat
 section 0 10.100.1.1 10.100.1.1
 quit
nat address-group 2
 mode pat
 section 0 10.101.1.1 10.101.1.1
 quit

nat-policy
 rule name outbound-ct
  source-zone trust
  destination-zone untrust
  action source-nat address-group 1
  quit
 quit

# ---------- 服务器映射:对外发布 Web 服务,走电信 ----------
nat server web-server protocol tcp global 10.100.1.1 80 inside 192.168.20.10 80

第 14 章要点:源 NAT 的地址组必须和出口接口在同一网段(10.100.1.1 就是电信接口地址),否则回包路由不对。

42.4.7 模块七:安全策略(第 27 章)

security-policy
 # 内网出外网:放行
 rule name trust-to-untrust
  source-zone trust
  destination-zone untrust
  action permit
  quit
 # 外网访问 Web 服务器
 rule name untrust-to-web
  source-zone untrust
  destination-zone trust
  destination-address 192.168.20.10 32
  destination-port 80
  action permit
  quit
 # 默认拒绝(华为默认就是拒绝,写出来是为了明确)
 rule name default
  action deny
  quit
 quit

✅ 已核实:security-policy + rule name + source-zone / destination-zone / action permit|deny 为华为 USG 系列标准安全策略语法(见第 27 章)。

42.4.8 模块八:IPSec VPN 到分公司(第 30 章)

双隧道主备:主走电信,备走联通。

# ---------- IKE 提议(第一阶段) ----------
ike proposal 10
 encryption-algorithm aes-cbc-256
 authentication-algorithm sha2-256
 dh group14
 quit

# ---------- IPSec 提议(第二阶段) ----------
ipsec proposal branch-prop
 esp authentication-algorithm sha2-256
 esp encryption-algorithm aes-256
 quit

# ---------- IKE 对等体:主隧道走电信 ----------
ike peer branch-ct v1
 pre-shared-key cipher Branch@IPSec2026
 ike-proposal 10
 remote-address 203.0.113.10
 quit

# 备隧道走联通
ike peer branch-cu v1
 pre-shared-key cipher Branch@IPSec2026
 ike-proposal 10
 remote-address 203.0.113.10
 local-address 10.101.1.1
 quit

# ---------- 感兴趣流 ----------
acl number 3400
 rule 10 permit ip source 192.168.0.0 0.0.255.255 destination 10.50.0.0 0.0.255.255
 quit

# ---------- IPSec 策略 ----------
ipsec policy branch-policy 10 isakmp
 security acl 3400
 ike-peer branch-ct
 proposal branch-prop
 quit

# 应用到电信出口接口
interface GigabitEthernet1/0/2
 ipsec policy branch-policy
 quit

⚠ 上面 ike peer / ipsec policy ... isakmp / security acl / proposal 的命令骨架已按官方参考核对(ipsec policy <名> <序号> isakmp、ike proposal、ipsec proposal、ike peer 均存在)。但各子命令的完整参数组合随版本差异较大,且 ike peer 的 v1/v2 语法不同,请以本机 ? 为准。 ⚠ 待核实:待核实——AR/USG 上 ike peer 的 v1/v2 具体语法(是否写作 ike peer X v1/v2)、security acl 与 acl 的对应关系、以及双隧道主备场景下 ike peer 的 local-address 绑定方式,需对照 EDOC1100212558 的 IPSec 分册

42.4.9 模块九:流量镜像分析出口流量(第 18 章)

排查"到底是哪条线路有问题"时,抓包是最直接的手段。

# 定义观察口
observe-port 1 interface GigabitEthernet1/0/8
# 把电信出口入方向流量镜像到观察口
interface GigabitEthernet1/0/2
 port-mirroring to observe-port 1 inbound
 port-mirroring to observe-port 1 outbound
 quit

✅ 已核实:observe-port <编号> interface <接口> + port-mirroring to observe-port <编号> { inbound | outbound },出处 references/huawei/(交换机端口镜像章节)。

42.4.10 模块十:带宽限速(QoS)(第 36 章)

防止单个用户占满出口。

# 对办公网段整体限速,给仓储和服务器留余量
traffic classifier limited-user operator or
 if-match acl 3500
 quit
traffic behavior limit-50m
 car cir 51200 cbs 3200000
 quit
traffic policy user-limit
 classifier limited-user behavior limit-50m
 quit

acl number 3500
 rule 10 permit ip source 192.168.10.0 0.0.0.255
 quit

interface GigabitEthernet1/0/1
 traffic-policy user-limit inbound
 quit

42.5 H3C 完整配置

42.5.1 模块一:核心与三层(第 3、8 章)

system-view
sysname CORE

vlan 10
vlan 11
vlan 20
vlan 200
quit

interface Vlan-interface10
 ip address 192.168.10.1 255.255.255.0
 quit
interface Vlan-interface11
 ip address 192.168.11.1 255.255.255.0
 quit
interface Vlan-interface20
 ip address 192.168.20.1 255.255.255.0
 quit
interface Vlan-interface200
 ip address 10.200.1.1 255.255.255.252
 quit

ip route-static 0.0.0.0 0 10.200.1.2
ip route-static 10.50.0.0 255.255.0.0 10.200.1.2

dhcp enable
dhcp server ip-pool office
 network 192.168.10.0 mask 255.255.255.0
 gateway-list 192.168.10.1
 dns-list 114.114.114.114
 quit

42.5.2 模块二:安全域与接口(第 27 章)

interface GigabitEthernet1/0/1
 description to-CORE
 ip address 10.200.1.2 255.255.255.252
 quit
interface GigabitEthernet1/0/2
 description to-CT-telecom
 ip address 10.100.1.1 255.255.255.252
 quit
interface GigabitEthernet1/0/3
 description to-CU-unicom
 ip address 10.101.1.1 255.255.255.252
 quit

security-zone name Trust
 import interface GigabitEthernet1/0/1
 quit
security-zone name Untrust
 import interface GigabitEthernet1/0/2
 import interface GigabitEthernet1/0/3
 quit

H3C 与华为差异:H3C 用 security-zone name <名> + import interface,华为用 firewall zone <名> + add interface。另外 H3C 的缺省安全策略行为与华为不同,需显式配置 security-policy 规则。

42.5.3 模块三:NQA 与浮动静态路由(第 10 章)

nqa entry admin ct
 type icmp-echo
  destination ip 10.100.1.2
  frequency 1000
  probe count 3
  reaction 1 checked-element probe-fail threshold-type consecutive 3 action-type trigger-only
  quit
 quit

nqa entry admin cu
 type icmp-echo
  destination ip 10.101.1.2
  frequency 1000
  probe count 3
  reaction 1 checked-element probe-fail threshold-type consecutive 3 action-type trigger-only
  quit
 quit

# 关联 track
track 1 nqa entry admin ct reaction 1
track 2 nqa entry admin cu reaction 1

# 浮动静态路由
ip route-static 0.0.0.0 0 10.100.1.2 track 1
ip route-static 0.0.0.0 0 10.101.1.2 preference 70 track 2

⚠ H3C 的 NQA 语料未覆盖:上面 nqa entry / reaction checked-element / track nqa 的写法依据 H3C Comware 通用语法,但本项目的 references/h3c 语料中没有 NQA 章节,无法逐字对照官方原文。 ⚠ 待核实:待核实——H3C Comware V7 的 NQA 配置命令(nqa entry 的 type/frequency/probe count/reaction)与 track 联动语法,references/h3c 无 NQA 文档,需补抓 H3C《网络管理和监控配置指导》NQA 分册

42.5.4 模块四:策略路由 PBR(第 18 章)

# 匹配电信资源
acl advanced 3100
 rule 10 permit ip destination 106.0.0.0 0.255.255.255
 rule 20 permit ip destination 180.0.0.0 0.255.255.255
 quit

# 匹配联通资源
acl advanced 3200
 rule 10 permit ip destination 110.0.0.0 0.255.255.255
 rule 20 permit ip destination 210.0.0.0 0.255.255.255
 quit

# 策略路由:电信
policy-based-route to-ct permit node 10
 if-match acl 3100
 apply next-hop 10.100.1.2
 quit

# 策略路由:联通
policy-based-route to-cu permit node 20
 if-match acl 3200
 apply next-hop 10.101.1.2
 quit

# 应用到 Trust 接口
interface GigabitEthernet1/0/1
 ip policy-based-route to-ct
 ip policy-based-route to-cu
 quit

✅ 已核实:policy-based-route <名> { permit | deny } node <号> + apply next-hop + 接口下 ip policy-based-route,出处 references/h3c/1185807_30005_0.txt(07-策略路由配置)。

42.5.5 模块五:NAT(第 14、28 章)

# 内网出外网 NAT
acl basic 2000
 rule 10 permit source 192.168.0.0 0.0.255.255
 quit

interface GigabitEthernet1/0/2
 nat outbound 2000
 quit
interface GigabitEthernet1/0/3
 nat outbound 2000
 quit

# 服务器映射(NAT Server)
interface GigabitEthernet1/0/2
 nat server protocol tcp global current-interface 80 inside 192.168.20.10 80
 quit

42.5.6 模块六:安全策略(第 27 章)

security-policy ip
 rule name trust-to-untrust
  source-zone Trust
  destination-zone Untrust
  action pass
  quit
 rule name untrust-to-web
  source-zone Untrust
  destination-zone Trust
  destination-ip 192.168.20.10
  service tcp destination-port 80
  action pass
  quit
quit

42.5.7 模块七:IPSec VPN(第 30 章)

# 第一阶段
ike profile branch-ct
 keychain branch-key
  pre-shared-key simple Branch@IPSec2026
  quit
 exchange-mode aggressive
 quit

ike keychain branch-key
 pre-shared-key address 203.0.113.10 32 key simple Branch@IPSec2026
 quit

# 第二阶段
ipsec transform-set branch-prop
 esp encryption-algorithm aes-cbc-256
 esp authentication-algorithm sha256
 quit

# IPSec 策略
ipsec policy branch-policy 10 isakmp
 security acl 3400
 remote-address 203.0.113.10
 ike-profile branch-ct
 transform-set branch-prop
 quit

acl advanced 3400
 rule 10 permit ip source 192.168.0.0 0.0.255.255 destination 10.50.0.0 0.0.255.255
 quit

interface GigabitEthernet1/0/2
 ipsec apply policy branch-policy
 quit

✅ 已核实:ipsec policy <名> <序号> isakmp、ipsec transform-set、ike profile 为 H3C 官方语法(ipsec policy map1 10 isakmp、ipsec transform-set tran1),出处 references/h3c/(IPSec 配置分册)。

⚠ 上面 ike profile 内部 keychain 的写法需以版本为准,H3C 在 IKEv1/IKEv2 下语法不同。 ⚠ 待核实:待核实——H3C Comware V7 中 ike profile 与 ike keychain 的完整配套语法(IKEv1 vs IKEv2),以及 ipsec policy 中引用 ike-profile 的确切命令名

42.5.8 模块八:流量镜像(第 18 章)

# 定义镜像组
mirroring-group 1 local
mirroring-group 1 mirroring-port GigabitEthernet1/0/2 both
mirroring-group 1 monitor-port GigabitEthernet1/0/8

✅ 已核实:mirroring-group <编号> local + mirroring-port + monitor-port,出处 references/h3c/(端口镜像章节)。

42.4.11 模块十一:出口带宽监控与容量算账

需求清单里"带宽监控"是 P2,但它决定了"什么时候该扩容"。做法是在出口接口上开流量统计,定期看利用率。

# 查看电信出口的实时流量
display interface GigabitEthernet1/0/2

重点看 Input bandwidth utilization 和 Output bandwidth utilization 两个百分比。经验判据:

出口利用率 判读 动作
< 50% 健康 无需动作
50%~70% 偏高 关注峰值时段
70%~85% 告警 考虑扩容或做 QoS 分流
> 85% 严重 必须扩容,否则高峰期会丢包

为什么要"两条线分别看":本案例是双出口,很可能出现"电信跑满、联通闲一半"的情况——这正是 PBR 没配好或者资源段划错的信号。如果两条线利用率长期严重不均衡,说明选路策略有问题,而不是容量不够。

42.4.12 模块十二:割接步骤与回滚预案

双出口改造是高风险变更(改动默认路由和 NAT 等于改动全公司上网),必须写好割接步骤和回滚方案。

割接前准备:

   □ 备份现有配置(display current-configuration 导出存档)
   □ 确认两条链路的运营商网关地址、带宽、公网 IP
   □ 确认对外服务器当前用的公网 IP(改 NAT 会导致外部访问中断)
   □ 选业务低谷窗口(夜间 22:00 之后)
   □ 通知相关部门

割接顺序(不能乱):

步 动作 为什么这个顺序
1 先配 NQA 探测,确认两条链路都"看得见" 探测没配好,后面切换全是瞎的
2 配浮动静态路由,不删旧路由 新旧共存,出问题能立刻回退
3 单独验证:手动 shutdown 电信口,看能否切联通 这一步验证的是"切换能力"
4 配 PBR 选路 最后才动"选路",因为它最容易配错
5 验证三件事:电信走电信、联通走联通、默认走电信 逐条 tracert
6 删除旧的临时路由 清理

回滚预案:每一步都保留"撤销命令",例如第 4 步配了 PBR,回滚就是 undo traffic-policy dual-wan inbound。回滚必须能在 5 分钟内完成,且不能依赖"重新配一遍"。

经验:割接时永远不要在同一个窗口里同时改"NAT"和"选路"。这两件事任一改动都会影响全公司上网,同时改出问题就分不清是谁的责任。分两个窗口做,每次只改一类。

42.6 验证清单

42.6.1 基础连通

# 检查项 命令 期望
1 内网能 ping 通胶囊 终端 ping 10.200.1.2 通
2 防火墙能 ping 两个网关 FW ping 10.100.1.2 / 10.101.1.2 都通
3 内网能上外网 终端访问网站 正常

42.6.2 智能选路

# 检查项 方法 期望
4 电信资源走电信 tracert 一个电信地址 第一跳 10.100.1.2
5 联通资源走联通 tracert 一个联通地址 第一跳 10.101.1.2
6 普通网站走默认 tracert 任意网站 第一跳 10.100.1.2
# 查看 PBR 命中情况(华为)
display traffic policy statistics interface GigabitEthernet1/0/1 inbound

42.6.3 故障切换(最关键)

# 检查项 方法 期望
7 拔电信线后自动切联通 拔 10.100.1.2 的光纤,持续 ping ≤ 3 秒恢复
8 切回后恢复电信 插回光纤 自动切回,≤ 3 秒
9 联通挂了不至于全断 拔联通线 业务走电信,不中断
# 查看 NQA 探测结果(华为)
display nqa results test-instance admin ct
NQA entry(admin ct) test result:
    Destination : 10.100.1.2
    Status      : success        ← 断开后会变成 failed
    ...
# 查看路由表中主备路由状态
display ip routing-table 0.0.0.0

42.6.4 NAT 与服务器发布

# 检查项 方法 期望
10 内网用户 NAT 正常 访问 ip.sb 之类查出口 IP 显示电信或联通地址
11 外网能访问 Web 手机 4G 访问发布的域名 能打开

42.6.5 IPSec

# 查看 IPSec SA 是否建立(华为)
display ipsec sa
# 看 IKE 对等体状态
display ike sa
# 检查项 期望
12 主隧道(电信)建立 display ike sa 有 Established
13 总部能 ping 分支内网 ping 10.50.0.1 通
14 主隧道断后备隧道接管 拔电信,隧道切换

42.7 本项目踩过的坑

坑一:3 秒切换指标没达到,实测要 15 秒

现象:验收时拔掉电信光纤,丢包持续了 15 秒才恢复。

排查:display nqa results test-instance admin ct 显示 nqa 的 frequency 是 5 秒。

根因:配置模板抄的是"5 秒探测 + 3 次判定"= 15 秒。模板是为"线路抖动不要太敏感"设计的,和 3 秒指标天生冲突。

处置:改成 frequency 1 + probe-count 3 = 3 秒。同时把 timeout 也调到 1 秒,避免一次探测超时被算成"还在等"。

教训:“3 秒"这种硬指标必须在验收前实测,不能按公式推算。而且改动频率要连通 timeout 一起改,否则一个探测包还没超时下一次探测就发了,结果不可控。

坑二:PBR 配好后"该走联通的走了电信”

现象:tracert 一个联通地址,第一跳却是电信。

排查:display traffic policy statistics 显示电信那条 classifier 的匹配计数在涨,说明电信 ACL 把联通流量也匹配进去了。

根因:ACL 的规则顺序问题。原来的 ACL 里有一条 rule 5 permit ip(全放行)写在前面,后面写具体网段——ACL 是"先匹配先走",permit ip 把所有流量都放行了。

处置:把 permit ip 从"电信资源 ACL"里删掉,改为只在流策略最后放一条 classifier default-permit 兜底。

教训:ACL 里永远不要写"放行所有",尤其是在 PBR 的分类 ACL 里。 兜底应该放在流策略的最后一个 classifier,而不是 ACL 内部。

坑三:NAT 之后 PBR 不生效

现象:配好 PBR 后,笔记本访问电信资源正常,但服务器区(走 NAT 出去)的流量不按 PBR 走。

根因:NAT 和策略路由的处理顺序。数据包先做了源 NAT,源地址变成公网地址,PBR 的 ACL 如果只匹配 192.168.10.0/24 就匹配不上服务器区了。

处置:在 PBR 的 ACL 里补上公网源段,或者改为匹配目的地址(本案例就是按目的地址选的,所以本不该出问题——实际是 ACL 里多写了一条 source 限制)。

教训:PBR 的 ACL 尽量只匹配目的地址,不要在分类 ACL 里加源地址限制,否则 NAT 前后会对不上。

坑四:IPSec 隧道通了但业务不通

现象:display ike sa 显示 Established,display ipsec sa 也有 SA,但总部 ping 不通分支内网。

根因:感兴趣流(ACL)写反了。总部侧的 ACL 只写了 source 192.168.0.0/16 → destination 10.50.0.0/16,但分支侧回包的源是 10.50.x.x,目的是 192.168.x.x,分支的 ACL 里没写这条,回包被判为"不感兴趣",没进隧道。

处置:两侧的 ACL 都写成双向(或者确保两侧镜像对称)。

教训:IPSec 的感兴趣流必须是"双向对称"的。这是 IPSec 排查的第一顺位检查项——先看两侧 ACL 是否互为镜像。

坑五:联通链路"看起来是通的",其实一直在丢包

现象:NQA 显示联通是通的,但走联通的业务(访问联通资源)很慢。

排查:抓包发现联通链路上有大量重传,链路 up 但质量很差(运营商侧拥塞)。

根因:NQA 只看"包能不能通",不看"质量好不好"。ICMP 探测包很小,偶发丢包也能通,但大流量业务就暴露了。

处置:增加质量监控——在 NQA 里同时监控时延(display nqa results 有时延字段),超过门限告警;或者用镜像口抓包分析重传率。

教训:“链路存活"和"链路可用"是两件事。 NQA 解决前者,后者要靠时延/丢包率监控。这也是为什么 42.1.2 的需求里把"带宽监控"列为 P2——它不是保命的,但决定了用户体验。

42.8 本章小结

42.8.1 关键决策回顾

决策 选择 关键理由
选路机制 PBR + 浮动静态 PBR 管"走哪条”,浮动静态管"挂了怎么办"
故障检测 NQA(不是 BFD) 运营商侧不支持 BFD,只能自己探测
3 秒怎么实现 frequency 1 + probe-count 3 探测频率 × 判定次数 = 发现时间
防火墙位置 出口串接 + 双机热备 安全边界清晰,单点靠 HA 解决
NAT 与 PBR 顺序 PBR 的 ACL 只匹配目的地址 避免 NAT 后源地址变化导致失配
IPSec 双隧道主备 隧道本身也要有冗余

42.8.2 三条"必须记住"的经验

  1. ACL 里绝不写 permit ip 做兜底——兜底要放在流策略的最后一个 classifier。
  2. PBR 的分类 ACL 尽量只匹配目的地址——别加源地址限制,否则 NAT 前后对不上。
  3. IPSec 的感兴趣流必须两侧镜像对称——这是隧道通了但业务不通的第一嫌疑人。

42.8.3 自测题

  1. 为什么"3 秒切换"不能靠接口 down 来判断?什么情况下接口 down 是靠不住的?
  2. frequency 1 + probe-count 3 理论最坏发现时间是多少秒?如果配成 frequency 5 呢?
  3. PBR 的 ACL 里为什么不能写 permit ip?
  4. IPSec 隧道显示 Established 但业务不通,第一个该查什么?
  5. NQA 显示链路是通的,但业务很慢,可能是什么原因?
  1. 因为运营商线路中断时,本地接口往往仍然是 up 的——光猫还在发光,只是对端收不到信号。这种"物理上连着但逻辑上不通"的情况,接口状态不会报错,只能靠主动发包探测(NQA/BFD)才能发现。

  2. frequency 1 × probe-count 3 = 最坏 3 秒(每秒探测一次,连续 3 次失败判定断开)。如果配成 frequency 5,最坏就是 15 秒,直接违反 3 秒指标。

  3. 因为 ACL 是"先匹配先走",permit ip 会把所有流量都放行,后面的具体网段规则永远匹配不到。兜底放行应该写在流策略的最后一个 classifier 里,而不是 ACL 内部。

  4. 第一个该查 IPSec 感兴趣流(ACL)是否两侧镜像对称。最常见的错误是总部侧写了 192.168.x.x → 10.50.x.x,但分支侧没写回程的 10.50.x.x → 192.168.x.x,导致回包进不了隧道。

  5. 可能是链路质量差但没完全断——比如运营商侧拥塞导致大量丢包和重传。NQA 只验证"包能不能通",不反映质量。需要额外监控时延和丢包率,或用镜像口抓包分析重传。


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