ACE Student Guide PDF

Table of Contents
Implementing the Application Control Engine Appliance

Overview
Objectives
Course Goal and Objectives
Course Flow
Additional References
Introducing the ACE 4710 Appliance

Overview
Objectives
IP Protocol Stack Review
IP Application Review
Web Technology Overview
Client/Server
User Agent
Server Caveats
Introducing ACE
Summary
Deploying ACE
Overview
Objectives
Connecting the ACE to the Network
ACE Installation Procedure
ACE Appliance GUI
Network Topologies
SNAT
Policy-Based Routing
Virtualization
Resource Management
Authorizing Management Users
Configuring Interfaces
Summary
Modular Policy CLI
1
1
1
3
4
5
7
7
7
8
16
29
47
47
47
48
61
63
63
63
64
66
69
71
73
74
81
90
99
107
111
113
Overview
Objectives
Class Maps
Syntax Summary
Policy Maps
Policy Type
Match Type
Syntax Summary
Applying Policy Maps
Primary Policy Maps
Secondary Policy Maps
Summary
113
113
114
121
123
126
126
131
133
136
136
140
Managing the ACE Appliance
141
Overview
Objectives
Permitting Management Traffic
SNMP Manageability
Summary
141
141
142
148
156
Security Features
Overview
Objectives
IP Access Control Lists
TCP/IP Fragmentation/Reassembly
TCP/IP Normalization
Network Address Translation
Summary
Layer 4 Load Balancing

Overview
Objectives
Load-Balancing Concepts
Client 1
Client 2
Client 3
Client 4
Load-Balancing Algorithms
Configuring Layer 4 Load Balancing
Monitoring rservers
Summary
Health Monitoring
Overview
Objectives
Health Monitoring Overview
Active Health Probes
No ip address Command in Probe
Optional ip address Command Without routed Keyword
Optional ip address routed Command
HTTP Error Code Monitoring
Using TCL Scripting
Summary
Layer 7 Protocol Processing

Overview
Objectives
Configuring HTTP Layer 7 Load Balancing
Persistent and Pipelined HTTP Extensions
Server Reuse
Session Persistence
Protocol Inspection
HTTP Inspection
FTP Protocol Processing
Other Inspected Protocols
Summary
Processing Secure Connections

Overview
Objectives
Digital Encryption Technologies
SSL Service Options
Configuring a Public Key Infrastructure
Configuring SSL Proxy Services
Summary
ii
Implementing the Cisco ACE Appliance (ACEAP) v1.0
157
157
157
158
160
164
170
178
179
179
179
180
188
189
189
189
195
198
198
206
207
207
207
208
214
215
216
216
232
234
240
241
241
241
242
250
254
257
267
268
270
274
281
283
283
283
284
291
294
301
307
2007 Cisco Systems, Inc.
Deploying Application Acceleration and Optimization

Overview
Objectives
Web Application Acceleration Architecture
FlashForward
Delta Optimization
Delta Optimization Requirements
Delta Optimization Base Files
Delta Optimization Canonicalization
Smart Redirect
Fast Redirect
FlashConnect
Just-in-Time Object Acceleration
Adaptive Dynamic Cache
Compression Overview
Request Processing
Response Processing
Summary
309
309
310
312
324
325
326
326
329
330
331
332
333
334
335
335
338
High Availability
339
Overview
Objectives
Redundancy
Object Tracking
Failover
State Replication
Fault-Tolerance Configuration
Displaying Fault-Tolerance Information
Summary
339
339
340
344
347
349
352
358
363
Integrating Multiple Features
365
Overview
Objectives
Analyzing Network Requirements
Designing ACE Contexts
Designing ACE Features
Configuring Multiple Integrated Features
Summary
365
365
366
371
376
384
392
Summary
Self-Check
393
395
Self-Check Answer Key
309
397
iii
iv
ACEAP
Implementing the Application

Control Engine Appliance
Overview
In this course, you will learn how to deploy and configure intelligent network services using the
Cisco Application Control Engine (ACE) appliance.
Objectives
Upon completing this lesson, you will be able to describe how to deploy and configure
intelligent network services using the Cisco ACE appliance. This includes being able to meet
these objectives:
Describe the course goal and objectives
Present the suggested flow of the course materials
Present the Cisco icons and symbols that are used in this course, and information on where
to find additional technical references
Learner Skills and Knowledge

Familiarity with TCP/IP protocol suite
Knowledge of HTTP and SSL protocols
Basic understanding of n-tier application architecture
Basic understanding of server load balancing concepts
2007 Cisco Systems, Inc. All rights reserved.
ACEAP v1.01-2
The figure lists the skills and knowledge that you must possess to benefit fully from the course.
Course Goal and Objectives

This topic describes the course goal and objectives.
Course Goal
Deploy and configure intelligent network services
using the Cisco 4710 Application Control Engine
appliance.
Implementing the Cisco ACE Appliance
ACEAP v1.01-4
Upon completing this course, you will be able to meet these objectives:
Describe IP application delivery with the Cisco Application Control Engine (ACE)
appliance
Describe the configuration tasks necessary to successfully deploy an ACE appliance
Describe the structure and function of the Modular Policy CLI statements used to configure
ACE features
Describe the methods used to manage the ACE appliance
Describe the ACE features that provide IP application-based security on the ACE appliance
Describe the capabilities and configuration of the ACE features used to provide load
balancing of IP-based applications
Describe the health monitoring capabilities of the ACE appliance
Identify the Layer 7 processing options used to provide advanced application networking
Describe the ACE support for SSL protocol processing
Describe the ACE web application acceleration, optimization, and compression features
Describe the high-availability features of the ACE appliance, which are used to provide
reliable application networking services
Describe a methodology used to design and configure multiple ACE features
Course Flow
This topic presents the suggested flow of the course materials.
Course Flow
A
M
DayDay
4 5
Day 1
Day 2
Day 3
Introducing ACE
Layer 4 Load
Balancing
Processing
Secure
Connections
Integrating
Multiple Features
Health Monitoring
Labs
Labs
Deploying ACE
High Availability
Lunch
Modular Policy
CLI
P
M
Layer 7 Protocol
Processing
WAA Features
Managing the
ACE appliance
Labs
Security Features
Labs
Labs
Labs
ACEAP v1.01-6
The schedule reflects the recommended structure for this course. This structure allows enough
time for the instructor to present the course information and for you to work through the lab
activities. The exact timing of the subject materials and labs depends on the pace of your
specific class.
Additional References
This topic presents the Cisco icons and symbols that are used in this course, and information on
where to find additional technical references.
Cisco Icons and Symbols

Cisco MDS 9500
Multilayer Director
IP Router
Ethernet Switch
Cisco MDS 9200

Multilayer Switch
Multilayer Switches
Cisco MDS 9100

Fabric Switch
Firewall
Third-Party FC
Director
ACE
ACEAP v1.01-8
These are some of the icons and symbols that you will see throughout this course.
Cisco Icons and Symbols (Cont.)

Application Server
FC JBOD
FC
Application Server
with FC HBA
HBA
FC
iSCSI
FC RAID
Subsystem
Application Server
with iSCSI
FC
NAS
NAS Filer
FC Tape
Subsystem
Workstation
ACEAP v1.01-9
For more information on Cisco terminology, see the Cisco Internetworking Terms and
Acronyms glossary of terms at
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/index.htm.
Lesson 1
Introducing the ACE 4710

Appliance
Overview
In this lesson, you will learn how to describe IP application delivery with the Cisco 4710
Application Control Engine (ACE) appliance and how to describe the features of the ACE
appliance and compare them with those of the rest of the Cisco family of content switches.
Objectives
Upon completing this lesson, you will be able to describe IP application delivery with the ACE
4710 appliance and introduce the features of the ACE 4710 appliance. This includes being able
to meet these objectives:
Describe the fundamentals of IP-based communications
Describe the fundamentals of IP-based applications
Describe HTTP-based applications
Describe the Cisco 4710 Application Control Engine appliance
IP Protocol Stack Review

This topic describes the fundamentals of IP-based communications.
IP Protocol Stack
Application Protocols
TCP
UDP
IP
Physical and Data

Link
Application protocols define the data payload format

used by individual IP-based applications.
TCP and UDP define program-to-program

communication.
IP defines system-to-system communication.
Physical and data link define how IP is transmitted on

individual media types.
ACEAP v1.01-4
IP networks are widely deployed and provide data transport for a large percentage of modern
data networks. The IP stack consists of the Internet Protocol and all the protocols that depend
on IP for network services.
The IP stack is often represented as a four-layer architecture. From bottom to top, these layers
are as follows:
Physical and data link protocols define how IP uses each supported physical media type to
transmit data.
IP itself defines system-to-system communication. Parts of IP address such issues as the

addressing scheme used to uniquely identify individual systems, the mechanisms used to
route traffic from one physical network to another, and the format of IP packets. IP
provides connectionless, best-effort communications between systems. The best-effort
nature of IP implies that no reliability guarantees are built into IP. For example, an IP
packet can be dropped by a network resource if necessary. IP provides a notification
mechanism if this happens but does not provide any recovery mechanisms.
TCP and User Datagram Protocol (UDP) define program-to-program communication. This
is done by adding more addressing, in addition to the IP address, in the form of port
numbers. A particular TCP or UDP port is associated with an individual program or
process that is using the IP network for communications. Notice that TCP or UDP port
numbers are significant only within a particular computer system. TCP and UDP also
describe the format of their respective packets. TCP adds additional functionality and
provides reliable data transmission. TCP does this through acknowledgment,
retransmission, and flow-control functions, which are part of the TCP specification.
Application protocols define the format and meaning of the data portion of a TCP or UDP
packet. Examples of application protocols are the Simple Mail Transfer Protocol (SMTP),
which describes how to transmit e-mail from one system to another, and the HTTP used to
request and transmit web pages.
One important aspect of a layered architecture is the encapsulation of higher-level packets in

lower-level packets. The lower-level protocol builds a packet that has headers appropriate to
that protocol and places the higher-level packet in the data portion of the new protocol. For
example, an HTTP request is contained in the data portion of a TCP packet. The headers of the
TCP packet contain header values used by TCP, including the port number that is being used by
the web server process on the target computer system. The TCP packet is placed in the data
portion of an IP packet, which is routed to the destination system. The IP packet contains IP
headers that specify items necessary for IP processing, including the IP address of the
destination system. The IP packet is placed in the data portion of one or more physical frames,
which are transmitted across the physical media for each link in the IP network. This frame has
headers that are used by the underlying transmission medium to process the frame.
Understanding ACE operations requires an understanding of IP, TCP, and UDP.
IP Header Fields
Physical
Header
Version
IP Hdr
20 bytes Protocol Data: ICMP, TCP, UDP
Header
Length
Type of Service
Flags (3
bits)
Identification
Time to Live
Total Length (in bytes)
Protocol
Fragment Offset
Header Checksum
Source IP Address
Destination IP Address
ACEAP v1.01-5
IP packets contain a standard 20-byte header, the layout of which is diagrammed in the figure.
The highlighted fields are the most important to understand when designing ACE solutions.
Optional header fields exist and are placed after the standard headers.
The standard IP header fields are:
10
Version: Four bits that specify the version of the IP protocol used by the packet. IP
Version 4 (IPV4) is the most prevalent version in modern networks. IP Version 6 (IPV6),
also known as IP Next Generation (IPNG) is a newer version of the IP protocol that has
been developed and is now supported by major network vendors including Cisco. This
course concentrates on IPV4; however, the concepts outlined here are applicable to IPV6.
Header length: 4 bits that specify the length of the IP header in 32-bit words. The standard
IP header carries a header length of 5. The maximum length of the IP header is 15 words or
60 bytes.
Type of service (ToS): 8 bits that describe the performance characteristics of the service
requested for this packet. ToS is used by quality-of-service (QoS) algorithms to schedule
packet transmission and to drop lower-priority packets if necessary.
Total length: 16 bits that specify the total byte count in the IP packet. This total length
includes the bytes in the header.
Identification: 16-bit field that contains a number identifying this packet. This field is used
to associate the fragments of a fragmented IP datagram together.
Flags: 3 bits, of which only two are used. The first is reserved. The second bit is used to
indicate that a packet should not be fragmented (the Do Not Fragment flag). The third bit is
used to indicate that More Fragments follow this one. If an IP datagram is fragmented, the
More Fragments flag is set on all fragments except the last one.
Fragment offset: 13 bits used to specify the offset at which the data in this fragment
should be placed in the reassembled IP datagram. The fragment offset counts groups of 8
bytes.
Time to Live: 8 bits that indicate how many hops the IP packet can transit. Each router
decrements the Time to Live (TTL) value when it moves a packet from one physical
network to another. If the TTL reaches 0 the packet is dropped.
Protocol: 8 bits that specify the upper-level protocol contained in the packet.
Header checksum: 16-bit checksum value used to detect corruption of any header values.
Source IP address: 32-bit address of the transmitting system.
Destination IP address: 32-bit address of the destination system.
11
UDP Header Fields

Physical
Header
IP Hdr
UDP Hdr
20 bytes 8 bytes
Application Data
Source Port Number
Destination Port Number
Length
Checksum
ACEAP v1.01-6
UDP datagrams contain a standard 8-byte header, the layout of which is diagrammed in the
figure. The fields most relevant to ACE services are highlighted.
The UDP header fields are:
Source Port Number: The 16-bit port address used by the sending process. The operating
system on the transmitting system provides a means to map the port number to the
appropriate process.
Destination Port Number: The 16-bit port address used by the receiving process. The
operating system on the receiving system provides a means to map the port number to the
Length: 16 bits that contain a count of the bytes in the UDP datagram including both the
header and the data.
Checksum: The 16-bit checksum used to detect corruption in the datagram. The UDP
checksum actually covers more fields than just the UDP header and the data field: the
source IP address, the destination IP address, and the protocol field in the IP header are also
included in the checksum calculation.
Note
12
The IP address and the UDP/TCP port number for the end of a particular flow of packets is
often written as [ip-address]:[port-number] or [domain-name]:[port-number]; for example,
198.133.219.25 :80 or www.cisco.com:80 specifies the well-known port for the
www.cisco.com web server.
TCP Header Fields

Physical
Header
IP Hdr
TCP Hdr
20 bytes 20 bytes Application Data
Source Port Number

Sequence Number
Acknowledgment Number
Header
Length
Reserved (6
bits)
Flags (6 bits)
TCP Checksum
Window Size
Urgent Pointer
ACEAP v1.01-7
TCP segments contain a standard 20-byte header, the layout of which is diagrammed in the
figure. The fields most relevant to ACE services are highlighted.
The standard TCP header fields are:
Source port number: The 16-bit port address used by the sending process. The operating
system on the transmitting system provides a means to map the port number to the
Destination port number: The 16-bit port address used by the receiving process. The
operating system on the receiving system provides a means to map the port number to the
Sequence number: The 32-bit number used to indicate the position in the senders byte
stream of the data in this segment. When a TCP connection is opened, a system establishes
a starting sequence number. The sequence number is incremented for each data byte
transmitted.
Acknowledgment number: 32-bit number used to indicate the sequence number of the
next byte that it is expected to receive.
Header length: 4-bit number containing the number of 32-bit words in the TCP header.
Flags: Six flags used for TCP connection and flow control: urgent (URG),
acknowledgment (ACK), push (PSH), reset (RST), synchronize (SYN), and finish (FIN).
Windows size: 16-bit counter of the number of bytes the receiver is still capable of
receiving.
TCP checksum: 16-bit field used to detect data corruption. The TCP checksum covers the
entire TCP segment and the source and destination address, protocol, and length fields from
the IP packet.
Urgent pointer: 16-bit field that points to the last byte of urgent data.
13
TCP Connection
Client
Server
SYN
Initialize
SYN-ACK
ACK
Data
ACK
Data
Use
More Data
ACK
FIN
Close
ACK
FIN
ACK
ACEAP v1.01-8
Protocols that use TCP for transport must first establish a TCP connection. After the connection
is established, application-level data can be transmitted. The figure shows a use of TCP: a web
client establishes a TCP connection with a web server to retrieve information.
TCP connections use a 32-bit sequence number to count each byte of transmitted data. When a
TCP connection is initialized, each system determines the sequence number to use to start the
byte numbering for data it transmits on that connection. This sequence number is then
transmitted to the communications partner. TCP acknowledges the receipt of data by
transmitting acknowledgments that indicate the next expected sequence number. For example,
if an acknowledgment contains the sequence number 64125, all bytes up to and including
64124 have been received.
The TCP packet header contains six flags, three of which are used in the normal setup and
teardown of a TCP connection. These flags are:
SYN: A packet with the SYN flag set is used to synchronize the sequence numbers; this
informs the receiver what sequence number the sender intends to use to start counting
transmitted data.
ACK: A packet with the ACK flag set acknowledges how much data has been received by
the system sending the ACK packet.
FIN: A packet with the FIN flag set indicates that the sending system has finished sending
data and wants to gracefully close the connection.
Many TCP packets have some combination of flags set. For example, a SYN-ACK packet
signifies that this packet is synchronizing the sequence number to be used in one direction and
at the same time acknowledging the packets received in the opposite direction.
14
The figure shows the packet flow throughout each phase of a TCP connection:
Initialize: A client normally starts a TCP connection by sending a SYN packet. The server
responds with a SYN-ACK, which the client then acknowledges with an ACK packet. At
this point, the connection is ready for use.
Use: Data is transmitted by each system as appropriate. Multiple data packets can be sent in
one direction before they are acknowledged by the receiving system.
Close: Each system informs its communications partner that it is done sending data and
wants to close a connection by transmitting a FIN packet. When each side has transmitted
and acknowledged a FIN packet, the connection is closed.
15
IP Application Review
This topic describes the characteristics of the prominent IP-based applications and the
underlying technologies.
OSI Layers
7
Application
Presentation
Session
Transport
Network
IP
Data Link
Physical
Link and Physical

Protocols
ISO OSI Stack
Application Protocols
TCP / UDP
TCP/IP Stack
ACEAP v1.01-10
The Open Systems Interconnection (OSI) suite of protocols developed by the ISO defines a
seven-layer network model. The seven layers in the OSI model are:
16
Physical: Defines the connectors and electrical characteristics of a networking technology
Data Link: Defines how devices are addressed and how data is presented and transmitted
over the physical medium
Network: Defines device addressing, services, and data formats that are used to provide
consistent services over many different physical media
Transport: Defines data transit management services such as end-to-end error recovery
and flow control
Session: Defines connections between applications
Presentation: Defines transformations that application data might need to undergo for
transport on a network (for example encryption)
Application: Defines the individual applications and how they transmit and receive
information
The TCP/IP protocol stack uses layer boundaries that are different from those of the OSI
model. However, even when content switching in a TCP/IP environment is described, it is
referred to as the corresponding OSI layers. The figure shows how the seven-layer OSI model
maps to the TCP/IP stack, which is generally defined with four layers.
In general, the OSI layer numbers are used to describe products and the functionality they
provide. For example, Layer 3 and 4 switching devices make switching decisions based on the
information in the IP or TCP/UDP layers. TCP/UDP application layer processing is usually
referred to as Layer 57 switching or just Layer 7 switching.
17
IP-Based Application: HTTP

Web
Server
Client
GET / HTTP 1.0

ACK
HTTP/1.0 200 OK
Continuation
ACK
ACEAP v1.01-11
After a TCP connection is established, the client sends requests to the server. The format of
these requests is defined by the individual protocol specification for the service the client is
requesting.
For example, a web request using HTTP has specific characteristics. The RFCs that describe
HTTP refer to method tokens to define the type of request being sent. The most common
methods are the following:
GET: Used to retrieve information from the web server
POST: Used to send form data to the web server
PUT: Used to send data for the web server to store
The standard HTTP request includes a method token, a path to the resource being acted upon,
and the HTTP version number used in the request.
Web server responses start with a numeric return code and a description of the return code. The
meaning of the possible return codes is defined by the HTTP specification and is processed by
the web client. The description of the return code is often used to provide additional readable
information, which can be provided to the end user.
Web server responses then contain any data to be presented to the end user as a result of the
HTTP request. These responses can span several TCP packets.
HTTP has two versions in use, version 1.0 and version 1.1. HTTP interactions include version
information in both the request and the response.
18
This example shows a GET request. The GET request includes the URL of the resource being
requested (/) and the version of the HTTP protocol being used (1.0). The response starts with a
return code or retcode (200) and description (OK), followed by the data, which requires a
second packet. Finally, the client acknowledges receipt of the data.
For more information on HTTP, see the relevant RFCs: RFC1945 for HTTP Version 1.0, and
RFC 2616 and RFC 2817 for HTTP Version 1.1.
Tip
A good source for Internet RFCs is http://www.rfc-editor.org.
19
Layer 4 Switching
Layer 4 information is always present in the first packet of the flow:
IP protocol
Source and destination IP addresses
Source and destination port addresses (for TCP/UDP)
The load-balancing decision is made on the first packet.
Client Side
Server Side
ACEAP v1.01-12
Layer 3 and 4 information in the packet includes the following fields:
IP Protocol: This field is used to differentiate between the higher level protocols such as
UDP and TCP that are supported by IP.
Source and destination IP addresses: The IP address of the transmitting system and the
intended recipient.
Source and destination port: The port number being used on the transmitting system and
the intended recipient.
Note
Port numbers are used to direct the IP traffic to a particular application process such as a
web client or server. Well-known port numbers are defined for most IP-based services. For
example, port 80 is used for HTTP.
Layer 4 content-switching decisions can be based on any of the Layer 4 fields listed above.
With TCP connections, the Layer 4 information is consistent for all packets in the connection.
The Layer 4 information is often said to define a flow, which is the communication path for a
particular connection.
The figure shows a flow of packets coming from the client side of the network to a ACE. The
ACE examines the first packet in a new flow or connection and a Layer 4 switching decision is
made for the flow as a whole. The content switch makes this decision and then records the flow
parameters and the switching decision. This table of switching decisions is used to switch every
subsequent packet in the flow. Information is removed from the switching table when a
connection is closed. In the case of Layer 4 switching of TCP packets, these decisions are
normally made on the basis of SYN and FIN packets and are done at TCP connection setup and
termination. Reset (RST) packets are also analyzed because they are used to refuse a
connection when it is requested or to abort an existing connection.
20
Layer 7 Switching
Layer 57 information
Received only after TCP connection setup
Might span multiple IP packets
Requires TCP termination and buffering
SYN
SYN_ACK
SYN
SYN_ACK
1
ACEAP v1.01-13
Information about layer 7 is available only after application data has been transmitted, but
transmission requires that the TCP connection be fully functional, leading to a dilemma. A
server must respond to the client to fully start the TCP connection before the client sends the
Layer 7 information that the content switch needs to select the server.
The content switch handles this dilemma by buffering client data and temporarily acting as a
server. To do this, the content switch responds to the incoming SYN packet with its own
SYN_ACK. The content switch then buffers packets until it has enough Layer 7 information to
make a load-balancing decision.
After a destination server has been selected, the content switch must make a connection to the
server on behalf of the client. To establish the TCP connection to the server, a SYN packet is
sent to the server and then the ACE waits for the SYN_ACK packet to be sent from the server.
At this point all buffered packets received from the client are sent to the server.
After the buffered packets have been sent, the two TCP connections can be spliced together by
the content switch. This splicing is done by receiving packets from one connection and
retransmitting them to the other.
Because there are two different TCP connections from the content switch, one to the client and
one to the server, there are probably two sets of sequence numbers in use, one on each
connection. The content switch translates the sequence numbers from one connection to the
other.
21
Digital Encryption
ACEAP v1.01-14
Encryption transforms data in ways that can be used to provide security. Unencrypted data is
often referred to as plaintext, and encrypted data is referred to as cipher text. A pair of
algorithms are used, one for encryption and one for decryption. Plaintext is encrypted to yield
cipher text, and cipher text is decrypted to yield plaintext. Encryption algorithms are designed
in such a way that the cipher text is unusable without specialized or secret knowledge. The
complexity of the algorithm and the specialized or secret knowledge affect the amount of
security provided by the encryption algorithm.
For example, you might take every byte of a data message and invert the order of the bits to
encrypt it. This does, in fact, create cipher text but it is not usable. The problem is that as soon
as the algorithm becomes known, the knowledge required to recover the plaintext is not secret.
This encryption algorithm is therefore not very secure.
Modern encryption algorithms are much more complicated. However, security that requires the
algorithm itself to stay secret does not last. Instead, modern encryption algorithms use a second
piece of data to modify the results of the process. This second piece of data is referred to as the
key. Modern encryption algorithms are designed so that a single plaintext data block encrypted
with two different keys results in two different cipher texts.
The figure shows the encryption and decryption process. Plaintext on the left is modified by a
key-based encryption algorithm to produce the cipher text in the middle. This cipher text is then
modified by a key-based decryption algorithm to produce a copy of the original plaintext.
22
Stateful Packet Filtering

Web Server
DMZ
Outside Network
Inside Network
Internet
State Table
Entries for each active connection:
Source and destination addresses
Source and destination ports
Sequence numbers
TCP flags
Source
Destination
Permitted?
Outside
DMZ:80
Yes
Outside
DMZ:!80
No
DMZ
Any
Yes
Inside
Any
Yes
Outside
Inside
Established Session
No
Yes
ACEAP v1.01-15
A firewall technology that is used in modern firewall products including the ACE module is
stateful packet filtering. Firewalls employing stateful packet filtering use defined policy entries
to determine under what conditions a connection can be initiated. When a new connection is
detected, it is added to the state table. Packets that are not initiating connections but that are
consistent with the information in the state table are allowed to pass through the firewall.
New connection detection for TCP is a matter of looking for TCP SYN packets. Because UDP
does not use connections, a connection entry is created the first time a packet is allowed by the
policy table. Any other UDP packets that match the source and destination information in the
state table are allowed.
Entries are removed from the state table when no longer needed. Again, this is easy to detect in
TCP because the firewall sees the FIN packets used to close a connection. UDP entries are
removed from the state table after a period of inactivity.
23
Network Address Translation Terminology
Internal Network
External Network
Inside Systems
Outside Systems
IL
OL
Local Addresses
IG
OG
Global Addresses
Source
Destination
Source
Destination
Inside Local
Outside Local
Inside Global
Outside Global
Source
Destination
Source
Destination
Outside Local
Inside Local
Outside Global
Inside Global
ACEAP v1.01-16
Network Address Translation (NAT) translates addresses when traffic transits between two
networks. These two networks are considered the internal and external networks from the
perspective of the NAT function.
NAT uses two different but closely related pairs of termsinside and outside, and local and
globalto describe systems attached to and addressing used by internal and external networks.
These terms are defined as follows:
Inside addresses represent systems attached to the internal network.
Outside addresses represent systems attached to the external network.
Local addresses are addresses that are valid on the internal network. They are used in
packets transiting the internal network.
Global addresses are addresses that are valid on the external network. They are used in
packets transiting the external network.
The packet flows shown at the bottom of the figure also illustrate how the addresses are used.
24
Network Address Translation Example

Internal Network
10.0.0.0/24
IL
External Network
198.133.219.0
OL
IG
OG
10.0.0.83
198.133.219.25
Source
Destination
Source
Destination
10.0.0.83
198.133.219.25
198.133.219.83
198.133.219.25
Source
Destination
Source
Destination
198.133.219.25
10.0.0.83
198.133.219.25
198.133.219.83
ACEAP v1.01-17
The figure shows destination NAT. The network address has an internal network of 10.0.0.0/24
and an external network of 198.133.219.0/24. Network translation is being used to allow a
system on a private network address space used on the internal network to communicate with a
web server that is on the public, external Internet. To perform this function, the network
translation on the firewall is configured to translate the IP address of the inside system to a
valid address in the outside network. An address with the same last octet has been allocated for
this purpose.
25
Network Address Translation Example 2

Internal Network
10.0.0.0/24
IL
External Network
198.133.219.0
OL
IG
OG
10.0.0.83
198.133.219.25
Source
Destination
Source
Destination
10.0.0.83
10.0.0.25
198.133.219.83
198.133.219.25
Source
Destination
Source
Destination
10.0.0.25
10.0.0.83
198.133.219.25
198.133.219.83
ACEAP v1.01-18
The figure shows both source and destination NAT. This example of a network address
translation has an internal network of 10.0.0.0/24 and an external network of 198.133.219.0/24.
Network translation is being used to allow two systems with IP addresses of 10.0.0.83 and
198.133.219.25 to communicate without knowing about the other network. Translation is set up
to leave the last octet of the IP address unchanged.
26
Port Address Translation Example

10.0.0.83
Internal Network
10.0.0.0/24
External Network
198.133.219.0
198.133.219.25
10.0.0.84
Source
Destination
Source
Destination
10.0.0.83:2418
198.133.219.25:80
198.133.219.83:2418
198.133.219.25:80
Source
Destination
Source
Destination
10.0.0.84:2417
198.133.219.25:80
198.133.219.83:2417
198.133.219.25:80
Source
Destination
Source
Destination
10.0.0.84:2418
198.133.219.25:80
198.133.219.83:2419
198.133.219.25:80
ACEAP v1.01-19
Port Address Translation (PAT) adds port numbers to the translation table. A typical use of
PAT is to provide network access for a large internal network while conserving addresses in the
external network. In this example, one address is used in the external network to provide access
for an internal network with a Class C worth of hosts. The packets show two different systems
generating requests to a web server.
The first request comes from the top system in the internal network. The request is translated on
the external network to use a single outside local address as the source. Because no other
connections are currently using this outside local address, the port number is maintained
through the translation.
A second request comes from the bottom system in the internal network. Again, it is translated
to use the same outside local address as the source address for these packets. No other
connection is currently using the port number in the request, so you can maintain the port
number through the translation.
The third request again comes from the bottom system in the internal network. Again, it is
translated with the single outside local address; however, this time there is a conflict with the
source port that is used by the client. This port is translated to a different port, which is unique
on the IP address being used as the outside local address.
27
Simple Network Management Protocol

Managed
Device
NMS
GET OID
Data
SET OID
Response
Trap
ACEAP v1.01-20
Simple Network Management Protocol (SNMP) provides methods for remote management of
network attached devices. The managed devices contain a software component that is referred
to as the SNMP agent. This component talks to the Network Management Station (NMS) with
SNMP.
The figure shows the major interactions that most devices utilize out of the entire protocol.
The top interaction shows the NMS retrieving management data from the managed device. This
is done by sending a GET request (of which there are several variations) to the managed device.
The GET request specifies the object ID (OID) of the management information to be retrieved.
OIDs are a hierarchical, numerical namespace used to identify individual manageable
attributes. Most NMSs use data in an MIB definition to associate OIDs with human-readable
variable names.
The middle interaction shows the NMS using a SET request to modify the operation of the
managed device. Some devices support full configuration activities through SNMP SET
commands.
The bottom interaction shows the managed device sending an unsolicited alert message called a
trap to the NMS. SNMP traps are often used to communicate error indications.
28
Web Technology Overview

This topic describes the fundamentals of HTTP applications.
HTTP
Client Request
Server Response
ACEAP v1.01-22
HTTP is the most common application protocol for transferring resources on the web. HTTP
defines the format and meaning of messages exchanged between systems. There are two
categories of HTTP messages: request and response. Requests come from clients, and
responses are sent by HTTP servers.
All HTTP messages are made up of three fields:
Start line: Specifies the method or reason for the message. The method is a verb or action
word, such as GET.
Header fields: Zero or more header fields follow the start line.
Body: The body is optional and can contain any kind of data, such as web pages and image
and audio files.
There are two main versions of HTTP in use: HTTP/1.0 and HTTP/1.1. This overview deals
specifically with HTTP/1.1.
HTTP is a stateless protocol; there is no awareness of previous sessions or conversations, either
on the client or on the server. The clients and servers can cache information that they receive
from the request-response process, but they do not track the previous conversations in the
HTTP protocol. The original intent for not maintaining state was to provide scalability for web
servers. If a server needed to maintain state for a large number of clients connections, the use
of resources (such as memory and CPU cycles) and the time for connections would increase,
degrading both the client and the server sessions. For applications that require state to be
maintained across multiple HTTP requests, other enhancements and headers are included (such
as cookies), or other protocols and applications are used.
For more information, see http://www.ietf.org/rfc/rfc2616.txt.
29
HTTP Uniform Resource Identifiers
http://www.cisco.com:80/US/partner/index.html
Scheme
Host
Optional Port
Path and/or Filename
GET /US/partner/index.html HTTP/1.1
Host: www.cisco.com
User-Agent: Mozilla/5.0 (Windows; rv:1.8.1.6) Firefox/2.0.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
ACEAP v1.01-23
The figure shows the different elements of a URL, which is a specialized form of a Uniform
Resource Identifier (URI), and where these fields are located in the HTTP request header.
Every resource (for example, HTML page, image file, script) on a server has a distinct name
that the client identifies it by. The client requests a specific resource with a URI. URIs have
been known by many names: WWW addresses, Universal Document Identifiers, and most
often as URLs.
URIs have a simple format that identifies three pieces of information: scheme or protocol,
location or Internet address (name or IP address), and a resource (such as path, file, or
mailbox).
http://hostname/path
ftp://host/file
mailto:mailbox@domain
URIs in HTTP can represent an absolute path or a relative path. The syntax of an absolute and a
relative path contain the same information, but in a relative path some information is implied.
For example:
Absolute path, http://www.cisco.com/US/partner/index.html:
30
Protocol: HTTP over TCP is the protocol to use when communicating with this resource.
This usually also implies the destination port, unless explicitly cited differently from the
default port for this protocol. For example, the default port for HTTP communications is
TCP port 80, but if :8080 were added to the end of the domain name/IP address of the URI,
the client would establish a TCP connection with port 8080 instead (that is,
http://www.example.com:8080/somepath).
Host: The hostname or IP address identifies the target system to which to connect (using
the protocol already specified by the first part of the URI).
Path and/or Filename: The URI path similar to a file path on a system (such as Windows
or UNIX). HTTP URIs are formatted using the UNIX file convention a/b/c.
Relative Path:
./example.jpg: This implies that protocol, host, and path remain unchanged, but instead of
looking for the index.html (from the absolute path example), look for the image
example.jpg in the same directory on the HTTP server. This could be expanded to
http://www.cisco.com/US/partner/example.jpg.
/swa/i/logo.gif: This implies that protocol and host remain unchanged but now look for the
image file logo.gif in the new absolute path specified relative to the host root directory.
This could be expanded to http://www.cisco.com/swa/i/logo.gif.
test/somefile.html: This implies that protocol and host remain unchanged and append the
directory test to the end of the original directory /US/partner/. This could be expanded to
http://www.cisco.com/US/partner/test/somefile.html.
For more information on URIs, see http://www.ietf.org/rfc/rfc3986.txt.
31
HTTP Request Methods
Client Request

Host: www.cisco.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; enUS; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Accept: text/xml,application/xml,application/xhtml+xml,
text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Keep-Alive: 300
HTTP Request
Methods
GET
HEAD
POST
PUT
DELETE
TRACE
OPTIONS CONNECT
ACEAP v1.01-24
HTTP supports several different request commands, called HTTP methods. Every HTTP
request uses a method. The client sends an HTTP request to the web server. The HTTP request
method tells the server what kind of response the client wants to receive or what to do with the
request.
There are eight defined request methods in HTTP/1.1. Not all HTTP servers implement all
methods; all servers are supposed to accept GET, HEAD, and if possible, OPTIONS methods.
32
GET: Retrieve whatever information is identified by the request. The client requests a
resource identified by the URI. Another option that can be included with a GET request is
an If-Modified-Since message, which transforms the GET request into a conditional GET.
A conditional GET retrieves the information only if the condition is met. It is also possible
to perform a partial GET, and send a range in the request.
HEAD: The HEAD method is identical to the GET request, except that the server must not
return the message body in the response, only the HTTP header with meta-information
identical to what it would have returned to a GET request.
POST: The POST method requests the server to accept information that is associated with
the request-URI previously requested. This method is often used with forms data or for
executing Common Gateway Interface (CGI) scripts on the server.
PUT: The PUT method is similar to the POST method, but instead of just altering an
existing URI, the PUT method creates a new URI if one does not exist. With the PUT
method, the data is stored as part of the request, not as part of the URI.
DELETE: The DELETE method is used to remotely delete the resource identified in the
request URI. Authorization is required to use this method.
TRACE: The TRACE method is used to observe how client messages are altered as they
pass through a proxy server (or multiple proxy servers). The request is echoed back to the
client, and by using the Max-Forward and Via headers, the client can determine how each
proxy server in the path is altering the request packets.
OPTIONS: The OPTIONS method represents a request for information about the
communication options available for requests and responses for a specific request-URI.
This method allows the client to determine the options and requirements associated with a
resource, or the capabilities of a server, without implying a resource action or initiating a
resource retrieval. Responses to this request are not cacheable.
CONNECT: Converts the request connection into a transparent TCP/IP tunnel, usually to
set up Secure Sockets Layer (SSL)-encrypted communication through an unencrypted
HTTP proxy.
33
HTTP Request Headers
Client Request
Host: www.cisco.com
User-Agent: Mozilla/5.0 (Windows; rv:1.8.1.6) Firefox/2.0.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;
q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Keep-Alive: 300
ACEAP v1.01-25
The boldface text in the figure is an example of request headers (except Connection: keepalive, which is an example of a general HTTP header).
HTTP headers determine how the end system (a server, in the case of a request header) handles
an HTTP request. In HTTP/1.1, unrecognized headers should be ignored by the receiving
system. Only the HOST header is required in all request headers, although some headers are
mandatory depending on the request type or server response.
The following are the well-formed request headers (experimental request headers are not
included):
34
Accept: The Accept request-header field can be used to specify certain media types that are
acceptable for the response.
Accept-Charset: The Accept-Charset request-header field can be used to indicate what

character sets are acceptable for the response.
Accept-Encoding: The Accept-Encoding request-header field is similar to Accept, but

restricts the content-codings that are acceptable in the response (such as compression).
Accept-Language: The Accept-Language request-header field is similar to Accept, but

restricts the set of natural languages that are preferred as a response to the request.
Authorization: A user agent that wants to authenticate itself with a server usually, but not
necessarily, after receiving a 401 response, does so by including an Authorization requestheader field with the request. The Authorization field value consists of credentials
containing the authentication information of the user agent for the realm of the resource
being requested.
Client-IP: Provides the IP address of the machine on which the client is running (not
defined in RFC2616, but implemented in most client browsers).
Expect: The Expect request-header field is used to indicate that particular server behaviors
are required by the client. A server that does not understand or is unable to comply with
any of the expectation values in the Expect field of a request must respond with appropriate
error status. The server must respond with a 417 (Expectation Failed) status if any of the
expectations can not be met or, if there are other problems with the request, some other 4xx
status.
From: The From request-header field, if given, should contain an Internet e-mail address
for the person sending the client request. This header field can be used for logging purposes
and as a means for identifying the source of invalid or unwanted requests. It should not be
used as an insecure form of access protection.
Host: The Host request-header field specifies the Internet host and port number of the
resource being requested. The Host field value must represent the naming authority of the
origin server or gateway given by the original URL. A host without any trailing port
information implies the default port for the service requested (for example, 80 for an HTTP
URL). A client must include a Host header field in all HTTP/1.1 request messages.
If-Match: The If-Match request-header field is used with a method to make it conditional.
A client that has one or more entities previously obtained from the resource can verify that
one of those entities is current by including a list of the associated entity tags in the IfMatch header field. An entity is the information transferred as the payload of a request or
response and is made up of metainformation.
If-Modified-Since: The If-Modified-Since request-header field is used with a method to

make it conditional; if the requested variant has not been modified since the time specified
in this field, an entity is not returned from the server with a 200 (OK) response; instead, a
304 (not modified) response is returned without any message-body.
If-None-Match: The If-None-Match request-header field is used with a method to make it

conditional. A client that has one or more entities previously obtained from the resource
can verify that none of those entities is current by including a list of the associated entity
tags in the If-None-Match header field. The purpose of this is to allow efficient updates of
cached information with a minimum amount of transaction overhead. It is also used to
prevent a method (such as PUT) from inadvertently modifying an existing resource when
the client believes that the resource does not exist.
If-Range: If a client has a partial copy of an entity in its cache and wants to have an up-todate copy of the entire entity in its cache, it could use the Range request-header with a
conditional GET (using either or both If-Unmodified-Since and If-Match.) However, if the
condition fails because the entity has been modified, the client would then have to make a
second request to obtain the entire current entity-body. The If-Range header allows a client
to short-circuit the second request. Its meaning is if the entity is unchanged, send me the
parts that I am missing; otherwise, send me the entire new entity.
If-Unmodified-Since: The If-Unmodified-Since request-header field is used with a method

to make it conditional. If the requested resource has not been modified since the time
specified in this field, the server should perform the requested operation as if the IfUnmodified-Since header were not present. If the requested variant has been modified
since the specified time, the server must not perform the requested operation, and must
return a 412 (Precondition Failed).
Max-Forwards: The Max-Forwards request-header field provides a mechanism with the

TRACE and OPTIONS request methods to limit the number of proxies or gateways that
can forward the request to the next inbound server. This can be useful when the client is
attempting to trace a request chain that appears to be failing or looping in midchain.
35
Proxy-Authorization: The Proxy-Authenticate response-header field must be included as

part of a 407 (Proxy Authentication Required) response. The field value consists of a
challenge that indicates the authentication scheme and parameters applicable to the proxy
for this request-URI.
The Proxy-Authorization request-header field allows the client to identify itself (or its user) to a
proxy that requires authentication. The Proxy-Authorization field value consists of credentials
containing the authentication information of the user agent for the proxy and/or realm of the
resource being requested.
36
Range: HTTP retrieval requests using conditional or unconditional GET methods can
request one or more subranges of the entity, instead of the entire entity, using the Range
request header, which applies to the entity returned as the result of the request; byte range
specifications in HTTP apply to the sequence of bytes in the entity-body (not necessarily
the same as the message-body). A byte range operation might specify a single range of
bytes, or a set of ranges within a single entity.
Referer: The Referer request-header field allows the client to specify, for the benefit of the
server, the address (URI) of the resource from which the request-URI was obtained (that is,
the referrer, although the header field is misspelled). The Referer request-header allows a
server to generate lists of back-links to resources for interest, logging, optimized caching,
and so on. It also allows obsolete or mistyped links to be traced for maintenance. The
Referer field must not be sent if the request-URI was obtained from a source that does not
have its own URI, such as input from the user keyboard.
TE: The TE request-header field indicates what extension transfer-codings it is willing to

accept in the response and whether or not it is willing to accept trailer fields in a chunked
transfer-coding. Its value can consist of the keyword trailers and/or a comma-separated list
of extension transfer-coding names with optional accept parameters.
User-Agent: The User-Agent request-header field contains information about the user
agent (browser type and version, and system OS and version) originating the request. This
is for statistical purposes, for the tracing of protocol violations, and for automated
recognition of user agents for the sake of tailoring responses to avoid particular user agent
limitations. User agents should include this field with requests.
HTTP Response Codes
Client Request
GET /swa/i/logo.gif HTTP/1.1
Host: www.cisco.com
Server Response
HTTP/1.1 200 OK
Content-type: image/gif
Content-length: 4523
ACEAP v1.01-26
The figure shows the response code received from the server when the client requests the URI
http://www.cisco.com/swa/i/logo.gif. The server sends the response code 200 (OK) and send
file along with content type and content length.
Every HTTP response message (from the server) contains a status code, a three-digit code that
tells the client whether its request succeeded, or if it was unsuccessful, why it was unsuccessful,
and offers possible remedies, either browser initiated or human initiated (like answering a
username/password challenge):
X00: Default Response
1XX: Informational
100 = Continue
101 = Switching Protocols
2XX: Success
200 = OK
201 = Created
202 = Accepted
203 = Nonauthoritative Information
204 = No Content
205 = Reset Content
206 = Partial Content
3XX: Redirection
300 = Multiple Choices
301 = Resource Moved Permanently
302 = Resource Moved Temporarily
37
38
303 = See Other
304 = Not Modified
305 = Use Proxy
306 = (Unused)
307 Temporary Redirect
4XX: Client Error
400 = Bad Request
401 = Unauthorized
402 = Payment Required
403 = Forbidden
404 = Not Found
405 = Method Not Allowed
406 = Not Acceptable
407 = Proxy Authentication Required
408 = Request Timeout
409 = Conflict
410 = Gone
411 = Length Required
412 = Precondition Failed
413 = Request Entity Too Large
414 = Request-URI Too Large
415 = Unsupported Media Type
416 = Requested Range Not Satisfiable
417 = Expectation Failed
5XX: Server Error
500 = Internal Server Error
501 = Not Implemented
502 = Bad Gateway
503 = Service Unavailable
504 = Gateway Timeout
505 = HTTP Version Not Supported
HTTP Cookies
Client Request
GET /index.html HTTP/1.1
Host: www.cisco.com
Server Response
HTTP/1.1 200 OK
Set-cookie: id=1234; domain=cisco.com
Client Request
GET /index.html HTTP/1.1
Host: www.cisco.com
Cookie: id= 1234
ACEAP v1.01-27
The figure shows how cookies are set by a server and how they are requested by the server on
subsequent visits.
Because HTTP is a stateless protocol, and the transactions are composed of multiple short-lived
HTTP sessions*, user persistence (or user identification) must be maintained by something
other than the HTTP protocol. There are many ways for the client to identify users to the server,
such as HTTP headers, client IP address tracking, user login, fat URLs, and cookies. HTTP
cookies have the fewest limitations of those listed to identify a user from a previous visit or
from an action earlier in the current session.
HTTP cookies are created by the server and sent to the client to store for:
The current session
A predetermined length of time
An unlimited length of time
A cookie can store anything the server wants it to store, because the server writes the cookie
information before sending it along with the response. Common items stored as a cookie are:
User ID
User preferences
There are two versions of cookies:
Version 0, which was created by Netscape and uses the Set-Cookie attribute
Version 1, which comes from RFC2965 and uses the Set-Cookie2 attribute
39
Cookies are sent to the user agent (client browser) by the server. The server can write whatever
information it needs in the cookie and then retrieve that information automatically the next time
the user agent visits the web page. Cookies can be specific to a domain, to a host, or to a
directory under a domain or host. The cookie is valid and requestable only for the domain that
created it. This means that the server at www.cisco.com can not request the cookie for
www.yourbankwithlotsofmoney.com. Multiple cookies are also allowed for a single domain;
restrictions on the number of cookies per domain are configurable in the client browser.
*Even with the advent of HTTP/1.1s persistent and pipelined connections, the HTTP state is
maintained only through the request-response. When a user clicks an object on the page, the
HTTP server knows little about the user to tie the user to a particular web session or event that
happened previously in the TCP session.
40
HTTP Response Headers
Server Response
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html charset=UTF-8
Set-Cookie: CP_GUTC=10.0.0.1.1191547089294320; path=/; expires=Tue,
28-Sep-3201:18:09GMT;domain=.cisco.com
Server: Apache/2.0
Transfer-Encoding: chunked
Date: Fri, 21 Sept 2007 01:09:00 GMT
Connection: closed
ACEAP v1.01-28
HTTP response header fields provide information about the server and the response sent for the
client. Some are required (such as Content-Type:) and some are optional and provide
additional information to the client (such as Server:).
Here is a list of many of the common response headers:
Accept: Acceptable media types.
Accept-Charset: Acceptable character sets.
Accept-Encoding: Acceptable content coding values.
Accept-Language: Acceptable natural languages.
Accept-Ranges: The type of ranges that a server accepts for this resource.
Age: Specifies how old the response is.
Allow: Methods supported by server.
Authorization: Authorization credentials used for a request.
Cache-Control: Cache control directives.
Connection: Options that are specified for a particular connection and must not be
communicated by proxies over further connections.
Content-Base: The base URL for resolving relative URLs within the body.
Content-Encoding: Any encoding that was performed on the body.
Content-ID: Content identification.
Content-Language: The natural language that is best used to understand the body.
Content-Length: The length or size of the body.
Content-Location: Where the resource actually is located.
Content-MD5: An MD5 checksum of the body.
41
42
Content-Range: The range of bytes that this entity represents from the entire resource.
Content-Transfer_Encoding: Addition.
Content-Type: The type of object that this body is.
Cookie: Cookies associated with the request.
Date: Date and time at which the message was originated.
Etag: The entity tag associated with this entity.
Expires: The date and time at which this entity will no longer be valid and will need to be
fetched from the original source.
From: E-mail address for the human user who controls the requesting user agent.
Last-Modified: The last date and time when this entity changed.
Location: Absolute URI.
Max-Forward: Number of proxies or gateways that can forward the request to the next
inbound server.
MIME-Version: Version of the MIME protocol that was used to construct the message.
Pragma: Implementation-specific directives that might apply to any recipient along the
request-response chain.
Proxy-Authenticate: Authentication scheme and realm returned by the proxy.
Proxy-Authorization: Header that is used to identify the users to a proxy that requires
authentication.
Proxy-Connection: Proxy-connection header.
Public: A list of request methods the server supports for its resources.
Raw-Headers: All the headers returned by the server. Each header is terminated by \0. An
additional \0 terminates the list of headers.
Raw-Headers-CRLF: All the headers returned by the server. Each header is separated by
a carriage return/line feed (CR/LF) sequence.
Referer: URI of the resource where the requested URI was obtained.
Retry-After: A date or time to try back, if a resource is unavailable.
Server: The name and version of the servers application software.
Set-Cookie: Not a true security header, but it has security implications; used to set a token
on the client side that the server can use to identify the client.
Set-Cookie2: Similar to Set-Cookie, RFC 2965 cookie definition.
Status-Code: Status code returned by the server.
Status-Text: Any additional text returned by the server on the response line.
Title: For HTML documents, the title as given by the HTML document source.
Transfer-Encoding: Type of transformation that has been applied to the message body so
it can be safely transferred between the sender and recipient.
Upgrade: Additional communication protocols that are supported by the server.
URI: Some or all of the URIs by which the request-URI resource can be identified.
Vary: A list of other headers that the server looks at and that might cause the response to
vary; that is, a list of headers the server looks at to pick which is the best version of a
resource to send the client.
Warning: A more detailed warning message than what is in the reason phrase.
WWW-Authenticate: A list of challenges for the client from the server.
43
HTTP Response Content Type
Server Response
HTTP/1.1 200 OK
Content-type: text/html
OR
Content-type: audio/x-wav
OR
Content-type: video/mpeg
Content-length: 4523
ACEAP v1.01-29
HTTP has become the workhorse of the Internet. When responding to a request, HTTP can
send almost any kind of data in the body of a message. This can be a simple HTML page, a
picture file in the form of a JPEG or GIF file, or an audio or video file. For the client to accept
only files that it can understand, the client should send an Accept: request header in the request
message. When responding to a request, the server must also let the client know what type of
data is in the body of the message using the Content-Type: response header.
Content-Type is defined using MIME (Multipurpose Internet Mail Extensions), which was
originally created to handle multimedia e-mail. MIME media type names are formatted in the
general media type, like text or image or audio, and then followed by a / and then the specific
type of encoding or format, like html or jpeg or x-wav. The preceding examples would be
expressed, respectively, as text/html, image/jpeg, and audio/x-wav. From this information the
browser can decode the response or hand it off to the appropriate application.
44
HTTP Compression
Request Header Message Accept-Encoding: gzip,deflate

Response Header Message Content-Encoding: gzip
ACEAP v1.01-30
Both HTTP/1.0 and HTTP/1.1 support compression, but HTTP/1.0 implementations were not
well supported. HTTP/1.1 can compress the body portion of a response message. The client
communicates its decompression capabilities through the Accept-Encoding request header. If
the server is configured to compress the body of a response, the server sends the compressed
response along with the Content-Encoding response header set to the appropriate encoding
algorithm. The standard IANA compression algorithms are:
Gzip: GNUs Not Unix (GNU) zip encoding
Compress: UNIX file compression program
Deflate: zlib compression format
Identity: No compression performed on body. This is the assumed or default behavior

when no Content-Encoding response header is received with the response.
The client can rate the compression algorithms for most or least preferred.
45
HTML and Web Page Construction

Static Web Page
Dynamic Web Page

HTML
HTML
HTML
HTML
HTML
ACEAP v1.01-31
When you visit a website, the content that appears in your web browser looks as if it is coming
from one source, but because of the way HTTP works, the content can come from anywhere.
You have seen how a URI uniquely identifies where to find a resource. When you request or
GET a web page, the objects can come from myriad sources. By using the HREF to a URI, the
browser can request information wherever the data resides.
Content on a web page can be either static or dynamic. Static content is updated only when it is
changed by an administrator maintaining it. Dynamic content can change each time a user visits
a page, or it can be configured by user preferences, as with a user home page (such as
igoogle.com or my.yahoo.com). Dynamic content can also be a sports score feed or real-time
financial information. Often web pages are made up of both static and dynamic content.
Dynamic content is commonly created using JavaScript, cascading style sheets (CSS), and
document object model (DOM), as well as with several browser-specific technologies.
46
Browser Behavior
Client Request
GET index.html HTTP/1.1
Host: www.cisco.com
Server Response
HTTP/1.1 200 OK
ACEAP v1.01-32
Client/Server
Because HTTP messaging depends on both a client and a server, the clients and the servers
behavior must be taken into account. To take advantage of HTTP/1.1 features both must
support those features.
User Agent
Although many user agents support HTTP 1.1, not all features are fully supported or supported
at all in the individual software.
Currently most browsers either turn off HTTP pipelining by default or do not support it. This
might be due to the fact that some web servers do not properly handle HTTP pipelined requests.
Firefox and Opera web browsers support pipelining, and when pipelining is enabled, these
browsers built-in heuristics to detect whether the web server supports pipelining.
Currently most browsers support HTTP persistent connections. The RFC (RFC2616) states that
Clients that use persistent connections SHOULD limit the number of simultaneous
connections that they maintain to a given server. As a result of the vagueness of the RFC, each
browser implements HTTP persistent connections differently. Internet Explorer (since 5.0)
supports two persistent connections per server with a 60-second inactivity timeout. Other
browsers allow the user to configure this feature.
Server Caveats
Implementing pipelining in web servers is a relatively simple matter of making sure that
network buffers are not discarded between requests. For that reason, most modern web servers
handle pipelining well. Exceptions include Microsoft Internet Information Services (IIS) 4 and
5 and some versions of Apache.
47
Introducing ACE
This topic describes the features and architecture of the Cisco 4710 Application Control Engine
appliance.
The Evolution of L4L7 Services

Today
Application Control
Engine
Integrated
Layer 4
and
Layer 7
Rules
Infrastructure simplification with Layer 47 services integration

Converged policy creation, management, and troubleshooting
Reduced latency (single TCP termination for all functions)
ACEAP v1.01-34
The Cisco ACE 4710 appliance integrates content switching, SSL offload, web application
acceleration, and data center security features on one device. This provides the same
functionality as a collection of appliances with reduced latency through a single point of TCP
termination. Centralized functionality also allows integrated rules configuration and
management along with simplified design through reduced numbers of VLANs and IP
addresses to manage. The ACE 4710 appliance is the newest product line in the Cisco
Application Networking Services (ANS) portfolio.
Note
48
The ACE 4710 appliance provides data center security features, but it is not a replacement
for perimeter firewalls. Ace is often deployed in conjunction with upstream firewalls as part of
a defense-in-depth security strategy.
Application Control Engine Appliance
Back Panel
ACEAP v1.01-35
The front panel of the ACE 4710 appliance has a console port, a USB port, a power button, and
a nonmaskable interrupt button. The console port provides console access to the onboard
command line interface (CLI) and is the only mechanism that can be used to access the ACE
4710 appliance if it is in the internal ROM monitor mode. The USB port currently is not
supported by the ACE software. The back panel of the ACE 4710 appliance has a PS2
keyboard and mouse connection (currently unused), a 9-pin serial port for console connections,
a VGA port, two Ethernet ports (currently unused), and four Gigabit Ethernet ports.
49
ACE 4710 Hardware Architecture
CONTROL
PLANE
Serial Port
PCI-X
BUS
1 Gb Ethernet
1 Gb Ethernet
1 Gb Ethernet
DATA PLANE
1 Gb Ethernet
ACEAP v1.01-36
The figure shows a functional diagram detailing the hardware architecture of the ACE 4710
appliance.
Control plane (x86 architecture):
50
3.4 GHz Processor: (DCOS Linux)
Configuration manager (CLI, XML, API, SSH)
ARP and DHCP relay
Routing
Probes (native probes, TCL scripts)
Syslog
SNMP
Virtualization
High availability
Web application acceleration features
1 GB Compact Flash:
Configurations
SSL certificates/keys
Boot image
Serial connection (console access)
6 GB RAM
PCI-X 133 MHz bus
Data Plane (Octeon 3816 PCI-X Board):
Connection to control plane over PCI-X bus
16 x 500 MHz multiprocessor (MontaVista Linux)
Connection/session management
TCP proxy
HTTP parsing
Fastpath
SLB
Inspection
IP fragmentation/reassembly
ACL processing
SSL acceleration
HTTP compression
Regular expression handling
2 GB RAM
4 x 1 Gb/s Ethernet ports:
10/100/1000 autosensing
Access or trunk mode
802.1Q trunking supported
5 K VLANs supported (1 K shared/4 K unshared)
PortChannels
Each VLAN belongs to one interface or PortChannel
51
Whats New in ACE ?

ACE
Virtualization (20 contexts):

Per-context active-standby
Role-based access control:

Predefined and user-configurable roles
Reflexive access lists, TCP and IP normalization, protocol fixups

HTTP inspection, RFC compliance, control on headers and
payload
Modular Policy CLI for integrated features configuration
Configuration rollback for quick error recovery and testing
Integrated SSL termination, with support for back-end SSL
TCP reuse for HTTP (same as TCP multiplexing or TCP offload)
CLI objects name completion
HTTP compression
Application optimization and acceleration
ACEAP v1.01-37
The figure lists some new features of the ACE 4710 appliance.
52
ACE Family of Products

Application Switching
XML Switching
Multimodule
(64 Gb/s)
ACE XML Gateway

30,000 TPS
Module
(416 Gb/s)
ACE
Module
16 Gb/s
ACE
Module
8 Gb/s
Appliance
(12 Gb/s)
ACE
Module
4 Gb/s
ACE XML
Gateway
Manager
ACE 4710
2 Gb/s
ACE 4710
1 Gb/s
ACE GSS
20K DNS RPS
ACE
Networking
Manager
ACE
AppScope
Global Products and Tools

ACEAP v1.01-38
The figure shows ACE products available.
53
ACE Improvements over CSS

ACE
CSS
Up to 4 Gb/s Throughput
Up to 2 Gb/s Throughput
Up to 1 Gb/s HTTP Compression
Up to 1 Gb/s HTTP Compression
Up to 1 M Concurrent
Connections
Up to ~44 K L4 Sustained
Connections per Second
Up to 5.6 K SSL
Transactions per Second
1 M Concurrent
Connections
3x
~120 K L4 Sustained
Connections per Second
7.5 K SSL
Transactions per Second
ACEAP v1.01-39
The ACE 4710 appliance provides enhanced functionality and capacity compared to the
Content Services Switch (CSS). The figure shows a comparison of several key attributes.
Although some features appear equal or higher on the CSS, the ACE 4710 appliance is a fixed
device, and features are limited only by the licenses purchased. For example, if a CSS11506
were set up for maximum compression (1.1 Gb/s), the number of I/O and session modules
allowed on the chassis would be limited, reducing the throughput and concurrent connection.
54
ACE Improvements over CSS (Cont.)

ACE
CSS
Content Switching
Functions Only;
Optional SSL Modules
Content Switching, SSL,

Security, Optimization Features
HTML Acceleration
Single Configuration CLI
Virtualized Configuration
per Context
IOS CLI
(Session or SSH/Telnet)
No Software Licenses
(Except GSLB, but GSS
Is Recommended)
Software Licenses
for Features or
Additional Performance
Per-Box Active-Standby
Redundancy Model
Active-Active
(Per-Context Active Standby)
ACEAP v1.01-40
The figure shows ACE appliance improvements over CSS.
55
Application Delivery Features

L4 to L7 SLB
Stateful Redundancy
Redundancy
Connection Persistence
(HTTP 1.1)
CSS
CSM
ACE SM
ACE AP
9
9
9
9
9
9
9
9
Per VIP or
per box
Per box
Per context
Per context
9
9
Fully supported
Limited
Limited
TCP Termination
for Generic Protocols
Inband Health Checking
TCP Reuse (Multiplexing)
Pipelining
(HTTP 1.1)
(Future phase) (Future phase)
X (Future phase) X
9
ACEAP v1.01-41
The figure shows application delivery features available with CSS, CSM, the ACE service
module (SM), and the ACE appliance (AP).
56
Application Delivery Features (Cont.)

CSS
CSM
ACE-SM
ACE-AP
L7 RDP-Aware Balancing
Windows Terminal Services
(Future phase)
L7 SIP-Aware LB
(Future phase)
Scriptable Health Checks
Route Health Injection
TCL
Routing
on CSS
HTTP Compression
KAL-AP Reporting Load to GSS

Proprietary
X
X
TCL
TCL
VRF-aware
Future daughter card
X
(Future phase)
ACEAP v1.01-42
The figure shows more application delivery features available with CSS, CSM, the ACE
service module (SM), and the ACE appliance (AP).
57
Security Features
CSS
CSM
ACE-SM
ACE-AP
TCP and IP Normalization
Layer 7 Fixups and Inspection
uRPF Check
Scalable Reflexive ACLs
9
9
9
9
FWLB
CSM recommended
SYN Cookies
(Reverse sticky, future phase)
9
(300K SYNs/
sec)
(4M SYNs/
(Future phase)
sec)
ACEAP v1.01-43
The figure shows security features available with CSS, CSM, the ACE service module (SM),
and the ACE appliance (AP).
The ACE service module supports the following protocol inspections: HTTP, FTP, RTSP,
ICMP, DNS, H.323, SCCP, and SIP.HTTP, FTP, RTSP, ICMP, DNS, H.323, SCCP, and SIP.
The ACE appliance supports the following protocol inspections: HTTP, FTP, RTSP, ICMP,
and DNS.
HTTP, FTP, RTSP, ICMP, and DNS.
58
Network Management Features

CSS
Command-Line Interface
XML Interface
Graceful Service Shutdown
Object Name Completion
Embedded Device Manager
(Onboard GUI)
Multidevice Manager
Server-Based GUI
CSM
ACE-SM
ACE-AP
9
9
9
9
9
9
9
WebNS
Supervisor IOS
9
9
9
9
9
9
9
CVDM
CVDM
(Future phase)
HSE
HSE
Onboard IOS-like
9
ANM
9
ANM
ACEAP v1.01-44
The figure shows network management features available with CSS, CSM, the ACE service
module (ACE SM), and the ACE appliance (ACE AP).
59
SSL Features
CSS
SSLM
CSM-S
ACE-SM
ACE-AP
9
9
9
9
9
9
Export Cipher-Suites
9
9
9
9(SSLM 3.1)
AES Cipher-Suites
9
9
9
9
Client Authentication
(Future phase)
SSL Session Reuse
(Future phase)
URL Rewrite
HREF http:// to https://
(Future phase)
SSL Termination
Back-End SSL
X
X
X
ACEAP v1.01-45
The figure shows SSL features available with CSS, CSM, the ACE service module (ACE SM),
and the ACE appliance (ACE AP).
60
Summary
This topic summarizes the key points that were discussed in this lesson.
Summary
The IP protocol stack includes data link, IP, TCP, UDP,
and application protocols.
IP applications processed by the ACE correspond to
OSI Layers 57.
HTTP is a stateless protocol that is part of the TCP/IP
suite. HTTP comprises response and request
messages that can be anything from HTML to image
files to streaming movies.
The ACE 4710 appliance is built specifically to process
IP applications.
ACEAP v1.01-46
61
62
Lesson 2
Deploying ACE
Overview
In this lesson, you will learn how to describe the configuration tasks necessary to successfully
deploy an ACE appliance.
Objectives
Upon completing this lesson, you will be able to describe the configuration tasks necessary to
successfully deploy an ACE appliance. This includes being able to meet these objectives:
Describe the process of connecting the ACE to the network
Describe the process of initially setting up the ACE appliance
Provide an overview of the ACE appliance graphic user interface
Describe possible deployment topologies including routed, bridge, and one-arm modes, and
direct server return
Describe the use of multiple contexts
Explain the resource management controls available on the ACE
Explain the process of granting access to authorized users for management tasks
Describe the steps to configure ACE interfaces
Connecting the ACE to the Network

This topic describes the process of connecting the ACE to the network.
ACE Network Topology
Web
Client
Client
VLAN
ACE
Server
VLAN
Web
Server
ACE
Appliance
ACEAP v1.01-4
The figure shows a basic network where a Cisco 4710 Application Control Engine (ACE)
appliance is physically connected to a router and server network using Gigabit Ethernet,
PortChannels, and VLAN trunking.
64
ACE VLANs
Web
Client
ACE
Client
VLAN
Server
VLAN
Web
Server
ACE
Appliance
ACEAP v1.01-5
In this example, the ACE connects to the network over all four Gigabit Ethernet links logically
bonded together using a PortChannel link. Two VLANs are used, one for a connection to
clients (a web client in the figure), and the other for a connection to servers (a web server in the
figure). Diagramming the individual VLAN connections is often necessary to completely
understand and document a network topology. As a result, the ACE appliance is shown
diagrammed as a standalone component of the network in much of this course.
Deploying ACE
65
ACE Installation Procedure

This topic describes the process of initially setting up the ACE appliance.
First-Time Bootup
Power Button
Serial Port
switch login: admin

Password: admin
---- Basic System Configuration Dialog ---This setup utility will guide you through the basic configuration of
the system. Setup configures only enough connectivity for management
of the system.
*Note: setup is mainly used for configuring the system initially,
when no configuration is present. So setup always assumes system
defaults and not the current system configuration values.
Press Enter at anytime to skip a dialog. Use ctrl-c at anytime
to skip the remaining dialogs.
Would you like to enter the basic configuration dialog (yes/no): yes
ACEAP v1.01-7
The figure shows the pertinent ACE appliance components needed to start the initial setup
process and the boot dialog.
66
Note
Accessing ACE for the first time requires using the console port, a rollover cable, an RJ-45to-serial adapter, and a terminal emulation application with the settings of 9600 b/s, 8 data
bits, no parity, and 1 stop bit, to access the command-line interface (CLI). Only the Admin
context is accessible through the console port; all other contexts can be reached through a
Telnet or Secure Shell (SSH) remote access session.
Note
When you boot the ACE for the first time and the appliance does not detect a startupconfiguration file, a setup script guides you through the process of configuring a
management VLAN on the ACE through one of its Gigabit Ethernet ports. The primary intent
of the setup script is to simplify connectivity to the Device Manager GUI.
Setup Dialog
Which port is used to carry Management vlan (1 - 4)? [1]:

Configure GigabitEthernet port mode (Access/Trunk) [Trunk]:
Which vlan is used as Management vlan (2 - 4094)? [10]:
What is the Management vlan ip address [192.168.1.10]:
What is the Management vlan ip netmask [255.255.255.0]:
Configure the default gateway? (yes/no) [y]: y
What is the ip address of the default gateway [192.168.1.1]:
ACEAP v1.01-8
The figure shows the Gigabit Ethernet port numbering and the initial setup dialog.
After you specify a Gigabit Ethernet port, a port mode, and a management VLAN, the setup
script automatically applies the following default configuration:
Management VLAN allocated to the specified Ethernet port.
Extended IP access list that allows IP traffic originating from any other host addresses.
Traffic classification (class map and policy map) created for management protocols HTTP,
HTTPS, ICMP, SSH, Telnet, and XML-HTTPS. HTTPS is dedicated for connectivity with
the Device Manager GUI.
VLAN interface configured on the ACE and a policy map assigned to the VLAN interface.
The completed configuration should look something like this:

The following configuration will be applied:
interface gigabitEthernet 1/1
switchport trunk allow vlan 10
no shut
access-list ALL extended permit ip any any
class-map type management match-any remote_access
match protocol xml-https any
match protocol icmp any
match protocol telnet any
match protocol ssh any
match protocol http any
match protocol https any
policy-map type management first-match remote_mgmt_allow_policy
class remote_access
permit
interface vlan 10
Deploying ACE
67
ip address 192.168.1.10 255.255.255.0

access-group input ALL
service-policy input remote_mgmt_allow_policy
no shutdown
ip route 0.0.0.0 0.0.0.0 192.168.1.1
Would you like to edit the configuration? (yes/no) [n]: n
Use this configuration? (yes/no) [y]: y
68
ACE Appliance GUI

This topic provides an overview of the ACE appliance graphic user interface.
Logging Into the ACE Device Manager GUI

To manage the ACE
Appliance, be sure to use:
https://<IP or
hostname>/
Extensive help
library available
ACEAP v1.01-10
After completing the initial setup script, the ACE appliance should be accessible via the
network (using Telnet, SSH, HTTPS, and SNMP). To access the ACE device manager GUI,
use a web browser to log in. Enter the secure HTTP address of your ACE (the VLAN IP
address configured during the setup script) in the browser address field. For example, in the
example in the figure you would use https://172.19.110.29/.
Note
Logging into http://172.19.110.29/ logs you into the System Info screen.
Next, you are probably prompted to accept and install a certificate from Cisco Systems,
Inc.
This should bring you to the ACE 4710 Device Manager login screen. The initial username
and password that you use are admin and admin.
Click Enter or press the Enter key after completing the password to enter the ACE Device
Manager GUI.
Note
The admin password can be changed, but not the username admin.
Deploying ACE
69
GUI Overview
The GUI is organized in a hierarchical structure. The first highlighted box (1)
shows the configuration location in the GUI. In this example, the user is in the
Config > Virtual Contexts > Expert > Class Map section.
2
3
4
10
6
9
ACEAP v1.01-11
The ACE Device Manager has several sections:

1. Config location: This section displays what the user is currently configuring.
2. First-level navigation tabs: These tabs allow the user, depending on role-based access
control (RBAC) privileges, to choose from three sections: Config, Monitor, and Admin.
3. Second-level navigation buttons: These buttons further specify the area of the config to
modify: Config (virtual contexts and operations), Monitor (virtual contexts), and Admin
(RBAC, device management, and tools).
4. Third-level navigation buttons: These buttons are for the different technologies to be
configured.
5. Fourth-level items: This is the actual feature or object to be configured.
6. Context selection drop-down window: This allows the user to change between contexts to
configure (depending on RBAC privileges).
7. This section displays who is logged in (admin in this example), logout button, and help
button.
8. This is the configuration section, where the configuration changes will be made.
9. Configuration buttons available in most configuration sections, from right to left: Add (add
new element), Edit, Delete, Filter, Save.
10. This is the screen option that allows the user to toggle between split screen, as seen here,
and full screen.
The ACE Device Manager interface is adaptive to the user privileges granted through RBAC.
This means that each user has different elements available, depending on the privileges granted
by the administrator.
70
Network Topologies
This topic describes possible deployment topologies including routed, bridge, and one-arm
modes, and direct server return.
ACE Bridged Mode

Servers Default Gateway:
Upstream Router
Content Switch Bridging
VLAN 10
VLAN 20
Subnet A
ACEAP v1.01-13
The ACE can be configured in bridge mode. In this mode, the client and server VLANs are part
of the same IP subnet, as shown in the figure. The ACE uses an Address Resolution Protocol
(ARP) table to track which VLAN contains what physical devices.
In the figure, VLAN 10 is used as the client-side VLAN, and VLAN 20 is the server-side
VLAN. The same IP subnet is used on both VLANs. The physical port attached to the upstream
router is assigned to VLAN 10. Physical ports connected to the servers are assigned to VLAN
20. The servers in a bridge mode environment are configured to use the IP address of the
upstream router interface as their default gateway.
Deploying ACE
71
ACE Routed Mode

Content Switch IP
Content Switch Routing
Subnet A
VLAN 10
Subnet B
VLAN 20
ACEAP v1.01-14
The ACE can be configured in routed mode. In this mode, the client and server VLANs are part
of different IP subnets, as shown in the figure.
In the figure, VLAN 10 is configured as the client-side VLAN, and VLAN 20 is the server-side
VLAN. Different IP subnets are associated with each VLAN. The physical port attached to the
upstream router is assigned to VLAN 10. Physical ports connected to the servers are assigned
to VLAN 20. The servers in a router mode environment are configured to use the IP address of
the CSM as their default gateway.
72
ACE One-Arm Mode
Subnet A
VLAN 10

Upstream Router
Subnet B
VLAN 20
ACEAP v1.01-15
The one-arm mode removes the ACE from a position directly in the transit path for all traffic to
the server farms. This configuration has the advantage that the ACE does not have to process
traffic that is not effected by ACE features. In the figure, VLAN 10 is used for traffic between
the ACE and the router, and VLAN 20 is used for traffic to the server farms. A VLAN 10
interface is configured on the router and an IP address from subnet A is configured on the ACE.
Additional IP addresses from subnet A are used to configure the virtual server IP addresses. A
VLAN 20 interface is configured on the router and is used by the servers as their default
gateway.
Note
An ACE in one-arm mode has only one VLAN.
Return traffic generated by the servers in response to load-balanced requests is still needed by
the ACE for full functionality. Getting this traffic to flow through the ACE is more complicated
than with an inline configuration. There are two ways to address this situation:
Source Network Address Translation (SNAT)
Policy-based routing (PBR)
SNAT
SNAT is configured by creating a pool of IP addresses. Client IP addresses are translated to IP
addresses from the client pool. These translated addresses are used as the source address in the
source packet that is sent to the server.
Deploying ACE
73
Policy-Based Routing
Policy-based routing (PBR) is a router feature available on Cisco IOS-based routers. PBR
allows the router to be configured to select a next hop for a packet based on a configured
policy. This policy overrides the routing decision that would have been made by consulting the
routing database. A routing policy is attached to the ingress interface on the router. Access lists
can be used to limit the traffic to which the policy is applied. For example, web responses being
sent to clients can be load balanced and redirected via policy-based routing, while SNMP
responses from the servers are routed normally.
74
One-Arm Mode: Flows
VIP
1
4
5
Server
IP
2
3
ACEAP v1.01-16
Traffic flow for load-balanced requests is shown in the figure. Packets are handled as follows:
1. Traffic from the client to the virtual IP (VIP) is routed normally by the router.
2. Traffic from the ACE to the server is routed normally by the router. If SNAT is used, the
source IP address is in the client NAT pool. Otherwise, the source IP address remains the
client IP address.
3. Traffic from the server is returned to the router because the router is the server default
gateway.
4. If SNAT is used, the destination IP address in the server response is routed normally to the
ACE. If SNAT is not used, PBR must be used on the router interface that is used as the
server default gateway. The policies configured must match any traffic being sent in
response to a load-balanced request. The IP address specified for the ACE is set as the
next-hop address by PBR.
5. Traffic from the ACE to the client is routed normally by the router. If SNAT is used, the
ACE has translated the destination IP address from the NAT pool IP address to the client IP
address. If PBR is used, the ACE does not need to modify the destination IP address
because the client IP address is already in the packet.
Deploying ACE
75
Overview of Direct Server Return

Upstream Router
Subnet B
ACEAP v1.01-17
A variation of one-arm mode is a direct server return. The figure shows the architecture of this
variation.
The ACE and the servers are placed in the same VLAN and IP subnet. An interface on that
VLAN is defined on the router and is the default gateway for the ACE and the servers. NAT is
turned off for the server destination address. Return traffic does not flow through the ACE but
returns directly to the client.
The advantage of a direct server return is that web servers can return higher-bandwidth traffic
than can be handled by the ACE. Because the return traffic is not processed by the ACE, the
following restrictions apply:
76
TCP termination is not possible. This restriction limits load balancing to Layer 4.
TCP flows must be timed out to be removed from memory.
Servers must be adjacent at Layer 2.
In-band health monitoring is not possible.
Flows of Direct Server Return
VIP
Loopback IP = VIP
2
3
ACEAP v1.01-18
Traffic flow for load-balanced requests is shown in the figure. Packets are handled as follows:
1. Incoming client requests are routed to the server VLAN. The packet is switched to the
ACE.
2. The ACE rewrites the Layer 2 destination MAC address and returns the packet to the
switch processor. The packet is switched to the server. The server uses a loopback interface
configured with the VIP address so that the server accepts a packet destined for the VIP.
3. The server responds directly to the client. This traffic is routed normally because the router
is the default gateway for the server.
When no more traffic is generated by the client on this TCP connection, the connection goes
idle. After the idle timeout, the ACE removes the connection from its session table.
Deploying ACE
77
Mixed Modes
VLAN 100 / Subnet A

VLAN 101 / Subnet B
VLAN 102 / Subnet C
VLAN 201 / Subnet A
VLAN 203 Subnet D
VLAN 202 / Subnet B
VLAN 204 Subnet E
ACEAP v1.01-19
The ACE is capable of handling multiple pairs of VLANs and mixed modes. The figure shows
one ACE handling several VLANs. The following mode configurations are possible:
Subnet A bridged between VLAN 100 and VLAN 201
Subnet B bridged between VLAN 101 and VLAN 202
Subnet C on VLAN 102 routed to Subnet D on VLAN 203 or Subnet E on VLAN 204
Note
78
The bridging versus routing mode selection is not an appliance-wide configuration option.
Rather, it is driven by the interface configuration within the ACE appliance.
ACE Network Configuration
ACEAP v1.01-20
After completing the initial setup script, you can configure further network changes from the
GUI or from the CLI. In the GUI, go to Config > Virtual Contexts > Network.
Note
PortChannel interfaces and Gigabit Ethernet interfaces can be configured only in the Admin
context.
Gigabit interfaces can be bundled into PortChannel interfaces to make them appear as one link.
Gigabit Ethernet and Port Channel interfaces can be turned into trunk interfaces so that multiple
VLANs can be bundled on the same link.
Minimal required configuration:
4710/Admin(config)#interface port-channel 255
Creates a port channel with an index number of 255

4710/Admin(config-if)# no shutdown
Administratively enables the interface

Optional Configuration:
4710/Admin(config-if)# description A port-channel interface 255
Gives the port channel a description

4710/Admin(config-if)# ft-port vlan 60
Configures the port-channel interface for fault tolerance using a dedicated fault-tolerant (FT)
VLAN for communication between the members of an FT group.
4710/Admin(config-if)# port-channel load-balance src-dst-ip
Sets the load-distribution method among the ports in the EtherChannel bundle, for example,
to configure an EtherChannel to balance the traffic load across the links using source or
destination IP addresses
Deploying ACE
79
4710/Admin(config-if)# switchport access vlan 101
Specifies that vlan 101 will be the access port for the port channel
4710/Admin(config-if)# switchport trunk allowed vlan 101,201,250-260
Selectively allocates individual VLANs to a trunk link

4710/Admin(config-if)# switchport trunk native vlan 266
Sets the 802.1Q native VLAN for a trunk
80
Virtualization
This topic describes the use of multiple contexts.
Service Virtualization: System Separation

One Physical Device
Multiple Virtual Systems

(Dedicated Control and Data Path)
100%
Traditional device:
Single configuration file
Single routing table
Limited RBAC
Limited resource
allocation
25%
25% 15% 15% 20%
Cisco application services

virtualization:
Distinct configuration files

Separate routing tables
RBAC with contexts, roles, domains
Management and data resource control
Independent application rule sets
Global administration and monitoring
ACEAP v1.01-22
The ACE supports the creation of virtual ACE images called contexts. Each context has its own
configuration file and operational data, providing complete isolation from other contexts on
both the control and data levels. Hardware resources are shared among the contexts on a
percentage basis.
Deploying ACE
81
Multi-tier Applications
Enterprise
Network
Enterprise
Network
Firewalls
Front-End
Firewalls
LB
Front-End
Servers
ACE with
Application
Infrastructure
Control and
Application
Security
LB
Application
Servers
Front-End
Servers
Application
Servers
Database
Servers
FE Virtual
Partition
APP Virtual
Partition
DB Virtual
Partition
LB
Database
Servers
ACEAP v1.01-23
One use of ACE contexts is to provide application controls at multiple levels of a multi-tier
application architecture. On the left in the figure is a typical multi-tier architecture with frontend web servers, application or middleware servers, and back-end database servers. Typically,
load-balancing and firewall services are required between layers. Each layer can be
implemented using an ACE context, which maintains separate data flows and security controls
while minimizing the number of devices to be managed.
82
Multiple Load Balancers

LB 1
Enterprise
Network
App C
LB 2
LB
App A
App D
LB
App B
Enterprise with Growing Number of Applications

ACEAP v1.01-24
Many enterprise networks add load-balanced applications over time. Given various
organizational or capacity issues, these applications are often implemented with standalone
server farms and load-balancing devices. Adding a new application in this mode requires the
purchase of at least one new load balancer.
Deploying ACE
83
Replacing Multiple Load Balancers

Enterprise
Network
ACE
Virtual Partition 1
App C
Virtual Partition 2
App D
Virtual Partition 3
App E
Virtual Partition 4
App F
ACE
Virtual Partition 1
App A
Virtual Partition 2
App B
Enterprise with Growing Number of Applications

ACEAP v1.01-25
Multiple ACE contexts can be used to provide the same load-balancing functions needed by the
preceding situation. Additional applications can be added without the purchase of additional
hardware if capacity is available.
84
Multiple Contexts
Physical Device
Admin
Context
Context 1
Context 2
Context 3
Context
Definition
Resource
Allocation
Management
Station
AAA
Admin Context + 250 Contexts (Licensed: 5 Contexts in Base cCode)

ACEAP v1.01-26
Network resources can be dedicated to a single context or shared between contexts, as shown in
the figure.
By default, a context named Admin is created by the ACE. This context can not be removed or
renamed. Additional contexts, and the resources to be allocated to each context, are defined in
the configuration of the Admin context.
The number of contexts that can be configured is controlled by licensing on the ACE. The base
code allows five contexts to be configured, and licenses are available that expand the
virtualization possible to 250 contexts. The Admin context does not count toward the licensed
limit on the number of contexts.
Deploying ACE
85
Configuring Contexts
ACE-AP/Admin# show vlan
Vlans configured on the physical port(s)
vlan33 vlan110 vlan231-238 vlan331-338
ACE-AP/Admin# config
Enter configuration commands,
ACE-AP/Admin(config)# context
ACE-AP/Admin(config-context)#
ACE-AP/Admin(config)# exit
vlan431-438
one per line. End with CNTL/Z.

development
allocate-interface vlan 110
allocate-interface vlan 231-238
exit
ACEAP v1.01-27
The show vlan command can be used to verify the VLANs that have been connected to the
ACE over the Gigabit Ethernet ports.
Contexts are defined in the ACE configuration mode, as shown in the figure. The context
context_name command creates a context and gives it a name. Individual VLANs are then
allocated to each context with the allocate-interface vlan vlan_list command.
86
Configuring Context GUI
ACEAP v1.01-28
The figure shows configuration of a context using the ACE appliance device manager.
The GUI configuration requires the name of the user-defined management policy map, VLAN
interface, IP address/netmask, and allowed protocols when creating a context.
Deploying ACE
87
Verifying Context Configuration

ACE-AP/Admin# show context development
Name: development , Id: 117
Description:
Resource-class: default
Vlans: Vlan110, Vlan231-238
ACE-AP/Admin# show run
Generating configuration....
context development
allocate-interface vlan 110
allocate-interface vlan 231-238
ACEAP v1.01-29
The show context context_name and show running-config commands can be used to verify
the configuration of ACE contexts.
88
Verifying Context Configuration GUI
Config Status
shows here
Config changes
made here
ACEAP v1.01-30
The figure shows the GUI for verifying context configuration.
Deploying ACE
89
Resource Management
This topic explains the resource management controls available on the ACE.
Resource Control
Per-Context Control:
Resource levels for each context
Support for oversubscription
Rates
Memory
Bandwidth
Access lists
Data connections per second
Regular expressions
Management connections per second
Data connections
SSL bandwidth
Management connections
Syslogs per second
SSL connections
Xlates
Sticky entries
ACEAP v1.01-32
ACE hardware resources are allocated to individual contexts under the control of resource-level
controls configured in the Admin context. The resources that can be managed fall into two
categories and are listed in the figure. The rate-based resources are amounts of data or number
of events per second. The memory-based resources control the storage for different kinds of
state and configuration objects, which are stored in memory.
Note
90
The memory available on an appliance-wide basis for each type of state and configuration
data is preallocated.
Resource Classes
Context
Context
Context
Context
Context
Context
Context
ACEAP v1.01-33
Resource allocation controls are defined in resource classes. Each context is then assigned to a
single resource class. If no resource classes are defined, every context is a member of a
resource class named default, which has unlimited access to system resources. A maximum of
100 resource classes can be configured.
Deploying ACE
91
Resource Class Allocation Parameters
Maximum
Unlimited
Maximum
Equal to
Minimum
Minimum
Guarantee
Minimum
Guarantee
ACEAP v1.01-34
Individual resource allocation controls specify a minimum and a maximum resource allocation,
which is configured as a percentage of overall system resources. Minimum resource allocations
constitute a guaranteed resource allocation. Maximum resource allocations can either be
specified as unlimited or as equal to the minimum.
The resource allocations defined in a resource class are applied to each context in the resource
class. For example, a resource class that specifies a 20 percent minimum resource allocation
and that has four contexts results in 80 percent of system resources allocated.
92
Resource Oversubscription
Oversubscribed Global Pool

Context 4 Minimum
Context 3 Minimum
Context 2 Minimum
Context 1 Minimum
ACEAP v1.01-35
Defining a resource class with a maximum resource allocation of unlimited allows resources to
be oversubscribed. Each context in the resource class receives the guaranteed minimum. Given
a maximum of unlimited, the contexts that are able to allocate from the global pool of resource
are not guaranteed. Allocation requests in the global pool are handled on a first-come-firstserved basis. The figure shows four contexts, all of which are competing for resources in the
global pool to satisfy requirements above their guaranteed minimums.
Deploying ACE
93
Configuring Resource Management
Oversubscribed Global Pool

Context 4 Minimum
Context 3 Minimum
Context 2 Minimum
Context 1 Minimum
ACE-AP/Admin(config)# resource-class testing
ACE-AP/Admin(config-resource)# limit-resource all minimum 20%
maximum unlimited
ACE-AP/Admin(config)# context IT-lab
ACE-AP/Admin(config-context)# member testing
ACEAP v1.01-36
Resource classes are defined with the resource-class resource_class_name command. Within
the resource-class definition, limit-resource commands are used to define the resource controls
for each type of resource. Contexts are placed in a resource class by configuring the member
resource_class_name command in the context configuration submode.
In the configuration shown in the figure, a resource class named testing, which guarantees a
minimum of 20 percent of all system resource types with an unlimited maximum, is defined.
The IT lab context is then configured to be a member of the testing resource class.
The full syntax of the limit-resource command is as follows:
limit-resource {acl-memory | all | buffer {syslog}| conc-connections |
mgmt-connections | proxy-connections | rate {bandwidth | connections |
inspect-conn | mac-miss | mgmt-traffic | ssl-connections | syslog} |
regexp | sticky | xlates} {minimum percentage} {maximum {equal-to-min
| unlimited}}
94
Configuring Resource Management GUI
ACEAP v1.01-37
Resource configuration in the ACE Device Manager located at Config > Virtual Contexts >
Systems > Resource Class.
Note
The default category in the GUI is equivalent to the all option in the CLI.
Deploying ACE
95
Resource Class show Commands

ACE-AP/Admin# show resource allocation
----------------------------------------------------------Parameter
Min
Max
Class
----------------------------------------------------------acl-memory
0.00%
100.00%
default
20.00%
200.00%
gold
syslog buffer
0.00%
20.00%
100.00%
200.00%
default
gold
conc-connections
0.00%
20.00%
100.00%
200.00%
default
gold
mgmt-connections
0.00%
20.00%
100.00%
200.00%
default
gold
proxy-connections
0.00%
20.00%
100.00%
200.00%
default
gold
ACEAP v1.01-38
The show resource allocation command shows the aggregate results of all of the resource
class and context configuration. The command output lists each resource type in the left
column. Each resource class that defines allocation controls for that resource type is
enumerated with a minimum and maximum amount and the resource class name that is in the
far-right column.
The Min column represents the minimum guarantee defined in the resource class times the
number of member contexts. For a example, a minimum of 20 percent might represent two
contexts that are members of a resource class that defines a minimum of 10 percent.
In resource class definitions that specify maximum equal-to-min, the maximum column
contains the same number as the minimum. In cases where maximum unlimited is configured,
the maximum column gives an indication of the oversubscription level for that particular
resource type, given the number of contexts in the resource class. For example, a maximum of
1200 percent represents a resource class with 12 contexts, which permits oversubscription.
96
Resource Class show Commands (Cont.)

ACE-AP/C1# show resource usage
Allocation
Resource
Current
Peak
Min
Max
Denied
-------------------------------------------------------------------Context: C1
conc-connections
0
0
800000
7200000
0
mgmt-connections
0
0
500
4500
0
proxy-connections
0
0
104858
943716
0
xlates
0
0
104858
943716
0
bandwidth
0
0
50000000 450000000
0
connection rate
0
0
100000
900000
0
ssl-connections rate
0
0
100
900
0
mgmt-traffic rate
0
0
12500000 112500000
0
mac-miss rate
0
0
200
1800
0
inspect-conn rate
0
0
600
5400
0
acl-memory
0
0
7861044
78610432
0
regexp
0
0
104858
1048576
0
ACEAP v1.01-39
The figure identifies resource class show commands.
Deploying ACE
97
Resource Usage GUI
ACEAP v1.01-40
The figure shows how to display resource usage for the GUI.
To get to the resource usage page, go to Monitor > Virtual Contexts > Resource Usage.
98
Authorizing Management Users

This topic explains the process of granting access to authorized users for management tasks.
Role-Based Access Control

Command Categories
Rules grant:
Create
Modify
Debug
Monitor
User-Accessible Commands
ACEAP v1.01-42
RBAC defines roles to which management users are assigned. Each role defines the level of
action that the user can perform on predefined categories of commands. The available levels of
actions are:
Monitor: Specifies commands for monitoring resources and objects (show commands)
Debug: Specifies commands for debugging problems (includes monitor commands)
Modify: Specifies commands for modifying existing configurations (includes debug and
monitor commands)
Create: Specifies commands for the creation of new objects or the deletion of existing
objects (includes modify, debug, and monitor commands)
Deploying ACE
99
Predefined Default Roles

Admin: Access to all functions in the context/device
SLB Admin: Server farm, servers, health monitoring
Security Admin: Access control, inspection, AAA,
NAT
Server Maintenance: Servers in/out of rotation, debug
of SLB functions
Server Application Maintenance: Servers, health
monitoring, load-balancing rules
Network Admin: Interfaces, routing, NAT, TCP
Network Monitor: Access to all show commands only
ACEAP v1.01-43
Predefined default roles exist that can not be modified. However, new roles can be created and
customized appropriately.
The capabilities of each role are shown in the following show role command output:
switch/Admin# show role
Role: Admin (System-defined)
Description: Administrator
Number of rules: 4
--------------------------------------------Rule Type Permission
Feature
--------------------------------------------1. Permit Create
all
2. Permit Create
user access
3. Permit Create
system
4. Permit Create
changeto
Role: Network-Admin (System-defined)
Description: Admin for L3 (IP and Routes) and L4 VIPs
Number of rules: 7
Feature
--------------------------------------------1. Permit Create
interface
2. Permit Create
routing
3. Permit Create
connection
4. Permit Create
nat
5. Permit Create
vip
6. Permit Create
config_copy
7. Permit Create
changeto
100
Role: Server-Maintenance (System-defined)

Description: Server maintenance, monitoring and debugging
Number of rules: 6
Feature
--------------------------------------------1. Permit Modify
real
2. Permit
Debug
serverfarm
3. Permit
Debug
vip
4. Permit
Debug
probe
5. Permit
Debug
loadbalance
6. Permit Create
changeto
Role: Server-Appln-Maintenance (System-defined)
Description: Server maintenance and L7 policy application
Number of rules: 5
Feature
--------------------------------------------1. Permit Create
real
2. Permit Create
serverfarm
3. Permit Create
loadbalance
4. Permit Create
config_copy
5. Permit Create
changeto
Role: SLB-Admin (System-defined)
Description: Administrator for all load-balancing features
Number of rules: 9
Feature
--------------------------------------------1. Permit Create
real
2. Permit Create
serverfarm
3. Permit Create
vip
4. Permit Create
probe
5. Permit Create
loadbalance
6. Permit Create
nat
7. Permit Modify
interface
8. Permit Create
config_copy
9. Permit Create
changeto
Role: Security-Admin (System-defined)
Description: Administrator for all security features
Number of rules: 8
Feature
--------------------------------------------1. Permit Create
access-list
2. Permit Create
inspect
3. Permit Create
connection
4. Permit Modify
interface
Deploying ACE
101
5. Permit Create
aaa
6. Permit Create
nat
7. Permit Create
config_copy
8. Permit Create
changeto
Role: SSL-Admin (System-defined)
Description: Administrator for all SSL features
Number of rules: 5
Feature
--------------------------------------------1. Permit Create
ssl
2. Permit Create
pki
3. Permit Modify
interface
4. Permit Create
config_copy
5. Permit Create
changeto
Role: Network-Monitor (System-defined)
Description: Monitoring for all features
Number of rules: 2
Feature
--------------------------------------------1. Permit Monitor
all
2. Permit Monitor
changeto
102
Management Domains
Physical Appliance
Context
A
Context
B
Domain1
Domain2
VIP1
VIP 2
Farm1
Farm2
VIP3
Farm3
Farm4
SSL
cert1,2
ACEAP v1.01-44
Objects can be grouped in management domains to restrict management access. Users can issue
commands that affect objects only if they are members of the same domain. Both users and
objects can be members of multiple domains with a limit of ten domains per context. Objects
created by a user who is a member of a domain are automatically added to that users domain.
If no domains are configured, all objects are part of the default domain.
Deploying ACE
103
Management Access Summary
Physical Appliance
Admin
Context
Role
Context
A
Context
B
Context A
Definition
Context B
Definition
Resource
Allocation
Admin
Management
Config
Domain1
Domain2
VIP1
VIP 2
Farm1
Farm2
VIP3
Farm3
Farm4
SSL
Cert1,2
Management Station
Admin
Network/Security
Server Admin
Monitor
AAA
ACEAP v1.01-45
The commands that a user is authorized to issue are controlled by both the role and domain
mechanisms. A user is able to issue only commands that are authorized by the role of which the
user is a member against objects in a common domain.
104
Configuring Management Users

role CONN-MGR
rule 1 permit debug feature interface
domain GROUP_A
add-object interface vlan 110
username c_mgr_a password secretenough role CONN_MGR domain GROUP_A
ACEAP v1.01-46
A role is configured with the role role_name command. Within the role definition, the rule
command specifies the command categories that the user can issue.
Domains are configured with the domain domain_name command. Within the domain
definition, the add-object command is used to add objects to a domain.
Management users are created with the username command, which is used to specify the
username, password, role, and domain.
In the figure, a user named c_mgr_a, who can issue debug interface commands against the
VLAN 110 interface, has been created.
Deploying ACE
105
GUI RBAC
1
2
5
3
ACEAP v1.01-47
The figure shows the screen for adding users, roles, and domains to a context in the ACE
Device Manager GUI.
The GUI allows you to access many pieces of the configuration simultaneously, as shown in
the figure:
1. Here is the location for making changes to RBAC features: Admin > Role-Based Access
Control > [Users | Active Users | Roles | Domains].
2. This is the context being used. RBAC information is context specific. This means that
creating a user c_mgr_a, role CONN-MGR, and domain GROUP_A would only be
available in the development context.
3. Roles and domains can be created, modified, and deleted from here.
4. Roles and domains can also be created in the user configuration area on the fly if needed.
5. Administrators can also monitor active users here and force them to log off if necessary.
106
This topic describes the steps to configure ACE interfaces.
Interface Types
Single Context
BVI
Int
VLAN
INT
VLAN
INT
Bridge Group
VLAN
INT
VLAN
INT
FT
INT
ACEAP v1.01-49
Three types of interfaces are configured on the ACE:
VLAN interfaces connect the ACE to regular data transit VLANs. Configuration of these
interfaces determines whether the VLAN is a routed or bridged interface. VLAN interfaces
that are to be routed are configured with Layer 3 information, and VLANs that are to be
bridged are configured to be members of a bridge group.
Bridge group virtual interfaces (BVIs) are software-only interfaces that are used to
configure the Layer 3 information for the ACE to participate in a bridged network.
FT interfaces connect to VLANs used to connect two fault-tolerant ACE appliances

together. A single ACE is limited to 8 K interfaces with up to 4 K BVI interfaces.
Note
The ACE appliance can be connected to regular VLANs or to the primary VLAN of a PVLAN
configuration.
Deploying ACE
107
Routed interfaces:
interface vlan 231
description Client vlan
ip address 172.16.31.5 255.255.255.0
no shutdown
Bridged interfaces:
interface vlan
bridge-group
no shutdown
interface vlan
bridge-group
no shutdown
231
3
232
3
interface bvi 3
description Server Access vlan
ip address 172.16.31.5 255.255.255.0
no shutdown
ACEAP v1.01-50
Interface configuration is started using the interface vlan vlan_number command. In interface
configuration submode, a description can be added to the interface with the description
command.
Configuration of routed mode VLAN interfaces must also specify the Layer 3 information with
the ip address ip_address network_mask command.
Configuration of bridged mode VLAN interfaces must be associated with a bridge group with
the bridge-group group_number command. The bridge group number is locally significant
within the context and is not visible to connected resources. The two interfaces to be bridged
must be associated with the same bridge group.
Layer 3 information for a bridge group is configured by defining a BVI interface with the
interface bvi group_number command. The bridge group number must match the bridge group
number that is used to tie the bridged VLAN interfaces together.
Finally, all interfaces must be administratively activated with the no shutdown command.
After the interface is administratively active, its state is controlled by several factors. Routed
mode VLAN interfaces and BVI interfaces must have Layer 3 information configured. Bridged
mode VLAN interfaces must have been assigned to a bridge group and the associated BVI must
be up.
108
Shared Interfaces
Contexts can share routed interfaces.
No conflicting IPs on shared interface.
Intercontext traffic must be L3 routed.
VLAN 100
192.168.100.0/24
Context
A
Context
B
ACEAP v1.01-51
VLAN interfaces can be shared by more than one context as long as the interfaces are
configured in routed mode. IP addresses on the shared interfaces must be unique and must be in
the same subnet. This includes the IP addresses assigned to the VLAN interface and any
floating IP addresses, such as alias IP addresses or VIP addresses.
Intercontext traffic must be processed by a Layer 3 router outside the ACE router, even if the
destination IP address is Layer 2 adjacent to the transmitting context.
Deploying ACE
109
MAC Address Allocation
ID Prom
MAC
Use
Supervisor
Layer 3
Unshared
VLAN
38
Unused
Shared MAC addresses:

16 1K Pools globally
shared-vlan-hostid selects 1
ACEAP v1.01-52
The MAC address IDPROM on an ACE contains eight unique MAC addresses. The first is
used as the MAC address of the Supervisor Layer 3 interface in any unshared VLAN attached
to the ACE. The second address in the IDPROM is used as the MAC address for any IP
addresses on unshared interfaces on the ACE.
Shared interfaces are addressed differently. One of the interfaces on a shared VLAN uses the
second MAC address from the IDPROM above. Additional MAC addresses for this VLAN are
allocated from 1 of 16 pools of addresses, each of which contains 1000 MAC addresses. These
16 MAC address pools are shared by every ACE worldwide. The shared-vlan-hostid
command can be used to manually configure which pool the ACE will select.
110
Summary
Summary
ACE connects to the network through VLANs.
The ACE appliance has an interactive setup script to complete

the initial setup and connect the device to the network.
The ACE appliance has a GUI for ease of configuration.
Several network topologies are possible with the ACE appliance,

including bridged, routed, one-arm, and direct server return.
Multiple contexts can be defined in a single ACE appliance.
Hardware resource allocation to each context can be controlled

through configuration options.
Management users can be granted specific access to objects

within the ACE.
Interfaces are configured to define the ACE connections to the

network from a functional perspective.
ACEAP v1.01-53
Deploying ACE
111
112
Lesson 3
Modular Policy CLI

Overview
In this lesson, you will learn how to describe the structure and function of the Modular Policy
CLI statements used to configure ACE features.
Objectives
Upon completing this lesson, you will be able to describe the structure and function of the
Modular Policy CLI statements used to configure ACE features. This includes being able to
meet these objectives:
Describe the structure and configuration of class maps
Describe the structure and configuration of policy maps
Describe the steps necessary to activate policy maps
Class Maps
This topic describes the structure and configuration of class maps.
Introducing Class Maps

Classify Traffic
Define criteria used to classify
traffic in class maps
Define Actions
Define processing steps to be
performed on traffic in policy
maps
Activate Policy
Associate policy defined with a
traffic stream
ACEAP v1.01-4
The first step in configuring the necessary traffic processing in the Cisco 4710 Application
Control Engine (ACE) appliance is to define class maps that contain criteria that classify traffic
as interesting; that is, to be handled by further configuration steps.
114
Class Map: Structure

Class name
Class type
Match criteria
Matched
Traffic
Characteristics
Match type
Not Matched
ACEAP v1.01-5
A class map defines the traffic characteristics that are used to analyze traffic. For each packet,
the class map returns an indication of whether the packet matched the defined criteria. Notice
that the class map does not change anything about the packets. It merely decides if a packet is
interesting, based on selection criteria. As shown in the figure, a stream of packets is going to
be processed by the class map. After a packet has been processed, it has an indication of
whether it was classified as interesting (that is, matched) by the class map. In the figure, the
first two packets have been analyzed and only the first packet was marked as interesting.
Several different types of class maps can be defined. Each type of class map is designed to
analyze characteristics that are relevant for different types of traffic processing.
Class maps have four components:
A name for the class
The type of class
The criteria used to analyze traffic
The logic used to aggregate the results of multiple criteria
Modular Policy CLI
115
Class Map: Name
Class Name
Class Type
Match Criteria
Match Type
Matched
Class Name: AuthUsers
Not Matched
ACEAP v1.01-6
Like most objects created in the ACE CLI, class maps are named objects. The names are used
to identify the class map that is to be used when policy maps are constructed. The class names
are case sensitive and are available for Tab-key completion in commands that have a class
name as a parameter. In the example shown in the figure, a class called AuthUsers is created.
116
Class Map: Class Type
Class Name
Class Type
Match Criteria
Match Type
Matched
Class Type: Layer 3/4
Not Matched
ACEAP v1.01-7
Multiple types of classes exist. The types available are:
Layer 3 and 4: Analyzes the IP and TCP/UDP fields in the packet
FTP inspection: Analyzes the FTP commands and responses
HTTP inspection: Analyzes the HTTP fields in the packet
HTTP load balancing: Analyzes the HTTP request fields used in making load-balancing
decisions
Management access: Analyzes management traffic
The specific details of the various class map types are discussed on a feature-by-feature basis.
In the example in the figure, the AuthUsers class map is designated as a Layer 3 and 4 class
map.
Modular Policy CLI
117
Class Map: Match Criteria
Class Name
Class Type
Match Criteria
Match Type
Matched
Not Matched
ACEAP v1.01-8
The match criteria in the class map define the traffic characteristics of the incoming traffic that
is analyzed. The specific match criteria available in a class map depend on the type of the class
map. Multiple criteria can be created within a single class map. The sample class map in the
figure has three criteria, which are used to analyze traffic.
118
Class Map: Match All
Class Name
Class Type
Match Criteria
Match Type
Matched

and
and
= matched
X
Not Matched
ACEAP v1.01-9
The figure shows a match all condition.
Modular Policy CLI
119
Class Map: Match Any
Class Name
Class Type
Match Criteria
Match Type
Matched

or
or
= matched
X
Not Matched
ACEAP v1.01-10
The figure shows a match any condition.
120
Class Maps
General Structure:
class-map [type class_type] [match_type] class_name
[linenumber] match match_criteria
Available class map types:

class-map
class-map
class-map
class-map
class-map
[match-all | match-any] map_name

type ftp inspect match-any map_name
type http inspect [match-all | match-any] map_name
type http loadbalance [match-all | match-any] map_name
type management [match-all | match-any] map_name
ACEAP v1.01-11
Class maps are configured with the class-map command in configuration mode. The class-map
command specifies the name, type, and match type of the class being defined. After the classmap command is entered, you are placed in the class map configuration submode, where you
can configure match statements to specify the match criteria used for this class. Every match
statement has a line number. The line number can be used to easily delete a long match
statement by specifying no linenumber in the class map configuration submode. A match
statement can be replaced by configuring a new match statement with the same line number.
Note
The line numbers do not imply a specific order or priority of the match criteria.
Syntax Summary
The following is the full syntax of all possible class map-related configuration statements:
class-map [match-all | match-any] map_name
[line_number] match access-list name
[line_number] match any
[line_number] match destination-address ip_address [mask]
[line_number] match port {tcp | udp} {any | eq {port_number} | range
port1 port2}
[line_number] match source-address ip_address mask
[line_number] match virtual-address vip_address {[netmask]
protocol_number | any | {tcp | udp {any | eq port_number | range port1
port2}}}
class-map type ftp inspect match-any map_name
[line_number] match request-method ftp_command
class-map type http inspect [match-all | match-any] map_name
[line_number] match content expression [offset number]
[line_number] match content length {eq bytes | gt bytes | lt bytes |
range bytes1 byte2}
Modular Policy CLI
121
[line_number] match header {header_name | header_field} header-value

expression
[line_number] match header length {request | response} {eq bytes | gt
bytes | lt bytes | range bytes1 bytes2}
[line_number] match header mime-type mime_type
[line_number] match port-misuse {im | p2p | tunneling}
[line_number] match request-method {ext method | rfc method}
[line_number] match transfer-encoding {chunked | compressed | deflate
| gzip | identity}
[line_number] match url expression
[line_number] match url length {eq bytes | gt bytes | lt bytes | range
bytes1 bytes2}
class-map type http loadbalance [match-all | match-any] map_name
[line_number] match class-map name
[line_number] match http cookie {name | secondary name} cookie-value
expression
[line_number] match http header {header_name | header_field} headervalue expression
[line_number] match http url expression [method name]
[line_number] match source-address ip_address [netmask]
class-map type management [match-all | match-any] map_name
[line_number] match protocol {http | https | icmp | snmp | ssh |
telnet} {any | source-address ip_address mask}
122
Policy Maps
This topic describes the structure and configuration of policy maps.
Introducing Policy Maps

Classify Traffic
Define criteria used to
classify traffic in class
maps
Define Actions
Define processing steps
to be performed on traffic
in policy maps
Activate Policy
Associate policy defined
with a traffic stream
ACEAP v1.01-13
The second step in defining traffic processing in the ACE is to define the actions that are to be
performed on traffic that has been classified by a previously defined class map. This
configuration is performed by creating a policy map.
Modular Policy CLI
123
Policy Map: Structure

Name
Policy/Match Type
Policy name
Policy type
Match type
Classification/action
clauses
ACEAP v1.01-14
A policy map defines the actions to be applied to traffic that has been determined to be
interesting. Actions can also be specified for all traffic that has not been classified as
interesting.
Policy maps contain four components, which must be defined:
1. Name of the policy
2. Policy type
3. Match type
4. Classification/action clauses
124
Policy Map: Name

Name: Passengers
ACEAP v1.01-15
Like other resources created by the ACE CLI policy, maps have a name. This name is case
sensitive and is available for the Tab-key completion function when the argument of a
command is the name of a policy. In the figure, a sample policy named Passengers has been
started.
Modular Policy CLI
125
Policy Map: Type

Name: Passengers
Type: Loadbalance
Policy Type
Match Type
Layer 3 and 4
multimatch
FTP Inspect
first-match
HTTP Inspect
all-match
Loadbalance
first-match
Management
first-match
ACEAP v1.01-16
Policy maps have a policy type and a match type, which are interrelated. The policy type
defines the types of classifications and actions that are available, and the match type handles
situations in which multiple classification criteria have defined the traffic as interesting.
Policy Type
The available policy types correspond to the class map types and are:
Layer 3 and 4 : Processes traffic selected by the IP and TCP/UDP fields in the packet
FTP inspection: Processes FTP commands and responses
HTTP inspection: Processes HTTP requests
HTTP load balancing: Load balances HTTP requests
Management access: Processes management traffic
In the figure, the Passengers policy map is designated as a load-balancing policy map.
Match Type
The match type controls how packets are processed if they are classified as interesting by more
than one of the class maps used in a policy. There are three match types:
126
all-match: Actions associated with all the matching class maps are performed on the
packet.
first-match: Actions associated with the first class that matches are performed on the
packet, and successive classes are ignored.
multi-match: Multiple classes exist in the policy map that use different features of the
ACE. Processing actions from several features can be applied to the packet, but each
feature operates in a first-match basis within the collection of classification/action clauses
that use that feature.
Each of the defined policy types has a match type that is used for that policy type. The mapping
between policy type and match type is shown in the table.
Policy maps have a policy type and a match type that are interrelated. The policy type defines
the type of classifications and actions that are available, while the match type handles situations
in which multiple classification criteria have defined the traffic as interesting.
Modular Policy CLI
127
Policy Map: Classification/Action Clause

Name: Passengers
Type: Loadbalance
Classification:
Class
Inline match
Actions defined in
configuration submode
Business Class
Give Food
Give Legroom
ACEAP v1.01-17
Classification-action clauses are used to specify the actions that are to be performed on any
packet that is classified as interesting. The clause is started by specifying the classification to be
performed. Class maps of the appropriate type can be used to classify traffic. Inline match
statements can also be used to classify traffic on a single criteria. After a classification
mechanism has been specified, you are in a submode of the policy map configuration mode,
which allows one or more actions to be specified.
The policy map in the figure uses a class map called Business Class to classify traffic. Anyone
who is a member of this class is the recipient of two actions giving them food and legroom.
128
Policy Map: class-default

Name: Passengers
Business Class
Type: Loadbalance
Give Food
Give Legroom
Give Food
ACEAP v1.01-18
The predefined class class-default can be used to specify the actions to be performed on
packets that have not matched any of the class maps specified in the policy map. The example
in the figure shows passengers who, if they have not been booked in a better class, are given
food.
Modular Policy CLI
129
Policy Map: insert-before

Name: Passengers
Type: Loadbalance
First Class
Give Food
Give Drinks
Give Legroom
Business Class
Give Food
Give Legroom
Give Food
ACEAP v1.01-19
The order in which classification/action clauses are processed is important for many of the
policy map types. Normally the classification/action clauses are processed in the order in which
they were configured. However, a mechanism exists to insert a classification/action clause
preceding an existing one. This is done with the insert-before keyword on the classification
definition command.
In the example, policy maps have been extended as shown with the addition of a First Class
classification/action clause preceding the Business Class classification/action clause.
Note
130
class-default is always processed last, no matter what order the classification/action

clauses are defined in.
Policy Maps
General structure:
policy-map [type policy_type] match_type policy_name
class {name [insert-before name] | class-default}
action_specifications
match name match_criteria [insert-before name]
action_specifications
Available policy map types:

policy-map
policy-map
policy-map
policy-map
policy-map
multi-match map_name
type inspect ftp first-match map_name
type inspect http all-match map_name
type loadbalance first-match map_name
type management first-match map_name
ACEAP v1.01-20
Policy maps are configured in configuration mode. The policy-map command is used to
specify the policy type, match type, and policy name. After this command is entered, you are
placed in the policy map configuration submode, where you can specify your classification
statements with either the class or match command. Either of these statements places you in a
submode of the policy map configuration submode where you can specify the actions to be
taken for packets matching the classification.
Syntax Summary
The following is the full syntax of all possible policy map-related configuration statements.
policy-map multi-match map_name
class {name1 [insert-before name2] | class-default}
appl-parameter http advanced-options name
connection advanced-options name
inspect {dns [maximum-length bytes]} | {ftp [strict policy
policy_map1]} | {http [policy policy_map2 | url-logging]} | {icmp
[error]} | rtsp
loadbalance policy name
loadbalance vip advertise [active] | [metric number]
loadbalance vip icmp-reply [active]
loadbalance vip inservice
nat dynamic nat_id vlan number
nat static ip_address netmask mask {port1 | tcp eq port2 | udp eq
port3} vlan number
ssl-proxy {client | server} ssl_service_name
Modular Policy CLI
131
policy-map type inspect ftp first-match map_name

class name
match name request-method ftp_command
deny
mask-reply
policy-map type inspect http all-match map_name
match name content expression [offset number] [insert-before map_name]
match name content length {eq bytes | gt bytes | lt bytes | range
bytes1 bytes2} [insert-before map_name]
match name content-type-verification [insert-before map_name]
match name header {header_name | header_field} header-value expression
[insert-before map_name]
match name header length {request | response} {eq bytes | gt bytes |
lt bytes | range bytes1 bytes2} [insert-before map_name]
match name header mime-type mime_type [insert-before map_name]
match name port-misuse {im | p2p | tunneling} [insert-before map_name]
match name request-method {ext method | rfc method} [insert-before
map_name]
match name strict-http [insert-before map_name]
match name transfer-encoding coding_types [insert-before map_name]
match name url expression [insert-before map_name]
match name url length {eq bytes | gt bytes | lt bytes | range bytes1
bytes2} [insert-before map_name]
permit
reset
policy-map type loadbalance first-match map_name
class [name1 [insert-before name2] | class-default]
match name1 http cookie {name2 | secondary name3} cookie-value
expression [insert-before map_name]
match name http header {header_name | header_field} header-value
expression [insert-before map_name]
match name http url expression [method name] [insert-before map_name]
match name source-address ip_address mask [insert-before map_name]
drop
forward
insert-http name header-value expression
serverfarm name1 [backup name2 [sticky | aggregate-state]]
set ip tos value
ssl-proxy client name
sticky-serverfarm name
policy-map type management first-match map_name
deny
permit
132
Applying Policy Maps

This topic describes the steps necessary to activate policy maps.
Modular Policy CLI: Concepts

Classify Traffic
Define criteria used to classify
traffic in class maps
Define Actions
Define processing steps to be
performed on traffic in policy
maps
Activate Policy
Associate policy defined with a
traffic stream
ACEAP v1.01-22
The third step in defining traffic processing in ACE is to associate previously defined policy
maps with a stream of packets to be classified and processed. This traffic stream contains the
packets that are analyzed for the presence of the criteria configured in the class maps. Packets
that have these criteria are processed according to the actions of the policy map associated with
the traffic stream.
Modular Policy CLI
133
Associate Traffic Stream
Traffic Stream
Class Map
Policy Map
Activate Policy
Traffic
Characteristics
Matched
Traffic
Characteristics
Matched
class-default
Actions
Actions
Actions
ACEAP v1.01-23
The figure shows an associate traffic stream.
134
Multiple Traffic Streams
Traffic Stream
Traffic
Characteristics
Matched
Traffic
Characteristics
Matched
Actions
Traffic Stream
Class Map
Policy Map
Activate Policy
class-default
Actions
Actions
ACEAP v1.01-24
Multiple traffic streams can be associated with the same policy map. This provides a
mechanism to provide the same traffic-mapping function to several different sources of packets.
For example, a policy map can be used to provide the same classification and processing to
packets being received by the ACE module on several different interfaces.
Modular Policy CLI
135
Multilayer Processing
Class
Type 1
Class
Type 2
Class
Type 1
Class
Type 2
Layer 3 and 4
Management
Class
Type 2
FTP Inspect
HTTP Inspect
Loadbalance
ACEAP v1.01-25
Policy maps must be associated with one or more traffic streams. These traffic streams supply
the packets that are analyzed and processed. Two layers of processing are possible with the
ACE; therefore, two methods are used to associate traffic streams with a policy map. Which
method is used depends on the type of policy map.
Primary Policy Maps

The primary policy map types, Layer 3 and 4 and Management, are attached directly to
interfaces with the service-policy command. These policy maps then process traffic streams
that consist of all the packets received by the ACE on those interfaces.
Secondary Policy Maps

The secondary policy map types, FTP Inspect, HTTP Inspect, and Loadbalance, are attached to
a traffic stream as the result of an action in a Layer 3 and 4-type policy map. The traffic streams
for these policy maps consist of the packets that have been matched by the class maps in the
Layer 3 and 4 policy map that references the secondary policy map as a processing action.
After a packet has matched a class map, it is no longer part of class-default in the policy map
containing the matching class map. Such classified packets are never processed by the actions
associated with class-default, regardless of the results of a secondary policy. For example, a
packet matched by the first class in the primary policy map in the figure is processed by the
associated secondary policy map. These packets are not processed by the actions associated
with the class-default class in the primary policy map, even if they do not match any of the
class maps that are contained in the secondary policy map.
136
Using service-policy
Class
Type 1
Class
Type 1
Attach a policy map to one or more interfaces:

service-policy input policy_name
ACEAP v1.01-26
Primary policy maps are attached to one or more interfaces with the service-policy command.
This command is issued in the interface configuration submode to attach a policy map to a
single interface. The service-policy command can also be used in global configuration mode to
attach the policy map to all interfaces. Policy maps that are applied to a single interface
override any globally applied policy maps for overlapping classification types.
Several policy maps can be attached to a particular interface. However, only one policy map for
each different feature is recommended.
Modular Policy CLI
137
Validating Traffic Mapping

Display subsets of running-config:
show running-config class-map
show running-config policy-map
Display active service:

show service-policy policy_name [detail]
ACEAP v1.01-27
The configured class and policy maps can be displayed by specifying the class-map or policymap arguments to the show running-config command. Information about applied policy maps
and the statistics related to them can be displayed with the show service-policy command.
138
Policy Lookup Order

There can be many features applied on a given interface, so the
feature lookup ordering is important.
The feature lookup order followed by datapath in ACE is as
follows:
Access control (permit or deny a packet)
Management traffic
TCP normalization and connection parameters
Server load balancing
Fixups and application inspection
Source NAT
Destination NAT
The policy lookup order is implicit, regardless of the order in

which the user configures policies on the interface.
ACEAP v1.01-28
Traffic streams received on a particular interface can be processed by several features on the
ACE. The Modular Policy CLI enables you to create several policy maps covering many of
these different features and associate them all with the same interface. The ACE processes
packets with the features configured. Instead of using the order in which the features were
configured, the ACE processes packets with features in a consistent order on every interface.
Modular Policy CLI
139
Summary
Summary
Class maps are used to classify traffic.
Policy maps match actions with traffic classification (class maps).
Policy maps must be activated for processing to occur by
attaching the service policy (Layer 3 and 4 policy map) to a traffic
stream or interface.
140
ACEAP v1.01-29
Lesson 4

Overview
In this lesson, you will learn how to describe the methods used to manage the ACE appliance.
Objectives
Upon completing this lesson, you will be able to describe the methods used to manage the ACE
appliance. This includes being able to meet these objectives:
Explain how to control management access to the ACE
Describe SNMP support for multiple contexts
Permitting Management Traffic

This topic explains how to control management access to the ACE.
Management Class Map
class-map type management match-any remote-access

description Match authorized management traffic
2 match protocol telnet source-address 172.16.31.0 255.255.255.0
3 match protocol ssh any
4 match protocol https any
ACEAP v1.01-4
Management access to the Cisco 4710 Application Control Engine (ACE) appliance is initially
limited to the console port and the session command from the Catalyst 6500 chassis. The first
step in allowing remote management access is the definition of a management-type class map.
This class map classifies traffic based on the protocol being used and, optionally, on the source
IP address.
The full syntax of the match protocol command is as follows:
match protocol {http | https | icmp | snmp | ssh | telnet} {any |
source-addressip_address mask}
In the figure, a management class map named remote-access is created. The remote-access
class map matches incoming Telnet connections from systems in the 172.16.31.0 255.255.255.0
subnet. It also matches incoming Secure Shell (SSH) or HTTPS connections from anywhere.
142
Management Policy Map

policy-map type management first-match remote-mgmt
class remote-access
permit
ACEAP v1.01-5
The second step in permitting remote access is to configure a management-type policy map.
This policy map associates the permit action with traffic classified as interesting by
management-type class maps used in the policy map. The deny action is also available in a
management-type policy map.
In the figure, the remote-access class map that was previously defined in a new policy map
called remote-mgt is used. Any traffic matching the remote-access class is permitted for
management access to the ACE.
143
Activating Management Policy Maps

class remote-access
permit
interface vlan 231
service-policy input remote-mgmt
ACEAP v1.01-6
Now the policy must be associated with a traffic stream to be effective. Management-type
policy maps are attached to one or more interfaces with the service-policy command.
The figure shows the interface configuration for VLAN 231. You attach the remote-mgmt
policy map to this interface to allow traffic received by the interface to be processed by the
policy map.
144
Validating Management Policy Configuration

switch/context# show run class-map | begin remote-access
switch/context# show run policy-map | begin remote-mgmt
class remote-access
permit
switch/context# show run interface | begin 231
interface vlan 231
service-policy input remote-mgmt
ACEAP v1.01-7
Subsets of running-config can be displayed by adding optional keywords to the show runningconfig command. In the figure, the class-map, policy-map, and interface keywords are used.
Another technique that is useful for finding information in a long configuration is use of the
pipe symbol (|) followed by one of several available filters. Shown here is the use of the begin
filter, which starts the output when the specified regular expression is found in the output.
145
Validating Management Policy Status
switch/context# show service-policy remote-mgmt

Status
: ACTIVE
----------------------------------------Interface: vlan 231
service-policy: remote-mgmt
ACEAP v1.01-8
The show service-policy policy_name [detail] command can be used to display run-time
information about a service policy. The figure shows the output when this command is applied
to a management policy.
146
Configuring Context GUI
2
3
ACEAP v1.01-9
The ACE Device Manager GUI automatically sets up the management class map, policy map,
and service policy.
The sections of the GUI correspond to the CLI as follows:
1. Protocols to allow = class map type management (permit action clauses for policy-map)
2. Policy name = policy map type management
3. VLAN to use = service policy applied to the VLAN interface
Note
Service policies can also be applied globally to all interfaces from the Config > Virtual
Contexts > System > Global Policy area of the Device Manager.
147
SNMP Manageability
This topic describes SNMP support for multiple contexts.
SNMP Support
ACE
NMS
SNMP versions 1, 2c, 3.

User-configurable SNMP engine ID per context.
SNMP GET to the Admin context can retrieve information about
any context.
SNMP GET to a user context still retrieves information for that
context only.
ACEAP v1.01-11
SNMP versions 1, 2c, and 3 can be used to manage the ACE appliance. The SNMP support
allows for a configurable SNMP engine ID per context. User context information can be
retrieved through SNMP GET requests sent to the Admin context or through SNMP GET
requests to the individual user context.
148
Multicontext SNMP Through Admin
ACE
NMS
NMS configured with Admin context IP address.

SNMPv1/2c uses the community string community@context to
retrieve data from a context.
SNMPv3 specifies the context name in the Context-Name field of
the SNMP GET.
ACEAP v1.01-12
SNMP management of contexts on the ACE appliance can be accomplished through the NMS
configuration guidelines shown in the figure.
149
Configuring Basic SNMP Parameters
ACE
NMS
snmp-server contact Example NOC shift supervisor

snmp-server location Atlanta DC1, Rack 42
ACEAP v1.01-13
The SNMP contact information and location information are configured with the snmp-server
contact contact_information command and the snmp-server location location command,
respectively. The figure shows the contact information configured for example.coms ACE
appliance in Atlanta Data Center 1.
150
Configuring SNMPv1/2c Community Strings
ACE
NMS
snmp-server community grand-poobah

snmp-server community status-keepers ro
ACEAP v1.01-14
SNMP community strings used by SNMP versions 1 and 2c are configured with the snmpserver community community_name [group group_name | ro] command. The ro option
specifies that a particular community string is granted only read-only access. The figure shows
a community string of grand-poobah configured with read-write access and a second
community string of status-keepers that grants only read access.
151
Configuring SNMPv3 Users
ACE
NMS
snmp-server user nms-control auth MySecret!
ACEAP v1.01-15
SNMP version 3 user IDs are created with the snmp-server user user_name [group_name]
[auth {md5 | sha} password1 [localizedkey | priv {password2 | aes-128 password2}]]
command. Passwords for users with both SNMP and CLI access are synchronized by the ACE
appliance. The figure shows a user being created.
152
Configuring SNMP Traps
ACE
NMS
snmp-server host 10.1.1.4 grand-poobah traps version 2c
snmp-server enable traps slb vserver
snmp-server trap-source vlan 110
ACEAP v1.01-16
ACE-initiated SNMP notifications can be sent to a NMS in the form of a trap or inform
message. The servers to which these messages will be sent are configured with the snmpserver host host_address community-string_username { informs | traps } version {1 {udpport} | 2c {udp-port} | 3 [auth | noauth | priv]}} command. Different types of trap
notifications are possible and are configured with the snmp-server enable traps
[notification_type] [notification_option] command. The notification_type and
notification_option parameters are defined as follows:
notification_type: (Optional) Specifies the type of notification to enable. If no type is

