主题：【原创】Cisco Catalyst 2912机的一个潜在问题 -- 萨苏

外链图片需谨慎，可能会被源头改

今天出问题的设备 -- Cisco Catalyst 2912 L2 Switch

萨虽然喜欢写点儿东西，但很少涉及自己的专业，为什么呢？ -- 一天十几个钟头对着这些铁家伙，就算路由器个个长得象徐若瑄你也会审美疲劳吧，何况，Cisco或者Baynetwork的那些玩意儿长得连葛优都没法比呢？

写东西就是为了放松一下，所以我轻易不愿意把自己放到这种坑里。

不过有句话说得好，坑人者终自坑也，今儿，终于忍不住往这上头靠一下儿了。原因是觉得今天碰到的案例比较特殊，说不定对同行的朋友能够有所帮助。

工程师这一行苦阿。本来计划好了带老婆孩儿坐夜行巴士，明天早上就到东京，玩儿上两天，小小魔女也可以和慕名已久的三个小鸭子交流一下犯混的经验。已经到家了电话忽然响起，就知道没好事。

因为萨挂着公司的2nd Tier（二线技术支持），说起来就是一线碰上解决不了的麻烦，才甩给你处理呢。老实说象萨这号混饭吃的作2nd Tier用处不大，干得最多的就是要么扔给三线的技术兽人来处理（个个动物凶猛），要么问题不大时候拖上俩钟头东问西问的往往问题就不医自愈了。

但是你跑不了，也得在一块儿干。

事情果然紧急。说来令人吃惊，我们公司的大量网络连接在瞬间中断，影响之大，范围之广震动了整个亚洲区。传来的消息是不但日本，而且澳大利亚，泰国等地都发生了类似的问题。总部让所有地区的2nd Tier工程师火速赶到办公室待机。

于是，迪斯尼乐园只好改明天早上飞过去了。小小魔女倒是挺理解的，看看爸爸拿起公文包，给爸爸拿来了皮鞋，说白白。 -- 出门的时候一阵歉疚，真有点儿对不住孩子。

到达公司的时候，情况依然一片混乱，一线工程师正在和所有线路厂商联系，确认今晚有无大规模的国际性网络问题 – 去年台湾地震，一下子把亚洲区的线路震掉了一半以上，大家第一个反应就是出了这样的事情。

按照工作常规，这是出现大规模网络故障后第一要作的事情，不过，萨觉得这未必对路 – 各公司和我们都有协定，一旦其网络骨干出现问题，都要用电子邮件第一时间通知我们。如果说一家公司疏忽了，或者系统被破坏了无法发出，这是可能的，但不大可能所有公司都同时出现这样的问题。

处理这样的问题，萨有自己的做法。好在2nd Tier的位置比较超然，于是我发了邮件给一家ISP（网络供应商）的客户代表，然后打电话请他给我回信。很快，回信就收到了。这样，我认为问题不是出在网络线路上。

这是因为他和我之间邮路顺畅，其公司如果发出网络故障报警，即便可能在故障期间被滞留，现在我们也没理由仍然收不到。结论就是他们根本没有报警 – 这时候问他贵公司网络有无故障是不明智的，因为他也不敢给你保票，肯定是告诉你调查以后再回复。这样做他安全了，你调查的时间也就耽误了。

既然排除了网络故障，此后的调查就有些茫然 – 这种大规模的故障，如果只发生在我们一家，我会推测和电源系统有关，也可能是某台机器的故障或者不合理设置导致路由混乱。可是，亚洲区很多部门同时出现故障，就不可能是这种事情了，设备掉电也没有约好了一起来的。

这种时候，谁也没有什么好办法，唯一的处理之到就是一面加强监控，一面冷静下来踏实工作。

十分钟以后，我在分析问题的电话会议上向各部门提问 – 请各部门检查本地是否有Cisco Catalyst 2912 Switch，如果有，是否有在故障期间重新启动的现象。

各出现故障的部门很快报告 – 有，而且有重新启动的纪录。

Catalyst 2912,是Cisco公司的老牌产品，对于其他网络设备来说作用活象电源插座之于家用电器，虽不起眼却很关键。它重新启动，其他网络设备之间的联系就被切断了，自然出现大面积网络中断的现象。似乎，问题的答案已经呼之欲出。

萨怎么找到答案的呢？应该说是借助工具而且运气较好。

萨的做法也很常规，我们公司使用的网络设备多为Cisco公司的产品，他们的系统信息内容很丰富。于是，我让一线工程师收集所有涉及的网络设备上面的四种信息 –

sh ver

sh log

sh tech

sh int

之所以列出命令，是因为这些命令的结果我觉得对同样干这一行的朋友分析网络故障问题很有帮助。

