WEBVTT

1
00:00.000 --> 00:05.760
Well, when we build layer two domains using layer two switches, we have found

2
00:05.760 --> 00:09.600
that this creates too large of a domain and so we want to make sure we don't

3
00:09.600 --> 00:14.360
have a thousand hosts in a single broadcast domain for example and so we

4
00:14.360 --> 00:21.080
carve this up into different virtual networks. So we have VLAN 10 on top, we

5
00:21.080 --> 00:25.960
have VLAN 20 on bottom and as the drawing is currently drawn here, this

6
00:25.960 --> 00:30.240
link would be in one of those VLANs, VLAN 20 and so we might need another
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

6
00:25.960 --> 00:30.240
link would be in one of those VLANs, VLAN 20 and so we might need another

7
00:30.240 --> 00:35.440
connection here between VLAN 10 to spread that and we have two completely

8
00:35.440 --> 00:39.840
different virtual domains even though we have only two physical switches we've

9
00:39.840 --> 00:45.880
got technically two sort of virtual switches in each one of these domains.

10
00:45.880 --> 00:50.280
So we could argue we have four different sets of switches. Really what this

11
00:50.280 --> 00:56.560
amounts to is each one of these domains has its own cam table and so we have

12
00:56.560 --> 01:01.840
two different cam tables as we've talked about in this course and on each
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

12
00:56.560 --> 01:01.840
two different cam tables as we've talked about in this course and on each

13
01:01.840 --> 01:07.000
individual switch which is why we have effectively two different virtualized

14
01:07.000 --> 01:12.420
switches even though we have one physical switch. Now naturally the

15
01:12.420 --> 01:15.640
industry came together and said hey it'd be a great idea if we could come up

16
01:15.640 --> 01:20.260
with a concept like a trunk which would carry two different VLANs we wouldn't

17
01:20.260 --> 01:24.620
need this other link if we have two VLANs we needed two links, if we had 10 V

18
01:24.620 --> 01:24.880
LANs

19
01:24.880 --> 01:28.720
we would have needed 10 links. Well now we could put all of those VLANs on a

20
01:28.720 --> 01:33.560
single link and call it a trunk. So here's the question, how much of this can
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

20
01:28.720 --> 01:33.560
single link and call it a trunk. So here's the question, how much of this can

21
01:33.560 --> 01:33.680
we

22
01:33.680 --> 01:39.400
accomplish at a layer three level? This is all happening at layer two but when

23
01:39.400 --> 01:44.320
we move to layer three here we are talking about having two different

24
01:44.320 --> 01:48.760
routers communicating with one another and maybe we've got different

25
01:48.760 --> 01:53.260
connections happening here on the layer three interfaces we're usually talking

26
01:53.260 --> 01:57.460
about much fewer connections on a router versus a switch which might have 48

27
01:57.460 --> 02:03.500
ports, router might just have a handful of ports and so can we carve this up in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

27
01:57.460 --> 02:03.500
ports, router might just have a handful of ports and so can we carve this up in

28
02:03.500 --> 02:08.060
the same way? And the answer is yes we have this wonderful technology called

29
02:08.060 --> 02:14.380
virtual routing and forwarding which unfortunately is not quite as catchy as

30
02:14.380 --> 02:19.660
a virtual LAN. I think we'd maybe have come up with something that you could

31
02:19.660 --> 02:23.500
actually say rather than you know people pronounce this sometimes as a

32
02:23.500 --> 02:31.820
verb for a VRF but either way it's is what it is. The VRF is effectively the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

32
02:23.500 --> 02:31.820
verb for a VRF but either way it's is what it is. The VRF is effectively the

33
02:31.820 --> 02:38.700
same thing as a VLAN when it comes to layer three versus layer two. We're

34
02:38.700 --> 02:44.300
taking a physical device we have two different physical routers here and we're

35
02:44.300 --> 02:49.980
going to carve this up into virtual routers virtual routing instances and so

36
02:49.980 --> 02:56.710
what we can do here is say let's make... we'll carve it up like this. So just

37
02:56.710 --> 02:56.820
like

38
02:56.820 --> 03:04.180
above we're now we've got VRF 10 on the top half, VRF 20 on the bottom half and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

38
02:56.820 --> 03:04.180
above we're now we've got VRF 10 on the top half, VRF 20 on the bottom half and

39
03:04.180 --> 03:09.780
now this link here we see we've got a link in VRF 10 and we might want to have

40
03:09.780 --> 03:15.900
another link in here at VRF 20 and so two physical devices here is what we've

41
03:15.900 --> 03:21.300
got and yet we have four different logical devices. Now we talk about

42
03:21.300 --> 03:26.580
logical switches that amounted to having different cam tables. A virtual router

43
03:26.580 --> 03:31.900
is going to be very similar in that we are going to have our own set of tables
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

43
03:26.580 --> 03:31.900
is going to be very similar in that we are going to have our own set of tables

44
03:31.900 --> 03:37.060
here and when we think back to the conversation around SAS and our routing

45
03:37.060 --> 03:41.580
tables and everything we're going to actually have a set of tables from a

46
03:41.580 --> 03:46.140
layer three perspective that involves the rib which is effectively the routing

47
03:46.140 --> 03:50.380
table. We're also going to have the SEF tables so we are going to have the

48
03:50.380 --> 03:55.940
FIB, the forwarding information base as well as the adjacency table. So those

49
03:55.940 --> 04:02.050
three tables are going to exist in each one of these VRFs on a per device basis
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

49
03:55.940 --> 04:02.050
three tables are going to exist in each one of these VRFs on a per device basis

50
04:02.050 --> 04:02.060
.

51
04:02.060 --> 04:08.660
So yeah that truly means we have our own routing table for every VRF that we

52
04:08.660 --> 04:15.460
configure. Now Cisco devices are actually built for VRFs from the ground up

53
04:15.460 --> 04:16.140
sort

54
04:16.140 --> 04:22.020
of like how again when we think back to layer two world all of these ports the

55
04:22.020 --> 04:28.060
default for a layer two switch port is going to be placed into VLAN 1. There's

56
04:28.060 --> 04:33.380
no way to disable VLANs on a layer two switch at least as far as Cisco devices
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

56
04:28.060 --> 04:33.380
no way to disable VLANs on a layer two switch at least as far as Cisco devices

57
04:33.380 --> 04:37.340
are concerned. Every port is going to be in VLAN 1 when we first turn it on and

58
04:37.340 --> 04:41.460
security recommendations are usually such that we change that over to

59
04:41.460 --> 04:46.460
something other than VLAN 1. Well VRFs are going to be the same way in that we

60
04:46.460 --> 04:46.660
're

61
04:46.660 --> 04:53.380
going to be assigned the default VRF. The default VRF is going to include the

62
04:53.380 --> 05:02.940
global routing table for that VRF and when you time we run commands such as
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

62
04:53.380 --> 05:02.940
global routing table for that VRF and when you time we run commands such as

63
05:02.940 --> 05:11.100
ping commands or we enter into a router instance such as an EIGRP or OSPF

64
05:11.100 --> 05:16.660
instance by default they're going to belong to the default VRF. If I just say

65
05:16.660 --> 05:23.500
ping 10.0.0.1 it's going to reference the rib or the fib or the

66
05:23.500 --> 05:28.860
adjacency table maybe all of them and it's going to ping using the default VRF

67
05:28.860 --> 05:36.820
but I can also specify using these same commands different VRFs. So I could say
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

67
05:28.860 --> 05:36.820
but I can also specify using these same commands different VRFs. So I could say

68
05:36.820 --> 05:43.620
hey I want to ping 10.0.0.1 in a different VRF altogether. Now that's

69
05:43.620 --> 05:47.780
interesting because we also now see that we've got the ability to have

70
05:47.780 --> 05:48.140
different

71
05:48.140 --> 05:52.540
VRFs so if I configure two VRFs I'm still going to have the default so I'd

72
05:52.540 --> 05:57.420
have three at that point. So I have the default VRF and we can actually give

73
05:57.420 --> 06:00.700
names to our VRFs. They don't have to be numbers although we could name them
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

73
05:57.420 --> 06:00.700
names to our VRFs. They don't have to be numbers although we could name them

74
06:00.700 --> 06:06.020
numbers. So let's just call this VRF green we'll call them colors here and

75
06:06.020 --> 06:12.660
then we have a different VRF that we call blue. So remember each one of these

76
06:12.660 --> 06:18.100
VRFs is going to have its own routing table. So what happens if I want to place

77
06:18.100 --> 06:26.980
an interface into assign it 10.0.0.1/24 in the default VRF and then I get on to

78
06:26.980 --> 06:27.020
a

79
06:27.020 --> 06:34.860
different VRF interface and I want to configure it with the same /24 address.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

79
06:27.020 --> 06:34.860
different VRF interface and I want to configure it with the same /24 address.

80
06:34.860 --> 06:40.460
Well at this point we have a duplicate IP address and yeah it's also not a

81
06:40.460 --> 06:45.700
duplicate IP address because the default VRF is going to manage its own tables

82
06:45.700 --> 06:52.380
just as VRF green is going to manage its own tables and VRF blue will do the

83
06:52.380 --> 06:58.460
same thing. So I could actually put this IP address in every single one of my

84
06:58.460 --> 06:59.100
VRFs

85
06:59.100 --> 07:05.900
and that is going to be okay. Everybody is happy here because I only care about
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

85
06:59.100 --> 07:05.900
and that is going to be okay. Everybody is happy here because I only care about

86
07:05.900 --> 07:11.420
duplicate IP addresses existing within the same VRF. Now if I never

87
07:11.420 --> 07:17.180
configure these VRFs, never actually configure additional VRFs, I'm only

88
07:17.180 --> 07:21.410
operating in the default VRF whether I realize it or not and therefore I couldn

89
07:21.410 --> 07:21.500
't

90
07:21.500 --> 07:27.020
create duplicate IP addresses within the VRF. I couldn't put two you know the

91
07:27.020 --> 07:27.140
same

92
07:27.140 --> 07:31.820
IP address on two different interfaces but as soon as I start configuring many
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
07:27.140 --> 07:31.820
IP address on two different interfaces but as soon as I start configuring many

93
07:31.820 --> 07:39.340
VRFs well now that becomes an option. Furthermore when I'm configuring a VRF

94
07:39.340 --> 07:46.940
the VRF gets mapped to the interface and so when we look at a router or even

95
07:46.940 --> 07:51.340
this situation up here maybe we see lots of interfaces in there well this

96
07:51.340 --> 07:58.540
interface is going to belong to let's say VRF green here and then I configure

97
07:58.540 --> 08:04.380
this interface to be part of VRF blue and then maybe these interfaces over here
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
07:58.540 --> 08:04.380
this interface to be part of VRF blue and then maybe these interfaces over here

98
08:04.380 --> 08:10.780
also belong to green and blue. So I can only map a single VRF to a single layer

99
08:10.780 --> 08:14.780
three interface. Now that could be physical interfaces or sub interfaces or

100
08:14.780 --> 08:20.540
SVIs if it's a layer three switch and furthermore when a packet comes in on

101
08:20.540 --> 08:25.660
one of these interfaces it's only going to check the routing table that belongs

102
08:25.660 --> 08:31.260
to that VRF which also means that it has to go out an interface in that VRF.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

102
08:25.660 --> 08:31.260
to that VRF which also means that it has to go out an interface in that VRF.

103
08:31.260 --> 08:35.980
Remember we've basically logically carved this layer three device up into two

104
08:35.980 --> 08:40.060
different layer three devices so same thing here when a packet comes in on

105
08:40.060 --> 08:45.020
this blue interface it's going to check the routing table for the blue VRF and

106
08:45.020 --> 08:48.700
maybe there's several different interfaces here it's going to check the

107
08:48.700 --> 08:52.540
routing table and decide hey do I send it out this one or this one but I could

108
08:52.540 --> 08:56.940
never send it out a green interface that's just not going to work but

109
08:56.940 --> 09:00.940
partly because it's just in a different VRF but ultimately what the reasoning
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
08:56.940 --> 09:00.940
partly because it's just in a different VRF but ultimately what the reasoning

110
09:00.940 --> 09:04.860
behind that is is the fact that we've got two completely different sets

111
09:04.860 --> 09:08.700
of our routing tables whether we're talking about the rib or the fib or the

112
09:08.700 --> 09:13.500
adjacency table. Now likewise our routing processes are

