Now logically, one might look at our topology and say,
"Well, this DR, if it needs to forward traffic to .1,"
it would just go ahead and forward out this interface.
But the reason I put additional space here
is there as a little stop along the way
that's going to be made,
and that is our services router function
on our tier zero gateway.
So I'm going to put that right here.
So this is our SR.
So all these are distributed router for gateway A,
distributed router for gateway zero,
and this is the services router for gateway zero.
And then we clean that up a little bit WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we clean that up a little bit
and add gateway zero here.
And this services router,
let's also document what its UUID is
and also the VRF that it's in.
So for these services router,
this row right here,
it is VRF4 and there is the UUID.
So we'll add that to our documentation.
So it begins with F5,
a whole bunch of characters,
and it ends with E5.
And on the edge one device that is in VRF number four.
And then we have some logical connectivity via IP,
between the gateway zero, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
between the gateway zero,
distributed router function,
and the gateway zero services router function,
which is actually going to do the actual connection
to the physical network.
So that's going to go like this.
Also, let's go ahead and document
the connectivity IP address involved
on this leg of our journey right here.
And we can look at the information
from the perspective of the DR on gateway zero
or from the SR on gateway zero.
Let's start off with the DR on gateway zero.
So that's VRF number one.
So we'll type in VRF1 press enter.
So now we're looking at the details for VRF1, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now we're looking at the details for VRF1,
let me make that a little bit bigger.
Again, that's our distributed router for our tier zero gateway.
So in VRF1, if we do a get forwarding,
I'll do a space question mark,
and let's look for 000/0 press enter.
So here's the default route that we just set up
a few moments ago.
And the next top is 192.168.1.1.
However, here on VRF1,
which is gateway zero, the DR,
if we do a get interfaces and press enter,
here are the interfaces associated with VRF1, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here are the interfaces associated with VRF1,
which is again our DR on gateway zero.
So if we scroll in here,
here's a logical interface between our tier zero DR
and down to, looks like gateway A.
And this confirms the IP addresses that we documented previously.
So on that link down to gateway A,
on this side, we're using 160 four zero dot zero
with a 31 bit mask.
And on the other side,
which was gateway A, it's using dot one.
And if we can need to scroll down,
here's another interface.
This is the one that goes down to gateway B
based on the name there. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
based on the name there.
And it's using locally 160 four zero two.
And on the other side,
gateway B would be using dot three on that common segment.
And if we scroll down,
here's the interface used for a multicast,
as we continue to scroll down.
Here is yet another fascinating interface.
And its name is BP for backplane DR,
distributed router port.
And here for the port type,
it says backplane.
And here it has an IP address of 169 two fifty four zero dot one.
So that IP address base of 169 two fifty four
is what's being used to communicate between the DR on gateway zero WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is what's being used to communicate between the DR on gateway zero
and the SR on gateway zero.
So I'm going to add that IP address to our documentation right now.
So I'm going to go ahead and label this as BP for backplane.
And the network is 169 two fifty four zero
with a 24 bit mask.
And we just saw here on gateway zero,
choosing the address of dot one.
And then over here, the services router,
it's very likely going to be a dot two.
We'll verify that here in a moment.
So here in this output,
we are currently looking at VRF one,
which is our distributed router on tier zero. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which is our distributed router on tier zero.
And as we got near the end of it,
this last one here is the backplane interface.
But check this out,
it's also showing us that same output.
This is again for VRF one,
that we have this associated VRF four and its set of interfaces.
And VRF four is our services router.
And if we scroll down,
our services router,
we have a backplane interface.
The name is BP SR zero port for services router zero.
And its IP address is 169 two fifty four zero dot two,
which confirms what we just jotted down in our topology. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which confirms what we just jotted down in our topology.
So the logical connectivity between the DR on gateway zero
and the SR on gateway zero is this logical subnet,
169 two forty four zero with the DR function using dot one
and the SR function using dot two.
And as we continue looking at VRF four here,
which is our services router,
we continue to scroll down.
Check it out.
Look what we have here is a 192 168 1.60 address.
And that is the virtual IP address that we assigned to the tier zero gateway.
And this IP address is actually owned by the services router. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this IP address is actually owned by the services router.
So for the connectivity to the 192 168 one address,
we would be using this logical interface,
the services router interface for that connectivity.
And so if we finished drawing our topology,
it would look like this on this 192 network,
we have the dot 60 right here.
And then we have the rest of my physical network with the physical router here
at dot one.
So in a packet from VM one enters host A host A with this distributed router is
going to do
most of the routing decisions.
And then at some point it's going to forward it over to edge one WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then at some point it's going to forward it over to edge one
who's providing the services router function to forward that packet onto the
physical network.
So I'm going to put in red here edge one.
So for the VM that's being hosted by ESXIA for as a packet,
the logical routing for gateway A is done by ESXIA.
The logical routing for the DR gateway zero is being done by ESXIA.
And then based on what we just saw,
when the gateway zero DR needs to forward the packet to the next hop of dot two
,
because gateway zero is logically connected to that segment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
because gateway zero is logically connected to that segment.
And by the way, we can verify the actual VNI for that segment.
Let's do that also right now.
So here on edge one, we'll exit a VRF configuration mode.
And let's go ahead and do a get segments.
Or if you want to use the older command of get logical switches,
that works too.
So here's the segment for segment 20.
Here's the segment for segment 10.
And we have our transit links that go between our tier one gateways and our
tier zero.
So this one is and this one is we have one for multicast.
And then we have this beautiful one right here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we have this beautiful one right here.
So that is VNI 67584.
So let's document that on our topology.
So for this segment 67584, that's the VNI number.
So ESXIA is logically connected to this segment 67584.
And now it needs to forward to the layer two address on that same segment.
Now that all the routing decisions are done,
needs to forward to the layer two address associated with this IP address 169,
254, zero dot two on this segment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
254, zero dot two on this segment.
And the control plane for NSX is going to let ESXIA know that,
hey, that MAC address associated with this is going to be reachable off of the
edge one VM
that's supporting that services router.
So from a tunnel perspective, ESXIA is going to forward traffic over the tunnel
over to the tunnel endpoint for edge one.
So ESXIA is 11, 11, 11, 11, 11.
And edge one is at 33 dot 33 dot 33 dot 33.
And then edge one would pick up on the work.
So edge one would receive that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So edge one would receive that.
It would do the logical routing for the traffic.
So let's assume the client PC was originally trying to go to 192.1 state one
dot one.
So edge one would do that logical route lookup and then forward it to that
segment,
which in our case is that VLAN back segment for where my 192.168.1 network is.
So if we capture the traffic right here, we would see traffic from 11, 11,
etc. to 33, 33, and inside the genieve header,
it would indicate is for VNI 6, 7, 5, 8, 4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it would indicate is for VNI 6, 7, 5, 8, 4.
And it would also identify the layer two address that we're trying to reach
for that next top address on the services router.
And again, then the services router would take a look at the IP header,
see what the destination is.
For example, 192.168.1 dot one, and then forward it appropriately based on its
routing table.
Now currently on this device, I set up a static route on this physical
appliance to say,
hey, if you ever need to reach the 1010 zero address space,
go ahead and forward it back to the next top of 192.168.1 dot 60. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
go ahead and forward it back to the next top of 192.168.1 dot 60.
So that routing from the external network, that part's already in place.
So what I like to do is let's just verify from this VM
that we really can indeed reach the 192.168.1 network
and specifically the dot one address here.
And then once we verify we have the connectivity,
let's go to trace flow. We'll verify it there.
We can also capture the trace flow and see what it looks like
as that traffic is going over the transport network.
So let me bring in a little console for this little VM right here.
And let's confirm its IP address with an IF config.
And that looks good as 1010 zero 10. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that looks good as 1010 zero 10.
And let's also do a route, verify its route.
So its default gateway is 1010 zero one,
which is our logical DR for gateway A.
And then the next top is the DR for gateway zero.
And let's just confirm from the perspective of ESXIA that gateway zero,
the DR believes that for its default route,
the next top is going to be 169.250.2.
So here at the NSX CLI for ESXIA host A, let's do a gate gateways.
And then for the DR gateway zero, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then for the DR gateway zero,
based on our documentation is the one that ends in bed.
That's this one right here. So I'll go ahead and copy that.
We'll do a get gateway space.
We'll plug in that UUID space and then we'll do a question mark.
And let's just look at the IPV4 else.
We'll specify IPV4 press enter.
It says that it's default route has a next top of 169.250.2,
which is the logical interface on the services router at tier zero.
It also indicates here from the routing table that is directly connected.
And this is the gateway zero DR being directly connected to the 169.2.4 network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this is the gateway zero DR being directly connected to the 169.2.4 network
.
And so ESXIA, as it needs to forward the traffic to that layer two address of
the next top there,
is going to leverage the NSX control plane to identify where that layer two
address lives.
So for ESXIA to forward on that segment to the layer two address associated
with 169.2.2,
which is the next top for the routing,
it would encapsulate the traffic forward over to edge one,
who had de-encapsulated, then continued the logical routing process. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
who had de-encapsulated, then continued the logical routing process.