In our previous posts we have talked about duplication problem and possible solutions. We have explained how to set up automatic deduplication and hopefully this was helpful. Now we are going to go one step further and explain how to set up manual deduplication and why or when this could be helpful.

If you haven't had time to check out our past post on this subject, you can find them

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