华为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 段写多之后维护成本高,需要定期更新。
42.3.2 决策二:BFD、NQA 还是 ip-link
这是实现"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 三条"必须记住"的经验
- ACL 里绝不写
permit ip做兜底——兜底要放在流策略的最后一个 classifier。 - PBR 的分类 ACL 尽量只匹配目的地址——别加源地址限制,否则 NAT 前后对不上。
- IPSec 的感兴趣流必须两侧镜像对称——这是隧道通了但业务不通的第一嫌疑人。
42.8.3 自测题
- 为什么"3 秒切换"不能靠接口 down 来判断?什么情况下接口 down 是靠不住的?
frequency 1+probe-count 3理论最坏发现时间是多少秒?如果配成frequency 5呢?- PBR 的 ACL 里为什么不能写
permit ip? - IPSec 隧道显示 Established 但业务不通,第一个该查什么?
- NQA 显示链路是通的,但业务很慢,可能是什么原因?
-
因为运营商线路中断时,本地接口往往仍然是 up 的——光猫还在发光,只是对端收不到信号。这种"物理上连着但逻辑上不通"的情况,接口状态不会报错,只能靠主动发包探测(NQA/BFD)才能发现。
-
frequency 1×probe-count 3= 最坏 3 秒(每秒探测一次,连续 3 次失败判定断开)。如果配成frequency 5,最坏就是 15 秒,直接违反 3 秒指标。 -
因为 ACL 是"先匹配先走",
permit ip会把所有流量都放行,后面的具体网段规则永远匹配不到。兜底放行应该写在流策略的最后一个 classifier 里,而不是 ACL 内部。 -
第一个该查 IPSec 感兴趣流(ACL)是否两侧镜像对称。最常见的错误是总部侧写了
192.168.x.x → 10.50.x.x,但分支侧没写回程的10.50.x.x → 192.168.x.x,导致回包进不了隧道。 -
可能是链路质量差但没完全断——比如运营商侧拥塞导致大量丢包和重传。NQA 只验证"包能不能通",不反映质量。需要额外监控时延和丢包率,或用镜像口抓包分析重传。
关于本书:《华为 / H3C 网络设备典型功能配置详解》—— 面向国内高校/企业网络环境, 华为 VRP 与 H3C Comware 双厂商并排配置的实操教材,共 43 章。 全书所有命令尽量有官方出处,查不到的显式标注「待核实」。 返回系列目录
本人保留对侵权者及其全家发动因果律武器的权利
版权提醒
如无特殊申明,本站所有文章均是本人原创。转载请务必附上原文链接:https://www.elliot98.top/post/huawei-h3c-book/42/。
如有其它需要,请邮件联系!版权所有,违者必究!