You are on page 1of 402

Table of Contents

Implementing the Application Control Engine Appliance


Overview Objectives Course Goal and Objectives Course Flow Additional References

1
1 1 3 4 5

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

7
7 7 8 16 29 47 47 47 48 61

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

63
63 63 64 66 69 71 73 74 81 90 99 107 111

Modular Policy CLI


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 113 114 121 123 126 126 131 133 136 136 140

Managing the ACE Appliance


Overview Objectives Permitting Management Traffic SNMP Manageability Summary

141
141 141 142 148 156

Security Features
Overview Objectives IP Access Control Lists TCP/IP Fragmentation/Reassembly TCP/IP Normalization Network Address Translation Summary

157
157 157 158 160 164 170 178

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

179
179 179 180 188 189 189 189 195 198 198 206

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

207
207 207 208 214 215 216 216 232 234 240

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

241
241 241 242 250 254 257 267 268 270 274 281

Processing Secure Connections


Overview Objectives Digital Encryption Technologies SSL Service Options Configuring a Public Key Infrastructure Configuring SSL Proxy Services Summary

283
283 283 284 291 294 301 307

ii

Implementing the Cisco ACE Appliance (ACEAP) v1.0

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 309 310 312 324 325 326 326 329 330 331 332 333 334 335 335 338

High Availability
Overview Objectives Redundancy Object Tracking Failover State Replication Fault-Tolerance Configuration Displaying Fault-Tolerance Information Summary

339
339 339 340 344 347 349 352 358 363

Integrating Multiple Features


Overview Objectives Analyzing Network Requirements Designing ACE Contexts Designing ACE Features Configuring Multiple Integrated Features Summary

365
365 365 366 371 376 384 392

Summary Self-Check
Self-Check Answer Key

393 395
397

2007 Cisco Systems, Inc.

Implementing the Cisco ACE Appliance (ACEAP) v1.0

iii

iv

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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.

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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

2007 Cisco Systems, Inc.

Implementing the Application Control Engine Appliance

Course Flow
This topic presents the suggested flow of the course materials.

Course Flow
Day 1 Day 2
Layer 4 Load Balancing

Day 3
Processing Secure Connections Labs

Day Day 4 5
High Availability Integrating Multiple Features Labs

A M

Introducing ACE

Deploying ACE

Health Monitoring

Lunch
Modular Policy CLI Layer 7 Protocol Processing WAA Features Labs Labs Labs

P M

Managing the ACE appliance Security Features Labs

2007 Cisco Systems, Inc. All rights reserved.

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.

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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 Cisco MDS 9100 Fabric Switch Firewall

Multilayer Switches

Third-Party FC Director

ACE

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-8

These are some of the icons and symbols that you will see throughout this course.

2007 Cisco Systems, Inc.

Implementing the Application Control Engine Appliance

Cisco Icons and Symbols (Cont.)


Application Server FC JBOD
FC
HBA

Application Server with FC HBA


FC

iSCSI

Application Server with iSCSI


FC

FC RAID Subsystem

NAS

NAS Filer

FC Tape Subsystem

Workstation

2007 Cisco Systems, Inc. All rights reserved.

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.

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

Application protocols define the data payload format used by individual IP-based applications.

TCP

UDP

TCP and UDP define program-to-program communication.

IP

IP defines system-to-system communication.

Physical and Data Link


2007 Cisco Systems, Inc. All rights reserved.

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.

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

IP Header Fields
Physical Header IP Hdr 20 bytes Protocol Data: ICMP, TCP, UDP

Version

Header Length

Type of Service Flags (3 bits)

Total Length (in bytes) Fragment Offset Header Checksum

Identification Time to Live Protocol

Source IP Address Destination IP Address

2007 Cisco Systems, Inc. All rights reserved.

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: 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.
10 Implementing the Cisco ACE Appliance (ACEAP) v1.0 2007 Cisco Systems, Inc.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

11

UDP Header Fields


Physical Header IP Hdr UDP Hdr 20 bytes 8 bytes Application Data

Source Port Number Length

Destination Port Number Checksum

2007 Cisco Systems, Inc. All rights reserved.

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 appropriate process. 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 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.

12

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

TCP Header Fields


Physical Header IP Hdr TCP Hdr 20 bytes 20 bytes Application Data

Source Port Number

Destination Port Number Sequence Number

Acknowledgment Number Header Length Reserved (6 bits) Flags (6 bits) Window Size Urgent Pointer

TCP Checksum

2007 Cisco Systems, Inc. All rights reserved.

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 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 appropriate process. 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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

13

TCP Connection
Client Server

SYN

Initialize
ACK Data

SYN-ACK

ACK

Use
ACK FIN

Data More Data

Close
ACK
2007 Cisco Systems, Inc. All rights reserved.

ACK FIN
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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

15

IP Application Review
This topic describes the characteristics of the prominent IP-based applications and the underlying technologies.

OSI Layers
7 6 5 4 3 2 1
Application Presentation Session Transport Network Data Link Physical IP Link and Physical Protocols Application Protocols

TCP / UDP

ISO OSI Stack


2007 Cisco Systems, Inc. All rights reserved.

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: 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

16

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

17

IP-Based Application: HTTP


Client Web Server

GET / HTTP 1.0 ACK HTTP/1.0 200 OK Continuation

ACK

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Layer 7 Switching
Layer 57 information
Received only after TCP connection setup Might span multiple IP packets

Requires TCP termination and buffering

1
SYN SYN_ACK

2 3
SYN_ACK SYN

1
ACEAP v1.01-13

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

21

Digital Encryption

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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 Outside Outside DMZ Inside Outside

Destination DMZ:80 DMZ:!80 Any Any Inside

Permitted? Yes No Yes Yes No Yes


ACEAP v1.01-15

Established Session
2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

23

Network Address Translation Terminology

Internal Network Inside Systems IL Local Addresses OL IG

External Network Outside Systems OG Global Addresses

Source Inside Local Source Outside Local

Destination Outside Local Destination Inside Local

Source Inside Global Source Outside Global

Destination Outside Global Destination Inside Global

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Network Address Translation Example


Internal Network 10.0.0.0/24 External Network 198.133.219.0

IL 10.0.0.83

OL

IG

OG 198.133.219.25

Source 10.0.0.83 Source 198.133.219.25

Destination 198.133.219.25 Destination 10.0.0.83

Source 198.133.219.83 Source 198.133.219.25

Destination 198.133.219.25 Destination 198.133.219.83

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

25

Network Address Translation Example 2


Internal Network 10.0.0.0/24 External Network 198.133.219.0

IL 10.0.0.83

OL

IG

OG 198.133.219.25

Source 10.0.0.83 Source 10.0.0.25

Destination 10.0.0.25 Destination 10.0.0.83

Source 198.133.219.83 Source 198.133.219.25

Destination 198.133.219.25 Destination 198.133.219.83

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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 10.0.0.83:2418 Source 10.0.0.84:2417 Source 10.0.0.84:2418


2007 Cisco Systems, Inc. All rights reserved.

Destination 198.133.219.25:80 Destination 198.133.219.25:80 Destination 198.133.219.25:80

Source 198.133.219.83:2418 Source 198.133.219.83:2417 Source 198.133.219.83:2419

Destination 198.133.219.25:80 Destination 198.133.219.25:80 Destination 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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

27

Simple Network Management Protocol


Managed Device NMS

GET OID Data

SET OID Response

Trap

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Web Technology Overview


This topic describes the fundamentals of HTTP applications.

HTTP

Client Request

Server Response

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

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
2007 Cisco Systems, Inc. All rights reserved. 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: 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.
30 Implementing the Cisco ACE Appliance (ACEAP) v1.0 2007 Cisco Systems, Inc.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

31

HTTP Request Methods

Client Request

GET /US/partner/index.html HTTP/1.1


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 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

HTTP Request Methods GET HEAD POST DELETE PUT TRACE

OPTIONS CONNECT

2007 Cisco Systems, Inc. All rights reserved.

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. 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.

32

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

33

HTTP Request Headers

Client Request

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
2007 Cisco Systems, Inc. All rights reserved. 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): 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).

34

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

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. 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.

36

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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
2007 Cisco Systems, Inc. Introducing the ACE 4710 Appliance 37

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

38

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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
2007 Cisco Systems, Inc. All rights reserved. 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

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.
2007 Cisco Systems, Inc. Introducing the ACE 4710 Appliance 41

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.

42

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

HTTP Compression

Request Header Message Accept-Encoding: gzip,deflate Response Header Message Content-Encoding: gzip

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

45

HTML and Web Page Construction


Static Web Page HTML HTML HTML HTML Dynamic Web Page HTML

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Browser Behavior

Client Request
GET index.html HTTP/1.1 Host: www.cisco.com

Server Response
HTTP/1.1 200 OK

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

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)
2007 Cisco Systems, Inc. All rights reserved. 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 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.

48

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Application Control Engine Appliance

Back Panel

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

49

ACE 4710 Hardware Architecture

CONTROL PLANE
Serial Port

PCI-X BUS
1 Gb Ethernet 1 Gb Ethernet 1 Gb Ethernet 1 Gb Ethernet

DATA PLANE

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-36

The figure shows a functional diagram detailing the hardware architecture of the ACE 4710 appliance. Control plane (x86 architecture): 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

50

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

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
2007 Cisco Systems, Inc. All rights reserved. ACEAP v1.01-37

The figure lists some new features of the ACE 4710 appliance.

52

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

ACE Family of Products


XML Switching
ACE XML Gateway
30,000 TPS

Application Switching
Module
(416 Gb/s)