specified, the ACE sends all notifications. Specify one of the following keywords as the
notification_type:
license: Sends SNMP license manager notifications. This keyword appears only in
the Admin context.
Slb: Sends server load balancing notifications. When you specify the slb keyword,
you can specify a notification_option value.
Snmp: Sends SNMP notifications. When you specify the snmp keyword, you can
specify a notification_option value.
Syslog: Sends error message notifications (Cisco Syslog MIB). Specify the level of
messages to be sent with the logging history level command.
virtual-context: Sends virtual context (ACE user context) change notifications. This
keyword appears only in the Admin context.
153
notification_option: (Optional) One of the following SNMP notifications:
When you specify the snmp keyword, specify the authentication, coldstart,
linkdown, or linkup keyword to enable SNMP notifications. This selection
generates a notification if the community string provided in the SNMP request is
incorrect, or when a VLAN interface is either up or down. The coldstart keyword
appears only in the Admin context.
When you specify the slb keyword, specify the real or vserver keyword to enable
server load balancing notifications. This selection generates a notification if the
following state change occurs:
The real server changes state (up or down) due to user intervention, ARP
failures, or probe failures.
The virtual server changes state (up or down). The virtual server represents the
servers behind the content switch in the ACE to the outside world and consists
of the following attributes: the destination address (can be a range of IP
addresses), the protocol, the destination port, or the incoming VLAN.
Link up and link down messages can be sent in two different formats. By default, the ACE
appliance uses a Cisco format. You can use a standardized format by configuring the snmpserver trap link ietf command.
The interface that is to be used as the source IP address of SNMP traps is configured with the
snmp-server trap-source vlan number command.
154
SNMP in the GUI
ACEAP v1.01-17
The figure shows the different SNMP characteristics that can be configured in the ACE
appliance Device Manager.
155
Summary
Summary
Management access to the ACE is controlled with the Modular
Policy CLI.
The ACE appliance is fully manageable through SNMP. The
Admin context allows full control of all contexts, while SNMP
actions directed to individual contexts affect only that context.
156
ACEAP v1.01-18
Lesson 5
Security Features
Overview
In this lesson, you will learn how to describe the ACE features that provide IP applicationbased security.
Objectives
Upon completing this lesson, you will be able to describe the ACE features that provide IP
application-based security. This includes being able to meet these objectives:
Describe simple IP access control lists
Explain IP fragmentation processing
Explain TCP/IP normalization
Explain NAT and PAT
IP Access Control Lists

This topic describes simple IP access control lists.
Configuring IP Access Control Lists

IP extended access control list entry:
access-list name [line number] extended {deny | permit} protocol
{src_ip_address netmask | any | host src_ip_address}
{dest_ip_address netmask | any | host dest_ip_address}
TCP or UDP extended access control list entry:

access-list name [line number] extended {deny | permit} {{tcp | udp}
{src_ip_address netmask | any | host src_ip_address}} [operator port1 [port2]]
{dest_ip_address netmask | any | host dest_ip_address} [operator port3 [port4]]
ICMP extended access control list entry:

access-list name [line number] extended {deny | permit} icmp
{src_ip_address netmask | any | host src_ip_address}
{any | host dest_ip_address | dest_ip_address netmask}
[icmp_type] [code operator code]
ACEAP v1.01-4
All flows through the Cisco 4710 Application Control Engine (ACE) appliance must be
allowed by an access control list (ACL). Any packets that are not part of an existing flow and
are not permitted by an ACL entry are discarded.
Note
158
The ACE creates sessions for User Datagram Protocol (UDP) and Internet Control Message
Protocol (ICMP) flows, even though they are connectionless protocols.
Applying Security ACLs

Source
Destination
Client
Server
ACE
input
output
output
input
Source
Destination
Server
Client
access-group {input | output} acl_name

ACEAP v1.01-5
ACLs can be used by various features. They can also be used as security ACLs to control
traffic through the ACE. Security ACLs are applied to an interface with the access-group
command in interface configuration submode. The direction specified for the ACL is relative to
the interface, that is, input refers to traffic being received on the interface. ACLs can also be
used to apply to all interfaces by configuring the access-group command in global
configuration mode. However, ACLs can only be applied globally in the input direction.
Note
An interface can have two IP ACLs, one in each direction.
Caution
No interface-specific input ACLs can be configured if an input ACL has been applied globally
to all interfaces.
Security Features
159
TCP/IP Fragmentation/Reassembly
This topic explains IP fragmentation processing.
IP Fragmentation
Max Packet:
1500 Bytes
Max Packet:
9000 Bytes
ACEAP v1.01-7
IP is supported over many different media types, many of which have different maximum
packet sizes. When an IP packet transits from one media type to another, it might be
determined that the packet is too big for the media used on the next hop. In that case, the IP
packet is fragmented into smaller packets. Normally, after a packet has been fragmented, it is
not reassembled until it is received by the target system.
The figure shows an example of an IP router attached to two networks with different packet
sizes. A packet from the right-hand interface, which supports 9000-byte packets, must be
fragmented into multiple 1500-byte packets for transit out the left-hand interface.
160
Packet Flow for Fragmentation

ACE Dataplane Multiprocessor
Fastpath MP
Fragmentation MP
ACEAP v1.01-8
If packets need fragmentation when they are being transmitted from the ACE appliance, the
fastpath process running on the dataplane multiprocessor detects this condition and sends the
packet to the fragmentation and reassembly processor. The individual fragments are then
returned to the fastpath process for transmit.
Security Features
161
Packet Flow for Reassembly

ACE Dataplane Multiprocessor
Fastpath MP
Reassembly MP
ACEAP v1.01-9
In a similar method, packet reassembly is handled by the dataplane multiprocessor

fragmentation and reassembly micro-engine. If the fastpath micro-engine receives fragments,
they are sent to the fragmentation and reassembly micro-engine for reassembly. The full packet
is then returned to the fastpath micro-engine for processing.
162
Configuration: Fragmentation and Reassembly

Interface level commands:
interface vlan 151:
mtu 4000
fragment chain 10
fragment min-mtu 128
fragment timeout 2
mtu 4000: IP Packets above 4000

must be fragmented.
Fragment chain 10: Packets with
more than 10 fragments are
discarded [default 24].
Fragment min-mtu 128: Fragments
except last one must be at least
128 bytes [default 576].
Fragment timeout 2: Reassembly
timeout for all fragments is 2 secs
[default 5].
Reassembly can be eliminated by fragment chain 1

interface config.
ACEAP v1.01-10
Fragmentation and reassembly are controlled by configuration statements issued in the interface
configuration submode, as shown in the figure.
Security Features
163
TCP/IP Normalization
This topic explains TCP/IP normalization.
Hardware-Based IP Normalization
Always performed:
Following packets are dropped:
src IP == dest IP
Configurable:
icmp-guard
Do Not Fragment flag

(allow, clear)
IP options (allow, clear,

clear-invalid, drop)
Minimum TTL
Verify reverse path
src IP or dest IP == 127.x.x.x

dest IP >= 240.0.0.0
src IP == 0.x.x.x
src IP >= 224.0.0.0
src IP == 0.0.0.0 and dest IP ==

255.255.255.255 allowed for
DHCP requests
ACEAP v1.01-12
IP packet normalization is performed in hardware by the ACE appliance. Sanity checking of the
source and destination IP address fields is always performed according to the rules listed in the
figure. Further IP normalization is configurable and performs the following functions:
164
icmp-guard performs security checks on ICMP messages that pass through the ACE to
filter out unsolicited ICMP responses.
Packets with the Do Not Fragment flag can be allowed to pass, or the flag can be cleared by
the ACE appliance.
IP options can be allowed; cleared; or cleared if an invalid option is detected; or packets

with IP options can be dropped.
A minimum Time to Live (TTL) can be specified for packets received by the ACE.
The ACE appliance can verify that the interface that received an IP packet would be the
same interface on which a response packet would be transmitted.
Hardware-Based TCP Normalization

Always performed on enabled
interface:
src port and dest port != 0
Only SYN packet allowed to create
connection
TCP header >= of 20 bytes
TCP header <= ip->length ip>header_length
urg flag cleared if urg_pointer is
zero
If urg flag not present,
urg_pointer is cleared
Illegal flags combinations dropped
( SYN, RST, and so on)
Configurable:
reserved bits
allow/clear/drop
urg flag
allow/clear/drop
syn-data allow/drop
exceed-mss
allow/drop
random-seq-numdisable
ACEAP v1.01-13
Hardware-based TCP normalization is enabled on an interface-by-interface basis. If enabled,

the header sanity checks listed in the figure are always performed. Additional normalization
parameters can be configured to allow further TCP normalization:
Reserved bits in the TCP header can be allowed through as set; cleared to all zeroes; or
packets with reserved bits on can be dropped by the ACE appliance.
The Urgent flag can be allowed or cleared, or packets with the Urgent flag set can be
dropped.
Synchronize (SYN) packets can be allowed to have data, or dropped if they contain data.
A maximum MSS value can be configured, and packets with a larger MSS can be allowed
or dropped.
Random sequence numbers can be disabled.
Security Features
165
IP Address Spoofing Attacks
Trusted Host
Attacker
Target
3
1 Attacker sends SYN with spoofed address
2 Target sends SYN-ACK
3 Attacker sends ACK with spoofed address
ACEAP v1.01-14
IP address spoofing attacks inject TCP packets into a network to create the illusion that the
target system is communicating with a trusted host. The first step in an IP address spoofing
attack is to send the packets necessary to complete the TCP connection handshake on behalf
of a trusted host. The attacker completes this step by transmitting a SYN packet followed by
an acknowledgment (ACK) packet, both with spoofed source addresses. For the ACK packet to
be successful in establishing the connection, it must contain the acknowledgment number
expected by the target system. This information is contained in the SYN-ACK packet that the
target sends out, but the attacker does not see this packet because it gets routed to the trusted
host being spoofed. If the target system uses a deterministic algorithm to select its initial
sequence number (ISN), the required acknowledgment number can be predicted.
After the attacker has established a TCP session with the target, it can send data to the target
application.
166
Randomized Sequence Numbers
SYN: Seq = X
SYN: Seq = X
SYN-ACK: Seq = Y, Ack = X + 1
SYN-ACK: Seq = Z, Ack = X + 1
ACK: Seq = X + 1, Ack = Z + 1

ACK: Seq = X + 1, Ack = Y + 1
ACEAP v1.01-15
The ACE performs randomization of the sequence numbers returned by protected resources, as
shown in the figure. The client initiates a connection by sending a SYN packet with an ISN of
X, which the ACE passes on to the server. The server sends back a SYN_ACK with an ISN of
Y. The ACE modifies this SYN_ACK packet, replacing Y with a random ISN of Z.
ISN randomization is enabled by default on the ACE.
Control plane connections are exempted.
Security Features
167
Randomized Sequence Numbers (Cont.)
SEQ=Startclient + Sentclient
ACK=StartACE + SentACE + 1
ACK=Startserver + Sentserver + 1
Adjust
Ack number
ACE Server
Adjust
Seq number
ACE Server
SEQ=Startserver + Sentserver
SEQ=StartACE + SentACE
ACK=Startclient + Sentclient + 1
ACEAP v1.01-16
The ACE has created two half-connections with different outbound ISNs, as discussed
previously. Each packet in the TCP connection must therefore be modified to change the
relevant sequence number fields. Inbound packets have an acknowledgment field based on the
outbound ISN and are adjusted by the ACE. The reverse adjustment is applied to the sequence
number field of all outbound packets. The formulas in the figure show the sequence and
acknowledgment numbers for any packet in the TCP connection.
168
Configuring Normalization
ACE
parameter-map type connection TCPIP_PARMS

reserved-bits clear
policy-map multi-match NORMALIZE
class class-default
connection advanced-options TCPIP_PARMS
interface vlan 110
service-policy input NORMALIZE
ip options clear
ACEAP v1.01-17
Normalization is configured in two different ways. IP normalization commands are configured

in the interface configuration submode as shown, with the ip options clear command. TCP
normalization parameters are configured in a parameter-map type connection parameter map
and associated with TCP flows through the connection advanced-options action statement in a
Layer 3 and 4 policy map, as shown in the figure.
Security Features
169
Network Address Translation

This topic explains NAT and PAT.
Static NAT
Mapped IP Address
Real IP Address
Outside Interface
Inside Interface
Class map identifies traffic from real IP address.

Policy map action specifies outside interface.
Service policy on inside interface.
Mapped IP Address
Real IP Address
Outside Interface
Inside Interface
Client Traffic Destination NAT

Server Traffic Source NAT
ACEAP v1.01-19
The concepts of inside and outside interfaces are flexible in the ACE configuration model and
depend on which interface contains the real and mapped IP addresses. The real IP address is
always on the inside interface and the mapped IP address is always reachable on the outside
interface.
Static network address translation (NAT) defines a static mapping between one or more real IP
addresses and a corresponding set of mapped interfaces. A class map is used to identify traffic
from the real IP address. This class map is referenced in a policy map, which specifies the
outside interface in an action statement. This policy map is then associated with the inside
interface.
In the figure, a server on the inside is being mapped to an address on the outside. As noted,
traffic from the client carries the destination IP address NATed, and traffic from the server
carries the source IP address NATed.
170
Static NAT and PAT: Configuration

Mapped IP Address:
Real IP Address:
198.133.219.25
10.20.42.15
Outside Interface
Inside Interface
VLAN 101
VLAN 201
class-map internal-addrs
match source-address 10.20.42.15 255.255.255.255
policy-map multi-match nat-internals
class internal-addrs
nat static 198.133.219.25 netmask 255.255.255.255 vlan 101
interface vlan 201
service-policy input nat-internals
ACEAP v1.01-20
A static NAT configuration is shown in the figure, which maps the address 10.20.42.15 to an
external address of 198.133.219.25.
Security Features
171
Dynamic NAT
Real IP Address
Mapped IP Address
Inside Interface
Outside Interface
NAT pool configured on outside interface.

Class map identifies traffic from real IP address.
Policy map action specifies outside NAT pool.
Service policy on inside interface.
Real IP Address
Mapped IP Address
Inside Interface
Outside Interface
Client Traffic Source NAT

Server Traffic No NAT
ACEAP v1.01-21
Dynamic NAT allows a real IP address on the inside interface to be dynamically translated to a
member of a pool of addresses on the outside interface. The procedure for configuring dynamic
NAT is similar to the process for configuring static NAT, with the additional step of defining a
NAT pool on the outside interface.
In the figure, the clients on the inside interface are dynamically translated to a member of the IP
address pool on the outside interface. Client-initiated traffic is source NATed, and serverinitiated traffic is not translated.
172
Dynamic NAT and PAT: Configuration

Real IP Address:
Mapped IP Address
Any
10.1.1.1-10.1.1.100
Inside Interface
Outside Interface
VLAN 101
VLAN 201
class-map client-traffic
match destination-address 198.133.219.25 255.255.255.255
policy-map multi-match nat-clients
class client-traffic
nat dynamic 1 vlan 201
interface vlan 101
service-policy input nat-clients
interface vlan 201
nat-pool 1 10.1.1.1 10.1.1.100 netmask 255.255.255.0 pat
ACEAP v1.01-22
The configuration in the figure translates the client IP address to an address in the range of
10.1.1.1-10.1.1.100 for any client connection initiated to the IP address of 198.133.219.25.
Security Features
173
Verifying NAT Operations

switch/Admin# show xlate
NAT from vlan14:5.1.1.2 to vlan13:6.1.1.2 count:1
switch/Admin# show conn
total current connections : 2
conn-id
dir prot vlan source
destination
state
----------+---+----+----+------------+----------------+----------+
1
in tcp 14 5.1.1.2:32887 13.1.1.2:23
ESTAB
2
out tcp 13 13.1.1.2:23
6.1.1.1:32887
ESTAB
switch/Admin# show service-policy
interface: vlan 14
service-policy: nat-dyn
class: nat-dyn
nat:
nat dynamic 10 vlan 13
curr conns
: 0
,
dropped conns
: 0
client pkt count : 56
,
server pkt count : 43
,
nat-dyn
hit count
: 1
client byte count: 3032

server byte count: 2564
ACEAP v1.01-23
NAT operations can be verified with the show xlate command, which lists the active
translations. The effects of NAT on a connection can be viewed in the output of the show conn
command. The show service-policy command can be used to display statistics about the
operation of a policy map that is configured for NAT.
174
Allocating from a NAT Pool

Real IP Address
Mapped IP Address
Inside Interface
Outside Interface
First select IP address, then select port number:

Hash into available NAT pool to choose a mapped address
If there are no port numbers left for the chosen IP address,

the connection is rejected:
This is true even if there are other port numbers available on other IP
addresses in the NAT pool.
As a workaround, configure multiple NAT pools.
ACEAP v1.01-24
The figure shows the algorithm for allocating IP addresses from a dynamic NAT pool.
Security Features
175
Multiple NAT Pools

Real IP Address
Mapped IP Address
Inside Interface
Outside Interface
Step through each NAT pool until IP and port can be

assigned
Advantage of multiple NAT pools: More likely to find an
available xlate
Disadvantages of multiple NAT pools:
Limited number of NAT pools available for system.
Performance could decrease due to searching multiple pools.
ACEAP v1.01-25
Multiple NAT pools can be used to enhance the chances that a new NAT translation can be
created, as described in the figure.
176
NAT/PAT Resource Limitations

Real IP Address
Mapped IP Address
Inside Interface
Outside Interface
Total number of pools: 8 K

Total number of static policies: 8 K
Total number of dynamic policies: 8 K
Total number of xlates: 500 K
Maximum number of addresses in a NAT pool: 64 K
Maximum number of addresses in a PAT pool: 32
ACEAP v1.01-26
Hardware limitations on the NAT-related resources are listed in the figure.
Security Features
177
Summary
Summary
IP access control lists must be configured to allow new flows
(except management) to be initiated through the ACE.
ACE reassembles IP fragments before passing them to real
servers.
ACE normalizes TCP/IP headers to comply with RFCs.
NAT and PAT are supported by the ACE appliance.
178
ACEAP v1.01-27
Lesson 6

Overview
In this lesson, you will learn how to describe the capabilities and configuration of the Cisco
4710 Application Control Engine (ACE) features used to provide load balancing of IP-based
applications.
Objectives
Upon completing this lesson, you will be able to describe the capabilities and configuration of
the ACE features used to provide load balancing of IP-based applications. This includes being
able to meet these objectives:
Describe the key concepts of server load balancing
Describe the load-balancing algorithms available
Describe the configuration of Layer 4 load balancing
Load-Balancing Concepts
This lesson describes the concepts of server load balancing and explores the ACE capabilities
of these features.
Real Servers
Servers
ACEAP v1.01-4
Content to be served out to the client in a load-balanced environment resides on a connection of

physical computer systems that have the storage capability for the content and have the
processing and network capabilities necessary to respond to client requests. In a load-balanced
environment, these are referred to as the real servers (rservers).
Note
The terminology used by the CSS is different, in that the CSS refers to real servers as
services.
In the figure, you can see the beginning of a load-balanced content server environment that has
three real servers.
180
Server Farm
Load Balancer
LB
ACEAP v1.01-5
To load balance connections across a collection of real servers with a load balancer, you can
group the servers into a collection called a server farm. The server farm consists of servers that
are all capable of responding to the same requests. In the process of creating a server farm, you
also define a load-balancing algorithm. This algorithm maps each request assigned to the server
farm to a particular real server contained in the server farm.
Note
The CSS does not use the server farm as a standalone concept. Rather, groups of real
servers (services, on the CSS) are added to a content rule that specifies how to handle a
particular kind of request.
In the figure, you can see the three real servers grouped together in a server farm and assigned a
load-balancing algorithm.
181
Multiple Server Farms

Load Balancer
LB
LB
ACEAP v1.01-6
A load-balancing environment can have multiple server farms. Each server farm has its own
collection of servers and its own load-balancing algorithm. Different load-balancing algorithms
can be used in different server farms in the same load-balancing environment.
In the figure, you can add a second server farm with two real servers.
182
Overlapping Server Farms
Load Balancer
LB
LB
LB
ACEAP v1.01-7
Server farms can overlap; in other words, the same server can be part of multiple server farms.
In this type of environment, the load-balancing algorithm used in one server farm does not
track the requests sent to a real server by the load-balancing algorithm of another server farm.
Thus, care should be taken in designing overlapping server farms.
In the figure, you can add a third server farm. This server farm contains two new real servers
and makes use of the resources of one of the real servers in the first server farm.
183
Virtual Server: Virtual IP Address
Load Balancer
LB
LB
LB
ACEAP v1.01-8
To provide seamless access to the resources hosted on the load-balanced real servers to clients,
you must present the clients with the image of a single server to which they send all their
requests. This virtual server is implemented by the load balancer and does not exist as a
standalone computer system. The virtual server is configured with a virtual IP (VIP) address
that is used as the destination of client requests. The load balancer receives a client request,
selects a server farm, uses the load-balancing algorithm defined in the server farm to select a
real server, and sends the client request to the real server. Data returned by the real server is
then modified so that it appears to come from the VIP and is returned to the client.
The load-balanced environment shown in the figure has a request coming from a client. The
selection algorithms have selected the right-hand real server of the bottom server farm. The
client request is sent to this server. The response is then processed by the load balancer to
return this data to the client sourced from the VIP.
184
Health Monitoring
Load Balancer
HM
HM
HM
X
ACEAP v1.01-9
Health monitoring is used by the load balancer to monitor the availability of each real server
used in a server farm. If the health monitoring function detects that a server is not available, the
server is taken out of service to keep future client requests from being directed to a server
unable to respond to that request. Each server farm can have different health monitoring
parameters configured. Health monitoring checks are sent to each real server in a server farm.
The sample environment shows the results of health monitoring. The right-hand server of the
bottom server farm has failed some health checks and is deemed to be out of service by health
monitoring. Future client requests are sent only to the left-hand server of this server farm while
this condition persists.
185
Farm A
2
4
ACE
ACEAP v1.01-10
Cisco load balancers can make load-balancing decisions based on Layer 4 information. This
decision is made on the first packet of a TCP connection (that is, the SYN packet from the
client) and on the first packet detected on a UDP flow. Layer 4 load-balancing decisions use the
load-balancing capabilities of a single server farm.
In the network shown in the figure, you see a server farm with two real servers. Incoming client
requests are being balanced between these servers at Layer 4.
186
Layer 4 Switching
Layer 4 information is always present in the first packet of the
flow:
IP protocol
Source and destination IP addresses
Source and destination L4 ports (for TCP/UDP)
The load-balancing decision is made on the first packet.
Client Side
Server Side
1
ACEAP v1.01-11
Layer 4 information in the packet includes the following fields:
IP: This field is used to differentiate between the higher-level protocols such as UDP and
TCP that are supported by IP.
Source and destination IP addresses: The IP address of the transmitting system and the
intended recipient.
Source and destination port: The port number being used on client or server. Well-known
port numbers are defined for most IP-based services (for example, port 80 is used for
HTTP, the transmitting system, and the intended recipient). Note that port numbers are
used to direct the IP traffic to a particular application process such as a web site.
Layer 4 content-switching decisions can be based on any of the Layer 4 fields listed in the
figure. With TCP connections, the Layer 4 information is consistent for all packets in the
connection. The Layer 4 information is often said to define a flow, which is the communication
path for a particular connection.
The figure shows a flow of packets coming from the client side of the network into an ACE.
The ACE examines the first packet in a new flow or connection, and a Layer 4 switching
decision is made for the flow as a whole. The content switch makes this decision and then
records the flow parameters and the switching decision. This table of switching decisions is
used to switch every subsequent packet in the flow. Information is removed from the switching
table when a connection is closed. In the case of Layer 4 switching of TCP packets, these
decisions are normally made on the basis of SYN and FIN packets and are done at TCP
connection setup and termination. Reset (RST) packets are also analyzed because they are used
to refuse a connection when it is requested or to abort an existing connection.
187
Layer 7 Policy-Driven Load Balancing

Farm A
2
ACE
Farm C
Farm B
ACEAP v1.01-12
Cisco load balancers are capable of policy-driven load balancing, which extends the server
selection process. Load-balancing policies are used to select a server farm to process a client
request. After a server farm has been selected, the server farm load-balancing algorithm
completes the server selection.
The figure shows a hypothetical policy-driven load-balancing situation. There are three server
farms. Farm A consists of two real servers that are load balancing using the round-robin
algorithm. Farm B consists of three real servers that are also performing round-robin load
balancing. Farm C consists of only one server.
One virtual server IP is configured on the ACE, which all clients will be targeting with their
requests. This virtual server implements the following policies:
1. Authorized users get HTML files from Farm A.
2. Authorized users get image files from Farm B.
3. Unauthorized users get an error page from Farm C.
Each client, in order, is trying to retrieve a home page from the virtual server. The home page
contains two images that the clients will also retrieve. Clients 13 are authorized; client 4 is not
authorized.
Client 1
1. Client requests the home page.
2. Policy assigns the request to Farm A.
3. Farm A load balancing assigns the request to the left server.
4. Client requests image 1.
5. Policy assigns the request to Farm B.
188
6. Farm B load balancing assigns the request to the top server.

9. Farm B load balancing assigns the request to the middle server.
Client 2
3. Farm A load balancing assigns the request to the right server.
6. Farm B load balancing assigns the request to the bottom server.
9. Farm B load balancing assigns the request to the top server.
Client 3
3. Farm A load balancing assigns the request to the left server.
6. Farm B load balancing assigns the request to the middle server.
9. Farm B load balancing assigns the request to the bottom server.
Client 4
2. Policy assigns the request to Farm C.
3. There is only one server in Farm C, so the request is assigned to it.
189
Layer 7 Switching
Layer 5 to Layer 7 information is received only after TCP
connection setup and might span multiple packets:
HTTP URLs
Cookies
HTTP request headers
Requires TCP termination and buffering
SYN
SYN_ACK
SYN
SYN_ACK
ACEAP v1.01-13
Layer 7 information is available only after application data has been transmitted, but
transmission requires that the TCP connection be fully functional. This leads to a dilemma: a
server must respond to the client to fully start the TCP connection before the client sends the
Layer 7 information that the content switch needs to select the server.
The content switch handles this dilemma by buffering client data and temporarily acting as a
server. To do this, the content switch responds to the incoming SYN packet with its own SYNACK. The content switch then buffers packets until it has enough Layer 7 information to make
a load-balancing decision.
After a destination server has been selected, the content switch must now make a connection to
the server on behalf of the client. To establish the TCP connection to the server, a SYN packet
is sent to the server, and then the ACE waits for the SYN-ACK packet to be sent from the
server. At this point, all buffered packets received from the client are sent to the server.
After the buffered packets have been sent, the two TCP connections can be spliced together by
the content switch. This splicing is done by receiving packets from one connection and
retransmitting them to the other.
Because there are two different TCP connections from the content switch, one to the client and
one to the server, there are probably two sets of sequence numbers in use, one on each
connection. The content switch translates the sequence numbers from one connection to the
other.
190
Splicing Flows Together
ACEAP v1.01-14
After a TCP connection is established, each packet has a valid sequence and acknowledgment
number. The sequence number is the number of the first byte of the data portion of the packet.
The sequence number is computed by adding the starting sequence number (established in the
SYN packet) with the number of bytes already transmitted. The acknowledgment number is the
number of the next byte of data expected from the other system. The acknowledgment number
is computed by adding 1 to the sum of the starting sequence number of the other systems, plus
the number of bytes received.
191
Splicing Flows Together (Cont.)
ACK=StartACE + SentACE + 1
Adjust
Ack no.
ACE Server
Adjust
Seq no.
ACE Server
SEQ=StartACE + SentACE
ACEAP v1.01-15
When Layer 7 load balancing is configured, the ACE terminates the TCP connection from the
client. A second TCP connection is opened to the server selected by the load-balancing
algorithm. The SYN packet that is used to open the connection to the server uses the sequence
number received in the client SYN packet (Startclient in the figure). As a result, the sequence
numbers of all packets transmitted from the client through the ACE, and to the server, are
consistent. The acknowledged sequence numbers are therefore also consistent from the server
through the ACE to the client.
Both the ACE and the server independently determine sequence numbers for return traffic.
Because of the order in which sequence numbers are determined, the sequence numbers from
the server (Startserver in the figure) and the sequence number from the ACE to the client
(StartACE in the figure) are not consistent. Packets from the server to the client will have their
sequence numbers adjusted. Packets from the client to the server will have their
acknowledgment numbers adjusted.
192
TCP Proxy Processing
Fastpath
TCP/HTTP/Inspect/L7
Proxy or reproxy:
Full TCP stack
processing
Full TCP state data
Layer 7 state data
Fastpath
Unproxy:
Smaller memory
requirements
Fewer MPs involved
1 million connections
Load on more MPs

