4大交换机网络通信故障排除，简单易上手！

思科交换机一般不容易产生故障，一但产生故障，对于CCNA认证标准的学员通常都不太好检测和排除。

在本文中总结在交换机使用过程中常出现的一些小故障，以帮助学员通过认证并适应简单的工作环境。

1. 关于物理层线路连接的故障

物理层线路连接是网络正常使用的提前，不得不指出，很多时候所谓的网络故障是因为物理层线路接连所导致。

比如：连接相应桌面计算机的双绞线连接了错误的交换机接口、RJ45连接头松脱、没有连接物理线缆等。

在这里需要特别提出的是思科的交换机连接交换机使用交叉双绞线、交换机与路由器或者计算机相连使用直通双绞线。

如果您需要交换机在某个接口上进行自适应介质接口，就必须在相关的接口模式下启动auto-MDIX指令。

auto-MDIX的全称叫做automatic medium-dependent interface crossover自动介质接口交叉。

当启动这个功能后，无论接口连接的是哪种类型的线缆，交换机都能自动调节该接口使其保持正常的工作。

启动auto-MDIX有一个要求：该接口必须能自动协商速率与双工模式。

2. 关于双工模式的故障

双式模式不匹配可能会产生相关的故障。

现今网络市场上几乎所有的设备都支持全双工模式，当然除了传统的集线器(HUB)设备外，应该让所有的网络设备处于全双式的模式下。

默认情况下，思科建议将交换机的接口配置成自动协商速度与双工模式。

这样做的理由是：如果发生一个半双工的设备去连接思科的交换机。

那么，思科的交换机将把自己的全双工降级成半双工模式以适应该设备的运行，如果管理员强制要求交换机接口工作在全双工模式下，将产生接口错误。

排除的依据是使用show interfaces fastEthernet 0/1 counters errors查看接口上的错误。

如图1所示。

3. 关于接口出错的故障

交换机的接口出错通常会导致大量的数据帧。

比如：当用户发现基于TCP的应用变得非常缓慢时，从表面看上去TCP的应用变慢是乎与交换机接口故障无关。

但是进一步思考，TCP变慢的更多原因是由于TCP慢启动所致，在TCP慢启动的状态下TCP的滑动窗口尺寸将变小，而这种现象往往是交换机丢包所致。

在这种状况下，基于UDP的应用就更可怕，因为UDP根本不会重传，所以网络质量将严重下降。

所以在排除这种故障时，我们需要知道，交换机为什么丢包，这往往与交换机的接口错误有关，必须查看交换机接口的错误统计消息。

关于交换机接口的错误统计消息，可以通过show interface x/y counters errors来得到如上图1所示，现在来理解每个错误统计器的意义：

• Align-Err(对齐错误)：如果数据帧不是以偶数个八位组结束就会出现对齐错误，指示是物理层差错，一般是由于布线、交换机接口故障所引发。
• FCS-Err(帧校验错误)：帧校验错误，通常也发生在物理层，并伴随Align-Err现象。
• Xmit-Err(发送错误)：指示交换机的接口发送缓存溢出，这通常是入站和出站速率不匹配所造成的。
• Rcv-Err(接收错误)：指示交换机的接口接收缓存溢出，这通常是交换机的背板发生拥塞，导致接收缓存被堆满。在很多时候接收错误也暗示了双工模式不匹配。
• UnderSize(超短帧)：指示校验和有效，但是帧尺寸小于64字节，这表示连接到该接口的主机正在发送无效的数据帧尺寸。
• Single-Col(单一冲突)：指示在该接口成功发送数据帧之前，产生了一次冲突时会发生单一冲突错误，产生这种错误的原因是链路的使用率过高或者双工不匹配。
• Multi-Col(多次冲突)：指示在该接口成功发送数据帧之前，产生了多次冲突时会发生多次冲突错误，产生这种错误的原因是链路的使用率过高或者双工不匹配。
• Late-Col(后期冲突)：指示转发数据帧以后，才检测到的冲突，产生这种错误的原因是物理介质(比如：线缆)过长、或者双工不匹配。
• Excess-Col(过载冲突)：当数据帧连续遇到16次冲突后会被丢弃，此时就会出现过载冲突错误，产生这种错误的主要原因是链路的使用率过高、双工不匹配、网络中的设备特别是半双工设备太多。
• Carri-Sen(载波侦听)：指示该接口工作在半双工状态，根据CSMA/CD的工作原理，在半双工状态下发送数据时，需要进行冲突检测这将增加carri-sen计数器，在全双工的模式下是不使用CSMA/CD。
• Runts(残帧)：帧的尺寸小于64个字节，而且CRC错误，出现残帧的错误一般是由物理层故障或者双工模式不匹配所导致的。
• Giants(超长帧)：帧的尺寸大于1518个字节，通常出现超长帧错误是主机NIC故障所导致。

4. 关于交换机CPU的使用率过高的故障

如图2所示的交换机架构，通常交换机的架构由两个层面组成：一个控制层面、一个转发层面。

控制层面负责运行交换机的操作系统，STP、路由协议、维护路由表、执行ACL等，控制层面包括交换机的CPU和内存。

转发层面包括交换机的转发逻辑和背板，交换机的转发逻辑是交换机用于做出转发决定的硬件，该硬件负责重写数据帧头;

而交换机的背板负责物理连接到交换机的端口，它依赖于交换机的体系统架构，数据帧从交换机的入站接口进入，然后转发给交换机的背板，最后通过出站接口转发数据帧。

注意在这个过程中控制平面并不直接参与数据帧的转发操作。

所以在交换机正常工作的情况下，即便是流量转发的高峰期，交换机的CPU占用率也应该很低，因为它不直接参加流量转发。

虽然控制层面不直接参与流量转发，但是由于转发层面中的转发逻辑却来自于控制层面，因为数据帧思转发与控制层面还是存在一定的间接关系的。

这样的话，如果控制层面出现持续性的高负载，比如CPU占用率过高，这将影响交换机转发数据的速率。

所以从交换机的架构来讲，控制层面不会影响交换机的性能，但是在故障排除时还必须考虑控制层面的因素。

交换机的转发逻辑以一个叫做TCAM的专用内存体现，TCAM与交换机的CEF功能相结合，数据转发的速度将非常快。

但是一旦转发逻辑故障，比如：TCAM内存溢出，转发逻辑将无法转发流量。

此时将由交换机的CPU来完成转发流量，这将增加交换机CPU的开销，转发能力也会被降低。

或者换一句话来讲，如果交换机的CPU占用率过高，这表示交换机已经没有使用转发逻辑转发数据帧，需要及时排查故障。