Multimodule
(64 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 GSS 20K DNS RPS ACE AppScope

ACE Networking Manager

ACE 4710 2 Gb/s ACE 4710 1 Gb/s

Global Products and Tools


ACEAP v1.01-38

2007 Cisco Systems, Inc. All rights reserved.

The figure shows ACE products available.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

53

ACE Improvements over CSS


ACE CSS

Up to 4 Gb/s Throughput 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
2007 Cisco Systems, Inc. All rights reserved.

Up to 2 Gb/s Throughput Up to 1 Gb/s HTTP Compression 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

ACE Improvements over CSS (Cont.)


ACE CSS
Content Switching Functions Only; Optional SSL Modules Content Switching, SSL, Security, Optimization Features HTML Acceleration Virtualized Configuration per Context IOS CLI (Session or SSH/Telnet) Software Licenses for Features or Additional Performance Active-Active (Per-Context Active Standby)
ACEAP v1.01-40

Single Configuration CLI

No Software Licenses (Except GSLB, but GSS Is Recommended) Per-Box Active-Standby Redundancy Model
2007 Cisco Systems, Inc. All rights reserved.

The figure shows ACE appliance improvements over CSS.

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

55

Application Delivery Features


CSS L4 to L7 SLB Stateful Redundancy Redundancy Connection Persistence (HTTP 1.1) Pipelining (HTTP 1.1) TCP Termination for Generic Protocols Inband Health Checking TCP Reuse (Multiplexing)
2007 Cisco Systems, Inc. All rights reserved.

CSM

ACE SM

ACE AP

Per VIP or per box

Per box

Per context

Per context

Limited

Limited

Fully supported

X X X X

(Future phase) (Future phase)

X (Future phase) X
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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Application Delivery Features (Cont.)


CSS L7 RDP-Aware Balancing Windows Terminal Services L7 SIP-Aware LB Scriptable Health Checks CSM ACE-SM ACE-AP

X X
Proprietary Routing on CSS TCL TCL

X
(Future phase)

X
(Future phase)

TCL

Route Health Injection HTTP Compression

VRF-aware

X
Future daughter card

KAL-AP Reporting Load to GSS


2007 Cisco Systems, Inc. All rights reserved.

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).

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

57

Security Features
CSS TCP and IP Normalization Layer 7 Fixups and Inspection uRPF Check Scalable Reflexive ACLs FWLB
CSM recommended (Reverse sticky, future phase)

CSM

ACE-SM

ACE-AP

X X X X

X X X X

SYN Cookies

(300K SYNs/ sec)

(4M SYNs/ (Future phase) sec)


ACEAP v1.01-43

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

WebNS

Supervisor IOS

Onboard IOS-like

X X
CVDM CVDM (Future phase)

HSE

HSE

ANM

ANM

2007 Cisco Systems, Inc. All rights reserved.

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).

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

59

SSL Features
CSS SSL Termination Back-End SSL Export Cipher-Suites AES Cipher-Suites Client Authentication
(SSLM 3.1)

SSLM CSM-S

ACE-SM

ACE-AP

X X
(Future phase)

SSL Session Reuse URL Rewrite HREF http:// to https://


2007 Cisco Systems, Inc. All rights reserved.

X
(Future phase)

X
(Future phase)
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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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.

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-46

2007 Cisco Systems, Inc.

Introducing the ACE 4710 Appliance

61

62

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

ACE VLANs

Web Client

ACE Client VLAN Server VLAN

Web Server

ACE Appliance

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-7

The figure shows the pertinent ACE appliance components needed to start the initial setup process and the boot dialog.
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.

66

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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]:

2007 Cisco Systems, Inc. All rights reserved.

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
2007 Cisco Systems, Inc. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

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 1 6

7
10 9

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Deploying ACE

71

ACE Routed Mode


Servers Default Gateway: Content Switch IP

Content Switch Routing

Subnet A VLAN 10

Subnet B VLAN 20

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

ACE One-Arm Mode


Servers Default Gateway: Upstream Router

Subnet A VLAN 10

Subnet B VLAN 20

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

One-Arm Mode: Flows

VIP 1 5 4 2

Server IP 3

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Deploying ACE

75

Overview of Direct Server Return


Servers Default Gateway: Upstream Router

Subnet B

2007 Cisco Systems, Inc. All rights reserved.

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: 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.

76

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Flows of Direct Server Return

VIP 1 3

Loopback IP = VIP 2

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Deploying ACE

77

Mixed Modes

VLAN 100 / Subnet A VLAN 101 / Subnet B VLAN 102 / Subnet C

VLAN 201 / Subnet A

VLAN 202 / Subnet B

VLAN 203 Subnet D


2007 Cisco Systems, Inc. All rights reserved.

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 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.

78

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

ACE Network Configuration

2007 Cisco Systems, Inc. All rights reserved.

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

2007 Cisco Systems, Inc.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Virtualization
This topic describes the use of multiple contexts.

Service Virtualization: System Separation


One Physical Device
100%

Multiple Virtual Systems (Dedicated Control and Data Path)


25% 25% 15% 15% 20%

Traditional device:
Single configuration file Single routing table Limited RBAC Limited resource allocation

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Deploying ACE

81

Multi-tier Applications
Enterprise Network
Firewalls LB Front-End Servers ACE with Application Infrastructure Control and Application Security Front-End Servers LB Database Servers
2007 Cisco Systems, Inc. All rights reserved.

Enterprise Network
Front-End Firewalls

LB Application Servers Application Servers


APP Virtual Partition

Database Servers
DB Virtual Partition

FE Virtual Partition

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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


2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Deploying ACE

83

Replacing Multiple Load Balancers


Enterprise Network

Virtual Partition 1

App C App D App E App F

Virtual Partition 2 Virtual Partition 3 Virtual Partition 4

ACE

ACE
Virtual Partition 1

App A App B

Virtual Partition 2

Enterprise with Growing Number of Applications


2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Multiple Contexts
Physical Device

Admin Context
Context Definition Resource Allocation

Context 1

Context 2

Context 3

Management Station AAA

Admin Context + 250 Contexts (Licensed: 5 Contexts in Base cCode)


2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

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-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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Configuring Context GUI

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Verifying Context Configuration GUI

Config Status shows here


2007 Cisco Systems, Inc. All rights reserved.

Config changes made here


ACEAP v1.01-30

The figure shows the GUI for verifying context configuration.

2007 Cisco Systems, Inc.

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 Data connections per second Management connections per second SSL bandwidth Syslogs per second

Access lists Regular expressions Data connections Management connections SSL connections Xlates Sticky entries

2007 Cisco Systems, Inc. All rights reserved.

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 The memory available on an appliance-wide basis for each type of state and configuration data is preallocated.

90

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Resource Classes

Context Context

Context Context Context Context Context

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Deploying ACE

91

Resource Class Allocation Parameters

Maximum Unlimited Minimum Guarantee

Maximum Equal to Minimum Minimum Guarantee

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Resource Oversubscription

Oversubscribed Global Pool Context 4 Minimum Context 3 Minimum Context 2 Minimum Context 1 Minimum

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

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
2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Configuring Resource Management GUI

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

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% 0.00% 20.00% 0.00% 20.00% 0.00% 20.00% 100.00% 200.00% 100.00% 200.00% 100.00% 200.00% 100.00% 200.00% default gold default gold default gold default gold

conc-connections

mgmt-connections

proxy-connections

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-39

The figure identifies resource class show commands.

2007 Cisco Systems, Inc.

Deploying ACE

97

Resource Usage GUI

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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
2007 Cisco Systems, Inc. All rights reserved. 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)

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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 --------------------------------------------Rule Type Permission 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 Implementing the Cisco ACE Appliance (ACEAP) v1.0 2007 Cisco Systems, Inc.

Role: Server-Maintenance (System-defined) Description: Server maintenance, monitoring and debugging Number of rules: 6 --------------------------------------------Rule Type Permission 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 --------------------------------------------Rule Type Permission 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 --------------------------------------------Rule Type Permission 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 --------------------------------------------Rule Type Permission Feature --------------------------------------------1. Permit Create access-list 2. Permit Create inspect 3. Permit Create connection 4. Permit Modify interface
2007 Cisco Systems, Inc. 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 --------------------------------------------Rule Type Permission 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 --------------------------------------------Rule Type Permission Feature --------------------------------------------1. Permit Monitor all 2. Permit Monitor changeto

102

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Management Domains

Physical Appliance
Context A Context B Domain2
VIP3 Farm3 Farm4 SSL cert1,2

Domain1
VIP1 VIP 2 Farm1 Farm2

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Deploying ACE

103

Management Access Summary

Physical Appliance
Admin Context
Context A Definition Context B Definition Resource Allocation Admin Management Config

Context A

Role
Context B Domain2
VIP3 Farm3 Farm4 SSL Cert1,2

Admin Network/Security Server Admin Monitor

Domain1
VIP1 VIP 2 Farm1 Farm2

Management Station
2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Deploying ACE

105

GUI RBAC

1 5 3 2

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Configuring Interfaces
This topic describes the steps to configure ACE interfaces.

Interface Types
Single Context
BVI Int Bridge Group VLAN INT VLAN INT FT INT

VLAN INT

VLAN INT

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Deploying ACE

107

Configuring Interfaces
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
2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Deploying ACE

109

MAC Address Allocation

ID Prom MAC
1 2 38
2007 Cisco Systems, Inc. All rights reserved.

Use
Supervisor Layer 3 Unshared VLAN Unused
ACEAP v1.01-52

Shared MAC addresses:


16 1K Pools globally shared-vlan-hostid selects 1

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Summary
This topic summarizes the key points that were discussed in this lesson.

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.
2007 Cisco Systems, Inc. All rights reserved. ACEAP v1.01-53

2007 Cisco Systems, Inc.

Deploying ACE

111

112

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Class Map: Structure


Class name Class type
Traffic Characteristics Matched

Match criteria Match type

Not Matched

2007 Cisco Systems, Inc. All rights reserved.

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

2007 Cisco Systems, Inc.

Modular Policy CLI

115

Class Map: Name

Class Name Class Type Match Criteria Match Type

Matched

Class Name: AuthUsers

Not Matched

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Class Map: Class Type

Class Name Class Type Match Criteria Match Type

Matched

Class Name: AuthUsers

Class Type: Layer 3/4

Not Matched

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Modular Policy CLI

117

Class Map: Match Criteria

Class Name Class Type Match Criteria Match Type

Matched

Class Name: AuthUsers

Class Type: Layer 3/4

Not Matched

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Class Map: Match All

Class Name Class Type Match Criteria Match Type

Matched

Class Name: AuthUsers and Not Matched and

Class Type: Layer 3/4 = matched X

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-9

The figure shows a match all condition.

2007 Cisco Systems, Inc.

Modular Policy CLI

119

Class Map: Match Any

Class Name Class Type Match Criteria Match Type

Matched

Class Name: AuthUsers or Not Matched or

Class Type: Layer 3/4 = matched X

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-10

The figure shows a match any condition.

120

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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}
2007 Cisco Systems, Inc. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Modular Policy CLI

123

Policy Map: Structure


Name Policy/Match Type

Policy name Policy type Match type Classification/action clauses

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Policy Map: Name


Name: Passengers

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Modular Policy CLI

125

Policy Map: Type


Name: Passengers Type: Loadbalance Policy Type Layer 3 and 4 FTP Inspect HTTP Inspect Loadbalance Management Match Type multimatch first-match all-match first-match first-match

2007 Cisco Systems, Inc. All rights reserved.

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: 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.

126

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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.

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Policy Map: class-default


Name: Passengers Type: Loadbalance

Business Class

Give Food Give Legroom

Give Food
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

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
2007 Cisco Systems, Inc. All rights reserved. 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 class-default is always processed last, no matter what order the classification/action clauses are defined in.

130

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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

2007 Cisco Systems, Inc.

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 class {name1 [insert-before name2] | class-default} 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 class {name1 [insert-before name2] | class-default} deny permit

132

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Modular Policy CLI

133

Associate Traffic Stream

Traffic Stream

Traffic Characteristics

Matched

Actions

Class Map Policy Map Activate Policy


2007 Cisco Systems, Inc. All rights reserved.

Traffic Characteristics

Matched

Actions

class-default

Actions
ACEAP v1.01-23

The figure shows an associate traffic stream.

134

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Multiple Traffic Streams

Traffic Stream

Traffic Characteristics

Matched

Actions

Traffic Stream

Class Map Policy Map Activate Policy


2007 Cisco Systems, Inc. All rights reserved.

Traffic Characteristics

Matched

Actions

class-default

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.

2007 Cisco Systems, Inc.

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


2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Using service-policy
Class Type 1

Class Type 1

Attach a policy map to one or more interfaces:


service-policy input policy_name

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

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]

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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.

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Modular Policy CLI

139

Summary
This topic summarizes the key points that were discussed in this lesson.

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.

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-29

140

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Lesson 4

Managing the ACE Appliance


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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Management Policy 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 policy-map type management first-match remote-mgmt class remote-access permit

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Managing the ACE Appliance

143

Activating Management Policy Maps

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 policy-map type management first-match remote-mgmt class remote-access permit interface vlan 231 service-policy input remote-mgmt
2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Validating Management Policy Configuration


switch/context# show run class-map | begin remote-access Generating configuration.... 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 switch/context# show run policy-map | begin remote-mgmt Generating configuration.... policy-map type management first-match remote-mgmt class remote-access permit switch/context# show run interface | begin 231 Generating configuration.... interface vlan 231 service-policy input remote-mgmt
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Managing the ACE Appliance

145

Validating Management Policy Status

switch/context# show service-policy remote-mgmt Status : ACTIVE ----------------------------------------Interface: vlan 231 service-policy: remote-mgmt

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Configuring Context GUI

2 3

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Managing the ACE Appliance

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.

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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.

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-12

SNMP management of contexts on the ACE appliance can be accomplished through the NMS configuration guidelines shown in the figure.

2007 Cisco Systems, Inc.

Managing the ACE Appliance

149

Configuring Basic SNMP Parameters

ACE NMS

snmp-server contact Example NOC shift supervisor snmp-server location Atlanta DC1, Rack 42

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Configuring SNMPv1/2c Community Strings

ACE NMS

snmp-server community grand-poobah snmp-server community status-keepers ro

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Managing the ACE Appliance

151

Configuring SNMPv3 Users

ACE NMS

snmp-server user nms-control auth MySecret!

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Managing the ACE Appliance

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

SNMP in the GUI

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-17

The figure shows the different SNMP characteristics that can be configured in the ACE appliance Device Manager.

2007 Cisco Systems, Inc.

Managing the ACE Appliance

155

Summary
This topic summarizes the key points that were discussed in this lesson.

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.

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-18

156

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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]

2007 Cisco Systems, Inc. All rights reserved.

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 The ACE creates sessions for User Datagram Protocol (UDP) and Internet Control Message Protocol (ICMP) flows, even though they are connectionless protocols.

158

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Applying Security ACLs


Source Client Destination Server

ACE
input output output input

Source Server

Destination Client

access-group {input | output} acl_name


2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Security Features

159

TCP/IP Fragmentation/Reassembly
This topic explains IP fragmentation processing.

IP Fragmentation

Max Packet: 1500 Bytes

Max Packet: 9000 Bytes

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Packet Flow for Fragmentation


ACE Dataplane Multiprocessor

Fastpath MP

Fragmentation MP

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Security Features

161

Packet Flow for Reassembly


ACE Dataplane Multiprocessor

Fastpath MP

Reassembly MP

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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.


2007 Cisco Systems, Inc. All rights reserved. ACEAP v1.01-10

Fragmentation and reassembly are controlled by configuration statements issued in the interface configuration submode, as shown in the figure.

2007 Cisco Systems, Inc.

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 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

Configurable:
icmp-guard Do Not Fragment flag (allow, clear) IP options (allow, clear, clear-invalid, drop) Minimum TTL Verify reverse path

src IP == 0.0.0.0 and dest IP == 255.255.255.255 allowed for DHCP requests

2007 Cisco Systems, Inc. All rights reserved.

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: 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.

164

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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)
2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Security Features

165

IP Address Spoofing Attacks

Trusted Host

Attacker

1 3 1 Attacker sends SYN with spoofed address 2 Target sends SYN-ACK 3 Attacker sends ACK with spoofed address

Target

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Security Features

167

Randomized Sequence Numbers (Cont.)

SEQ=Startclient + Sentclient ACK=StartACE + SentACE + 1

SEQ=Startclient + Sentclient ACK=Startserver + Sentserver + 1

Adjust

Ack number ACE Server


Adjust

Seq number ACE Server

SEQ=Startserver + Sentserver SEQ=StartACE + SentACE ACK=Startclient + Sentclient + 1 ACK=Startclient + Sentclient + 1


2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Security Features

169

Network Address Translation


This topic explains NAT and PAT.

Static NAT
Mapped IP Address Outside Interface Real IP Address Inside Interface

Class map identifies traffic from real IP address. Policy map action specifies outside interface. Service policy on inside interface.

Mapped IP Address Outside Interface

Real IP Address Inside Interface

Client Traffic Destination NAT Server Traffic Source NAT

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Static NAT and PAT: Configuration


Mapped IP Address: 198.133.219.25 Outside Interface VLAN 101 Real IP Address: 10.20.42.15 Inside Interface 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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Security Features

171

Dynamic NAT
Real IP Address Inside Interface Mapped IP Address 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 Inside Interface Mapped IP Address Outside Interface

Client Traffic Source NAT Server Traffic No NAT

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Dynamic NAT and PAT: Configuration


Real IP Address: Any Inside Interface VLAN 101 Mapped IP Address 10.1.1.1-10.1.1.100 Outside Interface 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
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

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 ,
2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Allocating from a NAT Pool


Real IP Address Inside Interface Mapped IP Address 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.

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-24

The figure shows the algorithm for allocating IP addresses from a dynamic NAT pool.

2007 Cisco Systems, Inc.

Security Features

175

Multiple NAT Pools


Real IP Address Inside Interface Mapped IP Address 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.

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

NAT/PAT Resource Limitations


Real IP Address Inside Interface Mapped IP Address 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

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-26

Hardware limitations on the NAT-related resources are listed in the figure.

2007 Cisco Systems, Inc.

Security Features

177

Summary
This topic summarizes the key points that were discussed in this lesson.

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.

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-27

178

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Lesson 6

Layer 4 Load Balancing


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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Server Farm
Load Balancer

LB

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 4 Load Balancing

181

Multiple Server Farms


Load Balancer

LB

LB

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Overlapping Server Farms

Load Balancer

LB

LB

LB

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 4 Load Balancing

183

Virtual Server: Virtual IP Address

Load Balancer

LB

LB

LB

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Health Monitoring

Load Balancer

HM

HM

HM

X
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Layer 4 Load Balancing

185

Layer 4 Load Balancing

Farm A 2 3 1

4 ACE

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 4 Load Balancing

187

Layer 7 Policy-Driven Load Balancing


Farm A
2 3 1

ACE

Farm C

Farm B
ACEAP v1.01-12

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

6. Farm B load balancing assigns the request to the top server. 7. Client requests image 2. 8. Policy assigns the request to Farm B. 9. Farm B load balancing assigns the request to the middle server.

Client 2
1. Client requests the home page. 2. Policy assigns the request to Farm A. 3. Farm A load balancing assigns the request to the right server. 4. Client requests image 1. 5. Policy assigns the request to Farm B. 6. Farm B load balancing assigns the request to the bottom server. 7. Client requests image 2. 8. Policy assigns the request to Farm B. 9. Farm B load balancing assigns the request to the top server.

Client 3
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. 6. Farm B load balancing assigns the request to the middle server. 7. Client requests image 2. 8. Policy assigns the request to Farm B. 9. Farm B load balancing assigns the request to the bottom server.

Client 4
1. Client requests the home page. 2. Policy assigns the request to Farm C. 3. There is only one server in Farm C, so the request is assigned to it.

2007 Cisco Systems, Inc.

Layer 4 Load Balancing

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

1
SYN SYN_ACK

2 3
SYN_ACK SYN

1
ACEAP v1.01-13

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Splicing Flows Together

SEQ=Startclient + Sentclient ACK=Startserver + Sentserver + 1 SEQ=Startserver + Sentserver ACK=Startclient + Sentclient + 1

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 4 Load Balancing

191

Splicing Flows Together (Cont.)

SEQ=Startclient + Sentclient ACK=StartACE + SentACE + 1

SEQ=Startclient + Sentclient ACK=Startserver + Sentserver + 1

Adjust

Ack no. ACE Server


Adjust

Seq no. ACE Server

SEQ=StartACE + SentACE ACK=Startclient + Sentclient + 1


2007 Cisco Systems, Inc. All rights reserved.

SEQ=Startserver + Sentserver ACK=Startclient + Sentclient + 1


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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

TCP Proxy Processing

Fastpath

TCP/HTTP/Inspect/L7

Fastpath

Proxy or reproxy:
Full TCP stack processing Full TCP state data Layer 7 state data Load on more MPs 256 K connections

Unproxy:
Smaller memory requirements Fewer MPs involved 1 million connections

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 4 Load Balancing

193

TCP Proxy Processing (Cont.)

Fastpath

TCP/HTTP/Inspect/L7

Fastpath

switch/Admin# show stats http | include prox SSL fin/rst msgs sent Reproxied requests HTTP unproxy conns : 0 : 1 : 1 , Unproxy msgs sent , Headers removed , Pipeline flushes : 1 : 0 : 0

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Load-Balancing Algorithms
This topic describes the load-balancing algorithms available.

Load-Balancing Algorithms
Called Predictors in the ACE. Select a real server within a server farm. Balance new connections. Application knowledge aids algorithm selection. Two types of Predictors:
Load Predictors Traffic pattern Predictors
LB

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 4 Load Balancing

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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 4 Load Balancing

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 rserver host EXT-HOST2 ip address 192.168.1.12 inservice

2007 Cisco Systems, Inc. All rights reserved.

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 Implementing the Cisco ACE Appliance (ACEAP) v1.0 2007 Cisco Systems, Inc.

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.

2007 Cisco Systems, Inc.

Layer 4 Load Balancing

199

Configuring Server Farms


ACE

rserver host EXT-HOST1 ip address 192.168.1.11 inservice rserver host EXT-HOST2 ip address 192.168.1.12 inservice serverfarm host EXT-SERVERS predictor roundrobin rserver EXT-HOST1 inservice rserver EXT-HOST2 inservice
2007 Cisco Systems, Inc. All rights reserved. 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 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.

200

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Define Load-Balancing Policy Map


ACE

policy-map type loadbalance first-match SLB-LOGIC class class-default serverfarm EXT-SERVERS

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 4 Load Balancing

201

Define VIP with Layer 3 and 4 Class Map


ACE

policy-map type loadbalance first-match SLB-LOGIC class class-default serverfarm EXT-SERVERS class-map match-all EXTERNAL-VIP 2 match virtual-address 198.133.219.25 tcp eq www

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Define Layer 3 and 4 Policy Map


ACE

policy-map type loadbalance first-match SLB-LOGIC class class-default serverfarm EXT-SERVERS class-map match-all EXTERNAL-VIP 2 match virtual-address 198.133.219.25 tcp eq www policy-map multi-match CLIENT-VIPS class EXTERNAL-VIP loadbalance vip inservice loadbalance policy SLB-LOGIC

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 4 Load Balancing

203

Attach Policy Map to a Traffic Stream


ACE

policy-map type loadbalance first-match SLB-LOGIC class class-default serverfarm EXT-SERVERS class-map match-all EXTERNAL-VIP 2 match virtual-address 198.133.219.25 tcp eq www policy-map multi-match CLIENT-VIPS class EXTERNAL-VIP loadbalance vip inservice loadbalance policy SLB-LOGIC 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
2007 Cisco Systems, Inc. All rights reserved. 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 You use this Layer 4 load-balancing configuration as a base configuration for many other configurations in this course.

204

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Layer 4 Load Balancing in running-config


access-list FROM-231 line 10 extended permit tcp any host 198.133.219.25 eq www class-map match-all EXTERNAL-VIP 2 match virtual-address 198.133.219.25 tcp eq www policy-map type loadbalance first-match SLB-LOGIC class class-default serverfarm EXT-SERVERS policy-map multi-match CLIENT-VIPS class EXTERNAL-VIP loadbalance vip inservice loadbalance policy SLB-LOGIC interface vlan 231 access-group input FROM-231 service-policy input CLIENT-VIPS

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 4 Load Balancing

205

Summary
This topic summarizes the key points that were discussed in this lesson.

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.

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-30

206

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

Health Monitoring Overview


This topic describes health monitoring options.

Health Monitoring Overview


Load Balancer
Passive Checks Probes

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Passive Health Checks


Load Balancer
Passive Checks

In-band health monitoring: CSS Return code monitoring: ACE, CSS

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

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.

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Built-in Probe Types


DNS Echo TCP ECHO UDP Finger FTP HTTP HTTPS ICMP IMAP POP3 RADIUS SMTP TCP Telnet 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.
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Health Monitoring

211

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.

212

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Server Status

Faildetect # probes failed

Passdetect # probes succeeded

X
ACEAP v1.01-8

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

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>

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Probe IP Address Handling


rserver being probed IP address s.s.s.s MAC ssss.ssss.ssss

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
2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Probing Through Firewalls


rserver fw1 ip address 172.16.1.2 rserver fw2 ip address 172.16.2.2 rserver fw3 ip address 172.16.3.2 serverfarm fws rserver fw1 rserver fw2 rserver fw3

172.16.1.2

172.16.2.2

10.0.1.2

probe icmp pinger ip address 10.0.1.2

172.16.3.2
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Health Monitoring

217

Probing DSR
rserver srv1 ip address 172.16.1.2 rserver srv2 ip address 172.16.1.3 serverfarm srvs rserver srv1 rserver srv2

VIP 198.133.219.25 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 ip address 198.133.219.25

Loopback 198.133.219.25

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

DNS Probe Configuration


probe dns <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> domain <name> expect address <ip-address>

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Health Monitoring

219

RADIUS Probe Configuration


probe radius <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> credentials <username> <password> [secret <shared-secret>] nas ip address <ip-address>

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-15

The RADIUS probe also adds two more attributes to the general probe configuration options. These are: 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.

220

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

UDP-Based 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> send-data <expression> expect regex <string> [offset <number>]

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Health Monitoring

221

TCP-Based 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> open <open-timeout> send-data <expression> expect regex <string> [offset <number>] connection term forced

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-17

The TCP-based probes Echo TCP, Finger, generic TCP, and Telnet add four more parameters to the general probe configuration: 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.

222

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

FTP/SMTP 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> receive <recv-timeout> open <open-timeout> send-data <expression> expect regex <string> [offset <number>] connection term forced expect status <min-number> <max-number> count <number>

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Health Monitoring

223

HTTP Probe Configuration


probe http <probe-name> description <description> ip address <ip-address> [routed] port <port-number> interval <seconds> faildetect <retry-count> passdetect interval <seconds> receive <recv-timeout> open <open-timeout> send-data <expression> expect regex <string> [offset <number>] connection term forced credentials <username> [<password>] header <field-name> header-value <value> request method {get | head} url <path> expect status <min-number> <max-number> hash <value> count <number>

2007 Cisco Systems, Inc. All rights reserved.

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: 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.

224

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

HTTPS Probe Configuration


probe https <probe-name> description <description> ip address <ip-address> [routed] port <port-number> interval <seconds> faildetect <retry-count> passdetect interval <seconds> receive <recv-timeout> open <open-timeout> send-data <expression> expect regex <string> [offset <number>] connection term forced credentials <username> [<password>] header <field-name> header-value <value> request method {get | head} url <path> expect status <min-number> <max-number> hash <value> ssl cipher RSA_ANY | <cipher-suite> ssl version SSLv2 | SSLv3 | TLSv1 count <number>

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-20

HTTPS adds SSL-specific attributes to the HTTP probe, allowing the probe to use particular SSL versions and cipher suites.

2007 Cisco Systems, Inc.

Health Monitoring

225

IMAP Probe Configuration


probe imap <probe-name> description <description> ip address <ip-address> [routed] port <port-number> interval <seconds> faildetect <retry-count> passdetect interval <seconds> count <number> receive <recv-timeout> open <open-timeout> send-data <expression> expect regex <string> [offset <number>] connection term forced credentials <username> <password> credentials mailbox <name> request method <command>
2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

POP Probe Configuration


probe pop <probe-name> description <description> ip address <ip-address> [routed] port <port-number> interval <seconds> faildetect <retry-count> passdetect interval <seconds> receive <recv-timeout> open <open-timeout> send-data <expression> expect regex <string> [offset <number>] connection term forced credentials <username> [<password>] request method <command> count <number>

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

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 predictor roundrobin probe pinger rserver ext-host1 inservice rserver ext-host2 inservice
2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-24

Current probe status and statistics can be displayed with the show probe detail command, as shown in the figure.

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-25

The ACE adds detail to the disconnect error messages with 49 different explanatory messages.

230

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

send failures probes failed conns refused open timeouts

: : : :

0 25 0 0

: : : : :

0 0 0 8 0

Total Total Total Total

send failures probes failed conns refused open timeouts

: : : :

0 8 0 0

. . . . . .

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-26

Global statistics grouped by probe type can be displayed with the show stats probe command.

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Displaying HTTP Return Code Statistics


switch/context# show serverfarm SF1 retcode serverfarm : SF1 rserver : R1 action count count count count count total count 0 0 0 0 0 -------------------------------------return code 400 401 402 403 404 +------------+--------+------------+

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

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>

2007 Cisco Systems, Inc. All rights reserved.

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: 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
234 Implementing the Cisco ACE Appliance (ACEAP) v1.0 2007 Cisco Systems, Inc.

MAIL_PROBE POP3_PROBE PROBENOTICE_PROBE RTSP_PROBE SSL_PROBE_SCRIPT TFTP_PROBE

2007 Cisco Systems, Inc.

Health Monitoring

235

Scripted Probe Configuration


probe scripted <probe-name> description <description> ip address <ip-address> [routed] port <port-number> interval <seconds> faildetect <retry-count> passdetect interval <seconds> count <number> receive <recv-timeout> script <script-name> [<script-arguments>]

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Show Commands
switch/context# show script code ECHO_PROBE_SCRIPT #!name = ECHO_PROBE_SCRIPT ################################################################################ # scriptname : ECHO_PROBE # # Description : # # # # ACE version: # # # Parameters: # # # debugFlag - default 0. Do not turn on while multiple probe suspects configured # Example config : # # probe echoProbe script script ECHO_PROBE [0] [debugFlag] 1.0+ 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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Health Monitoring

237

Displaying Scripted Probes


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

Last RunStart count= 2 Last Probe OK count= 2 Last ForkFail count= 0

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Scripted Probe Exit Codes


Exit Code
30001 30002 30003 30004 30005 30006 30007 30008 30009 Probe successful Probe error: server did not respond as expected Internal error: fork failed Script probe terminated due to timeout TCL interpreter panic Script error Cannot find file or buffer data Memory allocation failure for TCL_wt qnode Unknown return code

Description

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Health Monitoring

239

Summary
This topic summarizes the key points that were discussed in this lesson.

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.

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-36

240

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Lesson 8

Layer 7 Protocol Processing


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

rserver host EXT-HOST1 ip address 192.168.1.11 inservice rserver host EXT-HOST2 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
2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Configuring Additional Server Farms


ACE

serverfarm host EXT-SERVERS predictor roundrobin rserver EXT-HOST1 inservice rserver EXT-HOST2 inservice serverfarm host PHP-SERVERS predictor roundrobin rserver PHP-HOST1 inservice rserver PHP-HOST2 inservice
2007 Cisco Systems, Inc. All rights reserved. ACEAP v1.01-5

The new servers must now be placed into a new server farm, as shown in the figure.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

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 serverfarm EXT-SERVERS class-map match-all EXTERNAL-VIP 2 match virtual-address 198.133.219.25 tcp eq www policy-map multi-match CLIENT-VIPS class EXTERNAL-VIP loadbalance vip inservice loadbalance policy SLB-LOGIC

2007 Cisco Systems, Inc. All rights reserved.

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 match http commands can use regular expressions to match portions of the URL.

244

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Define Layer 7 Load-Balancing Policy


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 DYN-CONTENT serverfarm PHP-SERVERS class class-default serverfarm EXT-SERVERS class-map match-all EXTERNAL-VIP 2 match virtual-address 198.133.219.25 tcp eq www policy-map multi-match CLIENT-VIPS class EXTERNAL-VIP loadbalance vip inservice loadbalance policy SLB-LOGIC
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

245

Layer 7 Load Balancing in running-config


access-list FROM-231 line 10 extended permit tcp any host 198.133.219.25 eq www class-map match-all EXTERNAL-VIP 2 match virtual-address 198.133.219.25 www class-map type http loadbalance match-any DYN-CONTENT 2 match http url .*\.php policy-map type loadbalance http first-match SLB-LOGIC class DYN-CONTENT serverfarm PHP-SERVERS class class-default serverfarm EXT-SERVERS policy-map multi-match CLIENT-VIPS class EXTERNAL-VIP loadbalance vip inservice loadbalance policy SLB-LOGIC

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

247

Regular Expression Case Sensitivity


ACE

parameter-map type http HTTP_PARAM case-insensitive class-map match-all EXTERNAL-VIP 2 match virtual-address 198.133.219.25 tcp eq www policy-map multi-match CLIENT-VIPS class EXTERNAL-VIP appl-parameter http advanced-options HTTP_PARAM loadbalance vip inservice loadbalance policy SLB-LOGIC

2007 Cisco Systems, Inc. All rights reserved.

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.

248

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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.*.

2007 Cisco Systems, Inc. All rights reserved.

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.*.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

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 HTTP/1.1 200 OK Continuation

ACK FIN_ACK

FIN_ACK ACK
2007 Cisco Systems, Inc. All rights reserved. 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 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.

250

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

251

Configuring Persistent Rebalance


ACE

parameter-map type http HTTP_PARAM persistence-rebalance set header-maxparse-length 2048 length-exceed continue policy-map type loadbalance http first-match SLB-LOGIC class class-default serverfarm EXT-SERVERS class-map match-all EXTERNAL-VIP 2 match virtual-address 198.133.219.25 tcp eq www policy-map multi-match CLIENT-VIPS class EXTERNAL-VIP loadbalance vip inservice loadbalance policy SLB-LOGIC appl-parameter http advanced-options HTTP_PARAM
2007 Cisco Systems, Inc. All rights reserved. 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 Implementing the Cisco ACE Appliance (ACEAP) v1.0 2007 Cisco Systems, Inc.

Displaying Persistent Rebalance Statistics


ACE

switch/context# show stats http | include requests Reuse msgs sent Reproxied requests HTTP chunks : 0 : 0 : 0 , HTTP requests , Headers removed , Pipelined requests : 7 : 0 : 2

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-16

The show stats http | include requests command can be used to display statistics relevant to persistent rebalance.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

253

Server Reuse
This topic explains the reuse of ACE-to-server connections.

TCP Reuse
TCP1

ACE-TCP1 Pool1 TCP2

ACE-TCP2 Pool2

TCP3

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Configuring TCP Reuse


ACE

parameter-map type http HTTP_PARAM server-conn reuse policy-map type loadbalance http first-match SLB-LOGIC class class-default serverfarm EXT-SERVERS class-map match-all EXTERNAL-VIP 2 match virtual-address 198.133.219.25 tcp eq www policy-map multi-match CLIENT-VIPS class EXTERNAL-VIP loadbalance vip inservice loadbalance policy SLB-LOGIC appl-parameter http advanced-options HTTP_PARAM

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

255

Displaying TCP Reuse Statistics


ACE

switch/context# show stats http | include Reuse Reuse msgs sent Reproxied requests Headers inserted : 1 : 0 : 1 , HTTP requests , Headers removed , HTTP redirects 0 0 0 0 1 1 : 4 : 1 : 0 switch/context# show stats http | include Headers

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:

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Session Persistence
This topic explains session persistence.

The Shopping Cart Problem


Browse
I will never shop here again.

1 2 3

Select

Buy

Empty ?!?
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

257

Session Persistence
Browse Select Buy

That was easy.

3 2 1

2007 Cisco Systems, Inc. All rights reserved.

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 Session persistence lasts longer than a single TCP connection.

258

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Sticky Methods
Physical Header IP Hdr TCP Hdr 20 bytes 20 bytes Header Length HTTP Request Total Length (in bytes) Flags (3 bits) Protocol Source IP Address Destination IP Address Source Port Number Sequence Number Acknowledgment Number Header Length Reserved (6 bits) TCP checksum HTTP Request/Header
2007 Cisco Systems, Inc. All rights reserved. ACEAP v1.01-24

Version

Type of Service

Identification Time to Live (TTL)

Fragment Offset Header Checksum

Destination Port Number

Flags (6 bits)

Window Size Urgent Pointer

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

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

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.

2007 Cisco Systems, Inc. All rights reserved.

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 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.

260

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Sticky Group Attributes


ACE

timeout sticky-time timeout activeconns replicate sticky serverfarm name1 [backup name2 [sticky] [aggregate-state]]

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

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]

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Header Sticky
ACE

sticky http-header header_name group_name header offset offset [length length] static header-value value reserver name [port]

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

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]

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Activating a Sticky Group


ACE

sticky ip-netmask 255.255.255.255 address source EXT-STICKY serverfarm EXT-SERVERS policy-map type loadbalance http first-match SLB-LOGIC class class-default sticky-serverfarm EXT-STICKY class-map match-all EXTERNAL-VIP 2 match virtual-address 198.133.219.25 tcp eq www policy-map multi-match CLIENT-VIPS class EXTERNAL-VIP loadbalance vip inservice loadbalance policy SLB-LOGIC

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

265

Displaying Sticky Entries


ACE

switch/Admin# show sticky database sticky group : STICKY1 type timeout : HTTP-COOKIE : 3600 timeout-activeconns : FALSE rserver-instance time-to-expire

sticky-entry flags

---------------------+--------------------------------+-------------+-------+ 587583818767988700 R1:0 215961

switch/Admin# show stats http | include insert Headers inserted


2007 Cisco Systems, Inc. All rights reserved.

: 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

267

HTTP Inspection
This topic describes HTTP inspection.

HTTP Inspection
ACE

HTTP inspection:
Ensures RFC compliance Supports policy-based request filtering

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-35

The figure describes HTTP inspection.

268

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Configuring FTP Inspection


ACE

policy-map type loadbalance generic first-match SLB-LOGIC class class-default serverfarm EXT-SERVERS class-map match-all EXTERNAL-VIP 2 match virtual-address 198.133.219.25 tcp eq ftp policy-map multi-match CLIENT-VIPS class EXTERNAL-VIP loadbalance vip inservice loadbalance policy SLB-LOGIC inspect ftp access-list FROM-231 extended permit tcp any host 198.133.219.25 eq ftp interface vlan 231 access-group input FROM-231 service-policy input CLIENT-VIPS
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

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

2007 Cisco Systems, Inc. All rights reserved.

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 Implementing the Cisco ACE Appliance (ACEAP) v1.0 2007 Cisco Systems, Inc.

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 policy-map multi-match CLIENT-VIPS class ftp-conns inspect ftp strict policy NO-DELETES

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Configuring RTSP Inspection


ACE

class-map match-all RTSP-CONNS 2 match port tcp eq rtsp policy-map multi-match CLIENT-VIPS class rtsp-conns inspect rtsp access-list FROM-231 extended permit tcp any any eq rtsp interface vlan 231 access-group input FROM-231 service-policy input CLIENT-VIPS

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

275

ICMP Inspection
ACE

ICMP application inspection performs the following tasks:


Creates connection state for ICMP requests Verifies sequence numbers Matches responses to requests

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

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 access-group input FROM-231 service-policy input FIXUP-ICMP

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Summary
This topic summarizes the key points that were discussed in this lesson.

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.
2007 Cisco Systems, Inc. All rights reserved. ACEAP v1.01-50

2007 Cisco Systems, Inc.

Layer 7 Protocol Processing

281

282

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Asymmetric Encryption
Jane Key 1 Key 2 John

Key 1

Key 2

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Processing Secure Connections

285

Public Key Encryption


Key 2

Key 2

Key 2 Key 1

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Digital Signatures

Hash Signature

Hash

Equal?

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Processing Secure Connections

287

Certificates
Company Docs Application

Certificate Authority
Application

Key Pair

Certificate Signing Request Public Key Common name Domain name Location E-mail

Validation Process Certificate Signing Request Public Key Common name Domain name Location E-mail

Public Key Private Key

Server Private Key

Certificate
Server Public Key

Certificate
Server Public Key

SSL Server
2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

SSL Fundamentals: Key Exchange Packet Flow Overview


Client Hello Server Hello

Certificate

Server Public Key Public Key

Server Public Key Key Exchange

Random Number Generator

RSA Encrypt Data

SAasdfkjw1340+jakjb//alkjt

RSA Encrypt Data

Private Key

Shared Secret Key

Data Exchange SAasdfkjw1340+jakjb//alkjt SAasdfkjw1340+jakjb//alkjt

Shared Secret Key Shared Secret Encrypt & Decrypt

Shared Secret Encrypt & Decrypt

Data Client Browser


2007 Cisco Systems, Inc. All rights reserved.

Data

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 Step 2

The client sends a client hello packet to the server. The server sends a server hello set of packets to the client. Included in these packets is a copy of the servers certificate. The client uses the certificate to verify the identity of the server. The client creates a session key to be used as a shared key for symmetric encryption. The client encrypts the session key with the servers public key. The server decrypts the session key with its private key. Both systems encrypt further traffic with the shared key.

Step 3 Step 4 Step 5 Step 6 Step 7

2007 Cisco Systems, Inc.

Processing Secure Connections

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

2007 Cisco Systems, Inc. All rights reserved.

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: 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

290

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

SSL Service Options


This topic explains SSL offload, back-end SSL, and end-to-end encryption.

SSL Termination

ACE

Encrypted Unencrypted

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Processing Secure Connections

291

SSL Initiation

ACE

Encrypted Unencrypted

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

End-to-End Encryption

ACE

Encrypted Unencrypted

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Processing Secure Connections

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
2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Generating a Public/Private Key Pair


ACE

crypto generate key [non-exportable] bitsize filename

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Processing Secure Connections

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

2007 Cisco Systems, Inc. All rights reserved.

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: 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.

296

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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) #

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Processing Secure Connections

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}
2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Processing Secure Connections

299

Managing PKI Resources


ACE

Delete a PKI resource:


crypto delete {filename | all}

View a PKI resource:


show crypto {cert | key} [filename]

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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 class-map match-all external-vip 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 vip inservice loadbalance policy slb-logic
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Processing Secure Connections

301

Configuring SSL Certificate Chains


ACE

crypto cert cert cert

chaingroup InternalCAcerts rootCA.pem ouCA.pem deptCA.pem

ssl-proxy service secure_access key myrsakey_server cert mycert_server chaingroup InternalCAcerts

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Configuring SSL Protocol Options


ACE

parameter-map type ssl only-ssl3 version ssl3 ssl-proxy service secure_access key myrsakey_server cert mycert_server ssl advanced-options only-ssl3

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Processing Secure Connections

303

Configuring SSL Initiation


ACE

ssl-proxy service backend_ssl class-map match-all external-vip 2 match virtual-address 198.133.219.25 tcp eq http policy-map type loadbalance first-match slb-logic class class-default serverfarm ext-servers ssl-proxy client backend_ssl policy-map multi-match client-vips class external-vip loadbalance vip inservice loadbalance policy slb-logic
2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Configuring SSL End-to-End


ACE

ssl-proxy service secure_access key myrsakey_server cert mycert_server ssl-proxy service backend_ssl class-map match-all external-vip 2 match virtual-address 198.133.219.25 any policy-map type loadbalance first-match slb-logic class class-default serverfarm ext-servers ssl-proxy client backend_ssl policy-map multi-match client-vips class external-vip ssl-proxy server secure_access loadbalance vip inservice loadbalance policy slb-logic

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-28

The figure shows SSL end-to-end configuration.

2007 Cisco Systems, Inc.

Processing Secure Connections

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

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-29

The figure identifies the functions that did not make it into ACE SSL v1.0.

306

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Summary
This topic summarizes the key points that were discussed in this lesson.

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.

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-30

2007 Cisco Systems, Inc.

Processing Secure Connections

307

308

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

Web Application Acceleration Architecture


This topic describes the architecture of the web application acceleration features.

Web Application Acceleration Architecture

CONTROL PLANE
Serial Port

PCI-X BUS
1 Gb Ethernet 1 Gb Ethernet 1 Gb Ethernet 1 Gb Ethernet

DATA PLANE

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-4

The figure shows a diagram of web application acceleration (WAA) architecture. 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.

310

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

AVS Traffic Flow


Control Plane Components

IF: 127.1.0.128 S2 C2

IF: 127.1.0.192 Vip1 Vip2 Vipn Vip Internal (127.1.0.193) Vip1 Vip2 Vipn
IF

C1

S1

DP Components

Private HTTP headers are exchanged. Persistence rebalance is used.


2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Deploying Application Acceleration and Optimization

Rserver

IF

Client

311

FlashForward
This topic describes the FlashForward feature of the ACE appliance.

Normal Browser Behavior

HTTP 200 OK HTTP 200 OK

GET Index.html

GET Foo.gif GET Foo.js GET Foo.jpg GET Foo.css

HTTP 200 OK HTTP 200 OK

HTTP 200 OK GET bar.gif HTTP 200 OK HTTP 200 OK


2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Normal Browser Behavior: Return Visit

HTTP 200 OK 304 Not Modified

IMS Index.html

IMS Foo.gif IMS Foo.js IMS Foo.jpg IMS Foo.css

304 Not Modified 304 Not Modified

304 Not Modified IMS bar.gif HTTP 200 OK HTTP 200 OK


2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Deploying Application Acceleration and Optimization

313

FlashForward: Priming the Cache

1. Client requests HTML page.


GET Index.html

2. ACE forwards request to server.


GET Index.html

HTTP 200 OK
Unmodified HTML page

HTTP 200 OK
Unmodified HTML page

4. ACE passes unaltered HTML object page to client.


2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

FlashForward: Priming the Cache (Cont.)

1. Client requests altered objects from HTML object page.


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

2. ACE proxies the request and forwards it to server.


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.
2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Deploying Application Acceleration and Optimization

315

FlashForward: First Visit After Priming Cache

Client requests HTML page.


GET Index.html

ACE forwards request to server.

GET Index.html

HTTP 200 OK
Modified HTML page

HTTP 200 OK
Unmodified 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.
2007 Cisco Systems, Inc. All rights reserved.

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: Served with expiration date in the future: 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: 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.

316

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

FlashForward: First Visit after Priming Cache (Cont.)

Client requests altered objects from HTML object page.


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 proxies the request, checks cache for FF objects, and sends IMS message for objects to server to verify freshness.
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

ACE checks whether items can be FlashForwarded; if true, they are cached. ACE forwards objects unaltered to client.
2007 Cisco Systems, Inc. All rights reserved.

Server responds to request with objects.


ACEAP v1.01-12

The figure shows browser behavior with FlashForward for the first visit after the cache is primed.

2007 Cisco Systems, Inc.

Deploying Application Acceleration and Optimization

317

FlashForward: Second Visit

Client requests HTML page.


GET Index.html

ACE forwards request to server.


GET Index.html

HTTP 200 OK

Unmodified HTML page

Server responds to request with HTML object page.

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-13

On subsequent visits: 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.

318

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

FlashForward: Second Visit (Cont.)

Object reference:<img src=/images/Foo.jpg>

Unmodified HTML page

ACE checks whether objects are FF-able and cached. If so, ACE verifies freshness of objects with IMS messages to server.
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 200 OK Foo.jpg 304 NM Foo.css 304 NM bar.gif 304 NM bar.js

HTTP 200 OK Index.html

Transformed object reference: <img src= /images/Foo_CISCO _AAC_FLASHFORWAR D_vtmmi14xg2fvmlkxsx uk0ty1xd_V02.jpg>

Modified HTML page

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-14

The figure shows browser behavior with FlashForward for subsequent visits.

2007 Cisco Systems, Inc.

Deploying Application Acceleration and Optimization

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.
2007 Cisco Systems, Inc. All rights reserved. ACEAP v1.01-15

The figure shows browser behavior with FlashForward for subsequent visits.

320

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Deploying Application Acceleration and Optimization

321

Define FlashForwardObject Optimization


ACE

class-map type http loadbalance match-all CM-FFObject match http url .*gif match http url .*jpg action-list type optimization http ACTION-LIST-2 flashforward-object parameter-map type optimization http ParMap-FFObject cache ttl max 60 cache ttl min 0 policy-map type optimization http first-match PolMap-Opt class CM-FFObject action ACTION-LIST-2 parameter ParMap-FFObject

2007 Cisco Systems, Inc. All rights reserved.

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 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

322

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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 action-list type optimization http ACTION-LIST-1 flashforward action-list type optimization http ACTION-LIST-2 flashforward-object parameter-map type optimization http ParMap-FF parameter-map type optimization http ParMap-FFObject cache ttl max 60 cache ttl min 0 policy-map type optimization http first-match PolMap-Opt class CM-FF action ACTION-LIST-1 parameter ParMap-FF class CM-FFObject action ACTION-LIST-2 parameter ParMap-FFObject policy-map multi-match CLIENT-VIPS class VIP-170 optimize http policy PolMap-Opt

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Deploying Application Acceleration and Optimization

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

2007 Cisco Systems, Inc. All rights reserved.

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: 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

324

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc.

Deploying Application Acceleration and Optimization

325

Delta Optimization Methodology (Cont.)


3
2nd Client Request

Server Response

ACE Response (delta j-script) 2KB

2007 Cisco Systems, Inc. All rights reserved.

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.
2007 Cisco Systems, Inc.

Implementing the Cisco ACE Appliance (ACEAP) v1.0

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.

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Deploying Application Acceleration and Optimization

327

The following conditions must also be met for the page to be successfully delta optimized: 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.

328

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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

2007 Cisco Systems, Inc.

Deploying Application Acceleration and Optimization

329

Fast Redirect
This topic explains the use of fast redirect and its benefits.

Fast Redirect
1
Client Request

2
302 Response

200 Response

Fast Redirect Request

5 4

200 Response

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

FlashConnect
This topic explains the use of FlashConnect and its benefits.

FlashConnect
ACE Response Server Response

<html> <img src="img1.jpg"> <img src="img2.jpg"> <img src="img3.jpg"> <img src="img4.jpg"> </html> <html> <img src="http://fgn00.flashconnect.myhost/img1.jpg"> <img src="http://fgn01.flashconnect.myhost/img2.jpg"> <img src="http://fgn02.flashconnect.myhost/img3.jpg"> <img src="http://fgn03.flashconnect.myhost/img4.jpg"> </html>
2007 Cisco Systems, Inc. All rights reserved. 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

2007 Cisco Systems, Inc.

Deploying Application Acceleration and Optimization

331

Just-in-Time Object Acceleration


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

Just-in-Time Object Acceleration


Client Request
Is the requested object larger than 250K? Or Is this object marked as expired or noncacheable?

ACE Response

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Adaptive Dynamic Cache


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

Adaptive Dynamic Cache


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.

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Deploying Application Acceleration and Optimization

333

Compression Overview
This topic describes HTTP compression.

HTTP Performance over a WAN

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-34

The figure shows HTTP performance over a WAN.

334

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

HTTP Compression

HTTP standards-based Compression algorithms for deflate and gzip


2007 Cisco Systems, Inc. All rights reserved. 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:
2007 Cisco Systems, Inc.

Remove Content-Length header Add Transfer-Encoding Chunked header


Deploying Application Acceleration and Optimization 335

Enabling Compression
ACE

policy-map type loadbalance first-match slb-logic class class-default serverfarm ext-servers compress default-method gzip class-map match-all external-vip 2 match virtual-address 198.133.219.25 tcp eq www policy-map multi-match client-vips class external-vip loadbalance vip inservice loadbalance policy slb-logic

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-36

The figure shows how to enable compression.

336

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Compression Parameters
ACE

