So here's what we're going to do.
We're going to take our topology,
and we know that our topology has a couple of sites
that are managed by our manager,
so site 11 and edge 11 here,
site 12, which is edge 12,
and we have this network over here,
10.10.12.0.24,
and it's part of VPN 10,
and we have an Ubuntu host here
that has the .50 address.
So what we'd like to do here
is make it so that edge 11
isn't allowed to go straight here
to what will become our ultimate T-lock.
This is going to be the ultimate T-lock here,
but I want to leverage edge 13,
and that's going to force,
potentially, depending on how I configure it,
edge 11 to use the intermediate T-lock,
which will then get reflected down to edge 12.
If I do a tracer out,
I should be able to see that now edge 13
has been injected into the path,
whereas otherwise it would just go straight to edge 12.
So let's go ahead and verify
that it is going straight to edge 12
and that our Ubuntu host is reachable from edge 11.
I'll just do a quick ping from vrf10
to 10.10.12.50,
and then I'll do a tracer out also in vrf10
to 10.10.12.50,
and we do see that we're going straight to edge 12.
This would be edge 12's internet address,
and then we land on the Ubuntu host.
So the goal of this session
would be to configure our T-lock actions
such that we're going to see edge 13
showing up in this list.
But first, there's a preliminary step
that we're going to need to take,
and I realized I just lost my diagram.
There we go.
We're going to have to configure a special command on edge 13.
So let's go ahead and pull up edge 13 here.
We're going to do a config-t,
and if we look at Cisco's documentation,
it's going to require us to configure a service
known as traffic engineering,
and the way we do this or do that
is by configuring service te,
which again stands for traffic engineering,
and then we'll find that we can apply this
to the global vrf.
So I'm just going to hit enter here
and then commit,
and with that service in place,
that's going to allow this type of behavior
so that edge 13 knows what to do with the traffic
when it receives it.
So with that in place,
let's go ahead and swing over here to our SD-WAN manager.
What we're going to do is we're going to need to configure
a centralized policy to make this happen,
which should make sense
because we're influencing all of this
and enforcing all of this via OMP updates
coming from our controller,
and if we're ever doing anything like that,
then this is going to be a centralized policy
that we're going to have to deploy,
and it's going to be a control policy,
centralized control.
So what we're going to do is come up to our custom options,
and even though the interface is a little confusing
about how to go about creating custom control,
for lack of a better word, topologies,
we're going to have to come to topology,
but we just might not expect it to be under this.
So I'm going to come here.
I'm going to add a topology.
It's going to be a custom control policy.
I'm going to give it some kind of name here,
and let's just call it tlock action policy.
Why not?
And so this is going to use tlock actions,
and we're going to add a sequence type,
and it's going to be the route sequence type.
I will then add a sequence rule,
and the goal here is to do a match action type of statement.
I want to match on a certain set of traffic,
and I want to, again, we're thinking about OMP routes here,
so like site 11, for example.
Well, in our case, the diagram that we drew out,
we're going to change the way
we're routing towards site 12 routes.
So we're going to want to match against site 12 routes
and then include an additional tlock.
So let's go ahead and see this,
and we'll just go ahead and build it out
one step at a time here.
So again, I'm going to match.
We should be able to apply a site list here of site 12.
Perfect.
And then I'm going to go over to actions,
change it to accept,
and then the first thing I need to do is define the tlock.
So I'm going to add tlock here.
I'm going to say, hey, we're going to go to a new tlock,
and I could enter in a tlock list here,
or I could just enter in the IP address.
So for site 13, it's 13.13.13.13 is the tlock IP.
I can choose my biz internet and IPSec.
Or again, in production,
we'd probably want to use a tlock list.
So either way, I'm going to save match in actions,
and I'm going to come over to default action,
and I want to change this over to accept.
Because if I don't do that,
then all of the, anything that's not caught by this,
basically all non-site 12 routes,
they would be rejected by default.
Now notice what I didn't do yet.
I didn't do anything with tlock action.
All I did was change it
so that I'm adding the site 13 tlock.
So we just want to see what effect
that has on our environment.
So I've created the, again, the topology,
the custom control topology.
And I'm going to now,
actually just click up here to centralize policies,
and we'll create a centralized policy.
We're going to skip through the groups of interest,
add a topology, and we'll import an existing one.
It's our custom control.
And I said that we'd, what do we call it?
Tlock action.
So I'm going to import this, click next,
and we'll skip this because we're not doing anything there.
And our policy name will be custom tlock action.
And policy description,
we'll just say redirect through site 13.
And then where do we apply this?
Well, we're going to apply it to a site list.
I really want to make sure this gets advertised to site 11.
So I'm going to say site 11 as my outbound site list.
So now site 11 should see its routes updated.
So let's see how this is going to impact things
before I save the policy and apply it.
Let's go look at edge 11.
So here on edge 11, if I do a show SD-WAN OMP routes,
and I look and see how edge 12 here,
our site subnet 10.10.12.0.24,
that this is accessible via biz internet and MPLS
going directly to site 12,
these T locks attached to site 12 over here.
Now our focus is just on biz internet
throughout this core skill.
And so that's what we're really looking at here,
but it's kind of important for us to see
what it looks like before we start making changes.
So let's go ahead and go back and make those changes.
And let's see here, add a VPN.
Oh, I haven't clicked add.
Yeah, this resolution gets a little bit harrowing sometimes.
Scroll down, there we go.
There's the add button.
All right, so now we've added it.
Now we'll save.
So our policy is right here at the top,
custom T lock action.
I'm going to activate it.
And we can click on this and look at the config diff
to see how it's configured at the CLI.
Scroll all the way down.
We're going to find under policies.
Yeah, we've got our lists that we're pushing down.
And then right here, control policy,
T lock action, we're calling it.
We're matching route on site 12 and we're accepting it.
And then we're setting a new T lock.
We're saying, hey, use this T lock, color biz internet.
Here's the IP address.
Default action is accept, which is important.
And then we apply it to site 11 in the outbound direction.
Meaning again, from the perspective of the controller
outbound to site 11,
I am going to advertise routes in this fashion.
So again, just to remind ourselves,
we haven't applied T lock action yet.
We're only setting a T lock.
So that's basically us saying,
we don't need the redundancy.
We're just going to completely change the T lock
that we send it towards.
So let's go ahead and see how that impacted things here.
Once it's done, it looks like it is indeed done.
We'll flip back over to the CLI
and we'll do the same command, show stwan omp routes.
And things are looking a little bit different.
Notice 10.10.12, this is the site 12 IP address,
is going towards site 13's T lock address via biz internet.
So we also have lost the second entry.
So we only have one entry because of our hard override
of what we were normally sending out.
So if I were to, let's try pinging it first.
Okay, we can get to the host.
Let's do a trace route.
And it looks like we do send to site 13 first.
And then site 13 hands it over to site 12.
And then we do reach the Ubuntu server.
So that was effective, but this is not going to work
if site 13 were to have any problems.
And we can, it's something to play around with in the lab.
I'd encourage you to do that for the sake of time.
We're just going to assume, hey, if that goes down,
then this path is going to break.
What we really would rather have
is a method for making this redundant.
So let's go ahead and do that.
Let's switch back over to our manager interface.
And we'll go back here.
And what we want to do is edit our custom control policy.
So I'm coming all the way in.
Nope, not there.
We need to edit the current one.
And so I'm going to edit this one, tlock action,
and come in here where we added the tlock.
And now I'm going to add another entry,
which is a tlock action.
So, oops, we're on the match side.
Tlock action is an option.
And now I can use this dropdown
to pick one of those three options we talked about.
So let's go ahead and make this a primary path
so that we do have some redundancy.
So I'm going to click save match in actions.
We'll save and activate this by pushing it to the controller.
And under this configuration,
we will now see that we have a tlock action statement.
So same thing, I'm setting,
and I'm setting the tlock that we said,
but I'm now declaring this to be the primary.
So I'm not just overriding it.
I'm also saying that, yeah, this is just the primary.
This is becoming an intermediate tlock.
And what I really want to do
is leave the ultimate tlock in there.
As long as there's a tlock action statement,
we're still going to advertise the ultimate tlock.
So I'm going to allow this to progress.
And once it's done, we'll take a look at the CLI.
All right, it's done.
Let's flip over to the CLI and take a look.
So first of all, we will go ahead
and take a look at our OMP routes here,
show SD-WAN OMP routes.
And now we notice that we've got
a lot more information happening.
Whoops, not there, here.
Yes, well, that's all part of it.
So we've got site 13 routes and we have site 12 routes.
Why do we have both?
Well, because this is the primary.
Notice which one has the C, I, R.
It's the first entry here,
which is saying to go to site 13 via Biz Internet.
I know that the resolution gives us many lines
to look at here,
but this is what we're trying to focus in on
is the fact that we have chosen it,
that's what the C is, installed and resolved it.
So that means that we are using this path.
We are not using these other paths down here
because we are not trying to use these.
These are the ultimate tlocks,
but we said to use the intermediate T-lock
as the primary.
We can see this in more detail
if we add detail to the commands here.
And if I space down to where we see
route 10.10.12.0,
I can now see right away in the attribute section
that this one that we're using
has the primary set for our T-lock.
And specifically, we've got this whole thing
called ultimate T-lock.
So the ultimate T-lock we know is site 12.
And this is not just something that I made up.
Cisco calls it that right here in the CLI.
It's called the ultimate T-lock.
Now, we don't call it the intermediate T-lock here
for one reason or another,
probably because we're just using the command set T-lock.
But either way, this is the intermediate T-lock.
Also notice that when it says primary here,
it's not saying that this is the primary.
That's a little confusing.
It's saying that we're using the primary concept,
which means that the intermediate T-lock
is actually going to be chosen.
So just to confirm that,
and then we can do the trace route.
And we do see that we're still going through site 13.
And then we go to site 12.
So we do reach our destination,
but we have to go through site 13 to get it done.
So that is how we go about configuring
the T-lock action statement as part of a control policy.
Our custom control policy,
in order to push that out in centralized fashion
and make it so we're using either the intermediate
or the ultimate T-lock.
It just depends on whether we're setting it
to primary or secondary, or for that matter, ECMP.