設定ガイド:VCS メンテナンスモード

fmiyamot 投稿日: 2月 5, 2021

配置指南:VCS维护模式

通常,在进行维护工作时,除ISSU之外,通信总是会中断。
设置更改会导致通信中断,操作系统升级/降级,由于电缆故障导致的电缆更换,因收发器故障导致的收发器更换,因端口故障引起的设备更换。    

说到维护工作,大多数工作无法在白天停止,通常需要在深夜或假日工作,这给操作经理和操作员以及这里的人员增加了负担。对于公司而言,成本是一个主要问题。如果这样的维护工作可以“不间断”进行。    

对于希望在发生故障时加快恢复速度,降低系统运营成本并减轻系统人员负担的操作员而言,以太网结构是NetworkOS 7.0.0的“不间断”维护工作。已经实现了启用的功能。  

这次,我将详细解释这种维护模式。    

 

常规VCS维护工作

  通常,当需要维护工作(例如在VCS中进行OS升级或更换设备)时,我们将为您提供绕过流量=转移的最佳实践方法。  

例如,在VDX2上执行维护工作时,只能采用阻塞VDX2的每个端口并将流量转移到第1个系统(左侧=绿色)的过程。    

尽管可以在不到1秒的瞬间中断之内在VCS内进行切换,但是如果VCS外部的Edge端口被阻塞,则连接通常会断开1秒以上,具体取决于对端设备。工作本身很复杂,需要仔细注意。    

NOS7.0.0实现了期待已久的用于维护工作的命令,即系统模式维护。这是生产网络中经常使用的Spine / Leaf拓扑。 我将解释的维护模式如何工作。

       

 

VCS正常运行

  首先,检查VCS处于正常状态。

  •  使用“ show vcs”命令检查VCS状态

 

  • 使用“ show fabric route linkinfo”命令检查VCS中的链接以及每个成本值

 

维护模式的实现(模式1:对Spine VDX2执行)

执行维护工作,以绕过通过第二个系统主干路由桥(RB)2 = VDX2到第一个系统路由桥(RB)1 = VDX1的流量。      

维护工作的命令,系统模式维护,在RB2下提交。

启用了维护模式的RB将继续参与VCS,并且可以从Principal进行访问。
当然,对于Principal = RB2,维护模式也是可能的。

故意增加了ISL的费用(500->4900)阻止选择通过相应RB的ISL。
但是,取决于网络配置,流量可能流经配置的RB。一个例子如下所示。

在上述配置中,主机A和主机B之间的通信没有不通过RB12的替代路径(主机A和主机B之间的通信必须在RB11-RB12或RB2-RB12之间通过)。不保持),即使RB12处于维护模式,流量也始终通过RB12。

 

维护模式的实现(模式2:对Leaf VDX11执行)

执行维护工作,以绕过通过第一系统叶路由桥(RB)11 = VDX11到第二系统主干路由桥(RB)2 = VDX2的流量。

 

维护工作的命令,系统模式维护,在RB11下提交。

在运行维护模式的RB中,可以更改管理性关闭的端口,但不能启用端口通道或端口通道的成员端口。

*在此配置中,无法启用处于维护模式的RB11的端口16。    

交通申请的结果

 下面,让我们检查为模式1(书脊)和模式2(叶)中的每一个设置维护模式并生成多个流时的通信中断。

  • L2流量(MAC地址×100流)
  • L3流量(IP地址x 100流量)
  • 1,000个
  • 1,500字节
  • 双向的

从测试结果
模式1:将主干RB置于维护模式时,通信中断时间为0(零)。
模式2:将Leaf RB设置为维护模式时的通信中断时间也不到一秒。

 

通过实施维护模式,使用此配置维护主干的RB时,您可以“不间断”处理返回主干的通信。此外,具有vLAG配置的叶RB还会通知其他成员并交换路由,因此,可以将由于RB突然关闭而造成的流量损失降到最低,并且可以进行更优美的流量旁路。从运营商的角度来看,以太网结构= VCS将继续发展。

服务提供商相关文章