All right, let's go and jump into the management of SD-WAN as well as the very important application
quality of experience or AppQoE, that set of features that allows us to hopefully improve
performance on wide area network links, which usually have less bandwidth and generally less
performance than our local area network links. So first question out of eight, what does TCP
optimization aim to make more efficient across the WAN? Well, TCP optimization is going to focus on
the TCP windowing. We want to make sure that we are managing that effectively because we want to
avoid that shark fin like behavior where we ramp up our window sizes, hit congestion, and everybody
kind of globally synchronizes as we call it, TCP global synchronization. We all back down our window
sizing and we do this over and over again, and we're missing the use of all of this bandwidth
in here. So instead, our edges break up the TCP connection flow like this and we control TCP via
TCP optimization between the edges directly. Question two, which compression technique is
used by data redundancy elimination or DRE to reduce bandwidth usage on the WAN? This is just
going to be something we have to remember. It is that Lempel-Ziv-Welch or LZW compression algorithm.
That is how we do this. This is a lossless algorithm, very important. If I'm going to compress
data down by one edge and then send it to another edge, then I need to reinflate that data. I need
to be able to recover 100% of the missing bits, and that's what Lempel-Ziv-Welch allows us to do.
Question three, sketch a diagram that explains how packet duplication can make a network more
efficient. Well, the way packet duplication is going to work is we're going to take advantage
of the fact that we have multiple service provider links when sending data to a remote edge. The idea
here is that I might send a packet to this service provider and it ends up getting dropped.
And so if I can send to both service providers, then hopefully at least one of those makes it
through. If, for example, both of them do happen to make it through, which should be more often
than not, if we send two packets, we hope both of them arrive on the other side, then whichever one
arrives first, we're going to drop the other one so we don't end up sending duplicate packets onward
from the receiving edge. So yeah, we're not deduplicating our packets. We're actually
creating two times the amount of bandwidth usage here. For critical traffic, that makes sense,
especially when we have this whole WAN circuit down here, which might not be very heavily used,
and so we have bandwidth to spare in that regard. Next up, what part of forward error correction,
or FEC, is a proactive means of data recovery? So the idea here is with forward error correction,
and I'm going to send all five of these packets to the remote edge, and it's the inclusion of
this parity packet that is the forward part basically saying that we're being proactive.
Reactive would mean we'd have some kind of feedback mechanism that would say, hey, I didn't
get that, and then we might include parity to try to deal with any network congestion. That would be
like a backward error correction. Forward error correction says I'm including this no matter what,
which, yes, increases my utilization by 20 percent, roughly based on the size of the packets, but
I'm going to, in theory, reduce the loss mechanism because if I lose any one of these packets
and root, it doesn't matter which one I lose. I can use the parity packet, assuming that's not
the one that dropped. I can use that parity packet to restore the information in the packet that did
end up getting dropped. So the answer here is B. Sending a parity packet is the proactive means
of recovering data once a packet ends up getting lost in transit. All right, question five. We're
halfway there. Identify the AppNav component that is run or managed by each of the below
platforms. Well, Cisco AppNav, as we recall, is integration with the wide area application
services or WAAS solution. And when we're looking at it from a WAAS perspective, all four of these
devices, even though we're used to them, you know, at least iOS XE and SD-WAN edges, even though
they're part of our SD-WAN architecture, they form roles as far as the AppNav architecture is
concerned. And they have slightly different names depending on what we're talking about.
And so when we look at this, we see that we have the iOS XE agent, whoops, there we go,
which is known as the ANC. That stands for the AppNav controller. So that's the agent there.
The edge becomes the service controller or the SC. The WAAS manager is its own software package.
It is known as the WCM or the WAAS central manager. And WAAS devices, really we should
call this WAAS nodes, become known as WNs because we're going to use the node name rather than
device. So WAAS node is WN. These four devices come together to improve our efficiency that
we're using on the wide area network circuits. Yes, a lot of those app QoE features are very
useful to us and they're very helpful for us. But something like WAAS is just hardware tuned to get
the most out of our wide area networking, the most out of our compression algorithms, and the most
out of all the other features that it uses. And so WAAS is not dead just because we have SD-WAN
in place with all of these app QoE features, but rather we can integrate with WAAS thanks to the
AppNav architecture and we can leverage the best of both worlds and make sure that, again, we're
getting the absolute most out of our WAN circuits. Question six, which part of the RBAC architecture
defines individual permissions for a user? Well, the answer here is going to be B. It's the role
that's assigned to the user. The way this works is I create a role. It has permissions, which is
what we're asking about in this question, and then I'm going to map a user to this role. And the way
that we find out which role a user gets is thanks to the server over here. So we do have a TACACS
or a RADIUS server that when the user logs in, it's aware of what role that user is going to be
given. But the permissions are defined on SD-WAN manager, not on the server themselves. Keep in
mind we do have the concept of a scope. The scope is sort of an attack on where we say that
all the permissions are great, but we're only going to apply those to specific edges or specific
sites and so on and so forth. So it's a way for us to be a little bit more granular with our
approach to say, yes, you can do these configuration changes, but we really only want you doing this on
edges 11 and 12 or something to that extent. Question number seven. What are the two
notification options that can be assigned to alarms? So remember, alarms are how we
can tell what's going on in our environment. It's an important part of monitoring and reporting,
and notifications naturally are very important for us as well because we as network admins
should be alerted when something is going wrong in the network, depending on the level of
criticality. And so even though we might expect there to be a native configuration for text
messaging, we can't do that. What we can do is configure email, and we did mention that emails
can be used to trigger text messages for a lot of mobile device service providers. They allow us to
email a specific address, and that converts to a text message on our phones. But the other thing
we can do is perform webhook operations, which allows us to connect into WebEx natively or Slack.
These are both native options in SD-WAN Manager, or I can do a custom webhook, and at that point,
I can find a way to convert that into a text message. So we can get to the point of a text
message, but we're asking about the notification options that can be assigned to alarms here in
SD-WAN Manager, and it is only going to allow us to configure emails or webhooks.
And last question. What is the order of install for the SD-WAN devices when performing an upgrade?
Remember, we had that MVCE. I joked that it looks like the word mace, but the A is upside down. It's
actually a V. And so it's manager, then validator, then the controller, and then we push our
configuration out to the edges. So it's just important for us to remember the order of
operations when it comes to upgrading our environment. That's going to really help us out
when that day comes in our real-life deployments of SD-WAN, because we're going to have to upgrade
the code at some point. It feels new and shiny on day one, but eventually we are going to have to
perform upgrades. It's a very important part of the life cycle of any solution, including SD-WAN.
So that brings us to the end of this review and to the end of this whole course. At this point,
when you prepare yourself for going and taking the exam, make sure you go back and review the
cornerstone or these review types of skills. That's going to really highlight any areas that
we might have forgotten over the course of time. If we identify any areas of weakness,
whether in these sets of quizzes or as you review other quizzes, then be sure to go back and review
those materials in your final preparation as you get ready. Otherwise, I hope this
has been informative for you, and I'd like to thank you for viewing.