With the proliferation of SD-WAN services, certain types of traffic should be treated with varying levels of service. Here's how to configure the Riverbed SD-WAN solution to provide QoS to different types of traffic.
Riverbed SteelConnect gateways have the ability to implement a per-uplink traffic shaper for both inbound and outbound traffic. The configuration is very simplistic as there are no classes to configure, and you set the bandwidth with a fixed value. But let's get into the details of how QoS works for the SteelConnect gateway and how we can verify that it's working.
How QoS works for SteelConnect gateways
My background has been with Cisco QoS and primarily using Class-based Weighted Fair Queuing with a Low Latency Queue for priority traffic. The SteelConnect solution is a bit different. It uses an advanced fair queue mechanism that distributes bandwidth across queues. When there are multiple connections it also tracks latency on each of them, or for each traffic flow, rather than on a class. The inner workings of the QoS functionality are based on CAKE.
The scheduler maps traffic dynamically into non-configurable traffic classes. There are four different classes that have DSCP values mapped to them, as seen below. These are pretty standard classifications when all things are considered.
|Latency Sensitive -|
1/4 or 25% bandwidth
|Class Selector (CS)7, CS6, CS5, CS4, Expedited Forwarding (EF) Voice Admit (VA)|
|Streaming Media -|
3/4 or 75% bandwidth
|Assured Forwarding (AF)4x, AF3x, AF2x, CS3, CS2, TOS4, TOS1|
|Best Effort -|
|CS0, AF1x, Type of Service (TOS)2 or if the DSCP value isn't specified|
The scheduler attempts to prevent aggressive flows from consuming all the bandwidth by fairly distributing traffic across the link. CAKE is specifically designed for uplinks which is why it is used for the Riverbed SD-WAN solution. Let's get into the configuration of QoS.
Assigning DSCP Values
There are three ways to mark traffic with a DSCP value.
- Assign them in SteelConnect Manager using traffic path rules.
- Apply on a switch or router before traffic reaches the Riverbed device.
- Use the SteelHead appliance QoS feature.
The following example applies a traffic path rule to a specific user. Note that you can be very specific in the path preference, applications, and site scope. In this case we are creating as general of a rule as possible to be able to see the QoS markings when we test.
- Navigate to Rules>Traffic Rules
2. Create a traffic rule to apply the desired QoS value.
In our example, the traffic from the user Brandon Carroll should be marked with a priority value that classifies it into the latency sensitive class. We know this from the graphical interface since the QoS Priority option is set to Urgent.
Enabling QoS on Uplinks
To enable QoS on Uplinks follow these steps:
- Navigate to Network Design>Uplinks. QoS queuing and shaping is applied to the traffic that leaves an uplink interface.
2. Next select the uplink you want to apply QoS on. In this case we've selected the "Internet" link but we could just as well selected an MPLS link or an LTE connection.
3. Select the QoS tab and enable both inbound and outbound QoS. This requires a bandwidth specification which has been set to 150 Mbits/second in the example below.
Testing and Verification
Testing and verification on the Riverbed SD-WAN solution is not very easy. One possible method would be to capture traffic that has passed through the gateway with Wireshark and verify that it does in fact have QoS Markings. What I've found to be very limited in the solution is the ability to view QoS statistics from the SteelConnect Manager interface. There is a traffic timeline, however it lacks good QoS statistics. It's my understanding that this is an area that will get some more attention in the future. In the meantime it's a "set-it and hope it works" kinda configuration.
How to register an ASA SFR module with the FirePOWER Management Center
How to configure NAT and enable inbound access on the Riverbed SD-WAN
Cybersecurity researchers claim every network router at risk of secretly leaking data
Net neutrality: The smart person's guide