QoS for OSPF, VOICE and CRITICAL Traffic

Question

I plan to implement the QoS policy below.

• The target is to garantee bandwidth to VOICE and CRITICAL traffic.
• It should be 1/3 for Voice and Video, 1/3 for Business Critical traffic, 1/3 for all the rest.
• If one of the classes don´t use the reserved bandwidth, the other classes can take it.
• I would like to make sure OSPF is running fine even the when the links are congested to avaoid flappings etc.

The plan is:

• Parent policy to shape to 20Mbps
• Child policy to apply QoS for 1/3 Voice/Video, 1/3 Business Critical, 1/3 all the rest

The Questions:

• I read somewhere that routing protocol traffic gets automaticcally into the LLQ, thats true? If not, how i can make sure the OSPF traffic in outbound direction originated by the SW itself is priorized and gets transmitted even if the link is overloaded?
• Is the approach in my policy right to do what i descriped above? Or do i have some mistakes inside?

Open for tipps, tricks, critic, hints

---

Setup

• OSPF is running on both links where the policy should be applied
• Traffic is already marked by hard / sofphones for voice and video
• Platform where QoS should be implemented is Cisco 4500X running in VSS

PLANNED CONFIG

class-map match-any CM_QOS_VOICE-VIDEO-TRAFFIC description Matching voice, voice signalling, video and app-sharing traffic match dscp ef match dscp cs3 match dscp af41 match dscp af21 ! class-map match-any CM_QOS_CRITICAL-TRAFFIC description Matching critical traffic: Routing Protocol, Business critical, etc. match access-group name ACL_BUSINESS-CRITICAL-TRAFFIC match access-group name ACL_ROUTING-PROTOCOL-TRAFFIC ! Necessary or automatically put to LLQ? ! policy-map PM_QOS_SHAPING-20M class class-default shape average 20000000 service-policy PM_QOS_WAN-EDGE ! policy-map PM_QOS_WAN-EDGE class CM_QOS_VOICE-VIDEO-TRAFFIC priority percent 33 class CM_QOS_CRITICAL-TRAFFIC bandwidth percent 33 class class-default fair-queue random-detect ! interface te1/1/1 service-policy output PM_QOS_SHAPING-20M ! interface te2/1/1 service-policy output PM_QOS_SHAPING-20M !

Answer 1

Besides what Ron Trunk explained, you have some problems.

If you want to base your QoS on 20 Mbps on a 1 Gbps link, then you must set the bandwidth statement on the interface, otherwise QoS assumes that it is using the full 1 Gbps bandwidth of the interface. You probably want to set it to a smaller percentage for the 20 Mbps because of the overhead of small real-time packets like VoIP and video. This will take some experimentation to get right, but you could start at 97% and adjust later, as needed. That would get you something like:

interface te1/1/1
 bandwidth 19400
!
interface te2/1/1
 bandwidth 19400
!

You will also need to set up some ACLs and ingress policies to properly classify and mark the traffic inbound to the switch from the access interfaces so that you can properly treat the traffic as it is outbound on the uplink interfaces. That is really a different and complex question, so I will not deal with it here.

Typically, you want most of your traffic to be set as default (BE), then you want to set up a few classes for traffic that gets special treatment. Just as important as marking and treating high-priority traffic, like VoIP, you need to classify and treat low-priority traffic, like server backups, that can eat huge chunks of bandwidth for extended periods of time.

You could set up something like this typical set of classes:

class-map match-any EGRESS-VOICE
  description VoIP traffic
  match ip dscp cs4 cs5 ef
!
class-map match-any EGRESS-VIDEO
  description Video traffic
  match ip dscp af41 af42 af43
!
class-map match-any EGRESS-CONTROL
  description Control traffic for VoIP, Video, Routing, etc.
  match ip dscp cs3 af31 af32 af33 cs6 cs7
!
class-map match-any EGRESS-BUSINESS
  description Business traffic that requires special treatment
  match ip dscp cs2 af21 af22 af23
!
class-map match-any EGRESS-BULK
 description Bulk traffic like backups, etc.
 match ip dscp cs1 af11 af12 af13
!

Then, you create a policy for your uplink interfaces. Below is a typical good starting policy, then you will need to observe the production traffic and tweak the bandwidth percentages to give you what you need. You can use something like NetFlow to gather the statistics for that.

policy-map EGRESS-UPLINK
 description QoS for 20 Mbps uplinks
 class EGRESS-VOICE
  priority
  police cir percent 23
 class EGRESS-VIDEO
  bandwidth remaining percent 30
  police cir percent 23
 class EGRESS-CONTROL
  bandwidth remaining percent 10
 class EGRESS-BUSINESS
  bandwidth remaining percent 20
 class EGRESS-BULK
  bandwidth remaining percent 5
  dbl
 class class-default
  bandwidth remaining percent 34
  dbl
!

And, you apply the policy to your uplink interfaces:

interface te1/1/1
 bandwidth 19400
 service-policy output EGRESS-UPLINK
!
interface te2/1/1
 bandwidth 19400
 service-policy output EGRESS-UPLINK
!

Another thing you didn't ask about, besides the ingress QoS for the access interfaces, is setting up egress QoS for the access interfaces, which could be similar to the uplink interfaces, except that you probably do not want to set the bandwidth statement on the access interfaces (simply let QoS use the actual bandwidth of the interfaces).

---

Edit:

If you want to shape, you can add something like this (based on the 97% of the 20 Mbps bandwidth):

policy-map EGRESS-20M
  class class-default
    shape average 19400000 77600
    service-policy EGRESS-UPLINK
!

Then, use the shaping policy (which uses to the queuing policy):

interface te1/1/1
 bandwidth 19400
 service-policy output EGRESS-20M
!
interface te2/1/1
 bandwidth 19400
 service-policy output EGRESS-20M
!

Answer 2

QoS is a book-worthy topic. but here are a few quick answers:

I read somewhere that routing protocol traffic gets automatically into the LLQ, thats true?

Not true

If not, how i can make sure the OSPF traffic in outbound direction originated by the SW itself is prioritized and gets transmitted even if the link is overloaded?

Put OSPF (and all management traffic) in a separate queue and give it some slice of bandwidth (10%)

Is the approach in my policy right to do what i descriped above? Or do i have some mistakes inside?

Your voice traffic should not be shaped. Put it in a priority queue before the shaper.

Cisco documentation has lots of QoS examples for a relatively common requirement such as yours.