Packets Input vs. Packets Overrun 2

[strensk]

I am kind of new to routers and switches, and I have just started studying for my CCNA. My boss has given me a project to work on to help me out.

Now, the background is we have a 6509, which is where we have most of our internal servers. We have a number (3 IIRC) of 2948s with a number of VLANs setup to help segment the traffic. Some users complain of slow response times to the servers/internet. So, I figured I would start by looking at the servers, then work my way down to the workstations.

I have taken a look at the stats that I have collected from showing the port interface stats. On all the servers I looked at, the number of overruns is less than 1% with lots of traffic. I have included the comparisons of about two days worth of traffic.

Data from Day 1
GigabitEthernet1/4 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 000d.ed4e.500d (bia 000d.ed4e.500d)
Description: < *** OECFP2 *** >
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Full-duplex, 1000Mb/s
input flow-control is off, output flow-control is off
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:27, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/5142396/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 255000 bits/sec, 67 packets/sec
5 minute output rate 71000 bits/sec, 70 packets/sec
8916405911 packets input, 12753116442964 bytes, 0 no buffer
Received 1720139 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 5142396 overrun, 0 ignored
0 input packets with dribble condition detected
3789982926 packets output, 553748363006 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

Data from 2 Days Later
GigabitEthernet1/4 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 000d.ed4e.500d (bia 000d.ed4e.500d)
Description: < *** OECFP2 *** >
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 12/255
Encapsulation ARPA, loopback not set
Full-duplex, 1000Mb/s
input flow-control is off, output flow-control is off
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:33, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/5476507/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 47267000 bits/sec, 3928 packets/sec
5 minute output rate 335000 bits/sec, 650 packets/sec
9394529919 packets input, 13455895528421 bytes, 0 no buffer
Received 1772991 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 5476507 overrun, 0 ignored
0 input packets with dribble condition detected
3965438427 packets output, 572186380435 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

The number of overruns in comparison to the number of packets input for those two days is way less than 1%. I am thinking the problem may lie with the desktops. Could problems with drivers, etc cause errors like this?

I know this is a lot to look at, and I may not be phrasing things correctly, but please bear with me, I'm a newb to this stuff.

Thanks in advance for any advice/answers to my questions.

 

[vipergg]

I would look at the layer 1 and layer 2 stuff on the users workstations . Make sure the nics are set up the same as the switch settings . If the switch is set as auto negotiate the nics "must" be set as auto , if the switch is hardcoded to a specific speed and duplex you must hardcode to the same settings on the nic otherwise you have speed /duplex mismatches which slows down the link a lot . If there is a problem like this it is usually evident by the number of errors, crc's etc... on the users interface . Looking at the server nic this looks normal, also if you look at it the counters on the interface have never been cleared so this has been counting since the last time the 6500 had a power down whenever that was , so clear the counters on the server int's and then look at them . Also then check the uplinks to the switches for errors and speed/duplex mismatches .

 

[RookThis]

Looking at your interfaces it shows that you are taking some input queue drops. I've added a link that discussing trouble-shooting this. Hope that helps.

Day 1 numbers:
Input queue: 0/2000/5142396/0 (size/max/drops/flushes); Total output drops: 0
Day 2 numbers:
Input queue: 0/2000/5476507/0 (size/max/drops/flushes); Total output drops: 0

http://www.cisco.com/warp/public/63/queue_drops.html#topic2