07-28-2006 08:50 AM - edited 03-03-2019 01:29 PM
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?
07-28-2006 09:26 AM
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.
07-28-2006 09:49 AM
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
07-28-2006 11:33 AM
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#
07-28-2006 11:29 AM
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?
07-28-2006 12:15 PM
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?
07-29-2006 02:11 PM
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+.
07-31-2006 04:11 AM
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
07-31-2006 09:07 AM
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.
07-31-2006 10:45 AM
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.
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: