Internet Engineering Task Force (IETF)                  P. Francois, Ed.
Request for Comments: 8326                        Individual Contributor
Category: Standards Track                               B. Decraene, Ed.
ISSN: 2070-1721                                                   Orange
                                                              C. Pelsser
                                                   Strasbourg University
                                                                K. Patel
                                                            Arrcus, Inc.
                                                             C. Filsfils
                                                           Cisco Systems
                                                              March 2018
        
Internet Engineering Task Force (IETF)                  P. Francois, Ed.
Request for Comments: 8326                        Individual Contributor
Category: Standards Track                               B. Decraene, Ed.
ISSN: 2070-1721                                                   Orange
                                                              C. Pelsser
                                                   Strasbourg University
                                                                K. Patel
                                                            Arrcus, Inc.
                                                             C. Filsfils
                                                           Cisco Systems
                                                              March 2018
        

Graceful BGP Session Shutdown

正常BGP会话关闭

Abstract

摘要

This document standardizes a new well-known BGP community, GRACEFUL_SHUTDOWN, to signal the graceful shutdown of paths. This document also describes operational procedures that use this well-known community to reduce the amount of traffic lost when BGP peering sessions are about to be shut down deliberately, e.g., for planned maintenance.

本文档标准化了一个新的著名BGP社区,即优雅的关闭,以表示路径的优雅关闭。本文档还描述了在有意关闭BGP对等会话(例如,为了进行计划维护)时,使用此知名社区减少通信量损失的操作程序。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

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

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8326.

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

Copyright Notice

版权公告

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2018 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Packet Loss upon Manual EBGP Session Shutdown . . . . . . . .   4
   4.  Procedure for EBGP Graceful Shutdown  . . . . . . . . . . . .   4
     4.1.  Pre-configuration . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Operations at Maintenance Time  . . . . . . . . . . . . .   5
     4.3.  BGP Implementation Support for Graceful Shutdown  . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Alternative Techniques with Limited Applicability  .   8
     A.1.  Multi-Exit Discriminator Tweaking . . . . . . . . . . . .   8
     A.2.  IGP Distance Poisoning  . . . . . . . . . . . . . . . . .   8
   Appendix B.  Configuration Examples . . . . . . . . . . . . . . .   8
     B.1.  Cisco IOS XR  . . . . . . . . . . . . . . . . . . . . . .   9
     B.2.  BIRD  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     B.3.  OpenBGPD  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Appendix C.  Beyond EBGP Graceful Shutdown  . . . . . . . . . . .  10
     C.1.  IBGP Graceful Shutdown  . . . . . . . . . . . . . . . . .  10
     C.2.  EBGP Session Establishment  . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12
        
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Packet Loss upon Manual EBGP Session Shutdown . . . . . . . .   4
   4.  Procedure for EBGP Graceful Shutdown  . . . . . . . . . . . .   4
     4.1.  Pre-configuration . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Operations at Maintenance Time  . . . . . . . . . . . . .   5
     4.3.  BGP Implementation Support for Graceful Shutdown  . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Alternative Techniques with Limited Applicability  .   8
     A.1.  Multi-Exit Discriminator Tweaking . . . . . . . . . . . .   8
     A.2.  IGP Distance Poisoning  . . . . . . . . . . . . . . . . .   8
   Appendix B.  Configuration Examples . . . . . . . . . . . . . . .   8
     B.1.  Cisco IOS XR  . . . . . . . . . . . . . . . . . . . . . .   9
     B.2.  BIRD  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     B.3.  OpenBGPD  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Appendix C.  Beyond EBGP Graceful Shutdown  . . . . . . . . . . .  10
     C.1.  IBGP Graceful Shutdown  . . . . . . . . . . . . . . . . .  10
     C.2.  EBGP Session Establishment  . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12
        
1. Introduction
1. 介绍

Routing changes in BGP can be caused by planned maintenance operations. This document defines a well-known community [RFC1997], called GRACEFUL_SHUTDOWN, for the purpose of reducing the management overhead of gracefully shutting down BGP sessions. The well-known community allows implementers to provide an automated graceful shutdown mechanism that does not require any router reconfiguration at maintenance time.

