Our NetFlow and sFlow Analyzer receives  data collected over a 1 minute time interval  per flow, and can store up to 100 000 conversations (flows) per device. One limitation in NetFlow monitoring today is the amount of disk space needed to store the collected network traffic information. Especially, if one’s intent is to hold on to that information  for a certain period of time. In this blog I will try to help you understand how Scrutinizer archives data. In addition I will talk about the NetFlow Calculator, which can be a helpful tool for estimating the disk space needed on your NetFlow analyzer server. Read more »

There is no doubt that flow technology is revolutionizing network monitoring. In this  NetFlow/J-Flow/IPFIX/sFlow era, there is no need to settle with only knowing utilizations on the network. Besides, little analysis can be done in monitoring bandwidth only anyways.

Scott wrote a blog earlier that made a valid point: “A Network Administrator’s abilities are only as good as his awareness of what happens on his network.” In harmony with that statement, it’s beneficial to have useful tools to be able to collect that traffic information.

Recently, I learned that J-Flow is supported for the Juniper SRX series Gateways. I thought this might be good information for people who want to start monitoring flows on this type of device, especially our NetFlow and sFlow Analyzer users, since it can also process J-Flow packets. Below are some sample commands taken from Juniper’s Knowledge Base which walks you through your J-Flow configuration. Read more »

Today I will discuss the command “ip flow ingress infer-fields”, mostly used in the NetFlow configuration of NetFlow switches. Being the newest member of the Plixer International Tech Support team I am discovering how amazingly large certain networks can get. This is when an outstanding network monitoring and diagnosis capability come in handy. Read more »

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.