- What is DSCP QoS Marking
- How to monitor a specific Class of Service (CoS)
- How to test DSCP propagation
What you are going to learn:
The Quality of Service (QoS) can be configured in different ways depending on the network architecture, the network devices, and the transport technologies. The most popular way to configure QoS is by using the DSCP code located in the IP header.
With DSCP codes, the marking of the packets is done as close to the source as possible (ex: by the switch on which a computer is connected or by the IP Phone itself), and it is honored by all network equipment up to the destination (ex: VoIP/ IP PBX or another IP Phone).
Take note that QoS Monitoring with Obkio is only available on Obkio's Linux, Virtual Appliance and Hardware Appliance Monitoring Agents.
In the Network Monitoring Template, you can configure the DSCP code to be used by the client when sending the network performance packets to the server. By specifying the DSCP code to use, you can measure the end-to-end network performance for a specific class of service (for example, VoIP traffic).
This way, it is possible to make sure that the QoS is configured correctly. When a network degradation event occurs, a good QoS-enabled network path should not have degradation on the high priority class of service compared to the best effort data class of service that should have higher latency, jitter and packet loss rates.
With DSCP packet marking, a network device must honor the DSCP code and map it to the appropriate priority queues. Also, it must make sure it is not rewritten in the process. If the DSCP code is re-marked to another value in the network path, the QoS setting is erased and other equipments will not be able to honor the QoS setting. This can happen, for instance, after a configuration change, a new equipment deployment or a change in the service provider's network (to name a few).
As a network administrator or network engineer, when is the last time you verified the DSCP propagation within your network? Probably a long time a ago, usualy after the initial deployment, if ever...
When a DSCP code is configured in the Network Monitoring Template, if the server does not receive the right DSCP code from the client, it will raise a Network Issue
DSCP Mismatch with the severity level
Information. When the DSCP is back to a normal status for 60 seconds, a network event is sent to clear the issue.
With SD-WAN being more and more popular in businesses, it is possible to use the DSCP codes to route traffic to a specific WAN link dedicated for monitoring. For example, in a setup with two ISPs, you would have link
WAN 1 and
WAN 2. If the SD-WAN equipment is able to do it (and many are!), you could forward all the packets with
DSCP 1 only to
WAN 1 and the packets with
DSCP 2 only to
WAN 2. In this case, make sure you don't use DSCP codes that are already in use on the network in order to avoid traffic blackholing in the event that a WAN link fails.
This way, you would have standard
DSCP 0 packets that would monitor the real end-user experience (with the SD-WAN algorithms) and
DSCP 1 and
DSCP 2 that would monitor the performance of the specific WAN links.
In the Network Monitoring Template, you can disable the
DSCP mismatch network issue with the option
Disable DSCP Alerts. This can be useful when using DSCP codes to route traffic or when it is normal that the DSCP code is rewritten by network equipment.
The Windows Monitoring Agent doesn't support DSCP marking.
Learn more on this feature in the blog post QoS Monitoring with Obkio DSCP Features.