Defrag your hard drive!

As mentioned in Scott’s blog,  “Getting the most from your NetFlow and sFlow Analysis Tool“, disk fragmentation can be the primary cause for slow performance in running NetFlow reports.

Due to the large volume of data stored when collecting NetFlow packets, disk I/O may already be pushed to the limits on your server.  Add to that a highly fragmented disk drive and you might as well go hang out at the water cooler while you wait for your report to run.

Here’s an example of an extremely fragmented disk:

As Scott mentioned in his blog, “With hard drives, blue is a good thing, red is bad. Ideally we would want to see mostly blue and white.”

But, on the other hand,  if you don’t have anything better to do with your time, if using Scrutinizer has so streamlined your network monitoring that you need to slow your day down a bit, then please, leave your disk fully fragmented and take a break!

Otherwise, if you prefer your Netflow reporting to complete in your lifetime, then defrag!

And in the spare time that you now have to kill, you can monitor excessive Facebook traffic and other odd traffic patterns on your network, or read our blogs to learn how to enable Flexible NetFlow, or give us a call to find out what else our NetFlow solution can do for you.

- Joanne

If you’re a faithful follower of our blogs, then you are familiar with the “samplicator” described in Michael Patterson’s “Free NetFlow Forwarder or NetFlow Duplicator” blog from May 29th, 2010.

If you’re not familiar with this NetFlow Forwarder application and you have the need for exporting NetFlow packets to multiple (unlimited!) collectors, then you must read his blog.

With switches or routers that do not support NetFlow export to more than one NetFlow collector, or if you have the need to export to more than the typical two collectors, the samplicator is an ideal solution.

Configuration is quick and easy and, if using the config file to list source (exporters) and destinations (collectors), extremely scalable.

Read more »

You’re in the market for a NetFlow Traffic Analyzer.  What are the key features that you’re looking for?  What makes one NetFlow analyzer stand out from the rest?  Do you have a list of “must haves”?

Such as support for Flexible NetFlow, IPFIX reporting, portable network maps?  How about automated NetFlow configuration on your routers and switches?  Is customization of the web interface important to you?  Multiple language support critical?
Read more »

Okay, back to the basics. We’ve been working with Cisco NetFlow technology for many years now, but what is NetFlow?

NetFlow is a traffic profile monitoring technology developed by Darren Kerr and Barry Bruins at Cisco Systems, back in 1996. At that time, network monitoring mostly consisted of seeing how much traffic was traversing your network, but did not include what that traffic was.
Read more »

Sampled NetFlow provides NetFlow statistics for a subset of incoming (ingress) IPv4 traffic on an interface.  Output Sampled NetFlow allows you to collect NetFlow statistics for a subset of outgoing (egress) IPv4 traffic on that interface.

The Output Sampled NetFlow feature is now available starting with IOS 12.0(24)S for IPv4 traffic on Cisco 12000 Series IP Service Engine (ISE) line cards.  In IOS 12.0(26)S, this feature was enhanced to report the input interface and support for the Cisco 12000 Series 4-Port Gigabit Ethernet ISE line card was added.

Which means that you can now export both ingress and egress Sampled NetFlow for Cisco 12000′s!
Read more »

Come see Plixer International (Booth #960) at Cisco Live at Mandalay Bay Resort in Las Vegas June 27 – July 1, 2010.

What a great opportunity to meet several of the Plixer Team members, including:

• MMM (Mix Master Mitch), our renowned NetFlow Rapper
• Michael Patterson, Product Manager
• Jon Mills, Marketing Manager
• Nathan Halverson, blogger extraordinaire!

3 NEW features will be highlighted with live demos of our NetFlow Analyzer.  Maybe we’ll show off our IPFIX and NetFlow Probe abilities?

Come see why our sFlow and NetFlow Collector are different from the rest for network traffic monitoring.

- Joanne

Lawrence Technological University is among Michigan’s largest independent colleges and also Michigan’s first completely wireless laptop campuses, as well as one of the largest wireless networks in the Midwest.

This recently published case study demonstrates how successful network traffic analysis can be performed using NetFlow reporting with Scrutinizer NetFlow Analyzer. Monitoring NetFlow exported from devices such as Cisco ASA’s, routers, switches, and numerous other NetFlow compatible devices simplifies the task of managing your network, whether wired or, in LTU’s case, fully wireless.

Read more »

Consider this – customer calls in and says that a workstation on his network was scanning their entire corporate network and how can he be alerted on this type of behavior? The behavior wasn’t exactly malicious, but rather that someone had installed an inventory application on their desktop  which scanned their entire network with snmp scans.

So, no, it wasn’t malicious activity, but that sort of network monitoring also was not authorized for that individual on their network.

Using Scrutinizer NetFlow and sFlow Analyzer, he asked how he could detect that sort of network traffic.
Read more »

The question is, how do you integrate the network management application that you have been using forever and the NetFlow traffic monitoring application data that you have recently installed?  NetFlow collection, as we have all learned these last few years, provides more and more insight into not just how much network traffic you have, but what that traffic is.

So we need to be able to seamlessly move from one application to the other.  If your NetFlow traffic analyzer is Scrutinizer version 7, then the following information should be of great interest to you.
Read more »

A customer called the other day regarding NetFlow collection and interface descriptions not matching the correct interface instance numbers.  I’d seen this issue before and knew it was not related to the NetFlow configuration, but rather that the device in question was exporting the wrong interface information in the NetFlow packets.

Michael Patterson addressed this issue in his blog, “Messed Up Interface names in Scrutinizer” in February.

To summarize Michael’s blog, the device in question was including interface instance numbers from enterprise mibs in the NetFlow packets, and most NetFlow Traffic Analyzers get the interface descriptions from the standard MIB-2 ifIndex tables.
Read more »