思科7600系列设备VTT故障排查流程

在最近故障处理过程中出现过一次关于思科设备所有板卡一直加载不成功的问题。

主要是一下故障现象

1:思科设备在加电后主备电源显示红灯

2:设备板卡可以看到状态灯在加载过程

3:设备板卡加载过后,直接板卡全部自动重启,无法进入命令模式。也无法远程登录所有板卡业务基本没用,此类现象断电后重启依然重复

故障处理流程和注意事项:

1:首先出现类似故障,所有板卡加载不成功,并且反复自动重启,单板故障和电源模块故障问题基本排除,因为如果引擎故障,主备引擎同时出现问题概率太低,其次可以通过插板引擎切换排除。

2:电源模块有故障,基本不会出现板卡加载的过程,如果有时间的话,可以把所有板卡都拔处,单引擎加载看是否能加载成功。

3:因为有引擎板卡加载过程的状态,通过串口线来查看加载过程告警。

观察启动过程中所有板卡加载成功后有一个启动项有关于VTT的提示

Dec  9 2016 13:14:46.624 BJ: %FABRIC-SP-5-CLEAR_BLOCK: Clear block option is off for the fabric in slot 5.

Dec  9 2016 13:14:46.708 BJ: %FABRIC-SP-5-FABRIC_MODULE_ACTIVE: The Switch Fabric Module in slot 5 became active.

Dec  9 2016 13:14:48.268 BJ: %DIAG-SP-6-RUN_MINIMUM: Module 5: Running Minimal Diagnostics...

Dec  9 2016 13:14:53.000 BJ: %DIAG-SP-6-DIAG_OK: Module 5: Passed Online Diagnostics

Dec  9 2016 13:14:53.344 BJ: %OIR-SP-6-INSCARD: Card inserted in slot 5, interfaces are now online

Dec  9 2016 13:15:05.848 BJ: %PFREDUN-SP-6-ACTIVE: Standby initializing for SSO mode

Dec  9 2016 13:15:08.252 BJ: %SYS-SP-3-LOGGER_FLUSHED: System was paused for 00:00:00 to ensure console debugging output.

Dec  9 2016 13:15:11.364 BJ: %C7600_ENV-SP-0-VTTMAJFAILED: Too many VTT failures to continue system operation

Dec  9 2016 13:15:11.364 BJ: %C7600_ENV-SP-2-SHUTDOWN_SCHEDULED: shutdown for backplane scheduled in 10 seconds

Dec  9 2016 13:15:11.384 BJ: %C7600_ENV-SP-4-VTTFAILED: VTT 1 failed

Dec  9 2016 13:15:12.904 BJ: %C7600_ENV-SP-4-VTTFAILED: VTT 2 failed

从此告警信息可以到VTT1  VTT2 两个模块 启动失败,设备会在10秒内自动关闭。

因此VTT出问题的时候,在加电后板卡引擎都会启动,但是加载到VTT 的时候就会如此反复重启。

还有一个情况,就是如果你整个机框所有板卡拔出,单独插一个新的引擎的时候由于加载速度比较快,有可能会进入配置命令行,但是过会依然如此。

如果出现类似情况大家就只能更换VTT模块、VTT模块其实官方的解释简单来说就是机框电源稳压器。

更换VTT模块的位置在7600系列交换机背后电路板上,7600背板上面一共插了有3个VTT模块,分别有数字标明是1 2 3 。

更换模块之后进入系统也可以用sh env all 命令查看,具体详细的内容可以百度搜索的大家就百度搜索。

时间: 2024-11-06 17:26:00

思科7600系列设备VTT故障排查流程的相关文章

paip.hql的调试故障排查流程总结

环境.myeclipse7.0 1 Hql的调试工具myeclipxe默认工具.../Hibernate8IDE 1 故障的排除方法overview 1 Hql调试流程 1 问题的解决Session factory not created for configuration 3 环境.myeclipse7.0 Hql的调试工具myeclipxe默认工具.../Hibernate8IDE Hibernate8IDE是一个用Swing写的图形调试工具,很棒很方便,是开发Hibernate的必备工具之

mDNS故障排查(译)

Troubleshoot and Understand mDNS Gateway on Wireless LAN Controller (WLC) 第一部分:介绍 这篇文档描述了Bonjour协议在WLC上的操作,该文档旨在协助工程师理解该工作流量的原理以及提供故障排查的指导. 第二部分:需求和前提 知识需求: Cisco建议你对Bonjour协议.在WLC配置mDNS.以及多播路由有一定的基础知识,以便你能更好的理解. 设备组件: 该文档是基于如下设备和相关软件版本完成的: AIR-CT250

