华为H3C实战 | 第17章 VRF 与网络虚拟化

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

← 上一篇：第 16 章 IPv6 基础配置与地址自动配置 　下一篇：第 18 章 ACL 与路由策略 →

本章导读：一台物理设备能不能同时服务两家客户、而这两家客户的地址段完全一样？能不能让办公网和生产线用同一个 192.168.1.0/24 还不打架？这正是 VRF（虚拟路由转发）要解决的问题。本章从"一台设备虚拟成多台"讲起，重点是两个最容易被误解的概念——RD 只是区分、RT 才决定互通，以及一个最容易被忽略的操作陷阱——绑定 VRF 会清空接口上的 IP 地址。学过本章，你能独立设计并配好一套多租户或业务隔离的组网。

17.1 功能原理与业务场景

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

一栋写字楼里租了两家公司：A 公司在 3 楼，B 公司在 5 楼，两家都有"总经理"这个职位。如果整栋楼只有一个收发室、一套通讯录，那"总经理"就重名了——邮件不知道该送给谁。

解决办法是：收发室还是那一个，但给每家公司配一套独立的信箱和通讯录。A 公司的通讯录里"总经理"是张三，B 公司的通讯录里"总经理"是李四，两套通讯录互不相干，永远不会串。

VRF（Virtual Routing and Forwarding，虚拟路由转发）做的就是这件事。它把一台物理设备虚拟成多台互相独立的逻辑路由器，每台逻辑路由器有自己的一套：

这意味着：两家公司的网络地址可以完全相同，因为它们在设备的"大脑"里是两套完全独立的表，谁都看不到对方的。

17.1.2 VRF 与 VLAN 的区别（最重要的一张表）

这是初学者第一道坎——很多人觉得"我已经用 VLAN 隔离了，为什么还要 VRF？"

一句话记住区别：

VLAN 是"隔开广播域"，VRF 是"隔开路由表"。VLAN 解决"谁能收到谁的二层广播"，VRF 解决"两个网段重名怎么共存"。

举个最能说明问题的例子：某公司要上线一套测试环境，测试环境的服务器 IP 和现网完全一样（10.0.0.0/8），因为开发人员图省事直接克隆了虚拟机。如果用 VLAN，你把测试环境放进 VLAN 100——但它的网关 10.0.0.1 和现网网关 10.0.0.1 在同一台核心上根本配不了两条（同一个地址不能配两次）。用 VRF，两个 10.0.0.0/8 各在一个 VRF 里，两套网关都叫 10.0.0.1，和平共存。

17.1.3 典型应用场景

VRF 与 MCE 的关系：MCE（Multi-VPN-Instance CE，多实例 CE）不是一个独立技术，它就是"在 CE 设备上启用 VRF“这个用法的名字。理解了 VRF，MCE 就自然懂了。

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

17.2 核心概念：RD、RT 与 VPN 实例

17.2.1 VPN 实例（VRF 在设备上的名字）

在华为和 H3C 上，VRF 的落地形式叫 VPN 实例（VPN instance）。“VRF"是协议概念，“VPN 实例"是设备上的配置对象，两者基本可以当同义词。

一个 VPN 实例包含三样东西：

1. RD（Route Distinguisher，路由标识） —— 必须有
2. RT（Route Target，路由目标） —— 必须有（跨设备交换路由时）
3. 绑定的接口 —— 后续用 ip binding vpn-instance 挂上去

17.2.2 RD：只是"区分”，不影响转发

RD 的作用是给每条路由打一个"身份证号前缀”，让不同 VRF 里的同一条路由能够被区分开。

举例：A 租户的 VRF 里有 192.168.1.0/24，B 租户的 VRF 里也有 192.168.1.0/24。当这两条路由要被同一台设备（或通过 MP-BGP 传播到对端设备）时，设备怎么知道哪条是哪条？靠 RD：

这样就区分开了。

RD 的三种格式（华为官方命令参考原文）：

两个硬规矩：自治系统号和用户自定义数不能同时为 0（0:0 非法）。

最关键的一句：

RD 不影响转发，它只影响"这条路由叫什么名字”。

RD 是本地唯一的标识符，它的作用仅限于"让两条同名路由不打架"。它完全不管"谁能学到我、我能学到谁"——那件事归 RT 管。

17.2.3 RT：才决定"谁能和谁互通"

RT 是路由的"通行证"。它的工作方式是两个方向：

互通的条件是：A 的 export RT = B 的 import RT（或者至少有一个交集）。

举例：要打通 VRF-A 和 VRF-B 两个租户的路由（比如两个租户要共享一台公共打印机服务器）：

VRF-A 的配置：vpn-target 100:1 export-extcommunity   ← A 发出的路由打上 100:1
                 vpn-target 100:1 import-extcommunity   ← A 只想收带 100:1 的路由

VRF-B 的配置：vpn-target 100:1 both                    ← B 发出和接收都用 100:1

这样 A 发出的路由带着 100:1，B 看到"这个标签我认识（import 里有）"，学进来；反之亦然。

如果把 B 的 import 写成 100:2，那么 A 发出的路由带着 100:1，B 一看"这标签我不认识"，直接丢掉——两个 VRF 就是不通。而这时候 RD 配得再对也没用。