BGP中的路由更改可能由计划的维护操作引起。本文档定义了一个著名的社区[RFC1997],称为“优雅关闭”,目的是减少优雅关闭BGP会话的管理开销。众所周知的社区允许实现者提供一种自动、优雅的关闭机制,在维护时不需要任何路由器重新配置。

This document discusses operational procedures to be applied in order to reduce or eliminate loss of packets during a maintenance operation. Loss comes from transient lack of reachability during BGP convergence that follows the shutdown of an EBGP peering session between two Autonomous System Border Routers (ASBRs).

本文件讨论了为减少或消除维护操作期间的数据包丢失而采用的操作程序。在两个自治系统边界路由器(ASBR)之间的EBGP对等会话关闭后,BGP收敛期间暂时缺乏可达性会导致丢失。

This document presents procedures for the cases where the forwarding plane is impacted by the maintenance, hence for when the use of Graceful Restart does not apply.

本文档介绍了转发平面受到维护影响的情况下的程序,因此不适用优雅重启。

The procedures described in this document can be applied to reduce or avoid packet loss for outbound and inbound traffic flows initially forwarded along the peering link to be shut down. In both Autonomous Systems (ASes), these procedures trigger rerouting to alternate paths if they exist within the AS while allowing the use of the old path until alternate ones are learned. This ensures that routers always have a valid route available during the convergence process.

本文档中描述的过程可用于减少或避免最初沿要关闭的对等链路转发的出站和入站流量的数据包丢失。在两个自治系统(ASE)中,如果AS中存在备用路径,则这些过程会触发到备用路径的重新路由,同时允许使用旧路径,直到备用路径被学习为止。这确保路由器在收敛过程中始终具有有效的可用路由。

The goal of the document is to meet the requirements described in [RFC6198] as best possible without changing BGP.

本文件的目标是在不改变BGP的情况下尽可能满足[RFC6198]中所述的要求。

Other maintenance cases, such as the shutdown of an IBGP session or the establishment of an EBGP session, are out of scope for this document. For informational purposes, they are briefly discussed in Appendix C.

其他维护案例,如关闭IBGP会话或建立EBGP会话,不在本文档范围内。为了便于参考,附录C中对其进行了简要讨论。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时(如图所示)应按照BCP 14[RFC2119][RFC8174]所述进行解释。

2. Terminology
2. 术语

graceful shutdown initiator A router on which the session shutdown is performed for the maintenance.

正常关机启动器为维护而在其上执行会话关机的路由器。

graceful shutdown receiver A router that has a BGP session to be shut down with the graceful shutdown initiator.

优雅关机接收器具有要与优雅关机启动器关闭的BGP会话的路由器。

3. Packet Loss upon Manual EBGP Session Shutdown
3. 手动EBGP会话关闭时的数据包丢失

Packets can be lost during the BGP convergence following a manual shut down of an EBGP session for two reasons.

由于两个原因,在手动关闭EBGP会话之后,BGP聚合期间可能会丢失数据包。

First, some routers can have no path toward an affected prefix and drop traffic destined to this prefix. This is because alternate paths can be hidden by nodes of an AS. This happens when the extension defined in [RFC7911] is not used and a) the paths are not selected as best by the ASBRs that receive them on an EBGP session or b) Route Reflectors do not propagate the paths further in the IBGP topology because they do not select them as best.

首先,一些路由器可能没有指向受影响前缀的路径,并丢弃指向该前缀的流量。这是因为AS的节点可以隐藏备用路径。如果未使用[RFC7911]中定义的扩展,并且a)在EBGP会话中接收路径的ASBR未将路径选择为最佳路径,或者b)路由反射器不会在IBGP拓扑中进一步传播路径,因为它们没有将路径选择为最佳路径。

Second, the FIB can be inconsistent between routers within the AS, and packets toward affected prefixes can loop and be dropped unless encapsulation is used within the AS.

其次,AS内路由器之间的FIB可能不一致,除非AS内使用封装,否则指向受影响前缀的数据包可能循环并丢弃。

This document only addresses the first reason.

本文件仅涉及第一个原因。

4. Procedure for EBGP Graceful Shutdown
4. EBGP正常关闭程序

This section describes configurations and actions to be performed for the graceful shutdown of EBGP peering links.

本节介绍为正常关闭EBGP对等链路而要执行的配置和操作。

The goal of this procedure is to retain the paths to be shut down between the peers, but with a lower LOCAL_PREF value, allowing the paths to remain in use while alternate paths are selected and propagated, rather than simply withdrawing the paths. The LOCAL_PREF value SHOULD be lower than any of the alternative paths. The RECOMMENDED value is 0.

此过程的目标是保留对等点之间要关闭的路径,但使用较低的LOCAL_PREF值,允许在选择和传播备用路径时保持路径的使用,而不是简单地撤消路径。本地_PREF值应低于任何备选路径。建议的值为0。

Note that some alternative techniques with limited applicability are discussed in Appendix A for informational purposes.

注意,附录A中讨论了一些适用性有限的替代技术,以供参考。

4.1. Pre-configuration
4.1. 预配置

On each ASBR supporting the graceful shutdown receiver procedure, an inbound BGP route policy is applied on all EBGP sessions of the ASBR. That policy:

在每个支持正常关机接收程序的ASBR上,入站BGP路由策略应用于ASBR的所有EBGP会话。该政策:

o matches the GRACEFUL_SHUTDOWN community.

o 与社区匹配。

o sets the LOCAL_PREF attribute of the paths tagged with the GRACEFUL_SHUTDOWN community to a low value.

o 将使用“优雅”关闭社区标记的路径的“本地”PREF属性设置为低值。

For informational purposes, examples of configurations are provided in Appendix B.

为了便于参考,附录B中提供了配置示例。

4.2. Operations at Maintenance Time
4.2. 维修时的操作

On the graceful shutdown initiator, at maintenance time, the operator:

在正常停机启动器上,在维护时,操作员:

o applies an outbound BGP route policy on the EBGP session to be shutdown. This policy tags the paths propagated over the session with the GRACEFUL_SHUTDOWN community. This will trigger the BGP implementation to re-advertise all active routes previously advertised and tag them with the GRACEFUL_SHUTDOWN community.

o 在要关闭的EBGP会话上应用出站BGP路由策略。此策略将会话中传播的路径标记为“关闭”社区。这将触发BGP实现,以重新公布以前公布的所有活动路由,并用“正常关闭”社区标记它们。

o applies an inbound BGP route policy on the EBGP session to be shutdown. This policy tags the paths received over the session with the GRACEFUL_SHUTDOWN community and sets LOCAL_PREF to a low value.

o 在要关闭的EBGP会话上应用入站BGP路由策略。此策略使用优雅的\u SHUTDOWN社区标记通过会话接收的路径,并将本地\u PREF设置为低值。

o waits for route re-advertisement over the EBGP session and for BGP routing convergence on both ASBRs.

o 等待EBGP会话上的路由重新播发以及两个ASBR上的BGP路由会聚。

o shuts down the EBGP session, optionally using [RFC8203] to communicate the reason for the shutdown.

o 关闭EBGP会话,可以选择使用[RFC8203]来传达关闭原因。

In the case of a shutdown of the whole router, in addition to the graceful shutdown of all EBGP sessions, there is a need to gracefully shut down the routes originated by this router (e.g., BGP aggregates redistributed from other protocols, including static routes). This can be performed by tagging these routes with the GRACEFUL_SHUTDOWN community and setting LOCAL_PREF to a low value.

在关闭整个路由器的情况下,除了正常关闭所有EBGP会话外,还需要正常关闭该路由器发起的路由(例如,从其他协议重新分发的BGP聚合,包括静态路由)。这可以通过使用优雅的_SHUTDOWN社区标记这些路由并将LOCAL_PREF设置为低值来实现。

4.3. BGP Implementation Support for Graceful Shutdown
4.3. BGP实现对正常关机的支持

BGP Implementers SHOULD provide configuration knobs that utilize the GRACEFUL_SHUTDOWN community to inform BGP neighbors in preparation for an impending neighbor shutdown. Implementation details are outside the scope of this document.

BGP实施者应提供配置旋钮,该旋钮利用Grateful_SHUTDOWN社区通知BGP邻居,为即将发生的邻居关机做准备。实施细节不在本文件范围内。

5. IANA Considerations
5. IANA考虑

IANA previously assigned the community value 0xFFFF0000 to the 'planned-shut' community in the "BGP Well-known Communities" registry. IANA has changed the name 'planned-shut' to 'GRACEFUL_SHUTDOWN' and updated the reference to point to this document.

IANA之前将社区值0xFFFF0000分配给“BGP知名社区”注册表中的“计划关闭”社区。IANA已将名称“计划关闭”更改为“优雅关闭”,并更新了指向此文档的引用。

6. Security Considerations
6. 安全考虑

By providing the graceful shutdown service to a neighboring AS, an ISP provides means to this neighbor, and possibly its downstream ASes, to lower the LOCAL_PREF value assigned to the paths received from this neighbor.

通过向相邻AS提供正常关机服务,ISP向该邻居以及可能的下游ASE提供降低分配给从该邻居接收的路径的本地_PREF值的方法。

The neighbor could abuse the technique and do inbound traffic engineering by declaring that some prefixes are undergoing maintenance so as to switch traffic to another peering link.

邻居可能滥用该技术,通过声明某些前缀正在进行维护来进行入站流量工程,以便将流量切换到另一个对等链路。

If this behavior is not tolerated by the ISP, it SHOULD monitor the use of the graceful shutdown community.

如果ISP不允许这种行为,它应该监视社区的使用情况。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <https://www.rfc-editor.org/info/rfc1997>.

[RFC1997]Chandra,R.,Traina,P.,和T.Li,“BGP社区属性”,RFC 1997,DOI 10.17487/RFC1997,1996年8月<https://www.rfc-editor.org/info/rfc1997>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,DOI 10.17487/RFC2119,1997年3月<https://www.rfc-editor.org/info/rfc2119>.

[RFC6198] Decraene, B., Francois, P., Pelsser, C., Ahmad, Z., Elizondo Armengol, A., and T. Takeda, "Requirements for the Graceful Shutdown of BGP Sessions", RFC 6198, DOI 10.17487/RFC6198, April 2011, <https://www.rfc-editor.org/info/rfc6198>.

[RFC6198]DeClaene,B.,Francois,P.,Pelsser,C.,Ahmad,Z.,Elizondo Armengol,A.,和T.Takeda,“BGP会议正常关闭的要求”,RFC 6198,DOI 10.17487/RFC6198,2011年4月<https://www.rfc-editor.org/info/rfc6198>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174]Leiba,B.,“RFC 2119关键词中大写与小写的歧义”,BCP 14,RFC 8174,DOI 10.17487/RFC8174,2017年5月<https://www.rfc-editor.org/info/rfc8174>.

7.2. Informative References
7.2. 资料性引用

[BEST-EXTERNAL] Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H. Gredler, "Advertisement of the best external route in BGP", Work in Progress, draft-ietf-idr-best-external-05, January 2012.

[BEST-EXTERNAL]Marques,P.,Fernando,R.,Chen,E.,Mohapatra,P.,和H.Gredler,“BGP最佳外部路线的广告”,正在进行的工作,草案-ietf-idr-BEST-EXTERNAL-05,2012年1月。

[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, <https://www.rfc-editor.org/info/rfc7911>.

[RFC7911]Walton,D.,Retana,A.,Chen,E.,和J.Scudder,“BGP中多路径的广告”,RFC 7911,DOI 10.17487/RFC7911,2016年7月<https://www.rfc-editor.org/info/rfc7911>.

[RFC8203] Snijders, J., Heitz, J., and J. Scudder, "BGP Administrative Shutdown Communication", RFC 8203, DOI 10.17487/RFC8203, July 2017, <https://www.rfc-editor.org/info/rfc8203>.

[RFC8203]Snijders,J.,Heitz,J.,和J.Scudder,“BGP管理关闭通信”,RFC 8203,DOI 10.17487/RFC8203,2017年7月<https://www.rfc-editor.org/info/rfc8203>.

Appendix A. Alternative Techniques with Limited Applicability
附录A.适用性有限的替代技术

A few alternative techniques have been considered to provide graceful shutdown capabilities but have been rejected due to their limited applicability. This section describes these techniques for possible reference.

已经考虑了几种替代技术来提供良好的停堆能力,但由于其适用性有限而被拒绝。本节介绍这些技术,以供参考。

A.1. Multi-Exit Discriminator Tweaking
A.1. 多出口鉴别器调整

The Multi-Exit Discriminator (MED) attribute of the paths to be avoided can be increased to influence the routers in the neighboring AS to select other paths.

可以增加要避免的路径的多出口鉴别器(MED)属性,以影响相邻路径中的路由器,从而选择其他路径。

The solution only works if the alternate paths are as good as the initial ones with respect to the LOCAL_PREF value and the AS Path Length value. In the other cases, increasing the MED value will not have an impact on the decision process of the routers in the neighboring AS.

仅当备用路径与初始路径在本地_PREF值和as Path Length值方面一样好时,该解决方案才有效。在其他情况下,增加MED值不会对相邻AS中的路由器的决策过程产生影响。

A.2. IGP Distance Poisoning
A.2. IGP距离中毒

The distance to the BGP NEXT_HOP corresponding to the maintained session can be increased in the IGP so that the old paths will be less preferred during the application of the IGP distance tie-break rule. However, this solution only works for the paths whose alternates are as good as the old paths with respect to their LOCAL_PREF value, their AS Path length, and their MED value.

在IGP中,可以增加与所维护会话相对应的到BGP下一跳的距离,以便在应用IGP距离平局中断规则期间,旧路径将不那么优选。但是,此解决方案仅适用于在其局部_PREF值、as路径长度和MED值方面与旧路径具有相同替换效果的路径。

Also, this poisoning cannot be applied when BGP "NEXT_HOP self" is used, as there is no BGP NEXT_HOP specific to the maintained session to poison in the IGP.

此外,当使用BGP“下一跳自我”时,不能应用此中毒,因为IGP中没有特定于要中毒的维护会话的BGP下一跳。

Appendix B. Configuration Examples
附录B.配置示例

This appendix is non-normative.

本附录为非规范性附录。

This appendix includes examples of routing policy configurations to honor the GRACEFUL_SHUTDOWN well-known BGP community.

本附录包括路由策略配置示例,以表彰著名的BGP社区。

B.1. Cisco IOS XR
B.1. 思科IOS XR

community-set comm-graceful-shutdown 65535:0 end-set ! route-policy AS64497-ebgp-inbound ! normally this policy would contain much more if community matches-any comm-graceful-shutdown then set local-preference 0 endif end-policy ! router bgp 64496 neighbor 2001:db8:1:2::1 remote-as 64497 address-family ipv6 unicast send-community-ebgp route-policy AS64497-ebgp-inbound in

社区设置通信关闭65535:0结束设置!路由策略AS64497 ebgp入站!通常,如果社区匹配任何通信策略,则此策略将包含更多内容,然后设置本地首选项0 endif end策略!路由器bgp 64496邻居2001:db8:1:2::1远程as 64497地址系列ipv6单播发送社区ebgp路由策略AS64497 ebgp入站在

! ! !

! ! !

B.2. BIRD
B.2. 鸟
   function honor_graceful_shutdown() {
       if (65535, 0) ~ bgp_community then {
           bgp_local_pref = 0;
       }
   }
   filter AS64497_ebgp_inbound
   {
           # normally this policy would contain much more
           honor_graceful_shutdown();
   }
   protocol bgp peer_64497_1 {
       neighbor 2001:db8:1:2::1 as 64497;
       local as 64496;
       import keep filtered;
       import filter AS64497_ebgp_inbound;
   }
        
   function honor_graceful_shutdown() {
       if (65535, 0) ~ bgp_community then {
           bgp_local_pref = 0;
       }
   }
   filter AS64497_ebgp_inbound
   {
           # normally this policy would contain much more
           honor_graceful_shutdown();
   }
   protocol bgp peer_64497_1 {
       neighbor 2001:db8:1:2::1 as 64497;
       local as 64496;
       import keep filtered;
       import filter AS64497_ebgp_inbound;
   }
        
B.3. OpenBGPD
B.3. OpenBGPD
   AS 64496
   router-id 192.0.2.1
   neighbor 2001:db8:1:2::1 {
           remote-as 64497
   }
   # normally this policy would contain much more
   match from any community GRACEFUL_SHUTDOWN set { localpref 0 }
        
   AS 64496
   router-id 192.0.2.1
   neighbor 2001:db8:1:2::1 {
           remote-as 64497
   }
   # normally this policy would contain much more
   match from any community GRACEFUL_SHUTDOWN set { localpref 0 }
        
Appendix C. Beyond EBGP Graceful Shutdown
附录C.超出EBGP正常停机范围
C.1. IBGP Graceful Shutdown
C.1. 正常关机

For the shutdown of an IBGP session, provided the IBGP topology is viable after the maintenance of the session (i.e., if all BGP speakers of the AS have an IBGP signaling path for all prefixes advertised on this graceful shutdown IBGP session), then the shutdown of an IBGP session does not lead to transient unreachability. As a consequence, no specific graceful shutdown action is required.

对于IBGP会话的关闭,如果会话维护后IBGP拓扑是可行的(即,如果AS的所有BGP扬声器都有一个IBGP信令路径,用于该正常关闭IBGP会话上公布的所有前缀),则IBGP会话的关闭不会导致暂时不可访问性。因此,不需要特定的正常停机操作。

C.2. EBGP Session Establishment
C.2. EBGP会话建立

We identify two potential causes for transient packet losses upon the establishment of an EBGP session. The first one is local to the startup initiator; the second one is due to the BGP convergence following the injection of new best paths within the IBGP topology.

我们确定了EBGP会话建立后瞬时数据包丢失的两个潜在原因。第一个是本地启动启动器;第二个原因是在IBGP拓扑中注入新的最佳路径后,BGP收敛。

C.2.1. Unreachability Local to the ASBR
C.2.1. ASBR的本地不可访问性

An ASBR that selects a path received over a newly established EBGP session as the best path may transiently drop traffic. This can typically happen when the NEXT_HOP attribute differs from the IP address of the EBGP peer and the receiving ASBR has not yet resolved the MAC address associated with the IP address of that third-party NEXT_HOP.

选择通过新建立的EBGP会话接收的路径作为最佳路径的ASBR可暂时丢弃通信量。当下一跳属性不同于EBGP对等方的IP地址且接收ASBR尚未解析与该第三方下一跳IP地址关联的MAC地址时,通常会发生这种情况。

A BGP speaker implementation MAY avoid such losses by ensuring that third-party NEXT_HOPs are resolved before installing paths using these NEXT_HOPs in the RIB.

BGP扬声器实现可通过确保在RIB中安装使用这些下一跳的路径之前解决第三方下一跳来避免此类损失。

Alternatively, the operator (script) MAY ping third-party NEXT_HOPs that are expected to be used prior to establishing the session. By proceeding like this, the MAC addresses associated with these third-party NEXT_HOPs are resolved by the startup initiator.

或者,操作员(脚本)可以ping在建立会话之前预期使用的第三方下一跳。通过这样进行,与这些第三方下一跳关联的MAC地址由启动启动器解析。

C.2.2. IBGP Convergence
C.2.2. IBGP收敛

During the establishment of an EBGP session, in some corner cases, a router may have no path toward an affected prefix, leading to loss of connectivity.

在建立EBGP会话期间,在某些情况下,路由器可能没有指向受影响前缀的路径,从而导致连接丢失。

A typical example for such transient unreachability for a given prefix is the following:

给定前缀的这种瞬时不可达性的典型示例如下:

Consider three Route Reflectors (RR): RR1, RR2, RR3. There is a full mesh of IBGP sessions between them.

考虑三个路由反射器(RR):RR1、RR2、RR3。它们之间有一个完整的IBGP会话网格。

1. RR1 is initially advertising the current best path to the members of its IBGP RR full mesh. It propagated that path within its RR full-mesh. RR2 knows only that path toward the prefix.

1. RR1最初向其IBGP RR完整网格的成员宣传当前最佳路径。它在其RR完整网格内传播该路径。RR2只知道指向前缀的路径。

2. RR3 receives a new best path originated by the startup initiator, which is one of its RR clients. RR3 selects it as best and propagates an UPDATE within its RR full mesh, i.e., to RR1 and RR2.

2. RR3接收由启动启动器发起的新最佳路径,启动启动器是其RR客户端之一。RR3将其选择为最佳,并在其RR完整网格内传播更新,即到RR1和RR2。

3. RR1 receives that path, reruns its decision process, and picks this new path as best. As a result, RR1 withdraws its previously announced best path on the IBGP sessions of its RR full mesh.

3. RR1接收该路径,重新运行其决策过程,并选择该新路径作为最佳路径。因此,RR1在其RR完整网格的IBGP会话上撤销了先前宣布的最佳路径。

4. If, for any reason, RR3 processes the withdraw generated in step 3 before processing the update generated in step 2, RR3 transiently suffers from unreachability for the affected prefix.

4. 如果出于任何原因,RR3在处理步骤2中生成的更新之前处理步骤3中生成的撤销,则RR3暂时遭受受影响前缀的不可访问性。

The use of [RFC7911] or [BEST-EXTERNAL] among the RR of the IBGP full mesh can solve these corner cases by ensuring that within an AS, the advertisement of a new route is not translated into the withdraw of a former route.

在IBGP全网格的RR中使用[RFC7911]或[BEST-EXTERNAL]可以通过确保在AS中,新路由的广告不会转化为撤回以前的路由来解决这些拐角情况。

Indeed, advertising the best external route ensures that an ASBR does not withdraw a previously advertised (EBGP) path when it receives an additional, preferred path over an IBGP session. Also, advertising the best intra-cluster route ensures that an RR does not withdraw a previously advertised (IBGP) path to its non-clients (e.g., other RRs in a mesh of RR) when it receives a new, preferred path over an IBGP session.

实际上,公布最佳外部路由可确保ASBR在通过IBGP会话接收到额外的首选路径时不会撤回先前公布的(EBGP)路径。此外,公布最佳集群内路由可确保RR在通过IBGP会话接收到新的首选路径时,不会撤回到其非客户端(例如,RR网格中的其他RR)的先前公布(IBGP)路径。

Acknowledgments

致谢

The authors wish to thank Olivier Bonaventure, Pradosh Mohapatra, Job Snijders, John Heasley, and Christopher Morrow for their useful comments.

作者希望感谢Olivier Bonaventure、Pradosh Mohapatra、Job Snijders、John Heasley和Christopher Morrow的有用评论。

Authors' Addresses

作者地址

Pierre Francois (editor) Individual Contributor

皮埃尔·弗朗索瓦(编辑)个人撰稿人

   Email: pfrpfr@gmail.com
        
   Email: pfrpfr@gmail.com
        

Bruno Decraene (editor) Orange

布鲁诺·德雷恩(编辑)橙色

   Email: bruno.decraene@orange.com
        
   Email: bruno.decraene@orange.com
        

Cristel Pelsser Strasbourg University

斯特拉斯堡大学

   Email: pelsser@unistra.fr
        
   Email: pelsser@unistra.fr
        

Keyur Patel Arrcus, Inc.

凯乌尔·帕特尔·阿卡斯公司。

   Email: keyur@arrcus.com
        
   Email: keyur@arrcus.com
        

Clarence Filsfils Cisco Systems

克拉伦斯菲尔斯思科系统公司

   Email: cfilsfil@cisco.com
        
   Email: cfilsfil@cisco.com