其中，sh log 和sh tech所得的内容丰富，是很多网络同仁青睐的工具，sh int 可以帮助检验连接它的线路质量，而sh ver表面含义仅仅是提供产品的型号，软件版本，不大起眼，但我的看法这个命令能够给出相当多设备的基本状况，其情报价值不可多得 – 实际工作不是考试，自然没有难度要求，很多看来可怕的事故，其实原因都很单纯，往往在sh ver这样最简单的分析工具面前原形毕露。

这一次，纯粹是蒙对了。萨先看sh ver，很快就发现其中一台Catalyst 2912 Switch 的sh ver信息有些古怪，内容如下

ROM: Bootstrap program is C2900XL boot loader

GExxxxxxxx uptime is 48 minutes

System returned to ROM by reload

System restarted at xx:xx:28 UTC Fri Jul 20 2007

System image file is "flash:c2900XL-c3h2s-mz-120.5.2-XU.bin"

uptime is 48 minutes显示这台机器曾在48分钟前被重新启动过，那正是故障发生的时间。

那个时间我们肯定没有重新启动它，这机器的管理权是我们公司总部，他们也没理由重新启动该机阿。

带着这个疑问，我快速审阅了其他机器的sh ver结果，发现所有Catalyst 2912机都曾在那时发生重新启动，同时，也只有这一种机器发生问题，其他机型工作正常。

这种分析，带有一种抓小偷的有趣。

找到问题所在就好办了，公司马上与Cisco联系，让他们确认Catalyst 2912是否存在这样的问题。

实际上，当时所有的2nd Tier都在尽可能想办法，寻找问题根源，萨找到问题所在，倒不是比其他工程师水平高，而主要应该归结于运气，如果不是先看sh ver，而是先看sh tech，只怕到此时一台的内容还没看完呢。另外，萨工作的时候脾气急，一般做事上手也比较快，缺点是深入的分析整理就差一些，文档常常需要一改再改。

听到大家纷纷汇总当地同型号机器出现了一样的问题，萨反而感到有一丝疑惑 – 这些机器已经用了四五年了，为何现在才出故障？

据此，萨推断这次故障的原因是遭到了黑客的攻击。黑客利用某种程序进入我公司的Catalyst2912机内部，登陆成功后发布重新启动指令，因为可能用批命令的方式同时攻击各处，所以问题在同一时刻发生。

今天可是星期五呢。

萨觉得自己这个分析存在一定道理，于是，立即要求管理员不管三七二十一先修改接入的ACL和Password，这是为了避免黑客再次光临，用同样的方法渗透进来。这种匆忙的修改让一线工程师感到苦恼 – 这东西一个改的不好，自己就进不去了！但是，现实很快就证明我的看法是片面的。

Cisco公司的回信很快说明这种机器确实有这个问题，他们还专门发了Release,标号是CSCdw00322，有兴趣的朋友可以去看看。具体的问题好像是Memory Leak，这会引发Catalyst 2912机因内存错误儿自动重新启动。解决问题的方法也很简单，把当前的IOS升级就可以了。需要升级的版本为Release 12.0(5)WC4)。

至于为何以前没有出过问题，那是因为两周前这批机器的监控系统作了些修改，记住，教训是SNMP设置内容不当，可能导致Catalyst2912内存积累错误，最终自动重新启动。

于是，找了其中一台可以暂时停掉的机器作了实验，实验倒是挺成功的，所有机器的修复也安排好了时间，看表，已经接近三点。

然而，还是不困，就坐下来写这篇文章，干这份工作，虽然苦难不少，但成功的时候那种快乐也实在诱人得很。

不一会儿，电话铃声大作，接听，却是Cisco公司打来的，说的是你们如果有Cisco3500系列的设备，也请立即进行升级。

理由？原来这个问题的影响范围包括了Catalyst 2912系列设备, 也包括了3500系列机。打来电话的那位就是确认了这个BUG的工程师，用半生不熟的英语告诉萨 – 2912和3500的资源不同，所以出现Memory Leak的时间也会不同。

赶紧，调整时间表，想起自己认为是来了黑客的错误结论，还是人家水平高啊，脸上有点儿发烧，顺口说出一句 –　“人比人得死，货比货得扔”

“单田芳？！”那边一声惊呼。

原来也是国人啊。

败在自己人手里，还算能接受吧。

系统升级调试完毕，看表，已经三点半过了。

天亮，还要去迪斯尼乐园

[完]

谨将问题的处理经过和结论与同行朋友分享，Catalyst2912虽然陈旧，但是一种使用广泛的设备，当它的IOS版本低于12.0(5)WC4)时，假如出现自动重启现象，可以以此为参考。