113
09:13.500 --> 09:20.860
also going to have to specify a VRF and so if I'm configuring EIGRP or OSPF

114
09:20.860 --> 09:24.540
then when I create these processes I'm going to have to specify this because

115
09:24.540 --> 09:29.580
maybe I'm running EIGRP across my blue domain down here

116
09:29.580 --> 09:33.500
but I'm actually running OSPF as part of my green domain.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

116
09:29.580 --> 09:33.500
but I'm actually running OSPF as part of my green domain.

117
09:33.500 --> 09:37.740
Well I'm going to need to specify which VRF these processes are operating in

118
09:37.740 --> 09:41.580
especially if for example I'm running OSPF in both of those that's going to

119
09:41.580 --> 09:45.260
make it even more critical. Now this makes it pretty interesting because

120
09:45.260 --> 09:48.300
when we come back to our original diagram up here

121
09:48.300 --> 09:52.300
we see that if I want to bring a packet in on VRF 10

122
09:52.300 --> 09:56.460
and maybe I want to go out this VRF 20 interface over here.

123
09:56.460 --> 10:01.340
Well the only way for me to do that is to somehow talk to a device
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

123
09:56.460 --> 10:01.340
Well the only way for me to do that is to somehow talk to a device

124
10:01.340 --> 10:04.540
that bridges the gap. Maybe I've got a router out here

125
10:04.540 --> 10:10.220
that has no VRF awareness just one routing table and so I connect in

126
10:10.220 --> 10:14.860
via this interface here and this interface is what connects around

127
10:14.860 --> 10:20.220
down to VRF 20. Well at that point I could since this belongs to VRF 10

128
10:20.220 --> 10:24.140
I could bring this packet in send it out VRF 20

129
10:24.140 --> 10:27.900
or VRF 10 interface here get routed like normal

130
10:27.900 --> 10:33.580
through this device and then this gets sent into VRF 20 on the other side.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

130
10:27.900 --> 10:33.580
through this device and then this gets sent into VRF 20 on the other side.

131
10:33.580 --> 10:37.580
They say well what's the point of that? Well maybe this device here

132
10:37.580 --> 10:42.380
is a firewall or it's performing inspections something along those lines.

133
10:42.380 --> 10:46.220
So I don't want it to access this side of the router

134
10:46.220 --> 10:50.620
and whatever network it's attached to until it has been directed through that

135
10:50.620 --> 10:53.980
other device so that's one of the use cases of VRFs.

136
10:53.980 --> 10:58.460
But it is important to note that we cannot break through

137
10:58.460 --> 11:04.300
and get from VRF 10 to VRF 20 that really isn't an option.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

137
10:58.460 --> 11:04.300
and get from VRF 10 to VRF 20 that really isn't an option.

138
11:04.300 --> 11:07.980
We can kind of do that on layer two switches because I have the ability

139
11:07.980 --> 11:13.900
to bring a packet in on VLAN 20 get up to the SVI the higher level

140
11:13.900 --> 11:19.020
and then route over to SVI 10 and then get sent out and as a VLAN 10

141
11:19.020 --> 11:22.700
interface. So I do have a path to get from one VLAN to another on a

142
11:22.700 --> 11:26.460
multi-layer switch. I don't have that capability

143
11:26.460 --> 11:32.300
in the VRF and layer three world. So at the end of the day we might want to ask
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

143
11:26.460 --> 11:32.300
in the VRF and layer three world. So at the end of the day we might want to ask

144
11:32.300 --> 11:39.260
the question of what is the practical use case for VRFs?

145
11:39.260 --> 11:44.460
Because we're typically coming at this whole on-core course and on-core set of

146
11:44.460 --> 11:48.060
skills from an enterprise network perspective.

147
11:48.060 --> 11:52.060
And the reality is that the primary most common use case

148
11:52.060 --> 11:57.820
for VRFs is always going to be multi-tenancy

149
11:57.820 --> 12:02.860
in the service provider space which service providers a different
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

149
11:57.820 --> 12:02.860
in the service provider space which service providers a different

150
12:02.860 --> 12:07.740
technology as far as Cisco is concerned. We have a whole different set of

151
12:07.740 --> 12:12.380
skills and a whole different set of courses and ultimately exams

152
12:12.380 --> 12:17.260
from a Cisco perspective that cover service provider routing. At that point