256 K connections
ACEAP v1.01-16
The ACE appliance performs full TCP and Layer 7 processing on portions of a TCP stream as
required. When full TCP stack processing is not required, the connection is unproxied. In this
state, the only state information kept is that which the fastpath multipoint processor (MP) needs
in order to rewrite packets as they transit the appliance.
193
TCP Proxy Processing (Cont.)
Fastpath
Fastpath
TCP/HTTP/Inspect/L7
switch/Admin# show stats http | include prox

SSL fin/rst msgs sent
: 0
, Unproxy msgs sent
: 1
Reproxied requests
: 1
, Headers removed
: 0
HTTP unproxy conns
: 1
, Pipeline flushes
: 0
ACEAP v1.01-17
Statistics on the number of proxy, unproxy, and reproxy operations can be displayed with the
show stats http | include prox command, as shown in the figure.
194
This topic describes the load-balancing algorithms available.
Called Predictors in the ACE.
Select a real server within a server
farm.
Balance new connections.
LB
Application knowledge aids

algorithm selection.
Two types of Predictors:
Load Predictors
Traffic pattern Predictors
ACEAP v1.01-19
The load-balancing algorithms are referred to as Predictors in the ACE appliance and are
designed to select a real server to respond to an incoming connection. The load-balancing
algorithms do not necessarily result in identical load characteristics on each server, because the
load-balancing decision occurs at a more granular level. What is really balanced is the number
of connections to each of the real servers. If incoming connections are identical in
characteristics such as duration and processing power needed to respond to the request, this will
result in consistent server load throughout the server farm. Selection of the proper loadbalancing algorithm often requires some knowledge of the traffic and processing characteristics
of the application being load balanced.
195
Load Predictors
Load-balancing algorithms
Least connections with optional weight
and slow start
Monitor server load characteristics

Pick optimal server
Health monitoring must be used
Existing Connections
New Connection
ACEAP v1.01-20
Load Predictors monitor one or more server load characteristics to pick the optimal or leastloaded server for a new connection.
The least connections load-balancing algorithm monitors the number of connections assigned to
a system as an approximation of the current load being placed on a server. This algorithm then
chooses the least-loaded server to receive the new connection. Servers in the server farm can
have a weighting factor applied to divide connection requests in a manner proportional to the
relative capabilities of each server.
The least connections load-balancing algorithm has an optional slow start capability for
services that have just been placed into service. This capability causes the algorithm to increase
the new connections to a server over a period of time. This allows a new server to take on more
load gradually, rather than being hit with every connection until it has the same load as other
servers in the server farm.
Health monitoring should be used with load Predictors to keep a failed server from blackholing all requests. For example, if a server fails, it will have the least number of connections.
This server will be selected for every new connection by the least connections load-balancing
algorithm.
In the server farm shown in the figure, you see three servers. The top server has a large number
of connections, the middle server has a moderate number of connections, and the bottom server
has few connections. A least connections Predictor will select the bottom server for a new
connection.
196
Traffic Pattern Predictors

Load-Balancing Algorithms:
Hash address: source and destination or both
with optional mask
Hash cookie
Hash header
Hash partial or full URL
Round robin with optional weight
Algorithmically spread traffic around

Health monitoring recommended
Existing Connections
New Connection
ACEAP v1.01-21
Traffic pattern Predictors are designed to spread traffic around based on characteristics of the
traffic being load balanced.
Round robin selects successive servers each time a new connection comes in. An optional
weight specification configures round robin to select a real server multiple times to allocate
connections proportionately to the specified weight. This is used in situations in which various
servers in the server farm have different connection-processing capacities.
The hash-based traffic pattern Predictors algorithmically analyze various characteristics of the
incoming requests and spread the traffic around accordingly. The source, destination, or both IP
addresses in the request packet can be hashed after applying an optional network mask. The
value of an HTTP cookie, an HTTP header field, or part or all of the URL can be hashed.
Without health monitoring, the failure of X number of servers in a server farm with N real
servers will cause X out of N connections to be assigned to dead servers; therefore, the use of
health monitoring is recommended.
The server farm shown in the figure is using the round-robin Predictor and has selected the
bottom server for the next connection.
197
Configuring Layer 4 Load Balancing

This topic describes the configuration process and statements used to activate Layer 4 load
balancing on the ACE.
Configuring Real Servers

ACE
rserver host EXT-HOST1

ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
ACEAP v1.01-23
The first step in configuring load balancing is the configuring of real servers. On the ACE, real
servers are configured with the rserver command, which creates a named host. Various
parameters can be specified about the host. The IP address and placing the system in service
with the inservice command are required for requests to be sent to the server.
Note
Taking the server out of service in the rserver configuration submode takes the server out of
service in all server farms of which it is a member.
In the configuration shown in the figure, you see two servers and place them in service.
Monitoring rservers
To view rserver state use the following command:
ACE/Lab-OPT-17# show rserver {(rserver_name) | detail}
ACE/Lab-OPT-17# show rserver EXT-HOST1 detail
rserver
: EXT-HOST1, type: HOST
state
: INACTIVE
description : weight
: 8
------------------------------------------connections----------real
weight state
current total
---+---------------------+------+------------+----------+------------------198
Real server states:
Inbound probe failed: The server has failed the in-band Health Probe agent.
In service: The server is in use as a destination for server load balancing client
connections.
Operation wait: The server is ready to become operational and is waiting for the
associated redirect virtual server to be in service.
Out of service: The server is not in use by a server load balancer as a destination for client
connections.
Probe failed: The server load balancing probe to this server has failed. No new
connections will be assigned to this server until a probe to this server succeeds.
Probe testing: The server has received a test probe from the server load balancer
Ready to test: The server has failed, and its retry timer has expired; test connections will
begin glowing to it soon.
Test wait: The server is ready to be tested. This state is applicable only when the server is
used for HTTP redirect load balancing.
Testing: The server has failed and has been given another test connection. The success of
this connection is not known.
Throttle DFP: DFP (Dynamic Feedback Protocol) has lowered the weight of the server to
throttle level; no new connections will be assigned to the server until DFP raises its weight.
Throttle max clients: The server has reached its maximum number of allowed clients.
Throttle max connections: The server has reached its maximum number of connections
and is no longer being given connections.
Unknown: The state of the server is unknown.
199
Configuring Server Farms

ACE

ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
serverfarm host EXT-SERVERS
predictor roundrobin
rserver EXT-HOST1
inservice
rserver EXT-HOST2
inservice
ACEAP v1.01-24
Grouping servers together into server farms is the next step in a load-balancing configuration.
Server farms are defined with the serverfarm command. In the server farm configuration
submode, various server farm-specific parameters can be entered, including the load-balancing
algorithm to be used and the hosts that are part of the server farm.
In the configuration shown, you see a server farm called ext-servers. You specify the default
load balancing algorithm with the predictor roundrobin command. You also specify that the
two servers defined earlier are part of the new server farm, and that each of these real servers is
in service, from the perspective of the server farm.
Note
200
Taking a server out of service in a server farm keeps it from receiving traffic, based on loadbalancing decisions made through a specific server farm. The system is still in service and
available to other server farms of which it is a member.
Define Load-Balancing Policy Map

ACE
policy-map type loadbalance first-match SLB-LOGIC

class class-default
serverfarm EXT-SERVERS
ACEAP v1.01-25
On the ACE, load balancing is a feature that is controlled through the Modular Policy CLI. The
actual load-balancing policy is defined in a policy map of type loadbalance, which allows you
to classify traffic based on HTTP characteristics and perform different actions for different
classifications. For Layer 4 load balancing, you are not interested in analyzing Layer 7
characteristics. Therefore, the load-balancing policy map uses class-default to specify the
actions to be taken on all traffic that is to be load balanced. In the figure, you have created a
policy map called slb-logic for this specific purpose.
A load-balancing policy map is associated with a traffic stream through an action specification
in a Layer 3 and 4 policy map, which must now be configured.
201
Define VIP with Layer 3 and 4 Class Map

ACE

class class-default
class-map match-all EXTERNAL-VIP
2 match virtual-address 198.133.219.25 tcp eq www
ACEAP v1.01-26
The first part of configuring the Layer 3 and 4 policy map is to create a Layer 3 and 4 class map
to classify the traffic that is to be load balanced. Traffic is matched using the match virtualaddress command to specify the IP address, optional network mask, and optional destination
port, which defines the VIP.
Caution
A match virtual-address command must be used rather than a match destinationaddress command. The match virtual-address command not only matches traffic, but also
has the side effect of defining a VIP.
In the figure, you have created a class map named external-vip, which will match web requests
to an IP address of 198.133.219.25.
202
Define Layer 3 and 4 Policy Map

ACE

class class-default
policy-map multi-match CLIENT-VIPS
class EXTERNAL-VIP
loadbalance policy SLB-LOGIC
ACEAP v1.01-27
Now you are ready to create a Layer 3 and 4 policy map. This policy map will specify the
actions for traffic destined to the VIP. Two commands are required to activate load balancing.
First, the loadbalance vip inservice command places the VIP defined by the matching class
map into service. Second, the loadbalance policy command associates traffic destined to the
matching VIP with the load-balancing policy map.
In the figure, you configure a policy map called client-vips, which load balances traffic
destined for the VIP previously defined in the external-vip class map. Load-balancing
decisions for this traffic are to be controlled by the policy in the slb-logic policy-map.
203
Attach Policy Map to a Traffic Stream

ACE

class class-default
class EXTERNAL-VIP
access-list FROM-231 line 10 extended permit tcp any host
198.133.219.25 eq www
interface vlan 231
access-group input FROM-231
service-policy input CLIENT-VIPS
ACEAP v1.01-28
Finally, the Layer 3 and 4 policy map must itself be associated with a traffic stream by
specifying the service-policy input command on one or more interfaces.
Note
No traffic is allowed into the ACE unless it is permitted via an ACL. Management-type class
maps implicitly define an ACL when they are activated on an interface; however, this is not
true for Layer 3 and 4 type policy maps.
In the example, you define an access list called from-231 to allow traffic to the VIP. You
associate this access list and the Layer 3 and 4 policy map to the VLAN 231 interface. Now,
traffic can arrive for the VIP on VLAN 231 and be load balanced to one of the two real servers.
Note
204
You use this Layer 4 load-balancing configuration as a base configuration for many other
configurations in this course.
Layer 4 Load Balancing in running-config

198.133.219.25 eq www
class class-default
class EXTERNAL-VIP
interface vlan 231
ACEAP v1.01-29
Class map and policy map statements are not saved in the ACE configuration files in the same
order in which you have configured them in the example. Listed in the figure are the relevant
portions of running-config showing the order in which resource definitions are stored in the
configuration files.
205
Summary
Summary
Server load balancing is used to allow multiple real servers to
respond to client requests directed to a virtual IP address.
Several load-balancing algorithms are available to make real
server selection.
Load-balancing decisions can be made by analyzing the Layer 4
protocol fields.
206
ACEAP v1.01-30
Lesson 7
Health Monitoring
Overview
In this lesson, you will learn how to describe the health monitoring capabilities of the Cisco
4710 Application Control Engine (ACE) appliance.
Objectives
Upon completing this lesson, you will be able to describe the health monitoring capabilities of
the ACE appliance. This includes being able to meet these objectives:
Describe health monitoring options
Describe the configuration of health probes
Describe the configuration of HTTP error code monitoring
Describe the use of TCL for scripted probes

This topic describes health monitoring options.

Load Balancer
Passive
Checks
Probes
ACEAP v1.01-4
Two different types of health monitoring can be performed by Cisco load balancers. Passive
health checks monitor the responses from real servers to the requesting client. If error
conditions are detected in the server response, the server is removed from service. Active health
monitoring functions in the load balancer send out periodic requests called probes to the real
servers. If the server does not respond as expected, the server is removed from service.
208
Passive Health Checks

Load Balancer
Passive
Checks
In-band health monitoring: CSS

Return code monitoring: ACE, CSS
ACEAP v1.01-5
Two types of passive health checks are possible. These are in-band health monitoring, which is
supported on the content services switch (CSS), and HTTP return code monitoring, which is
supported on both the ACE and the CSS.
In-band health monitoring analyzes the TCP connection setup and teardown packets from the
server. If a server does not respond to a synchronization (SYN) packet or sends a reset (RST)
packet, an error is detected.
Return code monitoring analyzes the HTTP return codes present in server HTTP responses.
User-configured ranges of return codes are considered to be indicative of an error.
Health Monitoring
209
Active Health Checks

Load Balancer
Probes
Probe defines what to attempt, what to look for, and the time
interval between each instance.
Probe can be attached to a real server or server farm.
ACEAP v1.01-6
Active health checks are implemented by defining probes. These probes define the
communication to be attempted with a server to analyze its fitness for service, and the results
that are expected from a healthy server. The communication defined by the probe is repeated at
regular intervals defined in the probe configuration. Probes can be associated with a particular
real server, or with a server farm. Probes associated with a server farm are active on each of the
real servers in the server farm.
210
Built-in Probe Types

DNS
HTTP
RADIUS
Echo TCP
HTTPS
SMTP
ECHO UDP
ICMP
TCP
Finger
IMAP
Telnet
FTP
POP3
UDP
TCP-based service probes fail if TCP connection is not possible.

TCP connection can be configured to close (FIN) or abort (RST).
Protocol-specific request and login sent.
Configurable user credentials.
TCL scripts are used to implement additional probes.
ACEAP v1.01-7
There are 15 built-in probe types that can be configured. Additional probe processing can be
created by using TCL scripts. The built-in probe types are:
ICMP: Internet Control Message Protocol (ICMP) echo succeeds if an ICMP echo-reply is
received. The ICMP probe operates the same as the ping command.
Generic TCP probe: Open a connection with the server and disconnect with TCP FIN
(default) or TCP RST. Optional parameters allow a string to be sent over the connection
and the response compared to an expected response.
Generic UDP probe: Sends a User Datagram Protocol (UDP) packet. The probe is
considered successful if no ICMP error is received. For UDP ports that respond to packets,
the string to be sent in the probe, and the expected response, can be configured.
Echo tcp: Use the echo service via TCP to send a string to the server, which will echo it
back verbatim.
Echo udp: Use the echo service as shown in the figure, but via UDP.
Finger: Send a finger request to a server. The ID to be fingered can be configured in the
probe.
HTTP probe: Sends a GET/HTTP/1.1 request and compares the return code and the text
of the result to configured expectations.
HTTPS probe: Similar to the HTTP probe, except that the request is sent via an encrypted
Secure Sockets Layer (SSL) connection. Authentication parameters for the SSL session can
be configured in the probe.
FTP probe: A TCP connection is opened with an FTP server and then the FTP QUIT
command is issued. The status code returned by the FTP server is checked against expected
return codes.
Telnet probe: Makes a connection and verifies that a greeting is received from the server.
Health Monitoring
211
212
DNS probe: Makes a request to resolve the domain name configured in the probe and
verifies that the returned IP address is one that the probe is configured to expect.
SMTP probe: Connects to a Simple Mail Transfer Protocol (SMTP) server and sends an
SMTP HELO command. The status code of the response is compared against a list of
expected status codes.
POP3 probe: Makes a TCP connection to a Post Office Protocol (POP) server with
credentials configured in the probe. An optional command is sent to the POP server.
IMAP probe: Makes a TCP connection to an Internet Message Access Protocol (IMAP)
server with credentials configured in the probe. An optional command is sent to the IMAP
server.
RADIUS probe: Sends a query to a RADIUS server for a configured username, password,
and shared secret. Optionally, the ACE can be configured to specify another IP address in
the request as the address of the Network Access Server requesting the authentication.
Server Status
Faildetect # probes
failed
Passdetect # probes
succeeded
X
ACEAP v1.01-8
Two probe attributes control the transitioning of servers from in service to out of service.
The faildetect parameter defines the number of consecutive probe failures that, when reached,
will cause the server to be removed from service.
A server that is listed as out of service is probed periodically to determine if it has come back
into service. The passdetect parameter defines the number of successful probes that, when
reached, will lead to the server being placed back in service.
Health Monitoring
213
Active Health Probes

This topic describes the configuration of health probes.
General Probe Configuration

probe <probe-type> <probe-name>
description <description>
ip address <ip-address> [routed]
port <port-number>
interval <seconds>
faildetect <retry-count>
passdetect interval <seconds>
passdetect count <number>
receive <recv-timeout>
ACEAP v1.01-10
Probe configuration begins with the probe command, which is used to specify the probe type
and name. This command also places you in the probe configuration submode. In this submode,
you can configure the following probe attributes:
Description: This attribute is used to provide user documentation for the probe.
IP address: This attribute specifies an alternate address to which to send the probe. If this
command is not configured, the IP address of the real server being probed is used.
Port: This attribute specifies the TCP or UDP port number to be used in the request. Each
of the probe types has a default port number that matches the protocol used in the probe.
Interval: This attribute specifies the number of seconds between probes.
Faildetect: This attribute specifies the number of fail probes that result in a server being
taken out of service.
Passdetect: This attribute specifies the interval at which failed servers are probed for
possible placement back in service, as well as the number of successful probes necessary
before a server is returned to service.
Receive: This attribute specifies the number of seconds the ACE waits for a response to a
probe before the probe is deemed to have failed.
ICMP probes are defined with all the general probe configuration statements except the port
statement, which is not supported for ICMP probes.
214
Probe IP Address Handling

IP address s.s.s.s
MAC ssss.ssss.ssss
rserver being probed
IP address p.p.p.p
MAC pppp.pppp.pppp
Probe Definition
No ip address command
ip address p.p.p.p
ip address p.p.p.p routed
Probing server at s.s.s.s results in:

Destination IP
Destination MAC
s.s.s.s
p.p.p.p
p.p.p.p
ssss.ssss.ssss
ssss.ssss.ssss
pppp.pppp.pppp
ACEAP v1.01-11
Destination IP and MAC address fields in packets sent by probes are populated with values
determined by the ip address command configured in the rserver being probed, and optionally
in the probe itself. The network diagram is used to illustrate the options. In the network shown
in the figure, you have a server with an IP address of s.s.s.s, which is configured as a real server
(rserver) on the ACE. The associated MAC address of this interface is ssss.ssss.ssss. The server
in the network has a second interface with an IP address of p.p.p.p, and a MAC address of
pppp.pppp.pppp, which will be used for some probing activities.
Address Resolution Protocol (ARP) entries are maintained for the IP address specified by the ip
address command in the rserver configuration. In the network shown in the figure, the rserver
is configured with an ip address s.s.s.s statement. ARPing for this address results in a MAC
address of ssss.ssss.ssss.
No ip address Command in Probe

Probes that do not have the optional ip address statement configured generate packets that use
the rserver IP address and the associated MAC address. In the network shown in the figure, this
would result in packets with ssss.ssss.ssss as the destination MAC address, and s.s.s.s as the
destination IP address.
Probes without the ip address statement are the most common type of probe, and result in
probes that mimic real client traffic in all load-balancing situations, unless DSR is used.
Health Monitoring
215
Optional ip address Command Without routed Keyword

Probes that have the ip address command configured without the routed keyword generate
packets that use the probe-defined IP address. However, the MAC address associated with the
rserver IP address is still used as the destination MAC address. In the network shown in the
figure, a probe configuration with ip address p.p.p.p would result in packets with ssss.ssss.ssss
as the destination MAC address, and p.p.p.p as the destination IP address.
Probes with the ip address command without the routed keyword can be used for moreextensive testing in firewall load-balancing situations, and can be used to mimic real client
traffic in a server load-balancing situation that uses DSR. These situations are illustrated in the
figures that follow.
Optional ip address routed Command

ARP entries are maintained for the IP address specified by the ip address routed command in
the probe configuration. Probes that have the ip address routed command generate packets
that use the probe-defined IP address as the destination IP address. The MAC address learned
by ARPing this address will be used as the destination MAC address. In the network shown in
the figure, this would result in packets with pppp.pppp.pppp as the destination MAC address,
and p.p.p.p as the destination IP address.
Probes with the ip address routed command can be used to base the health of a client-facing
interface or process on the responses received from another client application or a management
interface on the rserver being probed.
216
Probing Through Firewalls

rserver fw1
ip address 172.16.1.2
rserver fw2
rserver fw3
172.16.1.2
serverfarm fws
rserver fw1
rserver fw2
rserver fw3
172.16.2.2
10.0.1.2
probe icmp pinger

ip address 10.0.1.2
172.16.3.2
ACEAP v1.01-12
Firewall load balancing (FWLB) can be used to deploy firewall protection for a network whose
bandwidth requirements exceed the capacity of a single firewall. Two ACE appliances are
required for FWLB: one external to the firewalls, and one internal. The rservers in an FWLB
configuration are the interfaces of the firewalls through which traffic is sent. Several health
monitoring levels are possible in an FWLB configuration.
The simplest health monitoring would be to have each ACE appliance probe the firewall
interface to which it is attached. This would require the firewalls to respond to these ping
requests. Success of a probe verifies that connectivity is functional between the firewall and the
ACE appliance and that the firewall is responding to the probed requests. Several failure modes
involving the firewall process and connectivity beyond the firewall are not detected with this
health monitoring technique.
More-advanced health monitoring is possible by configuring the ip address command in the
probe definition. A probe can be configured to mimic real client traffic that is expected to
transit the firewall. However, the packets generated by these probes should not be destined to
the firewall, but through the firewall. This is accomplished by generating packets that have the
destination IP address of a resource beyond the firewall, but which are switched at Layer 2 to
the firewall being probed.
This technique is illustrated in the figure, with a sample FWLB configuration using three
firewalls. The configuration statements shown would be configured on the external ACE to
probe the firewalls by sending a ping through each firewall to the server behind the firewalls.
Packets generated by this probe are sent with a destination MAC address determined by
ARPing the rserver (that is, the firewall) being probed. The destination IP address in the probe
packet is 10.0.1.2, which is the IP address of the back-end server. The resulting packets are
switched through the firewall being probed, and to the back-end server. Success of this probe
confirms that the external ACE is able to get traffic through the probed firewall to a resource,
and verifies connectivity on both sides of the firewall, as well as the forwarding process of the
firewall. By using a probe type that mimics real client traffic, a probe could also be used to
verify that the correct firewall rules are active on the firewall that is probed.
Health Monitoring
217
Probing DSR
rserver srv1
rserver srv2
serverfarm srvs
rserver srv1
VIP 198.133.219.25
rserver srv2
172.16.1.2
172.16.1.3
class-map match-all external-vip
2 match virtual-address 198.133.219.25
probe icmp pinger
Loopback
198.133.219.25
ip address 198.133.219.25
ACEAP v1.01-13
Servers deployed in a DSR configuration often require the use of probes configured with the ip
address command to effectively test server health. DSR configurations result in client requests
that are load balanced to an rserver, while maintaining a destination address of the virtual IP
(VIP) that the client used in the original request. Server applications are therefore configured to
expect traffic received to be destined to the VIP address.
Mimicking real client traffic with the ACE health monitoring probes can be done by
configuring the ip address command. Packets generated by a probe with this command have
the MAC address determined by the IP address configured in the rserver, while the destination
IP address is the VIP configured in the probe definition.
This technique is illustrated in the network and configurations shown in the figure. Probes
generated by the pinger probe have a destination address of 198.133.219.25, which is the VIP
address used by clients. When this probe is run for the defined rservers, the probe packets have
the destination address determined by ARPing the IP address of the rserver.
218
DNS Probe Configuration

probe dns <probe-name>
port <port-number>
interval <seconds>
domain <name>
expect address <ip-address>
ACEAP v1.01-14
Domain Name System (DNS) probes add two more attributes to the general probe
configuration:
Domain name: The domain name to be queried.
IP address: An IP address that is expected as the result of the DNS query. Multiple expect
address commands can be used to configure a list of possible valid responses.
Health Monitoring
219
RADIUS Probe Configuration

probe radius <probe-name>
port <port-number>
interval <seconds>
credentials <username> <password> [secret <shared-secret>]
nas ip address <ip-address>
ACEAP v1.01-15
The RADIUS probe also adds two more attributes to the general probe configuration options.
These are:
220
Credentials: This option defines the credentials to be used in the RADIUS request,
including the username/password combination for the user being authenticated, and the
servers secret key.
NAS IP address: This option defines the IP address used in the Network Access Server
(NAS) field of the RADIUS request. If this parameter is not configured, the IP address used
to send the request to the RADIUS server is used.
UDP-Based Probe Configuration

port <port-number>
interval <seconds>
send-data <expression>
expect regex <string> [offset <number>]
ACEAP v1.01-16
The UDP-based probes Echo UDP and generic UDP add two attributes to the general probe
configuration:
Send-data: This attribute defines the data to be sent in the UDP probe packet.
Expect regex: This attribute defines a regular expression used to match the results received
from the server.
Health Monitoring
221
TCP-Based Probe Configuration

port <port-number>
interval <seconds>
open <open-timeout>
connection term forced
ACEAP v1.01-17
The TCP-based probes Echo TCP, Finger, generic TCP, and Telnet add four more parameters
to the general probe configuration:
222
Open: This parameter defines the amount of time allowed for the server to respond to the
initial SYN packet.
Send-data: This parameter defines the data to be sent over the TCP connection after it is
established.
Expect regex: This parameter defines a regular expression used to match the returned
traffic.
Connection term forced: This parameter specifies that the TCP connection should be
aborted with a RST packet. If this command is omitted from the probe configuration, the
TCP connection is closed gracefully with FIN packets.
FTP/SMTP Probe Configuration

port <port-number>
interval <seconds>
count <number>
open <open-timeout>
expect status <min-number> <max-number>
ACEAP v1.01-18
FTP probes add one attribute to the TCP-based probe configuration: a range of expected status
codes. Multiple expect status commands can be configured to cause multiple ranges of status
codes to cause the server to pass the probe. At least one expect status command must be
configured for the probe to succeed.
Health Monitoring
223
HTTP Probe Configuration

probe http <probe-name>
port <port-number>
interval <seconds>
count <number>
open <open-timeout>
credentials <username> [<password>]
header <field-name> header-value <value>
request method {get | head} url <path>
hash <value>
ACEAP v1.01-19
HTTP probes add attributes to the general TCP probe configuration that are used to define the
HTTP request sent to the server:
224
Credentials: This attribute defines the username and password used to access passwordprotected resources.
Header: This attribute allows the specification of many HTTP header fields. Multiple
header commands can be configured in a single probe.
Request method: This attribute defines the HTTP request method used and the URL to be
requested from the web server.
Expected status: This attribute defines the range of HTTP status codes that indicate that
the probe was successful. Multiple expect status commands can be configured in one
probe.
Hash: A Message Digest 5 (MD5) hash value can be supplied for the page to be retrieved.
If this parameter is not configured in the probe configuration, the ACE computes the hash
on the first probe of a server. Subsequent probes compare the hash value to the configured
or remembered hash value.
HTTPS Probe Configuration

probe https <probe-name>
port <port-number>
interval <seconds>
count <number>
open <open-timeout>
header <field-name> header-value <value>
request method {get | head} url <path>
hash <value>
ssl cipher RSA_ANY | <cipher-suite>
ssl version SSLv2 | SSLv3 | TLSv1
ACEAP v1.01-20
HTTPS adds SSL-specific attributes to the HTTP probe, allowing the probe to use particular
SSL versions and cipher suites.
Health Monitoring
225
IMAP Probe Configuration

probe imap <probe-name>
port <port-number>
interval <seconds>
passdetect interval <seconds> count <number>
open <open-timeout>
credentials <username> <password>
credentials mailbox <name>
request method <command>
ACEAP v1.01-21
The IMAP probe adds several attributes to the base TCP probe configuration, which define the
IMAP user credentials, mailbox, and command to be sent to the server.
226
POP Probe Configuration

probe pop <probe-name>
port <port-number>
interval <seconds>
count <number>
open <open-timeout>
request method <command>
ACEAP v1.01-22
The POP probe adds two attributes to the base TCP probe configuration, which define the POP
user credentials and command to be sent to the server.
Health Monitoring
227
Activating Probes
ACE
probe icmp pinger
probe http get-index
request method get url /index.html
rserver host ext-host1
ip address 192.168.1.11
inservice
probe get-index
rserver host ext-host2
ip address 192.168.1.12
inservice
serverfarm host ext-servers
probe pinger
rserver ext-host1
inservice
rserver ext-host2
inservice
ACEAP v1.01-23
Here you extend the real servers and server farm defined earlier by adding health monitoring.
First, you define two probes: an ICMP probe called pinger, and an HTTP probe called getindex. Server ext-host1 will be probed with the get-index probe. Both servers will be probed by
the pinger probe, because they are both members of the ext-servers server farm. A failure of
either probe directed to ext-host1 will mark the server as out of service.
228
Displaying Probe Usage

switch/context# show probe detail
probe
: icmp-probe
type
: ICMP, state : ACTIVE
description :
---------------------------------------------port
: 0
address
: 0.0.0.0
addr type : interval : 10
pass intvl : 10
pass count : 3
fail count: 5
recv timeout: 5
--------------------- probe results -------------------probe association
probed-address probes
failed
passed
health
------------------- ---------------+----------+----------+----------+------rserver
: rs1
10.7.107.51
230
6
224
FAILED
Socket state
: RESET
No. Passed states
: 1
No. Failed states : 1
No. Probes skipped : 0
Last status code : 0
Last disconnect err : Host Unreachable, no route found to destination
Last probe time
: Sat Feb 18 18:24:18 2006
Last fail time
: Sat Feb 18 18:24:08 2006
Last active time
: Sat Feb 18 17:46:08 2006
ACEAP v1.01-24
Current probe status and statistics can be displayed with the show probe detail command, as
shown in the figure.
Health Monitoring
229
Explaining Show Probe Output

Probe health: INIT, FAILED, PASSED, DISABLED
Socket state: RESET, OPENING, RECEIVING, CLOSED
Last disconnect error49 error messages, such as:
Connection reset by server
Connection refused by server
Unrecognized or invalid response
Server open timeout (no SYN ACK)
Internal errror: Script was terminated due to time out
ICMP Internal error: No space, Transmit Path is full
Internal error: Failed to create SSL session
Received ICMP Stale pkt
ACEAP v1.01-25
The ACE adds detail to the disconnect error messages with 49 different explanatory messages.
230
Show Commands
switch/context# show stats probe
+------------------------------------------+
+----------- Probe statistics -------------+
+------------------------------------------+
----- icmp probe ---Total probes sent
: 0
Total
Total probes passed
: 423
Total
Total connect errors
: 0
Total
Total RST received
: 0
Total
Total receive timeout
: 0
----Total
Total
Total
Total
Total
tcp probe ---probes sent

probes passed
connect errors
RST received
receive timeout
:
:
:
:
:
0
0
0
8
0
Total
Total
Total
Total
send failures
probes failed
conns refused
open timeouts
:
:
:
:
0
25
0
0
send failures
probes failed
conns refused
open timeouts
:
:
:
:
0
8
0
0
. . . . . .
ACEAP v1.01-26
Global statistics grouped by probe type can be displayed with the show stats probe command.
Health Monitoring
231
HTTP Error Code Monitoring

This topic describes the configuration of HTTP error code monitoring.
Configuring Passive Health Checks

Load Balancer
Passive
Checks
serverfarm host SF1

retcode 400 404 check count
ACEAP v1.01-28
Passive health checks are configured for each server farm. The retcode min-code max-code
check count command is used to configure passive return code parsing. Only one range of
return codes can be configured per server farm. In the configuration shown, you count the
HTTP return codes between 400 and 404, inclusively.
232
Displaying HTTP Return Code Statistics

switch/context# show serverfarm SF1 retcode
serverfarm : SF1
rserver
: R1
-------------------------------------return code
action
total count
+------------+--------+------------+
400
count
401
count
402
count
403
count
404
count
ACEAP v1.01-29
The show serverfarm name retcode command can be used to display the return code statistics
maintained by the passive health check monitoring. In the figure, you see the results of the
previous configuration definitions.
Health Monitoring
233
Using TCL Scripting

This topic describes the use of TCL for scripted probes.
Using TCL
TCL Interpreter Release 8.44.
256 script files can be loaded.
15 sample scripts provided.
Scripts must be loaded into memory to be used.
script file <index> <script-name>
ACEAP v1.01-31
The TCL 8.44 interpreter is built into the ACE operating system and is used to run TCL scripts,
which are used to implement scripted health probes. Scripts must be loaded into memory before
they are used by a scripted probe. This is accomplished with the script file command in
configuration mode. This command loads a script from the disk0: file system into one of the
256 available memory slots used for scripts. A script must be unloaded and reloaded to reflect
changes in the source script file.
Note
To load a script into memory, the script must be in the disk0: directory. The ACE does not
load script files that are in a disk0: subdirectory.
The Cisco Technical Assistance Center (TAC)-supported scripts that come with the ACE are:
234
CHECKPORT_STD_SCRIPT
ECHO_PROBE_SCRIPT
FINGER_PROBE_SCRIPT
FTP_PROBE_SCRIPT
HTTP_PROBE_SCRIPT
HTTPCONTENT_PROBE
HTTPHEADER_PROBE
HTTPPROXY_PROBE
IMAP_PROBE
LDAP_PROBE
MAIL_PROBE
POP3_PROBE
PROBENOTICE_PROBE
RTSP_PROBE
SSL_PROBE_SCRIPT
TFTP_PROBE
Health Monitoring
235
Scripted Probe Configuration

probe scripted <probe-name>
port <port-number>
interval <seconds>
passdetect interval <seconds> count <number>
script <script-name> [<script-arguments>]
ACEAP v1.01-32
The configuration of scripted probes adds one attribute to the general probe configuration,
which specifies the script name and optional arguments to be passed to the script.
236
Show Commands
switch/context# show script code ECHO_PROBE_SCRIPT
#!name = ECHO_PROBE_SCRIPT
################################################################################
# scriptname : ECHO_PROBE
#
# Description :
#
Script sends a text string to echo server and expects server to echo back
Probe success only if server return the exact string sent by script
#
# ACE version:
#
1.0+
#
# Parameters:
#
[debugFlag]
#
# debugFlag - default 0. Do not turn on while multiple probe suspects configured
# Example config :
#
#
probe echoProbe script

script ECHO_PROBE [0]
ACEAP v1.01-33
The contents of the script associated with a scripted probe can be displayed with the show
script code command. In the figure, you see the start of a script called
ECHO_PROBE_SCRIPT. This script is a sample script supplied with the ACE.
Health Monitoring
237
Displaying Scripted Probes

switch/context# show script ECHO_PROBE_SCRIPT s1 rs1
script
: ECHO_PROBE_SCRIPT
scripted probe : s1
instance
----------------------------------------probe-association(s) : (count=1)
---------------------------------rserver
: rs1
--------------- script statistics -------------Exit code
= 30001
Child PID
= 1109
Exit Message
= :10.7.107.51:7: probe success
Panic String
Internal error
Last RunStart count= 2
, Last RunStart time= Sun Feb 19 16:59:31 2006
Last RunEnd count
, Last RunEnd time
= 2
Last Probe OK count= 2

Last ProbeFail
= 0
Last ForkFail count= 0
= Sun Feb 19 16:59:31 2006
, Last Probe OK time= Sun Feb 19 16:59:31 2006

, Last ProbeFail
= Never
, Last ForkFail time= Never
ACEAP v1.01-34
Detailed run-time TCL interpreter information and statistics for a scripted probe can be
displayed with the show script script_name probe_name server_name command. In the figure,
you see the results of runs of the ECHO_PROBE_SCRIPT script being used by the s1 probe to
monitor the health of server rs1.
238
Scripted Probe Exit Codes

Exit Code
Description
30001
Probe successful
30002
Probe error: server did not respond as expected
30003
Internal error: fork failed
30004
Script probe terminated due to timeout
30005
TCL interpreter panic
30006
Script error
30007
Cannot find file or buffer data
30008
Memory allocation failure for TCL_wt qnode
30009
Unknown return code
ACEAP v1.01-35
TCL scripted probes communicate their success and failure status to the health monitoring
component of ACE by setting an exit or return code when they finish. The table in the figure
shows the return codes interpreted by the ACE.
Health Monitoring
239
Summary
Summary
Health monitoring is used to automatically remove failing real
servers from consideration.
Active health probes periodically test the health of real servers.
HTTP error code monitoring passively monitors the health of real
servers.
TCL scripts can be used to provide custom probe logic.
240
ACEAP v1.01-36
Lesson 8

Overview
In this lesson, you will learn how to identify the Layer 7 processing options used to provide
advanced application networking.
Objectives
Upon completing this lesson, you will be able to identify the Layer 7 processing options used to
provide advanced application networking. This includes being able to meet these objectives:
Describe HTTP Layer 7 load balancing
Explain persistent HTTP connections and pipelined HTTP requests
Explain the reuse of ACE-to-server connections
Explain session persistence
Explain Layer 7 protocol inspection
Describe HTTP inspection
Explain the FTP processing capabilities of the ACE
Describe the Layer 7 inspected protocols
Configuring HTTP Layer 7 Load Balancing

This topic describes HTTP Layer 7 load balancing.
Configuring Additional Real Servers

ACE

