So based on our game plan,
our first step here is to create
this brand new Tier-1 gateway instead of NSX.
So to do that we're gonna go over to our NSX manager
and create the gateway.
So here on the homepage for the NSX manager,
it shows us in networking that we have one Tier-1 gateway,
and that's the Gateway A that we put in previously
in our previous skill.
So to create a new gateway,
we're gonna click right here on the Networking tab.
And with the Networking tab selected,
again, it's confirming for us
that we have one Tier-1 gateway.
It's also fun, I think, to take a look WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's also fun, I think, to take a look
at the topology occasionally.
So here's our current topology, Gateway A
and we have Segment 10, Segment 20,
and then inside of that we have two VMs on Segment 10
and two VMs on Segment 20.
I also took a moment and made sure
that VM-1 has the address of 10.10.0.10,
and VM-2 has the address of 10.20.0.20.
And I'm thinking a moment right here just to confirm
that that accurately is reflected here.
So VM-1 and VM-2, which are both on ESXi-A,
they're in two different segments and subnets.
And there are their respective IP addresses. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And there are their respective IP addresses.
And if they ever need to forward traffic
off their local subnet,
they're gonna use the default Gateway address of .1
on their respective subnet.
All right, so that looks good,
so let's create our second gateway,
our second Tier-1 gateway,
and we're gonna call it our Tier-1 Gateway B.
So to do that with the Networking tab selected on the left,
we'll click right here on Tier-1 gateways.
So there's our current one, so I'll collapse that.
And let's go ahead and click on add Tier-1 gateway.
So let's go ahead and call this our Tier-1 Gateway B.
And then for the HA mode, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then for the HA mode,
here I'm gonna specify distributed only.
And the reason for that is that I wanna make sure
we're only implementing distributor routers
and not adding on top of that service routers as well.
So anytime we're doing, for example,
a Tier-1 gateways active standby,
that's gonna invoke the services router.
Or if we start implementing Nat or VPNs
or other types of network services,
that's also going to invoke
an additional logical services router
for those specific functions.
But for now, I wanna make sure we're just doing
distributed routers and not the additional services router. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
distributed routers and not the additional services router.
And that's the reason for the demo here.
I'm gonna choose distributed mode
for the second Tier-1 gateway.
And so here it has an option to link this
to a Tier-0 gateway, but because we don't have one yet,
there's nothing to choose.
That'll change after we create a Tier-0 gateway
and there's nothing else required.
So we can go ahead and click on Save
and then scroll down a little bit
and then it's asking if we wanna continue.
So we'll click on No.
And sometimes they'll have that option of,
"Do you wanna continue, yes or no?"
Because they need to create the object first,
in this case, the gateway, and then you can go in further WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in this case, the gateway, and then you can go in further
and configure additional features.
So we've got this created,
I'm gonna go ahead and collapse it.
And now we have our two Tier-1 gateways,
Gateway A and Gateway B.
And if we click on the network topology,
it's gonna reflect that as well.
So here's our Tier-1 Gateway A
connected to our two segments, and here's Gateway B
that's not connected to either one.
So to make this look like our topology,
and let's take a quick peek at that real quick.
We wanna make sure that this gateway here,
the Tier-1 Gateway B is connected to Segment 20,
and we wanna reconfigure Tier-1 Gateway A, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we wanna reconfigure Tier-1 Gateway A,
so it's only connected to Segment 10.
So to do that on the Tier-1 gateways,
we're gonna go to the segments themselves
and specify from the segment perspective
which logical gateway they're connected to.
So let's do that by going to Segment 20
and telling Segment 20,
"Hey, you're no longer connected to Gateway A.
Instead we want you to be connected
and associated with Gateway B."
So to do that, we'll go to our segments.
So on the networking tab up here,
we'll go down to segments on the left
and we're gonna go to the Segment 20 Pink
and we're gonna edit it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we're gonna edit it.
So we'll go ahead and click on the three dots,
from the menu, we'll click on Edit,
and then I'm gonna collapse the left-hand column here
to give us a little more room to play with.
And so currently Segment 20
says it's connected to Tier-1 Gateway A,
and what we wanna do is use the dropdown and say,
"You know what? We don't want you to connect there.
Instead we're gonna connect you over
to this second Tier-1 gateway, Tier-1 Gateway B."
And check this out, because we had already put in 10.20.0.1
as the IP address for this connection,
that logical IP address 10.20.0.1
is now gonna be associated as the interface address WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is now gonna be associated as the interface address
for Gateway B's connection to the Segment 20.
So that's the only thing we need to change here.
So we'll scroll down, click on save,
and then click here on close editing.
And then over here it says In Progress,
we'll click on the refresh button, and that looks good.
So if we expand the left hand column again,
and now click here on network topology.
It's now showing us that we have Gateway A
connected to Segment 10 and we have Gateway B
that's now connected to Segment 20.
So the service here, if we hover over it,
it says we have some default gateway
firewall rules are in place.
By default they're permitting all traffic, which is fine. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
By default they're permitting all traffic, which is fine.
And then down here on the segments themselves,
previously I set up DHCP services
to hand out IP addresses to the clients.
So VM-1 has the address of 10.10.0.10
and VM-3 also on that same segment
has the address of 10.10.0.11, while on Segment 20,
VM-2 has the address of 10.20.0.20.
And VM-4 has the address of 10.20.0.21.
So that's what these services are referring to here
at the segment level and also here at the gateway level.
And behind the scenes, I thought it'd be fun
to take a peek at our transport nodes, ESXi-A and B WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to take a peek at our transport nodes, ESXi-A and B
and also our edge nodes and just verify
that all four of those transport nodes have instances
of Gateway A and Gateway B.
And a pretty direct way of verifying that
is to just open up an SSH session.
And that way we can look at the three logical routers
that are representing our Tier-0 Gateway 0,
Tier-1 Gateway A, and our Tier-1 Gateway B.
So here on the top half I've got a session over
to the ESXi-A host, and down here I've got a connection
over to the ESXi-B and to enter the NSX CLI environment WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
over to the ESXi-B and to enter the NSX CLI environment
on both of them, we simply type in nsxcli.
So I'm typing that down here
and simply gonna send that command
to both windows simultaneously.
All right, so we are in the NSX CLI
for both of these transport nodes.
And let's start off with a get gateways,
which you could also type in get logical routers,
that would also work, same exact results here.
Except the command gateways
is the direction that NSX is moving to
as far as the command line interface.
So those up here we have two distributed routers WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So those up here we have two distributed routers
that ESXi-A knows about and down here on ESXi-B,
we have the same exact two distributed routers.
So if we use the command get gateway
and let's plug in this first UUID,
which represents one of our routers.
So we use that first one on the list
and then let's put in a space
and let's go ahead and ask for forwarding and press enter.
And that's gonna show us the forwarding table.
So based on the results there, we're looking at Gateway B
because it is directly connected to the 10.20.0 network,
and that's what we're seeing right here.
So if we looked at the second entry here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we looked at the second entry here,
lemme go ahead and copy that into my buffer.
So now if we did a get gateway
and we'll plug in the UUID with a paste
and then we said forwarding and pressed enter,
it's gonna show us the routing table
effectively for that gateway,
which in this case based on the IP address here,
that is Gateway A, that's directly connected
to the 10.10.0 network.
So if we were to look at the interfaces
for that virtual router, we could go ahead
and type in get gateway, that UUID again
and then type in interfaces and press enter.
Still there is the command that we issued WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Still there is the command that we issued
on both of them simultaneously
and both of them have this interface.
Here's the UUID associated with this first interface
that's showing us and they both have
the same exact IP address
because it's the same distributed router,
they're both supporting for that virtual IP address,
associated with that gateway, the same MAC address
which is right here,
which is associated with this distributed switch
called DS for NSX, and it's also associated
with this VNI of 68608.
And again that information is consistent on both of them
because they both have effectively the exact same copy WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
because they both have effectively the exact same copy
of the distributed router.
So again here, to summarize, if we did a get gateways
or if we did the older command get logical routers,
it's the same exact output.
Again, they're migrating towards get gateways
instead of the get logical routers.
And also at layer two they're migrating to get segments
as opposed to get logical switches.
All right, so now that we've looked
at the distributed routers so far
for Gateway A and Gateway B on both ESXi-A and B
as transport nodes, let's also take a look WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as transport nodes, let's also take a look
at our edge nodes.
All right, so here what we're looking at
is we have an SSH connection to Edge-1 here at the top
and Edge-2 here in the bottom half.
And then I've got my command window
so I can send commands to both of them simultaneously.
So here if we typed in get gateways and press enter,
here is showing us the gateway information
that these two edge devices know about.
Now one of the questions might be,
well why is it that the host transport nodes
that we just looked at ESXi-A and B,
how come they only have two instances
of a virtual router and the edge devices, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of a virtual router and the edge devices,
Edge-1 and two, they have three?
Well the reason is because the actual edge devices
are running as a VM, so they also have
a routing table just for themselves.
And so that's where this first one right here is,
where it says VRF zero.
Think of that like the the basic routing table
for the VM itself.
And then for the distributed routers,
that would be the second one and third one,
it's also showing us right here in the name,
exactly which distributed routers those are.
So if we were take a look for example at this first one.
We could do a get gateway space and then the UUID WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We could do a get gateway space and then the UUID
and then I'll go ahead and copy and paste that down here
to make it a little bit easier.
So I'll paste that in, space
and let's type in forwarding and press enter.
So what this is showing us is a routing table
for the VM itself.
And so for Edge-3 it's using VLAN 103
and the IP address of 33.33.33.33
with a default gateway on the transport network of .1.
And over here Edge-2 is using the IP address
for its transport network interface,
this tunnel endpoint of 44.44.44.44 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this tunnel endpoint of 44.44.44.44
with a default gateway of .1.
So the routing tables for each
of those VMs across the transport network,
that should reflect that.
So let's confirm that as well.
So here on Edge-1 we are directly connected
to the 33.33.33 network.
Here is our exact IP address
and here's our default gateway that we configured
for this edge device, this edge VM when we deployed it.
And then down here for Edge-2 it has the IP address
of 44.44 et cetera.
It's a 24-bit network it's connected to,
so it's on the 44.44.44 network.
And its default gateway is 44.44.44.1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And its default gateway is 44.44.44.1.
So if we scroll over here to the right,
it's also showing us the layer two address
associated with that.
So if you notice up here for Edge-1,
it's default gateway MAC address of 33.33.33.1 is this,
and down here on Edge-4 is default Gateway Address
of 44.44.44.1 is this,
and these are both on my multilayer switches
in my transport network
that are actually doing the forwarding
and the routing of that traffic.
All right, so now that we've covered that, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, so now that we've covered that,
let me also go ahead and show you an easier way
to look at this information on our edges.
So we type in get gateways,
instead of typing in things like get gateway
and then the long UUID and so forth,
and then the command we wanna issue
like forwarding or whatever,
instead we could just go into the VRF for that router.
So let's take a moment and let's talk about VRFs
because I don't think we've talked about that yet.
And that was a perfect time.
So let's imagine we have a router
and by default most routers from most vendors
have one default routing table.
So if we connect interfaces WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we connect interfaces
for example like 10.10 here and 10.20 here
and that's done when we configure IP addresses
and associate with this router,
it then in its routing table is gonna say,
"Oh, I'm directly connected to the 10.10 network
and the 10.20 network, life is good."
And that's when we're using a single default routing table.
However, when we have a environment
where we have a need for a separate routing tables
for separate functions,
and lemme give you an example of that right here.
This distributed router has certain routes
and this distributed router has different certain routes. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and this distributed router has different certain routes.
So instead of having one giant routing table,
here's what we can do, we can take that router,
so this represents the router
and from a routing table perspective,
we can create virtual routing and forwarding instances
and that's what the VRF represents.
It's a separate compartment,
think of it like a little mini me section
of a routing table.
For example, if you have a refrigerator
and you have three or four people living in the house
and you wanna separate various parts of that refrigerator
for different people to use,
we could say something like the following,
"Okay, for us, we're gonna take the top third WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
"Okay, for us, we're gonna take the top third
of the refrigerator and that's just for us,
so hands off to everybody else."
And then for the first person maybe we give them
the middle part of the fridge,
and let's imagine there's total of three of us
and then the third person,
we'll go ahead and call that person number two,
we can give them the bottom third.
So we're compartmentalizing the refrigerator
just to make sure the right people get to the right stuff.
Well same thing right here in a routed environment.
We can create virtual routing and forwarding instances
which is simply like different sections of the refrigerator.
So let's start off for our section.
So if this is us right here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if this is us right here,
so we'll say that's our section for our routes
in the routing table,
and then for this section, in fact let me color code this
to match what we're using in our topology for our gateways.
So for person one, I'm gonna put that here in orange,
for the fridge analogy,
and for person two I'm gonna put that in blue.
So in our routing table we'll put a little section here
for Gateway A and we'll have another little section
for Gateway B and regarding us,
that we refer to this case for the actual edge device itself
for its own routes or the transport network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for its own routes or the transport network.
So lemme clean that up just a little bit
and I'll put Edge-1 here
because we're talking here about Edge-1.
It's also showing us right here in the output
that this UUID, I'll go ahead
and make a little note here in orange.
That is the UUID for Gateway A as shown here.
And this third one down here, this UUID
starting with 7cbeef is the UUID for Gateway B.
So think of it like the edge device
with three logical routing tables.
One's for itself, which in this case is VRF 0.
And then one for Gateway A, which here is shown as VRF 2, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then one for Gateway A, which here is shown as VRF 2,
and over here at Gateway B is using a logical container
or section of the fridge, if you will,
from the routing table on this edge device,
and that is VRF 3.
And again this is all for Edge-1.
And the only difference here between the VRFs
for Edge-1 and Edge-2 is gonna be the details they have
in their VRF 0.
Again, we looked at that a moment ago in VRF 0 on the edge.
It's gonna have its transport information,
so in VRF 0 on Edge-1 it includes information WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so in VRF 0 on Edge-1 it includes information
like the 33.33 address space and so forth.
While down here on Edge-2 it's VRF 0
is gonna have information about the 44.44 network.
However, as far as these other two VRFs
which represent the other two virtual routers
or the other two logical gateways
that we just configured as part of
a distributed routing environment,
VRF 2 and VRF 3 are gonna be identical
on both of these edges.
So to confirm that, let me show you an easier way
of seeing the details for those VRFs
rather than typing in get gateway and then the long UUID WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
rather than typing in get gateway and then the long UUID
and then the syntax you want,
what we can do is we can just go directly into those VRFs
and issue our commands from within those VRFs.
So I'm gonna make a note up here
that VRF 0 is the local edge
and the routing information for the local edge.
And so what we can do is we can take a look at VRF 2 or 3
on both of these edge nodes
and the information there is going to be identical.
So to do that and also to compare and contrast,
lemme show you the hard way versus the easy way
of looking at the details for those routing instances.
So if we said for example, get gateway WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we said for example, get gateway
and then we plugged in the long UUID,
so we'll grab this UUID that's associated with Gateway A,
so I'll paste that in down here
and then press space, then did forwarding and pressed enter.
That's gonna show us the forwarding information
for Gateway A effectively, the forwarding information
for VRF 2, however, an easier way of doing that
is simply by typing in VRF 2, pressing enter
and that puts us into the logical router
where we can just issue the commands we wanna issue
without having to plug in the actual UUID every single time. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
without having to plug in the actual UUID every single time.
And just as a reminder, if we do a get logical routers
and press enter, or if we do a get gateways
for the time being, both options are gonna work.
But just keep in mind that we're moving towards
more of the CLI that's going to include
just the gateways option as opposed to
the syntax of logical dash routers.
All right, so here just to confirm,
our VRF number for the Gateway A is VRF 2.
So what we can do is simply type here
at the NSX CLI on our edges, we can simply type in VRF space
and the VRF number we want, which is two, and press enter. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and the VRF number we want, which is two, and press enter.
And that puts us logically into that VRF.
See how the prompt changed right there?
Indicating that we are in VRF 2.
So now if we did a question mark,
let's do a question mark and send it in.
So now we can do any of these commands
directly right here from the VRF.
So if we wanna look at forwarding,
we can just say get forwarding for example,
instead of having to put in the entire UUID.
So here on both edge devices,
let's do a get forwarding and press enter.
And that shows at the routing table,
if we do a get interfaces, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if we do a get interfaces,
that'll show us the interfaces
associated with this virtual router.
So for Gateway A, which is using VRF 2 for this interface,
the IP address is 10.10.0.1 on each
of the distributed routers
because they're identical information.
For layer three and for layer two.
So we're regarding the name and the tail end here,
DLRP, DLRP is a a shortcut way of saying
Distributed Logical Router Port, DLRP.
And the same information is gonna be present
on our transport nodes as well.
So if we looked at the details regarding the IP address WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we looked at the details regarding the IP address
and the MAC address associated
with the connection from Gateway A to Segment 10,
all this information including the IP address,
the MAC address, the VNIs associated with,
all that would be identical,
because once again we are using a distributed router,
which is being distributed and is the same,
exact same information across all the transport nodes,
whether they're edge nodes or host nodes
that have that distributed router.
So now that we have created
this new logical Tier-1 Gateway B,
and we've also confirmed that that distributed router exists WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we've also confirmed that that distributed router exists
on ESXi-A as a host transport node
and also exists here on our host transport node ESXi-B
and also exists on our Edge-1 and Edge-2,
our next logical step then is to go ahead
and create our Tier-0 and link that up
or associate that Tier-0 gateway
with Gateway A and Gateway B.
'Cause right now as it sits without this Tier-0 gateway
connecting these two routers together,
clients on Segment 10 over here are not gonna have
connectivity from a routing perspective over here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
connectivity from a routing perspective over here
until we put this Tier-0 Gateway 0 in place.
So we'll do that in the very next video.
I'll see you there in just a moment.