锐捷S6000C 阿里云场景园区版本零配置VSU组建失败
一、故障现象描述
为了解决运行1489天触发的DCM翻转导致cpu高的软件bug（B74P1版本之前均存在），将VSU主备机轮流重启，先重启主机，后重启备机，发现备机重启之后无法正常组建VSU，由于申请了变更窗口，且业务都是双上行冗余，主机正常，故业务未受到影响，但单机运行存在风险。
场景拓扑如下：
二、故障排查分析
-
查看交换机日志，发现日志提示switch id冲突；
-
了解现场重启情况是在备机重启起来之后才接的vsl链路，没有在备机重启时候接上vsl，怀疑这种可能会导致vsu配置异常；
-
协商现场将备机重启发现问题依旧；
-
将备机恢复成单机模式，重新配置vsu，然后再次组建vsu，此时正常；
-
过了一会，未做任何操作，发现vsu系统只剩一台设备；
-
此时查看isolate这台的vsu配置，发现和正常active主机的vsu配置一样，怀疑是vsu组建成功之后，主备同步，主机把它的vsu配置文件同步给了备机，备机运行了同步过来的配置文件导致异常；
-
实际它的VSU配置应该如下；
-
协调后台研发分析明确是当前软件版本存在bug导致；
三、故障根因说明
故障根因原理说明：当前11.4(1)B12P8版本配置switch cfg_mode single情况下，需要通过读取配置文件的SN和设备实际SN对switchID进行区分赋值，研发分析代码发现由于软件配置读取存在时序BUG问题，会导致设备取不到自身实际SN。因此设备实际SN与配置文件中SN比对时，两个值不一致，触发默认赋值逻辑，给设备号SwitchID默认赋值为1；从而导致两台设备SwitchID均为1，产生了SwitchID冲突，无法正常组建VSU。
时序问题详细解析如下：
single模式下：vsu私有配置保存在config.text（全局配置文件）里。
single模式下读取配置文件里的SN号是调用vsu_cfg_get_devid_from_gefg_file方法。
get_backplane_info方法是获取设备实际SN的。
vsu_cfg_get_devid_from_gefg_file方法内部还调用了get_backplane_info方法，用来比对两个SN是否一致。
正常情况下，get_backplane_info方法和vsu_cfg_get_devid_from_gefg_file方法获取到的配置内SN和设备实际SN是一致的，就能按照全局配置文件里定义的switchID正常给设备赋值。
异常原因是get_backplane_info还没读取到设备实际SN，vsu_cfg_get_devid_from_gefg_file就去调用了get_backplane_info，导致返回了设备实际SN为空，与配置中读取到的SN号不一致，此时触发默认赋值逻辑，给设备SwitchID默认赋值为1。四、故障解决方案
-
临时解决方案： 先取消switch cfg_mode single，配置为 switch cfg_mode normal，等待VSU组建完成后，再配置上switch cfg_mode single可规避上述临时故障问题，但是如果设备重启故障又会复现，所以不作为最终推荐方案
-
彻底解决方案：
该问题在我司阿里专有云推荐版本11.4(1)B12P32中已经得到解决，建议将现场设备软件版本升级到我司阿里专有云推荐版本11.4(1)B12P32
阅读剩余
版权声明：
作者：SE_You
链接：https://www.cnesa.cn/3250.html
文章版权归作者所有，未经允许请勿转载。
THE END
