Alright, here for our game plan, let's do the following.
Let's first of all create a brand new transport zone.
Now as a reminder, transport zone says how far a segment can go.
So if we have for example, three hosts here and two more hosts here.
If we want a segment that goes no further than these three hosts, we can go
ahead and
create a transport zone.
It's called TZ1.
And then when we create the segment, we'll put that segment in TZ1.
And that's as far as that segment will go.
So down here, if we have two different hosts and they are supporting some WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So down here, if we have two different hosts and they are supporting some
different segments,
say TZ2, then when we create a new segment and we include it in the transport
zone, TZ2,
it'll only go as far as those two ESXI hosts.
So think of the transport zone as a way of controlling how far a specific
segment that's
included as part of that zone can go.
So currently we have an overlay transport zone that's including ESXIA and ESXIB
.
And when we create a transport zone, it can be one of two types.
It can be overlay or it can be VLANBAC.
And because we need a VLAN segment that we're going to use right here to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And because we need a VLAN segment that we're going to use right here to
represent this
network between the NSX environment and the physical network, we're going to
create a
transport zone, which is type VLAN.
And that way we could also go ahead and create a new VLANBAC segment.
So I'll put a little arrow here for the new transport zone.
It'll be VLANBAC and then we'll create the new VLANBAC segment and we'll make
sure it's
included as part of that zone.
We'd also want to make sure that the transport nodes that need to support that
segment are
currently associated with it as well.
So let's also put a step here saying let's include our edge nodes, which are WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's also put a step here saying let's include our edge nodes, which are
edge one
and edge two, to make sure they support that transport zone.
Now our ESXI hosts transport nodes, they don't really need to be included or
support this
specific VLANBAC segment up here because it's only the edge nodes that are
going to
provide that connectivity from the NSX environment over to the physical
environment.
We even like the device that's really moving the traffic physically over to
that network.
And that's going to be one of our edge nodes.
So we could include these two ESXI hosts as part of the new VLANBAC transport WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we could include these two ESXI hosts as part of the new VLANBAC transport
zone, but
there's no need to because these two hosts are not doing the actual work of
bridging that
traffic over to the physical network.
So as far as the name for that new VLANBAC segment, that's going to represent
this network
right here.
Let's name it EXTSAG 192 because in my network, in my home office here, this is
the network
segment that I want to use for the connectivity between my NSX environment and
the physical
network.
And this also happens to be VLAN0.
So it could be like VLAN20 or VLAN30 or VLAN40. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it could be like VLAN20 or VLAN30 or VLAN40.
It doesn't have to be without any kind of VLAN tag.
However, in my network, currently that 192 network is also my management
network.
And on that segment 192, I've got a gateway there.
It happens to be a firewall, but it's a physical device with an IP address of .
1 on the 192.168.1
network.
We're going to create a new VLANBAC segment.
We'll go ahead and call it external segment 192.
And I'm also going to specify what it asked me for what VLAN this segment is
going to
support.
I'm going to go ahead and say VLAN0. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm going to go ahead and say VLAN0.
Although again, it could be VLAN10 or 20 or whatever that VLAN happened to be
on the
physical network.
And the moment we take this tier zero gateway and we say, "Hey dear Mr. Tier
zero gateway,
we want to create some additional interfaces that connect to this segment."
It's at that moment when we save that config that it adds the SR component, the
services
router component to tier zero.
So effectively, we're going to have two logical entities for tier zero.
One's going to be the DR, that's the distributed router function, the other's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
One's going to be the DR, that's the distributed router function, the other's
going to be the
services router, which is going to be providing the connectivity for us.
It's also a services router that would be used if we were doing NAT or VPN or
other IP
services.
So we're going to have a connection that's automatically built between the tier
zero DR
and the tier zero SR.
Think of them like two logical friends that are in the same building.
And then for the connectivity between them, they'll be using some IP addressing
scheme
starting with 169.
And so maybe this is going to be .1 and maybe this is .2.
We'll take a look at when we deploy it, what actual IP addresses they use. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'll take a look at when we deploy it, what actual IP addresses they use.
And then as the services router and its interface here, this providing the
logical connectivity
to this external segment 192.
And up here on my VLAN zero up here, my network address space is 192, 168, 1.0
with a 24-bit
mask.
Now to facilitate this new services router and the connectivity, all we're
going to do
is we're going to go to our tier zero router and we're going to say, you know
what?
We want to create some new interfaces.
So for new interfaces, we can say, you know what?
I want to go ahead and connect to this segment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I want to go ahead and connect to this segment.
And when we do so, it'll say, okay, when you want to connect to this segment,
that's
going to require an edge.
Which edge do you want to use?
So maybe we create the first interface at 61, that'd be 192.168.1.61.
And we say, we want to use edge one for that.
And then for fault tolerance, if we're doing active active or even active
standby, we can
say, you know what?
We want a second interface and we're going to use .62 on the 192.168.1 network.
And for that second interface, we want to use edge two.
And that way we have some fault tolerance with two separate edge transport
nodes that
can both, at the end of the day, provide that connectivity for us. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
can both, at the end of the day, provide that connectivity for us.
And again, as the edge transport nodes, they're going to have a copy of that
services router
function.
So they know exactly how to forward and how to route based on that services
router.
We can also on our tier zero gateway, create a virtual IP address to represent
our logical
connection over to the 192.168.1 network.
So even though we're using .61 with the edge one and .62 at the edge two, we
can also
set up a virtual IP address and let's use 60. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
set up a virtual IP address and let's use 60.
So in my topology here, those three IP addresses are not currently used.
So those are safe to use here on my 192.168.1 network.
And last but not least, we're going to need some basic routing in place so we
can actually
forward traffic.
So in the event that all this is set up and this VM wants to go ahead and let's
just
say we want to reach this IP address of 192.168.1.1, which is a physical device
on the network
here, that traffic as it goes into this segment on ESXIA because it's a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here, that traffic as it goes into this segment on ESXIA because it's a
transport node.
It would do all the logical lookups here and here, including the fact that this
is the
next top address of .2.
It would then identify what segment is that on and who owns the MAC address
associated
with that .2 address.
And as a result, it would then build a tunnel and forward the traffic over to
the edge device
who's supporting that layer to address.
At which point the edge device would receive the traffic, logically make the
routing decision
on behalf of the services router and then go ahead and forward it.
If it was destined, for example, to .1, forward it to the physical network so WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If it was destined, for example, to .1, forward it to the physical network so
that .1 would
receive that.
Now if VM1 wanted a response, this device here would also need to know, hey, to
get back
to the 10100 network, you need to forward it back to the next top of the tier 0
router.
So if we set up an IP address of .60 up here, we could go ahead and set up a
static route
on this physical route.
It says, hey, you know what?
To get to the 10100 network, please go ahead and forward it to the next top of
.60 on the
.921681 network, which is logically being supported by the tier 0 gateway. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
.921681 network, which is logically being supported by the tier 0 gateway.
So it could receive the packet and then continue with its routing down back to
segment 10,
which is supporting the 10100 network.
So we're going to have some additional skills on routing options, including BGP
and OSPF.
However, for now and for this skill from a routing perspective, let's just go
ahead
and let's train this device here on the physical network that to get to the 10
100 network,
it should forward it down to 192.1681.60.
And that way we can verify the connectivity between this VM, VM1 and the IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that way we can verify the connectivity between this VM, VM1 and the IP
address of
.1 on the physical network and also get a response back because this device
here on the
top knows how to forward the traffic back.