2.6 网络接入层问题

show interfaces 命令的输出对于检测常见介质问题非常有用。这个输出信息中最重要的部分之一，是线路和数据链路协议的状态，如示例所示。

S1# show interfaces fastEthernet 0/18

FastEthernet0/18 is up, line protocol is up (connected)

Hardware is Fast Ethernet, address is 0025.83e6.9092 (bia 0025.83e6.9092)MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

第一个参数 (FastEthernet0/1 is up) 代表硬件层，显示这个接口是否在接收载波检测信号。第二个参数 (line protocol is up) 代表数据链路层，指示是否收到数据链路层协议 keepalive 数据包。

根据 show interfaces 命令的输出信息，有可能解决以下问题：

• 如果接口（interface）处于up状态但线路协议（line protocol）状态为down，表示存在问题。这种情况的问题可能是封装类型不匹配，另一端的接口处于error-disabled（错误禁用）状态，或者硬件出现了问题。
• 如果接口（interface）和线路协议（line protocol）状态皆为down，表示没有连接线缆，或者存在其他的接口问题。例如，在背对背连接中，连接的另一端可能处于administratively down（管理关闭）状态。
• If the interface is administratively down, it has been manually disabled (the shutdown 命令已经输入）在活动配置中。

show interfaces 命令的输出信息显示了FastEthernet0/18接口的计数器和统计信息，如示例中的阴影部分所示。

S1# show interfaces fastEthernet 0/18

FastEthernet0/18 is up, line protocol is up (connected)

Hardware is Fast Ethernet, address is 0025.83e6.9092 (bia 0025.83e6.9092)

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, media type is 10/100BaseTX

input flow-control is off, output flow-control is unsupported

ARP type: ARPA, ARP Timeout 04:00:00

Last input never, output 00:00:01, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

2295197 packets input, 305539992 bytes, 0 no buffer

Received 1925500 broadcasts (74 multicasts)

0 runts, 0 giants, 0 throttles

3 input errors, 3 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 74 multicast, 0 pause input

0 input packets with dribble condition detected

3594664 packets output, 436549843 bytes, 0 underruns

8 output errors, 1790 collisions, 10 interface resets

0 unknown protocol drops

0 babbles, 235 late collision, 0 deferred

有些介质问题的严重程度不足以导致电路出现故障，但却的确可以导致网络性能出现问题。这张表说明了一些可以使用命令show interfaces检测出来的常见错误。

错误类型 描述 输入错误数。它包括残帧、 超长帧、无缓冲区、CRC、帧、溢出和被忽略的计数。残帧是一种会被丢弃的数据包 因为它小于这个介质的 数据包最小值。例如，任何以太网数据包只要小于 64 字 就会被认为是一个残帧。超长帧会被丢弃，是因为它们超过了 这个介质的数据包最大值。例如，任何以太网数据包 只要大于1,518 个字节就会被认为是一个超长帧。CRC CRC错误是因为 计算出来的校验和与接收到的校验和不相同。输出 错误数 妨碍从这个（正在查看的）接口对外传输数据报文 的所有错误总量。冲突 因为以太网冲突而 导致重传的消息总数。延迟冲突 在512比特数据帧 已经完成传输之后，才发生的冲突。

接口输入与输出错误

“输入错误" 是指这个（正在查看的）接口接收到的数据报中，所有错误的总和。包括残帧、超长帧、无缓冲区、CRC、帧、溢出和被忽略的计数。通过 show interfaces 命令可以查看到的输入错误包括：

• 残帧 – 短于 64 字节最小许可长度的以太网帧称为残帧。NIC 故障是残帧过多的常见原因，但残帧也可能是由冲突导致的。
• 超长帧 – 大于最大许可大小的以太网帧称为超长帧。
• CRC 错误 – 在以太网接口和串行接口上，CRC 错误通常说明存在介质或线缆错误。常见的原因包括电气干扰、连接松动或损坏或电缆不正确。如果看到许多 CRC 错误，且链路上噪声过多，您应该检查线缆。还应搜索并消除噪声源。

“输出错误”是阻碍从正在查看的接口最终发送数据报的所有错误总和。通过 show interfaces 命令可以查看到的输出错误包括：

• 冲突 – 在半双工模式下运行发生冲突是正常的。但是，永远不应该在全双工模式的接口上看到冲突。
• 延迟冲突 – 延迟冲突是指在帧已经传输了 512 比特之后才发生冲突。线缆长度过长是造成延迟冲突的最常见原因。另一个常见原因是双工模式配置错误。比如，一条连接的一段配置的是全双工，另一端配置的却是半双工。这时，在配置为半双工模式的接口上就有可能看到延迟冲突。在这种情况下，必须在两端配置相同的双工模式。设计、配置无误的网络绝不应该出现延迟冲突。

排除网络接入层问题

故障排除流程：

使用 show interfaces 命令检查接口状态。

如果接口状态为 down：

• 检查连接的线缆类型是否正确。另外，检查线缆和连接器是否出现了损坏。如果怀疑线缆存在问题，则应该更换线缆。
• 如果接口仍然处于 down（关闭）状态，问题可能是速率设置不匹配。接口的速率通常是自动协商的；因此，即使在一个接口上是手动完成的配置，相连的接口也会按照那个设置进行自动协商。如果由于配置错误、硬件或软件问题确实造成速率不匹配，则可能导致接口关闭。如果怀疑存在问题，就应该在连接的两端手动设置相同的速率。

如果接口已经处于启动（up）状态，但连接问题仍然存在：

• 使用 show interfaces 命令，检查是否存在噪声过大的迹象。这些迹象包括残帧、超长帧和 CRC 错误计数器值不断增加。如果噪声过多，则尽可能找到并移除噪声源。另外，应该确认线缆不超出最大电缆长度，并且检查所使用的电缆类型。
• 如果噪声不是症结，则检查是否存在大量的冲突。如果存在冲突或延迟冲突，请验证连接两端的双工设置。双工设置和速率设置差不多，往往也是自动协商的。如果显示双工不匹配，则在连接的两端手动将双工模式设置为全双工。

更新: 2025-03-11 13:27:43
原文: https://www.yuque.com/yuhui.net/network/hu2iilvn9u3i06ke