Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

ADC Overview

 

Juniper Networks® Application Delivery Controller (ADC) for the MX Series 3D Universal Edge Router offers advanced router-integrated ADC functions that enables service providers and enterprises to efficiently scale service capacity and increase service performance. Routers are already ubiquitously deployed throughout the network: at the network edge, in the network core, and in the data center. Integrating the advanced ADC with the carrier-grade MX 3D router promotes network consolidation and reduces the number of network elements that providers must rack, power, cool, maintain, and upgrade. Furthermore, the ADC software, which is optionally licensed, improves service resiliency by monitoring server and application health and by automatically bypassing failures.

Server load balancing (SLB) benefits your network in a number of ways:

  • Increased efficiency for server use and network bandwidth With SLB, the ADC software is aware of the shared services provided by your server group and can then balance user session traffic among the available servers.

  • Important session traffic gets through more easily, reducing user competition for connections on overused servers. For even greater control, traffic is distributed according to a variety of user-selectable methods.

  • Increased reliability of services to users If any server in a server group fails, the remaining servers continue to provide access to vital applications and data. The failed server can be brought back up without interrupting access to services. Increased scalability of services As users are added and the server group’s capabilities are saturated, new servers can be added to the group transparently.

Server load balancing (SLB) can be the right option for addressing these vital network concerns:

  • A single server no longer meets the demand for its particular application.

  • When servers hold critical application data and must remain available even in the event of a server failure.

  • You want to use multiple servers or hot-standby servers for maximum server uptime.

  • You must be able to scale your applications to meet client request capacity.

  • You cannot afford to continue using an inferior load-balancing technique, such as DNS roundrobin or a software-only system.

The load-balancing module is used to efficiently deliver content and secure your servers from unauthorized intrusion, probing, and denial-of- service (DoS) attacks. The ADC software includes extensive filtering capabilities at the Layer 2 (MAC), Layer 3 (IP), and Layer 4 (TCP/UDP) levels. Traffic coming from client-facing interfaces is matched against filters. Servers must be connected to server-facing interfaces. The order of the filter term matching process is according to the order the terms appear in the configuration. You can move terms around by using Juniper Networks CLI commands. The order of matching filter terms between adc-instances is according to where the adc-instances appear in the configuration. Matches in one adc-instance are only compared with subsequent adcinstances in the configuration. Health checking allows you to verify content accessibility in large websites. As content grows and information is distributed across different server farms, flexible, customizable content health checks are critical to ensure end-to-end availability.

Service Instances

In a subscriber access network, each subscriber has its own set of services. You can configure a specific service instance for a particular subscriber by specifying a service name, also referred to as a service profile, and unique service parameters for that service instance. Service parameters can include a combination of policy lists, filters, rate-limit profiles, class of service (CoS) profiles, and interface profiles.

For example, filter-service (up-filter,down-filter) and filter-service (upstream-filter,downstream-filter) are considered two different instances of the same service (filter-service) because their parameters, enclosed in parentheses after the service name, are different. Each service instance is uniquely identified by the combination of its service name and service parameters. In CoA messages, the router identifies a subscriber service by its complete activation string, which consists of the service name and, if configured, one or more service parameters in the order specified.

An adc-instance is an instance of Application Delivery Software running on one or more Multiservices-DPC interfaces of a Juniper Networks device. An adc-instance includes a complete set of ADC definitions: real-servers, groups of servers, virtual servers using virtual IP addresses, and virtual services accessed by clients.

Using multiple instances on a single device allows you to create completely separate ADCs running on the same machine. Using different instances for different traffic guarantees computation power, guaranteeing no interruption between services. This can be used, for example, to load-balance traffic from different applications, where complete separation is required.

You must specify router interfaces that are bound to an adc-instance.

  • Multiservices interfaces—The physical multiservices interfaces of a device that are used to run the load-balancing instance application. The more multiservices interfaces used for a loadbalancing instance, the more capacity and processing power the instance has. At least one MS interface must be specified for each adc-instance, up to eight interfaces can run the same instance. A multiservices interface is associated exclusively to a single load-balancing instance (it cannot be shared between instances).

  • Client-facing interfaces—The device interfaces where client traffic is received. Traffic arriving on these interfaces is handled by the ADC software and destined to be routed to the virtual IP addresses and filter destination addresses configured in the instance. At least one client-facing interface must be specified for each adc-instance. A client-facing interface can be shared between instances.

  • Server-facing interfaces—The device interfaces where servers are connected, usually through switches or routers. Traffic to the servers is routed to these interfaces. At least one server-facing interface must be specified for each load-balancing instance; a serverfacing interface can be shared between instances. The same device interface can be used as a client-facing interface in one (or more) adcinstances, and as a server-facing interface in other instances.

