BMP:BGP监控协议

简介: 本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查,并已被互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息,请参见 RFC 7841 的第 2 节

640.gif


RFC7854:BGP Monitoring Protocol (BMP),June 2016


梗概


本文档定义了 BGP 监控协议 (BGP Monitoring Protocol,BMP),可用于监控 BGP 会话。BMP 旨在提供一个方便的接口来获取路由视图。在引入 BMP 之前,屏幕抓取是获取此类视图最常用的方法。设计目标是保持 BMP 简单、有用、易于实现和最小的服务影响。BMP 不适合用作路由协议。


本备忘录的状态


这是一个 Internet 标准跟踪文档。


本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查,并已被互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息,请参见 RFC 7841 的第 2 节。


有关本文档的当前状态、任何勘误以及如何提供反馈的信息,请访问 http://www.rfc-editor.org/info/rfc7854


版权声明


版权所有 (c) 2016 IETF Trust 和确定为文档作者的人员。版权所有。


本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 (http://trustee.ietf.org/license-info) 的约束,在本文档发布之日生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本,并且不提供如简化 BSD 许可中所述的保证。


本文档可能包含来自于 2008 年 11 月 10 日之前发布或公开提供的 IETF 文档或 IETF 贡献的材料。控制本材料某些版权的人可能未授予 IETF 信托允许修改此类材料的权利在 IETF 标准流程之外。如果没有从控制此类材料版权的人那里获得足够的许可,则不得在 IETF 标准流程之外修改本文档,并且不得在 IETF 标准流程之外创建其衍生作品,除非将其格式化为作为 RFC 发布或将其翻译成英语以外的语言。


1、 介绍


许多研究人员和网络运营商希望能够访问路由器的 BGP 路由信息库 (Routing Information Bases,RIB) 的内容以及路由器正在接收的协议更新的视图。这个监控任务无法通过标准的协议机制来实现。在引入 BMP 之前,这些数据只能通过屏幕抓取获得。


BMP 持续提供对对等体方的 Adj-RIB-In 的访问,并提供某些统计数据的定期转储,监控站可将其用于进一步分析。从高层次来看,BMP 可以被认为是将在各种受监控的 BGP 会话上接收到的消息多路复用在一起的结果。


1.1、 需求语言


关键词“必须”、“不得”、“要求”、“应该”、“不应该”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选” " 在本文档中,应按照 RFC 2119 [RFC2119] 中的描述进行解释。


2、 定义


Adj-RIB-In


如 [RFC4271] 中所定义,“Adj-RIBs-In 包含未处理的路由信息,这些信息已由其对等体通告给本地 BGP 发言者。”这在本文档中也称为 pre-policy Adj-RIB-In。


Post-Policy Adj-RIB-In


将入站策略应用于 Adj-RIB-In 的结果,但在应用路由选择以形成 Loc-RIB 之前。


3、 BMP操作概述


3.1、 BMP 消息


以下是BMP提供的消息:


路由监控 (Route Monitoring,RM)


用于提供从对等体方接收到的所有路由的初始转储,以及向监控站发送由对等体方通告和撤销的增量路由的持续机制。


对等体Down通知(Peer Down Notification)


发送的消息表示对等体会话已关闭,并带有指示会话断开原因的信息。


统计报告 (Stats Reports,SR)


持续的统计数据转储,监控站可以将其用作路由器中正在进行的活动的高级指示。


对等体Up通知(Peer Up Notification)


发送的消息表示已建立对等体会话。该消息包括关于在它们的 OPEN 消息中的对等体之间交换的数据的信息,以及关于对等体 TCP 会话本身的信息。除了在对等体方转换到已建立状态时发送之外,当 BMP 会话本身出现时,还会为处于已建立状态的每个对等体方发送对等体方通知。


发起(Initiation)


被监控路由器通知监控站其厂商、软件版本等的一种方式。


终止(Termination)


被监控路由器通知监控站其关闭BMP会话的原因的一种方式。


路由镜像(Route Mirroring)


被监控路由器发送接收到的消息的逐字副本的一种方式。可用于精确镜像受监控的 BGP 会话。还可用于报告格式错误的 BGP 协议数据单元 (Protocol Data Units,PDU)


3.2、 连接建立和终止


BMP 在 TCP 上运行。所有选项都由受监控路由器上的配置控制。没有 BMP 消息从监控站发送到被监控的路由器。被监控的路由器可以采取措施阻止监控站发送数据(例如,通过半关闭 TCP 会话或将其窗口大小设置为 0)或者它可以默默地丢弃监控站发送的任何数据。


路由器可以被一个或多个监控站监控。对于每一对(路由器和监控站),一方在 TCP 会话建立方面是主动的,而另一方是被动的。哪一方主动,哪一方被动,由配置控制。


被动方配置为侦听特定 TCP 端口,而主动方配置为与该端口建立连接。如果主动方无法连接到被动方,它会定期重试连接。重试必须受到某种程度的退避。建议使用默认初始退避 30 秒和最大 720 秒的指数退避。


路由器可以限制它接受连接的 IP 地址集。它应该限制它允许来自给定 IP 地址的同时连接数。这个限制的默认值应该是 1,尽管一个实现可以允许在配置中禁用这个限制。路由器还必须限制可以建立会话的速率。建议的默认设置是每分钟 2 个会话的建立速率。


路由器(或管理站)可以实现检测冗余连接的逻辑,如果双方都配置为活动,则可能会发生这种情况,并且可以选择终止冗余连接。为此目的定义了终止原因代码。


一旦建立连接,路由器就会通过它发送消息。没有初始化或握手阶段,只要连接建立就发送消息。


如果监控站打算结束或重新发起 BMP 处理,它只会断开连接。


3.3、 BMP 会话的生命周期


路由器被配置为与一个或多个监控站对话 BMP。它可以配置为仅发送其 BGP 对等体的子集的监控信息。否则,假定所有 BGP 对等体都受到监控。


当活动方(路由器或管理站,由配置决定)成功打开 TCP 会话(“BMP 会话”)时,BMP 会话开始。一旦会话建立起来,路由器就开始发送 BMP 消息。它必须以发送发起消息开始。随后,它通过 BMP 会话为其处于已建立状态的每个受监控 BGP 对等体发送 Peer Up 消息。随后发送封装在路由监控消息中的 Adj-RIBs-In(前策略、后策略或两者,参见第 5 节)的内容。一旦它发送了给定对等体的所有路由,它必须为该对等体发送一个 End-of-RIB 消息;当 End-of-RIB 已发送给每个受监控的对等体方时,初始表转储已完成。(一旦收集到与每个 Peer Up 消息相对应的 End-of-RIB 或 Peer Down 消息,只想收集表转储的监控站可以关闭连接。)


在初始表转储之后,路由器发送封装在路由监控消息中的增量更新。根据配置,它可以定期发送统计报告甚至新的发起消息。如果任何新的受监控 BGP 对等体建立,则会发送相应的 Peer Up 消息。如果发送 Peer Up 消息的任何 BGP 对等体脱离已建立状态,则发送相应的 Peer Down 消息。


当承载它的 TCP 会话因任何原因关闭时,BMP 会话结束。路由器可以在关闭会话之前发送终止消息。


4、 BMP 报文格式


4.1、 通用报文头


以下公共报文头出现在所有 BMP 消息中。BMP 消息中的其余数据取决于公共头中的消息类型字段。


640.png


Version:版本(1 字节),表示 BMP 版本。对于本规范中定义的所有消息,这都设置为“3”。(本文档的草稿版本使用了“1”和“2”。)版本 0 是保留的,不得发送。


Message Length:消息长度(4 字节),消息的长度,以字节为单位(包括报文头、数据和封装的消息,如果有的话)。


Message Type:消息类型(1 字节),这标识了 BMP 消息的类型。BMP 实现必须在收到时忽略无法识别的消息类型。


* Type = 0:路由监控

* Type = 1:统计报告

* Type = 2:Peer Down 通知

* Type = 3:Peer Up 通知

* Type = 4:发起消息

* Type = 5:终止消息

* Type = 6:路由镜像消息


4.2、 每对等体报文头


对于大多数 BMP 消息,每个对等体报文头遵循公共报文头。BMP 消息中的其余数据取决于公共头中的消息类型字段。


640.png


Peer Type:对等体类型(1字节),标识对等体的类型。目前,确定了三种类型的对等体点:


* Peer Type = 0:全局实例Peer

* Peer Type = 1:RD Instance Peer

* Peer Type = 2:本地实例对等体


Peer Flags(1 字节):这些标志提供有关对等体的更多信息。 标志定义如下:


640.png


* V 标志,表示 Peer 地址是 IPv6 地址。对于 IPv4 对等体点,此值设置为 0。


* L 标志,如果设置为 1,表示该消息反映了 post-policy Adj-RIB-In(即,它的路径属性反映了入站策略的应用)。如果消息反映了 pre-policy Adj-RIB-In,则设置为 0。本地来源的路由也带有 L 标志 1。有关详细信息,请参阅第 5 节。当与路由镜像消息(第 4.7 节)一起使用时,此标志没有意义。


* A 标志,如果设置为 1,表示使用旧的 2 字节 AS_PATH 格式格式化消息。如果设置为 0,则消息使用 4 字节 AS_PATH 格式 [RFC6793] 进行格式化。BMP 说话者可以选择传播从其对等体方接收到的 AS_PATH 信息,或者它可以选择将所有 AS_PATH 信息重新格式化为 4 字节格式,而不管它是如何从对等体方接收到的。在后一种情况下,AS4_PATH 或 AS4_AGGREGATOR 路径属性不应该在 BMP UPDATE 消息中发送。当与路由镜像消息(第 4.7 节)一起使用时,此标志没有意义。


* 其余位保留供将来使用。它们必须作为 0 传输并且它们的值在接收时必须被忽略。


Peer Distinguisher:对等体标识符(8 字节),今天的路由器可以有多个实例(例如:3层虚拟专用网络 (Layer 3 Virtual Private Networks,L3VPN) [RFC4364])。该字段用于区分属于一个地址域的对等体和另一个。


如果对等体方是“全局实例对等体方”,则此字段填零。如果对等体是“RD 实例对等体”,则将其设置为对等体所属的特定实例的路由标识符。如果对等体方是“本地实例对等体方”,则将其设置为唯一的、本地定义的值。在所有情况下,效果是 Peer Type 和 Peer Distinguisher 的组合足以消除其他识别信息可能重叠的对等体点的歧义。


Peer Address:对等体地址,与接收封装 PDU 的 TCP 会话相关联的远程 IP 地址。如果在该字段中携带 IPv4 地址(其中 12 个最高有效字节用零填充),则长度为 4 个字节,如果在该字段中携带 IPv6 地址,则长度为 16 个字节。


Peer AS:收到封装 PDU 的对等体方的自治系统编号。如果在该字段 [RFC6793] 中存储了 16 位 AS 编号,则应在其最高 16 位中填充零。


Peer BGP ID:从其接收封装的 PDU 的对等体的 BGP 标识符。


Timestamp:收到封装路由的时间(也可以认为这是它们安装在 Adj-RIB-In 中的时间),以从(UTC)1970年1月1日午夜(零时)开始的秒和微秒表示。如果为零,则时间不可用。时间戳的精度取决于实现。


4.3、 发起消息


发起消息为被监控路由器提供了一种方法来通知监控站其供应商、软件版本等。发起消息必须作为 TCP 会话出现后的第一条消息发送。如果受监控路由器上的更改保证,则可以在此后的任何时候发送发起消息。


发起消息由公共 BMP 报文头组成,后跟两个或多个信息 TLV(第 4.4 节),其中包含有关受监控路由器的信息。必须发送 sysDescr 和 sysName 信息 TLV,其他任何 TLV 都是可选的。字符串 TLV 可以被包含多次。


4.4、 信息TLV


Initiation(第 4.3 节)和 Peer Up(第 4.10 节)消息使用信息 TLV。


640.png


** Information Type:信息类型(2字节),提供的信息类型。定义的类型是:


* Type = 0:字符串。信息字段包含一个自由格式的 UTF-8 字符串,其长度由信息长度字段给出。该值是通过管理方式分配的。不需要用空(或任何其他特定)字符来终止字符串——信息长度字段给出了它的终止。如果包含多个字符串,则在报告它们时必须保留它们的顺序。


* Type = 1: sysDescr。信息字段包含一个 ASCII 字符串,其值必须设置为等于 sysDescr MIB-II [RFC1213] 对象的值。


* Type = 2:系统名称。信息字段包含一个 ASCII 字符串,其值必须设置为等于 sysName MIB-II [RFC1213] 对象的值。


** Information Length:信息长度(2 字节),以下信息字段的长度,以字节为单位。


** Information:信息(变量),有关受监控路由器的信息,根据类型。


4.5、 终止消息


终止消息为受监控的路由器提供了一种方式来指示它终止会话的原因。尽管建议使用此消息,但监控站必须始终为会话终止而没有消息做好准备。一旦路由器发送了一个终止消息,它必须关闭 TCP 会话而不发送任何进一步的消息。同样,监测站必须在收到终止消息后关闭 TCP 会话。


终止消息由公共 BMP 报文头和一个或多个包含终止原因信息的 TLV 组成,如下所示:


640.png


** Information Type:信息类型(2字节),提供的信息类型。定义的类型是:


* Type = 0:字符串。信息字段包含一个自由格式的 UTF-8 字符串,其长度由信息长度字段给出。包含此 TLV 是可选的。它可以用于为任何定义的原因提供进一步的细节。消息中可以包含多个字符串 TLV。


* Type = 1:原因。信息字段包含一个 2 字节的代码,指示连接终止的原因。某些原因可能有更多的 TLV 与之相关。需要包含此 TLV。明确的原因是:

+ 原因 = 0:会话管理性关闭。会话可能会重新发起。
+ 原因 = 1:未指定原因。
+ 原因 = 2:资源不足。路由器已耗尽可用于 BMP 会话的资源。
+ 原因 = 3:冗余连接。路由器已确定此连接与另一个连接是冗余的。
+ 原因 = 4:会话在管理上永久关闭,不会重新发起。监控站应降低(可能为 0)尝试重新连接到受监控路由器的速率。


** Information Length:信息长度(2 字节),以下信息字段的长度,以字节为单位。


** Information:信息(变量),有关受监控路由器的信息,根据类型。


4.6、 路由监控


路由监控消息用于 ADJ-RIBs-In 的初始同步。它们还用于持续监控 ADJ-RIB-In 状态。路由监控消息是状态压缩的。这在第 5 节中有更详细的讨论。


在公共 BMP 报文头和每个对等体报文头之后是 BGP 更新 PDU。


4.7、 路由镜像


路由镜像消息用于逐字复制收到的消息。镜像的一种可能用途是对一个或多个受监控的 BGP 会话进行精确镜像,无需状态压缩。另一个可能的用途是镜像已被视为撤销的消息 [RFC7606],用于调试目的。镜像消息可以被采样,或者可以是无损的。提供消息丢失信息代码以允许指示丢失。第 6 节提供了更多详细信息。


在公共 BMP 报文头和每个对等体报文头之后是一组 TLV,其中包含有关一条消息或一组消息的信息。每个 TLV 包括一个 2 字节类型代码、一个 2 字节长度字段和一个可变长度值。包含任何给定的 TLV 是可选的;但是,至少应该包含一个 TLV,否则发送消息就没有意义了。定义的 TLV 如下:


** Type = 0:BGP 消息。一个 BGP PDU。这个 PDU 可能是也可能不是更新消息。如果 BGP 消息 TLV 出现在路由镜像消息中,它必须出现在 TLV 列表的最后。


** Type = 1:信息。提供有关镜像消息或消息流的信息的 2 字节代码。定义的代码是:

* Code = 0:错误的 PDU。发现包含的消息有一些错误,使其无法使用,导致它被视为撤销 [RFC7606]。BGP 消息 TLV 也必须出现在 TLV 列表中。
* Code = 1:消息丢失。一条或多条消息可能已丢失。这可能发生,例如,如果一个实现用完可用的缓冲区空间来排队镜像消息。


可以在发送路由监控消息合法的任何时候发送路由镜像消息。


4.8、 统计报告


这些消息包含监控站可以用来观察路由器上发生的有趣事件的信息。


SR 消息的传输可以是定时器触发的或事件驱动的(例如,当发生重大事件或达到阈值时)。本规范没有对这些报告必须在何时以及在什么事件上传输施加任何时间限制。由实现来确定传输定时——但是,应该提供定时器和/或阈值的配置控制。本文档仅规定了SR消息的形式和内容。


在公共 BMP 报文头和 per-peer 报文头之后是一个 4 字节的字段,它指示 stats 消息中的计数器数量,其中每个计数器都编码为 TLV。


640.png


每个计数器的编码如下:


640.png


**Stat Type(2字节):定义Stat Data字段携带的统计类型。


**Stat Len(2字节):定义 Stat Data 字段的长度。


该规范定义了以下统计信息。BMP 实现必须在接收时忽略无法识别的统计类型,同样必须忽略统计数据字段中的意外数据。

Stats 是计数器或仪表,分别在 [RFC1155] 的第 3.2.3.3 节和 [RFC2856] 的第 4 节中的示例之后定义如下:


32 位计数器:一个非负整数,单调递增直到达到最大值,当它环绕并从 0 开始再次递增时。它的最大值为 2^32-1(十进制为 4294967295)。


64 位仪表:一个非负整数,可以增加或减少,但不得超过最大值,也不得低于最小值。最大值不能大于 2^64-1(18446744073709551615 十进制),最小值不能小于 0。当被建模的信息大于或等于其最大值时,该值具有最大值,并且有当被建模的信息小于或等于其最小值时,它的最小值。如果建模的信息随后减少到最大值以下(或增加到最小值以上),则 64 位 Gauge 也会减少(或增加)。


Stat Type = 0:(32 位计数器)入站策略拒绝的前缀数。
Stat Type = 1:(32 位计数器)(已知)重复前缀通告的数量。
Stat Type = 2:(32 位计数器)(已知)重复撤销的数量。
Stat Type = 3:(32 位计数器)由于 CLUSTER_LIST 循环而无效的更新数。
Stat Type = 4:(32 位计数器)由于 AS_PATH 循环而无效的更新数。
Stat Type = 5:(32 位计数器)由于 ORIGINATOR_ID 而失效的更新数量。
Stat Type = 6:(32 位计数器)由于 AS_CONFED 循环而无效的更新数。
Stat Type = 7: (64-bit Gauge) Adj-RIBs-In 中的路由数量。
Stat Type = 8: (64-bit Gauge) Loc-RIB 中的路由数量。
Stat Type = 9:per-AFI/SAFI Adj-RIB-In 中的路由数量。该值的结构为:2 字节地址族标识符 (AFI)、1 字节后续地址族标识符 (SAFI),后跟 64 位仪表。
Stat Type = 10:per-AFI/SAFI Loc-RIB 中的路由数量。该值的结构为:2 字节 AFI、1 字节 SAFI,后跟 64 位 Gauge。
Stat Type = 11: (32-bit Counter) 接受视为撤销处理的更新数量 [RFC7606]。
Stat Type = 12: (32-bit Counter) 接受视为撤销处理的前缀数 [RFC7606]。
Stat Type = 13:(32 位计数器)收到的重复更新消息的数量。


尽管当前规范仅将 4 字节计数器和 8 字节仪表指定为“统计数据”,但这并不排除未来版本合并更复杂的 TLV 类型“统计数据”(例如,可以携带特定前缀数据的数据)。SR 消息是可选的。但是,如果发送 SR 消息,则必须在其中携带至少一个统计信息。


4.9、 对等体Down通知


此消息用于指示对等体会话已终止。


640.png


原因指示会话关闭的原因。定义的值是:


**原因1:本地系统关闭会话。跟在 Reason 之后的是一个 BGP PDU,其中包含一个 BGP NOTIFICATION 消息,该消息将被发送到对等体。


**原因2:本地系统关闭会话。没有发送通知消息。原因代码之后是一个 2 字节的字段,其中包含与导致系统关闭会话的有限状态机 (Finite State Machine,FSM) 事件对应的代码(参见 [RFC4271] 的第 8.1 节)。两个都设置为 0 的字节用于表示没有定义相关的事件代码。


**原因3:远程系统通过通知消息关闭会话。Reason 之后是一个 BGP PDU,其中包含从对等体接收到的 BGP NOTIFICATION 消息。


**原因4:远程系统在没有通知消息的情况下关闭了会话。这包括传输会话的任何意外终止,因此在某些情况下本地和远程系统都可能认为这适用。


**原因5:由于配置原因,此peer的信息将不再发送到监控站。严格来说,这并不表示对等体方已关闭,但确实表示监控站将不会收到对等体方的更新。


Peer Down 消息隐式撤消与相关对等体相关联的所有路由。BMP 实现可以省略为此类路由发送显式撤销。


4.10、 对等体通知


Peer Up 消息用于指示对等体会话已出现(即已转换为已建立状态)。在通用 BMP 报文头和 per-peer 报文头之后是以下内容:


640.png


** Local Address:本地地址,与对等体 TCP 会话关联的本地 IP 地址。如果此字段中携带 IPv4 地址,则长度为 4 个字节,这由 V 标志(其中 12 个最高有效字节填充零)确定,如果此字段中携带 IPv6 地址,则长度为 16 个字节。


** Local Port:本地端口,与对等体 TCP 会话关联的本地端口号,如果实际上不存在 TCP 会话,则为 0(请参阅第 8.2 节)。


** Remote Port:远程端口,与对等体 TCP 会话关联的远程端口号,如果实际上不存在 TCP 会话,则为 0(参见第 8.2 节)。(远程地址可以在固定头的 Peer Address 字段中找到。)


**Sent OPEN Message:受监控路由器向其对等体传输的完整 OPEN 消息。


**Received OPEN Message:受监控路由器从其对等体接收的完整 OPEN 消息。


** Information:信息,有关对等体的信息,使用信息 TLV(第 4.4 节)格式。在这个上下文中只定义了字符串类型;它可能会重复。包括信息字段是可选的。它的存在或不存在可以通过检查公共头中的消息长度来推断。


5、 路由监控


在 BMP 的正常操作模式下,在 BMP 会话建立后,路由监控消息用于提供每个被监控对等体的 Adj-RIB-In 的快照。这是通过使用标准 BGP 更新消息发送存储在这些对等体方的 Adj-RIB-In 中的所有路由来完成的,这些路由封装在路由监控消息中。对等体转储中的消息顺序没有要求。当给定对等体的初始转储完成时,必须通过发送该对等体的 End-of-RIB 标记来指示(如 [RFC4724] 的第 2 节中所指定,加上 BMP 封装头)。另见第 9 节。


BMP 发言者可以发送策略前路由、策略后路由或两者。选择可能是由于实施限制(例如,BGP 实施可能不存储已被策略过滤掉的路由)。Pre-policy 路由必须在 BMP 头中清除它们的 L 标志(见第 4 节),post-policy 路由必须设置它们的 L 标志。当一个实现选择发送策略前和策略后路由时,它有效地将两个更新流复用到 BMP 会话上。这些流通过它们的 L 标志来区分。


如果实现能够提供有关何时收到路由的信息,它可以在 BMP 时间戳字段中提供此类信息。否则,BMP 时间戳字段必须设置为 0,表示时间不可用。


持续监控是通过在 BGP 更新 PDU 中传播路由更改并将这些 PDU 转发到监控站来完成的,再次使用 RM 消息。当路由发生变化时,例如属性发生变化,路由器必须用新的属性更新监控站。如上所述,它可以生成一个清除 L 标志并设置它的更新,或两个更新,一个清除 L 标志,另一个设置 L 标志。当一个路由被peer撤销时,相应的撤销被发送到监控站。撤销必须将其 L 标志设置为对应于任何先前公告的标志;如果有问题的路由先前被通知并同时清除并设置了 L 标志,则撤销必须类似地发送两次,同时清除并设置 L 标志。在可行的情况下,多个更改的路由可以分组为单个 BGP UPDATE PDU,与标准 BGP 协议完全相同。


需要注意的是,RM 消息不是从对等体接收到的复制消息。 (如果需要,则提供路由镜像(第 6 节)。)虽然路由器应尝试迅速生成更新,但在接收更新、生成 RM 消息和将其传输到监测站。如果该前缀的临时状态发生变化,则路由器生成该前缀的最终状态给监控站是可以接受的。这有时被称为“状态压缩”。生成并传输到站点的实际 PDU 也可能与从对等体接收的确切 PDU 不同,例如,由于不同实现格式路径属性之间的差异。


6、 路由镜像


提供路由镜像消息有两个主要原因:首先,使实现能够在一种模式下运行,在这种模式下,它提供从其对等体接收到的所有消息的全保真视图,没有状态压缩。正如我们在第 5 节中提到的,BMP 的正常操作模式无法提供这一点。实施者被强烈警告,如果没有状态压缩,实施可能需要无限存储来缓冲排队等待镜像的消息。路由镜像不太可能适合在传统路由器中实施,除非实施者仔细考虑了权衡,否则不推荐使用它。这些权衡包括:路由器资源耗尽、可能干扰 BGP UPDATE 消息的传输或接收,以及路由收敛速度变慢。


路由镜像的第二个应用是错误报告和诊断。当使用 BGP UPDATE 消息的修订错误处理 [RFC7606] 时,路由器可以处理确定包含错误的 BGP 消息,而无需重置 BGP 会话。此类消息可以被镜像。用于这种镜像的缓冲应该是有限的。如果由于缓冲区耗尽而无法镜像错误消息,则应发送带有“消息丢失”代码的消息来指示这一点。(这意味着应为此用途保留缓冲区。)


7、 统计报告


如上所述,SR 消息用于监视受监视路由器上的特定事件和计数器。一种类型的监控可能是查明在被监控路由器上是否有过多的路由通告和撤销发生(流失)。另一个指标是评估路由器上循环 AS_PATH 的数量。


虽然本文档一开始提出了一小部分计数器,但作者设想这个列表将来可能会随着需要 BMP 式监控的新应用程序而增长。


8、 其他注意事项


8.1、 多个实例


一些路由器可能支持 BGP 协议的多个实例,例如,作为“逻辑路由器”或通过一些其他设施。BMP 协议与 BGP 的单个实例相关;因此,如果路由器支持多个 BGP 实例,它也应该支持多个 BMP 实例(每个 BGP 实例一个)。不同的 BMP 实例应该生成彼此不同的发起消息,例如,通过使用可区分的 sysNames 或通过在字符串 TLV 中包含实例标识信息。


8.2、 本地路线


对于由本地路由器发起到 BGP 的路由,无论是由于来自另一个协议的重新分配还是出于某些其他原因,都需要进行一些考虑。


这样的路由可以被建模为由路由器发送给它自己,将路由器自己的地址放在报头的 Peer Address 字段中。建议这样做时,路由器应使用与 BMP 会话的本地地址相同的地址。由于在这种情况下实际上不存在传输会话,Peer Up 消息的本地和远程端口字段必须设置为 0。显然,Peer Up 消息的 OPEN 消息字段将同样没有被物理传输,但应该代表本地路由器的相关能力。


此外,回想一下 L 标志用于指示本地来源的路由,请参阅第 4.2 节。


9、 使用 BMP


一旦建立了 BMP 会话,路由监控就开始同时转储当前快照和增量更改。


让这些操作同时发生是可以的。如果初始转储访问路由并且随后接收到撤消,则这将被转发到监控站,监控站必须关联并反映在其内部状态中该路由的删除。无论如何,这是监测站需要支持的操作。


如果路由器甚至在对等体转储过程访问该前缀之前就收到了对前缀的撤销,则路由器将从其内部状态中清除该路由,并且不会将其转发到监控站。在这种情况下,监控站可能会收到虚假撤销,它可以安全地忽略。


10、 IANA 考虑


IANA 为以下 BMP 参数创建了注册表,这些参数被组织在一个新组“BGP 监控协议 (BMP) 参数”中。


10.1、 BMP 消息类型


本文档定义了用于在协作系统之间传输 BGP 消息的七种消息类型(第 4 节):


类型 0:路由监控
类型 1:统计报告
类型 2:Peer Down 通知
类型 3:Peer Up 通知
类型 4:发起
类型 5:终止
类型 6:路由镜像


类型值 0 到 127 必须使用“标准操作”策略分配,值 128 到 250 使用 [RFC5226] 中定义的“规范要求”策略分配。值 251 到 254 是实验性的,值 255 是保留的。


10.2、 BMP 对等体类型


为了解释 Peer Distinguisher 字段(第 4.2 节),本文档定义了三种类型的对等体点:

对等体类型 = 0:全局实例对等体
对等体类型 = 1:RD 实例对等体
对等体类型 = 2:本地实例对等体


Peer Type 值 0 到 127 必须使用“Standards Action”策略分配,值 128 到 250 使用“Specification Required”策略分配,在 [RFC5226] 中定义。值 251 到 254 是实验性的,值 255 是保留的。


10.3、 BMP 对等体标志


本文档在每个对等体头(第 4.2 节)的对等体标志字段中定义了三个位标志。这些位从 0(高位或最左边的位)到 7(低位或最右边的位)编号:

标志 0:V 标志
标志 1:L 标志
标志 2:一个标志


标志 3 到 7 未分配。注册处的注册程序是“标准操作”。


10.4、 BMP 统计类型


本文档为统计报告定义了 14 种统计类型(第 4.8 节):


Stat Type = 0:入站策略拒绝的前缀数
Stat Type = 1:(已知)重复前缀通告的数量
Stat Type = 2:(已知)重复撤销的数量
Stat Type = 3:由于 CLUSTER_LIST 循环而失效的更新次数
Stat Type = 4:由于 AS_PATH 循环而失效的更新次数
Stat Type = 5:由于 ORIGINATOR_ID 而失效的更新次数
Stat Type = 6:由于在 AS_CONFED_SEQUENCE 或 AS_CONFED_SET 中发现循环而失效的更新次数
Stat Type = 7:Adj-RIBs-In 中的路由数
Stat Type = 8:Loc-RIB 中的路由数量
Stat Type = 9:per-AFI/SAFI Adj-RIB-In 中的路由数量
Stat Type = 10:per-AFI/SAFI Loc-RIB 中的路由数量
Stat Type = 11:被视为撤销的更新数量
Stat Type = 12:被视为撤销的前缀数
Stat Type = 13:收到的重复更新消息的数量


Stat Type 值 0 到 32767 必须使用“Standards Action”策略分配,值 32768 到 65530 使用“Specification Required”策略分配,在 [RFC5226] 中定义。值 65531 到 65534 是实验性的,值 65535 是保留的。


10.5、 BMP 发起消息 TLV


本文档定义了 Initiation 消息(第 4.3 节)中携带的三种信息类型:

类型 = 0:字符串
类型 = 1:sysDescr
类型 = 2:系统名称


信息类型值 0 到 32767 必须使用“标准操作”策略分配,值 32768 到 65530 使用“规范要求”策略分配,定义在 [RFC5226] 中。值 65531 到 65534 是实验性的,值 65535 是保留的。


10.6、 BMP 终止消息 TLV


本文档为 Termination 消息(第 4.5 节)中携带的信息定义了两种类型:

类型 = 0:字符串
类型 = 1:原因


信息类型值 0 到 32767 必须使用“标准操作”策略分配,值 32768 到 65530 使用“规范要求”策略分配,定义在 [RFC5226] 中。值 65531 到 65534 是实验性的,值 65535 是保留的。


10.7、 BMP 终止消息原因代码


本文档定义了 Termination 消息(第 4.5 节)Reason code 中携带的信息的五种类型:

类型 = 0:管理关闭
类型 = 1:未指定原因
类型 = 2:资源不足
类型 = 3:冗余连接
类型 = 4:永久管理关闭


信息类型值 0 到 32767 必须使用“标准操作”策略分配,值 32768 到 65530 使用“规范要求”策略分配,定义在 [RFC5226] 中。值 65531 到 65534 是实验性的,值 65535 是保留的。


10.8、 BMP 对等体Down原因代码


本文档定义了 Peer Down Notification(第 4.9 节)原因代码中携带的信息的五种类型(并保留了另一种类型):

Type = 0 是保留的。
Type = 1:本地系统关闭,通知 PDU 跟随
Type = 2:本地系统关闭,FSM 事件跟随
Type = 3:远程系统关闭,通知 PDU 跟随
Type = 4:远程系统关闭,无数据
Type = 5:对等体方解除配置


信息类型值 0 到 32767 必须使用“标准操作”策略分配,值 32768 到 65530 使用“规范要求”策略分配,定义在 [RFC5226] 中。值 65531 到 65534 是实验性的,值 0 和 65535 是保留的。


10.9、 路由镜像 TLV


本文档为路由镜像消息(4.7 节)中携带的信息定义了两种类型:


类型 = 0:BGP 消息
类型 = 1:信息


信息类型值 0 到 32767 必须使用“标准操作”策略分配,值 32768 到 65530 使用“规范要求”策略分配,定义在 [RFC5226] 中。值 65531 到 65534 是实验性的,值 65535 是保留的。


10.10、 BMP路由镜像信息代码


本文档定义了路由镜像信息(4.7 节)代码中携带的两种信息类型:

类型 = 0:错误的 PDU
类型 = 1:消息丢失


信息类型值 0 到 32767 必须使用“标准操作”策略分配,值 32768 到 65530 使用“规范要求”策略分配,定义在 [RFC5226] 中。值 65531 到 65534 是实验性的,值 65535 是保留的。


11、 安全考虑


本文档定义了一种获取完整转储或提供对 BGP 发言者的 BGP 路由(包括接收到的 BGP 消息)的持续监控的机制。这种能力可以允许外部方获得否则无法获得的信息。例如,尽管很难将公共 Internet 中 BGP 路由的内容视为机密,但 BGP 也用于私有上下文,例如,用于 L3VPN [RFC4364]。作为另一个例子,聪明的攻击者可能能够通过比较 BMP 公开的前策略路由和 BGP 中导出的后策略路由来推断被监控路由器的导入策略的内容。


该协议的实现应该需要被监控和监控设备的手动配置。


除非使用提供相互身份验证的传输,否则攻击者可以伪装成被监控的路由器并欺骗监控站接受虚假信息,或者他们可以伪装成监控站并获得对 BMP 数据的未授权访问。除非使用提供机密性的传输,否则被动或主动攻击者可以访问或篡改传输中的 BMP 数据。


当上述安全考虑是一个问题时,该协议的用户应该在隧道模式下使用 IPsec [RFC4303] 和预共享密钥。


12、 参考文献


12.1、 规范参考

[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, <http://www.rfc-editor.org/info/rfc1213>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, <http://www.rfc-editor.org/info/rfc4724>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>.


12.2、 参考资料

[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990, <http://www.rfc-editor.org/info/rfc1155>.
[RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, DOI 10.17487/RFC2856, June 2000, <http://www.rfc-editor.org/info/rfc2856>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.


致谢


感谢 Ebben Aries、Michael Axelrod、Serpil Bayraktar、Tim Evens、Pierre Francois、Jeffrey Haas、John Ioannidis、John Kemp、Mack McBride、Danny McPherson、David Meyer、Dimitri Papadimitriou、Tom Petch、Robert Raszuk、Erik Romijn、Peter Schoenmaker, GROW 工作组成员的意见。

相关实践学习
部署Stable Diffusion玩转AI绘画(GPU云服务器)
本实验通过在ECS上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。
相关文章
|
4月前
|
网络协议 安全 网络性能优化
|
30天前
|
网络性能优化 网络虚拟化 数据中心
|
4月前
|
负载均衡 安全 网络虚拟化
NewH3C—链路聚合、DHCP协议
NewH3C—链路聚合、DHCP协议
NewH3C—链路聚合、DHCP协议
|
4月前
|
监控 网络协议 算法
|
域名解析 存储 缓存
DNS协议、ICMP协议、NAT技术(一)
DNS协议、ICMP协议、NAT技术
231 0
|
负载均衡 网络协议 安全
DNS协议、ICMP协议、NAT技术(二)
DNS协议、ICMP协议、NAT技术
235 0
|
网络协议 中间件 Linux
SOME/IP概述2【SOME/IP的主要中间件功能+SOME/IP报文PDU的封装】
SOME/IP概述2【SOME/IP的主要中间件功能+SOME/IP报文PDU的封装】
SOME/IP概述2【SOME/IP的主要中间件功能+SOME/IP报文PDU的封装】
|
运维 监控 网络协议
动态主机配置协议DHCP协议
动态主机配置协议DHCP协议
137 0
|
网络协议 算法 网络架构
【计算机网络】网络层 : BGP 协议 ( BGP 协议简介 | BGP 协议信息交换 | BGP 协议报文格式 | BGP-4 常用报文 | RIP 、OSPF、BGP 协议对比 )
【计算机网络】网络层 : BGP 协议 ( BGP 协议简介 | BGP 协议信息交换 | BGP 协议报文格式 | BGP-4 常用报文 | RIP 、OSPF、BGP 协议对比 )
548 0
【计算机网络】网络层 : BGP 协议 ( BGP 协议简介 | BGP 协议信息交换 | BGP 协议报文格式 | BGP-4 常用报文 | RIP 、OSPF、BGP 协议对比 )
|
网络协议 算法 数据库
【计算机网络】网络层 : OSPF 协议 ( 协议简介 | 链路状态路由算法 | OSPF 区域 | OSPF 特点 )
【计算机网络】网络层 : OSPF 协议 ( 协议简介 | 链路状态路由算法 | OSPF 区域 | OSPF 特点 )
465 0
【计算机网络】网络层 : OSPF 协议 ( 协议简介 | 链路状态路由算法 | OSPF 区域 | OSPF 特点 )