Acesm20 LG

ACESM
Implementing the
Application Control
Engine Service Module
Version 2.0

Lab Guide

Text Part Number: 67-2531-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.

Table of Contents
Lab Guide 1
Overview 1
Outline 1
Lab Topology 2
Your Client PC Information 2
IP Addressing 2
Connecting to Lab Devices 3
Lab 1: Implementing Virtualization 5
Activity Objective 5
Visual Objective 5
Required Resources 5
Task 1: Review the Current Network Configuration 6
Task 2: Configure New Contexts 10
Task 3: Create Resource Classes 14
Answer Key: Implementing Virtualization 20
Lab 2: Using Network Address Translation 21
Task 1: Configure Static NAT for a Host 22
Task 2: Configure Static NAT for a Subnet 28
Task 3: Apply the Baseline Configuration 30
Answer Key: Using Network Address Translation 31
Lab 3: Configuring Server Load Balancing 33
Visual Objective 33
Task 1: Configure Real Servers 34
Task 2: Configuring Load-Balancing Class Maps and Policy Maps 38
Task 3: Test the New VIP Load-Balancing Configuration 41
Task 4: Configure Dynamic NAT 42
Answer Key: Configuring Server Load-Balancing 46
Lab 4: Implementing Health Monitoring 51
Visual Objective 51
Task 1: Configure Health Monitoring for Real Servers 52
Task 2: Configure Health Monitoring for a Server Farm 59
Task 3: Configure Health Monitoring for a Real Server Within a Server Farm 62
Task 4: Return Code Parsing 67
Task 5: Configuring the Cisco ACE Action on Server Failure 70
Task 6: Configuring Partial Server Farm Failover 72
Lab 5: Configuring Layer 7 Load Balancing 83
Visual Objective 83
Task 1: Configure a Real Server 84
Task 2: Configure Layer 7 Load Balancing 86
Task 3: Test the New VIP Load-Balancing Configuration 89
Task 4: Mixing Layer 4 and Layer 7 Traffic 90
Task 5: Optimize the Mixed-Traffic VIP 95
Task 6: Generic Layer 4 Content Parsing 97
Task 7: Layer 4 Payload Stickiness 102
Answer Key: Configuring Layer 7 Load Balancing 107
ii Implementing the Application Control Engine Service Module (ACESM) v2.0 2007 Cisco Systems, Inc.
Lab 6: Enabling Sticky Connections 121
Visual Objective 121
Task 1: Create a Server Farm 122
Task 2: Apply Source IP Sticky to Ensure Client Persistence 123
Answer Key: Enabling Sticky Connections 125
Lab 7: Enabling Protocol Inspection 127
Task 1: Configure a Protocol Fixup 128
Task 2: Configure FTP 130
Answer Key: Enabling Protocol Inspection 135
Lab 8: Configuring SSL Termination 140
Task 1: Configure SSL Termination When You Have Certificates and Keys 141
Task 2: Configure SSL Termination When You Must Create Certificates and Keys 147
Task 3: SSL Session ID Reuse 155
Task 4: Configure SSL Queue Delay 160
Answer Key: Configuring SSL Termination 162
Lab 9: Integrating Multiple Features 169
Task 1: Create a Virtual IP Address to Accept Web Traffic 171
Task 2: Apply Source IP Sticky to Ensure Client Persistence 174
Task 3: Apply Probes to Ensure That Real Servers Are Working Properly 176
Task 4: Create a Virtual IP Address to Accept Clear Application Traffic 180
Task 5: Create a Virtual IP Address to Accept Secure Application Traffic 183
Task 6: Add SSL Acceleration 184
Task 7: Apply Probe and Cookie Insert Sticky to Ensure Client Persistence 190
Task 8: Create a Domain for the Security Team 193
Task 9: Allow Direct Server Access and Server-Initiated Connections 196
Task 10: Configure HTTP Normalization 199
Lab 10: Troubleshooting Case Study 1: Common SLB Configuration Errors 205
Task 1: Troubleshoot the First Error Case Configuration 206
Task 2: Troubleshoot the Second Error Case Configuration 206
Task 3: Troubleshoot the Third Error Case Configuration 207
Lab 11: Troubleshooting Case Study 2: Common Layer 7 SLB Configuration Errors 209
Task 1: Troubleshoot the First Error Case Configuration 210

ACESM
Lab Guide
Overview
This guide presents the instructions and other information concerning the lab activities for this
course. You can find the solutions in the lab activity Answer Key.
Outline
This guide includes these activities:
Lab 1: Implementing Virtualization
Lab 2: Using Network Address Translation
Lab 3: Configuring Server Load Balancing
Lab 4: Implementing Health Monitoring
Lab 5: Configuring Layer 7 Load Balancing
Lab 6: Enabling Sticky Connections
Lab 7: Enabling Protocol Inspection
Lab 8: Configuring SSL Termination
Lab 9: Integrating Multiple Features
Lab 10: Troubleshooting Case Study 1Common SLB Configuration Errors
Lab 11: Troubleshooting Case Study 2Common Layer 7 SLB Configuration Errors

2 Implementing the Application Control Engine Service Module (ACESM) v2.0 2007 Cisco Systems, Inc.
Lab Topology
The figure shows the lab topology.
2007 Cisco Systems, Inc. All rights reserved. ACESM v2.02
Lab Topology
192.168.1.10
192.168.1.11
192.168.1.12
192.168.1.13
192.168.1.14
192.168.1.15
Cisco ACE Admin
172.19.110.P9
1
0
.1
0
.1
0
.1
192.168.1.1
172.16.PC.L
172.16.PC.1
209.165.201.PC
1
0
.1
0
.1
0
.P
C
1
7
2
.
1
9
.
1
1
0
.
1
209.165.201.1
Catalyst 6500
Cisco
ACE
MSFC
1
7
2
.
1
9
.
1
1
0
.
P
C
VLAN 10
VLAN 2PC
V
L
A
N
3
P
C
V
L
A
N

4
P
C
P = Pod number
C = Client number
L = Lab exercise number + 10

Your Client PC Information
You will be assigned a pod and a client by your instructor. Below please write down your
username, password, pod number, and client number 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
Note In the current virtualized implementation used in this lab, all pods are internally numbered
pod 1. Therefore, P = 1 throughout this lab guide.
2007 Cisco Systems, Inc. Lab Guide 3
Pod 1 Addressing
Device Client LAN IP Client WAN IP
Cisco ACE
Client VLAN
Cisco ACE
Default
Gateway
Client
VLAN
Server
VLAN
Cisco ACE
Server
VLAN
Pod1-Sup720 172.19.110.1 209.165.201.1
Pod1-Client1 172.19.110.11 209.165.201.11 172.16.11.0/24 172.16.11.1/24 211 411 192.168.1.1/24
Pod1-Client2 172.19.110.12 209.165.201.12 172.16.12.0/24 172.16.12.1/24 212 412 192.168.1.1/24
Pod1-Client3 172.19.110.13 209.165.201.13 172.16.13.0/24 172.16.13.1/24 213 413 192.168.1.1/24
Pod1-Client4 172.19.110.14 209.165.201.14 172.16.14.0/24 172.16.14.1/24 214 414 192.168.1.1/24
Pod1-Client5 172.19.110.15 209.165.201.15 172.16.15.0/24 172.16.15.1/24 215 415 192.168.1.1/24
Pod1-Client6 172.19.110.16 209.165.201.16 172.16.16.0/24 172.16.16.1/24 216 416 192.168.1.1/24
Pod1-Client7 172.19.110.17 209.165.201.17 172.16.17.0/24 172.16.17.1/24 217 417 192.168.1.1/24
Pod1-Client8 172.19.110.18 209.165.201.18 172.16.18.0/24 172.16.18.1/24 218 418 192.168.1.1/24
Pod1-ACE 172.19.110.19
Connecting to Lab Devices
Connecting to Your Client PC
After you have been assigned a pod username and password by your instructor, point your IE
browser at http://www.labgear.net 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 in to the PC, use the username administrator and password
cisco.
Accessing the Remote Labs
Must use Internet Explorer 6 or later.
Browse to www.labgear.net.
Log in using username and password
supplied by your lab proctor.

2007 Cisco Systems, Inc. All rights reserved. Course acronym vx.x#-4
Accessing Devices
Use Device Manager to:
Control power
Clear console
Use Device Manager to:
Control power
Clear console

The web servers are running Red Hat Advanced Server Enterprise 4. You will configure
network connectivity to these servers during the lab exercises. In some activities, you will
establish a Telnet session into the server and log in with the username cisco and password
cisco. To gain root access, use the command su - and the password cisco123.
Connecting to the Cisco ACE Module
The Cisco ACE Application Control Engine Modules can be accessed using Telnet or SSH.
There are a maximum of four Telnet and four SSH sessions, which can simultaneously log in to
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 in to the Admin context.
You can access the Admin context using Telnet, SSH, or by using the session slot 1 processor
0 command from the Cisco Catalyst 6500 Series Supervisor Engine.
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 Catalyst 6500 and the Cisco
ACE Admin context. You will create new contexts and resource classes to understand the
flexibility of virtualization on the Cisco ACE Module. After completing this exercise, you will
be able to meet these objectives:
Review the existing Cisco ACE configuration
Define Cisco ACE contexts
Create Cisco ACE resource classes
Visual Objective
The figure illustrates what you will accomplish in this activity.
2007 Cisco Systems, Inc. All rights reserved. Course acronym vx.x#-5
Implementing Virtualization

Required Resources
These are the resources and equipment required to complete this activity:
Cisco Catalyst 6500 Series Supervisor Engine 720
Cisco ACE Module
Server minimally running Telnet and HTTP
Task 1: Review the Current Network Configuration
In this task, you will connect to the Catalyst 6500 Series Supervisor Engine 720 and establish a
session to the Admin context on the Cisco ACE Module. You will then review the existing
ACE configuration. This lab simulates configuring a new Cisco ACE Module just after system
boot and initial administrative configuration. Before you configure the Cisco ACE Module to
connect with the client-facing network and servers, you must understand how the Catalyst 6500
Series Supervisor Engine 720 is configured to allow these VLANs to be connected to the Cisco
ACE Module. By default, no VLANs are sent to the Cisco ACE Module; this is unlike the
Content Switching Module (CSM), which receives all VLAN traffic.
Note Use the terminal monitor command after you connect to any device to make sure that all
console messages are seen. This command offers an invaluable source of information when
initially configuring the service modules.
Activity Procedure
Complete these steps:
Step 1 Connect to your Client PC.
Step 2 Telnet to 172.19.110.P from your Client PC to access the Catalyst 6500 Series
Supervisor Engine 720 in the Catalyst 6500 within your pod. Log in with the
username cisco and the password cisco.
C:\> telnet 172.19.110.P
Trying 172.19.110.P...
Connected to 172.19.110.P (172.19.110.P).
Escape character is '^]'.

User Access Verification

Password: cisco
Step 3 Display the chassis modules to determine the slot of the Cisco ACE Module.
PodP-6k# show module
Mod Ports Card Type Model
Serial No.
--- ----- -------------------------------------- -------------
----- -----------
1 1 Application Control Engine Module ACE10-6500-K9
SAD103206UR
2 48 48 port 10/100 mb RJ45 WS-X6348-RJ-
45 SAL06313L4X
5 2 Supervisor Engine 720 (Active) WS-SUP720-
3BXL SAL10360EMM

Mod MAC addresses Hw Fw Sw
Status
--- ---------------------------------- ------ ------------ ---
--------- -------
1 0019.0627.b91a to 0019.0627.b921 1.1 8.7(0.5-Eng)
A2(0) Ok
2 000a.8a99.31a8 to 000a.8a99.31d7 6.1 5.4(2)
8.5(0.46)RFW Ok
5 0017.5a34.bc9c to 0017.5a34.bc9f 5.2 8.4(2)
12.2(18)SXF4 Ok

Mod Sub-Module Model Serial
Hw Status
---- --------------------------- ------------------ ----------
- ------- -------
2 Inline Power Module WS-F6K-PWR
1.0 Ok
5 Policy Feature Card 3 WS-F6K-PFC3BXL
SAL10360CHJ 1.8 Ok
5 MSFC3 Daughterboard WS-SUP720
SAL10360EV5 2.5 Ok

Mod Online Diag Status
---- -------------------
1 Pass
2 Pass
5 Pass
Step 4 Observe that, unlike the Firewall Services Module (FWSM) and the CSM, the Cisco
ACE Module does not use a multi-Gigabit EtherChannel to connect to the
backplane, but a single 10-gigabit interface.
Try some of the show commands: (The following will work if the Cisco ACE
Module is in slot 1.)
PodP-6k# show asic-version slot 1
Module in slot 1 has 2 type(s) of ASICs
ASIC Name Count Version
HYPERION 1 (5.0)
SSA 1 (8.0)
Note The Hyperion is the Cisco ACE interconnect to the Catalyst 6500 Switch Fabric.
PodP-6k# show interface TenGigabitEthernet 1/1 status

Port Name Status Vlan Duplex
Speed Type
Te1/1 connected trunk full
10G MultiService Module
Note The status keyword must abbreviated as statu or spelled out. Abbreviating the keyword as
stat issues the show interface TenGigabitEthernet 1/1 stats command, which will give
you blank output.
PodP-6k# show interface TenGigabitEthernet 1/1 counters

Port InOctets InUcastPkts InMcastPkts
InBcastPkts
Te1/1 745174 4799 5394
317

Port OutOctets OutUcastPkts OutMcastPkts
OutBcastPkts
Te1/1 248640 0 0
3885
Step 5 The Cisco ACE Module will not accept VLAN traffic unless the Catalyst 6500
Series Supervisor Engine 720 is specifically configured to allow VLANs to access
the Cisco ACE Module. This is similar to how the FWSM and Web VPN modules
work. By not allowing all VLANs to access the Cisco ACE Module, broadcast
storms on non-ACE VLANs have no effect on the Cisco ACE Module. This is an
improvement over the CSM, which has backplane connectivity to all VLANs within
the Catalyst 6500. To allow VLANs to access the Cisco ACE Module, use the svclc
command to create a VLAN group and apply it to the module.
PodP-6k# conf t
Enter configuration commands, one per line. End with CNTL/Z.
PodP-6k(config)# svclc ?
autostate Enable autostate for all svclc
modules
module Module number which a vlan-group
will be tied to
multiple-vlan-interfaces Enable multiple vlan interfaces
mode for svclc
modules
vlan-group Secure group which VLANs will be
tied to

PodP-6k(config)# exit
PodP-6k# show run | inc svc
svclc multiple-vlan-interfaces
svclc module 1 vlan-group 1,2
svclc vlan-group 1 31,110,2P1-2P8
svclc vlan-group 2 30,4P1-4P8
Note SVCLC VLAN groups can be applied to the FWSM using the firewall module command.
Likewise, firewall VLAN groups can be applied to the Cisco ACE Module using the svclc
command.

The svclc multiple-vlan-interfaces command is required when connecting more than one
VLAN with a Layer 3 MSFC interface to the Cisco ACE Module.

The number of VLANs you see displayed might vary for the example in this guide. In this
lab, you will only be concerned with 2PC and 4PC VLANs.
Step 6 Use the show svclc command to verify that the proper VLAN group has been
created and applied.
PodP-6k# show svclc ?
autostate Show ACE module vlan interfaces
autostate feature
hsrp-tracking show hsrp tracking entries
module Show secure VLANs tied to a module
multiple-vlan-interfaces Show state of multiple svclc vlan
interfaces
feature
rhi-routes show RHI Routes
vlan-group Show secure VLANs tied to a secure
group

PodP-6k# show svclc vlan-group
Display vlan-groups created by both ACE module and FWSM
commands

Group Created by vlans
----- ---------- -----
1 ACE 31,110,2P1-2P8
2 ACE 30,4P1-4P8

PodP-6k# show svclc module
Module Vlan-groups
------ -----------
01 1,2
Step 7 Verify your configuration with the show interfaces command. Make sure that both
VLAN 2PC and 4PC are allowed on the trunk and are allowed and active in
management domain.
PodP-6k# show interfaces TenGigabitEthernet 1/1 trunk

Port Mode Encapsulation Status Native
vlan
Te1/1 on 802.1q trunking 1

Port Vlans allowed on trunk
Te1/1 30-31,110,2P1-2P8,4P1-4P8

Port Vlans allowed and active in management domain
Te1/1 110,2P1-2P8,4P1-4P8

Port Vlans in spanning tree forwarding state and not
pruned
Te1/1 110,2P1-2P8,4P1-4P8
Activity Verification
You have completed this task when you understand how the Cisco ACE Module is physically
and logically connected to the Catalyst 6500:

Task 2: Configure New Contexts
In this task, you will define ACE contexts.
Activity Procedure
Step 1 Continuing from the Task 1 Telnet session, connect to the Cisco ACE Modules
Admin context. (This can be done by using a session from the Catalyst 6500 Series
Supervisor Engine 720 or by using Telnet or SSH from the Client PC in the pod.)
The following step uses the session command from the Catalyst 6500 Series
Supervisor Engine 720 to gain access to the Cisco ACE Module.
PodP-6k# session slot 1 processor 0
The default escape character is Ctrl-^, then x.
You can also type 'exit' at the remote prompt to end the
session
Trying 127.0.0.10 ... Open

PodP-ACE login: admin
Password: admin
Cisco Application Control Software (ACSW)
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2006, 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.
PodP-ACE/Admin#
Note Sessioning into a service module opens an internal connection over the loopback address of
the service module. This number is slot dependant, and the slot number is multiplied by 10.
For example, if the Cisco ACE Module were in slot 5, the session to slot 5 processor 0 would
open a connection to 127.0.0.50. Sessioning into Cisco ACE cannot be connected to while
the Cisco ACE Module is booting.
Reference Processor 0: Admin context used for administration after the module has successfully
booted.

Processor 1: Debug access to NP0. This should only be used with TAC or Engineering
guidance. Issuing commands in this session can make the NP unstable. Usage of this
access should be used with extreme caution in a production environment.

Processor 2: Debug access to NP1. This should only be used with TAC or Engineering
guidance. Issuing commands in this session can make the NP unstable. Usage of this
access should be used with extreme caution in a production environment.

No other processor interfaces are defined at this time.
Step 2 View system information and note the version of the code currently running on the
Cisco ACE Module.
PodP-ACE/Admin# sh version
reserved.
license.

Software
loader: Version 12.2[118]
system: Version A2(0) [build 3.0(0)A2(0.120)
adbuild_03:29:00-2007/05/17_/a
uto/itasca4/build/nightly/REL_3_0_0_A2_0_120]
system image file: [LCP] disk0:c6ace-t1k9-
mz.3.0.0_A2_0.120.bin
installed license: ACE-08G-LIC ACE-VIRT-250 ACE-SSL-20K-K9

Hardware
Cisco ACE (slot: 1)
cpu info:
number of cpu(s): 2
cpu type: SiByte
cpu: 0, model: SiByte SB1 V0.2, speed: 700 MHz
cpu: 1, model: SiByte SB1 V0.2, speed: 700 MHz
memory info:
total: 956648 kB, free: 312260 kB
shared: 0 kB, buffers: 2504 kB, cached 0 kB
cf info:
filesystem: /dev/cf
total: 1000000 kB, used: 389952 kB, available: 610048 kB

last boot reason: reload command by admin
configuration register: 0x1
PodP-ACE kernel uptime is 0 days 3 hours 59 minute(s) 5
second(s)
Step 3 The Cisco ACE Module 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.
PodP-ACE/Admin# terminal session-timeout 0
Step 4 The Cisco ACE Module also allows you to set future session idle timeout settings.
For this lab, disable future sessions from timing out.
PodP-ACE/Admin# config
PodP-ACE/Admin(config)# login timeout 0
Note The line vty command is different from Cisco IOS in that it does not control remote session
idle timeouts using the exec-timeout command.
Step 5 Issue the show run command from enable mode to see the current Cisco ACE
configuration. The Admin context is where you configure Layer 3 access (VLANs,
ACL static routes etc) to access the Admin context through SSH or Telnet. In the
running configuration, you can also view all of the contexts that are configuration
and the VLANs that are associated with them. You can also configure the Cisco
ACE features (load balancing, ssl-proxy, etc.) using the Admin context, but this is
not recommended.
Note By default, the admin and www users are present. They exist in the Admin context and
provide default access. The admin account is for administration. The www account is for
supporting the XML interface. Do not delete this user. If the www user is removed, the XML
interface will be disabled for the entire module.
Step 6 Use the context command to create a new context.
PodP-ACE/Admin# conf t
PodP-ACE/Admin(config)# context Lab-Virt-PC
Note Remember that P refers to your pod number and C refers to your client number. These
numbers were assigned to you at the beginning of the first part of the lab.

Note You can connect to a context in two ways: by using the changeto context_name command,
or by associating a VLAN and an IP address with the context and establishing a Telnet
session to that address (after you have allowed administrative traffic).
PodP-ACE/Admin(config-context)# ?
Submode commands:
allocate-interface Assign a vlan to a context
description Description for the context
do EXEC command
end Exit from configure mode
exit Exit from this submode
member Resource-class membership
no Negate a command or set its defaults
Step 7 Display the VLANs allocated to the entire Cisco ACE Module from the Catalyst
6500 Series Supervisor Engine 720.
PodP-ACE/Admin(config-context)# do show vlans
Vlans configured on SUP for this module
vlan110 vlan2P1-2P8 vlan4P1-4P8
Step 8 Allocate your client VLAN to the new context.
PodP-ACE/Admin(config-context)# allocate-interface vlan 2PC
Step 9 To better understand the VLAN allocations, attempt to add two more VLANs to this
context.
PodP-ACE/Admin(config-context)# allocate-interface vlan 11,12
PodP-ACE/Admin(config-context)# do show run context | beg
Virt-PC
Generating configuration....
context Lab-Virt-PC
allocate-interface vlan 11
allocate-interface vlan 2PC
Note The allocate-interface command does not accept comma separated VLANs.
Step 10 Attempt to add a range of VLANs.
PodP-ACE/Admin(config-context)# allocate-interface vlan 20-29
PodP-ACE/Admin(config-context)# do sho run context | beg Virt-
PC
context Lab-Virt-PC
allocate-interface vlan 11
allocate-interface vlan 20-29
Step 11 Remove VLANs 11 and 25. Observer the modified VLAN allocation. Next, remove
the remaining VLANs 20-24 and 26-29.
PodP-ACE/Admin(config-context)# no allocate-interface vlan 11
PodP-ACE/Admin(config-context)# no allocate-interface vlan 25
PodP-ACE/Admin(config-context)# do sho run context | beg Virt-
PC
context Lab-Virt-PC

PodP-ACE/Admin(config-context)# no allocate-interface vlan 20-
24
PodP-ACE/Admin(config-context)# no allocate-interface vlan 26-
29
Step 12 View the newly created context.
PodP-ACE/Admin(config-context)# do sho context Lab-Virt-PC
Name: Lab-Virt-PC , Id: 106
Config count: 0
Description:
Resource-class: default
Vlans: Vlan2PC
Step 13 Create another context to be used in the next task.
PodP-ACE/Admin(config-context)# context Lab-Virt2-PC

You have completed this task when you understand how to create a new context and how to
assign VLANs to a context.
Task 3: Create Resource Classes
In this task, you will learn how to create Cisco ACE resource classes and then assign those
resource classes to a context.
Activity Procedure
Step 1 View the current resource allocation.
PodP-ACE/Admin(config-context)# do show resource ?
allocation Show resource allocation information.
usage Show resource usage information

PodP-ACE/Admin(config-context)# do show resource allocation
--------------------------------------------------------------
-------------
Parameter Min Max Class
--------------------------------------------------------------
-------------

acl-memory 0.00% 10100.00% default
0.00% 800.00% cart
0.00% 100.00% avs

syslog buffer 0.00% 10100.00% default
0.00% 800.00% cart
0.00% 100.00% avs

conc-connections 0.00% 10100.00% default
0.00% 800.00% cart
0.00% 100.00% avs

mgmt-connections 0.00% 10100.00% default
0.00% 800.00% cart
0.00% 100.00% avs

proxy-connections 0.00% 10100.00% default
0.00% 800.00% cart
0.00% 100.00% avs

bandwidth 0.00% 10100.00% default
0.00% 800.00% cart
0.00% 100.00% avs

connection rate 0.00% 10100.00% default
0.00% 800.00% cart
0.00% 100.00% avs

inspect-conn rate 0.00% 10100.00% default
0.00% 800.00% cart
0.00% 100.00% avs

syslog rate 0.00% 10100.00% default
0.00% 800.00% cart
0.00% 100.00% avs

regexp 0.00% 10100.00% default
0.00% 800.00% cart
0.00% 100.00% avs

sticky 0.00% 10100.00% default
8.00% 8.00% cart
10.00% 10.00% avs

xlates 0.00% 10100.00% default
0.00% 800.00% cart
0.00% 100.00% avs

ssl-connections rate 0.00% 10100.00% default
0.00% 800.00% cart
0.00% 100.00% avs

mgmt-traffic rate 0.00% 10100.00% default
0.00% 800.00% cart
0.00% 100.00% avs

mac-miss rate 0.00% 10100.00% default
0.00% 800.00% cart
0.00% 100.00% avs

PodP-ACE/Admin(config-context)# do sho resource usage
Allocation
Resource Current Peak Min Max Denied
-----------------------------------------------------------------------------
Context: Admin
conc-connections 0 0 0 8000000 0
mgmt-connections 2 16 0 5000 0
proxy-connections 0 0 0 1048574 0
xlates 0 0 0 1048574 0
bandwidth 0 0 0 500000000 0
connection rate 0 0 0 1000000 0
ssl-connections rate 0 0 0 1000 0
mgmt-traffic rate 0 0 0 125000000 0
mac-miss rate 0 0 0 2000 0
inspect-conn rate 0 0 0 3000 0
acl-memory 2736 8136 0 78610432 0
regexp 335 398 0 1048576 0
syslog buffer 10000 0 0 4194304 0
syslog rate 10000 0 0 3000 0
Context: Lab-SLB-PC
xlates 0 0 0 1048574 0
bandwidth 0 0 0 500000000 0
acl-memory 2712 5328 0 78610432 0
regexp 0 0 0 1048576 0
syslog buffer 10000 0 0 4194304 0
syslog rate 10000 0 0 3000 0
Context: Lab-HM-PC
Step 2 Create a new resource class named HARD-SET-PC.
PodP-ACE/Admin(config)# resource-class HARD-SET-PC
Step 3 Allocate all resources to this resource-class using the keyword all and limit it to 1%
of the Cisco ACE resources.
PodP-ACE/Admin(config-resource)# ?
Submode commands:
do EXerror-case- command
exit Exit from this submode
limit-resource Set resource limits
no Negate a command or set its defaults

PodP-ACE/Admin(config-resource)# limit-resource ?
acl-memory Limit ACL memory
all Limit all resource parameters
buffer Set resource-limit for buffers
conc-connections Limit concurrent connections (thru-the-box traffic)
mgmt-connections Limit management connections (to-the-box traffic)
proxy-connections Limit proxy connections
rate Set resource-limit as a rate (number per second)
regexp Limit amout of regular expression memory
sticky Limit number of sticky entries
xlates Limit number of Xlate entries

PodP-ACE/Admin(config-resource)# limit-resource all minimum 1 maximum ?
equal-to-min Set maximum limit to same as minimum limit
unlimited Set maximum limit to unlimited

PodP-ACE/Admin(config-resource)# limit-resource all minimum 1 maximum equal-
to-min
Step 4 View the net resource class allocations.
---------------------------------------------------------------------------
---------------------------------------------------------------------------

0.00% 800.00% cart
0.00% 100.00% avs

0.00% 800.00% cart
0.00% 100.00% avs

0.00% 800.00% cart
0.00% 100.00% avs
0.00% 800.00% cart
0.00% 100.00% avs

0.00% 800.00% cart
0.00% 100.00% avs

0.00% 800.00% cart
0.00% 100.00% avs

0.00% 800.00% cart
0.00% 100.00% avs

0.00% 800.00% cart
0.00% 100.00% avs

bandwidth 0.00% 10100.00% default
0.00% 800.00% cart
0.00% 100.00% avs
Why are the resource allocations not displayed, although the resource class has been created?
Step 5 Apply the new resources class to the context Lab-Virt-PC.
PodP-ACE/Admin(config)# context Lab-Virt-PC
PodP-ACE/Admin (config-context)# member <TAB>
avs cart default HARD-SET-PC
PodP-ACE/Admin (config-context)# member HARD-SET-PC

View the changes to the resource allocation table.
---------------------------------------------------------------------------
---------------------------------------------------------------------------

0.00% 800.00% cart
0.00% 100.00% avs
1.00% 1.00% HARD-SET-PC

0.00% 800.00% cart
0.00% 100.00% avs
1.00% 1.00% HARD-SET-PC

0.00% 800.00% cart
0.00% 100.00% avs
1.00% 1.00% HARD-SET-PC

0.00% 800.00% cart
0.00% 100.00% avs
1.00% 1.00% HARD-SET-PC

0.00% 800.00% cart
0.00% 100.00% avs
1.00% 1.00% HARD-SET-PC
Is your resource class displayed? What percentage of the resources are assigned to your
resource class?
Step 6 Create a new resource-class named MIN+GROWTH-PC. Guarantee the resource
class 2% of the ACE resources and allow any unused ACE resources to be accessed
by contexts which are a member of this resource class.
PodP-ACE/Admin(config)# resource-class MIN+GROWTH-PC
PodP-ACE/Admin(config-resource)# limit-resource all minimum 2 maximum
unlimited

PodP-ACE/Admin(config)# context Lab-Virt2-PC
PodP-ACE/Admin(config-context)# member MIN+GROWTH-PC

Show the resource class information with your changes.
PodP-ACE/Admin(config-context)# do sho resource allocation
---------------------------------------------------------------------------
---------------------------------------------------------------------------

0.00% 800.00% cart
0.00% 100.00% avs
1.00% 1.00% HARD-SET-PC
2.00% 100.00% MIN+GROWTH-PC

0.00% 800.00% cart
0.00% 100.00% avs
1.00% 1.00% HARD-SET-PC

0.00% 800.00% cart
0.00% 100.00% avs
1.00% 1.00% HARD-SET-PC

0.00% 800.00% cart
0.00% 100.00% avs
1.00% 1.00% HARD-SET-PC
Step 7 Notice the resource usage difference between a context that is allocated only X%
resources (Lab-Virt-PC) compared to a context guaranteed Y% and allowed to burst
beyond this minimum allocation (Lab-Virt2-PC).
PodP-ACE/Admin(config-context)# do sho resource usage context Lab-Virt-PC
Allocation
-----------------------------------------------------------------------------
Context: Lab-Virt-PC
xlates 0 0 10486 0 0
bandwidth 0 0 5000000 0 0
acl-memory 0 0 786104 0 0
regexp 0 0 10486 0 0
syslog buffer 200 0 41943 0 0
syslog rate 200 0 30 0 0

PodP-ACE/Admin(config-context)# do sho resource usage context Lab-Virt2-PC
Allocation
-----------------------------------------------------------------------------
Context: Lab-Virt2-PC
xlates 0 0 20972 1017116 0
bandwidth 0 0 10000000 485000000 0
acl-memory 0 0 1572209 78610432 0
regexp 0 0 20972 1048576 0
syslog buffer 10200 0 83886 4194304 0
syslog rate 10200 0 60 3000 0
Step 8 Try to allocate more minimum resources than the Cisco ACE Module can support.
Create a temporary context for this test.
PodP-ACE/Admin(config-context)# exit
PodP-ACE/Admin(config)# resource-class MAX-PC
PodP-ACE/Admin(config-resource)# limit-resource all min 99 maximum equal-to-
min

PodP-ACE/Admin(config)# context MAX-PC
PodP-ACE/Admin(config-context)# member MAX-PC
Error: resources in use
Step 9 Try to increase an existing limit to allow more minimum resources than the Cisco
ACE Module can support.
PodP-ACE/Admin(config)# resource HARD-SET-PC
PodP-ACE/Admin(config-resource)# limit-resource all min 99 maximum equal-to-
min
Error: checking resource parameter limit failed

PodP-ACE/Admin(config-resource)# limit-resource sticky min 99 maximum equal-
to-min
Error: checking resource parameter limit failed
Step 10 What conclusions can be drawn regarding the Cisco ACE oversubscription rules
when allocating resources?
You have completed this task when you have developed an understanding of the multiple ways
that resources can be allocated to a context.
Answer Key: Implementing Virtualization
When you complete this exercise, the Cisco ACE Module running configuration file will be
similar to the following, with differences that are specific to your device or workgroup.
PodP-ACE/Admin(config-resource)# do sho run

resource-class HARD-SET-PC
limit-resource all minimum 1.00 maximum equal-to-min
resource-class MIN+GROWTH-PC
limit-resource all minimum 2.00 maximum unlimited
resource-class MAX-PC
limit-resource all minimum 99.00 maximum equal-to-min

context Lab-Virt-PC
member HARD-SET-PC
context Lab-Virt2-PC
member MIN+GROWTH-PC
context MAX-PC
Lab 2: Using Network Address Translation
Activity Objective
In this activity, you will configure your ACE context to perform a variety of network address
translations.
The steps required to configure NAT on Cisco ACE are significantly very different from Cisco
firewalls. NAT on Cisco ACE entirely relies on the 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:
Cisco Catalyst 6500 with Supervisor Engine 720
Cisco ACE Module
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
Static Destination NAT
Client
209.165.201.PC
Cisco ACE
VLAN 2PC
172.16.PC.12
Cisco ACE
VLAN 4PC
192.168.1.1
Server
192.168.1.10
192.168.1.10 172.16.PC.222
Outside Local Outside Global

Activity Procedure
Step 2 Connect directly to the Cisco ACE management IP address for your Lab 7 context.
C:\> telnet 172.16.PC.12
Trying 172.16.PC.12...
Connected to 172.16.PC.12 (172.16.PC.12).


Username: cisco
Password: cisco123
Step 3 Verify that you are in the correct context by looking at the prompt.
PodP-ACE/Lab-NAT-PC #
Step 4 Use the checkpoint system to roll back the configuration:
PodP-ACE/Lab-NAT-PC# checkpoint rollback static-nat-begin
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 Execute show run to see what is preconfigured for this lab.
Step 6 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.
PodP-ACE/Lab-NAT-PC# terminal session-timeout 0
Note In configuration mode, login timeout can be use to modify the idle timeout of future
sessions.
Step 7 Create the INBOUND access list to permit traffic from the client to the servers
NAT-translated address.
PodP-ACE/Lab-NAT-PC(config)# access-list INBOUND extended
permit tcp host 209.165.201.PC host 172.16.PC.222
Step 8 Define a class map that matches the source IP you want to translate.
PodP-ACE/Lab-NAT-PC(config)# class-map LNX-SOURCED
PodP-ACE/Lab-NAT-PC(config-cmap)# match source-address
192.168.1.10 255.255.255.255
PodP-ACE/Lab-NAT-PC(config-cmap)# exit
Step 9 Create a multimatch policy map that specifies NAT as the action. Provide the static
IP that will be used for the server, and define which VLAN the server traffic will use
after it has been NAT-translated.
PodP-ACE/Lab-NAT-PC(config)# policy-map multi-match SVR-NAT
PodP-ACE/Lab-NAT-PC(config-pmap)# class LNX-SOURCED
PodP-ACE/Lab-NAT-PC(config-pmap-c)# nat ?
dynamic Configure dynamic network address translation
static Configure static network address translation

PodP-ACE/Lab-NAT-PC(config-pmap-c)# nat static 172.16.PC.222
netmask 255.255.255.255 vlan2PC
Step 10 Apply the multimatch policy and ACL to the server-side (inside) interface.
PodP-ACE/Lab-NAT-PC(config)# interface vlan 4PC
PodP-ACE/Lab-NAT-PC(config-if)# service-policy input SVR-NAT
Step 11 Use the show nat-fabric command to obtain detailed NAT runtime information:
PodP-ACE/Lab-NAT-PC# sh nat-fabric policies

Nat objects:

NAT object ID:2 mapped_if:11 policy_id:1 type:STATIC
static_xlate_id:2
ID:2 Static address translation
Real addr:192.168.1.10 Real port:0 Real
interface:12
Mapped addr:172.16.PC.222 Mapped port:0 Mapped
interface:11
Netmask:255.255.255.255
Step 12 Check the traffic statistics of the access list.
PodP-ACE/Lab-NAT-PC# show access-list INBOUND
access-list:INBOUND, elements: 1, status: NOT-ACTIVE
remark :
access-list INBOUND line 10 extended permit tcp host
209.165.201.PC host 172.16.PC.222
Step 13 Why is the access list inactive? Was it applied to an interface?
PodP-ACE/Lab-NAT-PC# conf
PodP-ACE/Lab-NAT-PC(config-if)# int vlan 2PC
PodP-ACE/Lab-NAT-PC(config-if)# access-group input INBOUND
PodP-ACE/Lab-NAT-PC(config-if)# exit
PodP-ACE/Lab-NAT-PC(config)# exit
access-list:INBOUND, elements: 1, status: ACTIVE
remark :
209.165.201.PC host 172.16.PC.222 (hitcount=0)
Note 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 most likely 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 Module.
PodP-ACE/Lab-NAT-PC# sh xlate
NAT from vlan4PC:192.168.1.10 to vlan2PC:172.16.PC.222 count:1
Step 15 To see the NAT work, establish a Telnet connection from the context to the Linux
server. Switch to the user root and start tethereal.
PodP-ACE/Lab-NAT-PC# telnet 192.168.1.10
Trying 192.168.1.10...
Connected to 192.168.1.10.

linux1 (Linux release 2.6.9-11.ELsmp #1 SMP Fri May 20
18:26:27 EDT 2005) (0
)

login: cisco
Password for cisco: cisco
login: Resource temporarily unavailable while getting initial
credentials
Last login: Tue Jun 6 04:25:26 from 192.168.1.1
[cisco@linux1 ~]$ su -
Password: cisco123
[root@linux1 ~]# tethereal R "tcp.port == 80"

Step 16 On the client, start a Ethereal sniffer trace on the 209.165.201.PC interface. Then,
issue a wget request from the command line to the servers static IP.
C:\tools\wget-1.10.2b>wget http://172.16.PC.222
--12:08:30-- http:// 172.16.PC.222/
=> ìndex.html.7'
Connecting to 172.16.PC.222:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1,219 (1.2K) [text/html]

100%[====================================>] 1,219 --.-
-K/s

12:08:30 (8.67 MB/s) - ìndex.html.5' saved [1219/1219]
Step 17 Observe the tethereal output from the Linux server. Notice that the server IP is now
192.168.1.10 rather than 172.16.PC.222.
449.108905 209.165.201.PC -> 192.168.1.10 TCP 2399 > http
[SYN] Seq=0 Ack=0 Win=64270 Len=0 MSS=1460
449.109199 192.168.1.10 -> 209.165.201.PC TCP http > 2399
[SYN, ACK] Seq=0 Ack=1 Win=5870 Len=0 MSS=1460
449.110228 209.165.201.PC -> 192.168.1.10 TCP 2399 > http
[ACK] Seq=1 Ack=1 Win=64270 Len=0
449.117018 209.165.201.PC -> 192.168.1.10 HTTP GET / HTTP/1.0
449.117077 192.168.1.10 -> 209.165.201.PC TCP http > 2399
449.137044 192.168.1.10 -> 209.165.201.PC HTTP HTTP/1.1 200
OK
449.171825 192.168.1.10 -> 209.165.201.PC HTTP Continuation
or non-HTTP traffic
449.143738 209.165.201.PC -> 192.168.1.10 TCP 2399 > http
449.149136 192.168.1.10 -> 209.165.201.PC TCP http > 2399
[FIN, ACK] Seq=1485 Ack=101 Win=5870 Len=0
449.150719 209.165.201.PC -> 192.168.1.10 TCP 2399 > http
449.155886 209.165.201.PC -> 192.168.1.10 TCP 2399 > http
[FIN, ACK] Seq=101 Ack=1486 Win=64270 Len=0
449.156071 192.168.1.10 -> 209.165.201.PC TCP http > 2399
Step 18 On the client, analyze the Ethereal trace.
Static NAT Client Output

Step 19 On the Cisco ACE Module, view the ACL, service policy, and connection counters.
remark :
209.165.201.PC host 172.16.PC.222
(hitcount=1)

PodP-ACE/Lab-NAT-PC# show service-policy SVR-NAT

Status : ACTIVE
-----------------------------------------
Interface: vlan 4PC
service-policy: SVR-NAT
class: LNX-SOURCE
nat:
nat static 172.16.PC.222 vlan 3PC
curr conns : 1 , hit count : 1
dropped conns : 0
client pkt count : 7 , client byte count: 396
server pkt count : 6 , server byte count: 1728

PodP-ACE/Lab-NAT-PC# show stats connection

+------------------------------------------+
+------- Connection statistics ------------+
+------------------------------------------+
Total Connections Created : 2
Total Connections Current : 2
Total Connections Destroyed: 0
Total Connections Timed-out: 0
Total Connections Failed : 0
Step 20 Verify that server source NAT works as expected, which means that connections
sourced from the server 192.168.1.10 will be translated to 172.16.PC.222 as they
traverse the Cisco ACE Module.
PodP-ACE/Lab-NAT-PC(config)# access-list SVR-INIT extended
permit tcp host 192.168.1.10 any
PodP-ACE/Lab-NAT-PC(config)# int vlan 4PC
PodP-ACE/Lab-NAT-PC(config-if)# access-group input SVR-INIT
Step 21 Initiate a Telnet session from the Linux server to the client, then capture a sniffer
trace using Ethereal on the Client PC to verify the servers source IP address. Next,
capture a trace on the client to verify that the server source address is translated to
172.16.PC.222.
Note The Telnet session will fail because the client is not accepting Telnet connections.
[root@linux1 ~]# tethereal R "ip.addr == 209.165.201.0/24" &
[1] 10580
Capturing on eth0
[root@linux1 ~]# telnet 209.165.201.PC
Trying 209.165.201.PC...
34.711920 192.168.1.10 -> 209.165.201.PC TCP 34564 > telnet
[SYN] Seq=0 Ack=0 Win=5870 Len=0 MSS=1460 TSV=822460873 TSER=0
WS=2
34.716002 209.165.201.PC -> 192.168.1.10 TCP telnet > 34564
[RST, ACK] Seq=0 Ack=0 Win=0 Len=0
telnet: connect to address 209.165.201.PC: Connection refused
telnet: Unable to connect to remote host: Connection

No. Source Destination Proto Info
28 172.16.PC.222 209.165.201.PC TCP 34563 > telnet [SYN]
Seq=0 Ack=0 Win=5870 Len=0 MSS=146031 209.165.201.PC
172.16.PC.222 TCP telnet > 34563 [RST, ACK] Seq=0 Ack=0
Win=0 Len=06

PodP-ACE/Lab-NAT-PC# show service-policy SVR-NAT

Status : ACTIVE
-----------------------------------------
Interface: vlan 4PC
class: LNX-SOURCED
nat:
dropped conns : 0
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 NAT can be applied based on ACL matches and can
encompass an entire network address space.
The figure illustrates what you will accomplish in this task
Static Destination NAT for a Subnet
Client
209.165.201.PC
Cisco ACE
VLAN 2PC
172.16.PC.12
Cisco ACE
VLAN 4PC
192.168.1.1
Server
192.168.1.10
192.168.1.11
192.168.1.12
192.168.1.13
192.168.1.14
192.168.1.15
192.168.1.0/24 10.1.PC.0/0
Outside Local Outside Global

Activity Procedure
Step 1 Create an access list named SVR-VLAN-INIT to classify traffic initiated by a device
on the server VLAN.
PodP-ACE/Lab-NAT-PC(config)# access-list SVR-VLAN-INIT
extended permit tcp 192.168.1.0 255.255.255.0 any
Step 2 Define a class map named SERVER-VLAN-SOURCED that matches on the ACL
defined to classify server initiated traffic.
PodP-ACE/Lab-NAT-PC(config)# class-map match-all SERVER-VLAN-
SOURCED
PodP-ACE/Lab-NAT-PC(config-cmap)# match access-list SVR-VLAN-
INIT
PodP-ACE/Lab-NAT-PC(config)# exit
Step 3 Edit the multimatch policy map that specifies NAT as the action and remove the
previous class match.
PodP-ACE/Lab-NAT-PC(config)# policy-map multi-match SVR-NAT
PodP-ACE/Lab-NAT-PC(config-pmap)# no class LNX-SOURCED
Step 4 Provide the static IP subnet that will be used for the server traffic, and define which
VLAN the server traffic will use after it has been translated.
PodP-ACE/Lab-NAT-PC(config-pmap)# class SERVER-VLAN-SOURCED
netmask 255.255.255.0 vlan 2PC
Error: Specified ip address duplicates with an existing ip
address configured in the context!
Note IP addresses which overlap existing interface VLAN spaces are not allowed. This prevents
the possibility of introducing duplicate IPs.
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.
Step 5 Ensure that NAT is applied in both directions by modifying the existing ACL and
applying it to the server side (inside) interface. Without an ACL, clients cannot
initiate connections to the servers.
PodP-ACE/Lab-NAT-PC(config)# no access-list INBOUND
PodP-ACE/Lab-NAT-PC(config)# access-list INBOUND extended
permit tcp host 209.165.201.PC any
PodP-ACE/Lab-NAT-PC(config)# interface vlan 2PC
PodP-ACE/Lab-NAT-PC(config-if)# access-group input INBOUND
Step 6 Define a static route on the client to allow the client to reach the translated subnet
10.1.PC.0/24.
C:\tools\wget-1.10.2b> route add 10.1.PC.0 mask 255.255.255.0
209.165.201.PC
Step 7 Verify that your static subnet NAT is working. Telnet to the servers
(10.1.PC.10 - 10.1.PC.15) from your Client PC; try several servers. While you are
logged into at least one server session, execute a show conn and a show xlate to see
the destination NAT.
Pod1-ACE/Lab-NAT-11# show conn

total current connections : 4

conn-id np dir proto vlan source destination state
----------+--+---+-----+----+---------------------+---------------------+------+
12 2 in TCP 211 209.165.201.PC:1039 172.16.PC.12:23 ESTAB
6 2 out TCP 211 172.16.PC.12:23 209.165.201.PC:1039 ESTAB
10 2 in TCP 211 209.165.201.PC:1250 10.1.11.PC:23 ESTAB
9 2 out TCP 411 192.168.1.PC:23 209.165.201.PC:1250 ESTAB
Pod1-ACE/Lab-NAT-11# show xlate
NAT from vlan411:192.168.1.15 to vlan211:10.1.11.15 count:1
Step 8 Keeping your client-initiated Telnet connection open, examine the Cisco ACE
counters.
PodP-ACE/Lab-NAT-PC(config-if)# do sho service-policy SVR-NAT

Status : ACTIVE
-----------------------------------------
Interface: vlan 4PC
class: SERVER-VLAN-SOURCED
nat:
dropped conns : 0
client pkt count : 18 , client byte count:
871
server pkt count : 19 , server byte count:
956

PodP-ACE/Lab-NAT-PC(config-if)# do sho access-list INBOUND
remark :
209.165.201.PC any (hitcount=1)
Task 3: Apply the Baseline Configuration
The Cisco ACE Module 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 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.
PodP-ACE/Lab-NAT-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...
Rollback succeeded
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 2 Task 1 Answer Key

access-list INBOUND line 8 extended permit tcp host 209.165.201.PC
host 172.16.PC.222
access-list SVR-INIT line 8 extended permit tcp host 192.168.1.10 any

class-map match-all LNX-SOURCED
2 match source-address 192.168.1.10 255.255.255.255
class-map type management match-any remote-access
description remote-access-traffic-match
2 match protocol telnet any
3 match protocol ssh any
4 match protocol icmp any

policy-map type management first-match remote-mgmt
class remote-access
permit

policy-map multi-match SVR-NAT
class LNX-SOURCED
nat static 172.16.PC.222 netmask 255.255.255.255 vlan 2PC

interface vlan 2PC
ip address 172.16.PC.12 255.255.255.0
access-group input INBOUND
service-policy input remote-mgmt
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
access-group input SVR-INIT
service-policy input SVR-NAT
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
username cisco password 5 $1$DLODpUTE$pzudNN.PTCWK.E45AsyCz/ role
Admin domain default-domain
Lab 2 Task 2 Answer Key
Changes from the previous task are bolded.
access-list INBOUND line 8 extended permit tcp host 209.165.201.PC any
access-list SVR-INIT line 8 extended permit tcp host 192.168.1.10 any
access-list SVR-VLAN-INIT line 8 extended permit tcp 192.168.1.0
255.255.255.0 any

class-map match-all LNX-SOURCED
class-map match-all SERVER-VLAN-SOURCED
2 match access-list SVR-VLAN-INIT

class remote-access
permit

policy-map multi-match SVR-NAT
class SERVER-VLAN-SOURCED

interface vlan 2PC
ip address 172.16.PC.12 255.255.255.0
access-group input INBOUND
no shutdown
interface vlan 3PC
ip address 10.10.10.1 255.255.255.0
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
access-group input SVR-INIT
service-policy input SVR-NAT
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
Lab 3: Configuring Server Load Balancing
Activity Objective
In this exercise, you will configure your ACE context to match traffic destined for the VIP and
load-balance these flows to the real servers (rservers) on a private network behind your ACE
context. To accomplish this, you will apply class maps to classify client traffic destined to a
VIP address. The Cisco ACE Module will load-balance that traffic to a server farm and one of
the rservers will be selected to respond to the client request. To allow client traffic into the
ACE context, you must configure an access list.
After you complete this lab, you will be able to meet the following objectives:
Define real server containers and server farms containers
Configure class and policy maps to provide load balancing
Observe the Cisco ACE Module load-balancing client traffic
Configure Dynamic Source NAT to VIP
Visual Objective
Interface Service Policy
Apply to Any Interface
Multimatch Policy Map
Configuring Server Load Balancing
MSFC
Cisco ACE
C
a
t
a
l
y
s
t

6
5
0
0
Client
Servers
Traffic Class Map
Match VIP Connections
Load-Balancing Policy Map
Default Class
Real
Server 1
Real
Server 2
Server Farm
Only Allow Traffic Destined to a VIP

Required Resources
These are the resources and equipment that are required to complete this activity:
Cisco Catalyst 6500 with Supervisor Engine 720 and ACE Module
Client PC with a Telnet client and web browsers
Task 1: Configure Real Servers
In this task, you will connect to a context (specified by the IP address in step 2) and create a
configuration for the real servers within the pod. The Cisco ACE Module has administrative
connectivity enabled for the client.
Activity Procedure
C:\> telnet 172.16.PC.5
Trying 172.16.PC.5...


Username: cisco
Password: cisco123
PodP-ACE/Lab-SLB-PC#
Step 4 Use the checkpoint system to roll back the configuration:
PodP-ACE/Lab-SLB-PC# checkpoint rollback baseline-mgmt
Step 6 The first step in setting up a load-balancing configuration in an ACE context is to
create real server instances, known as rservers. Use this naming convention:
DC5-LNX<server_number>
PodP-ACE/Lab-SLB-PC# conf t
PodP-ACE/Lab-SLB-PC(config)# rserver DC5-LNX1
Note There are two types of rservers: host and redirect. The default is host; you do not have to
specify the host type in the CLI when you create rservers. The redirect type allows the Cisco
ACE Module to redirect web clients to a different site. In this lab, you will use the host type
only.
Step 7 In 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.
PodP-ACE/Lab-SLB-PC(config-rserver-host)# ip address
192.168.1.11
PodP-ACE/Lab-SLB-PCpodPclientC(config-rserver-host)# inservice
PodP-ACE/Lab-SLB-PC(config-rserver-host)# exit
Step 8 Create another rserver using the IP address of the second real web server
192.168.1.12 with the name DC5-LNX2.
PodP-ACE/Lab-SLB-PC(config)# rserver DC5-LNX2
PodP-ACE/Lab-SLB-PC(config-rserver-host)# ip address
192.168.1.12
PodP-ACE/Lab-SLB-PC(config-rserver-host)# inservice
PodP-ACE/Lab-SLB-PC(config-rserver-host)# exit
Step 9 Show the rservers you have just created by using the show run and show rserver
commands.
PodP-ACE/Lab-SLB-PC(config)# do show run rserver

rserver host DC5-LNX1
ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice

PodP-ACE/Lab-SLB-PC(config)# do show rserver DC5-LNX1

rserver : DC5-LNX1, type: HOST
state : INACTIVE
---------------------------------
----------
connections-----------
real weight state current
total
---+---------------------+------+------------+----------+--
------------------
Step 10 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.
PodP-ACE/Lab-SLB-PC(config)# serverfarm SERVERS1
Step 11 Add the recently created rservers to the server farm.
PodP-ACE/Lab-SLB-PC(config-sfarm-host)# rserver DC5-LNX1
PodP-ACE/Lab-SLB-PC(config-sfarm-host-rs)# inservice
PodP-ACE/Lab-SLB-PC(config-sfarm-host)# rserver DC5-LNX2
Step 12 Notice that the output from the show rserver command has changed after the
rservers were added to the server farm.
PodP-ACE/Lab-SLB-PC(config-sfarm-host-rs)# do show rserver
DC5-LNX1

state : OPERATIONAL
---------------------------------
----------
total
---+---------------------+------+------------+----------+--
------------------
serverfarm: SERVERS1
192.168.1.11:0 8 OPERATIONAL 0 0

PodP-ACE/Lab-SLB-PC(config-sfarm-host-rs)# do show rserver
DC5-LNX2

state : OPERATIONAL
---------------------------------
----------
total
---+---------------------+------+------------+----------+--
------------------
192.168.1.12:0 8 OUTOFSERVICE 0 0
Note Be sure to inservice the rservers within the server farm. Failure to do so will cause Cisco
ACE Module to consider these rservers out of service, and the server farm will not be
capable of receiving or responding to client requests.
PodP-ACE/Lab-SLB-PC(config-sfarm-host-rs)# inservice
PodP-ACE/Lab-SLB-PC(config-sfarm-host-rs)# do show serverfarm
SERVERS1
serverfarm : SERVERS1, type: HOST
total rservers : 2
---------------------------------
----------
total
---+---------------------+------+------------+----------+--
------------------
rserver: DC5-LNX1
192.168.1.11:0 8 OPERATIONAL 0 0
rserver: DC5-LNX2
192.168.1.12:0 8 OPERATIONAL 0 0

What is odd about these rservers being in the OPERATIONAL state?
Can you ping them? Why or why not?
Execute a do show arp. Are the rservers up?

Step 13 Add the other three web servers to the server farm before going onto the next step
and ensure that all five web servers are in the OPERATIONAL state.
The three additional web servers are as follows; put them into the server farm SERVERS1:
DC5-LNX3 192.168.1.13
DC5-LNX4 192.168.1.14
DC5-LNX5 192.168.1.15
Step 14 Add a new interface to allow the Cisco ACE Module to communicate with the real
servers. Use IP address 192.168.1.1/24 for VLAN 4PC.
PodP-ACE/Lab-SLB-PC(config)# interface vlan 4PC
PodP-ACE/Lab-SLB-PC(config-if)# ip address 192.168.1.1
255.255.255.0
PodP-ACE/Lab-SLB-PC(config-if)# description Servers vlan
PodP-ACE/Lab-SLB-PC(config-if)# no shut
PodP-ACE/Lab-SLB-PC(config-if)# exit
PodP-ACE/Lab-SLB-PC(config)# exit
Note VLAN 4PC is already configured in the Catalyst 6500 and the Admin context to be available
to this context.
Catalyst 6500 Config:
svclc multiple-vlan-interfaces
svclc module 1 vlan-group 1,2
svclc vlan-group 1 2P1-2P8
svclc vlan-group 2 4P1-4P8

Ace-Module/Admin:
context Lab-SLB-PC
Step 15 Use the show arp command to observe how the Cisco ACE Module populates its
ARP table.
PodP-ACE/Lab-SLB-PC# show arp

Context Lab-SLB-21
================================================================================
IP ADDRESS MAC-ADDRESS Interface Type Encap NextArp(s) Status
================================================================================
172.16.PC.1 00.d0.04.ec.0c.00 vlan2PC GATEWAY 71 61 sec up
172.16.PC.31 00.12.43.dc.83.05 vlan2PC INTERFACE LOCAL _ up
192.168.1.1 00.05.9a.3b.9a.c1 vlan4PC INTERFACE LOCAL _ up
192.168.1.11 00.50.56.29.01.01 vlan4PC RSERVER 78 297 sec up
================================================================================
Total arp entries 8
You have completed this task when you have:
Verified that the rservers are in the OPERATIONAL state.
Verified that the rservers are in the OPERATIONAL state within the server farm.
Confirmed that ARP entries exist for each of the rservers.
Task 2: Configuring Load-Balancing Class Maps and Policy
Maps
The Cisco ACE Module 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 type of matches is load balancing based on a clients attempt to reach a virtual
IP address. This type of a match is considered Layer 3 because it matches only the destination
IP and then makes a load-balancing decision.
Activity Procedure
Step 1 Start by creating a class map to distinguish traffic destined for a virtual IP (VIP)
from traffic destined elsewhere. Use the IP address 172.16.PC.50.
PodP-ACE/Lab-SLB-PC(config)# class-map VIP-50
PodP-ACE/Lab-SLB-PC(config-cmap)# match virtual-address
172.16.PC.50 any
Step 2 A policy map of type loadbalance is required. The Cisco ACE Module will attempt
to match a defined class map at Layer 507 in the order of occurrence as indicated by
the keyword first-match. The class-default map will handle non-matching 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 named LB-LOGIC and use the
class-default map.
PodP-ACE/Lab-SLB-PC(config)# policy-map type loadbalance
first-match LB-LOGIC
PodP-ACE/Lab-SLB-PC(config-pmap-lb)# class class-default
PodP-ACE/Lab-SLB-PC(config-pmap-lb-c)# serverfarm SERVERS1

Step 3 Use the show run policy-map command to view the configuration additions.
PodP-ACE/Lab-SLB-PC(config-pmap-lb-c)# do show run policy-map

class remote-access
permit
policy-map type loadbalance first-match LB-LOGIC
class class-default
serverfarm SERVERS1
Step 4 Add another policy map called CLIENT-VIPS, but this time set the type to be multi-
match. This policy simply ties classified incoming requests (at Layer 3 or Layer 4)
to a load-balancing policy map. Create a multimatch policy and apply the class map
to define the VIP address.
PodP-ACE/Lab-SLB-PC(config)# policy-map multi-match CLIENT-
VIPS
PodP-ACE/Lab-SLB-PC(config-pmap)# class VIP-50
PodP-ACE/Lab-SLB-PC(config-pmap-c)# loadbalance policy LB-
LOGIC
PodP-ACE/Lab-SLB-PC(config-pmap-c)# loadbalance vip inservice
Step 5 View the running configuration to observe the new policy map.
PodP-ACE/Lab-SLB-PC(config-pmap-c)# do show run policy-map

class remote-access
permit
class class-default
serverfarm SERVERS1
policy-map multi-match CLIENT-VIPS
class VIP-50
loadbalance vip inservice
loadbalance policy LB-LOGIC
Step 6 Apply the multimatch policy map to the client-facing interface.
PodP-ACE/Lab-SLB-PC(config-if)# service-policy input CLIENT-
VIPS
Step 7 Verify that the VIP is applied and in service (meaning the Cisco ACE Module will
respond to traffic destined to the VIP address). Use the show service-policy
command with and without the detail parameter to view the additional information
the Cisco ACE Module provides.
PodP-ACE/Lab-SLB-PC(config-if)# do sho service-policy CLIENT-
VIPS

Status : ACTIVE
-----------------------------------------
Interface: vlan 2PC
service-policy: client-vips
class: VIP-50
loadbalance:
L7 loadbalance policy: lb-logic
VIP Route Metric : 77
VIP Route Advertise : DISABLED
VIP ICMP Reply : DISABLED
VIP State: INSERVICE
dropped conns : 0

VIPS detail

Status : ACTIVE
Description: -
-----------------------------------------
Interface: vlan 2PC
service-policy: CLIENT-VIPS
class: VIP-50
loadbalance:
L7 loadbalance policy: LB-LOGIC
dropped conns : 0
L7 Loadbalance policy : lb-logic
class/match : class-default
LB action :
hit count : 0
dropped conns : 0
Step 8 Create a new access list from the global configuration.
PodP-ACE/Lab-SLB-PC(config)# access-list anyone extended
permit tcp any any
Step 9 Apply the access list to the client-facing interface.
PodP-ACE/Lab-SLB-PC(config-if)# access-group input anyone

