本页内容
 

gRIBI

gRPC 路由信息库接口 （gRIBI） 是一种 gRPC 服务，使外部应用能够以编程方式添加、修改和移除网络设备上的路由。

gRIBI 服务是一个 API，用于在设备的路由信息库（RIB，也称为路由表）中添加、修改和删除路由条目。如果条目符合转发条件，操作系统会自动将条目添加到设备的转发信息库（FIB，也称为转发表）。gRIBI 客户端应用程序可以使用瞻博网络扩展工具包 （JET） 支持的任何语言。客户端应用程序可以在外部网络管理系统上运行，也可以作为网络设备上的本地应用程序运行。

gRIBI 服务原型定义文件位于 https://github.com/openconfig/gribi/blob/master/v1/proto/service/gribi.proto。Junos 设备支持的 gRIBI 消息位于 JET IDL 包中。

OpenConfig 抽象转发表 （AFT） 模型是一种 YANG 数据模型，用于描述安装在网络设备上的转发条目。gRIBI 使用 OpenConfig AFT 模型的协议缓冲区转换版本来描述它可以修改的 RIB 条目。OpenConfig AFT 模式的 protobuf 表示形式位于 https://github.com/openconfig/gribi/blob/master/v1/proto/gribi_aft/gribi_aft.proto 的 proto 定义文件中。

gRIBI 的优势：

  • 在对路由进行编程时发送确认。
  • 支持分层查找。
  • 当多个客户端连接到 gRIBI 会话时，支持仲裁。

使用此 show route extensive 命令显示 gRIBI 的路由数据，包括路由使用的客户端 ID 和下一跳组 ID。

注意：

我们建议同时使用 gRIBI 或 JET RIB 服务 API，尤其是对于同一组路由。

支持的 RPC

Junos 设备支持 gRIBI 服务 RPC，可以从设备的 RIB 远程检索、添加、修改或删除路由。RPC 通过修改或读取设备上的抽象转发表 （AFT） 来发挥作用。

表 1：支持的 gribi.proto RPC
RPC 定义 在版本中引入
Modify()

从 AFT 添加、修改或删除条目。

Junos OS 19.4R1 版

Junos OS Evolved 版本 20.3R1
Get()

从 AFT 检索已安装的条目。

Junos OS 演化版 22.2R1
Flush()

移除与消息中 FlushRequest 描述的内容匹配的所有设备 AFT 条目。

Junos OS 演化版 22.2R1

网络设备配置

Junos OS Evolved 23.4R1 及更高版本

开始之前：

要为 gRIBI 配置网络设备：

  1. 使用基于过滤器的转发创建路由实例。
  2. 配置两个策略：一个用于处理多路径解析，一个用于处理负载平衡。

    在此示例中，名为 mp-resolve 的策略处理多路径解析。如果解析路由具有多个路径，则解析的路由将跨所有路径解析。该策略 pplb 告知数据包转发引擎对每个数据包的流量进行负载均衡。

  3. 设置剩余等待时间，以便系统有足够的时间更新路由。系统重新启动后，rpd 进程会等到剩余等待时间到期后再清理路由。rpd 进程不会删除在等待时间到期之前更新的任何路由。

    您现在已准备好使用 gRIBI 服务 RPC。

在 Junos OS 演化版 23.4R1 之前

开始之前：

要为 gRIBI 配置网络设备：

  1. 使用基于过滤器的转发创建路由实例。
  2. 配置要在路由实例中用于默认、IPv4 系列协议和 IPv6 系列协议路由解析的路由表。

    您最多可以为每个协议家族指定两个路由表。路由解析方案仅在第一个路由表中找不到协议下一跃点地址的条目时，才会检查第二个路由表。

    在此示例中，是默认 teVRF.inet.0 路由表。如果该路由表中没有下一跃点地址的路由，路由解决方案方案将检查该 inet.3 表。

  3. 为 IPv4 和 IPv6 族解析树指定导入策略。

    例如：

  4. 配置两个策略：一个用于处理多路径解析，一个用于处理负载平衡。

    在此示例中，名为 mp-resolve 的策略处理多路径解析。如果解析路由具有多个路径，则解析的路由将跨所有路径解析。该策略 pplb 告知数据包转发引擎对每个数据包的流量进行负载均衡。

  5. 配置路由选项，以便在转发平面中安装下一跃点时保留下一跃点层次结构。
  6. 配置要用于 IPv4 和 IPv6 系列协议路由解析的路由表，以及路由选项级别的路由解析策略。对在路由实例级别配置的每个路由表重复此配置。

    例如：

  7. 设置剩余等待时间，以便系统有足够的时间更新路由。系统重新启动后，rpd 进程会等到剩余等待时间到期后再清理路由。rpd 进程不会删除在等待时间到期之前更新的任何路由。

    您现在已准备好使用 gRIBI 服务 RPC。

修改路由

使用 Modify() RPC 安装新路由并编辑 gRIBI 服务器的 RIB 中的现有路由。路由将添加为静态路由。

Modify() 是一个双向流式 RPC。客户端发送包含 Modify() 消息的 ModifyRequest RPC，以修改服务器上的 AFT 条目。对于每个 ModifyRequest，gRIBI 服务器会通过消息响应 ModifyResponse 客户端。

该 ModifyRequest 消息由一条或多 AFTOperation 条消息组成。每 AFTOperation 条消息定义添加、修改或删除单个 AFT 条目的请求。gRIBI 服务器按照 RPC 流式传输 AFT 操作的顺序 Modify() 处理 AFT 操作。

Junos 设备支持以下 AFT 条目类型：

  • IPv4Entry- 对 IPv4 路由进行编程。
  • NextHopEntry- 对下一跳进行编程。
  • NextHopGroup- 对下一跳组进行编程。

使用 Modify() RPC 执行以下功能：

路由确认

当您使用 RPC 在 Modify() 数据包转发引擎中成功编程路由时，服务器会发送确认。如果 gRIBI API 未能在给定的超时时间内对数据包转发引擎中的路由进行编程，则服务器将发送一条错误消息。您可以配置此超时的长度。确认仅对最近的路由有效。如果旧路由发送确认，但新路由不发送确认，则数据包转发引擎将其记录为错误。

Junos 设备在消息AFTOperation字段中entry支持以下值：

注意：

Junos 设备不支持该 MAC_ENTRY 选项。

使用命令 show route extensive 显示确认状态。在 rpd 进程重新启动期间，确认状态是持久的。

对 IPv4 路由进行编程

要对 IPv4 路由进行编程，请使用 IPv4Entry AFT 条目。AFT 根据目标地址匹配输入数据包，并将其映射到相应的下一跃点。在默认 VRF 实例以及网络中的流量工程 VRF 实例上安装 AFT 条目。要在非默认实例中安装 AFT 条目，请在 network_instance 消息字段 AFTOperation 中指定 VRF 实例。例如：

  • 流量工程 VRF 实例： g_b4_cos1
  • 将字段设置为 network_instance ： g_b4_cos1

gRIBI 客户端仅在收到来自服务器的确认后，才会在服务器上对 AFT 条目进行编程IPv4Entry，表明服务器收到了关联NextHopGroup的 and NextHop 消息。如果客户端在未确认消息的情况下在NextHopGroup服务器上对 AFT 条目进行编程IPv4Entry，则会将路由作为隐藏路由添加到服务器。

计划下一跳和下一跳组

使用 gRIBI Modify() RPC 在 gRIBI 服务器上编程下一跃点或下一跳组。RPC 仅在默认 VRF 实例中创建下一跃点和下一跃点组。

当同一 ModifyRequest 消息中存在下一跃点和下一跳组时，gRIBI 客户端会根据 AFT 操作进行处理。如果 AFT 操作添加 NextHop 并 NextHopGroup 条目，则客户端会先将所有下一跃点添加到服务器，然后再添加下一跃点组。如果 AFT 操作删除 NextHop 并 NextHopGroup 条目，客户端将按相反的顺序处理它们：在删除下一跃点之前删除所有下一跃点组。

在 Junos 设备中，RPC 将表中的inet6.3下一跃点实例化为 FC01::next_hop_id，其中下一跃点 ID 为十六进制。例如，如果下一跃点 ID 为 10，则服务器将安装表中inet6.3调用FC01::A的路由。

下一跃点组在表中inet6.3显示为 FC02::next_hop_id。例如，如果下一跳组 ID 为 100，则服务器将安装表中inet6.3调用FC02::64的路由。

例如，要通过可直接访问的接口对下一跳对象进行编程：

  1. 假设地址 10.0.1.2 可通过接口 et-0/0/7.0 访问，请在消息中 Afts 设置以下字段，其中 = 表示将字段设置为该值：

  2. 按以下步骤设置 AFTOperation 消息字段：

  3. 将消息设置为 ModifyRequest 使用上面定义的内容 AFTOperation 。

  4. 使用上述ModifyRequest消息调用 Modify() RPC。

  5. 要确认路由已成功编程，请使用 show route programmed CLI 中的命令。

使用 MAC 地址进行下一跳编程

或者，您可以使用下一跃点的 MAC 地址（而非其 IP 地址）来识别下一跃点。在设备无法使用动态地址解析协议 （ARP） 或邻接方发现协议 （NDP） 来查找下一跃点的 MAC 地址的网络中，此功能很有用。要使用 MAC 地址，请使用该 mac_address 字段而不是 ip_address AFT 消息中的字段。

