So at this point in our journey, let's go ahead and create a gateway and a
segment that is stretched or can be used effectively by both sites.
And so for the gateway, let's create a tier one gateway. We'll call it tier one
dash S short for stretched and we'll also create a segment.
Let's create a segment called SEG 50 S again. The S reminding us it's a stretch
segment and then we'll test it. We'll put a couple VMs one here at site one.
We'll connect it to segment 50 S. We'll take another VM over here at site two
connected that same shared segment. We'll set up some IP addressing and verify WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
connected that same shared segment. We'll set up some IP addressing and verify
that they can communicate with each other.
We can also use trace flow to verify that packets are making it. And then just
for fun, let's also configure a distributed firewall at the global manager to
control what is or isn't allowed for that site to site traffic.
So here at the global manager and I'm looking at this global manager interface
and I realized I left off. We were working with the edge notes. So I'm going to
click right here on NSX.
And that's going to take us back to the global manager. I'll click here on
system just to confirm. Sure enough, we're back at the NSX global manager. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
system just to confirm. Sure enough, we're back at the NSX global manager.
And if he's called down, we have two sites site one and site two fantastic. So
here at the global manager, let's click on networking and let's create a brand
new tier one gateway.
This can be stretched across both sites and then we'll follow it up by creating
a segment connected to that gateway, which is also stretched across both sites.
So we'll start off here with the tier one gateways. So there's our four tier
one gateways to a site one and to a site two. And we're going to create a new
one right here at the global manager.
So we'll click on add tier one gateway. As far as linking this to a tier zero WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll click on add tier one gateway. As far as linking this to a tier zero
gateway, if we also had a stretch tier zero gateway that we created, we could
link to that.
So for the demo, I'm not going to associate this with a tier zero gateway. And
then as we scroll down a little bit under locations, check this out.
I'm going to specify that I want this associate with site one and we'll click
right here on add location. I also want it associated with site two.
And effectively, that's what makes it a stretch gateway that's available at
both sites. And we're going to the resources against supported at site one.
We're going to choose our edge cluster up there and at site two, we're going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're going to choose our edge cluster up there and at site two, we're going to
choose our edge cluster over there.
And then for route advertisements in the future, if we ever connect this to a
tier zero gateway, I want to advertise my route. So I'm going to go ahead and
enable that right now. So don't forget later.
And then we'll click on safe. And there is our new here one gateway. So if we
went over and looked at the local NSX manager at site one or site two, in fact,
let's go over to site two for a moment.
So here at site two, I'm using dark mode. So if we click on system, just to
confirm where the right device. So if I click on appliances right here, we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
confirm where the right device. So if I click on appliances right here, we're
at site two, which is the virtual IP address of dot 14 and the virtual IP
address.
And here's a site two, if we click on location manager, it's showing us that we
're synced up with the global manager. And here's the details for that global
manager. If we scroll down here, it has a list of remote locations, which from
site two's perspective is site one.
And here is site two, if we went to networking, and then on the left, if we
clicked on tier one gateways, check it out. There's our tier one stretch
gateway that was just configured at the global manager. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we have similar results over at site one at the local manager there, you
would also see this tier one stretched tier one gateway. However, if we go to
segments here, we don't have any common stretch segments yet. And that's
because we haven't created one yet over at the global manager.
So let's go back to the global manager. And let's create a stretched segment
that both site one and site two can use. So back at the global manager will go
to the networking tab.
And on the left, we'll click on segments currently is showing us the segments
available at site one and site two. And what we want to do is create a stretch WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
available at site one and site two. And what we want to do is create a stretch
segment. So we'll click here add segment.
So we'll call this seg 50 stretched and as far as the connected gateway, we're
going to connect that to the stretched gateway, which is right here T one
stretched. And now that it's connected, or will be once we click on save to
that tier one stretch tier one gateway.
So as site one and site two already have that stretch gateway, they are also
going to have this segment available to them. So over here in locations is
showing site one and site two with their default over the transport zones WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
selected one in each of the two sites.
And before we leave this let's also put in a default gateway address and let's
use 10.50.0.1 with a slash 24. Now currently the tier one gateway that is
connected to the segment isn't connected to the outside world or to a tier zero
gateway.
So we're going to have some limited connectivity until we flesh it all out.
However, for the meantime, we can still use this seg 50 stretch segment,
because it'll be available at both sites.
So we'll scroll down and click on save. All right, it's been successfully WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll scroll down and click on save. All right, it's been successfully
created. Do we want to continue. I'll say, no, that's enough for now for the
demo.
So next let's go to site one and site two to the vSphere client will connect
some VMs to that respective shared segment and then verify they can communicate
with each other.
Now currently over here under subnets, it's not showing as a hyperlink because
I don't currently have D H P services. So we'll manually set up our IP
addresses on the two VMs.
And for more details on setting up options for D H P, please check out the
skill on D H P services. But for now for this demo, we'll just do manual WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
skill on D H P services. But for now for this demo, we'll just do manual
configuration of our two VMs.
So for the game plan, let's use a little VM called tiny VM a that's running on
ESXi host a over here at site one will connect it to the segment, give it this
IP address.
Then over at site two, we'll use a little VM called tiny VM Y, which is running
on host Y over here at site two will also connect it to the same common segment
, which is the stretch segment being provided by the NSX federation.
And we'll use this IP address right here and then we'll test connectivity back
and forth. So here is the site one vSphere client and let me go ahead and grab WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and forth. So here is the site one vSphere client and let me go ahead and grab
a little VM that we can play with.
Let's take a look at ESXi a and see what VMs are over there. And I've got this
little VM here. I'm going to rename that. So right click and rename it.
And we'll call it tiny VM a and I'm also going to add site dash one just for gr
ins and click on OK. So now that that VM is renamed, let's also go ahead and put
on the correct segment.
So let's also verify that segment exists. So here's the segment that was
created as part of our NSX federation called SEG 50 stretched.
And let's go grab that VM, which is right there. We'll right click edit WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's go grab that VM, which is right there. We'll right click edit
settings and we'll place its network interface card on that new stretch segment
.
So we'll scroll down and there it is right there. We'll connect it and click on
OK. And we'll click on OK one more time.
So just to confirm, we'll put into the network tab here in the vSphere client
and went down to the segment 50 stretched and clicked on VMs.
So go ahead and right click and we'll power that guy on. And I'll also open up
a remote console over to it, which we'll use here in a moment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right. So for site one, we now have a VM connected to that segment. Let's
go do the similar treatment over at site two.
So over here at site two in dark mode to help differentiate it. Let's go find a
VM. So let's go to our host ESXY and click on the VMs tab.
And there's a little tiny VM there. Let me rename it to match our plan. So I'll
right click from the drop down, click on rename.
And I'll read in that tiny VM Y meaning it's running on host Y at site two and
click on OK.
Let's also modify the details for that and put it on that common stretch WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's also modify the details for that and put it on that common stretch
segment of segment 50. So we'll right click on the tiny VM, click on edit
settings.
And then for its network adapter, let's go ahead and click on browse. And then
we'll select that network segment right here, SEG 50 stretched and click on OK.
Then we'll click on OK again. Then we'll power it on. So I'll click on power on
. And let's also open a remote console to that VM as well.
So let me bring those guys in. So there's the remote console for tiny VM A that
's running on host A over here at site one. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let me bring in the one for the VM running over here at site two, which is
running on host Y. And let me make the screen a little bit bigger.
So for the machine here at the left, I have config and specify the IP address
of 1050 011 with the 24 bit mask for ethernet zero.
So there's the IP address right there based on our plan 1050 011. And let's do
a similar treatment over here for the VM at the right.
And this is the VM over at site two and for its IP address, it's going to end
in dot 22. So we'll do an I have config to specify the IP address, then we'll WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in dot 22. So we'll do an I have config to specify the IP address, then we'll
do an I have config for ethernet zero just to verify its IP address.
And that looks good. So the IP address is involved or on the VM at site one. We
have the IP address of 1050 011 connected to that common segment.
And at site two, we have this little VM, which is running ESX i host Y with the
IP address of 1050 022. So for that traffic flow, the traffic we go from the
host that's hosting that VM, it'd be forwarded over to the edge node that would
use its remote WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
address, send it over the tunnel, the genieve tunnel from the edge node at site
one over to an edge node at site two, who in D encapsulate that forwarded to
the host that's supporting this VM here on the right, who would then deliver it
to that client.
So let's verify that that ping works here between the two VMs. So starting off
on the left hand side, let's do a ping over to 10 dot 50 dot 0 dot 22. And that
is the virtual machine over at site two will press enter.
And that is flying. So all of that traffic is being tunneled from the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that is flying. So all of that traffic is being tunneled from the
respective host A here that the tiny VM is running on is being tunnel over to
the local edge node who's using the R.
Tap to send her to the remote edge node at site two. And then that edge notice
site two is doing a tunnel over to host Y who then receives that traffic then
forwards it to the VM on the right.
And the cool thing is we can verify that all with trace flow from the global
manager. So here at the global manager. If we click on the plan and troublesh
oot, we have here as well the option of using trace flow. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
oot, we have here as well the option of using trace flow.
So here for trace flow, we're going to use ICMP by default, we can change that
if we need to. I see people work great for this test. And then for the source,
let's go ahead and use a virtual machine.
And then it's asking us to specify the location. So we'll start from site one
and then select a VM from that location. Let's go ahead and grab the tiny VMA
site one.
And it's also showing us confirming for us the IP address that we have there.
And then for the destination, we'll go ahead and select the location of site
two.
And then with insight to will choose the VM of tiny VM Y at site two. It's also WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then with insight to will choose the VM of tiny VM Y at site two. It's also
confirming for us here. The IP addresses involved fantastic.
And then we'll scroll down and click on trace. So that's going to actually
inject the literal traffic, the ICMP traffic and then verify hop by hop by hop.
All the paths it's going through and whether or not that traffic actually makes
it. Now we know from the ping we just did that the traffic actually succeeds.
It's not being dropped by a firewall.
So trace flow is a nice visual representation of exactly which edge nodes were
involved and which taps and for intersite communications, which are taps were WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
involved and which taps and for intersite communications, which are taps were
being used. So here's the diagram, we make that full screen and make that a
little bit bigger.
So this represents the flow of the traffic from the tiny VM at site one. That's
going over our stretch segment, the segment 50 going down to the tiny VM at
site two. If we go ahead and collapse that, we can also take a look here at the
play by play,
which starts at site one at ESXIA and make that a little bit bigger, who
logically processed the distributed firewall rules that all passed, and then it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
logically processed the distributed firewall rules that all passed, and then it
handed it over to the edge nodes. And over here on the left, we have the
physical hop count, which represents every time it was sent over a network.
So we have the tunnel from ESXIA going to edge one using the tunnel endpoint
addresses for that forwarding, then edge one is logical routing and processing.
If we scroll down that continues. And then right here, we have it being
forwarded from edge one over to lab to edge one, and also over here in the
physical hop count is showing us how it's actually going over a transport
network.
So there are the remote tunnel endpoint addresses involved right here on the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So there are the remote tunnel endpoint addresses involved right here on the
right. And if he's scroll down, then lab two is doing its work of logical
processing that packet flow until it decided, Oh, you know what, I need to
forward this over to ESXIA that host at this point edge one use the local
tunnel endpoint address of 77, etc.
So we have the local endpoint address on host ESXIA, which is 66, etc. So ESXIA
received that. It did the logical processing as well, distributed firewall
rules, and finally that traffic was delivered as shown right here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
rules, and finally that traffic was delivered as shown right here.
And as the last piece, let's also create a simple distributed firewall rule
that would prevent that traffic from happening. So since we're sitting at the N
SS global manager, let's go ahead and click on security.
And after we'll click on distributed firewall, and let's simply create a policy
and a rule that denies that traffic. So we'll click on add policy. I'll
collapse the left hand side gives a little more room.
Let's call this our global policy will add a rule and we'll deny ICMP. And for
more details on the nitty gritty regarding distributed firewalls and their
policies and rules, feel free to check out our separate skill just on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
policies and rules, feel free to check out our separate skill just on
distributed firewall.
However, for now, I just want to go ahead and demonstrate how we can use this
at the global level to also implement policy. So we'll say deny ICMP. And I'm
going to go ahead and specify for the source. Again, we could use group
membership for this, but I'm going to go ahead and just put addresses in.
I'm going to say any traffic from 10.50 anything. So that'd be 1050 zero zero
with a 16 bit mask for the source, click on apply. And for the destination, we
could also specify the destination of 1050 anything. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But if we do a source, all of our traffic on that segment is going to be
sourced from that IP address. That'll be enough. And this is going to be
applied to the distributed firewall.
And the default action is allow. Let's go ahead and change that to drop. And
before we publish that and push it out, let's just test our ping one more time.
So here's our tiny little VM over at site one. I'll do that ping over to the
remote site VM at 1050 zero 22. Now what we'll do is this is go ahead and
publish this rule. This distributed firewall rule.
So we'll click on publish. Let's bring back that VM and it is going to stop in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll click on publish. Let's bring back that VM and it is going to stop in
its track. So it's no longer sending traffic because it's being dropped.
We can also verify that with trace flow go back to plan and troubleshoot. And
we simply do the same exact retrace again and proceed with that. That'll help
us to confirm that is the actual distributed firewall that we just deployed
that is preventing that traffic from flowing.
And so here in the output is showing us right there that is being dropped. So
he's six. I a right here is dropping that traffic. So if we go back to security
and I just realized that I that I call that rule. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and I just realized that I that I call that rule.
I see in P when we're really doing is we're denying anything sourced from 10
anything. So here in our policy, I should have named that deny. For example,
source traffic coming from 1050 because I didn't specify any services here.
So they go ahead and disable this rule and publish it out and let's bring back
our client. So now at our client, that ping is now picking up. So it missed a
whole bunch more than 100 as we had it blocked for a while. But now it's pe
aking once again.
Also to tidy this up a little bit, I'm going to go ahead and edit the services WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Also to tidy this up a little bit, I'm going to go ahead and edit the services
column. And here I'm going to search for ICMP and press enter and specify one
of match on ICMP and click on apply.
And that way, once this is applied, it'll be traffic source from 1050 anything.
And if it's ICMP at that point, it'll be dropped if we have this enforced. So I
'll go ahead. I'm going to leave it disabled, but I'm going to publish this.
And that way I'll have that new rule in place if I ever want to enable it and
it'll be correctly named of deny ICMP because that's now really what we're
doing again for a deeper dive on setting up and testing distributive firewalls. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
doing again for a deeper dive on setting up and testing distributive firewalls.
Please check out our separate skill, which is dedicated to the distributed
firewall. So if we reflect back on our game plan here, we've now implemented
and verified site to site communications by leveraging NSX Federation with a
global manager in charge of these two sites and a stretch gateway and stretch
segment.
That's now available to the vSphere client and its VMs in each of the sites.