In this session we're going to take a look at Netflow. We're going to look at what it is, how it works, what its uses are and some of the applications. We'll look at how we generate and export flow records and then we'll have a look at nfdump and nfsen and the architecture of these applications and how we go and use them. So what is a network flow? Well a network flow is a set of related packets, packets that belong to the same transport connection, for example, TCP, same source IP address, source port, destination IP address, destination port or UDP, same source IP address, source port, destination IP address, destination port. Some tools consider bi-directional flows, in other words A to B and the answer B to A as part of the same flow. You can read more about traffic flow on the wikipedia site in the url posted on this slide. So let's have a look at a simple flow. The slide shows a series of packets running between two routers. Some packets are red, other packets are green. The red packets belong to flow X and the green packets belong to flow Y. And this ends up being a simple flow running between the two routers. Cisco IOS' definition of a flow is a unidirectional sequence of packets sharing the same source IP address, same destination IP address, source port for UDP or TCP and 0 for other protocols destination port for UDP or TCP, type and code for ICMP or 0 for other protocols the same iprotocol,the same ingress interface and the same IP type of service. So let's have a look at this example. The slide shows six packets. Which of these six packets are in the same flows? Well let's look, have a look at packet A. Packet A source address one two three four, destination five six seven eight using a TCP protocol, source port 4001, destination port 22. Packet B source is 5678, destination 1234, TCP source port 22, destination 4001 and you can notice that packet B is kind of a response, the reverse of packet A. Packet C source 1234, destination 5678 using TCP protocol, source port 4002, destination port 80. Packet D 12345678 using protocol TCP, source port 4001, destination port 80. Packet C and D are coming from the same source going to the same destination but have the same destination port but different source ports. So is that the same flow or a different flow? And then let's look at packets E and F. Both E and F are UDP source address one two three four, destination eight eight eight eight four. Packet E source port six five four three two, destination fifty three. Packet F is the reverse of packet E, source 8888, destination one two three four, source port 53, destination 65432. So I'll give you a second to think about which are the same flows and which are not. Now let's have a look at the answer. So we've highlighted in green packets A and B so they're part of the same flow. A is the outbound, B is the response. Just know that Cisco IOS consider this different flows but for our purposes the bi-directional flow, they're part of the same one. Same is true for E and F. E is the output, F is the response. But what about packets C and D? Same source, same destination, same destination port, but the source ports are different. So these two packets are in different flows. There are different connections to the same destination. Let's have a look at flow accounting. Flow accounting is a summary of all the packets seen in a flow so far. So flow identification which will be the protocol the source and destination ip address and port. It will also include the packet count, the byte current start and end times and maybe additional information such as as numbers and net masks. Flow accounting requires the traffic volume and type but not the content. Netflow is not able to look inside IP packets but with netflow we can answer questions like: Which user or which department has been uploading or downloading the most? Which is the most commonly used protocols in my network? Which devices are sending the most SMTP traffic and where to? Netflow is very useful for identifying anomalies and attacks on your network or within your network and more fine-grained visualization, in other words graphing, is possible than can be done at the interface level on the router itself.

© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.

Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.