All right, we're gonna jump into SD-WAN Manager, but before we do I just want to
take a moment to define our goals for what we're going to log in and create. So
we're gonna start with our topology here, sites 11 and 12, and then site 13 over
here has a couple of edges, but they're the same site. And what we want to do is
we want to change things up a little bit to keep things fresh, because as we said
in the last video, we're gonna create a hub and spoke topology, but we're gonna
change our hub. We're gonna make site 11 and ultimately edge 11 our hub site. And
so from here now we've got site 13 over here, and so site 12 is gonna be a spoke,
site 13 is going to be a spoke, and we don't want the spokes to communicate. Or
at least at this point we are again replicating what we had, which is saying
that we don't want them to form tunnels, and we don't want them to communicate,
although later we're gonna see that we can, you know, do one or the other if we
so choose. So for right now what we want is we want to see that hub or site, the
hub, forms tunnels to the spoke so sites 11 and 12 can communicate, and then 11
will be able to communicate with 13 and 14. Now also keep in mind from a topology
perspective that we have two different transport mechanisms, so this topology
should exist for both Internet and MPLS. So I should be able to see that I have
tunnels across, going from site 11 from hub 11 to all three of the other edges
across both of those transport mechanisms. Now let's also recall how
exactly we're going to do this. We've got our controller up here, and our controller
is going to enforce this policy. So what policy are we enforcing? Well we want to
make sure that when we're advertising to one of these spoke sites that we are
excluding the spokes. So I'm not sending 13 information to site 12, and I'm not
sending site 12 information to 13, although certainly I want to give all of
the information for 12 and 13 to the hub. So I am sending site 11 information, and
so we'll create this topology that essentially says, hey let's accept that
we're sending site 11 and reject the rest. This is going to apply to both
routes and TLOCs as we'll see, and then from there we need to decide whether
this is an inbound or outbound policy, but because this is centralized, it's
coming from the controller, and given that it's from the perspective of the
controller, right there, we know it's an outbound policy. I'm enforcing these
things outbound, that's the direction of the arrows here, outbound from the
controller. So never forget our perspective, whether it's from the edges
perspective or the controller's perspective, in our case centralized
control policies are coming from the controller. All right, let's go ahead and
jump into our SD-WAN manager. We're going to go to configuration, go down to
policies, and under our centralized policy here we see the original topology we
created, which was a hub and spoke topology, and if I use the ellipses here
I should see that I can activate it, meaning that it's actually in a
deactivated state. If I can activate it, that means it's not actually already
activated. So we're going to go ahead and start by coming up here to custom
options and going to my lists. Remember I could also just start creating a policy
and that would give me access to all of my lists as well, but what we need to do
here is we actually need to create a site list right here that includes sites
12 and 13, because we're going to lump those together as spokes. So let's go
ahead and create it in the same format as what we did before. I'm going to say
sites 12-13, and this can be comma separated or it can be a dash, they're
right next to each other, so either way we'll just create this site list here,
and now we have a site list that consists of those two sites. So from here
we're going to go ahead and create our policy. So let's go back to centralized
policies, say add a policy, and again this is the part we can skip now because we
already created all of the groups of interest that we want, just gives us an
opportunity to do that, and now we're on the topology tab and I can add a policy
or topology rather. So remember we did hub and spoke earlier, we've talked about
mesh, something we can play with in the lab if we so desire, but right here
custom control policy, this is what we have been talking about. It's a topology
that is custom built, so I'm going to click this and it's going to take me to
an interface that's going to represent to us that we are effectively creating a
route map. So over on the right we already see a default action which is
saying that we're going to reject everything that is enabled. So from here
we're going to start to build this out as if it's a route map, but first let's
go ahead and give it a name and description. So our name, we might as well
call it something like custom topology hub and spoke, and in the description
we'll say that this is a site 11 as hub. So that way we can remember which site
is actually the hub. So again we've got the default action here, so that's great.
We're going to want to add a sequence type and we're given the choice of these
two, route and T-lock. So we're going to go ahead and start with the route policy,
but always keep in mind what's happening behind the scenes here. It shouldn't be a
surprise that we've got the ability to manipulate routes and T-locks because
that's what the hub and spoke topology did. We talked about that. It limited the
routing information which affected reachability. It also changed T-lock
information which is going to change how the tunnels are formed. So we're going to
do both here. We're going to start with a route policy. Over on the left we're kind
of building this out, but within our route policy now we need sequence rules.
So I'm going to add a sequence rule and this should feel familiar if you've ever
really done route maps before. If not, that's perfectly fine because all we
need to do is the concept of matching and actions. I match traffic and I apply
an action to it. So that's what I'm looking to do here. So what are we going
to match on? Well Cisco gives us all of the options here and at this resolution
we're gonna have to scroll over to see them all, but I can match on site for
example, VPNs, T-locks, preference, all of these kinds of things. So I'm just going
to click site and I'm going to add my site 11. So remember our game plan. We
want to allow site 11 routes to all of the sites, but we want to limit the other
one. So I can do that in one of two ways. I could allow site 11 and reject the
rest, or I could deny specific sites and then add an accept all at the end. In our
scenario it doesn't really matter, but for scaling it's usually better to do
the first type. So I'm going to accept site 11 here and furthermore I'm going
to match on the VPN. So we do need a VPN list here because we need to know which
routes we're actually restricting. So I'm going to say VPNs 10 and 20 here using
the VPN list that we've created in past skills. Now we might think that we're
done here. We've set what we're matching, but keep in mind if I save it says save
match and actions and we haven't actually set the actions yet. So never
forget that part. We have to scroll up and click actions here and if we're
rejecting it then, which is the default we'll notice, then it is what it is.
There's nothing else to do. But if I accept it now I can start to play around
with things. And as we said before I can just flat-out accept it and be done, but
I can start to do some interesting things. So for example I could set
community tags, OMP tags, and preference. This is a big deal. I can set my OMP
preference here if I want. Let's say I want to set it to an OMP preference of
100 and that allows me to now set OMP preference on the routes that I'm
advertising. I can also change the next hop and we'll explore that later on via
this TLOC option, but for now let's just call that good. All of the routes I'm
advertising I'm going to accept the routes from side 11. I'm going to say
they have an OMP preference of 100. So now we always have to be careful
with the UI. It might be tempting to save the control policy, but we first
have to save our match and actions here. Now we might be tempted to come down and
save our control policy, but we're not done yet. Remember we had those two
different types of control policies, so we want to add a TLOC policy as well. So
I'm going to add a TLOC policy here and notice over on the left here again we're
kind of forming a route map of sorts where we've gone through the route as
one match action set of statements. Now we're going through TLOCs and then the
default action happens after each one of these has been run. So we're going to
create a sequence rule here and once again I'm going to select site and I'm
allowing site 11 TLOCs to be advertised to sites 12 and 13 or at least that's
the goal. So I've got my site selected. Now notice these options are different
and that's because these are all the attributes of a TLOC route. So when I see
preference here it's talking about a TLOC preference not an OMP preference.
Routes are about OMP routes or V routes. TLOCs are about TLOC routes. Remember
and never never ever forget I guess I mentioned earlier what's happening on
the back end is we're enforcing policy by way of OMP route advertisements. That
might be V routes, that might be TLOC routes or service routes. For the most
part it's going to be V routes and TLOC routes which is why those are our
options here in the policy enforcement. So either way we're going to accept this
so click over to actions and I'm going to click accept and yeah we could change
things if we wanted to but we're not going to change anything we really just
want to advertise our site 11 TLOCs to the other sites and so scroll down save
match and actions. So I can click back and review that the route here we're
matching site 11 and accepting it and yes changing the preference. You can also
maybe expand this and see that there's a VPN list associated with that and the
same thing with the TLOC I can see that we're matching site 11 TLOCs and
accepting that and then the default action is rejecting. This is where I
would edit this if I wanted to but we naturally do want it to be rejection. So
that's our policy in a nutshell. We're going to save our control policy but
we're not actually done yet we have added a topology into our centralized
policy we're building up but we've still got these other steps to go through. So
I'm going to click next down here and this is where we can add in traffic flow
types of information we're just going to skip through that and now we just have
to provide a name for our control policy that we're creating. So I'm just going to
call this that this is a custom topology and it's a hub-and-spoke with 11 as the
hub something along those lines so I could just say custom topology here with
again site 11 as hub something that's somewhat helpful. So that's great we're
not done yet we're still not done remember we have to do a little bit more
when we're attaching a policy. I need to click this button right here to add a
site list it's a little confusing how this reads it's either a new site list
or a new WAN region list. So I really want to add the site list so I'm going
to click this and then we see the two options here so I'm going to keep site
list selected and this is where I decide whether it's inbound or outbound. So I'm
going to say it's outbound the question is where do I send it I want to send it
to sites 12 and 13. Now is this required at this phase no because I could have
selected two different site lists and 12 and 13 which we've defined before but it
does make it a little more seamless and we'll use this later as well. So I'm
going to go ahead and click the add button here and now we can save our
policy. So now we've created this custom topology inside of it or well I should
say a centralized control policy that within it has a custom topology. So it
takes a little while to kind of create policies understand the hierarchy there
but this is a centralized control policy that we're going to deploy and within it
it does have that custom topology as I just said. So now we're going to click
these ellipses over here and I'm going to select activate. I'm going to be able
to see the config diff if I want to and again I would always recommend doing
this especially as we're learning SD-WAN because I can also learn a little bit of
CLI here. For example again within the policy hierarchy I create my lists I
created only the lists that I'm going to use not all of them vManage is aware of
but all the ones I'm going to use so my VPN list my site list for 11 and my
site list for 12 and 13. Interestingly as part of this Cisco is going to create a
IP prefix that defines any subnet and attach it and then we're creating that
control policy again and within that control policy we're really creating a
custom topology so terminology and all that. So we see that this is turning into
a route map we've got sequence one or matching routes again this is where
Cisco throws in the prefix list but we you know the part that we care about is
the site list and the VPN list and we are accepting that so furthermore we're
then setting preference but importantly we're accepting that we're sending site
11 routes this is matching routes here. Next we're going to match on TLOX again
site 11 and we're accepting and then the default action is rejection. Then we have
to apply the policy down here including the direction of outbound. So again
getting more comfortable with the CLI is important but ultimately it's also
doing it for us so we can just click the activate button and allow it to roll out.
So once this is good we are going to switch over to the CLI and make sure
that everything was deployed successfully. So there's our validation
success so let's go ahead and flip over to the CLI. So naturally I've been logged
out of Edge 11 here so let's just go ahead and get logged back in and I'm
going to do a show IP route for VRF 10 which is look at 10 or 20. Remember this
is now our hub site so I see routes to sites 12 and 13 no problem as well as
some of those EIGRP and BGP routes that we chose to advertise out of site 13 so
that's great. But then if I look at I guess we might as well while we're here
look at our BFD sessions which tells us information about our tunnels and as we
mentioned we're expecting to see tunnels to edges 13 14 and 12 12 13 and
14 out both of our transport so here's our MPLS links 3 MPLS links is good and
then our biz internet links so this is to site 14 or edge 14 edge 12 and edge
13 so exactly what we drew out here just keep in mind it's per transport as well.
So let's go and take a look at edge 12 which also has been logged out of and
we'll do show IP route for VRF 10 and now it's interesting we're on a spoke
site I can see my route to edge 11 if I do a show SD WAN BFD sessions again I
see that I have forming a connection to edge 11 across both transports MPLS and
biz internet but I'm not forming any connections to my other spoke site here
or site 13 so edges 13 and 14 if I go to edge 13 which also has been logged out
of we could do the same commands show IP route VRF 10 and see that I can see my
local routes these are all my local routes down here otherwise I'm from OMP
which is the little M as always I'm only seeing information from site 11 so SD
WAN BFD sessions should confirm that I'm only building tunnels to site 11 so
that is exactly what we wanted to accomplish now before we go I want to
ask a little bit of a challenge question here because up until now the only edges
that are managed by the managed by our manager are edges 11 and 12 we just saw
the edge 13 is impacted by the changes we just pushed out by manager so pause
the video for a moment if needed but think through everything we've talked
about about how this works and answer the question why was edge 13 impacted by
changes made from man our SD WAN manager all right well you have your answer
because it's right there in blue in this diagram remember our policy is enforced
by our controller pushing out routes or choosing not to push out routes why was
edge 13 impacted because our SD WAN controller sent it information about
edge or site 11 it sent it a route from site 11 it sent it T lock information
from site 11 it just neglected to send it any information about site 12 so the
omission of information is why site 13 was impacted and why we didn't have to
make site 13 our hub or anything like that our topology is not restricted by
which devices are SD WAN manager managed instead it's all impacted by OMP
and enforced by OMP thanks to the way the controller sends those updates so
it's the fact that we're manipulating control plane information that's why
that works it is a centralized control policy and in the end we were able to
build out the topology that we wanted