摘要
- Route Target Constraints 把接收 PE 的导入兴趣变成面向具体邻居的披露状态:RT Membership NLRI 朝持有路由的一侧传播,匹配的 VPN 可达性再沿相反方向返回。
- 完整验收不能止于会话和路由计数,还要证明 AFI 1/SAFI 132 协商、精确成员关系、有限的初始同步、逐邻居 Adj-RIB-Out 差异、独立安全策略,以及 VRF、标签、FIB 和报文结果。
设想一个看似没有故障的开通窗口。工单显示新 VRF 已提交,导入 RT 与源端路由携带的 RT 一致。源 PE 的 VPN 表中有该前缀,沿途 BGP 会话全部 Established,反射器资源也很充足。可接收端查询不到路由。
问题并不在那条 VPN 路由上。接收 PE 尚未把自己的 RT 兴趣作为成员 NLRI 送到反射器,或者这份兴趣没有进入该邻居的有效计算。反射器因此仍认为接收端“不需要”,把本来有效的路由挡在 Adj-RIB-Out 之外。
这正是 RFC 4684 引入的控制面。若采用密集分发,RR 可以把大量 VPN 路由发给所有 PE,再由各 PE 丢弃没有 VRF 导入的部分。RTC 或 RT-Constrain 改为让接收者先公布兴趣,分发者据此生成逐邻居过滤器,只返回匹配的 VPN NLRI。
成员稀疏时,这种方法能显著减少状态、处理和更新流量。代价是运维证据从单向链条变成双向图:源路由存在,并不等于某个接收者在当前图中应当看到它。
Route Target 只决定候选资格
RFC 4364 中,Route Distinguisher 与 Route Target 承担不同职责。RD 让可能重叠的 VPN 前缀在 BGP 中保持唯一;RT 是扩展团体,用于表达导出和导入策略。
路由携带的任一 RT 与 VRF 的导入集合匹配时,该路由获得进入这个 VRF 的候选资格。它并未因此自动安装。BGP 选路、PE/CE 过程、本地策略、下一跳与标签递归、VRF RIB 和转发表编程仍可能阻止最终结果。
RTC 也没有把“兴趣”升级为客户身份。它只把导入需求向上游暴露,使对端避免披露无关 NLRI。一个成员通告既不创建 VRF,也不验证源路由,更不能证明报文已经可达。
因此,“缺路由”至少有多种边界:源端没有起源;RR 没有学到;RTC 兴趣没有起源或被策略挡住;反射器丢失了某个成员路径;派生过滤器没有刷新;接收端得到路由却未导入、未选中或未解析标签;FIB 已写入但数据面仍在别处失败。
排障应找到第一个缺失预期状态的边界,而不是围着一个总路由数反复猜测。
兴趣与可达性沿相反方向移动
RFC 4684 的关键不是一个新命令,而是一张反向图。接收者把兴趣通告给靠近 VPN 路由源头的系统;匹配的 VPN 路由再沿图的反方向返回。成员 NLRI 本身也是 BGP 可达性对象,会经历策略、选路和路由反射,并不是发给远端的强制请求。
RTC 使用 RFC 4760 的 MP_REACH_NLRI 与 MP_UNREACH_NLRI,地址族为 AFI 1、SAFI 132。除默认成员路由外,其键包含四字节起源 AS 和八字节 Route Target,以 32 至 96 位前缀表示。较短前缀可以覆盖更广的兴趣,也同时扩大状态和披露范围。
长度为零的前缀表示默认 RT 成员关系,即愿意接收该邻居关系上所有相关 VPN 路由。它不是 IP 默认路由,不是默认 VRF,不代表一个“所有客户”,也不是要求设备把每条路由都装进转发表。
某些 RR 的角色确实需要密集接收,RTC 与传统邻居并存时也可能保留兼容路径。但默认成员关系必须作为明确例外管理,因为它会削弱选择性、增大收敛开销,并扩大可见信息的边界。
能力协商只证明通道存在
双方在 BGP OPEN 中协商 AFI 1/SAFI 132,说明这条会话可以交换 RTC。它不证明某个 RT 成员前缀已经产生、收到、选中,更不证明对端为 VPN 地址族建立了正确过滤器。
同样,配置里出现 rtfilter 或 family route-target 只能说明意图。最低证据集要包含双方能力视图、原始或无损的成员 UPDATE、RTC RIB、被选与未选的相关路径、策略结果,以及实际作用于 VPN Adj-RIB-Out 的逐邻居过滤状态。
Cisco 的 Route Target Constraint 说明 展示了特定产品如何从 VRF 导入列表生成 rtfilter 更新,并让 RR 构造接收过滤器。Juniper 的 family route-target 文档 也描述了 PE 上报兴趣、RR 选择性返回路由的方向。
这些是一手实现资料,但不能外推到所有设备。软件版本、邻居模板继承和运行状态都要单独留存。Cisco 的 bgp default route-target filter 与 Juniper Route Target Filtering 记录的是各自产品的控制面;本地过滤配置不等于已经与对端交换 RFC 4684 成员关系。
成员需求不能被一个普通最佳路径代表
路由反射使 RTC 出现一个不同于普通可达性的要求。多个同 AS 的 PE 可能为同一个 {起源 AS, Route Target} 产生成员 NLRI。若 RR 只保留和使用一条普通 iBGP 最佳路径,就可能把其他感兴趣的客户端方向一起抹掉。
RFC 4684 因此要求在构造出站过滤器时考虑该 RT 前缀的所有可用 iBGP 路径,并调整本地产生成员信息的反射行为。这建立在 RFC 4456 的反射拓扑之上,但拓扑存在并不能证明 RTC 的特殊路径处理正确。
这也不是把 ADD-PATH 套到 VPN 路由上。RTC 关心的是保留每一个“需求来自哪里”的方向,而不是向一个接收者交付多条可达性备选。
因此,截图显示“表里有这个 RT”仍然不够。要逐邻居回答:哪些 PE 起源了兴趣,RR 保存了哪些成员路径,哪个过滤器被安装,匹配的 VPN 路由何时进入该邻居的 Adj-RIB-Out。
开通和退出都是图的变更
收到成员通告或撤回后,RFC 4684 要求发送者重新评估 VPN RIB-OUT,以最少的通告和撤回来完成新旧图转换。VRF 配置提交只是开通的起点;从配置中删除 RT 也不是退出完成的证据。
开通链条应依次证明:导入意图获批;成员 NLRI 起源;相关 RR 收到并保留必要路径;面向 PE 的过滤器扩展;匹配路由出现在 VPN Adj-RIB-Out;PE 收到并导入;下一跳和标签解析;FIB 写入;正向与反向测试通过。
退出时,只有在本地没有其他 VRF 仍需该 RT 后才能撤回成员关系。RR 应收缩路由集合,只撤掉不再由任何活动 RT 匹配的条目。单条路由可携带多个 RT,一个 VRF 也可导入多个 RT,所以总数不变并不能证明集合正确。
应比较准确的路由身份与属性,并为迁移保留旧图清空的证据。否则所谓“可逆”只发生在配置文件里,没有发生在分布式系统中。
EoR 给等待设置终点
初始交换时,RR 可能等待成员集合到齐后再释放 VPN 路由。RFC 4684 建议即使没有启用 Graceful Restart,也为 RTC 家族发送 End-of-RIB。EoR 是一次同步提示,帮助判断初始成员集是否已经结束。
等待不能无限。RFC 规定延迟 VPN 通告时必须设置上限,并给出 60 秒默认值。这不是统一服务指标,而是一条设计边界:优化机制不能因为等不到 EoR 而永久制造控制面中断。运维记录应包含实际定时器、EoR 时间以及超时后的产品行为。
RTC 与 Route Refresh 也不能混为一谈。RTC UPDATE 改变当前兴趣;Route Refresh 要求重新通告当前导出状态。RFC 5291 的 ORF 是随 ROUTE-REFRESH 传送的类型化过滤项。RFC 7543 描述后来的 Covering Prefix ORF 如何在缺少 VPN 路由时触发 RTC 兴趣,但普通 RTC 并不依赖它。
选择性披露不等于安全许可
RFC 4684 的安全章节明确说明:由 RT 成员 NLRI 构建的出站过滤器不用于安全。跨管理域时,应另设入站和出站 NLRI 过滤,并对对端可发布的成员信息本身进行限制。
成员 NLRI 是邻居给出的 BGP 声明。它不认证客户,不证明合同,不授权对方随意命名 RT,不验证 VPN 路由,也不直接限制数据面。如果接收者能任意扩大兴趣,而发送者把兴趣当许可,就会扩大不应披露的信息。
安全面必须独立包含:获批 RT 命名空间、邻居角色授权、成员入站策略、VPN NLRI 出站策略、边界处 RT 转换、状态上限、日志和回滚。RTC 可以在这些约束下节省资源,但不能替代约束。
从 VRF 意图走到报文结果
RFC 4271 的 Adj-RIB-In、Loc-RIB、Adj-RIB-Out 分层能避免用一张表代替整个决策过程。RTC 需要沿两个方向、跨两个地址族完整走一遍。
从接收 PE 保存获批的 VRF 导入 RT 和生效时间,验证 RTC 能力、成员 UPDATE、策略变换和全部相关 iBGP 成员路径。在 RR 上保存成员 RIB 与逐邻居派生过滤器。再换到 VPN 方向,对比源端、RR Loc-RIB、目标 Adj-RIB-Out 和接收 PE 的 VPN RIB。
最后验证 VRF 导入、选路、标签和下一跳、FIB 以及双向报文。正向 canary 证明应有路由可用,负向 canary 证明无权兴趣不会得到不该披露的路由。撤回、RR 迁移和软件升级都要重复这条链,不能只看变化后的总数。
来源
- RFC 4684 — Constrained Route Distribution for BGP/MPLS IP VPNs
- RFC 4364 — BGP/MPLS IP VPNs
- RFC 4760 — Multiprotocol Extensions for BGP-4
- RFC 4271 — A Border Gateway Protocol 4
- RFC 4456 — BGP Route Reflection
- RFC 5291 — Outbound Route Filtering Capability for BGP-4
- RFC 7543 — Covering Prefixes Outbound Route Filter for BGP-4
- Cisco — Route Target Constraint
- Cisco IOS MPLS command reference — bgp default route-target filter
- Juniper — family route-target
- Juniper — Route Target Filtering
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance