04-24-2007 08:19 AM - edited 03-05-2019 03:39 PM
I have a 10 MB Metro Ethernet link that is incrementing input drops. It is terminated on a 7606 router. I have tried adjusting the hold queue but even with this increased, they still increment. No other errors are incrementing. Is there a way to resolve this? Thanks
04-24-2007 09:15 AM
Did you force the speed/duplex on the 7606 LAN interface to match the network speed ? (10/FD)
04-24-2007 09:57 AM
Yes. It is hard coded for 10 full. There are not CRC's so I was assuming it was not a duplex issue. The only errors incrementing are input drops. I read that changing the hold queue helps but it did not stop them from incrementing.
04-24-2007 10:16 AM
Do you see high CPU utilization in the router?
Can you post the output of..
show int
show proc cpu
show buffers
HTH
Sundar
04-24-2007 10:45 AM
The CPU util is low. It is a 7606 router. Below is the output you requrested. Thanks.
-----
GigabitEthernet1/9 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 000b.45b6.b500 (bia 000b.45b6.b500)
Description: VON link to GrandDunes
Internet address is 10.100.10.1/16
MTU 1500 bytes, BW 10000 Kbit, DLY 10 usec,
reliability 255/255, txload 48/255, rxload 17/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 10Mb/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 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 22:28:53
Input queue: 0/1500/5403/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fair queuing
Output queue: 0/40 (size/max)
5 minute input rate 701000 bits/sec, 608 packets/sec
5 minute output rate 1903000 bits/sec, 671 packets/sec
L2 Switched: ucast: 150759 pkt, 11818916 bytes - mcast: 74042 pkt, 9622997 byt
es
L3 in Switched: ucast: 19035558 pkt, 2883736916 bytes - mcast: 0 pkt, 0 bytes
mcast
L3 out Switched: ucast: 20769037 pkt, 6041045645 bytes mcast: 0 pkt, 0 bytes
29365314 packets input, 3955041942 bytes, 0 no buffer
Received 123747 broadcasts, 0 runts, 0 giants, 0 throttles
5403 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
30995293 packets output, 7101186057 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 output buffer failures, 0 output buffers swapped out
------------------
FC_7606#sh proc cpu
CPU utilization for five seconds: 2%/2%; one minute: 1%; five minutes: 2%
---------
FC_7606#sh buffers
Buffer elements:
498 in free list (500 max allowed)
155699527 hits, 0 misses, 0 created
Public buffer pools:
Small buffers, 104 bytes (total 1024, permanent 1024):
1012 in free list (128 min, 2048 max allowed)
123984006 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Medium buffers, 256 bytes (total 3000, permanent 3000):
2999 in free list (64 min, 3000 max allowed)
18629245 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Middle buffers, 600 bytes (total 512, permanent 512):
510 in free list (64 min, 1024 max allowed)
2821814 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Big buffers, 1536 bytes (total 1000, permanent 1000):
1000 in free list (64 min, 1000 max allowed)
11928231 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
VeryBig buffers, 4520 bytes (total 10, permanent 10):
10 in free list (0 min, 100 max allowed)
73 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Large buffers, 5024 bytes (total 2, permanent 2):
2 in free list (0 min, 10 max allowed)
0 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Huge buffers, 18024 bytes (total 2, permanent 2):
2 in free list (0 min, 4 max allowed)
22 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Interface buffer pools:
EOBC0/0 buffers, 1524 bytes (total 2400, permanent 2400):
1200 in free list (0 min, 2400 max allowed)
1200 hits, 0 fallbacks
1200 max cache size, 686 in cache
138254083 hits in cache, 0 misses in cache
IPC buffers, 4096 bytes (total 336, permanent 336):
336 in free list (112 min, 1120 max allowed)
8301081 hits, 0 fallbacks, 0 trims, 0 created
0 failures (0 no memory)
Private Huge IPC buffers, 18024 bytes (total 2, permanent 2):
2 in free list (1 min, 4 max allowed)
21 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Private Huge buffers, 65280 bytes (total 2, permanent 2):
2 in free list (1 min, 4 max allowed)
0 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
04-24-2007 11:06 AM
The output you posted doesn't contain any clues to identify the cause of the input drops. Though you shouldn't be seeing input drops in ideal circumstances the # of drops are minimal considering the volume of traffic received on the interface. I am assuming you mayn't be seeing any drops incrementing at this time as I don't see any packets sitting in the input queue.
The best time to troubleshoot this is when the problem is happening. When the size counter in 'Input queue: 0/1500/5403/0' shows packets look at netflow/ip accounting stats to identify any anomaly that may be causing a lot of packets to be process switched. If you aren't already doing CEF switching enable CEF and that may help.
HTH
Sundar
04-24-2007 11:09 AM
Do I enable CEF globally or is it an interface specific command? What impact does it have if i enable it globally? Thanks.
04-24-2007 11:17 AM
Cisco's prefered switching method is CEF. Under ideal circumstances you shouldn't see any issues when enabling CEF unless there's an IOS bug or something. Yes, you need to enable CEF gloablly using the command 'ip cef' which enables CEF on all interfaces but you have the option of disabling CEF on individual interfaces.
HTH
Sundar
04-24-2007 11:36 AM
I think CEF is already enabled:
--
FC_7606#show ip cef summary
IP Distributed CEF with switching (Table Version 2618), flags=0x0
1048 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 20
21 instant recursive resolutions, 0 used background process
1048 leaves, 118 nodes, 265248 bytes, 2604 inserts, 1556 invalidations
0 load sharing elements, 0 bytes, 0 references
universal per-destination load sharing algorithm, id 23682455
3(0) CEF resets, 24 revisions of existing leaves
Resolution Timer: Exponential (currently 1s, peak 1s)
24 in-place/0 aborted modifications
refcounts: 32441 leaf, 30464 node
Table epoch: 0 (1048 entries at this epoch)
Adjacency Table has 885 adjacencies
04-24-2007 12:08 PM
With CEF enabled you shouldn't be seeing too many packets being process switched. Just as I stated in my previous post monitor closely the traffic pattern when you are seeing drops for any clues.
HTH
Sundar
04-24-2007 10:23 AM
Have you tried replacing the patch cable going into the router LAN interface ?
04-24-2007 12:37 PM
I have not tried that. I was assuming since no lost carrier, CRC, or other types of errors were incrementing that it was not a physical issue. Only input drops are incrementing. Thanks.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: