ACEAP10_SG

Table of Contents

Implementing the Application Control Engine Appliance 1 Overview 1

Objectives 1 Course Goal and Objectives 3 Course Flow 4 Additional References 5

Introducing the ACE 4710 Appliance 7 Overview 7

Objectives 7 IP Protocol Stack Review 8 IP Application Review 16 Web Technology Overview 29

Client/Server 47 User Agent 47 Server Caveats 47

Introducing ACE 48 Summary 61

Deploying ACE 63 Overview 63

Objectives 63 Connecting the ACE to the Network 64 ACE Installation Procedure 66 ACE Appliance GUI 69 Network Topologies 71

SNAT 73 Policy-Based Routing 74

Virtualization 81 Resource Management 90 Authorizing Management Users 99 Configuring Interfaces 107 Summary 111

Modular Policy CLI 113 Overview 113

Objectives 113 Class Maps 114

Syntax Summary 121 Policy Maps 123

Policy Type 126 Match Type 126 Syntax Summary 131

Applying Policy Maps 133 Primary Policy Maps 136 Secondary Policy Maps 136

Summary 140 Managing the ACE Appliance 141

Overview 141 Objectives 141

Permitting Management Traffic 142 SNMP Manageability 148 Summary 156

ii Implementing the Cisco ACE Appliance (ACEAP) v1.0 © 2007 Cisco Systems, Inc.

Security Features 157 Overview 157

Objectives 157 IP Access Control Lists 158 TCP/IP Fragmentation/Reassembly 160 TCP/IP Normalization 164 Network Address Translation 170 Summary 178

Layer 4 Load Balancing 179 Overview 179

Objectives 179 Load-Balancing Concepts 180

Client 1 188 Client 2 189 Client 3 189 Client 4 189

Load-Balancing Algorithms 195 Configuring Layer 4 Load Balancing 198

Monitoring rservers 198 Summary 206

Health Monitoring 207 Overview 207

Objectives 207 Health Monitoring Overview 208 Active Health Probes 214

No ip address Command in Probe 215 Optional ip address Command Without routed Keyword 216 Optional ip address routed Command 216

HTTP Error Code Monitoring 232 Using TCL Scripting 234 Summary 240

Layer 7 Protocol Processing 241 Overview 241

Objectives 241 Configuring HTTP Layer 7 Load Balancing 242 Persistent and Pipelined HTTP Extensions 250 Server Reuse 254 Session Persistence 257 Protocol Inspection 267 HTTP Inspection 268 FTP Protocol Processing 270 Other Inspected Protocols 274 Summary 281

Processing Secure Connections 283 Overview 283

Objectives 283 Digital Encryption Technologies 284 SSL Service Options 291 Configuring a Public Key Infrastructure 294 Configuring SSL Proxy Services 301 Summary 307

© 2007 Cisco Systems, Inc. Implementing the Cisco ACE Appliance (ACEAP) v1.0 iii

Deploying Application Acceleration and Optimization 309 Overview 309

Objectives 309 Web Application Acceleration Architecture 310 FlashForward 312 Delta Optimization 324

Delta Optimization Requirements 325 Delta Optimization Base Files 326 Delta Optimization Canonicalization 326

Smart Redirect 329 Fast Redirect 330 FlashConnect 331 Just-in-Time Object Acceleration 332 Adaptive Dynamic Cache 333 Compression Overview 334

Request Processing 335 Response Processing 335

Summary 338 High Availability 339

Overview 339 Objectives 339

Redundancy 340 Object Tracking 344 Failover 347 State Replication 349 Fault-Tolerance Configuration 352 Displaying Fault-Tolerance Information 358 Summary 363

Integrating Multiple Features 365 Overview 365

Objectives 365 Analyzing Network Requirements 366 Designing ACE Contexts 371 Designing ACE Features 376 Configuring Multiple Integrated Features 384 Summary 392

Summary 393 Self-Check 395

Self-Check Answer Key 397

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

2 Implementing the Cisco ACE Appliance (ACEAP) v1.0 © 2007 Cisco Systems, Inc.

© 2007 Cisco Systems, Inc. All rights reserved. ACEAP v1.0—1-2

Learner Skills and Knowledge

Familiarity with TCP/IP protocol suiteKnowledge of HTTP and SSL protocolsBasic understanding of n-tier application architectureBasic understanding of server load balancing concepts

The figure lists the skills and knowledge that you must possess to benefit fully from the course.

© 2007 Cisco Systems, Inc. Implementing the Application Control Engine Appliance 3

Course Goal and Objectives This topic describes the course goal and objectives.


Implementing the Cisco ACE Appliance

“Deploy and configure intelligent network services using the Cisco 4710 Application Control Engine appliance.”

Course Goal

Upon completing this course, you will be able to meet these objectives:

Describe IP application delivery with the Cisco Application Control Engine (ACE) appliance

Describe the configuration tasks necessary to successfully deploy an ACE appliance

Describe the structure and function of the Modular Policy CLI statements used to configure ACE features

Describe the methods used to manage the ACE appliance

Describe the ACE features that provide IP application-based security on the ACE appliance

Describe the capabilities and configuration of the ACE features used to provide load balancing of IP-based applications

Describe the health monitoring capabilities of the ACE appliance

Identify the Layer 7 processing options used to provide advanced application networking

Describe the ACE support for SSL protocol processing

Describe the ACE web application acceleration, optimization, and compression features

Describe the high-availability features of the ACE appliance, which are used to provide reliable application networking services

Describe a methodology used to design and configure multiple ACE features


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


Course FlowDay 5

Labs

WAA Features

Labs

Layer 7 Protocol Processing

Labs

Modular Policy CLI

Managing the ACE appliance

Security FeaturesLabs

Lunch

High AvailabilityIntegrating

Multiple Features

Labs

Processing Secure

Connections

Labs

Layer 4 Load Balancing

Health Monitoring

Introducing ACE

Deploying ACE

Day 4Day 3Day 2Day 1

AM

PM

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.

© 2007 Cisco Systems, Inc. Implementing the Application Control Engine Appliance 5

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 9500Multilayer Director

Cisco MDS 9200Multilayer Switch

Cisco MDS 9100Fabric Switch

Third-Party FCDirector

IP Router

Ethernet Switch

Multilayer Switches

Firewall

ACE

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



Cisco Icons and Symbols (Cont.)

iSCSI

FCHBA

NAS

Application Server

Application Serverwith FC HBA

Application Serverwith iSCSI

NAS Filer

Workstation

FC

FC

FC JBOD

FC RAIDSubsystem

FC TapeSubsystem

For more information on Cisco terminology, see the Cisco Internetworking Terms and Acronyms glossary of terms at http://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/index.htm.

Lesson 1

Introducing the ACE 4710 Appliance

Overview In this lesson, you will learn how to describe IP application delivery with the Cisco 4710 Application Control Engine (ACE) appliance and how to describe the features of the ACE appliance and compare them with those of the rest of the Cisco family of content switches.

Objectives Upon completing this lesson, you will be able to describe IP application delivery with the ACE 4710 appliance and introduce the features of the ACE 4710 appliance. This includes being able to meet these objectives:

Describe the fundamentals of IP-based communications

Describe the fundamentals of IP-based applications

Describe HTTP-based applications

Describe the Cisco 4710 Application Control Engine appliance


IP Protocol Stack Review This topic describes the fundamentals of IP-based communications.


IP Protocol Stack

Physical and data link define how IP is transmitted on individual media types.

Physical and Data Link

IP defines system-to-system communication.IP

TCP and UDP define program-to-program communication.UDPTCP

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

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.

© 2007 Cisco Systems, Inc. Introducing the ACE 4710 Appliance 9

Application protocols define the format and meaning of the data portion of a TCP or UDP packet. Examples of application protocols are the Simple Mail Transfer Protocol (SMTP), which describes how to transmit e-mail from one system to another, and the HTTP used to request and transmit web pages.

One important aspect of a layered architecture is the encapsulation of higher-level packets in lower-level packets. The lower-level protocol builds a packet that has headers appropriate to that protocol and places the higher-level packet in the data portion of the new protocol. For example, an HTTP request is contained in the data portion of a TCP packet. The headers of the TCP packet contain header values used by TCP, including the port number that is being used by the web server process on the target computer system. The TCP packet is placed in the data portion of an IP packet, which is routed to the destination system. The IP packet contains IP headers that specify items necessary for IP processing, including the IP address of the destination system. The IP packet is placed in the data portion of one or more physical frames, which are transmitted across the physical media for each link in the IP network. This frame has headers that are used by the underlying transmission medium to process the frame.

Understanding ACE operations requires an understanding of IP, TCP, and UDP.



IP Header Fields

PhysicalPhysicalHeaderHeader IP Hdr

20 bytes Protocol Data: ICMP, TCP, UDPProtocol Data: ICMP, TCP, UDP

Destination IP Address

Source IP Address

Header ChecksumProtocolTime to Live

Fragment OffsetFlags (3 bits)Identification

Total Length (in bytes)Type of ServiceHeader LengthVersion

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.


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.



UDP Header Fields


20 bytes UDP UDP HdrHdr8 bytes8 bytes Application DataApplication Data

ChecksumLength

Destination Port NumberSource Port Number

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.



TCP Header Fields


20 bytes TCP TCP HdrHdr20 bytes20 bytes Application DataApplication Data

Flags (6 bits)Reserved (6 bits)

Urgent Pointer

Window Size

TCP Checksum

Header Length

Acknowledgment Number

Sequence Number


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 sender’s 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.



TCP Connection

ServerClient

SYNSYN-ACK

ACK

DataACKData

More DataACK

FIN

ACK

ACKFIN

Initialize

Use

Close

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.


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.


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


OSI Layers

Presentation

Application

Session

Transport

Data Link

Network

Physical

ISO OSI Stack TCP/IP Stack

7

6

5

4

3

2

1

Link and Physical Protocols

IP

TCP / UDP

Application Protocols

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


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 5–7 switching or just Layer 7 switching.



IP-Based Application: HTTP

Client WebServer

GET / HTTP 1.0

ACK

HTTP/1.0 200 OK

Continuation

ACK

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.


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.



Layer 4 Switching

Client Side Server Side

1...n 1...n

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.

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.



Layer 7 Switching

123.n

SYN

SYN_ACK

1

SYN_ACK

SYN32

Layer 5–7 information– Received only after TCP connection setup– Might span multiple IP packets

Requires TCP termination and buffering

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.



Digital Encryption

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.



Stateful Packet Filtering

Outside Network Inside Network

Internet

DMZ

Web Server

YesEstablished Session

NoDMZ:!80Outside

NoInsideOutside

YesAnyInside

YesAnyDMZ

YesDMZ:80Outside

Permitted?DestinationSource

Entries for each active connection:Source and destination addressesSource and destination portsSequence numbersTCP flags

State Table

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.



Network Address Translation Terminology

Internal Network External Network

Local Addresses Global Addresses

Outside LocalInside LocalDestinationSource

Outside GlobalInside GlobalDestinationSource

Inside LocalOutside LocalDestinationSource

Inside GlobalOutside GlobalDestinationSource

Inside Systems Outside SystemsIL OL IG OG

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 terms—inside and outside, and local and global—to 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.



Network Address Translation Example

198.133.219.2510.0.0.83DestinationSource




IL OL IG OG10.0.0.83 198.133.219.25

Internal Network10.0.0.0/24

External Network198.133.219.0

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.



Network Address Translation Example 2





IL OL IG OG10.0.0.83 198.133.219.25



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.



Port Address Translation Example


198.133.219.25:8010.0.0.83:2418DestinationSource




10.0.0.84


198.133.219.25

10.0.0.83



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.



Simple Network Management Protocol

NMS

ManagedDevice

GET OIDData

SET OIDResponse

Trap

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.


Web Technology Overview This topic describes the fundamentals of HTTP applications.


HTTP

Server Response

Client Request

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.



HTTP Uniform Resource Identifiers

http://www.cisco.com:80/US/partner/index.html

HostScheme Path and/or Filename

GET /US/partner/index.html HTTP/1.1Host: www.cisco.comUser-Agent: Mozilla/5.0 (Windows; rv:1.8.1.6) Firefox/2.0.0.6Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Keep-Alive: 300Connection: keep-alive

Optional Port

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.


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.



HTTP Request Methods

HTTP Request Methods

CONNECTOPTIONS

TRACEDELETE

PUTPOST

HEADGET

Client Request

GET /US/partner/index.html HTTP/1.1Host: www.cisco.comUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6Accept: text/xml,application/xml,application/xhtml+xml, text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Keep-Alive: 300Connection: keep-alive

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.


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.



HTTP Request Headers

Client Request

GET /US/partner/index.html HTTP/1.1Host: www.cisco.comUser-Agent: Mozilla/5.0 (Windows; rv:1.8.1.6) Firefox/2.0.0.6Accept: text/xml,application/xml,application/xhtml+xml,text/html; q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Keep-Alive: 300Connection: keep-alive

The boldface text in the figure is an example of request headers (except Connection: keep-alive, 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 request-header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

Client-IP: Provides the IP address of the machine on which the client is running (not defined in RFC2616, but implemented in most client browsers).


Expect: The Expect request-header field is used to indicate that particular server behaviors are required by the client. A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request must respond with appropriate error status. The server must respond with a 417 (Expectation Failed) status if any of the expectations can not be met or, if there are other problems with the request, some other 4xx status.

From: The From request-header field, if given, should contain an Internet e-mail address for the person sending the client request. This header field can be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It should not be used as an insecure form of access protection.

Host: The Host request-header field specifies the Internet host and port number of the resource being requested. The Host field value must represent the naming authority of the origin server or gateway given by the original URL. A host without any trailing port information implies the default port for the service requested (for example, 80 for an HTTP URL). A client must include a Host header field in all HTTP/1.1 request messages.

If-Match: The If-Match request-header field is used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that one of those entities is current by including a list of the associated entity tags in the If-Match 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-to-date 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 If-Unmodified-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.


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.



HTTP Response Codes

Server Response

Client RequestGET /swa/i/logo.gif HTTP/1.1Host: www.cisco.com

HTTP/1.1 200 OKContent-type: image/gifContent-length: 4523

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


303 = See Other

304 = Not Modified

305 = Use Proxy

306 = (Unused)

307 Temporary Redirect

4XX: Client Error

400 = Bad Request

401 = Unauthorized

402 = Payment Required

403 = Forbidden

404 = Not Found

405 = Method Not Allowed

406 = Not Acceptable

407 = Proxy Authentication Required

408 = Request Timeout

409 = Conflict

410 = Gone

411 = Length Required

412 = Precondition Failed

413 = Request Entity Too Large

414 = Request-URI Too Large

415 = Unsupported Media Type

416 = Requested Range Not Satisfiable

417 = Expectation Failed

5XX: Server Error

500 = Internal Server Error

501 = Not Implemented

502 = Bad Gateway

503 = Service Unavailable

504 = Gateway Timeout

505 = HTTP Version Not Supported



HTTP Cookies

Server Response

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

HTTP/1.1 200 OKSet-cookie: id=“1234”; domain=“cisco.com”

Client RequestGET /index.html HTTP/1.1Host: www.cisco.comCookie: id= “1234”

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


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.1’s 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.



HTTP Response Headers

HTTP/1.1 200 OKCache-Control: privateContent-Type: text/html charset=UTF-8Set-Cookie: CP_GUTC=10.0.0.1.1191547089294320; path=/; expires=Tue,

28-Sep-32·01:18:09·GMT;·domain=.cisco.comServer: Apache/2.0Transfer-Encoding: chunkedDate: Fri, 21 Sept 2007 01:09:00 GMTConnection: closed

Server Response

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.


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 server’s application software.

Set-Cookie: Not a true security header, but it has security implications; used to set a token on the client side that the server can use to identify the client.

Set-Cookie2: Similar to Set-Cookie, RFC 2965 cookie definition.

Status-Code: Status code returned by the server.

Status-Text: Any additional text returned by the server on the response line.

Title: For HTML documents, the title as given by the HTML document source.

Transfer-Encoding: Type of transformation that has been applied to the message body so it can be safely transferred between the sender and recipient.

Upgrade: Additional communication protocols that are supported by the server.

URI: Some or all of the URIs by which the request-URI resource can be identified.


Vary: A list of other headers that the server looks at and that might cause the response to vary; that is, a list of headers the server looks at to pick which is the best version of a resource to send the client.

Warning: A more detailed warning message than what is in the reason phrase.

WWW-Authenticate: A list of challenges for the client from the server.



HTTP Response Content Type

Server Response

HTTP/1.1 200 OKContent-type: text/html

ORContent-type: audio/x-wav

ORContent-type: video/mpegContent-length: 4523

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.



HTTP Compression

Request Header Message Accept-Encoding: gzip,deflate

Response Header Message Content-Encoding: gzip

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: GNU’s 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.



HTML and Web Page Construction

HTML

HTML

HTML

HTML

HTML

Static Web Page Dynamic Web Page

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.



Browser Behavior

Server Response

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

HTTP/1.1 200 OK

Client/Server Because HTTP messaging depends on both a client and a server, the client’s and the server’s 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.


Introducing ACE This topic describes the features and architecture of the Cisco 4710 Application Control Engine appliance.


The Evolution of L4–L7 Services

Infrastructure simplification with Layer 4–7 services integration Converged policy creation, management, and troubleshootingReduced latency (single TCP termination for all functions)

Today

IntegratedLayer 4

andLayer 7Rules

Application Control Engine

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.



Application Control Engine Appliance

Back Panel

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.



ACE 4710 Hardware Architecture

CONTROLCONTROLPLANEPLANE

Serial Port

DATA PLANEDATA PLANE

1 Gb Ethernet

1 Gb Ethernet

1 Gb Ethernet

1 Gb Ethernet

PCI-XBUS

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


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



What’s New in ACE ?

ACE

Reflexive access lists, TCP and IP normalization, protocol fixupsHTTP inspection, RFC compliance, control on headers and payloadModular Policy CLI for integrated features configurationConfiguration rollback for quick error recovery and testingIntegrated SSL termination, with support for back-end SSLTCP reuse for HTTP (same as TCP multiplexing or TCP offload)CLI objects name completionHTTP compressionApplication optimization and acceleration

Virtualization (20 contexts):– Per-context active-standby

Role-based access control:– Predefined and user-configurable roles

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



ACE Family of Products

XML Switching

ACE 47101 Gb/s

ACE 47102 Gb/s

Appliance(1–2 Gb/s)

ACE AppScopeACE GSS

20K DNS RPS

ACE XML Gateway Manager

ACE Networking

Manager

Global Products and Tools

Application Switching

ACE XML Gateway30,000 TPS

ACE Module8 Gb/s

ACE Module16 Gb/s

ACE Module4 Gb/s

Module(4–16 Gb/s) +

Multimodule(64 Gb/s)

The figure shows ACE products available.



ACE Improvements over CSS

CSS

Up to 4 Gb/s Throughput Up to 2 Gb/s Throughput

Up to 1 M ConcurrentConnections

1 M ConcurrentConnections

Up to ~44 K L4 SustainedConnections per Second

~120 K L4 SustainedConnections per Second3x

Up to 5.6 K SSL Transactions per Second

7.5 K SSLTransactions per Second

Up to 1 Gb/s HTTP Compression Up to 1 Gb/s HTTP Compression

ACE

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.



ACE Improvements over CSS (Cont.)

CSS

ACE

No Software Licenses(Except GSLB, but GSS

Is Recommended)

Software Licensesfor Features or

Additional Performance

Per-Box Active-StandbyRedundancy Model

Active-Active(Per-Context Active Standby)

Single Configuration CLIVirtualized Configuration

per ContextIOS CLI

(Session or SSH/Telnet)

Content SwitchingFunctions Only;

Optional SSL Modules

Content Switching, SSL,Security, Optimization Features

HTML Acceleration

The figure shows ACE appliance improvements over CSS.



Application Delivery FeaturesCSS

Stateful Redundancy

Connection Persistence(HTTP 1.1)

Pipelining(HTTP 1.1)

L4 to L7 SLB

ACE SMCSM

Redundancy Per contextPer boxPer VIP orper box

Limited Limited Fully supported

TCP Terminationfor Generic Protocols X X

(Future phase)

Inband Health Checking X

TCP Reuse (Multiplexing) X X

ACE AP

Per context

X(Future phase)

X (Future phase) X

The figure shows application delivery features available with CSS, CSM, the ACE service module (SM), and the ACE appliance (AP).



Application Delivery Features (Cont.)

L7 SIP-Aware LB

L7 RDP-Aware BalancingWindows Terminal Services

KAL-AP Reporting Load to GSS

Route Health Injection

Scriptable Health Checks

HTTP Compression

CSS

X

Proprietary

Routingon CSS

ACE-SM

TCL

VRF-aware

XFuture daughter card

ACE-AP

X(Future phase)

X(Future phase)

X(Future phase)

TCL

CSM

X

TCL

X

X

The figure shows more application delivery features available with CSS, CSM, the ACE service module (SM), and the ACE appliance (AP).



Security Features

CSS ACE-SMCSM

TCP and IP Normalization X X

Layer 7 Fixups and Inspection X X

SYN Cookies (300K SYNs/sec)

X

uRPF Check X XScalable Reflexive ACLs X X

FWLBCSM recommended

ACE-AP

X(Future phase)(4M SYNs/

sec)

(Reverse sticky, future phase)

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.



Network Management Features

CSS

Graceful Service Shutdown

ACE-SMCSM

XML Interface

Embedded Device Manager(Onboard GUI) CVDM

X(Future phase)

Multidevice ManagerServer-Based GUI

Object Name Completion X

CVDM

HSE HSE

Command-Line InterfaceWebNS Supervisor IOS

ACE-AP

ANM ANM

Onboard IOS-like

The figure shows network management features available with CSS, CSM, the ACE service module (ACE SM), and the ACE appliance (ACE AP).



SSL FeaturesCSS

SSL Termination

ACE-SMSSLMCSM-S

Back-End SSL

AES Cipher-Suites X X

Export Cipher-Suites (SSLM 3.1)

Client Authentication

SSL Session Reuse

URL RewriteHREF http:// to https:// X X

ACE-AP

X(Future phase)

X(Future phase)

X(Future phase)

The figure shows SSL features available with CSS, CSM, the ACE service module (ACE SM), and the ACE appliance (ACE AP).


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

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

ACEWeb

Server

Client VLAN

Server VLAN

ACE Appliance

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.

© 2007 Cisco Systems, Inc. Deploying ACE 65


ACE VLANs

Web Client

ACEWeb

Server

ACE Appliance

Server VLAN

Client VLAN

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.


ACE Installation Procedure This topic describes the process of initially setting up the ACE appliance.


First-Time Bootup

switch login: adminPassword: admin---- Basic System Configuration Dialog ----

This setup utility will guide you through the basic configuration ofthe system. Setup configures only enough connectivity for managementof the system.

*Note: setup is mainly used for configuring the system initially,when no configuration is present. So setup always assumes systemdefaults and not the current system configuration values.

Press Enter at anytime to skip a dialog. Use ctrl-c at anytimeto skip the remaining dialogs.

Would you like to enter the basic configuration dialog (yes/no): yes

Serial Port

Power Button

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-45-to-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 startup-configuration file, a setup script guides you through the process of configuring a management VLAN on the ACE through one of its Gigabit Ethernet ports. The primary intent of the setup script is to simplify connectivity to the Device Manager GUI.



Setup Dialog

Which port is used to carry Management vlan (1 - 4)? [1]:

Configure GigabitEthernet port mode (Access/Trunk) [Trunk]:

Which vlan is used as Management vlan (2 - 4094)? [10]:

What is the Management vlan ip address [192.168.1.10]:

What is the Management vlan ip netmask [255.255.255.0]:

Configure the default gateway? (yes/no) [y]: y

What is the ip address of the default gateway [192.168.1.1]:

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


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


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

Extensive helplibrary available

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.



GUI Overview

23

4

5

1

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 theConfig > Virtual Contexts > Expert > Class Map section.

6

7

8

9

10

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.


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

Subnet A

VLAN 10 VLAN 20

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.



ACE Routed Mode

Servers Default Gateway:Content Switch IP

Content Switch Routing

Subnet AVLAN 10

Subnet BVLAN 20

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.



ACE One-Arm Mode


Subnet BVLAN 20

Subnet AVLAN 10

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.


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.



One-Arm Mode: Flows

VIP ServerIP

3

1 245

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.



Overview of Direct Server Return


Subnet B

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.



Flows of Direct Server Return

VIP Loopback IP = VIP

13

2

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.



Mixed Modes

VLAN 100 / Subnet AVLAN 101 / Subnet BVLAN 102 / Subnet C

VLAN 201 / Subnet AVLAN 202 / Subnet B

VLAN 204 Subnet EVLAN 203 Subnet D

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.



ACE Network Configuration

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


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


Virtualization This topic describes the use of multiple contexts.


Service Virtualization: System Separation

One Physical DeviceMultiple Virtual Systems

(Dedicated Control and Data Path)

Traditional device:Single configuration fileSingle routing tableLimited RBACLimited resource allocation

25% 25% 20%15%15%100%

Cisco application servicesvirtualization:

Distinct configuration filesSeparate routing tablesRBAC with contexts, roles, domainsManagement and data resource controlIndependent application rule setsGlobal administration and monitoring

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.



Multi-tier Applications

FE VirtualPartition

APP VirtualPartition

DB VirtualPartition

EnterpriseNetwork

DatabaseServers

LB

LB

LB

ApplicationServers

Front-EndServers

Firewalls

EnterpriseNetwork

Front-EndFirewalls

ACE withApplicationInfrastructureControl andApplicationSecurity

DatabaseServers

ApplicationServers

Front-EndServers

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



Multiple Load Balancers

LB

App A

EnterpriseNetwork

LB

App B

LB 2

App D

LB 1

App C

Enterprise with Growing Number of Applications

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.



Replacing Multiple Load Balancers

Virtual Partition 1

Virtual Partition 2

Virtual Partition 1

Virtual Partition 2

Virtual Partition 3

Virtual Partition 4

EnterpriseNetwork

App D

App EACE

ACE

App F

App C

App A

App B

Enterprise with Growing Number of Applications

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.



Multiple ContextsPhysical Device

Context 1Admin

ContextContext

Definition

Resource Allocation

ManagementStation

Context 2 Context 3

AAA

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

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.



Configuring Contexts

ACE-AP/Admin# show vlanVlans configured on the physical port(s)vlan33 vlan110 vlan231-238 vlan331-338 vlan431-438

ACE-AP/Admin# configEnter configuration commands, one per line. End with CNTL/Z.ACE-AP/Admin(config)# context developmentACE-AP/Admin(config-context)# allocate-interface vlan 110ACE-AP/Admin(config-context)# allocate-interface vlan 231-238ACE-AP/Admin(config-context)# exitACE-AP/Admin(config)# exit

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.



Configuring Context GUI

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.



Verifying Context Configuration

ACE-AP/Admin# show context development

Name: development , Id: 117Description:Resource-class: defaultVlans: Vlan110, Vlan231-238

ACE-AP/Admin# show runGenerating configuration....

context developmentallocate-interface vlan 110allocate-interface vlan 231-238

The show context context_name and show running-config commands can be used to verify the configuration of ACE contexts.



Verifying Context Configuration GUI

Config Status shows here

Config changes made here

The figure shows the GUI for verifying context configuration.


Resource Management This topic explains the resource management controls available on the ACE.


Resource Control

Rates Memory

Per-Context Control:Resource levels for each contextSupport for oversubscription

BandwidthData connections per secondManagement connections per secondSSL bandwidthSyslogs per second

Access listsRegular expressionsData connectionsManagement connectionsSSL connectionsXlatesSticky entries

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.



Resource Classes

ContextContext

Context

Context

Context

Context

Context

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.



Resource Class Allocation Parameters

Minimum Guarantee

Maximum Unlimited

Minimum Guarantee

Maximum Equal to Minimum

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.



Resource Oversubscription

Context 1 Minimum

Context 2 Minimum

Context 3 Minimum

Context 4 Minimum

Oversubscribed Global Pool

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-first-served basis. The figure shows four contexts, all of which are competing for resources in the global pool to satisfy requirements above their guaranteed minimums.



Configuring Resource Management

ACE-AP/Admin(config)# resource-class testingACE-AP/Admin(config-resource)# limit-resource all minimum 20%

maximum unlimited

ACE-AP/Admin(config)# context IT-labACE-AP/Admin(config-context)# member testing

Context 1 MinimumContext 2 MinimumContext 3 MinimumContext 4 Minimum

Oversubscribed Global Pool

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



Configuring Resource Management GUI

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.



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

conc-connections 0.00% 100.00% default 20.00% 200.00% gold

mgmt-connections 0.00% 100.00% default 20.00% 200.00% gold

proxy-connections 0.00% 100.00% default 20.00% 200.00% gold

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.



Resource Class show Commands (Cont.)

ACE-AP/C1# show resource usageAllocation

Resource Current Peak Min Max Denied--------------------------------------------------------------------Context: C1conc-connections 0 0 800000 7200000 0mgmt-connections 0 0 500 4500 0proxy-connections 0 0 104858 943716 0xlates 0 0 104858 943716 0bandwidth 0 0 50000000 450000000 0connection rate 0 0 100000 900000 0ssl-connections rate 0 0 100 900 0mgmt-traffic rate 0 0 12500000 112500000 0mac-miss rate 0 0 200 1800 0inspect-conn rate 0 0 600 5400 0acl-memory 0 0 7861044 78610432 0regexp 0 0 104858 1048576 0

The figure identifies resource class show commands.



Resource Usage GUI

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.


Authorizing Management Users This topic explains the process of granting access to authorized users for management tasks.


Role-Based Access Control

Command Categories

User-Accessible Commands

Rules grant:CreateModifyDebugMonitor

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)



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

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

---------------------------------------------


---------------------------------------------

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



Role: Server-Maintenance (System-defined)

Description: Server maintenance, monitoring and debugging

Number of rules: 6

---------------------------------------------


---------------------------------------------

1. Permit Modify real

2. Permit Debug serverfarm

3. Permit Debug vip

4. Permit Debug probe

5. Permit Debug loadbalance


Role: Server-Appln-Maintenance (System-defined)

Description: Server maintenance and L7 policy application

Number of rules: 5

---------------------------------------------


---------------------------------------------

1. Permit Create real

2. Permit Create serverfarm

3. Permit Create loadbalance



Role: SLB-Admin (System-defined)

Description: Administrator for all load-balancing features

Number of rules: 9

---------------------------------------------


---------------------------------------------

1. Permit Create real

2. Permit Create serverfarm

3. Permit Create vip

4. Permit Create probe

5. Permit Create loadbalance


7. Permit Modify interface



Role: Security-Admin (System-defined)

Description: Administrator for all security features

Number of rules: 8

---------------------------------------------


---------------------------------------------

1. Permit Create access-list

2. Permit Create inspect

3. Permit Create connection



5. Permit Create aaa




Role: SSL-Admin (System-defined)

Description: Administrator for all SSL features

Number of rules: 5

---------------------------------------------


---------------------------------------------

1. Permit Create ssl

2. Permit Create pki




Role: Network-Monitor (System-defined)

Description: Monitoring for all features

Number of rules: 2

---------------------------------------------


---------------------------------------------

1. Permit Monitor all

2. Permit Monitor changeto



Management Domains

Physical Appliance

ContextB

ContextA

VIP1VIP 2Farm1Farm2

VIP3Farm3Farm4SSL

cert1,2

Domain1 Domain2

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 user’s domain. If no domains are configured, all objects are part of the default domain.



Management Access Summary

Admin

Network/Security

Server Admin

Monitor

AdminContextContext ADefinition

Context BDefinition

ResourceAllocation

AdminManagement

Config

Physical Appliance

ContextB

ContextA

VIP1VIP 2Farm1Farm2

VIP3Farm3Farm4SSL

Cert1,2

Domain1 Domain2

Management Station

Role

AAA

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.



Configuring Management Users

role CONN-MGRrule 1 permit debug feature interface

domain GROUP_Aadd-object interface vlan 110

username c_mgr_a password secretenough role CONN_MGR domain GROUP_A

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.



GUI RBAC

12

3

5

4

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.


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


Interface Types

Bridge Group

Single Context

VLANINT

FTINT

BVIInt

VLANINT

VLANINT

VLANINT

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.



Configuring Interfaces

interface vlan 231description Client vlanip address 172.16.31.5 255.255.255.0no shutdown

Routed interfaces:

interface vlan 231bridge-group 3no shutdown

interface vlan 232bridge-group 3no shutdown

interface bvi 3description Server Access vlanip address 172.16.31.5 255.255.255.0no shutdown

Bridged interfaces:

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.



Shared Interfaces

Contexts can share routed interfaces.No conflicting IPs on shared interface.Intercontext traffic must be L3 routed.

ContextA

ContextB

VLAN 100192.168.100.0/24

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.



MAC Address Allocation

ID Prom

Unused3–8

Unshared VLAN2

Supervisor Layer 31

UseMAC

Shared MAC addresses:16 1K Pools globallyshared-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.




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.

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 TrafficDefine criteria used to classify traffic in class maps

Define Actions

Define processing steps to be performed on traffic in policy maps

Activate PolicyAssociate policy defined with a traffic stream

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.

© 2007 Cisco Systems, Inc. Modular Policy CLI 115


Class Map: Structure

TrafficCharacteristics

Matched

Class nameClass typeMatch criteriaMatch type

...n 1.. .. .. . .

XNot Matched

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



Class Map: Name

Class NameClass TypeMatch CriteriaMatch Type

Matched

Class Name: AuthUsers

XNot Matched

...n 1.. .. .. . .

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.



Class Map: Class Type


Matched

Class Name: AuthUsers Class Type: Layer 3/4

XNot Matched

...n 1.. .. .. . .

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.



Class Map: Match Criteria


Matched


XNot Matched

...n 1.. .. .. . .

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.



Class Map: Match All


Matched


and and = matchedXNot Matched

...n 1.. .. .. . .

The figure shows a match all condition.



Class Map: Match Any


Matched


or or = matchedXNot Matched

...n 1.. .. .. . .

The figure shows a match any condition.



Class Maps

class-map [type class_type] [match_type] class_name[linenumber] match match_criteria

General Structure:

class-map [match-all | match-any] map_nameclass-map type ftp inspect match-any map_nameclass-map type http inspect [match-all | match-any] map_nameclass-map type http loadbalance [match-all | match-any] map_nameclass-map type management [match-all | match-any] map_name

Available class map types:

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 class-map 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}


[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} header-value 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}


Policy Maps This topic describes the structure and configuration of policy maps.


Introducing Policy Maps


Define Actions

Define processing steps to be performed on traffic in policy maps


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.



Policy Map: Structure

Name Policy/Match TypePolicy namePolicy typeMatch typeClassification/action clauses

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



Policy Map: Name

Name: Passengers

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.



Policy Map: Type

Name: Passengers Type: Loadbalance

first-matchManagement

first-matchLoadbalance

all-matchHTTP Inspect

first-matchFTP Inspect

multimatchLayer 3 and 4

Match TypePolicy Type

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.


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.



Policy Map: Classification/Action Clause

Name: Passengers

Business Class Give FoodGive Legroom

Classification:– Class– Inline match

Actions defined in configuration submode

Type: Loadbalance

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.



Policy Map: class-default



Give Food

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.



Policy Map: insert-before



First ClassGive Food

Give DrinksGive Legroom

Give Food

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.



Policy Maps

policy-map [type policy_type] match_type policy_nameclass {name [insert-before name] | class-default}action_specifications

match name match_criteria [insert-before name]action_specifications

General structure:

policy-map multi-match map_namepolicy-map type inspect ftp first-match map_namepolicy-map type inspect http all-match map_namepolicy-map type loadbalance first-match map_namepolicy-map type management first-match map_name

Available policy map types:

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


policy-map type inspect ftp first-match map_name

class name

match name request-method ftp_command

deny

mask-reply

policy-map type inspect http all-match map_name


match name content expression [offset number] [insert-before map_name]

match name content length {eq bytes | gt bytes | lt bytes | range bytes1 bytes2} [insert-before map_name]

match name content-type-verification [insert-before map_name]

match name header {header_name | header_field} header-value expression [insert-before map_name]

match name header length {request | response} {eq bytes | gt bytes | lt bytes | range bytes1 bytes2} [insert-before map_name]

match name header mime-type mime_type [insert-before map_name]

match name port-misuse {im | p2p | tunneling} [insert-before map_name]

match name request-method {ext method | rfc method} [insert-before map_name]

match name strict-http [insert-before map_name]

match name transfer-encoding coding_types [insert-before map_name]

match name url expression [insert-before map_name]

match name url length {eq bytes | gt bytes | lt bytes | range bytes1 bytes2} [insert-before map_name]

permit

reset

policy-map type loadbalance first-match map_name

class [name1 [insert-before name2] | class-default]

match name1 http cookie {name2 | secondary name3} cookie-value expression [insert-before map_name]

match name http header {header_name | header_field} header-value expression [insert-before map_name]

match name http url expression [method name] [insert-before map_name]

match name source-address ip_address mask [insert-before map_name]

drop

forward

insert-http name header-value expression

serverfarm name1 [backup name2 [sticky | aggregate-state]]

set ip tos value

ssl-proxy client name

sticky-serverfarm name

policy-map type management first-match map_name


deny

permit


Applying Policy Maps This topic describes the steps necessary to activate policy maps.


Modular Policy CLI: Concepts


Define ActionsDefine processing steps to be performed on traffic in policy maps


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.



Associate Traffic Stream

Class MapTraffic

CharacteristicsMatched

Policy MapActivate Policy

Actions


Matched Actions

Actionsclass-default

Traffic Stream

The figure shows an associate traffic stream.



Multiple Traffic Streams

Class MapTraffic

CharacteristicsMatched

Policy MapActivate Policy

Actions


Matched Actions

Actionsclass-default

Traffic Stream

Traffic Stream

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.



Multilayer Processing

ClassType 1

ClassType 1

ClassType 2

ClassType 2

ClassType 2

Layer 3 and 4Management

• FTP Inspect• HTTP Inspect• Loadbalance

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.



Using service-policy

service-policy input policy_name

Attach a policy map to one or more interfaces:

ClassType 1

ClassType 1

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.



Validating Traffic Mapping

show running-config class-mapshow running-config policy-map

Display subsets of running-config:

show service-policy policy_name [detail]

Display active service:

The configured class and policy maps can be displayed by specifying the class-map or policy-map 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.



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.

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.




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.

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-accessdescription Match authorized management traffic2 match protocol telnet source-address 172.16.31.0 255.255.255.03 match protocol ssh any4 match protocol https any

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.

© 2007 Cisco Systems, Inc. Managing the ACE Appliance 143


Management Policy Map


policy-map type management first-match remote-mgmtclass remote-accesspermit

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.



Activating Management Policy Maps


policy-map type management first-match remote-mgmtclass remote-accesspermit

interface vlan 231service-policy input remote-mgmt

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.



Validating Management Policy Configuration

switch/context# show run class-map | begin remote-accessGenerating configuration....class-map type management match-any remote-accessdescription Match authorized management traffic2 match protocol telnet source-address 172.16.31.0 255.255.255.03 match protocol ssh any4 match protocol https any

switch/context# show run policy-map | begin remote-mgmtGenerating configuration....policy-map type management first-match remote-mgmtclass remote-accesspermit

switch/context# show run interface | begin 231Generating configuration....interface vlan 231service-policy input remote-mgmt

Subsets of running-config can be displayed by adding optional keywords to the show running-config 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.



Validating Management Policy Status

switch/context# show service-policy remote-mgmt

Status : ACTIVE-----------------------------------------Interface: vlan 231service-policy: remote-mgmt

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.



Configuring Context GUI

2

1

3

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.


SNMP Manageability This topic describes SNMP support for multiple contexts.


SNMP Support

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.

NMSACE

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.



Multicontext SNMP Through Admin

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.

NMSACE

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



Configuring Basic SNMP Parameters

NMSACE

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

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.com’s ACE appliance in Atlanta Data Center 1.



Configuring SNMPv1/2c Community Strings

NMSACE

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

SNMP community strings used by SNMP versions 1 and 2c are configured with the snmp-server 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.



Configuring SNMPv3 Users

NMSACE

snmp-server user nms-control auth MySecret!

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.



Configuring SNMP Traps

NMSACE

snmp-server host 10.1.1.4 grand-poobah traps version 2csnmp-server enable traps slb vserversnmp-server trap-source vlan 110

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 snmp-server host host_address community-string_username { informs | traps } version {1 {udp-port} | 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.

gdorantes

Resaltado


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



SNMP in the GUI

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




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.

Lesson 5

Security Features

Overview In this lesson, you will learn how to describe the ACE features that provide IP application-based 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

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

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]

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}

IP extended access control list entry:

TCP or UDP extended access control list entry:

ICMP extended access control list entry:

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.

© 2007 Cisco Systems, Inc. Security Features 159


Applying Security ACLs

ACE

ClientServerDestinationSource

ServerClientDestinationSource

input

output input

output

access-group {input | output} acl_name

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.


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


IP Fragmentation

Max Packet:1500 Bytes

Max Packet:9000 Bytes

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.



Packet Flow for Fragmentation

ACE Dataplane Multiprocessor

Fastpath MP

Fragmentation MP

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.



Packet Flow for Reassembly

ACE Dataplane Multiprocessor

Fastpath MP

Reassembly MP

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.



Configuration: Fragmentation and Reassembly

interface vlan 151:mtu 4000fragment chain 10fragment min-mtu 128fragment timeout 2

Reassembly can be eliminated by fragment chain 1interface config.

Interface level commands: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].

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


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

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

Configurable:icmp-guardDo Not Fragment flag (allow, clear)IP options (allow, clear, clear-invalid, drop)Minimum TTLVerify reverse path

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.



Hardware-Based TCP Normalization

Always performed on enabled interface:

src port and dest port != 0Only SYN packet allowed to create connectionTCP header >= of 20 bytesTCP header <= ip->length – ip->header_lengthurg flag cleared if urg_pointer is zeroIf urg flag not present,urg_pointer is clearedIllegal flags combinations dropped( SYN, RST, and so on)

Configurable:reserved bits allow/clear/dropurg flag allow/clear/dropsyn-data allow/dropexceed-mss allow/droprandom-seq-num-disable

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.



IP Address Spoofing Attacks

2

3

1

1 Attacker sends SYN with spoofed address

2 Target sends SYN-ACK

3 Attacker sends ACK with spoofed address

Trusted Host

Attacker Target

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.



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

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.



Randomized Sequence Numbers (Cont.)

AdjustSeq number

ACE Server

AdjustAck number

ACE Server

SEQ=Startclient + SentclientACK=StartACE + SentACE + 1

SEQ=StartACE + SentACEACK=Startclient + Sentclient + 1

SEQ=Startclient + SentclientACK=Startserver + Sentserver + 1

SEQ=Startserver + SentserverACK=Startclient + Sentclient + 1

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.



Configuring Normalization

parameter-map type connection TCPIP_PARMSreserved-bits clear

policy-map multi-match NORMALIZEclass class-defaultconnection advanced-options TCPIP_PARMS

interface vlan 110service-policy input NORMALIZEip options clear

ACE

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.


Network Address Translation This topic explains NAT and PAT.


Static NAT

Real IP Address

Inside Interface

Mapped IP Address

Outside Interface

Real IP Address

Inside Interface

Mapped IP Address

Outside Interface

Client Traffic – Destination NATServer Traffic – Source NAT

Class map identifies traffic from real IP address.Policy map action specifies outside interface.

Service policy on inside interface.

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.



Static NAT and PAT: Configuration

Real IP Address:

10.20.42.15

Inside Interface

VLAN 201

Mapped IP Address:

198.133.219.25

Outside Interface

VLAN 101

class-map internal-addrsmatch source-address 10.20.42.15 255.255.255.255

policy-map multi-match nat-internalsclass internal-addrsnat static 198.133.219.25 netmask 255.255.255.255 vlan 101

interface vlan 201service-policy input nat-internals

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.



Dynamic NAT

Mapped IP Address

Outside Interface

Real IP Address

Inside Interface

Mapped IP Address

Outside Interface

Real IP Address

Inside Interface

Client Traffic – Source NATServer Traffic – No NAT

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.

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 server-initiated traffic is not translated.



Dynamic NAT and PAT: Configuration

class-map client-trafficmatch destination-address 198.133.219.25 255.255.255.255

policy-map multi-match nat-clientsclass client-trafficnat dynamic 1 vlan 201

interface vlan 101service-policy input nat-clients

interface vlan 201nat-pool 1 10.1.1.1 10.1.1.100 netmask 255.255.255.0 pat

Mapped IP Address

10.1.1.1-10.1.1.100

Outside Interface

VLAN 201

Real IP Address:

Any

Inside Interface

VLAN 101

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.



Verifying NAT Operationsswitch/Admin# show xlateNAT from vlan14:5.1.1.2 to vlan13:6.1.1.2 count:1

switch/Admin# show conntotal current connections : 2conn-id dir prot vlan source destination state----------+---+----+----+------------+----------------+----------+1 in tcp 14 5.1.1.2:32887 13.1.1.2:23 ESTAB2 out tcp 13 13.1.1.2:23 6.1.1.1:32887 ESTAB

switch/Admin# show service-policy nat-dyninterface: vlan 14 service-policy: nat-dynclass: nat-dynnat:nat dynamic 10 vlan 13curr conns : 0 , hit count : 1dropped conns : 0client pkt count : 56 , client byte count: 3032server pkt count : 43 , server byte count: 2564

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.



Allocating from a NAT Pool

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.

Mapped IP Address

Outside Interface

Real IP Address

Inside Interface

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



Multiple NAT Pools

Step through each NAT pool until IP and port can be assignedAdvantage of multiple NAT pools: More likely to find an available xlateDisadvantages of multiple NAT pools:– Limited number of NAT pools available for system.– Performance could decrease due to searching multiple pools.

Mapped IP Address

Outside Interface

Real IP Address

Inside Interface

Multiple NAT pools can be used to enhance the chances that a new NAT translation can be created, as described in the figure.



NAT/PAT Resource Limitations

Total number of pools: 8 KTotal number of static policies: 8 KTotal number of dynamic policies: 8 KTotal number of xlates: 500 KMaximum number of addresses in a NAT pool: 64 KMaximum number of addresses in a PAT pool: 32

Mapped IP AddressReal IP AddressInside Interface Outside Interface

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




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.

Lesson 6


Overview In this lesson, you will learn how to describe the capabilities and configuration of the Cisco 4710 Application Control Engine (ACE) features used to provide load balancing of IP-based applications.

Objectives Upon completing this lesson, you will be able to describe the capabilities and configuration of the ACE features used to provide load balancing of IP-based applications. This includes being able to meet these objectives:

Describe the key concepts of server load balancing

Describe the load-balancing algorithms available

Describe the configuration of Layer 4 load balancing


Load-Balancing Concepts This lesson describes the concepts of server load balancing and explores the ACE capabilities of these features.


Real Servers

Servers

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.

© 2007 Cisco Systems, Inc. Layer 4 Load Balancing 181


Server Farm

Load Balancer

LB

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.



Multiple Server Farms

Load Balancer

LB

LB

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.



Overlapping Server Farms

Load Balancer

LB

LB

LB

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.



Virtual Server: Virtual IP Address

Load Balancer

LB

LB

LB

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.



Health Monitoring

Load Balancer

HM

HM

HM

X

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.




Farm A

ACE

12

3

4

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.



Layer 4 Switching

Client Side Server Side

1...n 1...n

Layer 4 information is always present in the first packet of theflow:– 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.

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.



Layer 7 Policy-Driven Load Balancing

Farm C Farm B

Farm A

ACE

12

3

4

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 1–3 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.


6. Farm B load balancing assigns the request to the top server.



9. Farm B load balancing assigns the request to the middle server.



3. Farm A load balancing assigns the request to the right server.



6. Farm B load balancing assigns the request to the bottom server.



9. Farm B load balancing assigns the request to the top server.



3. Farm A load balancing assigns the request to the left server.



6. Farm B load balancing assigns the request to the middle server.



9. Farm B load balancing assigns the request to the bottom server.


2. Policy assigns the request to Farm C.

3. There is only one server in Farm C, so the request is assigned to it.



Layer 7 Switching

123.n

SYN

SYN_ACK

1

SYN_ACK

SYN32

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

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



Splicing Flows Together



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.



Splicing Flows Together (Cont.)

AdjustSeq no.

ACE Server

AdjustAck no.

ACE Server

SEQ=Startclient + SentclientACK=StartACE + SentACE + 1

SEQ=StartACE + SentACEACK=Startclient + Sentclient + 1



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.



TCP Proxy Processing

Proxy or reproxy:Full TCP stack processingFull TCP state dataLayer 7 state dataLoad on more MPs256 K connections

Unproxy:Smaller memory requirementsFewer MPs involved1 million connections

Fastpath TCP/HTTP/Inspect/L7 Fastpath

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.



TCP Proxy Processing (Cont.)

Fastpath TCP/HTTP/Inspect/L7 Fastpath

switch/Admin# show stats http | include prox

SSL fin/rst msgs sent : 0 , Unproxy msgs sent : 1

Reproxied requests : 1 , Headers removed : 0

HTTP unproxy conns : 1 , Pipeline flushes : 0

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.


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

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 load-balancing algorithm often requires some knowledge of the traffic and processing characteristics of the application being load balanced.



Load Predictors

Load-balancing algorithms– Least connections with optional weight

and slow start

Monitor server load characteristicsPick optimal serverHealth monitoring must be used

Existing ConnectionsNew Connection

Load Predictors monitor one or more server load characteristics to pick the optimal or least-loaded 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 black-holing 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.



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 aroundHealth monitoring recommended

Existing ConnectionsNew Connection

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.


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

rserver host EXT-HOST1

ip address 192.168.1.11

inservice


ip address 192.168.1.12

inservice

ACE

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

---+---------------------+------+------------+----------+--------------------


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.



Configuring Server Farms


ip address 192.168.1.11

inservice


ip address 192.168.1.12

inservice

serverfarm host EXT-SERVERS

predictor roundrobin

rserver EXT-HOST1

inservice

rserver EXT-HOST2

inservice

ACE

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 load-balancing decisions made through a specific server farm. The system is still in service and available to other server farms of which it is a member.



Define Load-Balancing Policy Map

policy-map type loadbalance first-match SLB-LOGIC

class class-default

serverfarm EXT-SERVERS

ACE

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.



Define VIP with Layer 3 and 4 Class Map


class class-default


class-map match-all EXTERNAL-VIP

2 match virtual-address 198.133.219.25 tcp eq www

ACE

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 virtual-address 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 destination-address 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.



Define Layer 3 and 4 Policy Map


class class-default




policy-map multi-match CLIENT-VIPS

class EXTERNAL-VIP


loadbalance policy SLB-LOGIC

ACE

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.



Attach Policy Map to a Traffic Stream


class class-default





class EXTERNAL-VIP



access-list FROM-231 line 10 extended permit tcp any host

198.133.219.25 eq www

interface vlan 231

access-group input FROM-231

service-policy input CLIENT-VIPS

ACE

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.



Layer 4 Load Balancing in running-config


198.133.219.25 eq www




class class-default



class EXTERNAL-VIP



interface vlan 231

access-group input FROM-231

service-policy input CLIENT-VIPS

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.




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.

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

Probes

PassiveChecks

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.

© 2007 Cisco Systems, Inc. Health Monitoring 209


Passive Health Checks

Load BalancerPassiveChecks

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

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.



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.

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.



Built-in Probe Types

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.

DNSEcho TCPECHO UDPFingerFTP

HTTPHTTPSICMPIMAPPOP3

RADIUSSMTPTCPTelnetUDP

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.


DNS probe: Makes a request to resolve the domain name configured in the probe and verifies that the returned IP address is one that the probe is configured to expect.

SMTP probe: Connects to a Simple Mail Transfer Protocol (SMTP) server and sends an SMTP HELO command. The status code of the response is compared against a list of expected status codes.

POP3 probe: Makes a TCP connection to a Post Office Protocol (POP) server with credentials configured in the probe. An optional command is sent to the POP server.

IMAP probe: Makes a TCP connection to an Internet Message Access Protocol (IMAP) server with credentials configured in the probe. An optional command is sent to the IMAP server.

RADIUS probe: Sends a query to a RADIUS server for a configured username, password, and shared secret. Optionally, the ACE can be configured to specify another IP address in the request as the address of the Network Access Server requesting the authentication.



Server Status

XFaildetect # probes

failed

Passdetect # probes succeeded

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.


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>

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.



Probe IP Address Handling

pppp.pppp.ppppssss.ssss.ssssssss.ssss.ssss

Destination MACDestination IP

p.p.p.pip address p.p.p.p routedp.p.p.pip address p.p.p.ps.s.s.sNo ip address command

Probing server at s.s.s.s results in:Probe Definition

IP address s.s.s.sMAC ssss.ssss.ssss

IP address p.p.p.pMAC pppp.pppp.pppp

rserver being probed

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.


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



Probing Through Firewalls

172.16.1.2

172.16.2.2

172.16.3.2

10.0.1.2

rserver fw1

ip address 172.16.1.2

rserver fw2


rserver fw3


serverfarm fws

rserver fw1

rserver fw2

rserver fw3

probe icmp pinger

ip address 10.0.1.2

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.



Probing DSR

rserver srv1


rserver srv2


serverfarm srvs

rserver srv1

rserver srv2

class-map match-all external-vip

2 match virtual-address 198.133.219.25

probe icmp pinger

ip address 198.133.219.25

VIP 198.133.219.25

172.16.1.2

172.16.1.3

Loopback198.133.219.25

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.



DNS Probe Configuration

probe dns <probe-name>



port <port-number>

interval <seconds>





domain <name>

expect address <ip-address>

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.



RADIUS Probe Configuration

probe radius <probe-name>



port <port-number>

interval <seconds>





credentials <username> <password> [secret <shared-secret>]

nas ip address <ip-address>

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 server’s secret key.

NAS IP address: This option defines the IP address used in the Network Access Server (NAS) field of the RADIUS request. If this parameter is not configured, the IP address used to send the request to the RADIUS server is used.



UDP-Based Probe Configuration




port <port-number>

interval <seconds>





send-data <expression>

expect regex <string> [offset <number>]

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.



TCP-Based Probe Configuration




port <port-number>

interval <seconds>





open <open-timeout>



connection term forced

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.



FTP/SMTP Probe Configuration




port <port-number>

interval <seconds>


passdetect interval <seconds> count <number>


open <open-timeout>




expect status <min-number> <max-number>

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.



HTTP Probe Configuration

probe http <probe-name>



port <port-number>

interval <seconds>




open <open-timeout>




credentials <username> [<password>]

header <field-name> header-value <value>

request method {get | head} url <path>


hash <value>

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 password-protected resources.

Header: This attribute allows the specification of many HTTP header fields. Multiple header commands can be configured in a single probe.

Request method: This attribute defines the HTTP request method used and the URL to be requested from the web server.

Expected status: This attribute defines the range of HTTP status codes that indicate that the probe was successful. Multiple expect status commands can be configured in one probe.

Hash: A Message Digest 5 (MD5) hash value can be supplied for the page to be retrieved. If this parameter is not configured in the probe configuration, the ACE computes the hash on the first probe of a server. Subsequent probes compare the hash value to the configured or remembered hash value.



HTTPS Probe Configuration

probe https <probe-name>



port <port-number>

interval <seconds>




open <open-timeout>





header <field-name> header-value <value>

request method {get | head} url <path>


hash <value>

ssl cipher RSA_ANY | <cipher-suite>

ssl version SSLv2 | SSLv3 | TLSv1

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



IMAP Probe Configuration

probe imap <probe-name>



port <port-number>

interval <seconds>




open <open-timeout>




credentials <username> <password>

credentials mailbox <name>

request method <command>

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.



POP Probe Configuration

probe pop <probe-name>



port <port-number>

interval <seconds>




open <open-timeout>





request method <command>

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.



Activating Probes

rserver host ext-host1

ip address 192.168.1.11

inservice

probe get-index

rserver host ext-host2

ip address 192.168.1.12

inservice

serverfarm host ext-servers


probe pinger

rserver ext-host1

inservice

rserver ext-host2

inservice

ACE

probe icmp pinger

probe http get-index

request method get url /index.html

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



Displaying Probe Usageswitch/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

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



Explaining Show Probe Output

Probe health: INIT, FAILED, PASSED, DISABLEDSocket state: RESET, OPENING, RECEIVING, CLOSEDLast disconnect error—49 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

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



Show Commands

switch/context# show stats probe

+------------------------------------------+

+----------- Probe statistics -------------+

+------------------------------------------+

----- icmp probe ----

Total probes sent : 0 Total send failures : 0

Total probes passed : 423 Total probes failed : 25

Total connect errors : 0 Total conns refused : 0

Total RST received : 0 Total open timeouts : 0

Total receive timeout : 0

----- tcp probe ----

Total probes sent : 0 Total send failures : 0

Total probes passed : 0 Total probes failed : 8

Total connect errors : 0 Total conns refused : 0

Total RST received : 8 Total open timeouts : 0

Total receive timeout : 0

. . . . . .

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


HTTP Error Code Monitoring This topic describes the configuration of HTTP error code monitoring.


Configuring Passive Health Checks

Load BalancerPassiveChecks

serverfarm host SF1

retcode 400 404 check count

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.



Displaying HTTP Return Code Statistics

switch/context# show serverfarm SF1 retcode

serverfarm : SF1

rserver : R1

--------------------------------------

return code action total count

+------------+--------+------------+

400 count 0

401 count 0

402 count 0

403 count 0

404 count 0

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.


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>

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


MAIL_PROBE

POP3_PROBE

PROBENOTICE_PROBE

RTSP_PROBE

SSL_PROBE_SCRIPT

TFTP_PROBE



Scripted Probe Configuration

probe scripted <probe-name>



port <port-number>

interval <seconds>




script <script-name> [<script-arguments>]

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.



switch/context# show script code ECHO_PROBE_SCRIPT

#!name = ECHO_PROBE_SCRIPT

################################################################################

# scriptname : ECHO_PROBE

#

# Description :

# Script sends a text string to echo server and expects server to echo back

# Probe success only if server return the exact string sent by script

#

# ACE version:

# 1.0+

#

# Parameters:

# [debugFlag]

#

# debugFlag - default 0. Do not turn on while multiple probe suspects configured

# Example config :

# probe echoProbe script

# script ECHO_PROBE [0]

Show Commands

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.



switch/context# show script ECHO_PROBE_SCRIPT s1 rs1

script : ECHO_PROBE_SCRIPT

scripted probe : s1

instance

-----------------------------------------

probe-association(s) : (count=1)

----------------------------------

rserver : rs1

--------------- script statistics --------------

Exit code = 30001

Child PID = 1109

Exit Message = :10.7.107.51:7: probe success

Panic String =

Internal error =

Last RunStart count= 2 , Last RunStart time= Sun Feb 19 16:59:31 2006

Last RunEnd count = 2 , Last RunEnd time = Sun Feb 19 16:59:31 2006

Last Probe OK count= 2 , Last Probe OK time= Sun Feb 19 16:59:31 2006

Last ProbeFail = 0 , Last ProbeFail = Never

Last ForkFail count= 0 , Last ForkFail time= Never

Displaying Scripted Probes

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.



Scripted Probe Exit Codes

Unknown return code30009Memory allocation failure for TCL_wt qnode30008Cannot find file or buffer data30007Script error30006TCL interpreter panic30005Script probe terminated due to timeout30004Internal error: fork failed30003Probe error: server did not respond as expected30002Probe successful30001

DescriptionExit Code

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.




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 realservers.TCL scripts can be used to provide custom probe logic.

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


ip address 192.168.1.11

inservice


ip address 192.168.1.12

inservice

rserver host PHP-HOST1

ip address 192.168.1.13

inservice

rserver host PHP-HOST2

ip address 192.168.1.14

inservice

ACE

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.

© 2007 Cisco Systems, Inc. Layer 7 Protocol Processing 243


Configuring Additional Server Farms

serverfarm host EXT-SERVERS


rserver EXT-HOST1

inservice

rserver EXT-HOST2

inservice

serverfarm host PHP-SERVERS


rserver PHP-HOST1

inservice

rserver PHP-HOST2

inservice

ACE

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



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

2 match http url .*\.php

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

class class-default





class EXTERNAL-VIP



Define Layer 7 Class MapACE

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.






class DYN-CONTENT

serverfarm PHP-SERVERS

class class-default





class EXTERNAL-VIP



Define Layer 7 Load-Balancing PolicyACE

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.



Layer 7 Load Balancing in running-config


198.133.219.25 eq www


2 match virtual-address 198.133.219.25 www




class DYN-CONTENT

serverfarm PHP-SERVERS

class class-default



class EXTERNAL-VIP



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.



Nested Class Maps

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

match-any

match-all

match-all

match-any

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.



parameter-map type http HTTP_PARAM

case-insensitive




class EXTERNAL-VIP

appl-parameter http advanced-options HTTP_PARAM



Regular Expression Case SensitivityACE

By default, all regular expressions are case sensitive, but this can be changed in the parameter map and applies to all regex parsing in a class associated with the parameter map.

If you want only certain regular expressions to use case-sensitive matching, use the range regex operator. For example, use [Ii][Nn][Dd][Ee][Xx] instead of index.



Regular Expression Considerations

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

ACE

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


Persistent and Pipelined HTTP Extensions This topic explains persistent HTTP connections and pipelined HTTP requests.


HTTP 1.1: Persistent Connection

Client WebServer

SYNSYN_ACK

ACK

ACK

FIN_ACK

ACKFIN_ACK

GET /a.gif HTTP 1.1

HTTP/1.1 200 OK

ACK

ContinuationACK

ACKGET /b.gif HTTP 1.1

HTTP/1.1 200 OK

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.



HTTP 1.1: Request Pipelining

SYNSYN_ACK

ACK

ACK

FIN_ACK

ACKFIN_ACK

GET /a.gif HTTP 1.1GET /b.jpg HTTP 1.1

HTTP/1.1 200 OKHTTP/1.1 200 OK

ContinuationACK

Client WebServer

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.



Configuring Persistent RebalanceACE


persistence-rebalance

set header-maxparse-length 2048

length-exceed continue


class class-default





class EXTERNAL-VIP




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



Displaying Persistent Rebalance Statistics

switch/context# show stats http | include requests

Reuse msgs sent : 0 , HTTP requests : 7


HTTP chunks : 0 , Pipelined requests : 2

ACE

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


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


TCP Reuse

TCP1

ACE-TCP1 Pool1

TCP2

TCP3

ACE-TCP2 Pool2

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.



Configuring TCP ReuseACE


server-conn reuse


class class-default





class EXTERNAL-VIP




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.



Displaying TCP Reuse Statistics

switch/context# show stats http | include Reuse

Reuse msgs sent : 1 , HTTP requests : 4

switch/context# show stats http | include Headers


Headers inserted : 1 , HTTP redirects : 0

switch/context# show np 1 me-stats "-s icm | grep Reuse"

Reuse link update conn invalid error: 0

Reuse link update conn not on reuse erro 0

Reuse conn remove not on head error: 0

Connection Reuse Add Errors: 0

Connections Removed From Reuse Pools: 1

Connections Added To Reuse Pools: 1

ACE

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.


Session Persistence This topic explains session persistence.


The Shopping Cart Problem

Browse

Select

Buy

Empty ?!?

I will nevershop here

again. 1

2

3

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.



Session Persistence

BrowseSelectBuyThat

waseasy.

12

3

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



Sticky Methods

PhysicalHeader IP Hdr

20 bytes TCP Hdr20 bytes HTTP Request

HTTP Request/Header

Flags (6 bits)Reserved (6 bits)

Urgent Pointer

Window Size

TCP checksum

Header Length

Acknowledgment Number

Sequence Number


Destination IP Address

Source IP Address

Header ChecksumProtocolTime to Live (TTL)

Fragment OffsetFlags (3 bits)Identification

Total Length (in bytes)Type of ServiceHeader LengthVersion

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



Sticky Database Resources

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.

ACE

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.



Sticky Group Attributes

timeout sticky-timetimeout activeconnsreplicate stickyserverfarm name1 [backup name2 [sticky] [aggregate-state]]

ACE

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



IP Address Sticky Configuration

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_addressrserver rserver-name [port]

ACE

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.



Header Sticky

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

ACE

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 0–999, and the length value can be from 1–1000.



Cookie Sticky

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]

ACE

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 1–1000.

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.



Activating a Sticky Group

sticky ip-netmask 255.255.255.255 address source EXT-STICKYserverfarm EXT-SERVERS

policy-map type loadbalance http first-match SLB-LOGICclass class-default

sticky-serverfarm EXT-STICKYclass-map match-all EXTERNAL-VIP

2 match virtual-address 198.133.219.25 tcp eq wwwpolicy-map multi-match CLIENT-VIPS

class EXTERNAL-VIPloadbalance vip inserviceloadbalance policy SLB-LOGIC

ACE

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.



Displaying Sticky Entries

switch/Admin# show sticky database

sticky group : STICKY1

type : HTTP-COOKIE

timeout : 3600 timeout-activeconns : FALSE

sticky-entry rserver-instance time-to-expire flags

---------------------+--------------------------------+--------------+-------+

587583818767988700 R1:0 215961 -

switch/Admin# show stats http | include insert

Headers inserted : 1 , HTTP redirects : 0

ACE

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.


Protocol Inspection This topic explains Layer 7 protocol inspection.


Inspection in ACE

Protocol-specific inspection supported for:FTPStrict FTPRTSPICMPDNSHTTPS

ACE

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.


HTTP Inspection This topic describes HTTP inspection.


HTTP Inspection

HTTP inspection:Ensures RFC complianceSupports policy-based request filtering

ACE

The figure describes HTTP inspection.



Configuring HTTP Inspection

class-map type http inspect match-any HTTP-DONTSmatch request-method rfc tracematch port-misuse p2p

policy-map type inspect HTTP first-match HTTP-SECURITYclass HTTP-DONTS

resetmatch strict-http

resetclass-map match-all HTTP-CONNS

2 match port tcp eq httppolicy-map multi-match PROCESS-TRAFFIC

class HTTP-CONNSinspect http policy HTTP-SECURITY

ACE

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.


FTP Protocol Processing This topic explains the FTP processing capabilities of the ACE.


FTP Inspection

FTP application inspection performs the following tasks:

NATs embedded IP address and portPrepares dynamic secondary data connection

ACE

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.



Configuring FTP Inspection

policy-map type loadbalance generic first-match SLB-LOGICclass class-default

serverfarm EXT-SERVERSclass-map match-all EXTERNAL-VIP

2 match virtual-address 198.133.219.25 tcp eq ftppolicy-map multi-match CLIENT-VIPS

class EXTERNAL-VIPloadbalance vip inserviceloadbalance policy SLB-LOGICinspect ftp

access-list FROM-231 extended permit tcp any host 198.133.219.25 eq ftp

interface vlan 231access-group input FROM-231service-policy input CLIENT-VIPS

ACE

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.



Strict FTP Inspection

Strict FTP inspection:Ensures RFC complianceHides user IDsDisallows reply spoofingDisallows command pipeliningSupports policy-based command filtering

ACE

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.



Configuring Strict FTP Inspection

class-map type ftp inspect match-any DELETESmatch request-method delematch request-method rmd

policy-map type inspect ftp first-match NO-DELETESclass DELETES

denymatch syst-cmd request-method syst

mask-replyclass-map match-all FTP-CONNS

2 match port tcp eq ftppolicy-map multi-match CLIENT-VIPS

class ftp-connsinspect ftp strict policy NO-DELETES

ACE

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.


Other Inspected Protocols This topic describes the Layer 7 inspected protocols.


RTSP Inspection

RTSP application inspection performs the following tasks:

Enforced RFC 2326 compliance (TCP only)Prepares dynamic secondary data connection

ACE

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.



Configuring RTSP Inspection

class-map match-all RTSP-CONNS2 match port tcp eq rtsp

policy-map multi-match CLIENT-VIPSclass rtsp-conns

inspect rtsp

access-list FROM-231 extended permit tcp any any eq rtsp

interface vlan 231access-group input FROM-231service-policy input CLIENT-VIPS

ACE

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.



ICMP Inspection

ICMP application inspection performs the following tasks:

Creates connection state for ICMP requestsVerifies sequence numbersMatches responses to requests

ACE

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.



ICMP Error Inspection

ICMP error application inspection adds the following to ICMP inspection:

Allows error packets for existing connections by checking the embedded packetAllocates NAT translation entries for intermediate nodes or end nodes that generate errorsNAT translation applied to embedded packet

ACE

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.



Configuring ICMP Inspection

access-list ACL1 line 10 extended permit ip any any

class-map match-any ICMP-FLOWSmatch access-list ACL1

policy-map multi-match FIXUP-ICMPclass ICMP-FLOWS

inspect icmp error

access-list FROM-231 extended permit ip any any

interface vlan 231access-group input FROM-231service-policy input FIXUP-ICMP

ACE

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.



DNS Inspection

DNS application inspection performs the following tasks:

Matches DNS responses to requestsApplies NAT translation to A recordsPerforms maximum-length checkPerforms security checks

ACE

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.



Configuring DNS InspectionACE

class-map match-all DNS-L4-INSPECT-CLASSmatch port udp eq domain

policy-map multi-match DNS-L4-INSPECT-POLICYclass DNS-L4-INSPECT-CLASS

inspect dns maximum-length 1000

interface vlan 231service-policy input DNS-L4-INSPECT-POLICY

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.




Summary

Load-balancing decisions can be made by analyzing the Layer 7 application data.Persistent and pipelined client connections can be rebalanced bythe 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.

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

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.

© 2007 Cisco Systems, Inc. Processing Secure Connections 285


Asymmetric Encryption

Jane JohnKey 1

Key 1 Key 2

Key 2

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.



Public Key Encryption

Key 2

Key 2

Key 2

Key 1

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 server’s 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.



Digital Signatures

Hash Hash

Equal?Signature

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 signer’s 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.



Certificates

Public Key

Private Key

CertificateSigning Request

Public KeyCommon nameDomain name

LocationE-mail

CertificateSigning Request

Public KeyCommon nameDomain name

LocationE-mail

ValidationProcess

Server Public KeyServer Public Key

Application ApplicationCompany Docs

Key Pair

Server Private Key

Certificate Authority

SSL Server

CertificateCertificate

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.



SSL Fundamentals: Key Exchange Packet Flow Overview

Server Public Key

RandomNumber

GeneratorRSA

Encrypt

Shared Secret Key

Shared SecretEncrypt & Decrypt

Client Browser

Server Public Key

RSA Encrypt

Shared Secret Key

Shared SecretEncrypt & Decrypt

Server

Private Key

Data

Data Data

Public Key

Client Hello

Server Hello

SAasdfkjw1340+jakjb//alkjt


Data Exchange


Key Exchange

Data

Certificate

Secure Sockets Layer (SSL) uses a combination of public key encryption and symmetric encryption.

Public key encryption is used to initiate an SSL session using the following steps:

Step 1 The client sends a client hello packet to the server.

Step 2 The server sends a server hello set of packets to the client. Included in these packets is a copy of the server’s certificate.

Step 3 The client uses the certificate to verify the identity of the server.

Step 4 The client creates a session key to be used as a shared key for symmetric encryption.

Step 5 The client encrypts the session key with the server’s public key.

Step 6 The server decrypts the session key with its private key.

Step 7 Both systems encrypt further traffic with the shared key.



SSL v2/3 hybrid hello100,000 simultaneous connectionsConnections fully proxied all the timeWeighted cipher suite selectionNo SSL-related HTTP header insertion

ACE SSL CharacteristicsACE

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


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


SSL Termination

ACE

Encrypted

Unencrypted

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.



SSL Initiation

ACE

Encrypted

Unencrypted

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.



End-to-End Encryption

ACE

Encrypted

Unencrypted

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.


Configuring a Public Key Infrastructure This topic describes the steps needed to configure a public key infrastructure.


Supported key sizes (in bits): 512, 1024, 1536, 2048Certificate support:– Import of certificates for the following formats: PEM,

DER, and PKCS12– Generation of certificate signing request

PKI Resource FormatsACE

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.



crypto generate key [non-exportable] bitsize filename

Generating a Public/Private Key PairACE

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.



crypto csr-params myCSRconfigcountry-name “US”state “GA”locality “Atlanta”org-name “Example Inc”org-unit “SSL Acceleration Testing”common-name “www.example.com”serial-number “1001”email “[email protected]”

Configuring Certificate Signing Request Parameters

ACE

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.



Generating Certificate Signing Request

switch/context(config) # crypto generate csr myCSRconfig mykey.pem-----BEGIN CERTIFICATE REQUEST-----MIIBcDCCARoCAQAwgbQxCzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlTb21lU3RhdGUxETAPBgNVBAcTCFNvbWVDaXR5MRcwFQYDVQQKEw5BIENvbXBhbnkgTmFtZTEbMBkGA1UECxMSV2ViIEFkbWluaXN0cmF0aW9uMR0wGwYDVQQDExR3d3cuYWNvbXBhbnluYW1lLmNvbTEpMCcGCSqGSIb3DQEJARYad2ViYWRtaW5AYWNvbXBhbnluYW1lLmNvbSAwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAtBNcNXMBqh5cJHbWFsqe9LMUO90TpYG7gF5ODvtFGREMkHh7s6S1GF131IBWCSelG4Q/qEztjCO7y3pyjruVNQIDAQABoAAwDQYJKoZIhvcNAQEEBQADQQCMmXRdNPBDtMQPFvylpED5UMbeaMRm2iaC+1uZIaHmdoX4h5eckauu9pPgSxczau8w68PF+PDS9DAAMeRDxisL-----END CERTIFICATE REQUEST-----switch/context(config) #

ACE

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.



Transferring PKI ResourcesACE

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}

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.



Listing PKI ResourcesACE

switch/context(config) # show crypto filesFilename File File Expor Key/

Size Type table Cert----------------------------------------------------mycert.pem 1275 PEM No CERTmykey.pem 283 PEM Yes KEY

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.



Managing PKI Resources

Delete a PKI resource:

crypto delete {filename | all}

View a PKI resource:

show crypto {cert | key} [filename]

ACE

PKI files can be deleted with the crypto delete command. They can also be displayed on the console with the show crypto command.


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


Configuring SSL Termination

ssl-proxy service secure_accesskey myrsakey_servercert mycert_server

class-map match-all external-vip2 match virtual-address 198.133.219.25 tcp eq https

policy-map type loadbalance first-match slb-logicclass class-default

serverfarm ext-serverspolicy-map multi-match client-vips

class external-vipssl-proxy server secure_accessloadbalance vip inserviceloadbalance policy slb-logic

ACE

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.



crypto chaingroup InternalCAcertscert rootCA.pemcert ouCA.pemcert deptCA.pem

ssl-proxy service secure_accesskey myrsakey_servercert mycert_serverchaingroup InternalCAcerts

Configuring SSL Certificate ChainsACE

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.



parameter-map type ssl only-ssl3version ssl3

ssl-proxy service secure_accesskey myrsakey_servercert mycert_serverssl advanced-options only-ssl3

Configuring SSL Protocol OptionsACE

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.



Configuring SSL Initiation

ssl-proxy service backend_ssl

class-map match-all external-vip2 match virtual-address 198.133.219.25 tcp eq http

policy-map type loadbalance first-match slb-logicclass class-default

serverfarm ext-serversssl-proxy client backend_ssl

policy-map multi-match client-vipsclass external-vip

loadbalance vip inserviceloadbalance policy slb-logic

ACE

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.



Configuring SSL End-to-End

ssl-proxy service secure_accesskey myrsakey_servercert mycert_server

ssl-proxy service backend_sslclass-map match-all external-vip2 match virtual-address 198.133.219.25 any

policy-map type loadbalance first-match slb-logicclass class-defaultserverfarm ext-serversssl-proxy client backend_ssl

policy-map multi-match client-vipsclass external-vipssl-proxy server secure_accessloadbalance vip inserviceloadbalance policy slb-logic

ACE

The figure shows SSL end-to-end configuration.



What Did Not Make It into ACE SSL v1.0

Client authenticationSession cache reuseIntegration with high availabilitySSL statistics and SSL MIBSSL rehandshake based on time or data transferredURL rewriteHTTP header insertionFederal Information Processing Standard (FIPS) 140-2

ACE

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




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 tosupport SSL.SSL services on the ACE appliance are provided through SSL proxies.

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

CONTROLCONTROLPLANEPLANE

DATA PLANEDATA PLANE

Serial Port

1 Gb Ethernet

1 Gb Ethernet

1 Gb Ethernet

1 Gb Ethernet

PCI-XBUS

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.

© 2007 Cisco Systems, Inc. Deploying Application Acceleration and Optimization 311


DP Components

Vip1Vip2…VipnC

lient

Rse

rverIF IF

C1 S1

AVS Traffic Flow

Vip Internal (127.1.0.193)Vip1Vip2…Vipn

Control Plane Components

S2 C2

IF: 127.1.0.128

IF: 127.1.0.192

Private HTTP headers are exchanged.Persistence rebalance is used.

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.


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


GET Index.htmlHTTP 200 OK

GET Foo.gif

GET Foo.js

HTTP 200 OK

HTTP 200 OK

GET Foo.jpg

GET Foo.css

HTTP 200 OK

HTTP 200 OKGET bar.gif

GET bar.js

HTTP 200 OK

HTTP 200 OK

Normal Browser Behavior

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.



IMS Index.htmlHTTP 200 OK

IMS Foo.gif

IMS Foo.js

304 Not Modified

304 Not Modified

IMS Foo.jpg

IMS Foo.css

304 Not Modified

304 Not ModifiedIMS bar.gif

IMS bar.js

HTTP 200 OK

HTTP 200 OK

Normal Browser Behavior: Return Visit

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.



GET Index.html

2. ACE forwards request to server.

1. Client requests HTML page.

GET Index.html

FlashForward: Priming the Cache

HTTP 200 OKHTTP 200 OK

3. Server responds to request with HTML object page.4. ACE passes unaltered HTML

object page to client.

Un-modified

HTMLpage

Un-modified

HTMLpage

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.



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

1. Client requests altered objects from HTML object page.

FlashForward: Priming the Cache (Cont.)

3. Server responds to request with objects.

4. ACE checks whether items can be FlashForwarded; if true, they are cached.ACE forwards objects unaltered to client.

GET Foo.jpgGET Foo.css

GET Foo.gifGET Foo.js

GET bar.gifGET bar.js

200 OK Foo.jpg200 OK Foo.css

200 OK Foo.gif200 OK Foo.js

200 OK bar.gif200 OK bar.js

GET Foo.jpgGET Foo.css

GET Foo.gifGET Foo.js

GET bar.gifGET bar.js

200 OK Foo.jpg200 OK Foo.css

200 OK Foo.gif200 OK Foo.js


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.



GET Index.html

ACE forwards request to server.Client requests HTML page.

GET Index.html

FlashForward: First Visit After Priming Cache

HTTP 200 OKHTTP 200 OK

Server responds to request with HTML object page.

Un-modified

HTMLpage

ModifiedHTMLpage

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.

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.



ACE proxies the request, checks cache for FF objects, and sends IMS message for objects to server to verify freshness.

Client requests altered objects from HTML object page.

FlashForward: First Visit after Priming Cache (Cont.)

Server responds to request with objects.

ACE checks whether items can be FlashForwarded; if true, they are cached. ACE forwards objects unaltered to client.

GET Cisco_FF_MD5_Foo.jpgGET Cisco_FF_MD5_Foo.css

GET Cisco_FF_MD5_Foo.gifGET Cisco_FF_MD5_Foo.js

GET Cisco_FF_MD5_bar.gifGET Cisco_FF_MD5_bar.js

304 NM Foo.jpg304 NM Foo.css

304 NM Foo.gif304 NM Foo.js


IMS Foo.jpgIMS Foo.css

IMS Foo.gifIMS Foo.js

IMS bar.gifIMS bar.js

200 OK Cisco_FF_MD5_Foo.jpg200 OK Cisco_FF_MD5_Foo.css

200 OK Cisco_FF_MD5_Foo.gif200 OK Cisco_FF_MD5_Foo.js

200 OK Cisco_FF_MD5_bar.gif200 OK Cisco_FF_MD5_bar.js

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



GET Index.html

ACE forwards request to server.Client requests HTML page.

GET Index.html

FlashForward: Second Visit

HTTP 200 OK

Server responds to request with HTML object page.

Un-modified

HTMLpage

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.



FlashForward: Second Visit (Cont.)

ACE checks whether objects are FF-able and cached. If so, ACE verifies freshness of objects with IMS messages to server.

Un-modified

HTMLpage

200 OK Foo.jpg304 NM Foo.css

304 NM Foo.gif304 NM Foo.js

304 NM bar.gif304 NM bar.js

IMS Foo.jpgIMS Foo.css

IMS Foo.gifIMS Foo.js

IMS bar.gifIMS bar.js

ModifiedHTMLpage

Transformed object reference: <img src= “/images/Foo_CISCO_AAC_FLASHFORWARD_vtmmi14xg2fvmlkxsxuk0ty1xd_V02.jpg”>

Object reference:<imgsrc=“/images/Foo.jpg”>

HTTP 200 OKIndex.html

The figure shows browser behavior with FlashForward for subsequent visits.



Client requests altered object from Modified HTML object page.

FlashForward: Second Visit (Cont.)

Client reassembles page from new received object and cached objects on client user agent.

GET Foo_CISCO_AAC_FLASHFORWARD_vtmmi14xg2fvmlkxsxuk0ty1xd_V02..jpg

200 OK Foo_CISCO_AAC_FLASHFORWARD_vtmmi14xg

2fvmlkxsxuk0ty1xd_V02..jpg

ACE responds to request with FlashForward object from cache.

The figure shows browser behavior with FlashForward for subsequent visits.



class-map type http loadbalance match-all CM-FFmatch 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

Define FlashForward OptimizationACE

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.



class-map type http loadbalance match-all CM-FFObjectmatch http url .*gifmatch http url .*jpg

action-list type optimization http ACTION-LIST-2flashforward-object

parameter-map type optimization http ParMap-FFObject

cache ttl max 60

cache ttl min 0


class CM-FFObject

action ACTION-LIST-2 parameter ParMap-FFObject

Define FlashForwardObject OptimizationACE

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 http url .*jpg match http url .*jpeg match http url .*jpe match http url .*png match http url .*vbs match http url .*xsl match http url .*xml match http url .*pdf match http url .*swf match http url .*gif match http url .*css match http url .*js match http url .*class match http url .*jar match http url .*cab match http url .*txt match http url .*ps



class-map type http loadbalance match-all CM-FFmatch http url .*

class-map type http loadbalance match-all CM-FFObjectmatch http url .*gifmatch http url .*jpg

action-list type optimization http ACTION-LIST-1flashforward

action-list type optimization http ACTION-LIST-2flashforward-object

parameter-map type optimization http ParMap-FF

parameter-map type optimization http ParMap-FFObject

cache ttl max 60

cache ttl min 0


class CM-FF

action ACTION-LIST-1 parameter ParMap-FF

class CM-FFObject

action ACTION-LIST-2 parameter ParMap-FFObject


class VIP-170

optimize http policy PolMap-Opt

FlashForward Config

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.


Delta Optimization This topic explains the use of delta optimization and its benefits.


Delta Optimization Methodology

Server Response

1st Client Request1

2ACE Response (j-script) 70KB

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


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



Delta Optimization Methodology (Cont.)

3

4

2nd Client Request

Server Response

ACE Response (delta j-script) 2KB

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:

— This reduces the overall size of the deltas and increases performance.



Troubleshooting Delta Optimization

Internet Explorer does not handle certain compressed objects, especially JavaScript.Works only on pages up to 250 k.Sometimes Internet Explorer is confused when JavaScript is deltaoptimized:– 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.

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:

Client’s browser must match those listed in useragent.conf.

Client’s browser must support JavaScript.

Client’s 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.


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.


Smart Redirect This topic explains the use of smart redirect and its benefits.


HTTP/1.1 302 FoundLocation: http://www.cisco.com

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>

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


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


Fast Redirect

302 ResponseClient Request

200 Response

Fast Redirect R

equest

1 2

34

5200 Response

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 server’s response.

4. The redirection server responds to the ACE.

5. The ACE forwards the content from the redirection server seamlessly to the client.


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


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

FlashConnect

ACE Response Server Response

<html><img src="img1.jpg"><img src="img2.jpg"><img src="img3.jpg"><img src="img4.jpg"></html>

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


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


Just-in-Time Object Acceleration

ACE Response

Client RequestIs the requested

object larger than 250K?

OrIs this object

marked as expired or noncacheable?

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.


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.

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.


Compression Overview This topic describes HTTP compression.


HTTP Performance over a WAN

The figure shows HTTP performance over a WAN.



HTTP Compression

HTTP standards-basedCompression algorithms for deflate and gzip

Request Processing Parse for the following headers:

— Accept-Encoding (includes deflate and gzip)

— User-Agent (browser software)

Determine compression support:

— Compression method present in Accept-Encoding

— Browser supported

Modify:

— Remove the Accept Encoding: xxx header

— Insert Accept Encoding: Identity header

Response Processing Parse for the following headers:

— Content-Length (length of returned content)

— Content-Type (type of resource)

Determine compression support:

— Length over minimum

— MIME type allowed

— No Cache-Control: No-Transform header

Compress response:

— Remove Content-Length header

— Add Transfer-Encoding Chunked header



policy-map type loadbalance first-match slb-logic

class class-default

serverfarm ext-servers

compress default-method gzip



policy-map multi-match client-vips

class external-vip


loadbalance policy slb-logic

Enabling Compression

ACE

The figure shows how to enable compression.



Compression ParametersACE

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



policy-map multi-match client-vips

class external-vip


loadbalance policy slb-logic

appl-parameter http advanced-options COMPRESSION_PARMS

The figure shows compression parameters.




SummaryWAA 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 objectsHTTP compression is HTTP standards based. Compression algorithms include deflate and zip.

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

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.

ACE-1

ACE-2

FT VLAN

AActive

A′Standby

FTgroup 1

BActive

B′Standby

FTgroup 2

CActive

C′Standby

FTgroup 3

DActive

D′Standby

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

© 2007 Cisco Systems, Inc. High Availability 341


Fault-Tolerant VLAN

Designated fault-tolerant VLAN between ACE pairUsed for redundancy-related trafficConfigured in Admin context

ACE-1

ACE-2

FT VLAN

AActive

A′Standby

FTgroup 1

BActive

B′Standby

FTgroup 2

CActive

C′Standby

FTgroup 3

DActive

D′Standby

FTgroup 4

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.



Query VLAN

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

ACE-1

ACE-2

FT VLAN

AActive

A′Standby

FTgroup 1

BActive

B′Standby

FTgroup 2

CActive

C′Standby

FTgroup 3

DActive

D′Standby

FTgroup 4

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.



Configuration Synchronization

Bulk sync of the entire configuration at startupConfiguration changes disabled on standbyIncremental sync of configuration changesSync both running-config and startup-configConfigurable per context

ACE-1

ACE-2

FT VLAN

AActive

A′Standby

FTgroup 1

BActive

B′Standby

FTgroup 2

CActive

C′Standby

FTgroup 3

DActive

D′Standby

FTgroup 4

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


Object Tracking This topic explains object tracking.


Object Tracking

Active

Interface

RELINQUISH

HSRP Group

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.

Host

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.



Interface Tracking

ft track interface vlan-example

track-interface vlan 204

peer track-interface vlan 204

priority 150

peer priority 100

ACE: Track VLAN

ft

X

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.



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 100ACE: track Host

X

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.


Failover This topic explains the failover recovery process.


Virtual MAC Addresses

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.

ACE-1

ACE-2

FT VLAN

AActive

A′Standby

FTgroup 1

BActive

B′Standby

FTgroup 2

CActive

C′Standby

FTgroup 3

DActive

D′Standby

FTgroup 4

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.



Failover Actions

New active ACE appliance:Sends dummy multicast for every VLAN-VMAC pairSends gratuitous ARPs for alias and VIP addressesSends ARP request for gateway in bridged mode

ACE-1

ACE-2

FT VLAN

AActive

A′Standby

FTgroup 1

BActive

B′Standby

FTgroup 2

CActive

C′Standby

FTgroup 3

DActive

D′Standby

FTgroup 4

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.


State Replication This topic explains state replication between ACE appliances.


Connection Replication

ACE-1

ACE-2

FT VLAN

AActive

A′Standby

FTgroup 1

BActive

B′Standby

FTgroup 2

CActive

C′Standby

FTgroup 3

DActive

D′Standby

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

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.



Connection Replication Statistics

ACE-1

ACE-2

FT VLAN

AActive

A′Standby

FTgroup 1

BActive

B′Standby

FTgroup 2

CActive

C′Standby

FTgroup 3

DActive

D′Standby

FTgroup 4

show conn

show rserver

show serverfarm

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.



Sticky Replication

ACE-1

ACE-2

FT VLAN

AActive

A′Standby

FTgroup 1

BActive

B′Standby

FTgroup 2

CActive

C′Standby

FTgroup 3

DActive

D′Standby

FTgroup 4

Independent from connection replicationEnabled in the sticky group configurationBulk and periodic sync processesMultiple sticky entries per replication packet

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.


Fault-Tolerance Configuration This topic describes the information used to create appliance and context fault-tolerant configurations.


Configuring a Fault-Tolerant Interface

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-interface vlan 99

Fault -tolerant VLAN interface configuration:

Query VLAN interface configuration (optional):

ACE-1

ACE-2

FT VLAN

AActive

A′Standby

FTgroup 1

BActive

B′Standby

FTgroup 2

CActive

C′Standby

FTgroup 3

DActive

D′Standby

FTgroup 4

QUERYVLAN

Configuration of fault-tolerant and query VLAN interfaces is shown in the figure. This is configured in the Admin context.



Configuring Peer Redundancy

ft peer 1

ft-interface vlan 100

heartbeat count 20

heartbeat interval 200

Fault-tolerant peer configuration:

AActive

A′Standby

FTgroup 1

BActive

B′Standby

FTgroup 2

CActive

C′Standby

FTgroup 3

DActive

D′Standby

FTgroup 4

ACE-1

ACE-2

FT VLAN QUERYVLAN

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



Configuring Fault-Tolerant Groups

ft group 1associate-context SOME-CONTEXTpeer 1priority 100peer priority 50preemptinservice

Fault-tolerant group configuration:

AActive

A′Standby

FTgroup 1

BActive

B′Standby

FTgroup 2

CActive

C′Standby

FTgroup 3

DActive

D′Standby

FTgroup 4

ACE-1

ACE-2

FT VLAN QUERYVLAN

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.



Fault-Tolerant Configuration Synchronization

ft auto-sync running-configft auto-sync startup-config

Fault-tolerant config auto-sync:

AActive

A′Standby

FTgroup 1

BActive

B′Standby

FTgroup 2