这就是最大的概念误区：

很多人以为"配了 RD 就配好了 VRF"。错。RD 只解决"路由叫什么"，RT 才解决"路由给了谁"。配完 RD 不通，十有八九是 RT 没对上。

17.2.4 公网表与 VRF 表是两套独立系统

一台设备上，“公网路由表"和每个 VRF 的路由表是完全分开的：

              ┌──────────────────────────────────────┐
              │        一台物理设备                   │
              ├──────────────────────────────────────┤
              │  公网路由表（global）                 │
              │   192.168.1.0/24  ← 没绑 VRF 的接口  │
              ├──────────────────────────────────────┤
              │  VRF-A 路由表                        │
              │   192.168.1.0/24  ← A 租户的接口    │
              ├──────────────────────────────────────┤
              │  VRF-B 路由表                        │
              │   192.168.1.0/24  ← B 租户的接口    │
              └──────────────────────────────────────┘

后果一：查路由时必须带 vpn-instance 参数。你在设备上敲 display ip routing-table，看到的只有公网表——VRF 里的路由一条都看不到。这是新手最常见的"我明明配了路由怎么查不到”。

后果二：默认路由要在每个 VRF 里分别配。你在公网表里配了 ip route-static 0.0.0.0 0 1.1.1.1，VRF-A 里的用户照样上不了网——它得有自己的默认路由。

后果三：两个 VRF 之间默认完全不通，即使在同一台设备上。要通必须显式做（静态路由指向 / 路由泄漏 / 中间用防火墙），见 17.7。

17.2.5 接口归属：一个接口只能属于一个 VRF

一个三层接口（VLANIF、三层以太口、子接口）同时只能绑定一个 VRF。绑了就不再是"公网接口"。

绑定之后，这个接口：

• 加入该 VRF 的路由表（直连路由出现在 VRF 表里，不在公网表里）
• 只能配该 VRF 内的地址（地址可以和其他 VRF 重复）
• 跑的动态路由协议属于该 VRF 的实例

出处：

• RD 格式与取值：华为命令参考 route-distinguisher（references/huawei/EDOC1100212558.txt 第 142591 行起，原文列出 2 字节 AS:4 字节、整数 4 字节 AS:2 字节、点分 4 字节 AS:2 字节、IPv4 地址:2 字节四种格式及各自取值范围）
• RT 格式与方向：华为 vpn-target（同文件第 143310 行起，命令格式 vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-extcommunity ]）
• RT 的作用机制：H3C 官方原文「RT 用来控制 VPN 路由的发布。PE 在发布的 VPN 路由中添加 RT 扩展团体属性，该属性的值为配置的 Export Target。对端 PE 接收到 VPN 路由后，将路由中携带的 RT 属性与本地配置的 VPN 实例的 Import Target 进行比较，如果二者中存在相同的值，则将该路由学习到该 VPN 实例的路由表中」（references/h3c/1203718_mce_cmd.txt 第 1189 行起）

17.2.6 一个必须想清楚的问题：VRF 之间到底要不要通

初学者学完 RD/RT 常常直接问"那我怎么让两个 VRF 通？"。先别急着配，先问一句：这个互通是不是真的需要？

默认"不通"是特性，不是缺陷。 VRF 存在的全部意义就是隔离。如果两个租户本来应该互相看不见，那"不通"就是正确结果，你不需要做任何事。

只有下面三种情况才需要考虑打通：

为什么强烈建议"过防火墙"而不是直接泄漏路由：路由泄漏做出来的互通是三层直通——一旦路由通了，两边的所有主机都能互相访问，没有任何访问控制。如果这是两个客户，等于你把客户 A 和客户 B 的网络直连了，出了安全事故责任在你。而走防火墙，流量要经过安全策略检查，能控到"谁能访问谁的哪个端口"。

一个设计建议：如果确实需要"多租户 + 共享服务"，正确的做法是在第一天就规划好 VRF-SHARED，让所有租户的 VRF 都 import 它的 export RT，而不是事后给每个租户单独做点对点的泄漏。前者是加法，后者是乘法——租户一多，点对点泄漏的配置量会爆炸。

17.2.7 VRF 的三层隔离能到什么程度

最后一个概念层面的问题：VRF 到底"隔"得多彻底？

最后三行很重要：VRF 隔离的是"逻辑上的网络"，不隔离"物理上的资源和故障"。 一台设备上跑 20 个租户的 VRF，这 20 个租户共享同一块 CPU、同一条上联、同一个电源——设备挂了 20 个一起断。要解决这个，需要的是设备冗余（堆叠/双机），不是 VRF。

所以完整的隔离方案通常是三层叠加：

二层隔离  →  VLAN / 端口隔离
三层隔离  →  VRF
硬件隔离  →  独立设备 / 双机冗余

只做其中一层，都会留下漏洞。

17.3 华为设备配置详解

17.3.1 命令行基础速览

17.3.2 完整配置模板：多租户组网（本章核心案例）

