OSPF链路优雅关闭

admin 2026-05-04 04:30:07 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

文章总结: RFC8379定义了OSPFv2和OSPFv3中优雅链路关闭的协议扩展,允许路由器在链路维护前通告关闭状态以实现流量无损切换。该机制通过Graceful-Link-Shutdown子TLV标识待关闭链路,并支持点对点、广播、P2MP等多种链路类型。文档详细说明了度量值调整、TE链路处理及向后兼容性,特别适用于overlay网络中PE设备维护场景,确保在无备用路径时链路仍可作为最后手段使用。 综合评分: 87 文章分类: 技术标准,解决方案,网络协议,安全运营,其他


cover_image

OSPF链路优雅关闭

衡水石头哥 衡水石头哥

铁军哥

2026年5月3日 07:38 北京

在小说阅读器读本章

去阅读

RFC8379:OSPF Graceful Link Shutdown,May 2018

梗概

当链路准备退出服务时,需要从链路两端进行流量分流。将链路一侧的度量增加到最高值不足以转移另一方向的流量。

对于OSPFv2或OSPFv3路由域中的路由器来说,能够将链路通告为处于正常关闭状态以指示链路上即将进行的维护活动非常有用。网络设备可以使用此信息来有效地重新路由流量。

本文档描述了OSPFv2和OSPFv3中传播优雅链路关闭信息的协议扩展。

本备忘录的状态

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

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

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

版权声明

版权所有(c)2018 IETF Trust和文档作者。版权所有。

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

1、简介

本文档描述了一种机制,用于优雅地使链接退出服务,同时在没有其他路径可用时允许使用该链接。它还提供了一种从链路的两个方向转移流量的机制。

许多OSPFv2或OSPFv3部署在通过伪线或L2电路配置的overlay网络上运行。在底层网络中的设备离线进行维护之前,在实际执行维护之前将流量从节点引开是很有用的。由于底层网络中的节点对OSPF不可见,因此无法使用[RFC6987]中描述的现有末节路由器机制。在服务提供商的网络中,可能存在在单个PE上运行的许多CE到CE的连接。双向更改每个CE到CE连接上的度量非常麻烦。本文档提供了一种机制来更改远程端链路的度量,并且在没有可用的备用路径时也可以使用该链路作为最后手段链路。第7.1节详细描述了特定于此用例的应用程序。

本文档提供了在“OSPFv2前缀/链路属性通告”[RFC7684]和OSPFv3的E-Router-LSA[RFC8362]提供的灵活编码中通告优雅链路关闭状态的机制。在本文档中,当文本同时适用于OSPFv2和OSPFv3时,将使用OSPF。当文本特定于OSPF协议的一种版本时,使用OSPFv2或OSPFv3。

1.1、要求语言

本文档中的关键字“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们出现在所有内容中时,应按照BCP 14[RFC2119][RFC8174]中的描述进行解释。

2、动机

本文档的目的是减少维护活动期间的人工干预。以下目标有助于在一系列部署场景中实现这一目标。

  1. 通告即将进行的维护活动,以便将来自两个方向的流量从链路转移出去。

  2. 允许解决方案向后兼容,以便不理解新通告的节点不会导致路由环路。

  3. 将维护活动通告给网络中的其他节点,以便标签交换路径(Label Switched Path,LSP)入口路由器/控制器可以了解即将发生的维护活动,并应用特定策略来重新路由LSP,以便基于流量工程(Traffic Engineering,TE)进行部署。

  4. 允许将该链路用作最后手段链路,以防止在备用路径不可用时发生流量中断。

3、泛洪范围

优雅链路关闭信息在OSPFv2的区域范围扩展链路不透明LSA[RFC7684]和OSPFv3[RFC8362]的E-Router-LSA中泛洪。优雅链路关闭子TLV可以由头端节点或控制器处理,如第7节中所述。处理优雅链路关闭子TLV的过程在第5节中描述。

4、协议扩展

4.1、OSPFv2优雅链路关闭子TLV

Graceful-Link-Shutdown子TLV将链路标识为正常关闭。它在[RFC7684]中定义的扩展链路不透明LSA的扩展链路TLV中进行通告。

图1:OSPFv2的优雅链路关闭子TLV

Type:类型,7

Length:长度,0

4.2、远程IPv4地址子TLV