153
12:17.260 --> 12:21.980
we're talking about BGP, we're talking about MPLS,

154
12:21.980 --> 12:26.940
and so we're not going to see a lot of multi-tenancy in the enterprise

155
12:26.940 --> 12:27.500
networking

156
12:27.500 --> 12:36.140
space. So where would we see this? Well it would take away BGP and MPLS, we're
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

156
12:27.500 --> 12:36.140
space. So where would we see this? Well it would take away BGP and MPLS, we're

157
12:36.140 --> 12:42.700
going to see other use cases that are known as operating with VRF light.

158
12:42.700 --> 12:46.460
Now this phrase VRF light, it didn't always used to exist. I remember the first

159
12:46.460 --> 12:50.210
time I heard it I thought what what is VRF light? I mean I know what VRFs are,

160
12:50.210 --> 12:50.300
so

161
12:50.300 --> 12:54.940
what is VRF light? Well VRF light is a phrase that gets tossed around in the

162
12:54.940 --> 13:00.300
industry now and essentially it's saying no BGP or MPLS.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

162
12:54.940 --> 13:00.300
industry now and essentially it's saying no BGP or MPLS.

163
13:00.300 --> 13:03.740
It's pretty much everything we've described up until now. It's just using

164
13:03.740 --> 13:08.860
VRFs in a network and yeah the practical applications aren't going to be quite

165
13:08.860 --> 13:14.780
as prevalent because there's not a lot of use case for this type of situation

166
13:14.780 --> 13:19.180
where we want to force traffic from one layer three device to another layer

167
13:19.180 --> 13:19.420
three

168
13:19.420 --> 13:22.620
device then back to the original layer three device in a different VRF.

169
13:22.620 --> 13:27.420
We can come up with reasons for it and I've deployed VRFs in enterprise spaces

170
13:27.420 --> 13:31.260
using that type of logic to say we're going to force traffic a particular way
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

170
13:27.420 --> 13:31.260
using that type of logic to say we're going to force traffic a particular way

171
13:31.260 --> 13:37.020
using VRFs. But outside of really BGP and MPLS it's one of the only use cases

172
13:37.020 --> 13:41.180
we're going to see and again they're just trickier to use on their own and

173
13:41.180 --> 13:45.340
that's why I call it VRF light because it's pretty simple to spin up VRFs and

174
13:45.340 --> 13:50.140
use them that's hence the light part as opposed to integrating it with

175
13:50.140 --> 13:53.820
BGP and MPLS from a service provider perspective.

176
13:53.820 --> 13:57.980
So where can we expect to see this? Well once again if we want to call this

177
13:57.980 --> 14:02.940
traffic engineering or traffic direction either way that is certainly going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

177
13:57.980 --> 14:02.940
traffic engineering or traffic direction either way that is certainly going to

178
14:02.940 --> 14:03.100
be

179
14:03.100 --> 14:08.140
one of the applications of VRF light. Another place we'll absolutely see this

180
14:08.140 --> 14:12.540
I guarantee it because it's the default for a lot of Cisco platforms

181
14:12.540 --> 14:18.380
is creating a true out-of-band connection for our management network.

182
14:18.380 --> 14:23.340
So what exactly does that mean? Well traditional management requires us to

183
14:23.340 --> 14:26.220
take let's just say this is a layer three switch

184
14:26.220 --> 14:31.180
and I am going to configure an SVI as part of this layer three switch
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

184
14:26.220 --> 14:31.180
and I am going to configure an SVI as part of this layer three switch

185
14:31.180 --> 14:35.340
along with all the other SVI's by the way for my management.

186
14:35.340 --> 14:40.380
Which means that my management is technically in band. In band management

187
14:40.380 --> 14:44.300
says I'm going to come in you know on the same interface is that all of my

188
14:44.300 --> 14:48.620
users are coming in on and potentially other networking

189
14:48.620 --> 14:52.780
links like trunk links and such all of that

190
14:52.780 --> 14:56.300
those same types of interfaces are how I come in to perform

191
14:56.300 --> 15:00.620
management and I just happen to connect to an SVI which means by the way in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

191
14:56.300 --> 15:00.620
management and I just happen to connect to an SVI which means by the way in

