Policy Map Not Marking packets

[Peter Sheridan]

Hi Guys,

I have a weird issue with a QOS policy that I have implemented. Details are below.

This is basically the policy I have created. It is running on a Cisco 877 router (running Advance IP Services 12.4). The internet connection is an Internode ADSL service.

class-map match-any VOIP

match access-group name VOICE-OUT

!

!

policy-map QOS-to-ADSL

class VOIP

set dscp ef

   priority percent 50

class class-default

   fair-queue

!

!

ip access-list extended VOICE-OUT

permit ip host 192.168.1.100 any

!

!

interface Dialer0

service-policy output QOS-to-ADSL

!

The telephone hardware I am using is a Cisco SPA504G IP Phone that is linked to an Internode VOIP Service.  When I make a phone call I issue the command below and get the results;

ROUTER1#show policy-map interface dialer 0 out

Dialer0

Service-policy output: QOS-to-ADSL

   queue stats for all priority classes:

     queue limit 64 packets

     (queue depth/total drops/no-buffer drops) 0/0/0

     (pkts output/bytes output) 0/0

   Class-map: VOIP (match-any)

    51 packets, 19782 bytes

     5 minute offered rate 0 bps, drop rate 0 bps

     Match: access-group name VOICE-OUT

       51 packets, 19782 bytes

       5 minute rate 0 bps

     QoS Set

       dscp ef

         Packets marked 0

     Priority: 50% (192 kbps), burst bytes 4800, b/w exceed drops: 0

   Class-map: class-default (match-any)

    5978 packets, 1241808 bytes

     5 minute offered rate 6000 bps, drop rate 0 bps

     Match: any

     Queueing

     queue limit 64 packets

     (queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0

      (pkts output/bytes output) 0/0

     Fair-queue: per-flow queue limit 16

One would look at that and think ok great it is working. But if I issue the command again say 10, 20, 30 seconds into the call I get this.

ROUTER1#show policy-map interface dialer 0 out

Dialer0

Service-policy output: QOS-to-ADSL

   queue stats for all priority classes:

     queue limit 64 packets

     (queue depth/total drops/no-buffer drops) 0/0/0

     (pkts output/bytes output) 0/0

   Class-map: VOIP (match-any)

     51 packets, 19782 bytes

     5 minute offered rate 0 bps, drop rate 0 bps

     Match: access-group name VOICE-OUT

       51 packets, 19782 bytes

       5 minute rate 0 bps

     QoS Set

       dscp ef

         Packets marked 0

     Priority: 50% (192 kbps), burst bytes 4800, b/w exceed drops: 0

   Class-map: class-default (match-any)

     6470 packets, 1344961 bytes

     5 minute offered rate 10000 bps, drop rate 0 bps

     Match: any

     Queueing

     queue limit 64 packets

     (queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0

     (pkts output/bytes output) 0/0

     Fair-queue: per-flow queue limit 16

And Again…

ROUTER1#show policy-map interface dialer 0 out

Dialer0

Service-policy output: QOS-to-ADSL

   queue stats for all priority classes:

     queue limit 64 packets

     (queue depth/total drops/no-buffer drops) 0/0/0

     (pkts output/bytes output) 0/0

   Class-map: VOIP (match-any)

    51 packets, 19782 bytes

     5 minute offered rate 0 bps, drop rate 0 bps

     Match: access-group name VOICE-OUT

       51 packets, 19782 bytes

       5 minute rate 0 bps

     QoS Set

       dscp ef

         Packets marked 0

     Priority: 50% (192 kbps), burst bytes 4800, b/w exceed drops: 0

   Class-map: class-default (match-any)

     6997 packets, 1455318 bytes

     5 minute offered rate 14000 bps, drop rate 0 bps

     Match: any

     Queueing

     queue limit 64 packets

     (queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0

     (pkts output/bytes output) 0/0

     Fair-queue: per-flow queue limit 16

Notice how in each instance the VOIP Class Map stays the same (as in packet count), and the default class-map skyrockets. I have tried to isolate this test as much as possible so I have disconnected all other devices from my network so all that is left is the Cisco router plugged into the Cisco IP Phone.

When I do a show ip arp, I only see the two devices on the network

ROUTER1#show ip arp

Protocol Address         Age (min) Hardware Addr   Type   Interface

Internet 192.168.1.1             -   0016.473c.e7a6 ARPA   Vlan1

Internet 192.168.1.100           0   0002.fdff.3bb5 ARPA   Vlan1

So basically for some reason the policy-map is not marking packets and it is just being passed down to the default-class. Does anyone have any ideas as to why this might be happening?

Cheers

Peter

[gerald.suiza]

did you check hits on your acl VOICE-OUT incrementing during, before and after the call?

[Peter Sheridan]

Hi Gerald,

I just checked it again then and this is what i get.

Before:

Extended IP access list VOICE-OUT

    10 permit ip host 192.168.1.100 any (221 matches)

Start of phone call:

Extended IP access list VOICE-OUT

    10 permit ip host 192.168.1.100 any (235 matches)

30 Seconds in:

Extended IP access list VOICE-OUT

    10 permit ip host 192.168.1.100 any (237 matches)

End of Phone call:

Extended IP access list VOICE-OUT

    10 permit ip host 192.168.1.100 any (238 matches)

So it is detecting some. This is the same sort of behaviour i was experiencing when doing the policy-maps. I noticed that when i initiated the phone call the class map counters (for the VOIP Class Map) would go up, but during the call only the "default-class" would increase, and then when the phone call was ended the VOIP class would only increment slightly.

It is almost as though it is picking up only Real-Time Transport Control Protocol (RTCP) traffic, which is mainly used to initiate and control the voip telephone call (thats my limited understanding of it though :P).

[Mohamed Sobair · Accepted solution]

Peter,

Your QoS config is not implemented correctly. you are matching traffic from host on the inside Network 192.168.1.100 while the traffic is being natted since this is an Internet router besides you dont have any CLASSIFCATION & MARKING properly set here.

What I would firstly do is perform QoS classification and Marking as close to the source as possible and then apply your QoS policy outbound on the dialer interface.

Below is an example to set it up and configure it correctly:

                class-map match-any classification

                match access-group 100

                access-list 100 permit ip host 192.168.1.100 any             

                policy-map marking

                           class classification          

                           set ip dscp ef

                interface vlan 1

                sevice-policy input marking

class-map match-any VOIP

match ip dscp ef

!

!

policy-map QOS-to-ADSL

class VOIP

   priority percent 50

class class-default

   fair-queue

!

!

!

!

interface Dialer0

service-policy output QOS-to-ADSL

Please try the above configuration and check the output of the (show policy-map interface dialer0).

Regards,

Mohamed

[Peter Sheridan]

Ok Mohamed I will try that now and report back.

[Peter Sheridan]

Hi Mohamed,

I have implemented what you suggested an I am now certanly getting hits in the policy map along with the ACL. So it looks like it is marking the packets correctly now. Thanks very much!!

I guess the next step is to stress test the WAN links to see if the QOS is working properly. Can you recommended any good tools for maxing out WAN connections?

Also the packets are currently being matched to an ACL as my IP phone has a static IP address (192.168.1.100). If i changed the classification to a protocol using NBAR instead of the ACL what would the protocols required be? I assume it would be something like RTP, RTCP and SIP?

Thanks

Peter

[Mohamed Sobair]

Hi Peter,

Glad its working with you now.

For Testing purposes and WAN stressing, I would look into (IXIA), we have been using it in the past and its a very good tool for various testing methods. below is the link:

http://www.ixiacom.com/products/ixnetwork/index.php

If you for any reason couldnt purchase it, then try to manually download HUGE files from the internet, open multiple sessions to consume the full bandwidth and try your Voice quality.

If you change the ACL, you can indeed MARK based on NBAR on the class-map, you just need to match protocol (RTP Audio) as bellow:

                class-map match-any classification

                match protocol rtp audio

Thanks for reverting back, and please use the rating system to indicate your problem is resolved.

Good Luck,

Mohamed

[Peter Sheridan]

Hi Mohamed,

Thanks for that I will check out those tools. For some reason i think the voice quality is even worse now that i have got it working which does not make sense at all!!

I will play around with the settings and report back.

Just another thought, in the config i specified "priority 50 %" to the traffic matching that policy. With the 50% rule does that mean it will always consume 50% bandwidth or can other services use it if not in use? For example if i am not on a call can http for example use 100% of the bandwidth?

[Mohamed Sobair]

Hi Peter,

Yes, if you are not on a call, any traffic other than voice can consume 100% of the link BW.

The 50% priority is simply means, whenever there is a congestion, the Voice allowed upto 50% of the WAN Link and its always going to be deququed (Forwarded first before all traffic).

All QoS comes into picture when there is a real starting Congestion on the Link.

Just a quick note, I want to remind you to add.

Under the dialr intefrace, dont forget to add the (Bandwidth command), its a best pratise to use this command whenever you want to influence routing protocol or QoS decision and all QoS calculation will be based on it.

So, I would suggest, adding the following:

interface dialer0

bandwidth xxx (where xxx is your Internet Bandwidth in Kbits per seconds).

Regards,

Mohamed

[Peter Sheridan]

Hi Mohamed,

Thanks for the info, i actually have that command on my router already (I assume it is the upload bandwidth that you specify?). The point that you make about QoS comes into the picture when there is congestion on the link raises an interesting question.

Say you have a link that has a voip call running over it and some very mild http traffic. If there is no congestion on the link will the priority even be in play on the router in regards to the order packets are sent. eg if 100 http packets are sent to the router and then 50 voip packets, would the router send the 50 voip packets first even though they arrived after the http IF there is no congestion on the link? (hopefully that makes sense).

also i have been running with your QOS policy at work today and had mixed results. From what i gathered the person on the other end can hear me fine, but i can hardly hear them at some points. To me that tends to indicate a download bw problem.

fyi, my ADSL router is currently syncing at around 8160/384 (down/up) so it should be ample bandwidth to handle 1 telephone call. Especially since my voip provider is my ISP so its not like it has to travel far

From what i understand i don't believe it is possible to apply an inbound QOS policy on an atm interface as you cannot control what traffic the other end is sending....

[Mohamed Sobair]

Hello,

The answer to your question is NO, the LLQ is a queuing mechanism that doesn't take place unless congestion occurs. So when you have a priority of 50%, it only takes place when the bandwidth is consumed and would therefore gurantee 50% and is Always going to be dequeud/forwarded first.

Now, your 2nd question states how packets are treated by the router before and after QoS. Ok, So the router forward the packet normally and the normal queuing strategy performed by the Egress queue of the interface is always FIFO (first input first output).

So any packets arrive at the router interface is always forwarded based on who comes/arrive first. This always the behavior without QoS. With QoS set and whenever there is a congestion , the router forwards the packet based on the QoS policy which indeed priotrizing traffic over another.

Regards,

Mohamed

Sent from Cisco Technical Support iPhone App

[Peter Sheridan]

Ah ok that makes sense. I kinda don't agree with the theory though because even if there isn't congestion I thought it would always be better to send VOIP packets first. Prehaps I don't understand the entire picture though!

Also can you think of any reason why i can sometimes hardly hear the person i'm speaking with but they can hear me fine?

[Peter Sheridan]

Thanks for all of your help Mahamed

[Mohamed Sobair]

You are Welcome Peter.

The Voice quality though could be related to upstream providers. If this is a dedicated WAN LInk between you and your Branch, You should see better result.

But, I suspect this is because you have VOIP over the Internet , for End to End QoS, The transit Service Providers should have this implemented as well and this depends on the type os link and SLA agreement.

Regards,

Mohamed

[Peter Sheridan]

Yeah my VOIP connection is running over the internet. My VOIP Provider is actually my ISP as they offer services where you get a public telephone number etc. I asked the question and they responded saying that all VOIP traffic related to their server is QOS through the network. So it should be working but i dunno, sometimes i get mixed results.

Even when I dial a test number that is hosted on their server i sometimes don't hear it properly. Unfortunatly the cisco i am using is not one of their "Recommended" routers so getting tech support from them is hard.

Anyway will keep on trying different settings and see how that goes.

Cheers