WEBVTT 00:00:00.000 --> 00:00:10.000 Now it's time for our Flexible NetFlow Configuration and Verification discussion. 00:00:10.000 --> 00:00:15.000 So what exactly is Flexible NetFlow or NetFlow in general? 00:00:15.000 --> 00:00:18.000 Right, so what we're dealing with is a tool. 00:00:18.000 --> 00:00:22.000 A tool that gives us the ability to gather traffic as it flows through the network. 00:00:22.000 --> 00:00:24.000 Now you might be saying, oh my gosh, that's SPAN, RSPAN, ERSPAN. 00:00:24.000 --> 00:00:26.000 No, not exactly. 00:00:26.000 --> 00:00:32.000 You see, SPAN, RSPAN, and ERSPAN allows us to capture the traffic, 00:00:32.000 --> 00:00:41.000 send it to a particular destination that has a packet capturing tool like Wireshark connected to it, 00:00:41.000 --> 00:00:47.000 and then we can see everything about that particular packet, the data, everything. 00:00:47.000 --> 00:00:48.000 We can read it, right? 00:00:48.000 --> 00:00:52.000 If it was a Word doc, we'd be able to read the Word doc as an example. 00:00:52.000 --> 00:00:54.000 That's not what NetFlow does. 00:00:54.000 --> 00:00:57.000 So although it is a tool that allows us to gather traffic, 00:00:57.000 --> 00:01:02.000 it's about gathering traffic statistics as it flows through our network. 00:01:02.000 --> 00:01:05.000 And why might I want to gather traffic statistics? 00:01:05.000 --> 00:01:09.000 For billing purposes, for security purposes, for performance purposes, 00:01:09.000 --> 00:01:14.000 for just downright tracking what is going on in our network. 00:01:14.000 --> 00:01:16.000 You know, when we think about other tools that exist out there, 00:01:16.000 --> 00:01:18.000 like something like Cisco DNA Center, 00:01:18.000 --> 00:01:23.000 it can rely and get useful information and statistics from something like NetFlow. 00:01:23.000 --> 00:01:26.000 When you think about our Cisco Threat Defense solutions, 00:01:26.000 --> 00:01:28.000 we have the ability to use NetFlow for what? 00:01:28.000 --> 00:01:34.000 Measuring bandwidth, measuring application performance, utilization, and so on and so forth. 00:01:34.000 --> 00:01:39.000 So it's more about the numbers, the statistics, the measurements, 00:01:39.000 --> 00:01:43.000 more than what exactly is the traffic, what exactly is the data payload. 00:01:43.000 --> 00:01:47.000 That is what SPAN, RSPAN, and ERSPAN are for, whereas Flexible NetFlow, 00:01:47.000 --> 00:01:51.000 a totally different tool that is available to us. 00:01:52.000 --> 00:02:01.000 So, for example, we may have traffic that is flowing from PC1 out here, 00:02:01.000 --> 00:02:04.000 and we want to capture that traffic. 00:02:04.000 --> 00:02:11.000 So we can capture it ingress on this port or egress on that port, or both. 00:02:11.000 --> 00:02:13.000 It's up to us what we want to do. 00:02:13.000 --> 00:02:17.000 And then we'll know what type of traffic is flowing through the network. 00:02:17.000 --> 00:02:20.000 We might want to capture egress here, ingress here. 00:02:20.000 --> 00:02:23.000 We want to know what type of traffic is flowing through that network. 00:02:23.000 --> 00:02:30.000 So now when it comes to things like NetFlow in general, 00:02:30.000 --> 00:02:35.000 we are dealing with a flow, and a flow is unidirectional. 00:02:35.000 --> 00:02:36.000 What does that mean? 00:02:36.000 --> 00:02:43.000 It means that we are dealing with one-way traffic when it comes to this particular tool. 00:02:44.000 --> 00:02:49.000 So even though I said we could capture ingress or egress, 00:02:49.000 --> 00:02:52.000 traffic coming into the device or leaving the device on a particular interface, 00:02:52.000 --> 00:02:56.000 it is capturing the traffic flowing just in that direction. 00:02:56.000 --> 00:02:59.000 So we're only keeping the measurements for the traffic in that direction. 00:02:59.000 --> 00:03:03.000 So if we're capturing traffic, let's say, that is going this way, right, 00:03:03.000 --> 00:03:07.000 on this interface here, so we're capturing it egress, 00:03:07.000 --> 00:03:09.000 and it's only the traffic that is flowing that way. 00:03:09.000 --> 00:03:13.000 And if I want to capture the traffic coming in, then I would capture it inbound. 00:03:13.000 --> 00:03:15.000 So again, unidirectional traffic flows. 00:03:15.000 --> 00:03:20.000 So it's not worried about the end-to-end or bidirectional, I should say, communication. 00:03:20.000 --> 00:03:24.000 No, no, no, it's the unidirectional communication that we're dealing with with a flow. 00:03:24.000 --> 00:03:31.000 And so a flow in its general sense, in its basic sense, in its default sense, 00:03:31.000 --> 00:03:42.000 a flow is traffic that is coming from the same source IP, going to the same destination IP, 00:03:42.000 --> 00:03:47.000 using the exact same source port number, using the exact same destination port number, 00:03:47.000 --> 00:03:53.000 using the exact same Layer 3 protocol type, having the exact same type of service marking, 00:03:53.000 --> 00:03:58.000 and coming in that exact same interface or using that exact same interface. 00:03:58.000 --> 00:04:03.000 So if all those values are the exact same, and these would be values that we'd find where? 00:04:03.000 --> 00:04:06.000 In our packet header, as an example, yeah, in our packet. 00:04:06.000 --> 00:04:10.000 So if all of those are the exact same, then it's part of the exact same flow. 00:04:10.000 --> 00:04:15.000 If at least one of these items are different, then it's a completely different flow. 00:04:15.000 --> 00:04:17.000 It would be part of a totally different flow. 00:04:17.000 --> 00:04:18.000 So you can think about it this way. 00:04:18.000 --> 00:04:21.000 If I have traffic going from my PC to the Internet, 00:04:21.000 --> 00:04:23.000 and the traffic is going from the PC to the Internet, 00:04:23.000 --> 00:04:26.000 and let's say there's traffic going to two different places on the Internet, 00:04:26.000 --> 00:04:28.000 those are two different flows. 00:04:28.000 --> 00:04:29.000 Why? 00:04:29.000 --> 00:04:33.000 Because the source IP, even though it's the same, the destination IP would be different, 00:04:33.000 --> 00:04:37.000 and those port numbers would be different too, potentially, 00:04:37.000 --> 00:04:39.000 especially a different source port number for that communication. 00:04:39.000 --> 00:04:43.000 So as long as one of those things are different, then it's part of a different flow. 00:04:43.000 --> 00:04:47.000 If they're all the same, exactly the same values, then they're part of the same flow. 00:04:47.000 --> 00:04:48.000 All right. 00:04:48.000 --> 00:04:53.000 So in previous editions of Encore, we used to talk about NetFlow, 00:04:54.000 --> 00:04:56.000 which is the original version of NetFlow, 00:04:56.000 --> 00:04:58.000 and then we would talk about Flexible NetFlow. 00:04:58.000 --> 00:05:02.000 But on this new updated exam, Encore version 1.1, 00:05:02.000 --> 00:05:06.000 the exam objectives state that only Flexible NetFlow is required. 00:05:06.000 --> 00:05:17.000 So Flexible NetFlow allows us to pick and choose what we want to represent our flow. 00:05:17.000 --> 00:05:22.000 So traditional is these seven elements, these seven values. 00:05:22.000 --> 00:05:25.000 And I could still go with these seven elements, these seven values if I want to, 00:05:25.000 --> 00:05:31.000 but I could also go with more, so things that are not even listed here, 00:05:31.000 --> 00:05:37.000 or less, or none of these at all, and some other custom things I choose. 00:05:37.000 --> 00:05:45.000 So with Flexible NetFlow, you have the flexibility to pick and choose whatever you want to categorize as a flow, 00:05:45.000 --> 00:05:50.000 and pick and choose exactly what you want to collect from a statistical standpoint 00:05:50.000 --> 00:05:54.000 instead of being forced to only use these values. 00:05:54.000 --> 00:05:58.000 So NetFlow was only these values, and you couldn't do anything about it, 00:05:58.000 --> 00:06:01.000 whereas Flexible NetFlow says whatever you really want. 00:06:01.000 --> 00:06:06.000 So Flexible NetFlow allows you to control what is considered part of your flow 00:06:06.000 --> 00:06:09.000 and what information you collect about that particular flow. 00:06:09.000 --> 00:06:12.000 And we also get reusable configuration components here, 00:06:12.000 --> 00:06:14.000 so I can configure this aspect, this aspect, this aspect, 00:06:14.000 --> 00:06:20.000 and then if I want to reuse some aspect as part of another flow, I can go ahead and do that. 00:06:20.000 --> 00:06:23.000 So we have these different components that you need to be aware of for the exam. 00:06:23.000 --> 00:06:28.000 You've got your flow record, you've got your flow monitor, you've got your flow exporters, 00:06:28.000 --> 00:06:30.000 and you've got your flow sampler configurations. 00:06:30.000 --> 00:06:34.000 So your flow record configuration is about defining what will be captured. 00:06:34.000 --> 00:06:40.000 So when we talk about our flows, our unidirectional flows, 00:06:40.000 --> 00:06:43.000 we've got to remember that these are the basic values here. 00:06:43.000 --> 00:06:51.000 And you can still go ahead with Flexible NetFlow and use these seven basic values as is. 00:06:51.000 --> 00:06:57.000 So we have predefined flow records by Cisco for quick deployment, easy to use. 00:06:57.000 --> 00:06:59.000 Cisco constantly updates them in the future. 00:06:59.000 --> 00:07:02.000 And if you want to go with those traditional seven values, 00:07:02.000 --> 00:07:13.000 then you can use the predefined Cisco Flexible NetFlow record that uses those seven values. 00:07:13.000 --> 00:07:17.000 And then you have the ability to do your own custom flow records. 00:07:17.000 --> 00:07:22.000 So you pick and choose exactly what you want as the definition of a flow. 00:07:22.000 --> 00:07:27.000 You pick and choose exactly what you want to be collected as part of that flow. 00:07:27.000 --> 00:07:31.000 We have these options called key fields and non-key fields. 00:07:31.000 --> 00:07:38.000 So a key field would be you specifying this is what defines the flow. 00:07:38.000 --> 00:07:42.000 And then a non-key field would be like, although this is not what I define as a flow, 00:07:42.000 --> 00:07:45.000 I want you to collect this information from that flow as well. 00:07:45.000 --> 00:07:48.000 So more on that later. 00:07:48.000 --> 00:07:50.000 Your flow monitor is really what puts everything together, 00:07:50.000 --> 00:07:53.000 and you apply a flow monitor to an interface. 00:07:53.000 --> 00:07:56.000 So your flow monitor is going to be applied to the interface, 00:07:56.000 --> 00:08:01.000 defines the flow record, defines the flow exporter, and so on and so forth. 00:08:01.000 --> 00:08:03.000 And then you have your flow exporter. 00:08:03.000 --> 00:08:04.000 Your flow exporter is what? 00:08:04.000 --> 00:08:06.000 It defines the export parameters. 00:08:06.000 --> 00:08:10.000 So what is the formatting of the information that you're going to export, 00:08:10.000 --> 00:08:12.000 depending on the flow collector that you have? 00:08:12.000 --> 00:08:16.000 So you're going to have some servers set up as a NetFlow collector in your environment. 00:08:16.000 --> 00:08:18.000 And what version is that running? 00:08:18.000 --> 00:08:19.000 What formatting is it expecting? 00:08:19.000 --> 00:08:23.000 So your router has to format it properly before it sends it to the NetFlow collector. 00:08:23.000 --> 00:08:25.000 So is it version 5, version 9, version 10? 00:08:25.000 --> 00:08:27.000 You know, there's a multitude of versions out there. 00:08:27.000 --> 00:08:30.000 What is the source IP address that you want to send it from? 00:08:30.000 --> 00:08:33.000 What's the destination IP address of the flow collector you're sending it to? 00:08:33.000 --> 00:08:35.000 What is the transport protocols you want to use? 00:08:35.000 --> 00:08:38.000 And what is the source destination port numbers, as an example? 00:08:38.000 --> 00:08:39.000 And then our samplers. 00:08:39.000 --> 00:08:40.000 What is a sampler? 00:08:40.000 --> 00:08:43.000 A sampler is about reducing the load on our device. 00:08:43.000 --> 00:08:49.000 So by default, if you don't use a flow sampler, we are going to capture, you know, capture. 00:08:49.000 --> 00:08:52.000 I don't want to use the word capture because that's kind of like span, R-span, and E-R-span, 00:08:52.000 --> 00:08:58.000 but we are going to gather and analyze every single packet. 00:08:58.000 --> 00:09:05.000 Whereas with a sampler, we are only going to analyze a subset of packets instead. 00:09:05.000 --> 00:09:08.000 So if I set up a flow sampler like one in every hundred, 00:09:08.000 --> 00:09:14.000 that means only one in every hundred packets will actually be analyzed. 00:09:14.000 --> 00:09:19.000 So it's kind of like when you have an election happening in the United States or in Canada, 00:09:19.000 --> 00:09:27.000 and they send out a survey to, let's say, 5,000 people, and 5,000 people respond, 00:09:27.000 --> 00:09:33.000 they get a pretty good idea of how people are leaning in regards to that particular election. 00:09:33.000 --> 00:09:34.000 Same idea here, right? 00:09:34.000 --> 00:09:42.000 Instead of sending out a survey to every single person in America or every single person in Canada in the election, 00:09:42.000 --> 00:09:45.000 so that way they can find out what everybody is thinking, right? 00:09:45.000 --> 00:09:47.000 You're only doing 5,000 in that case, right? 00:09:47.000 --> 00:09:52.000 Reducing the load on the people involved in the overall process, same idea here. 00:09:52.000 --> 00:09:54.000 Let's reduce the number of packets that we actually analyze, 00:09:54.000 --> 00:09:58.000 and we're still going to get a pretty good result over a longer time frame. 00:09:58.000 --> 00:10:03.000 All right, so let's go look at some of these in more detail. 00:10:03.000 --> 00:10:07.000 So I'm going to show you how you can define a user-defined flow record here. 00:10:07.000 --> 00:10:12.000 So when you want to define a user-defined flow record, you type in flow record in global configuration mode, 00:10:12.000 --> 00:10:15.000 and then what you do is you specify a name for your flow record. 00:10:15.000 --> 00:10:20.000 So I'm going to just call mine Encore flow record so we know that that's what we're doing here. 00:10:20.000 --> 00:10:24.000 Now, any time you see a match value, the match value is one of those key fields, 00:10:24.000 --> 00:10:27.000 and then your collect value is a non-key field. 00:10:27.000 --> 00:10:34.000 So what the match does is it says this is what determines my flow. 00:10:34.000 --> 00:10:37.000 So the IP source address, the IP destination address, 00:10:37.000 --> 00:10:42.000 and the application name is what defines that unidirectional flow. 00:10:42.000 --> 00:10:45.000 So if it's coming all from the same source address, going to the same destination address, 00:10:45.000 --> 00:10:51.000 if it's the specific application, then that is all part of the same flow. 00:10:51.000 --> 00:10:53.000 So this is a custom one. 00:10:53.000 --> 00:10:58.000 As opposed to having those traditional values of source IP, destination IP, source port, destination port, 00:10:58.000 --> 00:11:01.000 layer 3 protocol type, type of service field, input logical interface, 00:11:01.000 --> 00:11:04.000 I have said that this is now what defines my flow. 00:11:04.000 --> 00:11:07.000 So a custom flow record instead. 00:11:08.000 --> 00:11:12.000 And also, though, you can see the collect option interface input. 00:11:12.000 --> 00:11:17.000 That means the interface input doesn't matter for the flow. 00:11:17.000 --> 00:11:19.000 However, I still want you to collect that information. 00:11:19.000 --> 00:11:27.000 So I want you to collect the IP address, source, and destination, the application name, and the interface input. 00:11:27.000 --> 00:11:31.000 But it doesn't matter what the interface input is when it comes to the flow. 00:11:31.000 --> 00:11:35.000 If it's coming from the same source, going to the same destination, and it's the same application, 00:11:35.000 --> 00:11:41.000 then you lump it as part of the same flow regardless of the interface. 00:11:41.000 --> 00:11:46.000 Now, if I wanted to match the interface, then I would use match, and that would be part of the flow then itself. 00:11:46.000 --> 00:11:48.000 It would define the flow. 00:11:48.000 --> 00:11:55.000 But in this case, collect allows me to collect more information without it having to be part of the definition of the flow. 00:11:55.000 --> 00:11:57.000 And so that's what we're doing here. 00:11:57.000 --> 00:12:06.000 We're setting up this custom flow record that's going to define my Unicast flow based on these three values, 00:12:06.000 --> 00:12:11.000 but it's going to collect the information on all four values. 00:12:11.000 --> 00:12:13.000 All right, let's talk about the flow record exporter now. 00:12:13.000 --> 00:12:18.000 So the flow exporter is basically what's the server's parameters that you're going to try to talk to 00:12:18.000 --> 00:12:21.000 and send the collective flow information to. 00:12:21.000 --> 00:12:31.000 So let's say over here we have a server, and I have my NetFlow collector up here from some vendor. 00:12:31.000 --> 00:12:32.000 There's a multitude of vendors. 00:12:32.000 --> 00:12:33.000 Just do a Google search for NetFlow collectors. 00:12:33.000 --> 00:12:36.000 You're going to be overwhelmed with the results you get. 00:12:36.000 --> 00:12:37.000 But here what do we have? 00:12:37.000 --> 00:12:46.000 We have what is the source of IP address that we want to put in the packets that we send to the NetFlow collector. 00:12:46.000 --> 00:12:48.000 So let's say right here we're going to send from here. 00:12:48.000 --> 00:12:52.000 We're collecting here, and what I want to do is I want to send it. 00:12:52.000 --> 00:12:56.000 So this is where that loopback address comes into play. 00:12:56.000 --> 00:13:03.000 So with NTP, we talked about setting up a loopback interface on your device for management communication. 00:13:03.000 --> 00:13:04.000 Well, same idea here. 00:13:04.000 --> 00:13:08.000 If you had that loopback interface now, the same one you were using for NTP as an example, 00:13:08.000 --> 00:13:10.000 you could use that one here as your source. 00:13:11.000 --> 00:13:16.000 So that way, every single packet you send to the NetFlow collector is sourced from that IP address. 00:13:16.000 --> 00:13:20.000 And therefore, now in the NetFlow collector, you could set up a filter. 00:13:20.000 --> 00:13:29.000 You could set up security parameters that indicate that you only want to collect traffic from this particular source IP address. 00:13:29.000 --> 00:13:36.000 So that way, you're not collecting information from rogue NetFlow devices that are out there maybe in your environment. 00:13:36.000 --> 00:13:38.000 It shouldn't be there, but it could be, right? 00:13:38.000 --> 00:13:42.000 So you want to protect that NetFlow collector from collecting bogus information from bogus devices. 00:13:42.000 --> 00:13:43.000 So that's a good way to do it. 00:13:43.000 --> 00:13:48.000 So if you're always constantly sourcing traffic from that same IP address, 00:13:48.000 --> 00:13:51.000 then you can set up the filters you need on that NetFlow collector properly. 00:13:51.000 --> 00:13:55.000 And then the destination is what is the IP address of the NetFlow collector? 00:13:55.000 --> 00:13:57.000 What is the formatting? 00:13:57.000 --> 00:14:00.000 So I'd have to know the formatting that this NetFlow collector is using. 00:14:00.000 --> 00:14:04.000 It might be using version 5 or version 9 or version 10 or some other version, right? 00:14:04.000 --> 00:14:05.000 So what if I know that? 00:14:05.000 --> 00:14:12.000 Then I can put that into my router so my router knows which version of the formatting it needs to use in order to send to the NetFlow collector. 00:14:12.000 --> 00:14:14.000 Transport UDP 9996. 00:14:14.000 --> 00:14:18.000 So, for example, what is the UDP port number using on the NetFlow collector? 00:14:18.000 --> 00:14:20.000 Or maybe we're using TCP instead. 00:14:20.000 --> 00:14:24.000 So then we'd specify our TCP port number in that case. 00:14:24.000 --> 00:14:29.000 And also this option here, I added this one in recently, interface table. 00:14:29.000 --> 00:14:31.000 What is that all about? 00:14:31.000 --> 00:14:32.000 All right. 00:14:32.000 --> 00:14:38.000 So this is about SNMP. 00:14:38.000 --> 00:14:47.000 SNMP. 00:14:47.000 --> 00:14:52.000 So with SNMP, we have interface indexes, index numbers. 00:14:52.000 --> 00:15:00.000 And if you're familiar with SNMP, every time we reboot a device, those index numbers can change, right? 00:15:00.000 --> 00:15:03.000 They absolutely can. 00:15:03.000 --> 00:15:09.000 So we have the ability with SNMP to type in a command SNMP if index persist. 00:15:09.000 --> 00:15:18.000 So that way there, any time we reboot the device, those SNMP interface index numbers do not change on our device, right? 00:15:18.000 --> 00:15:23.000 So what if we want to include the SNMP interface table? 00:15:23.000 --> 00:15:27.000 The SNMP interface tables contain those index numbers. 00:15:27.000 --> 00:15:41.000 What if I also want to send my interface index numbers to my NetFlow collector? 00:15:41.000 --> 00:15:48.000 Then you would use an option like this, option interface table under the export. 00:15:48.000 --> 00:15:55.000 So that is kind of misleading because you would think that this is something you'd want to collect under the flow record. 00:15:55.000 --> 00:15:57.000 You think it would be something you would collect under the flow record. 00:15:57.000 --> 00:15:59.000 In this case, it technically is, right? 00:15:59.000 --> 00:16:07.000 It's like when I am capturing my flow, I also want to make sure I have the SNMP interface table index numbers to go along with it. 00:16:07.000 --> 00:16:09.000 But you don't put that part of the flow record. 00:16:09.000 --> 00:16:13.000 You actually put that part of the flow exporter instead. 00:16:13.000 --> 00:16:21.000 So this command causes the periodic sending of the SNMP options table for our interfaces, 00:16:21.000 --> 00:16:30.000 which allows our collector now, our NetFlow collector, to map the interface SNMP indexes that it has. 00:16:30.000 --> 00:16:36.000 So now the flow records are going to have the interface index numbers with them as well. 00:16:36.000 --> 00:16:40.000 So again, you'd think it would be under flow record, but no, it's under here, our exporter instead. 00:16:40.000 --> 00:16:50.000 Another thing I want to point out to you, though, is that every single flow exporter you create can only have one destination specified. 00:16:51.000 --> 00:16:52.000 What does that mean? 00:16:52.000 --> 00:16:59.000 It means that if you had two NetFlow collectors, you would have to have two flow export configurations. 00:16:59.000 --> 00:17:02.000 What if you had IPv4 and IPv6? 00:17:02.000 --> 00:17:08.000 Well, again, you can only have one destination, and the one destination in your configuration can either be IPv4 or IPv6. 00:17:08.000 --> 00:17:13.000 So let's say you had a NetFlow collector that had an IPv4 address and an IPv6 address. 00:17:13.000 --> 00:17:18.000 Then you'd have to do a flow exporter for IPv4, and you'd have to do a flow exporter for IPv6. 00:17:18.000 --> 00:17:23.000 So you'd have two flow exporter configurations. 00:17:23.000 --> 00:17:31.000 So if you had one server, IPv4 and IPv6, and you wanted to send both IPv4 and IPv6 to it, you'd have to have two different flow exporter configurations, 00:17:31.000 --> 00:17:34.000 one for IPv4, one for IPv6. 00:17:34.000 --> 00:17:39.000 So if you had two servers, right, one primary and one secondary, like a backup server and a primary server, 00:17:39.000 --> 00:17:48.000 well, then you would have to actually have, if you were using IPv4 and IPv6 on both, four flow exporters. 00:17:48.000 --> 00:17:52.000 For the primary server, one flow exporter config for IPv4, one for IPv6. 00:17:52.000 --> 00:17:57.000 And then for the backup, one for IPv4, one for IPv6, so four flow exporters. 00:17:57.000 --> 00:18:02.000 Keep that in mind. 00:18:02.000 --> 00:18:04.000 So now let's talk about our flow monitor. 00:18:04.000 --> 00:18:07.000 So remember, I said the flow monitor binds things together. 00:18:07.000 --> 00:18:12.000 So here's an example of a flow monitor we create called Encore Flow Monitor. 00:18:12.000 --> 00:18:14.000 And then I put my exporter in it. 00:18:14.000 --> 00:18:16.000 I put my record in it. 00:18:16.000 --> 00:18:20.000 And this now can be attached to an interface. 00:18:20.000 --> 00:18:26.000 So once I attach it to the interface, then we're going to collect whatever the flow record is telling us to collect, 00:18:26.000 --> 00:18:31.000 and defining our flow based on whatever the flow record has defined as the flow. 00:18:31.000 --> 00:18:37.000 And then we're going to export it based on the exporter that's been attached. 00:18:37.000 --> 00:18:44.000 And you can have multiple exporters attached to a flow record for those IPv4, IPv6 scenarios. 00:18:44.000 --> 00:18:45.000 All right. 00:18:45.000 --> 00:18:49.000 In this case here, interface gig00, IP flow monitor. 00:18:49.000 --> 00:18:53.000 You type in the flow monitor to attach it to the interface, and then you say input. 00:18:53.000 --> 00:18:55.000 And if you want to do output, then you do output. 00:18:55.000 --> 00:18:58.000 So input for ingress traffic, output for egress traffic. 00:18:58.000 --> 00:19:02.000 You want both, input them both. 00:19:02.000 --> 00:19:10.000 So now the flow monitor is running on interface gig00 right here in both directions. 00:19:10.000 --> 00:19:16.000 So the flow record says that we are going to be defining a flow based on these values here. 00:19:16.000 --> 00:19:21.000 And we are going to be collecting all four of these values. 00:19:21.000 --> 00:19:22.000 Show flow record. 00:19:22.000 --> 00:19:27.000 Show flow exporter has all the parameters needed to export to the server. 00:19:27.000 --> 00:19:32.000 So in this case, use version 9 of NetFlow for formatting. 00:19:32.000 --> 00:19:37.000 And then you get your destination IP address, your source IP address, your source interface. 00:19:37.000 --> 00:19:41.000 You've got your transport protocol, your destination port number, your source port number, 00:19:41.000 --> 00:19:44.000 and so on and so forth for communication purposes. 00:19:44.000 --> 00:19:47.000 And the time to live is set to 255. 00:19:47.000 --> 00:19:50.000 Then we have our flow interface commands. 00:19:50.000 --> 00:19:56.000 Show flow interface shows us that interface gig00 has Encore flow monitor attached to it inbound 00:19:56.000 --> 00:20:00.000 and Encore flow monitor attached to it outbound. 00:20:00.000 --> 00:20:02.000 And if you type in show flow monitor, 00:20:02.000 --> 00:20:11.000 you're going to be able to see the parameters that are specified in a general sense for your actual device. 00:20:11.000 --> 00:20:16.000 So, for example, show flow monitor, we have this flow monitor created. 00:20:16.000 --> 00:20:19.000 And if we had additional flow monitors, they'd show up here as well. 00:20:19.000 --> 00:20:22.000 You can see which flow records attach, which flow exporters attach. 00:20:22.000 --> 00:20:25.000 You can see the caching type. 00:20:25.000 --> 00:20:29.000 So how are we caching information locally on the device before we send it to the exporter? 00:20:29.000 --> 00:20:36.000 And then what are the timers we have to determine when we export and how often we do our exporting? 00:20:36.000 --> 00:20:41.000 So that is our flow monitor verification. 00:20:41.000 --> 00:20:44.000 But if you want to check the actual statistics, 00:20:44.000 --> 00:20:51.000 then what you're going to do is you are going to look at the output of show flow monitor, 00:20:51.000 --> 00:20:57.000 specify the name of the flow monitor, and you type in cache. 00:20:57.000 --> 00:20:59.000 And then you're going to get more detail here. 00:20:59.000 --> 00:21:04.000 So the first thing I want to point out to you is that you can see the captured traffic down here. 00:21:04.000 --> 00:21:09.000 So we've captured all four of those parameters, as we said. 00:21:09.000 --> 00:21:16.000 We've captured all four of those parameters, but it's just these values here that define our flows. 00:21:16.000 --> 00:21:19.000 So those are our different flows we have. 00:21:19.000 --> 00:21:29.000 So four different flows so far, based on this little tiny example that I have. 00:21:29.000 --> 00:21:35.000 Now, I want you to pay attention to this value and this value here. 00:21:35.000 --> 00:21:37.000 Active timeout and inactive timeout. 00:21:37.000 --> 00:21:43.000 It's the same values you see here, active timeout and inactive timeout. 00:21:43.000 --> 00:21:46.000 So what are we dealing with here? 00:21:46.000 --> 00:21:54.000 These are going to determine how we export. 00:21:54.000 --> 00:21:59.000 You see, what we need to realize is that flows are temporary on our devices. 00:21:59.000 --> 00:22:07.000 So as we capture those flows, we store them very, very, very temporarily, like very temporarily. 00:22:07.000 --> 00:22:11.000 And if they are not exported to the NetFlow collector in a certain amount of time, 00:22:11.000 --> 00:22:13.000 the flows will be deleted from our cache. 00:22:13.000 --> 00:22:21.000 So this information here is only going to be here for a very, very, very, very short period of time. 00:22:21.000 --> 00:22:32.000 So NetFlow is valuable on its own, but it's even more valuable when you have a NetFlow collector in your environment 00:22:32.000 --> 00:22:35.000 to gather and store all this information. 00:22:35.000 --> 00:22:42.000 We don't want to rely on our device to be the device that's storing the information, like our router. 00:22:42.000 --> 00:22:47.000 So how does our device know when it should be exported? 00:22:47.000 --> 00:22:51.000 Well, it's going to export when a flow expires. 00:22:51.000 --> 00:22:54.000 And it's going to be exported under the following scenarios. 00:22:54.000 --> 00:22:57.000 And this is where the timer comes into play. 00:22:57.000 --> 00:23:06.000 When the flow has been idle or inactive. 00:23:06.000 --> 00:23:11.000 By default, that's 15 seconds. 00:23:11.000 --> 00:23:24.000 Any information pertaining to that flow that has been idle or inactive for 15 seconds can be deleted from the cache 00:23:24.000 --> 00:23:27.000 and exported to the NetFlow collector. 00:23:27.000 --> 00:23:35.000 So that means if your device is talking from the PC, let's say the PC, all the way to wherever it is, 00:23:35.000 --> 00:23:42.000 if it stops talking for like 15 seconds, then that flow that is associated with that can now be exported and deleted. 00:23:42.000 --> 00:23:44.000 15 seconds. 00:23:44.000 --> 00:23:46.000 That's all that it will be on the device for. 00:23:46.000 --> 00:23:51.000 So if you want it to stay longer on the device, then you can obviously increase the timers if you want to. 00:23:51.000 --> 00:23:58.000 But don't forget, you increase the timers, you're collecting more information and storing more information longer. 00:23:58.000 --> 00:24:02.000 So you're not necessarily collecting more information, you're just storing that information longer. 00:24:02.000 --> 00:24:04.000 The longer you store information, the more space is being taken up. 00:24:04.000 --> 00:24:12.000 The more space that's being taken up could cause other problems because you might run out of space on your device to hang on to this information. 00:24:12.000 --> 00:24:22.000 So that's why it's better to have a NetFlow collector or it's advisable to have a NetFlow collector so you can get that information off the device and have it long term storage on the collector. 00:24:22.000 --> 00:24:37.000 So if the conversation, that flow ceases to be occurring for 15 seconds for whatever reason, then erase the information and send it to the NetFlow collector. 00:24:37.000 --> 00:24:40.000 And if you're asking, well, what happens if the devices start talking again? 00:24:40.000 --> 00:24:46.000 Well, then fine, we'll just keep, we'll collect the information, keep collecting it from where we left off. 00:24:46.000 --> 00:24:48.000 We've already exported what we need to. 00:24:48.000 --> 00:24:49.000 That's okay. 00:24:49.000 --> 00:24:50.000 We freed up space. 00:24:50.000 --> 00:24:57.000 And it has devices start talking again after 15 seconds, could be 17 seconds later, let's say, as an example. 00:24:57.000 --> 00:24:59.000 Then fine, we'll just collect that information. 00:24:59.000 --> 00:25:02.000 And then when it's time to expire that, we'll expire it and send it off. 00:25:02.000 --> 00:25:07.000 Okay, so the other timer here is your active timeout. 00:25:07.000 --> 00:25:11.000 So that is based on our max age. 00:25:11.000 --> 00:25:17.000 That's really what it is, a max age. 00:25:17.000 --> 00:25:21.000 So when the flow's max age has been reached, that's 30 minutes. 00:25:21.000 --> 00:25:23.000 1,800 seconds is 30 minutes, folks. 00:25:23.000 --> 00:25:25.000 30 minutes. 00:25:25.000 --> 00:25:28.000 That's our active timer. 00:25:28.000 --> 00:25:32.000 The flow can be removed from the cache and exported. 00:25:32.000 --> 00:25:40.000 Meaning that if we're just talking, talking, talking, talking, talking, talking, talking, talking, collecting, collecting, collecting, collecting, collecting, collecting, collecting, right? 00:25:40.000 --> 00:25:44.000 And there's no 15 second break in there for inactivity. 00:25:45.000 --> 00:25:49.000 We're just going to keep collecting, collecting, collecting for up to, what, 30 minutes. 00:25:49.000 --> 00:25:52.000 Once 30 minutes hits, it's like, whew, that's a lot. 00:25:52.000 --> 00:26:03.000 And if they're still talking, we're going to take what we've collected over that 30 minutes, send it to the NetFlow collector, delete it out of the cache to free up space. 00:26:03.000 --> 00:26:08.000 And keep collecting, collecting, collecting, collecting, and so on and so forth. 00:26:09.000 --> 00:26:14.000 And remember, this is on a flow-by-flow basis this is being kept track of. 00:26:16.000 --> 00:26:21.000 So you're going to have flows expiring at different times, inactive at different times, and then when that happens, boom, get rid of it, delete it. 00:26:21.000 --> 00:26:22.000 Boom, get rid of it, delete it. 00:26:22.000 --> 00:26:24.000 Boom, get rid of it, delete it. 00:26:24.000 --> 00:26:26.000 Send it to the NetFlow collector. 00:26:26.000 --> 00:26:30.000 Okay, if your cache gets full, what do we fill up the cache? 00:26:30.000 --> 00:26:45.000 Then there are built-in heuristics, they're called, that are applied to age out the older flows immediately, export them to the NetFlow collector to free up space so that way there we can continue collecting. 00:26:45.000 --> 00:26:54.000 So essentially what we're doing is we're going to age out some of those flows early on and just ship it off and delete what we've shipped off. 00:26:54.000 --> 00:26:56.000 So, freeing up space. 00:26:57.000 --> 00:27:00.000 Lastly, TCP connections. 00:27:00.000 --> 00:27:11.000 So, TCP connections, when closed, could have a FIN byte, or not could have, would have a FIN byte set. 00:27:11.000 --> 00:27:18.000 And so, our NetFlow collector has been, or not our NetFlow collector, but our device has been designed to keep an eye on TCP connections. 00:27:19.000 --> 00:27:28.000 And if all of a sudden a TCP FIN byte is seen, then it can immediately take that information that's part of that flow and export it and delete it because the conversation is over. 00:27:28.000 --> 00:27:43.000 Or if a TCP conversation has had to be reset because a TCP reset byte has been seen in the message, then it can immediately take all that information that's part of that flow and send it off to the NetFlow collector. 00:27:44.000 --> 00:27:49.000 Because that information is no longer needed as part of the flow because it's done. 00:27:49.000 --> 00:27:50.000 Those flows are done. 00:27:50.000 --> 00:27:52.000 So it can do those as well. 00:27:52.000 --> 00:27:58.000 So, active timeout, very important, I want you to know that. 00:27:58.000 --> 00:28:00.000 Inactive timeout, very important, I want you to know that. 00:28:00.000 --> 00:28:05.000 So again, when the flow has been idle or inactive, that's 15 seconds, it can be removed from the cache and exported. 00:28:05.000 --> 00:28:12.000 When a flow's max age has been reached, 30 minutes, meaning it's talky-talky-talk, hasn't stopped talking, that's our active timer. 00:28:12.000 --> 00:28:21.000 The flow at that 30-minute mark can therefore take all that information from that flow, ship it off to the NetFlow collector, and delete it out of our cache. 00:28:21.000 --> 00:28:28.000 So, folks, that is flexible NetFlow in a nutshell. 00:28:28.000 --> 00:28:34.000 But there's one more thing I want to refer to or bring to your attention for NetFlow, and that is that flow sampler. 00:28:34.000 --> 00:28:37.000 So that flow sampler is all about what again? 00:28:38.000 --> 00:28:42.000 Well, it's about reducing CPU utilization, reduced memory utilization. 00:28:42.000 --> 00:28:57.000 Because think about this, if we are analyzing every single packet, and there's millions and millions and millions and millions of packets per second that are coming in and out of that interface, that could absolutely affect that networking device. 00:28:57.000 --> 00:29:05.000 So the flow sampler allows us to reduce CPU and memory utilization because the number of packets that are being analyzed is being reduced. 00:29:05.000 --> 00:29:09.000 So in this case, I'm creating a sampler, my Encore flow sampler. 00:29:09.000 --> 00:29:12.000 And right here, I'm just saying random one out of 50. 00:29:12.000 --> 00:29:21.000 So every 50 packets, I want you to analyze one of them, one out of every 50. 00:29:21.000 --> 00:29:26.000 And as a result of that, we are going to reduce CPU and memory utilization. 00:29:26.000 --> 00:29:28.000 And then you attach it to what? 00:29:28.000 --> 00:29:32.000 You attach it to what? 00:29:32.000 --> 00:29:34.000 The interface config, that's right. 00:29:34.000 --> 00:29:36.000 You don't attach to the flow monitor. 00:29:36.000 --> 00:29:37.000 No, no, no, no. 00:29:37.000 --> 00:29:38.000 Watch this. 00:29:38.000 --> 00:29:41.000 IP flow monitor, Encore flow monitor. 00:29:41.000 --> 00:29:43.000 Then you type in sampler. 00:29:43.000 --> 00:29:45.000 Encore flow sampler input. 00:29:45.000 --> 00:29:55.000 So now that is telling the interface only capture one out of 50 packets for this flow monitor based on the flow monitor information. 00:29:55.000 --> 00:29:57.000 So you don't attach to the flow monitor. 00:29:57.000 --> 00:30:02.000 You attach it to the interface IP flow monitor command. 00:30:02.000 --> 00:30:08.000 That's where it goes. 00:30:08.000 --> 00:30:13.000 So definitely familiarize yourself with NetFlow or flexible NetFlow for the certification exam. 00:30:13.000 --> 00:30:15.000 So know the flow record config. 00:30:15.000 --> 00:30:17.000 Know the flow exporter config. 00:30:17.000 --> 00:30:18.000 Know the flow monitor config. 00:30:18.000 --> 00:30:20.000 Know how to apply it to the interface. 00:30:20.000 --> 00:30:21.000 Know your sampler config. 00:30:21.000 --> 00:30:24.000 And familiarize yourself with those two timers. 00:30:24.000 --> 00:30:29.000 Those are the things you want to take away from this flexible NetFlow discussion.