场景：一台核心交换机（S5735-L24T4S-A1）给两个部门做网关。两个部门用了完全相同的地址段 192.168.1.0/24（比如都是从同一个模板克隆的环境）。这正是在一张路由表里绝对做不到、而 VRF 天生能做的事。

                    [ 一台核心交换机 ]
                     Vlanif10 → 绑定 VRF-DEPT_A
                     Vlanif20 → 绑定 VRF-DEPT_B
                     Vlanif30 → 公网/上行（不绑 VRF）
                          |
        +-----------------+------------------+
        |                                    |
   VLAN 10（A 部门）                    VLAN 20（B 部门）
   IP: 192.168.1.1/24                   IP: 192.168.1.1/24   ← 完全相同的网段！
   绑定 VRF-DEPT_A                      绑定 VRF-DEPT_B
        |                                    |
   PC-A: 192.168.1.10                   PC-B: 192.168.1.10   ← 连 IP 都一样
   网关: 192.168.1.1                    网关: 192.168.1.1

完整配置：

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

# ===== 第一部分：创建两个 VPN 实例 =====

# A 部门的 VRF
ip vpn-instance VRF-DEPT_A
 # RD：用于区分同名路由，写成本地唯一的即可
 route-distinguisher 100:1
 # RT：both 表示收发都用这个标签
 vpn-target 100:1 both
 quit

# B 部门的 VRF
ip vpn-instance VRF-DEPT_B
 route-distinguisher 100:2
 # 注意：B 用 100:2，与 A 的 100:1 不同 → 两个 VRF 默认不互通
 vpn-target 100:2 both
 quit

# ===== 第二部分：创建 VLAN 和接口 =====

vlan batch 10 20 30

# ---- A 部门网关 ----
interface Vlanif 10
 # 关键顺序：先绑定 VRF，再配 IP
 ip binding vpn-instance VRF-DEPT_A
 # 绑定后配的 IP 属于 VRF-A，公网表里看不到
 ip address 192.168.1.1 255.255.255.0
 quit

# ---- B 部门网关 ----
interface Vlanif 20
 ip binding vpn-instance VRF-DEPT_B
 # 和 A 完全相同的网段，完全相同的网关地址，互不冲突
 ip address 192.168.1.1 255.255.255.0
 quit

# ---- 上行接口（公网，不绑 VRF）----
interface Vlanif 30
 ip address 10.200.1.1 255.255.255.252
 quit

save

配完之后，三张路由表是这样的：

这份配置证明了 VRF 的核心价值：同一个 192.168.1.1 在设备上被配了两次，但因为在不同的路由表里，完全不冲突。

17.3.3 VRF 内的路由：静态、OSPF、BGP

（1）VRF 内静态路由

公网表的静态路由是 ip route-static <目的> <掩码> <下一跳>，VRF 里的要加 vpn-instance 前缀：

# 在公网表里配静态路由（默认路由指向 ISP）
ip route-static 0.0.0.0 0.0.0.0 10.200.1.2

# 在 VRF-DEPT_A 里配静态路由（默认路由指向该 VRF 的出口）
ip route-static vpn-instance VRF-DEPT_A 0.0.0.0 0.0.0.0 10.200.1.2

# 在 VRF-DEPT_B 里配默认路由（注意：单独一条，不能共用）
ip route-static vpn-instance VRF-DEPT_B 0.0.0.0 0.0.0.0 10.200.1.2

这三条命令说明了一个重要事实：同一个下一跳，每个 VRF 都要单独写一条默认路由。你在公网表配的那条，VRF 里的用户一个都用不上。

⚠ 注意下一跳的可达性：VRF 内的静态路由，下一跳必须在该 VRF 的路由表里可达。如果 10.200.1.2 是公网接口的邻居地址，VRF-A 的表里根本查不到它，这条路由不会生效。跨 VRF 的下一跳需要特殊处理（见 17.7.5）。

（2）VRF 内 OSPF（多实例）

OSPF 支持按 VRF 起多个实例，命令是 ospf <进程号> vpn-instance <名字>：

# VRF-DEPT_A 里的 OSPF 实例（进程号 10）
ospf 10 vpn-instance VRF-DEPT_A router-id 10.200.1.1
 area 0
  # 注意：network 声明的是该 VRF 内的地址
  network 192.168.1.0 0.0.0.255
  quit
 quit

# VRF-DEPT_B 里的 OSPF 实例（进程号 20，必须与 A 不同）
ospf 20 vpn-instance VRF-DEPT_B router-id 10.200.2.1
 area 0
  network 192.168.1.0 0.0.0.255
  quit
 quit

两个实例的 network 声明完全一样（都是 192.168.1.0/24），但因为分属不同的 VRF，互不干扰。

（3）VRF 内 BGP（BGP VPN 实例）

BGP 的写法是先起全局 BGP 进程，再在一个 ipv4-family vpn-instance 子视图里配：

# 全局 BGP 进程（本 AS 号）
bgp 65001
 # 为 VRF-DEPT_A 建立独立的 IPv4 地址族视图
 ipv4-family vpn-instance VRF-DEPT_A
  # 在这个视图里配邻居、宣告网段，都属于该 VRF
  peer 10.200.1.2 as-number 65002
  network 192.168.1.0 255.255.255.0
  quit

 # 为 VRF-DEPT_B 再建一个
 ipv4-family vpn-instance VRF-DEPT_B
  peer 10.200.2.2 as-number 65002
  network 192.168.1.0 255.255.255.0
  quit
 quit

BGP 与 VRF 是天然搭配：VRF 提供隔离的路由表，BGP（尤其是 MP-BGP）提供跨设备传递带 RD/RT 的 VPN 路由。企业内网如果只是单机多租户，用静态路由或 OSPF 多实例就够了；要跨设备扩展，才需要上 BGP。

17.3.4 逐行讲解

出处：ip vpn-instance、route-distinguisher、vpn-target、ip binding vpn-instance、ip route-static vpn-instance、ospf <进程号> vpn-instance <名字>、ipv4-family vpn-instance、display ip vpn-instance(487 处)、display ip routing-table vpn-instance(800 处)、display arp vpn-instance(71 处) 均在 references/huawei/ 语料中核实存在。

17.4 H3C 设备配置详解

17.4.1 完整配置模板：同一多租户场景

H3C 的命令和华为高度相似，主要差异在视图进入方式和个别关键字：

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

# ===== 创建两个 VPN 实例 =====
ip vpn-instance VRF-DEPT_A
 route-distinguisher 100:1
 # H3C 的 vpn-target 不给方向参数时，缺省就是 both
 vpn-target 100:1
 quit

ip vpn-instance VRF-DEPT_B
 route-distinguisher 100:2
 vpn-target 100:2
 quit

# ===== 创建接口并绑定 =====
vlan 10 20 30
 quit

interface Vlan-interface 10
 ip binding vpn-instance VRF-DEPT_A
 ip address 192.168.1.1 255.255.255.0
 quit

interface Vlan-interface 20
 ip binding vpn-instance VRF-DEPT_B
 ip address 192.168.1.1 255.255.255.0
 quit

interface Vlan-interface 30
 ip address 10.200.1.1 255.255.255.252
 quit

save force

17.4.2 H3C 的四处差异

关于 H3C 的 address-family ipv4 优先级，这一点值得单独说：H3C 的 VPN 实例视图和 IPv4 VPN 视图两个地方都能配 RT 等参数，如果两处都配了，以 IPv4 VPN 视图为准。这意味着你在 VPN 实例视图里改了 RT 却发现不生效时，要去 IPv4 VPN 视图里看是不是有另一份配置压着它。

17.4.3 H3C 的 VRF 内路由

OSPF 多实例（语料已核实）：

# H3C 的 OSPF 多实例写法
ospf 100 vpn-instance VRF-DEPT_A
 router-id 10.200.1.1
 area 0
  network 192.168.1.0 0.0.0.255
  quit
 quit

静态路由：

⚠ H3C 的 VRF 内静态路由写法，我没查到官方原文，不照华为猜。

已核实的情况：H3C 的 ip route-static 命令参考（references/h3c/1219381_30005_0.txt）给出的完整语法是 ip route-static dest-address { mask | mask-length } { next-hop-address | interface-type interface-number [ next-hop-address ] } [ preference ] [ tag ] [ permanent ] [ description ]，其中没有 vpn-instance 参数。而华为的写法是前置 vpn-instance <名字>。

上机时请用 ip route-static ? 和 ip route-static vpn-instance ? 补全确认，或查阅对应版本的《三层技术-IP 路由命令参考》中 ip route-static 的完整语法。

⚠ 待核实：待核实 H3C Comware V7 中为 VPN 实例配置静态路由的确切命令写法（是否支持 ip route-static vpn-instance <名> ... 形式，或需在 vpn-instance 上下文内配置）。本章语料中的 ip route-static 命令参考未列出 vpn-instance 参数，不可照搬华为写法

BGP（MCE 场景）：

# H3C 在 BGP 下为每个 VPN 实例配邻居
bgp 100
 address-family ipv4 vpn-instance VRF-DEPT_A
  peer 10.200.1.2 as-number 65002
  quit
 quit

⚠ 待核实：待核实 H3C Comware V7 的 BGP VPN 实例地址族视图准确关键字（华为为 ipv4-family vpn-instance X，H3C 可能为 address-family ipv4 vpn-instance X 或其他形式），本章语料未取到该视图的官方命令格式

出处：

• ip vpn-instance vpn-instance-name、route-distinguisher、vpn-target { ... } [ both | export-extcommunity | import-extcommunity ] 及「缺省 both」说明：references/h3c/1203718_mce_cmd.txt（H3C MCE 命令，第 1160~1210 行）
• ip binding vpn-instance vpn-instance-name、ospf 100 vpn-instance vpna：同上文档
• address-family ipv4 视图与优先级说明：同上，第 1211 行附近（「IPv4 VPN 视图下的配置优先级高于 VPN 实例视图下的配置」）

17.4.4 H3C 的接口绑定与 IP 清除

H3C 的 ip binding vpn-instance 与华为同名同义，行为也一样：绑定会清除接口原有的 IP 地址和三层配置。这一点两家的官方文档都写明了，是 VRF 操作里最需要注意的"静默副作用"。

# 正确顺序：先绑 VRF，再配 IP
interface Vlan-interface 10
 # 绑定 VRF（这一步如果是后做的，会把下面的 IP 清掉）
 ip binding vpn-instance VRF-DEPT_A
 # 绑定之后配的 IP 才属于该 VRF
 ip address 192.168.1.1 255.255.255.0
 quit

一个实操建议：调整接口 VRF 归属时，先把原来接口上的 IP、ACL 应用、路由协议使能等配置记下来（display current-configuration interface Vlan-interface 10），绑完 VRF 再逐条补回去。因为绑定动作清掉的不只是 IP，还有三层特性和 IP 相关的路由协议配置。

⚠ 待核实：待核实 H3C Comware V7 中 ip binding vpn-instance 的确切副作用说明（是否与华为一样明确写「清除接口 IP 地址、三层特性和 IP 相关路由协议」），本章按两家一致的通行行为描述，未取到 H3C 官方原文

17.5 华为 / H3C 命令对照表

这张表的结论：VRF 的基础配置两家几乎一模一样，这是全书里命令相似度最高的技术之一。真正要注意的是三处：H3C 的 vpn-target 可省方向、H3C 有独立的 address-family ipv4 子视图且优先级更高、以及 H3C 的 VRF 内静态路由写法待核。

17.6 配置验证

验证 VRF 要按"建对没 → 绑对没 → 路由对没 → 通不通“四步走。

第一步：VRF 建对没

<HUAWEI> display ip vpn-instance

期望能看到两个实例，且各自有 RD 和 RT：

  VPN-Instance Name and ID : VRF-DEPT_A, 1
    Route Distinguisher : 100:1
    Interfaces :
      Vlanif10
    Address family ipv4 :
      Import VPN target :
        RT : 100:1
      Export VPN target :
        RT : 100:1

  VPN-Instance Name and ID : VRF-DEPT_B, 2
    Route Distinguisher : 100:2
    Interfaces :
      Vlanif20

重点看两行：Route Distinguisher 是否与设计一致、Interfaces 下面是否挂着你期望的接口。如果 Interfaces 是空的，说明 ip binding 没配或配错了。

第二步：接口归没归

# 看接口是否绑定了 VRF
<HUAWEI> display ip vpn-instance verbose

# 或者直接看接口配置
<HUAWEI> display current-configuration interface Vlanif 10

期望看到 ip binding vpn-instance VRF-DEPT_A 和 ip address 192.168.1.1 255.255.255.0 两行都在。如果只有 binding 没有 ip address，就是踩了 17.7.2 那个坑——先绑后配 IP，绑的时候把原来的 IP 清掉了。

第三步：路由在不在（必须带 vpn-instance）

# 查公网表——看不到 192.168.1.0/24
<HUAWEI> display ip routing-table

# 查 VRF-A 的表——能看到
<HUAWEI> display ip routing-table vpn-instance VRF-DEPT_A

# 查 VRF-B 的表——也能看到同一条
<HUAWEI> display ip routing-table vpn-instance VRF-DEPT_B

这一步是 VRF 排错的分水岭。如果 display ip routing-table 里出现了 192.168.1.0/24，说明那个接口没有真正绑定 VRF——它的直连路由跑到公网表里去了。

期望的输出：

VRF-DEPT_A 路由表：
Destination/Mask    Proto   Pre  Cost      NextHop         Interface
192.168.1.0/24      Direct  0    0         192.168.1.1     Vlanif10
192.168.1.1/32      Direct  0    0         127.0.0.1       Vlanif10

第四步：通不通

# 带 VRF 参数 ping（关键：不带参数会走公网表，一定不通）
<HUAWEI> ping -vpn-instance VRF-DEPT_A 192.168.1.10

# 看 VRF 里的 ARP
<HUAWEI> display arp vpn-instance VRF-DEPT_A

ping 必须带 -vpn-instance 参数。直接 ping 192.168.1.10 会走公网表，公网表里没这个网段，必然不通——很多人在这里误判成"VRF 配错了”。

H3C 侧验证命令基本一致：

<H3C> display ip vpn-instance
<H3C> display ip vpn-instance verbose
<H3C> display ip routing-table vpn-instance VRF-DEPT_A
<H3C> display arp vpn-instance VRF-DEPT_A

⚠ 待核实：待核实 华为 ping -vpn-instance <名> 与 display ip vpn-instance verbose 的确切参数形式与输出字段（本章按常见实现给出，未从语料取到该两条命令的官方输出样例）

17.7 排错与故障树

VRF 的故障集中在五个地方，按下面的故障树查：

问题一：VRF 建了，但路由跑到公网表里去了
 ├─ 1. 接口绑定了吗？
 │   └─ display ip vpn-instance 看 Interfaces 列表是不是空的
 ├─ 2. 绑的是正确的 VRF 吗？
 │   └─ 名字大小写、拼写是否一致
 └─ 3. 是不是先配 IP 再绑定，绑定后 IP 被清、直连路由自然没了？
     └─ display current-configuration interface 看 ip address 还在不在

问题二：绑了 VRF 之后接口的 IP 没了
 └─ 这不是故障，是官方设计行为（见 17.7.2），重新配 IP 即可

问题三：两个 VRF 之间不通
 ├─ 1. 这是默认行为——VRF 本来就是隔离的，不通是对的
 ├─ 2. 想通：要么用静态路由跨 VRF 指（需下一跳可达）
 │      要么做路由泄漏（import/export RT 配对）
 │      要么中间串一台防火墙做跨 VRF 转发
 └─ 3. 走了 RT 方案还是不通 → 查 RT 是否真匹配（见问题四）