ip address 192.168.1.11
inservice
ip address 192.168.1.12
inservice
rserver host PHP-HOST1
ip address 192.168.1.13
inservice
rserver host PHP-HOST2
ip address 192.168.1.14
inservice
ACEAP v1.01-4
The first step in configuring Layer 7 load balancing is to create the additional servers that will
be used to serve certain types of content. Here you add two new servers, PHP-HOST1 and
PHP-HOST2, to the Cisco 4710 Application Control Engine (ACE) appliance to complement
the servers you have already defined.
242
Configuring Additional Server Farms

ACE
serverfarm host EXT-SERVERS

rserver EXT-HOST1
inservice
rserver EXT-HOST2
inservice
serverfarm host PHP-SERVERS
rserver PHP-HOST1
inservice
rserver PHP-HOST2
inservice
ACEAP v1.01-5
The new servers must now be placed into a new server farm, as shown in the figure.
243
Define Layer 7 Class Map

ACE
class-map type http loadbalance match-any DYN-CONTENT

2 match http url .*\.php
policy-map type loadbalance http first-match SLB-LOGIC
class class-default
class EXTERNAL-VIP
ACEAP v1.01-6
Layer 7 load-balancing decisions are made by first classifying traffic based on HTTP
characteristics. This is done by specifying one or more class maps of type http loadbalance,
which will then be used in the load-balancing policy map. Layer 7 load-balancing policy maps
often use class-default, so normally the class-maps defined are only for those traffic
characteristics that you need to send to a different server farm from the default server farm.
In the example, you create a class map called DYN-CONTENT, which matches any URL that
ends in .php.
Note
244
match http commands can use regular expressions to match portions of the URL.
Define Layer 7 Load-Balancing Policy

ACE

class DYN-CONTENT
serverfarm PHP-SERVERS
class class-default
class EXTERNAL-VIP
ACEAP v1.01-7
Layer 7 load-balancing configuration is completed by adding a classification and action clause

to the load-balancing policy map. This clause specifies the actions to be taken for any traffic
that matches criteria defined by one or more load-balancing class maps.
In the example, you load balance traffic that matches the DYN-CONTENT class map to
servers in the PHP-SERVERS server farm.
Caution
There can be at most 10 cookie or header fields inspected per Layer 3 and 4 class map.
245
Layer 7 Load Balancing in running-config

198.133.219.25 eq www
2 match virtual-address 198.133.219.25 www
class DYN-CONTENT
serverfarm PHP-SERVERS
class class-default
class EXTERNAL-VIP
ACEAP v1.01-8
As before, the order in which you define things does not match the order in which the
configuration is stored by the ACE. The Layer 7 configuration is shown in the figure as the
ACE would store it.
246
Nested Class Maps
match-any
match-all
match-all
match-any
class-map type http loadbalance match-any CLASS1

match http url /news
match http url /sports
class-map type http loadbalance match-all CLASS2
match http header User-Agent header-value FireFox
match class CLASS1
ACEAP v1.01-9
Layer 7 load-balancing class maps can be nested up to two levels. The nested class allows you
to classify traffic on an AND and OR set of criteria. Nested class maps are configured by using
the match class statement in the outer class map.
For example, CLASS2 in the figure matches any request in which the user agent header is
Firefox and the URL requested is either /news or /sports.
247
Regular Expression Case Sensitivity

ACE
parameter-map type http HTTP_PARAM

case-insensitive
class EXTERNAL-VIP
appl-parameter http advanced-options HTTP_PARAM
248
ACEAP v1.01-10
By default, all regular expressions are case sensitive, but this can be changed in the
parameter map and applies to all regex parsing in a class associated with the parameter
map.
If you want only certain regular expressions to use case-sensitive matching, use the range
regex operator. For example, use [Ii][Nn][Dd][Ee][Xx] instead of index.
Regular Expression Considerations

ACE
URL decoding performed automatically before regular

expression processing; handles %hh and $Uhhhh.
Approximately 11 wildcard rules of the form .*keyword.*
combined together with all permutations can exhaust
available regular expression memory.
In some cases you can rewrite your expressions to save
memory, such as using .*[ab].* instead of using two
separate rules .*a.* and .*b.*.
ACEAP v1.01-11
Regular expression configuration and processing has several considerations of note:
URLs that contain encoded characters are decoded before being matched against regular
expressions. This process is also known as deobfuscation. The encoded characters that are
supported are single-byte characters encoded as %hh and unicode characters encoded as
%Uhhhh where h is any hexadecimal digit. Multibyte characters greater than 8 bits are
treated as 255. User-defined regular expressions should be configured to match the
canonical form of a URL. For example, configure match http url .*gif and not match http
url .*%67%69%66.
Regular expressions with wildcard rules of the form .*keyword.* are expensive from a
memory perspective. Eleven such rules can exhaust available regular expression memory.
More-sophisticated syntax can sometimes be used to combine two rules, for example, using
.*[ab].* to replace the rules .*a.* and .*b.*.
249
Persistent and Pipelined HTTP Extensions

This topic explains persistent HTTP connections and pipelined HTTP requests.
HTTP 1.1: Persistent Connection

Client
Web
Server
SYN
SYN_ACK
ACK
GET /a.gif HTTP 1.1
ACK
HTTP/1.1 200 OK
ACK
GET /b.gif HTTP 1.1
ACK
ACK
HTTP/1.1 200 OK
Continuation
FIN_ACK
FIN_ACK
ACK
ACEAP v1.01-13
A persistent connection is used to retrieve multiple resources from a web server without
incurring the overhead of setting up multiple TCP connections. Requests are sent individually
and responded to individually.
The figure illustrates this interaction as follows:
The client opens a TCP connection.
The client sends a GET request.
The server replies with the requested data. In this example, a small image fits within one
packet.
Instead of closing the TCP connection, the client sends another GET request.
The server replies with the requested data. Note that this time, the requested data spans two
packets.
The client has no more objects to request, and initiates the TCP close.
Note
250
This client is not using HTTP 1.1 pipelining. Therefore, the client waits for the entire reply to
a GET request before sending out a new request.
HTTP 1.1: Request Pipelining

Client
Web
Server
SYN
SYN_ACK
ACK
GET /a.gif HTTP 1.1
GET /b.jpg HTTP 1.1
ACK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
Continuation
ACK
FIN_ACK
FIN_ACK
ACK
ACEAP v1.01-14
Request pipelining takes persistent connections to an additional level. With request pipelining,
multiple requests are sent by the client before the server responds to any of them. These
multiple requests can all be sent in one TCP packet.
The figure illustrates the same requests as the previous figure. However, in this example, the
requests are pipelined as follows:
The client opens a TCP connection.
The client sends a packet with two GET requests.
The server replies with the requested data. In this example, the data is a small image that
fits within one packet.
The server replies with the data requested in the next request. In this example, the data is a
larger image that spans two packets.
The client has no more objects to request, and initiates the TCP close.
251
Configuring Persistent Rebalance

ACE

persistence-rebalance
set header-maxparse-length 2048
length-exceed continue
class class-default
class EXTERNAL-VIP
ACEAP v1.01-15
Persistent and pipeline requests can be load balanced as separate requests. This is configured by
creating an HTTP parameter map that specifies the persistence-rebalance command. This
parameter map is then used to modify HTTP processing in a Layer 3 and 4 policy map by
specifying an appl-parameter http advanced-options action statement.
Persistent rebalance causes the ACE to handle pipelined and persistent connections as follows:
Multiple persistent HTTP requests on the same TCP connection are balanced to
(potentially) different rservers, if persistence rebalance is configured.
This works without regard to packet boundaries.
Pipelined requests are buffered and later parsed after completing transmit of the previous
response. In other words, the requests are unpipelined.
If persistence-rebalance is not configured, pipelined requests on a connection are all sent to

the same server as they arrive.
Persistence-rebalance causes header and cookie insertion on every request
To set the maximum number of bytes to parse for cookies, HTTP headers, and URLs, use the
set header-maxparse-length bytes command in HTTP parameter map configuration mode.
The bytes argument specifies the maximum number of bytes to parse for the total length of all
cookies, HTTP headers, and URLs. Enter an integer from 1 to 65535. The default is 2048 bytes.
The length-exceed {continue | drop} command specifies the action to take if the header
exceeds the max parse length. The options are:
continue: Continue load balancing. When you specify this keyword, the persistencerebalance command is disabled if the total length of all cookies, HTTP headers, and URLs
exceeds the maximum parse length value.
drop (default): Stop load balancing and discard the packet.
In the example shown in the figure, you have modified the Layer 4 load-balancing
configuration to include persistent rebalancing.
252
Displaying Persistent Rebalance Statistics

ACE
switch/context# show stats http | include requests

Reuse msgs sent
: 0
, HTTP requests
: 7
Reproxied requests
: 0
, Headers removed
: 0
HTTP chunks
: 0
, Pipelined requests
: 2
ACEAP v1.01-16
The show stats http | include requests command can be used to display statistics relevant to
persistent rebalance.
253
Server Reuse
This topic explains the reuse of ACE-to-server connections.
TCP Reuse
TCP1
ACE-TCP1 Pool1
TCP2
ACE-TCP2 Pool2
TCP3
ACEAP v1.01-18
TCP connections from the ACE to real servers that are being used for HTTP requests can be
reused by other clients after the full HTTP response has been received. The ACE performs this
function by using HTTP 1.1 persistence for connections to the real servers. TCP connections
are opened in response to client requests and are assigned to a connection pool when the client
has finished using the connection. Subsequent client requests can then be sent to the server over
the open connection. Clients are assigned to connections in the connection pool by matching
the TCP options of the new client connection to the server connection with the best fit of TCP
options.
HTTP 1.1 persistence headers are analyzed in the incoming client request. Any connection
close headers are dropped, and a connection keepalive header is added as necessary. This sets
the request up to maintain the connection with the server.
HTTP responses are analyzed so that the end of the response can be identified. For resources of
fixed length, the content-length header is parsed and the response bytes are counted until the
full response has been received. For resources of variable length that are chunk encoded, the
chunk-encoding fields are analyzed to find the end of the response.
A server connection is placed in a connection pool for reuse after the full HTTP response has
been received, and the client either closes the connection or is rebalanced. Connection pools are
maintained on a per-server, per-server-farm basis.
254
Configuring TCP Reuse

ACE

server-conn reuse
class class-default
class EXTERNAL-VIP
ACEAP v1.01-19
Persistent and pipeline requests can be load balanced as separate requests. This is configured by
creating an HTTP parameter map that specifies the persistence-rebalance command. This
parameter map is then used to modify HTTP processing in a Layer 3 and 4 policy map by
specifying an appl-parameter http advanced-options action statement.
255
Displaying TCP Reuse Statistics

ACE
switch/context# show stats http | include Reuse

Reuse msgs sent
: 1
, HTTP requests
: 4
switch/context# show stats http | include Headers

Reproxied requests
: 0
, Headers removed
: 1
Headers inserted
: 1
, HTTP redirects
: 0
switch/context# show np 1 me-stats "-s icm | grep Reuse"

Reuse link update conn invalid error:
Reuse link update conn not on reuse erro
Reuse conn remove not on head error:
Connection Reuse Add Errors:
Connections Removed From Reuse Pools:
Connections Added To Reuse Pools:
ACEAP v1.01-20
The show stats http | include reuse and show np np_number me-stats -s icm | grep Reuse
commands can be used to display statistics relevant to TCP reuse.
256
Session Persistence
This topic explains session persistence.
The Shopping Cart Problem

Browse
I will never
shop here
again.
Select
2
3
Buy
Empty ?!?
ACEAP v1.01-22
Many web applications require multiple interactions between the client and the server. The
challenge with these applications is distinguishing which client is which, when a request is
received by the server. Often the solution is to establish a session ID that is transmitted by the
client with each request. This session ID is then used by the server to retrieve stored
information about former interactions with this client.
Load-balancing applications, such as the ACE, create a potential problem with this approach to
multiple interactions. For example, the shopper in the figure is using an e-commerce
application to purchase an item from a website. Simple round-robin load balancing can result in
the following sequence of interactions:
1. The shopper retrieves a page with details about a product of interest. Load balancing
assigns this request to the top server. The server creates a session ID and sends it along
with the rest of the response to the client.
2. The shopper presses the Buy Now button. The resulting request contains the session ID and
is assigned to the middle server. A record is created in the shopping cart database,
associating the item selected to the session ID. A page is built and returned to the client
with confirmation of the buy decision and checkout link.
3. The shopper presses the checkout link. The resulting request is assigned to the bottom
server. This server uses the session ID in the client request to retrieve information about
what items are in the shopping cart. Finding no entries in the shopping cart database, the
server includes an indication to the client that the cart is empty.
Note
The session ID can be carried in various places, including cookies and the URL.
257
Session Persistence
That
was
easy.
Browse
Select
Buy
2
1
ACEAP v1.01-23
The solution to the shopping cart problem and similar problems is session persistence, also
known as stickiness. Stickiness modifies the content-switching decision process. When a
connection first matches certain configured criteria, an entry is made in the sticky database by
the ACE. This entry stores the connection criteria that were matched and the results of the loadbalancing decision. Stickiness criteria can be matched on traffic in either direction. For
example, if a cookie is being used for stickiness, the ACE can match the set cookie portion of
the response from the server or in the cookie portion of the request from the client.
The shopper in the diagram is using an e-commerce application to purchase an item from a
website. With stickiness, the following sequence of interactions can result:
1. The shopper retrieves a page with details about a product of interest. Load balancing
assigns this request to the top server. The server creates a session ID and sends it with the
rest of the response to the client. The ACE detects the session ID and creates an entry that
associates the session ID with the top server in the sticky database.
2. The shopper presses the Buy Now button. The resulting request contains the session ID.
The ACE finds the session ID in the sticky database, and the request is assigned to the top
server. A record is created in the shopping cart database associating the item selected to the
session ID. A page is built and returned to the client with confirmation of the buy decision
and a checkout link.
3. The shopper presses the checkout link. Again, the ACE finds the session ID in the sticky
database, and the request is assigned to the top server. This server uses the session ID in the
client request to retrieve the list of items in the shopping cart and continues with the
transaction.
Note
258
Session persistence lasts longer than a single TCP connection.
Sticky Methods
Physical
Header
Version
IP Hdr
TCP Hdr
20 bytes 20 bytes
Header
Length
HTTP Request
Type of Service
Identification
Time to Live (TTL)
Total Length (in bytes)

Flags (3
bits)
Fragment Offset
Protocol
Header Checksum
Source IP Address
Destination IP Address
Source Port Number

Sequence Number
Acknowledgment Number
Header
Length
Reserved (6
bits)
Flags (6 bits)
TCP checksum
Window Size
Urgent Pointer
HTTP Request/Header
ACEAP v1.01-24
Three different methods of stickiness can be configured with the ACE appliance:
IP address stickiness: Tracks the source IP address, destination IP address, or both IP

addresses in the request packets
HTTP header stickiness: Tracks the value of an HTTP header field in the HTTP request
Cookie stickiness: Tracks the values of cookies in the HTTP request and response
259
Sticky Database Resources

ACE
Entries must be allocated with resource class.

Entries can not be oversubscribed.
Static entries are configurable.
One nonstatic entry free needed for dynamic sticky.
Oldest entries are replaced, if needed.
HTTP content sticky.
ACEAP v1.01-25
Session persistence is implemented by tracking load-balancing decisions in a sticky database.

The memory resources for entries in this database are allocated via the resource management
mechanism. By default, no sticky database entries are available to a context, and therefore, they
must be allocated by putting the context in a resource class. Database entries can not be
oversubscribed.
Static and dynamic sticky entries are stored in the database. At least one entry that is not used
for a static entry must be available for dynamic sticky to work. If a new dynamic sticky
database entry needs to be created, the oldest database entry is replaced.
Note
260
If entries are removed from a context through changes in the resource management
definitions, then the oldest sticky database entries are removed. This can take some time.
Sticky Group Attributes

ACE
timeout sticky-time
timeout activeconns
replicate sticky
serverfarm name1 [backup name2 [sticky] [aggregate-state]]
ACEAP v1.01-26
Within a context, multiple sticky groups can be defined, each of which uses a different sticky
group method. All three sticky methods share some common parameters, which are configured
in the sticky group.
The attributes are:
Timeout: Configured with the timeout sticky-time command, that is, the number of
minutes that a sticky entry is stored in the sticky database. The timer for an entry is reset
each time a new connection or a new HTTP GET is received.
Active connection timeout: Configured with the timeout activeconns command. By

default, the ACE appliance removes a sticky database entry when the timer for that entry
expires and there are no active connections. The active connection timeout feature allows
the ACE to remove the sticky database entry even when active connections exist.
Sticky replication: Configured with the replication sticky command, this attribute causes
the ACE to replicate sticky database entries to a standby ACE appliance.
Server farm: Configured with the serverfarm command. This command specifies the
server farm to which requests are load balanced after they have been processed by the
sticky feature. If a sticky database entry is found, the client request is sent accordingly. If
no sticky database entry is found, the request is load balanced as normal, and the loadbalancing decision is saved in the sticky database. The backup option specifies a backup
server farm to be used if the primary server farm is down. A backup server farm with the
sticky option specifies that sticky processing is performed for connections sent to the
backup server farm, as well. Finally, the aggregate-state option specifies that the status of
the primary server farm is tied to all the real servers in both the primary and backup server
farms.
261
IP Address Sticky Configuration

ACE
sticky ip-netmask netmask address

[source | destination | both] name
static client source ip-address rserver rserver-name [port]
static client destination ip_address rserver rserver-name
[port]
static client source ip_address destination ip_address
rserver rserver-name [port]
ACEAP v1.01-27
IP address sticky groups are configured with the sticky ip-netmask command that is shown in
the figure. IP address sticky groups are configured to track entries in the sticky database by
source IP address, destination IP address, or source-destination IP address pair. Static entries
can be configured with the static client command. Three variations of the command syntax are
shown in the figure and correspond to the type of address tracking configured for the sticky
group.
262
Header Sticky
ACE
sticky http-header header_name group_name

header offset offset [length length]
static header-value value reserver name [port]
ACEAP v1.01-28
Header sticky groups are configured with the sticky http-header command that is shown in the
figure. The value in the header field specified by the header_name parameter is hashed and
tracked in the sticky database. An offset and length can be specified to limit the hash function
to a portion of the header value with the header offset command. The offset values can be from
0999, and the length value can be from 11000.
263
Cookie Sticky
ACE
sticky http-cookie cookie_name group_name

cookie insert [browser-expire]
cookie offset offset [length length]
cookie secondary cookie_name
static cookie-value value rserver name [port]
ACEAP v1.01-29
Cookie sticky groups are configured with the sticky http-cookie command, as shown in the
figure. The value in the cookie specified by the cookie_name parameter is hashed and tracked
in the sticky database. An offset and length can be specified to limit the hash function to a
portion of the header value with the cookie offset command. The offset values can be from 0
999, and the length value can be from 11000.
Secondary cookies that are located in the URL query also can be used for sticky with the same
or different cookie name.
To use cookie sticky for servers that do not generate cookies, the ACE appliance can be
configured to insert a set-cookie header in the HTTP response with the cookie insert command.
264
Activating a Sticky Group

ACE
sticky ip-netmask 255.255.255.255 address source EXT-STICKY

class class-default
sticky-serverfarm EXT-STICKY
class EXTERNAL-VIP
ACEAP v1.01-30
In the figure, an IP address-based sticky group called ext-sticky, which caches load-balancing
decisions to the EXT-SERVERS server farm, is defined.
After being defined, sticky groups are activated by specifying the sticky group name in the
sticky-serverfarm action statement in loadbalance policy-map. In the figure, the Layer 4
load-balancing configuration is enhanced by adding an IP source address-based sticky group.
Note
The sticky-serverfarm action statement replaces the serverfarm action statement normally
found, as shown in the figure in the modified line of the SLB-LOGIC policy map.
Caution
A maximum of ten total cookie and/or header names can be processed for each Layer 3 and
4 class map. In other words, each VIP can use up to ten cookie and/or header fields for
Layer 7 load-balancing and sticky decisions.
265
Displaying Sticky Entries

ACE
switch/Admin# show sticky database

sticky group : STICKY1
type
: HTTP-COOKIE
timeout
: 3600
sticky-entry
flags
timeout-activeconns : FALSE
rserver-instance
time-to-expire
---------------------+--------------------------------+-------------+-------+
587583818767988700
-
R1:0
215961
switch/Admin# show stats http | include insert

Headers inserted
: 1
, HTTP redirects
: 0
ACEAP v1.01-31
The contents of the sticky database can be displayed with the show sticky database command.
If cookie sticky is being used with cookie insert, the number of cookies that are inserted can be
displayed with the show status http command. In the figure, this command is piped through
the include filter to limit the output to the line of interest.
266
Protocol Inspection
This topic explains Layer 7 protocol inspection.
Inspection in ACE
ACE
Protocol-specific inspection supported for:

FTP
Strict FTP
RTSP
ICMP
DNS
HTTPS
ACEAP v1.01-33
Protocol-specific inspection functions on the ACE appliance can be used to analyze or modify
application data that is contained in an IP packet. Compliance with RFCs can also be enforced,
as well as filtering for user-defined interactions, which are denied if attempted.
267
HTTP Inspection
This topic describes HTTP inspection.
HTTP Inspection
ACE
HTTP inspection:
Ensures RFC compliance
Supports policy-based request filtering
ACEAP v1.01-35
The figure describes HTTP inspection.
268
Configuring HTTP Inspection

ACE
class-map type http inspect match-any HTTP-DONTS

match request-method rfc trace
match port-misuse p2p
policy-map type inspect HTTP first-match HTTP-SECURITY
class HTTP-DONTS
reset
match strict-http
reset
class-map match-all HTTP-CONNS
2 match port tcp eq http
policy-map multi-match PROCESS-TRAFFIC
class HTTP-CONNS
inspect http policy HTTP-SECURITY
ACEAP v1.01-36
The figure shows an HTTP inspection configuration. This configuration uses the class map
called HTTP-DONTS to classify HTTP requests of trace and point-to-point tunneling protocols
for further processing. The HTTP-SECURITY policy map uses the reset command to cause the
ACE appliance to reset any connection that attempts to use one of the commands from the
HTTP-DONTS class map. The HTTP-SECURITY policy map also demonstrates the use of an
inline match strict-http statement.
269
FTP Protocol Processing

This topic explains the FTP processing capabilities of the ACE.
FTP Inspection
ACE
FTP application inspection performs the following

tasks:
NATs embedded IP address and port
Prepares dynamic secondary data connection
ACEAP v1.01-38
Several of the FTP commands and responses contain embedded IP-address and port
specifications for one of the communicating partners. If the FTP connection is translated by
network address translation (NAT) by way of the ACE appliance, either because of an explicit
NAT configuration or an implicit configuration because of FTP server load balancing, these
embedded addresses must be adjusted based on the NAT tables. The FTP inspection function
performs these translations.
FTP is also somewhat unusual in that the connection from the client is a control connection that
is not used for the bulk of data transfer. Rather, a second data connection is initiated from the
server to the client when a file transfer is started. Because these connections happen
dynamically, it is difficult to account for them in statically defined access control lists (ACLs)
in a way that does not compromise security. The FTP inspection function addresses this issue
by preparing for the secondary data connection when the relevant FTP commands and
responses are processed.
270
Configuring FTP Inspection

ACE
policy-map type loadbalance generic first-match SLB-LOGIC

class class-default
2 match virtual-address 198.133.219.25 tcp eq ftp
class EXTERNAL-VIP
inspect ftp
access-list FROM-231 extended permit tcp any host
198.133.219.25 eq ftp
interface vlan 231
ACEAP v1.01-39
The figure shows the Layer 4 load-balancing configuration that was modified to load balance
FTP server connections. The changes to the VIP and ACL definitions reflect the new port of
interest. The inspect ftp statement that engages the FTP inspection function for any
connections through the FTP VIP has also been added.
271
Strict FTP Inspection

ACE
Strict FTP inspection:

Ensures RFC compliance
Hides user IDs
Disallows reply spoofing
Disallows command pipelining
Supports policy-based command filtering
ACEAP v1.01-40
If the strict option is enabled, each ftp command and response sequence is tracked for the
following anomalous activity:
Truncated command: The number of commas in the PORT and PASV reply commands
is checked to see if it is five. If it is not five, the PORT command is assumed to be
truncated, and the TCP connection is closed.
Incorrect command: Checks the ftp command to see if it ends with <CR><LF>
characters, as required by the RFC. If it does not, the connection is closed.
Size of retr and stor commands: These are checked against a fixed constant of 256. If the
size is greater, an error message is logged and the connection is closed.
Command spoofing: The PORT command is always sent from the client. The TCP
connection is denied if a PORT command is sent from the server.
Reply spoofing: The PASV reply command (227) is always sent from the server. The TCP
connection is denied if a PASV reply command is sent from the client. This prevents the
security hole when the user executes quote 227 xxxxx a1, a2, a3, a4, p1, p2.
Invalid port negotiation: The negotiated dynamic port value is checked to see if it is less
than 1024. Port numbers in the range from 1 to 1024 are reserved for well-known
connections. If the negotiated port falls in this range, the TCP connection is freed.
Command pipelining: The number of characters present after the port numbers in the
PORT and PASV reply command is cross checked with a constant value of 8. If it is more
than 8, the TCP connection is closed.
Strict FTP inspection hides the nonexistence of a user ID that is specified in the FTP user
command by changing any 530 responses from the FTP server to 331 responses. This keeps the
FTP client from being able to verify the existence of a user on the FTP server.
Additionally, each ftp command can be further filtered by specifying an FTP inspection policy
that determines which ftp commands are allowed and which are denied. If a denied command
is issued, the connection is closed.
272
Configuring Strict FTP Inspection

ACE
class-map type ftp inspect match-any DELETES

match request-method dele
match request-method rmd
policy-map type inspect ftp first-match NO-DELETES
class DELETES
deny
match syst-cmd request-method syst
mask-reply
class-map match-all FTP-CONNS
2 match port tcp eq ftp
class ftp-conns
inspect ftp strict policy NO-DELETES
ACEAP v1.01-41
The figure shows a strict FTP inspection configuration. This configuration uses the class map
called deletes to classify FTP requests of dele and rmd for further processing. The no-deletes
policy map uses the deny command to cause the ACE appliance to reset any connection that
attempts to use one of the commands from the deletes class map. The no-deletes policy map
also demonstrates the use of an inline match statement and the mask command to mask the
reply that the FTP server generates when it receives the ftp syst command.
273
Other Inspected Protocols

This topic describes the Layer 7 inspected protocols.
RTSP Inspection
ACE
RTSP application inspection performs the

following tasks:
Enforced RFC 2326 compliance (TCP only)
Prepares dynamic secondary data connection
ACEAP v1.01-43
Real Time Streaming Protocol (RTSP) is used by RealAudio, RealNetworks, Apple QuickTime
4, RealPlayer, and Cisco IP/TV connections.
RTSP applications use the well-known port 554 (Cisco IP/TV uses 8554 as well) with TCP,
and rarely with User Diagram Protocol (UDP), as a control channel. ACE inspection supports
only TCP in conformity with RFC 2326. The TCP control channel is used to negotiate the data
channels that are used to transmit audio and video traffic, depending on the transport mode that
is configured on the client. The supported Real Data Transports (RDTs) are rtp/avp,
rtp/avp/udp, x-real-rdt, x-real-rdt/udp, and x-pn-tng/udp. The RTSP inspection feature parses
SETUP response messages with a status code of 200 and opens pinholes for data channels.
Because RFC 2326 does not require that the client and server ports must be in the SETUP
response message, the ACE appliance keeps state information to remember the client ports in
the SETUP message. For example, QuickTime places the client ports in the SETUP message,
and then the server responds with only the server ports.
The ACE appliance does not offer RTSP inspections support for multicast RTSP, RTSP over
UDP, or HTTP cloaking in which RTSP messages are embedded in HTTP transactions.
274
Configuring RTSP Inspection

ACE
class-map match-all RTSP-CONNS

2 match port tcp eq rtsp
class rtsp-conns
inspect rtsp
access-list FROM-231 extended permit tcp any any eq rtsp
interface vlan 231
ACEAP v1.01-44
The figure shows a basic RTSP inspection configuration. The RTSP inspection feature is
activated for the traffic matched by the rtsp-conns class map by specifying the inspect rtsp
command statement in the Layer 3 and 4 policy map.
275
ICMP Inspection
ACE
ICMP application inspection performs the following

tasks:
Creates connection state for ICMP requests
Verifies sequence numbers
Matches responses to requests
ACEAP v1.01-45
The Internet Control Message Protocol (ICMP) inspection feature creates connection state
information for ICMP packets. ICMP response packets are checked against the outstanding
requests to ensure that only a single response packet is received for each request. Responses
that are not part of an established connection are discarded.
276
ICMP Error Inspection

ACE
ICMP error application inspection adds the following

to ICMP inspection:
Allows error packets for existing connections by checking the
embedded packet
Allocates NAT translation entries for intermediate nodes or
end nodes that generate errors
NAT translation applied to embedded packet
ACEAP v1.01-46
Unsolicited ICMP error messages are generated by intermediate and end nodes when they are
unable to process a packet. The ICMP error packet contains an embedded copy of the packet
that generated the error. The default processing performed by the ACE appliance translates the
source IP address in the ICMP error packet with the destination address that is specified in the
embedded packet, causing all ICMP errors to appear to come from the destination IP address.
ICMP error inspection extends the processing applied to ICMP error messages by allocating
additional NAT entries as needed to translate the address of all intermediate or end nodes that
are generating ICMP errors. The ICMP errors are also checked against the connection entry that
is relevant to the embedded packet, to filter out ICMP error messages that are not part of
existing connections.
277
Configuring ICMP Inspection

ACE
access-list ACL1 line 10 extended permit ip any any

class-map match-any ICMP-FLOWS
match access-list ACL1
policy-map multi-match FIXUP-ICMP
class ICMP-FLOWS
inspect icmp error
access-list FROM-231 extended permit ip any any
interface vlan 231
service-policy input FIXUP-ICMP
ACEAP v1.01-47
ICMP inspection is configured by using the inspect icmp [error] action statement in a Layer 3
and 4 policy map. An example of this type of configuration is shown in the figure.
278
DNS Inspection
ACE
DNS application inspection performs the following

tasks:
Matches DNS responses to requests
Applies NAT translation to A records
Performs maximum-length check
Performs security checks
ACEAP v1.01-48
The Domain Name System (DNS) inspection feature matches DNS responses to requests on a
one-to-one basis. Records that are returned in a DNS response are translated based on the NAT
configuration of the ACE appliance. Maximum packet length and security length checks are
also performed on the DNS response. The security checks include enforcing a maximum label
length of 63 bytes, enforcing a maximum domain name length of 255 bytes, and detection of
compression loops in the DNS response.
DNS queries that are handled by DNS inspection do not time out like regular UDP connections.
The ACE tears down the connection associated with the query as soon as the reply to the DNS
query has been received.
Note
Only forward lookups are translated by NAT. PTR records received in response to a reverse
lookup are not translated.
279
Configuring DNS Inspection

ACE
class-map match-all DNS-L4-INSPECT-CLASS

match port udp eq domain
policy-map multi-match DNS-L4-INSPECT-POLICY
class DNS-L4-INSPECT-CLASS
inspect dns maximum-length 1000
interface vlan 231
service-policy input DNS-L4-INSPECT-POLICY
ACEAP v1.01-49
Because DNS Inspections are not load balanced, only a Layer 4 class map and policy map are
required.
The maximum-length keyword is optional; if it is omitted, the ACE does not check the DNS
packet size.
280
Summary
Summary
Load-balancing decisions can be made by analyzing the Layer 7
application data.
Persistent and pipelined client connections can be rebalanced by
the ACE.
Server reuse allows ACE-to-server connections to be used for
multiple client requests.
Session persistence, also known as stickiness, is used to allow
multitransaction HTTP applications to be load balanced.
Layer 7 protocol inspection provides additional application-level
security.
HTTP inspection can be used to control HTTP transactions
according to user policy.
FTP application inspection is supported.
Several protocols can be inspected for security purposes.
ACEAP v1.01-50
281
282
Lesson 9
Processing Secure
Connections
Overview
In this lesson, you will learn how to describe the ACE support for SSL protocol processing.
Objectives
Upon completing this lesson, you will be able to describe the ACE support for SSL protocol
processing. This includes being able to meet these objectives:
Describe the use of digital encryption in IP-based applications
Explain SSL offload, back-end SSL, and end-to-end encryption
Describe the steps needed to configure a public key infrastructure
Describe the steps needed to configure SSL proxy services
Digital Encryption Technologies

This topic describes the use of digital encryption in IP-based applications.
Symmetric Encryption
Jane
John
ACEAP v1.01-4
Symmetric encryption algorithms rely on a shared key that each communicating party has
access to. This same key is used by both the encryption and decryption algorithms. The
symmetrical usage of keys between Jane and John is shown in the figure. Jane and John have
shared encryption keys. Her key encrypts her plaintext, and his key decrypts her encrypted
message, and vice versa, to accomplish symmetric encryption.
The biggest challenge with symmetric encryption is the management of the shared keys. If
multiple, mutually exclusive secure channels of communication are required, multiple shared
keys need to be deployed. The shared key to be used between two parties must be distributed in
a fashion that limits access to the key to the two intended recipients.
Consider an e-commerce company. Communications with each individual customer should be
secured in such a way that other customers can not decrypt them. This requires that a shared
key be generated for each customer. Users on the Internet often want to become customers on
the spur of the moment. This requires a shared key to be generated and distributed to the
customer on demand. Distribution of this key is something that must be secured, and yet secure
communications are not possible until the customer has the key.
284
Asymmetric Encryption
Jane
John
Key 1
Key 2
Key 1
Key 2
ACEAP v1.01-5
Asymmetric encryption algorithms use a pair of keys. Data encrypted with one key can be
decrypted only with the other key of the pair.
In the figure, Jane uses Key 1 to encrypt data. Now that her data is encrypted, only Key 2 can
decrypt it; John, the holder of Key 2, decrypts her message. The asymmetrical usage of keys is
revealed when John encrypts a message to Jane using Key 2. After the message is encrypted,
only Key 1 can be used to decrypt it. Jane uses Key 1 and decrypts the message.
Compared with symmetric encryption, asymmetric encryption security requires more
processing power.
285
Public Key Encryption

Key 2
Key 2
Key 2
Key 1
ACEAP v1.01-6
The figure shows an Internet server that needs to communicate securely with multiple clients.
This can be accomplished with asymmetric encryption. The server uses Key 1 for its encryption
and decryption activities. The clients use Key 2 for their encryption and decryption activities.
The use of an asymmetric encryption algorithm leads to the following conditions:
The server can decrypt data encrypted by any client.
Any client can decrypt data encrypted by the server.
No client can decrypt data encrypted by another client.
Key 1 in the figure is referred to as the servers private key, and Key 2 is known as the public
key. The names of the keys lead to the two names for this use of asymmetric encryption:
public/private encryption, and the more common public key encryption.
Public keys can be dispersed in any fashion without concern for privacy; private keys must be
closely secured.
286
Digital Signatures
Hash
Hash
Signature
Equal?
ACEAP v1.01-7
Digital signatures are used to verify that data has not been modified. This is done without
encrypting the data being signed.
Hashing functions are one-way algorithms that take a message of any size and reduce it to a
fixed-length hash value, also often known as the digest or fingerprint of the original message.
Sufficiently intricate functions that create a sufficiently long hash value produce fingerprints
that are nearly unique. Common hashing algorithms include MD5 (Message Digest 5) and
SHA1 (Secure Hashing Algorithm 1). MD5 fingerprints are 128 bits long; SHA1 fingerprints
are 160 bits long.
Data to be signed is first run through a hash function. The message digest is then encrypted
with the private key of the signing agency. This encrypted message digest is referred to as a
digital signature. The digital signature and the original data are then usually packaged together
in one data file to be transmitted or stored.
A signed data file can be verified by a receiver. First, the receiver uses the same hash function
as the signer to computer a digest of the signed data. The signers public key is then used to
decrypt the signature, which is compared to the computed message digest. If the computed and
decrypted message digests are equal, the message has not been modified since it was signed.
287
Certificates
Certificate Authority
Company Docs
Application
Key Pair
Certificate
Signing
Request
Public Key
Private Key
Public Key
Common name
Domain name
Location
E-mail
Server
Private Key
Certificate
Application
Validation
Process
Certificate
Signing
Request
Public Key
Common name
Domain name
Location
E-mail
Certificate
Server Public Key

Server Public Key
SSL Server
ACEAP v1.01-8
Asymmetric encryption provides the assurance that any communicating process that uses a
public key is interacting with a process that has access to the corresponding private key. An
issue not addressed by these algorithms is the identity of the entity that gave you the public key
in the first place. Someone could hand you a disk with a public key for www.irs.gov and point
you to another site that he or she owned and ask you for your tax information. You would be
assured that you were talking to the holder of the corresponding private key, but how do you
know that the private key is really held by the IRS?
The solution to the problem is the use of digital certificates, which are digital documents
attesting to the binding of a public key to an individual or other entity.
Digital certificates consist of a public key that has been signed by one or more certificate
authorities (CAs). Multiple signatures signify a hierarchy of CAs where each CA has a
certificate signed by a higher-level CA. For a certificate to be useful, the signatures must
eventually trace back to a CA that both communicating partners trust implicitly. These CAs are
usually referred to as trusted root CAs.
In the web browser market, each browser has a collection of trusted root CA certificates built
into the executable image of the browser. If a certificate is received from a server that is signed
at the highest level by one of the root certificates, the browser trusts the identity of the
organization running the server; otherwise, the user is prompted for a trust/no-trust decision.
Commercial CAs have a fairly rigorous verification process that they engage in when a
certificate is requested. This process verifies that the public key that they are being asked to
certify is owned by the entity requesting the certification.
The ACE Appliance can hold a maximum of 4096 certificates, and can hold the same number
of key pairs. The ACE supports all major digital certificates from CAs including VeriSign,
Entrust, Netscape iPlanet, Windows 2000 Certificate Server, Thawte, Equifax, and Genuity.
288
SSL Fundamentals: Key Exchange

Packet Flow Overview
Client Hello
Certificate
Server Hello
Server Public Key
Server Public Key

