On 3/1/10 7:28 PM, Javi wrote:
Guys,
I tried increasing the input queue (up to 2048) with no results, input
flushes keep going up. Users still experiencing really bad VoIP
performance in that WAN link...
clear the counters and get a few snapshots of sh int stat
with:
term exec prompt time
on...
Compare the process to fast cache counters...
Rodney, I didn't turn off SPD as I'm not sure if that is going to break
other stuff. This is a production head office main ISR router...
Any ideas?
Disable it..it will not change anything for the user traffic.
If they are seeing poor voice quality you need to double check the
direction and what class the traffic is matching along with the
corresponding 'sh policy-map int' output for it.
Thanks again,
J
On Mon, Mar 1, 2010 at 9:13 AM, Javi <[email protected]
<mailto:[email protected]>> wrote:
Thanks guys.
12.4(13r)T, we have a policy-map with 4 classes:
policy-map QOS-OUT
class DSCP-OUT-RT-VO
priority 1110 138750
police cir 1110000 bc 138750 be 138750
conform-action set-dscp-transmit ef
exceed-action set-dscp-transmit ef
violate-action set-dscp-transmit ef
class DSCP-OUT-D1-RT
bandwidth percent 7
random-detect dscp-based
random-detect dscp 34 25 75 20
random-detect dscp 36 12 24 20
service-policy QOS-OUT-D1-RT
class DSCP-OUT-D2-BA
bandwidth percent 55
random-detect dscp-based
random-detect dscp 18 61 122 20
random-detect dscp 20 34 68 20
service-policy QOS-OUT-D2-BA
class DSCP-OUT-D3-TO
bandwidth percent 21
random-detect dscp-based
random-detect dscp 10 48 96 20
random-detect dscp 12 31 62 20
service-policy QOS-OUT-D3-TO
class DSCP-OUT-RT-VI
bandwidth percent 6
queue-limit 30 packets
police 460000 57500 57500 conform-action set-dscp-transmit af43
exceed-action set-dscp-transmit af21 violate-action
set-dscp-transmit default
And sh int stats:
GigabitEthernet0/1
Switching path Pkts In Chars In Pkts Out
Chars Out
Processor 311249998 1622425452 311496548 1640497685
Route cache 910779860 166070169 883679645 1324432555
Total 1222029858 1788495621 1195176193
2964930240
I'll increase the interface input queue and monitor for a few hours.
Cheers,
Javi
On Sun, Feb 28, 2010 at 11:26 AM, Rodney Dunn <[email protected]
<mailto:[email protected]>> wrote:
On 2/26/10 1:57 AM, Javi in AUS wrote:
Gents,
We have a WAN facing Cisco 3845 which is showing the numbers
below on it's
Gi0/1 interface:
Input queue: 0/75/9/71805 (size/max/drops/flushes); Total
output drops:
714432
Turn off SPD:
config t
no spd enable
end
Of course, these counters are increasing and we have a bunch
of users at the
other side of the link complaining about poor VoIP
performance (they hear
us intermittently although we can hear them Ok).
CEF is enabled globaly, input queue is set to default (75).
GigabitEthernet0/1 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is
001b.d37d.f8a2 (bia
001b.d37d.f8a2)
Internet address is 10.83.2.17/30 <http://10.83.2.17/30>
MTU 1500 bytes, BW 20000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 11/255, rxload 10/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 3w3d
Input queue: 0/75/9/71805 (size/max/drops/flushes); Total
output drops:
714432
Queueing strategy: Class-based queueing
Output queue: 0/1000/0 (size/max total/drops)
30 second input rate 848000 bits/sec, 634 packets/sec
30 second output rate 874000 bits/sec, 604 packets/sec
1146444284 packets input, 1913512714 bytes, 0 no buffer
Received 1785 broadcasts, 0 runts, 0 giants, 1 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 6993 multicast, 0 pause input
0 input packets with dribble condition detected
1121611018 packets output, 2544901813 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
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
What is your policy doing on that interface for the output drops?
sh policy-map interface gig 0/1
What does 'sh int stat' show...the input queue is only for
process switched traffic so you need to figure that out?
What code?...12.4(20)T and later you can do an EPC trace on the
punt path coming in the interface to see what traffic it is.
Or try to catch the packets in 'sh buffers input-interface gig
0/1 packet'
Should we increase the input queue size to 150,200,250, etc
? Could these
flushed/drops be the cause of the poor VoIP performance?
Yeah..set it to the max of 4096.
Rodney
Many thanks,
P
_______________________________________________
cisco-nsp mailing list [email protected]
<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
