DSL QOS - Supplier information

[scotlandvisit]

I know there is plenty of information regarding QOS already in the community however, I would like to know the design steps before the actual configuration to ensure I am not forgetting a step.  We have 887ISR on DSL and we have some voip handsets at the site, we have agreement from the supplier that they will apply QOS to our traffic as it will be part of our IPVPN.  The supplier has given us a spread sheet showing class,marking,DSCP,profile1; class is just the name of the class and I have CS5,EF,CS6,CS7 under markings, DSCP has 40,46,48,56 and profile 1 shows the percentage in this case 50% as it is realtime traffic.

Marking is to ensure VoIP packets are marked correctly and DSCP are the numbers we should be looking for to apply a higher QOS percentage both marking and DSCP are the same as CS5=DSCP46.

class-map match-any RealTime

match ip dscp ef

match ip dscp CS5

match ip dscp CS6

match ip dscp CS7

!

policy-map QOS

class RealTime

priority percent 50

!

interface ATM0.1 point-to-point

ip nbar protocol-discovery

pvc 0/XX

cbr XXX

service-policy out QOS

!

Can anyone see and glaring misunderstanding on my part or do I have the translation from supplier to QOS correct, I have only included the realtime portion there is more to the QOS profile than just realtime.

Many thanks for taking the time to read.

[Georg Pauwen · Accepted solution]

Hello,

your configuration looks fine. The only thing you could add is fair queueing for the default class:

policy-map QOS

class RealTime

priority percent 50

class class-default

fair-queue

[Joseph W. Doherty]

It's unclear to me what your provider is providing vis-à-vis QoS. If you have a p2p CBR ATM PVC, you should be able to perform any QoS you like, independent of your provider. (This because the CBR sets and guarantees a fixed amount of bandwidth.)

You've set your LLQ to 50%. The general recommendation is to not exceed 1/3 of the bandwidth. This to insure you have sufficient bandwidth for non-LLQ traffic and to also insure LLQ doesn't self congest. (The latter also depends on the nature of your LLQ traffic. If, for example, your VoIP bearer traffic uses a CODEC that uses a fixed bandwidth per flow it's predictable, while VoIP bearer traffic using a CODEC that uses a variable bandwidth per flow it's not.)

It's debatable whether CS6 and CS7 should be in your real-time class. They, like VoIP control traffic (unknown how you're marking it), "by-the-book", often get their own classes, to guarantee their service requirements. (They both might be okay in the class-default if you use FQ as recommended by Georg.)

BTW, you're using NBAR discovery for?

Your DSL, it's not PPPoE, is it? If so, you lose 8 bytes from your MTU which will cause max size Ethernet packets to be fragmented. (This can possibly be mitigated with further configuration.)

Also BTW, if you want to make your real-time class matching a bit more efficient, you can consider matching IP Prec 5 for both DSCP EF and CS5.

[scotlandvisit]

---

@Joseph W. Doherty wrote:
It's unclear to me what your provider is providing vis-à-vis QoS. If you have a p2p CBR ATM PVC, you should be able to perform any QoS you like, independent of your provider. (This because the CBR sets and guarantees a fixed amount of bandwidth.)

You've set your LLQ to 50%. The general recommendation is to not exceed 1/3 of the bandwidth. This to insure you have sufficient bandwidth for non-LLQ traffic and to also insure LLQ doesn't self congest. (The latter also depends on the nature of your LLQ traffic. If, for example, your VoIP bearer traffic uses a CODEC that uses a fixed bandwidth per flow it's predictable, while VoIP bearer traffic using a CODEC that uses a variable bandwidth per flow it's not.)

It's debatable whether CS6 and CS7 should be in your real-time class. They, like VoIP control traffic (unknown how you're marking it), "by-the-book", often get their own classes, to guarantee their service requirements. (They both might be okay in the class-default if you use FQ as recommended by Georg.)

BTW, you're using NBAR discovery for?

Your DSL, it's not PPPoE, is it? If so, you lose 8 bytes from your MTU which will cause max size Ethernet packets to be fragmented. (This can possibly be mitigated with further configuration.)