PodP-ACE/Lab-SLB-PC(config-if)# do sho access-list anyone
access-list:anyone, elements: 1, status: ACTIVE
remark :
access-list anyone line 10 extended permit tcp any any
(hitcount=0)
Verified that the service policy is in the ACTIVE state.
Verified that the access list is in the ACTIVE state.
Task 3: Test the New VIP Load-Balancing Configuration
In this task, you will create a baseline configuration for all other labs.
Activity Procedure
Step 1 Use a browser on the Client PC to verify that the Cisco ACE Module is load-
balancing traffic to the server farm using the URL http://172.16.PC.50.
Note The color of an image indicates which server supplied the image.
Step 2 Notice that the service policy counters increment as connections are handled.
VIPS

Status : ACTIVE
-----------------------------------------
Interface: vlan 2PC
service-policy: CLIENT-VIPS
class: VIP-50
loadbalance:
L7 policy: LB-LOGIC
dropped conns : 0
64712
Step 3 Show the ACL to see the number of incoming requests.
PodP-ACE/Lab-SLB-PC(config-if)# do sho access-list anyone
access-list:anyone, elements: 1, status: ACTIVE
remark :
(hitcount=10)
Verified that the Cisco ACE Module load-balanced an HTTP request to the VIP.
Task 4: Configure Dynamic NAT
The goal of this exercise is to use dynamic source NAT (SNAT) for traffic from the client
destined to the VIP. You will use dynamic NAT to translate the clients IP (209.165.201.PC) to
10.0.0.1-10.0.0.6. Keep in mind that the Cisco ACE Module also does an implicit destination
NAT (DNAT) operation when load-balancing traffic from the VIP to the rserver.
The figure illustrates what you will accomplish in this task.
Dynamic Source NAT for a Subnet
Client
209.165.201.PC
Cisco ACE
VLAN 2PC
172.16.PC.5
Cisco ACE
VIP
172.16.PC.150
Server
192.168.1.10
192.168.1.11
192.168.1.12
192.168.1.13
192.168.1.14
192.168.1.15
10.0.0.1-6 209.165.201.PC
Inside Global Outside Global
192.168.1.11-15 10.0.0.1-6
Translated (NAT) and
Load- Balanced to:
Translated (NAT) to:
172.16.PC.150 209.165.201.PC
Destination Address Source Address

Activity Procedure
Step 1 Continue from the last task or use the checkpoint system to roll the configuration to
the slb-end configuration.
PodP-ACE/Lab-SLB-PC#
Step 3 Execute the show run command to see what is preconfigured for this lab.
Step 4 Create the ALLOW-CLI access list to permit the client to send traffic to the server.
PodP-ACE/Lab-SLB-PC(config)# access-list ALLOW-CLI extended
permit ip 209.165.201.0 255.255.255.0 any
Step 5 Dynamic NAT also uses a class map to define what traffic is to be translated, so
create a class map to match any client traffic:
PodP-ACE/Lab-SLB-PC(config)# class-map match-all CLIENT-
SOURCED
PodP-ACE/Lab-SLB-PC(config-cmap)# match source-address
209.165.201.0 255.255.255.0
Step 6 You need a policy map that says dynamic NAT is to be performed on traffic
matched by the class map CLIENT-SOURCED. You will also create a NAT pool
identified as 123 that uses the source addresses 192.168.1.200 through
192.168.1.205.
PodP-ACE/Lab-SLB-PC(config)# policy-map multi-match NATRULES
PodP-ACE/Lab-SLB-PC(config-pmap)# class CLIENT-SOURCED
PodP-ACE/Lab-SLB-PC(config-pmap-c)# nat dynamic 123 vlan 4PC
Step 7 Define the NAT pool itself on the server-side interface.
PodP-ACE/Lab-SLB-PC(config-if)# nat-pool 123 10.0.0.1 10.0.0.6
netmask 255.255.255.0
Step 8 Apply the NAT service policy and the ACL to the client-side interface, where the
source IP that need to be translated reside. (Remove the previous ACL named
anyone first.)
PodP-ACE/Lab-SLB-PC(config-if)# no access-group input anyone
PodP-ACE/Lab-SLB-PC(config-if)# access-group input ALLOW-CLI
PodP-ACE/Lab-SLB-PC(config-if)# service-policy input NATRULES
Step 9 To verify that the NAT rules were applied correctly, verify that the NAT fabric is
configured.
PodP-ACE/Lab-SLB-PC# sho nat-fabric policies

Nat objects:

NAT object ID:15 mapped_if:240 policy_id:22
type:DYNAMIC nat_pool_id:5
Pool ID:5 PAT:0 pool_id:123 mapped_if:240
Ref_count:1 ixp_bindin
g:in IXP1
lower:10.0.0.1 upper:10.0.0.6 Bitmap:0x1f
List of NAT object IDs: 15
Step 10 To verify the NAT configuration, establish a Telnet connection from the context to
the Linux server. Switch to the user root and start tethereal.
PodP-ACE/Lab-SLB-PC# telnet 192.168.1.10
Trying 192.168.1.10...

18:26:27 EDT 2005) (0)

login: cisco
credentials
Password: cisco123
[root@linux1 ~]# tethereal R "tcp.port == 80"
On the client issue a wget request from the command line.
C:\tools\wget-1.10.2b>wget http://172.16.PC.50
--12:08:30-- http://172.16.PC.50/
=> ìndex.html.5'

100%[====================================>] 1,219 --.-
-K/s

12:08:30 (8.67 MB/s) - ìndex.html.5' saved [1219/1219]
Observe the client IP is now 10.0.0.1 10.0.0.6 in the tethereal output from the Linux server.
Capturing on eth0
3060.106616 10.0.0.1 -> 192.168.1.11 TCP 3991 > http [SYN]
Seq=0 Ack=0 Win=64240 Len=0 MSS=1460
3060.106689 192.168.1.11 -> 10.0.0.1 TCP http > 3991 [SYN,
ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
3060.107030 10.0.0.1 -> 192.168.1.11 TCP 3991 > http [ACK]
Seq=1 Ack=1 Win=64240 Len=0
3060.107762 10.0.0.1 -> 192.168.1.11 HTTP GET / HTTP/1.0
3060.107781 192.168.1.11 -> 10.0.0.1 TCP http > 3991 [ACK]
Seq=1 Ack=101 Win=5840 Len=0
3060.115186 192.168.1.11 -> 10.0.0.1 HTTP HTTP/1.1 200 OK
3060.115285 192.168.1.11 -> 10.0.0.1 HTTP Continuation or
non-HTTP traffic
3060.115490 192.168.1.11 -> 10.0.0.1 TCP http > 3991 [FIN,
ACK] Seq=1321 Ack=101 Win=5840 Len=0
3060.115851 10.0.0.1 -> 192.168.1.11 TCP 3991 > http [ACK]
Seq=101 Ack=1322 Win=62920 Len=0
3060.122303 10.0.0.1 -> 192.168.1.11 TCP 3991 > http [FIN,
ACK] Seq=101 Ack=1322 Win=62920 Len=0
3060.122336 192.168.1.11 -> 10.0.0.1 TCP http > 3991 [ACK]
Seq=1322 Ack=102 Win=5840 Len=0
Step 11 Use the show service policy command to view NAT statistics.
PodP-ACE/Lab-SLB-PC# sho service-policy NATRULES

Status : ACTIVE
-----------------------------------------
Interface: vlan 2PC
service-policy: NATRULES
class: CLIENT-SOURCED
nat:
nat dynamic 123 vlan 4PC
dropped conns : 0

Step 12 If you initiate a long-lived flow for the client to the server, you can observe the
dynamic NAT in the show conn output.
PodP-ACE/Lab-SLB-PC# sho conn

total current connections : 2

conn-id np dir proto vlan source destination state
----------+--+---+-----+----+---------------------+---------------------+-----
-+
18 2 in TCP 2PC 209.165.201.PC:4063 172.16.PC.50:23 ESTAB
10 2 out TCP 4PC 192.168.1.15:23 10.0.0.1:4063 ESTAB
You have completed this task when connections to the rserver are sourced from the 10.0.0.0
network instead of the original source network.
Activity Procedure
Rollback succeeded

Answer Key: Configuring Server Load-Balancing
When you complete this activity, your ACE context running configuration file will be similar to
the following, with differences that are specific to your device or workgroup.
Initial Configuration Sample (Pre-Task 1)
PodP-ACE/Lab-SLB-PC# sho run

description remote-access

class remote-access
permit

interface vlan 2PC
ip address 172.16.PC.11 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
username cisco password 5 $1$36iNgaXz$XzVbOllHUrxkP5FBEULiv0 role
Admin domain
default-domain
Lab 3 Task 3 Configuration Sample for a Working SLB Configuration
PodP-ACE/Lab-SLB-PC# sho run


ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
ip address 192.168.1.15
inservice

serverfarm host SERVERS1
rserver DC5-LNX1
inservice
rserver DC5-LNX2
inservice
rserver DC5-LNX3
inservice
rserver DC5-LNX4
inservice
rserver DC5-LNX5
inservice

class-map match-all VIP-50
2 match virtual-address 172.16.PC.50 any

class remote-access
permit
class class-default
serverfarm SERVERS1
policy-map multi-match CLIENT-VIPS
class VIP-50
loadbalance policy LB-LOGIC

interface vlan 2PC
ip address 172.16.PC.11 255.255.255.0
access-group input anyone
service-policy input CLIENT-VIPS
no shutdown
interface vlan 4PC
description Servers vlan
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
Admin domain
default-domain
Lab 3 Task 4 Configuration Example
Pod1-ACE/Lab-SLB-PC# sh run

login timeout 0

access-list ALLOW-CLI line 23 extended permit ip 209.165.201.0
255.255.255.0 any

rserver host dc5-lnx1
ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
ip address 192.168.1.15
inservice

serverfarm host SERVERS1
rserver dc5-lnx1
inservice
rserver dc5-lnx2
inservice
rserver dc5-lnx3
inservice
rserver dc5-lnx4
inservice
rserver dc5-lnx5
inservice

class-map match-all CLIENT-SOURCED

class remote-access
permit

policy-map type loadbalance http first-match slb5-logic
class class-default
serverfarm SERVERS1

policy-map multi-match NATRULES
class CLIENT-SOURCED
nat dynamic 123 vlan 4PC
policy-map multi-match client-vips
class VIP-50
loadbalance policy slb5-logic

interface vlan 2PC
description Client vlan
ip address 172.16.PC.5 255.255.255.0
access-group input ALLOW-CLI
service-policy input client-vips
service-policy input NATRULES
no shutdown
interface vlan 411
ip address 192.168.1.1 255.255.255.0
nat-pool 123 10.0.0.1 10.0.0.6 netmask 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
Lab 4: Implementing Health Monitoring
Activity Objective
In this exercise, you will configure your 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
Define passive health monitoring checks for a server farm
Configure the Cisco ACE action on a server failure
Configure partial server farm failover
Visual Objective
Implementing Health Monitoring
Primary
Rserver
Backup
Rserver
Rserver Probe
MSFC CiscoACE
Catalyst 6500
?
?
Passive Probe
Server Farm Probe
X

Required Resources
Cisco ACE Module
Task 1: Configure Health Monitoring for Real Servers
When configuring the Cisco ACE Module for health probe monitoring, out-of-band health
monitoring allows the Cisco ACE Module to sends active probes periodically to determine the
server state. ICMP, TCP, HTTP, and other predefined health probes as well as scripted probes
are in this health-monitoring category. There are three ways to apply probes; this task will show
how to apply probes per rserver.
Activity Procedure
Step 2 Connect to the Cisco ACE management IP address for your Lab 3 context.
C:\> telnet 172.16.PC.6
Trying 172.16.PC.6...


Username: cisco
Password: cisco123
PodP-ACE/Lab-HM-PC#
Step 4 Use the checkpoint system to roll the configuration to the hm-begin checkpoint.
Step 6 Create a http GET request probe.
PodP-ACE/Lab-HM-PC(config)# probe http GET-INDEX
Step 7 Show the probe you just created.
PodP-ACE/Lab-HM-PC(config-prope-http)# do show probe detail

probe : GET-INDEX
type : HTTP,
state : INACTIVE
description :
----------------------------------------------
port : 80 address : 0.0.0.0 addr
type : -
interval : 120 pass intvl : 300 pass
count : 3
fail count: 3 recv timeout: 10

http method : GET
http url : /
conn termination : GRACEFUL
expect offset : 0 , open timeout : 10
expect regex : -
send data : -
--------------------- probe results ---
-----------------
probe association probed-address probes failed
passed health
------------------- ---------------+----------+----------+-
---------+-------
Note The default is a HTTP GET, with a graceful TCP shutdown (TCP FIN sequence).
Step 8 Now that you see the default parameters, change the interval timer so the Cisco ACE
Module probes more frequently.
PodP-ACE/Lab-HM-PC(config-probe-http)# interval 15
Step 9 Assign the probe to an rserver.
PodP-ACE/Lab-HM-PC(config)# rserver dc6-lnx1
PodP-ACE/Lab-HM-PC(config-rserver-host)# probe GET-INDEX

Step 10 Look at the details of the probe several times over several seconds.
PodP-ACE/Lab-HM-PC(config-rserver-host)# do show probe
probe : GET-INDEX
type : HTTP, state : ACTIVE
----------------------------------------------
type : -
count : 3
--------------------- probe results ---
-----------------
passed health
------------------- ---------------+----------+----------+-
---------+-------
rserver : dc6-lnx1
192.168.1.11 0 0 0
INIT

probe : GET-INDEX
----------------------------------------------
type : -
count : 3
--------------------- probe results ---
-----------------
passed health
------------------- ---------------+----------+----------+-
---------+-------
rserver : dc6-lnx1
192.168.1.11 1 1 0
FAILED

Why did the probe fail?

Step 11 This is a change in the default behavior of the CSM. The Cisco ACE Module does
not accept any response code by default. Adding one will enable a successful probe.
PodP-ACE/Lab-HM-PC(config)# probe http GET-INDEX
PodP-ACE/Lab-HM-PC(config-probe-http)# expect status 200 200
Note If using the default settings, the probe will take 3 (pass interval) iterations of 300 seconds
(pass interval) before the rserver will be put back into rotation. To expedite the process,
perform a no inservice/inservice on the rserver, which will force the probing to enter the
initialization state. Also change the probing interval with the interval <2-65535> (seconds)
command and the passdetect interval with the passdetect interval <2-65535> (seconds)
command.
PodP-ACE/Lab-HM-PC(config-probe-http)# interval 5
PodP-ACE/Lab-HM-PC(config-probe-http)# passdetect interval 10

PodP-ACE/Lab-HM-PC(config)# rserver dc6-lnx1
PodP-ACE/Lab-HM-PC(config-rserver-host)# no ins
PodP-ACE/Lab-HM-PC(config-rserver-host)# ins
probe : GET-INDEX
----------------------------------------------
type : -
count : 3
--------------------- probe results ---
-----------------
passed health
------------------- ---------------+----------+----------+-
---------+-------
rserver : dc6-lnx1
192.168.1.11 5 1 4
SUCCESS
Step 12 Force the probe to fail by shutting down the server-side VLAN.
PodP-ACE/Lab-HM-PC(config-rserver-host)# interface vlan 4PC
PodP-ACE/Lab-HM-PC(config-if)# shutdown

Step 13 View the probe again and with details after a single probe has failed. Notice there is
now a reason listed for the last probe failure.
PodP-ACE/Lab-HM-PC(config-if)# do sho probe
probe : GET-INDEX
----------------------------------------------
type : -
count : 3
--------------------- probe results ---
-----------------
passed health
------------------- ---------------+----------+----------+-
---------+-------
rserver : dc6-lnx1
192.168.1.11 36 2
35 SUCCESS

PodP-ACE/Lab-HM-PC(config-if)# do sho probe GET-INDEX detail

probe : GET-INDEX
description :
----------------------------------------------
type : -
count : 3

http method : GET
http url : /
expect regex : -
send data : -
--------------------- probe results ---
-----------------
passed health
------------------- ---------------+----------+----------+-
---------+-------
rserver : dc6-lnx1
192.168.1.11 36 2
35 SUCCESS

Socket state : CLOSED
No. Passed states : 1 No. Failed states : 0
No. Probes skipped : 0 Last status code : 0
No. Out of Sockets : 0 No. Internal error: 0
Last disconnect err : Server open timeout (no SYN ACK)
Last probe time : Sat Apr 8 22:46:58 2006
Last fail time : Never
Last active time : Sat Apr 8 22:36:28 2006
Step 14 After three consecutive probes have failed, the probe will take the rserver out of
service by placing it in a Probe-Failed state.
PodP-ACE/Lab-HM-PC(config-if)# do sho probe
probe : GET-INDEX
----------------------------------------------
type : -
count : 3
--------------------- probe results ---
-----------------
passed health
------------------- ---------------+----------+----------+-
---------+-------
rserver : dc6-lnx1
192.168.1.11 39 4
35 FAILED

PodP-ACE/Lab-HM-PC(config-if)# do sho rserver dc6-lnx1

rserver : dc6-lnx1, type: HOST
state : PROBE-FAILED
---------------------------------
----------
total
---+---------------------+------+------------+----------+--
------------------
serverfarm: servers3
192.168.1.11:0 8 PROBE-FAILED 0 0
Note Because interface VLAN 4PC was shut down, you might see ARP-FAILED instead of
PROBE-FAILED.

Note You can clear the probe counters with the clear probe command
Step 15 Enable the server VLAN interface, then verify that the probe succeeds and that the
rserver is placed back in an operational state.
Note The pass detect interval is 5 minutes, so expect this delay if the default value was not
altered.
You have completed this task when you have configured a probe for an rserver and verified that
the probe is successfully monitoring the rserver.
Task 2: Configure Health Monitoring for a Server Farm
In this task, you will deploy a probe for all rservers within the server farm.
Activity Procedure
Step 1 Create a simple Layer 4 probe for TCP. Configure it for port 23, to check the Telnet
port for TCP connectivity. Reduce the intervals for failure and pass detection.
PodP-ACE/Lab-HM-PC(config)# probe tcp L4-TCP
PodP-ACE/Lab-HM-PC(config-probe-tcp)# port 23
PodP-ACE/Lab-HM-PC(config-probe-tcp)# interval 5
PodP-ACE/Lab-HM-PC(config-probe-tcp)# passdetect interval 10
PodP-ACE/Lab-HM-PC(config-probe-tcp)# connection term forced
PodP-ACE/Lab-HM-PC(config-probe-tcp)# do sho run probe

probe http GET-INDEX
interval 5
passdetect interval 10
expect status 200 200
probe tcp L4-TCP
port 23
interval 5
connection term forced
Step 2 Apply the TCP probe to the existing server farm and observe them using show
commands.
PodP-ACE/Lab-HM-PC(config-probe-tcp)# exit
PodP-ACE/Lab-HM-PC(config)# serverfarm servers6
PodP-ACE/Lab-HM-PC(config-sfarm-host)# probe L4-TCP
PodP-ACE/Lab-HM-PC(config-sfarm-host)# do show probe
probe : GET-INDEX
----------------------------------------------
type : -
count : 3
--------------------- probe results ---
-----------------
passed health
------------------- ---------------+----------+----------+-
---------+-------
rserver : dc6-lnx1
192.168.1.11 123 0
123 SUCCESS

probe : L4-TCP
type : TCP, state : ACTIVE
----------------------------------------------
type : -
count : 3
--------------------- probe results ---
-----------------
passed health
------------------- ---------------+----------+----------+-
---------+-------
serverfarm : servers6
real : dc6-lnx1[0]
192.168.1.11 1 0 1
SUCCESS
real : dc6-lnx2[0]
192.168.1.12 1 0 1
SUCCESS
real : dc6-lnx3[0]
192.168.1.13 1 0 1
SUCCESS
real : dc6-lnx4[0]
192.168.1.14 1 0 1
SUCCESS
real : dc6-lnx5[0]
192.168.1.15 1 0 1
SUCCESS
Step 3 Telnet to the real server and view the probes from the Cisco ACE Module. Limit the
capture to avoid capturing your current session. Press Control-C to terminate
tethereal.
PodP-ACE/Lab-HM-PC(config-probe-tcp)# do telnet 192.168.1.10
Trying 192.168.1.10...

18:26:27 EDT 2005) (0)

login: cisco
credentials
[cisco@linux1 ~]$ tethereal
-bash: tethereal: command not found
Password: cisco123
[root@linux1 ~]# tethereal -R "ip.addr == 192.168.1.11"
Capturing on eth0
0.481551 192.168.1.1 -> 192.168.1.11 TCP 37204 > telnet
[SYN] Seq=0 Ack=0 Win
=5840 Len=0 MSS=1460 TSV=199555497 TSER=0 WS=0
0.483704 192.168.1.11 -> 192.168.1.1 TCP telnet > 37204
[SYN, ACK] Seq=0 Ack=
1 Win=5792 Len=0 MSS=1460 TSV=2175843216 TSER=199555497 WS=2
0.484179 192.168.1.1 -> 192.168.1.11 TCP 37204 > telnet
[ACK] Seq=1 Ack=1 Win
=5840 Len=0 TSV=199555497 TSER=2175843216
0.484700 192.168.1.1 -> 192.168.1.11 TCP 37204 > telnet
[RST, ACK] Seq=1 Ack=
1 Win=5840 Len=0 TSV=199555497 TSER=2175843216
4.335322 192.168.1.1 -> 192.168.1.11 TCP 37213 > telnet
[SYN] Seq=0 Ack=0 Win
=5840 Len=0 MSS=1460 TSV=199555997 TSER=0 WS=0
4.336859 192.168.1.11 -> 192.168.1.1 TCP telnet > 37213
[SYN, ACK] Seq=0 Ack=
1 Win=5792 Len=0 MSS=1460 TSV=2175847069 TSER=199555997 WS=2
4.337184 192.168.1.1 -> 192.168.1.11 TCP 37213 > telnet
=5840 Len=0 TSV=199555997 TSER=2175847069
4.337902 192.168.1.1 -> 192.168.1.11 TCP 37213 > telnet
[RST, ACK] Seq=1 Ack=
1 Win=5840 Len=0 TSV=199555997 TSER=2175847069
Note Observe that the probes originate from the Cisco ACE Module interface, which is connected
to the servers via Layer 3.
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.
Task 3: Configure Health Monitoring for a Real Server Within a
Server Farm
In this task, you will deploy a probe for a single real server within the server farm.
Activity Procedure
Step 1 Create a probe for HTTPS. Reduce the intervals for failure and pass detection.
PodP-ACE/Lab-HM-PC(config)# probe https L5-SSL
PodP-ACE/Lab-HM-PC(config-probe-tcp)# interval 5
PodP-ACE/Lab-HM-PC(config-probe-tcp)# passdetect interval 10
PodP-ACE/Lab-HM-PC(config-probe-https)# do sho run probe | beg
L5
probe https L5-SSL
interval 5
Step 2 Apply the TCP probe to the existing server farm and observe them using show
commands.
PodP-ACE/Lab-HM-PC(config-probe-tcp)# exit
PodP-ACE/Lab-HM-PC(config)# serverfarm servers6
PodP-ACE/Lab-HM-PC(config-sfarm-host)# rserver dc6-lnx5
PodP-ACE/Lab-HM-PC(config-sfarm-host-rs)# probe L5-SSL
PodP-ACE/Lab-HM-PC(config-sfarm-host-rs)# do show probe L5-SSL
probe : L5-SSL
type : HTTPS, state : ACTIVE
----------------------------------------------
type : -
count : 3
--------------------- probe results ---
-----------------
passed health
------------------- ---------------+----------+----------+-
---------+-------
real : dc6-lnx5[0]
192.168.1.15 1 1 0
FAILED

Tip By taking the rserver out of service and placing it back in service, the Cisco ACE Module will
reset the probing sequence and thus reduce the time it takes for the changes to take effect.
Why is the probe failing? The next step will go through some troubleshooting steps that are
available on your Linux server.
Step 3 There are several ways to determine why the probe is failing. One approach is to
look at the server, verify that SSL is running, and use a sniffer trace.
PodP-ACE/Lab-HM-PC(config-sfarm-host-rs)# do telnet
192.168.1.10
login: cisco
password for cisco: cisco
[cisco@linux1 ~]$ su - cisco123

[root@linux1 ~]# netstat -l | egrep "https|Address"
Proto Recv-Q Send-Q Local Address Foreign
Address State
tcp 0 0 *:https *:*
LISTEN

[root@linux1 ~]# tethereal -R "tcp.port == 443"
Capturing on eth0
11.974627 192.168.1.1 -> 192.168.1.10 TCP 38508 > https
[SYN] Seq=0 Ack=0 Win=
5840 Len=0 MSS=1460 TSV=199666757 TSER=0 WS=0
11.976089 192.168.1.10 -> 192.168.1.1 TCP https > 38508
[SYN, ACK] Seq=0 Ack=1
Win=5792 Len=0 MSS=1460 TSV=2176688287 TSER=199666757 WS=2
11.977023 192.168.1.1 -> 192.168.1.10 TCP 38508 > https
[ACK] Seq=1 Ack=1 Win=
5840 Len=0 TSV=199666757 TSER=2176688287
11.979669 192.168.1.1 -> 192.168.1.10 SSLv3 Client Hello
11.979953 192.168.1.10 -> 192.168.1.1 TCP https > 38508
=5792 Len=0 TSV=2176688291 TSER=199666757
12.017120 192.168.1.10 -> 192.168.1.1 SSLv3 Server Hello,
Certificate, Server
Hello Done
12.018666 192.168.1.1 -> 192.168.1.10 TCP 38508 > https
[ACK] Seq=81 Ack=1144
Win=8001 Len=0 TSV=199666758 TSER=2176688328
12.033203 192.168.1.1 -> 192.168.1.10 SSLv3 Client Key
Exchange, Change Cipher
Spec, Encrypted Handshake Message
12.048926 192.168.1.10 -> 192.168.1.1 SSLv3 Change Cipher
Spec, Encrypted Hand
shake Message
12.050995 192.168.1.1 -> 192.168.1.10 SSLv3 Application Data
12.067325 192.168.1.1 -> 192.168.1.10 SSLv3 Encrypted Alert
12.067334 192.168.1.1 -> 192.168.1.10 TCP 38508 > https
[RST, ACK] Seq=415 Ack
=1512 Win=10287 Len=0 TSV=199666761 TSER=2176688375

Note Observe that the probes are requesting HTTP data and receiving HTTP data from the
server. These messages are seen as Application Data in the SSL analysis. Immediately
after receiving the server data, the Cisco ACE Module closes SSL and tears down the
connection with a TCP RST. This is an indication that the Cisco ACE Module found
something wrong with the returned data, because it closes TCP with a FIN sequence with
successful probes.
Step 4 You could continue tracing to see more of what is going on. Try the following.
(Warning: The output is very verbose.)
[root@linux1 ~]# tethereal -V -R "tcp.port == 443"

<output removed>
ClientHello
Secure Socket Layer
SSL Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: SSL 3.0 (0x0300)
Length: 75
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 71
Random.gmt_unix_time: Jul 5, 2006
20:05:50.000000000
Random.bytes
Session ID Length: 0
Cipher Suites Length: 32
Cipher Suites (16 suites)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA
(0x0035)
(0x002f)
Cipher Suite:
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)
Cipher Suite:
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062)
Cipher Suite:
TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 (0x0061)
Cipher Suite:
TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 (0x0060)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA
(0x000a)
Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA
(0x0009)
Cipher Suite:
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0008)
Cipher Suite: TLS_RSA_WITH_IDEA_CBC_SHA
(0x0007)
Cipher Suite:
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA
(0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5
(0x0004)
Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5
(0x0003)
Cipher Suite: TLS_RSA_WITH_NULL_SHA (0x0002)
Cipher Suite: TLS_RSA_WITH_NULL_MD5 (0x0001)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)

ServerHello
Secure Socket Layer
SSLv3 Record Layer: Handshake Protocol: Server Hello
Length: 74
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 70
Random.gmt_unix_time: Jun 25, 2006
11:22:51.000000000
Random.bytes
Session ID Length: 32
Session ID (32 bytes)
(0x0035)
Compression Method: null (0)
SSLv3 Record Layer: Handshake Protocol: Certificate
Length: 1050
Handshake Protocol: Certificate
Handshake Type: Certificate (11)
Length: 1046
Certificates Length: 1043
Certificates (1043 bytes)
Step 5 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. One option at this point is to use SSLdump and the
servers SSL certificate and RSA key to decrypt the message. However, you could
also look at the detail of the probe.
PodP-ACE/Lab-HM-PC# sho probe L5-SSL detail
probe : L5-SSL
description :
----------------------------------------------
type : -
count : 3

http method : GET
http url : /
expect regex : -
send data : -
--------------------- probe results ---
-----------------
passed health
------------------- ---------------+----------+----------+-
---------+-------
real : dc6-lnx5[0]
192.168.1.15 10 10 0
FAILED

Last disconnect err : Received invalid status code
Last probe time : Thu Jul 6 03:03:30 2006
Last fail time : Thu Jul 6 03:00:40 2006
Last active time : Never
Step 6 Looking at the probe detail is much more useful than the sniffer approach. This is
telling you something 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 necessary to configure the expected status before the probe will be
successful.
PodP-ACE/Lab-HM-PC(config)# probe https L5-SSL
PodP-ACE/Lab-HM-PC(config-probe-https)# expect status 200 499
PodP-ACE/Lab-HM-PC(config-sfarm-host-rs)# do sho probe L5-SSL
probe : L5-SSL
----------------------------------------------
type : -
count : 3
--------------------- probe results ---
-----------------
passed health
------------------- ---------------+----------+----------+-
---------+-------
real : dc6-lnx5[0]
192.168.1.10 67 14
53 SUCCESS
You have completed this task when you have configured a probe for an rserver and verified that
it is successfully monitoring the rserver.
Task 4: Return Code Parsing
The objective of this task is to configure the server farm with the an HTTP return-code
checking (retcode-map) command. You can configure multiple retcode maps on each server
farm. You will be able to view hit counts for retcode checking by using the show serverfarm
command. The Cisco ACE Module will be able to check for HTTP return codes associated with
the server farm and keep track of the total number of return codes received for each return code
number that you specify.
Activity Procedure
Step 1 Configure the preconfigured server farm server6 using the retcode command.
Specify the first number to begin at 400 and the second number to end at 405. Add
the check count option.
PodP-ACE/Lab-HM-PC(config-sfarm-host)# retcode 400 405 check
count
These are the options that can be applied to the retcode command:
number1: Specifies the minimum value for an HTTP return code. Enter an
integer from 100 to 599. The minimum value must be less than or equal to the
maximum value.
number2: Specifies the maximum value for an HTTP return code. Enter an
integer from 100 to 599. The maximum value must be greater than or equal to
the minimum value.
check: Checks for HTTP return codes associated with the server farm.
count: Keeps track of the total number of return codes received for each return
code number that you specify.
log: Creates a syslog error message when the number of events reaches the
specified threshold.
resume-service seconds: Specifies the number of seconds that the Cisco ACE
Module waits before it resumes service for the real server automatically after
taking the real server out of service because the remove option is configured.
Enter an integer from 1 to 4294967295. The default setting is 300.

Step 2 View the output from the show serverfarm servers6 retcode detail command.
PodP-ACE/Lab-HM-PC(config-sfarm-host)# do show serverfarm
servers6 retcode detail

rserver : dc6-lnx1[0] retcode-map : 400-405
---------------------------------------------
return-code action current-count total-count reset-
seconds reset-count
+-----------+--------+-------------+-----------+------------
-+-----------+
400 count 0 0 0
0
401 count 0 0 0
0
402 count 0 0 0
0
403 count 0 0 0
0
404 count 0 0 0
0
405 count 0 0 0
0
Step 3 Test the configuration from the browser on the client by sending a request to
http://172.16.PC.60/retcode. Generate multiple requests to the VIP using more than
one browser.
Step 4 View the output from the show serverfarm servers6 retcode detail command
again.
servers6 retcode detail

---------------------------------------------
seconds reset-count
+-----------+--------+-------------+-----------+------------
-+-----------+
400 count 0 0 0
0
401 count 0 0 0
0
402 count 0 0 0
0
403 count 0 0 0
0
404 count 1 1 0
0
405 count 0 0 0
0

Step 5 Change the configuration to log the return code instead of just using the count
option. The 2 in the example represents return code threshold and the 120 represents
the return code reset measured in seconds.
PodP-ACE/Lab-HM-PC(config-sfarm-host)# retcode 400 405 check
log 2 reset 120
Step 6 Test the configuration from the browser on the client by sending a request to
http://172.16.PC.60/retcode. Generate multiple requests to the VIP using multiple
browsers.
Step 7 View the output from the show serverfarm servers6 retcode command.
PodP-ACE/Lab-HM-PC(config)# do show serverfarm servers6
retcode

---------------------------------------------
seconds reset-count
+-----------+--------+-------------+-----------+------------
-+-----------+
404 log 0 85 120
17

---------------------------------------------
seconds reset-count
+-----------+--------+-------------+-----------+------------
-+-----------+
404 log 2 79 120
16
Step 8 You should be able to see the Cisco ACE Module logging the event if you enable
logging to the monitor, console, or syslog server. Log to the monitor so you can
view the warning that the Cisco ACE Module generates when the retcode threshold
is met. To stop logging to the monitor, use the no logging monitor command. Note
that you might see many messages on the monitor.
PodP-ACE/Lab-HM-PC(config)# do terminal monitor
PodP-ACE/Lab-HM-PC(config)# logging enable
PodP-ACE/Lab-HM-PC(config)# logging monitor 4

%ACE-4-728032: Real Server dc6-lnx1 in Serverfarm servers6 has
reached configured threshold for HTTP retcode 404
%ACE-4-728032: Real Server dc6-lnx2 in Serverfarm servers6
has reached configured threshold for HTTP retcode 404
You have completed this task when you understand how the Cisco ACE Module can count or
log an event when detecting a status code from the server.
Task 5: Configuring the Cisco ACE Action on Server Failure
The objectives of this task are to configure the failaction command with the purge and
reassign options. This feature is important because it determines the action the Cisco ACE
Module takes if a server goes down. Failaction purge was introduced in Cisco ACE 1.0.
Failaction reassign is a new feature in Cisco ACE 2.0.
Activity Procedure
Step 1 Create a new server farm to confirm the failaction behavior.
PodP-ACE/Lab-HM-PC(config)# serverfarm host FAILACTION
PodP-ACE/Lab-HM-PC(config-sfarm-host-rs)# inservice
Step 2 Modify the policy map of type loadbalance to use the FAILACTION server farm.
PodP-ACE/Lab-HM-PC(config)# policy-map type loadbalance http
first-match slb6-logic
PodP-ACE/Lab-HM-PC(config-pmap-lb)# class class-default
PodP-ACE/Lab-HM-PC(config-pmap-lb-c)# serverfarm FAILACTION
How many server farms can be defined per class map action?
Step 3 From your Client PC, establish a Telnet session to the VIP and log in to the server
using the username cisco and the password cisco. Verify that the Telnet session is
working as expected.
Step 4 While keeping your Telnet session open, take the rserver out of service and observe
the effect on the established Telnet session.
Pod2-ACE/Lab-HM-PC(config)# serverfarm FAILACTION
Pod2-ACE/Lab-HM-PC(config-sfarm-host)# rserver dc6-lnx1
Pod2-ACE/Lab-HM-PC(config-sfarm-host-rs)# no inservice
Why does your Telnet session still work when the rserver is not in service?
If you quit the session, can you reconnect? Why?
Step 5 Configure the failaction command with the purge option and issue the inservice
command for the rserver.
The purge option tells the Cisco ACE Module to remove the connections to a
real server if the real server in the server farm fails. The module sends a reset
(RST) to both the client and the server that failed.
Pod2-ACE/Lab-HM-PC(config-sfarm-host-rs)# inservice
PodP-ACE/Lab-HM-PC(config-sfarm-host-rs)# exit
PodP-ACE/Lab-HM-PC(config-sfarm-host)# failaction purge
Note Failaction purge is the clean way to send a RST (generated by the Cisco ACE Module)
back to the client in case of server failure for both Layer 4 and Layer 7 connections.
Step 6 Telnet to the VIP and log in into the server using the username cisco and the
password cisco. Verify that the Telnet session is working as expected.
Step 7 Take the rserver out of service and observe the effect on the established Telnet
session.
Step 8 Modify the server farm FAILACTION. Change the action to failaction reassign.
Under rserver dc6-lnx1, add a backup server backup-rserver dc6-lnx2 and the server
farm in service.
The reassign option tells the Cisco ACE Module to reassign the existing server
connections to the backup real server if a backup is configured for the failing
real server. If a backup real server has not been configured for the failing server,
then this keyword does nothing and leaves the existing connections untouched in
the failing real server.
PodP-ACE/Lab-HM-PC(config-sfarm-host)# serverfarm FAILACTION
PodP-ACE/Lab-HM-PC(config-sfarm-host)# failaction reassign
PodP-ACE/Lab-HM-PC(config-sfarm-host-rs)# backup-rserver dc6-
lnx2
Step 9 View the modifications to the failaction server farm.
PodP-ACE/Lab-HM-PC(config-sfarm-host)# do show run serverfarm

serverfarm host FAILACTION
failaction reassign
rserver dc6-lnx1
backup-rserver dc6-lnx2
inservice
rserver dc6-lnx1
Note The failaction reassign feature reassigns the connection to a different server (simply starts
sending packets to a different server) when the original server fails. The new server will
most likely send back a RST since it receives a packet for a connection which it has no clue
about, so the end result is likely to be the same (i.e. the browser gets back a RST). The
failaction reassign feature works only if the devices that you are load-balancing can
exchange state and accept connections in mid-stream, such as stateful firewalls. It is always
recommended to configure a probe when using this feature.
You have completed this task when you understand how the failaction purge and failaction
reassign features work, and what the backup rserver option does.
Task 6: Configuring Partial Server Farm Failover
The objective of this task is to configure a primary server farm with a backup server farm that
is used when the primary server farm meets a partial-threshold failure condition.
Activity Procedure
Step 1 Use the checkpoint system to roll the configuration to the baseline-mgmt and then
the hm-end configuration.
Step 2 Issue a show run command to see what is preconfigured for this lab.
Note This lab is built on the principles learned in the previous lab.
Step 3 Configure two server farms. Assign the first two rservers and fifth rserver to server
farm PRIMARY and the remaining two rservers to server farm BACKUP.
Step 4 View the configured server farms.
PodP-ACE/Lab-HM-PC(config-sfarm-host-rs)# do show run
serverfarm

serverfarm host PRIMARY
rserver dc6-lnx1
inservice
rserver dc6-lnx2
inservice
rserver dc6-lnx5
inservice
serverfarm host BACKUP
rserver dc6-lnx3
inservice
rserver dc6-lnx4
inservice
Step 5 Configure the primary server farm with a partial-threshold of 40%, to deactivate
the server farm if it falls below 40%. Also, add the back-inservice threshold of
60%, to activate the server farm when the number of inservice servers rises above
60%.
PodP-ACE/Lab-HM-PC(config)# serverfarm PRIMARY
PodP-ACE/Lab-HM-PC(config-sfarm-host)# partial-threshold 40
back-inservice 60
Step 6 Change the load-balancing policy with the backup server option. Also configure
aggregate-state to ensure that, when the backup server farm is still responding to
traffic, the virtual server will also respond.
PodP-ACE/Lab-HM-PC(config)# policy-map type loadbalance http
first-match slb6-logic
PodP-ACE/Lab-HM-PC(config-pmap-lb)# class class-default
PodP-ACE/Lab-HM-PC(config-pmap-lb-c)# no serverfarm servers6
PodP-ACE/Lab-HM-PC(config-pmap-lb-c)# serverfarm PRIMARY
backup BACKUP aggregate-state
Step 7 View the configured policy server.
PodP-ACE/Lab-HM-PC(config-pmap-lb-c)# do show run policy-map

class remote-access
permit

class class-default
serverfarm PRIMARY backup BACKUP aggregate-state

class VIP-60
Step 8 View the output from the show serverfarm PRIMARY detail command.
PRIMARY detail
serverfarm : primary, type: HOST
total rservers : 3
active rservers: 3
description : -
state : ACTIVE
predictor : ROUNDROBIN
failaction : -
back-inservice : 60
partial-threshold : 40
num times failover : 0
num times back inservice : 0
total conn-dropcount : 0
---------------------------------
----------
total
---+---------------------+------+------------+----------+--
------------------
rserver: dc6-lnx1
192.168.1.11:0 8 OPERATIONAL 0 0
0
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 : -
rserver: dc6-lnx2
192.168.1.12:0 8 OPERATIONAL 0 0
0
count : -
min-conns : -
count : -
count : -

rserver: dc6-lnx5
192.168.1.15:0 8 OPERATIONAL 0 5
1
count : -
min-conns : -
count : -
count : -

PodP-ACE/Lab-HM-PC(config-sfarm-host)#
Step 9 From the Client PC, generate multiple Telnet connections to the VIP at
172.16.PC.60 on port 80.
Step 10 View the server farm connections.
PodP-ACE/Lab-HM-PC(config-sfarm-host-rs)# do show serverfarm

serverfarm type rservers predictor current conns
+--------------------+---------+--------+------------------+---------------
BACKUP
HOST 2 ROUNDROBIN 0
PRIMARY
HOST 3 ROUNDROBIN 4
servers6
HOST 5 ROUNDROBIN 0
Step 11 In the PRIMARY server farm, take rserver dc6-lnx1 and rserver dc6-lnx2 out of
service.
Pod2-ACE/Lab-HM-PC(config)# rserver dc6-lnx1
Pod2-ACE/Lab-HM-PC(config-sfarm-host-rs)# rserver dc6-lnx2

Step 12 View the real servers.
PodP-ACE/Lab-HM-PC(config-sfarm-host-rs)# do show rserver

state : OUTOFSERVICE
---------------------------------
----------
total
---+---------------------+------+------------+----------+--
------------------
serverfarm: PRIMARY
192.168.1.11:0 8 OUTOFSERVICE 0 0
192.168.1.11:0 8 OPERATIONAL 0 0

state : OPERATIONAL
---------------------------------
----------
total
---+---------------------+------+------------+----------+--
------------------
serverfarm: PRIMARY
192.168.1.12:0 8 OUTOFSERVICE 2 2
192.168.1.12:0 8 OPERATIONAL 0 0

state : OPERATIONAL
---------------------------------
----------
total
---+---------------------+------+------------+----------+--
------------------
serverfarm: BACKUP
192.168.1.13:0 8 OPERATIONAL 0 0
192.168.1.13:0 8 OPERATIONAL 0 0

state : OPERATIONAL
---------------------------------
----------
total
---+---------------------+------+------------+----------+--
------------------
serverfarm: BACKUP
192.168.1.14:0 8 OPERATIONAL 0 0
192.168.1.14:0 8 OPERATIONAL 0 0

state : OPERATIONAL
---------------------------------
----------
total
---+---------------------+------+------------+----------+--
------------------
serverfarm: PRIMARY
192.168.1.15:0 8 OPERATIONAL 2 2
192.168.1.15:0 8 OPERATIONAL 0 0

PodP-ACE/Lab-HM-PC(config-sfarm-host-rs)#
Step 13 View the output of the show serverfarm command.

+--------------------+---------+--------+------------------+---------------
BACKUP
HOST 2 ROUNDROBIN 0
PRIMARY
HOST 3 ROUNDROBIN 0
servers6
HOST 5 ROUNDROBIN 0
Step 14 Generate multiple Telnet connections to the VIP at 172.16.PC.60 on port 80 and
view the output of the show serverfarm command.

+--------------------+---------+--------+------------------+---------------
BACKUP
HOST 2 ROUNDROBIN 4
PRIMARY
HOST 3 ROUNDROBIN 0
servers6
HOST 5 ROUNDROBIN 0
What can you determine from the output?
Step 15 Put rserver dc6-lnx2 in service.

Step 16 Generate multiple Telnet connections to the VIP at 172.16.21.60 on port 80 and
view the output of the show serverfarm command.

+--------------------+---------+--------+------------------+---------------
BACKUP
HOST 2 ROUNDROBIN 0
PRIMARY
HOST 3 ROUNDROBIN 3
servers6
HOST 5 ROUNDROBIN 0

What was the outcome after you put rserver dc6-lnx2 in service?
Demonstrated the partial server farm failover feature.
Used the partial-threshold percentage to fail over server farms when threshold is met.

The Cisco ACE Module 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 it can be reused in the remaining labs.
Activity Procedure
PodP-ACE/Lab-HM-PC# checkpoint rollback baseline-mgmt
Rollback succeeded
Answer Key: Implementing Network Address Translation
Lab 4 Answer Key for the End of Task 3

logging enable
logging monitor 0

login timeout 0


script file 31 HTTPCONTENT_PROBE

probe http GET-INDEX
interval 15
probe tcp L4-TCP
port 23
interval 5
connection term forced
probe https L5-SSL
interval 5

ip address 192.168.1.11
probe GET-INDEX
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
ip address 192.168.1.15
inservice

serverfarm host servers6
probe L4-TCP
rserver dc6-lnx1
inservice
rserver dc6-lnx2
inservice
rserver dc6-lnx3
inservice
rserver dc6-lnx4
inservice
rserver dc6-lnx5
probe L5-SSL
inservice


class remote-access
permit
policy-map type loadbalance first-match slb6-logic
class class-default
serverfarm servers3
class VIP-60

interface vlan 2PC
ip address 172.16.PC.6 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
Admin domain
default-domain
Lab 4 Answer Key for the End of Task 6
PodP-ACE/Lab-L7-PC# sho run

login timeout 0


ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
ip address 192.168.1.15
inservice

serverfarm host BACKUP
rserver dc6-lnx3
inservice
rserver dc6-lnx4
inservice
serverfarm host PRIMARY
partial-threshold 40 back-inservice 60
rserver dc6-lnx1
inservice
rserver dc6-lnx2
inservice
rserver dc6-lnx5
inservice
rserver dc6-lnx1
inservice
rserver dc6-lnx2
inservice
rserver dc6-lnx3
inservice
rserver dc6-lnx4
inservice
rserver dc6-lnx5
inservice


class remote-access
permit

class class-default
serverfarm PRIMARY backup BACKUP aggregate-state
--More--

class VIP-60

interface vlan 2PC
ip address 172.16.PC.6 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
Admin domain
default-domain
Lab 5: Configuring Layer 7 Load Balancing
Activity Objective
In a previous lab, you configured load balancing using Layers 3 and 4. In this exercise, you will
create new class maps and server farms to demonstrate URL load balancing (Layers 5-7). 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
Configure generic protocol parsing
Configure session persistence based on Layer 4 payload data
Visual Objective
Configuring Layer 7 Load Balancing
MSFC
Cisco ACE
C
a
t
a
l
y
s
t

6
5
0
0
Client
Servers
Traffic Class Map
Match VIP Connections
Default Class
Real
Server 1
Real
Server 2
Server Farm

Required Resources
Cisco ACE Module
Task 1: Configure a Real Server
In this task, you will add a configuration for a real server.
Activity Procedure
Step 2 Connect to the Cisco ACE management IP address for your Lab 4 context.
C:\> telnet 172.16.PC.7
Trying 172.16.PC.7...


Username: cisco
Password: cisco123
PodP-ACE/Lab-L7-PC#
Step 4 Use the checkpoint system to roll the configuration to the l7-slb7-begin checkpoint.
Step 6 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 two of the preconfigured rservers to the server farm. Be sure to inservice
the rservers. Failure to do so will cause the Cisco ACE Module to consider these
rserver out of service and the server farm will not be capable of receiving or
responding to client requests.
PodP-ACE/Lab-L7-PC(config-sfarm-host)# rserver dc7-lnx1
PodP-ACE/Lab-L7-PC(config-sfarm-host-rs)# inservice
PodP-ACE/Lab-L7-PC(config-sfarm-host)# rserver dc7-lnx2
PodP-ACE/Lab-L7-PC(config-sfarm-host-rs)# inservice
Step 8 Add the other three web servers to the server farm called NON-IE.
dc7-lnx3 192.168.1.13
dc7-lnx4 192.168.1.14
dc7-lnx5 192.168.1.15
Step 9 Display the newly configured rservers.
PodP-ACE/Lab-L7-PC(config-sfarm-host)# do show run serverfarm

serverfarm host IE-WEB
rserver dc7-lnx1
inservice
rserver dc7-lnx2
inservice
serverfarm host NON-IE
rserver dc7-lnx3
inservice
rserver dc7-lnx4
inservice
rserver dc7-lnx5
inservice
rserver dc7-lnx1
inservice
rserver dc7-lnx2
inservice
rserver dc7-lnx3
inservice
rserver dc7-lnx4
inservice
rserver dc7-lnx5
inservice
Note The Server VLAN was added during the configuration rollback.
Step 10 Use the show arp command to ensure that the Cisco ACE Module populates its
ARP table with the real servers MAC addresses.
PodP-ACE/Lab-L7-PC# show arp

You have completed this task when you have verified that the servers are marked as
OPERATIONAL in the new server farms.

Task 2: Configure Layer 7 Load Balancing
To send traffic to each of the server farms you just created (IE-WEB and NON-IE) based on the
contents of Layer 7 data, the Cisco ACE Module must be configured to match URL strings.
This will be accomplished with class maps (CHECK-HEADERS and OTHER-HTTP).
Activity Procedure
Step 1 Create a class map (Layer 3- 4) to distinguish traffic destined for a virtual IP from
traffic destined elsewhere. Use the IP address 172.16.PC.71.
PodP-ACE/Lab-L7-PC(config)# class-map VIP-71
PodP-ACE/Lab-L7-PC(config-cmap)# match virtual-address
172.16.PC.71 any
Step 2 Create another class map (Layer 5-7) to classify HTTP requests that come from IE
clients and contain a Host Header value.
PodP-ACE/Lab-L7-PC(config)# class-map type http loadbalance
CHECK-HEADERS
PodP-ACE/Lab-L7-PC(config-cmap-http-lb)# match http url .*
PodP-ACE/Lab-L7-PC(config-cmap-http-lb)# match http header
Host header-value 172.16.PC.*
PodP-ACE/Lab-L7-PC(config-cmap-http-lb)# match http header
User-Agent header-value .*MSIE.*
Step 3 Create a second class map (Layer 5-7) to classify HTTP requests.
PodP-ACE/Lab-L7-PC(config)# class-map type http loadbalance
OTHER-HTTP
PodP-ACE/Lab-L7-PC(config-cmap-http-lb)# match http url .*
Step 4 Display the new class map and verify the configuration.
PodP-ACE/Lab-L7-PC(config-cmap-http-lb)# do show run class-map

class-map type http loadbalance match-all CHECK-HEADERS
2 match http url .*
3 match http header Host header-value "172.16.PC.*"
4 match http header User-Agent header-value ".*MSIE.*"
class-map type http loadbalance match-all OTHER-HTTP
2 match http url .*
Step 5 Create a policy map of type loadbalance to handle requests destined to this VIP.
Remember that the Cisco ACE Module will attempt to match a defined class map at
Layers 5 through 7 in the order of occurrence as indicated by the keyword first-
match. The class-default map will handle non-matching client requests. Apply the
IE and NON-IE class maps and server farms respectively.
PodP-ACE/Lab-L7-PC(config)# policy-map type loadbalance first-
match L7-LOGIC
PodP-ACE/Lab-L7-PC(config-pmap-lb)# class CHECK-HEADERS
PodP-ACE/Lab-L7-PC(config-pmap-lb-c)# serverfarm IE-WEB
PodP-ACE/Lab-L7-PC(config-pmap-lb)# class OTHER-HTTP
PodP-ACE/Lab-L7-PC(config-pmap-lb-c)# serverfarm NON-IE
Step 6 Use the show run policy-map command to view the configuration additions.
PodP-ACE/Lab-L7-PC(config-pmap-lb-c)# do show run policy-map

class remote-access
permit
policy-map type loadbalance first-match L7-LOGIC
class CHECK-HEADERS
serverfarm IE-WEB
class OTHER-HTTP
serverfarm NON-IE
class class-default
serverfarm servers7
class VIP-70
Step 7 Add to the existing multimatch policy map. Recall that the multimatch policy map is
used to tie the VIP to the load-balancing action.
PodP-ACE/Lab-L7-PC(config)# policy-map multi-match client-vips
PodP-ACE/Lab-L7-PC(config-pmap)# class VIP-71
PodP-ACE/Lab-L7-PC(config-pmap-c)# loadbalance policy L7-LOGIC
PodP-ACE/Lab-L7-PC(config-pmap-c)# loadbalance vip inservice
PodP-ACE/Lab-L7-PC(config-pmap-c)# do show run policy-map

class remote-access
permit
class CHECK-HEADERS
serverfarm IE-WEB
class OTHER-HTTP
serverfarm NON-IE
class class-default
serverfarm servers7
class VIP-70
class VIP-71
loadbalance policy L7-LOGIC
Step 9 Verify that the VIP is applied and INSERVICE.
Note After a policy map of type multi-match is added to the service policy, any additions to the
policy map are immediately applied.
PodP-ACE/Lab-L7-PC# show service-policy client-vips

Status : ACTIVE
-----------------------------------------
Interface: vlan 2PC
class: VIP-70
loadbalance:
L7 loadbalance policy: slb7-logic
dropped conns : 0
64676
class: VIP-71
loadbalance:
L7 loadbalance policy: L7-LOGIC
VIP ICMP Reply : Disabled
dropped conns : 0
You have completed this task when you have verified that the service policy shows the newly
created VIP in the INSERVICE state.
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 ACE
context. You will verify that the VIP works as expected and that the client is being load-
balanced between real servers.
Activity Procedure
Step 1 On the client, use the Internet Explorer browser to verify that the Cisco ACE
Module is load-balancing traffic to the IE-WEB server farm.
http://172.16.PC.71/index.html
Step 2 Notice the service policy counters increment as connections are handled.
PodP-ACE/Lab-L7-PC# sho service-policy client-vips

Interface: vlan 2PC
class: VIP-71
loadbalance:
L7 policy: lb-logic, VIP state: INSERVICE
dropped conns : 0
Step 3 Now use Firefox to connect to the same site. Verify that the Cisco ACE Module is
now sending the client to the NON-IE server farm.
Step 4 Now use either browser to connect to the same VIP, but this time without specifying
a URL.
http://172.16.PC.71/
Successfully load-balanced an HTTP request to the VIP and verified that only the proper
servers are responding based on the client issuing the HTTP requests.
Developed an understanding of the .* match.
Task 4: Mixing Layer 4 and Layer 7 Traffic
In this task, you will modify the class maps to handle both Layer 4 traffic and Layers 5-7
traffic.
Activity Procedure
Step 1 Recall that the L7-LOGIC policy map is configured only with Layer 7 HTTP
matches.
PodP-ACE/Lab-L7-PC# show run policy-map

class CHECK-HEADERS
serverfarm IE-WEB
class OTHER-HTTP
serverfarm NON-IE
Step 2 Establish a Telnet session from the Client PC in the lab pod to the VIP.
telnet 172.16.PC.71
Step 3 Why did the connection fail? Notice that the service policy counters increment as
connections are handled.
PodP-ACE/Lab-L7-PC# sho service-policy client-vips

Status : ACTIVE
-----------------------------------------
Interface: vlan 2PC
class: VIP-70
loadbalance:
L7 policy: slb7-logic
dropped conns : 0
64676
class: VIP-71
loadbalance:
L7 policy: L7-LOGIC
dropped conns : 2
13845
167217
Step 4 You might think that the failure is due to the lack of a default class map, which
makes sense based solely on the configuration. Telnet is not HTTP, thus it cannot
match the existing Layer 7 class maps. However, there is a class-default provided for
handling traffic that does not match a Layer 7 class map. Apply this class-default.
match L7-LOGIC
PodP-ACE/Lab-L7-PC(config-pmap-lb)# class class-default
PodP-ACE/Lab-L7-PC(config-pmap-lb-c)# serverfarm servers7
Step 5 Non-HTTP traffic still is being parsed with the HTTP ME. To rectify the problem
and allow HTTP and non-HTTP traffic to access the VIP, you must create a new
policy map that does not perform HTTP parsing.
match NONL7-LB
PodP-ACE/Lab-L7-PC(config-pmap-lb-c)# serverfarm servers7
Step 6 If the new policy were to be directly applied to the multimatch policy, the class VIP-
71 would be used twice and the second one would never be used. Therefore, you
must create a new class map. In the majority of cases, you will know the ports on
which HTTP is allowed. In this lab scenario, you will use the default port. Rather
than creating a new class map for the NONL7-LB policy, create one for the more
specific L7-lb-logic policy.
PodP-ACE/Lab2-L7-PC(config)# class-map VIP-71-HTTP
PodP-ACE/Lab2-L7-PC(config-cmap)# match virtual-address
172.16.PC.71 tcp eq www
Step 7 Now all that is needed is to modify the multimatch policy map.
PodP-ACE/Lab2-L7-PC(config)# policy-map multi-match client-
vips
PodP-ACE/Lab2-L7-PC(config-pmap)# class VIP-71-HTTP
PodP-ACE/Lab2-L7-PC(config-pmap-c)# loadbalance policy L7-
LOGIC
PodP-ACE/Lab2-L7-PC(config-pmap-c)# loadbalance vip inservice
PodP-ACE/Lab2-L7-PC(config-pmap)# class VIP-71
PodP-ACE/Lab2-L7-PC(config-pmap-c)# loadbalance policy NONL7-
LB
Note You can have only one policy map defined per class map. Remove the old one first and then
try to add NONL7-LB. View the running configuration if you need help remembering the old
policy map.
PodP-ACE/Lab2-L7-PC(config-pmap-c)# loadbalance vip inservice
PodP-ACE/Lab2-L7-PC(config-pmap-c)# do show run policy-map

class remote-access
permit

class CHECK-HEADERS
serverfarm IE-WEB
class OTHER-HTTP
serverfarm NON-IE
class class-default
serverfarm servers7
policy-map type loadbalance first-match NONL7-LB
class class-default
serverfarm servers7
class class-default
serverfarm servers7

class VIP-70
class VIP-71
loadbalance policy NONL7-LB
class VIP-71-HTTP
Step 9 Again, from the client establish a Telnet connection to the VIP.
telnet 172.16.PC.71
Step 10 Double-check the load balancing using both the IE and Firefox web browsers. Why
are the HTTP policies being ignored?
Step 11 Display the service policy counters.
PodP-ACE/Lab-L7-PC(config-pmap-c)# do sh service-policy
client-vips
Status : ACTIVE
-----------------------------------------
Interface: vlan 225
class: VIP-70
loadbalance:
dropped conns : 0
class: VIP-71
loadbalance:
L7 loadbalance policy: NONL7-LB
dropped conns : 2
157294
1481306
class: VIP-71-HTTP
loadbalance:
L7 loadbalance policy: L7-LOGIC
dropped conns : 0
Step 12 Notice that the counters are not incrementing for the VIP-71-HTTP class. This is
because the VIP-71 class map matches connections to any port before VIP-71-HTTP
is even checked. You introduced this error when you added the VIP-71-HTTP class
map to the client-vips policy map. Modify the order of the class maps in the policy
map.
PodP-ACE/Lab-L7-PC(config-pmap)# no class VIP-71-HTTP
PodP-ACE/Lab-L7-PC(config-pmap)# do sh run policy-map

class remote-access
permit
class CHECK-HEADERS
serverfarm IE-WEB
class OTHER-HTTP
serverfarm NON-IE
class class-default
serverfarm servers7
class class-default
serverfarm servers7
class class-default
serverfarm servers7
class VIP-70
class VIP-71

PodP-ACE/Lab-L7-PC(config-pmap)# class VIP-71-HTTP insert-
before VIP-71
PodP-ACE/Lab-L7-PC(config-pmap-c)# loadbalance policy L7-LOGIC
PodP-ACE/Lab-L7-PC(config-pmap-c)# loadbalance vip ins
PodP-ACE/Lab-L7-PC(config-pmap-c)# do sh run policy-map

class remote-access
permit
class CHECK-HEADERS
serverfarm IE-WEB
class OTHER-HTTP
serverfarm NON-IE
class class-default
serverfarm servers7
class class-default
serverfarm servers7
class class-default
serverfarm servers7
class VIP-70
class VIP-71-HTTP
class VIP-71
Step 13 Verify that Telnet and the HTTP policies all work correctly.
Step 14 Display the service policy counters.
Successfully load balanced an HTTP request to the VIP and verified that only the proper
servers are responding based on the client issuing the HTTP requests.
Developed an understanding of the impact of HTTP parsing on a policy map.
Task 5: Optimize the Mixed-Traffic VIP
In this task, you will optimize the mixed-traffic VIP.
Activity Procedure
Step 1 Recall that the L7-LOGIC policy map will only match HTTP traffic.
PodP-ACE/Lab2-L7-PC(config-pmap-lb-c)# do show run policy-map

class remote-access
permit
class CHECK-HEADERS
serverfarm IE-WEB
class OTHER-HTTP
serverfarm NON-IE
class class-default
serverfarm servers7
class class-default
serverfarm servers7
class class-default
serverfarm servers7
class VIP-70
class VIP-71-HTTP
class VIP-71
Step 2 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. Therefore, 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.
PodP-ACE/Lab-L7-PC# sho resource usage resource regexp
Allocation
-----------------------------------------------------------------------------
Context: Lab-L7-PC
regexp 146 219 0 1048576 0

PodP-ACE/Lab-L7-PC(config)# policy-map type loadbalance first-match L7-LOGIC
PodP-ACE/Lab-L7-PC(config-pmap-lb)# no class OTHER-HTTP
PodP-ACE/Lab-L7-PC(config-pmap-lb-c)# serverfarm NON-IE

PodP-ACE/Lab-L7-PC(config-pmap-lb-c)# do sho resource usage resource regexp
Allocation
-----------------------------------------------------------------------------
Context: Lab-L7-PC
regexp 146 219 0 1048576 0

PodP-ACE/Lab-L7-PC(config-pmap-lb-c)# exit
PodP-ACE/Lab-L7-PC(config-pmap-lb)# exit
Step 3 Notice the current memory consumption has not decreased. Remove the unused
class map and view the memory usage.
PodP-ACE/Lab-L7-PC(config)# no class-map type http loadbalance OTHER-HTTP
PodP-ACE/Lab-L7-PC(config)# do sho resource usage resource regexp
Allocation
-----------------------------------------------------------------------------
Context: Lab-L7-PC
regexp 146 219 0 1048576 0
Why did the current memory used for the regular expression not decrement?
Step 4 To see the memory consumption change, add a new match to the existing class map
CHECK-HEADERS.
PodP-ACE/Lab-L7-PC(config)# class-map type http loadbalance CHECK-HEADERS
PodP-ACE/Lab-L7-PC(config-cmap-http-lb)# match http header Transfer-Encoding
header-value .*foo.*
PodP-ACE/Lab-L7-PC(config-cmap-http-lb)# do sho resource usage resource regexp
Allocation
-----------------------------------------------------------------------------
Context: Lab-L7-PC
regexp 196 219 0 1048576 0
Step 5 Remove the match to see the usage go down.
PodP-ACE/Lab-L7-PC(config-cmap-http-lb)# no match http header Transfer-
Encoding header-value .*foo.*
Allocation
-----------------------------------------------------------------------------
Context: Lab-L7-PC
regexp 196 219 0 1048576 0
Step 6 Wait between a minute or two, then display the usage again.
Allocation
-----------------------------------------------------------------------------
Context: Lab-L7-PC
regexp 146 219 0 1048576 0

Why is there a delay in the decrementing of the current memory used for the regular expression
after it was removed?

Task 6: Generic Layer 4 Content Parsing
To load-balance unsupported traffic types at Layer 7, the Cisco ACE Module must be
configured with the selected class maps and properties to classify the traffic correctly. Multiple
regular expressions strings will need to be configured in this exercise.
Activity Procedure
Step 1 Create a new class map VIP-72 with an IP address 172.16.PC.72 that matches any
traffic.
Step 2 Use the class-map type generic command to create a class map for generic protocol
parsing. The class map is considered a match if the match commands meet one of
the following conditions:
match-all: Traffic needs to satisfy all of the match criteria implicitly, and match
the class map. (Default)
match-any: Traffic needs to satisfy only one of the match criteria implicitly, or
match the load-balancing class map.
PodP-ACE/Lab-L7-PC(config)# class-map type generic match-any
L7-GENERIC
Step 3 Define the match criteria for Layer 4 payloads by using the match layer4-payload
command in class-map generic. Generic data parsing begins at Layer 4 with the
TCP or UDP payload, which allows you the flexibility to match Layer 5 data (in the
case of LDAP or DNS) or any Layer 7 header or payload (for example, HTTP). In
this use case, you will be matching a Telnet user string value. Note that the regex
expression specifies the Layer 4 payload expression that is contained within the TCP
or UDP entity body. Enter an unquoted text string with no spaces and a maximum of
255 alphanumeric characters for each pattern you configure. Alternately, you can
enter a text string with spaces provided that you enclose the entire string in quotation
marks ().
PodP-ACE/Lab-L7-PC(config-cmap-generic)# match layer4-payload
regex ".*login.*"
Note You cannot configure more than one match layer4-payload command in the same match-
all class map.
Step 4 Display the newly configured class map.
PodP-ACE/Lab-L7-PC(config-cmap-generic)# do show run class-map
class-map type generic match-any L7-GENERIC
2 match layer4-payload regex ".*login.*"

Step 5 Create a Layer 7 load-balancing policy map, and define the match statements and
policy actions. Associate the Layer 7 class map with a Layer 7 policy map. Also,
add the server farm to the policy.
PodP-ACE/Lab-L7-PC(config)# policy-map type loadbalance
generic first-match L7-POLICY
PodP-ACE/Lab-L7-PC(config-pmap-lb-generic)# class L7-GENERIC
PodP-ACE/Lab-L7-PC(config-pmap-lb-generic-c)# serverfarm
servers7
Step 6 Layer 7 policy maps are child policies. Therefore, you must now associate a Layer 7
policy map with the appropriate Layer 3-4 policy map to provide an entry point for
Layer 7 traffic classification. Edit the Layer 3-4 policy that distinguishes traffic for
the virtual IP address.
PodP-ACE/Lab-L7-PC(config-pmap-c)# loadbalance policy L7-
POLICY
PodP-ACE/Lab-L7-PC(config-pmap-c)# loadbalance vip icmp-reply
Step 7 Display the newly configured policy map.
PodP-ACE/Lab-L7-PC(config-pmap-c)# do show run policy-map

class remote-access
permit

class class-default
serverfarm servers7

policy-map type loadbalance generic first-match L7-POLICY
class L7-GENERIC
serverfarm servers7

class VIP-72
loadbalance policy L7-POLICY
loadbalance vip icmp-reply
Note By adding the load-balance vip icmp-reply, you can ping the VIP address to test network
connectivity.
Step 8 Test the configuration by using wget on the client to reach the URL
http://172.16.PC.72. The login string is the Layer 7 value that you want the Cisco
ACE Module to match. This could be any string value, dynamic or static. In this lab,
you will use a static string value.
C:\tools\wget-1.10.2b>wget --post-data 'login'/
http://172.16.PC.72
--08:56:17-- http://172.16.PC.72/
=> ìndex.html.105'
HTTP request sent, awaiting response...
Step 9 Review the service policy to determine why the connection is awaiting a response.
PodP-ACE/Lab-L7-PC(config-pmap-c)# do show service-policy
client-vips detail | beg VIP-72

Status : ACTIVE
Description: -
-----------------------------------------
Interface: vlan 2PC
class: VIP-72
loadbalance:
L7 loadbalance policy: L7-POLICY
VIP ICMP Reply : ENABLED
dropped conns : 0
max-conn-limit : 0 , drop-count : 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
L7 Loadbalance policy : L7-POLICY
class/match : L7-GENERIC
LB action :
hit count : 0
dropped conns : 0
Step 10 Note that the Cisco ACE Module did load-balance the request to the server farm.
Why is that? On the Client PC use Ethereal to sniff the client connection (using the
209.165.XXX.PC interface) to determine why the connection is failing. For
example, is the Cisco ACE Module sending back a reset? Did the full TCP
handshake get established?
Note There are currently three conditions in which the generic protocol parsing function finishes
parsing a TCP stream. These are: when the parser receives max parse length bytes; when
the parser receives FIN or RST; and when the regex state machine reaches a repeating or
stopping state. The Cisco ACE Module will send the final parse result as soon it hits the
regex string that has at least one matching Layer 7 policy, provided that the Cisco ACE
Module has parsed the configured min or max number of bytes. It is recommended to
configure a max or max parse length in the L7 parameter map.
Step 11 Configure a Layer 7 parameter map with a maximum parse length of the entire
conversation from the sniffer trace. You will obtain these values from following the
TCP stream.
PodP-ACE/Lab-L7-PC(config)# parameter-map type generic
PARSE_LEN
PodP-ACE/Lab-L7-PC(config-parammap-generi)# set max-parse-
length 177
Step 12 Add the Layer 7 parameter to the policy map. Use the appl-parameter generic
advanced-options command.
Pod-ACE/Lab-L7-PC(config)# policy-map multi-match client-vips
Pod-ACE/Lab-L7-PC(config-pmap)# class VIP-72
Pod-ACE/Lab-L7-PC(config-pmap-c)# appl-parameter generic
advanced-options PARSE_LEN
Step 13 Re-test the wget requeues to the VIP.
C:\tools\wget-1.10.2b>wget --post-data 'login'/
http://172.16.PC.72
--09:11:14-- http://172.16.PC.72/
=> ìndex.html.105'

100%[=========================================================
===================>] 1,080 6.94K/s

09:11:14 (6.90 KB/s) - ìndex.html.105' saved [1080/1080]
Step 14 Review the service policy to determine what happened.
PodP-ACE/Lab-L7-PC(config-pmap-c)# do show service-policy
client-vips detail

Status : ACTIVE
Description: -
-----------------------------------------
Interface: vlan 2PC
class: VIP-72
loadbalance:
L7 loadbalance policy: L7-POLICY
VIP ICMP Reply : ENABLED
dropped conns : 0
L7 Loadbalance policy : L7-POLICY
class/match : L7-GENERIC
LB action :
hit count : 2
dropped conns : 0
Step 15 Send multiple wget requests to the VIP and determine if the requests are getting
load-balanced. Review the output of the show serverfarm command to determine
the connections that are being load-balanced.
Note To make it easier to view the load balancing, you can clear the counters for server farm with
the clear serverfarm command.
PodP-ACE/Lab-L7-PC(config-pmap-c)# do show serverfarm servers7
serverfarm : servers7, type: HOST
total rservers : 5
---------------------------------
----------connections---------
--
real weight state current total
failures
---+---------------------+------+------------+----------+-----------+------
--
rserver: dc7-lnx1
192.168.1.11:0 8 OPERATIONAL 0 4 5
rserver: dc7-lnx2
192.168.1.12:0 8 OPERATIONAL 0 4 2
rserver: dc7-lnx3
192.168.1.13:0 8 OPERATIONAL 0 4 0
rserver: dc7-lnx4
192.168.1.14:0 8 OPERATIONAL 0 2 1
rserver: dc7-lnx5
192.168.1.15:0 8 OPERATIONAL 0 2 2
Verified that connections are load-balanced across the five servers.
Gained a better understanding of generic protocol parsing.
Task 7: Layer 4 Payload Stickiness
Before you begin to configure a Layer 4 payload sticky group, be sure that you have allocated
resources to the sticky group. That is done in the Admin context. Layer 4 payload stickiness
will allow you to configure the Cisco ACE Module to stick a specific value to a server. An
example could be a user ID. In this example, we use a custom string value sent by a wget
request.
Activity Procedure
Step 1 In another window, establish a Telnet connection to 172.19.110.19 (the Admin
context on the Cisco ACE Module) using admin and admin for the username and
password.
Pod1-ACE login: admin
Password: admin
reserved.
license.
Pod1-ACE/Admin#
Step 2 Make your lab context a member of the cart resource class.
Pod1-ACE/Admin(config)# context Lab-L7-PC
Pod1-ACE/Admin(config-context)# member ?
cart sticky
avs default
Pod1-ACE/Admin(config-context)# member cart

Pod1-ACE/Admin# show context Lab-L7-PC

Name: Lab-L7-PC , Id: 50
Config count: 205
Description:
Resource-class: cart
Vlans: Vlan2PC, Vlan4PC
FT Auto-sync running-cfg configured state: enabled
FT Auto-sync running-cfg actual state: disabled
FT Auto-sync startup-cfg configured state: enabled
FT Auto-sync startup-cfg actual state: disabled
Step 3 Remove the generic Layer 4 load-balancing configuration from the last task.
Pod1-ACE/Lab-L7-PC(config)# policy-map type loadbalance
Pod1-ACE/Lab-L7-PC(config-pmap-lb-generic)# no class L7-
GENERIC
Pod1-ACE/Lab-L7-PC(config)# no class-map type generic match-
any L7-GENERIC
Step 4 Create an HTTP-content sticky group and associate a server farm with the sticky
group for sticky connections.
PodP-ACE/Lab-L7-PC(config)# sticky layer4-payload PAYLOAD
PodP-ACE/Lab-L7-PC(config-sticky-l4payloa)# serverfarm
servers7
Step 5 Configure a sticky timeout. The sticky timeout specifies the period of time (in
minutes) that the Cisco ACE Module keeps the Layer 4 payload sticky information
for a client connection in the sticky table after the latest client connection terminates.
The Cisco ACE Module resets the sticky timer for a specific sticky-table entry each
time that the Cisco ACE Module opens a new connection matching that entry.
PodP-ACE/Lab-L7-PC(config-sticky-l4payloa)# timeout 2
Step 6 Enable a Layer 4 payload timeout to override active connections. This specifies that
the Cisco ACE Module times out Layer 4 payload sticky table entries, even if active
connections exist after the sticky timer expires.
PodP-ACE/Lab-L7-PC(config-sticky-l4payloa)# timeout
activeconns
Step 7 Configure Layer 4 payload sticky parameters. A Layer 4 payload can change over
time with only a portion remaining constant throughout a transaction between the
client and a server. You can configure the Cisco ACE Module to use the constant
portion of a payload to make persistent connections to a specific server. To define
the portion of the payload that you want the Cisco ACE Module to use, you specify
payload offset and length values. The Cisco ACE Module stores these values in the
sticky table. You can also specify a beginning and end pattern based on a regular
expression that the Cisco ACE Module uses to stick a client to a particular server.
begin-pattern: Specifies the beginning pattern of the URL and the pattern string
to match before hashing. You cannot configure different beginning and ending
patterns for different server farms that are part of the same traffic classification.
Enter an unquoted text string with no spaces and a maximum of 255
alphanumeric characters for each pattern you configure.
end-pattern: Specifies the pattern that marks the end of hashing. If you want to
match a URL that contains spaces, you must use \x20 (without the quotation
marks) for each space character.
PodP-ACE/Lab-L7-PC(config-sticky-l4payloa)# layer4-payload
begin-pattern username: end-pattern \x20
Step 8 Display the newly configured sticky group.
PodP-ACE/Lab-L7-PC(config-sticky-l4payloa)# do show run sticky

sticky layer4-payload PAYLOAD
timeout 20
timeout activeconns
serverfarm servers7
layer4-payload begin-pattern username: end-pattern \x20
Step 9 Configure a Layer 7 load-balanced traffic policy and associate the sticky group with
the Layer 7 policy map. Add the default class map with the sticky server farm to the
policy.
PodP-ACE/Lab-L7-PC(config)# policy-map type loadbalance
PodP-ACE/Lab-L7-PC(config-pmap-lb-generic)# class class-
default
PodP-ACE/Lab-L7-PC(config-pmap-lb-generic-c)# sticky-
serverfarm PAYLOAD
Step 10 Configure a Layer 3 and Layer 4 load-balancing traffic policy and add the traffic
policies for server load balancing. In this lab, you can use the configured policy map
client-VIPs. However you will need to remove the current load-balancing policy and
add the generic load-balancing policy that you just created.
PodP-ACE/Lab-L7-PC(config-pmap-c)# loadbalance policy L7-
POLICY
PodP-ACE/Lab-L7-PC(config-pmap-c)# loadbalance vip icmp-reply
Step 11 Display the newly configured policy maps.
PodP-ACE/Lab-L7-PC(config-pmap-lb-generic-c)# do show run
policy-map

class remote-access
permit

class class-default
serverfarm servers7

policy-map type loadbalance generic first-match L7-Policy
class class-default
sticky-serverfarm PAYLOAD

class VIP-72
loadbalance policy L7-Policy
Step 12 Before sending any traffic, you need to reconfigure the maximum or minimum parse
length. Configure a Layer 7 parameter map with a max parse length of the entire
conversation from the sniffer trace. You will obtain these values from following the
TCP stream.
PodP-ACE/Lab-L7-PC(config-pmap-c)# parameter-map type generic
PARSE_LEN
PodP-ACE/Lab-L7-PC(config-parammap-generi)# set max-parse-
length 189
Step 13 Add the Layer 7 parameter to the policy map. Use the appl-parameter generic
advanced-options command.
PodP-ACE/Lab-L7-PC(config-parammap-generi)# policy-map multi-
match client-vips
PodP-ACE/Lab-L7-PC(config-pmap-c)# appl-parameter generic
advanced-options PARSE_LEN
Step 14 Test the configuration by using the wget tool on the client to reach the URL
http://172.16.PC.72/. In the data of the wget request you specify the username:string
value. In this example you will use the string michael.
C:\tools\wget-1.10.2b>wget --post-data 'username:michael'/
http://172.16.PC.72
--18:58:32-- http://172.16.PC.72/
=> ìndex.html.222'

100%[=========================================================
===================>] 1,080

18:58:32 (10.11 KB/s) - ìndex.html.222' saved [1080/1080]
Step 15 Verify that the connection got stuck to an rserver. First, check the sticky database.
PodP-ACE/Lab-L7-PC(config-pmap-lb-generic-c)# do show sticky
database
sticky group : PAYLOAD
type : LAYER4-PAYLOAD
timeout : 2 timeout-activeconns : FALSE
sticky-entry rserver-instance time-
to-expire flags
---------------------+--------------------------------+-----
---------+-------+ 7981647108477075273 dc21-lnx1:0
120 -
Step 16 Verify that the connection got stuck to rserver dc21-lnx1.
PodP-ACE/Lab-L7-PC(config-pmap-lb-generic-c)# do show serverfarm servers7
total rservers : 5
---------------------------------
----------connections---------
--
---+---------------------+------+------------+----------+------------------
--
rserver: dc21-lnx1
192.168.1.11:0 8 OPERATIONAL 0 1
rserver: dc21-lnx2
192.168.1.12:0 8 OPERATIONAL 0 0
rserver: dc21-lnx3
192.168.1.13:0 8 OPERATIONAL 0 0
rserver: dc21-lnx4
192.168.1.14:0 8 OPERATIONAL 0 0
rserver: dc21-lnx5
192.168.1.15:0 8 OPERATIONAL 0 0
Step 17 Using wget, generate multiple connections with the same data string value. Check to
see if the connection got load-balanced to the same server.
PodP-ACE/Lab-L7-PC(config-pmap-lb-generic-c)# do show serverfarm servers7
total rservers : 5
---------------------------------
----------connections---------
--
---+---------------------+------+------------+----------+------------------
--
rserver: dc21-lnx1
192.168.1.11:0 8 OPERATIONAL 0 20
rserver: dc21-lnx2
192.168.1.12:0 8 OPERATIONAL 0 0
rserver: dc21-lnx3
192.168.1.13:0 8 OPERATIONAL 0 0
rserver: dc21-lnx4
192.168.1.14:0 8 OPERATIONAL 0 0
rserver: dc21-lnx5
192.168.1.15:0 8 OPERATIONAL 0 0
Step 18 Check the sticky database to see how many sticky entries you have.
PodP-ACE/Lab-L7-PC(config-pmap-lb-generic-c)# do show sticky database
sticky group : PAYLOAD
type : LAYER4-PAYLOAD
sticky-entry rserver-instance time-to-expire flags
---------------------+--------------------------------+--------------+------
-+
7981647108477075273 dc21-lnx1:0 120 -
Verified the connections getting stuck to one server.
Confirmed that the sticky database contains an entry that corresponds to the correct rserver.
Activity Procedure
PodP-ACE/Lab-L7-PC# checkpoint rollback baseline-mgmt
Rollback succeeded

Answer Key: Configuring Layer 7 Load Balancing
Initial Configuration Sample

login timeout 0


ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
ip address 192.168.1.15
inservice

rserver dc7-lnx1
inservice
rserver dc7-lnx2
inservice
rserver dc7-lnx3
inservice
rserver dc7-lnx4
inservice
rserver dc7-lnx5
inservice


class remote-access
permit
class class-default
serverfarm servers7
class VIP-70

interface vlan 2PC
ip address 172.16.PC.12 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
Admin domain
default-domain

Configuration Sample After Task 2 When Layer 7 SLB is Working

login timeout 0


ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
ip address 192.168.1.15
inservice

rserver dc7-lnx1
inservice
rserver dc7-lnx2
inservice
rserver dc7-lnx3
inservice
rserver dc7-lnx4
inservice
rserver dc7-lnx5
inservice
rserver dc7-lnx1
inservice
rserver dc7-lnx2
inservice
rserver dc7-lnx3
inservice
rserver dc7-lnx4
inservice
rserver dc7-lnx5
inservice

2 match http url .*
2 match http url .*

class remote-access
permit
class CHECK-HEADERS
serverfarm IE-WEB
class OTHER-HTTP
serverfarm NON-IE
class class-default
serverfarm servers7
class VIP-70
class VIP-71

interface vlan 2PC
ip address 172.16.PC.12 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
Admin domain
default-domain

Configuration Sample After Task 3 When a Mix of Layer 4 and Layer 7 SLB is
Working

login timeout 0


ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
ip address 192.168.1.15
inservice

rserver dc7-lnx1
inservice
rserver dc7-lnx2
inservice
rserver dc7-lnx3
inservice
rserver dc7-lnx4
inservice
rserver dc7-lnx5
inservice
rserver dc7-lnx1
inservice
rserver dc7-lnx2
inservice
rserver dc7-lnx3
inservice
rserver dc7-lnx4
inservice
rserver dc7-lnx5
inservice

2 match http url .*
class-map match-all VIP-71-HTTP
2 match virtual-address 172.16.PC.71 tcp eq www
2 match http url .*

class remote-access
permit
class CHECK-HEADERS
serverfarm IE-WEB
class OTHER-HTTP
serverfarm NON-IE
class class-default
serverfarm servers7
class class-default
serverfarm servers7
class class-default
serverfarm servers7
class VIP-70
class VIP-71-HTTP
class VIP-71

interface vlan 2PC
ip address 172.16.PC.12 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
Admin domain
default-domain

Configuration Sample After Task 4 When the Mixed Traffic Configuration Has Been
Optimized

login timeout 0


ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
ip address 192.168.1.15
inservice

rserver dc7-lnx1
inservice
rserver dc7-lnx2
inservice
rserver dc7-lnx3
inservice
rserver dc7-lnx4
inservice
rserver dc7-lnx5
inservice
rserver dc7-lnx1
inservice
rserver dc7-lnx2
inservice
rserver dc7-lnx3
inservice
rserver dc7-lnx4
inservice
rserver dc7-lnx5
inservice
2 match http url .*

class remote-access
permit
class CHECK-HEADERS
serverfarm IE-WEB
class class-default
serverfarm NON-IE
class class-default
serverfarm servers7
class class-default
serverfarm servers7
class VIP-70
class VIP-71-HTTP
class VIP-71

interface vlan 2PC
ip address 172.16.PC.12 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
Admin domain
default-domain

Configuration Sample After Task 6 When Layer 4 Content Parsing is Working
PodP-ACE/Lab-L7-PC# sh run

login timeout 0


parameter-map type generic PARSE_LEN
set max-parse-length 177

ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
ip address 192.168.1.15
inservice

rserver dc7-lnx1
inservice
rserver dc7-lnx2
inservice
rserver dc7-lnx3
inservice
rserver dc7-lnx4
inservice
rserver dc7-lnx5
inservice
rserver dc7-lnx1
inservice
rserver dc7-lnx2
inservice
rserver dc7-lnx3
inservice
rserver dc7-lnx4
inservice
rserver dc7-lnx5
inservice

2 match http url .*

class-map type generic match-any L7-GENERIC
2 match layer4-payload regex ".*login.*"






class remote-access
permit

policy-map type loadbalance http first-match L7-LOGIC
class CHECK-HEADERS
serverfarm IE-WEB
class class-default
serverfarm servers7
policy-map type loadbalance http first-match NONL7-LB
class class-default
serverfarm servers7
class class-default
serverfarm servers7

class L7-GENERIC
serverfarm servers7

class VIP-70
class VIP-71-HTTP
class VIP-71
class VIP-72
appl-parameter generic advanced-options PARSE_LEN

interface vlan 2PC
ip address 172.16.PC.7 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
Admin domain
default-domain

Configuration Sample After Task 7 When Layer 4 Payload Stickiness is Working
PodP-ACE/Lab-L7-PC# sh run

login timeout 0


parameter-map type generic PARSE_LEN
set max-parse-length 189

ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
ip address 192.168.1.15
inservice

rserver dc7-lnx1
inservice
rserver dc7-lnx2
inservice
rserver dc7-lnx3
inservice
rserver dc7-lnx4
inservice
rserver dc7-lnx5
inservice
rserver dc7-lnx1
inservice
rserver dc7-lnx2
inservice
rserver dc7-lnx3
inservice
rserver dc7-lnx4
inservice
rserver dc7-lnx5
inservice

sticky layer4-payload PAYLOAD
timeout 2
timeout activeconns
serverfarm servers7
layer4-payload begin-pattern "username:" end-pattern "\x20"

2 match http url .*

class remote-access
permit

policy-map type loadbalance http first-match L7-LOGIC
class CHECK-HEADERS
serverfarm IE-WEB
class class-default
serverfarm servers7
policy-map type loadbalance http first-match NONL7-LB
class class-default
serverfarm servers7
class class-default
serverfarm servers7

class class-default
sticky-serverfarm PAYLOAD

class VIP-70
class VIP-71-HTTP
class VIP-71
class VIP-72
appl-parameter generic advanced-options PARSE_LEN

interface vlan 2PC
ip address 172.16.PC.7 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
Admin domain
default-domain

Lab 6: Enabling Sticky Connections
Activity Objective
In this lab, you will configure an ACE context to match VIP-destined traffic and load-balance
these flows to the real servers on a private network behind the your 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 rservers is selected to respond to
the client request. The configuration should cause the client connection to persist with the same
rserver for the duration of the client session. To allow client traffic into the 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
Visual Objective
Enabling Sticky Connections
MSFC Cisco ACE
Catalyst 6500
Servers
1. Browse
2. Select
3. Buy
1 2 3

Required Resources
Cisco ACE Module
Task 1: Create a Server Farm
In this task, you will define real server containers and server farms.
Activity Procedure
C:\> telnet 172.16.PC.19
Trying 172.16.PC.19...

Username: cisco
Password: cisco123
PodP-ACE/Lab-Cart-PC#
Step 4 Use the checkpoint system to roll the configuration to the start-cart checkpoint.
Step 6 Configure a server farm called WEB-FARM with three servers called LINUX-1,
LINUX-2, LINUX-3 at IP addresses of 192.168.1.11, 192.168.1.12 and
192.168.1.13 respectively.
rserver host LINUX-1
ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice

serverfarm host WEB-FARM
rserver LINUX-1
inservice
rserver LINUX-2
inservice
rserver LINUX-3
inservice
Created the rservers
Created the server farm
Ensured that they are both operational
Task 2: Apply Source IP Sticky to Ensure Client Persistence
In this task, you will apply source IP sticky to ensure client persistence.
Activity Procedure
Step 1 Create a sticky group named STICKY-GRP.
PodP-ACE/Lab-Cart-PC(config)# sticky ip-netmask
255.255.255.255 address source STICKY-GRP
Step 2 Specify a timeout of 1 minute.
PodP-ACE/Lab-Cart-PC(config-sticky-ip)# timeout 1
Step 3 Specify the server farm to be used for this sticky group.
PodP-ACE/Lab-Cart-PC(config-sticky-ip)# serverfarm WEB-FARM
PodP-ACE/Lab-Cart-PC(config-sticky-ip)# exit
Step 4 The sticky group is applied within a policy map of type loadbalance.
PodP-ACE/Lab-Cart-PC(config)# policy-map type loadbalance
first-match WEB-POLICY
PodP-ACE/Lab-Cart-PC(config-pmap-lb)# class class-default
PodP-ACE/Lab-Cart-PC(config-pmap-lb-c)# sticky-serverfarm
STICKY-GRP
Step 5 Create a VIP on interface VLAN 2PC and load-balance with this sticky group.
PodP-ACE/Lab-Cart-PC(config)# class-map STICKY-VIP
PodP-ACE/Lab-Cart-PC(config-cmap)# match virtual-address
172.16.PC.50 any
PodP-ACE/Lab-Cart-PC(config-cmap)# exit
PodP-ACE/Lab-Cart-PC(config)# policy-map multi-match VIPS
PodP-ACE/Lab-Cart-PC(config-pmap)# class STICKY-VIP
PodP-ACE/Lab-Cart-PC(config-pmap-c)# loadbalance vip inservice
PodP-ACE/Lab-Cart-PC(config-pmap-c)# loadbalance policy WEB-
POLICY
PodP-ACE/Lab-Cart-PC(config-pmap-c)# exit
PodP-ACE/Lab-Cart-PC(config-pmap)# exit
PodP-ACE/Lab-Cart-PC(config)# int vlan2PC
PodP-ACE/Lab-Cart-PC(config-if)# service-policy input VIPS
PodP-ACE/Lab-Cart-PC(config-if)# exit
Step 6 Allow any traffic in to all interfaces using the everyone access list.
PodP-ACE/Lab-Cart-PC(config)# access-group input everyone
PodP-ACE/Lab-Cart-PC(config)# exit
Step 7 Use the client web browser to access http://172.16.PC.50.
Step 8 View the sticky tables on the Cisco ACE Module.
PodP-ACE/Lab-Cart-PC# show sticky database
sticky group : STICKY-GRP
type : IP
to-expire flags
---------------------+--------------------------------+-------
-------+-------+
3517303317 LINUX-1:0 53
-
Successfully connected to the rserver from the Client PC.
Connected to a separate rserver after the sticky timer expired.
Activity Procedure
PodP-ACE/Lab-Cart-PC# checkpoint rollback baseline-mgmt
Rollback succeeded
Answer Key: Enabling Sticky Connections
PodP-ACE/Lab-Cart-PC# sho run

