cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
715
Views
0
Helpful
11
Replies

buffers

sweigle
Level 1
Level 1

Hi all,

I have a 2851ISR with 256MB of memory using adventerpriseK9 12.4(11)XW5. 2 weeks ago I began monitoring the buffers and I have noticed buffer misses on small buffers, middle buffers, Big buffers, and Verbig buffers. I then looked at Cisco's documentation on tweaking the buffers and used their rules for each buffer. However, I'm still noticing buffer misses and failures. Fortunately, the failures are not because of memory. The CPU is always under 10% and mostly under 3%. I used the show buffers assigned command and noticed there are a lot of buffers allocated to a dot11 interface. This interface is bridged using irb. When I perform a show buffers leak, the dot11 interface has alot of entries. Is this normal for a bridged interface? And since the CPU and memory do not seem to having issues, should I worry about buffer misses and failures?

thanks

scott

1 Accepted Solution

Accepted Solutions

1) You need to classify the traffic

2) You need to mark that traffic

3) You need to allocate bandwidth or limit user traffic.

The problem with QoS is that you taking away from some application to give to another application. I don't have a clear picture of your network so I can't make a recommendation nor I'm planning to. QoS is one of those features where you need a full understanding of your network else something may break.

I highly suggest you take a moment and read the QoS documentation and see which method works best for your environment.

http://www.cisco.com/en/US/docs/ios/12_4/qos/configuration/guide/hqos_c.html

HTH,

__

Edison.

View solution in original post

11 Replies 11

Edison Ortiz
Hall of Fame
Hall of Fame

should I worry about buffer misses and failures?

It depends on the % from those numbers when computed against the hits.

What's your current %?

Do you have any input/output drops in the interface?

__

Edison.

Hi Edison!

Here are more details:

Buffer elements:

1067 in free list (1119 max allowed)

169317868 hits, 0 misses, 619 created

Public buffer pools:

Small buffers, 104 bytes (total 39, permanent 56, peak 89 @ 3w0d):

23 in free list (17 min, 80 max allowed)

16558686 hits, 2102 misses, 2892 trims, 2875 created

2 failures (0 no memory)

Middle buffers, 600 bytes (total 25, permanent 32, peak 112 @ 3w0d):

15 in free list (10 min, 42 max allowed)

16581186 hits, 10841 misses, 1797 trims, 1790 created

106 failures (0 no memory)

Big buffers, 1536 bytes (total 278, permanent 220, peak 278 @ 1w0d):

208 in free list (42 min, 262 max allowed)

3690335 hits, 24 misses, 14 trims, 72 created

0 failures (0 no memory)

VeryBig buffers, 4520 bytes (total 15, permanent 14, peak 15 @ 1w0d):

13 in free list (2 min, 16 max allowed)

187642 hits, 2 misses, 3 trims, 4 created

0 failures (0 no memory)

The % misses for small buffers is: 2106/16561665 = .01%

failures are only 2/16561665

The % misses for middle is:

10841/16581609 = .06%

failures are only 106/16581609

The % misses for Big is only 24/3691055. However, notice the total buffers of big stays at 278. 278 happened when I changed the permanent buffers to 220 last week. It has not changed for a week. The other buffers the total seems to change based on traffic needs.

-------------------------------------------

Serial0/0/0:0 is up, line protocol is up

Hardware is GT96K Serial

Description: T-1 to

Internet address is x.x.x.x/30

MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,

reliability 255/255, txload 250/255, rxload 21/255

Encapsulation PPP, LCP Open

Open: IPCP, loopback not set

Keepalive set (10 sec)

CRC checking enabled

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

Last clearing of "show interface" counters 3w0d

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

Queueing strategy: weighted fair

Output queue: 34/1000/64/22181 (size/max total/threshold/drops)

Conversations 1/15/256 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 1152 kilobits/sec

5 minute input rate 131000 bits/sec, 90 packets/sec

5 minute output rate 1507000 bits/sec, 204 packets/sec

28568124 packets input, 1778195707 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

386 input errors, 386 CRC, 116 frame, 59 overrun, 0 ignored, 91 abort

99000849 packets output, 646878145 bytes, 0 underruns

0 output errors, 0 collisions, 1 interface resets

0 output buffer failures, 0 output buffers swapped out

2 carrier transitions

Timeslot(s) Used:1-24, SCC: 0, Transmitter delay is 0 flags

Dot11Radio0/3/0 is up, line protocol is up

Hardware is 802.11G Radio, address is 001c.580a.a470 (bia 001c.580a.a470)

MTU 1500 bytes, BW 54000 Kbit, DLY 1000 usec,

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

Encapsulation ARPA, loopback not set

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

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

Last clearing of "show interface" counters 1w0d

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

Queueing strategy: fifo

Output queue: 0/30 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

961003 packets input, 87695068 bytes, 0 no buffer

Received 1494635 broadcasts, 0 runts, 0 giants, 3 throttles

13988 input errors, 119815 CRC, 0 frame, 0 overrun, 0 ignored

0 input packets with dribble condition detected

1479438 packets output, 2117465760 bytes, 0 underruns

2455 output errors, 0 collisions, 1 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

So to answer you question, yes, there are drops on both the serial interface and the dot11 interface.

thanks,

Scott

Your T1 is oversubscribed. Look at the output rate

5 minute output rate 1507000 bits/sec, 204 packets/sec

You need a bigger pipe. QoS may help but that's just a band-aid to a problem. How many users are behind this router and what type of application are they demanding over this WAN connection? Is this an internet facing router? If so, T1 may not cut it.

__

Edison.

Hi Edison,

OK, here is what I'm doing... I have a dedicated T-1 to the Internet and a DSL line. This router has a service policy on the the Internal Ethernet Interface that route-maps critical traffic out the serial interface. It just so happens the snap shot I took of the serial interface someone was uploading a large file through an IPSEC tunnel. This is not always the case as you can see from the attached throughput chart on the serial interface. Traffic like HTTP/HTTPS traffic will default out the DSL Path. The dot11 interface services all visitors locally here with Internet connectivity out the DSL. As you can see not much happens on the wireless visitor, but it sure seems to need lots of buffers.

thanks,

scott

Fair enough. The number of failures are very low, I wouldn't be concerned.

Failures could be attributed to bursty traffic (FTP transfer, Multicast, etc).

__

Edison.

How about the number of buffers allocated to a bridged Dot11 interface? Should I be concerned?

thanks,

Scott

Nope, no need to be concerned.

Hi Edison,

In regards to your suggestion of QoS, how would I properly rate limit this so that someone uploading a large file would not hog the entire T-1 if another resource needed bandwidth... While, still maintaining the route paths? Can I build a service policy that will 1st rate-limit and then set ip next-hop?

thanks,

scott

1) You need to classify the traffic

2) You need to mark that traffic

3) You need to allocate bandwidth or limit user traffic.

The problem with QoS is that you taking away from some application to give to another application. I don't have a clear picture of your network so I can't make a recommendation nor I'm planning to. QoS is one of those features where you need a full understanding of your network else something may break.

I highly suggest you take a moment and read the QoS documentation and see which method works best for your environment.

http://www.cisco.com/en/US/docs/ios/12_4/qos/configuration/guide/hqos_c.html

HTH,

__

Edison.

The buffers may change based on misses. Misses isn't a bad thing since it's basically a request to create new buffers.

High amount of failures = large amount of drops.

See my other reply, your problem isn't the buffers but an overloaded T1.

__

Edison.

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