我有一台出现故障的 Cisco 2811。它通过 Call Manager Express 为我们 20 人的办公室提供互联网和电话服务。但最近电话无法正常工作，互联网也不稳定。连接到我们 ISP 的外部接口没有问题。内部接口连接到 2960，我们的内部网络连接在那里。在 show interface 中存在明显问题：
FastEthernet0/1 is up, line protocol is up
Hardware is MV96340 Ethernet, address is 001b.d40a.e071 (bia 001b.d40a.e071)
Internet address is 192.168.1.254/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 13/255, rxload 19/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
Keepalive not set
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:54:10
Input queue: 1/150/420/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 7463000 bits/sec, 1038 packets/sec
5 minute output rate 5244000 bits/sec, 880 packets/sec
3021883 packets input, 2691686783 bytes
Received 7649 broadcasts, 0 runts, 0 giants, 95 throttles
2155 input errors, 0 CRC, 0 frame, 0 overrun, 2155 ignored
0 watchdog
0 input packets with dribble condition detected
2537251 packets output, 1717084791 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
464 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
我已经用一根全新的电缆替换了这根电缆，但没有任何效果。我已在它所连接的 2960 上设置了 switchport nonegotiate。我已验证两个接口（100M，自动/自动）上的设置是否相同。我已确保 CDP 已打开，并且 keepalive 已关闭。
我今天在远程，但明天我将在 2960 上安装一个 SPAN 端口，以尝试获取更多信息。我还能做些什么来找出这些问题的根源吗？
我做了一个 sho 接口 mac 记账，一个人的电脑向路由器发送了大约 80% 的总流量...总共 3100M 字节中有 2800M 字节。我的助手检查了她的电脑，没有发现任何异常。
编辑：
根据要求，这是sh int来自交换机端口的信息：
GigabitEthernet1/0/48 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is b414.89ba.32b0 (bia b414.89ba.32b0)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 22/255, rxload 4/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:03, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 20147
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1883000 bits/sec, 693 packets/sec
5 minute output rate 8721000 bits/sec, 1020 packets/sec
64561402 packets input, 46701593519 bytes, 0 no buffer
Received 109892 broadcasts (102372 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 102372 multicast, 0 pause input
0 input packets with dribble condition detected
66138056 packets output, 36914890016 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
答案1
因此，从故障排除的背景来看，我会以这种方式来看待它。
一切都很不稳定/很慢，对吧？互联网和电话。你向我们展示了界面统计数据。我正在看这部分：
->3021883 packets input, 2691686783 bytes
->Received 7649 broadcasts, 0 runts, 0 giants, 95 throttles
->2155 input errors, 0 CRC, 0 frame, 0 overrun, 2155 ignored
->464 unknown protocol drops
首先，让我们排除简单的问题，即协议丢失和输入错误。464 次丢失占输入的 3,021,883 个数据包的 0.01%，输入错误也是类似的情况。这些事情确实偶尔会发生，你担心这一点，但我敢打赌你会说这比慢 0.01% 更糟糕，对吧？
无论如何，节流阀可能会对问题有所启发，当设备超载时就会发生节流阀。所以这可能是值得研究的事情。
然而，诊断速度缓慢是一件很麻烦的事，我真的想尝试将其与一个时间段联系起来，也许在大多数人都离开后的某个晚上待到很晚，看看它是否仍然很慢？90% 的时间里，我发现所有的缓慢都与容量有关。
因此需要检查一些事情。
- 检查 CPU 使用率（“显示进程 CPU 历史记录”）并查看是否出现任何峰值。
- 您是否在使用 QoS？检查接口上的丢包情况（“显示策略映射接口 xx/xx”
- 您运行了多少个 VLAN？如果是的话，我假设您将使用单板路由器设置？
我个人怀疑是某个地方存在某种 CPU/内存瓶颈，这不会显示在正常的接口 show 命令上。从您粘贴的 show 命令中，我没有看到任何“真正的”问题，没有任何会引起明显问题的东西。
另外，重新启动一下。你永远不知道 :)
答案2
尝试关闭交换机接口上的 DTP。switchport nonegotiate由于路由器不是交换机，因此它无法理解动态中继协议。
答案3
Artanix 提出了一些很好的故障排除技巧，这是解决路由器问题的好方法。
我还使用了一些故障排除技巧这里因为路由器的 CPU 使用率经常徘徊在 99-100%。
通过 NetFlow 配置 MAC 地址记帐（如上所述）这里) 让我找到了一台设备，它产生了 Fa0/1 接口上 80% 的流量。我的实习生将其追溯到一台计算机，没有发现任何可以归咎于它的原因，但我在 MS Outlook 中检查了她的发件箱……她向我们另一个城市的办公室的同事发送了一封附件超过 50MB 的电子邮件（我们的发件大小限制为 40MB）。
根据我的 SPAN 会话，邮件服务器会尽职尽责地接收所有这些数据，然后告诉 Outlook 它已超出大小限制，并断开连接。Outlook 知道它尚未发送邮件，因此继续尝试再次发送，而且非常积极。我不知道为什么错误消息没有返回，但我怀疑这与 Outlook 认为邮件服务器的带宽很便宜有关。
一旦我们从发件箱中删除了这封邮件，并就如何使用文件服务器传输大文件而不是电子邮件进行了一次小讲座，CPU 使用率就会回落到正常的 40-60% 范围，电话和网络也会恢复正常状态，界面上的节流阀也会恢复为零。
所以，这解决了问题，并使问题变得相对毫无意义。我仍然不知道未知协议是什么，但我确信我的 SPAN 会话已列出它们。