FTP Load Balancing on ACE in One-Arm Mode Configuration Example

From DocWiki

Contents

Goal

The goal of this document is to configure an ACE Module or ACE 4710 to perform FTP load balancing in a one-arm topology. It will cover the basics of the FTP protocol, and explain why specific configuration elements are necessary to allow FTP to function.

FTP Protocol Basics

FTP is a protocol which allows client PCs running FTP client software, to transfer files to and from a remote FTP server. An FTP session is itself composed of two TCP flows, each with a very specific role. The first flow is created as the user initiates the FTP connection to the server. It is used to pass FTP commands (such as GET, PUT, etc) back and forth between the client and server, and is known as the control channel. This flow is always sourced from the client PC, with the destination being the FTP server (generally TCP port 21), never the other way around. The next TCP flow is known as the data channel, and it is created when data needs to flow between the client and the server (file copies, directory listings, etc). This flow can be established in either direction, depending on whether ACTIVE FTP or PASSIVE FTP is being used. To establish the data connection during an Active FTP session, the server initiates the TCP connection to the client PC. To establish the data connection during a Passive FTP session, the client initiates the TCP connection to the FTP Server. It is important to note that when an FTP session authenticates properly but then hangs on directory listings or file transfers, generally some piece of network equipment is preventing the data channel from being properly established.

Design

Clients will establish an FTP control channel connection with the VIP configured on the ACE. Once established, the ACE will forward the control connection to one of the configured real servers. The ACE will inspect the commands being sent through the control connection, and will take action as necessary to ensure the data connection can also be established between the client and the server in the appropriate direction when necessary. Generally this will involve performing NAT on the IP addresses embedded within the FTP control channel messages, as well as opening any necessary ports in the ACE access-lists. The ACE will also source nat the request as it is passed to the real server. This will ensure that the server response is sent back to the ACE, rather than being sent through the MSFC, bypassing the ACE completely. Only the TCP port for the control channel must be explicitly permitted in the ACE access-list. The TCP port for the data channel is dynamically assigned by the client or server (depending on which FTP mode is used), and ACE will open a pin-hole in its access-list to allow traffic through to the real server on this port.

Configuration

The ACE configuration is performed in a layered fashion, making the order it is built in important. Each configuration step builds upon the previous step; the order this document will follow is outlined below.

Configure a management policy to allow admin access to the ACE

Configure access-list to permit traffic into the ACE from the client facing interface

Define real server addresses (create the rservers)

Group rservers together (create a serverfarm)

Define the virtual address (VIP)

Define how traffic is to be handled once it is received (L7 policy-map)

Next configure an access-list to permit the desired traffic to enter the ACE. Before the traffic can reach any configured virtual servers, it must be permitted by an access-list.
Note: While this example shows a “permit any any”, it is recommend ACLs be used to only permit specific traffic through the ACE.

The ultimate goal of this configuration is for ACE to distribute FTP connections to a group of real servers. The ACE must have each of these real servers configured as rservers, so that it knows each of their IP addresses. Note that unlike previous SLB products, a TCP/UDP port is NOT specified during this step; it will be defined when the rservers are added to a serverfarm.

The rservers must be grouped into a serverfarm, accomplishing two things. It allows the whole group of rservers to be attached to any load balancing actions with a single command, and it provides an opportunity to define the port on which the rservers are configured to accept traffic.

Note:

In this example, no port is configured on the rservers. This instructs the ACE to inherit the port from the virtual server which will be defined in a later step.

In order for the ACE to accept traffic on a virtual server IP, it must be configured using a class-map. In this example the VIP address is configured to accept traffic on TCP port 21, the standard port for FTP control channel connections.

Once the ACE accepts traffic destined to the virtual address, it must be told how to handle the traffic. This is accomplished by configuring an L7 policy-map. In this example the policy-map is configured to match all traffic (class-default matches anything), and to send it to the ftp serverfarm.

The final “glue” which ties all of the previous steps together, is the multi-match policy. It can contain multiple class references; each would be configured with a different VIP address. In this case only one class is referenced, instructing the ACE to only accept traffic destined to the single VIP address. The class reference also references the L7 policy-map, and a command to put the VIP in service.

Caution:

Since this configuration is an example of FTP load balancing, the class reference also contains the “inspect ftp” command. It instructs the ACE to inspect the FTP control channel commands, and perform any necessary fixups to allow the data channel to establish properly. Without this command, FTP load balancing WILL NOT WORK!

At this point the traffic handling logic is completely defined within the configuration. The final step is to apply this logic to the interfaces of the ACE. The following steps create the one-arm VLAN interface, and apply the multi-match policy and access-list to it. A NAT pool is also added to the interface, to allow the ACE to source nat the client requests.

Next, apply the nat-pool which was configured. The nat-pool is applied to the class reference within the multi-match policy. This instructs the ACE to source NAT all client requests destined for the VIP address.

The last step is to add a default route. This allows the ACE to be reachable from remote networks, and allows the ACE to return traffic to distant clients.

ACE-1/onearm(config)# ip route 0.0.0.0 0.0.0.0 172.16.5.1

Related show Commands

The following command can be used to verify that both the control channel and the data channel were successfully established. In this example conn-id 3 illustrates the control channel being established from the client to the VIP on TCP port 21, and conn-id 19 illustrates the data channel being established from the VIP to the client on TCP port 4726. The directionality of the data channel indicates that this is an active mode FTP session. Note that normally the data channel is torn down immediately after use; in order to observe its behavior a long-running file transfer must be in progress.