交换网络环境的故障诊断

网络技术是从1990年代中期发展起来的新技术 , 它把互联网上分散的资源融为有机整体 , 实现资源的全面共享和有机协作 , 使人们能够透明地使用资源的整体能力并按需获取信息 。资源包括高性能计算机、存储资源、数据资源、信息资源、知识资源、专家资源、大型数据库、网络、传感器等 。当前的互联网只限于信息共享 , 网络则被认为是互联网发展的第三阶段 。在一个交换网络里 , 您如何确定从哪里开始动手查找问题?想深入“透视”一个交换网络是非常困难的 。首先 , 在2层交换的时候还是桥接转发方式 , 但到了3层交换却有了更高级的特性和转发规则 , 例如VLAN 。到了4层交换 , 就更加复杂了 , 出现了更高级的转发和负载均衡技术 , 故障诊断故障诊断和解决就需要更多的交换机配置知识 。
在安装完一台交换机后 , 每个交换机的半双工端口就构成了一个冲突域 。如果该端口连接了一个集线器 , 集线器下面连接若干站点 , 那么冲突域会扩大 。但随着交换产品的价格下跌 , 现在大多数新建的网络每个交换端口都只连接一个站点 。因此 , 在半双工连接情况下 , 冲突域仅针对一个单独的电缆链路 。
交换机通常是一个独立广播域的一部分 , 包括串连或者并连的任意数目的其他交换机 。如果使用了OSI模型3层的功能 , 就可以创建多广播域 , 广播域的数目与VLAN数目相等 。最极限的情况 , 如果交换机功能允许 , 每个端口可以配置为一个独立的广播域 。可以把这种情况描述为路由到桌面 。为每个端口创建一个独立的广播域后 , 故障诊断就会严格受限 。但是如果我们把每个端口设置为一个单独的广播域 , 交换机在转发流量的时候 , 每个端口都需要路由服务 , 这会占用交换机CPU的有限资源 。在网络环境中 , 对每个单独的端口进行路由请求和应答是非常困难的 , 我们应该避免这样的配置 。不幸的是 , 这种情况在实际情况中非常常见 , 网络中经常发现服务器全部在一个子网或者广播域中 , 所有的客户在另外的子网或者广播域中 。在这种情况下 , 所有的请求都必须路由 。如果维护行为限制在一个单独的服务器群里 , 那么考虑把服务器放进单独的VLAN里 。然后把使用这台服务器的用户放到同一个VLAN 。这样就可以使用2层交换的桥接方式来交换流量 , 只有很少的请求需要路由 。如果服务器支撑多于一个用户区 , 可以在服务器上多装一块网卡来实现到用户的2层交换连接 。
【交换网络环境的故障诊断】对交换机进行故障诊断的5种技术
可以采取5种基本方式来透视交换机 。每一种方法都不同 , 都有积极或者消极的一面 。类似在网络中遇到的其他问题一样 , 没有一个最好的答案 。最合适的方案往往取决于您手中可以利用到的资源(什么工具可以使用或者以前安装过什么工具) , 而且使用这些技术有可能造成服务中断 。
即使把这些方式组合起来 , 也不能监测到所连接的网络 , 在交换的环境里面 , 也不像集线器那样方便监测 。我们几乎不可能看到通过一个交换机的全部流量 。大多数的故障诊断会假设流量会在站点和所连接的服务器之间或经过故障诊断交换机uplink口通过 。而实际上如果2台主机直接传输信息的话 , 就不会使用交换机的uplink口或者任何其他的端口来交换流量 。除非你知道具体用到哪个端口 , 否则是监测不到的 。
举个例子 , 如图1 , 一台服务器接入一台交换机 。在反映有问题的用户中 , 一部分是直接与这台交换机相连 , 另外的一部分用户是由这台交换机的uplink口从其他路由器或者交换机连接上来的 。故障报告是访问服务器“慢” , 这样的故障报告对技术支持工程师来说基本上没有任何价值 。

交换网络环境的故障诊断

文章插图
图一、一个最基本的交换机环境
方法1:通过TELNET或者串行口接入服务器
高级的网络技术支持工程师或其他知道交换机密码的人在进行故障诊断时可以选择通过TELENET或者交换机的串口登陆 , 来检查交换机的配置 。(如图2)
交换网络环境的故障诊断

文章插图
图 2、使用RS-232 控制端口
交换机配置可以通过上面提到的2种方法查看 , 虽然问题不一定是配置引起的 。不管问题是操作系统有BUG还是配置不完善 , 都不能从配置列表中轻易的查看出 。配置信息在定位交换机是否像预期的那样运行上比较有用 , 但针对故障诊断就不是了 。为了验证交换机的配置 , 往往需要使用多种的交换机故障诊断方法配合 。
很多交换机都带有实时的故障诊断工具 , 因为交换机生产厂家和型号的不同 , 这些故障解决工具的特征也各不相同 。但是要使用好这些工具 , 必须依靠一定的理论知识和实际经验 。
方法2:连接到一个空闲端口
最简单的故障诊断方法是在交换机的空闲端口接入一个监测工具 , 例如协议分析仪 。
交换网络环境的故障诊断

文章插图
图3、从任意端口监测
把监测工具接入交换机的一个空闲端口 , 不用中断服务就可以查看所属广播域 。该监测工具与广播域里的其他站点一样有相同的权限 。
不幸的是 , 交换机(做为一个多端口的桥接设备)几乎不转发流量到监测端口 。因为桥接设备就是这样设计的 , 流量直转发到所属的目的端口 , 不会去其他的端口 。协议分析仪因此几乎监测不到流量 。
交换网络环境的故障诊断

文章插图
图4、交换机在源端口和目的端口之间转发流量 。非常少的流量会转到其他端口 。站点和服务器之间可能每秒钟会转发几千个帧 , 但是监测端口每分钟只能看到几个帧
转发到监测端口的流量几乎全部都是广播 , 包含一些零星的目的地址不明的帧 。这些零星的帧是由于路由转发表老化的结果 , 经常是目的端口不明的帧 。一些经验不够的技术人员看到这么高的广播(接近100%) , 却没有注意到端口利用率很低 , 就误判网络出现了广播风暴 , 其实不是 。
这样查看交换网络几乎没有用 , 因为监测工具必须获取流量 。获得的流量或者对广播域的查询对网络搜索和发现其他类型问题是有很有帮助的 , 但对解决用户连接慢的问题并没有多大的帮助 。
对大多数交换机来说 , 都有一个更好的选择 , 可以把需要监测的端口流量备份到一个专门的空闲口 。这种技术通常称为端口镜像 。
大多数交换机厂家都提供备份或镜像流量的功能 , 可以把监测工具接入交换机一个专门配置过的端口 。老的交换机必须指定一个专门的监测口做为镜像口 , 但现在大多数新的交换机可以指定任何一个端口做为镜像口 。
虽然交换机厂家实现镜像的方式各不相同 , 但是有一些基本相同的监测选项 。值得注意的是 , 几乎在所有的情况下 , 交换机在转发流量到镜像口的时候 , 同时把错误都过滤掉了 。对于故障诊断来说 , 这意味着同时过滤掉了有用的信息 。
此外 , 实际操作当中需要我们通过控制口(交换机的RS232端口) , 或者Telnet进程来配置镜像 。这意味着除了监测工具之外 , 我们通常还需要带一台电脑或者终端来对交换机进行配置 。
镜像端口经常只是一个“监听”端口 , 不过很多交换机厂家允许把该端口配置成全双工的 。配置了镜像口 , 监测工具就可以查看报告连接慢的主机和服务器之间的实际流量的备份 。镜像口可以只监测交换机的任意一个端口 , 甚至可以是Uplink口 , 也可以同时监测交换机的多个端口 。但是同时监测的端口很多的话 , 过高的流量就有可能会超过镜像口的接收能力 。
监测端口的输出能力是一个很重要的问题 。镜像口可以收 , 也可以发 。在配置的时候 , 经常关掉了镜像口发的功能 。但不管有没有关掉镜像口发的功能(不管镜像口是全双工或者不是) , 镜像口的接收能力都是有限制的 。如果被监测的全双工端口的速率和镜像口是一样的话 , 交换机在转发流量的时候很容易就会丢包 , 但是交换机不会通知您 。
假设您在监测一个以100M全双工速率连接到交换机的服务器的话 , 那么服务器在全双工工作的时候 , 服务器的收发速率都是100M , 那么总共就有了200M 。然而交换机的100M镜像口最多只能接收100M的流量 。所以任何交换机的端口(全双工的)利用率超过50%的时候 , 镜像口接收到的包就会有丢失 。
如果把多个端口镜像到一个端口 , 丢包的问题就会更加的严重 。因为大多数交换机都工作在低容量 , 这个问题并不会被立刻注意到 。大多数用户连接的平均利用率都很低 。只是偶尔会有流量的突发 。
如果选择一个高速的镜像口 , 就可以减少丢包的问题 。例如把图6中的100M镜像口换成1000M , 那么就可以很容易的接收200M的监测流量

    推荐阅读