Public Key
Key Exchange
Random
Number
Generator
RSA
Encrypt
SAasdfkjw1340+jakjb//alkjt
Shared Secret
Encrypt & Decrypt
Shared Secret Key
Data Exchange
Shared Secret
Encrypt & Decrypt
Data
Data
Client Browser
Private Key
Data
Data
Shared Secret Key
RSA
Encrypt
Server
ACEAP v1.01-9
Secure Sockets Layer (SSL) uses a combination of public key encryption and symmetric
encryption.
Public key encryption is used to initiate an SSL session using the following steps:
Step 1
The client sends a client hello packet to the server.
Step 2
The server sends a server hello set of packets to the client. Included in these packets
is a copy of the servers certificate.
Step 3
The client uses the certificate to verify the identity of the server.
Step 4
The client creates a session key to be used as a shared key for symmetric encryption.
Step 5
The client encrypts the session key with the servers public key.
Step 6
The server decrypts the session key with its private key.
Step 7
Both systems encrypt further traffic with the shared key.
289
ACE SSL Characteristics

ACE
SSL v2/3 hybrid hello

100,000 simultaneous
connections
Connections fully proxied
all the time
Weighted cipher suite
selection
No SSL-related HTTP
header insertion
ACEAP v1.01-10
The ACE appliance supports SSL version 3 and Transport Layer Security (TLS) version 1. A
client capable of both SSL versions 2 and 3 might send a version 2/3 hybrid client hello, which
the ACE supports. However, the ACE does not create an SSL version 2 connection, but replies
to the hybrid hello with an SSL version 3 server hello.
The ACE appliance supports 100,000 simultaneous SSL connections. These connections are
fully proxied throughout the life of the connection because every packet needs to be processed
by the full TCP and SSL stack. The ACE can be licensed to process up to 7500 transactions per
second (TPS); by default, it supports 1000 TPS.
SSL cipher suites can be weighted to affect cipher selection. The cipher suites supported by the
ACE appliance are:
290
rsa-export1024-with-des-cbc-sha
rsa-export1024-with-rc4-56-md5
rsa-export1024-with-rc4-56-sha
rsa-export-with-des40-cbc-sha
rsa-export-with-rc4-40-md5
rsa-with-3des-ede-cbc-sha
rsa-with-aes-128-cbc-sha
rsa-with-aes-256-cbc-sha
rsa-with-des-cbc-sha
rsa-with-rc4-128-md5
rsa-with-rc4-128-sha
SSL Service Options

This topic explains SSL offload, back-end SSL, and end-to-end encryption.
SSL Termination
ACE
Encrypted
Unencrypted
ACEAP v1.01-12
SSL termination is the ACE terminology for deploying the ACE appliance as an SSL offload
device. When configured for SSL termination, the ACE appliance terminates the SSL
connection from the client, decrypts the request from the client, and sends it as plaintext to the
real servers. Notice that the real servers are selected through the normal load-balancing
functions of the ACE appliance. Responses from the real servers are received by the ACE in
plaintext, encrypted, and sent back over the SSL connection to the client.
291
SSL Initiation
ACE
Encrypted
Unencrypted
ACEAP v1.01-13
SSL initiation is used to implement a network design that is often called back-end SSL, in
which the interaction between the client and the ACE is in plaintext, and the traffic between the
ACE and the real servers is encrypted SSL traffic. In SSL initiation, the ACE appliance takes
the role of the SSL client when dealing with the real servers.
292
End-to-End Encryption
ACE
Encrypted
Unencrypted
ACEAP v1.01-14
End-to-end encryption combines SSL termination and SSL initiation in one ACE configuration.
This deployment model is often used when highly sensitive data needs to be load balanced
based on Layer 7 criteria but the data is not allowed to exist on any network segment as
plaintext. In this situation, the data is unencrypted only within the ACE appliance.
293
Configuring a Public Key Infrastructure

This topic describes the steps needed to configure a public key infrastructure.
PKI Resource Formats

ACE
Supported key sizes (in bits): 512, 1024, 1536,

2048
Certificate support:
Import of certificates for the following formats: PEM,
DER, and PKCS12
Generation of certificate signing request
ACEAP v1.01-16
The supported key sizes are shown in the figure, as are the supported file formats for
certificates. Note that the ACE can not generate certificates on its own, but relies on external
public key infrastructure (PKI) resources for this process.
294
Generating a Public/Private Key Pair

ACE
crypto generate key [non-exportable] bitsize filename
ACEAP v1.01-17
A public and private key pair is generated with the crypto generate key command, which
specifies the number of bits in the key and the file in which the key is stored. Including the
nonexportable keyword marks, the resulting key file is ineligible to be exported off the ACE
appliance and stored on an external file server.
295
Configuring Certificate Signing Request

Parameters
ACE
crypto csr-params myCSRconfig

country-name US
state GA
locality Atlanta
org-name Example Inc
org-unit SSL Acceleration Testing
common-name www.example.com
serial-number 1001
email webadmin@example.com
ACEAP v1.01-18
Parameters for the certificate signing request (CSR) are configured with the crypto csr-params
param_name command. Within the CSR parameter configuration submode, the details of the
CSR are defined as follows:
296
Country name where the SSL site resides is defined with the country-name command.
Country name is a required attribute.
State or province name where the SSL site resides is defined with the state command. State
name is a required attribute.
A locality within a state where the SSL site resides is defined with the locality command.
Locality name is an optional attribute.
The name of the organization that owns the SSL site is defined with the org-name
command. Organizational name is an optional attribute.
The name of the unit within the organization that is responsible for the SSL site is defined
with the org-unit command. Organizational unit name is an optional attribute.
The domain name or host name of the SSL site is defined with the common-name
command. Common name is a required attribute.
The serial number for the certificate to be issued is defined with the serial-number
command. Serial number is a required attribute. Note that the CA might overwrite this
serial number when they generate the certificate.
The e-mail address of a person responsible for this SSL site is defined with the email
command. E-mail is an optional attribute.
Generating Certificate Signing Request

ACE
switch/context(config) # crypto generate csr myCSRconfig mykey.pem

-----BEGIN CERTIFICATE REQUEST----MIIBcDCCARoCAQAwgbQxCzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlTb21lU3RhdGUx
ETAPBgNVBAcTCFNvbWVDaXR5MRcwFQYDVQQKEw5BIENvbXBhbnkgTmFtZTEbMBkG
A1UECxMSV2ViIEFkbWluaXN0cmF0aW9uMR0wGwYDVQQDExR3d3cuYWNvbXBhbnlu
YW1lLmNvbTEpMCcGCSqGSIb3DQEJARYad2ViYWRtaW5AYWNvbXBhbnluYW1lLmNv
bSAwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAtBNcNXMBqh5cJHbWFsqe9LMUO90T
pYG7gF5ODvtFGREMkHh7s6S1GF131IBWCSelG4Q/qEztjCO7y3pyjruVNQIDAQAB
oAAwDQYJKoZIhvcNAQEEBQADQQCMmXRdNPBDtMQPFvylpED5UMbeaMRm2iaC+1uZ
IaHmdoX4h5eckauu9pPgSxczau8w68PF+PDS9DAAMeRDxisL
-----END CERTIFICATE REQUEST----switch/context(config) #
ACEAP v1.01-19
The CSR is generated with the crypto generate csr csr_parameter key_file command. As
shown in the figure, the CSR is sent to the terminal as a result of this command. The CSR can
then be copied to another system and sent to the CA for processing.
297
Transferring PKI Resources

ACE
Import a PKI resource:

crypto import [non-exportable] {{{ftp | sftp}
[passphrase passphrase] ip_addr username
remote_filename local_filename} | {tftp [passphrase
passphrase] ip_addr remote_filename local_filename}|
{terminal local_filename [passphrase passphrase]}}
Export a PKI resource:

crypto export local_filename {ftp | sftp | tftp |
terminal} {ip_addr} {username} {remote_filename}
ACEAP v1.01-20
PKI files can be imported into the ACE from other systems with the crypto import command
and can be stored on external servers with the crypto export command. The syntax of both
commands is shown in the figure. The nonexportable keyword on the crypto import command
specifies that the crypto file can not be exported from the ACE with the crypto export
command.
298
Listing PKI Resources

ACE
switch/context(config) # show crypto files

Filename
File
File
Expor Key/
Size
Type
table Cert
---------------------------------------------------mycert.pem 1275
PEM
No
CERT
mykey.pem
283
PEM
Yes
KEY
ACEAP v1.01-21
The list of crypto files currently stored on the ACE appliance can be displayed with the show
crypto files command. Sample output is shown in the figure.
299
Managing PKI Resources

ACE
Delete a PKI resource:

crypto delete {filename | all}
View a PKI resource:

show crypto {cert | key} [filename]
ACEAP v1.01-22
PKI files can be deleted with the crypto delete command. They can also be displayed on the
console with the show crypto command.
300
Configuring SSL Proxy Services

This topic describes the steps needed to configure SSL proxy services.
Configuring SSL Termination

ACE
ssl-proxy service secure_access

key myrsakey_server
cert mycert_server
2 match virtual-address 198.133.219.25 tcp eq https
policy-map type loadbalance first-match slb-logic
class class-default
serverfarm ext-servers
policy-map multi-match client-vips
class external-vip
ssl-proxy server secure_access
loadbalance policy slb-logic
ACEAP v1.01-24
SSL termination is configured by first defining an SSL termination point with the ssl-proxy
service name command. Within the configuration submode for the SSL proxy, configuration
statements associate the private key and the certificate files with the SSL proxy.
SSL processing is then activated by using the ssl-proxy server name action statement in a
Layer 3 and 4 policy map.
In the figure, the sample Layer 4 load-balancing configuration has been changed to accept
connections from clients via SSL. These connections are then decrypted on the ACE and load
balanced to the back-end servers.
301
Configuring SSL Certificate Chains

ACE
crypto
cert
cert
cert
chaingroup InternalCAcerts
rootCA.pem
ouCA.pem
deptCA.pem

key myrsakey_server
cert mycert_server
chaingroup InternalCAcerts
ACEAP v1.01-25
A chain of certificates can be sent to the SSL peer in addition to the server certificate defined in
the SSL proxy. This chain of certificates is often used to supply root and intermediate CA
certificates when an internal CA structure is used by an enterprise.
The chain group is configured with the crypto chaingroup command. In the chain group
configuration submode, the individual certificates in the chain group are specified with the cert
command. You do not need to enter the chain group in any particular order, because the ACE
determines the proper order from the certificate files. A chain group can be displayed with the
show crypto chaingroup command.
The figure shows the SSL proxy configuration from the preceding figure, to which a certificate
chain group has been added.
302
Configuring SSL Protocol Options

ACE
parameter-map type ssl only-ssl3

version ssl3
key myrsakey_server
cert mycert_server
ssl advanced-options only-ssl3
ACEAP v1.01-26
SSL parameters for the SSL proxy service can be changed by creating an SSL parameter map
and associating it with the SSL proxy service. Within the parameter map, particular ciphers can
be specified as allowable with the cipher command. The version command can be used to limit
connections to ssl3, tls1, or all versions of SSL. In the figure, the SSL proxy has been changed
to accept only SSL v3 connections.
303
Configuring SSL Initiation

ACE
ssl-proxy service backend_ssl

2 match virtual-address 198.133.219.25 tcp eq http
class class-default
ssl-proxy client backend_ssl
class external-vip
ACEAP v1.01-27
SSL initiation is configured by first defining an SSL service point with the ssl-proxy service
command. For SSL initiation, there are often no other parameters to specify in the
configuration submode for the service point.
The service point is then used to encrypt data that has been load balanced to back-end servers
by specifying the ssl-proxy client action statement in the load-balancing policy map.
In the figure, the Layer 4 load-balancing configuration has been extended to encrypt
connections to the real servers with SSL.
304
Configuring SSL End-to-End

ACE

key myrsakey_server
cert mycert_server
ssl-proxy service backend_ssl
2 match virtual-address 198.133.219.25 any
class class-default
ssl-proxy client backend_ssl
class external-vip
ssl-proxy server secure_access
ACEAP v1.01-28
The figure shows SSL end-to-end configuration.
305
What Did Not Make It into ACE SSL v1.0

ACE
Client authentication
Session cache reuse
Integration with high availability
SSL statistics and SSL MIB
SSL rehandshake based on time or data transferred
URL rewrite
HTTP header insertion
Federal Information Processing Standard (FIPS) 140-2
ACEAP v1.01-29
The figure identifies the functions that did not make it into ACE SSL v1.0.
306
Summary
Summary
Digital encryption technologies are used to provide secure HTTP
communications.
SSL support on the ACE can be used to provide SSL offload,
back-end SSL encryption, and end-to-end encryption.
PKI resources such as key pairs and certificates are required to
support SSL.
SSL services on the ACE appliance are provided through SSL
proxies.
ACEAP v1.01-30
307
308
Lesson 10
Deploying Application
Acceleration and Optimization
Overview
In this lesson, you will learn how to describe the major application acceleration and
optimization features and their benefits in the overall design.
Objectives
Upon completing this lesson, you will be able to describe the major application acceleration
and optimization features and their benefits in the overall design. This includes being able to
meet these objectives:
Describe the architecture of the web application acceleration features
Describe the FlashForward feature of the ACE appliance
Explain the use of delta optimization and its benefits
Explain the use of smart redirect and its benefits
Explain the use of fast redirect and its benefits
Explain the use of FlashConnect and its benefits
Explain the use of just-in-time object acceleration and its benefits
Explain the use of adaptive dynamic cache and its benefits
Describe HTTP compression

This topic describes the architecture of the web application acceleration features.
CONTROL
PLANE
Serial Port
PCI-X
BUS
1 Gb Ethernet
1 Gb Ethernet
1 Gb Ethernet
DATA PLANE
1 Gb Ethernet
ACEAP v1.01-4
The figure shows a diagram of web application acceleration (WAA) architecture.
310
Process and thread management:
Request scheduling
HTTP header parsing
Buffer management
10,000 concurrent client requests.
Cisco Web Application Acceleration features:
Request and response handling
Content manipulation
6 GB memory of which 2 GB are for cache in TMP files.
WAA connections are always proxied.
WAA talks to MP to obtain PIDs for any object.
WAA match patterns should be a subset of the load-balance match patterns.
AVS Traffic Flow

Control Plane Components
IF: 127.1.0.128
S2
C2
Client
C1
Vip1
Vip2
Vipn
Vip Internal (127.1.0.193)

Vip1
Vip2
Vipn
IF
S1
Rserver
IF: 127.1.0.192
IF
DP Components
Private HTTP headers are exchanged.

Persistence rebalance is used.
ACEAP v1.01-5
Following are the basics of the static (executed during initiating period) and dynamic elements
of the hidden configuration:
Static:
Internal interface
Access control list (ACL) to permit traffic from control plane to data plane on this interface
VIP plus Layer 7 parameter maps to parse the SAM private header
HTTP parameter map to enable persistence-rebalance
RSERVER, RRSERVER to represent WAA
Dynamic:
Any Layer 4 policy configured by the user is pasted on the internal IF.
When an L7 Optimize policy is configured, a class map with the highest priority is added to
it with match patterns that must go to AVS.
SAM private header insertion.
311
FlashForward
This topic describes the FlashForward feature of the ACE appliance.
Normal Browser Behavior
HTTP 200 OK
GET Index.html
HTTP 200 OK
GET Foo.gif
HTTP 200 OK
HTTP 200 OK
GET Foo.js
GET Foo.jpg
GET Foo.css
HTTP 200 OK
GET bar.gif
HTTP 200 OK
HTTP 200 OK
GET bar.js
ACEAP v1.01-7
When a user agent, usually a web browser, retrieves a web page (an HTML object page), many
other objects might need to be retrieved as well. After the initial HTTP GET, six other HTTP
GET requests are issued by the user agent in this example. The requests can be individual TCP
connections or part of a persistent, pipelined HTTP request. Each time the server sends an
HTTP response to a user agent GET, the server sends the requested object with an HTTP
response code of 200 OK and optional Cache-control: timeout value indicating the freshness of
the object.
312
Normal Browser Behavior: Return Visit
HTTP 200 OK
IMS Index.html
304 Not Modified
IMS Foo.gif
304 Not Modified

304 Not Modified
IMS Foo.js
IMS Foo.jpg
IMS Foo.css
304 Not Modified

IMS bar.gif
HTTP 200 OK
HTTP 200 OK
IMS bar.js
ACEAP v1.01-8
On a return visit to a site, the browser sends an HTTP GET request to the server, but if the page
was cached, the user agent sends an HTTP If-Modified-Since request to the server. If the object
is still fresh, as determined by the server, the server sends a 304 Not Modified message. If the
server determines that the object is stale, the server sends the new fresh object with a 200 OK
message and an optional Cache-control: timeout value.
This process of verifying the freshness of an object is carried out for each object referenced on
the HTML object page. For pages with a large number of objects, verifying the freshness of
each object can create significant overhead, even if the object is cached.
313
FlashForward: Priming the Cache
1. Client requests HTML

page.
2. ACE forwards request to

server.
GET Index.html
GET Index.html
HTTP 200 OK
HTTP 200 OK
Unmodified
HTML
page
4. ACE passes unaltered HTML

object page to client.
Unmodified
HTML
page
3. Server responds to request

with HTML object page.
ACEAP v1.01-9
1. The first user to visit a site with FlashForward enabled sends a request normally.
2. The ACE proxies the request to the server.
3. The server responds to the ACE with the HTML object page.
4. The ACE parses the page looking for cached FlashForward objects. Because this is the first
visitor, there are no cached objects. The ACE passes the HTML page unaltered to the client
user agent.
314
FlashForward: Priming the Cache (Cont.)
1. Client requests altered objects

from HTML object page.
GET
GET
GET
GET
GET
GET
2. ACE proxies the request and

forwards it to server.
Foo.gif
Foo.js
Foo.jpg
Foo.css
bar.gif
bar.js
GET
GET
GET
GET
GET
GET
Foo.gif
Foo.js
Foo.jpg
Foo.css
bar.gif
bar.js
200 OK Foo.gif
200 OK Foo.js
200 OK Foo.jpg
200 OK Foo.css
200 OK bar.gif
200 OK bar.js
4. ACE checks whether items can be

FlashForwarded; if true, they are cached.
ACE forwards objects unaltered to client.
200 OK Foo.gif
200 OK Foo.js
200 OK Foo.jpg
200 OK Foo.css
200 OK bar.gif
200 OK bar.js
3. Server responds to request

with objects.
ACEAP v1.01-10
1. The first user sends an HTTP GET to the site for all the objects from the HTML object
page.
2. The ACE proxies the request to the server.
3. The server responds to the ACE with the objects.
4. The ACE caches the cacheable objects (defined by the ACE configuration). Because this is
still the first visitor, the ACE passes the objects unaltered to the client user agent.
315
FlashForward: First Visit After Priming Cache
Client requests HTML page.
ACE forwards request to server.
GET Index.html
GET Index.html
HTTP 200 OK
HTTP 200 OK
Unmodified
HTML
page
Modified
HTML
page
ACE checks whether objects referenced are

allowed to be FF and whether they are in the
cache; if so, FFobject names are altered in the
HTML object page and the modified HTML page
is sent to the client.
Server responds to request with

HTML object page.
ACEAP v1.01-11
On the first visit:
The client requests the URL.
The ACE proxies the request to the origin server.
The server responds to the request normally, and the ACE intercepts the response.
The ACE responds with the HTML container page, which has been modified to reference
the new objects references. If delta optimization is also configured, the HTML container
page is a dynamic HTML page with an embedded JavaScript:
Embedded objects that are referenced in HTML container pages are:
The default is over 20 years.
The object name is appended with an MD5 hash based on the object as well as a
version number:
316
Served with expiration date in the future:
For example, Foo.jpg could become

Foo_CISCO_AAC_FLASHFORWARD_vtmmi14xg2fvmwheicuk0ty1xd_V01.
jpg.
The client receives the response and parses the HTML container page for objects to
request.
The client requests the objects from the server.
The ACE intercepts the request and forwards the transformed request objects (minus
FlashForward alterations) from the server, according to the refresh rate configuration.
Assuming that the object in the ACE cache is fresh, the ACE responds to the client with the
requested object.
FlashForward: First Visit after Priming Cache

(Cont.)
Client requests altered objects

from HTML object page.
ACE proxies the request, checks cache for FF

objects, and sends IMS message for objects to server
to verify freshness.
GET Cisco_FF_MD5_Foo.gif
GET Cisco_FF_MD5_Foo.js
GET Cisco_FF_MD5_Foo.jpg
GET Cisco_FF_MD5_Foo.css
GET Cisco_FF_MD5_bar.gif
GET Cisco_FF_MD5_bar.js
200 OK Cisco_FF_MD5_Foo.gif
200 OK Cisco_FF_MD5_Foo.js
200 OK Cisco_FF_MD5_Foo.jpg
200 OK Cisco_FF_MD5_Foo.css
200 OK Cisco_FF_MD5_bar.gif
200 OK Cisco_FF_MD5_bar.js
ACE checks whether items can be

FlashForwarded; if true, they are cached.
ACE forwards objects unaltered to client.
IMS Foo.gif
IMS Foo.js
IMS Foo.jpg
IMS Foo.css
IMS bar.gif
IMS bar.js
304 NM Foo.gif
304 NM Foo.js
304 NM Foo.jpg
304 NM Foo.css
200 OK bar.gif
200 OK bar.js

objects.
ACEAP v1.01-12
The figure shows browser behavior with FlashForward for the first visit after the cache is
primed.
317
FlashForward: Second Visit
Client requests HTML page.
ACE forwards request to server.
GET Index.html
GET Index.html
HTTP 200 OK
Unmodified
HTML
page

HTML object page.
ACEAP v1.01-13
On subsequent visits:
318
The client requests the URL.
The ACE proxies the request origin server.
The server creates and delivers the HTML page to the ACE.
The ACE parses the HTML for all the references to embedded objects and checks whether
the objects are cached locally on the ACE. If the object is cached locally, the ACE issues
an HTTP IMS request to the server:
If the server responds with an HTTP 304 Not Modified message, the ACE uses its
previously created object reference in the HTML container document.
If the server responds with an HTTP 200 OK message (and the modified object), the
ACE caches the object, renames it, changes the expiration date, and adds the new
object name to the HTML container document.
The ACE sends the modified server HTML container document to the client.
The client parses the HTML container document for objects:
Any previously cached FlashForward objects that are referenced do not have an
HTTP GET issued because they have a long expiration date.
Any new FlashForward objects that are referenced are fetched from the ACE.
FlashForward: Second Visit (Cont.)
Object reference:<img
src=/images/Foo.jpg>
Unmodified
HTML
page
IMS Foo.gif
IMS Foo.js
IMS Foo.jpg
IMS Foo.css
IMS bar.gif
IMS bar.js
HTTP 200 OK
Index.html
Transformed object
reference: <img src=
/images/Foo_CISCO
_AAC_FLASHFORWAR
D_vtmmi14xg2fvmlkxsx
uk0ty1xd_V02.jpg>
ACE checks whether objects are FF-able

and cached. If so, ACE verifies freshness
of objects with IMS messages to server.
Modified
HTML
page
304 NM Foo.gif
304 NM Foo.js
200 OK Foo.jpg
304 NM Foo.css
304 NM bar.gif
304 NM bar.js
ACEAP v1.01-14
The figure shows browser behavior with FlashForward for subsequent visits.
319
FlashForward: Second Visit (Cont.)
Client requests altered object

from Modified HTML object page.
ACE responds to request with

FlashForward object from cache.
GET Foo_CISCO_AAC_FLASH
FORWARD_vtmmi14xg2fvmlkx
sxuk0ty1xd_V02..jpg
200 OK Foo_CISCO_AAC_
FLASHFORWARD_vtmmi14xg
2fvmlkxsxuk0ty1xd_V02..jpg
Client reassembles page from new

received object and cached objects on
client user agent.
ACEAP v1.01-15
The figure shows browser behavior with FlashForward for subsequent visits.
320
Define FlashForward Optimization

ACE
class-map type http loadbalance match-all CM-FF

match http url .*
action-list type optimization http ACTION-LIST-1
flashforward
parameter-map type optimization http ParMap-FF
policy-map type optimization http first-match PolMap-Opt
class CM-FF
action ACTION-LIST-1 parameter ParMap-FF
ACEAP v1.01-16
There are two elements to configure in the FlashForward optimization feature. The figure
shows configuring the FlashForward for a VIP to be associated with a Layer 3 and 4 class map.
The elements of the FlashForward configurations are:
Class map: This looks at the Layer 7 elements to classify the traffic.
Action list: This defines which feature to use. (If you are including delta optimization, that
is included here as well.)
Parameter map: This is required and must match statements associated with it.
Policy map: This is similar to a Layer 7 load-balancing or inspection policy map.
321
Define FlashForwardObject Optimization

ACE
class-map type http loadbalance match-all CM-FFObject

match http url .*gif
match http url .*jpg
flashforward-object
parameter-map type optimization http ParMap-FFObject
cache ttl max 60
cache ttl min 0
class CM-FFObject
action ACTION-LIST-2 parameter ParMap-FFObject
ACEAP v1.01-17
This is the second of two elements to configure in the FlashForward optimization feature. The
figure shows configuring the FlashForwardObject, which defines which objects are eligible for
FF optimization. The elements of the FlashForwardObject configurations are:
Class map: This classifies the object types that qualify for flashforward.
Parameter map: This is required and must match statements associated with it.
Action list: This defines which feature to use. (If you are including delta optimization, that
is included here as well.)
Policy map: This is similar to a Layer 7 load-balancing policy map.
The ACE 4710 appliance Device Manager easy optimization configuration uses the following
objects by default in the class map:
match
match
match
match
match
match
match
match
match
match
match
match
match
match
match
match
match
322
http
http
http
http
http
http
http
http
http
http
http
http
http
http
http
http
http
url
url
url
url
url
url
url
url
url
url
url
url
url
url
url
url
url
.*jpg
.*jpeg
.*jpe
.*png
.*vbs
.*xsl
.*xml
.*pdf
.*swf
.*gif
.*css
.*js
.*class
.*jar
.*cab
.*txt
.*ps
FlashForward Config
class-map type http loadbalance match-all CM-FF
match http url .*
class-map type http loadbalance match-all CM-FFObject
match http url .*gif
match http url .*jpg
flashforward
flashforward-object
parameter-map type optimization http ParMap-FF
parameter-map type optimization http ParMap-FFObject
cache ttl max 60
cache ttl min 0
class CM-FF
action ACTION-LIST-1 parameter ParMap-FF
class CM-FFObject
action ACTION-LIST-2 parameter ParMap-FFObject
class VIP-170
optimize http policy PolMap-Opt
ACEAP v1.01-18
The figure shows the complete FlashForward configuration.

An embedded object can be FlashForwarded if the following conditions are met:
Container page referencing the embedded object must match an application class that
includes OptimizationPolicy FlashForward.
Reference to an embedded object must match an application class with OptimizationPolicy

FlashForwardObject.
Embedded object must not be referenced in a JavaScript.
Embedded object must have been previously requested and currently present in the AVS
cache.
Embedded object must not have been explicitly marked noncacheable by the original
server. The following directives allow control over caching headers sent by client or server:
RequestCachePolicy, ResponseCachePolicy, RequestHeader, and ResponseHeader.
Reference to an embedded object must not change with each request of the container page.
323
Delta Optimization
This topic explains the use of delta optimization and its benefits.
Delta Optimization Methodology

1
1st Client Request
Server Response
ACE Response (j-script) 70KB
ACEAP v1.01-20
The figure shows delta optimization methodology:

1. The client request is proxied by the ACE to the server, and the response is intercepted by
the ACE.
2. The ACE responds with the dynamic HTML container page in a JavaScript (in this
example, the original file is 70 KB).
Delta optimization is applied to dynamic HTML (noncacheable) documents. The delta
optimization feature allows the ACE to cache dynamically created content on the client browser
and then, on subsequent visits, to send the differences using dynamic HTML:
324
Dynamically generated pages are not cacheable.
Delta optimization calculates and sends the difference between two visits to an dynamic
HTML page.
Delta optimization creates a JavaScript base file that contains the entire first visit to the
page.
Delta optimization uses a JavaScript on the delta page to reassemble the entire page.
Benefits of delta optimization include:
Reduced bandwidth usage
Reduced page download times
Compatibility with other optimizations
Delta Optimization Requirements
Browsers that are supported must be configurable.
Browsers must support cookies, JavaScript, and caching (automatically checked).
HTML must use only single-byte character sets.
Certain HTML elements are not condensable:
IFRAME
SCRIPT
OBJECT
325
Delta Optimization Methodology (Cont.)

3
2nd Client Request
Server Response
ACE Response (delta j-script) 2KB
ACEAP v1.01-21
The figure shows delta optimization methodology (continued):

1. If the client requests the page again, the request is again proxied to the server by the ACE,
but this time when the ACE receives the response it compares it with the original response
and builds a delta of the two.
2. The ACE creates a JavaScript from the delta and sends that to the client to execute and
reassemble the HTML container document (in this example, the delta file is only 2 KB).
Delta Optimization Base Files
Two modes:
DeltaOptimize
PerUserDeltaOptimize
Delta is generated against a base file, which is shared among all users:
Can contain information that all users should not see
Use PerUserDeltaOptimize to create individual base files for each user
Cacheable for 30 days
Compressible with certain browser types
Delta Optimization Canonicalization
Base files are created based on the URL without query parameters:
The same URL can generate different pages based on query parameters or cookies.
Several different URLs might generate pages that are similar enough to warrant a
single base file.
Use CanonicalUrl to create base files based on URL query parameters:
326
This reduces the overall size of the deltas and increases performance.
Troubleshooting Delta Optimization

Internet Explorer does not handle certain compressed objects,
especially JavaScript.
Works only on pages up to 250 k.
Sometimes Internet Explorer is confused when JavaScript is delta
optimized:
Use ExcludeScripts to exclude the JavaScript on the delta page
Sometimes non-ASCII characters cause delta optimization to fail:

Use ExcludeNonAscii to exclude any non-ASCII characters from delta
UTF-8 character detection is on by default. Allows delta

optimization for a page with five or fewer UTF-8 characters.
ACEAP v1.01-22
The figure describes some common delta optimization problems.

Delta optimization is applied dynamically to pages. Not all content is delta encoded. The
following conditions must be met for the page to be successfully delta optimized:
Clients browser must match those listed in useragent.conf.
Clients browser must support JavaScript.
Clients browser must send the FGNCDN cookie set to the JavaScript.
Delta optimize must be turned on at the global level in fgn.conf with the DeltaOptimize
On setting.
URL must match an application class that has OptimizationPolicy that includes
DeltaOptimize.
Page must be larger than 1024 bytes and be adjustable using MinCondensablePage.
Page must be smaller than 250,000 bytes and be adjustable using MaxCondensablePage.
327
The following conditions must also be met for the page to be successfully delta optimized:
328
Page must not return a ContentType listed in mimetypes.conf with the directive
NoDeltaOptimizeMimeType.
Page should be dynamic html and is not cacheable. Set DeltaOptimizeCacheableContent

On to allow delta optimization of static content.
Page must use single-byte character set (ISO-8859-1).
Page should contain fewer than five UTF-8 characters. This is configurable using
UTF8Detection and UTF8Threshold.
Size of the delta must not exceed 50 percent of the base file size. This is tunable by
adjusting RebaseDeltaPercent.
Client must be able to retrieve the correct base file from the AVS.
In environments with multiple AVSs, some type of persistence method must ensure that the
delta request and the base file request are sent to the same AVS.
Smart Redirect
This topic explains the use of smart redirect and its benefits.
Smart Redirect
ACE Response
Server Response
<HTML>
<META HTTP-EQUIV="Refresh"
CONTENT="5;URL=http://www.cisco.com">
</HEAD>
<BODY>
This will be redirected to another page.
</HTML>
HTTP/1.1 302 Found

Location: http://www.cisco.com
ACEAP v1.01-24
Some applications automatically redirect client browsers from one page to another using
HTML meta tags. HTML meta tag-based page redirection can cause poor download times
because the browser issues IMS for each embedded object on the redirected page.
Smart redirect enables the ACE to automatically and transparently convert HTML meta tagbased redirections into more-efficient HTTP header-based redirections.
Features of smart redirect:
Converts meta refresh to HTTP header redirect
Parses for the meta refresh tag
Identify by IMS requests for FlashForward objects
329
Fast Redirect
This topic explains the use of fast redirect and its benefits.
Fast Redirect
1
2
302 Response
Client Request
200 Response
Fast Redirect Request
200 Response
ACEAP v1.01-26
Fast redirect intercepts HTTP 302 responses from the origin server and makes a second request
on behalf of the client for the redirect URL, fetches it, and sends it to the client. This applies
only to redirects within the same domain.
Steps of a fast redirect:
1. Client requests URL.
2. Server responds with HTTP 302 Redirect to a server in the same domain as the origin
server.
3. ACE fast redirects a request to the server in the origin servers response.
4. The redirection server responds to the ACE.
5. The ACE forwards the content from the redirection server seamlessly to the client.
330
FlashConnect
This topic explains the use of FlashConnect and its benefits.
FlashConnect
ACE Response
Server Response
<html>
<img src="img1.jpg">
</html>
<html>
<img src="http://fgn00.flashconnect.myhost/img1.jpg">
</html>
ACEAP v1.01-28
FlashConnect dynamically renames embedded objects by adding a prefix and changing the
hostname, making the objects appear to reside on different hosts although they might all reside
on a single host. FlashConnect makes the browser open separate connections to the origin
server for each object, which increases the network performance because the objects are
retrieved in parallel, rather than serially.
FlashConnect:
Makes the browser believe that it is communicating with multiple web servers
Rewrites object references in pages
Renames objects (as a transparent proxy)
Does not work with SSL
331

This topic explains the use of just-in-time object acceleration and its benefits.

Client Request
Is the requested
object larger than
250K?
Or
Is this object
marked as expired
or noncacheable?
ACE Response
ACEAP v1.01-30
Just-in-time object acceleration is used to accelerate noncacheable embedded objects to

accelerate application response time.
Just-in-time object acceleration applies to either of the following conditions:
Dynamic HTML content that is larger than the maximum condensable page size (250 KB)
Content that is marked by the origin server as expired or not cacheable
Just-in-time object acceleration functions as follows:
The browser requests an object, and the ACE fetches it on behalf of the browser request.
The ACE constructs and inserts an entity tag (ETag) header by using an MD5 hash of the
content, and then it sends the object to the browser. The ETag is a request header that you
can use to identify different versions of the same object.
All subsequent requests from the browser include this ETag header, which the ACE
compares with a recomputed MD5 hash of the latest origin server content as follows:
If the content has not changed, the ACE returns a 304 (Not Modified) response and
no data
If the content has changed, the ACE retrieves the new content and resets the ETag.
It is recommended that you use compression with just-in-time object acceleration.
332

This topic explains the use of adaptive dynamic cache and its benefits.

Cache dynamically generates noncacheable pages.
Time to Live can be based on server load.
Works in conjunction with other optimizations.
Identifies pages with larger server latency.
Must decide which parameters uniquely identify page
and define with CacheParameter.
Must decide valid shelf life.
ACEAP v1.01-32
Adaptive dynamic caching allows the ACE to answer requests for dynamic or personalized
information, reducing the burden on servers and databases. Adaptive dynamic caching enables
the ACE to cache dynamic content such as Active Server Pages (ASP) scripts.
Adaptive dynamic caching features include:
Cache parameterization: A response can be differentiated by more than the URL and its
query parameters. Cookie values, HTTP header values, and the HTTP method used can
also be used as parameters. Cache parameterization can be applied to both static and
dynamic caching.
Expanded expiration rules: Time to Live of cached content can be based on the server
load; for example, increasing the TTL when the server load increases.
Delta cache: Stores the delta content in a cache (a memory-only object) when the original
HTML content is in the dynamic cache and a rebase has not occurred.
Adaptive dynamic caching can be configured for use with multiple or single users.
333
Compression Overview
This topic describes HTTP compression.
HTTP Performance over a WAN
ACEAP v1.01-34
The figure shows HTTP performance over a WAN.
334
HTTP Compression
HTTP standards-based
Compression algorithms for deflate and gzip
ACEAP v1.01-35
Request Processing
Parse for the following headers:
Accept-Encoding (includes deflate and gzip)
User-Agent (browser software)
Determine compression support:
Compression method present in Accept-Encoding
Browser supported
Modify:
Remove the Accept Encoding: xxx header
Insert Accept Encoding: Identity header
Response Processing
Parse for the following headers:
Content-Length (length of returned content)
Content-Type (type of resource)
Determine compression support:
Length over minimum
MIME type allowed
No Cache-Control: No-Transform header
Compress response:
Remove Content-Length header
Add Transfer-Encoding Chunked header
335
Enabling Compression
ACE

class class-default
compress default-method gzip
class external-vip
ACEAP v1.01-36
The figure shows how to enable compression.
336
Compression Parameters
ACE
parameter-map type http COMPRESSION_PARMS

