从 CE 上的一条 RIP 路由到远端 VRF：export 发生在哪一步

一条 RIPv2 update 到达 provider edge，进入 VRF 路由表，然后就停在那里，除非有人显式地把它 export 出去。三个判断依次发生，每一个都能以各自的原因拒绝该前缀。把它们当成一件事来理解，正是远端站点无法访问 CE 明明在通告的网络时，人们查错设备的原因。沿着 PE 把这条路由走一遍，顺序就清楚了。

PE 收到 RIP update 后做了什么

PE 在 VRF 接口上收到 update，确认来源是允许的邻居，然后把前缀装进 VRF 路由表，跳数由通告推导而来。这张表就是一张普通的路由表，有自己的管理距离，也有自己的最优路径选举。如果 CE 用不同 metric 两次通告同一个前缀，只有更好的那个会留在表里。这一步与运营商骨干网毫无关系。

此时前缀只存在于某个客户的路由上下文里，离在其他地方可达还差得很远。

export 是策略行为，不是协议的必然结果

要离开 VRF，一条路由必须被重分布进承载 VPN 路由的 MP-BGP 进程，并且需要带有 route target extended community，用它指明哪些远端 VRF 可以 import 它。这套架构见 RFC 4364，它正是出于这个原因，把这些交换与 CE-PE 协议分开。在边缘使用 RIP，并不说明什么应当穿过运营商网络。

在配置任何东西之前，先把 export 约定写下来：哪些客户前缀必须能从远端访问，哪些路由必须留在本地，以及任何默认路由、更具体的路由或共享服务的例外。把这个约定与真实的 VRF 对照，而不是与另一个客户名下同名的那一个对照。

import 一侧是第二套策略，有自己的 route target；export 匹配而 import 不匹配，就会产生一个存在于骨干网、却不出现在任何远端表里的前缀。

重分布与显式注入的行为不同

重分布取的是 VRF 表里已经存在的路由，经 route map 过滤后复制进 BGP。map 决定哪些前缀有资格、携带什么属性；metric 必须显式设置，因为 RIP 的跳数作为 BGP metric 没有意义。你没有设置的部分会被继承下来，方式通常让半年后读配置的人吃惊。

双向重分布才是暗伤发生的地方。导进 BGP 的前缀可能从第二个重分布点绕回来；没有 tag 或过滤时，路由来回振荡，而两张表在任何瞬间看起来都合理。要在边缘打的 tag 上做过滤，而不是指望拓扑去阻止回程。

显式注入看起来更整洁，却不是无条件的。network 语句通常要求路由表里先有一条匹配的路由，前缀才会被注入，所以 CE 一旦停止通告，这条通告就消失了。这往往正是你想要的行为，它与一条永远配置在那里的静态路由并不相同。去查平台的实际规则，而不是假定两者之一。

无论哪种方式，对每个前缀要问的是：哪一个活跃来源让它有资格，以及那个来源消失时会发生什么。

在四个地方验证这条链路

依次看 CE 的通告、VRF 路由表、带 route target 的 VPN 路由表，以及远端 VRF 的 import。在 IOS 上，这就是 CE 邻居的输出、show ip route vrf CUSTOMER、show ip bgp vpnv4 vrf CUSTOMER，以及在远端 PE 上执行同样的命令。在 IOS-XR 上，等效输出位于 show bgp vrf CUSTOMER ipv4 unicast 之下。命令的名字不同，四个检查点相同。

检查一条应当被拒绝的前缀，要和检查一条应当通过的前缀一样仔细，因为一条放行一切的策略在第一个例外到来之前，看起来和正确的策略一模一样。然后再观察一次撤销：关掉 CE 接口，确认远端条目在预期计时器内消失，而不是继续赖着。

记录每套策略归谁负责。当运营商代管 CE 时，交付的行为属于服务合同的一部分；受管设备上出现不同的协议或撤销策略，首先是一个文档问题，其次才是路由问题。