单链路故障系列之桌面链路故障

作者:上海 尹岗

    小张所在的公司业务增长很快，两周前公司本部和分公司都安装了电视会议系统，公司本部还同时加装了多媒体平台。大家可以在公司和分公司之间随时举行电视会议，处理业务的反应速度加快了很多，而且节省了不少差旅费。在公司本部也可以进行内部各部门内的网上会议，可以同时支持10个左右的会议，并且使用DV数字摄像机作为视频信号摄取源，图像质量非常好 ，大家都非常满意。许多产品培训的介绍方式也开始改变，员工可以随时直接观看从服务器上点播的由公司产品部和培训部新近联合拍摄的DV数字音像教材，既直观清晰又不受时间限制。员工还可以直接查看各种授权的影像资料。
今天，公司总裁将利用这套多媒体系统召开网上全体员工大会，公布公司上半年的运行情况和业绩情况。会议刚开始不久，刚从法国出差回来的产品部经理肖小姐就打电话反映她的机器不能看到总裁的讲话。(客串：Joaan Xiao)

Joaan：小张呀，我是Joaan。我的机器看不到总裁讲话的图像。
小张：噢，那你刚才登录上去了吗？
Joaan：登录上去了呀，而且我还看了一下这一个多礼拜的资料，都能看见，也可以点播，但是现在开会的图像我看不到。
小张：那奇怪了，你的机器这一周没有人弄过吧？
Joaan：应该没有。
小张：那你其他的工作能做吗？比如收发E-mail、上网、查看新闻什么的。
Joaan：都可以，而且我们服务器上不是提供视频点播吗？我点播上周上载的几个图片资料看，都很好，但唯独看不见今天开会的资料。
小张：噢？这还真有点怪了，你那个多媒体会议模块没有卸载吧？
Joaan：我肯定没有卸载！当然，别人有没有卸载我不知道，待会儿开完会我们再去看吧。

半小时后会议结束，小张和Joaan 一起来到了Joaan的办公室。小张打开 Joaan 的机器,发现没有什么问题。点播服务器上的图像，资料都可以查看，检查会议模块安装正常，没发现异常。小张随即把刚才会议的图像资料从办公室要来，然后上载到服务器上。这时从Joaan的机器上很清楚流畅地点播刚才的视频录象，这样小张也感到很奇怪。

小张：Joaan，看起来你这个机器没什么问题，一切似乎都很正常。
Joaan：很正常那刚才为什么看不到？
小张：你看，现在不就能看到了吗。其实我刚才只做了一件事，就是把你的机器重启了一下。
Joaan：这么说这机器现在好了？
小张：应该是好了，你现在可以看任何服务器上的图像资料了。

Joaan继续观看，并挑选了几个资料看了看确实没有什么问题。

Joaan：好的。小张，谢谢你！

第二天，公司有个经理级的会议，总裁要宣布公司新的计划和人事任免的情况。Joaan也需要参加这个会议，由于公司会议室被原先一个新产品培训占据了，所以本次会议改在网上进行。小张为每个部门经理授权了登录权限。早上九点，会议准时开始，可就在这时小张的电话又响了。

Joaan：小张呀，快来呀！
小张：怎么啦？
Joaan：我的机器现在又看不见开会的情况了，我刚刚试着重启了一下，也不行。
小张：噢，这可真是奇怪了，我过来看看。

从Joaan办公室机器上看不到开会的图像。小张试着把机器重启，也不行。难道是机器中毒了？不会呀，所有的漏洞和补丁都打过了。小张先决定暂不进行杀毒和打补丁的工作，而是采用对比法来做初步判断。小张跑回自己的座位拿了一个笔记本电脑重新回到Joaan的办公室，把笔记本连到了网络上，但图像仍然没有出现。这是怎么回事？难道笔记本也有问题？换到别的位置再试试。小张来到隔壁的房间，拔掉一台电脑的网线，将笔记本连接上去，很快，会议的图像就出现了。由此看来，是Joaan这条链路有问题。可是不像呀！要是这条链路有问题，那他上网收邮件浏览网页时也会有问题。而且，查看以往的视频会议记录、图像文件也都没问题，点播其他的图像、节目也都没有问题，这不是很奇怪吗？小张拿起了电话打给小杨。

小张：小杨！
小杨：怎么了，是不是又要请我吃饭啦？
小张：你想什么时候吃就什么时候吃吧，反正你得帮帮我想想办法。
小杨：什么事呀？
小张：我这里有一台机器，开视频会议的时候没有图像，但是正常收发E-mail和访问网页都没有问题。
小杨：噢？那你可能是软件安装有问题或者有效带宽不够吧。
小张：软件没问题，有效带宽也是够的。
小杨：你不要以为能收发E-mail和浏览网页就表示这条链路带宽能力充足，因为收发E-mail和浏览网页，包括多数下载文件时占用的带宽都很小。一般都不会超过1兆，而你那是100兆的带宽。
小张：我们的视频点播最高的时候要用到8兆左右带宽，这时图像已经非常好了。我上次测过，瞬时最大带宽可以达到17兆，这是指单个用户的带宽。
小杨：是呀！可网上会议会超过17兆这个极限呢。
小张：肯定不会，网上会议就是总裁坐在那里讲话，图像的变化因素很小，数据流能超过1兆就已经算不错了。
小杨：那倒也是，你可以把软件重新装一下试试。
小张：软件也不必重装，因为我换了一台机器试了试，也看不见视频图像，这说明不是机器的问题，也不是软件的问题，应该是传输链路的问题。
小杨：那你就作个通道测试吧！
小张：通道测试？
小杨：对，通道传输能力测试。有效传输能力不足可能出现一些问题，比如马赛克、停顿、定格、断续音等等，不过你这个现象还不大像—因为你现在是完全看不到图像。
小张：这个测试怎么做呀？
小杨：很简单，用一个具有发包能力的工具，发送高流量数据包穿过被测通道，看看链路的数据通行能力和沿途的数据包出错率、丢包数量等，这样可以很快判断这条通道是不是有问题。
小张：我下载了一个文件，速度蛮快的，大致估算了一下能达到32兆左右的速度。这难道还不能说明通道能力好吗？
小杨：是用FTP吗？
小张：是的。
小杨：如果没有其他的用户，32兆应该还凑合，但不是最好，最好可以达到50兆以上。
小张：可我的图像带宽只有一二兆呀！
小杨：是呀，32兆多的有效带宽，足够只有1兆-2兆的准静态视频会议使用的，我建议你做一个完整的通道检测。
小张：怎么个做法你能不能简单的介绍一下。
小杨：行。通道性能测试，正如我刚才讲的，需要大流量发包，然后到对方去接收这些包，根据接收到的数量得出通道的丢包率，然后再沿途观察数据包出错的位置和出错的比例。这时观察可以用网管工具，也可以用仪器。
小张：发什么样的包呢？
小杨：一般发第二层和第三层的包，90兆以上流量。第二层的包主要是验证第二层上的传输能力，这是经常做的。如果中间牵涉到路由或者第三层的交换，那么，还可以使用IP包去贯穿它。在发包上也有一些讲究。
小张：有什么讲究？
小杨：为了考验交换机、路由器等对包的处理能力，通常以最短的数据包发送，这样可以测出丢包率，因为长字节的数据包通常考验的是传输通道中端口的内存能力，而短字节的包考虑的是它的转发能力。在短字节包测量以后，每隔一定的字节差进行类似的测试。
小张：听起来太复杂了点。
小杨：可以简化一些，一般选3级，也就是64字节、512字节和1518字节。1518字节是以太网包传输的上限，这可以考验以太网传输节点的内存的处理能力。有时侯为了进一步简化程序，只选取64字节和1518字节进行测试，可以大致的判断通道的传输能力。不过话说回来，你那里什么工具都没有，这种测试也做不了。所以，咱们说点你实际能做的。依我看还是采取老办法，替代法，你把有问题的链路的插头拔下来，插到其他的空余交换机端口上试试看。
小张：行，(过了一会儿)小杨，我试过了，还是不行。
小杨：为什么？
小张：Joaan所在的交换机端口，我都试过了，她那台交换机是16端口的，上面还有4个端口空着，4个端口我都试过了，都不行。我甚至把其他的端口拔掉，插上去试过也不行。我怀疑这台交换机有问题，但是想想又不像。因为，我可以看其他的视频点播节目，我甚至还可以看原来在举行会议时也看不到，但是上载到服务器以后，却可以看到的图像内容。种种迹象表明，应该是多媒体软件模块有问题。
小杨：但是，你刚才说在其他的位置，你可以看见的。
小张：是的。
小杨： 那你有没有仔细检查各种登录设置、口令、授权等。
小张：这个，我都试过了，没问题。
小杨：其他的位置也连着这台交换机吗？
小张：我手里没有拿拓扑图，而且拓扑图也不一定准，所以不能准确告诉你交换机上的其它用户联到哪里。但是，这台机器有16个端口，其它端口都能用，偏偏这4个空的端口不能用，这也说不过去。
小杨：准确的拓扑在处理故障时很有用，现在为了节省时间，你可以将你的笔记本插到上一级交换机上试一试。
小张：对呀，我怎么没有想想试试这个呢！

小张把笔记本电脑接到工作组交换机上，由于刚才的会议已经结束，小张决定重新开通一个仿真会议，一个没有任何主持人参与的只是用来排除故障的会议，结果笔记本上实时的会议图像出现了。小张又到桌面交换机上重复这一过程，结果看不到会议图像。

小张：小杨呀，我按你的方法试过了，工作组交换机上可以，但桌面交换机上不行。
小杨：那就比较简单了，应该是这个桌面交换机出了问题。
小张：要是桌面交换机有问题，那小杨你怎么解释同样一个会议的视频流，在实时会议的时候看不见但在上载到服务器以后点播就能看见了呢？
小杨：这个原因可能是因为传输的方式或者数据包成帧格式不同造成的，它们在传输过程中处理方式有异。
小张：这一点我倒觉得不像。同样的数据包为什么这个设备能传输而另一个设备就不能传输，要知道它们所依据的传输原理是完全一样的呀？
小杨：从其它地方可以看见实时的会议视频流这点来看，恰恰证明是传输通道的问题而不是应用软件的问题。所以我建议你做一个通道测试，做完测试你就可以很清楚的了解通道的传输能力了。你现在手头没有工具，我这就传一个软件给你，这个软件叫协议分析专家，是试用版的，它是一个功能很强的软件型协议分析仪，用它可以很清楚的了解网络当中数据包的传输内容和数量。不过软件型协议分析仪都有一个明显的弱点，那就是在网络流量高时容易造成捕包缺失，也就是我们常说的丢包。但如果被观测的流量比较低，一般不会丢包。你刚才告诉我会议视频流应该只有一二兆，所以用该软件型协议分析仪应该不会有丢包的嫌疑。
小张：怎么做呢？
小杨：你可以用它接在桌面交换机的一个镜像口上，观察镜像流量，捕获传输的低流量数据包，可以将这些数据包每个字节都读取出来分析，看看是不是你所期望的数据包。
小张：那我还得设置一个镜像口喽？
小杨：是的，设好了镜像口以后你就可以进行观察了。哪里没有观测到数据包哪里就有问题！
小张：有意思！我甚至可以逐级观察数据包的传输过程喽？
小杨：是的。你现在就把那条有问题的链路镜像到镜像端口上，然后把装好协议分析专家的笔记本接到镜像口上进行流量分析。你刚才说过流量在2兆左右，观察一下是否有你所期望的视频流出现。
小张：好的。

小张启动笔记本进行观测分析，结果只观测到一些广播和组播类型的数据包，没有目标协议和流量出现。

小张：小杨啊，视频流我看不见，是不是这样观测不行呀？
小杨：哦？那你做一个视频点播，看看是否能观测到点播的视频流。
小张：（小张依计而行）小杨，太好了，可以看见点播的视频流。
小杨：这就对了。这就说明实时的会议视频流没有传输到交换机端口，而点播的视频流却准确地出现在端口上。
小张：是的，这样看来确实是软件本身有问题。
小杨：先别急着下结论。请你把笔记本接到上级交换机的镜像端口上，然后把该交换机与桌面交换机相连的端口镜像到笔记本上，开通视频会议后进行观察。
小张：好的，让我试试。
小杨：(过了一会儿)我可以看到实时视频流了，只是流量小一点，大约只有1.3兆左右。原来有1.5兆左右。
小杨：这就对了。你现在应该重点检查桌面交换机，肯定是它的配置有什么问题。
小张：何以见得？
小杨：你先告诉我协议分析专家观察并捕获的视频流的数据包长度是多少？
小张：等等，让我看一下，长度很均匀，都是1500字节。
小杨：那请你告诉我刚才做视频点播分析的时候，从协议分析专家观测到的数据包长度是多少？
小张：嗯……大约128字节到512字节左右，比视频会议实时数据包的长度短很多。
小杨：很好。现在请你检查一下桌面交换机的端口设置，特别关注一下是不是有字节长度的限制，然后告诉我结果。你知道的，通常我们会把它的MTU设为1500字节。
小张：(过了5分钟)小杨，真的如你所说，端口长度限MTU的值被设置成了1472字节，这样，长度超过1472字节的数据包就会被桌面交换机端口丢弃。
小杨：是的。当你点播图像文件的时候，数据包的长度是512字节及以下长度的字节，但当你开通视频会议的时候，使用的是1500字节的满载长度帧，这样的数据帧是会被桌面交换机端口“干掉的”。其实这种检查还可以用更简单的Ping可变字节来检查，也就是将Ping包的字节长度设置为1500字节，这样也可以看到丢包的情况。
小张：但这样我就看不到视频流的数据结构了。
小杨：是的，但是你要知道多数的网络问题都不需要动用协议分析仪进行捕包分析的程度就可以快速地定位。协议分析仪较多地应用在对应用数据包的分析上面。
小张：可是为什么这套多媒体平台的软件模块在不同的工作背景时要区分不同的数据包长度呢？
小杨：这个嘛，主要还是为了提高效率，减少拥塞。点播的时候，希望视频流所占用的通道流量不要过高，要尽量给其它应用留下点空间，所以数据包的长度一般都不长，这样其它的应用就可以经常有机会利用数据包之间的空隙占用通道传输对应的数据。而在开通视频会议时，通常会使用广播或组播的方式传输数据包，这很容易造成整个网络的流量拥塞。为了提高传输效率，其视频流的数据包长度通常都选择比较大，这样可以相对减少数据包无效载荷的开销，在较长的数据包间隙其它低流量应用实时性要求不高的应用数据包能得以有效地传输。你所选用的多媒体平台其视频会议模块默认采用的最大帧长度，也就是1518字节(应该是有可以调整的选项的)。这样当开通视频会议时，由于前期的用户登录、认证所发送的数据包都是比较短的帧，可以正常地通过桌面交换机，因此开通过程似乎看不出什么问题。而当真正的会议视频流出现时其长度都是1518字节的长帧，超过了交换机端口1472字节的限制，所以才会出现开通认证没有问题但就是看不见图像的特殊现象。
小张：但还有一个问题，这台交换机上有12个用户，为什么他们都没有反映出现类似的问题而只有在Joaan的机器出现问题呢？
小杨：这正是需要你去验证的事情。要么，这台交换机上只有这几个端口被设置成了带限制的MTU=1472字节；要么就是其它用户没有使用视频会议而只是使用视频点播功能。谁知道呢？去检查一下吧！也许是你专门把他们设置成1472字节的限制也未必呀！
小张：(经过一番检查)小杨呀，果真是这台交换机所有端口都被配置成了1472字节限制，其它的用户都是产品部的图形工作站和数据服务器，难怪没有人向我们反映看不到图像的问题。原来产品部用户的其它机器都是接入到另外一台交换机上的。刚才我已经把端口配置全部改过来了，现在Joaan的机器已经可以正常工作了。我现在记起来了，产品部经理的办公室是后来增设的，当时因为交换机上没有多余端口，于是就把Joaan的机器接到了产品部的老式部门交换机上，而那台交换机确实是以前集成商负责安装的。由于其它用户并没有连接到该交换机上，所以只有Joaan受到影响。正好Joaan上周出差去了法国，她的机器并没有实地经受网上宽带实时会议的视频流传输质量的检验。
小杨：好了好了，我又不是你的老板，干吗急着为自己辩白呀。再说集成商将其配置成1472字节限制也可能是在有意无意间所为，我的意思其实就是想提醒你别忘了做一些定期的检查和备份的工作，这样就可以把一些故障隐患特别是那些严重的故障隐患消灭在萌芽状态，这叫未雨绸缪嘛。
小张：这倒是。我最近正采纳你的建议在做一些流量分析和通道测试，就是为了以后少出问题和不出问题，省得麻烦你。
小杨：是省得花学费吧？！网络维护的定期项目当中有半年维护和年度维护等内容，主要就是要求将网络设备和网上设备的配置检查工作安排在此间进行。我不知道你有没有对交换机、路由器等做定期的配置检查和文档备案，定期地对网络的性能和变化趋势做一些简单评估。
小张：你上次跟我建议过，我已经开始进行这方面的定期检查。不过惭愧得很，现在所进行地定期检查的内容还比较简单，我们至今还没有建立起我们的网络在正常工作状态下的状态图和设备准确配置图。至于你上次提到的灾难恢复方案，由于杂事太多还来不及做呢。不过呢，就已经做过的检查来看，这阵子还真找出了不少问题和隐患，现在的故障率已经很低了。总的来说，我这个“学生”做得还算不错吧。
小杨：别只顾着自夸了，你现在的麻烦不是来自于你管辖的网络，而是来自于应该立刻做出一项决定—确定一下今天晚上的饭局哥儿几个该到哪里凑堆儿问题。
小张：我要昏倒了。好吧，反正也被你宰惯了，也不少这一顿。

尹工点评

端口是单链路结构中的重要环节，常被维护人员所忽视。虽说以太网是由星型加树枝形结构延伸而成的复杂网络结构，交换节点特别是支持第三层交换的交换节点数量庞大，联接形式灵活，应用流量也是千差万别。但是端口的处理能力和处理过程我们还是可以检验和考察的。存在的问题和隐患可以通过定期维护的方法将其暴露出来。对端口的认证可以通过对端口的工作状态做直接的测试和对通道的认证测试来进行。
端口的直接测试也是比较简单的，主要是检查端口的物理性能和被干扰状况。比如信号强度和质量、全双工或半双工状态、端口有无激活、网管功能有无启用、端口配置是否正确、端口是否工作在所期望的状态(比如流量限制、字节限制、端口保护、转发模式自适应等等)。总的来说端口的配置虽然相对比较简单，但仍然有不少选项值得网管人员给予足够重视，一般建议将网络设备的检查程序(包括对端口状态的检查)纳入定期维护的内容中去。
另外需要强调的就是，某些病毒就是通过SNMP进行设备配置改写的，这类病毒不一定攻击网上设备，但却可能专门攻击网络设备，比如改写端口配置等，而这恰恰是被许多中小型网络的网管所忽略的地方。