该子TLV指定链路上远程端点的IPv4地址。它在[RFC7684]中定义的扩展链路TLV中通告。该子TLV是可选的,并且可以在区域范围的扩展链路不透明LSA中通告,以在两个节点之间存在多个并行链路时识别链路。

图2:远程IPv4地址子TLV

Type:类型,8

Length:长度,4

Value:值,远程IPv4地址。当两个节点之间存在多条并行链路时,远端IPv4地址用于标识远端的特定链路。

4.3、本地/远程接口ID子TLV

该子TLV指定本地和远程接口ID。它在[RFC7684]中定义的扩展链路TLV中通告。该子TLV是可选的,并且可以在区域范围的扩展链路不透明LSA中通告,以在两个节点之间存在多个并行的无编号链路时识别链路。本地接口ID通常很容易获得。[RFC4203]中描述了获取远程接口ID的机制之一。

图3:本地/远程接口ID子TLV

Type:类型,9

Length:长度,8

Value:值,4个八位字节的本地接口ID,后跟4个八位字节的远程接口ID。

4.4、OSPFv3优雅链路关闭子TLV

按照OSPFv3的[RFC8362]中的定义,Graceful-Link-Shutdown子TLV在Router-Link TLV中携带。Router-Link TLV包含邻居接口ID,可以唯一标识远程节点上的链路。

图4:OSPFv3的优雅链路关闭子TLV

Type:类型,8

Length:长度,0

4.5、BGP-LS优雅链路关闭TLV

[RFC7752]中定义的BGP-LS是一种使用BGP路由协议将网络信息分发到外部实体的机制。正常链路关闭是重要的链路信息,外部实体可以将其用于第7节中定义的各种用例。BGP链路网络层可达性信息(Network Layer Reachability Information,NLRI)用于携带链路信息。定义了一个新的TLV“Graceful-LinkShutdown”来描述graceful-link-shutdown状态对应的链路属性。TLV格式如[RFC7752]的3.1节中所述。没有值字段,并且该TLV的长度字段设置为零。

图5:BGP-LS的优雅链路关闭TLV

Type:类型,1121

Length:长度,0

4.6、区分并行链接

图6:并行链接

考虑两个路由器A和B,通过两个并行点对点接口连接。I.w和I.x表示RouterA侧的接口地址,I.y和I.z表示RouterB侧的接口地址。[RFC7684]中定义的扩展链路不透明LSA使用链路类型、链路ID和链路数据来描述链路。例如,Router A上一条地址为I.w的链路描述如下:

链路类型 = 点对点

Link ID = B的Router ID

链接数据 = I.w

网络中的第三个节点(控制器或头端)无法根据上述链路信息区分路由器B上的接口,该接口连接到路由器A上的该特定接口。由于这种不明确性,可以选择地址为I.y或I.z的接口。在这种情况下,应发起远程IPv4地址子TLV并将其添加到扩展链路TLV。第7节中描述的用例需要控制器或头端节点解释正常链路关闭信息,因此需要远程IPv4地址子TLV。I.y携带在扩展链路TLV中,它明确标识了远端的接口。[RFC8362]中描述的OSPFv3 Router-Link TLV包含Interface ID和邻居的Interface ID,可以唯一标识连接远端的接口;因此,OSPFv3不需要将单独的远程IPv6地址与OSPFv3 Graceful-Link-Shutdown子TLV一起通告。

5、程序要素

根据[RFC7684]中的定义,节点上的每个链路都将具有单独的扩展链路不透明LSA。具有要退出服务的链路的节点必须在OSPFv2的扩展链路不透明LSA的扩展链路TLV中通告Graceful-Link-Shutdown子TLV(如[RFC7684]中所定义),以及OSPFv3的E-Router-LSA的Router-Link TLV中。Graceful-Link-Shutdown子TLV表示该子TLV标识的链路正在维护。

为了更改度量OSPFv2和OSPFv3路由器LSA需要重新发起。要更改流量工程度量,需要重新发起OSPFv2[RFC3630]中的TE不透明LSA和OSPFv3[RFC5329]中的区域内TE-LSA。

正常链路关闭信息作为链路的属性进行通告,并通过该区域进行泛洪。入口路由器或控制器可以使用此信息来采取特殊操作。第7.2节描述了特定于该用例的应用程序。

当链路准备好承载流量时,必须从扩展链路TLV/路由器链路TLV中删除优雅链路关闭子TLV,并且必须重新通告相应的LSA。类似地,度量值必须设置为原始值,并且相应的LSA必须重新通告。

本文档中描述的过程可用于在链路关闭或链路替换活动以外的情况下将流量从链路转移。

被识别为正常关闭的链路另一端的远程节点所采取的精确操作取决于链路类型。

5.1、点对点链接

具有要退出服务的链路的节点必须将链路的度量设置为MaxLinkMetric(0xffff)并重新发起其Router-LSA。链路的流量工程度量应设置为(0xffffffff),并且节点应重新发起相应的TE链路不透明LSA。当收到点对点链路的Graceful-Link-Shutdown子TLV时,远程节点必须识别与该正常关闭链路相对应的本地链路,并将其度量设置为MaxLinkMetric(0xffff),并且远程节点必须使用更改后的度量重新发起其Router-LSA。当启用TE时,链路的流量工程度量应设置为(0xffffffff)并遵循[RFC5817]中的过程。同样,远程节点应将链路的流量工程度量值设置为 0xffffffff,并应使用新值重新生成链路的 TE 链路不透明 LSA。

扩展链路不透明LSA和扩展链路TLV不属于多拓扑[RFC4915]的范围。在多拓扑部署[RFC4915]中,扩展链路不透明LSA中通告的Graceful-Link-Shutdown子TLV对应于包含该链路的所有拓扑。接收方节点应该按照[RFC4915]中的定义,更改包括远程链路的所有拓扑的反向度量并重新发起Router-LSA。

当Graceful-Link-Shutdown子TLV的发起者清除扩展链路不透明LSA或在没有Graceful-Link-Shutdown子TLV的情况下重新发起它时,远程节点必须重新发起适当的LSA,并将度量和TE度量值设置为其原始值。

5.2、广播/NBMA链接

OSPF中的广播或非广播多路访问(Non-Broadcast Multi-Access,NBMA)网络由星形拓扑表示,其中指定路由器(Designated Router,DR)是广播或NBMA网络上所有其他路由器逻辑连接的中心点。因此,广播或NBMA网络上的路由器仅向DR通告其邻接关系。不充当DR的路由器不会相互形成或通告邻接关系。对于广播链路,远程链路上的MaxLinkMetric无法更改,因为所有邻居都在同一链路上。将链路成本设置为MaxLinkMetric将影响穿过该广播链路上连接的任何邻居的所有路径。

具有要退出服务的链路的节点必须将链路的度量设置为MaxLinkMetric(0xffff)并重新发起Router-LSA。链路的流量工程度量应设置为(0xffffffff),并且节点应重新发起相应的TE链路不透明LSA。对于广播链路,使用[RFC8042]中描述的两部分度量。发起Graceful-Link-Shutdown子TLV的节点必须将OSPFv2和OSPFv3的网络到路由器度量子TLV中的度量设置为MaxLinkMetric(0xffff),并重新发起相应的LSA。接收两部分度量的节点应遵循[RFC8042]中描述的过程。应遵循[RFC8042]中描述的向后兼容程序以确保无环路路由。

5.3、点对多点链路

点对多点(point-to-multipoint,P2MP)链路的操作与点对点链路类似。当接收到点对多点链路的Graceful-Link-Shutdown子TLV时,远程节点必须识别对应于Graceful-shutdown链路的邻居,并将其度量设置为MaxLinkMetric(0xffff)。远程节点必须使用相应邻居的已更改度量重新发起Router-LSA。

5.4、无编号的接口

无编号的接口没有唯一的IP地址,而是从其他接口借用其地址。[RFC2328]描述了在Router-LSA上下文中处理无编号接口的过程。我们对通告Graceful-Link-Shutdown子TLV的扩展链路TLV应用类似的过程,以处理无编号的接口。扩展链路TLV中的链路数据字段包括本地接口ID,而不是IP地址。当两个节点之间存在多个并行无编号接口时,必须通告本地/远程接口ID子TLV。[RFC4203]中定义了获取远程端接口ID的机制之一。

5.5、混合广播和P2MP接口