login timeout 0

access-list everyone line 10 extended permit ip any any

ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice

rserver LINUX-1
inservice
rserver LINUX-2
inservice
rserver LINUX-3
inservice

sticky ip-netmask 255.255.255.255 address source STICKY-GRP
timeout 1
serverfarm WEB-FARM

class-map match-all STICKY-VIP
5 match protocol http any

class remote-access
permit
policy-map type loadbalance first-match WEB-POLICY
class class-default
sticky-serverfarm STICKY-GRP
policy-map multi-match VIPS
class STICKY-VIP
loadbalance policy WEB-POLICY
access-group input everyone

interface vlan 2PC
ip address 172.16.PC.19 255.255.255.0
service-policy input VIPS
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
Lab 7: Enabling Protocol Inspection
Activity Objective
In this exercise, you will implement protocol fixups and inspection for FTP. After completing
this exercise, you will be able to meet these objectives:
Implement fixups for FTP
Implement FTP inspection (Strict FTP)
Visual Objective
Enabling Protocol Inspection
MSFC
Catalyst 6500
Server
Cisco ACE

Required Resources
Cisco ACE Module

Task 1: Configure a Protocol Fixup
The Cisco ACE Module uses FTP inspection to enable FTP fixups. This must be used to allow
the Cisco ACE Module to load-balance FTP sessions.
Activity Procedure
C:\> telnet 172.16.PC.9
Trying 172.16.PC.9...

Username: cisco
Password: cisco123
PodP-ACE/Lab-Fixups-PC#
Step 4 Use the checkpoint system to roll the configuration to the ftp-begin checkpoint.
Step 6 Start by creating a class map (VIP-91-FTP) to distinguish traffic destined for a
virtual IP from traffic destined elsewhere. Use the IP address 172.16.PC.91.
PodP-ACE/Lab-Fixups-PC(config)# class-map VIP-91-FTP
PodP-ACE/Lab-Fixups-PC(config-cmap)# match virtual-address
172.16.PC.91 tcp eq any
Step 7 Create a server farm for the FTP servers called FTP-APP and add rserver dc9-lnx4
and dc9-lnx5. Then, create the load-balancing policy map for FTP.
PodP-ACE/Lab-Fixups-PC(config)# policy-map type loadbalance
first-match FTP-LB
PodP-ACE/Lab-Fixups-PC(config-pmap-lb)# class class-default
PodP-ACE/Lab-Fixups-PC(config-pmap-lb-c)# serverfarm FTP-APP
Step 8 Modify the multimatch policy to include the FTP VIP and load-balancing policy.
PodP-ACE/Lab-Fixups-PC(config)# policy-map multi-match client-
vips
PodP-ACE/Lab-Fixups-PC(config-pmap)# class VIP-91-FTP
PodP-ACE/Lab-Fixups-PC(config-pmap-c)# loadbalance policy FTP-
LB
PodP-ACE/Lab-Fixups-PC(config-pmap-c)# loadbalance vip ins
Step 9 Using the Client PC, 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.91
Connected to 172.16.PC.91.
220 (vsFTPd 2.0.1)
User (172.16.PC.91:(none)): cisco
331 Please specify the password.
Password: cisco
The FTP connection was successful, so why did the directory listing and file transfer 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.
PodP-ACE/Lab-Fixups-PC(config-pmap-c)# inspect ftp
Step 11 Try the FTP connection from the client again. Use the show service command to see
the counters. Notice now there are FTP inspection counters.
PodP-ACE/Lab-Fixups-PC# sho service-policy client-vips

Status : ACTIVE
-----------------------------------------
Interface: vlan 2PC
class: VIP-91-FTP
loadbalance:
L7 policy: FTP-LB
dropped conns : 0
inspect ftp:
strict ftp: DISABLED
dropped conns : 0
class: VIP-90
loadbalance:
L7 policy: slb9-logic
dropped conns : 0
Load-balanced FTP connections (Use the show serverfarm command to verify this.)
Task 2: Configure FTP
The Cisco ACE Module uses the keyword ftp in Layer 7 class maps to perform FTP request
inspection for FTP sessions, which allows you to restrict specific commands by the Cisco ACE
Module. This function provides a security feature to prevent web browsers from sending
embedded commands to the Cisco ACE Module in FTP requests. Each specified FTP command
must be acknowledged before the Cisco ACE Module 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
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 dc9-lnx2.
Step 2 Create a new class map VIP-92-STRICT to handle strict FTP sessions. Use the
virtual IP address 172.16.PC.92 and restrict the match to the FTP port.
Step 3 Create a new load-balancing policy called STRICT. Send all traffic to the server
farm STRICT-FTP-APP.
Step 4 Now define the strict FTP matching. This is done in a class map, because the Cisco
ACE Module is classifying FTP requests as they are received from the client. Create
a class map called NO-PUTS and define a match for put,
PodP-ACE/Lab-Fixups-PC(config)# class-map type ftp inspect
match-any NO-PUTS
PodP-ACE/Lab-Fixups-PC(config-cmap-ftp-insp)# match request-
method put
Step 5 Use the show class-map command to view the configuration additions.
PodP-ACE/Lab-Fixups-PC(config-cmap-ftp-insp)# do show run
class-map

class-map match-all VIP-91-FTP
class-map match-all VIP-92-STRICT
2 match virtual-address 172.16.PC.92 tcp eq ftp
class-map type ftp inspect match-any NO-PUTS
2 match request-method put
Step 6 A new policy type is now needed: the inspect policy type is used by strict FTP to
apply the previously created class map. Any traffic matching the class map NO-
PUTS will be denied. Create a policy map called FTP-INSPECT-POLICY.
PodP-ACE/Lab-Fixups-PC(config)# policy-map type inspect ftp
first-match FTP-INSPECT-POLICY
PodP-ACE/Lab-Fixups-PC(config-pmap-ftp-ins)# class NO-PUTS
PodP-ACE/Lab-Fixups-PC(config-pmap-ftp-ins-c)# deny
Step 7 Finish the strict FTP configuration by updating the multimatch policy map.
PodP-ACE/Lab-Fixups-PC(config)# policy-map multi-match client-
vips
PodP-ACE/Lab-Fixups-PC(config-pmap)# class VIP-92-STRICT
PodP-ACE/Lab-Fixups-PC(config-pmap-c)# loadbalance vip
inservice
PodP-ACE/Lab-Fixups-PC(config-pmap-c)# loadbalance policy
STRICT
PodP-ACE/Lab-Fixups-PC(config-pmap-c)# inspect ftp strict
policy FTP-INSPECT-POLICY
Step 8 Display the policy map.
PodP-ACE/Lab-Fixups-PC(config-pmap-c)# do show run policy-map

class remote-access
permit
policy-map type loadbalance first-match FTP-LB
class class-default
serverfarm FTP-APP
class class-default
serverfarm servers9
policy-map type loadbalance first-match STRICT
class class-default
serverfarm STRICT-FTP-APP
policy-map type inspect ftp first-match FTP-INSPECT-POLICY
class NO-PUTS
deny
class VIP-91-FTP
loadbalance policy FTP-LB
inspect ftp
class VIP-90
class VIP-92-STRICT
loadbalance policy STRICT
inspect ftp strict policy FTP-INSPECT-POLICY

Step 9 Test the FTP configuration. Open a command line window on the client and ftp to
the new vip class map you created (172.16.PC.92). The ftp username and password
are cisco and cisco. Display a list of the files on the server.
C:\Documents and Settings\Administrator>ftp 172.16.PC.92
Connected to 172.16.PC.92.
220 (vsFTPd 2.0.1)
User (172.16.PC.92:(none)): cisco
331 Please specify the password.
Password: cisco
230 Login successful.
ftp> dir
200 PORT command successful. Consider using PASV.
190 Here comes the directory listing.
-rw-r--r-- 1 0 0 2124906 Oct 09 2005
UltraVnc-101-src.zip
-rw-r--r-- 1 0 0 1113 Oct 09 2005
anaconda-ks.cfg
drwxr-xr-x 7 0 0 7096 Nov 08 01:25
htmldata
-rw-r--r-- 1 0 0 1913993 Nov 08 01:23
htmldata.zip
-rw-r--r-- 1 0 0 48180 Oct 09 2005
install.log
-rw-r--r-- 1 0 0 3653 Oct 09 2005
install.log.syslog
-rw-r--r-- 1 0 0 1607137 Oct 09 2005 vnc-
4_1_1-1[1].i386.rpm
-rw-r--r-- 1 0 0 1607137 Oct 09 2005
vnc.rpm
-rw-r--r-- 1 0 0 3317760 Nov 08 02:02 vtlab-
data.tar
226 Directory send OK.
ftp: 690 bytes received in 0.09Seconds 6.99Kbytes/sec.
Step 10 Look at the files in your current working directory with the !dir command.
ftp> !dir
Volume in drive C has no label.
Volume Serial Number is 08F8-DB81

Directory of C:\Documents and Settings\Administrator

04/06/2006 03:29a <DIR> .
04/06/2006 03:29a <DIR> ..
04/06/2006 03:29a 49 .asadminprefs
04/06/2006 03:29a 757 .asadmintruststore
04/06/2006 03:19a <DIR> Desktop
09/23/2004 12:35p <DIR> Favorites
09/23/2004 04:22a <DIR> My Documents
09/23/2004 04:22a <DIR> Start Menu
2 File(s) 806 bytes
6 Dir(s) 17,946,099,712 bytes free
Step 11 Test the strict FTP functionality by issuing a PUT of an existing file in your working
directory.
ftp> put .asadminprefs
200 PORT command successful. Consider using PASV.
Connection closed by remote host.
ftp>
Step 12 Examine the output of the following show commands.
PodP-ACE/Lab-Fixups-PC# show service-policy client-vips detail

<output removed>

class: VIP-92-STRICT
loadbalance:
L7 policy: STRICT
dropped conns : 0
inspect ftp:
strict ftp: ENABLED
dropped conns : 0
L7 policy: FTP-INSPECT-POLICY
TotalReplyMasked : 0 TotalDropped: 1
You have completed this task when you have used the FTP inspection feature of the Cisco ACE
Module to prevent FTP PUTs to a FTP server.
Activity Procedure
PodP-ACE/Lab-Fixups-PC# checkpoint rollback baseline-mgmt
Rollback succeeded

Answer Key: Enabling Protocol Inspection
Working FTP Configuration Sample
PodP-ACE/Lab-Fixups-PC# show checkpoint detail ftp-end

login timeout 0


probe http get-index
interval 15

ip address 192.168.1.11
probe get-index
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
ip address 192.168.1.15
inservice

serverfarm host FTP-APP
rserver dc9-lnx4
inservice
rserver dc9-lnx5
inservice
rserver dc9-lnx1
inservice
rserver dc9-lnx2
inservice
rserver dc9-lnx3
inservice
rserver dc9-lnx4
inservice
rserver dc9-lnx5
inservice


class remote-access
permit
class class-default
serverfarm FTP-APP
class class-default
serverfarm servers9
class VIP-91-FTP
inspect ftp
class VIP-90

interface vlan 291
ip address 172.16.PC.13 255.255.255.0
no shutdown
interface vlan 491
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
username cisco password 5 $1$1WMrkvAT$wKQ1z8XC0XvTY0Fpv55QN0 role
Admin domain
default-domain

Working Strict FTP Configuration Sample
Pod5-ACE/Lab-Fixups-91# show checkpoint detail ftp-strict

login timeout 0


probe http get-index
interval 15

ip address 192.168.1.11
probe get-index
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
ip address 192.168.1.15
inservice

serverfarm host FTP-APP
rserver dc9-lnx4
inservice
rserver dc9-lnx5
inservice
serverfarm host STRICT-FTP-APP
rserver dc9-lnx2
inservice
rserver dc9-lnx1
inservice
rserver dc9-lnx2
inservice
rserver dc9-lnx3
inservice
rserver dc9-lnx4
inservice
rserver dc9-lnx5
inservice

class-map type ftp inspect match-any NO-PUTS
2 match request-method put
class-map match-all VIP-92-STRICT
2 match virtual-address 172.16.PC.92 tcp eq ftp

class remote-access
permit

class class-default
serverfarm FTP-APP
policy-map type loadbalance first-match STRICT
class class-default
serverfarm STRICT-FTP-APP
class class-default
serverfarm servers9

policy-map type inspect ftp first-match FTP-INSPECT-POLICY
class NO-PUTS
deny

class VIP-90
class VIP-91-FTP
inspect ftp
class VIP-92-STRICT
loadbalance policy STRICT
inspect ftp strict FTP-INSPECT-POLICY

interface vlan 2PC
ip address 172.16.PC.9 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
username cisco password 5 $1$1WMrkvAT$wKQ1z8XC0XvTY0Fpv55QN0 role
Admin domain
default-domain
Lab 8: Configuring SSL Termination
Activity Objective
In this exercise, you will configure 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
Configure SSL session caching
Configure SSL queuing delay
Visual Objective
Configuring SSL Termination
MSFC
Catalyst 6500
Server
Encrypted
Unencrypted
Cisco ACE

Required Resources
Cisco ACE Module

Task 1: Configure SSL Termination When You Have Certificates
and Keys
It is very simple to configure SSL services on the Cisco ACE Module. All that is needed is the
SSL certificate and RSA key added to an ssl-proxy and associated to a classification of traffic.
Activity Procedure
Step 2 Connect directly to the Cisco ACE management IP address of the Lab-SSL-PC
context.
C:\> telnet 172.16.PC.14
Trying 172.16.PC.14...

Username: cisco
Password: cisco123
PodP-ACE/Lab-SSL-PC#
Step 4 Use the checkpoint system to roll the configuration to the ssl-begin checkpoint.
Step 6 Create a server farm named WEB-SF and add rservers dc14-lnx1 and dc14-lnx2.
Then, create a load-balancing policy map for the SSL Terminated traffic. Call the
policy map WEB-LB.
PodP-ACE/Lab-SSL-PC(config)# policy-map type loadbalance
first-match WEB-LB
PodP-ACE/Lab-SSL-PC(config-pmap-lb)# class class-default
PodP-ACE/Lab-SSL-PC(config-pmap-lb-c)# serverfarm WEB-SF
Step 7 For the initial exercise, you will import the SSL certificates from the Linux Apache
server. Telnet to the server and copy the certificate and key to the cisco users
directory.
This step is required because, by default, Apache installs the server certificate and key into a
root-owned directory with permissions for only the owner to rwx, which prevents vs-ftp from
accessing the files.
Note Overwrite the destination files if prompted.
PodP-ACE/Lab-SSL-PC(config-pmap-lb-c)# do telnet 192.168.1.10
login: cisco
[cisco@linux1 ~]$ su
Password: cisco123
[root@linux1 ~]# cp /etc/httpd/conf/ssl.crt/server.crt .
[root@linux1 ~]# cp /etc/httpd/conf/ssl.key/server.key .
[root@linux1 ~]# chmod 644 server.*
Step 8 Exit the Telnet session and begin importing the SSL files, but first make sure that
there are no crypto files already in your context on the Cisco ACE Module.
Note The crypto import commands are EXEC mode commands, not CONFIG mode commands.
Pod1-ACE/Lab-SSL-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.
Pod1-ACE/Lab-SSL-PC#
PodP-ACE/Lab-SSL-PC# crypto import ftp 192.168.1.10 cisco
server.crt server.crt
Password: cisco
?Invalid command This is a known issue, you can ignore
this message
Passive mode on.
Hash mark printing on (1024 bytes/hash mark).
#
Successfully imported file from remote server.
server.key server.key
Password: cisco
this message
Passive mode on.
#
Step 9 Show the files.
PodP-ACE/Lab-SSL-PC# show crypto files
Filename File File Expor Key/
Size Type table Cert
-----------------------------------------------------------------------
server.crt 1464 PEM Yes CERT
server.key 887 PEM Yes KEY
Step 10 Verify that the key and cert match.
PodP-ACE/Lab-SSL-PC# crypto verify server.key server.crt
Keypair in server.key matches certificate in server.crt.
Step 11 Create the ssl-proxy service.
PodP-ACE/Lab-SSL-PC(config)# ssl-proxy service 141-SSL
PodP-ACE/Lab-SSL-PC(config-ssl-proxy)# cert server.crt
PodP-ACE/Lab-SSL-PC(config-ssl-proxy)# key server.key
Step 12 Create the class map vip for the SSL traffic.
PodP-ACE/Lab-SSL-PC(config)# class-map VIP-141
PodP-ACE/Lab-SSL-PC(config-cmap)# match virtual-address
172.16.PC.141 tcp eq https
Step 13 Create the policy multimatch for the SSL traffic.
PodP-ACE/Lab-SSL-PC(config)# policy-map multi-match client-
vips
PodP-ACE/Lab-SSL-PC(config-pmap)# class VIP-141
PodP-ACE/Lab-SSL-PC(config-pmap-c)# loadbalance vip inservice
PodP-ACE/Lab-SSL-PC(config-pmap-c)# loadbalance policy WEB-LB
PodP-ACE/Lab-SSL-PC(config-pmap-c)# ssl-proxy server 141-SSL
Step 14 Show the service policy.
PodP-ACE/Lab-SSL-PC(config-pmap-c)# do show service-policy
client-vips detail

Status : ACTIVE
Description: -
-----------------------------------------
Interface: vlan 2PC
class: VIP-140
loadbalance:
dropped conns : 0
L7 Loadbalance policy : slb14-logic
LB action :
hit count : 0
dropped conns : 0
class: VIP-141
VIP Address: Protocol: Port:
172.16.18.141 tcp eq 443
loadbalance:
L7 loadbalance policy: WEB-LB
dropped conns : 0
L7 Loadbalance policy : WEB-LB
LB action :
serverfarm: WEB-SF
hit count : 0
dropped conns : 0
Step 15 Test the SSL configuration by using a client browser to access
https://172.16.PC.141/. 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.
client-vips detail

Status : ACTIVE
Description: -
-----------------------------------------
Interface: vlan 2PC
class: VIP-140
loadbalance:
dropped conns : 0
LB action :
hit count : 0
dropped conns : 0
class: VIP-141
loadbalance:
dropped conns : 0
LB action :
serverfarm: WEB-SF
hit count : 2
dropped conns : 0
Step 16 Check the server farm. Can you find the problem?
PodP-ACE/Lab-SSL-PC(config-pmap-c)# do sho server WEB-SF
serverfarm : WEB-SF, type: HOST
total rservers : 2
---------------------------------
----------connections---------
--
failures
---+---------------------+------+------------+----------+------------------
--
rserver: dc14-lnx1
192.168.1.11:0 8 OPERATIONAL 0 1 0
rserver: dc14-lnx2
192.168.1.12:0 8 OPERATIONAL 0 1 0
Note The issue is that the server farm has a Layer 3 rserverin other words, the rserver is
defined by IP only. This means the Cisco ACE Module will not implicitly perform PAT on the
client requests.

On the wire, the server sees the client load-balancing to dc14-lnx1 or 2 and then a TCP SYN
to port 443 next a HTTP GET, which the Apache HTTPSD server will reject. This results in
the client receiving a blank page after receiving the SSL certificate.
Step 17 Make the rservers port bound in the server farm, to force the Cisco ACE Module to
implicitly perform PAT on incoming connections to the Apache HTTPD server
residing on port 80.
PodP-ACE/Lab-SSL-PC(config-sfarm-host-rs)# rserver dc14-lnx1
80
80
Step 18 Test the site again. Is any configuration missing?
PodP-ACE/Lab-SSL-PC(config-sfarm-host-rs)# do sho run
serverfarm

rserver dc14-lnx1
inservice
rserver dc14-lnx2
inservice
rserver dc14-lnx3
inservice
rserver dc14-lnx4
inservice
rserver dc14-lnx5
inservice
serverfarm host WEB-SF
rserver dc14-lnx1
inservice
rserver dc14-lnx1 80
rserver dc14-lnx2
inservice
Step 19 Notice by adding a port-bound rserver, the existing rservers were left as originally
configured. Remove them and inservice the port-bound rservers.
PodP-ACE/Lab-SSL-PC(config-sfarm-host-rs)# ins
80
PodP-ACE/Lab-SSL-PC(config-sfarm-host-rs)# ins
PodP-ACE/Lab-SSL-PC(config-sfarm-host-rs)# no rserver dc14-
lnx1
PodP-ACE/Lab-SSL-PC(config-sfarm-host)# no rserver dc14-lnx2

PodP-ACE/Lab-SSL-PC(config-sfarm-host)# do sho run serverfarm

inservice
inservice
rserver dc14-lnx1
inservice
rserver dc14-lnx2
inservice
rserver dc14-lnx3
inservice
rserver dc14-lnx4
inservice
rserver dc14-lnx5
inservice
Step 20 Test the VIP again. Now the web page should appear. Verify that the server
response byte count exceeds the client byte count.
PodP-ACE/Lab-SSL-PC(config-sfarm-host)# do show service-policy
client-vips detail

Status : ACTIVE
Description: -
-----------------------------------------
Interface: vlan 2PC
class: VIP-140
loadbalance:
dropped conns : 0
LB action :
hit count : 0
dropped conns : 0
class: VIP-141
loadbalance:
dropped conns : 0
11876
54325
LB action :
serverfarm: WEB-SF
hit count : 13
dropped conns : 0
You have completed this task when you are able to access web pages via SSL connections.
Task 2: Configure SSL Termination When You Must Create
Certificates and Keys
The Cisco ACE Module 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 Microsofts CA Server.
Note You cannot create self-signed certificates on the Cisco ACE Module.
Activity Procedure
Step 1 In this lab task, you will reuse the server farm and load-balancing policy map
created in the previous exercise. You will need a new class map to define a separate
VIP for this task. Use the class map name VIP-142-SELF-SIGNED and the IP
address 172.16.PC.142.
Step 2 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 the CSR can be easily
recreated if needed, without re-entering all the CSR data again. Create a CSR
parameter map and name it ACECSR-INFO.
PodP-ACE/LAB-SSL-PC(config)# crypto csr-params ACECSR-INFO
PodP-ACE/Lab-SSL-PC(config-csr-params)# country US
PodP-ACE/Lab-SSL-PC(config-csr-params)# state California
PodP-ACE/Lab-SSL-PC(config-csr-params)# locality SJC
PodP-ACE/Lab-SSL-PC(config-csr-params)# organization-name
Cisco
PodP-ACE/Lab-SSL-PC(config-csr-params)# organization-unit ADBU
PodP-ACE/Lab-SSL-PC(config-csr-params)# common-name
www.example.com
PodP-ACE/Lab-SSL-PC(config-csr-params)# serial-number 1234
PodP-ACE/Lab-SSL-PC(config-csr-params)# email
secadmin@example.com
Step 3 Show the defined crypto parameters.
PodP-ACE/Lab-SSL-PC# sho crypto csr-params all
crypto csr-params ACECSR-INFO
country US
state California
locality SJC
organization-name Cisco
organization-unit ADBU
common-name www.example.com
serial-number 1234
email secadmin@example.com
Step 4 Before the CSR can be generated, a RSA key pair must be created. Use 1024 bits
and name it ACEKEY. Delete an existing file if necessary. When created, the
crypto generate csr command combines the public key and information in the CSR
parameter-map to create a CSR in PEM format.
PodP-ACE/Lab-SSL-PC# crypto generate key 1024 ACEKEY
PodP-ACE/Lab-SSL-PC# sho crypto key ACEKEY

1024 bit RSA keypair found in ACEKEY
Modulus:
c5:d3:28:fc:2b:dd:15:90:e9:8c:1e:f9:4d:87:ef:72:80:cc:d4:39:da:99:14:36:db:b6:
52
:a4:64:22:4a:f2:00:6f:df:e5:86:b6:45:cd:7c:59:cc:48:8e:d0:57:66:4c:cb:b1:b7:19
:e
5:90:26:e6:4e:48:38:f3:56:3f:4c:72:ff:40:8b:a1:99:12:95:0f:31:80:6d:a7:28:bc:f
5:
c0:37:76:97:b6:78:6d:92:f5:c7:90:c2:00:13:54:0b:b5:ad:77:8a:c5:fa:79:4c:fe:af:
eb
:58:17:dd:4e:ff:ad:07:0d:90:1d:e6:97:62:af:be:3e:d0:52:99:97:69:

PodP-ACE/Lab-SSL-PC# crypto generate csr ACECSR-INFO ACEKEY
-----BEGIN CERTIFICATE REQUEST-----
MIIBzzCCATgCAQAwgY4xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MQwwCgYDVQQHEwNTSkMxDjAMBgNVBAoTBUNpc2NvMQ0wCwYDVQQLEwRBREJVMRgw
FgYDVQQDEw93d3cuZXhhbXBsZS5jb20xIzAhBgkqhkiG9w0BCQEWFHNlY2FkbWlu
QGV4YW1wbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDF0yj8K90V
kOmMHvlNh+9ygMzUOdqZFDbbtlKkZCJK8gBv3+WGtkXNfFnMSI7QV2ZMy7G3GeWQ
JuZOSDjzVj9Mcv9Ai6GZEpUPMYBtpyi89cA3dpe2eG2S9ceQwgATVAu1rXeKxfp5
TP6v61gX3U7/rQcNkB3ml2Kvvj7QUpmXaQIDAQABoAAwDQYJKoZIhvcNAQEEBQAD
gYEAVcc+a0grYZiSKBn9p77RrSgPWNRIMn257pQcK+SYArEOGZVOenZFWCMqO4Pf
7/sOiiE3okJEAKeq0HpcEpvGt+xl6SXVKNBjijLXUKuNMzQe3xJmBH90et2O+8fk
XyHXJkQ5jHKKcr99Kd2JhTXLkB/WccQTPWuXA/8Mx2IQpb4=
-----END CERTIFICATE REQUEST-----
Step 5 Sign the CSR using the Linux server to make an SSL Certificate or obtain the
Certificate free from Thawte or VeriSign. When using the Linux server, paste the
CSR of the Cisco ACE Module into a file.
Note The entire CSR, including the -----BEGIN and -----END lines must be copied from the
Cisco ACE Module 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.
PodP-ACE/Lab-SSL-PC# telnet 192.168.1.10
login: cisco
Password: cisco123
[cisco@linux1 ~]# cat > ACECSR
MIIBzzCCATgCAQAwgY4xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MQwwCgYDVQQHEwNTSkMxDjAMBgNVBAoTBUNpc2NvMQ0wCwYDVQQLEwRBREJVMRgw
FgYDVQQDEw93d3cuZXhhbXBsZS5jb20xIzAhBgkqhkiG9w0BCQEWFHNlY2FkbWlu
QGV4YW1wbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDF0yj8K90V
kOmMHvlNh+9ygMzUOdqZFDbbtlKkZCJK8gBv3+WGtkXNfFnMSI7QV2ZMy7G3GeWQ
JuZOSDjzVj9Mcv9Ai6GZEpUPMYBtpyi89cA3dpe2eG2S9ceQwgATVAu1rXeKxfp5
TP6v61gX3U7/rQcNkB3ml2Kvvj7QUpmXaQIDAQABoAAwDQYJKoZIhvcNAQEEBQAD
gYEAVcc+a0grYZiSKBn9p77RrSgPWNRIMn257pQcK+SYArEOGZVOenZFWCMqO4Pf
7/sOiiE3okJEAKeq0HpcEpvGt+xl6SXVKNBjijLXUKuNMzQe3xJmBH90et2O+8fk
XyHXJkQ5jHKKcr99Kd2JhTXLkB/WccQTPWuXA/8Mx2IQpb4=
Step 6 Use OpenSSL to create a Root CA certificate. Press Enter for all of 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
/usr/share/ssl/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, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:
Step 7 Notice the previous OpenSSL command created two new files, which will be used to
sign the CSR of the Cisco ACE Module.
[cisco@linux1 ~]$ ls -lrt | tail -3
-rw-r--r-- 1 cisco root 704 Jun 26 05:22 ACECSR
-rw-r--r-- 1 cisco root 887 Jun 26 05:37 rootCAkey.pem
-rw-r--r-- 1 cisco root 1001 Jun 26 05:37 rootCAcert.pem

[cisco@linux1 ~]$ openssl x509 -in ACECSR -req -days 365 -CA
rootCAcert.pem -CAk
ey rootCAkey.pem -set_serial 1234 -out ACECERT.pem
Signature ok
subject=/C=US/ST=California/L=SJC/O=Cisco/OU=ADBU/CN=www.examp
le.com/emailAddres
s=secadmin@example.com
Getting CA Private Key
Step 8 Use OpenSSL to view and verify the new SSL certificate.
[cisco@linux1 ~]$ openssl x509 -in ACECERT.pem -text
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 1234 (0x4d2)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd
Validity
Not Before: Jun 26 12:38:30 2006 GMT
Not After : Jun 26 12:38:30 2007 GMT
Subject: C=US, ST=California, L=SJC, O=Cisco, OU=ADBU,
CN=www.example.co
m/emailAddress=secadmin@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:c5:d3:28:fc:2b:dd:15:90:e9:8c:1e:f9:4d:87:
ef:72:80:cc:d4:39:da:99:14:36:db:b6:52:a4:64:
22:4a:f2:00:6f:df:e5:86:b6:45:cd:7c:59:cc:48:
8e:d0:57:66:4c:cb:b1:b7:19:e5:90:26:e6:4e:48:
38:f3:56:3f:4c:72:ff:40:8b:a1:99:12:95:0f:31:
80:6d:a7:28:bc:f5:c0:37:76:97:b6:78:6d:92:f5:
c7:90:c2:00:13:54:0b:b5:ad:77:8a:c5:fa:79:4c:
fe:af:eb:58:17:dd:4e:ff:ad:07:0d:90:1d:e6:97:
62:af:be:3e:d0:52:99:97:69
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
5a:74:ac:0a:72:51:d3:fc:bc:c3:de:c5:d1:6f:89:db:9a:13:
63:d5:d0:25:65:c4:81:79:5a:f5:12:fb:07:62:c9:7d:32:a0:
4b:77:b5:4a:7f:97:35:fa:b8:e8:e9:3b:6a:c9:d6:af:28:df:
a9:a8:20:0f:c9:90:d4:7a:01:d6:0f:6b:ff:63:d9:bf:d7:7d:
17:32:c5:8b:52:88:1a:63:41:bb:d1:49:15:b6:78:0e:7d:34:
d7:48:23:83:c3:b6:26:b4:80:dc:cf:c9:4a:0e:54:b5:15:50:
07:9f:e1:ff:cd:5b:5f:87:67:b3:78:ff:fa:44:80:ad:9e:92:
d2:16
-----BEGIN CERTIFICATE-----
MIICSzCCAbQCAgTSMA0GCSqGSIb3DQEBBAUAMEwxCzAJBgNVBAYTAkdCMRIwEAYD
VQQIEwlCZXJrc2hpcmUxEDAOBgNVBAcTB05ld2J1cnkxFzAVBgNVBAoTDk15IENv
bXBhbnkgTHRkMB4XDTA2MDYyNjEyMzgzMFoXDTA3MDYyNjEyMzgzMFowgY4xCzAJ
BgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMQwwCgYDVQQHEwNTSkMxDjAM
BgNVBAoTBUNpc2NvMQ0wCwYDVQQLEwRBREJVMRgwFgYDVQQDEw93d3cuZXhhbXBs
ZS5jb20xIzAhBgkqhkiG9w0BCQEWFHNlY2FkbWluQGV4YW1wbGUuY29tMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDF0yj8K90VkOmMHvlNh+9ygMzUOdqZFDbb
tlKkZCJK8gBv3+WGtkXNfFnMSI7QV2ZMy7G3GeWQJuZOSDjzVj9Mcv9Ai6GZEpUP
MYBtpyi89cA3dpe2eG2S9ceQwgATVAu1rXeKxfp5TP6v61gX3U7/rQcNkB3ml2Kv
vj7QUpmXaQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAFp0rApyUdP8vMPexdFvidua
E2PV0CVlxIF5WvUS+wdiyX0yoEt3tUp/lzX6uOjpO2rJ1q8o36moIA/JkNR6AdYP
a/9j2b/XfRcyxYtSiBpjQbvRSRW2eA59NNdII4PDtia0gNzPyUoOVLUVUAef4f/N
W1+HZ7N4//pEgK2ektIW
-----END CERTIFICATE-----

Step 9 After the certificate is created, import it using cut and paste or FTP.
PodP-ACE/Lab-SSL-PC# crypto import terminal ACECERT
Please enter PEM formatted data. End with "quit" on a new line.
MIICSzCCAbQCAgTSMA0GCSqGSIb3DQEBBAUAMEwxCzAJBgNVBAYTAkdCMRIwEAYD
bXBhbnkgTHRkMB4XDTA2MDYyNjEyMzgzMFoXDTA3MDYyNjEyMzgzMFowgY4xCzAJ
BgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMQwwCgYDVQQHEwNTSkMxDjAM
BgNVBAoTBUNpc2NvMQ0wCwYDVQQLEwRBREJVMRgwFgYDVQQDEw93d3cuZXhhbXBs
ZS5jb20xIzAhBgkqhkiG9w0BCQEWFHNlY2FkbWluQGV4YW1wbGUuY29tMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDF0yj8K90VkOmMHvlNh+9ygMzUOdqZFDbb
tlKkZCJK8gBv3+WGtkXNfFnMSI7QV2ZMy7G3GeWQJuZOSDjzVj9Mcv9Ai6GZEpUP
MYBtpyi89cA3dpe2eG2S9ceQwgATVAu1rXeKxfp5TP6v61gX3U7/rQcNkB3ml2Kv
vj7QUpmXaQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAFp0rApyUdP8vMPexdFvidua
E2PV0CVlxIF5WvUS+wdiyX0yoEt3tUp/lzX6uOjpO2rJ1q8o36moIA/JkNR6AdYP
a/9j2b/XfRcyxYtSiBpjQbvRSRW2eA59NNdII4PDtia0gNzPyUoOVLUVUAef4f/N
W1+HZ7N4//pEgK2ektIW
quit

Step 10 List the files.
-----------------------------------------------------------------------
ACEKEY 891 PEM Yes KEY
ACECERT 855 PEM Yes CERT
Step 11 Verify that the key and certificate match.
PodP-ACE/Lab-SSL-PC# crypto verify ACEKEY ACECERT
Keypair in ACEKEY matches certificate in ACECERT.
Step 12 For this example, force the Cisco ACE VIP to accept connections only from clients
that are capable of using the standard strong cipher RC4-128-MD5. Create a
parameter map of type-ssl, called RC4-ONLY.
Note An SSL parameter map defines the SSL session parameters that the Cisco ACE Module
applies to an SSL proxy service. Creating an SSL parameter map allows you to apply the
same SSL session parameters to different proxy services.
PodP-ACE/Lab-SSL-PC# conf
PodP-ACE/Lab-SSL-PC(config)# parameter-map type ssl RC4-ONLY
PodP-ACE/Lab-SSL-PC(config-parammap-ssl)# cipher <TAB>
RSA_EXPORT1024_WITH_DES_CBC_SHA RSA_WITH_AES_128_CBC_SHA
RSA_EXPORT1024_WITH_RC4_56_MD5 RSA_WITH_AES_256_CBC_SHA
RSA_EXPORT1024_WITH_RC4_56_SHA RSA_WITH_DES_CBC_SHA
RSA_EXPORT_WITH_DES40_CBC_SHA RSA_WITH_RC4_128_MD5
RSA_EXPORT_WITH_RC4_40_MD5 RSA_WITH_RC4_128_SHA
RSA_WITH_3DES_EDE_CBC_SHA
PodP-ACE/Lab-SSL-PC(config-parammap-ssl)# cipher RSA_WITH_RC4_128_MD5

Create a new ssl-proxy service for this particular SSL VIP.
PodP-ACE/Lab-SSL-PC(config)# ssl-proxy service ACE-SSL-RC4
PodP-ACE/Lab-SSL-PC(config-ssl-proxy)# cert ACECERT
PodP-ACE/Lab-SSL-PC(config-ssl-proxy)# key ACEKEY
PodP-ACE/Lab-SSL-PC(config-ssl-proxy)# ssl advanced-options RC4-ONLY

Create the class map vip for the SSL traffic.
PodP-ACE/Lab-SSL-PC(config)# class VIP-142-SSL-RC4
PodP-ACE/Lab-SSL-PC(config-cmap)# match vir 172.16.PC.142 tcp eq 443
PodP-ACE/Lab-SSL-PC(config)# policy-map multi client-vips
PodP-ACE/Lab-SSL-PC(config-pmap)# class VIP-142-SSL-RC4
PodP-ACE/Lab-SSL-PC(config-pmap-c)# load vip ins
PodP-ACE/Lab-SSL-PC(config-pmap-c)# load pol WEB-LB
PodP-ACE/Lab-SSL-PC(config-pmap-c)# ssl-proxy server ACE-SSL-
RC4
Step 14 Show the service policy.
PodP-ACE/Lab-SSL-PC(config-pmap-c)# do show service client-
vips detail
Status : ACTIVE
Description: -
-----------------------------------------
Interface: vlan 2PC
class: VIP-140
loadbalance:
dropped conns : 0
LB action :
hit count : 0
dropped conns : 0
class: VIP-141
loadbalance:
dropped conns : 0
11876
54325
LB action :
serverfarm: WEB-SF
hit count : 13
dropped conns : 0
class: VIP-142-SSL-RC4
loadbalance:
dropped conns : 0
LB action :
serverfarm: WEB-SF
hit count : 13
dropped conns : 0
Step 15 Test the SSL configuration by using a client browser to reach https://172.16.PC.142.
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.
PodP-ACE/Lab-SSL-PC(config-pmap-c)# do show service client-vips detail

Status : ACTIVE
Description: -
-----------------------------------------
Interface: vlan 2PC
class: VIP-140
loadbalance:
dropped conns : 0
LB action :
hit count : 0
dropped conns : 0
class: VIP-141
loadbalance:
dropped conns : 0
LB action :
serverfarm: WEB-SF
hit count : 24
dropped conns : 0
class: VIP-142-SSL-RC4
loadbalance:
dropped conns : 0
LB action :
serverfarm: WEB-SF
hit count : 24
dropped conns : 0
Created a RSA key and CSR.
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: SSL Session ID Reuse
An SSL session ID is created every time the client and the Cisco ACE Module perform a full
SSL key exchange and establish a new master secret key. To speed up the SSL negotiation
process between the client and the Cisco ACE Module, the SSL session ID reuse feature allows
the Cisco ACE Module to reuse the secret key information in the session cache. On subsequent
connections with the client, the Cisco ACE Module reuses the key stored in cache from the last
negotiated session.
By default, SSL session ID reuse is disabled on the Cisco ACE Module. You can enable
session ID reuse by setting a session cache timeout value for the total amount of time that the
SSL session ID remains valid before the Cisco ACE Module requires a full SSL handshake to
establish a new session. To set the session cache timeout, use the session-cache timeout
command in parameter-map SSL configuration mode
Activity Procedure
Step 1 Connect directly to the Cisco ACE management IP address for your lab context at
172.16.PC.14.
PodP-ACE/Lab-SSL-PC#
Step 3 Use the checkpoint system to roll the configuration to the baseline-mgmt checkpoint
and then the ssl-begin checkpoint.
Step 4 Issue a show run command to see what is preconfigured for this lab.
Step 5 Bind the rservers to port 80, to force the Cisco ACE Module to implicitly use PAT
on incoming connections to the server residing on port 80.
PodP-ACE/Lab-SSL-PC(config)# serverfarm host servers14
PodP-ACE/Lab-SSL-PC(config-sfarm-host)# rserver dc14-lnx1 80
PodP-ACE/Lab-SSL-PC(config-sfarm-host-rs)# do sho run
serverfarm

rserver dc14-lnx1
inservice
rserver dc14-lnx2
inservice
rserver dc14-lnx3
inservice
rserver dc14-lnx4
inservice
rserver dc14-lnx5
inservice
Note ACE does not append existing rservers with the port. To modify the port, you must add a
new rserver and remove the previous rserver.
PodP-ACE/Lab-SSL-PC(config-sfarm-host-rs)# inservice
80
80
80
80
PodP-ACE/Lab-SSL-PC(config-sfarm-host-rs)# no rserver dc14-
lnx1
Step 6 View the configured server farm.
PodP-ACE/Lab-SSL-PC(config-sfarm-host)# do show run serverfarm

inservice
inservice
inservice
inservice
inservice
Step 7 Import the SSL certificates from the Linux server. Telnet from ACE to the server
and copy the certificate and key to the cisco users directory.
Note By default, Apache installs the server certificate and key into a root-owned directory with
permissions for the owner only. This prevents vs-ftp from accessing the files. This is a nice
security feature in the real world.
PodP-ACE/Lab-SSL-PC(config-pmap-lb-c)# do telnet 192.168.1.10
Login: cisco
Password: cisco123
[root@linux1 ~]# cp /etc/httpd/conf/ssl.crt/server.crt .
[root@linux1 ~]# cp /etc/httpd/conf/ssl.key/server.key .
[root@linux1 ~]# chmod 644 server.*
Step 8 Exit from the Telnet session. Delete any files already existing in the context and
begin importing the SSL files.
Note The crypto delete and crypto import commands are EXEC mode commands.
Pod1-ACE/Lab-SSL-18# 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.

server.crt server.crt
Password: cisco
this message
Passive mode on.
#
server.key server.key
Password: cisco
this message
Passive mode on.
#
Step 9 Show the files.
-----------------------------------------------------------------------
Step 10 Verify that the key and certificate match.
PodP-ACE/Lab-SSL-PC# crypto verify server.key server.crt
Keypair in server.key matches certificate in server.crt.
Step 11 Create the ssl-proxy service.
PodP-ACE/Lab-SSL-PC(config-ssl-proxy)# cert server.crt
PodP-ACE/Lab-SSL-PC(config-ssl-proxy)# key server.key
PodP-ACE/Lab-SSL-PC(config)# policy-map multi-match client-
vips
PodP-ACE/Lab-SSL-PC(config-pmap)# class VIP-140
PodP-ACE/Lab-SSL-PC(config-pmap-c)# ssl-proxy server 140-SSL
Step 13 View the configured policies.
PodP-ACE/Lab-SSL-PC(config-pmap-c)# do show run policy-map

class remote-access
permit

class class-default
serverfarm servers14

class VIP-140
ssl-proxy server 140-SSL
Step 14 On the Client PC, use Ethereal (capture interface 209.165.XXX.PC) to monitor an
SSL connection process and determine the SSL Session ID. Test the SSL
configuration by using a client browser to reach the URL https://172.16.PC.140.
Take time to verify that the certificate that the client receives is the correct SSL
certificate.
Is the connection completely successful?
Note In Ethereal capture interface 209.165.XXX..PC. For the session ID information, look at:
Protocol=SSLv3(Server Hello)/Secure Socket Layer/SSLv3 Record Layer/Handshake
Protocol/Session ID.
View the service policy states, and then use Ethereal to view the SSL connections to determine
what SSL Session ID value the Cisco ACE Module is setting.
What is the SSL Session ID value that the Cisco ACE Module is setting?
client-vips detail

Status : ACTIVE
Description: -
-----------------------------------------
Interface: vlan 2PC
class: VIP-140
VIP Address: Port:
172.16.PC.140 any
loadbalance:
dropped conns : 0
10853
65034
L7 Loadbalance policy : sbl21-logic
LB action :
hit count : 11
dropped conns : 0
Step 15 Create a parameter-map type of ssl, and configure the SSL Session ID Reuse feature
using the session-cache timeout command. The seconds argument is the time in
seconds that the Cisco ACE Module reuses the key stored in cache before removing
the session IDs. Enter an integer from 0 to 72000.
PodP-ACE/Lab-SSL-PC(config)# parameter-map type ssl SSLPARAM
PodP-ACE/Lab-SSL-PC(config-parammap-ssl)# session-cache
timeout 600
Step 16 Add the parameter-map to the SSL proxy group.
PodP-ACE/Lab-SSL-PC(config-ssl-proxy)# ssl advanced-options
SSLPARAM
Step 17 Show the details of the parameter map.
PodP-ACE/Lab-SSL-PC(config-parammap-ssl)# do show parameter-
map SSLPARAM

Parameter-map : SSLPARAM
Type : ssl
version : all
close-protocol : none
session-cache timeout : 600
queue-delay timeout : disabled
PodP-ACE/Lab-SSL-PC(config-parammap-ssl)#
Step 18 Show the session cache information for the session. Note that the all option is only
available from the Admin context as a way for the administrator to see session-cache
information for the Cisco ACE Module without having to change to each specific
context.
PodP-ACE/Lab-SSL-PC(config-parammap-ssl)# do show crypto
session-cache
Step 19 Test the SSL configuration again by using a client browser to reach the URL
https://172.16.PC.140. Use Ethereal to view the SSL connections to determine what
SSL Session ID value the Cisco ACE Module is setting.
What SSL Session ID value is the Cisco ACE Module setting now?
Step 20 Refresh the browser to https://172.16.PC.140. Use Ethereal to view the SSL
connections to determine what SSL Session ID the client is using.
What SSL Session ID value is the client using?
Configured and verified SSL termination.
Reviewed sniffer traces to see how the Cisco ACE Module reuses the SSL Session ID.
Task 4: Configure SSL Queue Delay
In this task, you will configure SSL queuing delay.
Activity Procedure
The Cisco ACE Module queues packet data from the server before encrypting it for
transmission to the client. The Cisco ACE Module empties the data from the queue for
encryption when one of the following events occurs:
The queue reaches 8,000 bytes.
The server sends a TCP-FIN segment.
The queue delay time on the Cisco ACE Module has passed, even though the queue had not
reached 8,000 bytes.
The queue delay time is the amount of time that the Cisco ACE Module waits before emptying
the queued data for encryption. By default, the queue delay timer is disabled. You can set the
delay time by using the queue-delay timeout command in parameter map SSL configuration
mode.
Step 1 Configure the Cisco ACE Module with a queue-delay timeout value of 300
milliseconds.
PodP-ACE/Lab-SSL-PC(config)# parameter-map type ssl SSLPARAM
PodP-ACE/Lab-SSL-PC(config-parammap-ssl)# queue-delay timeout
300
Step 2 View the configured parameter map.
PodP-ACE/Lab-SSL-PC(config-parammap-ssl)# do show run
parameter-map

parameter-map type ssl SSLPARAM
session-cache timeout 600
queue-delay timeout 300

PodP-ACE/Lab-SSL-PC(config-parammap-ssl)#
Note In some cases, the default value of the ssl-queue-delay will not be optimal and you will see a
delay with encrypted return traffic. In a case where the unencrypted traffic coming back from
the server involves a small amount of data or data transferred in small blocks, the ssl-queue-
delay can be lower and result in better performance. Unfortunately, each applications traffic
pattern is different, so you must vary this value to find what works best in your environment.
You have completed this task when you have configured the queue-delay timeout command
for SSL traffic.
Activity Procedure
PodP-ACE/Lab-SSL-PC# checkpoint rollback baseline-mgmt
This operation will rollback the system's running
configuration
Rollback succeeded
Answer Key: Configuring SSL Termination
SSL Termination Configuration (Task 1)
PodP-ACE/Lab-SSL-PC(config-sfarm-host)# do sho run

login timeout 0


ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
ip address 192.168.1.15
inservice

ssl-proxy service 141-SSL
key server.key
cert server.crt

rserver dc14-lnx1
inservice
rserver dc14-lnx2
inservice
rserver dc14-lnx3
inservice
rserver dc14-lnx4
inservice
rserver dc14-lnx5
inservice
inservice
inservice

2 match virtual-address 172.16.PC.141 tcp eq https

class remote-access
permit
class class-default
policy-map type loadbalance first-match WEB-LB
class class-default
serverfarm WEB-SF
class VIP-140
class VIP-141
loadbalance policy WEB-LB

interface vlan 2PC
ip address 172.16.PC.14 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
Admin domain
default-domain

SSL Termination Configuration Using ACE-Created CSR and Limiting Client to the
RC4 Cipher (Task 2)
PodP-ACE/Lab-SSL-PC# sho run

login timeout 0

crypto csr-params ACECSR-INFO
country US
state California
locality SJC
organization-name Cisco
organization-unit ADBU
common-name www.example.com
serial-number 1234
email secadmin@example.com


parameter-map type ssl RC4-ONLY
cipher RSA_WITH_RC4_128_MD5

ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
ip address 192.168.1.15
inservice

key server.key
cert server.crt
ssl-proxy service ACE-SSL-RC4
key ACEKEY
cert ACECERT
ssl advanced-options RC4-ONLY

rserver dc14-lnx1
inservice
rserver dc14-lnx2
inservice
rserver dc14-lnx3
inservice
rserver dc14-lnx4
inservice
rserver dc14-lnx5
inservice
inservice
inservice

class-map match-all VIP-142-SELF-SIGNED
class-map match-all VIP-142-SSL-RC4

class remote-access
permit
class class-default
policy-map type loadbalance first-match WEB-LB
class class-default
serverfarm WEB-SF
class VIP-140
class VIP-141
class VIP-142-SSL-RC4
ssl-proxy server ACE-SSL-RC4

interface vlan 2PC
ip address 172.16.PC.14 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
Admin domain
default-domain

SSL Session ID Reuse (Task 3)
Pod-ACE/Lab-SSL-PC# show run

login timeout 0


parameter-map type ssl SSLPARAM
session-cache timeout 600

ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
ip address 192.168.1.15
inservice

key server.key
cert server.crt
ssl advanced-options SSLPARAM

inservice
inservice
inservice
inservice
inservice

2 match virtual-address 172.16.21.140 tcp eq https

class remote-access
permit

class class-default

class VIP-140

interface vlan 2PC
ip address 172.16.PC.14 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1

Lab 9: Integrating Multiple Features
Activity Objective
In this exercise, you will configure your ACE context to perform a variety functions in an
integrated environment. After completing this exercise, you will be able to meet these
objectives:
Create a virtual IP address to accept web traffic
Apply source IP sticky to ensure client persistence
Apply probes to ensure that real servers are working properly
Create a virtual IP address to accept clear application traffic
Create a virtual IP address to accept secure application traffic
Configure SSL acceleration
Apply probe and cookie insert sticky to ensure client persistence
Create a domain for the security team
Allow direct server access and server-initiated connections
Configure HTTP normalization
The features you configure will provide the following services:
Web (HTTP and HTTPS with source IP sticky):
Layer 3 VIPs
Source IP sticky
Health monitoring on port 80 with real SSL probe
Web with SSL offload (HTTP and HTTPS with cookie sticky):
Layer 4 VIPs
SSL termination
Health monitoring on port 80
Sticky to tie them together with cookie insert
Effective use of RBAC and domains:
ACLs (security role and domain)
Permit only 80 and 443
Allow server management access only (require source NAT)
Add HTTP normalization:
Deobsfucation
Misuse
Source NAT for server-initiated connections
Visual Objective
Integrating Multiple Features
MSFC
Cisco ACE
C
a
t
a
l
y
s
t

6
5
0
0
Client
Servers
Traffic Class Map
Match VIP connections
Default Class
Real
Server 1
Real
Server 2
Server Farm

Required Resources
Cisco ACE Module

Task 1: Create a Virtual IP Address to Accept Web Traffic
In this task, you will create a virtual IP address to accept web traffic.
Activity Procedure
C:\> telnet 172.16.PC.19
Trying 172.16.PC.19...


Username: cisco
Password: cisco123
PodP-ACE/Lab-Cart-PC#
Step 4 Use the checkpoint system to roll the configuration to the start-cart checkpoint.
Step 6 Create a class map for the Layer 3 VIP.
class-map match-all VIP-WEB
match virtual-address 172.16.PC.190 any
Step 7 Create Layer 3 rserver entries for the two real servers.
rserver host linux-1
ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
Step 8 Use the show arp command to verify that the Cisco ACE Module has network
connectivity to the real servers.
show arp

Context Lab-Cart-PC
================================================================================
IP ADDRESS MAC-ADDRESS Interface Type Encap NextArp(s) Status
================================================================================
172.16.PC.1 00.d0.63.ec.0c.00 vlan2PC GATEWAY 6 243 sec up
172.16.PC.19 00.02.02.02.02.03 vlan2PC INTERFACE LOCAL _ up
192.168.1.1 00.02.02.02.02.03 vlan4PC INTERFACE LOCAL _ up
192.168.1.11 00.0c.29.26.b4.c4 vlan4PC RSERVER 7 270 sec up
192.168.1.12 00.0c.29.26.b4.c4 vlan4PC RSERVER 8 271 sec up
================================================================================
Total arp entries 6
Step 9 Create a server farm to group the rservers.
rserver linux-1
inservice
rserver linux-2
inservice
Step 10 Create a policy map for load-balancing traffic to the real servers via the server farm.
class class-default
serverfarm WEB-FARM
Step 11 Create a policy map of type multi-match to associate VIP and load-balancing policy
map.
class VIP-WEB
loadbalance vip icmp-reply active
Step 12 Apply the policy map to the client VLAN interface.
int vlan 2PC
Step 13 Verify that the VIP is active and ready to receive traffic by using the show service-
policy command.
show service-policy client-vips

Status : ACTIVE
-----------------------------------------
Interface: vlan 2PC
class: VIP-WEB
loadbalance:
L7 loadbalance policy: WEB-POLICY
VIP ICMP Reply : ENABLED-WHEN-ACTIVE
dropped conns : 0
Step 14 Verify that the VIP is accessible by trying to access the VIP from your Client PC.
Test both port 80 traffic and port 443.
https://172.16.PC.190/small.html
Step 15 Issue the show service-policy command again and verify that the counters are
incrementing.
Configuration Example
login timeout 0


ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice

rserver linux-1
inservice
rserver linux-2
inservice


class remote-access
permit
class class-default
serverfarm WEB-FARM
class VIP-WEB

interface vlan 2PC
ip address 172.16.PC.19 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
username cisco password 5 $1$XmQdckxk$.7qpe2mHEq1WJowynpfuK0 role Admin domain
default-domain
Task 2: Apply Source IP Sticky to Ensure Client Persistence
In this task, you will apply source IP sticky to ensure client persistence.
Activity Procedure
Step 1 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-grp-
web
timeout 5
serverfarm WEB-FARM
Step 2 The sticky group is applied within the policy map of type loadbalance. Before the
sticky group can be applied, the current server farm must be removed.
class class-default
no serverfarm WEB-FARM
sticky-serverfarm sticky-grp-web
Step 3 Use the following commands to view the sticky tables on the Cisco ACE Module.
show sticky database type ip-netmask source
show sticky database group
Step 4 Verify that the sticky configuration is working for clients accessing the VIP from
your Client PC. Test both port 80 traffic and port 443.
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.
login timeout 0


ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice

rserver linux-1
inservice
rserver linux-2
inservice

sticky ip-netmask 255.255.255.255 address source sticky-grp-web
timeout 10
serverfarm WEB-FARM


class remote-access
permit
class class-default
class VIP-WEB

interface vlan 2PC
ip address 172.16.PC.19 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
default-domain

Task 3: Apply Probes to Ensure That Real Servers Are Working
Properly
In this task, you will apply probes to ensure that real servers are working properly.
Activity Procedure
Step 1 Create a probe to check the index.html page on the real servers.
probe http HTTP-PROBE
Step 2 Apply the probe to the server farm WEB-FARM.
probe HTTP-PROBE
Step 3 Use the show probe command to view the probes and their default parameters. Note
that you will need to wait some time for the probe to leave the initialization state.
PodP-ACE/Lab-Cart-PC(config-sfarm-host)# do sho probe HTTP-PROBE

probe : HTTP-PROBE
----------------------------------------------
port : 80 address : 0.0.0.0 addr type : -
interval : 120 pass intvl : 300 pass count : 3
--------------------- probe results -------------------
-
probe association probed-address probes failed passed health
------------------- ---------------+----------+----------+----------+------
-
serverfarm : WEB-FARM
real : linux-1[0]
192.168.1.11 0 0 0 INIT
real : linux-2[0]
192.168.1.12 0 0 0 INIT
Step 4 See what the default probe is. Using a new Telnet session from your Client PC,
connect to the ACE context.
C:\> telnet 172.16.PC.19
Trying 172.16.PC.19...


Username: cisco
Password: cisco123
Step 5 From the ACE context, establish a Telnet connection to the rserver.
telnet 192.168.1.11
login: cisco
Resource temporarily unavailable while getting initial
credentials
Last login: Fri Mar 31 18:32:06 from 209.165.202.18
[cisco@linux1 ~]$
Step 6 When you are logged into the Linux server, change to the super-user account.
Password: cisco123
Step 7 Use tethereal to verify the probe from the Cisco ACE Module.
[root@linux1 ~]# tethereal -R http
Capturing on eth0
9.451638 192.168.1.1 -> 192.168.1.12 HTTP GET / HTTP/1.1
9.452596 192.168.1.1 -> 192.168.1.11 HTTP GET / HTTP/1.1
9.483577 192.168.1.11 -> 192.168.1.1 HTTP HTTP/1.1 200 OK
9.487261 192.168.1.11 -> 192.168.1.1 HTTP Continuation or non-HTTP traffic
9.501460 192.168.1.12 -> 192.168.1.1 HTTP HTTP/1.1 200 OK
91.644233 192.168.1.1 -> 192.168.1.12 HTTP GET / HTTP/1.1
91.645006 192.168.1.1 -> 192.168.1.11 HTTP GET / HTTP/1.1
91.659091 192.168.1.12 -> 192.168.1.1 HTTP HTTP/1.1 200 OK
91.667273 192.168.1.11 -> 192.168.1.1 HTTP HTTP/1.1 200 OK
170.424459 192.168.1.1 -> 192.168.1.12 HTTP GET / HTTP/1.1
170.424605 192.168.1.1 -> 192.168.1.11 HTTP GET / HTTP/1.1
170.440235 192.168.1.12 -> 192.168.1.1 HTTP HTTP/1.1 200 OK
170.456357 192.168.1.11 -> 192.168.1.1 HTTP HTTP/1.1 200 OK
Step 8 See what is in the details of the show probe command.
PodP-ACE/Lab-Cart-PC(config-sfarm-host)# do sho probe HTTP-PROBE detail

probe : HTTP-PROBE
description :
----------------------------------------------
port : 80 address : 0.0.0.0 addr type : -
interval : 120 pass intvl : 300 pass count : 3

http method : GET
http url : /
expect regex : -
send data : -
--------------------- probe results -------------------
-
probe association probed-address probes failed passed health
------------------- ---------------+----------+----------+----------+------
-
serverfarm : WEB-FARM
real : linux-1[0]
192.168.1.11 8 0 8
SUCCESS

Last disconnect err : -
Last probe time : Sat Sep 16 18:01:31 2006
Last active time : Sat Sep 16 17:47:31 2006

real : linux-2[0]
192.168.1.12 8 0 8
SUCCESS

