A couple weeks ago a customer reported an issue where, apparently, our NetFlow and sFlow Analyzer was not seeing traffic from Vyatta Core 6. This being the second time the issue is reported to us, I was encouraged to talk about it.

In general, whether it is a collector issue or an exporter issue, from a tech support view point, I would say that the Scrutinizer web interface does a great job signaling what might be preventing proper network traffic analysis. This customer’s Scrutinizer web  interface seemed to be saying: “There are flows coming from Vyatta, but there is nothing to report on”. Whenever he restarted the Netflow collector, everything would work well for a short period of time, then in the Scrutinizer web interface, while the Vyatta widget would  still be green, indicating that it is eventually sending netflow, its interfaces would turn yellow (no data to report for this interface) for a few hours before the collector completely stops.

What we found

His Vyatta was sending NetFlow packets that were not properly constructed. Looking at their content, we found that they did not contain flow information, but packet headers only, which gives Scrutinizer nothing to report on.

Recommendations

Unfortunately I am not a Vyatta expert. If you are experiencing a similar issue, I recommend consulting the Vyatta community, or try other software base routing/firewall systems such as nProbe, pfsense, Quagga,etc. I can’t tell you much about pfsense or Quagga; however, once in a while we get calls from nProbe users, it supports NetFlow and seems to work well for them.

Hello everybody! My name is Paul Dube and I have recently graduated from the University of Maine in Orono with a degree in Computer Science and joined the support team here at Plixer International. Over the course of the past few weeks I’ve been trying to learn everything there is to know about Scrutinizer, NetFlow, sFlow and network traffic analysis. During this process I’ve come across a lot of great resources that I would like to consolidate into one place to help you get started.
Read more »

Let’s say that you are looking for information regarding network traffic taking place between company workstations and an application server; we’ll call it acmeapplication.com. You know that acmeapplication.com is using random port numbers to send downloads back to the workstations making the requests.

When using NetFlow analysis software to monitor network traffic, you may see lots of HTTP port 80 conversations with the assistance of the Conversations filter, but nothing showing the random ports used by acmeapplication.com, as demonstrated below.

Read more »

Hi there guys! Great news this week. We’ve decided to start beta for the first phase of our NetFlow migration tool.
With this simple tool, we’ll be able to take all your NetFlow v5 records you collected from Scrutinizer v6 and be able to migrate them over to the new Scrutinizer v7 format.

We’re going to start this migration test one bite at a time, since your archived NetFlow and sFlow database integrity is important to us.

I’ve seen some really incredible Network Topology maps out there and I’m sure there was significant time invested to make them that way. So lets start out by making life easier and let our network traffic map migration tool move them over for you!

If you’d like to volunteer and help me beta test the migration, I would love to help.
Call our customer support desk at (207) 324-8805 ext. 4 and we can schedule a time to get things going.

PS: The migration BETA is for the Flash maps only. The google map integration needs a few more tweeks. We will be announcing the release of the full database migration tool at a later date once internal testing has come to a completion.