如何在 OSPF 中配置灵活的分段路由算法 流量工程

配置灵活算法的好处

• 分段路由流量工程的轻量级版本，可在网络核心中使用。

• 即使无需安装网络控制器，也可以使用分段路由配置流量工程。

• 每切片利用等价多路径 （ECMP） 和 TI-LFA，无需配置 BGP-LS 或静态路径。

• 使用相同的灵活算法定义和约束计算计算 TI-LFA 备份路径。

• 利用仅使用 OSPFv2 的分段路由流量工程，无需配置 RSVP 或 LDP。

• 能够基于单个标签配置受约束的主路径。

什么是灵活算法定义 （FAD）？

灵活的算法允许 IGP 根据指定的约束计算其他最佳路径，从而提供简单的流量工程，而无需使用网络控制器。对于尚未实施具有完整分段路由的控制器，但仍希望在网络中获益的网络来说，这是一款轻量级解决方案。每个作员都可以根据自己的要求定义单独的约束或颜色。

要定义灵活的算法，请在[edit routing-options]层次结构级别包含flex-algorithm id语句。灵活算法定义 （FAD） 分配了一个介于 128 到 255 之间的标识符。这种灵活的算法可以在网络中的一个或多个路由器上定义。灵活的算法会根据以下参数计算最佳路径：

• Calculation type—SPF 或严格 SPF 是两个可用的计算类型选项。您可以在 FAD 中指定其中一种计算类型。如果要根据特定本地策略（例如流量工程快捷方式）影响设备上的 SPF 计算，请选择 SPF 计算类型。如果选择严格 SPF，则本地策略无法影响 SPF 路径选择。

• Metric type- IGP 公制或 TE 公制是可用的公制类型选项。您可以根据网络要求在 FAD 中指定其中一种指标类型。如果不想对特定链路使用 IGP 指标，可以配置 OSPFv2 可用于计算路由的 TE 指标。

• Priority- 您可以根据需要为 FAD 分配优先级，OSPFv2 会根据您分配的优先级将特定 FAD 播发优先于另一个 FAD。

• Set of Link constraints- 您可以在层次结构级别为许多协议[edit protocols mpls admin-groups]配置管理组，以便为单个链接着色。然后，可以在层次结构级别上将这些admin-groups定义为 或[edit routing-options flex-algorithm definition admin-groups] include-all exclude。include any

建议仅在少数路由器上配置灵活的算法，以提供冗余并避免冲突。灵活的算法定义在 IGP 中公布为 FAD sub-TLVs。在超大型网络中，我们不建议配置超过 8 个灵活算法定义，因为每个灵活算法都会计算自己的路径，超出这个范围可能会导致性能问题。

默认 FAD 具有以下参数：

• 计算类型：SPF

• 指标类型：IGP-度量

• 优先级：0

• 链路限制：无

从 Junos OS 21.4R1 开始，我们支持 TED 中的灵活算法定义 （FAD）“和”灵活算法前缀度量 （FAPM）“，并在 BGP-LS 中实现了两个新的对应 TLV”FAD TLV“和”FAPM TLV“。FAD TLV 的值包含 Flex-Algorithm、Metric-Type、Calculation-Type 和 Priority，每个均为一个字节。TLV 中可能包含零个或多个子 TLV。五个子 tlv 是 Flex 算法排除任何亲和力、Flex 算法包括任何亲和力、Flex 算法包括所有亲和力、Flex 算法定义标志和 Flex 算法排除 SRLG。

只有当相应的节点源自底层 IGP TLV 或子 TLV 时，才能将 FAD TLV 添加到节点 NLRI 的 BGP-LS 属性中。与节点 NLRI 关联的 BGP-LS 属性可能包括一个或多个 FAD TLV，这些 FAD TLV 对应于节点播发的每个算法的灵活算法定义。

FAPM TLV 的值包含 Flex 算法（1 字节）、保留（3 字节）和度量（4 字节）。仅当相应的节点源自前缀时，才能将 FAPM TLV 添加到源自节点的前缀 NLRI 的 BGP-LS 属性中。

从 Junos OS 22.4R1 版开始，我们定义了灵活算法前缀度量 （FAPM），以便为区域间前缀提供最佳的端到端路径。区域边界路由器 （ABR） 在通告给定灵活算法 （flex algo） 中可访问的区域之间的前缀时，必须包括 FAPM。当前缀无法访问时，在区域之间播发时，ABR 不得在该 flex 算法中包含该前缀。定义的 FAPM 提供区域间支持。

参与灵活的算法

您可以根据需要将特定路由器配置为参与特定灵活的算法。各种应用程序使用基于灵活算法定义计算的路径，每个应用程序可能使用自己的特定数据平面来通过此类路径转发数据。参与设备必须向分段路由灵活算法子 TLV for OSPFv2 中的每个应用程序明确播发其参与特定灵活算法的情况。您可以将节点配置为参与某种灵活的算法，前提是它可以支持该 FAD 中指定的约束。

要在灵活的算法中配置参与，请在[edit protocols isis source-packet- routing]层次结构级别包含flex-algorithm语句。同一设备可以通告 FAD，也可以参与灵活的算法。

配置了灵活算法定义的网络拓扑

图 1 显示了示例拓扑，有 8 个路由器 R0、R1、R2、R3、R4、R5、R6 和 R7。四种灵活的算法 128、129、130 和 135 被定义并配置了管理组，如下表所示：

图 1：灵活的算法拓扑

