cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
544
Views
5
Helpful
11
Replies

Policy-map issue on 7507

gregwoodson
Level 1
Level 1

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?

1 Accepted Solution

Accepted Solutions

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

View solution in original post

11 Replies 11

dgahm
Level 8
Level 8

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

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.

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

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...

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

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?

Can you post your current config, and a show policy-map interface for ingress and egress interfaces?

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

class-map match-any 2505PlanoRd

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

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

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: