RFC 4379 - 检测 MPLS 数据平面故障 (Detecting MPLS Data Plane Failures)
Network Working Group K. Kompella Request for Comments: 4379 Juniper Networks, Inc. Updates: 1122 G. Swallow Category: Standards Track Cisco Systems, Inc. February 2006
本备忘录状态 (Status of This Memo)
本文档为互联网社区规定了一项互联网标准跟踪协议, 并请求讨论与改进建议. 请参阅 "Internet Official Protocol Standards" (STD 1) 的当前版本. 本备忘录的分发不受限制.
版权声明
Copyright (C) The Internet Society (2006).
摘要 (Abstract)
本文档描述一种简单高效的机制, 用于检测多协议标签交换 (MPLS) 标签交换路径 (Label Switched Path, LSP) 中的数据平面故障. 文档分两部分: (1) MPLS "echo request" 与 "echo reply" 中为故障检测与隔离携带的信息; (2) 可靠发送 echo reply 的机制.
目录
- 引言
- 动机
- 分组格式
- 操作理论
- 参考文献
- 安全考虑
- IANA 考虑
- 致谢
1. 引言 (Introduction)
本文档描述用于检测 MPLS LSP 数据平面故障的简单高效机制. 包括 echo request/reply 中携带的信息, 以及传输 echo reply 的机制. 第一部分旨在提供足够信息以检查数据平面正确运行, 并提供对照控制平面验证数据平面、从而定位故障的机制. 第二部分建议两种更稳健的可靠回复通道.
设计的重要考虑是: MPLS echo request 沿与正常 MPLS 分组相同的数据路径转发. Echo request 主要用于验证数据平面, 次要用于对照控制平面验证数据平面. 检查控制平面的机制有价值, 但不在本文档覆盖范围.
本文档特殊使用地址范围 127/8. 这是对 RFC 1122 [RFC1122] 行为的例外, 并更新该 RFC. 动机与细节见第 2.1 节.
1.1 约定 (Conventions)
关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 与 "OPTIONAL" 见 RFC 2119.
术语 "Must Be Zero" (MBZ) 用于保留字段: 发送时 MUST 置零, 接收时忽略.
L2/L3 VPN 术语见 [RFC4026]. 本文档中未限定的 "TTL" 指 MPLS TTL; IP 首部中的 TTL 称为 "IP TTL".
1.2 文档结构
主体四部分: 动机、MPLS echo request/reply 分组格式、LSP ping 操作、可靠返回路径. 首次阅读者建议先跳过分组格式、先读操作理论.
1.3 贡献者
Ronald P. Bonica, Dave Cooper, Ping Pan, Nischal Sheth, Sanjay Wadhwa 等对文档各方面作出重要贡献.
2. 动机 (Motivation)
当 LSP 未能投递用户流量时, 故障未必能被 MPLS 控制平面检测到. 需要工具在合理时间内检测此类流量 "黑洞" 或误路由, 并隔离故障.
机制仿照 ping/traceroute 范式: ping (ICMP echo) 用于连通性检查, traceroute 用于逐跳故障定位与路径跟踪. 本文档为测试 MPLS LSP 规定 ping 模式 与 traceroute 模式.
基本思想: 验证属于特定转发等价类 (FEC) 的分组, 其 MPLS 路径确实终结于该 FEC 的出口 LSR. 方法是沿与该 FEC 其他分组相同的数据路径发送 "MPLS echo request", 并携带被验证 FEC 的信息.
- Ping 模式 (基本连通性): 分组应到达路径末端, 交给出口 LSR 控制平面, 验证其确为该 FEC 的出口.
- Traceroute 模式 (故障隔离): 分组交给各中转 LSR 控制平面, 执行多种检查确认其为路径中转; 并返回有助于对照控制平面检查数据平面的信息.
用法示例: 周期性 ping FEC 确保连通; ping 失败后 traceroute 定位故障. 也可周期性 traceroute 验证转发与控制平面一致, 但会加重中转 LSR 负担, 应谨慎使用.
2.1 使用地址范围 127/8
LSP ping 是诊断工具, 需在控制平面与数据平面不同步时工作. 它仅根据标签栈路由 MPLS echo request, 从不在转发决策中使用 IP 目的地址. 发送方甚至可能事先不知道 LSP 末端路由器地址.
还需能跟踪 LSP 可能走的所有路径 (含 ECMP 负载分担). 因此要求:
- 即使 LSP 以未知方式损坏, 诊断分组被投递给 MPLS 服务用户的可能性 MUST 保持绝对最低.
- 若 LSP 过早终结, 诊断分组 MUST NOT 被 IP 转发.
- REQUIRED 能变化诊断分组以锻炼所有 ECMP 路径.
通用单播地址不满足前两条. 私有地址空间对 IPv4 VPN 无效 (VPN 常用私有地址). IPv4 链路本地范围有限且部署路由器可能仍会向默认路由转发.
选择 127/8 (以及嵌入为 IPv4-mapped IPv6 的同一范围) 的原因:
- RFC 1122 将 127/8 分配为 "Internal host loopback", 规定此类地址 MUST NOT 出现在主机外; 主机默认丢弃, 有助于误投到主机时静默丢弃.
- RFC 1812: 路由器 SHOULD NOT 转发目的为网络 127 的分组 (除非经环回接口); 若有禁用检查的开关, MUST 默认执行检查. 有助于确保诊断分组永不被 IP 转发.
- 127/8 提供约 1600 万地址, 便于变化地址以锻炼 ECMP.
- 实现上易于识别可能的 LSP 诊断分组.
3. 分组格式 (Packet Format)
MPLS echo request 是 (可能带标签的) IPv4 或 IPv6 UDP 分组; UDP 内容格式:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Version Number: 当前为 1. 影响解析/处理能力的变更时递增.
- Global Flags: 位向量; 定义 V (Validate FEC Stack) 位: 为 1 时发送方要求接收方执行 FEC Stack 验证; 为 0 时由接收方选择. 其余 MUST 发送置零、接收忽略.
- Message Type: 1 = MPLS echo request; 2 = MPLS echo reply.
- Reply Mode:
- 1 = Do not reply (单向连通性测试)
- 2 = Reply via IPv4/IPv6 UDP packet (正常)
- 3 = Reply via IPv4/IPv6 UDP packet with Router Alert (返回路径不可靠时)
- 4 = Reply via application level control channel (如 VCCV)
- Sender's Handle: 发送方填充, 回复中原样返回, 无语义, 用于匹配请求/回复.
- Sequence Number: 检测丢失回复等.
- TimeStamp Sent / Received: NTP 格式的秒与微秒.
TLV 格式: Type | Length | Value (Value 零填充至 4 八位组边界; 可嵌套 sub-TLV).
顶级 TLV 类型:
| Type | Value Field |
|---|---|
| 1 | Target FEC Stack |
| 2 | Downstream Mapping |
| 3 | Pad |
| 5 | Vendor Enterprise Number |
| 7 | Interface and Label Stack |
| 9 | Errored TLVs |
| 10 | Reply TOS Byte |
Type < 32768 为强制 TLV: 不支持则 echo 响应中 Return Code = 2. Type ≥ 32768 为可选: 不理解时 SHOULD 忽略.
3.1 返回码 (Return Codes)
发送方将 Return Code 置 0. 接收方可设置 (RSC = Return Subcode, 对指定栈深度的码填入 stack-depth, 否则 MUST 为 0):
| Value | Meaning |
|---|---|
| 0 | No return code |
| 1 | Malformed echo request received |
| 2 | One or more of the TLVs was not understood |
| 3 | Replying router is an egress for the FEC at stack-depth <RSC> |
| 4 | Replying router has no mapping for the FEC at stack-depth <RSC> |
| 5 | Downstream Mapping Mismatch |
| 6 | Upstream Interface Index Unknown |
| 8 | Label switched at stack-depth <RSC> |
| 9 | Label switched but no MPLS forwarding at stack-depth <RSC> |
| 10 | Mapping for this FEC is not the given label at stack-depth <RSC> |
| 11 | No label entry at stack-depth <RSC> |
| 12 | Protocol not associated with interface at FEC stack-depth <RSC> |
| 13 | Premature termination of ping due to label stack shrinking to a single label |
3.2 Target FEC Stack
Target FEC Stack TLV (Type 1) 包含一个或多个 sub-TLV, 描述标签栈自顶向下对应的 FEC. 用于验证数据平面与控制平面一致.
主要 sub-TLV 类型:
| Sub-Type | FEC |
|---|---|
| 1 | LDP IPv4 Prefix |
| 2 | LDP IPv6 Prefix |
| 3 | RSVP IPv4 LSP |
| 4 | RSVP IPv6 LSP |
| 6 | VPN IPv4 Prefix |
| 7 | VPN IPv6 Prefix |
| 8 | L2 VPN Endpoint |
| 9 | FEC 128 Pseudowire (Deprecated) |
| 10 | FEC 128 Pseudowire (Current) |
| 11 | FEC 129 Pseudowire |
| 12 | BGP Labeled IPv4 Prefix |
| 13 | BGP Labeled IPv6 Prefix |
| 14 | Generic IPv4 Prefix |
| 15 | Generic IPv6 Prefix |
| 16 | Nil FEC |
3.2.1–3.2.2 LDP IPv4 / IPv6 Prefix
携带前缀与前缀长度, 对应 LDP 绑定的 IPv4/IPv6 FEC.
3.2.3–3.2.4 RSVP IPv4 / IPv6 LSP
标识 RSVP-TE LSP (含隧道端点、扩展隧道 ID、发送方等信息), 用于 TE 隧道诊断.
3.2.5–3.2.6 VPN IPv4 / IPv6 Prefix
含 Route Distinguisher (RD) 与 VPN 前缀, 用于 L3VPN 数据平面验证. 第 4.7 节讨论相关问题.
3.2.7–3.2.10 L2 VPN 与伪线 FEC
L2 VPN Endpoint、FEC 128 (旧/新)、FEC 129 伪线 sub-TLV, 支持 PW 连通性验证 (常与 VCCV 结合).
3.2.11–3.2.15 BGP 标签前缀、通用前缀、Nil FEC
BGP LU、无协议特定前缀、以及 Nil FEC (表示栈中该层无特定 FEC, 仍可验证标签操作).
3.3 Downstream Mapping
Downstream Mapping TLV (Type 2) 在 traceroute 中由中转节点返回, 描述下游邻居、出接口、下游标签栈、多路径 (ECMP) 信息等, 使发起方能:
- 验证控制平面与数据平面下一跳一致;
- 通过变化地址/熵字段锻炼所有 ECMP 分支.
3.3.1 多路径信息编码
编码如何通过改变 IP 目的地址 (在 127/8 内) 或其他字段选择不同 ECMP 路径.
3.3.2 下游路由器与接口
标识下游 LSR 与接口, 供下一跳 traceroute 使用.
3.4–3.8 其他 TLV
- Pad TLV: 填充以控制分组大小.
- Vendor Enterprise Number: 厂商扩展.
- Interface and Label Stack: 报告接收接口与标签栈.
- Errored TLVs: 返回未理解或错误的 TLV 副本.
- Reply TOS Byte: 指定回复 IP TOS.
4. 操作理论 (Theory of Operation)
4.1 处理 ECMP
LSP 可能经 ECMP 分叉. Traceroute 使用 Downstream Mapping 的 multipath 信息, 系统性地变化 127/8 目的地址 (或其他键), 覆盖所有分支.
4.2 测试承载 MPLS 载荷的 LSP
当 LSP 承载的是 MPLS (而非 IP) 时, 仍使用相同 echo 机制; Nil FEC 与标签栈验证帮助处理纯标签转发场景.
4.3 发送 MPLS Echo Request
- 构造 UDP 载荷 (Version、Flags、Message Type=1、Reply Mode、Handle、Seq、时间戳、TLV).
- 封装为 IP (目的通常在 127/8), 源为发送方地址.
- 施加与被测 FEC 相同的 标签栈 (及合适的 MPLS TTL).
- Ping: TTL 足够大以到达出口.
- Traceroute: 从 TTL=1 递增, 迫使沿途节点上送控制平面.
4.4 接收 MPLS Echo Request
接收 LSR 的高层步骤:
- 通用健全性: 格式错误 → Return Code 1.
- 记录入接口等上下文.
- 标签验证: 按栈深度检查入标签是否有映射、是否交换、是否出口.
- 标签操作检查: 对照 Target FEC Stack 验证控制平面绑定.
- 出口处理 / FEC 验证: 若为出口, 确认是所述 FEC 的出口 (V 标志时更严格).
- 发送 Reply: 按 Reply Mode 构造 echo reply (Message Type=2), 填 Return Code/Subcode、时间戳、可选 Downstream Mapping 等.
4.4.1 FEC 验证
对 Target FEC Stack 中每个 FEC, 检查标签映射、隐式空、关联协议等, 设置相应返回码.
4.5 发送 MPLS Echo Reply
根据 Reply Mode:
- Mode 2: 普通 IP/UDP 发回发起方.
- Mode 3: 带 Router Alert, 便于不可靠返回路径.
- Mode 4: 应用控制通道 (如 VCCV).
回复使用与请求相同的 IP 版本.
4.6 接收 MPLS Echo Reply
发起方用 Sender's Handle 与 Sequence Number 匹配, 解析 Return Code 与 TLV, 报告连通性或逐跳信息.
4.7 VPN IPv4/IPv6 前缀问题
PE 上 VPN 上下文依赖 VRF; 验证需正确 RD/前缀, 且注意多租户隔离与控制平面查找范围.
4.8 不合规路由器
不支持 LSP ping 的路由器可能静默丢弃或错误 IP 转发. 127/8 与 Router Alert 回复模式有助于降低风险, 但不能消除所有旧设备问题.
5. 参考文献
5.1 规范性
- [KEYWORDS] RFC 2119
- [RFC1122], [RFC1812], [NTP], 及相关 MPLS/LDP/RSVP/VPN 规范
5.2 资料性
- [ICMP], [VCCV], [RFC4026] 等
完整列表见英文源 docs/rfc-4379/index.md.
6. 安全考虑 (Security Considerations)
LSP ping 可被滥用于:
- 侦察 MPLS 拓扑与 FEC;
- 以 traceroute 加重中转控制平面负载 (DoS);
- 若过滤不当, 诊断分组泄漏到用户网络 (127/8 缓解但非万能).
实现 SHOULD 提供访问控制 (谁可发起/响应)、速率限制、以及仅在管理平面启用. 过滤异常源、限制 Reply Mode 3 的处理范围. 详见规范安全章节.
7. IANA 考虑 (IANA Considerations)
IANA 管理:
- Message Types、Reply Modes、Return Codes 注册表
- TLV 与 sub-TLV 类型注册表
新赋值需按文档规定的注册策略.
8. 致谢 (Acknowledgements)
感谢贡献者与 MPLS 工作组成员的讨论与审阅.
运维速查
| 模式 | MPLS TTL | 目的 |
|---|---|---|
| Ping | 大 | 端到端连通 + 出口 FEC 验证 |
| Traceroute | 1,2,3,… | 逐跳验证 + Downstream Mapping |
| 组件 | 作用 |
|---|---|
| 标签栈 | 强制走数据平面 LSP |
| 127/8 目的 | 防止 IP 转发与用户投递 |
| Target FEC Stack | 控制平面对照 |
| Downstream Mapping | ECMP 与下一跳诊断 |
相关资源
- 官方文本: https://www.rfc-editor.org/rfc/rfc4379.txt
- DataTracker: https://datatracker.ietf.org/doc/html/rfc4379
- 英文源:
docs/rfc-4379/index.md - 后续更新: 若干 RFC 更新了 TLV/返回码 (实现时请查 errata 与更新链)
说明: 英文源约 110KB. 本中文版按章节完整翻译动机、分组格式、全部主要 TLV/FEC 类型、操作理论与安全要点. 完整接收状态机逐步伪代码与全部 sub-TLV 位域请对照英文源第 3–4 节实现.