📜 ⬆️ ⬇️

CISCO ACE - Application Balancing

Hello!

I want to tell a little about the family of equipment for data processing centers from CISCO - CISCO ACE (Application Control Engine). This article will address such issues as the purpose of devices, architectural features, applications, setting up basic functions. The material does not provide for any more subtleties of work; it’s rather designed for those who are thinking about introducing such devices, trying to make a choice, wanting to understand how such equipment will help optimize the network infrastructure, increase the availability and time of service deployment.


In the people, these devices are called "balancers", that is, devices that can distribute the load on several servers, depending on certain conditions. It can be said that switching is performed at the L4-L7 levels. But this is only one side of the medal and the manufacturer himself declares that the use of CISCO ACE in the data center allows:

• Increase productivity
• Scalability
• Flexibly redistribute resources,
• Simplify the process of introducing new applications,
• Optimize application performance,
• Ensure availability,
• Consolidate resources
• Provide manageability and monitoring.
')
These devices are presented in two form factors: standalone equipment (for example, CISCO ACE 4710) and modules in a CISCO 6500/7600 chassis (CISCO ACE-20/30 Module). Standalone equipment is a separate device that can be integrated into a network built on the basis of any vendor, service modules are high-performance devices suitable for installation in the network with existing 6500/7600 chassis, which improves performance, ensures centralized management, reduces the number of cable connections, contributes to fast the introduction of services.

Specifications:
CISCO ACE 4710


FeatureMaximum Performance or Configuration
Throughput0.5, 1, 2, or 4 Gbps
Compression0.5, 1, or 2 Gbps (using GZIP or Deflate)
Virtual contexts20
SSL throughput1 Gbps
SSL TPS7500 SSL TPS using 1024-bit keys
SSL TPS7500 SSL TPS using 1024-bit keys
Maximum L4 connections per second100,000 complete transactions sustained rate
Maximum L7 connections per second30,000 complete transactions sustained rate
Concurrent connections1 million


What's inside the box: CPU Intel Pentium 4 3.4 Ghz, 4x1GE, 8Gb RAM (cannot be increased), 1Gb Flash (cannot be increased), console port, ports for connecting a monitor, keyboard. Ability to manage using CLI, SNMP, WEB interface. The form factor is 1U.

CISCO ACE-20/30 Module

FeatureMaximum Performance or Configuration
Throughput16 Gbps *, 8 Gbps *, and 4 Gbps
Total VLANs (client and server)4,000
ProbesICMP, TCP, UDP, Echo, Finger, DNS, Telnet, FTP, HTTP, HTTPS, SMTP, POP3, IMAP, RTSP, RADIUS, SIP, SNMP, KAL-AP, and TCL Scripts
NAT entries1 million
Virtual partitionsUp to 250 *; 5 virtual partitions (devices) included in base price
SSL throughput3.3 / 6 Gbps
SSL TPS1000 TPS included in base price, and 5000, 10,000, or 15,000 TPS with licensing, (up to 30,000 with 1024-bit key)
Maximum L4 connections per second325,000 / 500,000 complete transactions sustained rate
Maximum L7 connections per second130,000 / 200,000 complete transactions sustained rate
Concurrent connections4 million
Sticky table entries4 million


Inside: 1Gb FLASH (cannot be increased), 3Gb RAM DATA PLANE, 1Gb RAM CONTROL PLANE.

In the CISCO 6500/7600 chassis it is possible to install up to 4 modules, thereby obtaining a performance of up to 64 Gb per chassis. It should be noted that the installation of 4 modules does not mean that in the system we will get one balancer with the declared performance, we will just have 4 by 16 Gbps. Marketers love to give these numbers, but you can just as well take a dozen CISCO ACE 4710, put them on top of each other and get great performance. By the way, I will give prices for devices:

ConfigurationPrice $ GPL
ACE 4710 0.5 Gbps15.995
ACE 4710 1 Gbps29.995
ACE 4710 2 Gbps39.995
ACE 4710 4 Gbps49.995
ACE30 Module with 4G, 1G Comp, 1K SSL TPS and 5VC39.995
ACE30 Module with 16G, 6G Comp, 30K SSL TPS and 250VC109.995


The approximate prices are given, as the price offers very few offers and the price varies greatly from the number of contexts required (more on that later), SSL sessions, etc.

Opportunities

Here we’ll dwell a bit on what these non-cheap devices are able to do (the list will not be complete, only the main one).

1. Switching applications.
CISCO ACE is an application level switch that provides server load balancing based on information from L4 to L7. Native deep support (Generic protocol parsing) for HTTP, FTP, DNS, Internet Control Message Protocol (ICMP), Session Initiation Protocol (SIP), Real-Time Streaming Protocol (RTSP), Extended RTSP, RADIUS, and Microsoft Remote Desktop Protocol (RDP). This means that in the case of using these protocols, it is possible to balance traffic based on (practically) any information in payload.

There is a flexible regular expression mechanism, as well as any manipulations with HTTP headers (add, delete, modify, etc.).

2. Traffic processing.
As it has already become clear, ACE can perform deep packet inspection, but besides this there is tcpdump, which is especially useful when troubleshooting.

3. Address translation.
It can implement Source NAT, Destination NAT, and Static NAT (but this is rather a side effect of the previous two types with one server in the server farm, but more on that later).

4. Balancing methods.
To balance traffic to servers within a server farm, a set of tests is made to determine the availability of applications / services. So we can balance on the server. Parameters: least loaded (the number of connections or the amount of traffic per server), randomly (here I would note that each server in a server farm is assigned a coefficient - weight. The probability of sending a request to a specific server is defined as the ratio of its own weight to the sum of weights all servers in the farm. Therefore, if all servers have the same weight (relative value), then balancing will be even), defining the hash from addresses, the cookie hash, the protocol hash, the URL hash. In the case of cookies or SSL, the device binds a specific user to a specific server to ensure the constancy of the sessions.

5. Determining the availability of services / applications (how it is configured and I will give an example further): ICMP, TCP, UDP, ECHO {tcp | udp}, Finger, HTTP, HTTPS, FTP, Telnet, DNS, SMTP, IMAP, POP, RADIUS, scripted, Keepalive Appliance Protocol (KAL-AP), RTSP, SIP, HTTP return-code parsing, SNMP. It is also worth noting that using (for example) an HTTP probe, availability is determined not only by receiving any response, but it is possible to specify the necessary response codes (or their ranges), the necessary header values ​​in the HTTP response, the response time, etc. By creating a sample, we define the requested page, header values, etc. The mechanism is very, very flexible.

6. Fault tolerance. Fault tolerance is achieved by using an additional module / device within one chassis or geographically separated in Active / Active, Active / Standby modes. Using CISCO VSS, it is possible to virtualize both modules in the chassis into one virtual device.



7. Acceleration of applications. The device multiplexes TCP / UDP sessions to improve network performance.



8. SSL acceleration. ACE has a built-in hardware SSL accelerator that allows you to terminate sessions on the device, thereby removing the load from the servers. There are 3 modes of operation: SSL termination, SSL initiation, End-to-end SSL (termination + initiation). SSL termination - the session is terminated on the CISCO ACE, the traffic from the balancer to the server goes unencrypted. The server responds to the balancer, which in turn encrypts the data and sends it back to the client. One interesting feature should be noted: the traffic balancer decrypts the traffic, but the destination port (TCP) does not change, that is, the WEB server on the servers must listen to port 443 instead of 80, of course, without encryption.


SSL initiation - the traffic from the client to the balancer goes in open form, the balancer establishes an SSL session with the servers and communicates with them using SSL. The openings are transmitted to the client in unencrypted form.

In the third mode, the client establishes one session with a balancer, and that volume in turn establishes another session with servers. Double encryption occurs (meaning not encrypting encrypted, but re-encrypting previously decrypted).



