Contents

Overview of ACE L4 Load Balancing

Load balancing at L4 involves selecting a server in a server farm to service a client request based on the VIP address and protocol in the request. You configure a class map to classify (match) interesting traffic arriving at the ACE and associate the class map with a policy map to perform an action on the traffic based on the classification. With L4 load balancing, the ACE selects a server based on the first packet it receives in a particular flow. See the "Overview of ACE Connection Handling" section in the Troubleshooting Connectivity article.

Classifying L4 Traffic for Server Load Balancing

You classify inbound network traffic destined to or passing through the ACE based on a series of flow match criteria specified by a class map. Each class map defines a traffic classification, which is network traffic that is of interest to you. A policy map defines a series of actions (functions) that you want applied to a set of classified inbound or outbound traffic.

The three major steps in the traffic classification process are as follows:

Create a class map using the class-map command and the associated match commands, which comprise a set of match criteria related to Layer 3 and Layer 4 traffic classifications or Layer 7 protocol classifications.

Create a policy map using the policy-map command, which refers to the class maps and identifies a series of actions to perform based on the traffic match criteria.

Activate the policy map by associating it with a specific VLAN interface or globally with all VLAN interfaces using the service-policy command to filter the traffic received by the ACE.

Figure 1 provides a basic overview of the process required to build and apply the Layer 3, Layer 4, and Layer 7 policies that the ACE uses for SLB. The figure also shows how you associate the various components of the SLB policy configuration with each other.

The dropped conns counter under a VIP in the output of the show service policy detail command is incremented whenever a connection request destined to that VIP is rejected by the ACE. There are several reasons why the ACE rejects such connection requests. For example:

If all the real servers in the server farm associated with the VIP go down, then the VIP will go down. So, all the incoming connections to that VIP are rejected.

If the URL in a connection request to the VIP is unknown, then the connection request is rejected.

If the server that the ACE selects to load-balance the connection doesn't respond to the request, then, after maximum retries, the ACE rejects the connection.

The dropped conns counter is cumulative and the value may comprise entries from any of the following show command counters:

show stats loadbalance

Total Layer4 rejections

Total Layer7 rejections

Total Layer4 LB policy misses

Total Layer7 LB policy misses

Total times rserver was unavailable

show stats connection

Total Connections Timed-out
Total Connections Failed

The failures counter of the show serverfarm serverfarm_name command.

The Total drop decisions counter of the show stats inspect command.

4. Verify that the L4 policy is applied as a service policy to an active interface by entering the following command:

5. Check the total conn-dropcount field for the primary server farm in the output of the following command. Also, check the IP address, state, and the connection statistics for each real server that is configured in the server farm.

The ID Map is used to map real servers and server farms between the local and the remote peers in a redundant configuration. The Total IDMap Lookup Failures field increments if the local ACE fails to find the local ACE to peer ACE ID mapping. A failure can occur if the peer ACE did not send a proper remote ID for the local ACE to look up and so the local ACE could not perform a mapping or if the ID Map table was not created.