摘要

  • LOCAL_PREF 表达接收方自治系统的内部偏好，不是邻居提供的质量认证。数值可以改变同一前缀的候选路径排序，却不能取代安全检查、下一跳可达性或最长前缀匹配。
  • 风险大小取决于策略实际匹配的路由范围，而非改动了几行配置。验证必须跨越入口策略、内部传播、最佳路径、硬件转发和真实流量；撤回配置也要证明服务恢复。
  • 客户通过 community 请求某种待遇，不等于取得运营商的路由决策权。运营商仍需限定请求来源、适用范围、冲突顺序和有效期。

两条路，一项没有向外通告的决定

设想一个纯粹用于说明机制的网络：边界 A 和边界 B 都收到通向同一目的前缀的可用路由，下一跳可解析，两条路都通过了入口检查。A 的 AS_PATH 较短，B 的较长。如果采用 Cisco 所述的比较流程，再明确假设两条路径的 weight 相同，本地策略给 A 赋予 100、给 B 赋予 200，B 就能在比较 AS_PATH 之前胜出。这不是某次事故的复盘，也不是设备实测输出，而是用来分离政策优先级与路径长度的假设。

这里的前提不能省略。Cisco 的最佳路径说明把 weight 放在 LOCAL_PREF 之前；高偏好不能让一条已被拒绝的路径重新取得资格。其他实现也有自己的选择流程。由这个例子可以推出的，是本地偏好能够改变出口，不能推出全网每台路由器必然选同一出口，更不能推出 200 代表两倍性能、两倍可靠性或两倍商业价值。

变化发生在自治系统内部。RFC 4271 第 5 节规定了这个四字节无符号属性的内部传播和较高值优先的语义；普通 EBGP 不向外携带它，联邦另有例外。外部观察者可能看到流量变化，却看不到作出这项选择的内部数值。因而，把公网路由采集器没有异常当作“出口策略没有变化”的证据，并不成立。

另一个边界在目的地址上。例子比较的是同一前缀的两条路径。若转发表同时存在更具体的路由，覆盖它的聚合前缀即便拥有更高 LOCAL_PREF，也不会因此压过最长前缀匹配。这种混淆很容易让排障走错方向：工程师不断调高聚合路由的偏好，实际流量却始终命中另一条更具体的转发表项。

数字没有价格，策略才有

偏好之所以有商业意义，是因为网络自己给它赋予含义。运营商可能希望优先使用某类互联、避开受限容量，或者保留一条昂贵但有独立故障域的后备路径。协议并不知道合同、容量价格和风险预算；它只执行被编码的排序。把数字称为“质量分”会掩盖这层责任：它可能忠实执行一项已经过时的采购决定。

100 尤其容易制造虚假的自然秩序。RFC 4277 第 8 节记录它是常见默认值，并不是协议统一规定的默认值。Juniper 的 LOCAL_PREF 文档进一步说明 Junos 的具体默认及导出行为。混合设备网络不能只核对显示出来的数字，还要核对这个数字在哪个阶段出现、是否经过显式策略，以及相同配置意图是否在不同实现上得到相同待遇。

因此，策略表最好先写“为什么”，再写“多少”。一个待遇等级应有可识别的负责人、允许使用的入口、匹配条件和例外。把采购优惠、客户请求、故障绕行全部塞进同一个高值，短期减少了配置项，长期却使问责失去抓手。故障时看到 200，值班人员不知道它是合同承诺还是临时维护遗留，就无法判断该恢复什么。

数值也不能替代起源验证。RFC 6483 第 3 节讨论如何把路由起源验证结果用于本地选择。这里有两项不同判断：是否允许某条路进入候选集合，以及允许后如何排序。经营者应分别留存证据。若把安全理由和商业偏好都压成一个数值，后来覆盖该数值的规则可能无声地改变原有安全意图；最高偏好的路由仍不意味着来源经过认证。

商业验收也需要自己的时间尺度。短时间内出口流量增加，只能支持流量确实转移的判断，不能直接证明账单会下降。计费安排、峰值需求与备用容量的费用可能使技术结果和财务结果分离。这是对运营决策的分析，而非协议承诺。负责批准的人应预先说明：这次调整究竟要证明路径可控、性能改善，还是长期成本降低，避免把最容易测到的一项替代真正的目标。

还应防止反馈过快。若人工或自动控制在短暂拥塞时提高另一路的偏好，又在下一次采样时立刻反向调整，经营者需要评估反复变化是否使观察失去稳定基线。不能仅凭每次赋值都获得批准，就认定连续决策的组合也合理。试行方案应把观察窗口、停止条件和重新开始的责任人一起写清楚。

外部请求怎样变成内部命令

客户并非完全无法影响这一过程。RFC 1998说明，客户可以附带双方约定的 community，由提供方映射成其内部 LOCAL_PREF。关键动作在映射处：对方发送的是请求标签，提供方运行的策略决定是否接受、如何解释。旧文中的实例证明这种安排的机制，不代表今天所有网络都采用同一组数值或商业等级。