图 2 显示了 FAD 128 如何在配置了管理组 red 的任何接口上路由流量。

图 2：灵活算法定义 128 的流量

图 3 显示了 FAD 129 如何在配置了管理组绿色的任何接口上路由流量。

图 3：灵活算法定义的流量 129

图 4 显示了 FAD 130 如何在配置了管理组绿色和蓝色的任何接口上路由流量。

图 4：灵活算法定义 130 的流量

图 5 显示了 FAD 135 如何在未配置管理组 red 的任何接口上路由流量。

图 5：灵活算法定义 135 的流量

灵活的算法 RIB

对于路由器参与的每个灵活算法，相应的灵活算法路由都会安装在相应的灵活算法 RIB 组（也称为路由表）中。默认情况下，带标签的 OSPFv2 灵活算法路由安装在 inet.color inet(6)color.0 和 mpls.0 RIB 中。

BGP 社区和灵活的算法

灵活的算法可以具有关联的 BGP 颜色社区，用于解析其他服务（如 VPN 服务）的路由。默认情况下，关联的 BGP 颜色社区与灵活算法 ID 相同。安装在 inet（6）color.0 表中的灵活算法入口路由在路由中会有这个颜色社区。但是，您可以在层次结构级别配置不同的 BGP 颜色社区 [edit routing-options flex-algorithm id color desired color community value] 。

支持和不支持的功能

Junos OS 在以下场景中支持灵活的算法：

• 支持为不同的灵活算法配置和播发前缀 SID。

• 部分支持 IGP 灵活算法 draft-ietf-lsr-flex-algo-05.txt互联网草案

• 目前灵活算法的实现仅支持 OSPFv2，因为只有 OSPFv2 支持分段路由。

Junos OS 不支持以下功能与灵活算法结合使用：

• 不支持链路延迟指标。

• 灵活的算法仅适用于默认单播拓扑，不支持 OSPFv2 多拓扑。

• OSPFv2 快捷方式和其他 OSPFv2 流量工程配置选项不适用于灵活的算法计算。.
• OSPFv3 不支持灵活算法的当前实现。

• 不支持灵活算法前缀 SID 的区域间 （OSPFv2） 泄漏。

• 不支持前缀和 SID 冲突解决。

• 不支持远程无环路替代功能，因为 TI-LFA 是首选的 FRR 计算。

• 不支持在没有灵活算法参与的情况下宣传灵活算法定义。

• 不支持使用特定于应用程序的链接属性通告来通告 Flex 算法的链路属性。

• 不支持传输类 RIB。

基于应用特定链接属性的灵活算法

从 Junos OS 和 Junos OS 演化版 22.2R1 版开始，您可以在同一链路上为 RSVP 和灵活算法播发不同的 te 属性，例如 te-metric、delay-metric 或admin-groups。这是使用 RFC 8920 中定义的灵活算法、特定于应用的链路属性来完成的。

让灵活的算法应用程序特定的链接属性通告 te-metric、delay-metric 或 admin-groups 的优点是，单个链接可以为 RSVP 等传统应用程序通告不同的 te-link-属性，为灵活的算法通告不同的 te-link-attributes 。

要配置灵活的算法特定于应用程序的 te 属性，请在[edit protocols ospf area interface]层次结构级别添加语句，strict-asla-based-flex-algorithm在层次结构级别包括application-specific语句[edit protocols ospf source-packet-routing]。通过此实现，不再强制要求链路启用和[edit protocols ospf traffic-engineering advertisement always]配置 RSVP，这与广告流量工程属性的现有行为就是这种情况。

基于严格应用特定链接属性的灵活算法

特定于应用程序的灵活算法的默认行为是将灵活算法特定于应用程序的 te 属性用于链接（如果可用），如果没有，则回退到通用的特定于应用程序的 te 属性，如果两者都不可用，则使用旧版 te 属性。

中的配置语句strict-asla-based-flex-algorithm[edit protocols ospf source-packet-routing]必须应用于网络中设备上运行的所有灵活算法，以避免路由环路。

如果 strict-asla-based-flex-algorithm 在所有设备上都配置了该属性，则必须为每个灵活算法链路播发通用的应用特定于 te 属性或灵活算法的应用特定于 te 属性。如果没有特定于应用的 te 属性，设备不会回退到传统的 te 属性，而只会忽略链路。

作系统支持以下功能以及基于特定于应用程序的链接属性的灵活算法：

• 特定于应用的 te-attribute subTLV，符合 RFC 8920。特定于应用的 te-attributes 子 TLV 是 RFC 7684 中定义的 OSPFv2 扩展链路 TLV 的子 TLV。

• 部分支持标准应用标识符位掩码，以通告 X 位以实现灵活的算法。只有 te-metric、delay-metric 或 admin-groups 才会作为特定于应用程序的链路属性子 TLV 的一部分进行播发。

作系统不支持以下功能与基于应用程序特定链接属性的灵活算法结合使用：

• 不支持播发用户定义的应用程序标识符位掩码。
• 不支持使用 BGP-LS 重新播发灵活的算法、特定于应用的链路属性，或者更确切地说，任何特定于应用的链路属性，因为流量工程数据库 （TED） 不支持特定于应用的链路属性。

• 不支持使用标准应用程序标识符位掩码和用户定义的应用程序标识符位掩码长度设置为零的通用应用程序特定链接属性。

• 不支持在灵活算法中宣传 SRLG 链路约束。

• 除灵活算法外，不支持多种应用的流量工程。

• 不支持定义独立于 MPLS 的管理组。