QoS on Ethernet ISP Link

Answered Question
Feb 2nd, 2008

Hi Experts,

Just a general questoin about applying QoS mechanisims to an ethernet ISP Link...

General Scenarios: I have a Cisco 2811 and i want to apply LLQ for all sip traffic outbond towards the internet.

Questions:

1. If my ethernet link speed is 100Mb and my ISPs bandwidth to my link is 1Mb/1MB, how exactly do i give the bandwidth command? Is it based on the 100 Mb or the 1 Mb?

2. Must i apply the bandwidth 1000 to the ethernet interface for LLQ to work correctly?

Any opinions or real world experience of this would be great.

Thanks & Regards

Stephen

I have this problem too.
0 votes
Correct Answer by pcameron about 8 years 11 months ago

You should use the policy on the interface that connects to the ISP so any priority traffic is prioritised before it hits the ISP. Unless you have some kind of Service Level Agreement (SLA) , they won't have a clue about your particular traffic types, they only thing they normally do is police your access rate in case your exceed the purchased CIR. Never assume they will give your voice traffic over anything else. By shaping on your egress interface, you ensure two things -

1) The traffic passed to the ISP is already prioritised. The ISP will (hopefully) pass this first in , first out so your voice traffic will always be in front of the queue at the destination.

2) Because you have shaped to the purchased CIR (1Meg) on the egress interface, the ISP should never drop your traffic. If you were to exceed the CIR, the ISP would not differentiate between the more important voice/signalling traffic and the other data traffic - they drop anything over the CIR. So this improves reliability for the voice traffic.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.8 (6 ratings)
Loading.
pcameron Sat, 02/02/2008 - 03:25

When you use a ethernet connection and want to apply QOS to it, there are several things your have to take into account -

With ethernet, technically you don't get any congestion on the interface. The interface listens for activity then packets get placed onto the wire, and on a switched network there are (or should not be) any collisions, so there will not be any 'backpressure' from the interface that indicates congestion.

Therefore with an ethernet interface, there is no default mechanism to allow the QOS policy to kick in. Adding a 'bandwidth 1000000' command won't make any difference - the interface just keeps throwing the packets on the wire at the actual physical rate of 100mbps.

To allow the QOS to work properly on a ethernet connection, you need to use a nested service policy (sometimes called parent/child policy) which shapes all the traffic (the default class) to a predefined rate, and then under this policy you apply a secondary policy that does the actual prioritisation. When the traffic rate exceeds the parent rate, the child policy handles the classification and prioritisation.

Following is a sample config that demonstrates this concept. The parent policy shapes all the traffic to a rate of 1 Meg, the SIP traffic gets 32K and the RTP gets 300K. All other traffic goes into the default queue. You can obviously set more policies for other traffic.

!

class-map match-all VoIP-Control

match access-group 198

class-map match-all VoIP-RTP

match access-group 199

!

policy-map Data

class VoIP-RTP

priority 300

class VoIP-Control

bandwidth 32

class class-default

fair-queue

!

policy-map QOS-Policy

class class-default

shape average 1000000

service-policy Data

access-list 198 permit udp any any eq 5060

access-list 199 permit udp any any range 16384 32767

!

interface fastethernet 0/0

service-policy output QOS-Policy

!

Refer to the QOS SRND on Cisco.Com for more details -

http://www.cisco.com/univercd/cc/td/doc/solution/esm/qossrnd.pdf

stephen.stack Sat, 02/02/2008 - 03:51

Hi,

This is an excellent response - Clear and concise. (And i learned something new - nested policies).

But, can i ask one more thing? is it feasible or practical to place this type of policy outbound on an ISp facing interface, to perhaps prioritise voice traffic etc...

I realise that what happens the pakcets after it leaves the interface is outside of our control - Would you do in the real world?

Thanks Again

Stephen

Paolo Bevilacqua Sat, 02/02/2008 - 04:09

Stephen,

Yes, it is very applicable in the real world, and it's the only way to protect voice from congestion caused by concurrent data traffic sourced from your own network.

As you noted, nobody can guarantee what will happen after that, but at least you took all the precautions possible.

Correct Answer
pcameron Sat, 02/02/2008 - 04:16

You should use the policy on the interface that connects to the ISP so any priority traffic is prioritised before it hits the ISP. Unless you have some kind of Service Level Agreement (SLA) , they won't have a clue about your particular traffic types, they only thing they normally do is police your access rate in case your exceed the purchased CIR. Never assume they will give your voice traffic over anything else. By shaping on your egress interface, you ensure two things -

1) The traffic passed to the ISP is already prioritised. The ISP will (hopefully) pass this first in , first out so your voice traffic will always be in front of the queue at the destination.

2) Because you have shaped to the purchased CIR (1Meg) on the egress interface, the ISP should never drop your traffic. If you were to exceed the CIR, the ISP would not differentiate between the more important voice/signalling traffic and the other data traffic - they drop anything over the CIR. So this improves reliability for the voice traffic.

stephen.stack Sat, 02/02/2008 - 04:50

hi guys,

Thansk again. This is absolutly excellent information. I think perhaps i will only use this type of policy where it is needed. Most of my customers don't need this use of QOS to an ISP, except maybe on or two at the moment.

Thanks again guys - you are a credit to the netpro forums.

Stephen

joshgluck Tue, 02/05/2008 - 05:10

I have implemented a similar set of class and policies on a metroethernet router (2811) which is running 100Full connecting to a Tasman but with a contracted rate of 3Mbs. I was wondering if the fair-queue command on the class class-default actually does what I thought it would do. It seems that when I do a sho int fa0/0 it still says the interface is set to FIFO queuing and when I do a sho queuing fair it only lists the Serial interfaces on the router which are not in use nor have a service-policy applied to them.

Should the queuing type have been changed on Fa0/0 or is this normal? Is the fair-queue command under class-default just there to give the rest of my traffic (using a 2 explicit class, 1 default class 3Class schema) which isnt matched in an extended acl some place to fall?

What is the best way to monitor if my QoS policies are actually shaping the connection down to 3Mbs, queuing the packets instead of having the upstream provider discard them silently, and ensure I am carving up the 3Mbs according to my intentions?

Any help is greatly appreciated!

Josh

Actions

This Discussion