cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
729
Views
10
Helpful
9
Replies

High Queue Drop Rate on Input Packets

mdcarey15
Level 1
Level 1

I recently turned on DFM in Ciscoworks and I'm getting a ton of alerts that my interfaces have a high queue drop rate on input packets. The default queue is 75, so should I just increase the size or look into QOS? What are the negative aspects of increasing it about 75?

9 Replies 9

gpulos
Level 8
Level 8

although QoS will be a great factor in assuring mission critical data gets the priority it needs, the fact that FIFO is dropping inbound packets tells me that even with QoS, you'll problably be dropping packets. (lowest priority first)

i'd look into why your interface queue(s) are so full first. remedy the situation that is oversubscribing your interfaces and you may be able to lower your packet drops.

coupled that with QoS and you'll have a well oiled machine that can hopefully handle all packets you send it.

what is the router model? provide a show version if possible. there may be other factors contributing or there may be some other features we can look into to help remedy.

The most important thing here to notice is the fact that we're having 'input queue drops'. The input queue is used to store packets while waiting on the 'IP input' process to make a switching decision. This switching method is only used when a better switching path (CEF) cannot be used.

That being said, the most important thing we're going to want to look at is why our packets aren't being CEF switched.

Do you have 'ip cef' enabled in global config?

Do you have "no ip route-cache" under any interfaces?

If the answers are yes and no, we may be having issues with CEF, or there might be a large amount of packets destined for the router itself (maybe an attack).

To see which it is, please give us the output of:

'show cef drop'

'show cef not'

Will

In response to Will's comments, "ip cef" is not enabled globally (I'm not sure why) and we do have "ip route-cache same-interface" on every interface on this router. Here is the output you requested:

Willard2#show cef drop

CEF Drop Statistics

Slot Encap_fail Unresolved Unsupported No_route No_adj ChkSum_Err

RP 29245160 1 0 3268 0 50038

7 0 0 0 0 0 0

13 0 0 0 0 0 0

8 0 0 0 0 0 0

27 0 0 0 0 0 0

IPv6 CEF Drop Statistics

Slot Encap_fail Unresolved Unsupported No_route No_adj

RP 0 0 0 3334802 0

Willard2#show cef not

CEF Packets passed on to next switching layer

Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access Frag

RP 23216476 0 214074122 0 84200313 0 0 0

7 0 0 0 0 0 0 0 0

13 0 0 0 0 0 0 0 0

8 0 0 0 0 0 0 0 0

27 0 0 0 0 0 0 0 0

IPv6 CEF Packets passed on to next switching layer

Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access MTU

RP 4 0 1053308 0 149 25 0 0

Willard2#

Software: Version 12.2(18)SXF4, RELEASE SOFTWARE (fc1)

The other thing that gets me is this info when I do a show interface:

5 minute input rate 10000 bits/sec, 6 packets/sec

5 minute output rate 30000 bits/sec, 6 packets/sec

There really doesn't appear to be that much traffic on this interface, so why all the drops?? If the traffic rates were higher, I would say we need to upgrade this FastEthernet interface to Gigabit, but I'm cannot make that judgement based on this, correct?

Another thought that I was just discussing, what if a device was connected to this network with the wrong subnet, and the address was denied by the ACL, would those packets be logged as input queue drops? And if the address is blocked by an ACL, will that address show up in the ARP table on that interface?

Looks like you're running 6500 code, which makes it exceptionally scary you have CEF disabled globally. I was almost positive the 'no ip cef' command was taken out in this case.

It is in your best interest to do an 'ip cef distributed' (or 'ip cef' if that doesn't work) globally. Once this is done, you'll stop getting these input queue drops, and your 6500 will perform MUCH faster.

As for questions about ACL and ARP:

ACL:

No, packets dropped via ACL wont show up as input queue drops (all the time). They will sit in the input queue like all other packets waiting on the processor to decide if they get dropped or not. If the processor decides they are dropped, they won't increment any counter except 'show access-list '

As for ARP:

ARP is a protocol that works within a L2 domain. Addresses outside of the ethernet segment will not show up in your ARP table, regardless of your ACL's. If an ACL prevents access from a machine on your connected ethernet segment, ARP will still contain an entry, as it is on Layer2, while ACL is on layer3+.

Sorry for the incorrect information, but on this code, there was no "ip cef" listed in the config, but it is turned on by default in this version of IOS so we are running "IP CEF enabled"

router#show ip cef summary

IP Distributed CEF with switching (Table Version 100727), flags=0x0

6922 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 77

583 instant recursive resolutions, 0 used background process

6922 leaves, 582 nodes, 1574360 bytes, 65635 inserts, 58713 invalidations

0 load sharing elements, 0 bytes, 0 references

universal per-destination load sharing algorithm, id 8E4B69A0

3(0) CEF resets, 10505 revisions of existing leaves

Resolution Timer: Exponential (currently 1s, peak 2s)

10505 in-place/0 aborted modifications

refcounts: 162509 leaf, 149248 node

Table epoch: 0 (6922 entries at this epoch)

Adjacency Table has 3468 adjacencies

3465 IPv4 adjacencies

3 IPv6 adjacencies

Makes more sense. That being the case, we want to look back to 'show cef not' to see why we're process-switching so many packets.

Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access Frag

RP 23216476 0 214074122 0 84200313 0 0 0

You can see here that 23K packets were because of 'no adjacency', or no next-hop in the TCAM.

We also have 84K packets being punted due to "Receive", or destined to the router. If all of these came in at relatively the same time, it could definately cause input queue overflows. You may consider modifying some access-lists to limit which hosts can ping/telnet/etc the router.

Some other interesting facts here: Traffic rates are extremely low, 53 packets/sec in and 89 packets/sec out. And look at the # of throttles going on this interface. Willard2#show int fa5/8

FastEthernet5/8 is up, line protocol is up (connected)

Hardware is C6k 100Mb 802.3, address is 000f.3567.4700 (bia 000f.3567.4700)

Description: HSBB0386;NM;TLT;LAN1;Willard;131A;UP

Internet address is 128.118.3.1/24

MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

reliability 255/255, txload 2/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s

input flow-control is off, output flow-control is unsupported

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:01, output 00:00:01, output hang never

Last clearing of "show interface" counters 2w5d

Input queue: 0/75/2619072/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 39000 bits/sec, 53 packets/sec

5 minute output rate 1004000 bits/sec, 89 packets/sec

L2 Switched: ucast: 63521 pkt, 5527019 bytes - mcast: 4268597 pkt, 326723535 bytes

L3 in Switched: ucast: 26015961 pkt, 16938568737 bytes - mcast: 1064 pkt, 125078 bytes mcast

L3 out Switched: ucast: 19244351 pkt, 18565351375 bytes mcast: 548470 pkt, 89510675 bytes

31687500 packets input, 17366774043 bytes, 0 no buffer

Received 5608069 broadcasts (5078 IP multicasts)

5 runts, 0 giants, 17939 throttles

5 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 0 multicast, 0 pause input

0 input packets with dribble condition detected

20355578 packets output, 18699616011 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

I guess my next step is to SPAN the port and see what type of traffic is coming to this router.

Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco