WEBVTT

1
00:00.000 --> 00:05.520
Let's begin with a scenario where our manager or supervisor walks in and says,

2
00:05.520 --> 00:10.200
"You know what? Can you tell me what percentage of our network traffic that is

3
00:10.200 --> 00:10.720
coming from,

4
00:10.720 --> 00:15.740
for example, the 10 network down here? What percentage of that network traffic

5
00:15.740 --> 00:16.640
is going out to the

6
00:16.640 --> 00:21.270
internet and what are the quantities? Are we using HTTPS mostly, which is very

7
00:21.270 --> 00:21.680
likely,

8
00:21.680 --> 00:26.960
how much DNS traffic? And also, do we have situations where clients over here

9
00:26.960 --> 00:27.760
that are making requests

10
00:27.760 --> 00:31.390
out to the network using weird protocols? Like, maybe protocols that are being
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:27.760 --> 00:31.390
out to the network using weird protocols? Like, maybe protocols that are being

11
00:31.390 --> 00:32.480
used for tunneling

12
00:32.480 --> 00:36.180
or other traffic patterns that may indicate some kind of a problem or security

13
00:36.180 --> 00:37.200
risk on our network.

14
00:37.200 --> 00:42.530
Now, by default, it would be almost impossible to get that right because we

15
00:42.530 --> 00:43.520
wouldn't really know

16
00:43.520 --> 00:47.280
how much traffic is going from, you know, for example, this computer or this

17
00:47.280 --> 00:48.800
computer out to the internet

18
00:48.800 --> 00:52.500
or between each other. And so we're going to need some type of a tool that can

19
00:52.500 --> 00:53.680
give us a bird's-eye

20
00:53.680 --> 00:57.990
view of what traffic is being used. For example, what protocols are being used,

21
00:57.990 --> 00:58.640
what the source

22
00:58.640 --> 01:02.330
and destination addresses are, and the quantity of traffic. And fortunately,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

22
00:58.640 --> 01:02.330
and destination addresses are, and the quantity of traffic. And fortunately,

23
01:02.330 --> 01:03.200
there is a tool that

24
01:03.200 --> 01:07.740
lets us do that. And that is a tool called NetFlow. So NetFlow has been

25
01:07.740 --> 01:09.040
evolving over the years.

26
01:09.040 --> 01:13.750
So we start off with the basic concepts of NetFlow at the beginning. In the

27
01:13.750 --> 01:14.240
early days,

28
01:14.240 --> 01:17.280
with NetFlow, what we would do is we'd tell a router like this one, you know,

29
01:17.280 --> 01:18.240
on this interface

30
01:18.240 --> 01:23.680
and this interface and this interface and this interface, please keep track of

31
01:23.680 --> 01:24.400
the traffic that's

32
01:24.400 --> 01:28.990
going through it. Not making full copies of the packets, but just like making a

33
01:28.990 --> 01:29.920
documentation

34
01:29.920 --> 01:33.440
of what type of traffic you see, for example, the source and destination IP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

34
01:29.920 --> 01:33.440
of what type of traffic you see, for example, the source and destination IP

35
01:33.440 --> 01:34.160
addresses,

36
01:34.160 --> 01:38.430
the layer for protocols, and so forth. And with NetFlow, you can enable that

37
01:38.430 --> 01:39.040
router to take a

38
01:39.040 --> 01:42.360
look at traffic either going into those interfaces or out of those interfaces

39
01:42.360 --> 01:43.440
that's called Ingress,

40
01:43.440 --> 01:48.390
going in or egress, going out, or both. And then what the router will do, it'll

41
01:48.390 --> 01:49.280
create a cache

42
01:49.280 --> 01:53.740
of that information. Now a cache is just temporary in memory. So periodically,

43
01:53.740 --> 01:54.320
that cache is going

44
01:54.320 --> 01:58.850
to time out. Let's say, for example, that the cache is five minutes. So the

45
01:58.850 --> 01:59.680
router collects all

46
01:59.680 --> 02:03.520
the information regarding what's going through it for five minutes regarding
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

46
01:59.680 --> 02:03.520
the information regarding what's going through it for five minutes regarding

47
02:03.520 --> 02:04.480
the traffic flows,

48
02:04.480 --> 02:08.110
source, the station IP address, layer for protocols, and so forth. And then

49
02:08.110 --> 02:09.360
when the cache expires,

50
02:09.360 --> 02:14.160
it can go ahead and send that to a server, meaning send that cached information

51
02:14.160 --> 02:14.800
to the server.

52
02:14.800 --> 02:18.560
So let's imagine the server is right here. So this is our NetFlow. And the

53
02:18.560 --> 02:19.120
purpose of this

54
02:19.120 --> 02:23.430
NetFlow server is to go ahead and collect the cached information that the

55
02:23.430 --> 02:24.720
router or in the case

56
02:24.720 --> 02:28.540
of multiple routers that are sending to it regarding NetFlow. So that server in

57
02:28.540 --> 02:29.600
the world of NetFlow

58
02:29.600 --> 02:33.360
is called a collector, because collecting the information being sent. So R2 is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

58
02:29.600 --> 02:33.360
is called a collector, because collecting the information being sent. So R2 is

59
02:33.360 --> 02:34.160
keeping track of

60
02:34.160 --> 02:37.160
the traffic flows that are going through, sends it a periodically over the

61
02:37.160 --> 02:38.000
collector, and then what

62
02:38.000 --> 02:42.050
we do is you and I log into the collector, and then we can create graphs and

63
02:42.050 --> 02:43.120
charts and make pretty

64
02:43.120 --> 02:47.920
pictures and have information regarding what traffic flows this router has seen

65
02:47.920 --> 02:48.640
going in and

66
02:48.640 --> 02:52.600
or out of its interfaces. So those are the three main parts of traditional Net

67
02:52.600 --> 02:53.680
Flow. We enable it on

68
02:53.680 --> 02:58.080
a router, we point to a collector, then you and I log into that collector, and

69
02:58.080 --> 02:58.800
we extract that

70
02:58.800 --> 03:01.910
information and make pretty graphs. So for example, maybe the collector is over
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

70
02:58.800 --> 03:01.910
information and make pretty graphs. So for example, maybe the collector is over

71
03:01.910 --> 03:03.120
here at the IP address

72
03:03.120 --> 03:08.720
of 5.5.5.5.5. If that's its IP address, then as far as the protocol that it's

73
03:08.720 --> 03:09.280
listening on,

74
03:09.280 --> 03:14.850
perhaps it's UDP port number 6783. And on most collectors, you can go ahead and

75
03:14.850 --> 03:15.920
specify the port

76
03:15.920 --> 03:19.480
you want to listen on. And you should be telling the router to forward over to

77
03:19.480 --> 03:20.720
that destination port.

78
03:20.720 --> 03:24.840
And although NetFlow in its early days was great, and it provided a lot of

79
03:24.840 --> 03:26.000
useful information,

80
03:26.000 --> 03:30.580
it wasn't very quote unquote flexible, because what if we need to take, for
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

80
03:26.000 --> 03:30.580
it wasn't very quote unquote flexible, because what if we need to take, for

81
03:30.580 --> 03:31.920
example, some flows

82
03:31.920 --> 03:35.510
that we wanted to track through the network and send them to one server, and we

83
03:35.510 --> 03:36.400
had other flows

84
03:36.400 --> 03:39.890
on different interfaces that we wanted to send to get a different server. So it

85
03:39.890 --> 03:40.960
wasn't very modular,

86
03:40.960 --> 03:44.270
we couldn't break it down into smaller components. And that's one of the

87
03:44.270 --> 03:46.320
benefits of flexible NetFlow.

88
03:46.320 --> 03:50.700
Let me break it down how flexible NetFlow gives the ability to match on

89
03:50.700 --> 03:52.000
virtually anything we want

90
03:52.000 --> 03:56.000
to regarding IP traffic, and also collect additional information regarding

91
03:56.000 --> 03:56.960
those flows that we want

92
03:56.960 --> 04:00.540
to have recorded. And then we can choose which parts of that information we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
03:56.960 --> 04:00.540
to have recorded. And then we can choose which parts of that information we

93
04:00.540 --> 04:01.600
want to send to which

94
04:01.600 --> 04:06.110
servers. So let me clean this up. Let's chat about how flexible NetFlow allows

95
04:06.110 --> 04:07.040
us to do exactly

96
04:07.040 --> 04:10.530
that. So the first part of flexible NetFlow that we want to chat about is the

97
04:10.530 --> 04:11.280
ability to

98
04:11.280 --> 04:16.520
identify what we want to specify is a flow of data. So we can control what is a

99
04:16.520 --> 04:17.600
flow of data.

100
04:17.600 --> 04:22.490
For example, we can match on source IP address and destination IP address. And

101
04:22.490 --> 04:22.960
let's say also,

102
04:22.960 --> 04:29.510
for example, the layer for protocol is involved, whether it's TCP or UDP or GRE

103
04:29.510 --> 04:31.200
or ICMP or something
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

103
04:29.510 --> 04:31.200
or ICMP or something

104
04:31.200 --> 04:35.720
else. And so any traffic that matches the same parameters, for example, this PC

105
04:35.720 --> 04:36.240
going out to a

106
04:36.240 --> 04:39.620
server where the source IP address and the SH IP address and the layer for

107
04:39.620 --> 04:40.880
protocol is the same,

108
04:40.880 --> 04:44.080
that would be considered one flow. So if this is the only criteria that we're

109
04:44.080 --> 04:45.040
looking for regarding a

110
04:45.040 --> 04:49.120
flow of data, even if this computer sends hundreds or thousands of packets from

111
04:49.120 --> 04:50.160
this client to the

112
04:50.160 --> 04:53.760
server, that would be considered a flow. Now, in addition to identifying that

113
04:53.760 --> 04:54.880
that flow is happening,

114
04:54.880 --> 04:58.830
we can also collect information regarding that flow. So for example, we could

115
04:58.830 --> 04:59.440
say we also want

116
04:59.440 --> 05:03.810
details regarding number of packets, or we could say we want to include timest
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

116
04:59.440 --> 05:03.810
details regarding number of packets, or we could say we want to include timest

117
05:03.810 --> 05:04.640
amps that could then

118
05:04.640 --> 05:08.570
be included without flow information. So up here, this would be what we're

119
05:08.570 --> 05:09.760
matching on. And this

120
05:09.760 --> 05:12.620
additional information would be information that we're collecting. In addition

121
05:12.620 --> 05:12.960
to what we're

122
05:12.960 --> 05:17.200
matching on information we're collecting about those flows. So I'll put here

123
05:17.200 --> 05:18.400
also collect. And the

124
05:18.400 --> 05:23.120
cool thing about flexible netflow is that we can create this object here that

125
05:23.120 --> 05:24.320
specifies what

126
05:24.320 --> 05:27.880
constitutes a flow of data and also what information we want to collect. And in

127
05:27.880 --> 05:28.800
flexible netflow,

128
05:28.800 --> 05:31.600
what they call this regarding what we're going to match on what information we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

128
05:28.800 --> 05:31.600
what they call this regarding what we're going to match on what information we

129
05:31.600 --> 05:32.320
're collecting in

130
05:32.320 --> 05:35.910
addition to that, they call that a record. And there are some predefined

131
05:35.910 --> 05:36.880
records that we can use

132
05:36.880 --> 05:41.830
with flexible netflow, or we can just create our own. So I'm going to put the

133
05:41.830 --> 05:42.800
record in this blue

134
05:42.800 --> 05:46.360
box here. So I'm going to put this information here in blue. And that is a

135
05:46.360 --> 05:47.440
record, a flexible

136
05:47.440 --> 05:51.300
netflow record. Again, just identifying what we want to match on and what

137
05:51.300 --> 05:51.920
information we want

138
05:51.920 --> 05:57.030
to collect. Now, a next part of the flexible netflow infrastructure is a module

139
05:57.030 --> 05:58.080
that allow us to go

140
05:58.080 --> 06:03.260
ahead and send that data that's being collected and cached by the router over
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

140
05:58.080 --> 06:03.260
ahead and send that data that's being collected and cached by the router over

141
06:03.260 --> 06:04.800
to a server, a net

142
06:04.800 --> 06:08.190
flow collector. So perhaps we're using netflow right here flexible netflow. And

143
06:08.190 --> 06:08.960
we want to send,

144
06:08.960 --> 06:14.340
for example, some of the information we collect over to, let's say, server one,

145
06:14.340 --> 06:14.640
which is one of

146
06:14.640 --> 06:18.040
our netflow collectors. And for a different flow of data based on a different

147
06:18.040 --> 06:18.560
record,

148
06:18.560 --> 06:21.790
we want to send that data over to server two, because we can have a lot of

149
06:21.790 --> 06:22.960
different groups and

150
06:22.960 --> 06:26.420
organizations in our company that want different information for different

151
06:26.420 --> 06:27.680
reasons. For example,

152
06:27.680 --> 06:32.330
maybe we want one for network monitoring for security purposes, or we want one
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

152
06:27.680 --> 06:32.330
maybe we want one for network monitoring for security purposes, or we want one

153
06:32.330 --> 06:33.200
network monitor

154
06:33.200 --> 06:36.680
for network planning, or maybe we want to do user profiling based on

155
06:36.680 --> 06:37.600
identifying, you know,

156
06:37.600 --> 06:41.290
which users are sending which types of traffic to which destinations, or

157
06:41.290 --> 06:42.240
perhaps we're doing

158
06:42.240 --> 06:45.520
billing and accounting, we're doing chargebacks to our departments for their

159
06:45.520 --> 06:46.480
traffic usage.

160
06:46.480 --> 06:49.570
And with flexible netflow, we can carve it out so we can get the information

161
06:49.570 --> 06:50.720
that we need for

162
06:50.720 --> 06:54.460
whatever purpose we need it. So the modular part of this is we can go ahead and

163
06:54.460 --> 06:56.240
specify where to

164
06:56.240 --> 06:59.890
send the data. So the router would cache that information for a period of time.

165
06:59.890 --> 07:00.320
And then once
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

165
06:59.890 --> 07:00.320
And then once

166
07:00.320 --> 07:04.260
the cache expires, it would export that data to the collector. So we can

167
07:04.260 --> 07:06.240
specify where to send

168
07:06.240 --> 07:09.840
the cache data. And I'll call it cache flow information. And as part of that,

169
07:09.840 --> 07:11.200
we'd include the address

170
07:11.200 --> 07:16.500
information, IPA for where that server is, and also the port and protocol that

171
07:16.500 --> 07:17.680
we're using to go

172
07:17.680 --> 07:20.750
ahead and send it over. Because that way, if we have a server, for example,

173
07:20.750 --> 07:22.080
expecting to listen on

174
07:22.080 --> 07:27.430
port 673 or port 992, whatever it is, we can be very specific. And if this

175
07:27.430 --> 07:28.480
server here is listening

176
07:28.480 --> 07:34.610
on port 9996, and over here we're listening on port 6783, we can create
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

176
07:28.480 --> 07:34.610
on port 9996, and over here we're listening on port 6783, we can create

177
07:34.610 --> 07:36.080
separate modules that

178
07:36.080 --> 07:39.970
identify each of these servers, and then use the appropriate protocol and port

179
07:39.970 --> 07:40.400
when we communicate

180
07:40.400 --> 07:44.320
with those servers. Now this part here that specifies where the servers are,

181
07:44.320 --> 07:45.440
the collectors are,

182
07:45.440 --> 07:49.200
and what are the IP addresses and ports to reach them, those are created in an

183
07:49.200 --> 07:50.320
object called an

184
07:50.320 --> 07:55.080
exporter. So I'll put that right here in the same color pink. So we can modular

185
07:55.080 --> 07:56.320
ly create our own

186
07:56.320 --> 07:59.350
record, so identify what we want to collect. And we're also going to create our

187
07:59.350 --> 07:59.840
own custom

188
07:59.840 --> 08:04.040
exporters to specify exactly which servers to send that information to, and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

188
07:59.840 --> 08:04.040
exporters to specify exactly which servers to send that information to, and

189
08:04.040 --> 08:04.800
which ports and

190
08:04.800 --> 08:08.150
protocols to use to reach them. And there's one last piece here that's going to

191
08:08.150 --> 08:09.280
tie us all together,

192
08:09.280 --> 08:14.320
and that is yet one more object here that's going to identify for a router

193
08:14.320 --> 08:15.760
where we want to collect

194
08:15.760 --> 08:19.930
that information. For example, do you want to collect it on gig 1 0 coming in

195
08:19.930 --> 08:21.200
bound or traffic

196
08:21.200 --> 08:24.970
that's going egress or outbound on gig 1 0? And the object that allows us to go

197
08:24.970 --> 08:25.840
ahead and do that

198
08:25.840 --> 08:30.530
here on a Cisco router interface is called inflexible net flow, that's called a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

198
08:25.840 --> 08:30.530
here on a Cisco router interface is called inflexible net flow, that's called a

199
08:30.530 --> 08:31.840
monitor. So think of a

200
08:31.840 --> 08:35.740
monitor as being an object we're going to apply to an interface that specifies

201
08:35.740 --> 08:36.640
we don't where we

202
08:36.640 --> 08:41.310
want to collect that data. For example, gig 1 0 ingress coming in or outbound

203
08:41.310 --> 08:42.160
going out. So I'll

204
08:42.160 --> 08:45.250
put here in black that not only the monitor is going to specify where we're

205
08:45.250 --> 08:45.920
going to collect

206
08:45.920 --> 08:49.050
that data from, for example, which interface and which direction, but it's also

207
08:49.050 --> 08:50.240
going to include

208
08:50.240 --> 08:53.480
which record that we should be paying attention to, for example, what the

209
08:53.480 --> 08:54.560
matches should be and

210
08:54.560 --> 08:57.630
what information to collect. So I'll go ahead down here. I'll say it includes

211
08:57.630 --> 08:58.400
the record that

212
08:58.400 --> 09:02.390
identifies what to collect. The monitor is also going to include the exporter,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

212
08:58.400 --> 09:02.390
identifies what to collect. The monitor is also going to include the exporter,

213
09:02.390 --> 09:03.120
which also tells

214
09:03.120 --> 09:07.580
it where to ship that data once the cache expires on the local router. So the

215
09:07.580 --> 09:08.640
monitor is also going

216
09:08.640 --> 09:13.070
to include the exporter. So I color coded them here just to remind you how they

217
09:13.070 --> 09:14.080
fit into the big

218
09:14.080 --> 09:18.440
picture with flexible net flow. Also, please be aware that as Cisco develops

219
09:18.440 --> 09:19.440
and works with new

220
09:19.440 --> 09:24.420
technologies, industry standards often catch up to that after a period of time.

221
09:24.420 --> 09:25.520
So now that Cisco

222
09:25.520 --> 09:31.120
has flexible net flow, industry standard has thing called IPFIX, which is an
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

222
09:25.520 --> 09:31.120
has flexible net flow, industry standard has thing called IPFIX, which is an

223
09:31.120 --> 09:32.320
acronym for

224
09:32.320 --> 09:35.970
Internet Protocol Flow Information Export. There's also something called Net

225
09:35.970 --> 09:37.040
Flow version 10,

226
09:37.040 --> 09:40.080
which takes a lot of the concepts behind Internet Protocol Flow Information

227
09:40.080 --> 09:41.760
Export and also integrates

228
09:41.760 --> 09:45.740
many of the features of flexible net flow from Cisco. So officially, when

229
09:45.740 --> 09:46.960
flexible net flow came

230
09:46.960 --> 09:51.610
out, it's called version nine. So when you see things like IPFIX and Net Flow

231
09:51.610 --> 09:52.960
10, think of them

232
09:52.960 --> 09:56.790
like similar implementations to flexible net flow, especially with Net Flow

233
09:56.790 --> 09:57.760
version 10,

234
09:57.760 --> 10:02.130
which is incorporating many of the features of flexible net flow from Cisco. So
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

234
09:57.760 --> 10:02.130
which is incorporating many of the features of flexible net flow from Cisco. So

235
10:02.130 --> 10:02.480
I just wanted

236
10:02.480 --> 10:05.810
to be aware that those other terms exist. And when you see them, just think

237
10:05.810 --> 10:06.960
that they fit under the

238
10:06.960 --> 10:09.760
umbrella of the flexible net flow family.

239
10:09.760 --> 10:19.760
[BLANK_AUDIO]