We are in the final post of this series. Previously we talked about identifying various traffic types, QoS configurations for preferential treatment and NetFlow based DiffSrv verification. This post helps you to use Class Based Quality of Service reporting to validate your QoS policies.

DiffSrv forwarding treatment mechanism does nothing but allocating the bandwidth and raising the priority of interested traffic using a static QoS policies configured on the router. Since the network has varying loads, there is no light on the bandwidth requirement of business critical applications and the comparative usage of bandwidth allocated through QoS policies. A deficit forwarding treatment could create packet loss to the interested traffic which otherwise may be forwarded by best effort treatment.

The CBQoS reporting on pre and post policy metrics and packet drops gives in-depth visibility into forwarding treatment on per class basis, which help in validating the QoS configuration.

CBQoS reports on Pre & Post policy traffic and percentage of drop per traffic class.

The CBQoS reporting in NetFlow Analyzer can show you the pre and post policy traffic usage, dropped traffic and also the queuing for packets in each class.

Pre Policy:

The pre policy graphs under CBQoS reports in the product shows the behavior of the traffic before the effect of the policy and this information is shown on a per class basis. The graphs help identify how the traffic pattern was prior to passing through the interface where the policy is applied.

Post Policy:

The post policy graphs in the product shows the traffic behavior after the effect of the policy. These graphs show the traffic pattern after passing through the interface where the policy is applied and helps identify any change in the traffic. This information too is shown on a per class basis.

Drop and Queuing Traffic:

CBQoS reports in NetFlow Analyzer shows not only the pre and post policy traffic usage, but also the traffic that was dropped and if there was queuing in traffic because of the polices. For each class, the actual dropped traffic, based on volume, packets and speed with percentage values, can be seen along with packet queuing for each traffic class.

The administrator can use these high visibility reports into their existing QoS policies along with the QoS configurations to fine tune the policies for optimum network performance and get the best return of investment.

Hope these blogs will be helpful to implement and validate QoS policies. Please write your queries to netflowanalyzer-support@managengine.com

Thanks

Raj

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

In this blog, I will discuss about our NetFlow and VOIP add-ons for OpManager and how they help in isolating VOIP degradation due to bandwidth consumption and QoS configuration issues. If you are new to OpManager, please visit this link for more information. VOIP add-on relies on Cisco IPSLA to collect QoS metrics. The Cisco IOS IP Service Level Agreements(SLAs) is a Cisco technology use active monitoring to generate traffic in a continuous, reliable, and predictable manner, thus enabling the measurement of network performance and health. Please visit this link to know more on Cisco IP SLA.

As discussed in previous blog, we rely extensively on performance data like packet loss, delay, jitter and the Mean Opinion Score (MOS) to define QoS policies. Now OpManager with Netflow and VOIP add-on gives you a single comprehensive console to correlate all these parameters and helps reduce voice quality issues instantaneously.

VOIP and NetFlow dashboard

OpManager add-on family includes NetFlow and VOIP add-ons for increased visibility into network performance data. VOIP dashboard displays all performance centric information like packet loss, delay, jitter and the Mean Opinion Score (MOS). Network administrators identifies the problematic sites based on the MOS. MOS is a function of codec used for voice communication, jitter, packet loss and delay. Sites having the poorest MOS scores are hit with high jitter and packet loss. The following is the general MOS rating scheme for voice traffic.

The following use cases helps us to understand the functionality of both the add-ons.

1. Poor voice quality due to incorrect configuration of backup process:



Following is a screenshot of a VOIP dashboard on OpManager. Here we can see a bad call with high jitter and latency.

MOS for a voice call with Jitter, Packet Loss, and delay.

Now the administrator can see into the bandwidth usage pattern of the particular link which connects to the remote site in the same page. Using the detailed bandwidth reports like top applications and conversations, generated using NetFlow add-on, network administrator can quickly identify the root cause of the VOIP degradation. In the screenshot, we can see there is a backup process occupying most of the bandwidth during the period when performance degradation happened.

Voice degradation due to backup process

Based on the observations the backup process is rescheduled for non-business hours and this helps increase the voice quality during business hours.

2. Using NetFlow add-on - CBQoS reports to identify traffic drops:

Another angle to investigate this VOIP degradation is examining the QoS policies defined at the router level. Here we can use the CBQoS reporting ability in NetFlow add-on, to find drops in voice traffic due to insufficient bandwidth allocation or lack of priority routing to the voice class.

In the following screenshot, CBQoS graph gives you the pre and post policy metrics including the drop percentage for each class. Using this information, the administrator finds traffic drop in VOIP class and so can raise the VOIP priority to route the voice traffic in best effort.

Drop in voice traffic - CBQoS report

Hope this helps you understand the functional advantages in using VOIP and NetFlow add-ons with OpManager. Please write to us if you have any questions. Our support email id is netflowanalyzer-support@manageengine.com

Thanks

Raj

We have discussed about application detection and grouping in our previous blog . Now it is time to implement QoS policies based on the results. To provide preferential service to a specific type of traffic, it is necessary to define a class based QoS policy to raise the priority of the traffic. Here the class refers to different traffic classes or types identified in the discovery phase.

Fundamentally, QoS helps to reduce the delay and jitter for sensitive applications like VOIP or video by raising the priority of a flow or limiting the priority of another flow. Before deploying QoS policies it is important to know the threshold settings of max packet loss and max delay for those traffic classes like VOIP. This helps us to allocate more bandwidth and increase the priority for delay sensitive applications. Here are the max delay and jitter specification for voice, video and data traffic recommended by Cisco.

