按 VRF 打标签还是按前缀打标签？真正的容量账单

两种设计在同一个提供商核心中发布同一个客户前缀。一种为每个前缀分配一个标签，另一种为整个 VRF 分配一个标签，而后者在每张幻灯片上都显得更便宜。标签数量是真实的，但它通常不是最先耗尽的预算。在两者之间做选择意味着要计算四项资源，而不是一项，而标签是其中最小的一项。

选择还取决于出口路由器在弹出标签后必须对数据包做什么。应当由这一功能差异、而不是标签算术来驱动决策。

每种分配实际节省的是什么

按前缀分配把转发信息放在标签里。出口路由器可以把数据包直接送到正确的邻接，而无需查找目的地，这正是它在大规模 VRF 路由集上扩展良好的原因，也是它为每个 VRF 中每个发布的前缀消耗一个标签的原因。按 VRF 分配，例如 Junos vrf-table-label，为每个路由实例发布一个标签，并用该标签选择 VRF 表；随后路由器在表内执行 IP 查找。

这是真正的架构差异，而不是调优旋钮。按 VRF 打标签给出更小的标签空间和更简单的标签发布，代价是一次查找和一个不说明目的地的标签。按前缀打标签为出口线卡预先提供更多信息，并按所承载路由的数量成比例消耗标签。

标签账簿是小的那本

MPLS 标签是有限的，但标签空间足够大，普通服务提供商不会用几千个前缀把它耗尽。按 VRF 打标签真正有帮助的地方，是硬件标签表较小的平台，或者单个 VRF 承载完整互联网路由、按前缀打标签会把标签需求乘以路由数量的设计。这些是真实约束，也正是该功能存在的原因。它们没有一个与表中的前缀数量有关。

在选择之前，既数服务标签，也数传输标签。按 VRF 的设计仍然需要为环回和路径上每一跳准备传输标签，也仍然需要邻接状态。如果设计简报只数服务标签，那么节省是在错误的账簿上衡量的。

路由源在标签之前消耗内存

每条接收到的路径都会消耗控制平面内存、更新处理时间和收敛时间，无论该 VRF 使用一个标签还是一万个。VRF 内的完整互联网路由之所以昂贵，是因为 BGP 路径、RIB、FIB 条目以及它们背后的抖动，而不是因为表前面的那个标签。同一条路由源还会扩大该租户内路由泄漏或策略错误的影响半径。

所以要问客户实际需要什么。如果合同是私有站点加默认出口，完整路由表只会增加成本而不会增加需求。这是一个商业问题，它值得一个书面答复，而不是从上一个设计继承来的假设。如果服务确实因策略或本地出口选择而需要这条路由源，就把它做成明确条目，配有自己的容量预留和自己的故障行为。

何时按 VRF 打标签才是正确的默认值

当平台将其记录为受支持、当 VRF 路由数量很大、当出口查找成本对流量画像可以接受时，它就是好的默认值。当运营简单性比从转发中榨出最后一微秒更重要时，它也是自然的选择，因为每个租户一个标签比每个前缀一个标签更容易解释和审计。

当平台文档把该功能与特定硬件或版本限制绑定，或者当设计依赖出口处按前缀的转发决策时，它就是错误的默认值。在假设行为之前，请阅读平台自己的 statement 参考；Junos 命令有文档记录，但真正决定部署的是它周围的硬件和版本限制。

一份你能辩护的预算

把容量论证建成五个独立的数字：接收路径、选用路由、已安装转发表项、服务标签和传输标签。再加上下一跳和邻接状态、租户数量以及冗余模型。单个 VRF 的顺利路径快照不是规模数字，标称的标签空间大小也不是可用的硬件表。

然后既约定稳态，也约定故障模式。当路由源增长一半、当租户增加第二个 VRF、或者当平台需要重启以调整表大小时，会发生什么？能经受这些问题的预算，比只在纸面上成立的标签数量更有价值。

根据出口动作和平台限制选择分配方式，然后把路由源变成明确的服务决策。标签是设计中可见的部分；路由才是每天都要付费的部分。