问题四：配了 RD 和 RT，两个 VRF 还是不通
 ├─ 1. A 的 export RT 与 B 的 import RT 不相等
 │   └─ display ip vpn-instance 逐字比对 RT 值
 ├─ 2. RT 配在了错误的视图（H3C 有两个视图，IPv4 VPN 视图优先级更高）
 ├─ 3. 中间设备没有正确传递 VPN 路由（需要 MP-BGP，不是普通 BGP）
 └─ 4. 只配了 RD 没配 RT → 路由出不去也进不来

问题五：跨 VRF 访问不通（如 A 要访问公网）
 ├─ 1. VRF 里没有默认路由 → 每个 VRF 都要单独配
 ├─ 2. 默认路由的下一跳在该 VRF 里不可达 → 换成可达的下一跳或走泄漏
 └─ 3. 出口设备没做 NAT 或没放行 → VRF 的流量到出口要做地址转换

17.7.1 五个高频故障的深入说明

（1）“VRF 建了但路由在公网表里”

最常见的原因是接口没绑或者绑错了 VRF 名。注意 VRF 名区分大小写，VRF-A 和 vrf-a 是两个不同的实例。

另一个隐蔽原因：先配了 IP，后绑 VRF。绑定动作会清空 IP（见下条），IP 没了直连路由自然就没了，你以为是"路由跑到公网去了"，其实是"路由没了"。

（2）绑定 VRF 会删除接口已有 IP —— 这是官方设计，不是 bug

华为官方命令参考原文写得非常明确：

「配置接口与 VPN 实例绑定后，或取消接口与 VPN 实例的绑定，都会清除该接口的 IP 地址、三层特性和 IP 相关的路由协议，如果需要应重新配置。」

正确顺序是：建 VRF → 绑接口 → 配 IP（及其他三层配置）。反过来做，你配的 IP 会被清掉，而且不会有任何报错提示——这是最坑的一点：命令执行成功，配置却没了。

（3）配了 RD 但 RT 不匹配 → 两个 VRF 不通

这是本章最想让你记住的坑。回到 17.2.2 和 17.2.3：RD 只是"给路由起个唯一名字"，RT 才是"决定谁能收到"。

诊断动作：display ip vpn-instance 把两边的 RT 逐字比对。特别要注意方向——A 的 export 必须等于 B 的 import，反过来也一样。如果 A 配了 vpn-target 100:1 export-extcommunity，B 配了 vpn-target 100:2 import-extcommunity，那 A 发出来的路由带着 100:1 标签，B 只认 100:2，直接丢弃。

（4）全局路由表查不到 VRF 路由

不是故障，是设计。VRF 的路由只在 VRF 表里，查的时候必须 display ip routing-table vpn-instance <名字>。同理 ping、tracert 都要带 -vpn-instance。

（5）跨 VRF 怎么通

VRF 之间默认完全隔离。让它们通有三种做法，各有适用场景：

生产环境的建议：多租户之间要互通，优先走防火墙。因为 VRF 之间直接泄漏路由，等于绕过了安全策略——两家租户本来该隔离，结果三层直通了，安全部门会找你。用防火墙做跨 VRF 转发，既能互通又能控策略。

17.7.2 VRF 与 DHCP / NAT / 防火墙 / 无线的配合

VRF 不是孤立的，它要和一批周边功能配合。这里把最容易踩的几个讲清：

（1）VRF 里的 DHCP 池

DHCP 服务器要把地址池绑定到对应的 VRF，否则拿不到地址：

# 全局先启用 DHCP
dhcp enable

# 创建地址池
ip pool POOL_A
 network 192.168.1.0 mask 255.255.255.0
 gateway-list 192.168.1.1
 # 关键：地址池要绑定到该 VRF
 vpn-instance VRF-DEPT_A
 quit

# 在 VRF 内的网关接口上启用 DHCP
interface Vlanif 10
 dhcp select global
 quit

H3C 侧的写法类似，池里也要绑 VRF（vpn-instance VRF-DEPT_A）。没绑 VRF 的地址池只服务公网接口上的 DHCP 请求，VRF 里的用户请求拿不到地址——现象是"VRF 用户拿不到 IP"，而你在池里看不出任何问题。

⚠ 待核实：待核实 华为 ip pool 视图下绑定 VRF 的确切命令（本章写作 vpn-instance VRF-DEPT_A，未从语料取到该命令的官方格式）以及 H3C dhcp server ip-pool 下绑定 VRF 的写法

（2）VRF 出口的 NAT

VRF 里的用户要访问公网，出口设备要做 NAT。关键是 NAT 必须指定 VRF——不带 vpn-instance 的 NAT 只处理公网实例的流量，VRF 里的用户走完全不会命中。

两家厂商的做法差别很大，分别说：

H3C：nat outbound 直接带 vpn-instance 参数

H3C 的 NAT 命令族在接口视图下就支持 vpn-instance，写法直接：

