It's time to start migrating our conversation to talk about how quality of service is leveraged
inside of the SD-WAN space, and there are a few things to be aware of here. First of all,
we want to talk about tagging and enforcement, how exactly that all works. Now again, most of
our prioritization is going to be taking traffic in and deciding how to send traffic out on a
relatively low bandwidth WAN link. This is typically how it works in wide area networks.
We've got 10 gigabits per second on our switches and going out to our PCs. We've got gigabit links
at a minimum, all of these things, and we might have a 20 megabit per second WAN service. And so
we have to be able to take traffic and decide which traffic gets prioritized as we talked about,
and then we also have to worry about potentially traffic shaping to proactively drop packets to
prevent the WAN service provider over here from doing the dropping. However, there is another
use case for quality of service, and that would be what if on the other side of this, we have
another part of our network, maybe we sent this to the data center or we're sending from the data
center down to a site or something like that. Well, we might want to be able to enforce our
quality of service on the other side. And then the big question is also, will the service provider
actually provide any enforcement? If this is an MPLS provider, this is a possibility.
If it's the internet, then we're not going to see anything there, but there are some service
providers that will be able to enforce policy. So here's the question, how does our tagging survive
this trip through the SD-WAN? Well, importantly, I've got a packet that just arrived, and we know,
here I'll draw it over here, this packet that arrived has a tag in it, except this packet is
about to be sent out under the SD-WAN, and so we're going to encapsulate that packet using IPsec.
And so I'm going to tunnel it through the service provider. So how does the tag survive to the other
side? And importantly, if we're going to enforce anything in the middle, how do we see that tag?
Well, the tag is going to be migrated and copied really into the outer header. And so this solves
our problem because the tag is now in two places, one place that can be seen by the service provider
and inside once it actually gets de-encapsulated and sent into the rest of the network. But again,
I do want to be clear that this level of enforcement doesn't usually happen, and certainly
on the internet, there is no likelihood of us being able to tell the internet to prioritize
our voice over IP frames or packets. Now, the other thing to be aware of has to do with the
edges themselves. Our edges are Cisco hardware, at least in the modern SD-WAN network. I know we
used to have the Viptela hardware, but our edges are going to have interfaces that connect into
our service provider networks. And we said that we're going to need to get tagged traffic so that
the edge knows what to do with it. Well, that's kind of true and kind of not, because now we know
So how does it do it? Well, it either does it via matching those six tuples or possibly deep
packet inspection could be a possibility, but I could actually match traffic either based on tags
or based on the application itself. Furthermore, when I'm sending that traffic out onto this link,
we're going to find that an edge has eight queues in hardware that we can leverage.
Now we mentioned already that we've got 12, 13, 14, however many different per-hop behaviors in
DSCP land that we want to be able to use. So I'm going to create a maximum here of 1, 2, 3, 4, 5,
6, 7, 8 queues, and I can assign values to each of these queues. Now, one of these is going to
be reserved for the low latency queue, and what's interesting about this is the low latency queue
is not going to be used for voice over IP as much as it's going to be used for control traffic.
Control traffic being BFD and our control plane tunnels, and so one of those queues is already
reserved. So all the other values are going to potentially go into these other seven, except
keep in mind I also am going to have a best effort queue in here, and so really I get these six queues
here in the middle. So what can I assign to these? Well, whatever we want. We are in control of this.
Furthermore, I can put multiple packets or traffic classifications. For example, I could put
AF4X traffic into this queue, and maybe I could put AF1X traffic into this queue down here,
but I could also put AF3X traffic, if I really wanted to, into the same queue. So I have total
control over this, but this is primarily how I'm going to split my traffic up, and if I wanted to
break down individual assured forwarding values, like 31 versus 33, then I could, but usually we
put the same priority value into one of the queues, and again, given the fact that we've got
all of these different priority values, it makes more sense to split these up into these different
queues this way. Just also keep in mind we have EF in here for voice over IP traffic, so that's
going to need a queue as well. Now lastly, I want to lay the foundation for a little bit of a config
conversation. We're not going to do the configuration here in this skill, but we are going to demonstrate
the configuration coming up. We need to understand how configuration goes into effect. How do I get
all of this working on my edge devices? Well, first and foremost, here's a question. Is this a data
policy or a control policy? Looking at it, we see that it impacts real traffic as it traverses the
edge, which means it happens at the data plane, and therefore this is going to be a data policy
but we're going to find that there's a place for both of those configurations. So there are two
different parts of the configuration to worry about. We have to worry about the, first of all,
the queue configuration. So I have to configure my queues as well as how much bandwidth and all
of that. We'll talk about that in a moment. So I have to create these queues, and furthermore,
I need to perform traffic assignment. So I need to tell the edge how to get different traffic types
into the queues, basically this side of things. So we have to get the traffic assignment taken
care of, and we have to get the queues assigned. So those are our two configuration elements.
Now let's break that down a little bit. In the queue configuration, I'm going to have to configure
class lists. That's a group of interest. So just like with all of our lists, I get in there, I
create some class lists, and that's going to map my classes to my hardware queues. I'm also going
to have to create something called a QoS map. This is going to create the bandwidth reservations
that get mapped to each queue. So the class lists basically create the queues themselves.
The QoS map defines the bandwidth that's being assigned to all of them. Then I have to create
a localized data policy, and this is very important. It's a localized data policy that
gets pushed out, and then also I need to map out the interface config. I need to apply this
to an actual interface on an edge. Think back to access control lists. I needed to push a
localized data policy to define the ACL, but I also needed to put it onto the interface.
And so this gets assigned via device template, whereas this gets assigned via feature template.
So we'll take a look at that again in more detail coming up. As far as traffic assignment is
concerned, this is where we actually put traffic into these queues. It's great that we've defined
the queues, but we haven't told the edge which traffic types go into each one. Now interestingly,
I can perform this as a centralized or localized configuration. I have a choice here. So as a
centralized configuration, this is going to get pushed to our vSmart or our SD-WAN controller,
and we're going to use the concept of a QoS policy. Think back to our route policies and our
TLOC policies. Well, now I'm going to create a QoS policy, and it's part of our traffic data flow,
and we'll see how we configure that as well. Or I can still perform this localized,
and I'm going to leverage access control lists. ACLs are going to have to be part of a data policy
that gets pushed out, applied to interfaces, and so regardless of which method I use, we're going
to use match statements to define the classification, whether via application or whether
DSCP tag, all of these things, and I'm going to specify an action which is going to set
this packet to what we refer to as a forwarding class, which brings us back up here
to our class lists. So again, we'll break this all down more in detail coming up, but for right now,
just understanding kind of how this all comes together from an SD-WAN perspective,
and this will be a really good reference to come back to as we go through configuration
to make sure that we understand which parts of the configuration are accomplishing which tasks.