9. Security features : ACL (L3-L7), Bidirectional NAT and PAT (+ policy NAT), TCP connection state tracking, Virtual connection state for UDP, Sequence number randomization, TCP header validation, TCP window-size checking, Unicast Reverse check Path Forwarding (URPF) when setting a session, Rate limiting.

10. Virtualization features.
The device can work as one and the only thing that is not always flexible. Or from one physical device it is possible to create up to 250 virtual balancers. Each such balancer has its own administrators, its own configuration, its own rules, and the limits of resources used (CPU, connections, bandwidth). It is very well suited not only for its own needs, but it is also possible to provide customers with a dedicated ACE service, where within their device they can do whatever they want.


11. Operating modes : Routed mode, Bridged Mode, Asymmetric server normalization (ASN). In Router mode, you can select two sub-modes: Inline and On-a-stick (or One-Arm-Mode).

Bridged mode

The device is located in the “gap” between servers and default-gateway for servers. Both device interfaces on the same subnet in L2 (bridge) mode. A necessary condition is the absence of traffic passing between the servers and the router NOT through CISCO ACE. Thus, the client calls VIP 172.16.3.100 (Virtual IP is the virtual address of the balancer. The traffic coming to it (VIP) is balanced between the servers), and the device in turn redirects the request to the servers, changing the destination address. The server sends a response to 172.16.3.1, but when the traffic passes through the ACE (and we said that this is mandatory), the source address changes back to 172.15.3.100.

Such a solution is well suited for implementing CISCO ACE into an already operating network, addressing does not change, servers are not reconfigured.

Routed Inline mode

In this mode, CISCO ACE performs hop for passing traffic. The mode is preferred for new installations. The balancer is the default-gateway for servers. In this mode, I will dwell in more detail and give a typical configuration for balancing.

Routed mode On-a-stick (One-Arm-Mode)

Traffic from the user comes to the balancer (VIP). The client's address is replaced with the own balancer address and the destination address with the real (or one of the real) server address. In this case, the server responds directly to the balancer and the procedure is repeated in the reverse order: the source address is changed to VIP, the destination address is changed to the client's address. The client (s) have the impression of communicating with a server with an address (VIP), although in reality servers can be located around the globe.

A good option when a client wants to get a balancing service. For example, the client has 3 WEB servers in different DC. From us it receives the real IP address of the balancer –VIP. In the DNS settings binds your domain to the selected VIP. Now the client does not “shine” its servers, and by adding or withdrawing them, clients continue to receive service.

Routed mode Asymmetric server normalization
The mode is very similar to the previous one, then the server responds directly to the client, bypassing CISCO ACE.

Consider an example setup

I want to consider a basic example, without describing many options, since there is no urgent need for this (I will give links to good materials), better, if necessary, I will comment on or explain not clear points.

As a topology, take rice. Routed Inline mode.
Management Interface 172.16.1.5.

Let's write the rules of the management policy:
class-map type management match-any L4_REMOTE-ACCESS_CLASS
description Enabling remote access traffic to the ACE and the Cisco ACE Module
2 match protocol ssh source-address 172.16.1.0 255.255.255.0
3 match protocol icmp source-address 172.16.1.0 255.255.255.0
4 match protocol https source-address 172.16.1.0 255.255.255.0
5 match protocol snmp source-address 172.16.1.0 255.255.255.0

policy-map type management first-match L4_REMOTE-ACCESS_MATCH
class L4_REMOTE-ACCESS_CLASS
permit

interface vlan 20
ip address 172.16.1.5 255.255.255.0
service-policy input L4_REMOTE-ACCESS_MATCH


From the network 172.16.1.0/24 it is possible to access the device using the protocols SSH, SNMP, HTTPS, ICMP.

Let us have 3 servers in the server farm, on which we will balance the load. We declare the server:

rserver host SERVER-1
description SERVER-1
ip address 192.168.1.11
inservice
rserver host SERVER-2
description SERVER-2
ip address 192.168.1.12
inservice
rserver host SERVER-3
description SERVER-3
ip address 192.168.1.13
inservice


