格里比
摘要 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模型的Protocol Buffer翻译版本来描述它可以修改的RIB条目。OpenConfig AFT 模式的 protobuf 表示形式位于 位于 https://github.com/openconfig/gribi/blob/master/v1/proto/gribi_aft/gribi_aft.proto 的原型定义文件中。
gRIBI的好处:
- 在对路由进行编程时发送确认。
- 支持分层查找。
- 当多个客户端连接到 gRIBI 会话时,支持仲裁。
使用命令显示 show route extensive
gRIBI 的路由数据,包括路由使用的客户端 ID 和下一跃点组 ID。
我们建议使用 gRIBI 或 JET RIB Service API,不要同时使用两者,尤其是对于同一组路由。
支持的 RPC
Junos 设备支持 gRIBI 服务 RPC,可从设备的 RIB 远程检索、添加、修改或删除路由。RPC 通过修改或读取设备上的抽象转发表 (AFT) 来发挥作用。
版本中引入 | 的RPC | 定义 |
---|---|---|
Modify() |
在 AFT 中添加、修改或删除条目。 |
Junos OS 19.4R1 版 Junos OS 演化版 20.3R1 |
Get() |
从 AFT 检索已安装的条目。 |
Junos OS 演化版 22.2R1 |
Flush() |
删除与消息中 |
Junos OS 演化版 22.2R1 |
网络设备配置
Junos OS 演化版 23.4R1 及更高版本
在 Junos OS 演化版 23.4R1 之前
修改路由
Modify()
使用 RPC 在 gRIBI 服务器的 RIB 中安装新路由并编辑现有路由。路由将添加为静态路由。
Modify()
是一个双向流式 RPC。客户端发送包含 Modify()
消息的 ModifyRequest
RPC,以修改服务器上的 AFT 条目。对于每一个 ModifyRequest
,gRIBI服务器用一条 ModifyResponse
消息回应客户端。
消息 ModifyRequest
包含一条或多 AFTOperation
条消息。每 AFTOperation
条消息定义一个请求来添加、修改或删除单个 AFT 条目。gRIBI 服务器按照 RPC 流式传输操作的 Modify()
顺序处理 AFT 操作。
Junos 设备支持以下 AFT 条目类型:
IPv4Entry
— 对 IPv4 路由进行编程。NextHopEntry
—对下一跃点进行编程。NextHopGroup
- 对下一跃点组进行编程。
Modify()
使用 RPC 执行以下功能:
- 路由确认
- 对 IPv4 路由进行编程
- 对下一跃点和下一跃点组进行编程
- 使用 MAC 地址编程下一跃点
- 分层查找和 IP-in-IP 隧道
- 多个客户的仲裁
- 在 VRF 实例中编程回退路由
- VRF 实例选择
- 基于策略的转发
路由确认
当您使用 RPC 在 Modify()
数据包转发引擎中成功对路由进行编程时,服务器会发送确认。如果 gRIBI API 未能在给定的超时期限内对数据包转发引擎中的路由进行编程,服务器将发送错误消息。您可以配置此超时的长度。确认仅对最近的路由有效。如果较旧的路由发送确认,但新路由未发送,则数据包转发引擎会将其记录为错误。
Junos 设备支持消息AFTOperation
字段中的entry
以下值:
AFTOperation { EntryAckType { INVALID; FIB_ACK; RIB_ACK; } ack_type; )
Junos 设备不支持该 MAC_ENTRY
选项。
使用 show route extensive
命令显示确认状态。确认状态在 rpd 进程重新启动后持续存在。
对 IPv4 路由进行编程
要对 IPv4 路由进行编程,请使用 IPv4Entry
AFT 条目。AFT 根据目标地址匹配输入数据包,并将其映射到相应的下一跃点。在网络中的默认 VRF 实例以及流量工程 VRF 实例上安装 AFT 条目。要在非默认实例中安装 AFT 条目,请在消息字段中AFTOperation
指定 VRF 实例network_instance
。例如:
- 流量工程 VRF 实例:
g_b4_cos1
- 将该
network_instance
字段设置为:g_b4_cos1
gRIBI 客户端仅在从服务器收到服务器收到关联NextHopGroup
和NextHop
消息的确认后,才对服务器上的 AFT 条目进行编程IPv4Entry
。如果客户端在服务器上对 AFT 条目进行编程IPv4Entry
而不确认NextHopGroup
消息,则会将路由作为隐藏路由添加到服务器。
对下一跃点和下一跃点组进行编程
使用 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,则服务器将安装表中调用 FC01::A
的 inet6.3
路由。
下一跃点组在 inet6.3
表中 FC02::next_hop_id
显示为 。例如,如果下一跃点组 ID 为 100,则服务器将安装表中调用 FC02::64
的 inet6.3
路由。
例如,要通过可直接访问的接口对下一跃点对象进行编程:
-
假设地址 10.0.1.2 可通过接口 et-0/0/7.0 访问,请在消息中
Afts
设置以下字段,其中 = 表示将字段设置为该值:NextHop { ip_address = 10.0.1.2; // Next hop IP address InterfaceRef { interface = "et-0/0/7"; subinterface = 0; } } NextHopKey { index = 1; }
-
按
AFTOperation
如下方式设置消息字段:AFTOperation { Operation { ADD; } entry { next_hop; // NextHopKey object created above } }
- 将
ModifyRequest
消息设置为使用上面定义的消息AFTOperation
。 -
Modify()
使用上述ModifyRequest
消息调用 RPC。 -
要确认路由已成功编程,请使用
show route programmed
CLI 中的命令。
使用 MAC 地址编程下一跃点
或者,您可以使用下一跃点的 MAC 地址(而不是其 IP 地址)来标识下一跃点。在设备无法使用动态地址解析协议 (ARP) 或邻居发现协议 (NDP) 查找下一跃点的 MAC 地址的网络中,此功能非常有用。要使用 MAC 地址,请使用字段而不是 mac_address
ip_address
AFT 消息中的字段。
使用 gRIBI 服务将 MAC 地址编程为接口上的下一跃点后,设备不会对使用此接口的任何流量使用动态 ARP 或 NDP。如果在客户端断开连接时删除或清除编程的 gRIBI 下一跃点,设备会自动在接口上重新启用 ARP,并且路由将继续使用动态 ARP 运行。
例如,要通过可直接访问的接口对具有 MAC 地址的下一跃点对象进行编程:
-
确保要使用下一跃点编程的接口是带编号的接口。
-
确保接口上已启用 IPv6 系列。
-
假设可以通过接口 et-0/0/7.0 访问 MAC 地址 00:00:5E:00:53:00,请在消息中
Afts
设置以下字段,其中 = 表示将字段设置为该值:NextHop { mac_address = 00:00:5E:00:53:00; // Next hop MAC address InterfaceRef { interface = "et-0/0/7"; subinterface = 0; } } NextHopKey { index = 1; }
-
按
AFTOperation
如下方式设置消息字段:AFTOperation { Operation { ADD; } entry { next_hop; // NextHopKey object created above } }
- 将
ModifyRequest
消息设置为使用上面定义的消息AFTOperation
。 -
Modify()
使用上述ModifyRequest
消息调用 RPC。 -
要确认路由已成功编程,请使用
show route programmed
CLI 中的命令。
分层查找和 IP-in-IP 隧道
gRIBI 的 Junos 实现支持分层查找。要配置分层查找,请使用 IPv4 AFT 对 IP-IP 隧道端点和站点组虚拟 IP 地址路由进行编程。
要将入口节点上的流量封装到 IP-in-IP 隧道中,请在消息中 NextHop
设置以下字段:
NextHop { encapsulate_header; IpInIp { dst_ip; // Destination IP address src_ip; // Source IP address } }
多个客户的仲裁
Modify()
当多个客户端连接到 gRIBI 服务器时,RPC 支持仲裁。仲裁确定哪个客户端可以执行哪些操作。
使用该 SessionParameters
消息为 gRIBI 客户端设置持久性模式和客户端冗余模式。所有客户端必须发送消息所有 SessionParameters
属性的相同值。 SessionParameters
在会话的生存期内应只发送一次。
SessionParameters
必须是重新连接后发送的第一条消息。当客户端重新连接时,将启动新会话。如果已连接其他客户端,请将消息值与现有客户端设置的值匹配 SessionParameters
。如果所有客户端重新连接,则可以将 SessionParameters
消息值设置为与上一个会话中使用的值不同的值。
Junos 设备同时支持 PRESERVE
持久性模式和 DELETE
持久性模式。如果持久性模式设置为 PRESERVE
,则即使在客户端断开连接后,服务器也会保留客户端添加的 AFT 条目。如果持久性模式设置为 DELETE
,则服务器会在客户端断开连接时删除 AFT 条目。
我们建议在更改会话参数之前删除所有路由。如果更改会话参数并在其他模式中添加路由后切换SINGLE_PRIMARY
冗余模式ALL_PRIMARY
,则可能会看到意外行为。
当有多个客户端时,必须在两种客户端冗余模式之间进行选择:
所有主模式
在 ALL_PRIMARY
冗余模式下:
-
任何客户端都可以修改路由。
-
多个客户端可以添加相同的 AFT 条目。
-
gRIBI API 维护了哪些客户端添加了路由的映射。
-
第一个添加操作将条目添加到 RIB。来自不同客户端的同一条目的后续添加操作会将客户端添加到引用该条目的客户端列表中。
-
删除操作将从引用该条目的客户端列表中删除客户端。仅当没有客户端引用该条目时,才会删除该条目。
处理时 FlushRequest
,将删除条目,而不进行任何引用计数检查。
使用该 show route extensive
命令查看路由的详细信息。下面是命令在 show route extensive
模式下显示 ALL_PRIMARY
的内容的示例。为清楚起见,输出已缩短。
user@host> show route 10.0.1.1 extensive b4.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 10.0.1.1/32 (1 entry, 1 announced) TSI: [...] Opaque data client: PRPD Address: ABC123 Opaque-data reference count: 2 Opaque data PRPD: client_num_ids=1,5,6 nh group Id=110
单主模式
在 SINGLE_PRIMARY
冗余模式下:
-
gRIBI 客户端可以具有主要(活动)或备份角色。
-
只有主客户端可以执行 AFT 操作。
-
具有最高选择 ID 的客户端是主客户端。所有其他客户机都是备份客户机。
-
当备份客户机成为主客户机时,新的主客户机可以修改先前主客户机添加的路由。
设置每台设备的选择 ID,以确定哪个客户端是主要客户端。您只能在冗余模式下设置选择 ID SINGLE_PRIMARY
。即使客户端处于关闭状态,也会保留选择 ID。如果主客户端断开连接,它将保持为主客户端,直到您将其他设备的选择 ID 设置为更高。设置选择 ID 后,新的主客户端将继续对 gRIBI 条目进行编程。
要更新选举 ID,请在将选举 ID 设置为新值的情况下发送 ModifyRequest
消息。每个客户端必须具有唯一的选举 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
的内容的示例。为清楚起见,输出已缩短。
user@host> show route 10.0.1.1 extensive b4.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 10.0.1.1/32 (1 entry, 1 announced) TSI: [...] Opaque data client: PRPD Address: ABC123 Opaque-data reference count: 2 Opaque data PRPD: group_num_id=1 nh group Id=110
在 VRF 实例中编程回退路由
当通过静态路由无法访问下一跃点时,网络可以通过备用路由重新路由流量以避免流量中断。此备用路由称为回退路由。如果流量未封装在隧道中,请像通常使用 CLI 一样配置回退静态路由。但是,如果流量封装在隧道中,则可以使用 gRIBI 对包含解封装和封装的回退隧道进行编程。
您可以在 VRF 中对回退路由进行编程,以便系统解封装来自旧隧道的流量并将其重新封装到新隧道中,然后再将流量重新路由到下一跃点。此功能支持具有 IPv4 或 IPv6 有效负载的动态 IP-IP 隧道的 IPv4 传输。
要对具有解封装和重新封装功能的回退 IP-in-IP 隧道进行编程,请在消息中 NextHop
设置以下字段:
NextHop { decapsulate_header; encapsulate_header; network_instance; // VRF instance IpInIp { dst_ip; // Destination IP address src_ip; // Source IP address } }
您可以使用流量工程虚拟路由和转发 (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 上:
[edit] user@host# set firewall filter b4-filter term 1 from dscp cs7 user@host# set firewall filter b4-filter term 1 then count b4-count user@host# set firewall filter b4-filter term 1 then routing-instance b4 user@host# set firewall filter b4-filter term 2 then accept user@host# set interfaces et-0/0/0 unit 0 family inet filter input b4-filter
基于策略的转发
使用该 PolicyForwardingEntry
消息对 gRIBI 服务器上基于策略的转发进行编程。基于策略的转发可确保移动到备用隧道的流量保留在隧道中,而不管路由表显示什么。
要设置匹配条件并编程转发流量的策略,请执行以下操作:
-
在消息中
Afts
设置以下字段:PolicyForwardingEntry { ip_prefix; // To match the destination IP address src_ip_prefix; // To match the source IP address next_hop_group; }
-
在消息中
AFTOperation
设置以下字段:AFTOperation { entry { policy_forwarding_entry; // PolicyForwardingEntryKey object created above } }
- 将
ModifyRequest
消息设置为使用上面定义的消息AFTOperation
。 -
Modify()
使用上述ModifyRequest
消息调用 RPC。
获取路由
当客户端失去与 gRIBI 服务器的连接时,停机期间编程的任何路由可能不会添加到服务器。恢复与服务器的连接后,使用 Get()
RPC 检查是否已将所有路由正确添加到服务器的路由表中。RPC Get()
还可用于定期检查服务器上安装的路由是否正确并协调任何差异。
Get()
RPC 检索服务器上安装的 AFT 的内容。当客户端发送 Get()
RPC 请求时,服务器会使用流使用GetResponse
当前安装的条目集进行响应。服务器仅使用已确认的条目进行响应。服务器将所有条目发送到客户端后,服务器将关闭 RPC。
如果配置了平滑路由引擎切换 (GRES),则 gRIBI 服务器和 rpd 进程也会在 gRIBI 服务器重新启动后恢复路由。客户端重新连接到服务器后,客户端会自动向服务器发送 gRIBI Get()
RPC 请求。如果配置了 GRES,客户端将协调服务器上的路由。如果客户端发送另一个 Get()
RPC 请求, GetResponse
则流将包括服务器上的活动协调路由。如果配置了 GRES 但未配置不间断路由,则 gRIBI API 还会在路由引擎切换后恢复路由。
当 rpd 进程重新启动时,仅恢复活动路由。
冲洗路线
RPC 将 Flush()
删除与消息中 FlushRequest
描述的内容匹配的所有服务器的 gRIBI 编程路由。发送 FlushRequest
消息是从服务器中删除 gRIBI 编程路由的一种快速简便的方法。
当流量工程 VRF 实例中存在路由时,请在删除 VRF 实例之前使用 RPC 刷新 Flush()
来自 VRF 实例的路由。