ACEAP

Implementing the Cisco ACE Appliance
Version 1.0 Revision 1.0

Lab Guide
Text Part Number: 97-2616-01

DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED “AS IS.” CISCO MAKES AND YOU RECEIVE NO WARRANTIES IN CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY OR IN ANY OTHER PROVISION OF THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO SPECIFICALLY DISCLAIMS ALL IMPLIED WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. This learning product may contain early release content, and while Cisco believes it to be accurate, it falls subject to the disclaimer above.

Your Client PC Information
You will be assigned a pod and a client by your instructor. Please write down your username, password, pod number, and client number here for easy reference during the remainder of the class.
Username Password Pod Number Client Number

IP Addressing
The IP addressing scheme is outlined in these tables, where: P = pod number C = client number

Connecting to Lab Devices
Connecting to Your Client PC
After you have been assigned a pod, a username, and a password by your instructor, go to http://10.199.0.246/ and log in using your assigned credentials. All work in this lab will be initiated from the client PC. Click the PC Desktop icon, which will launch an RDP connection. When prompted to log into the PC, use the username administrator and the password cisco.

The web servers are running Red Hat Advanced Server Enterprise 4. You will configure network connectivity to these servers during the lab exercises. To use Telnet to access the server, use the username cisco and the password cisco. To gain root access, use the command su - with the password cisco123.

Connecting to the Cisco ACE
The Cisco ACE modules can be accessed using Telnet or Secure Shell (SSH). A maximum of four Telnet and four SSH sessions can simultaneously log into any given context. If the sessions appear full, please bring this to the attention of the instructor. The Cisco ACE modules have a default configuration for the Admin context. This allows you to remotely access the Admin context to begin the lab. Use the default user admin and password admin to log into the Admin context. You can access the Admin context, using Telnet, SSH, or HTTPS. Note: **** When changing the admin password a strong password of 8 characters minimum is required. For the Lab Guide the user admin and password admin123 is used.

Lab 1: Implementing Virtualization
Complete this lab activity to practice what you learned in the related lesson.

Activity Objective
In this exercise, you will explore the lab configuration of the Cisco ACE Admin context. You will create new contexts and resource classes to understand the flexibility of virtualization on the Cisco ACE appliance. After completing this exercise, you will be able to meet these objectives: Review the existing Cisco ACE configuration Define contexts and resources classes Combine resource classes and contexts

Visual Objective
The figure illustrates what you will accomplish in this activity.

Task 1A: Configure New Contexts Using Device Manager
This lab simulates configuring a new Cisco ACE appliance just after system boot and initial Admin context configuration is created by the setup script. In this task, you will connect to the Admin context, using the Cisco ACE Device Manager and work with the virtualization commands.

Activity Procedure
Complete these steps:
Step 1

Connect to the Cisco ACE appliance Admin context by opening a connection to the PC Client workstation, then open your browser and enter https://172.19.110.29. Click OK to accept the warning message.

Create a user for the context you just created. From Admin > Role-Based Access Control > Users, choose the context you created from the drop-down box. Currently there are no users in your context. Create one by clicking the + (plus sign) button on the green bar. Create a new Admin user with the following username and password: yourname_clientC/qwer1234. (Example: test_client1)

Step 11

Click the Deploy Now button to deploy and verify the user that you have created.

Task 1B: Configure New Contexts Using CLI
This lab simulates configuring a new Cisco ACE appliance just after initial admin configuration and system boot. In this task, you will connect to the Admin context, using the Cisco ACE command-line interface (CLI) and work with the virtualization commands.

Activity Procedure
Complete these steps:
Note Use the terminal monitor command after you connect to any device, to make sure that all console messages are seen. This offers a valuable source of information when initially configuring the service appliances.

Step 1 Step 2

Connect to your client PC. Use Telnet on command line or Putty to access 172.19.110.29 from your client PC to access the Admin context of the Cisco ACE appliance within your pod. Log in with the username cisco and the password cisco.
C:\> telnet 172.19.110.29 switch login: admin Password: admin Cisco Application Control Software (ACSW) TAC support: http://www.cisco.com/tac Copyright (c) 1985-2007 by Cisco Systems, Inc. All rights reserved. The copyrights to certain works contained herein are owned by other third parties and are used and distributed under license. Some parts of this software are covered under the GNU Public License. A copy of the license is available at http://www.gnu.org/licenses/gpl.html. switch/Admin#

Step 3

Check system information and the version of the code currently running on the Cisco ACE appliance.
switch/Admin# sho ver Cisco Application Control Software (ACSW) TAC support: http://www.cisco.com/tac Copyright (c) 1985-2007 by Cisco Systems, Inc. All rights reserved. The copyrights to certain works contained herein are owned by other third parties and are used and distributed under license. Some parts of this software are covered under the GNU Public License. A copy of the license is available at http://www.gnu.org/licenses/gpl.html. Software loader: Version 0.95 system: Version A1(7) [build 3.0(0)A1(7) adbuild_01:21:07-2007/11/04_/auto/adbu-rel3/ws/c4710ace-a1_7throttl

The Cisco ACE appliance allows users to set a session time. This can be used to limit the current session or to prevent it from ever timing out. For this lab, disable the session time for your current session.
switch/Admin# terminal session-timeout 0

Step 5

The Cisco ACE also allows you to set future session idle timeout settings. For this lab, disable future sessions from timing out.
PodP-ACE/Admin# config Enter configuration commands, one per line. End with CNTL/Z. PodP-ACE/Admin(config)# login timeout 0

Note

The line vty command is different from that of the Cisco IOS Software, in that it does not use the exec-timeout command to control remote session idle timeouts.

Step 6

Use the show run command from the enable mode to see the current Cisco ACE configuration.
By default, the admin and www users are present. They exist in the Admin context and provide default access. The admin is, of course, for administration. The www user account is for supporting the Extensible Markup Language (XML) interface. Do not delete this user. If the www user is removed, the XML interface will be disabled for the entire appliance.

Create a new context named Testing-PC. By default, new contexts are members of the default resource class (like the Admin context in the previous step). Add two VLANs (2PC and 4PC) to the context, using the allocate-interface vlan command, and add a description of the Testing context.
switch/Admin(config)# context switch/Admin(config-context)# switch/Admin(config-context)# switch/Admin(config-context)# Testing-PC allocate-interface vlan 2PC allocate-interface vlan 4PC description Testing Context

To connect to a new context remotely, a network interface must be configured, and management traffic must be allowed to the context. This is done by creating a class map and a policy map and attaching the policy map to an interface, using the service-policy command.
To configure the basic context configuration, use the changeto context_name command.

Back at the Resource Class screen, create a new resource class named appl-set-PC and limit the class to 3% of the Cisco ACE resources. Ensure that you have restricted the maximum usage to 3% of Cisco ACE resources for this resource class.

Create a new resource class named appl-set-PC and limit the class to 3% of the Cisco ACE resources. Ensure that you have restricted the maximum usage to 3% of Cisco ACE resources for this resource class.

Why are the resource allocations not displayed, although the resource class has been created? __________________________________________________________________________ Apply the new resources class to the context Testing-PC.
switch/Admin(config)# context Testing-PC switch/Admin(config-context)# member appl-set-PC cart default switch/Admin(config-context)# member appl-set-PC

Activity Verification
You have completed this task when you have attained these results: Developed an understanding of the multiple ways resources can be allocated to a context
Note To avoid resource conflicts, remove this context from the Admin context when you have completed this task.

Lab 2: Using Network Address Translation
Complete this lab activity to practice what you learned in the related lesson.

Activity Objective
In this activity, you will configure your Cisco ACE context to perform a variety of Network Address Translations (NATs). The steps required to configure NAT on the Cisco ACE appliance are very different from the steps for using Cisco firewalls. NAT on Cisco ACE relies entirely on the Cisco Modular Policy CLI Framework. After completing this activity, you will be able to meet these objectives: Configure static NAT for a host Configure static NAT for a subnet Roll back the configuration

Required Resources
These are the resources and equipment required to complete this activity: Catalyst 6500 with Supervisor 720 Cisco 4710 Application Control Engine Appliance Server minimally running Telnet and HTTP

Task 1: Configure Static NAT for a Host
In this task, you will configure static destination NAT (DNAT) for a host. The goal is to configure the equivalent of a static (inside, outside) 172.16.PC.222 192.168.1.10 NAT, which can be read as “translate inside address 192.168.1.10 to 172.16.PC.222 on the outside.”

Activity Visualization
The figure illustrates what you will accomplish in this task.

Verify that you are in the correct context by looking at the prompt.
Switch/Lab-OPT-PC #

Step 4

Use the checkpoint system to roll back the configuration.
Switch/Lab-OPT-PC# checkpoint rollback baseline-mgmt

Note

The Cisco ACE module allows up to 10 configuration rollback checkpoints in each context. To view the currently created checkpoints, use the show checkpoint all command. To view the configuration contained in a checkpoint, use the show checkpoint detail command.

Step 5 Step 6

Execute show run to see what is preconfigured for this lab. The Cisco ACE module allows users to set a session time that can be used to limit the current session or to prevent it from ever timing out. For this lab, disable the session time for your current session.
Switch/Lab-OPT-PC# terminal session-timeout 0

Note

In configuration mode, login timeout can be used to modify the idle timeout of future sessions.

The (hitcount=0) output is always the part to look for when showing an access list. If it is not there, the access list is probably not applied to a VLAN interface.

Step 14

If you initiate a long-lived connection (Telnet, for example) from the client PC to 172.16.PC.222, you will see the xlate entry on the Cisco ACE.
Switch/Lab-OPT-PC# sh xlate NAT from vlan4PC:192.168.1.10 to vlan2PC:172.16.PC.222 count:1

Initiate a telnet session from the Linux server to the client; then capture a sniffer trace using Wireshark on the client PC to verify the server’s source IP address. Next, capture a trace on the client to verify that the server source address is NATed to 172.16.PC.222.
The Telnet session will fail because the client is not accepting Telnet connections.

Task 2: Configure Static NAT for a Subnet
In this task you will configure the equivalent of a static destination NAT (DNAT) for the entire server network. This task shows that NATing can be applied based on ACL matches and can encompass an entire network address space.

Activity Visualization
The figure illustrates what you will accomplish in this task.

Switch/Lab-OPT-PC(config-pmap-c)# nat static 172.16.PC.128 netmask 255.255.255.128 vlan 2PC Error: NAT static mapped ip netmask has to match with real ip netmask!
Note When matching a subnet, the static NAT range must have the same number of available IP addresses as the ACL classifies.

Verify that your static subnet NAT is working. Telnet to the servers (10.2.PC.10 - 10.2.PC.15) from your client PC; try several servers. While you are logged into at least one server session, use show conn and show xlate to see the Destination NAT.

Task 3: Apply the Baseline Configuration
The Cisco ACE ensures that no duplicate IPs exist across contexts per VLAN. Because of the overlapping IPs used in this lab, it is necessary to remove the VLAN interface for the server, so that the VLAN interface can be reused in the remaining labs.
Note If you want to compare your completed configuration with the one in the Answer Key provided at the end of this lab, be sure to do so before you complete this task.

Activity Procedure
Use the checkpoint feature to roll back to baseline-mgmt.
Switch/Lab-OPT-PC# checkpoint rollback baseline-mgmt This operation will rollback the system's running configuration to the checkpoint's configuration. Do you wish to proceed? (y/n) [n] y Rollback in progress, please wait... Generating configuration.... Rollback succeeded

Activity Verification
You have completed this task when you have removed the server VLAN from the context.

Answer Key: Using Network Address Translation
When you complete this activity, your switch running-configuration file will be similar to the following, with differences that are specific to your device or workgroup.

Lab 3: Configuring Server Load Balancing
Complete this lab activity to practice what you learned in the related lesson.

Activity Objective
In this exercise, you will configure your Cisco ACE context to match virtual IP (VIP)- destined traffic and load-balance these flows to the real servers on a private network behind the Cisco ACE context. To accomplish this, class maps are applied to classify client traffic destined to a VIP address. This traffic is then load-balanced to a server farm and one of the real servers is chosen to respond to the client request. To allow client traffic into the Cisco ACE context, an access list is required to permit the client flows. After completing this exercise, you will be able to meet these objectives: Define real server containers and server farms Configure class and policy maps to provide load balancing Observe the Cisco ACE load-balancing client traffic Roll back the configuration

Visual Objective
The figure illustrates what you will accomplish in this activity.

Task 1A: Configure Real Servers
In this task, you will add a configuration for the real servers within the pod. The Cisco ACE has administrative connectivity already enabled for the client. You will also create the Cisco Modular Policy CLI Layer 3 and 4 load-balancing policy maps and class map at the same time with the quick configuration tools available in the Cisco ACE 4710 Appliance Device Manager. The Modular Policy CLI classifies incoming traffic with class maps, which are then used in policy maps to force an action based on the class map match. The simplest type of these matches is load balancing based on a client’s attempt to reach a virtual IP address. This type of match is considered Layer 3 because it matches only the destination IP and then makes a loadbalancing decision.

Activity Procedure
Complete these steps:
Step 1 Step 2

Connect to your client PC. Make a Telnet connection to LAB-OPT-PC context at address 172.16.PC.20 and roll back the configuration to baseline-mgmt. Connect to the Cisco ACE appliance at https://172.19.110.29 through your web browser and log in with username/password of admin/admin123. View the Lab-OPT-PC context that will be used for the remainder of this lab. You can double-click your context from Config > Virtual Contexts. When you complete your changes, click the Deploy Now button at the bottom right of the screen. Context Name: Resource Class: VLANs: Policy Name: Management VLAN: Management IP Address: Management IP Netmask: Protocols to Allow: Default Gateway IP: SNMP v2c Community Lab-OPT-PC Default 2PC, 4PC MGMT-ACCESS 2PC 172.16.PC.20 255.255.255.0 Select all 172.16.PC.1 public

Step 3

Step 4

Note

You might need to synchronize the web configuration to the CLI configuration, using the Sync button at the bottom of the Config > Virtual Context screen.

Open another browser and log into your new context at https://172.16.PC.20 using the username and password that you just created.
If you failed to add all protocols in step 4, you will not be able to log into the web browser login for your context.

Verify that you are in the correct context by looking at the prompt.
switch/Lab-OPT-PC#

Step 4

Roll back the configuration to baseline-mgmt.
switch/Lab-OPT-PC# checkpoint rollback baseline-mgmt

Step 5 Step 6

Execute show run to see what is preconfigured for this lab. Allow HTTP and HTTPS mgmt access
switch/Lab-OPT-PC(config)# class-map type management match-any remote-access switch/Lab-OPT-PC (config-cmap-mgmt)# match protocol http any switch/Lab-OPT-PC (config-cmap-mgmt)# match protocol https any

Step 7

The Cisco ACE appliance allows users to set a session time. This can be used to limit the current session or to prevent it from ever timing out. For this lab, disable the session time for your current session.
switch/Lab-OPT-PC# terminal session-timeout 0

Note

In configuration mode, login timeout can be used to modify the idle timeout of future sessions.

Step 8

The first step to adding load balancing to the Cisco ACE context is to create real server instances, known as rservers on the Cisco ACE. Use the naming convention LINUX-<server_number>.
switch/Lab-OPT-PC# conf Enter configuration commands, one per line. switch/Lab-OPT-PC(config)# rserver LINUX-1 End with CNTL/Z.

Within the rserver object, assign the IP address of the real server and inservice the object. Use the IP address of 192.168.1.11 for the first real web server.
switch/Lab-OPT-PC(config-rserver-host)# ip address 192.168.1.11 switch/Lab-OPT-PCpodPclientC(config-rserver-host)# ins switch/Lab-OPT-PC(config-rserver-host)# exit

Step 10

Create another rserver using the IP address of the second real web server 192.168.1.12 with the name LINUX-2.
switch/Lab-OPT-PC(config)# rserver LINUX-2 switch/Lab-OPT-PC(config-rserver-host)# ip address 192.168.1.12 switch/Lab-OPT-PC(config-rserver-host)# inservice switch/Lab-OPT-PC(config-rserver-host)# exit

Step 11

View the rservers you have just created, using the show run and show rserver commands.

switch/Lab-OPT-PC(config)# do show rserver LINUX-1 rserver : LINUX-1, type: HOST state : INACTIVE ----------------------------------------connections----------real weight state current total ------------------+------+------------+----------+-----------------Step 12

After the rservers have been created, they must be added to a server farm for use in load balancing. Currently, the only server farm type is host.
switch/Lab-OPT-PC(config)# serverfarm WEBFARM

Step 13

Add the recently created rservers to the server farm. Be sure to inservice the real servers within the server farm. Failure to do so will cause the Cisco ACE appliance to consider these real servers out of service, and the server farm will not be capable of receiving or responding to client requests.
switch/Lab-OPT-PC(config-sfarm-host)# rserver LINUX-1 switch/Lab-OPT-PC(config-sfarm-host-rs)# inservice switch/Lab-OPT-PC(config-sfarm-host)# rserver LINUX-2

Add the other three web servers to the server farm and ensure that all five web servers are in OPERATIONAL state. The three additional web servers are as follows; put them into the server farm WEBFARM. LINUX-3 192.168.1.13 LINUX-4 192.168.1.14 LINUX-5 192.168.1.15

Activity Verification
You have completed this task when you attain these results: The rservers created are in the OPERATIONAL state. The rservers are in the OPERATIONAL state within the server farm. ARP entries exist for each of the rservers.

Task 2A: Configuring Load-Balancing Class Maps and Policy Maps
In the first task, you created your VIP (Layer 3 and 4 class map), rservers, server farm, Layer 3 and 4 policy map (multimatch policy map or service policy) and Layer 7 load-balancing policy map. All that remains to do in this step is to add an access control list (ACL) to permit traffic to the interface where client traffic will be received (VLAN 2PC).

Now you can add entries to the ACL, using the plus sign (+). Protocol: IP Permit: yes Any Source: yes Any Destination: yes And then click Deploy Now.
When you click Any Source or Any Destination the configuration options will change.

Task 2B: Configuring Load-Balancing Class Maps and Policy Maps
The Cisco ACE appliance uses a Modular Policy CLI to classify incoming traffic with class maps, which are then used in policy maps to force an action based on the class map match. The simplest of these types of matches is load balancing based on a client’s attempt to reach a virtual IP (VIP) address. This type of match is considered Layer 3 because it matches only the destination IP and then makes a load-balancing decision.

Activity Procedure
Complete these steps:
Step 1

Start by creating a class map to distinguish traffic destined for a VIP from traffic destined elsewhere. Use the IP address 172.16.PC.150.
switch/Lab-OPT-PC(config)# class-map VIP-150 switch/Lab-OPT-PC(config-cmap)# match virtual-address 172.16.PC.150 any

Step 2

A policy map of type load balance is required. The Cisco ACE will attempt to match a defined class map at L5–L7 in the order of occurrence, as indicated by the keyword first-match. The class default is used to handle nonmatching client requests. The significance of the class map order will be apparent in a later lab. For this task, simply create a load-balancing policy map using class-default.
switch/Lab-OPT-PC(config)# policy-map type loadbalance firstmatch lb-logic switch/Lab-OPT-PC(config-pmap-lb)# class class-default switch/Lab-OPT-PC(config-pmap-lb-c)# serverfarm WEBFARM

Task 3: Test the New VIP Load-Balancing Configuration
In this task, you will verify that Layer 3 and 4 load balancing is working correctly. This should be the same task for both the GUI and the command-line interface (CLI).

Activity Procedure
Complete these steps:
Step 1

Use a browser on the client PC to verify that the Cisco ACE appliance is loadbalancing traffic to the server farm, using the URL http://172.16.PC.150/.
The color of an image indicates which server supplied the image.

Note Step 2 Note

Notice that the service policy counters increment as connections are handled.
Because the Cisco ACE 4710 Appliance Device Manager interface autogenererates policy map and class map names, some differences might occur between the CLI and GUI configurations.

Task 4: Apply the Baseline Configuration
The Cisco ACE ensures that no duplicate IPs exist across contexts per VLAN. Because of the overlapping IPs used in this lab, it is necessary to remove the VLAN interface for the server, so that the VLAN interface can be reused in the remaining labs.

Activity Procedure
Step 1

Use the checkpoint feature to roll back to baseline-mgmt.
switch/Lab-OPT-PC# checkpoint rollback baseline-mgmt This operation will rollback the system's running configuration to the checkpoint's configuration. Do you wish to proceed? (y/n) [n] y Rollback in progress, please wait... Generating configuration.... Rollback succeeded

Activity Verification
You have completed this task when you have removed the server VLAN from the context.

Lab 4: Implementing Health Monitoring
Complete this lab activity to practice what you learned in the related lesson.

Activity Objective
In this exercise, you will configure your Cisco ACE context to monitor real servers. After completing this exercise, you will be able to meet these objectives: Define health monitoring for a real server Define health monitoring for a real server with a server farm Define health monitoring for an entire server farm Roll back the configuration

Visual Objective
The figure illustrates what you will accomplish in this activity.

Task 1A Configure Health Monitoring for Real Servers
When configuring the Cisco ACE for health probe monitoring, out-of-band health monitoring allows the Cisco ACE to send active probes periodically to determine the server state. Internet Control Message Protocol (ICMP), TCP, HTTP, and other predefined health probes, including scripted probes, are in this health monitoring category. The Cisco ACE supports 4000 unique probes and 256 scripted probes per system, and allocates 1000 sockets for health monitoring. There are three ways to apply probes on the Cisco ACE; this task will show how to apply probes per rserver.

Task 1B: Configure Health Monitoring for Real Servers
When configuring the Cisco ACE for health probe monitoring, out-of-band health monitoring allows the Cisco ACE to send active probes periodically to determine the server state. Internet Control Message Protocol (ICMP), TCP, HTTP, and other predefined health probes, including scripted probes, are in this health monitoring category. The Cisco ACE supports 4000 unique probes and 256 scripted probes per system, and allocates 1000 sockets for health monitoring. There are three ways to apply probes on Cisco ACE; this task will show how to apply probes per rserver.

Activity Procedure
Complete these steps:
Step 1 Step 2

Connect to your client PC. Connect to the Cisco ACE management IP address for this lab context.
C:\> telnet 172.16.PC.20 Username: cisco Password: cisco123 Cisco Application Control Software (ACSW) TAC support: http://www.cisco.com/tac Copyright (c) 1985-2007 by Cisco Systems, Inc. All rights reserved. The copyrights to certain works contained herein are owned by other third parties and are used and distributed under license. Some parts of this software are covered under the GNU Public License. A copy of the license is available at http://www.gnu.org/licenses/gpl.html.

Step 3

Verify that you are in the correct context by looking at the prompt:
Switch/Lab-OPT-PC#

Step 4 Step 5 Note Step 6

Use the checkpoint system to roll the configuration to the SLB-END. Use show run to see what is preconfigured for this lab.
This lab is built on the principles learned in the previous lab.

This is a change in the default behavior of the Caching Services Module (CSM). The Cisco ACE does not accept any response code by default. Adding one will enable a successful probe.
switch/Lab-OPT-PC(config-rserver-host)# probe http get-index switch/Lab-OPT-PC(config-probe-http)# expect status 200 200

Note

If using the default settings, the probe will take three (pass interval) iterations of 300 seconds (pass interval) before the rserver will be put back into rotation. To expedite the process, simply perform a no inservice/inservice on the rserver; this will force the probing to enter the initialization state.

Enable the server VLAN interface and verify that the probe succeeds and that the rserver is placed back in an operational state.
The pass detect interval is 5 minutes, so expect this delay if the default value was not altered.

Note

Activity Verification
You have completed this task when you configure a probe for an rserver and verify that it is successfully monitoring the rserver

Activity Verification
You have completed this task when you attain these results: Configured a probe for an rserver and verified that it is successfully monitoring the rserver Configured a probe for a server farm and displayed the resulting traffic

There are several ways to determine why the probe is failing. One approach is to look at the server and verify that Secure Sockets Layer (SSL) is running and use a sniffer trace. View the probe from the Cisco ACE.

Although the sniffer traces show valuable information that covers the default HTTPS probe characteristics, they do not add any more useful data than what you have already determined. You can search for another approach to troubleshoot, because all that is left is to use SSLdump and the server’s SSL certificate and RSA key to decrypt the message. Rather than going to this step, you could view the detail of the probe.

This was much more useful than the sniffer approach. This is telling you something that you have seen before with the HTTP probe. The HTTPS probes are simply the HTTP probe using the OpenSSL in the control plane. Thus for HTTPS it is mandatory to configure the expected status before the probe will be successful.

Task 4: Apply the Baseline Configuration
The Cisco ACE ensures that no duplicate IPs exist across contexts per VLAN. Due to the overlapping IPs used in this lab, it is necessary to remove the VLAN interface for the server, so that it can be reused in the remaining labs.

Activity Procedure
Use the checkpoint feature to roll back to baseline-mgmt.
Switch/Lab-OPT-PC# checkpoint rollback baseline-mgmt This operation will rollback the system's running configuration to the checkpoint's configuration. Do you wish to proceed? (y/n) [n] y Rollback in progress, please wait... Generating configuration.... Rollback succeeded

Activity Verification
You have completed this task when you have removed the server VLAN from the context.

Lab 5: Configuring Layer 7 Load Balancing
Complete this lab activity to practice what you learned in the related lesson.

Activity Objective
In this exercise, you will create new class maps and server farms to demonstrate URL load balancing. After completing this exercise, you will be able to meet these objectives: Define multiple server farms Create a classification for URL strings Send matches to a specified server Modify a class map to alter URL processing Optimize the mixed-traffic VIP by configuring match-any and match-all Roll back the configuration

Visual Objective
The figure illustrates what you will accomplish in this activity.

Task 1A: Configure a Real Server
In this task, you will add a configuration for the real servers within the pod. The Cisco ACE has administrative connectivity already enabled for the client. For Layer 3 and 4 load balancing you can create the server farm at the same time you create the virtual IP (VIP). With Layer 7 load balancing in this lab, you will need multiple server farms, so you will create them at the beginning, for ease in configuration.

Verify that you are in the correct context by looking at the prompt.
switch/Lab-OPT-PC#

Step 4

Use the checkpoint system to roll the configuration to the SLB-END checkpoint.
Swich/Lab-OPT-PC# checkpoint rollback SLB-END

Step 5 Step 6

Use show run to see what is preconfigured for this lab. Use the serverfarm command to create a server farm for IE servers only.
PodP-ACE/Lab2-L7-PC(config)# serverfarm IE-WEB

Step 7

Add the recently created rservers to the server farm. Be sure to inservice the real servers within the server farm. Failure to do so will cause the Cisco ACE appliance to consider these real servers out of service, and the server farm will not be capable of receiving or responding to client requests.
switch/Lab-OPT-PC(config-sfarm-host)# rserver LINUX-1 switch/Lab-OPT-PC(config-sfarm-host-rs)# inservice switch/Lab-OPT-PC(config-sfarm-host)# rserver LINUX-2 switch/Lab-OPT-PC(config-sfarm-host-rs)# inservice

Step 8

Add the other three web servers to the server farm called NON-IE. LINUX-3 192.168.1.13 LINUX-4 192.168.1.14 LINUX-5 192.168.1.15

The Server VLAN was added during the configuration rollback. Use the show arp command to ensure that the Cisco ACE populates its Address Resolution Protocol (ARP) table with the MACs of the real server.
switch/Lab-OPT-PC# show arp

Activity Verification
You have completed this task when the servers are marked as OPERATIONAL in the new server farms.

Task 2A: Configure Layer 7 Load Balancing
To send traffic to each server farm you just created (IE-WEB & NON-IE) based on the contents of Layer 7 data, the Cisco ACE must be configured with a class map to properly classify the traffic destined to the server farm.

Activity Procedure
Complete these steps:
Step 1

Create a VIP named VIP-171, give it an IP address of 172.16.PC.171 for all IP traffic, and assign it to the client-facing VLAN interface. Also add one of the server farms already configured (you will remove it in a later step). Click Config > Virtual Contexts > Load Balancing > Virtual Servers “+” add button

Now choose the policy map that was autocreated by the interface when you created the virtual server (for example, VIP-171-l7slb) and edit the class statements. Remove the default action class-default and add the two new class maps with the action for CHECK-HEADERS > IE-WEB and OTHER-HTTP > NON-IE. Click Config > Virtual Contexts > Expert > Policy Map.

Task 2B: Configure Layer 7 Load Balancing
In order to send traffic to each server farm you just created (IE-WEB & NON-IE) based on the contents of Layer 7 data, the Cisco ACE must be configured with a class map to properly classify the traffic destined to the server farm.

Verify that the VIP is applied and inservice (meaning that the Cisco ACE will respond to traffic destined to the VIP address).
After a policy map of type multimatch is added to the service policy, any additions to the policy map are immediately applied.

Task 3: Test the New VIP Load-Balancing Configuration
In this task, you will use show commands to verify the working order of the current Cisco ACE context. You will verify that the VIP works as expected and that the client is being load balanced between real servers.

Activity Procedure
Complete these steps:
Step 1

On the client, use the IE browser to verify that the Cisco ACE appliance is loadbalancing traffic to the IE-WEB server farm.
http://172.16.PC.171/index.html

Now use Firefox to connect to the same site. Verify that the Cisco ACE appliance is now sending the client to the NON-IE server farm.
http://172.16.PC.171/index.html

Step 4

Now use either browser to connect to the same VIP, but this time without specifying a URL.
http://172.16.PC.171/

Activity Verification
You have completed this task when you attain these results: Successfully load-balance HTTP requests to the VIP and verify that only the proper servers are responding, based on the client issuing the HTTP requests Understand the .* regular expression, which matches both anything and nothing

Task 4: Mixing Layer 4 and Layer 7 Traffic
In this task, you will configure the Layer 7 parsing behavior of the Cisco ACE appliance to distinquish between HTTP traffic and other traffic.
Note There is no Cisco ACE 4710 Device Manager task here; if you chose to do this task with the Cisco Device Manager, remember that the Device Manager autogenerates names, so the policy map L7-LOGIC would be called VIP-171-l7slb, for example; this applies to several names throughout this task.

You could consider the failure to be caused by the no default class map, which makes sense based solely on the configuration. Telnet is not HTTP; thus it cannot match the existing L7 class maps. However, there is a class default provided for handling traffic that does not match an L7 class map. Apply this class default.
switch/Lab-OPT-PC(config)# policy-map type loadbalance firstmatch L7-LOGIC switch/Lab-OPT-PC(config-pmap-lb)# class class-default switch/Lab-OPT-PC(config-pmap-lb-c)# serverfarm WEBFARM

Step 5

Again, from the client, use Telnet to connect to the VIP.
telnet 172.16.PC.171

Why did the connection fail?
Step 6

To rectify the problem and allow HTTP and non-HTTP traffic to access the VIP, a new policy map must be created that does not impose HTTP parsing.
switch/Lab-OPT-PC(config)# policy-map type loadbalance firstmatch NONL7-LB switch/Lab-OPT-PC(config-pmap-lb)# class class-default switch/Lab-OPT-PC(config-pmap-lb-c)# serverfarm WEBFARM

Step 7

If the new policy were to be directly applied to the multimatch policy, the class map VIP-171 would be used twice and the second occurance would never be used. Therefore, a new class map must be made. In the majority of cases, customers know the port on which HTTP is allowed. In this lab situation the default port is used. Rather than creating a new class map for the non-Layer 7 load-balancing policy, create one for the more specific Layer 7 load-balancing logic.
PodP-ACE/Lab2-L7-PC(config)# class-map VIP-171-HTTP PodP-ACE/Lab2-L7-PC(config-cmap)# match virtual-address 172.16.PC.171 tcp eq www

Notice that the counters are not incrementing for the VIP-171-HTTP class. This is because the VIP-171 class map matches connections to any port before VIP-171HTTP is even checked. You introduced this error when you added the VIP-171HTTP class map to the CLIENT-VIPS policy map. Modify the order of the class maps in the policy map.

Verify that Telnet and the HTTP policies all work correctly. Display the service-policy counters.

Activity Verification
You have completed this task when you attain these results: Successfully load-balance HTTP requests to the VIP and verify that only the proper servers are responding, based on the client issuing the HTTP requests Understand the HTTP parsing impact to a policy map Can use HTTP to a specific server, based on client, and can gain non-HTTP access to the server

The rationale for creating the OTHER-HTTP class map was to classify only HTTP traffic and send it to the NON-IE server farm. In Task 3 you saw how a single match of type HTTP forces all traffic to be inspected as if it were HTTP; thus the default class map will serve the same function as making the class map OTHER-HTTP. View the regex memory consumption before removing the class map.

Task 6: Apply the Baseline Configuration
The Cisco ACE ensures that no duplicate IPs exist across contexts per VLAN. Because of the overlapping IPs used in this lab, it is necessary to remove the VLAN interface for the server, so that the VLAN interface can be reused in the remaining labs.

Activity Procedure
Step 1

Use the checkpoint feature to roll back to baseline-mgmt.
switch/Lab-OPT-PC# checkpoint rollback baseline-mgmt This operation will rollback the system's running configuration to the checkpoint's configuration. Do you wish to proceed? (y/n) [n] y Rollback in progress, please wait... Generating configuration.... Rollback succeeded

Activity Verification
You have completed this task when you have removed the server VLAN from the context.

Lab 6: Enabling Sticky Connections
Complete this lab activity to practice what you learned in the related lesson.

Activity Objective
In this exercise, you will configure your Cisco ACE context to match VIP-destined traffic and load-balance these flows to the real servers on a private network behind the Cisco ACE context. To accomplish this, class maps are applied to classify client traffic destined to a virtual IP (VIP) address. This traffic is then load-balanced to a server farm, and one of the real servers is chosen to respond to the client request. To allow client traffic into the Cisco ACE context, an access list is required to permit the client flows. After completing this exercise, you will be able to meet these objectives: Define real server containers and server farms Apply source IP sticky to ensure client persistence Roll back the configuration

Visual Objective
The figure illustrates what you will accomplish in this activity.

Verify that you are in the correct context by looking at the prompt.
switch/Lab-OPT-PC#

Step 3 Step 4 Step 5

Use the checkpoint system to roll the configuration to the SLB-END. Execute show run to see what is preconfigured for this Lab. Create a sticky group named STICKY-GRP.
switch/Lab-OPT-PC(config)# sticky ip-netmask 255.255.255.255 address source STICKY-GRP

Task 2: Apply the Baseline Configuration
The Cisco ACE ensures that no duplicate IPs exist across contexts per VLAN. Because of the overlapping IPs used in this lab, it is necessary to remove the VLAN interface for the server, so that the VLAN interface can be reused in the remaining labs.

Activity Procedure
Use the checkpoint feature to roll back to baseline-mgmt.
switch/Lab-OPT-PC# checkpoint rollback baseline-mgmt This operation will rollback the system's running configuration to the checkpoint's configuration. Do you wish to proceed? (y/n) [n] y Rollback in progress, please wait... Generating configuration.... Rollback succeeded

Activity Verification
You have completed this task when you have removed the server VLAN from the context.

Lab 7: Enabling Protocol Inspection
Complete this lab activity to practice what you learned in the related lesson.

Activity Objective
In this exercise, you will implement fixups and inspection for the FTP protocol. After completing this exercise, you will be able to meet these objectives: Implement fixups for the FTP protocol Implement FTP inspection (Strict FTP) Roll back the configuration

Visual Objective
The figure illustrates what you will accomplish in this activity.

Verify that you are in the correct context by looking at the prompt:
switch/Lab-OPT-PC#

Step 4

Use the checkpoint system to roll the configuration to the SLB-END to ensure that the following task steps correspond to the Cisco ACE configuration. Execute show run to see what is preconfigured for this lab.
This lab is built on the principles learned in the previous lab.

Use the client PC to connect to the new VIP, using FTP from the command prompt. Look at the directory and download a file.
C:\Documents and Settings\Administrator>ftp 172.16.PC.172 Connected to 172.16.PC.172. 220 (vsFTPd 2.0.1) User (172.16.PC.172:(none)): cisco 331 Please specify the password. Password: cisco

Although the FTP connection was successful, why did the directory listing or file transfer, or both, fail?
Step 10

To apply the FTP fixup, the multimatch policy map must be configured to inspect FTP traffic. This enables FTP fixups for a VIP.
switch/Lab-OPT-PC(config-pmap-c)# inspect ftp

Step 11

Try the FTP connection from the client again. Use the show service to see the counters. Notice that now there are FTP inspection counters.

Task 2: Configure Strict FTP
The Cisco ACE uses a Layer 7 FTP command class map to perform FTP request inspection for FTP sessions, allowing you to restrict specific commands by the Cisco ACE. This function provides a security feature to prevent web browsers from sending embedded commands to the Cisco ACE in FTP requests. Each specified FTP command must be acknowledged before the Cisco ACE allows a new command. To create a Layer 7 class map to be used for the inspection of FTP request commands, use the class-map type ftp inspect command.

Activity Procedure
Complete these steps:
Step 1

Create a server farm for a different FTP server to handle only strict FTP connections. Call the server farm STRICT-FTP-APP and add rserver LINUX-2. Create a new class map VIP-173-STRICT to handle strict FTP sessions. Use the virtual IP address 172.16.PC.173 and restrict the match to the FTP port. Create a new LB policy called STRICT. Send all traffic to the server farm STRICT-FTP-APP. Define the strict FTP matching. Do this in a class map, because Cisco ACE is classifying FTP requests as they are received from the client. Create a class map called NO-PUTS and define a match for put.
switch/Lab-OPT-PC(config)# class-map type ftp inspect matchany NO-PUTS switch/Lab-OPT-PC(config-cmap-ftp-insp)# match request-method put

Now a new policy type is needed. The “inspect” policy type is used by strict FTP to apply the previously created class map. Any traffic matching the class map NOPUTS will be denied. Create a policy map called FTP-INSPECT-POLICY.
switch/Lab-OPT-PC(config)# policy-map type inspect ftp firstmatch FTP-INSPECT-POLICY switch/Lab-OPT-PC(config-pmap-ftp-ins)# class NO-PUTS switch/Lab-OPT-PC(config-pmap-ftp-ins-c)# deny

Task 3: Apply the Baseline Configuration
The Cisco ACE ensures that no duplicate IPs exist across contexts per VLAN. Because of the overlapping IPs used in this lab, it is necessary to remove the VLAN interface for the server, so that the VLAN interface can be reused in the remaining labs.

Activity Procedure
Use the checkpoint feature to roll back to baseline-mgmt.
# checkpoint rollback baseline-mgmt This operation will rollback the system's running configuration to the checkpoint's configuration. Do you wish to proceed? (y/n) [n] y Rollback in progress, please wait... Generating configuration.... Rollback succeeded

Activity Verification
You have completed this task when you have removed the server VLAN from the context.

Lab 8: Configuring SSL Termination
Complete this lab activity to practice what you learned in the related lesson.

Activity Objective
In this exercise, you will configure Secure Sockets Layer (SSL) termination. After completing this exercise, you will be able to meet these objectives: Configure SSL termination when you have certificates and keys Configure SSL termination when you must create certificates and keys Roll back the configuration

Visual Objective
The figure illustrates what you will accomplish in this activity.

Task 1: Configure SSL Termination when You Have Certificates and Keys
It is very simple to configure SSL services on the Cisco ACE appliance. All that is needed is the SSL certificate and (Rivest, Shamir, and Adleman) RSA key added to an SSL proxy and associated to a classification of traffic.

Verify that you are in the correct context by looking at the prompt.
switch/Lab-OPT-PC#

Step 4 Step 5 Note Step 6

Use the checkpoint system to roll the configuration to the SLB-END. Use show run to see what is preconfigured for this lab.
This lab is built on the principles learned in the previous lab.

Delete any crypto files on the Cisco ACE before beginning this lab.
switch/Lab-OPT-PC# crypto delete all This operation will delete all crypto files for this context from the disk, but will not interrupt existing SSL services. If new SSL files are not applied SSL services will be disabled upon next vip inservice or device reload. Do you wish to proceed? (y/n) [n] y

This is required, because, by default, Apache installs the server certificate and key into a root-owned directory with permissions which allow only the owner to read and write the files. This prevents the FTP server from accessing the files. Overwrite the destination files if prompted.

Test the SSL configuration by using a client browser to access https://172.16.PC.171/. Take time to verify that the certificate the client receives is the correct SSL certificate. Is the connection completely successful? View the service policy states.

switch/Lab-OPT-PC(config-pmap-c)# do sho server SSL-SF serverfarm : SSL-SF, type: HOST total rservers : 2 ------------------------------------------connections--------real weight state current total ---------------+------+------------+----------+-----------------rserver: LINUX-1 192.168.1.11:0 8 OPERATIONAL 0 1 rserver: LINUX-2 192.168.1.12:0 8 OPERATIONAL 0 1 Note The issue is that the server farm has Layer 3 rservers; in other words, real servers defined by IP only. This means that Cisco ACE will not implicitly translate the port addresses of client requests with PAT. On the wire, the server sees the client load-balancing to LINUX-1 or 2 and then a TCP SYN to port 443 followed by an HTTP GET, which the Apache HTTPSD server will reject; resulting in a blank page after receiving the SSL certificate. Step 18

Make the rservers port-bound in the server farm to force Cisco ACE to implicitly translate the destination ports of incoming connections to direct them to the Apache HTTPD server residing on port 80.
switch/Lab-OPT-PC(config-sfarm-host-rs)# rserver LINUX-1 80 switch/Lab-OPT-PC(config-sfarm-host-rs)# rserver LINUX-2 80

Task 2: Configure SSL Termination when You Must Create Certificates and Keys
Cisco ACE allows the user to create an RSA key pair and CSR. These are the core server components for creating an SSL certificate. The other required component is a certificate authority (CA). CAs can be third-party companies such as VeriSign or Thawte, or freeware CAs such as OpenSSL or the Microsoft CA Server.
Note You cannot create self-signed certificates on the Cisco