parameter-map type http COMPRESSION_PARMS compress mimetype text/* compress minimum-size 512 policy-map type loadbalance first-match slb-logic class class-default serverfarm ext-servers compress default-method gzip class-map match-all external-vip 2 match virtual-address 198.133.219.25 tcp eq www policy-map multi-match client-vips class external-vip loadbalance vip inservice loadbalance policy slb-logic appl-parameter http advanced-options COMPRESSION_PARMS
2007 Cisco Systems, Inc. All rights reserved. ACEAP v1.01-37

The figure shows compression parameters.

2007 Cisco Systems, Inc.

Deploying Application Acceleration and Optimization

337

Summary
This topic summarizes the key points that were discussed in this lesson.

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.

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-38

338

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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

A
Active FT VLAN

B
Active

C C

D D
Active

Standby Standby

A
ACE-2

Standby Standby Active

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.
2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Fault-Tolerant VLAN
ACE-1

A
Active FT VLAN

B
Active

C C

D D
Active

Standby Standby

A
ACE-2

Standby Standby Active

FT FT FT FT group 1 group 2 group 3 group 4

Designated fault-tolerant VLAN between ACE pair Used for redundancy-related traffic Configured in Admin context

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

High Availability

341

Query VLAN
ACE-1

A
Active FT VLAN

B
Active

C C

D D
Active

Standby Standby

A
ACE-2

Standby Standby Active

FT FT FT FT group 1 group 2 group 3 group 4

Data VLAN. Standby ACE pings the active ACE. Successful ping transitions to STANDBY_COLD.

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Configuration Synchronization
ACE-1

A
Active FT VLAN

B
Active

C C

D D
Active

Standby Standby

A
ACE-2

Standby Standby Active

FT FT FT FT group 1 group 2 group 3 group 4

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
2007 Cisco Systems, Inc. All rights reserved. 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

2007 Cisco Systems, Inc.

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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Interface Tracking
ft track interface vlan-example track-interface vlan 204 peer track-interface vlan 204 priority 150 peer priority 100 ft ACE: Track VLAN

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

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
2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Failover
This topic explains the failover recovery process.

Virtual MAC Addresses


ACE-1

A
Active FT VLAN

B
Active

C C

D D
Active

Standby Standby

A
ACE-2

Standby Standby Active

FT FT FT FT group 1 group 2 group 3 group 4 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.
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

High Availability

347

Failover Actions
ACE-1

A
Active FT VLAN

B
Active

C C

D D
Active

Standby Standby

A
ACE-2

Standby Standby Active

FT FT FT FT group 1 group 2 group 3 group 4

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
2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

State Replication
This topic explains state replication between ACE appliances.

Connection Replication
ACE-1

A
Active FT VLAN

B
Active

C C

D D
Active

Standby Standby

A
ACE-2

Standby Standby Active

FT FT FT FT group 1 group 2 group 3 group 4 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.
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

High Availability

349

Connection Replication Statistics


ACE-1

A
Active FT VLAN

B
Active

C C

D D
Active

Standby Standby

A
ACE-2

Standby Standby Active

FT FT FT FT group 1 group 2 group 3 group 4

show conn show rserver show serverfarm

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Sticky Replication
ACE-1

A
Active FT VLAN

B
Active

C C

D D
Active

Standby Standby

A
ACE-2

Standby Standby Active

FT FT FT FT group 1 group 2 group 3 group 4

Independent from connection replication Enabled in the sticky group configuration Bulk and periodic sync processes Multiple sticky entries per replication packet
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

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


ACE-1
FT VLAN QUERY VLAN

A Active

B C D Active Standby Standby D Active

ACE-2

A B C Standby Standby Active


FT group 1 FT group 2

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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Configuring Peer Redundancy


ACE-1
FT VLAN QUERY VLAN

A Active

B C D Active Standby Standby D Active

ACE-2

A B C Standby Standby Active


FT group 1 FT group 2

FT FT group 3 group 4

Fault-tolerant peer configuration:


ft peer 1 ft-interface vlan 100 heartbeat count 20 heartbeat interval 200

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-21

The ft peer is associated with the peer via FT VLAN. This is configured in the Admin context.

2007 Cisco Systems, Inc.

High Availability

353

Configuring Fault-Tolerant Groups


ACE-1
FT VLAN QUERY VLAN

A Active

B C D Active Standby Standby D Active

ACE-2

A B C Standby Standby Active


FT group 1 FT group 2

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

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Fault-Tolerant Configuration Synchronization


ACE-1
FT VLAN QUERY VLAN

A Active

B C D Active Standby Standby D Active

ACE-2

A B C Standby Standby Active


FT group 1 FT group 2

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

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-23

Configuration of fault-tolerant config sync is shown in the figure. This can be configured in all contexts.

2007 Cisco Systems, Inc.

High Availability

355

Forcing a Failover
ACE-1
FT VLAN QUERY VLAN

A Active

B C D Active Standby Standby D Active

ACE-2

A B C Standby Standby Active


FT group 1 FT group 2

FT FT group 3 group 4

Failing over fault-tolerant contexts:


ft switchcover [group-id] [force]

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Fault-Tolerant Sticky Replication Configuration


ACE-1
FT VLAN QUERY VLAN

A Active

B C D Active Standby Standby D Active

ACE-2

A B C Standby Standby Active


FT group 1 FT group 2

FT FT group 3 group 4

Fault-tolerant sticky configuration:


sticky ip-netmask 255.255.255.255 address source EXT-STICKY replicate sticky

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

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
2007 Cisco Systems, Inc. All rights reserved.

: : : : : : : : : : : : : : : : : : : :

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Show Fault-Tolerant Group


ACE/Admin# sh ft group detail FT Group Configured Status Maintenance mode My State My Config Priority My Net Priority My Preempt Peer State Peer Config Priority Peer Net Priority Peer Preempt Peer Id Last State Change time No. of Contexts Context Name Context Id switch/Admin# : 1 : in-service : MAINT_MODE_OFF : FSM_FT_STATE_ACTIVE : 120 : 120 : Enabled : FSM_FT_STATE_STANDBY_HOT : 50 : 50 : Enabled : 1 : Thu Feb : 1 : Admin : 0 2 06:38:13 2006

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

High Availability

359

Show Fault-Tolerant Stats


ACE/Admin# show ft stats HA Heartbeat Statistics -----------------------Number of Heartbeats Sent Number of Heartbeats Received Number of Heartbeats Missed Number of Unidirectional HB's Received Number of HB Timeout Mismatches Num of Peer Up Events Sent Num of Peer Down Events Sent : 431 : 435 : 0 : 5 : 0 : 1 : 0

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-29

The show ft stats command displays statistics reflecting the handling of heartbeats.

360

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Show Fault-Tolerant Track


ACE/Admin# sh ft track detail FT Group Status Maintenance mode My State My Config Priority My Net Priority My Preempt Context Name Context Id Track type Vlan Id State Priority Transitions : 1 : in-service : MAINT_MODE_OFF : FSM_FT_STATE_ACTIVE : 120 : 120 : Enabled : Admin : 0 : TRACK_INTF : 40 : TRACK_UP : 50 : 1

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

High Availability

361

Show Fault-Tolerant Track (Cont.)


ACE/Admin# show ft track detail FT Group Status Maintenance mode My State My Config Priority My Net Priority My Preempt Context Name Context Id Track type Vlan Id State Priority Transitions : 1 : in-service : MAINT_MODE_OFF : FSM_FT_STATE_ACTIVE : 120 : 70 : Enabled : Admin : 0 : TRACK_INTF : 40 : TRACK_DOWN : 50 : 2

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Summary
This topic summarizes the key points that were discussed in this lesson.

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.

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-32

2007 Cisco Systems, Inc.

High Availability

363

364

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Lesson 12

Integrating Multiple Features


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

Analyzing Network Requirements


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

Analyzing Network Requirements


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

Servers

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Sample Network
Servers Internet

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
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Integrating Multiple Features

367

Document Flows
Servers Internet

Users

Client
Internet or internal users Internet mail servers Mail server Internal users Server admin
2007 Cisco Systems, Inc. All rights reserved.

Server
Web/file servers

Protocols / Processing
HTTP LB HTTPS SSL offload, LB FTP LB, no delete

Mail server Internet mail servers Mail server Servers

SMTP SMTP 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Management Access Needed


Servers Internet

Users

Manager
Network admins Server admins Server admins Helpdesk

Resource
ACE Web/file servers VIPs VIPs

Function
Configure/monitor all functions Remove from/return to service Monitor VIP status Monitor VIP status

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Integrating Multiple Features

369

IP/VLAN Network Topology


VLAN 10 VLAN 5

Servers
VLAN 20

Internet

Users

VLAN
5 10 20

IP
192.168.1.0/24 10.0.1.0/24 10.0.2.0/24 10.0.3.0/24

Segment
Router Firewall Servers Default gateway is 10.0.1.1 IT Default gateway is 10.0.2.1 Users Default gateway is 10.0.3.1

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Designing ACE Contexts


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

Designing ACE Contexts


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 Design topology changes
2007 Cisco Systems, Inc. All rights reserved. ACEAP v1.01-10

Router

ACE

Servers

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.

2007 Cisco Systems, Inc.

Integrating Multiple Features

371

Transit Segments
VLAN 10 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users Protocols / Processing HTTP LB HTTPS SSL offload, LB FTP LB, no delete

Client Internet or internal users Internet mail servers Mail server Internal users Server admin
2007 Cisco Systems, Inc. All rights reserved.

Server Web/file servers

Mail server Internet mail servers Mail server Servers

SMTP SMTP POP, SMTP Telnet, HTTP, FTP, SSH, RDP, SNMP, X
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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Allocate Single Context

Transit Nontransit
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Integrating Multiple Features

373

Allocate Multiple Contexts

Transit Nontransit
2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Proposed IP/VLAN Network Topology


VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

VLAN 5 10 20 100

IP 192.168.1.0/24 10.0.1.0/24 10.0.2.0/24 10.0.3.0/24 10.0.0.0/24

Segment Router Firewall Servers Default gateway is 10.0.1.1 IT Default gateway is 10.0.2.1 Users Default gateway is 10.0.3.1 Router ACE, used for VIP addresses

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Integrating Multiple Features

375

Designing ACE Features


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

Designing ACE Features


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

Servers

2007 Cisco Systems, Inc. All rights reserved.

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: 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.

376

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

VLAN 100: Client Flows


VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

Client Internet or internal users Internet mail servers Internal users Server admin Management users
2007 Cisco Systems, Inc. All rights reserved.

Server Web/file servers

Protocols / Processing HTTP LB HTTPS SSL offload, LB FTP LB, no delete SMTP POP, SMTP Telnet, HTTP, FTP, SSH, RDP, SNMP, X Telnet, SSH, HTTPS
ACEAP v1.01-17

Mail server Mail server servers ACE

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.

2007 Cisco Systems, Inc.

Integrating Multiple Features

377

VLAN 100: Classification Criteria


VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

Client Internet or internal users Internet mail servers Internal users Server admin Management users
2007 Cisco Systems, Inc. All rights reserved.

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 n/a n/a n/a 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

Web/file servers

Mail server Mail server Servers ACE

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

VLAN 100: Processing Actions


VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

Client Internet or internal users Internet mail servers Internal users Server admin Management users
2007 Cisco Systems, Inc. All rights reserved.

Server

Classification Criteria: Processing Actions


match virtual-address 10.0.0.14 tcp eq http: LB to WEBFarm 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

Web/file servers

Mail server Mail server Servers ACE

n/a n/a n/a 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.

2007 Cisco Systems, Inc.

Integrating Multiple Features

379

VLAN 100: ACL Entries


VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

Client Internet or internal users Internet mail servers Internal users Server admin Management users
2007 Cisco Systems, Inc. All rights reserved.

Server Web/file servers

ACL Entries
permit tcp any host 10.0.0.14 eq http permit tcp any host 10.0.0.14 eq https permit tcp any host 10.0.0.14 eq ftp

Mail server Mail server Servers ACE

permit tcp any host 10.0.1.45 eq smtp permit tcp 10.0.0.0 255.0.0.0 host 10.0.1.45 eq pop 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

VLAN 10: Client Flows


VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

Client Mail server Internal servers

Server Internet mail servers Internet servers SMTP

Protocols / Processing

HTTP, FTP (outbound)

2007 Cisco Systems, Inc. All rights reserved.

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.

2007 Cisco Systems, Inc.

Integrating Multiple Features

381

VLAN 10: Classification Criteria


VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

Client Mail server Internal servers

Server Internet mail servers Internet servers n/a n/a

Classification Criteria

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

VLAN 10: ACL Entries


VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

Client Mail server Internal servers

Server Internet mail servers Internet servers

ACL Entries permit tcp any any eq smtp permit tcp any any eq http permit tcp any any eq ftp

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-23

The figure shows the ACL entries needed for traffic from VLAN 10.

2007 Cisco Systems, Inc.

Integrating Multiple Features

383

Configuring Multiple Integrated Features


This topic describes the configuration of multiple integrated features.

Real Servers
VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

rserver host ip address inservice rserver host ip address inservice

WEBFILE1 10.0.1.50 WEBFILE2 10.0.1.51

2007 Cisco Systems, Inc. All rights reserved.

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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Server Farms
VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

serverfarm host FTPFarm rserver WEBFILE1 21 inservice rserver WEBFILE2 21 inservice serverfarm host WEBFarm rserver WEBFILE1 80 inservice rserver WEBFILE2 80 inservice
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Integrating Multiple Features

385

Class Maps
VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

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
2007 Cisco Systems, Inc. All rights reserved. ACEAP v1.01-27

The classification list for each VLAN can be translated into a class map, as shown in the figure.

386

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Layer 7 Processing
VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

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
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc.

Integrating Multiple Features

387

Layer 4 Processing
VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

policy-map multi-match WEBFILE-VIPS class HTTP-VIP loadbalance policy WEB-SLB loadbalance vip inservice class HTTPS-VIP loadbalance policy WEB-SLB loadbalance vip inservice ssl-proxy server SSL-OFFLOAD class FTP-VIP loadbalance policy FTP-SLB loadbalance vip inservice inspect ftp strict policy FTP-POLICY
2007 Cisco Systems, Inc. All rights reserved. ACEAP v1.01-29

Layer 7 processing is activated by your Layer 3 and 4 policy map, which is now defined.

388

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Management Access
VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

policy-map type management first-match MANAGEMENT-ACCESS class REMOTE-ACCESS permit

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-30

You now define the management policy map.

2007 Cisco Systems, Inc.

Integrating Multiple Features

389

ACLs
VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

access-list from-outside access-list from-outside access-list from-outside access-list from-outside access-list from-outside eq pop access-list from-outside 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
2007 Cisco Systems, Inc. All rights reserved. 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

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Interfaces
VLAN 10 VLAN 100 VLAN 5

Servers
VLAN 20 Flow Transit Nontransit

Internet

Users

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

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-32

Finally, you associate the ACLs and policy maps with the appropriate interfaces.

2007 Cisco Systems, Inc.

Integrating Multiple Features

391

Summary
This topic summarizes the key points that were discussed in this lesson.

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.

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-33

392

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Lesson 13

Summary
This topic summarizes the key points that were discussed in this lesson.

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.
2007 Cisco Systems, Inc. All rights reserved. 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.

2007 Cisco Systems, Inc. All rights reserved.

ACEAP v1.01-3

394

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

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) Application firewall Intrusion detection Dynamic IP routing Load balancing Perimeter firewall SSL encryption and decryption VPN termination

Resource minimums can be oversubscribed. (True or false.) (Source: Deploying ACE) A) B) true false

Q3)

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) Client interface Depends on the NAT configuration DMZ Server interface

Q5)

How many server farms are used in Layer 4 load balancing? (Choose two.) (Source: Layer 4 Load Balancing) E) F) G) H) one two three any number

Q6)

How many server farms are used in Layer 7 load balancing? (Choose two.) (Source: Layer 7 Protocol Processing) A) B) C) D) one two three any number

Q7)

Policy-driven Layer 7 inspection is available for which two application protocols? (Choose two.) (Source: Layer 7 Protocol Processing) A) B) C) D) E) FTP HTTP NNTP SMNP SMTP

Q8)

Which two of the following SSL/TLS versions are supported by the ACE module? (Choose two.) (Source: Processing Secure Connections) A) B) C) SSL v2 SSL v3 TLS V1

Q9)

How many ACE modules are deployed for a fault-tolerant environment? (Source: High Availability) A) B) C) D) one two three four

Q10)

What is the first step in designing an ACE deployment? (Source: Integrating Multiple Features) A) B) C) D) Analyzing Requirements Designing Topology changes Determining number of contexts Documenting Flows

396

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.

Self-Check Answer Key


Q1) Q2) Q3) Q4) Q5) Q6) Q7) Q8) Q9) Q10) A, D, F B D, E B A D A, B B, C B A

2007 Cisco Systems, Inc.

Self-Check

397

398

Implementing the Cisco ACE Appliance (ACEAP) v1.0

2007 Cisco Systems, Inc.