Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

了解长寿命 BGP 平滑重启能力

 

Junos OS 支持从失败的 BGP 对等体中保留 BGP 路由详细信息的机制,而不是使用 BGP 平滑重新启动功能维护此类路由信息的持续时间。

从历史上看,路由协议和 BGP 的设计重点在于正确性,在这种情况下,"正确性" 的重要方面是每个网络元素的转发状态都是以快速方式融合到网络的当前状态。可能性. 出于此原因,该协议旨在删除由路由器(从 BGP 角度)发出的、尽可能及时地公布的状态。借助在 RFC 4724 中定义 BGP 平滑重新启动,快速融合功能已被尝试从网络中快速删除 "陈旧" 状态。

在一段时间内,两个共同的因素导致了这种快速移除陈旧状态的方法以进行修改和增强。第一种是通道转发基础架构的广泛采用,例如 MPLS。此类基础架构消除了某些类型的转发循环可能会在跳转式转发中产生的风险,因此减少了转发元素之间的强大一致性的动机之一。第二个是将 BGP 不断增加,因为数据传输与原始情况相比不是数据包转发的紧密关联。示例包括使用 BGP 实现自动发现(VPLS [RFC4761])和过滤器编程(FLOWSPEC [RFC5575])。在这些情况下,BGP 数据所采用的特征不符合传统路由。

在 BGP 控制平面因某种原因而失败时,为网络运营商提供选择将 BGP 数据保留较长时间的能力非常重要。尽管 BGP 平滑重新启动的属性与此所需的要求保持较长时间的 BGP 信息,但存在多个差距,最多可保留—"过时" 信息的最长持续时间重新启动施加了4095秒的上限限制。Junos OS 支持一种称为长寿命持续重新启动功能的 BGP 功能,使陈旧信息可在会话重置期间保留较长时间。它还支持新 BGP 社区 "LLGR_STALE" 来标记此类信息。此类过时信息将被视为最不可取的广告,并且其通告限制在支持新功能的 BGP 扬声器。

BGP 长寿命重新启动(LLGR)允许网络运营商选择维护失败的 BGP 对等体中的陈旧路由信息,比现有 BGP 平滑重启设施长得多。用于维护较长时间内的 BGP 路由的此功能符合 IETF 草案, 支持长寿命 BGP 平滑重启—uttaro-idr-BGP-持久化-03. 根据此草案,必须按 NLRI 明确配置长寿命持续重新启动(LLGR),并包括将陈旧信息传播到不识别和验证 LLGR 的其他对等方的规定。LLGR 导致以下优势和操作:

  • 来自故障节点的路由将保留在配置的时间段(按天数顺序)。

  • 您可使用相应的 show 命令检查每 NLRI LLGR 协商状态。

  • 您可以查看 LLGR 当前是否对对等方有效,如果有效,将在此期间到期。

  • LLGR 保留的陈旧路由在show bgp neighbor命令输出中显式标记。

  • 从其他邻居获知的陈旧路由在show bgp neighbor命令输出中显式标记(使用明确定义的社区)。

尽管 LLGR 方法可应用于多种不同的情景,但一个特定情景是此功能的一个重要目标。在发生路由反射器和客户端之间的连接中断的情况下,包括可能导致连接在整个筋传输之前重置的间歇连接,这样的故障不会导致重新启动。此外,此类现象并不意味着客户端与路由反射器公布的下一跃点之间存在任何连接问题。预计典型的长时间中断重新启动时间的顺序为12小时。

IETF 草案中介绍的所有行为准则和操作点 draft-uttaro-idr-bgp-persistence-03,支持 LLGR。此外,还支持向后兼容低于版本15.1 的版本中的现有 Junos OS 功能,特别是平滑重新启动和不间断路由(NSR)。配置 LLGR 时,平滑重新启动将以现有方式运行,除非在 Internet 草稿中明确说明。您也可以同时配置 LLGR 和 NSR,并实现完整的 LLGR 功能。作为 LLGR 的先决条件,支持 IETF 草案 BGP 平滑重新启动—的通知消息支持草稿-ietf-idr-BGP-gr-01执行。此草案扩展了普通 GR 的行为,使其能够抵御通信中断和协议错误。