如何识别我的Cisco 2811上的未知协议?

我有一个行事不端的思科2811,它通过Call Manager Express服务于我们的20个互联网和电话办公室。 除了最近的手机不能正常工作,互联网是波涛汹涌的。 连接到我们的ISP的外部接口是好的。 内部接口连接到我们的内部networking连接的2960。 显示界面中有明显的问题:

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 

我用一个全新的replace了电缆,没有效果。 我已经设置了交换机在它所连接的2960上进行非协商。 我已经validation两个接口(100M,Auto / Auto)的设置是相同的。 我已经确保CDP开启,Keepaliveclosures。

今天我很偏远,但是我打算在明天2960上放一个SPAN端口,试图获得更多信息。 还有什么我可以做的,以弄清楚这些问题来自哪里?

我做了一个笑接口mac-accounting,一个人的电脑发送约80%的总stream量的路由器…总计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 

所以,排除故障的背景,我会这样看。

一切都是波涛汹涌/缓慢的? 互联网和电话。 你已经向我们展示了界面统计。 我正在看这里:

  ->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 

首先,让我们消除一个简单的,协议下降和input错误。 input的3,021,883个数据包中的464个下降占0.01%,同样的input错误也是类似的。 这些事情偶尔会发生,这是一个你有任何问题,但我敢打赌,你会说它低于0.01%,比较慢吗?

因此无论如何,油门可能会对这些问题提供一些帮助,当设备过载时会发生油门。 所以这可能是需要研究的东西。

缓慢是一个痛苦的屁股来诊断,但我真的试图把它绑在一段时间,也许留一晚,当大多数人走了,看看它是否仍然缓慢? 90%的时间,我发现所有的缓慢是与容量有关。

所以有几件事要检查。

  • 检查CPU使用情况(“show process cpu history”),看看是否有任何高峰。
  • 你使用QoS吗? 检查接口上的丢弃(“show policy-map interface xx / xx)
  • 你运行多less个VLAN? 如果是的话,我假设你会使用路由器上的一个棍子的设置?

我个人怀疑某处存在某种CPU /内存瓶颈,这不会在正常的界面显示命令中显示出来。 从你粘贴的show命令中,我没有看到任何“真正的”问题,没有任何会引起明显的问题。

另外,重新启动它。 你永远不会知道 :)

尝试closures交换机接口上的DTP。 switchport nonegotiate由于路由器不是交换机,因此不会理解dynamic中继协议。

Artanix提出了一些很好的故障排除提示,这是开始处理路由器问题的好方法。

我还使用了一些故障排除提示,因为路由器上的CPU使用率通常在99-100%之间。

通过NetFlowconfigurationMAC地址计费(如此处所述),使我得到了一台设备,该设备在Fa0 / 1接口上产生了80%的stream量。 跟踪到一台电脑,我的实习生没有发现他可以指责的事情,但是我在MS Outlook里检查了她的发件箱…她给一位同事发了一封附件超过50MB的电子邮件(我们的外发大小限制为40MB)在我们在另一个城市的办公室。

根据我的SPAN会话,邮件服务器将尽职尽责地收到所有这些数据,然后告诉Outlook超出了大小限制,并且断开连接。 outlook,知道它还没有发送消息,继续尝试再次发送,并非常积极。 我不知道为什么错误信息不能恢复,但我怀疑它与Outlook有什么关系,假设邮件服务器的带宽很便宜。

一旦我们从发件箱中删除了这封邮件,并且在使用文件服务器传输大文件而不是电子邮件的小讲座上,CPU使用率回落到正常的40-60%的范围,手机和networking恢复到正常状态,并且界面上的节stream器返回到零。

所以,解决了这个问题,使问题变得比较有意义。 我仍然不知道未知的协议是什么,但我确定我的SPAN会议列出了他们。