这使 community 映射成为一处容易被低估的授权边界。标签本身不是身份凭证，知道一个值也不等于有权使用它。接受方需要验证请求从哪条会话进入、涉及哪些前缀、允许影响哪个地域，以及与其他规则冲突时谁优先。否则，一项本为客户自助维护提供的便利，可能悄悄变成绕过流量采购安排的入口。

RFC 8195 的 Large Community 用例展示了偏好函数与地域限定等表达方式。更大的命名空间有助于区分动作，却不会自动带来更严格的授权。一个标签写得很完整，并不能证明接收策略的匹配范围正确。特别是从旧 community 迁移时，保留新旧两套映射可能产生重复或互相覆盖的动作，数字正确而授权已经扩张。

维护场景则提供了反向例子。RFC 8326 第 4、6 节用 GRACEFUL_SHUTDOWN 表达撤离某条路径的意图，并建议把偏好降至低值，推荐值为 0。但降到 0 不是撤销路由：没有其他合格路径时，它仍可能被选中。维护前必须确认替代路径可见、能承载流量，并观察收敛。不能用“已经降权”代替“可以断开”。

这些机制的职责应当分开看。MED 是邻居关于进入其网络的建议；LOCAL_PREF 是接收方内部的排序决定。AIGP 表达受限管理范围内累积的度量，不是本地商业等级的别名。Large Community 提供信息或请求的表达空间；Route Refresh 帮助重新取得、重评路由，并不决定重评后的政策。把这些工具都称为“调流量”，会抹去谁有权做决定这一核心差别。

一致性不是把所有数值刷成一样

内部传播使一次入口赋值有机会影响远处的路由器，也放大了误匹配的代价。不过，治理目标并不是机械统一。RFC 4272 的 LOCAL_PREF 分析明确指出，协议没有要求自治系统内部所有发言者的偏好值必须一致。经过设计的地域策略可以存在。真正要证明的是，各节点的选择与实际转发结构相容，而不是表格里每行都出现同一个数字。

与此同时，RFC 4271 第 9.1.1 节提醒，对内部学习到的路由重新计算偏好可能形成持续环路。两句话并不矛盾：自由并不是没有后果。若两个区域分别偏爱对方出口，而数据包的下一跳又把它们送回彼此，局部排序各自合理，整体转发仍可能失败。具体是否发生环路取决于拓扑与转发方式，不能只凭“数值不同”作事故结论。

路由反射器增加了证据上的难度。某客户端没有选另一出口，原因可能不是它不接受该偏好，而是它根本没有看到那条候选路径。因此，观察应该覆盖入口、反射传播路径和具有不同可见性的客户端。相同偏好也不能保证相同最佳路径：候选集合、后续比较项、下一跳解析和多路径配置仍可能不同。简单的全网数值对比适合发现漂移，不足以证明出口行为一致。

协议格式错误与政策错误同样不能混为一谈。RFC 7606 第 7.5 节区分普通外部接收时的属性丢弃，以及内部接收时长度不是四字节所触发的视同撤销处理。一个格式正确、却误设得很高的 LOCAL_PREF 不会因为违背商业意图而自动成为坏报文。运营控制必须捕捉语义错误，不能等协议错误计数器替它报警。

必须证明的是出口，而非配置提交

验收应沿着一条可以复查的链展开。先记录谁批准了哪项政策，以及预期影响哪些前缀、会话和地址族；再确认入口匹配实际命中什么，保留 Adj-RIB-In 接收路由与赋值后的对应关系。随后检查内部通告或遥测，在多个观察点比较候选路径与 Loc-RIB 的选择。最后核对下一跳解析、FIB 安装、多路径状态和从不同入口发出的数据包。

Juniper 的 BGP 选择说明把路由可用性、选择和转发表联系起来，也说明平台的路由 preference 与 BGP LOCAL_PREF 不应混称。实践中，控制面看到一条最佳路径，不代表硬件已经装入同一结果；出口计数增加，也不代表所有目标都经过该出口。需要把时间、前缀、入口位置和观察层次对齐，才有因果证据。

这里提出的是一种验证方法，不是对某个真实网络的测量结论。没有设备状态、配置历史和流量数据，就不能断言某家运营商存在误设或隐性绕路。能成立的分析是：属性的外部不可见性提高了内部证据的重要性，而广泛匹配会把一项小改动变成大量目的地的共同选择。变更的实际半径是匹配集合，不是命令长度。

一个稳妥的试行应同时保留反证。选取有限的前缀、明确的入口和单独的地址族，记录变更前后的状态，再保留未命中策略的对照路由。若只有预期对象改变，解释才更可信；若对照组也改道，应先查共享规则或同期事件。回滚之后则重走同样的链，证明旧路径重新取得相应待遇、转发恢复，而不是仅仅证明旧文本回到了配置文件。

证据保存也应覆盖没有改变的部分。一次有边界的调整，不应把其他出口的稳定当作默认事实。对照节点、未命中的路由和原有备用能力都需要留下记录，才能回答后来的问题：结果究竟来自这项策略，还是来自同时发生的故障与需求变化。这个区分决定了试验结论能否被下一次变更复用。