# H3C：给 A 公司的出口做源 NAT，指定其 VRF
# 关键就在末尾这个 vpn-instance 参数
interface GigabitEthernet1/0/1
 nat outbound 3000 address-group 1 vpn-instance VRF-DEPT_A
 quit

# H3C：NAT 静态映射（服务器发布）——最简形式
nat static outbound 192.168.1.10 203.0.113.10

# 需要指定 VRF 时，源和目的可各带一个 vpn-instance（语法支持，但官方示例多用简写）
# nat static outbound 192.168.1.10 vpn-instance VRF-DEPT_A 203.0.113.10 vpn-instance public

这两条命令的官方语法（已核实，H3C 命令参考原文）：

nat outbound [ ipv4-acl-number | name ipv4-acl-name ] address-group
  { group-id | name group-name } [ vpn-instance vpn-instance-name ] ...
nat static outbound local-ip [ vpn-instance local-vpn-instance-name ]
  global-ip [ vpn-instance global-vpn-instance-name ] [ acl ... ]

注意：vpn-instance 修饰的是"哪一侧的地址属于哪个 VPN 实例"，静态映射时源和目的可以各写一个。

华为：走 nat-policy，按安全域 + 地址段匹配

华为的 AR/USG 用 nat-policy 视图做源 NAT，规则里按源安全域、地址段匹配。这个视图下的规则是否直接支持 vpn-instance 参数，本书语料未能核实。 工程上更常见的做法是：让 VRF 的流量先进入防火墙的虚拟路由器（见下面第 3 点），在虚拟路由器实例内做 NAT，而不是在路由器上直接对 VRF 做 NAT。

# 华为：nat-policy 视图的基本结构（供参考，VRF 相关的具体写法见下方 TODO）
nat-policy
 rule name nat_vrf_a
  source-zone trust
  destination-zone untrust
  source-address 192.168.1.0 mask 255.255.255.0
  action source-nat easy-ip
 quit

⚠ 待核实：待核实 华为 AR/USG 上为 VPN 实例内流量做源 NAT 的确切配置方式—— nat-policy 规则视图下是否支持按 vpn-instance 匹配或指定，或需借助防火墙 virtual-router 承接。 本书语料中 nat outbound 与 nat-policy 均未取到含 vpn-instance 的官方语法。

（3）防火墙的 virtual-router（VRF 在安全设备上的实现）

防火墙上的**虚拟路由器（virtual-router）**就是 VRF 在安全设备上的对应实现。一台防火墙可以建多个 virtual-router，每个有独立的路由表、接口和安全策略，用于：

• 多租户场景下不同租户走不同 virtual-router
• 不同业务的安全域之间彻底隔离
• 双机热备时与对端 virtual-router 配对

理解要点：virtual-router 和 VRF 是同一个思想的两套实现——都是"把一台设备切成多台逻辑设备，各自有独立路由表"。你在交换机上学过 VRF，迁移到防火墙上只是命令名换了。

实际工程里最常见的架构：不让路由器/交换机上的 VRF 直接做 NAT，而是把 VRF 的流量引到防火墙，由防火墙的对应 virtual-router 承接——NAT、安全策略、VPN 都在那个实例内完成。这样既解决了"VRF 里做 NAT 各家写法不一"的问题，也顺便获得了防火墙的安全能力。

   VRF-A 用户 ──┐
                ├──> 汇聚交换机（VRF 隔离）──> 防火墙
   VRF-B 用户 ──┘                                ├─ virtual-router A → NAT A → 互联网
                                                  └─ virtual-router B → NAT B → 互联网

⚠ 待核实：待核实 华为 USG6000E 与 H3C F1000 防火墙的 virtual-router（或等价多实例）配置命令， 以及它与交换机 VRF 对接（路由发布、接口归属）的完整流程。

（4）无线认证与 VRF

无线控制器（AC）给不同 SSID / 不同租户的 AP 分配地址时，如果 AC 上启用了 VRF，必须保证三处都绑对：

设计上有一条铁律：AP 管理网和用户业务网不要放在同一个 VRF 里。管理网应该是独立的、干净的、只有 AP 能访问的 VRF；用户网按租户/业务分。这样即使某个业务 VRF 出问题，AP 也不会一起掉线——否则一个 VRF 配错，整栋楼的 AP 全掉，连排错都进不去。

⚠ 待核实：待核实 华为 AC 与 H3C WX 系列在启用 VPN 实例后， AC 源接口（capwap source interface）、AP 管理 VLAN 与用户 VLAN 绑定 VRF 的具体配置要求与命令。

（5）一个务实的建议

VRF 不是越多越好。 每多一层虚拟化，排错的复杂度就多一层——你要记住"这个地址在哪个 VRF 里、这条命令要不要带 vpn-instance、这个功能支不支持 VRF"。只有当"地址段必须重复"或"必须做强隔离"这两个需求至少满足一个时，才值得上 VRF。 如果只是想做访问控制，ACL 就够了。

17.8 新手踩坑与本章小结

17.8.1 新手踩坑与注意事项

