About Netflow Collector in packet tracer

Question

How Netflow collector works in packet tracer to analyze the different parameters like counter bytes and counter packets

Answer 1

NetFlow collectors work by receiving and collating NetFlow updates, and in general will keep a local connection table to mirror the connection table on the router side. Counters for bytes (or octets) and packets are sent by routers configured to keep tabs on data flows and summarize the volumes in periodic updates; this is distinct from a packet capture containing the details of each packet, and is much more compact.

The tables on each side use an explicit tuple of sending IP, receiving IP, protocol, and (for appropriate protocols) sending port and receiving port. This identifies the communication sufficiently that when the byte counters and packet counters are received as part of a datagram, they can be matched to the correct conversation with reasonable accuracy.

There's also an implicit factor of time: these tables are of finite size, and the oldest entries (the ones that have been updated least recently) will get pushed out periodically in order to make room for records of conversations that are still on-going. If another packet comes in later matching the same hosts/protocol/ports, it gets noted as a new conversation.

You're probably using Cisco equipment, given the use of Packet Tracer, and so you should have a look at how Flexible NetFlow is configured on those platforms. Note that some of those fields are marked "match" and some "collect". The "match" fields are must-have, and you'll see that they match the identifying tuple I mentioned. The others are "collect" and you'll see from that example that there are a lot of other fields that can be sent alongside byte and packet counts for analysis -- which means that there are a lot of potential combinations that can be sent. In the Flexible NetFlow format, which uses NetFlow v9, template datagrams are sent periodically to tell your NetFlow collector how to read the actual data being sent in the other datagrams.

The important thing to realize when looking at that configuration is that there's no guaranteed "I'll get an update every X seconds" aspect -- update rates vary according to how busy the router is, and if UDP datagrams are dropped or delayed. As a result, byte and packet counter analysis is going to be at the mercy of when the data actually comes in if you're trying to do live analysis; you'll find that it's much more reliable in retrospect (even a few minutes afterward) when all of your data sources have reported in and filled in their byte/packet counts after-the-fact, and you're looking at totals for the whole conversation.