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