Where to apply QoS

[johnny.schultz]

Our customers are experiencing bad call quality and I need to determine where to apply a QoS policy to protect the voice traffic. We have an MPLS DS3 circuit to our provider and a VRF for each customer. I need to apply the policy to traffic destined to the customers through the DS3 circuit. Each customer has their own loopback interface which I associated to their VRF. When I tried to apply a policy, the router said it can only be applied in the outbound direction:

lax_router7206_2(config-if)#service-policy input qos-policy768

CBWFQ : Can be enabled as an output feature only

The outbound interface is a DS3 and I need to apply a separate QoS policy for each VRF since different customers may have a different amount of bandwidth dedicated for voice. I don't see a way to do this through the DS3. How would this be done?

Here are relevant parts of the configuration:

ip vrf GCF01

description Global Cash Flow VRF

rd 7751:100001

route-target export 7751:100001

route-target export 999:1803

route-target import 7751:100001

class-map match-all voip-control

match access-group 111

class-map match-all voip-rtp

match ip rtp 16384 16383

!

!

policy-map qos-policy512

class voip-rtp

priority 512

set dscp ef

class voip-control

bandwidth 8

class class-default

fair-queue

policy-map qos-policy768

class voip-rtp

priority 768

set dscp ef

class voip-control

bandwidth 8

class class-default

fair-queue

!

interface Loopback1

description Loopback for GCF01 VRF

ip vrf forwarding GCF01

ip address 10.5.0.1 255.255.255.252

!

interface Serial1/0

description MPLS Access Sprint NUA 46244937

ip address 177.177.177.2 255.255.255.252

mpls ip

dsu bandwidth 44210

framing c-bit

cablelength 40

!

router bgp 7751

no synchronization

bgp log-neighbor-changes

neighbor 177.177.177.1 remote-as xxxx

address-family ipv4 vrf GCF01

redistribute connected

redistribute static

default-information originate

no auto-summary

no synchronization

exit-address-family

!

Any help would be greatly apprecaited. Thank you.

-Johnny Schultz

[Giuseppe Larosa]

Hello Johnny,

have a look at this recent thread about a close scenario

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Service%20Providers&topic=MPLS&topicID=.ee8558c&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cd47453

You need to control what each customer sends to you on each VRF access link.

So you need to police and mark at the VRF access links (edge)

After this on the DS3 core facing link you can create classes for each marking.

Take in account 4 bytes for each MPLS label in addition to permitted traffic.

MPLS VPN requires two labels unless there is a direct link to remote PE node.

More labels are used if MPLS TE plays a role for VPN traffic.

Hope to help

Giuseppe

[johnny.schultz]

I have reviewed the thread you posted, however, on the DS3 facing link, how would it help to create classes for each marking? We have QoS applied on all CE devices for traffic inbound from customers and outside callers hear customer just fine.

Since customers are hearing the bad call quality, it must be because of traffic destined to the customer. Traffic comes in through a Gigabit interface and exits through a 45Mb DS3 but it first gets routed through the appropriate VRF/loopback interface. I need a way to apply QoS on the loopback interfaces so that voice traffic going back to the customers gets prioritized. If I try to apply an outbound QoS policy on the interface, it gives me an error as well:

lax_router7206_2(config-if)#service-policy output qos-policy768

Class Based Weighted Fair Queueing not supported on interface Loopback3

Let me know if I am leaving anything out. Thank you for your help.

[Giuseppe Larosa]

Hello Johnny,

you cannot apply QoS to a loopback interface it is a logical interface and I don't think traffic is really forwarded via the loopback interface.

You have a loopback interface for each VRF but its usage should be for routing purposes.

>> Since customers are hearing the bad call quality, it must be because of traffic destined to the customer.

I agree

Now, the question becomes who manages the other side of the DS3 link?

Queueing schedulers can only be applied outbound.

I see a description on DS3 interface that makes me think you are in a Carrier Supporting Carrier Scenario with mpls enabled towards an upstream provider.

First of all, you need to be sure that traffic marking and conditioning (policing) is correctly performed in each of customer remote sites at the MPLS edge boundary (VRF access links).

You need to implement CBWFQ also on remote PE nodes core facing links.

Then, If it is a CSC scenario you need to make an agreement with the upstream provider so that they will implement a scheduler on the DS3 link towards your router.

Also it is important to coordinate QoS configuration with voip call control servers configuration:

given a codec type it means a certain BW to be used including all overheads.

Each customer Voip implementation has to use Call admission control to stay within the QoS BW limits for the LLQ.

That is no more then M calls at the same time for customer X.

the M+1 call have impact on all calls so CAC blocks it.

Hope to help

Giuseppe

[johnny.schultz]

Guiseppe,

Sprint is the one who manages the other side of the DS3 link and I they will not be of any help to resolve the bad call quality.

I do have QoS applied on the CE routers at customer locations and outside callers can hear customers fine.

Is there any way at all to apply a QoS policy on the Serial interface and match traffic from my SIP server or MPLS bits after mapping DSCP? I think I need to focus on this part sice this is the only place to apply a policy for my voice. If you have any ideas, I would greatly appreciate it. Thank you.

[Giuseppe Larosa]

Hello Johnny,

unfortunately once that voip traffic is not well served by the other side of the DS3 connection there is little you can do to repair to this.

The problem can be on the outgoing direction of the outside callers if they don't implement QoS or CAC correctly.

Are the remote callers managed by your company or they are managed by others?

Check also the SLA you have with Sprint you may have oversubscribed the llq class/voip gold class on their side.

To be noted:

voip communications are symmetrical you can get a better quality in the case of oversubscribing Sprint side by reducing the number of concurrent calls customers can do.

This is Call admission control.

Hope to help

Giuseppe