诊断交换机故障5个方法

来源：Fluke      翻译：潘凯恩

      十年前，网络相对简单，主要组成设备有Hub，交换机和路由器等。每一个都是独立的设备，可以很容易的同其他设备区分。故障诊断也比现在的网络要简单，如果你连在一个Hub上，那么用于诊断碰撞域故障的经验都可以用上。此时，故障诊断可以用一个协议分析仪，而且如果你熟悉网络基础以及协议那么这个过程可以做到非常高效。
然后交换机进入我们的视线，在交换环境中发现的错误总的来说和共享介质环境下一样，如发生了什么、谁在用和占了多少。但区别在于交换机仅局限于一个特点端口。

      交换机环境中关心的问题：
•    每个端口有多忙
•    怎样识别和追溯错误源头
•    广播风暴的源头是什么
•    转发表是否正常
•    端口上连接着的是什么站点
•    交换机有没有对某些协议和端口做限制
•    端口是否属于VLAN，如果是，那么同服务器或应用服务属于同一VLAN吗？
      你怎样确定从哪里开始查找问题？问题在于无法透视交换机环境。从OSI 2层网桥开始，到VLAN、OSI 3层以及更高的不同转发方式。高级交换功能如OSI 4层或更高层转发，负载均衡等需要更多交换机方面的知识。
      交换环境建立起一个广播域，包括了串联或并联的交换设备，如果使用3层交换，那么就有了多个广播域，这取决于VLAN的数目。极限情况下，如果交换机性能允许，可以为每个端口配置一个广播域，这也称为路由到桌面。由于不同的端口有了不同的广播域，这给故障诊断带来了很大麻烦，不同端口属于不同广播域这也占用了相当一部分CPU资源用于路由转发工作。当然，每个请求和应答都需要路由是很难想象的，这是需要避免的。不幸的是，没有一个清楚的配置信息表的情况相当普遍，如我们会发现所有服务器都被分配在一个子网或广播域里，而所有的用户被分配在不同的子网和广播域里，这实际上就使得所有请求必须进行路由。如果服务器维护必须在机房进行，那么可以考虑将服务器归于不同VLAN，且将用户分配在各服务器对应的不同VLAN。这样的配置可以使交换矩阵只用2层转发，或仅少量请求需要路由。如果服务器需要支持多个用户群，那么可以考虑安装多网卡适配器。

诊断交换机故障5项技术

      我们可以通过5种方法来查看交换机环境。每项技术提供了不同的内容，都有利有弊。同网络其他问题一样，没有一个单一的最佳办法。最合适的解决办法取决于已有的资源（如可用的工具或已配置的工具），以及采用某项测试技术时可能引起的业务中断情况。即便如此，这些技术也不能像监测就Hub环境那样监测交换机环境的网络。而且要看到交换机的所有流量也是不太可能的，大多数情况下，故障诊断假设流量经过站点与服务器间或者上联设备链路，但如果两台站点相互直接进行通信，那么流量将不经过上联链路或交换机上任何端口，除非你知道如何找到它，它才可能被检测到。

图 1基础的交换机连接示意图

      为简单起见，故障诊断模型简化为服务器连接一个交换机，如图1所示。假设出问题的用户连接在该交换机上，且通过上联口连接另一台交换机或路由器。故障诊断从用户所提报告开始，即用户反映连接服务器慢，实际上等于没说。

方法一：用TELNET或串口线连接交换机控制台

高级网管人员或其他知道交换机口令的人员一般在故障诊断过程中会查看交换机配置情况，交换机配置情况可以通过Telnet登录后查看，或者通过串口登录。

图 2 – 用RS-232串口线登录控制

      交换机配置情况可以通过上述两种方式获得，而通过配置信息大部分时候并不能给出问题原因，如交换机是否有Bug，或者配置错误。而这些配置信息在诊断交换机是否按预期设置工作倒是个好的方法，所以要验证结果，必须还要用其他交换机故障诊断方法。 
      不同的厂商或交换机型号会提供一些在线故障诊断的帮助，但需要操作人员有相当的故障诊断经验和理论基础。

方法二：连接到一个空的端口

这是最简单的交换机故障诊断方式，如连接像协议分析仪这样的工具到任意一个空闲的端口。

图 3 – 从空闲端口监测.

      连接到一个空闲交换机端口，然后将监测工具在不影响正常业务的情况下接入端口所属广播域，所接入工具同其他站点接入没有什么两样。
      很可惜，交换机（有称多口桥）只会转发极少的数据到监测口。因为它是个桥设备，所以设计时就是要阻止无关流量到达本端口。由于协议分析仪没有请求任何服务，而且通常不产生任何数据包。

图 4 – 交换机在源地址和目标地址间转发流量，
极少一部分流量被发送到其他端口，
监测工具将看到少量帧而不是每分钟上千帧

    转发到监测端口的流量几乎都是广播包，以及零星的一些目的地址未知的帧。这些帧可能是老化的转发表造成的，许多粗心的技术人员看到流量分布（接近１００％广播）而没有留意到低利用率。从而导致错误判断认为是广播风暴，或者网络此时广播利用率过大的判定结果。
    这种查看网络的方式基本没有什么用处，除非监测工具要查看广播流量。这些流量对网络发现和查找其他类的问题有用，但对连接服务慢的问题提供不了什么帮助，更好的建议是，端口流量复制（见图５），又被称为Port Alias, Port mirror或者Port Span。
    多数交换机供应商都提供端口镜像或复制的功能，用于监测工具对所配置的镜像端口进行分析。老式交换机配有一个专用口，可以被用来做镜像口，而新型交换机允许用任何口用作镜像口。
    不同供应商配置方式不一样，但镜像功能大致相同，这里需要注意的是，大多数情况下，交换机的转发技术采用过滤后送到mirror port，这意味着所有的错误将被交换机过滤，而不转发到mirror port上。此时，作为故障诊断，端口镜像有时候效率不高，因为它隐藏了交换机上的错误流量。

图 5 – 端口镜像逻辑示意图.

      另外，实际操作过程必须通过Console或Telnet来执行，也就是需要一台PC或终端以配合对交换机进行配置。尽管一部分供应商允许将镜像端口配置成双向，但通常镜像口是一个只用于接收的端口。在交换机上配置镜像口后，就可以看到我们例子中连接慢的用户和服务器的实际流量，镜像口可以镜像交换机上的任意口，包括上联口，也可以镜像多个端口或者全部其他端口，你镜像端口越多，镜像流量完全性就越差，因为达到了镜像能力上限。
      镜像端口输出能力是很重要的问题，输出端口有TX和RX，且TX方向，我们知道监测设备到交换机的流量将被交换机阻止掉，但无论TX方向是否被阻止（端口是否为双向），RX方向监测能力都是有限的。如果你监测的是一个全双工端口且速率和监测端口输出一样，那么交换机可能引起丢包。
      假设我们正好在监测服务器，而这个服务器又是连在一个全双工的百兆端口上，此时，服务器的发送方向支持百兆流量，同时，接收方向上也支持百兆流量，总共200兆的传输速率，如果你通过另外一个百兆口作镜像来监测这个端口，那么你实际用到只是交换机到监测工具方向的，能够镜像的最大容量上限为100Mbps，任何超过链路容量（200Mbps）50%的流量都将被丢弃。
      如果镜像了多端口，情况可能更糟，因为大多数交换机工作时流量远低于上限容量，所以问题不一定能马上显现，大多数用户连接利用率都很小，但有时候突发流量将会很大。

图 6 – 镜像端口输出能力限制

    这种情况在使用了高速端口时会好转，如果图6中，百兆口换作千兆口，那么200M的流量可以很轻易的接收下来。

方法三：在链路中串入Hub

    在监测工具和交换机中引入共享介质Hub，多数网络中，文件服务器资源通过传输和接收实现共享，在交换机端口和服务器之间加入共享式的Hub，这样分析仪可以连接到同一个碰撞域，如图7所示，使得分析仪可以看到所有进出文件服务器的流量，从而帮助网管人员分析相当多的网络问题，如用户登录失败，网络性能差，连接中断等。

图 7 – 采用Hub监测交换机端口

      这种方法很多时候很难实现，尤其是在监测多服务器的流量时，Hub应当接在哪里？在所有服务器上吗？如果选择需要监测时接入Hub，那你是不是打算每次都要为了安装Hub而中断网络？这些时间将导致连接线程中断。另外，Hub有时不支持所要分析的端口。但用Hub分析确实是一个监测流量和错误的有效办法，这也是看全交换机环境中实际流量的好办法。与此相比，虽然通过SNMP协议也可以知道流量和错误，但要更好的进行分析，这种方法更直接。
      这种方法主要有两个缺点，如服务器不能使用全双工连接，或由双工不匹配引起更多的错误，而现在有很多Hub是交换式的Hub，如果采用了这种Hub进行测试，你将看不到所想测的流量，这就等同于加入了另外一个交换机在链路里，对测试没有一点用处。双速率Hub 10/100M可支持不同的速率，为不同速率提供不同的碰撞域，不同速率间设置桥隔离碰撞，这种情况下，需要确保分析端口的速率和监测诊断工具速率相同。另外有的Hub在所有端口设置了桥，俗称Low-cost交换机，此类Hub不适用于本方法。

方法四：用Tap或分路器

      这种方法类似于加入共享Hub，除了被接入Tap的链路中测试仪只能接收不能发送。Tap和分路器实质是一种东西，区别是分路器一般用于光纤链路，在光纤链路上，分路器按一定比例操作，即传输链路中的光能量和被分路的光能量之比，典型值为80：20，70：30或50：50，按第一种比例，80%的光能量通过而20%被分路到测试仪。这种光损耗也意味着如果光链路经过了过量损耗或距离超长，那么分路器将导致光链路失败，因为此时分路器减少了实际光主通道中的能量，一个分路器有时可引起3dB的光损耗。另外，光分路器不需要加电，通过分路器件可以准确地进行能量分路，但必须注意不要把输入输出方向弄反了。

图 8 –采用Tap或分路器

      由于Tap需要读取流经的网络流量，铜缆Tap同样也会引起信号衰减问题。对于铜缆，这等同于衰减，同样在安装过程中也可能引起连接中断。铜缆Tap需要电源供电，因为信号复制和重发到镜像口，如果设计合理，掉电不会引起网络中断。接入Tap监测是一种非常理想的监测方法，它可以监测整个所连链路上的流量，一旦安装完毕后，对所连设备来讲，它是透明的，可以随时进行分析而不中断网络，但使用Tap分析前，必须断开网络，而且Tap和分路器单独提供每个方向上的流量，这就意味着发送和接收有两个分析口。
      如想要同时监测流经链路的请求和响应流量，必须要用带有两个分析口的分析工具，带有双输入端口的分析工具可以单独分析几组输入，或者将数据量合并后分析。一次分析一个方向流量，这样交替分析，实际是很困难的。分析半双工和全双工没有什么大的区别，要么用单口分析工具轮流分析Tap不同输出口，有么用多口分析工具同时分析Tap的两个端口。

图 9 – Tap功能原理图

方法5：通过SNMP查询

    最有效的诊断交换网络的方法是询问交换机网络情况如何，这可以通过SNMP或者Console方式来获得，显然，Console方式查询有局限性，因为你必须通过串口线连接到每个交换机。SNMP是比较好的解决办法，由于它可以从网络任何地方通过带内查询，而且不需要额外的硬件设备。如果你已经部署了网管系统，你可以配置SNMP trap来发送异常情况，如利用率、错误、或其他参数超过特定门限，然后用网管工具或网络监测工具查看引起故障的原因。
    交换机一般都有SNMP代理功能，主要区别是提供数据的多少，很多便宜的交换机只提供交换机描述信息，而价格贵的交换机却能提供每个端口非常详细的信息。
SNMP可能是最常用且最小影响网络的交换网络监测方法，SNMP控制台不必位于监测设备旁，即便中间存在路由，并且在控制台中中的安全设置保障同交换机代理的正常访问。

图 10 – 用 SNMP查看交换机

      因为交换机不转发错误，使用SNMP可能是定位错误较好的一个办法。交换机虽然不转发错误，但是它可以统计到错误，这根据不同交换机支持MIB不同而有差异，每个MIB给控制台略微不同或更详细的交换机工作信息，另外，对于私有MIB，不同交换机有自定义的MIB。而标准MIB可以很高效的监测一个交换网络，下面列出的是故障诊断非常有用的MIB，尽管也有比这些更好的。
 
RFC 1213 – MIB II
RFC 1643 – Ethernet-Like Interface MIB
RFC 2819 – RMON Ethernet
RFC 2021 – RMON 2
RFC 2613 – SMON

      许多RFC经过了更新和增加，所以建议经常检查一下RFC索引，以便及时更新。例如，RFC1213更新或增加了至少5次（2011，2012，2013，2358和2665）。另外，除了RFC定义的这些包括利用率、错误的MIB，还有像bridge MIB（RFC 1493）对故障诊断也是很有帮助的。

      安全问题是使用SNMP监测网络时的突出问题，如果SNMP代理不加限制，那么任何人任何地方都可以监测你的网络甚至修改你的交换机配置，通常交换机在出售时带有通用密码，SNMP密码有称为通讯字符串，对大小写和符号都区分，通讯字符串以明文传输，存在安全隐患。而从SNMP V3版本开始针对这个漏洞提供了加密通讯。通讯字符串默认为 public。直到今天，我们很多网络中交换机设备你还是可以通过public字符串进行访问，简直不可思议。
      最少，默认的通讯字符串必须改掉，SNMP代理可以配置为根据不同字符串进行不同级别的访问，如通过一个特定的子网访问，通过一个特定的IP地址访问或者其他等等配置。路由器提供了访问SNMP代理的路径，也增加一些限制，如防火墙可能阻止了SNMP协议。而且即便你可以通过SNMP进行访问，也必须是代理支持你想要查询的MIB，大部分厂家支持标准MIB，然而，也有一些厂家不支持。有时，对交换机OS升级从而支持希望的MIB是很有必要的。当然，极少情况下，我们还会碰到通过SNMP读出的数据不正确，这虽然很少发生，但编程错误也有可能引起这类问题。

      这里有很多原因导致交换机对SNMP查询不响应，但一旦这些访问问题解决了，那么SNMP查询将是一个非常高效的监测流量的工具。

总结

      故障诊断最常用方式是等用户抱怨，但用户的话需要打折扣，因为它不一定描述准确，但却是很有效的。用户对正常时的网络最有体会，任何感觉比正常性能有所下降都会引来对网管人员的抱怨，当用户开始抱怨时，那么你可以开始进行故障诊断了，首先就从他所连的那个信息点的连接开始。但这种方法是事后的。
      我们更理想的是要一种事前防范的方法。事前做工作以防止问题扩大到影响到用户工作，这包括定期检查交换机，交换机端口性能状况查询，实施一些策略，如长期监测某些交换机端口，或用工具透视交换网络，这样才可以使你从排除故障的工作方式到防止故障的工作方式转变。