Well, we've been configuring our environment in Cisco modeling labs, and we've
been largely
using a very manual process to bring our edges online.
Manual meaning that we're creating those initial configurations, those cloud
init scripts,
that effectively emulates us using bootstrap configuration, which we can do in
the real
world.
This is going to be very important for us if we want to perform the bootstrap
operation,
which is relying on that more manual approach.
But in a perfect world, especially in real world deployments, we're instead
going to
want to use either zero touch provisioning or Cisco's plug and play connect
portal.
And we have spent a little bit of time in the plug and play connect portal, but
we did
so in order to create those bootstrap configurations, which is useful, but
wouldn't it be better
if it all just came up without us having to create those bootstraps and deploy
them to
our devices in some form or another.
So what is the difference between ZTP and PNP?
Well, the difference is to do with which types of devices that we're bringing
online.
Specifically, ZTP was a Viptela solution.
Remember Viptela is the solution that Cisco purchased.
They were their own company, and they did have their own hardware.
And so those V edges that often get cited, anything starting with this little V
has to
do with Viptela.
That's where the V comes from.
And so zero touch provisioning is a V edge that wants to reach out to an
automatic provisioning
server.
And it's going to download its configuration that's built out in that
environment.
And specifically, it's going to go out to ztp.viptela.com.
So again, this is truly a Viptela solution.
And Cisco does not integrate with ZTP when we're talking about sea edges.
So the big difference here is simply are we using V edges or are we using sea
edges where
the little C stands for Cisco.
Now again, in the current iteration of our SD-WAN architecture, Cisco has
gotten rid
of V edge and sea edge sort of in the same way they've gotten rid of V bond and
V smart
and V manage.
And yet we can expect to see all of these terms thrown around, whether it's in
CLI commands
or in logging information.
And it just pointed to depend on what we're looking at and what we're reading
and potentially
which exams have been written at which times which terms are we going to end up
using.
So we need to be familiar and comfortable with all of these terminologies.
And it does get a little bit cumbersome at times.
But keep in mind that again, we're using not sea edge, but an SD-WAN edge term
for our
edge devices these days.
So either way, we're not talking about a V edge.
The V edge was dedicated hardware created by Viptela.
And yes, when Cisco acquired Viptela before they had an opportunity to
integrate their
own routing hardware, which Cisco was pretty good at creating routing hardware.
They probably didn't want to use Viptela's routers, but they had to for a
little while.
And so not only do we see Viptela deployments, which are getting pretty old at
this point,
but Viptela deployments built on V edges.
But we also see early Cisco deployments built on V edges as well.
And even though they're not sold these days, if we are deploying a V edge,
maybe a used
one that's off the shelf or somehow we acquired one, if we're configuring a
true V edge, we're
going to be using ZTP.
And we're going to see that our devices are trying to resolve the ZTP dot Vipt
ela dot
com.
But that's not true with a C edge or a modern SD-WAN edge type of deployment.
Instead, we're going to use the plug and play connect portal.
And we might think, well, okay, maybe the URL is PNP dot something dot
something.
It's actually not.
It is this URL device helper dot Cisco dot com.
And this is not just used for SD-WAN devices.
This is used for all kinds of different Cisco devices that are taking advantage
of plug
and play.
The whole plug and play portal that Cisco created again, it was there before SD
-WAN and
it's there for a lot of other types of solutions.
So yes, our C edges and our SD-WAN edges are taking advantage of it alongside
plenty of
other types of devices.
And as a result, they're going to need access to this specific URL.
So what exactly happens when we want to take advantage of these services?
Well, once again, I have some form of an edge device, the edge, the edge, SD-W
AN edge, whatever
we want to call it at this point.
And this device is going to need connection to the internet.
The internet is where these services live.
So whether we're going to the DTP dot Viptela dot com, or we're going to Cisco
's device
helper.
I'll just abbreviate it here, device helper.
But either way, regardless of which one we're going out to, we clearly need
internet access.
And so we need the ability to first and foremost get power on this device so it
can turn on.
And clearly, it's going to need some kind of network connectivity.
But as long as we can get somebody on site who can plug it in and connect it to
an appropriate
internet circuit, then this device is capable of reaching out to one of these
two services
and downloading its configuration.
The difference between this process and the process that we used is simply
whether that
configuration is coming from the internet or whether it's coming from the boot
strap.
And neither one of these is wrong and versus right, we can use either method.
But naturally, this is a much more automated method to use ZTP or PNP.
But in the end, the concept is the same.
It's going to be able to go out and find the V bond that exists or the valid
ator.
And the way it's able to do that is by grabbing the configuration via one of
these two methods.
Now I just mentioned something that maybe gave us a little bit of hesitation,
which is this
right here, we need somebody who's probably not technical to get onto a device,
not get
onto a device, they're not going to configure it, but they're going to take
this device
that hasn't been configured and they're going to connect an internet circuit to
it.
Does that seem a little bit insecure because that is something that is top of
mind for
Cisco and before them, Viptela, as far as making sure that these edge devices
are properly
hardened, which is a phrase we use in the security world to say that it is
locked down
from a security perspective.
So if we think about it, we need to be able to get out to these websites out
here.
As a result, we're going to need an IP address.
And so we have some specific services that are going to be required in order to
make
this conversation happen.
Otherwise we want to make sure that nothing else is allowed on this edge
interface that's
connected to the internet.
We don't want to connect our SD-WAN edge to the internet and then maybe it
takes a few
days for it to download the config because we weren't ready for it to come
online.
And meanwhile, all kinds of threat actors are out here on the internet and they
happen
to be running their ping tests and they find it and they're able to log in and
compromise
the device before we even download configuration.
That would be a non-starter of a conversation.
We need this device locked down before we get a configuration on it.
And so again, this was top of mind with Viptela when they designed this
solution and Cisco
continues to deploy a very secure solution here.
So let's explore what exactly happens when we have an edge device here and we
want to
bring a connection online here that is connecting to the internet.
First of all, we're going to need to explore the concept of this interface
being known
as a tunnel interface.
The idea of a tunnel interface is when we configure it to allow tunnels to form
and more
or less to block everything else.
That is the goal.
Now, we can't quite do this when it first turns on, but for the most part, this
is what
we're trying to accomplish because even when we get to steady state operation,
we're forming
data plane tunnels that are going out to the rest of the edge devices, well, at
that
point, we still maintain this internet connection.
And if we're maintaining an internet connection, then we need to make sure that
we're secure
as possible.
And so this is why the concept of tunnel interface exists.
We're going to see this command show up at the CLI and in various parts of the
graphical
user interface configuration as well.
But this is a very important concept for us to understand, which is that this
is sort
of an auto security type of function.
If I configure tunnel interface on an interface, which should be going on to
all of our wide
area network types of connections are transport interfaces to use Cisco's
terminology for
SD-WAN.
We have the transport side and we have the service side over here, which is
going to
connect to our local area network.
Well, this interface, which faces our transport, that is going to need to be a
tunnel interface.
And that's going to, again, allow for the tunnels to form, but it's not going
to allow
any other communications in, which means that if there's a threat actor out
here trying
to break into this interface, we don't need to worry about configuring a bunch
of extra
security because the tunnel interface handles a lot of that for us.
It's going to get blocked because it's not part of one of the tunnels, which
requires
a whole lot of authentication and authorization in order to form those tunnels
to begin with.
And so it automatically, again, creates a little bit of security for us.
Now that's pretty cool, except we just said that some of this information up
here and
some of these communications are going to need to happen outside of tunnels.
Otherwise, we have a chicken and egg problem.
How do we form tunnels out to these different locations if we don't have the
information
to form the tunnels?
Well, we've got to get the information first and that's going to require us to
have certain
services that are allowed through the tunnel interface.
And so this is going to bring us to this command that we'll see at the CLI,
which is
known as the allow service command.
The allow service is going to allow other non-tunnel traffic to come into a
tunnel interface.
Remember, the tunnel interface command is intended to block everything else
with this
slight exception of things that are explicitly allowed.
So I can explicitly allow certain services to come into this interface.
So what kind of services should we be allowing?
Well, the good news is that there are a few of these enabled by default to
enable this
automated process to happen.
And we can kind of think through a few of these, which are logical and a few
that we
might not think about.
So specifically, we're going to need DHCP to be allowed.
We're also going to need DNS to be allowed.
DHCP gets me the IP address, which does mean that my internet service provider
must be
providing me with an IP address via DHCP.
If I'm using static addressing, this isn't going to work.
So I need a DHCP address.
Otherwise, I'd have to manually configure the static address and then we're
right back
to using the bootstrap.
So DHCP DNS is also important because we have to be able to go out and resolve
these
URLs.
If we don't resolve them or we can't resolve them because of DNS issues, then
we're not
going to be able to automate anything either.
So those two make sense.
But then we also have a couple others that we might not fully expect.
First of all, ICMP.
This as much as anything is going to allow us to check to see if this device is
online.
So if our service provider is telling us, "Hey, here's your IP address.
It's not coming online."
"Hey, we'd like to be able to ping it to make sure that it is responsive."
And so we do have ICMP enabled.
And then this is the interesting one.
HTTPS is also allowed.
Why is that allowed?
Well, because we're going to use HTTPS in order to download some of this
information.
I say we, but this is really a conversation between our edge device and our
upstream automated
platforms.
So these four services are absolutely required.
And the good news is that they are enabled by default.
But if any of them are disabled because we got onto the device and we added
some configuration
or we bootstrap the config and we disabled some of these services, we're going
to have
some problems.
So we need to make sure that we understand that these are going to be required.
Now we do have a few optional configurations that we can consider as well.
We could consider deploying, for example, NetConf.
Or that's going to be used to onboard to manager, but it's not something that
we need
before the tunnels are formed.
Then we're also going to possibly want to enable SSH and in Linux terms, that's
a demon.
And so, or demon, however we want to say it.
And so if I want to be able to SSH into this device remotely, then I might want
to enable
this as well.
And then we also could consider enabling NTP, depending on whether we want that
to come
through the transport side or the service side.
And so these are optional.
Maybe I want to configure them and maybe I don't.
Just keep in mind, this is usually a conversation once the device is already
online, because
once it's online, we can already use all of these through the tunnels.
The question is whether we want these to exist outside of the tunnels.
Again, do we want to explicitly allow this traffic to show up on a tunnel
interface?
Now, also worth noting that we do have one catch all option.
Truly the word all here.
We have to be very careful about this, but this would be for an internal or
trusted link
only.
So I could just enable all services on an interface.
If I fully trust that interface, maybe that's a lab environment, or maybe it's
just that
I've got a dark fiber connection that it's using back to my headquarters.
At that point, I could probably just enable all of these services to be allowed
outside
of tunnel interfaces.
But that's just it.
We want to make sure that we understand here that when we're talking about, let
's draw
this one more time here, when we're talking about this interface right here,
remember
that this interface is creating tunnels.
So here's just an example tunnel.
We're going to allow all kinds of communication into and out of this tunnel.
The question is what traffic can show up outside the tunnel that will allow.
So when we look at Netcom, for example, I said that, well, that's how managers
going
to be managing this device.
Well, why is it optional?
Because this is outside the tunnel.
And normally we're going to be sending Netcom in and out of the tunnel
interface, the tunnel
that's formed to VManage or Manager.
And so if we wanted to exist outside, then we can enable it.
But for the most part, we're going to need that in a production environment
because Netcom
will travel in and out of the tunnel.
And that's true with all of these optional services as well.
And this will hopefully also makes it a little more clear why we need to make
sure these other
services are allowed outside of tunnels because we probably need those to get
the tunnels online.
So coming out of this conversation, let's make sure that we understand exactly
what this
automated process looks like, as well as the URLs that we're trying to reach
out to.
And importantly, the services that must be allowed in order for those to work,
as well
as how well this ties to the concept of the tunnel interface, which
automatically deploy
some amount of security that we usually take advantage of.
But sometimes we might want to work around in order for us to properly service
the device
and troubleshoot it in real world situations.