All right, so we have our control policies and we have our data policies and those policies can
either be centralized or they can be localized. Well, now we can also find that our policies
are either going to be inbound or outbound. If you've studied access control lists this is going
to feel pretty familiar because when we look at a device and we talk about a policy being enforced
we're typically going to look at it as being enforced inbound or outbound.
So, for example, we just saw that if we take our SD-WAN controller that we might put a topology
policy in place. A topology policy is a control policy because it impacts the control plane,
specifically those T-lock routes and OMP routes, and it is a centralized policy because it is
And so we learned about the fact that we're going to filter, for example,
we just said it, OMP routes and T-lock routes. So if I have an edge and it's advertising
OMP and T-lock routes but we decide that we're going to filter it as it goes down to this other
edge, is this an inbound or an outbound policy? First of all we have to identify is this in
relation to the advertising edge? Is it something we're doing on outbound there? Is it from the
perspective of the controller? And is it happening on this interface or this interface? There's a
lot to unpack there so let's just dive right into it. When we're talking about an inbound policy
we are probably either talking about a centralized policy or a localized policy.
So what is it inbound relative to? Well if it's centralized it's going to be relative to the SD-WAN
controller. And if it's localized it's going to be relative to the edge. So then we have to look at
it as saying, well is it going to be filtered as it's coming into the device or is it happening
as it goes out of the device? So if it's inbound we're going to be talking about it coming into
the controller. So something that is coming into the controller or something that's coming
into the edge. This would be in the inbound direction. Is this where the filtering is
taking place? So when we're looking at the centralized concept and specifically as we
look at these routes and being part of a centralized control policy we're going to have
to ask is the controller actually performing learning? This is a great way to determine
whether it's inbound or outbound because if it is learning it that means that it's coming in
no problem. It comes in and I record these routes. So for example if we let's say we've got routes
in VPN 10 but we don't actually have VPN 10 over here. We have filtered it out as part of
another type of control or centralized control policy which would be the VPN membership policy.
So at that point does this mean that the controller is aware of VPN 10 or and for that
matter we're talking about the OMP routes that belong to VPN 10? Well hopefully so because
chances are if there's a VPN 10 at this location there's probably a VPN 10 at another location
that it needs to send it to. In order for me to learn of those routes I'm going to need to learn
of them so inbound is fine. This turns into an outbound policy because now I am filtering it.
So again the question we have to ask is where is it getting filtered or where is it filtering?
In our case it's filtering in the outbound direction
specifically to certain sites or certain edges. So this is where how we evaluate whether it's
inbound or outbound and in our case this topology or VPN membership this would be an outbound
type of policy. Now if I didn't want the controller learning about something I would configure an
inbound policy. So again let's look at this. So we've got the centralized concept. We have
information flowing into the controller and information flowing out of it. If it's inbound
if it's an inbound policy this means that it's going to get filtered here. If it's an inbound
localized policy same concept that means it's going to be filtered here inbound to the edge.
Meanwhile traffic flows out of the edge as well whether that's data actual data traffic so data
policy or control plane information which is a control policy and so now we need to consider
what would an outbound policy do and as we have already demonstrated an outbound policy is going
to filter here or filter and not quite there let's do it there in the outbound direction.
So that's all it takes for us to evaluate whether something is inbound or outbound.
We're going to need to see or ask the question of where is it filtering and also identify the
proper device. If it's a centralized policy we need to evaluate a controller if it's a localized
policy we need to approach it from the perspective of the edge. Now one thing to keep in mind with
this is that we are pushing information from a manager as we've said and let's say we're doing
a control policy here and so we're also making this centralized and we're going to push a
centralized policy to the SD-WAN controller. Well that's great except what if we have multiple
controllers? We have to operate from the perspective that these controllers must be in
sync at all times. They're controlling my whole environment and if I push a policy
the question is what happens if one of these controllers receives it the second controller
receives it but this third controller for some reason it either rejected the policy or it's just
unreachable and it's still working but the manager wasn't able to communicate with it. For whatever
reason the policy failed. Well these would be out of sync at this point and so we have to ask well
whose responsibility is it to stay in sync? I mean are these controllers supposed to communicate with
one another and the answer is no. The syncing responsibility actually lies with the manager.
So how does that work? How is the manager going to be responsible? Well the manager is going to
be responsible by saying hey if we're out of sync meaning that this device this other
controller wasn't able to accept the policy well at that point I'm going to revert the others.
So even though they accepted it to start with we're going to say you know what never mind
that policy you know we were just messing around so we're going to pull that back
and actually make it so that they go back to their original behaviors.
So again the responsibility for staying in sync lies with the manager from that perspective.
It's designed to make sure that the controllers any policy we deploy go to all of the controllers
and if for any reason that doesn't work we will revert it and make sure that they do end up staying
in sync one way or the other.