A10 Lightning ADC Use Case Scenarios

This section of the document briefly discusses the various configuration scenarios which a user can implement using the features offered by A10 Lightning ADC. These use cases help users to understand the A10 Lightning ADC features better, and how these features can be effectively used to address various scenarios. For example, If a user wants to block his network for a specific country. In this case, a user can use the SmartFlow feature in A10 Lightning ADC to create a service condition to block traffic for a specific country. Similarly, there are many other use case scenarios discussed in this section of the document.

Traffic Management Use Cases

Redirecting HTTP traffic to HTTPS

In an ideal scenario when you enter a URL (http://www.example.com) in your web browser, this sends an HTTP command to the Web server to fetch and transfer the requested web page. Here, your web browser is your client and your website host as a server. Sometimes, the clients may be exchanging private information with a server, which needs to be secured for preventing some hacking issue. For this reason, we are redirecting the traffic from HTTP to HTTPS using Smartflow feature in A10 Lightning ADC. The ‘S’ at the end of HTTPS stands for ‘Secure’. It means all communications between your browser and the website are encrypted. HTTPS is often used to protect highly confidential online transactions like online banking and online shopping order forms.

In order to redirect the traffic from HTTP to HTTPS in A10 Lightning ADC user can use the SmartFlow feature in the A10 Lightning ADC to create a smart flow condition for a particular service(s) so that any data exchange through A10 Lightning ADC is secure. Rather creating a smart flow condition for each URL request, the user can use https://$host$request_uri as the input in the Redirect URL field and set the condition as Redirect the traffic which will redirect all the URL requests.

In this case, a request from the client hits the smart flow and if the condition matches, then the traffic is redirected from HTTP:// to HTTPS:// [temporarily or permanently] for the requested URL.

Steps to configure a Smartflow policy to redirect traffic:

  1. Login to the A10 Lightning ADC.
  2. Click Configuration > Services > Smartflow
  3. Click Add a new Smartflow and set the conditions and then save.
_images/image10.0.png

See also

Adding a Smartflow section under Traffic Management Configuration, for more information on Smartflow configuration.

The video below demonstrates the steps to configure the redirect traffic policy:

Dealing with DDoS Attack

A distributed denial-of-service (DDoS) attack occurs when multiple systems flood the bandwidth or resources of a targeted system, usually one or more web servers. Such an attack is often the result of multiple compromised systems (For example, a botnet) flooding the targeted system with traffic. In this use case, we are discussing the Surge protection feature in A10 Lightning ADC which is designed to prevent such attacks.

If the attack is made in the form of SlowLoris, SlowPost or other similar low and slow attacks, the aggressively configured restrictions in the Surge Protection policy helps to mitigate such attacks. Thus, limiting the total number of user sessions and rate limiting traffic within a session using Session Tracking policy preventing the attacker from creating junk connections and consuming server resources.

See also

Protection against DDoS Attacks section under Security Configuration for more information on Surge Protection policies, and how to configure them.

The video below demonstrates the steps to configure Surge protection policy and Session tracking policy:

This video is about how to check for SlowPost attacks in the application.

Estimate the Rate Limit Configuration Values

This use case discusses the effort to estimate the Rate Limit configuration values considering the analytics of various other parameters.

Based on the session tracking and the per request analytic values combined together user can estimate the values for Rate Limit configuration.

A session is defined as a single user agent such as a browser or an API client. Each session has an idle expiry time that defaults to 30 minutes (this cannot be changed currently). A session can be tracked in two ways.

  1. LADC cookie- Cookies are maintained by LADCs and are returned with every response. Each user agent is uniquely identified by the combination of source IP and port.
  2. Client IP- Only the source IP of the client is used to identify a user agent uniquely.

Based on the values obtained from these four parameters as discussed below, the user can estimate the values to configure the Rate Limiting.

1. A number of Concurrent Sessions- The a maximum number of sessions (or user agents) that can be accepted at any given point in time. Suppose, it is set to a value of 100; then approximately a maximum of 100 user agents can be served at any point in time. Any more user agents will get a 403 forbidden response. This value can be retrieved from the “active sessions” value in the session tracking graphs (under App dashboard > Blocked requests)

2. A number of Concurrent Requests per Session- The maximum number of open requests (for which a response has not been received yet) that can be accepted at any given point in time. This value can be derived from a total number of requests that can be served at any given point in time and the number of concurrent sessions. Number of concurrent requests per session = Total number of requests/Number of concurrent sessions. Let suppose that it is known from the app server infrastructure/health that they can support a maximum of 10000 outstanding requests at any point in time and the maximum number of concurrent sessions (as seen from the graphs) is 1000. Therefore the number of concurrent requests per session can be set to 10.

  1. Session Rate- The maximum number of sessions that can be accepted per second. In other words, this implies the maximum number of user agents that can be served per second. This can be used to block too many new user agents served by the App server infrastructure per second.
  2. Request Rate per Session- The maximum number of requests per second that can be made over a session. This will block user agents to send too may requests/per second over a session.

Release a New Version of the Application to a Specific Domain

When there is a requirement for a user to test the new version of the application with zero downtime. In this case, the user can use the Blue/Green feature in A10 Lightning ADC to set the traffic steering policies for inbound traffic across old (blue) and new (green) deployments while both environments remain online. The user can monitor blue and green server behavior and health metrics to adjust traffic steering rules in real-time.

The following use case helps the user to understand how to configure the Blue/Green deployment feature in A10 Lightning ADC to steer traffic to a specific user domain, whenever there are any new additions to the application or to release a new version of the application.

In this use case, we are discussing four different Blue/Green deployment scenarios such as specific user, specific browser, specific country, and specific device. Basically, the Blue/Green policy steers the inbound traffic across old (blue) and new (green) deployments while both environments remain online based on the policy configured.

See also

Traffic Management Configuration for more information on Blue/Green deployment.

Configuring Blue/Green Policy

  1. Click Configuration > Blue/Green
  2. Click Configure a Blue/Green Deployment
_images/image9.8.png
  1. Select the Blue Service from the drop-down.
_images/image9.9.png
  1. Configure the condition(s) to direct the Green traffic based on requirement.
_images/image9.10.png

The first four steps remain same for all the policy configuration only we are changing the conditions as shown below.

Specific User

To filter the User specific traffic set the conditions as shown below, here If condition can be Header, Cookie, or Query Parameter.

_images/image9.11.png

Specific Browser

To filter the Browser specific traffic set the conditions as shown below.

_images/image9.12.png

Specific Country

To filter the Country specific traffic set the conditions as shown below, and the value used should be the country code (For example, US).

_images/image9.13.png

Specific Device

To filter the Device specific traffic set the conditions as shown below.

_images/image9.14.png

Security Configuration Use Cases

Block Traffic from a Specific Country

The following use case addresses the user requirement for blocking the traffic from a specific country. For example, the user is required to block traffic from a specific country in order to prevent any malicious attacks to the network, in such case user can create a security policy in A10 Lightning ADC and make the network much secure.

The security configuration policies in A10 Lightning ADC allows a business to build a policy that enables blocking of traffic for a specific country based on various parameters. This policy can be enabled for an existing service(s) or for a new service profile. In this example, we are creating a new service, and then enabling a smart flow condition to block the traffic for a specific Country.

Configuration steps:

  1. Click Add New Service > Provide Name, Description, IP and Port Number as shown in the video.
  2. Set the Service conditions as shown and then Save. Here, US is the country code for the United States.
_images/image9.0.png
  1. Activate the Service.
  2. Click Add SmartFlow > Set SmartFlow conditions > Save. As shown in the video.
_images/image9.1.png

The video below explains how to configure the policy to block traffic for a specific Country:

Block Traffic from a Specific Network

Your network is always vulnerable to all kind of threats and attacks. The attack may happen from a known source of network or from an unknown network. In order to prevent such attacks, we need to block such networks. This use case demonstrates the steps to block traffic from such networks using the traffic blocking policy in A10 Lightning ADC.

The security configuration policies in A10 Lightning ADC allows a business to build a policy that enables blocking of traffic for a specific Network using the IP address of the client network. This policy can be enabled for an existing service(s) or for a new service profile. In this example, we are creating a new service, and then enabling a smart flow condition to block the traffic for a specific Network.

Configuration steps:

  1. Click Add New Service > Provide Name, Description, IP and Port Number as shown in the video.
  2. Set the Service conditions as shown and then Save. Here, the value is the IP address of the network for which the traffic is blocked.
_images/image9.2.png
  1. Activate the Service.
  2. Click Add SmartFlow > Set SmartFlow conditions > Save. As shown in the video.
_images/image9.3.png

The video below explains how to configure the policy to block traffic for a specific Network:

Block Traffic from a Specific Browser

Sometimes it is required for a user to block traffic from a specific browser, in order to stop requests from a specific browser which the user application may not support or for many other reasons. For example, let’s say there is a request from Mozilla hits the server; and the application is not so compatible with Mozilla, in such case, the server may not respond to the request and there may be unnecessary space eaten up by such requests and may cause some downtime.

As a solution to overcome such issues the A10 Lightning ADC allows a business to build a policy that enables blocking traffic for a specific browser based on conditions like header type, match if, case, and value. This policy can be enabled for an existing service(s) or for a new service profile. In this example, we are creating a new service, and then enabling a smart flow condition to block the traffic for a specific browser.

Configuration steps:

  1. Click Add New Service > Provide Name, Description, IP and Port Number as shown in the video.
  2. Set the Service conditions as shown and then Save. Here, define Header name as User-Agent and value as the name of the Browser (For example, Mozilla in this case).
_images/image9.4.png
  1. Activate the Service.
  2. Click Add SmartFlow > Set SmartFlow conditions > Save. As shown in the video.
_images/image9.5.png

The video below explains how to configure the policy to block traffic for a specific Browser:

Block Traffic from a Specific Device

The following use case is very much similar to the use case to block traffic from a specific browser, the difference here is we are blocking traffic from a specific device.

The security configuration policies in A10 Lightning ADC allows a business to build a policy that enables blocking traffic for a specific device based on service policy conditions. This policy can be enabled for an existing service(s) or for a new service profile. In this example, we are creating a new service, and then enabling a smart flow condition to block the traffic for a specific device.

Configuration steps:

  1. Click Add New Service > Provide Name, Description, IP and Port Number as shown in the video.
  2. Set the Service conditions as shown and then Save. Here, define Header name as User-Agent and value as the name of the Device (For example, Macintosh in this case).
_images/image9.6.png
  1. Activate the Service.
  2. Click Add SmartFlow > Set SmartFlow conditions > Save. As shown in the video.
_images/image9.7.png

The video below explains how to configure the policy to block traffic for a specific Device: