Monitoring with CBQoS (Class-Based Quality of Service) in addition to NetFlow and IPSLA on a network can provide additional insight into an organization’s critical applications utilization. As more companies deploy VoIP and video conferencing CBQoS can be utilized to show how these applications are delivered across an infrastructure with defined policies. CBQoS is a Cisco feature set that is part of IOS 12.4(4)T and above, and is available at no additional cost. The QoS statistics provided by CBQoS are made available via SNMP polling and give detailed information about the defined QoS policies applied to interfaces and class-based traffic patterns.

A typical network with no QoS policies defined runs with a best-effort delivery, with all traffic having equal priority and an equal chance of being delivered. When these networks become congested, all traffic also has an equal chance of being dropped. The definition of policies (class-maps defined in policy-maps) allows specific traffic to be prioritized according to its relative importance and uses congestion-avoidance to ensure its delivery. CBQoS can also be used to limit the amount of bandwidth for certain network traffic making network performance more predictable and utilization more efficient.

CBQoS can be used to ensure network applications such as VoIP and video conferencing receive the highest priority. It also provides an in-depth look at the amount of traffic used, both before it is filtered through a policy (pre-policy) and after it has been filtered (post-policy). If any of the traffic was dropped during congestion because of the rules defined in a policy, CBQoS reports the amount of traffic that was dropped.

In the following example, I have configured one of Plixer’s lab routers (sent home with an employee) to prioritize both IAX and SIP traffic for VoIP calls along with a priority for webmail and file transfer. This policy, attached to a WAN interface, will ensure that the employee will be able to effectively work from home. After the policy is in place, I enabled CBQoS to monitor the pre-policy, post-policy, and dropped traffic from my defined class-maps.

In my example, I have classified the VoIP traffic for support protocol of Plixer’s PBX. When an employee is at home, the VoIP traffic will be given 70% (priority) of the interface, only when congested. I have classified PlixerVoIP traffic with an access-list.

lab(config)#ip access-list extended PlixerVoIP
lab(config-ext-nacl)#permit udp any any eq 4569
lab(config-ext-nacl)#permit udp any any eq 5060

This PlixerVoIP class references out access-list, defined above.
lab(config)#class-map match-any PlixerVoIP
lab(config-cmap)#match access-group name PlixerVoIP

The “Web_Email” class includes regular web taffic like HTTP, HTTPS, FTP, SMTP, and POP3. In other words, this includes web browsing, file transfer, and email traffic.

lab(config)#class-map match-any Web_Email
lab(config-cmap)#match protocol http
lab(config-cmap)#match protocol secure-http
lab(config-cmap)#match protocol ftp
lab(config-cmap)#match protocol smtp
lab(config-cmap)#match protocol pop3

The policy-map is used to match the classes, above, with the policy you define for that type of traffic.
In my examples, we are giving PlixerVoIP traffic 70% priority, if that traffic is present. We are also setting the DSCP EF bit to notify routers down the line that this traffic is important PlixerVoIP traffic. We are giving Web_Email web browing traffic 75% of the remaining bandwidth. For all traffic that was not defined (the class-default), it will just be fairly queued.

lab(config)#policy-map TP-Pol-FastEthernet0/1
lab(config-pmap)#class PlixerVoIP
lab(config-pmap-c)#priority percent 70
lab(config-pmap-c)#set dscp ef
lab(config-pmap)#class Web_Email
lab(config-pmap-c)#bandwidth remaining percent 75
lab(config-pmap-c)#exit
lab(config-pmap)#class class-default
lab(config-pmap-c)#fair-queue

On the WAN interface (your connection to the Internet, in this example it is FastEthernet0/1).
The NBAR protocol-discovery command must be applied for NBAR to recognize traffic.
The service-policy command applies your QoS policy to the Interface.

lab(config)#interface FastEthernet 0/1
lab(config-if)#ip nbar protocol-discovery
lab(config-if)#service-policy output TP-Pol-FastEthernet0/1

Now that our policy has been applied to the interface, let’s enable CBQoS.

lab(config)#enable
lab(config)#configure terminal
lab(config)#snmp-server ifindex persist
lab(config)#snmp mib persist cbqos
lab(config)#end
lab(config)#write mib-data
or
lab(config)#write

To verify our CBQoS commands, we can show them in the running-config:

lab(config)#show running-config | include cbqos
snmp mib persist cbqos
lab(config)#show running-config | include persist
snmp-server ifindex persist
snmp mib persist cbqos

We can monitor the CBQoS statistics with the Denika add-on to Scrutinizer.

As you can see below, there isn’t enough traffic to cause dropped packets, so the pre-policy traffic is the same as the post-policy traffic. The dropped bytes trending graphs indicate that we have not had any problems with our business specific applications.

Hello Everyone,

If you would like to see other blogs on how to setup IP SLAs check out these links.

IP SLA – Jitter – 1 of 4
IP SLA – ICMP Echo – 2 of 4
IP SLA – HTTP – 4 of 4

This week we are focusing on the Cisco IP SLA TCP Connect operation.  One can consider this to be a ping over TCP.  The TCP Connect operation can be useful in several ways.  Administrators can set it up to baseline existing performance, and also to monitor changes in performance due to configuration changes. 

Some companies use this monitor for their own verification of outsourced service provider SLAs.  This information can then be used to negotiate more cost effective SLAs with their service providers.

The TCP Connect operation is also a great alternative to measure response times when ICMP ping is blocked.

If you would like detailed instructions on setting up the Cisco TCP Connect IP SLA operation, check out our white paper on how to set it up.

Check out the next and final part of the series – HTTP IP SLAs.

Raul

Hello Everyone,

If you would like to see other blogs on how to setup IP SLAs check out these links.

IP SLA  – ICMP Echo – 2 of 4
IP SLA – TCP Connect – 3 of 4
IP SLA - HTTP - 4 of 4 

I’m going to be putting together a four part series on some common Cisco IP SLA monitor configurations.  Cisco IP SLAs are great ways to get statistics on different types of communications between routers.  They’re relatively simple to set up, and reports can be generated by an SNMP trender.

focus on the Jitter monitor.  You can get a ton of information from the Jitter monitor, starting with latency, Packet Loss, and Jitter.  If the router’s clocks are synchronized you can also get the latencies for each way.  By adding a VoIP codec to the monitor, the router can generate the Mean Opinion Score (MOS), and the Impairment/calculated planning impairment factor (ICPIF) score.

Check out Plixer’s white paper on setting up the Jitter operation.  It will walk you through setting up a Jitter monitor, how to trend the statistics, and generate reports.

If you plan on using the jitter operation to monitor VoIP, pay special attention to make sure that you are using the codec that matches the actual codec being used.

It is also important to have realistic expectations on MOS values pertaining to each codec.  Although Cisco’s scale is 1-5 in their documentation, production environments will not see a 5.  The chart below will help in determining how well your communications are doing.

Cisco VoIP Codec White Paper

Scrutinizer Netflow Analyzer has a My View page that contains gadgets that can integrate with third party applications.  One of these applications is Denika which can trend the IP SLA statistics.  If you have Scrutinizer and Denika ask us about a custom VoIP gadget to display VoIP IP SLA Statistics.

Check out Part 2 of the IP SLA series.

Raul