At this point, we've spent a lot of time talking about our different policy types.
We have a control policy and a data policy type.
These policies can also be centralized or localized.
When we look at it, we know that control policies affect the control plane,
and data policies affect the data plane.
As a result of this, the fact that we have a controller running OMP to our different edge devices,
usually a control policy here is going to be centralized.
We define centralized as coming from and enforced by the controller,
which is at the center, the centralized concept, at the center of our architecture.
Data policies, because we have edges down here and our data policies affect the data plane,
meaning actual real traffic as it traverses the edge,
these are typically going to be deployed localized,
because the policy needs to be local to the edge, hence localized,
so that it can impact the local data flow.
A great example of this is when we took a look at access control lists.
ACLs are localized data policies.
They impact the data plane directly.
Truly, packets might hit the edge and get dropped because of our policy,
so that very much impacts the data plane.
It's localized because it has to go directly on the interface.
It is important to keep in mind that my policy can still be defined on our manager,
and then it can get pushed down one of two ways.
It can get pushed down directly, or it can actually get pushed down via an OMP update,
but it's not actually enforced by OMP.
It's more or less just delivered as a configuration to our devices.
We can still manage it here.
That's kind of a lousy M, but there we go.
Our manager still allows us to contain all of our policies,
some of which might be activated, some of which might not be activated,
and then maybe one day I decide to activate a policy,
but it becomes a repository of all of the different configurations
that I can push out in my network.
We have to be careful not to think of this as the concept of centralized.
It really, again, is less about how it's managed by you and me as admins
and more about how it's enforced if we're going to talk about centralized versus localized.
Here's the question that we have to ask.
Are all data policies localized and all control policies centralized?
The answer is no.
In fact, we're about to explore a centralized data policy.
Specifically, we're going to be looking at direct Internet access, or DIA,
as a configuration that we can put onto our edges.
We've already talked about it earlier in the course,
but we're going to actually configure it here in this skill.
First of all, before we jump into DIA configuration,
because it's a centralized data policy,
I should really throw that in there,
because it's a centralized data policy,
it's centralized, meaning that it's on our controllers,
and yet it's affecting the data plane.
I just want to break down what exactly that entails
and why it's going to be important for us
as we think about how this policy gets pushed out and enforced.
The reason why we have to deploy a centralized policy
the traffic gets enforced or our policy gets enforced,
we are not going to apply it with any amount of specificity.
That's a fancy word.
Basically, we're not going to apply it to a specific interface.
Access control lists had to be applied to a specific interface,
and yet with centralized policies, I'm going to use direction.
Now, this should sound familiar,
because we use direction for centralized control policies.
Remember, if I have a centralized control policy up here
and I apply it in an outbound direction,
we just saw this with the concept of TLOC actions,
when I receive information in, if I'm going to push it out,
and let's say it's an outbound policy,
at this point, this is where it gets enforced.
For example, I include additional information in here,
or potentially I perform some kind of filtering.
But we have the direction in mind
because we need to know if we're doing this enforcement
as we send the information to other edges
or as we receive it inbound here.
If I apply it when it's inbound,
then naturally it's going to affect everything,
all of my outbound calls here,
but also what I store here on the controller,
because I applied my filtering, let's say, in an inbound fashion.
Outbound means that I might store all this information,
but when I send it out to specific sites,
that's when I perform my filtering.
So the direction is very important for us
when we're talking about centralized policies.
And this is also going to be the case
with centralized data policies.
So here's the question, do I use inbound and outbound?
And if so, on my edge, draw it again here,
when I'm talking about traffic flowing back and forth,
usually via the service side and the transport side,
With the controller, it's fairly simple.
I just apply everything from the controller's view,
so am I receiving information or am I sending it?
But with centralized data policies and the edges,
we could get very confused trying to decide
which is inbound and outbound.
Is it inbound because I'm coming from the external world
into the service area?
We could call that inbound,
but I could also call it inbound to go the other way.
I'm sending it into the wide area network
We don't want to do that.
We would rather get rid of any amount of potential vagueness
or confusion.
So Cisco makes this a little easier for us.
When we apply a centralized data policy using a direction,
we're either going to use the from service direction
or we're going to use the from transport.
Now, we have to be careful here.
Transport is the side that we refer to this
as the wide area network side of things.
We've got the service side VPNs.
We've got the transport side VPNs.
But when we're talking about the direction
for centralized data policies,
we're actually going to use the from tunnel command,
not from transport, but from tunnel.
So, yeah, I mean, that's fine.
This is where our tunnels are.
It's just a little nuance to all of this.
So when we're applying, for example,
a direct internet access policy,
and I want it to impact this traffic
as it goes towards my internet circuit,
which is on the transport side.
Well, as we might imagine,
I'm going to use the from service direction.
And the reason for that is because it's coming
from the service side.
So it makes our direction a little more clear.
I can just use from service or from tunnel
and I can very quickly evaluate
which direction the traffic is flowing across the edge.
if we were to deploy a policy at the CLI,
it'd look a little something like this.
I would enter into the apply policy section,
just like I do for my control policies.
And then I apply it to a site list,
just like I do elsewhere.
So maybe a site one type of site list.
And then I'm going to use data dash policy,
not control policy, but data policy.
And then whatever my data policy name is,
and then I'm going to specify from service
or from transport.
So maybe from service here,
we'd toss in there for the configuration example
we just gave.
So this is all going to feel very comfortable
and very familiar to us
because we've been doing this with control policies
for so long, centralized control policies.
And yet I'm not used to,
or at least we haven't covered a lot of situations yet
where we're going to have to deploy centralized data policy.
So importantly, this configuration I just gave
goes on the controller.
Usually we apply data policies directly to the edges.
In this case, we're defining this again
with less specificity.
We're simply pushing configuration out
to many different edges that are out there in the network.
And I'm basically defining this region over here
as the from service side
and this to the from transport side.
And now I can generally speaking push configuration down
that impacts traffic as it flows
from one domain to another across many WAN sites
as well as many WAN edges.