本人小网管一名,毕业后做网络安全(就是管个防火墙、杀毒软件、准入和信息审计啥啥的)1年半多点,去年12月公司唯一的专职网管因为种种原因离职,我被公司调来兼职网管岗位,勉强撑到现在。
先简单介绍一下公司网络环境,我们公司在全国共计4各厂区,欧洲还有3个厂区。我负责全公司的网络建设和维护,当然除了总部所在的主厂区外,其他几个厂区都有人维护不用我太操心。主厂区网络,除了承担日常办公网络外,还承载着全公司的数据中心。主厂区核心为两台cisco 6509E做的VSS,国内数据中心和3个厂区用的核心是思科4500系列,其他的都是cisco 3750。主厂区核心下联,3台3750,8台3560,3台3550(公司网络也要十年以上了,部分老设备还没更换完)作为汇聚,接入层2960和2950。整个主厂区共计交换机200余台,计算机保守估计4000+。
说一下问题表现吧,公司核心自2010年升级为6509后,至今6年时间宕机的情况之前就发生过一两次,原因都是供电的问题。但到了今年6月中旬,那天下班刚到家,公司就不断有人打电话反映上不去网,回去检查后发现6509的主机重启并切换到了备机,当时并未查到原因,同时也因为没有做日志服务器(后来检查show run发现其实做了,不过前几任网管都不用,这服务器就被人忘了,检查日志发现当时存在内存报错)找不什么价值的系统日志。事情发生后,当然是先从数据中心找个有冗余的服务器装个日志工具了。从那以后,天天检查日志。直到前两天,上午九时左右,我又在6509的日志中发现了同样内存报错,就在发现的半个小时后核心再次重启切换到了备机。之后的第二天上午九时,核心备机(昨天切了就没再往回切换)再次重启切换回了主机。
截一段问题日志给大家看看:
3419: -Traceback= 41C863D0z 41C9EFC0z 426EABA0z 426EAFECz 426EB674z 426EA2E4z 40E44CBCz 40E456ECz 40E45DC8z 40E45FECz 40E4861Cz 401F2018z 40235548z 40182218z 401823D4z 41C71D0Cz
3418: -Process= "ADJ resolve process", ipl= 0, pid= 556
3417: Alternate Pool: None Free: 0 Cause: No Alternate pool
3416: Pool: I/O Free: 5008 Cause: Memory fragmentation
3415: Sep 6 09:50:49: %SYS-2-MALLOCFAIL: Memory allocation of 308 bytes failed from 0x426EBED8, alignment 32
上面的就是内存报错的日志。6月份的时候,我也没看明白是怎么回事,以为是哪个内存地址有异常导致的。这两天仔细瞅了瞅,才发现6509的IO内存耗尽导致的重启。至于IO内存怎么看,sh proc mem一下就看到了:
C6509-A>show proc mem
Processor Pool Total: 891159232 Used: 245143636 Free: 646015596
I/O Pool Total: 67108864 Used: 52429872 Free: 14678992
为了搞清原因我们当然联系经销商做售后,但出现了种种的事端(时间太久出保了,得不到cisco服务支持,哎)。
当然找外援的同时我也没闲着,一直在百度“cisco 交换机内存报错”,终于发现了一篇cisco官方的资料找到眉目,链接如下:
http://www.cisco.com/support/zh/63/mallocfail.shtml#pool
在这篇文章的最后提到了缓冲泄露耗尽内存的问题,顺道再贴两个官文:
http://www.cisco.com/MT/eval/zh/63/buffertuning.html
http://www.cisco.com/MT/eval/zh/63/bufferleak_troubleshooting.html
至于怎么查缓冲泄露,当然是看“show buffers”,我公司cisco 6509的如下:
C6509-A#show buffers
Buffer elements:
474 in free list (500 max allowed)
239627442 hits, 0 misses, 0 created
Public buffer pools:
Small buffers, 104 bytes (total 85715, permanent 1024, peak 86723 @ 2d21h):
609 in free list (128 min, 2048 max allowed)
276214906 hits, 90932 misses, 11063 trims, 95754 created
675 failures (0 no memory)
我只贴出了small buffers的,由上面可以看到,small buffers中实际的报数量是85715个,而在处理中(free list)只有609个。显然,大量未处理的包占据了内存空间,造成了缓冲泄露。如果不及时找出发包机器,IO内存又会急速下降造成6509重启。
要想查看small buffers中包括的具体信息,可以使用“show buffers pool small header”
C6509-A#show buffers pool small header
Buffer information for Small buffer at 0x4791D614
data_area 0x80290A4, refcount 1, next 0x0, flags 0x2000
linktype 7 (IP), enctype 1 (ARPA), encsize 14, rxtype 1
if_input 0x5375B288 (Vlan63), if_output 0x0 (None)
inputtime 23:31:48.172 (elapsed 4d10h)
outputtime 00:00:00.000 (elapsed never), oqnumber 65535
datagramstart 0x802911A, datagramsize 60, maximum size 308
mac_start 0x802911A, addr_start 0x802911A, info_start 0x0
network_start 0x8029128, transport_start 0x802913C, caller_pc 0x41225964
source: 192.168.63.113, destination: 224.0.0.251, id: 0x33B4, ttl: 1,
TOS: 0 prot: 17, source port 5353, destination port 5353
上面只是截取了8万多包中的一条。经过检查,可以发现在公司vlan 63中192.168.63.113、192.168.63.18等几个IP地址向224.0.0.251这个地址(明显是UDP广播包地址,网管都知道和ARP广播包一个样,都是用来发现邻居计算机的)发送了大量数据包,并积压在6509的内存中得不到处理。
在内存快速耗尽的情况下,我利用show mac address-table address XXXX.XXXX.XXXX和show arp迅速找到相应的计算机,并shutdown相应端口。其后,内存快速消耗趋势被终止了。当然,为了确定是这些电脑缘故,在shutdown一小时后,我找到了其中一台电脑,让他接入公司网络,结果是内存又开始迅速消耗。就这样,造成公司6509宕机重启的那些嫌疑计算机被找到了。
因为这几台电脑在同一vlan,并且是同一部门。我认为是病毒感染的缘故,并没有想到和苹果公司的软件有什么关系。就在当天晚间,恰好我值班,发现6509的cpu占用率突然上升到了99%(一般28%左右),通过show proc cpu sorted 5sec发现,IP input进程和mDNS进程CPU占用异常。IP input进程异常,debug开几秒抓包就行了,我好奇的是mDNS是什么东西。经过万能的百度,mDNS是苹果公司开发一种类似局域网共享、发现计算机的协议,一般存在于苹果机中,而windows系统通过安装itunes也可以实现mDNS协议。
百度,还是百度,进一步的百度mDNS的相关信息,可以发现mDNS一般使用的便是224.0.0.251地址的5353端口。就这样,我猜想这几台电脑应该是装了苹果itunes。
第二天,我将其中的三台电脑扣押了,开始慢慢研究怎么回事。作为一名网安加网管,我的想法是异常的电脑一定要看系统日志,进windows系统日志,检查了一圈,最后在其中一台电脑里面发现了Bonjour Service报错日志,其中有些报错日志中直接包含了mDNS字样。而百度Bonjour Service会发现,这是itunes一个共享服务,使用正是mDNS协议。似乎我已经找到了源头。
在另一台计算机中,我发现了一个特殊情况,更加印证了我的猜想:
这台计算机在9月份发生第二次6509宕机重启前的一个小时,具体时间是8:11:52和8:11:53,在这两秒钟的时间内Bonjour Service服务共计生成了3万余条错误日志,这也就解答了第一次宕机重启的24个小时后6509内存会突然消耗尽而发生第二次宕机。
再插一句,当我发现这几台电脑时,我的经销商也给我反馈(前面说了,设备脱保了,cisco专业的售后享受不到,只能托经销商花钱找个懂行的)。就懂行的这哥们,看了我两次故障的日志,发了个mail,表示“交换机两次重启是CPU、内存在短时间内耗尽造成的,如果硬件没有问题,就要从内网查找,很麻烦很耗时间,做不了”。结合我们两台6509的来历,一个10年买的,一直做主机,一个13年买的一直做备机,在两天时间内分别重启了一次,不大像硬件问题。我更加确信是内网有啥在捣蛋。呵呵。
总结:
上面废话太多了,主要是想分享一下经历。本文发表时,事故才出现5天时间,目前还在观察期内,我只能说90%是因为苹果公司的Bonjour(在windows的控制面板程序卸载中可以发现改名字的软件,本人屌丝一名买不起iPhone,问这几个问题电脑的哥们也不知道怎么装上的,但是确实是苹果的软件),在局域网中异常发包造成的。
我想很多企业为了实现快速转发,再来就是好配置和管理,都会采用二层构架(就是划vlan、做trunk,极少极少用路由),计算机数量多了,向我们公司这样的,下面三四千电脑,广播包(ARP)组播包(UDP)是核心最大的威胁,尤其是苹果的mDNS协议,如果在普通家庭网中,就五六台设备不会有啥事,如果放在企业中,动辄上百成千的计算机,组播包稍有不慎同样会形成风暴。