Last disconnect err : -
Last probe time : Sat Sep 16 18:01:31 2006
Last active time : Sat Sep 16 17:47:31 2006
Step 9 The probe works fine, but now bring the probe timers down, so that you can
demonstrate a failure detection quickly. You also need to lower the passdetect
parameters to let the Cisco ACE Module bring the real server back into rotation
more quickly.
interval 5
passdetect count 1
Step 10 Take a look at the traces. Verify that the new timers have taken effect.
DELAY is greater than the new interval of 5 Seconds initially. Why?
1037.431043 192.168.1.1 -> 192.168.1.11 HTTP GET / HTTP/1.1
1037.431050 192.168.1.1 -> 192.168.1.12 HTTP GET / HTTP/1.1
1037.448825 192.168.1.11 -> 192.168.1.1 HTTP HTTP/1.1 200 OK
1037.461033 192.168.1.12 -> 192.168.1.1 HTTP HTTP/1.1 200 OK
1040.744189 192.168.1.1 -> 192.168.1.12 HTTP GET / HTTP/1.1
1040.744453 192.168.1.1 -> 192.168.1.11 HTTP GET / HTTP/1.1
1040.757704 192.168.1.11 -> 192.168.1.1 HTTP HTTP/1.1 200 OK
1040.766226 192.168.1.12 -> 192.168.1.1 HTTP HTTP/1.1 200 OK
1044.037083 192.168.1.1 -> 192.168.1.12 HTTP GET / HTTP/1.1
1044.037089 192.168.1.1 -> 192.168.1.11 HTTP GET / HTTP/1.1
1044.049173 192.168.1.12 -> 192.168.1.1 HTTP HTTP/1.1 200 OK
1044.053683 192.168.1.11 -> 192.168.1.1 HTTP HTTP/1.1 200 OK
Step 11 Now try the SSL probe. Configure the same adjusted parameters and change the
URL requested to just a small static page.
probe https SSL-PROBE
interval 5
passdetect count 1
request method get url /small.html
You must add the probe to the server farm or rserver.
Step 12 Apply the new HTTPS probe to the server farm.
Step 13 Use the previous show probe and show probe detail commands to verify that the
SSL probe is working. Also try the show stats probe command.
Step 14 Verify that the SSL probes really are establishing SSL connections on the real
servers.
[root@linux1 ~]# tethereal -R ssl
6.109443 192.168.1.1 -> 192.168.1.11 SSLv3 Client Hello
6.118343 192.168.1.11 -> 192.168.1.1 SSLv3 Server Hello,
Certificate, ServerHello Done
6.127678 192.168.1.1 -> 192.168.1.11 SSLv3 Client Key
Exchange, Change Cipher Spec, Encrypted Handshake Message
6.136039 192.168.1.11 -> 192.168.1.1 SSLv3 Change Cipher
Spec, Encrypted Handshake Message
Step 15 Verify that the configuration is working for clients accessing the VIP from your
Client PC. Test both port 80 traffic and port 443.
that the output is still as expected.
login timeout 0


interval 5
passdetect count 1
interval 5
passdetect count 1

ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice

probe HTTP-PROBE
probe SSL-PROBE
rserver linux-1
inservice
rserver linux-2
inservice

timeout 10
serverfarm WEB-FARM


class remote-access
permit
class class-default
class VIP-WEB

interface vlan 2PC
ip address 172.16.PC.19 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
default-domain
Task 4: Create a Virtual IP Address to Accept Clear Application
Traffic
In this task, you will create a virtual IP address to accept clear application traffic.
Activity Procedure
Step 1 Create a class map for a new Layer 4 VIP.
class-map match-all VIP-APP-WEB
2 match virtual-address 172.16.PC.191 tcp eq http
Step 2 Create Layer 3 rserver entries for the two real servers.
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice
Step 3 Use the show arp command to verify that the Cisco ACE Module has network
connectivity to the real servers.
Step 4 Create a server farm to group the rservers.
serverfarm host APP-FARM
rserver linux-3
inservice
rserver linux-4
inservice
Step 5 Create a policy map for load-balancing traffic to the real servers via a server farm.
policy-map type loadbalance first-match APP-POLICY
class class-default
serverfarm APP-FARM
Step 6 Edit the existing policy map of type multi-match to associate VIP and load-
balancing policy map.
class VIP-APP-WEB
loadbalance policy APP-POLICY
policy command.
PodP-ACE/Lab-Cart-PC(config-pmap-c)# do show service-policy client-vips

Status : ACTIVE
-----------------------------------------
Interface: vlan 2PC
class: VIP-WEB
loadbalance:
L7 loadbalance policy: WEB-POLICY
dropped conns : 0
class: VIP-APP-WEB
loadbalance:
L7 loadbalance policy: APP-POLICY
dropped conns : 0

Step 8 Verify that the VIP is accessible by trying to access the VIP from your Client PC.
Only test port 80 traffic at this point.
incrementing.
login timeout 0


interval 5
passdetect count 1
interval 5
passdetect count 1

ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice

rserver linux-3
inservice
rserver linux-4
inservice
probe HTTP-PROBE
probe SSL-PROBE
rserver linux-1
inservice
rserver linux-2
inservice

timeout 10
serverfarm WEB-FARM


class remote-access
permit
class class-default
serverfarm APP-FARM
class class-default
class VIP-WEB
class VIP-APP-WEB

interface vlan 2PC
ip address 172.16.PC.19 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
default-domain
Task 5: Create a Virtual IP Address to Accept Secure
Application Traffic
In this task, you will create a virtual IP address to accept secure application traffic.
Activity Procedure
Step 1 Create a class map for the Layer 4 VIP.
class-map match-all VIP-APP-SSL
Step 2 Create a new policy map for load-balancing secure traffic to the real servers via a
server farm.
policy-map type loadbalance first-match SSL-APP-POLICY
class class-default
serverfarm APP-FARM
Step 3 Edit the existing policy map of type multi-match to associate VIP and load-
balancing policy map.
class VIP-APP-SSL
loadbalance policy SSL-APP-POLICY
policy command.
Step 5 Verify that the secure VIP is accessible by trying to access the VIP from your Client
PC.
https://172.16.PC.191/index.html
incrementing.
Task 6: Add SSL Acceleration
In this task, you will configure SSL acceleration.
Activity Procedure
Step 1 Create a private RSA key file within the ACE context. This key file will be used for
generating the certificate and to encrypt/decrypt all SSL traffic.
crypto generate key 2048 app-key
Step 2 View the private key file using show crypto key commands.
PodP-ACE/Lab-Cart-PC# show crypto key all
Filename Bit Size Type
-------- -------- ----
app-key 2048 RSA

PodP-ACE/Lab-Cart-PC# show crypto key app-key

2048 bit RSA keypair found in app-key
Modulus:
a9:46:d4:d4:e0:9b:f6:ab:e6:03:35:71:89:1c:f7:2d:69:64:a5:2e:14
:79:77:a0:bb:e4:90
:92:7f:28:2a:50:92:5b:bc:62:30:73:aa:f3:e1:7d:e3:5b:3d:6b:70:e
b:e6:84:09:5a:28:7
1:8c:19:fc:40:d8:da:77:18:7b:a4:65:55:0b:7c:45:bb:31:c2:a4:db:
7a:96:51:d4:83:47:
b3:ae:6d:01:a9:39:71:a0:be:ac:7a:7a:75:54:a4:c2:09:ad:32:3a:5a
:60:a2:30:ec:45:72
:ff:87:f5:44:d9:95:90:79:52:3d:87:fe:97:4f:1d:fd:ad:ee:2b:db:1
6:fb:6d:c6:2e:b3:5
7:38:25:a3:ad:96:6e:e4:38:25:d7:c4:82:5a:95:38:87:d1:ff:a3:28:
b5:41:2b:24:c4:47:
40:e6:5d:18:58:dc:d5:6c:c5:27:ff:f2:84:23:63:1f:34:33:c0:7c:9b
:e3:a6:91:67:48:a3
:c4:08:b3:0c:5a:c3:bc:4e:a1:ee:16:8f:c4:82:54:a6:30:ed:ca:6d:7
c:e9:32:01:a6:d8:3
7:c9:c4:a6:62:81:a1:5d:e3:c9:38:eb:d2:5b:06:b2:91:40:f3:01:9b:
3e:50:19:31:4c:2e:
63:62:61:2a:67:3a:7e:45:b8:b6:20:ac:03:89:aa:a5:
Step 3 Use the key to create a Certificate Signing Request.
Step 4 You will be asked a series of questions. The answers will be used to fill out the
certificate you are creating for the site.
PodP-ACE/Lab-Cart-PC(config)# crypto csr-params app-csr
PodP-ACE/Lab-Cart-PC(config-csr-params)# common-name
testapp.neufoo.com
PodP-ACE/Lab-Cart-PC(config-csr-params)# country US
PodP-ACE/Lab-Cart-PC(config-csr-params)# email
secofficer@neufoo.com
PodP-ACE/Lab-Cart-PC(config-csr-params)# locality SanJose
PodP-ACE/Lab-Cart-PC(config-csr-params)# organization-name
CentralIT
PodP-ACE/Lab-Cart-PC(config-csr-params)# organization-unit
Demo
PodP-ACE/Lab-Cart-PC(config-csr-params)# state California
PodP-ACE/Lab-Cart-PC(config-csr-params)# serial-number 12345
Step 5 From EXEC mode, generate the CSR.
crypto generate csr app-csr app-key
MIIC4TCCAckCAQAwgZsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MREwDwYDVQQHEwhTYW4gSm9zZTESMBAGA1UEChMJQ2VudHJhbElUMQ0wCwYDVQQL
EwREZW1vMRswGQYDVQQDExJ0ZXN0YXBwLm5ldWZvby5jb20xJDAiBgkqhkiG9w0B
CQEWFXNlY29mZmljZXJAbmV1Zm9vLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAKlG1NTgm/ar5gM1cYkc9y1pZKUuFHl3oLvkkJJ/KCpQklu8YjBz
qvPhfeNbPWtw6+aECVoocYwZ/EDY2ncYe6RlVQt8RbsxwqTbepZR1INHs65tAak5
caC+rHp6dVSkwgmtMjpaYKIw7EVy/4f1RNmVkHlSPYf+l08d/a3uK9sW+23GLrNX
OCWjrZZu5Dgl18SCWpU4h9H/oyi1QSskxEdA5l0YWNzVbMUn//KEI2MfNDPAfJvj
ppFnSKPECLMMWsO8TqHuFo/EglSmMO3KbXzpMgGm2DfJxKZigaFd48k469JbBrKR
QPMBmz5QGTFMLmNiYSpnOn5FuLYgrAOJqqUCAwEAAaAAMA0GCSqGSIb3DQEBBAUA
A4IBAQCWyT6MPhX2LuuVTatPIQcT7Rp3RfHNR7q4ezN4NePkmiXKn484NEVqAJ10
M5XBojnoIu/sF8TMlSMwbFdMvZGQhYarAAi2iZRsva99ik7y4NDuDNxeqnFOXAYa
5mlC6/BbEvUn32n3kGIrVUDiIPz3XsOnIH32z7cHRHJwHy3ETj5j60p3Fjd8PnuW
tnqc7FLf91/MuMxZZN+wbUezsnZBhTUaM7VnKkCxQdZvGkhVgktZO4NhyLIFcPp5
6PKHHEvD6gXaxRPwA55segL4jKYRKvFlycS5VixinpJf6b+k2H0yTLUS38JBvi5L
Qjgr3zbyTYLFwgvDh/sPfYbVPhTR
Step 6 Use the Telnet session you have on the Linux server. Leave the su shell (exit) and,
from the cisco users shell, save this CSR as a new file in the /tmp directory.
[cisco@linux1 ~]$ cat > /tmp/appcsr
MIIC4TCCAckCAQAwgZsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MREwDwYDVQQHEwhTYW4gSm9zZTESMBAGA1UEChMJQ2VudHJhbElUMQ0wCwYDVQQL
EwREZW1vMRswGQYDVQQDExJ0ZXN0YXBwLm5ldWZvby5jb20xJDAiBgkqhkiG9w0B
CQEWFXNlY29mZmljZXJAbmV1Zm9vLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAKlG1NTgm/ar5gM1cYkc9y1pZKUuFHl3oLvkkJJ/KCpQklu8YjBz
qvPhfeNbPWtw6+aECVoocYwZ/EDY2ncYe6RlVQt8RbsxwqTbepZR1INHs65tAak5
caC+rHp6dVSkwgmtMjpaYKIw7EVy/4f1RNmVkHlSPYf+l08d/a3uK9sW+23GLrNX
OCWjrZZu5Dgl18SCWpU4h9H/oyi1QSskxEdA5l0YWNzVbMUn//KEI2MfNDPAfJvj
ppFnSKPECLMMWsO8TqHuFo/EglSmMO3KbXzpMgGm2DfJxKZigaFd48k469JbBrKR
QPMBmz5QGTFMLmNiYSpnOn5FuLYgrAOJqqUCAwEAAaAAMA0GCSqGSIb3DQEBBAUA
A4IBAQCWyT6MPhX2LuuVTatPIQcT7Rp3RfHNR7q4ezN4NePkmiXKn484NEVqAJ10
M5XBojnoIu/sF8TMlSMwbFdMvZGQhYarAAi2iZRsva99ik7y4NDuDNxeqnFOXAYa
5mlC6/BbEvUn32n3kGIrVUDiIPz3XsOnIH32z7cHRHJwHy3ETj5j60p3Fjd8PnuW
tnqc7FLf91/MuMxZZN+wbUezsnZBhTUaM7VnKkCxQdZvGkhVgktZO4NhyLIFcPp5
6PKHHEvD6gXaxRPwA55segL4jKYRKvFlycS5VixinpJf6b+k2H0yTLUS38JBvi5L
Qjgr3zbyTYLFwgvDh/sPfYbVPhTR
Step 7 Still using the Linux session, generate a CA certificate.
[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
Step 8 Use the CA to sign the CSR.
[cisco@linux1 ~]$ openssl x509 -in /tmp/appcsr -req -days 365
-CA /tmp/rootCAcert.pem -CAkey /tmp/rootCAkey.pem -set_serial
1234 -out /tmp/appcert
Signature ok
subject=/C=US/ST=California/L=SanJose/O=CentralIT/OU=Demo/CN=t
estapp. neufoo.com/emailAddress=secofficer@neufoo.com
Getting CA Private Key
unable to write 'random state'
Step 9 View the certificate using OpenSSL.
[cisco@linux1 ~]$openssl x509 -in /tmp/appcert text
Step 10 Now import the certificate into the Cisco ACE Module.
PodP-ACE/Lab-Cart-PC# crypto import terminal app-cert
Please enter PEM formatted data. End with "quit" on a new line.
MIIC3DCCAkUCAgTSMA0GCSqGSIb3DQEBBAUAMEwxCzAJBgNVBAYTAkdCMRIwEAYD
bXBhbnkgTHRkMB4XDTA2MDkxMzEyNDcxMFoXDTA3MDkxMzEyNDcxMFowgZsxCzAJ
BgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMREwDwYDVQQHEwhTYW4gSm9z
ZTESMBAGA1UEChMJQ2VudHJhbElUMQ0wCwYDVQQLEwREZW1vMRswGQYDVQQDExJ0
ZXN0YXBwLm5ldWZvby5jb20xJDAiBgkqhkiG9w0BCQEWFXNlY29mZmljZXJAbmV1
Zm9vLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKlG1NTgm/ar
5gM1cYkc9y1pZKUuFHl3oLvkkJJ/KCpQklu8YjBzqvPhfeNbPWtw6+aECVoocYwZ
/EDY2ncYe6RlVQt8RbsxwqTbepZR1INHs65tAak5caC+rHp6dVSkwgmtMjpaYKIw
7EVy/4f1RNmVkHlSPYf+l08d/a3uK9sW+23GLrNXOCWjrZZu5Dgl18SCWpU4h9H/
oyi1QSskxEdA5l0YWNzVbMUn//KEI2MfNDPAfJvjppFnSKPECLMMWsO8TqHuFo/E
glSmMO3KbXzpMgGm2DfJxKZigaFd48k469JbBrKRQPMBmz5QGTFMLmNiYSpnOn5F
uLYgrAOJqqUCAwEAATANBgkqhkiG9w0BAQQFAAOBgQBwbF2gzGwmZvXjVKBqfQFT
6VDEYqZhaqQg4/TTQZZuhuDLFAgvg/6Wc18FkZyrqLHfBT3a1XZM5hJjYI0sAeLV
ZQUWRijjqJnX5G6iNSMrWjxbLuP210l8b/9P2zj1v0qIpUqLc9oCswhoIDlnpZqv
0E4JztvOTMvKFfHzZGU06w==
quit
Step 11 Verify that the certificate and key match.
PodP-ACE/Lab-Cart-PC# crypto verify app-key app-cert
Keypair in app-key matches certificate in appcert.
Note If the verification fails, you must fix the problem before proceeding.
Step 12 After the SSL key and SSL certificate exist within the context, they can be applied
to the ssl-proxy service.
ssl-proxy service app-ssl
cert app-cert
key app-key
Step 13 Apply the ssl-proxy service to the policy map multimatch.
class VIP-APP-SSL
ssl-proxy server app-ssl
policy command.
Step 15 Before testing the SSL acceleration, force the Cisco ACE Module to perform PAT
on the client requests so that requests to port 443 are translated (PAT) to port 80
after the traffic is decrypted. This requires removing and re-adding the existing
rservers with the destination port specified.
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 access the VIP from your Client
PC.
https://172.16.PC.191/index.html
incrementing.
login timeout 0

crypto csr-params app-csr
country US
state California
locality SanJose
organization-name CentralIT
organization-unit Demo
common-name testapp.neufoo.com
serial-number 12345
email secofficer@neufoo.com


interval 5
passdetect count 1
interval 5
passdetect count 1

ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice

key app-key
cert app-cert

rserver linux-3 80
inservice
rserver linux-4 80
inservice
probe HTTP-PROBE
probe SSL-PROBE
rserver linux-1
inservice
rserver linux-2
inservice

timeout 10
serverfarm WEB-FARM


class remote-access
permit
class class-default
serverfarm APP-FARM
class class-default
serverfarm APP-FARM
class class-default
class VIP-WEB
class VIP-APP-WEB
class VIP-APP-SSL

interface vlan 2PC
ip address 172.16.PC.19 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
default-domain

Task 7: Apply Probe and Cookie Insert Sticky to Ensure Client
Persistence
In this task, you will apply probe and cookie insert sticky to ensure client persistence.
Activity Procedure
Step 1 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 Use the show probe command to verify that the probes are working as expected.
Step 3 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 loadbalance for both
policy maps. Again, before the sticky group can be applied, the current server farm
must be removed.
class class-default
no serverfarm APP-FARM
sticky-serverfarm app-cookie
class class-default
no serverfarm APP-FARM
Step 5 Use the show sticky database static command to view the cookie insert sticky
tables.
PodP-ACE/Lab-Cart-PC(config-pmap-lb-c)# do sho sticky databas
static
sticky group : app-cookie
type : HTTP-COOKIE
to-expire flags
---------------------+--------------------------------+-----
---------+-------+
9029821149554191621 linux-3:80
never -
sticky group : app-cookie
type : HTTP-COOKIE
to-expire flags
---------------------+--------------------------------+-----
---------+-------+
439771910386717333 linux-4:80
never -
Step 6 Verify that the sticky configuration is working for clients accessing the VIP from
your Client PC. Test both port 80 traffic and port 443.
Also try the Serverstress.html page. It has about 50 images.
that the output is as expected.
login timeout 0

country US
state California
locality SanJose
serial-number 12345


interval 5
passdetect count 1
interval 5
passdetect count 1

ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice

key app-key
cert app-cert

probe HTTP-PROBE
rserver linux-3 80
inservice
rserver linux-4 80
inservice
probe HTTP-PROBE
probe SSL-PROBE
rserver linux-1
inservice
rserver linux-2
inservice

timeout 10
serverfarm WEB-FARM
cookie insert
serverfarm APP-FARM

class remote-access
permit
class class-default
class class-default
class class-default
class VIP-WEB
class VIP-APP-WEB
class VIP-APP-SSL

interface vlan 2PC
ip address 172.16.PC.19 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
default-domain
Task 8: Create a Domain for the Security Team
In this task, you will create a domain for the security team.
Activity Procedure
Step 1 Create a domain. This domain will have a user and all the objects the InfoSec team
will need so that they can apply ACL security policies.
domain infosec
Step 2 Add the current ACLs and interfaces to the infosec domain.
add-object access-list extended everyone
add-object interface vlan 2PC
Step 3 Create a new user for the security team. Give them the password neufoosec and the
role of Security-Admin and make them apart of the infosec domain. (Note that
Security-Admin is case sensitive.)
username secops password neufoosec role Security-Admin domain
infosec
Step 4 From your Client PC, create another Telnet session to the ACE context and log in as
the secops user.
C:\> telnet 172.16.PC.19
Trying 172.16.PC.19...


Username: secops
Password: neufoosec
Step 5 Using the secops account, create access lists to allow web traffic only for the two
VIPs.
access-list web line 10 extended permit tcp any host
172.16.PC.190 eq www
172.16.PC.190 eq https
172.16.PC.191 eq www
172.16.PC.191 eq https
Step 6 Apply the new access list to the client VLAN to protect the VIPs and servers.
Step 7 Verify that the ACLs block non-web traffic. You should no longer be able to
establish a Telnet connection to VIP 190. To verify this, use the cisco account and
enable logging to monitor the terminal.
Step 8 Use the show domain command to view the objects in the infosec domain. Notice
the web ACL was created within the infosec domain by default.
login timeout 0

country US
state California
locality SanJose
serial-number 12345

access-list web line 10 extended permit tcp any host 172.16.PC.190 eq www
access-list web line 20 extended permit tcp any host 172.16.PC.190 eq https

interval 5
passdetect count 1
interval 5
passdetect count 1

ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice

key app-key
cert app-cert

probe HTTP-PROBE
rserver linux-3 80
inservice
rserver linux-4 80
inservice
probe HTTP-PROBE
probe SSL-PROBE
rserver linux-1
inservice
rserver linux-2
inservice

timeout 10
serverfarm WEB-FARM
cookie insert
serverfarm APP-FARM


class remote-access
permit
class class-default
class class-default
class class-default
class VIP-WEB
class VIP-APP-WEB
class VIP-APP-SSL

interface vlan 2PC
ip address 172.16.PC.19 255.255.255.0
access-group input web
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

domain infosec
add-object access-list extended web

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
default-domain
username secops password 5 $1$ZudFMk7n$bjMjyAXHaUC8viJR6mkmq/ role Security-Adm
in domain infosec
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 a real server IP or a server network. One important aspect of
applying NAT as a subnet is that the NAT pool subnet cannot overlap the VIP, even if the VIP
would never be accessed by the NAT rule. The Cisco ACE Module ensures that duplicate IPs
cannot exist, so NAT pool networks cannot overlap VIP addresses. In this demonstration, you
will use matches based on host IPs rather than networks. Keep in mind that networks could also
be used in this type of a design.
To allow direct access to the real server, think of how flows should be manipulated if they are
initiated from the servers. This will help you align your thought process with the way the Cisco
ACE Module implements static NAT. Also realize that the pinholes created for source NAT are
applied bi-directionally; thus, if a server should be translated using source NAT to X, then
connections from the outside to X will be translated to the real server.
Activity Procedure
Step 1 Configure a class map to match the real servers initiated connections. Note that in
this scenario, 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
Step 2 Create a new policy map of type multi-match to classify server sourced traffic and
translate it to the client VLAN.
policy-map multi-match src-nat-servers
class server-initiated
Step 3 Apply the source NAT policy map to the servers VLAN.
interface vlan 4PC
service-policy input src-nat-servers
Step 4 To show that the Cisco ACE Module is properly applying NAT to client-to-server
and server-initiated traffic, run Ethereal on the client and capture on the interface
209.165.201.PC.
Step 5 When the sniffer is running, create a Telnet connection to the servers NAT address.
Verify that the server is reachable and that the IPs in the trace are as expected.
telnet 172.16.PC.250
Step 6 Now that Telnet is allowed into the real server, use this session to connect back to
the client. Verify that your Client PCs 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 the IPs in the trace are as expected.
login timeout 0

country US
state California
locality SanJose
serial-number 12345


interval 5
passdetect count 1
interval 5
passdetect count 1

ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice

key app-key
cert app-cert

probe HTTP-PROBE
rserver linux-3 80
inservice
rserver linux-4 80
inservice
probe HTTP-PROBE
probe SSL-PROBE
rserver linux-1
inservice
rserver linux-2
inservice

timeout 10
serverfarm WEB-FARM
cookie insert
serverfarm APP-FARM


class remote-access
permit
class class-default
class class-default
class class-default
class VIP-WEB
class VIP-APP-WEB
class VIP-APP-SSL

interface vlan 2PC
ip address 172.16.PC.19 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

domain infosec

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
default-domain
username secops password 5 $1$ZUdFMk7n$bjMjyAXHaUC8viJR6mkmq/ role Security-Adm
in domain infosec

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
Step 1 The security team has realized 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 network from the
web servers. InfoSec would like to restrict HTTP requests to the server farm to three
acceptable HTTP methods: GET, HEAD, and POST.
To implement this restriction, create a white list using an HTTP inspection class
map called WHITE to classify acceptable HTTP traffic.
class-map type http inspect match-any WHITE
3 match request-method rfc get
4 match request-method rfc head
5 match 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 Module to
return a reset for any traffic that does not match class WHITE by including class-
default with the appropriate action.
policy-map type inspect http all-match HTTP-INSP
class WHITE
permit
class class-default
reset
Step 3 Add the HTTP inspection policy to the multimatch policy maps to begin inspecting
all HTTP traffic for the correct HTTP methods.
class VIP-APP-WEB
inspect http policy HTTP-INSP
class VIP-APP-SSL
Step 4 Test the white list by sending a TRACE request from the client to the VIP. You can
use Telnet to send the request. You should see that connection is immediately
closed.
C:\Documents and Settings\Administrator>telnet <VIP> 80

TRACE / HTTP/1.1<HIT ENTER>
Connection to host lost.
Step 5 InfoSec would like to add basic protections to prevent application-level attacks by
restricting the length of requested URL to 45 bytes. This should help to prevent
buffer overflows.
InfoSec wants to ensure that users are never 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
Step 6 Add the blacklist with action reset to the HTTP inspection policy map that you
created earlier.
class BLACK
reset
Step 7 Verify that the blacklist rejects requests longer than 45 bytes by sending a request
such as:
https://<VIP>/index.html?long=1234123412341234123412341234
The Cisco ACE Module should send you a reset. You can test this further by
adjusting the length of the URL to see how the Cisco ACE Module 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, etc.). Make sure that the
URL admin.html cannot be accessed. Try requesting the following URL:
http://VIP_address/admin.html
Step 9 Try accessing the same URL again, but 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_address/%61dmin.html
You can use this website as a resource to help you obfuscate URLs:
http://ha.ckers.org/xss
The Cisco ACE Module 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?
Note The Cisco ACE HTTP inspection engine automatically performs URL deobfuscation. An
example of an obfuscated URL is: http://bock-bock/%7E%63%70%61%67%67%65%6E.
Phishing e-mails frequently use this technique because it can easily hide suspicious portions
of an URL and make them appear to belong to some legitimate script.
login timeout 0

country US
state California
locality SanJose
serial-number 12345


interval 5
passdetect count 1
interval 5
passdetect count 1

ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ip address 192.168.1.13
inservice
ip address 192.168.1.14
inservice

key app-key
cert app-cert

probe HTTP-PROBE
rserver linux-3 80
inservice
rserver linux-4 80
inservice
probe HTTP-PROBE
probe SSL-PROBE
rserver linux-1
inservice
rserver linux-2
inservice
timeout 10
serverfarm WEB-FARM
cookie insert
serverfarm APP-FARM

class-map type http inspect match-any BLACK
2 match url .*admin.html
3 match url length range 46 65535

class-map type http inspect match-any WHITE
3 match request-method rfc get
4 match request-method rfc head
5 match request-method rfc post


class remote-access
permit
class class-default
class class-default
class class-default
class WHITE
permit
class BLACK
reset
class class-default
reset
class VIP-WEB
class VIP-APP-WEB
class VIP-APP-SSL

interface vlan 2PC
ip address 172.16.PC.19 255.255.255.0
no shutdown
interface vlan 4PC
ip address 192.168.1.1 255.255.255.0
no shutdown

domain infosec

ip route 0.0.0.0 0.0.0.0 172.16.PC.1
default-domain
username secops password 5 $1$ZUdFMk7n$bjMjyAXHaUC8viJR6mkmq/ role Security-Adm
in domain infosec

Final Configuration Example
!Generated on 10/04/2002 08:48:55
configure
Activity Procedure
PodP-ACE/Lab-Cart-PC# checkpoint rollback baseline-mgmt
Rollback succeeded
Lab 10: Troubleshooting Case Study 1: Common
SLB Configuration Errors
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 Module is load-balancing client traffic
Visual Objective
Troubleshooting Case Study 1:
Common SLB Configuration Errors
MSFC
Catalyst 6500
Servers
X
Why cant
I get to this
website?
Cisco ACE

Required Resources
Cisco ACE Module

Task 1: Troubleshoot the First Error Case Configuration
In this task, you will review an existing configuration to determine why clients cannot
successfully connect to the VIP.
Activity Procedure
Step 2 Connect directly to the Cisco ACE management IP address for your SLB context.
C:\> telnet 172.16.PC.5
Trying 172.16.PC.5...


Username: cisco
Password: cisco123

Use the checkpoint feature to roll back to error-case-1.
PodP-ACE/Lab-SLB-PC# checkpoint rollback error-case-1
configuration
Rollback succeeded
Step 3 Use show commands to view the configuration.
Problem: Why can clients not successfully connect to the VIP and receive HTTP responses?
Step 4 Make the corrections and test to ensure that the client can successfully reach the
VIP.
http://172.16.PC.50/
You have completed this task when you have successfully load-balanced an HTTP request to
the VIP.
After you complete this task, roll back the configuration to baseline-mgmt.
Task 2: Troubleshoot the Second Error Case Configuration
Activity Procedure
Step 1 Use the checkpoint feature to roll back to error-case-2.
configuration
Rollback succeeded
VIP.
http://172.16.PC.50/
Tip Try using the show service-policy client-vips detail command.
the VIP.
Task 3: Troubleshoot the Third Error Case Configuration
Activity Procedure
configuration
Rollback succeeded
VIP.
http://172.16.PC.50/
the VIP.

Lab 11: Troubleshooting Case Study 2: Common
Layer 7 SLB Configuration Errors
Activity Objective
In this exercise, you will troubleshoot common Layer 7 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 Module is load-balancing client traffic
Visual Objective
Troubleshooting Case Study 2:
Common Layer 7 SLB Configuration Errors
MSFC
Catalyst 6500
Servers
X
Why cant
I get to this
website?
Cisco ACE

Required Resources
Cisco ACE Module

Task 1: Troubleshoot the First Error Case Configuration
Activity Procedure
Step 2 Connect directly to the Cisco ACE management IP address for your Layer 7 load-
balancing context.
C:\> telnet 172.16.PC.7
Trying 172.16.PC.7...


Username: cisco
Password: cisco123
PodP-ACE/Lab-L7-PC#
VIP.
http://172.16.PC.71/
the VIP.

Acesm20 LG

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Acesm20 LG

Transféré par

Droits d'auteur :

Formats disponibles

ACESM

Vous aimerez peut-être aussi