compress mimetype text/*
compress minimum-size 512
class class-default
compress default-method gzip
class external-vip
appl-parameter http advanced-options COMPRESSION_PARMS
ACEAP v1.01-37
The figure shows compression parameters.
337
Summary
Summary
WAA features support up to 10,000 concurrent client requests.
FlashForward provides decreased page download time, decreased network
congestion, and decreased number of requests to the original server.
Delta optimization calculates and sends the difference between two visits to a
dynamic HTML page. It creates a JavaScript base file, which contains the entire
first visit to the page, and uses a JavaScript on the delta page to reassemble the
entire page.
Smart redirect allows the ACE to convert HTML redirects to HTTP 302 redirects.
Fast redirect intercepts HTTP 302 responses from the origin server and sends the
redirect URL to the client as a 200 OK response.
FlashConnect multiplexes HTTP responses, helping to circumvent TCP limitations.
Just-in-time object acceleration is used when objects are too large to use delta
optimization or are noncacheable.
Adaptive Dynamic Cache protects overutilized servers by dynamically adapting the
age of noncacheable objects
HTTP compression is HTTP standards based. Compression algorithms include
deflate and zip.
338
ACEAP v1.01-38
Lesson 11
High Availability
Overview
In this lesson, you will learn how to describe the high-availability features of the ACE
appliance, which are used to provide reliable application networking services.
Objectives
Upon completing this lesson, you will be able to describe the high-availability features of the
ACE appliance, which are used to provide reliable application networking services. This
includes being able to meet these objectives:
Describe the ACE redundancy model
Explain object tracking
Explain the failover recovery process
Explain state replication between ACE appliances
Describe the information used to create fault-tolerant configurations
Describe the information used to monitor fault-tolerant configurations
Redundancy
This topic describes the ACE redundancy model.
Redundancy Model
ACE-1
Active
Active
Standby Standby
FT VLAN
Standby Standby Active
D
Active
ACE-2
FT
FT
FT
FT
group 1 group 2 group 3 group 4
Redundant pair of ACE appliances.

1 context per fault-tolerant group on each appliance.
1 context active in an FT group active.
Active contexts can be split between ACE appliances.
ACEAP v1.01-4
The Cisco 4710 Application Control Engine (ACE) appliance provides redundancy through a
pair of ACE appliances. A fault-tolerant group is created for a pair of contexts, one on each
appliance. Within the pair of contexts, one context is active and the other context is on standby.
The ACE appliance hosting the active context can be controlled on a per-context basis.
340
Fault-Tolerant VLAN
ACE-1
Active
Active
Standby Standby
FT VLAN
D
Active
ACE-2
FT
FT
FT
FT
Designated fault-tolerant VLAN between ACE pair

Used for redundancy-related traffic
Configured in Admin context
ACEAP v1.01-5
The fault-tolerant VLAN is configured in the Admin context and is used for redundancy control
traffic between the ACE contexts. This traffic includes heartbeats, configuration, and state
synchronization.
High Availability
341
Query VLAN
ACE-1
Active
Active
Standby Standby
FT VLAN
D
Active
ACE-2
FT
FT
FT
FT
Data VLAN.
Standby ACE pings the active ACE.
Successful ping transitions to STANDBY_COLD.
ACEAP v1.01-6
One of the data VLANs can also be designated as a query VLAN. The standby ACE appliance
monitors the fault-tolerant VLAN for heartbeats. Loss of these heartbeats signals the possibility
that the active ACE appliance has failed. If a query VLAN has been configured, the standby
ACE appliance verifies the failure of the primary ACE appliance by sending a ping on the
query VLAN. If this ping fails, the standby ACE appliance transitions to active. If the ping
succeeds, the standby ACE appliance concludes that the primary ACE appliance is still active
and that the fault-tolerant VLAN has failed.
342
Configuration Synchronization
ACE-1
Active
Active
Standby Standby
FT VLAN
D
Active
ACE-2
FT
FT
FT
FT
Bulk sync of the entire configuration at startup

Configuration changes disabled on standby
Incremental sync of configuration changes
Sync both running-config and startup-config
Configurable per context
ACEAP v1.01-7
Configuration synchronization allows the running or startup configuration to be synchronized

automatically between the redundant ACE appliances. Bulk sync is used to send the entire
configuration from the active to the standby appliance when synchronization is first activated or
when the appliance first boots. After a bulk sync has been successfully completed,
configuration changes are disabled on the standby appliance. Incremental sync of configuration
changes propagates any configuration changes made on the active ACE appliance to the
configuration of the standby appliance.
Manually Synced Files:
Script files
SSL files (keys and certificates)
Licenses
High Availability
343
Object Tracking
This topic explains object tracking.
Object Tracking
Operational state of external resources can be tracked:
State of critical interfaces
Health of an external host
Failure of tracked resources causes active to

RELINQUISH control.
HSRP
Host Group
Interface
Active
RELINQUISH
ACEAP v1.01-9
Object tracking gives the ACE appliance the ability to track network resources external to the
appliance. If a tracked resource fails, the active appliance can be configured to turn control over
to the standby ACE appliance. Thus the redundant ACE pair can optimize the assignment of
active processing functionality in response to external network events.
344
Interface Tracking
ft track interface vlan-example
track-interface vlan 204
peer track-interface vlan 204
priority 150
ft
peer priority 100
ACE:
Track
VLAN
ACEAP v1.01-10
Interface tracking monitors the state of a VLAN.

Note
You can not delete an interface if the ACE is using the interface for tracking. Also, you can
not configure the fault-tolerant VLAN for tracking.
High Availability
345
Host Tracking
ft track interface server
track-host 12.10.40.54
peer track-host 12.10.40.54
probe PINGER priority 15
peer probe PINGER priority 15
priority 150
peer priority 100
ACE:
track
Host
X
ACEAP v1.01-11
Host tracking uses health monitoring probes to verify the status of a server. Multiple probes can
be configured. Each probe is assigned a priority that is decremented from the appliance priority
if a probe fails.
346
Failover
This topic explains the failover recovery process.
Virtual MAC Addresses

ACE-1
Active
Active
Standby Standby
FT VLAN
D
Active
ACE-2
FT
FT
FT
FT
VMAC assigned to all floating IPs:
Alias IP addresses on Layer 3 interfaces
VIPs
VMAC based on fault-tolerant group ID.

VMACs only assigned if high availability configured.
Only active ACE responds to packets destined to VMAC.
Only active ACE responds to ARP requests for floating IPs.
ACEAP v1.01-13
Virtual MAC (VMAC) addresses are assigned to IP addresses that will be moved from one
ACE appliance to another in case of a failover. These IP addresses are often referred to as
floating IP addresses and consist of all alias IP addresses configured on Layer 3 interfaces, and
all VIPs. The VMAC assigned is based on the fault-tolerant group ID, which allows
redundancy support for VLANs that are shared among multiple contexts. VMACs are assigned
only if fault tolerance is configured.
The active ACE appliance responds to packets destined to a VMAC and answers Address
Resolution Protocol (ARP) requests for the floating IP addresses. The standby ACE blocks
packets destined to a VMAC and does not respond to ARP requests for the floating IP
addresses.
High Availability
347
Failover Actions
ACE-1
Active
Active
Standby Standby
FT VLAN
D
Active
ACE-2
FT
FT
FT
FT
New active ACE appliance:

Sends dummy multicast for every VLAN-VMAC pair
Sends gratuitous ARPs for alias and VIP addresses
Sends ARP request for gateway in bridged mode
ACEAP v1.01-14
A failover of an ACE context to the redundant ACE appliance might require that switches
attached to VLANs to which the ACE is connected move the MAC address to a different
interface. To expedite these changes, the ACE appliance takes several actions. A dummy
multicast is sent out on every VLAN on which a VMAC has been assigned. This multicast
packet uses the VMAC as the source MAC address. Gratuitous ARPs are generated for all
floating IP addresses. If the ACE appliance has interfaces in bridged mode, it also generates an
ARP request for the gateway IP address and bridges the ARP response.
348
State Replication
This topic explains state replication between ACE appliances.
Connection Replication
ACE-1
Active
Active
Standby Standby
FT VLAN
D
Active
ACE-2
FT
FT
FT
FT
Proxied connections not eligible.

NAT and load-balancing results contained in connection entries.
Standby creates connection entries.
Bulk and periodic sync.
One connection entry per replication packet.
Active entries flushed if object tracking causes a RELINQUISH.
ACEAP v1.01-16
Connection replication sends connection entries from the active ACE appliance to the standby
ACE appliance. Connection entries for proxied connections are not eligible for replication. No
special replication is necessary for NAT xlates or load-balancing state information because all
the required information can be derived from the connection entries. The standby ACE
appliance creates connection entries as it receives them via replication, giving it the full state
information needed to continue processing after a failover. Connection replication contains
both bulk and periodic replication processes, which both send one connection entry per
replication packet.
If an ACE appliance transitions from active to standby as a result of object tracking, it flushes
all its connection entries and allows the new active ACE appliance to bulk sync its connection
entry table back to the original appliance.
High Availability
349
Connection Replication Statistics

ACE-1
Active
Active
Standby Standby
FT VLAN
D
Active
ACE-2
FT
FT
FT
FT
show conn
show rserver
show serverfarm
ACEAP v1.01-17
The results of connection replication can also be seen on the standby appliance through the use
of the show conn, show rserver, and show serverfarm commands.
350
Sticky Replication
ACE-1
Active
Active
Standby Standby
FT VLAN
D
Active
ACE-2
FT
FT
FT
FT
Independent from connection replication

Enabled in the sticky group configuration
Bulk and periodic sync processes
Multiple sticky entries per replication packet
ACEAP v1.01-18
Replication of sticky database entries is handled by a separate process. Sticky database entries
are also synchronized with both bulk and periodic sync processes. Replication of sticky
database entries must be enabled in the sticky group configuration. Multiple sticky entries are
transmitted in each sticky replication packet.
High Availability
351
Fault-Tolerance Configuration
This topic describes the information used to create appliance and context fault-tolerant
configurations.
Configuring a Fault-Tolerant Interface

A
Active
ACE-1
FT VLAN
ACE-2
QUERY
VLAN
B
C
D
Active Standby Standby
A
B
C
FT
group 1
FT
group 2
D
Active
FT
FT
group 3 group 4
Fault -tolerant VLAN interface configuration:

ft interface vlan 100
ip address 192.168.12.1 255.255.255.0
peer ip address 192.168.12.15 255.255.255.0
no shutdown
Query VLAN interface configuration (optional):

query-interface vlan 99
ACEAP v1.01-20
Configuration of fault-tolerant and query VLAN interfaces is shown in the figure. This is
configured in the Admin context.
352
Configuring Peer Redundancy

A
Active
ACE-1
FT VLAN
QUERY
VLAN
ACE-2
B
C
D
A
B
C
FT
group 1
FT
group 2
D
Active
FT
FT
group 3 group 4
Fault-tolerant peer configuration:

ft peer 1
ft-interface vlan 100
heartbeat count 20
heartbeat interval 200
ACEAP v1.01-21
The ft peer is associated with the peer via FT VLAN. This is configured in the Admin context.
High Availability
353
Configuring Fault-Tolerant Groups

A
Active
ACE-1
FT VLAN
ACE-2
QUERY
VLAN
B
C
D
A
B
C
FT
group 1
FT
group 2
D
Active
FT
FT
group 3 group 4
Fault-tolerant group configuration:

ft group 1
associate-context SOME-CONTEXT
peer 1
priority 100
peer priority 50
preempt
inservice
ACEAP v1.01-22
There can be up to 251 fault-tolerant groups, one for every context available. Each group can
have a maximum of two member contexts (one active context and one standby context). The
higher-priority peer is active. When modifying an active fault-tolerant group, no inservice the
group first.
This must be configured for all contexts that require fault tolerance and can be configured in
the Admin context or in each individual context.
354
Fault-Tolerant Configuration Synchronization

A
Active
ACE-1
FT VLAN
QUERY
VLAN
ACE-2
B
C
D
A
B
C
FT
group 1
FT
group 2
D
Active
FT
FT
group 3 group 4
Fault-tolerant config auto-sync:

ft auto-sync running-config
ft auto-sync startup-config
Fault-tolerant config auto-sync verification:

ACE/Admin# sh context Admin
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
ACEAP v1.01-23
Configuration of fault-tolerant config sync is shown in the figure. This can be configured in all
contexts.
High Availability
355
Forcing a Failover
A
Active
ACE-1
FT VLAN
ACE-2
QUERY
VLAN
B
C
D
A
B
C
FT
group 1
FT
group 2
D
Active
FT
FT
group 3 group 4
Failing over fault-tolerant contexts:

ft switchcover [group-id] [force]
ACEAP v1.01-24
The syntax required to force a switchover between active and standby contexts is shown in the
figure. This is useful for maintenance windows or to verify that standby context is working
correctly. Before issuing this command for a group, no preempt must be added to the faulttolerant group config if preempt is currently configured. This command can be issued from the
exec mode of the Admin context or from the exec mode of other contexts (in individual
contexts, the group-id argument is not needed; you can only failover that context).
356
Fault-Tolerant Sticky Replication Configuration

A
Active
ACE-1
FT VLAN
ACE-2
QUERY
VLAN
B
C
D
A
B
C
FT
group 1
FT
group 2
D
Active
FT
FT
group 3 group 4
Fault-tolerant sticky configuration:

sticky ip-netmask 255.255.255.255 address source EXT-STICKY
replicate sticky
ACEAP v1.01-25
Configuration of fault-tolerant sticky is shown in the figure. This is an additional configuration

option in the IP address stickiness configuration. This can be configured in all contexts.
High Availability
357
Displaying Fault-Tolerance Information

This topic describes the information used to monitor fault-tolerant configurations.
Show Fault-Tolerant Peer

ACE/Admin# sh ft peer detail
Peer Id
State
Maintenance mode
FT Vlan
My IP Addr
Peer IP Addr
Query Vlan
Peer Query IP Addr
Heartbeat Interval
Heartbeat Count
Tx Packets
Tx Bytes
Rx Packets
Rx Bytes
Rx Error Bytes
Tx Keepalive Packets
Rx Keepalive Packets
SRG Compatibility
License Compatibility
FT Groups
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
1
FSM_PEER_STATE_COMPATIBLE
MAINT_MODE_OFF
60
12.1.1.1
12.1.1.2
Not Configured
0.0.0.0
100
10
13
2838
9
1644
0
0
0
COMPATIBLE
COMPATIBLE
1
ACEAP v1.01-27
The show ftp peer detail command is used to display information detailing the state of a faulttolerant peer.
358
Show Fault-Tolerant Group

ACE/Admin# sh ft group detail
FT Group
: 1
Configured Status
: in-service
Maintenance mode
: MAINT_MODE_OFF
My State
: FSM_FT_STATE_ACTIVE
My Config Priority
: 120
My Net Priority
: 120
My Preempt
: Enabled
Peer State
: FSM_FT_STATE_STANDBY_HOT
Peer Config Priority
: 50
Peer Net Priority
: 50
Peer Preempt
: Enabled
Peer Id
: 1
Last State Change time
: Thu Feb
No. of Contexts
: 1
Context Name
: Admin
Context Id
: 0
2 06:38:13 2006
switch/Admin#
ACEAP v1.01-28
The show ft group detail command displays detailed information about a fault-tolerant group.
Of particular interest are the config and net priority entries. The config priority is the appliance
priority that was configured, and the net priority reflects any adjustments to the appliance
priority as a result of object tracking. Priorities for this appliance and the fault-tolerant peer are
shown in the figure.
High Availability
359
Show Fault-Tolerant Stats

ACE/Admin# show ft stats
HA Heartbeat Statistics
-----------------------Number of Heartbeats Sent
: 431
Number of Heartbeats Received
: 435
Number of Heartbeats Missed
: 0
Number of Unidirectional HB's Received
: 5
Number of HB Timeout Mismatches
: 0
Num of Peer Up Events Sent
: 1
Num of Peer Down Events Sent
: 0
ACEAP v1.01-29
The show ft stats command displays statistics reflecting the handling of heartbeats.
360
Show Fault-Tolerant Track

ACE/Admin# sh ft track detail
FT Group
: 1
Status
: in-service
Maintenance mode
: MAINT_MODE_OFF
My State
My Config Priority
: 120
My Net Priority
: 120
My Preempt
: Enabled
Context Name
: Admin
Context Id
: 0
Track type
: TRACK_INTF
Vlan Id
: 40
State
: TRACK_UP
Priority
: 50
Transitions
: 1
ACEAP v1.01-30
The show ft track detail command is used to display the detail status of an object tracking
entry. In the figure you see object tracking details for VLAN 40, which is currently active.
High Availability
361
Show Fault-Tolerant Track (Cont.)

ACE/Admin# show ft track detail
FT Group
: 1
Status
: in-service
Maintenance mode
: MAINT_MODE_OFF
My State
My Config Priority
: 120
My Net Priority
: 70
My Preempt
: Enabled
Context Name
: Admin
Context Id
: 0
Track type
: TRACK_INTF
Vlan Id
: 40
State
: TRACK_DOWN
Priority
: 50
Transitions
: 2
ACEAP v1.01-31
The results of VLAN 40 failing can be seen in the figure in the show ft track detail output.
Notice that the interface is listed as down and that the net priority has been changed
accordingly.
362
Summary
Summary
ACE redundant pairs can be active or standby on a per-context
basis.
Object tracking allows active functions to be moved to a standby
ACE appliance in response to other network events.
The failover process followed by the ACE allows an ACE failure to
be transparent to the rest of the network.
State information is replicated between a pair of redundant ACEs.
Fault-tolerant configurations can be applied to the appliance, to
individual contexts, and to sticky sessions
Fault-tolerant state information can be displayed with show
commands.
ACEAP v1.01-32
High Availability
363
364
Lesson 12

Overview
In this lesson, you will learn how to describe a methodology used to design and configure
multiple ACE features.
Objectives
Upon completing this lesson, you will be able to describe a methodology used to design and
configure multiple ACE features. This includes being able to meet these objectives:
Describe the process of identifying features needed to fulfill network requirements
Explain the process of designing a multiple-context implementation
Explain the process of designing a multifeature ACE implementation
Describe the configuration of multiple integrated features

This topic describes the process of identifying features needed to fulfill network requirements.

Traffic flows needing LB, SSL, or
security processing
Management granularity
Router
IP/VLAN network topology

ACE
Servers
ACEAP v1.01-4
Design of an ACE-based network solution starts with an analysis of the processing that is
required of the Cisco 4710 Application Control Engine (ACE) appliance. Of specific
importance are the traffic processing requirements, the management requirements, and the
related network topology.
366
Sample Network
Internet
Servers
Users
Web and file servers:

HTTP, HTTPS, FTP.
All have the same content.
Load balancing, SSL offload, FTP security (no delete).
Mail server:
SMTP from Internet
POP and SMTP from users
ACEAP v1.01-5
The figure shows the process used to design an ACE-based solution. The network is attached to
the Internet with a perimeter firewall. Behind this firewall is a router to which two LAN
segments are attached, one for servers and one for corporate personnel.
The company using this network has a pair of identical servers that are to be deployed in
support of an e-commerce site. This site allows users to browse a catalog and place electronic
orders. FTP is also used on each of these servers to allow customers to upload sample files and
to download support files. Security is required on the FTP server to ensure that FTP clients can
not delete files. A mail server is also present, which is both the Post Office Protocol (POP) mail
server for incoming mail, and the outgoing Simple Mail Transfer Protocol (SMTP) server.
367
Document Flows
Internet
Servers
Users
Client
Server
Protocols / Processing
HTTP LB
Internet or internal
users
Web/file servers
HTTPS SSL offload, LB

FTP LB, no delete
Internet mail
servers
Mail server
SMTP
Mail server
Internet mail
servers
SMTP
Internal users
Mail server
Server admin
Servers
POP, SMTP
Telnet, HTTP, FTP, SSH, RDP, SNMP, X
ACEAP v1.01-6
The network analysis begins with identifying the traffic flows that require processing by the
ACE appliance. The figure shows the client and server endpoints for each type of flow. For
each pair of endpoints, the figure shows the protocols to be used and the ACE processing that
should be applied. The network diagram shows the paths of the flows listed.
368
Management Access Needed

Internet
Servers
Users
Manager
Resource
Network admins
ACE
Configure/monitor all functions
Server admins
Web/file servers
Remove from/return to service
Server admins
VIPs
Monitor VIP status
Helpdesk
VIPs
Monitor VIP status
Function
ACEAP v1.01-7
The figure shows management requirements including the user group performing management
functions, the resource being managed, and the management functions that need to be
permitted.
369
IP/VLAN Network Topology

VLAN 10
VLAN 5
Internet
Servers
VLAN 20
Users
VLAN
IP
192.168.1.0/24
10
10.0.1.0/24
Servers Default gateway is 10.0.1.1
10.0.2.0/24
IT Default gateway is 10.0.2.1
10.0.3.0/24
Users Default gateway is 10.0.3.1
20
Segment
Router Firewall
ACEAP v1.01-8
The topology of the network that connects clients to the servers for which network services are
provided must be documented at Layer 2 and Layer 3. This is done by documenting all the
VLANs and IP subnets involved.
370

This topic explains the process of designing a multiple-context implementation.

Always use at least one context in
addition to Admin
Identify network segments where
multiple flows transit
Allocate contexts to topology
points with common functional,
management, resource, and
redundancy requirements
Split contexts for ease of
configuration
Router
ACE
Servers
Design topology changes

ACEAP v1.01-10
The process of designing an ACE-based solution includes determining the number of ACE
contexts to use. After the number of contexts has been determined, you can design topological
changes to the network. Some guidelines to consider in determining the number of ACE
contexts include:
Always use at least one non-Admin context for functional configuration. This allows a
second functional context to be added as needed, without the need to move production
configuration from Admin to another context.
Identify the network segments where multiple flows to be processed are in transit.
Contexts can be effectively allocated to points in the network topology where the flows in
transit have common processing and management requirements.
You can split contexts, as a mechanism to segment the size of a configuration file, if the
network topology allows.
371
Transit Segments
VLAN 10
VLAN 5
Internet
Servers
VLAN 20
Flow
Transit
Users
Nontransit
Client
Server
HTTP LB
users
Web/file servers

FTP LB, no delete
Internet mail
servers
Mail server
SMTP
Mail server
Internet mail
servers
SMTP
Internal users
Mail server
POP, SMTP
Server admin
Servers
ACEAP v1.01-11
The figure shows a single transit segment in the network. All the flows that require ACE
processing transit from the router to the Servers subnet.
372
Allocate Single Context
Transit
Nontransit
ACEAP v1.01-12
Common requirements allow use of a single context. Note that this context must be a routed
context. In the process of adding this context, you must add a VLAN and an IP subnet between
the router and the ACE.
373
Allocate Multiple Contexts
Transit
Nontransit
ACEAP v1.01-13
This topology would handle situations where routed mode is not an option or where functional,
management, resource, redundancy, or ease of configuration considerations make a single
context unacceptable. You need to add two VLANs between the router and the ACE contexts.
Additionally, if either context is to be configured in routed mode, you must add an IP subnet
between the router and the routed mode ACE contexts.
374
Proposed IP/VLAN Network Topology

VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Users
Transit
Nontransit
VLAN
IP
192.168.1.0/24
10
10.0.1.0/24
Servers Default gateway is 10.0.1.1
10.0.2.0/24
IT Default gateway is 10.0.2.1
10.0.3.0/24
Users Default gateway is 10.0.3.1
10.0.0.0/24
Router ACE, used for VIP addresses
20
100
Segment
Router Firewall
ACEAP v1.01-14
The network can be adequately served by a single ACE context, given the single transit
segment and the network requirements. In the figure, the decision has also been made to use a
routed mode ACE configuration. This requires changes to the Layer 2 and Layer 3 topologies,
resulting in the additional VLAN and IP subnet shown.
Caution
Changing the network topology probably requires changes to the configuration of other
network devices. In the network in the figure, the router needs to statically route the Servers
subnet to the ACE appliance.
375

This topic explains the process of designing a multifeature ACE implementation.

For each interface:
Identify flows with clients on this interface
Identify additional connections needed
from this interface (paths broken by ACE
or management traffic)
Router
Define classification criteria

Define processing actions
ACE
Define ACLs needed
Servers
ACEAP v1.01-16
Designing the specific ACE features can be done in a step-by-step process. This process can be
applied to each interface in each context in turn:
376
Identify the flows for which the packets from the client will be received on the interface in
question. This determines which flows will have connections initiated from this interface.
Identify additional connections that might now flow through the ACE because of the
topology changes made to deploy the ACE.
For each flow, define the criteria that classify traffic as part of the flow.
Define the processing actions needed for the flow.
Define the access control lists (ACLs) needed to allow new connections for the flow to be
received by the ACE appliance.
VLAN 100: Client Flows

VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Transit
Users
Nontransit
Client
Server
Internet or
internal users
Web/file servers
Internet mail
servers
Mail server
SMTP
Internal users
Mail server
POP, SMTP
Server admin
servers
Management
users
ACE
HTTP LB
FTP LB, no delete

Telnet, SSH, HTTPS
ACEAP v1.01-17
The network analysis continues with identifying the client flows received on VLAN 100, which
is the VLAN between the ACE and the router. Most of the table in the figure is a subset of the
master flow table created during the network analysis. The flow documented in the bottom row
is a new flow that accounts for management traffic. This flow is added to VLAN 100 because
that is the ingress interface for new management connections.
377
VLAN 100: Classification Criteria

VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Users
Transit
Nontransit
Client
Server
Classification Criteria
match virtual-address 10.0.0.14 tcp eq http
match virtual-address 10.0.0.14 tcp eq https
match virtual-address 10.0.0.14 tcp eq ftp
match FTP request-method dele or rmd
users
Web/file servers
Internet mail
servers
Mail server
n/a
Internal users
Mail server
n/a
Server admin
Servers
n/a
Management users
ACE
match protocol telnet 10.0.2.0 255.255.255.0

match protocol https 10.0.2.0 255.255.255.0
match protocol ssh 10.0.2.0 255.255.255.0
ACEAP v1.01-18
Criteria are now created for each classification that will be used to identify the flows. At this
point in the process, 10.0.0.14 has been selected as the VIP address to be used. Notice that
some flows have no classification criteria. This is because these flows need to flow through the
ACE, but there is no ACE-specific processing that needs to be applied to the flows.
378
VLAN 100: Processing Actions

VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Users
Transit
Nontransit
Client
Server
Classification Criteria: Processing Actions

match virtual-address 10.0.0.14 tcp eq http: LB to WEBFarm
Internet or
internal users
Web/file servers
match virtual-address 10.0.0.14 tcp eq https: LB to WEBFarm, ssl

match virtual-address 10.0.0.14 tcp eq ftp: LB to FTPFarm, inspect
match FTP request-method dele or rmd: deny
Internet mail
servers
Mail server
n/a
Internal users
Mail server
n/a
Server admin
Servers
n/a
Management
users
ACE
match protocol telnet 10.0.2.0 255.255.255.0: permit

match protocol https 10.0.2.0 255.255.255.0: permit
match protocol ssh 10.0.2.0 255.255.255.0: permit
ACEAP v1.01-19
You now add to the analysis by designing the processing actions for each classification. At this
point you also name some resources, such as the server farms.
379
VLAN 100: ACL Entries

VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Users
Transit
Nontransit
Client
Server
ACL Entries
permit tcp any host 10.0.0.14 eq http
users
Web/file servers
Internet mail
servers
Mail server
permit tcp any host 10.0.1.45 eq smtp
Internal users
Mail server
permit tcp 10.0.0.0 255.0.0.0 host 10.0.1.45 eq pop
Server admin
Servers
Management users
ACE
permit tcp any host 10.0.0.14 eq https

permit tcp any host 10.0.0.14 eq ftp
permit tcp 10.0.2.0 255.255.255.0 10.0.1.0 255.255.255.0

n/a
ACEAP v1.01-20
Here you need the IP address of the mail server. It is 10.0.1.45. Notice that you do not have a
specific ACL entry for internal users to reach the mail server for outgoing mail; this is because
these connections are already allowed by the ACL entry for the Internet mail servers to mail
server flow. You do not need to define an additional ACL entry for management users because
the management policy map builds this implicitly.
380
VLAN 10: Client Flows

VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Transit
Users
Nontransit
Client
Server
Mail server
Internet mail
servers
Internal servers
Internet servers
SMTP
HTTP, FTP (outbound)
ACEAP v1.01-21
You now repeat the same analysis steps for the other interface, VLAN 10. Again, you have an
additional flow. This time, you need to account for HTTP and FTP connections used by system
administrators to retrieve resources from the Internet while they are logged into the servers for
maintenance. This flow must be accounted for, because it will now transit through the ACE.
381
VLAN 10: Classification Criteria

VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Users
Transit
Nontransit
Client
Server
Classification Criteria
Mail server
Internet mail
servers
n/a
Internal servers
Internet servers
n/a
ACEAP v1.01-22
There is no ACE-specific processing to be done on connections from the servers, and therefore
no classification criteria or processing actions.
382
VLAN 10: ACL Entries

VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Transit
Users
Nontransit
Client
Server
Mail server
Internet mail
servers
Internal servers
Internet servers
ACL Entries
permit tcp any any eq smtp
permit tcp any any eq http
permit tcp any any eq ftp
ACEAP v1.01-23
The figure shows the ACL entries needed for traffic from VLAN 10.
383
Configuring Multiple Integrated Features

This topic describes the configuration of multiple integrated features.
Real Servers
VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Transit
Users
Nontransit
rserver host
ip address
inservice
rserver host
ip address
inservice
WEBFILE1
10.0.1.50
WEBFILE2
10.0.1.51
ACEAP v1.01-25
Implementing the sample design begins with defining the real servers. For this task you need
the IP addresses, which are 10.0.1.50 and 10.0.1.51, as shown in the figure.
384
Server Farms
VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Transit
Users
Nontransit
serverfarm host FTPFarm

rserver WEBFILE1 21
inservice
rserver WEBFILE2 21
inservice
serverfarm host WEBFarm
rserver WEBFILE1 80
inservice
rserver WEBFILE2 80
inservice
ACEAP v1.01-26
You have two different server farms that use the same real servers, but direct traffic to two
different ports. Because you are doing Secure Sockets Layer (SSL) offload process for some,
but not all, of your load-balanced HTTP traffic, you need to redirect both types of incoming
connections to port 80 on your servers. This requires you to define a separate server farm
utilizing the FTP port to load balance your incoming FTP traffic.
385
Class Maps
VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Transit
Users
Nontransit
class-map type ftp inspect match-any FTP-DELETE

match request-method dele
match request-method rmd
class-map match-any HTTP-VIP
match virtual-address 10.0.0.14 tcp eq http
class-map match-any HTTPS-VIP
match virtual-address 10.0.0.14 tcp eq https
class-map match-any FTP-VIP
match virtual-address 10.0.0.14 tcp eq ftp
class-map type management REMOTE-ACCESS
match protocol telnet 10.0.2.0 255.255.255.0
match protocol https 10.0.2.0 255.255.255.0
match protocol ssh 10.0.2.0 255.255.255.0
ACEAP v1.01-27
The classification list for each VLAN can be translated into a class map, as shown in the figure.
386
Layer 7 Processing
VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Transit
Users
Nontransit
ssl-proxy service SSL-OFFLOAD

key myrsakey_server
cert mycert_server
policy-map type inspect ftp first-match FTP-POLICY
class FTP-DELETE
deny
policy-map type loadbalance first-match FTP-SLB
class class-default
serverfarm FTPFarm
policy-map type loadbalance first-match WEB-SLB
class class-default
serverfarm WEBFarm
ACEAP v1.01-28
Next in your implementation, you configure the Layer 7 processing. This includes the SSL
proxies, inspection policies, and load-balancing policies.
387
Layer 4 Processing
VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Transit
Users
Nontransit
policy-map multi-match WEBFILE-VIPS

class HTTP-VIP
loadbalance policy WEB-SLB
class HTTPS-VIP
loadbalance policy WEB-SLB
ssl-proxy server SSL-OFFLOAD
class FTP-VIP
loadbalance policy FTP-SLB
inspect ftp strict policy FTP-POLICY
ACEAP v1.01-29
Layer 7 processing is activated by your Layer 3 and 4 policy map, which is now defined.
388
Management Access
VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Transit
Users
Nontransit
policy-map type management first-match MANAGEMENT-ACCESS

class REMOTE-ACCESS
permit
ACEAP v1.01-30
You now define the management policy map.
389
ACLs
VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Users
Transit
Nontransit
access-list from-outside
eq pop
255.255.255.0
extended
extended
extended
extended
extended
permit
permit
permit
permit
permit
tcp
tcp
tcp
tcp
tcp
any host
any host
any host
any host
10.0.0.0
10.0.0.14
10.0.0.14
10.0.0.14
10.0.1.45
255.0.0.0
eq http
eq https
eq ftp
eq smtp
host 10.0.1.45
extended permit tcp 10.0.2.0 255.255.255.0 10.0.1.0
access-list from-servers extended permit tcp any any eq smtp

access-list from-servers extended permit tcp any any eq http
access-list from-servers extended permit tcp any any eq ftp
ACEAP v1.01-31
You define ACL entries for all the traffic that is allowed to start a new connection through the
ACE appliance.
390
Interfaces
VLAN 10
VLAN 100
VLAN 5
Internet
Servers
VLAN 20
Flow
Transit
Users
Nontransit
interface vlan10
ip address 10.0.1.1 255.255.255.0
access-group input from-servers
interface vlan100
ip address 10.0.0.2 255.255.255.0
access-group input from-outside
service-policy input WEBFILE-VIPS
service-policy input MANAGEMENT-ACCESS
ACEAP v1.01-32
Finally, you associate the ACLs and policy maps with the appropriate interfaces.
391
Summary
Summary
Various types of requirements must be collected to
design a multifeature ACE implementation.
ACE context design allows functionality to be
partitioned based on topological and functional
requirements.
ACE feature design selects the characteristics of the
ACE features needed to fulfill network requirements.
Configuring multiple integrated features builds a
comprehensive network solution.
392
ACEAP v1.01-33
Lesson 13
Summary
Summary
The ACE appliance has four times the capacity of the CSS and
adds SSL, application firewall, and WAA functionality.
The ACE appliance attaches to the network via physical Gigabit
Ethernet links, and the contexts attach to the network using
VLANs.
The Modular Policy CLI is used to configure most of the traffichandling functions of the ACE appliance.
The ACE Device Manager GUI automatically sets up the
management class map, policy map, and service policy. SNMP
can be used to manage the ACE appliance.
ACE security features can be used to protect application hosting
resources from network attacks.
The ACE appliance load balances by analyzing Layer 4 attributes
of the client request.
ACEAP v1.01-2
The Cisco 4710 Application Control Engine (ACE) appliance provides intelligent network
services through load-balancing, Secure Sockets Layer (SSL) processing, and application
firewall features. The features for the ACE appliance, design and operational considerations,
and configuration activities were discussed in this module.
Summary (Cont.)
The ACE appliance can track the state of real servers and server
farms using health monitoring probes.
Layer 7 load balancing, inspection, and modification is available
for several application protocols.
The ACE appliance supports encryption and decryption of SSL
transactions.
The ACE appliance supports 1 Gb/s of compression and web
application acceleration features.
ACE appliances deployed in pairs provide redundancy.
Multiple features can be integrated to provide several types of
processing at the same time.
394
ACEAP v1.01-3
Lesson 14
Self-Check
Use the questions here to review what you learned in this lesson. The correct answers and
solutions are found in the Lesson Self-Check Answer Key.
Q1)
What are the three types of network functions that are performed by the ACE module?
(Choose three.) (Source: Introducing ACE)
A)
B)
C)
D)
E)
F)
G)
Q2)
Resource minimums can be oversubscribed. (True or false.) (Source: Deploying ACE)

A)
B)
Q3)
Application firewall
Intrusion detection
Dynamic IP routing
Load balancing
Perimeter firewall
SSL encryption and decryption
VPN termination
true
false
Which two of the following policy-map types are associated with an interface with the
service-policy input command? (Choose two.) (Source: Modular Policy CLI)
A)
B)
C)
D)
E)
FTP inspection
HTTP load balancing
HTTP inspection
Layer 3 and 4
Management access
Q4)
Which interface is the inside interface for Network Address Translation? (Source:
Security Features)
A)
B)
C)
D)
Q5)
How many server farms are used in Layer 4 load balancing? (Choose two.) (Source:
Layer 4 Load Balancing)
E)
F)
G)
H)
Q6)
one
two
three
four
What is the first step in designing an ACE deployment? (Source: Integrating Multiple
Features)
A)
B)
C)
D)
396
SSL v2
SSL v3
TLS V1
How many ACE modules are deployed for a fault-tolerant environment? (Source: High
Availability)
A)
B)
C)
D)
Q10)
FTP
HTTP
NNTP
SMNP
SMTP
Which two of the following SSL/TLS versions are supported by the ACE module?
(Choose two.) (Source: Processing Secure Connections)
A)
B)
C)
Q9)
one
two
three
any number
Policy-driven Layer 7 inspection is available for which two application protocols?

(Choose two.) (Source: Layer 7 Protocol Processing)
A)
B)
C)
D)
E)
Q8)
one
two
three
any number
How many server farms are used in Layer 7 load balancing? (Choose two.) (Source:
Layer 7 Protocol Processing)
A)
B)
C)
D)
Q7)
Client interface
Depends on the NAT configuration
DMZ
Server interface
Analyzing Requirements
Designing Topology changes
Determining number of contexts
Documenting Flows
Self-Check Answer Key

Q1)
A, D, F
Q2)
Q3)
D, E
Q4)
Q5)
Q6)
Q7)
A, B
Q8)
B, C
Q9)
Q10)
Self-Check
397
398

ACE Student Guide PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ACE Student Guide PDF

Uploaded by

Copyright:

Available Formats

Table of Contents

Implementing the Application Control Engine Appliance

Introducing the ACE 4710 Appliance

Modular Policy CLI

Managing the ACE Appliance

Layer 4 Load Balancing

Layer 7 Protocol Processing

Processing Secure Connections

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Deploying Application Acceleration and Optimization

Integrating Multiple Features

Self-Check Answer Key

2007 Cisco Systems, Inc.

Implementing the Cisco ACE Appliance (ACEAP) v1.0

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Implementing the Application

Describe the course goal and objectives

Present the suggested flow of the course materials

Learner Skills and Knowledge

2007 Cisco Systems, Inc. All rights reserved.

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Course Goal and Objectives

Implementing the Cisco ACE Appliance

2007 Cisco Systems, Inc. All rights reserved.

Describe the configuration tasks necessary to successfully deploy an ACE appliance

Describe the methods used to manage the ACE appliance

Describe the health monitoring capabilities of the ACE appliance

Describe the ACE support for SSL protocol processing

Describe a methodology used to design and configure multiple ACE features

2007 Cisco Systems, Inc.

Implementing the Application Control Engine Appliance

2007 Cisco Systems, Inc. All rights reserved.

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Cisco Icons and Symbols

Cisco MDS 9200

Cisco MDS 9100

2007 Cisco Systems, Inc. All rights reserved.

2007 Cisco Systems, Inc.

Implementing the Application Control Engine Appliance

Cisco Icons and Symbols (Cont.)

2007 Cisco Systems, Inc. All rights reserved.

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Introducing the ACE 4710

Describe the fundamentals of IP-based communications

Describe the fundamentals of IP-based applications

Describe HTTP-based applications

Describe the Cisco 4710 Application Control Engine appliance

IP Protocol Stack Review

Physical and Data

Application protocols define the data payload format

TCP and UDP define program-to-program

IP defines system-to-system communication.

Physical and data link define how IP is transmitted on

2007 Cisco Systems, Inc. All rights reserved.

IP itself defines system-to-system communication. Parts of IP address such issues as the

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.