So it is time to verify that everything's working.
So we'll bring in a couple VMs.
I'll put one at site one.
We'll call that little VM site one blue.
We'll put another one over here at site two on that same common segment.
We'll call it site two green.
And then we'll verify they get IP addresses.
They can ping each other and they can get access out to the Internet.
So at the moment, currently the tier zero gateway, the active is right here at
site one.
And the tier one gateway is also active here.
Now the reason that matters is because the traffic flow from these VMs as they WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now the reason that matters is because the traffic flow from these VMs as they
go out to the Internet
for site one blue is going to go like this.
And for the traffic from this green VM out to the Internet, because these are
both standby
based on how we configure the NSX and these stretch gateways,
that traffic would go from the host that's running this VM over to the local
edge node.
And then the local edge node would go ahead and forward it over to the edge
nodes over at site one
who then proceeded the logical processing for the T1 and T0 routing.
And then eventually out to the Internet.
And if we changed which devices were active, that would also influence the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if we changed which devices were active, that would also influence the
traffic flow through the network.
So currently with the T0 and T1 both active here at site one,
let's bring in these VMs and let's do some testing.
And because I have two v centers running, I'll go ahead and have the vCenter
for site one
and light mode.
And then we'll have the vCenter over for site two and dark mode.
So let's begin over here at site one.
So let's go grab a VM. Let me go to the VM and templates view.
Let's use mint a.
All right, click on that and let me rename it and we'll call that site one blue WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, click on that and let me rename it and we'll call that site one blue
to represent the site one blue VM.
Click on OK, let's also make sure it's in the right segments.
We'll right click on that site one blue VM from the menu.
We'll click here on edit settings and then we'll click here and put it on the
right network.
And the network we want is the stretched segment 10 right there and we'll click
on OK and click on OK.
And then we'll go ahead and power that VM up and I'll open up a remote console
to that device.
And while that's initializing, let's go over to the vSphere client over for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And while that's initializing, let's go over to the vSphere client over for
site two.
So here at site two, I've got a little VM called site two green and again,
site to the vSphere client is here in dark mode.
Let me right click on site two green click on edit settings.
Let's verify it's on the right network.
So we'll go to the network adapter, click on browse and let's scroll down and
put it on segment 10.
That looks good.
Click on OK and click on OK.
Then we'll power it up as well and we'll also open up a remote console.
So just to confirm if we went to the networking tab and went to stretch segment WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So just to confirm if we went to the networking tab and went to stretch segment
10 here at site two,
I've got site two green running on a host called ESX X.
And if we jumped over to the vSphere client for site one and went to the
networking tab just to confirm if went to the stretch segment 10.
There is the site one blue VM running on a host called ESXIA.
So let me bring up consoles for each of those.
So there's a little console for site two green right there.
And here is a console for site one blue site one blue is running a flavor of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And here is a console for site one blue site one blue is running a flavor of
Linux known as mint Linux.
And this one right here is running a really small version of legs called tiny
core Linux and they both have VMware tools installed.
So let's verify our IP dressing.
We'll start here on the site to green and we'll type in if config.
And sure enough, it has an IP address 10 10 0 1 53 right there.
And if we type in route, we can verify it has a default gateway set to 10 10 0
1.
And if we try a ping out to for example 8 8 8 8 press enter.
I'm juggling a little bit because there's a lot going on and that's working the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm juggling a little bit because there's a lot going on and that's working the
first time out of the gate.
So that's great news.
So we have our connectivity and again to confirm it's IP address will do a IF
config and it's IP address is 10 10 0 1 53.
So next let's go over to our site one blue here on the left and let's bring up
a command prompt.
And so here let's go ahead and do an IF config and it is at the IP address 10
10 0 1 52.
So we'll ping the 10 dot 10 dot 0 1 53.
Nice to double check on that IP address that looks good and we'll press enter WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Nice to double check on that IP address that looks good and we'll press enter
and sure enough we have connectivity between these two VMs on that common
segment from site one to site to fantastic.
And let's also verify we can get to the Internet.
So one way of doing that would be a trace route.
So on this platform it's got trace path that'll work as well.
I'll say no name resolution required and let's do a maximum number of hops with
the dash M of five and let's go out to 8 8 8 8 and all I'm really concerned
about is the first few hops.
So notice here that is going out through service provider a at 23.1.2.1 then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So notice here that is going out through service provider a at 23.1.2.1 then
over here if we went to site to green this VM here will notice that its trace
is going to be different because it's going through a different path as that
traffic gets sent from site to over to site one to the edge.
So it's going to be different than the other one.
So I'm going to say there's going to be a trace route that's going to be
different than the other one.
So if you're looking at the first five hops in the path I'll say that's going
to be a different type of pass center.
So I'll go ahead and zoom these in a little bit. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'll go ahead and zoom these in a little bit.
So notice here they both went out through their default gateway at 10 10 0 1
but as far as all the hops in the path is different for these two VMs and that
's because one of them is at site two and the other is at site one.
So behind the scenes the actual flow of traffic logically is different.
Now a great way of seeing that is to use trace flow in the NSX manager and
fortunately we can do that right from the global manager.
So if we go back to the NSX global manager and we go to the plan and troublesh
oot tab right there here we can do our trace flow. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
oot tab right there here we can do our trace flow.
So here for the source we specify VM and we're going to specify the site.
Let's say site one and for the VM let's use site one blue and then for the
destination.
Let's go ahead and target an IP address that's done on our local network.
Let's go out to 888 just like that and then we'll go ahead and click on trace
and that'll take just a couple of moments and when it's done it'll show us the
play by play for that traffic going from a VM at site one as it's going out to
the Internet.
So here's the graphical representation that it worked and let's go ahead and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here's the graphical representation that it worked and let's go ahead and
make that a little bit bigger.
So it started at the blue VM through segment 10 through the tier one to tier
zero and out to the Internet.
And if we collapse that and look at the play by play right here it's going to
show us all the nodes it went through.
So here on the left I'm going to collapse the column for trace flow to give us
a little bit more room.
And if we didn't want to see the play by play of all the devices involved we
can just click here on one delivered it'll show the results or we can click
here on all and it'll show us all the details.
Or we can click on the dropped option to see exactly where it dropped as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Or we can click on the dropped option to see exactly where it dropped as well.
Now because it made it we don't have any drops.
So let's go back to all. So because the VM lives on ESXIA it did a lot of the
initial processing including the logical firewall rules.
It also identified because the tier one gateway is set up as active standby
that's going to require an edge note.
So it forwarded over to its local edge which is happening right here.
Let me go ahead and scroll to the right a little bit.
So this is ESXIA using its tunnel endpoint to send it to and based on the IP
address that is edge one.
So edge one must be the active edge node at site one for the tier one gateway. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So edge one must be the active edge node at site one for the tier one gateway.
So edge one continues to process that including processing the firewall rules
including the routing based on the tier one gateway including the processing of
the net rule before it forwarded out to the Internet.
So currently the play by play was ESXIA and then edge one all the way through.
So if we went in and we manipulated who the active router is for the tier zero
gateway at site one and we said hey we wanted to be edge two.
The results here would change. In fact that's easy to do. Let's do that. So we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The results here would change. In fact that's easy to do. Let's do that. So we
're here in the NSX global manager and with networking selected we'll go to our
tier zero gateways and then we'll edit our tier zero gateway by hitting the
three dots clicking on edit.
And then instead of having it choose which edge node we want to use we're going
to go ahead right here and say you know what we want edge to to be the
preferred edge.
Again this is for the tier zero gateway. We'll go ahead and we'll save that and
close that.
So with that change for the tier zero gateway saying we prefer edge to let's do
that trace again. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that trace again.
So we'll go back to plan and troubleshoot. It already has that trace loaded so
we'll go ahead and simply run it again.
So we'll click here on retrace and then we'll simply run the trace again with
all the same parameters.
So we'll give that a moment to run and then we'll look at the details. Let me
bring that up a little bit.
So the beginning of our journey is still ESXIA because that's who's hosting
that VM.
If we scroll down ESXIA handed off to edge one who is responsible for the tier
one gateway.
And then as we continue to scroll down right here we have edge one who is now WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then as we continue to scroll down right here we have edge one who is now
handing it over to edge two and that is happening right here.
And that's because edge two we specified as the preferred edge node to handle
the responsibilities for the T zero gateway.
So now edge two is doing its work and doing the processing including the net.
So let me share with you one other really cool thing. So here is our current
trace out to the internet and we're going out through service provider one here
based on that IP address.
So currently we're using site one and service provider a with this 23.1.2 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So currently we're using site one and service provider a with this 23.1.2
address base for egress out of the network.
And that's because in our topology we specified that we want site one to be the
primary and site to be the standby or the backup.
So what would happen if we went back to our configuration here at the NSX
manager and we went to networking and then with networking selected if we go
back to our tier zero gateways.
And if we edited the tier zero gateway we'll click on edit to do that.
And here if we said you know what we don't want site one to be the primary we
want site two to be the primary.
Let's go ahead and flip that.
I'll say site two is the primary site one is the secondary as far as the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'll say site two is the primary site one is the secondary as far as the
priority goes for the secondary.
We only have one secondary so I'll use the priority one there and then
furthermore we can specify which edges to choose.
So here at site one is no longer even the primary for T zero.
So it won't really matter too much about edge to here because the work for the
T zero gateway is going to be processed by the edge nodes over now at site one
once we save this.
So I'm going to go ahead and take off the preference for edge two at site one
and I'll go ahead and let NSX choose which node at each of the sites. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and I'll go ahead and let NSX choose which node at each of the sites.
But the final result here is going to be that the traffic as it's being sent
out to the Internet is now going to be done through site two.
So the actual service provider and the associated IP address base there is now
going to be using service provider to going through site two once we save this.
So we'll click on save and we'll go ahead and close that.
So now the primary is going through site two now just be aware also that when
we make changes here it's pretty disruptive if there's a lot of traffic going
through the network at the moment we're making the changes.
So you definitely want to schedule some downtime before you change the logical WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So you definitely want to schedule some downtime before you change the logical
routing depology inside your environment.
So now that we've done that here in our lab environment and I've given it a
couple seconds.
Let's bring back our VM.
So here's the site one blue VM on the left hand side and when we did this trace
out to the Internet earlier it was going out through service provider A through
site one.
So the address base of 23.1.2.1.
So now check this out my hands will never leave my arms if we hit the up arrow
key and press enter check this out.
Now we are going through 24.1.2.1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now we are going through 24.1.2.1.
And you'll also notice that we have this additional hop the 169.2.4 address
base is what we're using for the backplane routes.
So the other cool thing is that if we went back to the plan and troubleshoot
right now and we did that same exact flow for site one blue going out to the
Internet and we clicked on retrace and then clicked on proceed.
It's now going to show us the exact play by play hop by hop logically as that
packet is being sent.
So here's the play by play for this flow of traffic.
Again we're coming from site one blue going out to the Internet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Again we're coming from site one blue going out to the Internet.
So ESXIA first is processing it with all the rules involved and then ESXIA is
handing it over based on the tunnel endpoint here to edge one at site one.
And then edge one is doing some processing. So edge one is handing it over to
edge two and based on the outputs very likely to edge two is the active edge
node for the T zero gateway at site one.
However the bad news is that site one is not responsible for for that traffic
out to the Internet.
The primary site for the tier zero gateway is site two.
So we're going to see here in a moment that edge two using its remote tunnel WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we're going to see here in a moment that edge two using its remote tunnel
endpoint address is shipping that over through the tunnel over to an endpoint
address of an edge node at site two.
So it's leaving site one.
Now it's at site two.
Site two does the logical processing for the tier zero gateway including the
net and forwarding it out to the Internet via service provider B or going
through that 24 dot one dot two address space.
So now that we have configured and tested our implementation of the stretched
gateways and segments to help reinforce these concepts in the next video. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
gateways and segments to help reinforce these concepts in the next video.
I've got a little validation exercise that we can go through together. So when
you're ready, I'll see you in the next video.
video.