Input drops incrementing on Ethernet link

Unanswered Question
Apr 24th, 2007

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Edison Ortiz Tue, 04/24/2007 - 09:15

Did you force the speed/duplex on the 7606 LAN interface to match the network speed ? (10/FD)

mark.blanchfield Tue, 04/24/2007 - 09:57

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.

sundar.palaniappan Tue, 04/24/2007 - 10:16

Do you see high CPU utilization in the router?

Can you post the output of..

show int

show proc cpu

show buffers

HTH

Sundar

mark.blanchfield Tue, 04/24/2007 - 10:45

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)

sundar.palaniappan Tue, 04/24/2007 - 11:06

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

mark.blanchfield Tue, 04/24/2007 - 11:09

Do I enable CEF globally or is it an interface specific command? What impact does it have if i enable it globally? Thanks.

sundar.palaniappan Tue, 04/24/2007 - 11:17

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

mark.blanchfield Tue, 04/24/2007 - 11:36

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

sundar.palaniappan Tue, 04/24/2007 - 12:08

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

Edison Ortiz Tue, 04/24/2007 - 10:23

Have you tried replacing the patch cable going into the router LAN interface ?

mark.blanchfield Tue, 04/24/2007 - 12:37

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.

Actions

This Discussion