So we've already talked about the fact that when we're creating a hub-and-spoke topology in SD-WAN,
if we really want the spokes to be talking to each other in the real world, we should really just allow tunnels to be built.
But maybe there's a reason why we don't want that.
Or just in general, what if we're just trying to get comfortable with this concept of custom topologies?
If we want to stick to the script, then we would choose one of Cisco's hub-and-spoke or mesh topologies,
but we've just created a custom topology.
And keep in mind, we've already seen how we can customize it.
We already set OMP preference as an option that doesn't exist in one of Cisco's more template-style of topology deployments.
But we can also make it so that our spokes can actually communicate with one another.
So how are we going to do that?
Well, the way this happens is by analyzing, as always, what exactly is happening under the hood here.
So under the hood, we know that we have the controller, and it is pushing our full information to the hub,
but it's only pushing site 11 information to sites 13 and 12.
So that is true for both the route and the TLOC information.
So routing is why we can't actually route to one another, because we're filtering the routes from each other.
So they're not aware of it.
And the TLOCs are so that we don't form tunnels.
So that's well and good.
Let's say that we allow the routes to go through.
So that's fine, except we still have a problem.
What is the next hop for a V route?
Think back to when we learned about OMP and we're configuring it.
The next hop is always a TLOC in the SD-WAN space.
This is a checkmark, by the way, to say that we're receiving routes.
So what if we're receiving routes?
Is that good enough?
I'm now receiving a route from site 13.
It's not enough because the route is pointing to this TLOC here, and site 12 doesn't know how to get to that TLOC.
So if we really want to share site 13 information, not only do we need to share it, but we need to update the next hop.
And where are we going to update the next hop to?
Ideally, a reachable TLOC, which would be the TLOC at site 11.
So in order for us to make our spokes be able to communicate, we need to do two things.
I'll write it in here.
Number one, we need to allow the route.
But number two, we need to update the next hop and point that to site 11.
So those are our two goals for our configuration.
So let's go ahead and jump into SD-WAN Manager and see how we can go about doing this.
So we're going to go to configuration and then down to policies.
And first of all, we need to create really a one list, but maybe a couple lists depending on your configuration.
So first of all, the site list.
We need to make sure we do have a site list for sites 12 and 13.
I just did this in the last video.
As you are going through and you decide you don't want to make the site list for the last video, if you happen to do that, that's fine.
But now you're going to need to create it.
So we need that site list if you haven't made it.
We are also going to need a TLOC list.
We've not created one of these yet.
Let's go ahead and create it.
These TLOC lists are kind of interesting.
I can create a list of TLOCs that might need to be referenced at some point, and we're certainly going to reference them here.
So I'm going to create a TLOC list called site 11 TLOCs.
Name hopefully includes a little bit of a description in there.
So remember, what is the IP address and the color and the encapsulation?
What's this all about again?
Well, as we recall, TLOCs are a 3-tuple of information, so we're basically saying anything that matches this 3-tuple is a TLOC that we need to include.
The TLOC IP address is not the reachability IP address.
Like, it's not its public IP address on that edge device.
But instead, it is the system IP address, which is included in the 3-tuple.
The system IP address for my site 11 TLOCs are going to be the all 11s address.
And then the color we can include as, let's go ahead and do bizinternet first, encapsulations ipsec.
And then I'm going to add another TLOC, which has the same IP address and the same encapsulation, but it's available via a different color.
So this one would be MPLS.
So these are our two TLOCs at site 11.
These are the hub TLOCs that we're going to want to use as a next hop.
From here, I'm going to click save.
And now we have our TLOC list created.
So perfect.
We're good to go there.
Now I can exit out and go back to centralized policies here.
And what we want to do is we want to edit our custom policy.
Now we see that our custom policy is still activated.
It's still in use.
So I'm just going to go to edit here.
And then this tab at the top is the topology tab.
So we're going to come here, and this is where we see that custom hub and spoke topology deployed that we used earlier.
Now at this point, we might want to come here and edit it, except we see that we actually can't edit the topology that's already deployed.
So what we need to do is create a new topology, but it's mostly the same as what we want before with just a couple of changes.
So I'm going to use the dropdown, and I'm just going to say let's copy it.
We'll call this, we'll just call it routing topology hub and spoke.
And this is a hub and spoke with full routing.
All right.
So we're going to copy it, or create the copy rather.
And now this new one, we can actually edit this.
All right.
So, well, now we have to think about what we're trying to do.
Remember, the T-lock policies are really the rules.
This is to block T-locks and allows us to make sure that we're properly filtering the tunnels, and we want to keep that in place.
What we really want to do is extend routes.
So what we're doing, first of all, is we're advertising site 11 routes and accepting them.
We don't want to change that.
I want my site 11 or my hub routes to still be advertised.
But what I do want to do is add a new rule.
So I'm creating a second rule here, and I'm going to, once again, match on the site.
But this time, I'm going to match on sites 12 and 13.
So at this point, I'm saying, hey, I'm going to advertise routes from sites 12 and 13 to sites 12 and 13.
But we're going to do more than just advertise it.
I'm going to go to actions here.
I'm going to accept it.
I'm going to say, hey, we are allowed to send these routes, but now I want to make a change.
We alluded to this earlier, that we're going to add the T-lock property here, and we're going to change the T-lock or the next hop to something else.
What are we going to change it to?
We're going to change it to say that it's reachable via the site 11 T-locks.
So that is how we're going to go about doing this.
I'm going to click this save match in actions.
And we should see, as I scroll down here just to center it, that we've got these two match conditions, site 11 fully accepted.
We do change the OMB preference.
Again, that's a customization that's only possible by deploying a custom policy.
Then we are also advertising sites 12 and 13 subnets.
Again, this is not T-locks.
This is routes.
These are subnets.
And I'm accepting it, but I'm also changing the T-locks in the next hop.
So now I'm going to save my control policy.
I'm going to detach the existing custom topology.
Remember, this is the restrictive one.
We don't want this anymore, so I'm going to detach it.
And notice that it disappears.
The first time I did that, I thought, whoa, whoa, whoa.
I didn't actually want that to happen, I don't think.
But we're detaching it from the policy.
We have to keep in mind that what we have is we have a policy that we're creating,
a centralized control policy, and then we're giving it a topology to manage inside of it,
where we can also apply other things like application-aware routing and such.
Our focus is on the topology, so it feels a little unnecessary to have two different levels here,
where we have a control policy and then also a topology.
But that's exactly how this works.
So I'm keeping the same control policy, but I'm changing out the topology underneath it.
I detached one, and I can delete it later if I wanted to do that.
We'll take a look at that coming up.
But let's now make sure that this, the new topology that we just created, is attached, and it is.
Or is it?
We didn't see an attach option here, did we?
So what's going on?
Well, we're going to say save topology changes, and we're going to say activate,
and we're going to realize that something's wrong here.
What's going on?
It's saying that we need to specify how exactly this topology is going to get applied.
So what we need to do is scroll up and recognize that, remember, we're just on this topology tab.
We need to come over here to policy application, and remember this whole conversation before,
and we're sending this outbound to sites 12 and 13.
Now, again, I can just pick the one site list that has both of those in there and click add.
From here, I can now click save policy changes, activate,
and now I can use that config diff to make sure that this is doing what I think it's going to do,
scroll down, take a look at it,
and what we see here is we're accepting these routes from sites 12 and 13,
and we're setting these TLOCs to the next hop, and it's applied in the outbound direction.
So right name, right direction, hopefully we are good to go.
So let's go ahead and activate that, and then we'll go take a look at it at the CLI,
keeping in mind that before we applied all this policy that we were unable to communicate between sites 12 and 13
as the spokes.
So this is just about pushed, and then we'll switch it over to the CLI.
All right, let's go ahead and do that and flip it over.
If I do that show IP route VRF10, if I scroll up just a little bit, remember,
we don't have any information from site 12, but now if I look at it,
we do see that we have information from site 12.
But very importantly, what is up with this next hop?
Look at that.
It actually knows that it's via that TLOC from Edge 11.
And so if I were to look at, let's say, Edge 12, log back into that.
Show IP route for VRF10.
Same thing.
I now see the routes coming from site 13.
I see that subnet.
I know that I'm not able to communicate with it directly via site 13,
but I'm able to communicate via the hub.
So here's the big question.
Can I actually ping in VRF10 out to 10.10.13,
and then .50 as our Ubuntu host out there?
So now we have enabled communication, and we were able to do it by way of going
in there, basically creating a new topology.
We just copied the old one over, but we modified the route rule to say,
yes, we're going to allow those routes,
but we're going to change the next hop to be the hub so we can actually
communicate.
Now, one last note before we go.
As I flip back over to our SD-WAN manager,
I mentioned that we would take a look at a little bit of cleanup here.
So if I go back to – actually, I'll just click the back arrow here.
So up here, this link up here is worth paying attention to.
We mentioned that we created a topology within this policy.
We deactivated one of those – or detached, really,
one of those topologies, and it just sort of disappeared.
So where did it go?
Right here.
We see this topology link here.
This is going to show us all of our topologies.
We see the one that we created originally.
So even though we detached that, the topology is still defined.
It's still here, site 13 as a hub.
Meanwhile, I've got my full routing custom control policy that I created,
and we see that it is referenced.
It is attached right now to a policy.
And then we also have this one, which we detached.
It's not used any longer.
So I could come over here, and I could say delete
and delete that topology and keep my environment a little bit clean.
But I wanted to point that out because it can be a little bit confusing
as to where things are stored.
So I can come up here.
I can see my list.
I can see my topologies.
And if I want to clean up my actual centralized policies, for example,
these are not actually in use anymore, and so I could delete these if I so desired.
But it's important for us to try to keep our environment as clean as possible,
especially in a lab environment where sometimes things get deployed
and never actually cleaned up.