注意：使用此接口的所有流量均使用 gRIBI 服务编程的静态 MAC 地址，即使未由 gRIBI 服务编程的路由上的流量也是如此。

使用 gRIBI 服务将 MAC 地址编程为接口上的下一跃点后，设备不会对使用此接口的任何流量使用动态 ARP 或 NDP。如果在客户端断开连接时删除或清除已编程的 gRIBI 下一跃点，设备会自动在接口上重新启用 ARP，路由将继续使用动态 ARP 运行。

例如，要通过可直接访问的接口对具有 MAC 地址的下一跳点对象进行编程：

  1. 确保要使用下一跃点编程的接口是编号接口。

  2. 确保接口上已启用 IPv6 家族。

  3. 假设可通过接口 et-0/0/7.0 访问 MAC 地址 00：00：5E：00：53：00，请在消息中 Afts 设置以下字段，其中 = 表示将字段设置为该值：

  4. 按以下步骤设置 AFTOperation 消息字段：

  5. 将消息设置为 ModifyRequest 使用上面定义的内容 AFTOperation 。

  6. 使用上述ModifyRequest消息调用 Modify() RPC。

  7. 要确认路由已成功编程，请使用 show route programmed CLI 中的命令。

分层查找和 IP-in-IP 隧道

gRIBI 的 Junos 实施支持分层查找。要配置分层查找，请使用 IPv4 AFT 对 IP-IP 隧道端点和站点组虚拟 IP 地址路由进行编程。

要将入口节点上的流量封装到 IP-in-IP 隧道中，请在消息中 NextHop 设置以下字段：

多个客户的仲裁

Modify()当多个客户端连接到 gRIBI 服务器时，RPC 支持仲裁。仲裁决定哪个客户端可以执行哪些操作。

使用该 SessionParameters 消息为 gRIBI 客户端设置持久模式和客户端冗余模式。所有客户端必须发送消息的所有 SessionParameters 属性的相同值。 SessionParameters 在会话的生存期内只能发送一次。

SessionParameters 必须是重新连接后发送的第一条消息。当客户端重新连接时，新会话将启动。如果已连接其他客户端，请将 SessionParameters 消息值与现有客户端设置的值进行匹配。如果所有客户端都重新连接，则可以将 SessionParameters 消息值设置为与上一个会话中使用的值不同的值。

Junos 设备同时支持PRESERVEDELETE和持久化模式。如果持久性模式设置为 PRESERVE，则即使在客户端断开连接后，服务器也会保留客户端添加的 AFT 条目。如果持久性模式设置为 DELETE，则服务器将在客户端断开连接时删除 AFT 条目。

建议在更改会话参数之前删除所有路由。如果更改会话参数并在另一种模式下添加路由之间和SINGLE_PRIMARY之后切换冗余模式ALL_PRIMARY，则可能会看到意外行为。

当有多个客户端时，您必须在两种客户端冗余模式之间进行选择：

所有主模式

在 ALL_PRIMARY 冗余模式下：

  • 任何客户端都可以修改路由。

  • 多个客户端可以添加同一个 AFT 条目。

  • gRIBI API 维护已添加路由的客户端的映射。

  • 第一个添加操作将条目添加到 RIB。来自不同客户端的同一条目的后续添加操作会将客户端添加到引用该条目的客户端列表中。

  • 删除操作会从引用该条目的客户端列表中删除客户端。仅当没有引用该条目的客户端时，才会删除该条目。

注意：

处理时 FlushRequest ，将删除条目，而不检查任何参考计数。

使用该 show route extensive 命令查看路由的详细信息。以下是命令 show route extensive 在 ALL_PRIMARY 模式下显示的内容的示例。为清楚起见，输出已缩短。

单主模式

在 SINGLE_PRIMARY 冗余模式下：

  • gRIBI 客户端可以具有主（主动）或备份角色。

  • 只有主客户端可以执行 AFT 操作。

  • 具有最高选择 ID 的客户端是主客户端。所有其他客户端都是备份客户端。

  • 当备份客户端成为主客户端时，新的主客户端可以修改前一个主客户端添加的路由。

设置每个设备的选择 ID，以确定哪个客户端是主客户端。您只能在冗余模式下设置选举 ID SINGLE_PRIMARY 。即使客户端处于关闭状态，选举 ID 也会保留。如果主客户端断开连接，它仍是主客户端，直到您将另一台设备的选择 ID 设置为更高。设置选择 ID 后，新的主客户端将继续对 gRIBI 条目进行编程。

要更新选举 ID，请发送 ModifyRequest 将选举 ID 设置为新值的邮件。每个客户端都必须有一个唯一的选举 ID。更新选举 ID 时，请勿设置消息的 ModifyRequest 任何其他字段。

