We are now ready to be able to deploy a control policy,
and so we'll start by deploying a topology policy
to restrict the topology.
As always, keep in mind that when we're talking about deploying policies,
our starting point is everybody can talk to everybody
and everything is accessible.
So anytime we're talking about enforcing a policy,
we're really saying that we don't want everybody to be able to speak freely.
We want to place restrictions out onto our network.
So when it comes to restricting things from a topology perspective,
let's say we want to deploy a hub and spoke.
So if we're going to deploy a hub and spoke,
we'll make site 13 over here be our hub,
and we'll have a spoke here at site 12 and a spoke here at site 11.
Now, we know that all of these edges have a full mesh of connectivity
to one another through the MPLS cloud, but also through the internet,
and it's going to look pretty much the same
where we have communication through here to our different edge devices.
So it gets a little bit complicated.
We'll just sort of leave this in place here
and get all of the full mesh connectivity in place there.
So we know that edge 13 and 14 don't actually have a connection
because they're at the same site.
So this is the topology that we're looking at on a per transport basis.
When we make a hub and spoke, what we're really saying is that
And so in our case, we're not only going to get rid of the tunnel,
but we're also going to make it so that we don't actually share routes
to one another, meaning that our hosts will not be able to communicate.
So what is the value of this? Why would we want to do this?
Well, we imagine a scenario where our sites,
maybe we have a bunch of retail sites,
and we just have no reason for those retail sites to communicate with one another.
Now, if we have voice over IP, then right away,
we're going to see some problems with that if sites need to call other sites.
So we're really talking about a scenario where we really don't want locations
to communicate with one another.
Maybe they represent different customers,
but the reality is that if we're going to get rid of this tunneled connection,
then we might as well say that those sites shouldn't talk directly to one another.
If they should talk directly with one another, then that tunnel should be in place.
So I just want to point out that when we enforce a topology,
it's not just that we're changing the tunnel configuration,
we're actually changing the advertisement of routes as well.
And we will absolutely see this as we build it out.
Now, that said, we can always inject routes down
and make it so our sites can communicate.
But again, at that point,
why wouldn't we just build the tunnels directly to one another?
So let's go ahead and talk about the process here.
In order to build out a control policy, we're going to need a few things.
First of all, for context, we're going to be focusing on VPN 10.
And so we'll see all of our communications
and all of our configurations are applying to that VPN.
Second of all, we're going to need to create some things.
We're going to create one of those site lists that we've talked about.
Actually, we're going to create a bunch of site lists, as we'll see.
And then we're going to create VPN lists as well for VPNs 10 and 20
to make sure we're applying policy to the correct VPN.
And then we're going to create the topology itself.
So let's go ahead and jump into the configuration side of our manager here.
And this is right here.
So we're going to log into our SD-WAN manager
and start to create these configurations.
So we're going to go to configuration
and then all the way down at the bottom where we were going to templates,
right below that is policies.
So we're going to fire up policies here.
We're going to stay on centralized policy.
And a couple of things.
First of all, if I click add policy,
it's going to allow me to create these groups of interest
so we can create our site list, for example, right here.
But if I cancel out of this,
I can also use custom options just to go to lists directly and create lists here.
So however we want to do it is fine.
The reality is that we're going to need to create site lists and VPN lists.
So let's go ahead and create some site lists.
When I create a site list, I have to give it a name.
So let's say I want a site list that includes sites 11 and 12.
So I'd call it sites 11 and 12 or something along those lines.
And then I can add a range of sites here and click add.
So I've got my new site list here, but let's go ahead and create a few more.
Because as we've said before, there's value in having a site list for each site.
We might end up using all of those.
So I'm going to add site 11 into its own list.
I'm going to add site 12 into its own list.
And this might seem like a lot of work.
But as always, when it comes to centralized management and configuration,
sometimes the setup takes more work than we would have to do at the CLI to do something.
But once it's done once, it's done forever.
So by sitting here and creating a bunch of site lists,
I can now reference these as much as needed into the future.
So I can either deploy a policy straight to site 11,
or I can deploy it to all of my spokes using the site lists that we've created.
And then site 13, again, is going to be the hub.
Over on the left, I'm going to create some VPN lists.
So I say new VPN list.
I'll call this VPN 10 and add a VPN 10 here.
And then I can do the same thing.
I can say VPN 20, adding VPN 20.
And then I can also say VPNs 10 and 20.
So maybe 10 underscore 20, something like that.
And then we say we can do comma separation.
So I could do 10 and 20 together into one list.
And that way, if I need to reference both of the VPNs,
I can just reference that one list rather than trying to reference multiple lists.
So at this point, I've created my list.
I could either scroll down and click next if I started the process of doing a configuration.
But from here, what I'm going to do is go back to my centralized policies, click add policy.
So, again, when I add a policy, this is interesting.
It takes me to the section where it allows me to perform or create groups of interest
before getting into the actual policy configuration.
So I can verify, for example, that my site lists are in place.
I can verify my VPN lists are in place.
If I'm creating TLOC lists or color lists or anything like that, then I would verify that here as well.
But either way, I don't need to select anything yet.
I just need to make sure my lists are in place.
This is where I can click next.
And now we're taken.
We see this step-by-step flow at the top here.
So I've created my groups of interest.
Now it's time to configure the topology and VPN membership.
These are the two primary control policies that we would deploy.
So we're creating a topology as part of this video here.
So I can click now this add topology and select hub and spoke.
So I click hub and spoke, give it a name.
So we'll just call this HS1 for hub spoke 1.
Description is going to be site 13 as a hub.
And then the VPN list, I'm going to, again, only apply this to VPN 10.
So let's select VPN 10 here.
And then we need to identify which site is which from a list perspective.
So I'm going to say here add a hub site or add hub sites.
But either way, it's just going to be one site for us.
It's site 13.
And then I scroll down here.
Okay, so we click add first.
There we go.
The resolution is always when we're recording is just a little bit different
than what yours will look like.
You'll see this a lot clearer on your own screen in all likelihood.
Either way, when it comes to spoke sites down here,
this is where I could select, for example, sites 11 and 12 together as one list.
Or I could add individual lists.
The flexibility is there for us.
But don't forget to click add.
So with both of these added, we should see them in the list
with the ability to remove them if we needed to remove them for any reason.
I'm just going to scroll down and click save hub and spoke topology.
So I've created my topology now.
And that's great.
Site 13 is going to be the hub.
But the reference count is zero.
It's not actually in use anywhere.
And so I'm going to need to manually add this into use once we get to that point.
But for right now, we're still in the middle of this creation wizard.
So I'm going to click next.
Cisco allows me to create other policies.
I'm not going to do that right now.
I'm going to click next.
And now I need to actually save this as a policy name.
So I'm going to name this topology hub and spoke or HS.
And then this is a hub and spoke topology.
So here I'm going to save the policy.
And now my policy is in place.
And within this one policy, we have a topology without a VPN membership
and anything else.
We really just focused on the topology element of this specific centralized policy.
So now we can enable it here.
I use the three dots or the ellipses.
And I would click activate.
Now, I'm not quite ready to do that yet because I want to go see what the
current state of the network is.
So let's go ahead and do that.
So let's go ahead and log into Edge 11 here.
And what I want to do is just make sure everything's in place.
So number one, before we do anything, we want to be sure that it's in good shape.
But number two, we want to see the before and after as well.
So if I do a show IP route VRF10, we see specifically, let's focus in.
We're logged into Edge 11.
I want to focus on the spoke sites.
So if I'm Edge 11, I want to look at Site 12.
So I do see that I've got this route over to Site 12.
This is within the context of VPN10.
I can also do a show IP route VRF20 and see that I do have a path there,
keeping in mind that VPN20 doesn't exist at the hub site.
It only exists at the spoke sites.
This is the way that we set up our lab.
So if I were to ping within VRF10 over to, let's say, 10.10.
The site is 12.50.
And we see that I can ping it no problem.
I could also do a source ping and source it from 10.10.11.
What is the IP address of this site?
It should just be .11.
Yep, okay, good.
Been a while since we've looked at individual site IP addresses.
And then we can look at the tunnels as well.
So show SD-WAN BFD sessions is always a good way to do that.
Always keep in mind that tunnels are not VPN-specific.
We form one set of tunnels, and then we put all of our VPNs into that.
So I see that I have tunnels going to each of the individual sites
across Biz Internet.
It looks like our MPLS is actually down right now.
So we'll have to take a look and see why that's the case.
But either way, we do see that all of our connections are online,
and we are extending and connecting over to our fellow spokes site of Site 12 there.
We see that we've got a tunnel up going directly to Site 12.
Oh, and I just remembered why we're only seeing Biz Internet.
If we do a show IP int brief, yep, right there.
So recall earlier on when we were doing backup paths in the lab,
we had actually shut down the MPLS as part of that lab process.
For right now, I'm going to leave that in a shutdown state
just so that we can kind of keep things a little cleaner
and monitor just one transport at a time.
If in your lab environment you've got this back online
or you want to bring it up before experimenting with the topology,
that's perfectly fine.
Again, we're just going to go ahead and move forward with it as is.
So importantly, again, our primary takeaway here,
we've got tunnels to all three sites or all three other edges
other than the two other sites because there's two edges at one site.
And then we also have an IP routing table in VRF10 and VRF20 for that matter
that includes the other site.
All right, so let's go ahead and flip back now to SD-WAN Manager
and complete the configuration there.
So as mentioned here, once we're on our centralized policy here,
we see the policy that we created,
and so we're going to use these ellipses again to come down to activate.
Now, it tells us which controllers is going to receive this policy,
so we say activate.
And the nice thing about this is, first of all, I could just say activate here.
It's going to apply it to all of my controllers.
But I could click on the controller over here,
see the configuration preview of what it's going to look like,
and importantly, look at the configuration diff,
meaning that looking at the differences of, well, it says it right there,
local configuration versus the new configuration.
So we're going to scroll all the way down here
and look at really the meat and potatoes of this,
which is that we're deploying a policy.
So notice how this is coming together in configuration at the CLI.
It's going to enter into a policy configuration mode,
get into list mode, and it's going to create some lists.
Now, we could look at this and say, well, I see one VPN list
and I see two site lists,
but you and I know we created a whole lot more lists,
so what's going on here?
Well, what's happening is that we're only pushing down the lists
that we're going to use.
This is the beautiful thing about this architecture
is that the SD-WAN manager stores all of this information for us,
including all of the lists that we create
as well as all kinds of other different policies, I suppose,
and it's only going to push down to the controller and edge devices
anything that's required.
So if I later push down a policy that requires my VPN 20 list,
then it will push it down at that point.
And so it's not to say that it's deleting it.
It's not deleting it.
It's just going to exist on SD-WAN manager
and get pushed to the controller if that's actually required.
But until then, it's not going to push it.
So we're only using three of our lists.
It's only pushing three of our lists.
Also, notice the syntax.
We'll take a look at this in more detail later
when we're looking at CLI configuration,
but do notice how, again, the syntax goes from policy to lists.
We create individual types of lists, give them a name,
add specific site IDs or VPN IDs,
and, again, there's TLOC colors and so on and so forth.
Then it's going to create a control policy,
and it gives it a name that includes this long number
that's just randomly generated as part of this,
and this indicates to us that it was pushed down through manager.
If you and I were creating this,
we'd probably give it a more logical name
like hub and spoke topology or something like that.
From here, we see that these policies, the control policies,
are going to act a lot like route maps,
and we've said that before.
So it's going to have a sequence number.
It's going to have the match and action concept here.
So we're matching a route,
and we're going to identify the lists that we're matching,
so site 13, VPN 10,
and we're going to accept routes from that.
And then we're also matching TLOCs,
and so this is right here where we are matching routes
and saying that we're accepting site 13,
and then we're matching TLOCs,
and we're also accepting site 13.
Well, what's the default action?
The default action is to reject everything.
So what are we actually saying here?
Because we're implying what we're doing,
but let's be explicit.
What are we actually accomplishing?
What we're accomplishing is we are rejecting everything
that's not explicitly allowed.
So what are we allowing?
We're allowing site 13 TLOCs to be advertised.
We're allowing site 13 routes to be advertised.
We are not allowing site 11 and 12 to advertise their routes,
nor are we allowing them to advertise their TLOCs
to one another.
So that's going to create our hub-and-spoke topology,
which is pretty cool when we see this come together.
Then we're going to apply the policy.
We say, well, wait a second.
Shouldn't site 13 receive the TLOCs and the routes
from sites 11 and 12?
So we're only applying this rejection policy
to sites 11 and 12.
And furthermore, we see that we have to specify
the input or output direction.
So I'm going to receive routes.
I'm going to receive TLOCs from sites 11 and 12.
And let's just draw this out real quick.
Here's our controller.
So I've got my edge 11 and edge 12,
and I'm still receiving the TLOCs and the routes.
However, when it comes to advertising to 11 and 12,
we're rejecting what we learn here.
Now, meanwhile, 13 and 14 edges, they're part of site 13.
They are advertising TLOCs and routes,
and we're allowing these to come down to sites 11 and 12.
So that's how this is working,
and this is how it all comes together.
In the end, it's a fairly simple,
or at least relatively so,
a relatively simple set of configurations.
There's not a lot of lines here.
We create our lists, we create our policy,
and then we apply our policy down here at the bottom.
And thanks to SD-WAN Manager,
this is all a lot of graphical user interfacing
and pointing and clicking.
So I have now pushed the configuration.
This should look a little familiar.
Anytime we've pushed config to our edges,
this is exactly what we ended up doing.
So it was validating the configuration.
It put that configuration in place,
and now we're just waiting for the status
to say that we are good to go.
Oh, and there it goes.
I didn't even have to pause the video.
It happens pretty fast.
So let's go ahead and flip over to site,
or edge 11, rather, and see what the result was.
So here we are on edge 11,
and let's go ahead and verify everything happened
as we thought it would.
So I'm going to do a show SD-WAN BFD sessions.
And yes, I do still have tunnels up to edges 14 and 13,
but I don't have a tunnel up anymore to site 12.
If I do a show IP route VRF 10,
I'm going to see that I no longer have a path
to 10.10.12.
So I'm not getting the routes,
and I'm not getting the TLOCs.
Lastly, if I try to ping in VRF 10,
that 10.10.site12.50,
this ping worked before.
It's no longer working because I don't have a route
to that subnet.
Now, if I had a default route through the hub site,
then yeah, we could make this work.
But just strictly speaking,
using the routes and the TLOCs
that are part of the SD-WAN environment,
edge 11 and edge 12 can no longer communicate.
So just to wrap this up,
let's go ahead and log into our SD-WAN manager
and clean up this config
So let's go ahead and go to configuration
and back down to policies.
And I'm going to use the triple dots here
to instead of activate now,
I'm going to select deactivate.
And once again,
I can click on my SD-WAN controller over here.
I can look at the config diff.
We're going to see that we're going to remove
all of that configuration that we just added.
That's what the red highlight means.
So I'm going to click deactivate.
And once this gets pushed,
we'll just double check that all of our routes
and TLOCs are back in place.
And so yeah, that was really fast.
Let's go ahead and switch back over to our edge.
And we could do this as simply
as just running the ping command again,
and we see that the pings have gone through.
But we could check the IP routing table.
I see site 12 subnet there.
And then of course I can check the tunnels
and make sure that I do have a tunnel
that's up to site 12.
So we've undone what we did,
but it's important to recognize exactly
what we did and how we did it.
We deployed a hub and spoke topology
using a control policy.
We see that on the back end,
it created those lists and the policy,
and it applied the policy.
But we understand also that what it's really doing
is it's making it so that certain sites
don't get the TLOCs,
so they can't build the tunnels,
and certain sites don't get routes from one another,
which means they can no longer route
and send traffic back and forth.