I have a misbehaving Cisco 2811. It serves our office of 20 with internet and phones via Call Manager Express. Except that lately the phones aren't working right and internet is choppy. The outside interface attached to our ISP is fine. The inside interface is attached to a 2960 where our internal network is connected. There are obvious issues in the 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
I have replaced the cable with a brand new one, with no effect. I have set the switchport nonegotiate on the 2960 it is attached to. I have verified that the settings are the same on both interfaces (100M, Auto/Auto). I have ensured CDP is on, and keepalives are off.
I am remote today, but I'm going to put a SPAN port on the 2960 tomorrow to try to get more info. Is there anything else I can do to figure out where these problems are coming from?
I did a sho interface mac-accounting and one person's computer is sending about 80% of the total traffic to the router...2800M bytes out of 3100M bytes total. My assistant checked on her PC and found nothing out of the ordinary.
EDIT:
By request, here's the sh int
from the switch port:
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
Try tuning off DTP on the switch's interface.
switchport nonegotiate
Since the router isn't a switch, it won't understand the Dynamic Trunking Protocol.So, going off a troubleshooting background, I'd look at it this way.
Everything is choppy/slow right? Internet and phones. And you've shown us the interface statistics. I'm looking at this bit here:
First, lets eliminate the easy one, protocol drops and input errors. 464 drops accounts for 0.01% of those 3,021,883 packets input, again the input errors are a similar story. These things do happen occasionally, it is a concern that you have any, but I'm willing to bet you would say its worse than 0.01% slower right?
So anyway, the throttles may shed some light on the issues, throttles happen when then the device is overloaded. So that might be something to look into.
Slowness is a pain in the bum to diagnose though, I'd really try to tie it down to a time period, maybe stay late one night when most people have gone and see if its still slow? 90% of the time, I've found all slowness is capacity related.
So a few things to check.
I personally suspect some sort of CPU/Memory bottleneck somewhere, this wont show up on normal interface show commands. From the show command you've pasted, I don't see any "real" problems, nothing that would be causing noticeable issues.
Also, give it a reboot. You never know :)
Artanix suggested some great troubleshooting tips, which are a great way to get started on a router issue.
I also used some of the troubleshooting tips here because the CPU usage on the router regularly pegged at 99-100%.
Configuring MAC address accounting via NetFlow (as described here) led me to a single device that was generating 80% of the traffic coming in on the Fa0/1 interface. Tracing that to a single computer, my intern found nothing he could lay blame to, but I checked her outbox in MS Outlook...she had sent an email with attachments over 50MB (our outgoing size limit is 40MB) to a co-worker in our office in another city.
According to my SPAN session, the mail server would dutifully receive all this data, then tell Outlook it was over the size limit, and drop the connection. Outlook, knowing that it had not yet sent the message, continued to attempt to send it over again, and very aggressively. I don't know why the error messages weren't getting back through, but I suspect that it had something to do with Outlook assuming bandwidth to the mail server being cheap.
Once we deleted this mail message from the outbox and had given a small lecture on using the file server to transfer large files rather than email, CPU usage fell back to the normal 40-60% range and phones and network returned to their normal state, and throttles on the interface returned to zero.
So, that fixed the problem and rendered the question relatively moot. I still don't know what the unknown protocols were, but I am sure my SPAN session has them listed.