We merge servers into the farm (for samples we will use HTTP and ICMP):
serverfarm host FARM
probe HTTP_PROBE
probe ICMP_PROBE
rserver SERVER-1
inservice
rserver SERVER-2
inservice
rserver SERVER-3
inservice


Sample Description:
probe http HTTP_PROBE
interval 5
passdetect interval 10
passdetect count 2
request method head url /index.html
expect status 200 210
header User-Agent header-value "LoadBalance"
probe icmp ICMP_PROBE
interval 10
passdetect interval 60
passdetect count 4
receive 1


interval - interval between samples
receive - timeout
passdetect count - serer is considered not available when not receiving so many answers
passdetect interval - sample interval for server not available

We describe the balancing policy.
Virtual IP address (we will accept requests only on port 80):
class-map match-all FARM-VIP
2 match virtual-address 172.16.1.100 any eq www


We will balance the traffic on our farm, which means we will describe the balancing policy:
policy-map type loadbalance http first-match FARM_POLICY
class class-default
serverfarm FARM


If we do not specify the http balancing type (which is optional), then using the http protocol, we can get problems with cookies, for example. This parameter determines the type of future traffic and processing features. The problem of "basket":



This means that any HTTP traffic to which the FARM_POLICY policy will be assigned will be sent to the FARM farm.

Now we create a policy that combines the above:

policy-map multi-match WWW-PM
class FARM-VIP
loadbalance vip inservice
loadbalance policy FARM_POLICY
loadbalance vip icmp-reply active


This policy is applicable on the input (external) interface:
interface vlan 20
service-policy input WWW-PM


This means that, firstly, the balancer will give up its MAC when requesting the address 172.16.1.100. Further, if traffic goes to port 80 of address 172.16.1.100 (class-map match-all FARM-VIP), then the traffic must be balanced (loadbalance vip inservice) using the described balancing rules (loadbalance policy FARM_POLICY), that is, all (class-default ) send to the farm FARM (serverfarm FARM). Also CISCO ACE responds to pings to this address (loadbalance vip icmp-reply active).

In order for the server responses to reach the client in general and with the correct address, it is necessary to create a translation of the internal addresses of the servers to the external VIP address.

Also, on all interfaces, add an ACL allowing everything. We imply that we are filtering traffic elsewhere. CISCO ACE blocks all traffic by default.

access-list PERMIT-ANY line 8 extended permit ip any any

access-list NAT line 1 extended permit ip host 192.168.1.11 any
access-list NAT line 2 extended permit ip host 192.168.1.12 any
access-list NAT line 3 extended permit ip host 192.168.1.13 any

class-map match-any PAT-ClassMap
2 match access-list NAT

policy-map multi-match NAT-PM
class PAT-ClassMap
nat dynamic 1 vlan 20

interface vlan 20
access-group input PERMIT-ANY
nat-pool 1 172.16.1.100 172.16.1.100 netmask 255.255.255.255 pat

interface vlan 40
ip address 192.168.1.1 255.255.255.0
access-group input PERMIT-ANY
service-policy input NAT-PM



On the FWSM (ASA, PIX) NAT is configured several times easier.

Minor touches (default route, SNMP):
ip route 0.0.0.0 0.0.0.0 172.16.1.1

snmp-server community xxx group Network-Monitor
snmp-server user user_name Network-Monitor auth sha p@ssword localizedkey
snmp-server host 172.16.1.2 traps version 2 xxx


Under the link (http://pastebin.com/DV4QM2Ya) you can find the complete configuration. To demonstrate the capabilities, CISCO ACE has an interface to the user network. For users, it performs the PAT function and inspects the FTP protocol so that there are no problems with this protocol (active / passive mode).

Monitoring what was received (base):
ACE # show serverfarm FARM
serverfarm : FARM, type: HOST
total rservers : 2
---------------------------------
----------connections-----------
real weight state current total failures
---+---------------------+------+------------+----------+----------+---------
rserver: SERVER-1
192.168.1.11:0 8 OPERATIONAL 44 52841950 12274606
rserver: SERVER-2
192.168.1.11:0 8 OPERATIONAL 49 51043947 13091531


ACE-MEL/Admin# show serverfarm FARM detail
serverfarm : FARM, type: HOST
total rservers : 2
active rservers: 2
description : -
state : ACTIVE
predictor : ROUNDROBIN
failaction : -
back-inservice : 0
partial-threshold : 0
num times failover : 0
num times back inservice : 0
total conn-dropcount : 44
Probe(s) :
HTTP_PROBE, type = HTTP
ICMP_PROBE, type = ICMP

---------------------------------
----------connections-----------
real weight state current total failures
---+---------------------+------+------------+----------+----------+---------
rserver: SERVER-1
192.168.1.11:0 8 OPERATIONAL 44 52841981 12274606
description : -
max-conns : - , out-of-rotation count : -
min-conns : -
conn-rate-limit : - , out-of-rotation count : -
bandwidth-rate-limit : - , out-of-rotation count : -
retcode out-of-rotation count : -
load value : 0

rserver: SERVER-1
192.168.1.11:0 8 OPERATIONAL 49 51043976 13091532
description : -
max-conns : - , out-of-rotation count : -
min-conns : -
conn-rate-limit : - , out-of-rotation count : -
bandwidth-rate-limit : - , out-of-rotation count : -
retcode out-of-rotation count : -
load value : 0


ACE # show rserver SERVER-1

rserver : SERVER-1, type: HOST
state : OPERATIONAL (verified by arp response)
---------------------------------
----------connections-----------
real weight state current total
---+---------------------+------+------------+----------+--------------------
serverfarm: FARM
192.168.1.11:0 8 OPERATIONAL 13 1288706


And many more other teams.

Summarizing

In this article I wanted to acquaint the reader with this equipment a little, and not only CISCO production, but in general with balancers as an important enough part of the data center infrastructure. There is a lot of information spinning in my head, but it seems to me that the post turned out to be not very small.

So, the main purpose of such devices: load sharing between services (which entails increased availability, performance, consolidates resources), transfer of SSL termination functions from servers to hardware accelerators, some increase in security (due to normalizations and other proprietary technologies), TCP / acceleration UDP (due to multiplexing, compression).

Also worth noting is the possibility of balancing not only in the aisles of a single data center, but also between geographically distant services.

We use the ACE20-MOD-K9 4Gbps module. It is loaded, of course, not on all 4 Gbps, but it performs its tasks. There were no problems with it during operation, it proved itself quite well. What I started writing about it. The fact is that, in particular, on the etherealmind.com resource I have not heard positive reviews towards CISCO ACE. Or do not write, or openly spit. Mostly they complain about hangs, IOS buggy, instability of work. I know that CISCO with its ACE is far from ahead of the rest. Engineers praise enough products from F5, while noting children's prices. I did not come across this equipment, and in general, in our lands it is a rarity, I have not seen such people.

If readers have a desire to know something in more detail - I will try to help, or even write a separate note.

I'm really looking forward to the comments and opinions of people who worked / work with such equipment. In fact, on Habré, the topic was practically unaffected.

CISCO ACE. Part 2: balancing remote servers and applications

Sources:
1. CISCO Documentation, cisco.com.
2. vivekganapathi.blogspot.com/2010/07/cisco-ace-4710-load-balancer.html .
3. www.packetslave.com/2010/01/24/cisco-ace-basic-http-load-balancing
4. docwiki.cisco.com/wiki/Cisco_Application_Control_Engine_ (ACE) _Configuration_Examples
5. etherealmind.com/cisco-ace-load-balance-stick-source-nat-part-1
6. etherealmind.com/cisco-ace-load-balance-stick-source-nat-part-2
7. etherealmind.com/cisco-ace-load-balance-stick-source-nat-part-3
8. etherealmind.com/cisco-ace-fwsm-resource-allocation-for-virtualization
9. www.cisco.com/en/US/products/hw/modules/ps2706/products_configuration_example09186a00809c3041.shtml

Source: https://habr.com/ru/post/143564/


All Articles