In the last skill, we took a look at deploying topologies.
And a topology is a centralized control mechanism.
Meaning that first of all centralized is saying that this policy gets enforced
thanks to the SD-WAN controller by controlling the flow of control plane information.
And so that's where the control concept comes from.
That this is affecting the control plane.
We are affecting what it is exactly that we're sharing.
So remember, OMP is going to share routes.
OMP routes.
We sometimes call these V routes.
But it's containing the subnets that exist on other sites.
And it also is going to share TLOC routes.
And those are what are responsible for forming tunnels.
So we have reachability being impacted.
And we also have the formation of tunnels being impacted.
So there's two sides of this.
When we look at our lab environment.
We've got sites 11 and 12 here.
And then we have a couple of edges over here at site 13.
We know that when we formed a hub and spoke topology here.
The hub and spoke topology basically said, hey, we're going to only form tunnels
using site 13 as the hub and sites 11 and 12 as spokes.
And so our tunnels formed like this.
Now our topology is not that large.
So we really only eliminated a single tunnel here between edges 11 and 12.
But we can imagine for a much larger topology with more spokes here.
That we're going to see that we don't need.
Or at least we're going to eliminate a lot more of these tunnels.
Not just between the ones that I just marked.
But also, for example, these two edges don't need to form a connection.
And so on and so forth.
So this is something to help us scale out.
Especially when we have larger environments.
But for our small lab environment.
We still see that we got rid of one tunnel.
And we understand that scaling up.
We could actually save ourselves a lot more.
But this also impacted reachability.
For example, now I'm not sharing routes between these sites.
Meaning that a host here at site 11.
And a host over here at site 12.
These cannot communicate with one another.
So this is interesting.
Because in a traditional hub and spoke topology.
We might expect that we could communicate by way of the hub.
But that's not how we ended up building this out.
And the reason for that is because SD-WAN changes the way that we approach network design.
With especially a wide area network environment.
We really would expect to be able to go through the hub.
And one of the reasons for that is simply that we in traditional WANs.
Use the hubs to simplify our topologies.
Rather than having a whole bunch of partial mesh connections.
Maybe full mesh connections.
Rather than doing that.
We can simplify our wide area network circuit needs.
Create a hub site.
Have it communicate out to all of the spokes.
And then they communicate through the hub.
But remember with SD-WAN.
We are no longer relying on the underlay to define our topology.
Instead we're creating an overlay with all of the tunnels.
And so if.
Again we rewire our brains a little bit.
If we are saying that we want a hub and spoke topology.
Then Cisco is saying okay.
Well if you want a hub and spoke topology.
These two concepts should really be bound together.
Because if I really want sites 11 and 12 to be able to communicate.
Then we just build this tunnel here.
And allow them to communicate.
But we're saying we don't want the tunnel.
And therefore we must not want reachability either.
And to be fair in most cases.
They're probably right.
I mean if we have a retail organization.
We've got a bunch of retail stores out there.
Those stores don't usually need to communicate with one another.
So we can save on tunnels.
And we can prevent reachability.
For hosts that have no business talking to one another.
Which is good for security.
But let's say we did want to crack this open.
We said hey.
We don't want reachability and tunnels to be tied together.
We really do want these hosts to be able to communicate through our hub site.
Even though we're trying to cut down on the number of tunnels.
That's perfectly fine.
We can do this.
The problem is that our topologies as we've seen.
We had two topologies.
We have hub and spoke.
And we have one we didn't take a deep look at.
But we have another option here.
Which is a mesh.
Where we sort of define which sites can communicate with which other sites.
The problem is these are templates.
Provided by Cisco.
Via our SD-WAN manager interface.
And they're going to make it so that ultimately.
The reachability and tunnels are tied to one another.
So if we really want to break this open.
We do have a third option here.
And that is to create a custom topology.
Where we have a whole lot more control.
And we can crack open the bond between reachability and tunnels.
And furthermore crack open the bond here.
That we have.
Or maybe the set of rules that tell us.
That we are going to have to define hub and spoke sites.
And define which sites can communicate.
Instead we can pretty much do whatever we want.
Again we're returning the level of control.
Or a level of control to us that we just don't have.
With Cisco's templates.
The hub and spoken mesh templates.
So what exactly is a custom topology?
Well a custom topology is going to create a route map like set of definitions.
Route maps are famous for their match action statements.
We're going to match on a particular something.
Traffic or control plane information.
We're going to match our traffic.
And then we're going to perform an action.
So then also we're going to have a default action at the bottom of the route map.
That's going to take care of anything that we don't match against.
Sort of our catch-all bucket.
Now matching is going to operate based on lists.
Lists are a very important part of our control policies and data policies as we've seen.
We're going to use those here again.
And then our actions are going to be one of two.
It's either going to be accept or it's going to be reject.
Incidentally so is our default action.
It's also going to be accepting or rejecting.
And by default it's going to want to reject everything.
As we've said before we already have an environment in a architecture that allows everything.
If we want to deploy a policy against that and we want everybody to communicate to everybody.
Well then we already have that.
So usually the assumption here is that we want to explicitly state what devices we want
communicating and then deny all of the rest of that.
Although certainly we could reverse that if we wanted to change the default action to allow
and reject specific sites from communicating as well.
Now furthermore as we'll see if I change the policy to accept.
I then have other options that I can deploy.
So for example I'm bringing in a route.
I'm saying yes I've accepted that we can pass that route along.
But now we want to play around with some things.
For example a big one that we might want to take a look at is the idea of setting OMP preference.
We've alluded to OMP preference but we haven't yet configured it.
Because it's required to configure it as part of one of these control policies.
But that's a very big part of our traffic selection.
And some environments is going to need to set OMP preference.
And so this is how we go about doing it.
Now when we're deploying one of these custom topologies.
It's still centralized and it's still a control policy.
Meaning that we're enforcing this via the SD-WAN controller.
We essentially looked at this as such with site 13 on the right.
Sites 11 and 12 over here.
And we said that we want to learn everything.
So all of the inbound is fully learned.
That's all good.
But on outbound I want to send everything to site 13.
But I only wanted to send site 13 information down to 11 and 12.
Which means 12 doesn't know anything about 11.
And 11 doesn't know anything about 12.
So that's how we ended up doing it.
But before we also said that this was going to impact our routes as well as our tunnels.
Well we just mentioned that we can split this wide open now.
So with the control policy I can still do this for the sake of the tunnels.
But with the routes I could just accept all of them.
And so now I can actually send 12 and 13 routes to site 11.
And 11 and 13 routes to site 12.
And yet we're still with the tunnels restricting it only to site 13.
So now we will be able to see where the other site is.
And receive those routes if we so desire.
So what we want to do is we want to jump into the lab.
But we want to take this in two steps.
First of all we want to replicate what we did earlier.
We're going to replicate the hub and spoke using or via a custom policy.
So we'll start with that.
Just to make sure we understand how custom policies come together.
But then second of all we're going to do this concept of breaking things open.
And we want to make sure then that we can create a custom policy
that goes against the templates that Cisco created for us.
So let's go ahead and jump into the lab and start to make this happen.