So with our topology established in our lab environment, and we've got all of our routing in place and everything
it's time to dive into this concept of
policy
Policy as a general term gets thrown around a lot when it comes to our software-defined networks
And there's a good reason for this one of the huge advantages of having a software-defined network
Which by the way again, FSDWAN is a software-defined network. We just add in the wide area part in there
so SDWAN is indeed an SDN and one of the benefits of SDNs is that we are
supposed to as admins
Spend less time
trying to configure devices via the CLI for example and trying to keep everything afloat in the network and
So we're supposed to spend less time doing this and more time deploying and creating policy
So
Let's compare this to what a traditional environment looks like in a traditional environment
I or for example you as an admin we probably all have this experience
We're so busy trying to keep the lights on as we say just keep the network online and operational
So we don't have a lot of time to make things better. And so for example, what ends up happening is somebody
Maybe an admin that is higher ranked or maybe a manager will create a policy and
push it down to the admins to say we are supposed to deploy this via CLI and
Sometimes that works out. Okay, but in a lot of cases we just don't have time because again
We're just trying to keep these devices online. We're trying to get new network devices
added to the network and we're just very very busy and
So what happens a lot is that even though this policy is created it doesn't end up getting deployed into the network
so instead what SDN is supposed to deliver is our ability to spend less time at the CLI and
More time investing into creating these policies
Maybe we can help create the policies or maybe maybe somebody else creates them
But either way the idea here is this policy ends up getting deployed
To the network via our
manager
Now when we say our SDN manager, this could be a lot of different things
But in our case, we're talking about the SD-WAN manager
Which is going to push configuration to the SD-WAN controller, which was the vSmart
Or possibly directly to the edge and
And so this flow looks a lot different I'm no longer being given a policy and told to deploy it
But rather I'm helping to craft that policy and eventually it gets deployed again by the SD-WAN manager
So in SD-WAN now as we get into
More specifics around our architecture. We're able to use these policies to do a lot of things
So for example, we could actually use it to manage the topology
We by default have an any-to-any type of topology
We form tunnels everywhere we can we share routes everywhere we can but maybe we want to restrict the topology
Maybe we want to make it a hub-and-spoke topology, for example
And we'll just say etc here. We've got a lot of different options for the topology
But the idea here is I can create a policy and that policy just automatically gets deployed as CLI commands
We can also manage edge
Configuration
So it doesn't have to be something that is managed via the propagation of tunnels and the propagation of routes
I might just want to deploy
Configuration to the edge. Maybe I want to deploy something security related and so that could be at the data plane
I could also want to maybe make changes at the control plane so I could control routes and
The route propagation so maybe there are certain routes. I don't want to share
With the particular sites, well, that's very complicated in traditional networks
But in SD-WAN, I can create a policy that more or less says hey don't share these routes with these sites
all right, so a set of routes that I don't want shared with let's say site 13 and
Boom, it's done that policy gets deployed automatically. Thanks to my automation that I have with SD-WAN manager
Now the other thing to keep in mind in all of this is automation
as I just mentioned automation is a big part of how this all works and
We might want to ask that question. How does all of this work? Well, we have a couple of API's at play
We covered this earlier in the course, but just as a quick refresher
We have two main API's at play because the manager kind of sits in the middle here. We as the network admins
can leverage
rest API's if
We so desire now
I can also just use the graphical user interface log into the web console and and do all the
Configurations like we've been doing up until now, but I also could use rest API's I could programmatically
Create some scripts that automatically go out to manager and execute some amount of configuration
So I could end up doing this. I don't have to but it is an option
But also keep in mind that manager is going to push configuration to our controllers and our edges
So we it's going to leverage an API in order to do this API's were primarily built for machine-to-machine communications. That makes sense
However, we're not going to use rest API's rest API's were really developed for people. It's very human readable
It's very simple for us to make modifications to rest API's
But instead of leveraging those we're going to use something a little more machine driven which in our case is going to be netconf
It's going to send communications via the netconf API's which will allow the manager to
Configure these different types of devices
So again, just a quick refresher on which of these API's are used on which side always remember that managers configuring
Devices via netconf. Whereas we might configure manager via rest API
That or at least maybe we should say categories that we will divide our
policies into
We'll find there's actually quite a few types that are out there
We're continue to break down and break down the different types and categories that there are but let's just say two
Overarching categories here. We have our control policies and
We have our data policies
Now control policies is the name implies for both of these
It's going to target a particular plane of operation. It's meant to target the control plane
Whereas the data policies are meant to target the data plane
When we perform configurations we'll have to leverage different types of
Policies which fall under one of these two categories. So when we're thinking about the control plane, what types of things are we talking about?
Well, we have to think about the fact that we're going to be impacting primarily
OMP here, but also possibly some downstream routing protocols like EIGRP or OSPF
So anything involving routes?
Anything involving TLOCs?
This is going to be the result of a control policy
So for example, if I want to change the topology
Well, how would I do that?
Well, the way I do it is I would change the propagation of TLOCs
So that two edges can't actually try to form tunnels to one another because they simply don't know about the remote TLOC
That would be a good way to control the topology. Well, if we're controlling TLOC propagation
That's part of OMP which is part of the control plane. Therefore the topology type of
Policy that is a control policy
Meanwhile at the data plane we have quite a few options as well
For example, if we're talking about deploying an access control list on an interface
This would be something that requires a data policy because we're talking about the flow of traffic through an edge device
we might also see that we want to deploy quality of service on an interface and
Then we also have the option of deploying
Direct internet access or DIA. We'll be talking about that later on in the skill. That is going to allow our
Users possibly our guests to go through an edge device here. That would be an edge device
That's an E and rather than following a circuit out to another edge device
Maybe to try to access the internet out here. We might recognize that. Hey, this is an internet circuit
So why not just use it and communicate directly with the web?
So that would be direct internet access and we'll be talking about that more coming up
So generally speaking or thinking about policies
We want to recognize that there's this new flow
That we're going to want to use in our SD-WAN environment compared to how we used to do things
We're going to want to focus on creating good policies
Because we don't have to spend as much time at the CLI trying to make the SD-WAN work
Just keeping it online and making sure that failover is good all of that's taken care of now
So we as network admins can create policies and those policies will be deployed
By our SD-WAN manager by pushing configs down to the controllers and the edges
We see that we've got a lot of different types of policies and two primary categories
Which are control and data policies and we will continue to see the different types of policies that fall under those umbrellas as we dive
even deeper