Qos Recommendation Urgent

[sebastiandm]

Hi Guys,

I have a two remote sites each running call manager express with one site having only a 4MG ADSL connection to the internet therefore leaving only 512k for upstream traffic. There is also a vpn tunnel between the two sites.

Users are experiencing qos issues when making intersite calls jitter packet drops etc.

At the moment there is no qos deployed so i have come up with the following recommendation to prioritize the voice traffic.

class-map match-all Voice

match ip dscp ef

class-map match-any Call_Signalling

match ip dscp cs3

match ip dscp af31

policy-map WAN-EDGE

class Voice

priority percent 20

class Call_Signalling

bandwidth percent 5

class class-default

fair-queue

!

interface fastethernet 0/1

service-policy output WAN-EDGE

I would like to know if there is any other mechanism i can use and if the above recommendation will be sufficient to resolve the qos issues on this link...thanks.

[Nicholas Matthews]

Think of it this way:

What is the speed of the link you're putting this on? (Fast E)?

That means you're giving 20 percent of 100 Mb to voice. Doesn't accomplish much.

You should try something like this:

policy-map SHAPER

class class-default

shape average 4000000

service-policy WAN-EDGE

That will give it 4 MB instead of 100 to work with.

hth,

nick

[sebastiandm]

Hey Nic,

All i have is an ADSL with 4Mb download speed and 512kbs upstream so trying to make the most of that.

The setup is ADSL circuit - ADSL modem- Firewall - Switch - Router.

I only need to allow approx 4 calls simultaneously at G.729.

What do you think ?

[stephen.himebaugh]

This configuration will not do anything for voice. You says there's a VPN tunnel between the sites, so all the voice traffic is encapsulated in the VPN tunnel. The VPN tunnel falls into the default queue with your configuration.

You also don't say if you're providing standard Internet connectivity for users at the site through the DSL interface. This user Internet traffic would compete with the bandwidth for the IPSec tunnel. User Internet traffic would increase jitter for the IPSec packets, and therefore voice packets.

I would do the following:

- Investigate a policy on the DSL interface that guarantees bandwidth to the IPSEc tunnel

- Investigate a policy on the inside interface that will prioritize traffic going into the IPSec tunnel

[Deleted line about G.711 vs G.729 in my original post. He's using G.729]

[Nicholas Matthews]

Actually when a packet is encapsulated into a tunneled packet or IPSEC, the ToS byte is copied from the old header to the new.

And since in this scenario he is matching on DSCP he should be fine.

You may also want to make sure that you're not oversubscribing your INPUT value on each side.

It's also possible that each side is using up their 4 MB and the provider is having to choose whether or not to send the customer site internet traffic, or voice from another site.

This is very tricky without leased lines.

-nick