混合广播和P2MP接口表示建模为P2MP接口的广播网络。[RFC6845]描述了处理这些接口的过程。Hybrid接口的操作与P2MP接口的操作类似。当接收到混合链路的Graceful-Link-Shutdown子TLV时,远程节点必须识别对应于Graceful-Shutdown链路的邻居,并将其度量设置为MaxLinkMetric(0xffff)。连接到发起者的所有远程节点必须使用更改后的邻居度量重新发起Router-LSA。

6、向后兼容性

文档中描述的机制完全向后兼容。要求通告优雅链路关闭子TLV的节点以及处于优雅关闭链路的远程端的节点支持本文描述的用于从优雅关闭链路转移的流量的扩展。如果远程节点不支持该功能,它仍将使用优雅关闭链接,但不会产生其他不利影响。在使用两部分度量的广播链路的情况下,[RFC8042]中描述的向后兼容过程是适用的。

7、应用

7.1、overlay网络

许多服务提供商为连接不同位置的客户提供L2服务。客户的IGP协议为客户创建跨位置的无缝专用网络(overlay网络)。服务提供商希望在PE设备被取出进行维护时提供正常关闭功能。可能有大量客户连接到PE节点,并且这些L2连接电路的远程端点分布在服务提供商的网络中。在两个方向上更改所有相应L2电路的度量是一个乏味且容易出错的过程。优雅链路关闭功能通过增加CE-CE重叠链路上的度量来简化流程,从而将两个方向的流量从正在进行维护的PE转移出去。正常链路关闭功能允许将链路用作最后手段链路,以便在备用路径不可用时不会中断流量。

图7:overlay网络

CE:客户边缘

PE:提供商边缘

在图7所示的示例中,当PE1节点因维护而退出服务时,服务提供商将PE1设置为Stubrouter状态,并将待处理的维护操作传达给overlay客户网络。用于在PE1和CE1之间进行通信的机制不属于本文档的讨论范围。CE1将CE3、CE2、CE4之间的链路设置为graceful-link-shutdown状态,将度量值更改为MaxLinkMetric,并重新生成相应的LSA。链路远端CE3、CE2、CE4也将链路上的度量设置为MaxLinkMetric,两个方向的流量都从PE1引流出去。

7.2、基于控制器的部署

在控制器参与IGP协议的基于控制器的部署中,控制器还可以接收优雅链路关闭信息,作为链路维护即将进行的警告。使用此信息,控制器可以找到使用受影响链路的流量的备用路径。控制器可以应用各种策略并将LSP重新路由到远离正在进行维护的链路。如果没有满足约束的备用路径,控制器可能会暂时放宽这些约束并将服务置于不同的路径上。单独增加链路度量并不指定维护活动,因为在LDP-IGP同步等事件中度量可能会增加。需要来自路由器的使用Graceful-Link-Shutdown子TLV的显式指示来通知控制器或头端路由器。

图8:基于控制器的流量工程

在上面的示例中,PE1->PE2 LSP的建立是为了满足每条链路上10 Gbps带宽的约束。链路P1->P3和P3->P2只有1Gbps的容量,并且没有满足10Gbps带宽约束的备用路径。当P1->P2链路准备维护时,由于没有满足约束条件的备用路径,控制器收到链路优雅关闭信息,控制器选择一条不太优的路径,临时建立一条经过P1->P3->P2的备用路径。一旦流量分流,P1->P2链路就可以退出服务进行维护/升级。

7.3、L3VPN服务和虚假链接

许多服务提供商向客户提供三层虚拟专用网络(Layer 3 Virtual Private Network,L3VPN)服务,CE-PE链路运行OSPF[RFC4577]。当PE停运维护时,可以将PE上的所有链路设置为graceful-link-shutdown状态,保证双归CE的流量得到分流。OSPF和BGP之间的交互超出了本文档的范围。当实现支持摘要和外部的高指标通告时,基于[RFC6987]的具有以高指标进行通告的摘要和外部的机制也可以用于实现相同的功能。

另一个有用的用例是ISP向客户提供虚假链接服务[RFC4577]。当PE停运维护时,可以将PE上的所有sham link设置为graceful-linkshutdown状态,实现两端流量分流,而无需触及sham link远端的配置。

7.4、轴辐式部署

OSPF主要部署在Hub和Spoke部署中,有大量Spoke连接到Hub。通常的做法是部署多个Hub,所有Spoke都连接到这些Hub以实现冗余。[RFC6987]中定义的机制可用于从过载的集线器路由器转移分支到分支的流量。在某些场景下,从Spoke经Hub流向外部网络的流量可能不会被引流。当Hub节点因维护而停机时,Hub上的所有链路都可以设置为graceful-link-shutdown状态,并且流量也可以从Spoke站点转移,而无需在Spoke上进行配置更改。