Now let us dive deeper into QoS configuration. It has four steps

1. Creating a traffic class or class-map

2. Creating a policy or policy-map

3. Associate a traffic class to a policy

4. Attaching the policy to an Interface

1.Creating a traffic class or class-map:

Traffic class helps to identify and name a specific traffic flow (or class) from all other traffic using different matching criterion. A traffic class is determined using a match criterion like port, protocol, IP address or an access group in ACL. Using the "class map" command one can define the traffic class with the desired criterion used to match against a specific traffic flow to further classify it.

2.Creating a policy or policy-map:

Policies help us in priority routing and queuing of the packet. This is achieved by a variety of means like - providing dedicated bandwidth, limiting bandwidth, creating queues with different routing characteristics, dropping the packets etc. A policy can be defined using the “policy map" command. Each policy specifies the action to take for packets that are in or out of profile.

3.Associate a traffic class to a policy:

Once the policy actions are defined, these actions can be associated with the desired traffic class. This helps to apply the specific policies to the traffic classes. A policy can be associated with one or more traffic classes.

4.Attaching the policy to an Interface:

Once all the class maps are associated with the defined policies, policy maps are associated with the interfaces. Here it is possible to specify the direction in which the traffic policy should be applied (either on packets coming into the interface or packets leaving the interface).

The following is an example CBQoS policy to raise the priority of voice traffic.

class-map match-all VOICE

match access-group name VOIP

ip access-list extended VOIP

permit udp any any range 16384 32767 precedence critical

permit tcp any eq 1720 any

permit tcp any any eq 1720

policy-map VOICEFAST

description Policy 6 M to MPLS

class VOICE

priority 600 64000

set ip precedence 5

The above policy provides priority with dedicated bandwidth to voice traffic with the hosts specified in the ACL list. Also sets the IP precedence bit to 5 which is critical application specification. Also click here to find how to block skype in your network using NBAR based application detection and CBQOS

And next is going to be an add-on post in this series which is very useful for VOIP deployments. I am going to talk about the NetFlow and VOIP add-ons for our OPManager in the next blog and how these add-ons are going to be helpful in QoS policies.

Thanks

Raj

The drive for QoS has become very strong in recent years because of evolving needs for enterprises to carry different types of services including voice, video, streaming music, web pages and email on a single link. One of the most complex tasks of a network architect is to design a robust network and also ensure the quality of end to end applications delivered across branch locations and data centers.

Quality of Service refers to the ability to provide better treatment for some applications over other services in the network. The primary goal of implementing QoS in business critical networks includes priority routing for critical applications through dedicated bandwidth, controlling jitter and latency. Now a day’s most of the enterprises rely on the service provider network for their day to day branch office transactions.

Typically, networks operate on the basis of best-effort delivery, in which all traffic has an equal priority and an equal chance of being delivered. When congestion results, all traffic have an equal chance of being dropped. QoS selects network traffic, prioritizes it according to its relative importance and uses congestion avoidance to provide priority-indexed treatment. Configuring QoS can also limit the bandwidth used by non critical network traffic and so makes network performance more predictable and bandwidth utilization much more effective.

Configuring and validating quality of service involve four steps.

A.    Application discovery and grouping

B.    Implementing Quality of Service (QoS)

C.    Verification of QoS treatment for interested traffic

D.    Validating QoS configuration for application performance

This blog focuses on application discovery and grouping of similar type of applications.

Application discovery and grouping:

To apply QoS policies, it is very important to identify applications that are competing for bandwidth. NetFlow and NBAR is an excellent data source to identify most of the applications. NetFlow exports consist of port and protocol information which can be mapped to a well known application conversation. Cisco embeds NBAR (Network Based Application Recognition) engine that can identify traffic up to the application layer. It is extremely useful in identifying peer-to-peer applications.

ManageEngine NetFlow Analyzer is a unique blend of NetFlow and NBAR technologies. In addition to static NetFlow based port and protocol application detection, it also supports NBAR to identify most of the peer-to-peer applications.

Application identified through NetFlow data export

NetFlow port and protocol based application detection:

NetFlow Analyzer maintains the port and protocol mapping for more than 1500 applications for application classification. Additionally it is also possible to map new applications that are running on particular IP address/range or a range of ports.  These applications can be grouped into single application. For example, the user can classify all the database applications like Oracle, MySql, MS-Sql in to one group called the database group.

Application distribution graph over time

NBAR (Network Based Application Recognition)

Intelligent application classification by examining the data payload helps ensure the network bandwidth is used efficiently by working with QoS feature. Unlike NetFlow, which relies on port & protocol for application categorization, NBAR approach is useful in dealing with malicious software using known ports to fake being “priority traffic”, as well as non-standard applications using non-determinant ports. The biggest advantage in using NetFlow Analyzer is that the user can enable NBAR on the fly from the web GUI for instant visibility and can it turn off at peak times to save CPU cycles for routing.NBAR is supported in most Cisco switches and routers and values are retrieved through SNMP. It is possible to identify applications like Kazaa, Edonkey and Skype, which use dynamic ports to transfer data. NBAR does deep packet inspection of traffic to identify these applications which normally cannot be identified with NetFlow and reports on the bandwidth they occupied.

Based on the results, we can group applications under various categories. The grouping can be done as delay sensitive applications like voice or real time video in one category, applications that use high bandwidth in another and those that are tolerant to packet loss or delay can be considered as another group. In the next blog, we will discuss about implementing QoS policies for these groups of applications based on their business criticality and priority.

Raj

ManageEngine NetFlow Analyzer