选举 ID 出现在以下消息中：

  • ModifyRequest- 设置客户端的选举 ID。具有最高选择 ID 的客户端成为主客户端。

  • AFTOperation— 确定服务器是否应处理 AFT 操作。

  • ModifyResponse— 服务器使用当前最高的选择 ID 进行响应。

使用此 show programmable-rpd clients detail 命令查看组 ID 以及客户端是否具有主角色或备份角色。

使用该 show route extensive 命令查看路由的详细信息。以下是命令 show route extensive 在 SINGLE_PRIMARY 模式下显示的内容的示例。为清楚起见，输出已缩短。

在 VRF 实例中编程回退路由

当下一跃点无法通过静态路由到达时，网络可以通过备用路由重新路由流量，以避免流量中断。此替代路由称为回退路由。如果流量未封装在隧道中，请像通常使用 CLI 一样配置回退静态路由。但是，如果流量封装在隧道中，则可以使用 gRIBI 对包含解封装和封装的回退隧道进行编程。

您可以在 VRF 中对回退路由进行编程，以便系统对旧隧道中的流量进行解封装，并将其重新封装在新隧道中，然后再将流量重新路由到下一跃点。此功能支持具有 IPv4 或 IPv6 有效负载的动态 IP-IP 隧道的 IPv4 传输。

要对具有解封装和重新封装功能的回退 IP-in-IP 隧道进行编程，请在消息中 NextHop 设置以下字段：

您可以将流量工程虚拟路由和转发 （VRF） 实例中的默认路由用作备用路由。首先将默认路由添加到 VRF，以便您在 VRF 中配置的将来路由将会将其用作回退路由。要使用此默认路由，请将字段设置为 decapsulate_header 并设置为 network_instance DEFAULT。OPENCONFIGAFTTYPESENCAPSULATION HEADERTYPE_IPV4此默认路由有一个带解封装功能的下一跃点，可在默认 VRF 中查找路由。

您还可以选择备份下一跃点组，以便更轻松地配置回退路由。为此，请在消息中NextHopGroup设置backup_next_hop_group字段。

VRF 实例选择

gRIBI 不支持在非默认 VRF 实例中对路由进行编程。要使用非默认 VRF 实例，请先使用 CLI 配置防火墙过滤器。防火墙过滤器必须与所需的 DSCP 和 IP 协议匹配。将过滤器应用于预期流量所在的接口。

例如，如果流量位于接口 et-0/0/0 上：

基于策略的转发

使用该 PolicyForwardingEntry 消息在 gRIBI 服务器上对基于策略的转发进行编程。基于策略的转发可确保无论路由表显示什么，移动到备用隧道的流量都保留在隧道中。

要设置匹配条件并设计转发流量策略：

  1. 在消息中 Afts 设置以下字段：

  2. 在消息中 AFTOperation 设置以下字段：

  3. 将消息设置为 ModifyRequest 使用上面定义的内容 AFTOperation 。

  4. 使用上述ModifyRequest消息调用 Modify() RPC。

获取路线

当客户端断开与 gRIBI 服务器的连接时，可能不会将停机期间编程的任何路由添加到服务器中。恢复与服务器的连接后，使用 Get() RPC 检查是否将所有路由正确添加到服务器的路由表中。 Get() RPC 还可用于定期检查服务器上安装的路由是否正确并协调任何差异。

Get() RPC 检索服务器上安装的 AFT 的内容。当客户端发送 Get() RPC 请求时，服务器会使用流使用GetResponse当前安装的条目集进行响应。服务器仅使用已确认的条目进行响应。服务器将所有条目发送到客户端后，服务器关闭 RPC。

如果配置了平滑路由引擎切换 （GRES），则 gRIBI 服务器和 rpd 进程也会在 gRIBI 服务器重新启动后恢复路由。客户端重新连接到服务器后，客户端会自动向服务器发送 gRIBI Get() RPC 请求。如果配置了 GRES，客户端将协调服务器上的路由。如果客户端发送另一个 Get() RPC 请求，则流 GetResponse 将包括服务器上的活动协调路由。如果配置了 GRES，但未配置不间断路由，则 gRIBI API 也会在路由引擎切换后恢复路由。

注意：

RPD 进程重新启动时，仅恢复活动路由。

刷新路由

Flush() RPC 将删除与消息中FlushRequest描述的内容匹配的所有服务器 gRIBI 编程路由。发送FlushRequest消息是从服务器中删除 gRIBI 编程路由的一种快速简便的方法。

如果流量工程 VRF 实例中存在路由，请在 Flush() 删除 VRF 实例之前使用 RPC 清除 VRF 实例中的路由。

变更历史表

是否支持某项功能取决于您使用的平台和版本。使用 功能资源管理器 确定您的平台是否支持某个功能。

发布
描述
23.4R1-EVO
不再需要在 [edit routing-options resolution] 层次结构级别配置语句来运行 gRIBI 服务 RPC。