Installing and Configuring the ADC Software

You must purchase a suitable license in order to run the ADC software. Each license is for one Multiservices-DPC (two NPUs per license). You should purchase licenses according to the number of Multiservices-DPCs that you have in your device.

As part of the ADC software integration into the Juniper Networks Junos OS system, the ADC software is using an internal configuration. The internal configuration is done in two ways: using a commit script and using the Junos OS internal API.

Application-Based Health Checks

Application-based health checks include the following:

SSL Server Health Checks

The SSL-Hello health check option on the group configuration allows the ADC to query the health of the Secure Sockets Layer (SSL) servers by sending an SSL client "Hello" packet and then verifying the contents of the server's "Hello" response. The SSL health check is performed using the server listening port configured, under the virtual service configuration, or using the virtual service port when the server listening port is not configured. The following is a summary of the SSL enhanced health check process:

  • The ADC sends an SSL "Hello" packet to the SSL server.

  • If it is up and running, the SSL server responds with the "Server Hello" message.

  • The ADC verifies fields in the response and marks the service "Up" if the fields are OK.

During the handshake, you and the server exchange security certificates, negotiate an encryption and compression method, and establish a session ID for each session.

DNS Health Checks

The ADC software supports both TCP and UDP-based DNS health checking. This health check is performed by sending a DNS query over either protocol and watching for the server reply. The domain name to be queried can be modified using the configuration.

Ping Health Checks

Ping health checks verify if the real server is alive. The Layer 3 echo-echo reply health check is used for UDP services or when ping health checks are configured. Note: Ping health check is the default health check for a group.

HTTP Health Checks

HTTP-based health checks can include the hostname for Host headers. The Host header and healthcheck URL are constructed from the virtual server hostname, domain name, and sServer group health check field components. If the Host header is required, an HTTP/1.1 GET will result. Otherwise, an HTTP/1.0 GET will result. HTTP health check is successful if you get a return code of 200. If content is not specified, the health check is performed using the / character.

The following is an example of an HTTP-based health monitor:

Script-Based Health Checks

Health check scripts dynamically verify application and content availability by executing a sequence of tests based on send and expect commands. Configuring Script-Based Health Checks You can configure the ADC software to send a series of health check requests to real servers or real server groups and monitor the responses. Both ASCII and binary-based scripts, for TCP and UDP protocols, can be used to verify application and content availability. The benefits of using script-based health checks are:

  • Ability to send multiple commands.

  • Checks for any return ASCII string or binary pattern.

  • Tests availability of different applications.

  • Tests availability of multiple domains or websites.

  • The ADC software supports the following capacity for a single ADC: 6K bytes per script and 64 scripts per load-balancing instance

The commands are grouped together as a list so you can change their order. Each script command is made up of one or more tcp-command or udp-command containers. Commands exist to open a connection to a specific TCP or UDP port, send a request to the server, and expect an ASCII string or binary pattern. The string or pattern configured with an expect (or in the case of binary, binaryexpect) command is searched for in each response packet. If it is not seen anywhere in any response packet before the real-server health-check interval expires, the server does not pass the expect (or binary-expect) step and fails the health check. A script can contain any number of these commands, up to the allowable number of characters that a script supports.

Note

There is no need to use double slashes when configuring a script that uses special characters with single slashes. For example, the script entry GET /index.html HTTP/ 1.1\r\nHOST:www.hostname.com\r\n\r\n does not require the use of \\r or \\n to ensure proper functioning of the script. Only one protocol can be configured per script.

Script Formats

Health check script formats use different commands based on whether the content to be sent is ASCII-based or binary-based. Each script should start with the command open <protocol port number>,<protocol-name>. The next line can be either a send or expect (for ASCII-based), or bsend or bexpect (binary-based).

ASCII-Based Health Check

The general format for TCP-based health-check scripts is as follows:

Binary-Based UDP Health Check

The general format for UDP binary-based health check scripts is shown below. Specify the binary content in hexadecimal format. UDP-based health check scripts can use either ASCII strings or binary patterns.