8、安全考虑

本文档使用[RFC2328]、[RFC3630]、[RFC5329]和[RFC5340]中描述的OSPF数据包和LSA。[RFC2328]中针对OSPFv2和[RFC4552]中针对OSPFv3描述的身份验证过程也适用于本文档。除了[RFC2328]和[RFC5340]中讨论的安全问题之外,本文档没有引入任何其他安全问题。

9、IANA考虑因素

IANA已在“OSPFv2扩展链路TLV子TLV”注册表中注册了以下内容:

7 - Graceful-Link-Shutdown Sub-TLV8 - Remote IPv4 Address Sub-TLV9 - Local/Remote Interface ID Sub-TLV

IANA已在“OSPFv3 Extended-LSA Sub-TLV”注册表中注册了以下值:

8 - Graceful-Link-Shutdown sub-TLV

IANA已在“BGP-LS节点描述符、链路描述符、前缀描述符和属性TLV”注册表[RFC7752]中注册了以下值:

1121 – Graceful-Link-Shutdown TLV

10、参考文献

10.1、规范性参考文献

[RFC2119]Bradner, S.,&nbsp;"Key words for use in RFCs to Indicate Requirement Levels", BCP&nbsp;14, RFC&nbsp;2119, DOI&nbsp;10.17487/RFC2119, March&nbsp;1997, <https://www.rfc-editor.org/info/rfc2119>.[RFC2328]Moy, J.,&nbsp;"OSPF Version 2", STD&nbsp;54, RFC&nbsp;2328, DOI&nbsp;10.17487/RFC2328, April&nbsp;1998, <https://www.rfc-editor.org/info/rfc2328>.[RFC3630]Katz, D., Kompella, K.,&nbsp;and&nbsp;D. Yeung,&nbsp;"Traffic Engineering (TE) Extensions to OSPF Version 2", RFC&nbsp;3630, DOI&nbsp;10.17487/RFC3630, September&nbsp;2003, <https://www.rfc-editor.org/info/rfc3630>.[RFC5329]Ishiguro, K., Manral, V., Davey, A.,&nbsp;and&nbsp;A. Lindem, Ed.,&nbsp;"Traffic Engineering Extensions to OSPF Version 3", RFC&nbsp;5329, DOI&nbsp;10.17487/RFC5329, September&nbsp;2008, <https://www.rfc-editor.org/info/rfc5329>.[RFC5340]Coltun, R., Ferguson, D., Moy, J.,&nbsp;and&nbsp;A. Lindem,&nbsp;"OSPF for IPv6", RFC&nbsp;5340, DOI&nbsp;10.17487/RFC5340, July&nbsp;2008, <https://www.rfc-editor.org/info/rfc5340>.[RFC5817]Ali, Z., Vasseur, JP., Zamfir, A.,&nbsp;and&nbsp;J. Newton,&nbsp;"Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", RFC&nbsp;5817, DOI&nbsp;10.17487/RFC5817, April&nbsp;2010, <https://www.rfc-editor.org/info/rfc5817>.[RFC6845]Sheth, N., Wang, L.,&nbsp;and&nbsp;J. Zhang,&nbsp;"OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type", RFC&nbsp;6845, DOI&nbsp;10.17487/RFC6845, January&nbsp;2013, <https://www.rfc-editor.org/info/rfc6845>.[RFC6987]Retana, A., Nguyen, L., Zinin, A., White, R.,&nbsp;and&nbsp;D. McPherson,&nbsp;"OSPF Stub Router Advertisement", RFC&nbsp;6987, DOI&nbsp;10.17487/RFC6987, September&nbsp;2013, <https://www.rfc-editor.org/info/rfc6987>.[RFC7684]Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J.,&nbsp;and&nbsp;A. Lindem,&nbsp;"OSPFv2 Prefix/Link Attribute Advertisement", RFC&nbsp;7684, DOI&nbsp;10.17487/RFC7684, November&nbsp;2015, <https://www.rfc-editor.org/info/rfc7684>.[RFC7752]Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A.,&nbsp;and&nbsp;S. Ray,&nbsp;"North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC&nbsp;7752, DOI&nbsp;10.17487/RFC7752, March&nbsp;2016, <https://www.rfc-editor.org/info/rfc7752>.[RFC8042]Zhang, Z., Wang, L.,&nbsp;and&nbsp;A. Lindem,&nbsp;"OSPF Two-Part Metric", RFC&nbsp;8042, DOI&nbsp;10.17487/RFC8042, December&nbsp;2016, <https://www.rfc-editor.org/info/rfc8042>.[RFC8174]Leiba, B.,&nbsp;"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP&nbsp;14, RFC&nbsp;8174, DOI&nbsp;10.17487/RFC8174, May&nbsp;2017, <https://www.rfc-editor.org/info/rfc8174>.[RFC8362]Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V.,&nbsp;and&nbsp;F. Baker,&nbsp;"OSPFv3 Link State Advertisement (LSA) Extensibility", RFC&nbsp;8362, DOI&nbsp;10.17487/RFC8362, April&nbsp;2018, <https://www.rfc-editor.org/info/rfc8362>.

