All right, let's go ahead and make sure we understand these concepts. We're going to look
at a topology here and answer some questions about what we just learned. So first up, what type of
policy can be used to filter which edges receive routes from which VPNs? For example here, we see
that we've got this site over here and it has routes in VPN 10 and 20. So we know it needs to
receive routes for VPNs 10 and 20 from the controller. But what about this site here?
Edge 30 only has VPN 10 subnets. Edge 40 only has VPN 20 subnets. So there's no reason for me to
share VPN 10 information with this site or share VPN 20 information with this site because it
doesn't need it. It doesn't have any buddy there that belongs to that VPN. And so don't allow them
to accidentally configure VPN 20 and all of a sudden receive these routes. Instead, we want
to block that and we can use the VPN membership policy in order to make that happen. Now number
two, which type of policy can be used to change how many tunnels are created between edges? So
for example, do I want to make this a hub site and these would be spoke sites? Meaning that we would
form tunnels this way across MPLS and this way across the internet, but we are not going to form
tunnels with one another. Well at that point I could deploy a topology policy and that would
allow me to restrict it to let's say a hub and spoke type of network. The number three are the
above two policies that we just talked about. Are they control or data policies? We have to think
about whether we're affecting the control plane or data plane and we're talking about the propagation
of routes from the controller, whether those are T-lock routes or OMP routes. And in either case,
it's control plane information and therefore these are control policies. All right, now question
number four. An SD-WAN tech wants to filter the routes learned by the SD-WAN controller. Is this
an inbound or outbound policy? So if we're talking about routes learned by the controller, then that
means inbound and outbound is relative to the controller. This would be a centralized policy
because again this is the heart of our entire operation. So if we're filtering routes as we
learn them, this would be an inbound policy. That's always where I'm filtering is the question.
So when we say we want to filter routes learned by the SD-WAN controller, not advertised but learned,
then we have to pay attention to what routes am I actually putting into my table.
I might learn four routes and then only advertise two routes. Then it's an outbound policy, but in
this case, if I'm actually filtering routes in and I don't even install a couple of these routes,
that would be an inbound policy. Now lastly, it has been determined that edges should use their
local internet circuits for guest access via local DIA policy. What type of policy is this?
Well, DIA is always going to be a data policy. And we have a localized and centralized version
of DIA, whether we deploy things to an individual edge and it's localized or whether we end up
deploying something more globally. And even though we're not involving the SD-WAN controller,
we are still managing everything centrally, this time via vManage. It's still pushing policy down
to a bunch of edges, but it's all at once. So we'll continue to explore these different types of
policies. We're going to put our hands on the lab and make sure that we can configure things.
And it'll all start to come together really, really soon if we're still a little bit, maybe, gray as
far as whether or not I know where control and data policies are. But again, always think about
whether the controller data plane is being affected and also where is filtering occurring. That will
tell me a lot about whether it's centralized or inbound or localized or outbound and as well,
controller data policies. I hope this has been informative for you and I'd like to thank you for viewing.