We have discussed about traffic classification and QoS configuration for preferential treatment in my previous blog.
Now it is time to verify the validity of the QoS settings. Majority of networks are based on DiffSrv per-hop-behavior (PHB). There is no end-to-end control signaling in these networks. The QOS markings are not carried forward as the packet moves through the routers. Each router decides based on its own settings.
Moreover, when traffic traverses different administrative domains, such as from enterprise network to service provider network and then back into the enterprise network, the routed traffic may be treated differently in each domain since each hop might be configured with its own QoS policy configuration. Having different forwarding treatments could cause significant packet loss and affect the business critical applications. So it is important to verify and validate the QoS treatment provided in various administrative domains to ensure the contracted QoS treatment is provided for interested traffic.
This can be done in two levels.
1. Verifying internal and contracted QoS treatment using NetFlow data. (Discussed below)
2. Validating QoS policies within sites using CBQoS reporting. (Will be discussed in next blog)
Verifying internal and contracted QoS treatment using NetFlow data:
Packet classification, or marking, happens via Differentiated Services Code Point (DSCP) values. Mostly, all of the QoS operations are carried out with DSCP values in the Differentiated Services Model. Each DSCP value has its own forwarding treatment. And this per-hop-behavior could vary in different administrative domains.
NetFlow exports from a router contain the six bit DSCP value which gives the packet classification information based on the type of the traffic. Let’s take an example use case mentioned in the below diagram. An Enterprise company having an HQ and two branch sites connected through a service provider link. In this scenario,
DSCP reports at different sites
A. We can use the QoS OUT reports of the WAN links in each sites(HQ, Branch 1, Branch 2) to verify the QoS engineering (packet classification and forwarding treatment). This helps to ensure right QoS configurations are in place for the interested traffic within each site.
B. QoS IN reports of the WAN links can be used to verify the ISP circuit between sites does provide the contracted QoS treatment for the business critical applications and there is no significant packet loss or delay in routing.
C. QoS OUT reports of WAN links can also be used to monitor if the interested traffic exceeds the contracted QoS bandwidth on the circuit, for capacity planning and troubleshooting purpose. E.g. sending more than 5Mbps EF traffic, when 5Mbps of EF traffic is contracted.
Hope this helps in verifying the QoS configuration used internally and contracted with the ISP, using NetFlow based QoS reports. Please write your questions to netflowanalyzer-support@manageengine.com. In the final blog, I am going to show you some screenshot from our CB-QoS reporting and how it can be used to identify network traffic drops.
Thanks
Raj
Download | Interactive Demo | Product overview video | Twitter | Customers
