So, now that you've had a few minutes to consider this topology and consider
why, for example,
a VM here couldn't connect to or get a ping response from this external gateway
at 10 to
220.0.1, let's talk about a few potential problems.
Number one, at this device right here, maybe they're not allowing via the
device itself.
Maybe they've configured it to not be able to respond or not being willing to
respond
to a ping request.
So, if this customer down here is trying to ping that IP address, maybe locally
here
at this router, it's configured to not respond to a ping. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
at this router, it's configured to not respond to a ping.
So, that is definitely a possibility.
So, as far as testing that, we could also go ahead and do a ping, for example,
from
VM4 to the virtual IP address or to the edge IP address on that common 10 to
220.0 network
segment.
So, if the ping worked from here to the IP address on the segment that the
gateway owned, it
could be an indication this router has been configured to not respond to ping
requests.
However, another option could be that this router right here didn't get the
routing
information that it needs.
So, even though we configured BGP here, the customer did between the external WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So, even though we configured BGP here, the customer did between the external
router and
the tier zero gateway, maybe this tier zero gateway forgot to do a
redistribution of the
routes down here, the 1010 and the 1020 networks at tier one.
Perhaps it forgot to redistribute those into BGP and as a result, this external
router
has no clue from a routing perspective of how to route in the correct direction
to get
back down to the 1010 and the 1020 subnet.
Another problem could be that these VMs here don't have a correct default
gateway that
leads off to their respective tier one gateways.
So, if these IP addresses here on the segment 10, segment 20 are .1 on their WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So, if these IP addresses here on the segment 10, segment 20 are .1 on their
respective subnets
and the clients aren't using those as the correct default gateway, that could
cause
a problem.
So, if the redistribution was configured correctly here at the tier zero
gateway, perhaps these
tier one gateways were not configured to correctly advertise those subnets and
if they
don't advertise them, then the tier zero gateway has nothing to redistribute
into BGP.
So, that could also be another challenge.
So, as far as solutions that we could offer, one would be to verify the BGP
between the
router here and our tier zero gateway, just to verify that we have the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
router here and our tier zero gateway, just to verify that we have the
neighborhood, verify
that we're advertising the routes that we expect to be, make sure that we're
advertising
the routes from the tier one up to the tier zero and making sure that our
clients have
an appropriate and correct default gateway for their communications on the
network.
So, thanks for joining me in this set of videos and in the skill regarding
using border gateway
protocol as a dynamic routing protocol between our tier zero gateways in NSX
and the external
network and the external router that's also running BGP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
network and the external router that's also running BGP.
So, again, thanks for joining me and I'll see you in the next skill.
Until then, I hope this has been informative and I'd like to thank you for
viewing.
[BLANK_AUDIO]