Mailing List Archive: Input queues drops on IOS 12.3(10)

Input queues drops on IOS 12.3(10)

Mar 2, 2005, 5:22 AM

Post #1 of 3 (1191 views)

Hi,

I'm running Cisco IOS 12.3(10) (c5300-is-mz.123-10.bin) on AS5300's and am experiencing input queue drops on my FE interfaces:

Input queue: 513/512/162151/65 (size/max/drops/flushes); Total output drops: 0

FastEthernet0 buffers, 1554 bytes (total 512, permanent 512):
0 in free list (0 min, 512 max allowed)
113965 hits, 93199 fallbacks
192 max cache size, 0 in cache
945985415 hits in cache, 206948 misses in cache

Increasing the hold-queue to 2096 get the packets flowing again:

Input queue: 545/2096/162496/65 (size/max/drops/flushes); Total output drops: 0

I've captured 'sh ip cache flow', 'sh tech-support' output, going through this doesn't show me obvious evidence of who the culprit is sending packets to my FE interface, which would result in packets being queued and then resulting in input queue drops and my NASs dissapearing off the network. The NAS CPU load is only at 23% according to 'show tech-support' output. CEF is enabled globally, and CEF switching enabled on the FE:

#sh ip int fa0 | i CEF
IP CEF switching is enabled
IP CEF Feature Fast switching turbo vector
IP route-cache flags are Fast, CEF

The only traffic that I'm seeing destined to my FE is SGBP traffic to/from my other NASs. I've got ~22 NASs running SGBP in this particular POP - I am not sure that this is causing the problem though - I've seen my input queues fill up in smaller POPs, which only got two SGBP members.

Any hints/ideas on what to look for in my cache flow data? Should I increase the hold-queue to 1024 for input packets on fa0?

I've had similar issues on IOS 12.2.(19) as well. What is the current recommended code for AS5300 and AS5400's?

Already had a read at http://www.cisco.com/warp/public/63/queue_drops.html...

Cheers,
Jaco

--
bje@serendipity.org.za
the faculty of making fortunate discoveries

RE: Input queues drops on IOS 12.3(10) [ In reply to ]

oboehmer at cisco

Mar 3, 2005, 12:03 AM

Post #2 of 3 (1131 views)

Permalink

>
> I'm running Cisco IOS 12.3(10) (c5300-is-mz.123-10.bin) on AS5300's
> and am experiencing input queue drops on my FE interfaces:
>
> Input queue: 513/512/162151/65 (size/max/drops/flushes); Total
> output drops: 0
>
> Increasing the hold-queue to 2096 get the packets flowing again:
>
> Input queue: 545/2096/162496/65 (size/max/drops/flushes); Total
> output drops: 0
>

> The only traffic that I'm seeing destined to my FE is SGBP traffic
> to/from my other NASs. I've got ~22 NASs running SGBP in this
> particular POP - I am not sure that this is causing the problem
> though - I've seen my input queues fill up in smaller POPs, which
> only got two SGBP members.
>
> Any hints/ideas on what to look for in my cache flow data? Should I
> increase the hold-queue to 1024 for input packets on fa0?

Can you check "show ip traffic" if you're doing a lot of re-assembly?
I.e. when the AS5300 is used as L2TP LAC and it needs to re-assemble
fragmented L2TP-pkts? Pkt reassembly can only be done in the process
path.. This can also happen with SGBP-initiated tunnels for
Multichassis-MLPPP sessions.

> I've had similar issues on IOS 12.2.(19) as well. What is the
> current recommended code for AS5300 and AS5400's?

12.3(10b) (or 12.3(10c) which will be on CCO shortly) and 12.3(12a) are
proven releases in this environment..

oli

Re: Input queues drops on IOS 12.3(10) [ In reply to ]

bje at serendipity

Mar 3, 2005, 8:17 AM

Post #3 of 3 (1134 views)

Permalink

Hi!

On Thu 2005-03-03 (08:03), Oliver Boehmer (oboehmer) wrote:
> Can you check "show ip traffic" if you're doing a lot of re-assembly?
> I.e. when the AS5300 is used as L2TP LAC and it needs to re-assemble
> fragmented L2TP-pkts? Pkt reassembly can only be done in the process
> path.. This can also happen with SGBP-initiated tunnels for
> Multichassis-MLPPP sessions.

#show ip traffic | i reas
Frags: 6386928 reassembled, 87989 timeouts, 0 couldn't reassemble
#sh ver | i uptime
uptime is 12 weeks, 1 day, 9 hours, 9 minutes

#show ip traffic | i reas
Frags: 181055 reassembled, 662 timeouts, 0 couldn't reassemble
#sh ver | i uptime
uptime is 1 day, 4 hours, 45 minutes

#sh ip traffic | i reas
Frags: 11954057 reassembled, 48267 timeouts, 0 couldn't reassemble
#sh ver | i uptime
uptime is 5 weeks, 18 hours, 45 minutes

-Jaco

--
bje@serendipity.org.za
the faculty of making fortunate discoveries