So far we've been looking at ways to monitor our device specifically. Simple Network Management Protocol, or SNMP, gathering statistics, syslog, gathering those informational or emergency messages or warning messages that our device is telling us that, "Hey I have a problem or this has come up, this has gone down." Well what about traffic flow? How could we gather statistics on the traffic flow so we can figure out who is using this particular type of traffic, so this particular application, how can we monitor that? How can we see who is over utilizing the network? We can implement a feature such as NetFlow to do that.
NetFlow is a great way to do accounting of traffic inside of your network. So we are tallying things, like source IPs, destination IPs, what protocols, and we can use this, in fact, service providers can use this to do billing. If you're a service provider billing customers based on usage, they're going to get it from NetFlow. This is an industry-standard technology, okay. So we're measuring utilization, resources, and you could also do this to do planning. If you're trying to get a sense of the traffic flow and a new rollout and you're trying to understand, "Hey, what protocols go across this?" You could use NetFlow to get a high-level perspective. Now it's not as powerful as things like Network-Based Application Recognition, or NBAR. So you have to understand that it does have some shortcomings. It's still rooted in an analysis of things like source and destination ports and IP protocol IDs. So it is not able to really ascertain things like application layer information, but it's still quite powerful.
The structure that we're going to be delving into is we can enable this NetFlow technology on our interfaces. And so we can say, I want to monitor the flow of traffic ingress on this port, ingress being coming in or egress being leaving. And we would then pump the information to what is called a NetFlow collector and that's where all of the goodies, the reporting, the analysis, the collating of data can be done.
So what is a flow? We have to understand what a flow is to fully understand what the purpose of NetFlow and collection is all about? Well a flow is traffic with common characteristics going in one direction. It's not the flow of traffic going from source to destination then back again, no just from source to destination, so unidirectional traffic flows. But I also mentioned with common characteristics - source and destination IP address, source and destination port numbers, the layer 3 protocol type, type of service information, and then the interface that it arrived on. So all of these being equal then that traffic would be considered part of the same flow.
If I'm ever studying NetFlow, knowing these and being able to recognize these things that NetFlow looks at, that would be the sort of thing to know. Historically, that's what's important here.
So we've gathered our flow statistics. We are using our NetFlow collector, all right. So that would be a third-party application of some type that we'd get our hands on and folks, you could do a quick search in your favorite web browser for NetFlow collectors and the list goes on and on and on. You can even click down at the bottom to go to the next page and the next page and they're still legitimate NetFlow collectors you could get your hands on. As you can see here it is the ability to identify what's going on in regards to those flows of traffic.
I would just want to say something that struck me when I looked at this and that is sometimes in like a design class we'll talk about top N reporting. Talk about this thing called top N reporting. And many times in networking, we want to know like who the top 5 protocols are, the top 10 protocols, the top 5 speakers, the top 5 sources, right? And so that's, in fact, what we're looking at. This is an example of specific top N reportings done, top 5 conversations, top 10 applications. So just in case, you ever hear that term top N reporting, you've now seen an example of it, might be a while till you do it and there's no shame in that, but now you understand what it means.
If we were to dissect what happens on the NetFlow collector, now wait a minute, what is the NetFlow collector, is that a router? No that is the destination for this NetFlow information. We do have to understand that there's a lot of potential data that can be sent over to the NetFlow collector. We can filter it, so we can say, you know what, "I don't want that kind of information, I don't want that source." So think about a NetFlow collector getting NetFlow information from a source that it doesn't want to have as input to the reporting. We also aggregate the data. So instead of lots and lots of itty-bitty pieces that amount to one large thing, we can do an aggregation of that data. And all of this is to make this a scalable technology because we could be inundated by information.
When we look at the amount of traffic that would be flowing through a production router and one of the key locations of our infrastructure, we might find that it is dealing with just inordinate amounts of data. You know, we're talking tens of gigabits of data or tens of gigabits of traffic, which then results in a lot of NetFlow information, right? So we filter, we aggregate, and then we can output to the applications that want to read this data and do their number crunching against it.
NetFlow sounds pretty intimidating, it does, at least, that was my first impression when I was learning about it a while back. And what we see from the configuration, it's really quite straightforward. Let's look, in fact, at the configuration itself. We go to the interface and we say, "Hey I want to keep track of traffic that either comes into this interface or leaves this interface, maybe both or maybe just one or the other."
R1(config-if)#ip flow ingress
R1(config-if)#ip flow egress
R1(config)#ip flow-export destination 10.1.10.100 9996
R1(config)#ip flow-export version 9
But remember it's unidirectional, folks, it's unidirectional traffic flow.
So let's make sure you know these terms, ingress and egress. Ingress coming in, egress leaving, exiting. So it's on an interface-by-interface basis, you can say ingress for inbound, egress for outbound, got you covered there. Then I want to pump it to the collector. What do I have to know about the collector in order to make this work right?
We need three pieces of information. First and foremost, we need to know it's IP address and therefore, we also need to make sure we have layer 3 connectivity to it. So we have to be able to successfully ping that NetFlow collector so that way there we can send the NetFlow information to it, right? So we know the IP address, here it's 10.1.10.100, we put that in. But which port is it speaking on? Which port is it listening to? That is a value we have to provide as well. Usually, it's 9996, so that's usually what is used, the industry standard, but it doesn't have to be. That NetFlow collector might be using a different User Datagram Protocol, or UDP, port number, that's right, UDP port number. And you have to make sure you specify the right UDP port number here or else the NetFlow collector will not get the information you're sending it.
And then on top we need to know what version of NetFlow it's running. There are different versions out there. Version 9 though is the most versatile, it's what we want to use today. But there are other versions 1, 5, 7, 8, 9, 9 may or may not be backwards compatible with other versions, I know it's not with 8 or 5. So stick with 9, just go with it for yourself, draw your devices in your NetFlow collector. But let's recap; 3 pieces of information, you need to have the IP address, you need to know the port number it's listening to, UDP port number that is, and then you need to know the version of NetFlow that is running. Let's use number 9.
Few verification commands here, it's verified whether we have NetFlow configured on an interface, inbound or outbound. Let's go to the interface; show ip interface. Notice IP is listed there, that show interface Gigabit Ethernet, show ip interface Gigabit Ethernet and then look at the input and output features we have set up on this interface. Input feature NetFlow ingress, output features NetFlow egress. But I would like to also verify who I'm sending the NetFlow information to as well as the version.
R1#show ip interface GigabitEthernet0/1<output omitted>Input features: Ingress-NetFlow, MCI CheckOutput features: Access List, Post-Ingress-NetFlow, Egress-Netflow
R1#show ip flow exportFlow export v9 is enabled for main cacheExport source and destination details :VRF ID : DefaultDestination(1) 10.1.10.100 (9996)Version 9 flow records43 flows exported in 15 udp datagrams
We do the show ip flow export command, plainly, that's our destination and the version, those would be the things we would care about. Also, want to be thinking about the ports, making sure. So let's say you're talking to the administrator of your NetFlow collector and they're saying, "Hey, I'm not getting your information from this router." You would want to make sure the destination, the port, the version are all aligning to what is actually out there and expected. So show ip flow export, another good command for us here. This command, in fact, is one of the most powerful for you. So let's say you're not doing NetFlow accounting, you're not looking to build graphs, but you want to understand more about your network, you want to understand what's going on underneath. Because very often, even really talented admins, you know, they focus on connectivity, we're talking layer 3 that's what we worry about, I got layer 3.
And then if everything has got connectivity, we in fact, almost lose sight of what is going on in our network because everything is working, right? Well if you are trying to gather information about your network, you're trying to gather information about existing protocols, applications that are running in your environment, this command is where it's at. So you do show ip cache flow and what this is going to do is, this is going to say, "Hey, here is all of the information that I have observed from things like monitoring ingress traffic on this particular interface." And so you're going to be able to look and say, "Oh, I got a lot of Telnet going on." So what would that mean to you? "Hey, people are using Telnet still, let's kill it. Teach everybody to use Secure Shell." Maybe that's the reaction or maybe it means I don't want to cut off Telnet in my access control list. And so we could do a pretty good analysis of the traffic that is going on in this interface by looking at all of the protocol information. So that's really for me where it's at, this is really useful, okay, really useful.
Branch#show ip cache flow<output omitted>IP Flow Switching Cache, 278544 bytes2 active, 4094 inactive, 31 added6374 ager polls, 0 flow alloc failuresActive flows timeout in 30 minutesInactive flows timeout in 15 secondsIP Sub Flow Cache, 34056 bytes2 active, 1022 inactive, 31 added, 31 added to flow0 alloc failures, 0 force free1 chunk, 0 chunks added last clearing of statistics 00:49:48Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)------------ Flows /Sec /Flow /Pkt /Sec /Flow /FlowTCP-Telnet 19 0.0 19 58 0.1 6.5 11.7TCP-WWW 14 0.0 8 202 0.0 0.0 1.5TCP-other 2 0.0 19 98 0.0 2.2 8.9<output omitted>SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP PktsGi0/1 172.16.1.100 Gi0/0.10 10.1.10.100 01 0000 0000 1341
So you turn on the NetFlow for a little while during a baseline period of utilization in your network. And you come to this command and you go, "Oh, I didn't know that protocol was running." Maybe you've got obscure ports that are in use, proprietary applications. Now NetFlow is not going to be able to recognize things like proprietary applications, but it would be able to tell you, "Hey, I saw something with this UDP port or this TCP port", and then you could enumerate that later on to figure out, "Hey, what's port 5234?" And your software team is like, "Oh, we built that to do X, Y, and Z." "Oh okay, I understand my network a lot better." So for me, this is what the whole point of this NetFlow discussion is. It is the point because you may not be doing that interfacing with the NetFlow collector and even without that, this is useful.