So we know that our policies can either be control policies, which impact the control plane,
or they can be data policies, which impact the data plane. But we're not quite done with our
categorization because we can also set our policies to either be centralized or they can be localized.
So yeah, lots of categories and we're not even done yet. We're going to talk about more as we
keep going. But in this video we want to focus on this concept. What is the difference between
a centralized or a localized policy? So let's go ahead and talk about centralized first.
Centralized policies are when we want to apply something globally to the entire fabric at once.
This wouldn't be a policy for a specific site unless we were trying to impact how everybody
treats that one site. If we just want a local site to use QoS, right, we wouldn't be using
that as a centralized policy. Instead, we're looking for things that we want to configure
in SD-WAN Manager for the most part. But we could possibly use the CLI in the controller.
So we could use the controller CLI here as well. But either way, this is going to create policy
inside of the SD-WAN controller which used to be known as the vSmart.
So the SD-WAN controller or the vSmart is going to receive this policy and in some way it's going
to distribute this into the entire network. This is why we call it centralized because the policy
is coming from the center of our control plane which at the very heart of our control plane is
absolutely the software-defined WAN controller or the vSmart again. But the question is how?
How is it doing this? What mechanism is it doing or is it using in order to push things out? Because
as far as we understand it, SD-WAN controller here or the vSmart, this is primarily relying
on OMP. Remember we are going to find that edges share information via OMP.
And then the SD-WAN controller is going to share that information with other edges
also via OMP. OMP is what's carrying a lot of information. We know there's three different
OMP types of routes. We have OMP itself or OMP types of routes which are carrying
the routes and the subnets. We have the T-lock routes which is how we are able to form tunnels
to one another. And then we also have the service routes which allow us to do service chaining.
So what exactly is our vSmart here going to do? Well it's going to manipulate or filter
in the end our OMP information. Think about what our SD-WAN controller is doing by default.
The default policy for our SD-WAN controller is to do nothing else other than to share
absolutely everything with everyone. It doesn't have a lot of discretion. It doesn't know any
better. If I receive information, I'm going to push that information absolutely everywhere.
Now sometimes the edge isn't able to receive information. For example, if we have like VPNs 10
and 20 at this site and this edge is only configured for VPN 10, well it could push
VPN 20 information down but it's not able to use it. It doesn't even have that VPN or in our case
the VRF running Cisco edges. It doesn't have that VPN slash VRF configured. And so we might not
look at an edge and see this VPN 20 information over here. But the moment that I do add VPN 20,
guess what? It's going to receive that information via OMP because that information is out there and
SD-WAN controller wants to push that out everywhere that it makes sense to do so. We'll
actually see this exact example later on in the lab. We'll see why we might want to contain that
from prevent that from happening depending on the real world type of topology. So the answer of how
we're going to enforce this policy is right here. We're going to filter the information that we are
providing via OMP. So what are a couple of examples of this? Well when we're thinking about centralized
policy, we could look at a topology policy. So we already mentioned the topology policy is going to
do exactly what it sounds like. It's going to allow us to control the tunnels. The tunnel formation
will be impacted by a topology policy. That's a little hard to say. So the topology policy
is going to affect our tunnels. How? How is it going to do that? Well we just said that these
TLOC routes are shared everywhere by default. And so what we're going to do is we're going
to see that the SD-WAN controller is going to filter the TLOC routes and it's going to filter
the OMP routes. This will allow us to make a change. So we might have three edges in our topology
and let's just do this for a single transport. We know that across that transport we're going to try
to form tunnels across all of the TLOCs that exist out there. If each of these routers has a TLOC
they're going to try to form tunnels to both of the other TLOCs. So what if we wanted to make this
the hub and these devices over here could be spokes?
Well instead of forming tunnels everywhere we can filter those TLOC and OMP routes out
so that the top spoke over here knows about this TLOC but it doesn't know about the other TLOC.
It has no information about it so it doesn't even try to form a tunnel. Same thing with the other
spoke. It doesn't know anything about this spoke's TLOC but it does know about the hub's TLOC.
And so not only are we making sure to only advertise the TLOC routes that allow us to form
these tunnels but we're also restricting the OMP routes because now I'm not able to directly
communicate therefore there's no reason for me to want to send traffic directly to that other site.
Now is that what I want in a hub and spoke? Potentially. A lot of our sites don't need to
communicate with one another. A lot of retail stores don't need to communicate from one store
to the other but they do need to communicate with the hub which would be some headquarters
type of location. So we've got hub and spoke. We've got mesh capability. We can do a custom
topology and we'll see those coming up. But this is thanks to the concept of a centralized policy.
I am heavily manipulating my OMP information in order to do this.
What about VPNs? We can create a VPN membership policy. So I just mentioned that we might want to
block our VPNs. Well I can do that using a VPN membership policy. So in this case
I might be a service provider and I'm managing different customers. So I've got customers here
and I've got customers here and at this site I have two customers. VPNs 10 and 20 represent two
different customers. But over here maybe this is the only customer that's at this site. In fact
maybe the customer manages this device. That's not out of the question depending on the situation.
And so if that's the case I wouldn't want to push VPN 20 information down. Now you and I could look
at this and say okay that's great except VPN 20 wasn't actually included in the configuration
and therefore that information isn't able to be stored on that router. But what if the
customer manager managing team, the team managing this device, what if they get on there
and they do add VPN 20? All of a sudden they're going to get all the VPN 20 routes which belong
to a different organization and that's a major violation of privacy. So we can use a VPN membership
to manage the routes that are within a VPN and where those go. How do we do it? Well we do it
by filtering. And in this case we're primarily going to be filtering OMP routes. We don't want
to advertise routes to a location that doesn't need to be getting those routes especially
if it's a customer managing their own device. So how often does that happen in the real world?
It depends on especially whether you're a service provider. If you're your own organization you're
probably not really leveraging VPNs a whole lot. But in the right situation VPN membership
centralized policy manipulating the information we're sharing via OMP might be very very important.
Now lastly we do have the concept of localized policies. Now our focus is on centralized
policies. We're going to spend a lot of time looking at topology and VPN membership policies
for example. But localized is very important as well. The idea of a localized policy is that we're
going to push CLI information, however we want to think of it, we're going to push configuration
to an edge. Yes that will change the CLI configuration and just like we did over here
we can see it be pushed via CLI. So I as the admin might perform CLI configuration. But either way
this becomes a localized policy if it only impacts that one site and specifically that one edge. So
a couple of things. First of all the controller or the vSmart that's not involved in this.
It's a localized policy. We're not sending everything through the centralized controller
and that's what differentiates it as localized. Most commonly we're going to be looking at things
as we mentioned such as ACLs and quality of service and generally speaking configurations
that are interface specific. Now I've got an interface here that connects to something and
I really want to make sure this interface has a specific configuration. I wouldn't push that out
using a centralized policy. I would use a localized policy in order to do that.
It also is going to potentially be used for local routing configurations. So our IGPs, BGP,
you know our EIGRP, OSPF and so on and so forth. What we end up finding is that localized policies
actually are simply route maps. Which is why we can apply access control lists. It's why we can
control our routing protocols and how we want to impact our routes. So when we go to configure
these, whether we're configuring it via the CLI or via manager, either way we're going to see very
quickly it takes the same form that we use to generate our route maps in a traditional network
environment. So we're going to see match statements, we're going to see action statements and so on and
so forth in here. So the big takeaway here is recognizing the difference between centralized
and localized policies. Making sure we understand that centralized policies leverage the SD-WAN
controller, whereas localized policies are really aiming straight at the edge. And also understanding
that there are a couple of specific types of centralized policies. Specifically looking at
topology and VPN membership policies that we're going to be leveraging heavily when we go forward
and look at configuring policies.