# 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](https://help.highlight.net/functionality/discover-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](https://help.highlight.net/device-setup/snmp-config#cisco-basic-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
```

{% hint style="info" %}
Traffic that does not match will be classified as `class-default`.
{% endhint %}

### 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 useful 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 placed on the CPE is minimal, but the act of recognising the classes creates statistics which Highlight can collect and report on alongside the corresponding outgoing data.

To do this, create classes which mirror the outgoing classes but with slightly different names. The simplest approach is usually to recognise the incoming DSCP markers — it is implicit and essential that the Service Provider cloud has not stripped the markers from the packets. For example, a mirror configuration for the setup in the previous section would involve adding the following lines to the configuration, which will create three 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
```

{% hint style="info" %}
Traffic that does not match will be classified as `class-default`.
{% endhint %}

Highlight needs to be configured to match these class names, as described in [class autodiscovery implementation summary](https://help.highlight.net/functionality/discover-classes).