Well, when we build layer two domains using layer two switches, we have found
that this creates too large of a domain and so we want to make sure we don't
have a thousand hosts in a single broadcast domain for example and so we
carve this up into different virtual networks. So we have VLAN 10 on top, we
have VLAN 20 on bottom and as the drawing is currently drawn here, this
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
link would be in one of those VLANs, VLAN 20 and so we might need another
connection here between VLAN 10 to spread that and we have two completely
different virtual domains even though we have only two physical switches we've
got technically two sort of virtual switches in each one of these domains.
So we could argue we have four different sets of switches. Really what this
amounts to is each one of these domains has its own cam table and so we have
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
two different cam tables as we've talked about in this course and on each
individual switch which is why we have effectively two different virtualized
switches even though we have one physical switch. Now naturally the
industry came together and said hey it'd be a great idea if we could come up
with a concept like a trunk which would carry two different VLANs we wouldn't
need this other link if we have two VLANs we needed two links, if we had 10 V
LANs
we would have needed 10 links. Well now we could put all of those VLANs on a
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
single link and call it a trunk. So here's the question, how much of this can
we
accomplish at a layer three level? This is all happening at layer two but when
we move to layer three here we are talking about having two different
routers communicating with one another and maybe we've got different
connections happening here on the layer three interfaces we're usually talking
about much fewer connections on a router versus a switch which might have 48
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
ports, router might just have a handful of ports and so can we carve this up in
the same way? And the answer is yes we have this wonderful technology called
virtual routing and forwarding which unfortunately is not quite as catchy as
a virtual LAN. I think we'd maybe have come up with something that you could
actually say rather than you know people pronounce this sometimes as a
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
verb for a VRF but either way it's is what it is. The VRF is effectively the
same thing as a VLAN when it comes to layer three versus layer two. We're
taking a physical device we have two different physical routers here and we're
going to carve this up into virtual routers virtual routing instances and so
what we can do here is say let's make... we'll carve it up like this. So just
like
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
above we're now we've got VRF 10 on the top half, VRF 20 on the bottom half and
now this link here we see we've got a link in VRF 10 and we might want to have
another link in here at VRF 20 and so two physical devices here is what we've
got and yet we have four different logical devices. Now we talk about
logical switches that amounted to having different cam tables. A virtual router
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
is going to be very similar in that we are going to have our own set of tables
here and when we think back to the conversation around SAS and our routing
tables and everything we're going to actually have a set of tables from a
layer three perspective that involves the rib which is effectively the routing
table. We're also going to have the SEF tables so we are going to have the
FIB, the forwarding information base as well as the adjacency table. So those
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
three tables are going to exist in each one of these VRFs on a per device basis
.
So yeah that truly means we have our own routing table for every VRF that we
configure. Now Cisco devices are actually built for VRFs from the ground up
sort
of like how again when we think back to layer two world all of these ports the
default for a layer two switch port is going to be placed into VLAN 1. There's
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
no way to disable VLANs on a layer two switch at least as far as Cisco devices
are concerned. Every port is going to be in VLAN 1 when we first turn it on and
security recommendations are usually such that we change that over to
something other than VLAN 1. Well VRFs are going to be the same way in that we
're
going to be assigned the default VRF. The default VRF is going to include the
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
global routing table for that VRF and when you time we run commands such as
ping commands or we enter into a router instance such as an EIGRP or OSPF
instance by default they're going to belong to the default VRF. If I just say
ping 10.0.0.1 it's going to reference the rib or the fib or the
adjacency table maybe all of them and it's going to ping using the default VRF
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
but I can also specify using these same commands different VRFs. So I could say
hey I want to ping 10.0.0.1 in a different VRF altogether. Now that's
interesting because we also now see that we've got the ability to have
different
VRFs so if I configure two VRFs I'm still going to have the default so I'd
have three at that point. So I have the default VRF and we can actually give
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
names to our VRFs. They don't have to be numbers although we could name them
numbers. So let's just call this VRF green we'll call them colors here and
then we have a different VRF that we call blue. So remember each one of these
VRFs is going to have its own routing table. So what happens if I want to place
an interface into assign it 10.0.0.1/24 in the default VRF and then I get on to
a
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
different VRF interface and I want to configure it with the same /24 address.
Well at this point we have a duplicate IP address and yeah it's also not a
duplicate IP address because the default VRF is going to manage its own tables
just as VRF green is going to manage its own tables and VRF blue will do the
same thing. So I could actually put this IP address in every single one of my
VRFs
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
and that is going to be okay. Everybody is happy here because I only care about
duplicate IP addresses existing within the same VRF. Now if I never
configure these VRFs, never actually configure additional VRFs, I'm only
operating in the default VRF whether I realize it or not and therefore I couldn
't
create duplicate IP addresses within the VRF. I couldn't put two you know the
same
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
IP address on two different interfaces but as soon as I start configuring many
VRFs well now that becomes an option. Furthermore when I'm configuring a VRF
the VRF gets mapped to the interface and so when we look at a router or even
this situation up here maybe we see lots of interfaces in there well this
interface is going to belong to let's say VRF green here and then I configure
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
this interface to be part of VRF blue and then maybe these interfaces over here
also belong to green and blue. So I can only map a single VRF to a single layer
three interface. Now that could be physical interfaces or sub interfaces or
SVIs if it's a layer three switch and furthermore when a packet comes in on
one of these interfaces it's only going to check the routing table that belongs
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
to that VRF which also means that it has to go out an interface in that VRF.
Remember we've basically logically carved this layer three device up into two
different layer three devices so same thing here when a packet comes in on
this blue interface it's going to check the routing table for the blue VRF and
maybe there's several different interfaces here it's going to check the
routing table and decide hey do I send it out this one or this one but I could
never send it out a green interface that's just not going to work but
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
partly because it's just in a different VRF but ultimately what the reasoning
behind that is is the fact that we've got two completely different sets
of our routing tables whether we're talking about the rib or the fib or the
adjacency table. Now likewise our routing processes are
also going to have to specify a VRF and so if I'm configuring EIGRP or OSPF
then when I create these processes I'm going to have to specify this because
maybe I'm running EIGRP across my blue domain down here
but I'm actually running OSPF as part of my green domain. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but I'm actually running OSPF as part of my green domain.
Well I'm going to need to specify which VRF these processes are operating in
especially if for example I'm running OSPF in both of those that's going to
make it even more critical. Now this makes it pretty interesting because
when we come back to our original diagram up here
we see that if I want to bring a packet in on VRF 10
and maybe I want to go out this VRF 20 interface over here.
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
Well the only way for me to do that is to somehow talk to a device
that bridges the gap. Maybe I've got a router out here
that has no VRF awareness just one routing table and so I connect in
via this interface here and this interface is what connects around
down to VRF 20. Well at that point I could since this belongs to VRF 10
I could bring this packet in send it out VRF 20
or VRF 10 interface here get routed like normal
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
through this device and then this gets sent into VRF 20 on the other side.
They say well what's the point of that? Well maybe this device here
is a firewall or it's performing inspections something along those lines.
So I don't want it to access this side of the router
and whatever network it's attached to until it has been directed through that
other device so that's one of the use cases of VRFs.
But it is important to note that we cannot break through
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
and get from VRF 10 to VRF 20 that really isn't an option.
We can kind of do that on layer two switches because I have the ability
to bring a packet in on VLAN 20 get up to the SVI the higher level
and then route over to SVI 10 and then get sent out and as a VLAN 10
interface. So I do have a path to get from one VLAN to another on a
multi-layer switch. I don't have that capability
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
in the VRF and layer three world. So at the end of the day we might want to ask
the question of what is the practical use case for VRFs?
Because we're typically coming at this whole on-core course and on-core set of
skills from an enterprise network perspective.
And the reality is that the primary most common use case
for VRFs is always going to be multi-tenancy
in the service provider space which service providers a different WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in the service provider space which service providers a different
technology as far as Cisco is concerned. We have a whole different set of
skills and a whole different set of courses and ultimately exams
from a Cisco perspective that cover service provider routing. At that point
we're talking about BGP, we're talking about MPLS,
and so we're not going to see a lot of multi-tenancy in the enterprise
networking
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
space. So where would we see this? Well it would take away BGP and MPLS, we're
going to see other use cases that are known as operating with VRF light.
Now this phrase VRF light, it didn't always used to exist. I remember the first
time I heard it I thought what what is VRF light? I mean I know what VRFs are,
so
what is VRF light? Well VRF light is a phrase that gets tossed around in the
industry now and essentially it's saying no BGP or MPLS. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
industry now and essentially it's saying no BGP or MPLS.
It's pretty much everything we've described up until now. It's just using
VRFs in a network and yeah the practical applications aren't going to be quite
as prevalent because there's not a lot of use case for this type of situation
where we want to force traffic from one layer three device to another layer
three
device then back to the original layer three device in a different VRF.
We can come up with reasons for it and I've deployed VRFs in enterprise spaces
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
using that type of logic to say we're going to force traffic a particular way
using VRFs. But outside of really BGP and MPLS it's one of the only use cases
we're going to see and again they're just trickier to use on their own and
that's why I call it VRF light because it's pretty simple to spin up VRFs and
use them that's hence the light part as opposed to integrating it with
BGP and MPLS from a service provider perspective.
So where can we expect to see this? Well once again if we want to call this
traffic engineering or traffic direction either way that is certainly going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
traffic engineering or traffic direction either way that is certainly going to
be
one of the applications of VRF light. Another place we'll absolutely see this
I guarantee it because it's the default for a lot of Cisco platforms
is creating a true out-of-band connection for our management network.
So what exactly does that mean? Well traditional management requires us to
take let's just say this is a layer three switch
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
and I am going to configure an SVI as part of this layer three switch
along with all the other SVI's by the way for my management.
Which means that my management is technically in band. In band management
says I'm going to come in you know on the same interface is that all of my
users are coming in on and potentially other networking
links like trunk links and such all of that
those same types of interfaces are how I come in to perform
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
management and I just happen to connect to an SVI which means by the way in
most
cases without ACLs and all kinds of things that any of my user subnets
could actually access the management SVI. So in band management is not ideal
we certainly use it in a lot of places it's usually better to
form out-of-band management which again we think about carving things up here
out-of-band management has a different VRF for management
and makes it so that I have to come in this interface whereas all my users who
are in a different VRF and have access to all these other WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
are in a different VRF and have access to all these other
SVI's there's no way for them to route to one of these SVI's and then route
over
to the management interface because it's in a completely different VRF.
So this would be out-of-band management and it is the preferred solution from a
security perspective because it truly isolates management
management network traffic. Now could this VRF
or dedicated out-of-band management port just loop back around and plug right
back into the same switch and therefore get integrated into WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
back into the same switch and therefore get integrated into
the in-band world? Absolutely it could but it could also be a separate network
it could also pass through firewalls at least it gives us
the option to fully flash out an out-of-band network.
So those are going to be some of the primary use cases for us we could use
this to manage air-gapped networks by you know it will at that point save us
from deploying multiple physical devices we could do something again like this
up here where we've got two different routing domains and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
up here where we've got two different routing domains and
they shall never in our mix if we take out the thing on the left here
but we never intermix the two domains and we just need those two networks to
not talk to one another that could be for security purposes
there's you know medical world sometimes has these back-end networks so
we might see those kinds of things with the air-gapped networks
but one thing we're never going to find at least with VRF light
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
is the concept of a trunk so there's really no way to bridge multiple VRFs
together on a trunk link I couldn't just connect these two together and include
two different VRFs now in a full VRF implementation using
BGP and especially MPLS that is doable I could use MPLS tags in the middle here
to carry multiple VRFs so 10 and 20 but unfortunately it's a lot more
complicated to set up than simply configuring a link to be a trunk like it
is in the layer two world so this is how VRFs come together WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is in the layer two world so this is how VRFs come together
again our focus the scope of this course and the scope of this exam is going to
be on the world of VRF light don't need to worry about integrating it with
BGP and MPLS but do understand in an enterprise sense
it does limit our applications we can come up with some nifty applications
here but it is going to be tricky to really
find practical use cases for VRFs in this enterprise space