服务器raid5阵列故障排查及数据恢复过程记录

[服务器故障情况概述] 今天介绍的是服务器raid5阵列因为不明原因导致阵列崩溃后的故障排查方法,以及服务器数据恢复过程.下面简单介绍一下需要恢复数据的服务器硬件配置情况:本次数据恢复案例中的服务器型号为某品牌X3850型号,服务器上组建了一个raid5磁盘阵列,阵列里包含4块成员盘和1块热备盘一共5块.服务器再正常使用过成功突然崩溃,管理员查看raid阵列状态时发现阵列中有2块硬盘掉线,热备盘没有启用.需要从服务器层面进行数据恢复操作.·[服务器数据恢复普通流程]首先关闭服务器并保证在排查故障

51CTO学习笔记--Linux运维故障排查思路与系统调优技巧视频课程(高俊峰)

51CTO学习笔记--Linux运维故障排查思路与系统调优技巧视频课程 第一课 Linux运维经验分享与思路 1.一般把主机名,写到hosts下    127.0.0.1    hostname,因为很多应用要解析到本地.oracle没有这个解析可能启动不了. 2.注释掉UUID以及MAC地址,需要绑定网卡的时候,这个可能会有影响. 3.磁盘满了无法启动,  var下木有空间,无法创创建PID等文件,导致文件无法启动,按e   进入single  然后b  重启进入单用户模式. 4.ssh登陆系

[linux]df 磁盘100%Used告警,du显示目录状态良好的故障排查

1.回顾: 某在线主机深夜连续接到告警系统的disk Used 超限告警. 登陆主机查看却遇到了困惑:在检查磁盘使用量 df –h 出来的磁盘使用量确实和告警信息一样,已经被100%占用,但是查看目录大小 du 时,却显示实际目录大小并非这样,而是有很大空闲空间. 如图:磁盘用量 df –h 结果为100%Used, 目录实际总大小 du –h –max-depth=1,显示总目录大小为60k,几乎可以忽略的使用比例. [知识准备] [linux] lsof 命令了解: lsof(list op

minidlna源码初探(二)—— SSDP设备发现的大致流程

前言: 之前有专文介绍了minidlna中的UPNP功能,内中介绍其中包含的SSDP(简单发现协议),SOAP(简单对象访问协议)等几个协议(http://blog.csdn.net/sakaue/article/details/19070735).本文将根据minidlna的程序流程,概述SSDP的流程,为下一部分ACE实现做铺垫. 设备发现的大致流程: 首先,根据UPNP的规范: 在设备加入网络,UPnP发现协议允许设备向控制点广告它的服务.它使用向一个标准地址和端口多址传送发现消息来实现.

思科4500系列与华为9300系列交换机介绍与选配

思科4500系列与华为的9300系列交换机在整个交换机产品的产品线定位来说.都属于企业核心级交换机设备,今天把思科的4500系列和华为9300系列作为一篇文章,一来是这2个产品都是目前在企业当中应用非常广泛的设备,无论是甲方(企业网管)还是乙方(系统集成商)都不陌生.二来是这2个不同厂家的核心级设备都是定位是一个级别的.所以咱们今天就把它们放在一起作为一个专题. 1思科4500系列交换机 思科的4500系列交换机定位在"企业核心级交换机"这个产品线的级别上,典型的模块化交换机,前面一直

MPLS VPN 故障排查详解—Yeslab 彭Sir笔记

Technorati 标签: CCIE,MPLS VPN,故障排查,troubleshooting,MPLS Troubleshooting主要从两个层面来进行: 1, 控制层面---路由(和LDP,CEF没有关系) 控制平面主要管的事情是CE之间能通过MPLS VPN相互能学习到路由. No.1 : CE和CE之间,检查路由相互之间是否学习到. 在图中是R10和R2. 如果R10上面没有通过R8学习到对端R2的CE路由. No.2 : 这个时候需要到R1的vrf路由表查询是否有学习到R2的路由

SQL Server 2008性能故障排查(三)——I/O

原文:SQL Server 2008性能故障排查(三)--I/O 接着上一章:CPU瓶颈 I/O瓶颈(I/O Bottlenecks): SQLServer的性能严重依赖I/O子系统.除非你的数据库完全加载到物理内存中,否则SQLServer会不断地把数据库文件从缓存池中搬进搬出,这会引起大量的I/O传输.同样地,日志记录在事务被声明为已提交前必须写入磁盘.最后,SQLServer基于许多原因使用tempdb,比如存储临时结果.排序和保持行版本.所以一个好的I/O子系统是SQLServer性能关