Differentiate TCP profile settings between endpoints using AppQoE

So a new feature that was introduced in 11.1 which I some reason overlooked was the ability to configure seperate TCP profiles using AppQoE actions, which in its essence allows us to configure different AppQoE policies using different TCP profiles based upon which endpoint is connecting using expressions.

Now by default when a client connects to a virtual server, the client and the vserver will communicate using the TCP profile which is defined to the virtual server, or using the default_tcp_profile if nothing is attached to the virtual server

image

Now with 11.1 as mentioned we can bind different AppQoE policies to a virtual server with difference expressions which will then have a TCP profile bound too it.

image

This allows for us to much easier adjust TCP traffic based upon where the clients come from, user-agents types etc. To configure this we first need to enable AppQoE feature. Next we need to create two different policies, where one is aimed at local connection coming from the LAN

image

Where I use the profile internal_apps, then I bind it to a AppQoE policy,

image

Next I create a similar policy aimed at Android devices,

image

then I use another TCP profile which is bound to that AppQoE policy

image

then lastly I bind the policies to a virtual load balanced virtual server

image

So now when a client connects to this virtual server, depending on what and where the device is coming from with get the AppQoE policy enabled. It is important to note that even if we are defining a seperate TCP profile for each device, some of the TCP profiles parameters such as Window Scaling, SACK etc are evaluted during the initial conneciton before the AppQoe policies are evaluted. Therefore they will not be changed even if we bind another TCP profile using AppQoe where we have other TCP settings for WS and SACK defined. This is where the vServer TCP profile will decide if WS and SACK will be enabled or not.

You May Also Like

About the Author: Marius Sandbu

Leave a Reply

Your email address will not be published. Required fields are marked *