07-09-2007 06:15 AM
I have a 7507 that has policy maps for matching voice for QoS. A show access-list shows that traffic is being matched. A show interface shows that packets are being dropped. The end result is though, that latency is high and call quality is suffering. A show queueing on the interface shows that no packets are being dropped. Any suggestions?
Solved! Go to Solution.
07-10-2007 11:53 AM
Greg,
I know next to nothing about MPLS, so I won't even hazard a guess.
Don't forget to use the pull down menu to rate helpful posts.
Regards, Dave
07-09-2007 06:58 AM
Greg,
A show policy-map interface Sx/x will display what your service policies are doing.
Perhaps you have more voice calls than the QOS is provisioned to handle. Is this Call Manager, CME, or VOIP transport?
Can you post your config?
Please rate helpful posts.
Dave
07-09-2007 07:29 AM
class-map match-all 2505PlanoRd
match access-group name PlanoRd2505-voice
policy-map 2505PlanoRd
class 2505PlanoRd
priority 192
class class-default
fair-queue
!
!
interface Serial5/0/0/5:0
bandwidth 1536
ip address xx.xx.xx.xx 255.255.255.252
no ip redirects
no ip unreachables
load-interval 30
service-policy output 2505PlanoRd
!
ip access-list extended PlanoRd2505-voice
permit ip any any dscp ef
permit ip any any dscp cs6
permit ip any host xx.xx.xx.xx
Core-1#sh access-list PlanoRd2505-voice
Extended IP access list PlanoRd2505-voice
10 permit ip any any dscp ef (124045 matches)
20 permit ip any any dscp cs6 (9779 matches)
30 permit ip any host xx.xx.xx.xx (93010 matches)
Core-1#sh queueing int s5/0/0/5:0
Interface Serial5/0/0/5:0 queueing strategy: VIP-based fair queueing
Serial5/0/0/5:0 queue size 0
pkts output 0, wfq drops 0, nobuffer drops 0
WFQ: aggregate queue limit 384 max available buffers 384
Priority Class: limit 48 qsize 0 pkts output 0 drops 0
Non-Priority Class: limit 336 qsize 0 pkts output 0 drops 0
available bandwidth 1344
Class 0: weight 8750 limit 336 qsize 0 pkts output 0 drops 0
Core-1#sh int s5/0/0/5:0
Serial5/0/0/5:0 is up, line protocol is up
Hardware is cyBus CT3
Internet address is xx.xx.xx.xx
MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
reliability 255/255, txload 72/255, rxload 12/255
Encapsulation HDLC, crc 16, loopback not set
Keepalive set (10 sec)
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/32 (size/max/drops/flushes); Total output drops: 510996
Queueing strategy: Class-based queueing
Output queue: 0/40 (size/max)
30 second input rate 77000 bits/sec, 57 packets/sec
30 second output rate 439000 bits/sec, 78 packets/sec
80041948 packets input, 17598546217 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 9 giants, 0 throttles
696964 input errors, 38821 CRC, 302664 frame, 92 overrun, 1 ignored, 355377 abort
113990388 packets output, 96683334345 bytes, 0 underruns
0 output errors, 0 collisions, 10 interface resets
0 output buffer failures, 3437585 output buffers swapped out
10 carrier transitions no alarm present
Timeslot(s) Used: 1-24, Transmitter delay is 0 flags
non-inverted data
This is standard VoIp transport selection based on dscp.
07-09-2007 08:37 AM
Greg,
How about a show policy-map interface Serial5/0/0/5:0?
I have always gotten more consistent results defining class maps based on matching DSCP, rather than access lists when configuring egress queuing. For the host address you want to priority queue you would need to use an inbound service policy on the ingress interface to set the DSCP to the value you want.
Dave
07-09-2007 08:45 AM
Core-1#show policy-map interface Serial5/0/0/5:0
Serial5/0/0/5:0
Service-policy output: 2505PlanoRd
queue stats for all priority classes:
queue size 0, queue limit 48
packets output 0, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
Class-map: 2505PlanoRd (match-all)
228557 packets, 20260889 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: access-group name PlanoRd2505-voice
Priority: kbps 192, burst bytes 4800, b/w exceed drops: 0
Class-map: class-default (match-any)
80560815 packets, 72389666505 bytes
30 second offered rate 412000 bps, drop rate 0 bps
Match: any
queue size 0, queue limit 336
packets output 0, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
Fair-queue: per-flow queue limit 84
Sorry- forgot that...
07-09-2007 08:54 AM
Was there voice traffic active when you entered the command?
It is showing that no traffic is being priority queued.
Try changing your class map to this:
class-map match-any 2505PlanoRd
match ip dscp ef
match ip dscp cs6
match access-group name PlanoRd2505-voice
07-10-2007 06:57 AM
We made a hardware change last nite. We discovered that the main ethernet card was not on a VIP card. This has dropped our CPU utilization a BUNCH. Now I have been able to tag traffic coming into the router that is voice- it shows to be tagging the traffic correctly as ef. However, the new policy map (the one you recommended)- still shows not to be queueing that traffic as priority. Any suggestions?
07-10-2007 09:54 AM
Can you post your current config, and a show policy-map interface for ingress and egress interfaces?
07-10-2007 10:22 AM
Here is the ingress policy map that assigns the ef tag:
FastEthernet0/0/0.996
Service-policy input: Starvox
Class-map: Starvox-voice (match-all)
5327746 packets, 787174956 bytes
30 second offered rate 348000 bps, drop rate 0 bps
Match: any
QoS Set
dscp ef
Packets marked 5327739
Class-map: class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
Here is the egress policy map toward the customer site:
Service-policy output: 2505PlanoRd
queue stats for all priority classes:
queue size 0, queue limit 48
packets output 1255, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
Class-map: 2505PlanoRd (match-all)
1253 packets, 94800 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: dscp ef (46)
Match: dscp cs6 (48)
Match: access-group name PlanoRd2505-voice
Priority: kbps 192, burst bytes 4800, b/w exceed drops: 0
Class-map: class-default (match-any)
1844909 packets, 1594721515 bytes
30 second offered rate 212000 bps, drop rate 0 bps
Match: any
queue size 0, queue limit 336
packets output 1845797, packet drops 580
tail/random drops 580, no buffer drops 0, other drops 0
Fair-queue: per-flow queue limit 84
It actually was matching some control packets based on the access-list before it was removed, but no ef or RTP traffic.
Here is the current config:
class-map match-all Starvox-voice
description matches all Starvox traffic
match any
class-map match-all 2505PlanoRd
match dscp ef
match dscp cs6
match access-group name PlanoRd2505-voice
!
!
policy-map 2505PlanoRd
class 2505PlanoRd
priority 192
class class-default
fair-queue
!
!
interface FastEthernet0/0/0.996
description Connected to StarVox
encapsulation dot1Q 996
ip address XX.XX.XX.XX 255.255.255.248
no ip redirects
no ip unreachables
ip policy route-map Edgewater
service-policy input Starvox
!
!
interface Serial5/0/0/5:0
description nBuilding- 2505 Plano Rd (03.HCRU.005344..EPGN)
bandwidth 1536
ip address XX.XX.XX.XX 255.255.255.252
no ip redirects
no ip unreachables
load-interval 30
service-policy output 2505PlanoRd
!
ip access-list extended PlanoRd2505-voice
permit ip any host XX.XX.XX.XX
Greg
07-10-2007 11:01 AM
class-map match-any 2505PlanoRd
07-10-2007 11:34 AM
well... duh... that works better huh?
It's matching and prioritizing now! We're seeing a problem with some links that are BGP MPLS links and the ef tagging- is there something special you have to do on these links to prioritize the ef tagged traffic?
Greg
07-10-2007 11:53 AM
Greg,
I know next to nothing about MPLS, so I won't even hazard a guess.
Don't forget to use the pull down menu to rate helpful posts.
Regards, Dave
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide