Thanks to Jimmy D, our renowned International Sales Channel Manager, we have a proven solution for monitoring NetFlow traffic for home users.

A situation arose for Jim where his wife and daughter would be in Florida caring for his parents while he was still here in Maine. The geek that he is, he didn’t want distance to keep them apart.

So he decided to provide voice, video, and network monitoring while they were in Florida. To achieve this, he decided to set up a small embedded server rack in his parents’ Florida home. This would allow for VoIP, Video, network traffic monitoring, and a web server.

Read more »

To celebrate the release of Version 7.0 of Scrutinizer NetFlow and sFlow Analyzer, which is absolutely free, I thought I’d share with you three fabulous free resources for Cisco network administrators. Read more »

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

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

As a field engineer for Plixer I do my fair share of training customers. I’ve found that the most effective and entertaining way of teaching the use of Scrutinizer is by getting right into the network and showing customers how I look for anything that appears out of place.

While reviewing the Flow Analytics Threats Overview gadget, I decided to drill into the P2P Monitor algorithm. As the customer is a well-known college  I had a feeling I would see something interesting here.

When a user clicks on the P2P Monitor link, a new Scrutinizer alarm window pops up showing a list of hosts that are involved in network behavior resembling P2P traffic.

One of the administrators said: “Hey… That right there is a workstation…” We immediately clicked on the user to see what kind of traffic this host was generating.

What surprised me wasn’t the fact that this guy was abusing the college’s bandwidth by taking up about 1.5% of a gigabit link by himself, but how he was able to conceal his abuse by using a port range commonly used for VoIP, in an environment where VoIP isn’t out of the ordinary. This technique allowed the user to circumvent packet shapers and an ASA firewall with an IPS module. To add insult to injury, QoS has been implemented to give priority to VoIP so that others would have to take a back seat to this user’s illegitimate traffic use.

We have to remember that Flow Analytics is analyzing behavior, not just what ports are being used. What gave it away is that although VoIP traffic is not out of the ordinary on this link, the behavior of this VoIP traffic was.

If you look at the bottom of the list, you’ll see conversations using ports commonly reserved for VoIP being used in a way that is not consistent with normal end user VoIP traffic. For practical blogging purposes I had to cut off the report at 100 conversations, but there were several hundred conversations that were too small for real VoIP traffic.

I have to admit I got a kick out of this one. You can run, but you can’t hide from Scrutinizer and Flow Analytics.

Raul J Duran

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.

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