Shape individual flows / applications that are using too much bandwidth

Summary

How to shape applications, hosts or ports that are utilizing too much bandwidth on the network.

Overview

The circuit is being capped at max bandwidth, and on Monitor > Real Time, there are individual flows or specific applications that are using a extremely high amount of bandwidth

Cause

These flows are falling under overly permissive policies that allows them to obtain too much bandwidth

Resolution

In order to troubleshoot this, at least one of three things must be known:

1.- Isolate the problematic traffic by the IPs of the server/s. If the traffic is an application that user knows comes from specific IPs, then keep that/those IPs in mind.
2.- Isolate the problematic traffic by tcp/udp ports. If the application is running on a specific port, write that port down.
3.- Isolate the problematic traffic by L7 information. In real time monitor, some applications contain the URL between brackets.

With this information, the following can be done:

For case 1: Create a network object that defines the subnets or IPs for the application. Go to Configuration-->Objects-->Network and create a network object for the IPs involved. From there, it is possible to create a policy using that network object as the host (filter rules: host: Network Object Created <--> host: ALL). From now on, all traffic to and from those IPs will be subject to this policy, so configure the burst bandwidth to be a lower value than what the application is obtaining currently.

OPTIONAL: It is also possible to monitor the application with a custom name and not with whatever name the Exinda is classifying it as. This can be done through going to Configuration-->Objects-->Application and creating an application object with whatever name for the traffic to be classified as, and specifying the network object created earlier.

For case 2: Create an application object (or modify an existing one) under Configuration-->Objects-->Applications, defining "Ports/Protocol"--> TCP or UDP Port/Range-->Ports learned. From now on the traffic will be classified as the application object name given (This can be verified in Monitor-->Real Time), and hence, the application can be added to an existing policy or a new policy with a new predefined bandwidth allocation.

For case 3: In each application object, the "L7 Signatures" section provides a more detailed option, being a little more specific as to what type of L7 traffic you want that application to be. Going to Monitor-->Real Time, some flows will be classified as (for instance): HTTP[www.exinda.com]. This means that that flow is getting classified as L7 HTTP (So it will fall under the generic Web policy) but as an aggregate it is showing that the URL involved is "www.exinda.com". This can be taken advantage of by editing an existing application object or creating a new one specifying: L7 Signature-->HTTP-->host-->[URL keyword]

The above means: HTTP traffic that contains the word "exinda" within the URL will no longer be classified as HTTP, it will now be classified as this new application object. Another example: User is limiting Streaming traffic (including "Flash") but there is an important training going on that is presented in Flash format and exinda is classifying it as:

Flash[training.com]

It is possible to create a new application object specifying the following details as the L7 Signature:

Flash-->host-->training

And now that traffic will be classified differently, hence it can be added to a separate policy and shaped separately