📚 课程目录第4章租户路由表与全局路由表交互

4. 租户路由表与全局路由表交互

在Arista EOS的多租户网络中，VRF（Virtual Routing and Forwarding）实例把一台物理交换机切分成多张彼此独立的逻辑路由表。理解租户VRF与默认VRF（default VRF，即全局路由表）之间的交互，是设计隔离方案和排查跨租户通信问题的核心。本节围绕四件事展开：管理VRF的定位、默认VRF的角色、路由泄漏的实现方式，以及跨VRF通信的需求边界与限制。

一、管理VRF与默认VRF的定位

默认VRF是EOS启动后天然存在的全局路由表，所有未显式绑定VRF的接口、管理流量和路由协议默认都落在其中。管理VRF（Management VRF）则是一个特殊用途的VRF，通常命名为management，用于承载带外管理流量。它的价值在于：即使业务VRF的路由表被大量前缀占满、或业务侧发生路由震荡，管理平面仍能通过独立的路由表和独立的接口（如Management1）保持可达，运维人员不会因为业务故障而失去登录通道。

需要区分两个概念：管理VRF是“一个被约定俗成用于管理的VRF实例”，而默认VRF是“系统内置的全局表”。二者不是同一层级的对象。管理VRF中的路由不会自动出现在默认VRF中，反之亦然。若希望管理网段与业务网段互通，必须显式做路由泄漏或使用带VRF感知的协议。

二、路由泄漏：让前缀跨越VRF边界

路由泄漏（route leaking）指把某个VRF中的路由导入到另一个VRF的路由表中。EOS提供两种主要手段：一是基于静态路由的泄漏，二是基于路由映射（route-map）配合BGP的泄漏。静态泄漏最直观，适合少量、固定的前缀；BGP泄漏适合动态、规模较大的场景。

静态泄漏的典型写法是在目标VRF中写一条指向源VRF接口的静态路由，并指定下一跳所在的VRF。例如，把租户A的10.10.10.0/24泄漏到默认VRF，可在默认VRF中配置：

ip route vrf default 10.10.10.0/24 Vlan100 10.0.0.2
! 其中 Vlan100 属于租户A的VRF，10.0.0.2 为租户A侧下一跳

更规范的做法是使用ip route vrf <目标VRF> <前缀> <出接口> <下一跳> vrf <源VRF>的形式，明确指定下一跳所属的VRF，避免EOS在错误的路由表中解析下一跳。BGP泄漏则通过route-map在import或export方向匹配前缀并设置属性，再配合redistribute或neighbor ... route-map完成。无论哪种方式，泄漏都是单向的：A泄漏到B，不等于B泄漏到A，双向互通需要两条方向相反的泄漏策略。

路由泄漏会打破VRF的隔离假设。一旦泄漏，两个VRF之间就存在可达路径，原本依赖隔离实现的安全边界随之消失。因此泄漏必须配合前缀过滤和访问控制，只放行必要的业务前缀。

三、跨VRF通信的需求与限制

跨VRF通信的需求通常来自三类场景：租户访问共享服务（如DNS、NTP、AD域控）、租户访问互联网出口、运维网段访问租户设备。这些需求的共同点是“有限、可控、可审计”，而不是“任意互通”。

限制主要体现在三方面。第一，转发面限制：VRF之间没有天然的转发路径，必须通过泄漏、共享接口或外部设备（如防火墙、路由器）中转。第二，控制面限制：不同VRF中的路由协议实例相互独立，OSPF进程、BGP对等体默认不跨VRF交换路由。第三，策略限制：即使做了泄漏，也需要用前缀列表、route-map、ACL控制哪些前缀可以进入、哪些流量可以转发。

一个常见的误区是认为“把两个接口放进同一个VRF就能互通”。实际上，接口属于哪个VRF，决定了它参与哪张路由表；跨VRF互通必须显式建立路径。另一个误区是认为“泄漏了路由就等于放通了流量”，路由可达只是第一步，ACL和防火墙策略仍需单独配置。

四、典型配置案例

假设一台Arista交换机上划分三个VRF：default（全局）、Tenant-A、Tenant-B。需求是：Tenant-A和Tenant-B各自隔离，但都能访问默认VRF中的共享DNS服务器192.168.100.10；同时默认VRF中的运维网段192.168.200.0/24可以访问Tenant-A的管理地址10.10.10.1。

实现思路分三步。第一步，在Tenant-A和Tenant-B中分别配置指向共享服务的静态路由，下一跳指向默认VRF中的共享网关。第二步，在默认VRF中配置指向两个租户网段的回程路由，并指定下一跳所属VRF。第三步，用ACL限制只允许DNS端口和运维管理端口，其余流量丢弃。

! 租户A访问共享DNS
ip route vrf Tenant-A 192.168.100.0/24 Vlan100 192.168.100.1 vrf default

! 默认VRF回程到租户A
ip route vrf default 10.10.10.0/24 Vlan100 10.10.10.1 vrf Tenant-A

! 运维网段访问租户A管理地址
ip route vrf default 10.10.10.1/32 Vlan100 10.10.10.1 vrf Tenant-A

! 限制只放行必要流量
ip access-list TENANT-A-IN
   10 permit udp any host 192.168.100.10 eq 53
   20 permit tcp 192.168.200.0/24 host 10.10.10.1 eq 22
   30 deny ip any any

验证时，先在Tenant-A中执行show ip route vrf Tenant-A确认192.168.100.0/24已出现且下一跳正确；再在默认VRF中执行show ip route vrf default确认回程路由存在；最后用ping vrf Tenant-A 192.168.100.10和traceroute vrf Tenant-A 192.168.100.10观察实际转发路径。若ping不通但路由存在，优先检查ACL是否误拦、下一跳VRF是否写错、以及共享服务侧是否有回程路由。

从这张图可以清楚看到：默认VRF位于中心，两个租户VRF各自独立；泄漏是双向箭头，意味着必须成对配置；租户之间用红色虚线表示默认隔离，除非显式建立泄漏路径，否则无法互通。ACL则像一道闸门，决定泄漏之后哪些流量真正被放行。

工程实践中，建议把“哪些前缀允许泄漏、泄漏到哪个VRF、由哪条ACL控制”记录成一张路由泄漏矩阵表，作为变更和审计的依据。矩阵表的行是源VRF，列是目标VRF，单元格填写允许的前缀和策略名称。这样在新增租户或调整共享服务时，能快速判断需要修改哪些泄漏条目，避免遗漏回程路由导致单向可达。

最后强调一个排障顺序：先确认源VRF中是否有目标前缀且下一跳正确，再确认目标VRF中是否有回程前缀，然后检查ACL和防火墙策略，最后用带VRF参数的ping和traceroute验证实际路径。多数跨VRF不通的问题，根源都在“只配了去程、没配回程”或“下一跳VRF写错”这两点上。