Well, if we're going to configure our control policies,
then we're going to need to know how to put these together.
And as you might imagine, if we're looking at something like control policies,
a lot of those are going to be centralized, which require going through the vSmart,
and that's going to require something that's pretty scalable,
because we're going to push that out to the rest of the environment.
So when we do this, we're going to follow a specific framework,
and it's going to follow three primary steps.
The first step is to define a group of interest,
because we might want to apply a policy, let's say, to a particular site.
Well, that site might have multiple edges, or maybe we want to apply it to many sites.
That's just an example of a group of interest.
Then we need to actually create the policy.
So we're going to perform policy creation,
and this is going to have a little bit of a route map feel to it,
meaning that we're going to, in the end, get a bunch of those match and action statements.
So match a group of sites, or maybe a group of prefixes,
and then what is the action we're going to take?
Are we going to accept a set of routes, or a set of sites, or TLOCs, or what have you,
or are we going to reject those?
So that's the end goal here, is to get this applied.
And so the last thing we have to do is actually to apply it.
So we're going to have to activate a policy after we actually create it.
So this process is going to happen whether we're in the CLI or whether we're in the Graphical User Interface.
Now, when we're in the Graphical User Interface, this is going to be a very clear-cut process.
If we're doing this from a CLI perspective, then we might want to start with the Graphical User Interface,
do this first, see this process, and then in the end, when this gets pushed,
this actually gets pushed via CLI, which is kind of cool to see the actual command line interfaces
that are getting thrown out there, and then we can log into the CLI
and make sure we understand how that process looks.
After that, then we can go back and actually perform configurations via CLI.
Now also keep in mind, a lot of these control and therefore centralized policies are going to be on the controller,
so we might need to look at things from a controller perspective,
but some of them are going to apply to our edges as well.
So always keep that in mind as far as what devices are going to be receiving the policy.
But a lot of them are going to focus on us applying it to the list of controllers.
I was going to say a controller, but really it's going to be as many controllers as we have
because we need those to stay in sync.
So first up, we need to get our group of interests defined,
and the way we're going to do that is by using lists.
but at the same time it kind of does, and we have the concept of prefix lists, for example,
and access control lists, and the same concept applies.
We're really trying to identify traffic or identify information that we want to filter.
And so there's lots and lots of lists.
We have, for example, site lists.
We have TLOC lists.
We have prefix lists.
Yes, those do still exist here even in SD-WAN.
We can also create VPN lists and color lists and service level agreement or SLA lists
that we might want to tie into policy later on.
So the more of these lists that we have available in manager, the easier it is to create policies
When I get all the way into policy creation, realize I don't have my lists created properly,
and I have to go back.
This is if I'm performing configuration via the graphical user interface.
If I'm doing it via the CLI, then probably I'm going to have to do the same thing,
I need these lists created.
The interesting thing here is that I can create tons of lists,
and manager is going to store all of those lists, and it's configuration.
But when it pushes configuration out to the controller, let's say,
it's only going to push the necessary lists.
So I might create all of these lists, but I only ended up needing the site lists,
and maybe I only needed half of those.
So I'm going to push only the lists that are required.
So when I look at the CLI of the controller, I'm only going to see the required lists
that were needed for that policy.
So, for example, in our lab environment, we know that site 13 kind of is special.
It has a couple of edges there.
We could view it as maybe a hub.
We'll later turn it into a hub and spoke.
And so I might create a list that just has 13 in it.
And then I'll create another list that has 11 and 12 in that list.
And that's great, but what if I want to apply policy later to site 11?
Well, that's why it might help for me to create multiple lists here.
And so now I've got a list for every single site,
but I also have this joint site list that I could apply for other policies
where I want the same policy to be applied to it.
So it's just kind of one of those things that we need to think through
as we're creating our lists in a real-world environment.
So next up, we once again have the policy creation.
So we've got to create the policy itself.
As mentioned, we're going to have these match action statements.
And for the most part, when we're using the graphical user interface,
we're going to follow a template.
And that template is then going to form our match action statements for us.
But I can, in many cases, create a custom policy,
at which point I'm going to have to define the match action statements
a little more directly.
Now, as we already said, it's going to involve me applying
accept and reject actions to specific matches.
So the actions are accept and reject,
whereas the match is I'm matching one of my lists,
potentially multiple of my lists, depending on the situation.
So I'm targeting my group of interests,
and I'm applying a policy against them.
Importantly, I also have a default action at the bottom of any of my policies.
Usually, this default action is reject.
Remember, I'm modifying an environment
that is designed to accept everything.
I mean, I form tunnels from every edge to every edge.
I share routes from every edge to every edge.
I form as many tunnels as I can,
even between my different transport mechanisms.
So my default operation is to accept everything.
So when I apply a policy, that changes.
My default is now to reject everything,
which means I have to explicitly enable everything.
That's known as a whitelist model versus a blacklist model.
We're going to change from a blacklist model,
basically saying allow everything unless otherwise specified.
Well, now we're going to make it so that we have to specify things.
But again, I can decide what I want the default action to be,
especially if I'm using a custom policy.
Lastly, I'm going to need to perform my activation.
So creating the policy just stores it in manager for me.
or potentially to the edges depending on the situation,
then I'm going to have to activate this.
In a lot of situations, I'm going to need to make sure
I'm activating it in the correct direction.
So I'm going to have to specify it in the inbound direction
or the outbound direction.
Now again, if I'm using a template,
usually it's going to figure this out for me.
So when it provides the CLI commands
that's going to push to the controller,
we'll see that the inbound and outbound is already determined
because that's the point of a template,
a VPN membership policy pushed out to my environment.
But if I'm manually configuring everything or anything,
or for that matter, performing configuration via CLI,
then I'm going to have to make sure
I get this applied in the right direction.
Again, we related it to access control lists earlier.
If I am applying a policy and I want to filter outbound,
first of all, what's it related to?
If it's centralized, it's relative to the controller.
If it's localized, it's relative to an edge.
it would be outbound.
If I'm filtering in, then it would be an inbound policy.
So take some good notes at this point.
This is just a chalkboard look at the method
that we use for creating and applying our policies.
It especially starts with creating lists,
so we need to know that part.
And as we progress and we get into the lab environment,
we will get our hands on creating lists
and creating policies and activating them,
and we'll understand a lot better how this comes together.
But for now, this is just prep work
and making sure we understand what it is we're about to do
once we do jump into the lab.