安装和配置 FRRouter¶

本规范的目标是设计和规划需求，以便为 TripleO 添加支持，在 overcloud 节点上安装并提供 Free Range Router (FRR) 的基本配置，以支持 BGP 动态路由。管理员可能希望运行 FRR 的原因有很多，包括在多个上行链路到 northbound 交换机上获取多个路由，或通过动态路由协议向网络或 IP 地址通告路由。

问题描述¶

使用 BGP 有多种用例，事实上，目前正在进行单独的努力来利用 BGP 用于控制平面和数据平面。

BGP 可用于出站链路的等价多路径 (ECMP) 负载均衡，以及双向转发检测 (BFD)，以提高弹性，确保路径提供连接性。对于出站连接，BGP 将从 BGP 对等体处学习路由。

BGP 可用于向 API 端点通告路由。在这种模式下，HAProxy 将侦听一个 IP 地址，FRR 将向 BGP 对等体通告该 IP 的路由。HAProxy 的高可用性通过其他方式提供，例如 Pacemaker，FRR 将仅在 API 控制器上处于活动状态时通告虚拟 IP 地址。

BGP 还可以用于将入站流量路由到提供商网络 IP 或实例连接的浮动 IP。Compute 节点将运行 FRR 以向本地 VM IP 或节点上托管的浮动 IP 通告路由。FRR 具有一个名为 Zebra 的守护进程，负责在诸如 BGP 和内核之类的路由守护进程之间交换路由。FRR 配置中的 *redistribute connected* 语句将导致主机上的本地 IP 地址通过 BGP 进行通告。浮动 IP 地址附加到命名空间中的环回接口，因此将使用此方法重新分发它们。需要对 OVN 进行更改，以确保分配给 VM 的提供商网络 IP 将以类似的方式分配给命名空间中的环回接口。

提议的变更¶

概述¶

创建一个包含 FRR 的容器。该容器将运行 BGP 守护进程、BFD 守护进程和 Zebra 守护进程（该守护进程将路由复制到/从内核）。提供一个基本配置，允许与多个对等体进行 BGP 对等连接。在控制平面用例中，FRR 容器需要与 HA 组件一起启动，但在数据平面用例中，该容器将是支持 Neutron 的 sidecar 容器。容器的定义在以下变更中提出：[1]

容器将使用 TripleO 部署服务部署。该服务将使用 Ansible 对 FRR 配置文件进行模板化，并且存在一个简单的实现，在以下变更中提出：[2]

当前的 FRR Ansible 模块不足以配置 BGP 参数，需要扩展它。目前，Ansible Networking 开发团队对扩展 FRR 模块不感兴趣，因此配置将使用 TripleO 模板为 FRR 主配置文件和守护进程配置文件提供。这些模板在以下变更中提出：[3]

需要提供一个用户可修改的环境文件，以便安装程序可以提供 FRR 所需的配置数据（请参阅用户体验部分）。

需要修改 OVN，以使 Compute 节点能够将 VM 提供商网络 IP 分配给命名空间内的环回接口。这些 IP 地址将不用于发送或接收流量，仅用于将路由重新分发到 BGP 对等体。发送到这些 IP 地址的流量将使用 hypervisor 上的 OVS 流转发到 VM。已经编写了一个 OVN 代理来演示如何监视 southbound OVN DB，并在 Compute 节点上启动 VM 时创建环回 IP 地址。OVN 的更改将在单独的 OVN 规范中详细说明。演示代码在 Github 上可用：[4]

用户体验¶

安装程序需要提供一些基本的 FRR 配置信息，包括是否启用 BFD、BGP IPv4、BGP IPv6 和其他设置。请参阅下面的示例配置数据部分。

其他用户提供的数据可能包括入站或出站过滤前缀。默认过滤前缀将仅通过 BGP 接受默认路由，并且仅导出具有 /32 子网掩码的 IPv4 或 /128 子网掩码的 IPv6 的环回 IP。

示例配置数据¶

tripleo_frr_bfd: false
tripleo_frr_bgp: false
tripleo_frr_bgp_ipv4: true
tripleo_frr_bgp_ipv4_allowas_in: false
tripleo_frr_bgp_ipv6: true
tripleo_frr_bgp_ipv6_allowas_in: false
tripleo_frr_config_basedir: "/var/lib/config-data/ansible-generated/frr"
tripleo_frr_hostname: "{{ ansible_hostname }}"
tripleo_frr_log_level: informational
tripleo_frr_watchfrr: true
tripleo_frr_zebra: false

替代方案¶

通过多个上行链路路由出站流量

通常通过绑定以太网接口提供出站流量的容错性和负载均衡。这适用于大多数情况，但容易受到单向接口故障的影响，即流量仅在一个方向上工作的情况。用于绑定的 LACP 协议确实提供了一些针对单向流量故障的保护，但不如 FRR 提供的双向转发检测 (BFD) 强大。
将入站流量路由到高可用性 API 端点

当前用于提供 API 端点 HA 的最常见方法是使用虚拟 IP，该虚拟 IP 在活动到待机节点之间使用共享以太网 MAC 地址进行故障转移。这种方法的缺点是所有待机 API 控制器必须位于与活动控制器相同的 layer 2 区域（VLAN）中。如果操作员希望将 API 控制器放置在不同的故障域中以实现电源和/或网络，这将是一个挑战。BGP 守护进程通过直接通过路由的 layer 3 链路向 BGP 对等路由器通告共享 IP 地址来避免此限制。
路由到 Neutron IP 地址

通常通过与 IP 关联的以太网 MAC 地址以及通过共享 VLAN 上的 ARP 请求确定的方式将数据平面流量传递到提供商网络或浮动 IP 地址。这要求每个可能托管提供商网络 IP 或浮动 IP 的 Compute 节点都具有适当的 VLAN trunk 到连接到接口或 bond 的提供商桥接器。这使得在边缘计算拓扑或在完全 layer 3 路由的数据中心中跨 layer 3 边界迁移 VM 或浮动 IP 变得不可能。

安全影响¶

尚未识别出与此方法相关的直接安全影响。安装程序应确保整个网络上的安全策略防止 IP 欺骗，这可能会将合法流量转移到意外的主机。无论 OpenStack 节点是否使用 BGP，这都是一个问题，并且可能是在使用传统路由架构或静态路由的环境中出现的问题。

升级影响¶

当（如果）我们删除管理 overcloud heat 堆栈中的网络资源的能力时，我们需要评估是否要继续提供 BGP 配置作为 overcloud 配置的一部分。

如果操作员希望在升级 OpenStack 版本的同时开始使用 BGP 路由，他们需要提供所需的配置参数（如果与 TripleO 部署服务提供的默认值不同）。

性能影响¶

预计使用这种方法不会产生性能影响，无论是积极的还是消极的。已经尝试通过在配置中使用保守的默认值来最大程度地减少内存和 CPU 使用量。

文档影响¶

这是一个新的 TripleO 部署服务，应正确记录，以指导安装程序为他们的环境配置 FRR。

TripleO 文档需要在许多部分进行更新，包括

FRR 守护进程在其他地方有文档记录，我们不需要记录 BGP 的用法，因为这是一种标准协议。根据使用的路由交换机的制造商和型号，配置 top-of-rack 交换机是不同的，我们不应期望为网络硬件提供配置示例。

实现¶

该实现需要一个新的 TripleO 部署服务、容器定义和对现有角色定义的修改。这些更改已提出上游，请参阅参考部分中的 URL 链接。

负责人¶

主要负责人

Dan Sneddon

次要分配人

Michele Baldessari
Carlos Gonclaves
Daniel Alvarez Sanchez
Luis Tomas Bolivar

工作项¶

开发容器定义
定义 TripleO 部署服务模板
定义 TripleO Ansible 角色
修改现有 TripleO 角色以支持上述更改
合并对容器、部署服务和 Ansible 角色的更改
确保 FRR 包适用于受支持的 OS 版本

安装和配置 FRRouter