易捷行云EasyStack高性能网络解析系列之OVN中的BFD协议详解

易捷行云EasyStack云基础设施ECF的核心之一是高性能网络产品，在具备大规模软件定义云网络能力的基础上，如何解决包括大规模软件定义网络方案，平台网络高可用性，南北向与东西向数据流量的转发性能，一云多芯、多样算力（虚拟云主机、裸金属、安全容器、容器集群）的网络连通等问题，针对这些问题，我们将对高性能网络产品中核心技术之一的OVN进行系列介绍。

易捷行云EasyStack云基础设施高性能网络产品，在基于数字原生架构基础上，提供了针对大规模、高性能的网络方案，面对企业用户，网络的高可用性与整个平台的可用性都是非常关键的考量因素，以下是针对OVN中高可用性关键协议BFD进行详细介绍。

BFD协议简介

BFD（Bidirectional Forwarding Detection，双向转发检测 ) 是一种网络协议，用于检测通过链路连接的两个路由器或交换机之间的故障。即使在不支持任何类型的故障检测的物理介质上，例如以太网、虚拟电路、隧道和 MPLS 标签交换路径，它也能提供低开销的故障检测。

BFD 通过特定链路在两个端点之间建立会话。如果两个系统之间存在多条链路，则可以建立多个BFD会话来监控其中的每一个。BFD会话的建立和删除都是通过三次握手机制实现的，来确保通信双方都能了解状态的变化。可以在会话上启用身份验证。可选择简单密码、MD5 或 SHA1 身份验证。

BFD 没有发现机制；会话必须在端点之间显式配置。BFD 可用于许多不同的底层传输机制，并独立于所有这些进行操作。因此，它需要通过它使用的任何传输进行封装。例如，监控 MPLS LSP 涉及在 LSP-Ping 数据包上建立会话。支持某种形式的邻接设置的协议，例如 OSPF、IS-IS、BGP 或 RIP，也可用于引导 BFD 会话。这些协议然后可以使用 BFD 来接收故障链接的通知，这比通常使用协议自己的保活机制可能实现的更快。

BFD在很多方面与路由协议的hello机制是一样的。两个系统之间相互交互周期性的BFD报文，如果一个系统在一定的时间内没有收到BFD报文，则认为链路故障。系统之间协商也可以不通过周期性的发送BFD报文以减少对带宽资源的占用。

BFD运行模式BFD有两种运行模式和一种辅助功能。辅助功能可以与两种运行模式联合使用。

异步模式是BFD的一种主要运行模式，在这种模式下，系统向邻居周期性的发送BFD控制报文，并且如果没有收到一定数量的来自对端的BFD控制报文（检测时间内应该收到的报文数量），则宣告会话断开。

查询模式是BFD的另一种工作模式，在这种模式下，它假定系统有一个独立的路径来确定它与邻居之间的连通性。一旦BFD会话建立起来，该系统可能会要求其他系统停止发送 BFD 控制数据包，直到需要检验连通性的时候，会与邻居交互一连串的BFD控制报文，如果正常收到相应的BFD控制报文，则继续静默，否则，宣告会话断开。查询模式中，两个方向会话是相互独立的。

这两种主要的工作模式有一个辅助功能就是回声功能。回声功能开启后，会发一串回声报文流并等待对端将该报文流环回回来。如果没有收到，宣告会话断开。回声功能是和异步模式或查询模式一起使用的，当开启回声功能后，回声功能承担了检测任务，异步模式的发包频率可以减小，查询模式可以完全不发包。

纯异步模式可以完成一些开启回声功能后无法完成的任务。回声功能开启可以减少对带宽资源的消耗。

回声功能可以只在一个方向开启，要求对端具有环回功能。

查询模式适用于周期报文占用过多带宽资源的场景，比如配了大量的BFD会话，每一个会话都需要周期发送BFD控制报文，对链路带宽的占用会非常明显。查询模式BFD无法快速检测到突发的链路故障。

BFD控制报文格式

BFD控制报文需要封装在适当的报文中发出去，比如封装在udp中或者作为icmp的tlv封装在ping报文中。

BFD控制报文分为强制部分和可选部分，强制部分24字节，可选部分最短2字节。

Version (Vers)  协议版本号，本文档定义为1。

Diagnostic (Diag)  诊断类型字段，记录本地系统最近一次状态变化的原因，有以下值：

0 -- 无

1 -- 控制检测时间超时

2 -- 回声功能失败

3 -- 邻居标记会话down

4 -- 转发面重置

5 -- 路径down

6 -- Concatenated Path Down

7 -- 管理down

8 -- Reverse Concatenated Path Down

9到31 -- 保留

State (Sta) 当前BFD会话状态：

0 -- 管理down

1 -- down

2 -- init

3 -- up

Poll (P)  若置位的话，系统要求检测链路状态，或者有参数变化，发送P位置位的包（下文简称P包），并期待收到F位置位的包（下文简称F包）。若复位的话，标明系统不需要检测链路状态。

Final (F)  若置位的话，标明系统在回应P包，若复位，标明系统并没有在回应P包。

Control Plane Independent (C)  若置位，标明BFD的运行独立于控制面（换句话说BFD运行于转发面，可以在控制面故障的时候继续运行），若复位，表明控制面不独立，BFD的功能受控制面状态影响。

Authentication Present (A)  若置位，标明需要认证。

Demand (D)  若置位，查询模式开启（此时两边BFD状态都为up，通知对端停止发送周期报文），若复位，查询模式关闭。

Multipoint (M)  保留，用于未来点对多点BFD实现，必须置0。

Detect Mult  检测倍数，在异步模式系统中，检测倍数与协商的最小发包时间间隔乘积决定检测时间。

Length  BFD控制报文长度，单位byte。

My Discriminator  本端标识符，唯一标示本端的某一个BFD会话。

Your Discriminator  远端标识符，唯一标示远端的某一个BFD会话，若不知道远端标识符，则置0。

Desired Min TX Interval  期望最小发包间隔，单位ms，标明本端系统发包的最快频率。

Required Min RX Interval  要求最小收包间隔，单位ms，标明本端支持的最快收包频率。如果为0，标明本端不支持接收周期BFD控制报文。

Required Min Echo RX Interval  要求最小回声报文收包间隔，单位ms，标明本端支持的最快回声报文收包频率。如果为0，标明本端不支持接收BFD回声报文。

Auth Type  认证类型。

0 -- 保留

1 -- 简单秘钥

2 -- Keyed MD5

3 -- Meticulous Keyed MD5

4 -- Keyed SHA1

5 -- Meticulous Keyed SHA1

6 -- 255 保留做未来使用

Auth Len  认证部分长度，单位byte。

BFD状态机

BFD的状态机非常简单。会话过程中只有三个状态：两个用来建立会话（init和up），一个用来断开会话（down）。建立回话和断开会话都需要三次握手确保两端系统都感知到。另外还有一个特殊状态：admindown，使会话可以通过管理手段断开会话，在状态机中admindown也是down状态。每个系统通过发送报文中的sta域发送本端状态，接收报文中的sta域了解对端状态，综合起来决定状态机的跳转。

Down状态意味着会话down。一个会话会维持在down状态直到收到对端的报文并且该报文的sta字段标志着对端状态不是up（down或者init），如果收到的是down包，状态机将从down状态跳转到init状态，如果收到的是init包，状态机将从down状态跳转到up状态，如果收到的是up包，状态机维持down状态。（注意以上描述的down包、init包、up包只是BFD控制报文中sta域标志位down、init、up的控制包，只是非正式简称，下文出现此种描述也是这个意思）。Down状态意味着转发路径不可达，BFD可以采取相应的动作。Down状态是BFD的基态，如果什么都不发生会永远维持down状态，除非由于管理操作终止了BFD。

Init状态意味着远端正在通信，并且本地会话期望进入up状态，但是远端还没有意识到。一个init状态的会话会维持init状态直到收到对端的init包或者up包，就会跳转到up状态，否则等到检测时间超时以后，便会跳转到down状态，意味着与远端的通信丢失。

Up状态意味着BFD会话成功建立，并且正在确认链路的联通性，会话会一直保持在up状态直到链路故障或者admindown操作。如果收到远端的down包或者检测时间超时会话就会从up状态跳转到down状态。

admindown意味着会话是被管理操作断开会话的，这会导致远端系统会话进入down状态，并且一直保持down状态直到本端退出admindown。admindown并不意味着转发路径的连通性问题。

下图是BFD状态机

BFD建立过程

基于BFD实现的L3 HA

OVN以透明的方式实现 L3 高可用性，不需要启用任何配置标志。一旦有多个chassis能够充当连接到路由器的特定外部网络的 l3 网关，它就会将路由器网关端口调度到多个chassis， NB中的 Logical_Router_Port 表中的 gateway_chassis 列来记录该断开可被调度的chassis。

路由器连接到外部网络，可以通过如下的方式：

（1）配置网关节点ovn-cms-options=enable-chassis-as-gw（Open_vSwitch table’s external_ids column）

ovs-vsctl set open . external-ids:ovn-cms-options="enable-chassis-as-gw"

（2）如果所有节点都未配置ovn-cms-options=enable-chassis-as-gw，则所有节点都可以当作网关节点。

本质上这些功能主要由 OpenFlow 规则实现，并具有捆绑 active_passive 输出。ARP 响应器和路由器启用/禁用由 ovn-controller 处理。FIP 和路由器外部地址的免费 ARP 由 ovn-controller 定期发送。

BFD monitoring

OVN 通过 BFD 协议监控chassis的可用性，该协议封装在chassis之间的 Geneve 隧道之上。

每个标记为gateway chassis将监控部署中的所有其他gateway chassis以及compute node chassis，让网关启用/禁用数据包的路由和 ARP 响应/公告。

compute node chassis将通过 BFD协议 监控gateway chassis，将router的外部流量（snat/dnat）自动引导到active chassis gateway chassis以星型拓扑相互监视。compute node chassis不会相互监视，因为这不是必需的。

Failover (detected by BFD)

以上图为例，计算节点 BFD 检测到到达网关节点 1 的隧道的endpoint已关闭。因此，需要通过路由器进入外部网络的流量输出将被重定向到 R1 的较低优先级chassis。R2 保持不变，因为网关节点 2 已经是 R2 的最高优先级chassis。

网关节点 2 将检测到网关节点 1 的隧道endpoint已关闭，因此它将负责转发 R1 的外网流量，ovn controller将为下发openflow rule（外部 ARP 响应器、流量转发 (N/S) 和定期的免费 ARP）。

网关节点 2 还将绑定router的external port（在 South Bound 数据库上表示为chassis-redirect port）。

如果网关节点 1 仍然存在，则会检测到接口 2 上的故障，因为它看不到任何其他节点。

目前还没有检测外部网络故障的机制，检测网络故障的推荐做法是用bond口。

支持的故障模式有：

gateway chassis与网络断开连接（隧道接口）

ovs-vswitchd 停止（它负责 BFD 信令）

ovn-controller 已停止，因为 ovn-controller 会将自己删除为已注册的chassis。

Failback

OVN 中的L3HA是基于优先级抢占实现的（至少目前是这样），这会将路由器平衡回原始chassis，避免任何网关节点成为瓶颈。