Juniper first started with Jflow support, similar and compatible to Cisco Netflow standard, and later added support for vendor-neutral IPFIX. Flow export in Juniper terminology refers to inline active flow monitoring. This feature is implemented directly on the data plane thus avoiding the need for dedicated flow processing hardware, which was necessary with older hardware and software

Until now we have wrote about different ways and options for exporting and collecting NetFlow traffic. Today we will go one step further in this area...

Often it is necessary to export NetFlow traffic on more than one server (production, development, test...). Having in mind that Cisco, Juniper and other devices can often export NetFlow data only on two devices, there is a need for

There are situations when you need to get NetFlow statistics, but having a device that does not export Netflow can be a bummer. There is always a solution...

When a network device is not supporting NetFlow protocol, you can use a server with a NetFlow probe to analyze traffic from the network device and to generate a NetFlow statistics.

We will call this server the NetFlow

This post gives a short explanation of NetFlow duplication problem, why it is important and how to overcome it. Network admins think about their data and if it is actually correct and deduplicated. And rightfully so! This should not be on their list of concerns - NetFlow analyzer should include out-of-the-box solution to this problem. Unfortunately, this is often not the case

As you probably noticed, interest toward NetFlow has sharply risen in the previous years. This is due to the fact that its dataset provides much more detail and effective traffic analysis than simple SNMP monitoring. It also lightweight and it does not require to store big data and intrude on people's privacy as in the case of Deep-Packet Inspection. For this reason,