摘要

  • D-PATH 是 RFC 10039 定义的 BGP 可选传递属性，属性码为 36，用来记录特定 EVPN/IPVPN 互联场景中声明过的 DOMAIN-ID 序列。
  • 接收方发现自身 DOMAIN-ID 时可识别域级回路；在 Local Preference 之后，较短的 D-PATH 也可参与选路，但该序列不是身份认证或交付凭证。
  • 可审计的运营闭环必须分四段取证：域身份配置、边界属性保存、RIB/FIB 实现、租户上下文中的双向交付。

一条“看起来正确”的路由

值班工程师在域 C 看到一条 VPN 路由。D-PATH 写着 A、B，没有 C，因此没有触发回路拒绝；BGP 会话正常，路由也进入了候选集合。与此同时，租户的应用仍然超时。

这不是标准失灵，而是证据被越权解释。D-PATH 回答的是：这条更新声明自己经过了哪些网关域，以及接收域是否已经出现在这份声明中。租户能否收到报文，需要后续系统给出答案。把前一个答案当成后一个答案，才是故障处理中最危险的捷径。

域身份来自配置，不来自发现

RFC 10039 的每个 D-PATH 段包含服务地址族类型和一串 DOMAIN-ID。网关把路由送往另一个域时，将代表本域的标识加入相应序列。规范要求同一网关域的各个网关使用相同 DOMAIN-ID，不同网关域使用不同值。

然而 DOMAIN-ID 是不透明的管理值。协议不会主动发现“哪些设备属于同一域”，也不会验证两家组织是否碰巧分配了同一值。若同域网关配置成不同标识，真实回路可能逃过检查；若不同域误用相同标识，合法路径可能被当作回路。D-PATH 精确记录的是设备实际写入的值，而不是网络治理者心中那张拓扑图。

因此，第一份权威证据必须来自配置盘点：域边界清单、网关归属、DOMAIN-ID 分配记录，以及变更前后的逐设备比对。路由更新可以验证这些配置产生了什么，却不能单独证明配置本身正确。

“可选传递”也不是不可篡改

D-PATH 的属性码为 36，属性类型为可选传递。这使不理解该属性的 BGP 节点仍有机会继续传递它，是跨多段控制面的实用设计。但“传递”不等于“签名”：策略可以移除或改变属性，软件缺陷可以错误编码，旧实现也可能采取意外处理。

互联模型还会合法地改变观察结果。在 No Propagation 模式中，D-PATH 不被带到对端域；在 Uniform Model 中，它随路由传播并保留更连续的域历史。因此，看到属性缺失不能立即断言边界损坏，看到属性存在也不能断言所有相关属性都完整。调查之前必须先确认该边界采用的模式和策略。

对于格式错误的 D-PATH，规范采用 treat-as-withdraw。这样可以阻止畸形更新继续生效，却也意味着一次编码兼容性故障可能表现为可达性突然消失。升级期间，仅查看“是否支持属性 36”不够，还应监控解析错误、撤回数量和对端实际收到的字节。

最短序列只是一项控制面偏好

RFC 10039 将 D-PATH 长度比较放在 Local Preference 之后。当此前条件相同时，DOMAIN-ID 较少的路径优先；没有 D-PATH 的路径在该比较中长度为零。这条规则让选路可重复，却没有把域数转化为时延、容量、可靠性或安全等级。

本地策略仍然可以通过 Local Preference 选择较长的域序列。反过来，较短 D-PATH 获胜后，下一跳也可能无法解析，标签或 VNI 可能错误，路由目标可能没有正确导入，数据面策略也可能丢弃流量。控制面选择回答“哪条候选路由赢了”，不是“哪个租户请求成功了”。

四段证据链如何落地

第一段是身份配置。对所有参与互联的网关导出 DOMAIN-ID，检查同域一致性和跨域唯一性，并把例外与变更单绑定。

第二段是边界传播。在每个 BGP 边界同时保留入站与出站更新证据，比较 D-PATH 序列、服务地址族类型以及构成 VPN 服务所需的其他属性。这里的目标不是截一张最终路由表，而是证明属性穿越每一道边界时发生了什么。

第三段是 RIB/FIB 实现。确认收到的路线是否被选中、是否安装、下一跳是否解析，以及标签、VNI 和隧道状态是否与该租户对应。RIB 有条目而 FIB 没有，是一种完全不同于域回路的故障。

第四段是服务交付。从租户实际使用的 VRF 或等价隔离上下文发起双向测试，覆盖返回路径和策略。只有这一段能回答最终的交付问题。前面三段让故障定位更快，却不能替它作证。