7 Features of Highly Effective NetFlow Analyzers

Posted in NetFlow on September 7th, 2009 by mike@plixer.com
7-features-of-highly-effective-netflow-analyzers

Guys like Stephen Covey keep me inspired.  Have you read his book “Seven Habits of Highly Effective People“.  I thought it was great.  It lead me to believe that it was high time someone blogged about what sets NetFlow and sFlow reporting tools apart: Read more »

Michael Patterson
Scrutinizer Product Manager
Follow Me on Twitter
Tags: , , , , , , , , , ,

ToS, DSCP and NetFlow…. what the DiffServ? Part 4

Posted in NetFlow on August 18th, 2009 by mike@plixer.com
tos-dscp-and-netflow-what-the-diffserv-part-4

This is part 4 of an 4-part series (so far 4 parts) on the ToS field (i.e. Differentiated Services Field) of IP frames. I finally get into how all this relates to NetFlow in 2009.  Make sure you have already read Part 1, Part 2 and Part 3 of this blog.

ToS and DSCP part 4
At the end of Part 3 of this blog series I digressed very briefly on how CBQoS can be used to modify DSCP values on packets which come into the router.  In other words, VoIP traffic that comes in on ports 4569 and 5060 could enter a router with one DSCP value 0×00 and leave with a completely different one e.g. 0xEF (i.e. 11101111).    Read more »

Michael Patterson
Scrutinizer Product Manager
Follow Me on Twitter
Tags: , , , , , , , , , , , , ,

ToS, DSCP and NetFlow…. what the DiffServ? Part 3

Posted in NetFlow on July 30th, 2009 by mike@plixer.com
tos-dscp-and-netflow-what-the-diffserv-part-3

This is part 3 of a series on the ToS field (i.e. Differentiated Services Field) of IP frames. I’m getting closer to how it relates to NetFlow and sFlow.  Make sure you have already read Part 1 and Part 2 of this blog.

ToS part 3
In this blog I copy largely from RFC 2474, which was written in 1998. I discuss how 6 bits of the 8-bit ToS is now the Differentiated Services Code Point. See the screen capture below from my first blog. This is where we are today however, many of us still refer to this field as ToS (i.e. type of service). Sometimes it is called the Differentiated Services Field (DSF) but, not as often.  Read more »

Michael Patterson
Scrutinizer Product Manager
Follow Me on Twitter
Tags: , , , , , , , , , , , , , ,

Using Cisco CBQoS to monitor QoS on your network

Posted in Denika, NetFlow, Network Health Report on June 7th, 2009 by tomp@plixer.com
using-cisco-cbqos-to-monitor-qos-on-your-network

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.

-Tom Pore
Follow me on Twitter
Tags: , , , , , , ,