03-13-2008 08:24 AM - edited 03-05-2019 09:44 PM
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
Solved! Go to Solution.
03-13-2008 10:12 AM
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.
03-13-2008 08:57 AM
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.
03-13-2008 09:14 AM
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.
03-13-2008 09:14 AM
-------------------------------------------
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
03-13-2008 09:19 AM
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.
03-13-2008 09:48 AM
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
03-13-2008 09:56 AM
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.
03-13-2008 10:02 AM
How about the number of buffers allocated to a bridged Dot11 interface? Should I be concerned?
thanks,
Scott
03-13-2008 10:07 AM
Nope, no need to be concerned.
03-13-2008 09:59 AM
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
03-13-2008 10:12 AM
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.
03-13-2008 09:22 AM
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.
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: