L3VPN 交接：私有路由、默认路由还是完整路由表？

你的线路已开通，VRF 已配置，服务商提出了一个决定其余设计的问题：客户边缘应当收到什么？常见的答案有三种，没有一种来自“存在标签栈”这一事实。它们是关于流量从哪里离开分支的服务决策。

按顺序走一遍交接，是把这件事做对的最省事的方式。你从“什么都不匹配的流量会发生什么”开始，然后写下私有前缀及其故障行为，最后才谈你愿意承载多大的 feed。

从没人规划过的流量开始

在任何前缀列表出现之前先问一个问题：当一个数据包不匹配任何私有路由时，它该去哪里？自带互联网线路的分支通常保留一条本地默认路由，于是普通网页流量从本地防火墙出去，从不经过服务商。在这种设计里，VPN 只承载远端私有站点，由更具体的前缀完成选择。

打算使用中心出口的分支是相反的情形。在那里默认路由指向服务内部，由服务商或中心站点负责转发、回程路由以及任何转换。在缺少这个责任方的情况下说“默认走 VPN”，得到的只是一个能解析域名却什么都到不了的分支。

两种设计的差别在于路由故障长什么样，这也是猜测代价高昂的原因。有本地默认路由时，一条丢失的私有路由会把那部分流量送到互联网，被防火墙丢弃，或者更糟，被某个你并不打算的对象回答。有中心默认路由时，同样的丢失会彻底切断互联网访问，工单会以“整个分支都挂了”的形式进来。两种故障本身都不算错，但只有一种匹配你卖出的服务，而光看 BGP 配置并不能告诉你建的是哪一种。

把私有前缀连同故障情形一起写下来

列出分支必须到达的前缀，并注明哪些被汇总了。多出哪怕一位的聚合会把未知目的地拉进 VPN，只有在远端确实拥有并转发它们时才可以这么做。

然后描述私有服务故障时的预期行为。保留的丢弃路由让流量远离未授权路径，产生干净且符合预期的中断。浮动默认路由可以通过切换到备用路径来保持可用性，但前提是备用路径被授权承载那部分流量。

把可用性与允许的退路作为两项独立要求写进交接文档。把它们合并的团队最后会争论分支该不该中断，而不是检查约定的策略是否已落实。

检查 CE 实际安装了什么

配置意图与转发状态经常不一致，因此验证属于交接，而不属于事故复盘。在 IOS-XE 客户边缘上，下面三条命令回答三个不同的问题：提供了什么、接受了什么、实际在使用什么。

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

在交接当天就把三条都跑一遍，而不是一个月后，趁还有人记得约定了什么。第一条输出取决于 soft-reconfiguration inbound 或保存的路由刷新；两者都没有，CE 就无法展示它拒绝了什么。第二条显示策略之后被接受的路由和最优路由。第三条告诉你默认路由实际去了哪里，而这是整个交接中最有用的一行。

如果站点是双归的，在第二台 CE 上做同样的检查。两个边缘之间的非对称接受是“从一台服务器能通、从另一台不通”的常见原因，而在看起来对称的配置差异里根本看不出来。

评估更大的 feed，而不是假定它

有时客户确实需要 VRF 内部的互联网路径信息，用于策略路由，或者用于按前缀调度的中心出口。这是需要声明、划定范围并计价的需求，而不是隐藏的默认路由。它会带来 RIB 和 FIB 的内存、更新所需的 CPU、过滤器维护，以及结果表的责任人。

容量争论在两个方向上都会出错。VRF 内部并不禁止完整表，它也并非免费。同样，你不能用旧的路径数量推断今天的成本，更小的标签分配也不会消除存储路由的成本。

BGP/MPLS IP VPN 规范在 VPN 服务之外还讨论了几种互联网接入安排，并没有宣布完整表或默认路由对每个客户都是必需的，当有人提出“标准做法”时，值得指出的正是那一节：RFC 4364。

交接的最后，把通告集合、接收集合和选中集合与约定的出口策略记录在一起，并测试一个私有目的地、一个预期公网目的地和一个路由丢失情形。这三项测试的签字记录，比任何关于大多数网络怎么做的说法都能平息更多争论。