五千年(敝帚自珍)

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

共:💬27 🌺62
分页树展主题 · 全看首页 上页
/ 2
下页 末页
  • 家园 【原创】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)时,假如出现自动重启现象,可以以此为参考。

    关键词(Tags): #Cisco(当生)#交换机(当生)#Catalyst2912#IOS#Bug#upgrade元宝推荐:爱莲,
    • 家园 没想到萨总也是同行

      以前只知道萨是老挨踢的,没想到也是网工,哈哈。

      2912系列,那得多老了?反正我是没见过,呵呵。

      不过CISCO的东西还是比较结实耐用的,出问题的几率比国产货H3C的东东少很多(当然了,现在H3C是外企了)。我前次一个网络集成项目,从路由器到防火墙到交换机,我把全部VRP(相当于CISCO的IOS)升了一遍,有的甚至升了两三遍,为啥?因为H3C的东西实在是不地道,出场的vrp居然还有测试版的,就算是正式版,也是bug一大堆,一会vrrp抢占,一会路由器自动重启,烦得我不行了。唉,这年头,确实便宜无好货啊。

    • 家园 马和斑马的问题

      先花一个。

      老萨讲的这个事故是个个案,可从故障查找上反映了工程上的一个通用规则:影响越大,越广的问题,通常也是越简单的问题。这个不单是在IT上,在其他的工程问题上也是如此。这是当年刚做紧急事故(Emergency Responding Team)时,一个老家伙讲的。这么多年做过来,虽然处理的事故不多,可这个大原则是基本上不错的。结果是那些一动就是几个部门的大毛病,常常是手到擒来。反而是那些小毛病搞的我们非常狼狈。一整就是好几天。搞的那些操作的人怨声载道的,一说就是我们这些人没有大头儿在时候就不好玩活儿。可那儿知道大毛病是那儿都有的马,抓起来当然容易。可这些小毛病常常是斑马,稀有动物,那有那么好抓。这里面的苦也只有做的人才知道。

      • 家园 您说的对.

        感觉搞工程的原则性的东西都差不多.我是搞底层软件的,常跟客户问如何复现(duplicate)问题, 是每次都出现还是概率性问题,最怕的就是概率性问题.概率性的问题找原因很难.

    • 家园 我在国内(2500系列)和加拿大(1600系)碰见过自动重起进入

      ROMMONITOR的事情,很多年过去了,这BUG应该FIX了吧?

      在国内时候还以为是买到了水货,在加拿大又碰到, 立刻把对CISCO的信心毁了一大半:)

    • 家园 没想到和萨大算是半个同行,献花献花

      以前干的也是类似的ネットワークサポートエンジニア,不过是比较辛苦的“售前售后/安装施工全包”的那种了。

      现在总算金盆洗手,改做3GPP的ISP技术支持了。

      不过家里的Lab还有将近20台Cisco的设备,正发愁怎么处理掉呢。

    • 家园 谢谢萨先生。

      类似的问题也困扰我们,估计是相同的技术原因。送花感谢。

    • 家园 打补丁是个非常讨厌但是又不得不做的事情

      尤其是这么大规模网络的网管。

      据说有人每天起床第一件事就是登到死磕去看有没有新的版本升级。

    • 家园 CSCdw00322 是11/19/01 发现的,最先是35上

      Customer is having a memory leak with :

      IOS (tm) C3500XL Software (C3500XL-C3H2S-M), Version 12.0(5.4)WC(1)

      *Dead* process is holding more and more memory :

      14.11.01 1015:

      RBAS700E>show processes memory

      Total: 3494636, Used: 2492060, Free: 1002576

      PID TTY Allocated Freed Holding Getbufs Retbufs Process

      0 0 13825604 6944096 1522384 4353044 3874432 *Dead*

    • 家园 最爱看的是你写工作上的故事

      不过这个盼望对你来说太残忍了

    • 家园 你们公司没有定期打补丁的计划吗?

      Cisco还算好的了,如果你做过某些公司的机器一定早就会养成这个习惯了。

    • 家园 【花】偶也干差不多的活,和萨大握个手!干IT工程师确实太辛苦了!
分页树展主题 · 全看首页 上页
/ 2
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河