ESNP LAB 笔记：配置静态BFD检测MPLS LDP LSP

一、BFD 简介

1.1 定义

BFD（Bidirectional Forwarding Detection，双向转发检测）是一种通用、标准化、介质无关且协议无关的快速故障检测机制。与路由协议不同，BFD 本身并不负责邻居发现，也不参与业务流量的重路由，它的唯一作用是 快速检测转发通道是否正常。

它通过在设备之间建立轻量级的会话，并以极短的周期交换检测报文，实时监测 IP 网络中链路或转发路径的连通性。一旦在协商的检测时间内未收到对端报文，BFD 会立即判定通道故障，并将状态通知给上层应用（如 OSPF、BGP、MPLS 等），从而触发业务的快速收敛与切换，保障网络和业务的高可用性与连续性。

1.2 产生背景与目的

为降低链路或节点故障对业务的影响，网络设备需要快速检测邻居通信状态。然而：

• 硬件告警（如 SDH）虽能快速检测，但并非所有介质都支持；

• 路由协议的 Hello 报文检测速度较慢（通常大于 1 秒），高速环境下可能丢失大量数据；

• Hello 机制无法覆盖所有场景（如静态路由、隧道）。

BFD 正是为解决以上问题而产生，能够跨介质、跨协议统一提供快速故障检测。

1.3 功能

• 对相邻设备的转发通道进行轻量、快速的连通性检测（接口、链路、隧道甚至设备故障）。

• 提供通用检测机制，可独立于具体的三层协议运行。

• 检测结果实时通告上层路由/转发协议，实现快速收敛。

1.4 受益

• 毫秒级故障检测（典型 3×100ms = 300ms），显著提升业务连续性。

• 覆盖物理链路、逻辑链路、隧道等多种场景。

• 可与 OSPF、BGP、MPLS LSP、静态路由等配合，提高网络可靠性。

二、BFD原理描述

2.1 BFD基本原理

• BFD 在两台网络设备之间建立会话，用于检测双向转发路径的连通性，为上层应用（如路由协议、MPLS、静态路由等）提供快速故障感知能力。

• BFD 本身不具备邻居发现功能，而是依赖上层应用告知对端邻居信息来建立会话。

• 会话建立后，双方周期性发送 BFD 控制报文。若在约定的检测时间内未收到对端报文，则判定该转发路径故障，并立即通知上层应用触发收敛或切换。

• BFD 可以看作是操作系统为上层应用提供的一种“快速故障检测服务”。

  • 上层应用（如 OSPF、IS-IS、BGP、静态路由、MPLS LSP）向 BFD 注册需求，指定检测的目标地址、检测周期等参数；

  • BFD 模块根据这些参数创建、维护或删除会话，并周期性交互检测报文；

  • 检测结果实时通告给上层应用，使其能够在故障发生时立即采取保护或切换措施。

下面以OSPF与BFD联动为例，简单介绍BFD会话建立流程。

OSPF 与 BFD 联动的会话建立流程：

1. OSPF 邻居发现，两台设备通过 OSPF 的 Hello 报文机制建立邻居关系。

2. OSPF 通告邻居信息，OSPF 在邻居关系建立成功后，将对端的邻居信息（如源 IP、目的 IP）传递给 BFD。

3. BFD 会话建立，BFD 根据 OSPF 提供的邻居信息发起会话请求，建立 BFD 会话。

4. BFD 链路检测，会话建立后，BFD 周期性发送检测报文；一旦在约定时间内未收到对端响应，则判定链路故障，并立即通知 OSPF。OSPF 收到通知后会快速收敛，触发路由重计算或切换，保证业务不中断。

2.2 BFD单跳检测和多跳检测

在 IP 链路上可以建立 BFD 会话，利用 BFD 的检测机制对链路进行快速故障检测。BFD for IP 支持 IPv4 链路的单跳检测和多跳检测：

• BFD 单跳检测（Single-hop BFD）
  单跳检测用于两个 直连系统之间的 IP 连通性检测，这里的“一跳”指的是 IP 的一跳。在这种场景下，对于某一种给定的数据协议，在指定接口上只会建立 一个 BFD 会话。单跳检测常用于直连路由器之间的链路快速故障检测。

• BFD 多跳检测（Multi-hop BFD）
  多跳检测用于检测两个系统之间 跨越多个路由跳数的任意路径的连通性。这些路径可能跨越很多中间设备，甚至在某些部分出现路径重叠。多跳检测常用于验证端到端的 IP 路由可达性（例如：PE–PE之间的转发路径），在隧道、VPN 等场景下尤其重要。

2.3 BFD会话建立

2.3.1 建立模式

BFD 会话双方在BFD会话建立阶段可处于 主动模式 和 被动模式：

• 主动模式：无论是否收到对端报文，都会主动发出 BFD 控制报文；

• 被动模式：只有在收到对端报文后才会回应；
  👉 至少一方为主动模式，会话才能成功建立。

2.3.2 会话管理

BFD会话有四种状态：Down、Init、Up和AdminDown。会话状态变化通过BFD报文的State字段传递，系统根据自己本地的会话状态和接收到的对端BFD报文驱动状态改变。BFD状态机的建立和拆除都采用三次握手机制，以确保两端系统都能知道状态的变化。以BFD会话建立为例，简单介绍状态机的迁移过程。