10.2、参考资料

[RFC4203]Kompella, K., Ed.&nbsp;and&nbsp;Y. Rekhter, Ed.,&nbsp;"OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC&nbsp;4203, DOI&nbsp;10.17487/RFC4203, October&nbsp;2005, <https://www.rfc-editor.org/info/rfc4203>.[RFC4552]Gupta, M.&nbsp;and&nbsp;N. Melam,&nbsp;"Authentication/Confidentiality for OSPFv3", RFC&nbsp;4552, DOI&nbsp;10.17487/RFC4552, June&nbsp;2006, <https://www.rfc-editor.org/info/rfc4552>.[RFC4577]Rosen, E., Psenak, P.,&nbsp;and&nbsp;P. Pillay-Esnault,&nbsp;"OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC&nbsp;4577, DOI&nbsp;10.17487/RFC4577, June&nbsp;2006, <https://www.rfc-editor.org/info/rfc4577>.[RFC4915]Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L.,&nbsp;and&nbsp;P. Pillay-Esnault,&nbsp;"Multi-Topology (MT) Routing in OSPF", RFC&nbsp;4915, DOI&nbsp;10.17487/RFC4915, June&nbsp;2007, <https://www.rfc-editor.org/info/rfc4915>.

致谢

感谢Chris Bowers对本文档的宝贵意见和编辑。感谢Jeffrey Zhang、Acee Lindem和Ketan Talaulikar的投入。感谢Karsten Thomann对优雅链接关闭有用的应用程序进行了仔细审查和输入。

感谢Alia Atlas、Deborah Brungard、Alvaro Retana、Andrew G. Malis和Tim Chown提供的宝贵意见。

***推荐阅读***

我们的WireGuard管理系统支持手机电脑了!全平台终端配置,支持扫码连接,一键搞定

保姆级教程:一条命令部署OpenVPN管理系统V4版,支持Win/Mac/安卓/iOS全平台接入

成本省下99.7%!用40元的腾讯云服务器自建IPsecVPN,成功对接企业级飞塔防火墙

别再乱选VPN了!实测数据告诉你:为什么L2TP是个“坑”

SRv6部署第一坑:为什么配置了Locator却Ping不通?

嫌一键部署不过瘾?带你手搓Hermes智能体,主打一个通透

Hyper-V别开!VMware 25H2安装避坑指南,附Hermes新动向

H3C CAS实战:CVM纳管CVK的相爱相杀,这波操作太秀了!

VPP转发性能从10G暴增至24G?揭秘OpenEuler虚拟机的极限压榨术

NVUE不支持OSPFv3?别慌!教你一招搞定SRv6地基

手机也能跑DeepSeek-R1/Qwen3了:零成本搭建AI推理平台

2048卡昇腾910C集群算力集群交付工程手册

2048卡H100算力中心100G无阻塞存储网建设方案


免责声明:

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。

任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我

本文转载自:铁军哥 衡水石头哥 衡水石头哥《OSPF链路优雅关闭》

OSPF链路优雅关闭 网络安全文章

OSPF链路优雅关闭

文章总结: RFC8379定义了OSPFv2和OSPFv3中优雅链路关闭的协议扩展,允许路由器在链路维护前通告关闭状态以实现流量无损切换。该机制通过Gracef
评论:0   参与:  0