APPLE Bonjour服务导致公司网络核心Cisco 6509崩溃的案例

jinying8869

　　本人小网管一名，毕业后做网络安全（就是管个防火墙、杀毒软件、准入和信息审计啥啥的）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:>
　　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>
　　  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,>
　　  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协议，如果在普通家庭网中，就五六台设备不会有啥事，如果放在企业中，动辄上百成千的计算机，组播包稍有不慎同样会形成风暴。