1. 以为配了 RD 就完事——RD 只给路由"起名字"，RT 才决定谁能收到。两个 VRF 不通，先查 RT 不查 RD。
2. 先配 IP 再绑 VRF——绑定会静默清除接口 IP 和三层配置。正确顺序：建 VRF → 绑接口 → 配 IP。
3. 查路由时忘了带 vpn-instance——display ip routing-table 只看公网表，VRF 路由得用 display ip routing-table vpn-instance X。
4. ping 时不带 vpn-instance——走公网表，必然不通，容易误判成"VRF 配坏了"。
5. 默认路由只在公网配了一条——每个 VRF 都要各自配，公网那条对 VRF 无效。
6. 以为 VRF 能替代 VLAN——两者层次不同，通常是配合使用：VLAN 做二层隔离，VRF 做三层隔离。
7. VRF 名大小写不一致——VRF-A 和 vrf-a 是两个实例，绑定和查路由时必须完全一致。
8. VRF 之间直接泄漏路由来做互通——绕过了安全策略，等保测评会被指出。生产环境走防火墙。
9. 忘了 H3C 的 vpn-target 缺省是 both——照抄华为写 both 没错，但要知道 H3C 不写也是 both，别以为是漏配。
10. H3C 两个视图都配了 RT——VPN 实例视图 和 IPv4 VPN 视图 都配的话，以后者为准，改了不生效要去另一个视图查。
11. VRF 内静态路由的下一跳在 VRF 里不可达——路由配了不生效，display ip routing-table vpn-instance X 里看不到。
12. VRF 里的 DHCP 池没绑 VRF——用户拿不到地址，池配置看起来完全正常。
13. VRF 叠加太多层——每加一层排错难度都上升。只有"地址必须重复"或"必须强隔离"时才用。

17.8.2 本章小结

• VRF 把一台物理设备虚拟成多台逻辑路由器，各自有独立的路由表、ARP 表、接口归属和路由协议实例。
• VLAN 隔二层、VRF 隔三层。最本质的差别：同名网段在 VLAN 里不能共存，在 VRF 里可以。
• RD 只是区分，RT 才决定互通。RD 给路由起唯一名字，RT 是收发路由的"通行证"——A 的 export 要等于 B 的 import。
• 公网表和 VRF 表是两套独立系统：查路由、ping 都必须带 vpn-instance 参数；默认路由每个 VRF 各配一条。
• 绑定 VRF 会清除接口 IP（两家官方都明确写了），所以顺序必须是：建 VRF → 绑接口 → 配 IP。
• 华为与 H3C 的 VRF 命令相似度极高，要注意的差异只有三处：H3C 的 vpn-target 可省方向、H3C 有独立的 address-family ipv4 子视图且优先级更高、H3C 的 VRF 内静态路由写法待核。
• VRF 不是万能药：只有"地址必须重复"或"必须强隔离"时才值得上，单纯做访问控制用 ACL 就够。

一张纸记牢本章：

自测题

1. 某核心交换机上一个 VLAN 里有两个部门，都用 192.168.1.0/24。只用 VLAN 能做到吗？用 VRF 呢？为什么？
2. RD 和 RT 各解决什么问题？为什么"配了 RD 但两个 VRF 不通"是正常的？
3. ip binding vpn-instance 之后接口 IP 没了，这是 bug 吗？正确的配置顺序是什么？
4. 在 VRF-A 里配了一条默认路由，VRF-B 的用户能用到吗？为什么？
5. 两个 VRF 之间要怎么才能互通？三种做法分别适合什么场景？
6. 华为和 H3C 在 VRF 配置上最主要的三个差异是什么？

1. 只用 VLAN 做不到。两个 VLAN 可以用同一网段吗？技术上 VLAN 本身只隔离广播域，但两个 VLAN 配同一网段的网关（比如都是 192.168.1.1）在同一台三层设备上会冲突——同一个地址不能配在两张同一网段的路由表里。用 VRF 可以：两套独立路由表，各配一个 192.168.1.1，互不冲突。
2. RD 解决"两条同前缀路由如何区分"（给路由起唯一名字，只在本地/传递时用）；RT 解决"谁能收到我的路由、我能收到谁的路由"（export/import 配对）。所以配了 RD 但 RT 不匹配时，路由能被区分开，但不会被对方接收，不通是正常的。
3. 不是 bug，是官方设计。华为官方明确写「配置接口与 VPN 实例绑定后，或取消接口与 VPN 实例的绑定，都会清除该接口的 IP 地址、三层特性和 IP 相关的路由协议」。正确顺序：建 VRF → 绑接口 → 配 IP。
4. 用不到。公网表和 VRF 表是两套独立系统，VRF 内的默认路由要在该 VRF 里单独配。VRF-B 的路由表里没有那条默认路由。
5. 三种：①静态路由跨 VRF 指（下一跳指向对端 VRF 的接口地址，适合简单场景）；②路由泄漏（让 A 的 export RT 出现在 B 的 import 里，适合有 MP-BGP 的场景）；③过防火墙（各接防火墙一个接口做策略转发，适合多租户、有安全管控需求）。生产环境多租户互通优先走防火墙，避免绕过安全策略。
6. ①H3C 的 vpn-target 不写方向参数时缺省是 both（华为必须显式写）；②H3C 有独立的 address-family ipv4 子视图，且其配置优先级高于 VPN 实例视图；③H3C 的 VRF 内静态路由写法本章语料未能核实，不能照搬华为的 ip route-static vpn-instance。

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