All right, what we're going to do for the challenge is we are going to walk
through
this topology and we're going to look at each one of the circled numbers and
answer some
questions around them.
So you can pause the video and maybe try to figure it out yourself.
However, it probably makes sense for us to pause at each increment to make sure
that we
understand what is being asked of us since there's a lot of question marks out
there.
So let's start with this area over here.
The certificate authority, the CA is going to send a bunch of things back and
forth with
the controller objects.
So pause the video for a moment, make sure you understand or can answer the
question
of what is being sent at each one of these numbers, one, two and three.
So remember, the first thing the CA is going to do is provide for us a root
certificate.
And we're going to have to make sure that that gets onto the controller devices
.
The controller devices then create a certificate signing request or a CSR and
the CA is going
to be able to then create a signed cert.
And so that is the end goal, as we recall, is to get a signed certificate added
to the
controllers.
Next number is four and five here.
Let's make sure we know which VPN ID is which given the network topology over
here.
So when we're looking at the VPN up at the top, we see we're connecting to the
management
network.
And that's going to be VPN 512.
Meanwhile, we also need the data path enabled, which is the controllers
reaching out across
the underlay.
Very important that we recognize it's the underlay, not the overlay.
They can't be part of the overlay because that would really be a chicken and
egg problem.
And so they're going to have to use the underlay to help build the overlay.
That is going to be VPN zero VPN zero is always associated with our underlay
network.
Now lastly, we come to an interesting conversation here with number six, which
one of these devices
of well, which ones of these are going to require a public IP address in this
scenario?
Go and take a moment think through the topology and make that decision.
Well the answer here is going to be only the validator.
The controller doesn't require a public IP, the manager doesn't require a
public IP address.
Now remember what we've said, these devices have to reach out across the under
lay and be
able to communicate back and forth with these edge devices before the IP sec
tunnels are
established.
That's why we're running on VPN zero.
Now yes, if this was the internet, not MPLS, if this was truly the public
internet, then
we would require public IP addresses because they'd be using the public
internet in order
to get to these controller devices.
Now they could absolutely go through that, that would be fine.
In order to get there, they could have a private IP address internally and a
public IP address
on the internet and all of that would work if it was an internet circuit.
But we said it's an MPLS circuit and MPLS has the ability to carry private IP
addresses.
Now remember we've talked about maybe getting away from advertising routes into
the MPLS
space.
However, in this case we might need to advertise this network into MPLS.
Maybe it's the 10 dot 100 dot zero dot zero slash 24 network something along
those lines
that can advertise that into MPLS.
And at this point I can pass those routes down or simply allow these devices to
use a default
route to forward upstream, whatever that makes sense for in our environment.
But ultimately I can get away with these using private IP addresses in that
scenario.
So hopefully this allowed us to sort of think through how we build this out
from a networking
perspective, from a security perspective, making sure we know which VPNs are
which ones,
how the certificate process goes as well as when public IP addresses are
required,
keeping in mind validators always need a public IP address available.
But controllers and managers don't necessarily need them if the network is
properly configured.
I hope this has been informative for you and I'd like to thank you for viewing.