Well, we are going to talk about the concept of a direct internet circuit or
DIA, and this is a specific feature of Cisco's SD-WAN topology. So, what exactly
we can do here is we can ask a question. We're looking at our remote sites. A lot
of our remote sites are going to have an internet circuit as one of our
transports. This is pretty common because one of the advantages of SD-WAN
is I don't need multiple MPLS circuits, which are really expensive. I can just
use an MPLS along with an internet, and in some cases, I could use dual internet
circuits. So, if I've got a site here, let's call this site 11, edge 11, and we
know in our lab environment we've got a connection to MPLS, and we've got a
connection to the internet, and we're using that to connect to our headquarters
location. We'll call this our site 13. We'll just draw a single edge here, and
so we know that we're forming our tunnels across these different transport
mechanisms, and so the question is when I have a user here at site 11, and I want
to go to the internet, how exactly does that traffic flow? Well, if we just follow
the routes and we're stuck inside of a VPN, we know we're in VPN 10 here, let's
say, and what VPN is this a part of? Well, this is part of VPN 0, which is part of
the underlay, which means I can't just exit that interface as if it's a normal
internet circuit. I would have to follow my default route over to headquarters
site 13 over here, and then I would have to go through whatever firewall is
here, and then go out the primary internet circuit. Now, this might be a
firewall that's going to protect me. This might be intrusion prevention systems.
We could have URL filtering here. This security suite of products usually
exists at the headquarters, so this traffic flow is not necessarily a
problem. We might, in fact, prefer this, that this device, which is a corporate
PC, let's say, we want it to go out through our own security mechanisms to
get out to the internet, and to do that, it's just going to have to transport
over to site 13, so it's not necessarily a bad thing, but it does raise a couple
of questions. First of all, what if I could pack this up and put it on the
edge? Could we implement this? Could we deploy our security out there, and then
would it be more efficient for me to go out the internet circuit that's here,
especially as it relates to communicating with software as a service types of
offerings? We talked about SaaS earlier in the course. We use a lot of software
that lives on the internet, that lives in the cloud. It's very common these days,
and me having to go through all of this just to go out to the internet, and then
allow the return traffic to come all the way back through, that might actually
create performance problems for my users. And lastly, we have another
interesting use case, which is what about our guest users? We're going to have
guests at a lot of our locations. Maybe we're a retail store, we offer Wi-Fi,
whatever the situation is, and do we need them to go through this whole path? And
usually not. In fact, we might actually prefer them to go out the internet
that's locally, and that's going to free up our internet circuit here at
headquarters. So whether it's one of these or both of these, we might look at
this and say, could we actually use that VPN zero internet circuit for local
internet traffic? So that's exactly what we are going to do using DIA. It's going
to allow for us to use local internet that is actually a part of VPN zero. So
the question is, how are we going to do this? Well, we actually have two different
setups. The first is a static configuration. If we want to do this, this
would be good for just a site or two, and we're going to require two
configurations. We're going to need NAT to be configured on that external
interface. And second of all, we're going to have to have a static route, a default
static route, and that's going to have to exist inside of our VPN. So let's say
VPN 10, and the next hop is interesting. The next hop is not
going to be an IP address. It's actually going to point to VPN zero in order to
allow the route leaking to occur, and NAT will allow the traffic to come back in.
The advantage to this, pretty simple to deploy. Again, a couple of sites, not too
bad. This is CLI based. We can log in very quickly and get it done. The
disadvantage, as we might imagine, is this doesn't scale very well. And so we
have to ask, could we deploy this a little more scalable? In other words,
could we deploy this via a centralized policy? And the answer is yes. Otherwise,
why would we be talking about it? So we can deploy this centralized, but
interestingly, this is a centralized data policy. We're not controlling control
plane traffic here. We're not leveraging the SD-WAN controller. We just need this
edge and potentially a whole lot of other edges to behave in a certain way. So
this becomes a centralized data policy, which might feel a little weird at first,
but it does affect the data plane, and we can push centralized data policies
out thanks to our SD-WAN manager. The way this works is our manager is going to
push this out to our edges, and it's going to affect the scope of a single
VPN. Furthermore, it's always applied inbound on an edge device, because as
traffic comes into this edge device, we need to know what to do with it, whether
it's coming into it from a user perspective, we need to NAT it out VPN0,
or whether we have return traffic coming back, and we need to apply NAT to it in
order to reverse the flow and get it back to the original sender. So it's
inbound, but it can affect both service and transport interfaces, so keep that in
mind as well. Now that aside, the process is very
simple, or very similar rather, to what we did on the static side. We have to apply
NAT to an interface, and we need to make sure that we get that static route in
place. So basically, this policy gets enforced just in a different manner.
We're going to push this policy from SD-WAN manager out to the edges, and
make it happen in the exact same fashion. So that's how direct internet access can
work. Again, we need to understand what its purpose is, and the fact that we can
deploy it in one of two ways, either statically via CLI getting in there
really quickly, or more appropriately, centralized via our SD-WAN manager.