ACE appliance.

Activity Procedure
Complete these steps:
Step 1

In this lab task, you will reuse the server farm and load-balancing policy map created in the previous exercise. A crypto parameter map is required to define the parameters used in the generation of a Certificate Signing Request (CSR). This benefit of this is that the CSR can be easily re-created if needed, without reentering all the CSR data again. Create a CSR parameter map and name it ACE-CSR-INFO.
PodP-ACE/LAB-SSL-PC(config)# crypto csr-params ACE-CSR-INFO switch/Lab-OPT-PC(config-csr-params)# country US switch/Lab-OPT-PC(config-csr-params)# state California switch/Lab-OPT-PC(config-csr-params)# locality SJC switch/Lab-OPT-PC(config-csr-params)# organization-name Cisco switch/Lab-OPT-PC(config-csr-params)# organization-unit ADBU switch/Lab-OPT-PC(config-csr-params)# common-name www.example.com switch/Lab-OPT-PC(config-csr-params)# serial-number 1234 switch/Lab-OPT-PC(config-csr-params)# email secadmin@example.com

Before the CSR can be generated, an RSA key pair must be created. Use 1024 bits and name it ACEKEY. Delete an existing file if necessary. When this is created, the crypto generate csr command combines the public key and information in the CSR parameter map to create a CSR in PEM format.

Sign the CSR, using the Linux server to make an SSL certificate or obtain the certificate free from Thawte/Verisign. When using the Linux server, paste the Cisco ACE CSR into a file.
The entire CSR, including the -----BEGIN and -----END lines, must be copied from the Cisco ACE and pasted into a file on the Linux server. The UNIX cat command used below copies from the terminal to a file. After pasting the CSR, press Enter to ensure that a final carriage return is present in the file; then end the cat command by pressing Control-D.

Use openssl to create a Root CA certificate. Press Enter for all the default questions. In the real world, you would want to fill these out appropriately.

