Configuration for Class of Service
Overview
This page explains configuration required on monitored devices used for managing traffic classification, typically in MPLS networks. The examples shown are for Cisco edge devices. Other types of equipment will be supported in the future.
Refer to how Highlight discovers and monitors classes for an explanation of class based traffic management. In Cisco’s case, this normally uses the Class-Based Quality of Service (CBQOS) feature, which lets customers specify rules for matching types of traffic
Device Configuration
This section describes the configuration requirements for the Router / CPE from which Highlight collects Class information.
SNMP Access
Devices need to be configured to allow SNMP read-only access from the IP addresses of the Highlight data collectors. Refer to the basic SNMP commands needed to achieve SNMP access.
Establish the relevant Class Names
CBQOS has the task of marking outgoing data with class information. While doing this, it keeps statistics on the activity, and it is this activity which Highlight reports on. A typical (very simplified) CBQOS configuration might look like the following, whereby the outgoing traffic is resolved into three classes called premium, classic and standard.
class-map match-any premium
match [voice protocol spec]
class-map match-any classic
match-protocol http
class-map match-any standard
match-protocol smtp
!
! apply these to a policy map
!
policy-map applyQos
class premium
set ip dscp EF
class classic
set ip dscp 26
class standard
set ip dscp 10
!
! apply policy-map to the interface
!
interface Serial0/0
service-policy output applyQos Traffic that does not match will be cassified as class-default
Bi-Directional reporting
With the above, a basic CBQOS configuration will only produce charts for outgoing traffic levels–the volume of data which that site is pushing into the network. It would also be very interesting to see the equivalent statistics for incoming traffic. To do this, the CPE needs to be configured to recognise different classes on incoming traffic. The CPE need take no action (marking etc) on these classes so the overhead they place on the CPE is minimal, but the act of recognising the classes creates statistics which Highlight can collect and, importantly, report on alongside the corresponding outgoing data.
To do this, create classes which mirror the outgoing classes, but which have slightly different names. The simplest way is usually to recognise the incoming DSCP markers (it is implicit and essential that the Service Provider cloud has not stripped the markers off the packets). For example, a mirror configuration for the setup in the previous paragraph would involve adding these lines to the configuration, which will create 3 classes called isDscpEF, isDscp26 and isDscp10:
class-map match-any isDscpEF
match ip dscp EF
class-map match-any isDscp26
match ip dscp 26
class-map match-any isDscp10
match ip dscp 10
!
! apply these to a policy map
!
policy-map countInbound
class isDscpEF
class isDscp26
class isDscp10
!
! apply policy-map to the interface
!
interface Serial0/0
service-policy input countInbound Traffic that does not match will be cassified as class-default
Highlight needs to be configured to match these class names, as described in class autodiscovery implementation summary.