Next up, we have eight questions about our data policies.
In the same way we just quizzed ourselves over control policies,
now it's time to dive into the data side of things.
So first up, what is the main purpose of a data policy in SD-WAN?
Well, this is just the flip side of what we talked about with control policies.
Data policies are going to impact the data plane,
and we even diagrammed this out previously.
We saw that when we were talking about control policies
at the start of the last quiz,
that data policies are going to impact traffic
as it's actually flowing through an edge.
This means that the enforcement point is not the proliferation
or the propagation or the sending and receiving of routes.
This would be the control plane mechanism
for managing what routes are received,
informing topologies and such,
because we can either send routes or we can withhold routes.
But in this case, we have all of the routes.
And so now we're talking about a packet arrives on the device,
and now we have to decide whether to send it or drop it or filter it
or change properties, whatever it is that we're doing there.
So that's the purpose of a data policy.
So again, we're not filtering routes and forming topologies.
That's control.
Also, again, controlling OMP peerings, that'd be control plane.
Onboarding has nothing to do with this.
It really is D, affecting traffic traversing an edge.
All right, question number two, and this is a good one.
What is the order that SD-WAN edges
evaluate overlapping access control lists on an interface?
Consider explicit and implicit rules as well as default actions.
So that's just a little hint if we can't quite remember all of our options.
What we're talking about here is that when we deploy an edge,
and we've got our transport side of the configuration,
that the transport side is going to have our tunnel interface configuration.
The tunnel interface configuration is basically saying
we're only going to allow things to come in on the tunnel.
So if it's not coming in on the tunnel,
then we're going to reject it short of a few specifically enabled protocols.
And so this is going to be known as the implicit ACL.
Implicit meaning that it's just implied that it's there.
We don't actually see it.
Now, we can look at some of the configuration commands,
but we're not actually configuring an ACL.
We're actually just relying on some of the default configurations
or possibly changing the default configurations that are on that interface.
We're specifically talking about those allow service commands,
the allow service commands such as allowing, for example, SSH or DSCP or DNS.
These are protocols that we might want to allow before the tunnel is actually formed.
It's going to be important for us to be able to do that
if we want to bring some of our edge devices online.
So the question here is what happens when I also configure an explicit ACL?
An explicit ACL is simply one that I configure myself.
So we have the implicit that's here on the interface.
What if I also add the explicit to the same interface?
So what's the order of operations here?
Well, first of all, we're going to look at the explicit rules.
This goes assuming that because we configured the explicit ACL
that we know what we're doing,
and we're going to first of all run our checks through it.
So if we deny traffic that would otherwise have been allowed by an allow service command,
well, we're checking this first.
And so we're going to drop that traffic if we have a matching statement.
But what we're going to do is we're going to take the default action for the explicit,
and we're going to put it at the end.
So our default explicit rule, whether that's allow or reject,
basically permit or deny,
regardless of what we're doing, we're going to evaluate that last.
And right here in the middle is going to be our implicit ACL rules.
So importantly, if I'm allowing something in here that's being rejected here,
we see the rejection first before we get to the accept.
Conversely, if we accept something here that's rejected down here,
then we're going to accept it because we see the accept rule before we get to the reject rule.
And lastly, if neither of these specifically apply and hit a match for traffic that's going through,
we're going to end up landing on the default configuration for our explicit ACL.
That might be deny, that might be permit,
but either way, we're going to follow that rule.
So this is a good question because it reminds us of the difference between an explicit and implicit ACL,
and it helps us to review and make sure we remember the order of operations for processing ACLs
if we end up having overlapping configurations being put onto the same interface.
Question number three, what is the primary goal of deploying DIA or
direct internet access as a service within the SD-WAN?
So DIA is all about allowing us to send traffic locally via an internet circuit.
So it would be B here, leveraging that local circuit for internet traffic.
The idea here is that normally a host that's sitting on a user or service VPN
is going to have to go through the tunnel.
So we've got these IPSec tunnels, and maybe we're going to have to go up to some headquarters site,
and then we'll use an internet circuit up here.
So if I want to get to the internet, then I have to go through this tunnel,
and then out to the internet.
And of course, return traffic is going to end up doing the same thing.
Well, maybe we would rather not do it that way,
because this tunnel could be built across the internet itself.
And therefore, we have a circuit to the internet,
and maybe we just want to allow this host to go directly to the internet this way.
This is where DIA comes into play.
It's going to rely on us having NAT configured on that interface.
We're going to have to have a default route
that points to the global VRF and then NATs the traffic as it goes out towards the internet.
So there's a few configuration changes that we're going to have to make
in order to allow this to happen.
The value is going to vary depending on the organization.
Is this useful or not?
And as we've pointed out before, it's very useful, especially for guest traffic.
We do have to keep in mind, if this isn't guest traffic,
then the matching qualifications for this traffic showing up and getting sent to the internet,
we need to make sure we're not sending it to something internal to the rest of the network,
maybe a server in the data center or something like that.
So that's something we have to consider, as we pointed out during the skill where we discussed it.
But for right now, as far as DIA is concerned,
we're really focusing in on the fact that allows for us to leverage that local circuit for internet traffic.
Question number four, what factor is used to select which DIA configuration method should be used?
Well, the answer is right there at the top.
It's A, scaling.
And the reason for this is because we actually have two different ways to configure DIA,
the first of which is static.
And that just requires a few CLI commands.
It's pretty quick.
I can log into an edge and perform that.
Or we have to consider deploying it via policy,
specifically a centralized data policy.
Now, if we go this route, this is going to require us to push it out through the controller,
but it's going to scale out to many different edges all at once,
all of our edges out on the SD-WAN,
whereas static is just going to be one device at a time.
So it's not less secure or more security is one or the other.
It's not any more or less simple, or at least at the very minimum,
that's a subjective evaluation.
Whether this side is easier to configure or this side is easier to configure,
and they're both going to create, ideally, a stable connection.
So this is all about scaling and which,
you know, choosing the right method for the size of our environment.
All right, next question.
Which direction is used when deploying DIA as a centralized data policy?
Well, we just said that configuring DIA can be done statically or via centralized data policy.
And keep in mind how direction works on data policies.
It's one of these two.
It's from service or from tunnel.
We're not doing inbound and we're not doing outbound.
These would be how we define direction for control policies.
We're not going to use that for data policies.
And the reason for that, as we said,
is because now we're talking about things being relative to the edge
and saying, is this inbound into the WAN or is this inbound into the LAN?
We don't want to get into those conversations.
The question is, really, which direction is it flowing?
So if it's flowing this way, and let's say this is the service VPN over here,
and this is the transport VPN.
And importantly, this is where our tunnels are.
Then in this case, we would say it's from the service
going out towards the tunnels or the transport mechanism.
DIA, as we just got done saying, is going to be traffic coming in from the service side
and getting sent out the internet circuit without going into the tunnel.
So the direction we have drawn is how DIA operates.
So the answer here is going to be C.
It's applied in the from service direction,
and we see that in the apply policy section of our data policy configuration.
Okay, just three more to go.
We're over halfway there.
Question number six.
What is the primary purpose of application-aware routing?
Application-aware routing, or AAR, whatever we want to call it,
it's very useful to us.
It's going to monitor links using a service level agreement
and allow us to fail over from one link to another link,
not in the event that the link goes down,
but rather in the event that we drop below the SLA threshold, whatever that is.
And so we're talking about redirecting,
not redirecting traffic to different locations,
but diverting traffic when a link is impaired.
And so that would be B here.
That's what's key.
We understand that if I've got an edge and I've got two different circuits
and I'm sending traffic out this circuit,
if this goes down, it's a pretty simple mechanism to just say,
hey, let's forward it out this other link.
That's what OMP is going to allow us to do with a redundancy level configuration.
However, what if it doesn't go down,
but again, it just starts to get a little bit impaired?
At that point, we'd want to switch over,
but that takes a lot more complexity,
at least as far as traditional networking configuration is concerned.
Fortunately with SD-WAN,
we're talking about a feature like application aware routing doing that for us.
So let's make sure we have a firm grasp of what that is as we move on.
All right, question number seven,
and this is applicable to what we just talked about.
What three metrics are used to evaluate an AAR,
application aware routing, SLA, or service level agreement?
Well, the answer here is just,
we just have to know this and understand it.
We are tracking loss.
We are tracking latency,
and we're tracking jitter.
These are the three metrics we're going to use to try to figure out
whether one of these links is actually impaired or not.
And these metrics are going to depend on the traffic that we're matching.
So voice over IP is going to have a much lower threshold
for deciding that a link is not usable anymore.
We don't want our application quality of experience to go down,
basically our user experience to say that there's a problem.
So voice over IP is going to have more strict settings,
but then something else like bulk traffic,
maybe we want to switch that over if we're having an extreme amount of loss.
But other than that,
we're not really concerned about sending large traffic types over that link
and experiencing some latency and jitter
because that doesn't impact bulk traffic flows.
So it's those three metrics that we have as far as evaluating
and making sure that they stay good enough to continue to use that link.
All right, question number eight, and it is our last question.
PPR or predictive path recommendations
integrates with which other Cisco platform
in order to provide proactive recommendations?
Well, the answer here is D, ThousandEyes.
ThousandEyes is the product that Cisco has integrated with.
And keep in mind what PPR does.
The idea of PPR is that it can look at an application and say,
you know what, that application could really use this type of policy
in order to improve our end user experience.
So it might provide us with an AAR policy
that will keep that application running better in our environment.
So ThousandEyes is a monitoring solution,
but saying it's a monitoring solution,
it kind of robs it a little bit
because it's way more than monitoring.
It goes way deeper into metrics.
And so, yes, it can alert us to things that are happening on the network
and it can be proactive in that regard.
But PPR is going to leverage the information that ThousandEyes has
and then go into our SD-WAN environment
and basically say, hey, here's a policy we created
and give us just a few clicks to enable that policy on the network.
So this covers all the data policies.
Again, the primary data policies would be access control list.
That's a localized data policy.
We have some centralized data policies such as AAR as well as DIA.
Those are two policies we can deploy centrally,
pushing configuration out and pushing policy out to edges,
but continuing to allow edges to enforce that behavior.
So with that, let's go ahead and go into our lab challenge
in order to make sure we've got it all down
as far as data policies are concerned.