One of the most frequently asked questions with my SD-WAN implementations is how to properly configure QoS in Citrix SD-WAN. On the one hand, you want to seamlessly implement Citrix SD-WAN into the network, assuming things are working well most of the time. On the other you want to make sure the implementation makes sense from the SD-WAN technology perspective so you can get the most out of your investment.
Citrix SD-WAN is designed to offer an optimized network out of the box. However, we know that a one-size-fits-all configuration is rarely possible in the enterprise world. For this reason, I wanted to highlight features you can leverage to transform your previous QoS metrics into a robust SD-WAN implementation, along with some DOs and DON’Ts we’ve learned in the field.
SD-WAN has its own QoS configuration within your infrastructure. It can be centrally managed, offers robust options, and stays completely under your control. You will no longer rely on any provider to manage this configuration or guarantee QoS; that becomes the SD-WAN’s role. Providers now become only one path of transport. But now that you are adding more options to transport your data, SD-WAN can make the best use of all the infrastructure to ensure data gets to where it needs to go.
The QoS profile of your choice can be applied to all your WAN links within a virtual path, whatever they are. And SD-WAN can aggregate all the bandwidth and determine which traffic is sent where. From your MPLS provider’s infrastructure perspective (their routers), all the traffic is now UDP port 4980 (by default). You can use different tags for SD-WAN traffic. But because SD-WAN will handle the scheduling and prioritization, it can make sure by itself that data is sent out according to priority.
But that also means that SD-WAN now needs to know which traffic needs to get priority on your infrastructure, how that traffic should be treated, and which of the many options should be used for each type of traffic. So let’s look at some DOs and DON’Ts.
Categorizing Applications
Do use application objects and application QoS. You can mix and match how you identify traffic, and the objects let you group applications based on the traditional IPs, networks, protocols, ports and tags, as well as on known protocols (such as Citrix ICA) and applications identified through deep packet inspection (based on the Application Signature Library).
- As a bonus, you can enable reports for these objects to be viewed in the Citrix SD-WAN Center and they can be used later in other SD-WAN firewall- and routing-related configurations, simplifying how you categorize applications on your network as a whole.
- To be able to use your application objects within your QoS default set, you will want to use the application QoS node. These rules have priority over what’s on the rules node, but the defaults will still apply for any traffic you don’t match within the application QoS.
Don’t just copy from the router. For one, the objects match traffic on both directions (source or destination), so that may differ from your standard implementation. And when profiles are applied globally, a rule from one site may affect another site. Finally, it is a general QoS best practice to identify the applications more granularly (not just networks or server IPs), so you can use this opportunity to address this gap if you have it.
Creating Classes
Do minimize the number of profiles (default sets). Bandwidth percentages are also dynamic, meaning any class can use the entirety of the bandwidth when there is no contention. But you can guarantee minimal levels of service as appropriate. Chances are that critical applications are critical everywhere. If a particular site does not have voice or video, for example, assigning classes for them will not hurt. If you are matching applications correctly, you won’t have to manage multiple default sets only due to minor differences in the classes.
Don’t use bulk classes for any important traffic. The SD-WAN classes are tiered in such a way that the real-time classes are served first based on total bandwidth percentage. Interactive classes are then served the remaining bandwidth proportionally to your allocated percentage. Bulk classes are strictly best-effort. They are only served if there is no real-time/interactive traffic. That means you will see lots of drops for any applications in the bulk classes whenever there is contention. Distribute your classes between the existing real-time and interactive classes and you can configure the unused classes if necessary.
Customizing Rules
Do understand the functionality and what parameters you can or should use. It takes some reading and learning, but it will save you from having issues due to misconfiguration. I’ll do my best to give you a head start:
- Traffic is packet-based, not flow-based, which means the packets are sent out through the best path at the moment of transfer. There is built-in monitoring on the headers to ensure the paths are always measured for quality.
- The transport method lets you choose if packets are Load Balanced (distributed normally), Duplicated (sent twice to minimize loss), or Persistent (consistent path for a given flow). Load balance can be used for most applications, while duplicate can be used for low-bandwidth, loss-sensitive traffic such as voice. Persistent should be used for larger traffics that are also sensitive to latency variation, such as video.
- Packets can and should be resequenced if the application requires it, and lost packets can also be retransmitted. The usage will depend on the type of application and may add overall latency to the flow as packets are held.
- SD-WAN can drop packets intelligently, but make sure you understand what each of them does before configuring them. You can drop packets based on latency limit or queue depth limit, and random early detection (RED) lets you drop packets uniformly across different flows.
- Within each rule, you can determine which Tag the packets will have when returned to the LAN so that they are appropriately recognized by LAN devices if necessary.
Don’t go in blind. There are defaults within the configuration that apply to specific known applications/flows to offer them a good level of service and the appropriate SD-WAN transport method. Observe how different traffic types get different parameters and use the same base settings for your applications, tweaking when necessary (you can also overwrite default rules with a custom rule if needed). You can view the defaults within the configuration by going to Connections -> Virtual Paths -> Rules within a site and observing the (auto) rules applied to it.
Given all these concepts and the paradigm shift, the goal on a new design will always be to cover two things to make sure the QoS configuration is properly translated into SD-WAN:
- Make sure applications get the minimum service levels they did before. No application should be forgotten or it can affect user perception. That means you will have to dig into the many MPLS router configurations to gather that information and plan your SD-WAN QoS configuration unless everything is very well documented already.
- Implement a configuration that makes sense for an SD-WAN world. Applications are more accurately matched; MPLS queues are forgotten; SD-WAN classes are used instead; and the traffic is transported using the right methods and parameters. This also means you will keep traffic as dynamic as possible to adapt to bad conditions.
There’s a lot more you can do. My colleague Marcos Negrão covered many more concepts on how Citrix SD-WAN selects links in his blog post, which I highly recommend. And we haven’t even touched the provisioning configuration, which also becomes more important as your network grows. Stay tuned for that!
Citrix Tech Bytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.
Click here for more Tech Bytes and subscribe.
Want specific Tech Bytes? Let us know! tech-content-feedback@citrix.com.