CActive

C′Standby

FTgroup 3

DActive

D′Standby

FTgroup 4

ACE-1

ACE-2

FT VLANQUERYVLAN

ACE/Admin# sh context AdminFT Auto-sync running-cfg configured state: enabledFT Auto-sync running-cfg actual state: disabledFT Auto-sync startup-cfg configured state: enabledFT Auto-sync startup-cfg actual state: disabled

Fault-tolerant config auto-sync verification:

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



Forcing a Failover

ft switchcover [group-id] [force]

Failing over fault-tolerant contexts:

AActive

A′Standby

FTgroup 1

BActive

B′Standby

FTgroup 2

CActive

C′Standby

FTgroup 3

DActive

D′Standby

FTgroup 4

ACE-1

ACE-2

FT VLAN QUERYVLAN

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



Fault-Tolerant Sticky Replication Configuration

sticky ip-netmask 255.255.255.255 address source EXT-STICKYreplicate sticky

Fault-tolerant sticky configuration:

AActive

A′Standby

FTgroup 1

BActive

B′Standby

FTgroup 2

CActive

C′Standby

FTgroup 3

DActive

D′Standby

FTgroup 4

ACE-1

ACE-2

FT VLAN QUERYVLAN

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.


Displaying Fault-Tolerance Information This topic describes the information used to monitor fault-tolerant configurations.


Show Fault-Tolerant PeerACE/Admin# sh ft peer detail

Peer Id : 1

State : FSM_PEER_STATE_COMPATIBLE

Maintenance mode : MAINT_MODE_OFF

FT Vlan : 60

My IP Addr : 12.1.1.1

Peer IP Addr : 12.1.1.2

Query Vlan : Not Configured

Peer Query IP Addr : 0.0.0.0

Heartbeat Interval : 100

Heartbeat Count : 10

Tx Packets : 13

Tx Bytes : 2838

Rx Packets : 9

Rx Bytes : 1644

Rx Error Bytes : 0

Tx Keepalive Packets : 0

Rx Keepalive Packets : 0

SRG Compatibility : COMPATIBLE

License Compatibility : COMPATIBLE

FT Groups : 1

The show ftp peer detail command is used to display information detailing the state of a fault-tolerant peer.



Show Fault-Tolerant GroupACE/Admin# sh ft group detail

FT Group : 1

Configured Status : in-service


My State : FSM_FT_STATE_ACTIVE

My Config Priority : 120

My Net Priority : 120

My Preempt : Enabled

Peer State : FSM_FT_STATE_STANDBY_HOT

Peer Config Priority : 50

Peer Net Priority : 50

Peer Preempt : Enabled

Peer Id : 1

Last State Change time : Thu Feb 2 06:38:13 2006

No. of Contexts : 1

Context Name : Admin

Context Id : 0

switch/Admin#

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.



Show Fault-Tolerant Stats

ACE/Admin# show ft stats

HA Heartbeat Statistics

------------------------

Number of Heartbeats Sent : 431

Number of Heartbeats Received : 435

Number of Heartbeats Missed : 0

Number of Unidirectional HB's Received : 5

Number of HB Timeout Mismatches : 0

Num of Peer Up Events Sent : 1

Num of Peer Down Events Sent : 0

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



Show Fault-Tolerant Track

ACE/Admin# sh ft track detail

FT Group : 1

Status : in-service







Context Id : 0

Track type : TRACK_INTF

Vlan Id : 40

State : TRACK_UP

Priority : 50

Transitions : 1

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.



Show Fault-Tolerant Track (Cont.)

ACE/Admin# show ft track detail

FT Group : 1

Status : in-service







Context Id : 0

Track type : TRACK_INTF

Vlan Id : 40

State : TRACK_DOWN

Priority : 50

Transitions : 2

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.




Summary

ACE redundant pairs can be active or standby on a per-context basis.Object tracking allows active functions to be moved to a standbyACE 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 sessionsFault-tolerant state information can be displayed with show commands.

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

Router

ACE

Servers

Traffic flows needing LB, SSL, or security processingManagement granularityIP/VLAN network topology

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.

© 2007 Cisco Systems, Inc. Integrating Multiple Features 367


Sample Network

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

Internet

Users

Servers

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.



Document Flows

Internet

Users

Servers

SMTPInternet mail serversMail server

Telnet, HTTP, FTP, SSH, RDP, SNMP, XServersServer adminPOP, SMTPMail serverInternal users

SMTPMail serverInternet mail servers

HTTP – LBHTTPS – SSL offload, LBFTP – LB, no delete

Web/file serversInternet or internal users

Protocols / ProcessingServerClient

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.



Management Access Needed

Configure/monitor all functionsACENetwork admins

Monitor VIP statusVIPsServer admins

Monitor VIP statusVIPsHelpdesk

Remove from/return to serviceWeb/file serversServer admins

FunctionResourceManager

Internet

Users

Servers

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.



Users

IP/VLAN Network TopologyVLAN 5VLAN 10

VLAN 20

Router – Firewall192.168.1.0/245

IT – Default gateway is 10.0.2.1Users – Default gateway is 10.0.3.1

10.0.2.0/2410.0.3.0/24

20

Servers – Default gateway is 10.0.1.110.0.1.0/2410

SegmentIPVLAN

InternetServers

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.


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


Designing ACE Contexts

Router

ACE

Servers

Always use at least one context in addition to AdminIdentify network segments where multiple flows transitAllocate contexts to topology points with common functional, management, resource, and redundancy requirementsSplit contexts for ease of configurationDesign topology changes

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.



Transit Segments

Flow

Transit

Nontransit


Telnet, HTTP, FTP, SSH, RDP, SNMP, XServersServer adminPOP, SMTPMail serverInternal users





Users

VLAN 5VLAN 10

VLAN 20

InternetServers

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.



Allocate Single Context

Transit

Nontransit

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.



Allocate Multiple Contexts

Transit

Nontransit

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.



Proposed IP/VLAN Network Topology

Router – ACE, used for VIP addresses10.0.0.0/24100

Router – Firewall192.168.1.0/245

IT – Default gateway is 10.0.2.1Users – Default gateway is 10.0.3.1

10.0.2.0/2410.0.3.0/24

20

Servers – Default gateway is 10.0.1.110.0.1.0/2410

SegmentIPVLAN

VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

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.


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


Designing ACE Features

Router

ACE

Servers

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

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.



VLAN 100: Client Flows

Telnet, SSH, HTTPSACEManagement users

Telnet, HTTP, FTP, SSH, RDP, SNMP, XserversServer admin

POP, SMTPMail serverInternal users





VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

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.



VLAN 100: Classification Criteria

match protocol telnet 10.0.2.0 255.255.255.0match protocol https 10.0.2.0 255.255.255.0match protocol ssh 10.0.2.0 255.255.255.0

ACEManagement users

n/aServersServer admin

n/aMail serverInternal users

n/aMail serverInternet mail servers

match virtual-address 10.0.0.14 tcp eq httpmatch virtual-address 10.0.0.14 tcp eq httpsmatch virtual-address 10.0.0.14 tcp eq ftpmatch FTP request-method dele or rmd


Classification CriteriaServerClient

VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

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.



VLAN 100: Processing Actions

match protocol telnet 10.0.2.0 255.255.255.0: permitmatch protocol https 10.0.2.0 255.255.255.0: permitmatch protocol ssh 10.0.2.0 255.255.255.0: permit

ACEManagement users

n/aServersServer adminn/aMail serverInternal users

n/aMail serverInternet mail servers

match virtual-address 10.0.0.14 tcp eq http: LB to WEBFarmmatch virtual-address 10.0.0.14 tcp eq https: LB to WEBFarm, sslmatch virtual-address 10.0.0.14 tcp eq ftp: LB to FTPFarm, inspectmatch FTP request-method dele or rmd: deny


Classification Criteria: Processing ActionsServerClient

VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

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.



VLAN 100: ACL Entries

n/aACEManagement users

permit tcp 10.0.2.0 255.255.255.0 10.0.1.0 255.255.255.0ServersServer admin

permit tcp 10.0.0.0 255.0.0.0 host 10.0.1.45 eq popMail serverInternal users

permit tcp any host 10.0.1.45 eq smtpMail serverInternet mail servers

permit tcp any host 10.0.0.14 eq httppermit tcp any host 10.0.0.14 eq httpspermit tcp any host 10.0.0.14 eq ftp


ACL EntriesServerClient

VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

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.



VLAN 10: Client Flows


HTTP, FTP (outbound)Internet serversInternal servers


VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

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.



VLAN 10: Classification Criteria

n/aInternet mail serversMail server

n/aInternet serversInternal servers

Classification CriteriaServerClient

VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

There is no ACE-specific processing to be done on connections from the servers, and therefore no classification criteria or processing actions.



VLAN 10: ACL Entries

permit tcp any any eq smtpInternet mail serversMail server

permit tcp any any eq httppermit tcp any any eq ftp

Internet serversInternal servers

ACL EntriesServerClient

VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

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


Configuring Multiple Integrated Features This topic describes the configuration of multiple integrated features.


Real Servers

rserver host WEBFILE1ip address 10.0.1.50inservice

rserver host WEBFILE2ip address 10.0.1.51inservice

VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

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.



Server Farms

serverfarm host FTPFarmrserver WEBFILE1 21inservice

rserver WEBFILE2 21inservice

serverfarm host WEBFarmrserver WEBFILE1 80inservice

rserver WEBFILE2 80inservice

VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

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.



Class Maps

class-map type ftp inspect match-any FTP-DELETEmatch request-method delematch request-method rmd

class-map match-any HTTP-VIPmatch virtual-address 10.0.0.14 tcp eq http

class-map match-any HTTPS-VIPmatch virtual-address 10.0.0.14 tcp eq https

class-map match-any FTP-VIPmatch virtual-address 10.0.0.14 tcp eq ftp

class-map type management REMOTE-ACCESSmatch protocol telnet 10.0.2.0 255.255.255.0match protocol https 10.0.2.0 255.255.255.0match protocol ssh 10.0.2.0 255.255.255.0

VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

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



Layer 7 Processing

ssl-proxy service SSL-OFFLOADkey myrsakey_servercert mycert_server

policy-map type inspect ftp first-match FTP-POLICYclass FTP-DELETEdeny

policy-map type loadbalance first-match FTP-SLBclass class-defaultserverfarm FTPFarm

policy-map type loadbalance first-match WEB-SLBclass class-defaultserverfarm WEBFarm

VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

Next in your implementation, you configure the Layer 7 processing. This includes the SSL proxies, inspection policies, and load-balancing policies.



Layer 4 Processing

policy-map multi-match WEBFILE-VIPSclass HTTP-VIPloadbalance policy WEB-SLBloadbalance vip inservice

class HTTPS-VIPloadbalance policy WEB-SLBloadbalance vip inservicessl-proxy server SSL-OFFLOAD

class FTP-VIPloadbalance policy FTP-SLBloadbalance vip inserviceinspect ftp strict policy FTP-POLICY

VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

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



Management Access

policy-map type management first-match MANAGEMENT-ACCESSclass REMOTE-ACCESSpermit

VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

You now define the management policy map.



ACLs

access-list from-outside extended permit tcp any host 10.0.0.14 eq httpaccess-list from-outside extended permit tcp any host 10.0.0.14 eq httpsaccess-list from-outside extended permit tcp any host 10.0.0.14 eq ftpaccess-list from-outside extended permit tcp any host 10.0.1.45 eq smtpaccess-list from-outside extended permit tcp 10.0.0.0 255.0.0.0 host 10.0.1.45 eq popaccess-list from-outside extended permit tcp 10.0.2.0 255.255.255.0 10.0.1.0 255.255.255.0

access-list from-servers extended permit tcp any any eq smtpaccess-list from-servers extended permit tcp any any eq httpaccess-list from-servers extended permit tcp any any eq ftp

VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

You define ACL entries for all the traffic that is allowed to start a new connection through the ACE appliance.



Interfaces

interface vlan10ip address 10.0.1.1 255.255.255.0access-group input from-servers

interface vlan100ip address 10.0.0.2 255.255.255.0access-group input from-outsideservice-policy input WEBFILE-VIPSservice-policy input MANAGEMENT-ACCESS

VLAN 100VLAN 10

Flow

Transit

Nontransit

Users

VLAN 5

VLAN 20

InternetServers

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




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.

Lesson 13



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 traffic-handling 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 hostingresources from network attacks.The ACE appliance load balances by analyzing Layer 4 attributes of the client request.

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

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

Q2) Resource minimums can be oversubscribed. (True or false.) (Source: Deploying ACE) A) true B) 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) FTP inspection B) HTTP load balancing C) HTTP inspection D) Layer 3 and 4 E) Management access


Q4) Which interface is the inside interface for Network Address Translation? (Source: Security Features) A) Client interface B) Depends on the NAT configuration C) DMZ D) Server interface

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

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

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

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

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

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

© 2007 Cisco Systems, Inc. Self-Check 397

Self-Check Answer Key Q1) A, D, F

Q2) B

Q3) D, E

Q4) B

Q5) A

Q6) D

Q7) A, B

Q8) B, C

Q9) B

Q10) A

ACEAP10_SG

Documents

Transcript of ACEAP10_SG