1. DeviceA和DeviceB各自启动BFD状态机，初始状态为Down，发送状态为Down的BFD报文。对于静态配置BFD会话，报文中的Your Discriminator的值是用户指定的；对于动态创建BFD会话，Your Discriminator的值是0。

2. DeviceB收到状态为Down的BFD报文且已学习到Your Discriminator的值时，状态会切换至Init，并发送状态为Init的BFD报文。（DeviceB本地BFD状态为Init后，不再处理接收到的状态为Down的报文。）

3. DeviceA的BFD状态变化同DeviceB，DeviceA收到状态为Down的BFD报文且已学习到Your Discriminator的值时，会向DeviceB发送状态为Init的报文。

4. DeviceB收到状态为Init的BFD报文后，本地状态切换至Up。

5. DeviceA的BFD状态变化同DeviceB。

2.4 BFD检测机制

BFD 的核心机制是在两个系统之间建立会话，并沿它们之间的转发路径周期性发送 BFD 控制报文。如果一方在规定的检测时间内未收到对端报文，则判定该路径发生故障，并上报给上层应用，实现快速收敛。

• 报文封装与会话建立
  BFD 控制报文封装在 UDP 报文中传送。在会话建立初期，双方系统通过交换控制报文协商必要参数，包括：会话标识符、最小收发报文间隔、本端 BFD 状态等。协商成功后，双方按照协商结果在路径上定时发送 BFD 控制报文。

• 业务相关性
  当 BFD 与不同的上层业务结合使用时，BFD 协商报文的发送路径会跟随业务指定的路径进行转发，而 BFD 检测报文则严格沿业务的实际转发路径传递，从而确保检测与业务一致。

• 检测模式
  BFD 的主要检测模式是 异步模式（Asynchronous Mode，UDP目的端口3784）。在该模式下，双方周期性互发控制报文，如果连续丢失若干个报文，会话即被判定为 Down。

• Echo 功能（辅助）
  异步模式可结合 Echo 功能（UDP目的端口3785）。当启用 Echo 功能时，本地设备向对端发送 BFD Echo 报文，对端设备不处理该报文，而是通过转发面原路返回。若连续若干个 Echo 报文未返回，会话同样被判定为 Down。由于直接验证了转发路径，Echo 功能能更准确反映实际数据面状况，但仅适用于单跳检测。

2.5 BFD协议报文

🔑 BFD 报文关键字段

1. State (Sta)

   • 表示本地 BFD 会话的状态。

   • 取值：

     • 0 = AdminDown（管理员关闭，会话不可用）

     • 1 = Down（未建立，链路不可用）

     • 2 = Init（正在初始化，尝试建立会话）

     • 3 = Up（会话建立成功，链路正常）
       👉 是 BFD 协商和检测的核心字段，直接反映会话状态。

2. Detect Mult (Detection Multiplier)

   • 检测倍数，用于计算 BFD 的超时时间。

   • 检测时间 = Required Min RX Interval × Detect Mult。

   • 例如：Min RX = 100ms，Detect Mult = 3，则超时时间 = 300ms，如果 300ms 内没收到报文，就判定链路 Down。
     👉 这是 BFD 快速检测的核心机制。

3. My Discriminator / Your Discriminator

   • My Discriminator：本端唯一 ID（非 0），标识一个会话。

   • Your Discriminator：记录对端的 My Discriminator。

   • BFD 报文通过这两个字段实现 会话绑定，区分多个会话。
     👉 类似于 TCP 的端口号，用来标识会话实例。

4. Desired Min TX Interval / Required Min RX Interval

   • Desired Min TX Interval：本端期望的最小发送间隔。

   • Required Min RX Interval：本端能接受的最小接收间隔。

   • 两端交换这两个参数后，协商出最终的报文发送周期。
     👉 这是 BFD 协商检测速度的核心参数。

5. P (Poll) / F (Final)

   • 用于参数协商。

   • P=1：请求对端立即确认新的参数。

   • F=1：对端确认（回应 Poll）。
     👉 相当于 TCP 的握手机制，保证参数协商一致。

6. C (Control Plane Independent)

   • 表示 BFD 是否依赖控制平面：

     • 0：依赖控制平面，控制平面重启时 BFD 可能误判 Down。

       • 对比本端与对端的C bit位，二者不都为1时，表示BFD报文在控制平面传输。这种情况下，GR期间BFD检测往往会误down，其结果是不可信的，业务不需要进行响应。

     • 1：独立于控制平面，即使控制平面重启，BFD 检测仍然有效。
       👉 对 GR（Graceful Restart） 场景特别关键。

       • 对比本端与对端的C bit位，二者都为1时，表示发送系统的BFD实现不依赖于控制平面，BFD报文在转发平面传输，即使控制平面失效，BFD仍然能够起作用。这种情况下，GR期间BFD检测down是可信的，业务将响应down消息并改变拓扑和路由，避免流量丢失。

---

✨ 总结：

• 会话状态（State） → 直观反映链路是否 Up。

• 检测倍数（Detect Mult）+ Min RX → 控制检测超时，决定 BFD 反应速度。

• Discriminator → 标识和绑定会话。

• Poll/Final → 保证参数协商一致。

• C 位 → 保证在控制平面故障时，转发检测仍然可靠。

三、BFD for LDP LSP

3.1 概述

在 LDP 中，LSR 通过周期性发送 Hello 消息来通告自身存在并维持与邻居的 Hello 邻接关系。每个邻居对应一个 Hell