All right, we need to create a hub and spoke topology,
but we don't want to use Cisco's version
because we need to allow ourselves
to activate communications between our spoke sites.
And Cisco's version of a hub and spoke topology,
that doesn't allow us to do that.
So let's go to configuration
and we're going to go down to policies.
We're going to create a centralized policy.
But first of all, and we can come up to custom options
and to create our own topology here,
we add a topology and we simply say,
let's add a custom control policy here.
So from here, I'm just going to say something like
custom control underscore challenge.
And this will say, it'll be challenge topology.
And we'll add the sequence type.
Now, what we want to do is we want to make sure
that our routes are actually propagating
and it's only our T-locks that are not.
So I'm going to add a T-lock rule here.
And what we're going to do is match on our sites.
So let's go to sites here
and we're going to pick sites 11 and 12.
There we go.
So sites 11 and 12, and we want to make sure
we're applying this outbound to sites 11 and 12 eventually.
But the idea here is that we're going to reject these sites
as part of our T-lock policy.
And then from here, I'm going to save our actions
and then go to default action.
We're going to change this over to accept.
Now that's great and all,
but we have to think through this a little bit
because yes, we're restricting the T-locks,
but we don't actually have anything in here about routes
because I need to make sure that I know
that if I'm receiving routes
from one of the other spoke sites,
that I should be using site 13 in order to access it.
And so we're going to still need to add
a route sequence type.
Now under the route here,
it doesn't shouldn't matter which order we do them in.
We could change this if we wanted to,
but either way, what we're going to do
is we're going to match again on these sites.
So where's our site list?
There it is.
So sites 11 and 12,
and then we'll click actions here.
And what we want to do is set our next hop,
which is a T-lock.
So we're going to change the T-lock
and we could use a T-lock list here.
We don't have a T-lock list configured.
So we'll just specify,
and we'll just go with edge 13.
So 13.13.13.13.
And we can add bizinternet here,
as well as encapsulation ipsec.
So that should work.
The only thing to keep in mind again,
is that we want to make sure the default action
as part of this whole policy,
is that we're accepting everything else.
So all we're doing is catching the routes
from sites 11 and 12.
And as we learn of those,
we're going to send them towards edge 13 instead.
We did that by changing the T-lock next hop.
So let's go ahead and say, save control policy.
And now we have this policy in place.
Now we have to create the actual centralized policy.
Yeah, the word policy kind of gets thrown around a lot,
it feels like.
I'm going to add a centralized policy.
We don't need any groups of interest.
I'm going to import the topology I just configured.
By the way, you can always just add
a custom control policy here as part of the wizard process,
but it does add it on the backend
to that custom options that exist up here.
So it's just nice to kind of go through the flow
of where things actually are sometimes.
So either way, I'm going to import
this custom control policy we call CC challenge.
And from here, I'm going to click next.
We're not going to do anything on the data side.
And now I'll call this centralized challenge policy.
So centralized challenge.
And on the topology here, we're going to add a site list.
So the site list is going to be for sites 11 and 12.
And we want to apply this in the,
whoops, grabbed the wrong one, in the outbound direction.
So we'll make sure we put it correctly
in the outbound site list.
So basically what we're saying now is
as we send these routes towards sites 11 and 12,
we're going to filter out any TLOCs
that we learned from sites 11 and 12.
And from there, I'm going to click,
well, first of all, the add button as we saw,
and then save policy.
Now we see this sent challenge policy
right here in the middle.
I'm going to click activate.
We can take a look at what it's going to do here.
Everything should be in good shape.
It's probably going to remove the policy
that was on there already.
Yeah, that policy we made for DIA, that's fine.
So we've got a control policy in place
and we're looking at these sites.
Oh, whoops, no, these are the lists, sorry.
Now we're matching TLOCs from this site list
and we're rejecting them.
Meanwhile, we're going to accept everything else.
And then we're applying this to the sites
under apply policy.
So that all looks good.
We'll allow this to apply and then we'll go to the CLI
to confirm that it's working.
All right, so it was successfully pushed.
Let's go to the CLI.
So we're on edge 11.
Let's go and do a show SD-WAN BFD sessions.
We should see that we only have connections now to site,
there will really edges 13 here and 14
across the two different colors.
So, hey, the TLOC filtering is working.
What about routing though?
Let's see what we have on the edge 11 here.
So I do see my own installed local routes,
but I do not see any routes that are,
oh, right here, there it is.
Okay, I wasn't looking at it right.
So we've got our local routes here, that's great.
But look at site 12's subnet.
Notice it's pointing to edge 13.
So that's exactly what we were looking for.
So if I do a show IP route VRF 10,
we're gonna find that edge 12's subnet
is attached via site 13.
So if I do a trace route towards 10.10.12.50
and whoops, okay, yep.
That is not working because I did not specify the VRF.
VRF 10, there we go.
Now we see we bounce off of edge 13 first,
then we land on edge 12
and then we hit the host over at site 12.
So our policy worked.
We can go ahead and remove that policy.
It might be a good idea to remove that before moving on.
Otherwise, let's go ahead and keep moving
as we get into data policies.