[cisco@linux1 ~]$ openssl req -newkey rsa:1024 -nodes -x509 -keyout rootCAkey.pem -out rootCAcert.pem -config /opt/lampp/etc/openssl.cnf Generating a 1024 bit RSA private key ...........................................++++++ .......................++++++ writing new private key to 'rootCAkey.pem' ----You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----Country Name (2 letter code) [GB]: State or Province Name (full name) [Berkshire]: Locality Name (eg, city) [Newbury]: Organization Name (eg, company) [My Company Ltd]:Organizational Unit Name (eg, s ection) []: Common Name (eg, your name or your server's hostname) []: Email Address []: Step 7

For this example, force the Cisco ACE VIP to accept connections only from clients capable of using the standard strong cipher RC4-128-MD5. Create a parameter map of type-ssl, called RC4-ONLY.
An SSL parameter map defines the SSL session parameters that the Cisco ACE applies to an SSL proxy service. Creating an SSL parameter map allows you to apply the same SSL session parameters to different proxy services.

Test the SSL configuration by using a client browser to reach https://172.16.PC.172/. Take time to verify that the certificate the client receives is the correct SSL certificate. Is the connection completely successful? View the service policy states.

Activity Verification
You have completed this task when you attain these results: Created an RSA key and CSR on Cisco ACE Used OpenSSL to create a Root CA cert and key Used OpenSSL to sign the Cisco ACE CSR to make it an SSL certificate Applied the Cisco ACE SSL certificate, and verified that SSL termination works as expected

Task 3: Apply the Baseline Configuration
The Cisco ACE ensures that no duplicate IPs exist across contexts per VLAN. Because of the overlapping IPs used in this lab, it is necessary to remove the VLAN interface for the server, so that the VLAN interface can be reused in the remaining labs.

Activity Procedure
Use the checkpoint feature to roll back to baseline-mgmt.
switch/Lab-OPT-PC# checkpoint rollback baseline-mgmt This operation will rollback the system's running configuration to the checkpoint's configuration. Do you wish to proceed? (y/n) [n] y Rollback in progress, please wait... Generating configuration.... Rollback succeeded

Activity Verification
You have completed this task when you have removed the server VLAN from the context.

Lab 9: Enabling HTTP Optimizations
Complete this lab activity to practice what you learned in the related lesson.

Activity Objective
In this exercise, you will configure your Cisco ACE context to monitor real servers. After completing this exercise, you will be able to meet these objectives: Define application acceleration parameters Test application acceleration

Required Resources
These are the resources and equipment that are required to complete this activity: Catalyst 6500 with Supervisor 720 Cisco 4710 Application Control Engine Appliance Server minimally running Telnet and HTTP

Task 1: Enable HTTP Optimizations
The Neufoo applications team has been receiving complaints about application response time and overall performance. They have begun to examine things from the server side, but you know that the Cisco ACE can assist in client-side delivery with the new web optimization features. In this section, you will configure the Cisco ACE to address a variety of application delivery-related problems. You will experiment with three optimizations: Compression Delta optimization FlashForward

Activity Procedure
Complete these steps:
Step 1 Step 2

From the client PC, connect to 172.16.PC.20. Verify that you are in the correct context by looking at the prompt:
switch/Lab-OPT-PC

Step 3

Within Lab-OPT-PC, use the checkpoint rollback command to roll back to optstart. Apply compression to the virtual IPs (VIPs) that you have created. Compression is a simple optimization, supported by the HTTP 1.1 standard. It will help with bandwidth usage over the network, with the added benefit of usually improving response times to the user. You can easily configure the Cisco ACE to compress responses from the 191 VIP by adding the following to the POM-L7lb policy map.
switch/Lab-OPT-PC(config)# policy-map type loadbalance firstmatch POM-L7lb switch/Lab-OPT-PC(config-pmap-lb)# class CM-DELTA switch/Lab-OPT-PC(config-pmap-lb)# compress default-method deflate

Step 4

Step 5

This configuration change uses deflate as the default method of compression. We can easily verify that compression is working by examining the response from the VIP. The response size for HTML data should reflect the correct Content-Encoding value in the HTTP headers, and the HTTP payload itself will be compressed binary. For a given page, the size over the wire should also be significantly smaller, reduced as much as 90%. Using the HTTP Analyzer tool for Internet Explorer, verify that the response has been compressed. Open the Internet Explorer browser and click View > Explorer Bar > IE HTTP Analyzer. You should see that the application is now open within the Internet Explorer browser. Now you can simultaneously use Internet Explorer to send a request to the VIP and examine the HTTP headers. A particular page that has certain remote users upset is a simple page that lists important details for the day. For some reason, this page takes a long time to load when accessed by certain users. Examine the page in the Internet Explorer HTTP Analyzer by accessing it at http://172.16.PC.190/neufoo/big.php. You should see that, although the page is very simple, it is very large. Perhaps the developers made a mistake when they created it. Note the size and the response time in the HTTP Analyzer for an HTTP 200 response.

Now access the same page from the VIP with compression enabled by browsing to http://172.16.PC.191/neufoo/big.php. You should see a big difference in the size of the response from this VIP for the same content. How does the response time compare? Although this page is very large, when accessed across the LAN, it is downloaded in a few hundred milliseconds. Could this be the delay the users were referring to? The simple answer is No. None of the complaints logged by the Neufoo tech support came from users inside the Neufoo corporate office. In fact, all the complaints came from users in locations that are remote, and they claimed a delay on the order of seconds. One thing these users have in common are Internet connections with limited bandwidth—mostly DSL lines shared with their children at home (using bandwidth by playing video games) or high-latency connections (that remote team in India with a 400 ms delay). Simulating the conditions of these users would more readily identify the poor performance reported.

Step 9

Create parameter-maps that define the behavior of some of our other optimizations. You will specify a cache time (for the FlashForward feature) such that the Cisco ACE will check the freshness of any embedded objects in our web pages at least once a minute and set up persistent rebalance as well.
switch/Lab-OPT-PC(config)# parameter-map type optimization http PM-DEF switch/Lab-OPT-PC(config)# parameter-map type optimization http PM-DFF switch/Lab-OPT-PC(config-parammap-optmz)# cache ttl max 60 switch/Lab-OPT-PC(config-parammap-optmz)# cache ttl min 0 switch/Lab-OPT-PC(config)# parameter-map type http PM-REB switch/Lab-OPT-PC(config-parammap-http)# persistence-rebalance

Step 10

Define the optimizations that will be applied in an action list. In this case, you will use delta optimization and FlashForward. Delta optimization will also assist with bandwidth usage, by allowing the client to only download changes to a given dynamic HTML page since the last visit, rather than the entire page. FlashForward helps in cases where latency is an issue, by preventing unnecessary requests (and their responses) from traveling the wide-area network.
switch/Lab-OPT-PC(config)# action-list AL-DEF switch/Lab-OPT-PC(configactlist-optm)# switch/Lab-OPT-PC(configactlist-optm)# switch/Lab-OPT-PC(config)# action-list AL-DFF switch/Lab-OPT-PC(configactlist-optm)# type optimization http delta flashforward type optimization http flashforward-object

Step 11

Construct a class map that will look for embedded objects. You already have a class map that looks for all HTTP contact (CM-DELTA). These URL classes will allow you to choose which HTTP data will have optimizations applied to it.
switch/Lab-OPT-PC(config)# class-map type http loadbalance match-any CM-DFF switch/Lab-OPT-PC(config-cmap-http-lb)# match http url .*gif switch/Lab-OPT-PC(config-cmap-http-lb)# match http url .*jpg

Step 12

Create a policy map that will apply the optimization actions that you will then bundle to a VIP. The optimization policy map simply associates types of actions with parameters that modify their behavior. Note that because this policy is a firstmatch, the order in which the classes of traffic are processed is important. For this
Lab Guide 149

Access http://172.16.PC.191/ to see the optimization features in action (using Internet Explorer HTTP Analyzer) Verify that the optimizations are functioning by using an HTTP or network tracing tool. You should see several changes in the HTML payload delivered through the Cisco ACE. For the FlashForward feature, confirm that you are seeing the filenames of objects (images, and so on) in the web page modified, and the cache values set to expire approximately two years in the future. For delta encoding, confirm that the response through the Cisco ACE is a delta page that consists of a series of JavaScript instructions.

Verify that the VIP is accessible by trying to connect to the VIP from your client PC. Make sure you test both port 80 traffic and port 443. http://172.16.PC.170/index.html https://172.16.PC.170/small.html

Step 17

Use the show service-policy command again and verify that the counters are incrementing.

Create a sticky group. Use the name STICKY-GRP-WEB to clearly identify the sticky group being used.
sticky ip-netmask 255.255.255.255 address source STICKY-GRPWEB timeout 10 serverfarm WEBFARM

Step 2

The sticky group is applied within the policy map of type load balance. Before the sticky group can be applied, the current server farm must be removed.
policy-map type loadbalance first-match STICKY-SLB class class-default no serverfarm WEBFARM sticky-serverfarm STICKY-GRP-WEB

Step 3

Use the following commands to view the sticky tables on the Cisco ACE.
show sticky database type ip-netmask source show sticky database group

Step 4

Verify that the sticky configuration is working for clients connecting to the VIP from your client PC. Make sure you test both port 80 traffic and port 443. http://172.16.PC.170/index.html https://172.16.PC.170/small.html Also try the Serverstress.html page. It has about 50 images.

Step 5

Issue the show commands for the service-policy and the sticky table again and verify that the output is as expected.

The probe works fine, but now bring the probe timers down, so that you can demonstrate a failure detection quickly for the VPs, in case they ask. You also need to lower the passdetect parameters to let the Cisco ACE bring the real server back into rotation more quickly.
probe http HTTP-PROBE interval 5 passdetect interval 2 passdetect count 1

Step 10

Take a look at the traces. Verify that the new timers have taken effect.

Verify that configuration is working for clients connecting to the VIP from your client PC. Make sure you test both port 80 traffic and port 443. http://172.16.PC.170/index.html https://172.16.PC.170/small.html

Step 16

Use the show commands for the service-policy and the sticky table again and verify that the output is still as expected.

Use the show arp command to verify that the Cisco ACE appliance has network connectivity to the real servers. Create a server farm to group the rservers.
serverfarm host APP-FARM rserver LINUX-3 inservice rserver LINUX-4 inservice

Verify that the VIP is active and ready to receive traffic, by using the show servicepolicy command. Verify that the secure VIP is accessible, by trying to connect to the VIP from your client PC.
https://172.16.PC.171/index.html

Step 5

Step 6

Issue the show service-policy command again and verify that the counters are incrementing.

After the key file exists on the Cisco ACE, it can be used to create a certificate signing request. Now you will be asked a series of questions. The answers will be used to fill out the certificate you are creating for the site. Note that any information you put in at this time will be added to the SSL appliance.
switch/Lab-OPT-PC(config)# crypto csr-params APP-CSR switch/Lab-OPT-PC(config-csr-params)# common-name testapp.neufoo.com switch/Lab-OPT-PC(config-csr-params)# country US switch/Lab-OPT-PC(config-csr-params)# email secofficer@neufoo.com switch/Lab-OPT-PC(config-csr-params)# locality SanJose switch/Lab-OPT-PC(config-csr-params)# organization-name CentralIT switch/Lab-OPT-PC(config-csr-params)# organization-unit Demo switch/Lab-OPT-PC(config-csr-params)# state California switch/Lab-OPT-PC(config-csr-params)# serial-number 12345

Still using the Linux session, generate a CA certificate. For a real CA certificate, you would want to fill these out appropriately.

[cisco@linux1 ~]$ openssl req -newkey rsa:1024 -nodes -x509 -keyout /tmp/rootCAkey.pem -out /tmp/rootCAcert.pem -config /usr/share/ssl/openssl.cnf Generating a 1024 bit RSA private key ....++++++ .............++++++ unable to write 'random state' writing new private key to '/tmp/rootCAkey.pem' ----You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----Country Name (2 letter code) [GB]: State or Province Name (full name) [Berkshire]: Locality Name (eg, city) [Newbury]: Organization Name (eg, company) [My Company Ltd]: Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:Email Address []:[ciscocrypto generate csr APP-CSR app-key

Before testing the SSL Acceleration, you will need to force the Cisco ACE appliance to translate the client requests so that requests to port 443 are translated to port 80 after the traffic is decrypted. You need to remove and re-add the existing rservers.
serverfarm APP-FARM no rserver LINUX-3 no rserver LINUX-4 rserver LINUX-3 80 inservice rserver LINUX-4 80 inservice

Step 16

Verify that the secure VIP is accessible, by trying to connect to the VIP from your client PC. https://172.16.PC.171/index.html Issue the show service-policy command again and verify that the counters are incrementing.

To set up probes, reuse the existing HTTP probe. Notice that no HTTPS probe is needed because traffic to the server will be HTTP only.
serverfarm APP-FARM probe HTTP-PROBE

Step 2 Step 3

Use the show probe command to verify that the probes are working as expected. Create a new sticky group. Use the name app-cookie to clearly identify the sticky group being used.
sticky http-cookie ACE-ID app-cookie cookie insert serverfarm APP-FARM

Step 4

The sticky group is applied within the policy map of type load balance for both app maps. Again, before the sticky group can be applied, the current server farm must be removed.
policy-map type loadbalance first-match APP-POLICY class class-default no serverfarm APP-FARM sticky-serverfarm app-cookie policy-map type loadbalance first-match SSL-APP-POLICY class class-default no serverfarm APP-FARM sticky-serverfarm app-cookie

Step 5

Use the show sticky database static command to view the cookie insert sticky tables.

Verify that the sticky configuration is working for clients connecting to the VIP from your client PC. Make sure that you test both port 80 traffic and port 443. http://172.16.PC.171/index.html https://172.16.PC.171/small.html Also try the Serverstress.html page. It has about 50 images.

Create a new user for the security team. Give the new user the password neufoosec and the role of Security-Admin and make the new user a part of the infosec domain (Security-Admin is case sensitive).
username secops password neufoosec role Security-Admin domain infosec

Apply the new access list to the client VLAN to better protect the VIPs and servers. Verify that the ACLs block nonweb traffic. You should no longer be able to Telnet to VIP 190. To see the ACLs denies, use the cisco account and enable logging to monitor the terminal. Use the show domain command to view the objects in the infosec domain. Notice that the web ACL was created within the infosec domain by default.

Task 9: Allow Direct Server Access and SERVER-INITIATED Connections
Direct access to the server can be applied using ACLs or simple class map matches. The user has the option of matching per real server IP or a server network. One important aspect of applying Network Address Translation (NAT) as a subnet is that the NAT pool subnet cannot overlap the VIP, even if the VIP would never be affected by the NAT rule. The Cisco ACE ensures that duplicate IPs cannot exist, so it is required that NAT pool networks do not overlap VIP addresses. In this demonstration, use matches based on host IPs rather than networks; but be aware that networks could be used in this type of design. To allow direct access to the real server, consider that you are the Cisco ACE and think of how flows should be manipulated if they are initiated from the servers. The reasons for this are (1) it will align your thought process with the way the Cisco ACE implements static NAT; and (2) you need to realize that the pinholes created for source NAT are applied bidirectionally; thus, if a server should be source NATed to X, connections from the outside to X will be NATed to the real server.

Activity Procedure
Complete these steps:
Step 1

Configure a class map to match the real server’s initiated connections. Note that the provisioning group used a VMware server for real server 11-14. The primary IP for the physical real server is 192.168.1.10.
class-map match-all SERVER-INITIATED match source-address 192.168.1.11 255.255.255.255

To show that the Cisco ACE is properly NATing client-to-server and server initiated traffic, simply open Ethereal on the client. Capture on the interface 209.165.201.PC. When the sniffer is running, create a Telnet connection to the server’s NATed address. Verify that the server is reachable, and that the IPs in trace are as expected.
telnet 172.16.PC.250

Step 5

Step 6

Now that Telnet works into the real server, use this session to connect back to the client. Verify that your client PC’s IP address is 209.165.201.PC, and make a Telnet connection to the client from the real server. Verify that the client is reachable, and that IPs in trace are as expected. Note that the real server-to-client connection will fail, because the client is not running a Telnet or HTTP server.

Task 10: Configure HTTP Normalization
The Cisco ACE HTTP normalization feature set can provide HTTP security. In this task, you will configure application protection to prevent the following attacks: Specific methods Prevention of buffer overflows Prevention of obfuscated attacks

Activity Procedure
Complete these steps:
Step 1

The security team has identified that the existing Apache web servers allow HTTP TRACE requests (see https://www.kb.cert.org/vuls/id/867593), which could be used by hackers to surreptitiously gain information about the internal Neufoo network from the web servers. InfoSec wants to restrict HTTP requests to the server farm to three acceptable HTTP methods: GET, HEAD, and POST. To implement this restriction, create a whitelist using an HTTP inspection class map WHITE to classify acceptable HTTP traffic.
class-map 3 match 4 match 5 match type http inspect match-any WHITE request-method rfc get request-method rfc head request-method rfc post

Step 2

Create an HTTP inspection policy map and add the class map WHITE to the new policy map with action permit. Make the default action for Cisco ACE to return a reset for any traffic that does not match class WHITE by including class classdefault with the appropriate action.
policy-map type inspect http all-match HTTP-INSP class WHITE permit class class-default reset

Test the whitelist by sending a TRACE request from the client to the VIP. You can use Telnet to send the request, and you should see that that connection is immediately closed.
C:\Documents and Settings\Administrator>telnet <VIP> 80 TRACE / HTTP/1.1<HIT ENTER> Connection to host lost.

InfoSec wants to add basic protections to prevent application level attacks by restricting the length of requested URLs to 45 bytes. This should help to prevent buffer overflows. InfoSec is also concerned that users should never be able to directly request an administrative page called admin.html. Create a blacklist to reject any traffic matching these conditions.
class-map type http inspect match-any BLACK 2 match url .*admin.html 3 match url length range 46 65535

Test that the blacklist rejects requests longer than 45 bytes by sending a request such as the following.
https://<VIP>/index.html?long=1234123412341234123412341234

The Cisco ACE should send you a reset. You can test further by adjusting the length of the URL to see how the Cisco ACE will react to the request.
Step 8

Malicious encodings attacks are a technique used to bypass a server’s security filters, using various types of character encodings (URL, Unicode, and so on). Make sure that the URL admin.html cannot be accessed. Try requesting the URL:
http://<VIP>/admin.html

Note

The Cisco ACE HTTP inspection engine automatically performs URL deobfuscation. Here is a example of an obfuscated URL: http://bock-bock/%7E%63%70%61%67%67%65%6E. Many phishing e-mails frequently use this technique because it can easily hide suspicious portions of a URL and make them appear as if they belong to some legitimate script.

Now try accessing the same URL; however, this time try to bypass the blacklist filter by obscuring the URL. For example, try converting the a in admin.html to its URL encoded equivalent (%61): http://<VIP>/%61dmin.html You can use http://ha.ckers.org/xss as a resource to help you obfuscate URLs. Cisco ACE will first deobfuscate the requested URL before applying any regular expression match to it. Can you access the page now that you have encoded the request?

Lab 11: Troubleshooting Case Study 1: Common SLB Configuration Errors
Complete this lab activity to practice what you learned in the related lesson.

Activity Objective
In this exercise, you will troubleshoot common server load-balancing (SLB) configuration errors. After completing this exercise, you will be able to meet these objectives: Troubleshoot real server containers and server farms Troubleshoot class and policy maps to provide load balancing Verify that the Cisco ACE is load-balancing client traffic

Visual Objective
The figure illustrates what you will accomplish in this activity.

Troubleshooting Case Study 1: Common SLB Configuration Errors
Why Can’t I get to this website?!?
Servers

Required Resources
These are the resources and equipment that are required to complete this activity: Catalyst 6500 with Supervisor 720 Cisco 4710 Application Control Engine Appliance Server minimally running Telnet and HTTP

Use the checkpoint feature to roll back to error-case-1.
switch/Lab-OPT-PC# checkpoint rollback error-case-1 This operation will rollback the system's running configuration to the checkpoint's configuration. Do you wish to proceed? (y/n) [n] y Rollback in progress, please wait... Generating configuration.... Rollback succeeded

Step 4

Use show commands to view the configuration. Problem: Why cannot clients successfully connect to the VIP and receive HTTP responses?

Step 5

Make the corrections and test to ensure that clients can successfully reach the VIP http://172.16.PC.171/.

Activity Verification
You have completed this task when you have successfully load-balanced HTTP requests to the VIP.

Task 2: Troubleshoot the Second Error Case Configuration
In this task, you will review an existing configuration to determine why clients cannot successfully connect to the VIP.

Activity Procedure
Complete these steps:
Step 1

Use the checkpoint feature to roll back to error-case-2.
switch/Lab-OPT-PC# checkpoint rollback error-case-2 This operation will rollback the system's running configuration to the checkpoint's configuration. Do you wish to proceed? (y/n) [n] y Rollback in progress, please wait... Generating configuration.... Rollback succeeded

Step 2

Use show commands to view the configuration. Problem: Why are clients unable to successfully connect to the VIP and receive HTTP responses?

Step 3

Make the corrections and test to ensure that clients can successfully reach the VIP http://172.16.PC.171/.
Try using the show service-policy CLIENT-VIPS detail command.

Tip

Activity Verification
You have completed this task when you have successfully load-balanced HTTP requests to the VIP.

Task 3: Troubleshoot the Third Error Case Configuration
In this task, you will review an existing configuration to determine why clients cannot successfully connect to the VIP.

Activity Procedure
Complete these steps:
Step 1

Use the checkpoint feature to roll back to error-case-3.
switch/Lab-OPT-PC# checkpoint rollback error-case-3 This operation will rollback the system's running configuration to the checkpoint's configuration. Do you wish to proceed? (y/n) [n] y Rollback in progress, please wait... Generating configuration.... Rollback succeeded

Step 2

Use show commands to view the configuration. Problem: Why are clients unable to successfully connect to the VIP and receive HTTP responses?

Step 3

Make the corrections and test to ensure that clients can successfully reach the VIP http://172.16.PC.171/.

Activity Verification
You have completed this task when you have successfully load-balanced HTTP requests to the VIP.

Task 4: Apply the Baseline Configuration
The Cisco ACE ensures that no duplicate IPs exist across contexts per VLAN. Because of the overlapping IPs used in this lab, it is necessary to remove the VLAN interface for the server, so that the VLAN interface can be reused in the remaining labs.

Activity Procedure
Use the checkpoint feature to roll back to baseline-mgmt.
switch/Lab-OPT-PC# checkpoint rollback baseline-mgmt This operation will rollback the system's running configuration to the checkpoint's configuration. Do you wish to proceed? (y/n) [n] y Rollback in progress, please wait... Generating configuration.... Rollback succeeded

Activity Verification
You have completed this task when you have removed the server VLAN from the context.

Activity Objective
In this exercise, you will troubleshoot common Layer 7 server load-balancing (SLB) configuration errors. After completing this exercise, you will be able to meet these objectives: Troubleshoot real server containers and server farms Troubleshoot class and policy maps to provide load balancing Verify that the the Cisco ACE is load-balancing client traffic

Visual Objective
The figure illustrates what you will accomplish in this activity.

Required Resources
These are the resources and equipment that are required to complete this activity: Catalyst 6500 with Supervisor 720 Cisco 4710 Application Control Engine appliance Server minimally running Telnet and HTTP