To really appreciate the concept of the idea of VRF light and what it brings to
the table,
let's first take a look at what we have built so far during this course.
Currently, we have an
external gateway. We have an external segment that's on the VLAN 23 with the IP
address base of 23.1.2.
At our tier 0 gateway, we're using .61 and .62 for edge 1 and edge 2
respectively.
We also have a virtual IP address of .60 here on this 23.1.2 network. And then
below our tier 0 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
below our tier 0
gateway, we have inter router connections down to our tier 1 gateway A here and
tier 1 gateway B
here. And then connected to each of those, we have an overlay segment with
segment 10,
supporting the 10-10 address base and segment 20, supporting the 10-20 address
base. And then
behind the scenes, here is our infrastructure regarding our transport nodes,
both host transport
nodes, host A and B, and our edge transport nodes, edge 1 and edge 2. So
everything we've built so far
is functional, it works. However, what if we are a provider and we have a
couple of different WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
couple of different
customers? So let's imagine we have customer 1 and we have customer 2. Now it's
very possible
for each of those customers, they're going to want to have their own networks.
For example,
customer 1 may want to have down here a 10.10 network and customer 2 also may
want to have a
10.10 network. And each customer may want to have a 10.20 as well, IP address
base and so
forth and so on. And because they're separate customers, they should be able to
have their own
sets of routes that they're using in their environment. So over here customer 1
may have a
T1 router, customer 2 has a T1 router, and then customer 1 has a T0 router, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
T1 router, customer 2 has a T1 router, and then customer 1 has a T0 router,
customer 2 has a T0
router. However, once again, we need to keep all the routes for customer 1
separate from the routes
for customer 2 because they're overlapping IP address bases and also customer 1
doesn't need
access to any of customer 2 stuff and vice versa. So how do we do that? How do
we take our NSX
environment and logically chunk it up into subsections or sub routing
environments? And the answer is
VRF Lite. And VRF stands for virtual routing and forwarding. And here's a great WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
VRF Lite. And VRF stands for virtual routing and forwarding. And here's a great
way to help
understand how VRF works. Let's imagine we have a single router. So this
represents a router
and inside that router perhaps has dozens of routes. And by default, most
routers can keep all those
routes and what's known as the default or the global routing table. However, if
we have multiple
customers and they need to keep track of their own routes, if we had a single
router to do that,
what we could do is carve it up using VRF virtual routing and forwarding. So
let's imagine customer
1 will just take a little chunk out of here. So that'll be customer 1 and blue, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
1 will just take a little chunk out of here. So that'll be customer 1 and blue,
and we'll take
another section of this router and we'll set it up for routes for customer 2.
If we had to get a
third customer, we could carve up another VRF as part of the routing
information on this router,
and we can have that for customer 3. And that way, in this example, we could
use one single router,
but by using VRF's virtual routing and forwarding instances, we can carve up
subsections like little
mini-me portions of that router for one of the customer specific routes. So in
that case, the
1010 network here for customer 1 would be in this VRF, the one here in blue. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
1010 network here for customer 1 would be in this VRF, the one here in blue.
And this subnet
1010 here for customer 2 would be in this VRF, and they wouldn't be part of the
same global
routing table. So think of it like little slices of the routing environment
that are set aside and
dedicated and isolated for an individual customer. So now that we've taken a
look at this logical
concept called virtual routing and forwarding, where we carve up portions of
the route tables for
individual customers, how do we apply that concept here in our network topology
with NSX?
And here's how we're going to pull that off. We're going to start off by
implementing a tier 0 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
implementing a tier 0
gateway, just a normal tier 0 gateway. And then we're going to subdivide that
tier 0 gateway into
logical VRFs. So in this example here in our tier 0 gateway, we're going to
carve off part of that
for customer blue, and we'll carve off another piece here for customer green.
And the way we do
that after we have our tier 0 gateway, we go in and we simply create additional
tier 0 gateways,
but instead of saying tier 0 gateway from the dropdown, we specify that we want
to create a VRF.
And then we create that VRF, which is a sub component of the tier 0 gateway. So WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we create that VRF, which is a sub component of the tier 0 gateway. So
with the tier 0 gateway
in place, we create one VRF for blue, one VRF for green. And again, these would
each represent a
customer that we're supporting. And then below that tier 0 VRF, if we want to,
we can add a tier 1
gateway that's associated with that VRF. And the same thing over here on the
green side, we can
create a tier 1 gateway for green, associate it with the green VRF. And then
anything below that
is going to be associated with that VRF here up on the tier 0 gateway. And then
we follow the same
process down on both sides. We can create segments, associate them with the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
process down on both sides. We can create segments, associate them with the
tier 1 gateways. So this
10, 10 network over here is associated with the tier 1 gateway for the VRF blue
, while this 10,
10 network over here with the same IP addressing space, isn't a problem because
it's associated
with the VRF green, because this segment is connected to the green tier 1
gateway, which is
connected to the green VRF, which is being contained in this little section
right here
of the router. Think of it again, like a little subsection of the tier 0
gateway associated for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
gateway associated for
a specific customer, or sometimes referred to as a specific tenant. So that my
friend is the concept
of using VRF light in an NSX environment. Now another question I like to answer
here in this
overview is why is it called light? Well, some other vendors have solutions
where they're using
VRFs. And one of those is called MPLS VPNs. And behind the scenes uses multi
protocol label switching
and VRFs in combination with border gateway protocol. It's a wonderful,
wonderful thing. However,
if we're using the compartmentalization of the routing table here on our tier 0 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if we're using the compartmentalization of the routing table here on our tier 0
gateway,
and we're not using it in combination with MPLS. And that's where the term
light comes in. We're
not using it in combination with MPLS or MPLS VPNs. We're simply using the VRF
functionality here
in NSX to carve up logical subsections for individual tenants or individual
customers to keep all the
routes. In this case, for blue, separate from the routes for green. And so one
of the best ways of
really appreciating this and also a really great way to reinforce the concepts
up to this point in
the course is to go ahead and implement and verify VRF light in an NSX WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the course is to go ahead and implement and verify VRF light in an NSX
environment.