Also BTW, if you want to make your real-time class matching a bit more efficient, you can consider matching IP Prec 5 for both DSCP EF and CS5.

---

The policy as I explained is to set up our QOS to match the suppliers QOS which is applied to our ADSL2+ and they supply the IPVPN site to site using PPPoE but the configuration for this is in the rest of the config.  I use nbar as this is required to identify traffic and must be on the same interface as the service policy; the rest of the config has for example "match protocol skinny" which needs nbar I beleive. 

The QOS question was just one small part of the set up to make sure I hadn't missed something as I am not a QOS Guru.

[Joseph W. Doherty]

"I use nbar as this is required to identify traffic and must be on the same interface as the service policy; the rest of the config has for example "match protocol skinny" which needs nbar I beleive. "

NB: BTW, you don't need to activate interface NBAR for CBWFQ class "match protocol xxx". (This command is used to obtain NBAR analysis of what kind of traffic is crossing an interface.)

Sorry, I'm still confused over your network management vs. your provider's . Your provider is providing VPN beyond your ATM interface, across the Internet? If so, unclear what "their" QoS is doing. Again, if you have CBR, p2p, what you do on you ATM interface, with QoS, shouldn't really need provider QoS. It's possible, although unusual, they support QoS across their network, but that would generally "stop" once/if they need to forward your Internet traffic to another ISP or backbone provider. Also, if they are providing a CBR service, your QoS markings shouldn't matter once you hand off your traffic to them.

It's fine you're not a QoS Guru, but that's why posting to these forums can be useful, as you may obtain responses from those with a bit more experience.

[scotlandvisit]

---

@Joseph W. Doherty wrote:
"I use nbar as this is required to identify traffic and must be on the same interface as the service policy; the rest of the config has for example "match protocol skinny" which needs nbar I beleive. "

NB: BTW, you don't need to activate interface NBAR for CBWFQ class "match protocol xxx". (This command is used to obtain NBAR analysis of what kind of traffic is crossing an interface.)

Sorry, I'm still confused over your network management vs. your provider's . Your provider is providing VPN beyond your ATM interface, across the Internet? If so, unclear what "their" QoS is doing. Again, if you have CBR, p2p, what you do on you ATM interface, with QoS, shouldn't really need provider QoS. It's possible, although unusual, they support QoS across their network, but that would generally "stop" once/if they need to forward your Internet traffic to another ISP or backbone provider. Also, if they are providing a CBR service, your QoS markings shouldn't matter once you hand off your traffic to them.

It's fine you're not a QoS Guru, but that's why posting to these forums can be useful, as you may obtain responses from those with a bit more experience.

---

Hi, Thanks for that I misunderstood the NBAR which means I can take that off, our DSL connections are not internet connections they don't leave the suppliers network.  They provide a network across their network to our WAN connection on a leased line provided by them also; we then provide internet access to the sites, due to this they can honor our markings and put in place QOS of which they provide three standard profiles.  We select the profile we think would work best and implement that for traffic leaving our DSL sites and the provider does the rest including routing between sites.

[Georg Pauwen]

Joseph,

highly interesting read. I have one question: it is my understanding that for PPPoE, typically, an MTU of 1492 and an MSS of 1452 is recommended, For PPPoA, no adjustments are required. However, I often see PPPoA configs such as the one below with an MTU adjustment. In what situations would that be necessary ?

interface ATM0
no ip address
ip nat outside
ip virtual-reassembly
no atm ilmi-keepalive
pvc 8/35
encapsulation aal5mux ppp dialer
dialer pool-member 1
!
dsl operating-mode auto
!
interface Dialer0
ip address negotiated
ip mtu 1492
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap

[Joseph W. Doherty]

The 1492 might just be a "mistake" for PPPoA, i.e. someone just used what's recommended for PPPoE.

However, even when you don't need to concern yourself with PPPoE overhead, you may still concern yourself with optimal efficiency for packing Ethernet into ATM without any "wasted" (i.e. padded) cell allocation. For those unfamiliar with that issue, here's a couple of links that get into that subject:

https://learningnetwork.cisco.com/thread/25798
https://www.speedguide.net/forums/showthread.php?199883-Best-DSL-MTU-not-1500