192
15:00.620 --> 15:00.860
most

193
15:00.860 --> 15:05.740
cases without ACLs and all kinds of things that any of my user subnets

194
15:05.740 --> 15:11.980
could actually access the management SVI. So in band management is not ideal

195
15:11.980 --> 15:16.140
we certainly use it in a lot of places it's usually better to

196
15:16.140 --> 15:20.780
form out-of-band management which again we think about carving things up here

197
15:20.780 --> 15:24.620
out-of-band management has a different VRF for management

198
15:24.620 --> 15:29.020
and makes it so that I have to come in this interface whereas all my users who

199
15:29.020 --> 15:32.460
are in a different VRF and have access to all these other
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

199
15:29.020 --> 15:32.460
are in a different VRF and have access to all these other

200
15:32.460 --> 15:37.250
SVI's there's no way for them to route to one of these SVI's and then route

201
15:37.250 --> 15:37.740
over

202
15:37.740 --> 15:42.060
to the management interface because it's in a completely different VRF.

203
15:42.060 --> 15:47.660
So this would be out-of-band management and it is the preferred solution from a

204
15:47.660 --> 15:51.580
security perspective because it truly isolates management

205
15:51.580 --> 15:54.940
management network traffic. Now could this VRF

206
15:54.940 --> 15:59.020
or dedicated out-of-band management port just loop back around and plug right

207
15:59.020 --> 16:02.700
back into the same switch and therefore get integrated into
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

207
15:59.020 --> 16:02.700
back into the same switch and therefore get integrated into

208
16:02.700 --> 16:06.620
the in-band world? Absolutely it could but it could also be a separate network

209
16:06.620 --> 16:09.740
it could also pass through firewalls at least it gives us

210
16:09.740 --> 16:16.780
the option to fully flash out an out-of-band network.

211
16:16.780 --> 16:20.780
So those are going to be some of the primary use cases for us we could use

212
16:20.780 --> 16:25.340
this to manage air-gapped networks by you know it will at that point save us

213
16:25.340 --> 16:29.020
from deploying multiple physical devices we could do something again like this

214
16:29.020 --> 16:33.740
up here where we've got two different routing domains and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

214
16:29.020 --> 16:33.740
up here where we've got two different routing domains and

215
16:33.740 --> 16:37.580
they shall never in our mix if we take out the thing on the left here

216
16:37.580 --> 16:42.220
but we never intermix the two domains and we just need those two networks to

217
16:42.220 --> 16:46.380
not talk to one another that could be for security purposes

218
16:46.380 --> 16:50.140
there's you know medical world sometimes has these back-end networks so

219
16:50.140 --> 16:53.500
we might see those kinds of things with the air-gapped networks

220
16:53.500 --> 16:57.260
but one thing we're never going to find at least with VRF light

221
16:57.260 --> 17:02.700
is the concept of a trunk so there's really no way to bridge multiple VRFs
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

221
16:57.260 --> 17:02.700
is the concept of a trunk so there's really no way to bridge multiple VRFs

222
17:02.700 --> 17:07.500
together on a trunk link I couldn't just connect these two together and include

223
17:07.500 --> 17:12.140
two different VRFs now in a full VRF implementation using

224
17:12.140 --> 17:18.140
BGP and especially MPLS that is doable I could use MPLS tags in the middle here

225
17:18.140 --> 17:23.580
to carry multiple VRFs so 10 and 20 but unfortunately it's a lot more

226
17:23.580 --> 17:27.580
complicated to set up than simply configuring a link to be a trunk like it

227
17:27.580 --> 17:32.380
is in the layer two world so this is how VRFs come together
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

227
17:27.580 --> 17:32.380
is in the layer two world so this is how VRFs come together

228
17:32.380 --> 17:36.700
again our focus the scope of this course and the scope of this exam is going to

229
17:36.700 --> 17:40.380
be on the world of VRF light don't need to worry about integrating it with

230
17:40.380 --> 17:44.300
BGP and MPLS but do understand in an enterprise sense

231
17:44.300 --> 17:48.140
it does limit our applications we can come up with some nifty applications

232
17:48.140 --> 17:50.940
here but it is going to be tricky to really

233
17:50.940 --> 17:57.660
find practical use cases for VRFs in this enterprise space