Network Integration and Interception

This chapter is from the book 

Interception Techniques and Protocols

There are two approaches for leveraging the network infrastructure to intercept and redirect traffic to WAAS for optimization. The first method relies on interception protocols or routing configuration used by the networking components (routers and switches) to selectively intercept traffic and redirect it to the WAAS infrastructure. This method is referred to as off-path interception. The most common method for off-path network interception is the Web Cache Communication Protocol, or WCCPv2.

The second method places the WAE physically inline between two network elements, most commonly a router and LAN switch. All traffic between the two network elements is passed through the WAE, which can then selectively intercept traffic for optimization. This method is referred to as in-path interception, because the WAE is physically placed in the data path between the clients and servers.

This section discusses both off-path (WCCPv2) and in-path interception in detail. It also discusses other interception options for specific use cases, such as policy-based routing (PBR) and content switching. These additional interception options add to the flexibility with which WAAS can be integrated into existing network infrastructures of all sizes.

Web Cache Communication Protocol

This section does not provide an exhaustive reference for the WCCPv2 protocol. Rather, it provides enough information about the protocol background and concepts to enable you to understand the WCCPv2 implementation in Cisco WAAS. For an in-depth understanding of the WCCPv2 protocol, you are encouraged to read the WCCPv2 protocol draft. The full WCCPv2 IETF draft is available online at http://www.wrec.org/Drafts/draft-wilson-wrec-wccp-v2-00.txt.

WCCP Overview

WCCP is a transparent interception protocol first developed by Cisco Systems, Inc. in 1997. WCCP is a control plane protocol that runs between devices running Cisco IOS and WCCP "clients" such as WAAS. The protocol enables the network infrastructure to selectively intercept traffic based on IP protocol and port numbers, and redirect that traffic to a WCCP client. WCCP is considered transparent, because it allows for local interception and redirection of traffic without any configuration changes to the clients or servers. WCCP has built-in load-balancing, scalability, fault-tolerance, and service assurance (fail open) mechanisms. Figure 4-4 shows the basic functions of WCCP.

The current version, WCCPv2, is used by Cisco WAAS to transparently intercept and redirect all TCP traffic, regardless of port. The following section describes the basic WCCPv2 concepts and how they are specifically used by Cisco WAAS.

Service Groups

The routers and WAEs participating in the same service constitute a service group. A service group defines a set of characteristics about what types of traffic should be intercepted, as well as how the intercepted traffic should be handled. There are two types of service groups:

• Well-known services
• Dynamic services

Well-known services, also referred to as static services, have a fixed set of characteristics that are known by both IOS and WCCPv2 client devices. There is currently a single well-known service called web-cache. This service redirects all TCP traffic with a destination port of 80. The characteristics of a dynamic service are initially only known to the WCCPv2 clients within the service group. The characteristics of the service group are communicated to the IOS devices by the first WCCPv2 client device to join the service group.

A unique service ID identifies service groups, which is a number from 0 to 255. Service IDs 0 to 50 are reserved for well-known services.

The WCCPv2 implementation in WAAS supports a single dynamic WCCPv2 service, the tcp-promiscuous service. Although referred to in WAAS as a single service, the tcp-promiscuous service is in fact two different services. The two service IDs enabled with the tcp-promiscuous service are 61 and 62. These are the two service group IDs that are configured in IOS when using WCCPv2 with WAAS. Two different service groups are used because both directions (client-to-server and server-to-client) of a TCP connection must be transparently intercepted. To optimize a connection, WAAS must see both directions of the connection on the same WAE. Not only does WAAS intercept the connection in both directions, but it also intercepts the connection on both sides of the WAN link. Because the packet Layer 3 and Layer 4 headers are preserved, transparent interception is used on both sides of the WAN in both directions to redirect connections to the WAAS infrastructure for optimization. Figure 4-5 shows a basic topology with WCCPv2 interception configured for WAAS.

What is the difference between services 61 and 62? You can view the service attributes using CLI commands in both WAAS and IOS. Example 4-9 shows the attributes of services 61 and 62 using the IOS CLI.

Example 4-9. WCCP Service Group Attributes

AST6-RTR-02# show ip wccp 61 service
WCCP service information definition:
        Type:          Dynamic
        Id:            61
        Priority:      34
        Protocol:      6
        Options:       0x00000501
        --------
            Hash:      SrcIP
            Alt Hash:  SrcIP SrcPort
            Ports:     -none-

AST6-RTR-02#
AST6-RTR-02# show ip wccp 62 service
WCCP service information definition:
        Type:          Dynamic
        Id:            62
        Priority:      34
        Protocol:      6
        Options:       0x00000502
        --------
            Hash:      DstIP
            Alt Hash:  SrcIP SrcPort
            Ports:     -none-

AST6-RTR-02#

A description of each value is provided in Table 4-2.

Table 4-2. WCCP Service Group Attributes

Value	Description
Type	Well-known or dynamic service.
Id	The numeric service ID for the group.
Priority	The priority for the service group. When multiple service groups are configured on the same interface in the same direction, they are evaluated in descending priority order.
Protocol	The IP protocol number defined by the service group.
Options	Flags field indicating further service characteristics.
Hash	The value(s) in the redirected packet used as the hash key.
Alternate Hash	The value(s) in the redirected packet used as the alternate hash key.
Ports	The Layer 4 port numbers defined by the service group.

The command output shows that the only difference between services 61 and 62 is the value from the packet used as the hash key. By default, service group 61 hashes on the source IP address and service group 62 hashes on the destination IP address. Later, this chapter discusses the significance of the hash key used in each service group. By default, the spoof-client-ip feature is enabled for both services. This is the WCCPv2 feature that allows WAAS to handle optimized traffic transparently. Traffic forwarded to the WAE uses the same source and destination IP addresses and TCP ports as when it entered the WAE.

The tcp-promiscuous services define TCP as the protocol and do not define any ports. By not defining any ports as part of the service groups, this causes interception and redirection of all TCP traffic. When traffic passes through an interface in the IOS device with WCCPv2 redirection configured, it is evaluated against the protocol and port combination defined by the service to determine whether or not the packet should be redirected. By default this is the only criteria that is used to determine whether or not a packet is redirected. It is important to note that the IOS WCCPv2 implementation is not stateful. This means that IOS WCCPv2 is only dealing with redirected traffic on a packet-by-packet basis. It does not keep track of TCP connection state for redirected traffic. On the other hand, the WCCPv2 implementation in WAAS is stateful. WAAS tracks each connection as a flow throughout the life of the connection.

Forwarding and Return Methods

WCCPv2 supports different methods for forwarding redirected traffic to a WAE, and for the WAE to return traffic to the router for forwarding. These methods are referred to as the forwarding and return methods and are negotiated between IOS and the WAE when a WAE joins the service group.

The forwarding method defines how traffic that is being redirected from IOS to the WAE is transmitted across the network. The first method, GRE forwarding, encapsulates the original packet in an IP GRE header with the destination IP address set to the target WAE and the source IP address set to the WCCPv2 router ID of the redirecting router. When the WAE receives the GRE-encapsulated packet, the GRE header is removed, and the packet is processed. Figure 4-6 shows an example of GRE forwarding.

The second forwarding method, L2 forwarding, simply rewrites the destination MAC address of the packet being redirected to equal the MAC address of the target WAE. This forwarding method assumes that the WAE is Layer 2 adjacent to the redirecting router. L2 forwarding was originally developed for the WCCPv2 implementation on hardware-based platforms, such as the Catalyst 6500. Figure 4-7 shows an example of L2 forwarding.

One of the benefits of L2 forwarding is that it allows for the WCCPv2 redirection to occur in hardware on Cisco Catalyst Series switches. In fact, on the Catalyst 3560/3750 and 4500/4948 series switches, the only forwarding method supported by WCCPv2 is L2 forwarding. Additional information about the configuration requirements for deploying WCCPv2 on Cisco Catalyst switches is provided in the "WCCP Configuration" section.

The return method defines how traffic should be returned from the WAE to the redirecting router for normal forwarding. Like the forwarding method, there are two different return methods:

• GRE return: Egress traffic from the WAE using GRE return are encapsulated using IP GRE, with a destination IP address of the WCCPv2 router ID and a source IP address of the WAE itself. When the WCCPv2-enabled router receives the returned packet, the IP GRE header is removed and the packet is forwarded normally. WCCPv2 in IOS knows not to re-intercept traffic returned to it using GRE return.
• L2 return: The L2 return method returns traffic to the WCCPv2-enabled router by rewriting the destination MAC address of the packet to equal the MAC address of the WCCPv2-enabled router.

Load Distribution

When multiple WAEs exist in a service group, WCCPv2 automatically distributes redirected traffic across all WAEs in the service group. When traffic passes through an IOS device with WCCPv2 redirection configured, the IOS device assigns traffic for that connection to a bucket. Each bucket is assigned to a specific WAE. The method that determines to which bucket traffic is assigned, which determines how traffic is distributed across multiple WAEs within a service group, is called the assignment method. The bucket assignments are communicated from the lead WAE to all of the IOS devices in the service group. The assignment method can use either a hashing or masking scheme, and is negotiated between IOS and WAE during the formation of the service group.

Hash assignment, which is the default assignment method, performs a bitwise hash on a key identified as part of the service group. In WAAS, the hash key used for service group 61 is the source IP address, while the hash key used for service group 62 is the destination IP address. The hash is not configurable, and is deterministic in nature. This means that all of the routers within the same service group will make the same load-balancing decision given the same hash key. This deterministic behavior is what allows WCCPv2 to support asymmetric traffic flows, so long as both directions of the flow pass through WCCPv2-enabled IOS devices in the same service group. Hash assignment uses 256 buckets. Figure 4-8 shows an example of the hash assignment method and bucket-based distribution model used by WCCPv2.

The second assignment method is called mask assignment. With mask assignment, the source IP address, destination IP address, source port, and destination port are concatenated and ANDed with a 96-bit mask to yield a value. The resulting 96-bit value is compared to a list of mask/value pairs. Each mask/value pair is associated with a bucket, and each bucket is in turn assigned to a WAE. Unlike hash assignment, the number of buckets used with mask assignment depends on the number of bits used in the mask. By default, WAAS uses a mask of 0x1741. This results in 2⁶ buckets that can be assigned across the WAEs in a service group. With current Catalyst WCCPv2 implementations, up to 7 bits can be defined for the mask. Figure 4-9 shows an example of the mask assignment method and bucket-based distribution model used by WCCPv2.

Failure Detection

Once a WAE has successfully joined a service group, a periodic keepalive packet is sent every 10 seconds from the WAE to each router in the service group. The keepalive mechanism occurs independently for each configured service group. If a router in the service group has not received a keepalive packet from the WAE in 25 seconds, the router unicasts a Removal Query message to that WAE requesting that it immediately respond. If no response is received within 5 seconds, for a total of 30 seconds since the last keepalive message from the WAE, the WAE is considered offline and is removed from the service group. Figure 4-10 illustrates this behavior.

When the WAE is removed from the service group, it is reflected in the Router View advertised from each router in the service group. When the lead WAE determines that a WAE has been removed from the service group, it generates a Redirect Assignment message to each router in the service group. The Redirect Assignment message instructs the routers how to reallocate the buckets across the remaining WAEs in the service group. The length of time required to calculate the new assignments might very depending upon when the group of WAEs becomes stable. The WAE waits a minimum of 9 seconds. The maximum length of time depends on when the IOS device sends an update message without any changes indicated, typically between 19 and 39 seconds.

Flow Protection

When a WAE (re)joins the service group, a new Redirect Assignment message is generated by the lead WAE. When the new WAE begins receiving redirected traffic from the routers in the service group, it does one of two things, depending on whether or not the redirected traffic is for a new connection or part of an existing connection. Traffic associated with newly established connections is evaluated against the Application Traffic Policy (ATP) and processed normally by the WAE. Traffic associated with existing connections is forwarded directly to the WAE that previously owned the bucket for that connection. This WCCPv2 mechanism is called flow protection and is enabled by default. Flow protection allows for existing connections to continue to be optimized even when the traffic assignments for the WAEs in a service group change.

Graceful Shutdown

After the no wccp ver 2 command is issued, WCCPv2 checks whether any connections are being served by the WAE. If zero connections are being served, the shutdown is immediately carried out. If there are more than zero connections being served, WCCPv2 waits for the user-configured wccp shutdown max-wait XX time.

During this time, if the connection count goes down to zero, shutdown is immediately done. At the end of the max-wait time, if the connection count has decreased but is still non-zero, the shutdown count waits another 60 seconds, in the hope that if the connection count has decreased other connections may complete too. At the end of the max-wait time, if the connection count has not decreased, shutdown is immediately done. During the 60-second incremental wait, if the connection count becomes zero, shutdown is done. At the end of the 60-second incremental wait, if the connection count has not reduced, the shutdown is done. At the end of the 60-second incremental wait, if the count has further reduced but is still non-zero, another 60-second incremental wait is done.

Unless the user interrupts the wait period, the code waits first for the configured length of time. If it thinks that connections are reducing, it waits a little longer in the hope that more connections can be completed. However, if it realizes that the connection count has not decreased, it discontinues waiting and shuts down.

Scalability

With WCCPv2, each service group can support up to 32 routers and 32 WAEs. This means that a single service group can support N x 32 concurrent optimized TCP connections, where N is the number of concurrent optimized TCP connections supported by the largest WAE model. Each WAE in the service group is manually configured with the IP address of each router in the service group. The WAE then uses unicast packets to exchange WCCPv2 messages with each router. It is not required that the routers in the service are manually configured with the IP address of each WAE in the service group. Each router listens passively for WCCPv2 messages from the WAEs in the service group and responds only as a result of receiving those messages.

The WAE in the service group with the lowest IP address is elected as the "lead" WAE. The lead WAE is responsible for communicating the list, or view, of the routers in the service group to the service group routers. The lead WAE is also responsible for informing the routers how traffic should be distributed across WAEs in the service group. Upon receiving the view of the routers in the service group from the lead WAE, each router responds individually with a Router View. The Router View contains a list of each WAE that the router is currently communicating with. What is implied is that the routers in the service group do not communicate directly with each other; they learn about each other through the Router View advertised by the WAE. Likewise, the WAEs in a service group do not communicate directly with each; they learn about each other from the WAE View advertised by the routers.

Redirect Lists

For deployments where you may want to limit redirection to specific types of traffic, you can use a WCCPv2 redirect list. A WCCPv2 redirect list is a standard or extended IOS access list that is associated with a WCCPv2 service. Traffic passing through an interface on the router with WCCPv2 redirection configured must match not only the protocol/port specified as part of the service group, but also a permit entry in the redirect list. Packets that match the service group protocol/port criteria but do not match a permit entry in the redirect list are forwarded normally. Example 4-10 demonstrates the use of a WCCPv2 redirect list.

Example 4-10. WCCP Redirection Using a Redirect List

!
access-list 100 permit ip 10.10.10.0 0.0.0.255 any
access-list 100 permit ip any 10.0.0.0 0.0.0.255
access-list 100 deny ip any any
!
ip wccp 61 redirect-list 100
ip wccp 62 redirect-list 100
!

In this example, TCP traffic sourced from or destined to subnet 10.10.10.0/24 will be intercepted and redirected by WCCPv2. Another option is to use a redirect list to specify a subset of TCP ports for redirection. Example 4-11 shows how this could be done.

Example 4-11. WCCP Redirect List Using Application Ports

!
access-list 101 permit tcp any any eq 25
access-list 101 permit tcp any eq 25 any
access-list 101 deny ip any any
!
ip wccp 61 redirect-list 101
ip wccp 62 redirect-list 101
!

This example uses a redirect list to allow WCCPv2 to intercept and redirect SMTP traffic only on port 25.

Service Group Placement

The placement of service groups 61 and 62 should not be overlooked in your deployment. The placement refers to which IOS interfaces are configured with service group 61 and which interfaces are configured with service group 62. In most environments, service group 61 should be configured on the client-facing interfaces. For example, when deploying WCCPv2 on a remote-office WAN router, service group 61 is configured to intercept a client request. Configuring group 61 inbound on the router's LAN interface or outbound on the router's WAN interface accomplishes this. Figure 4-11 shows an example of configuring service group 61 inbound on the router's LAN interface.

For the reverse direction of the connection, service group 62 is used. Service group 62 will be configured in the opposite direction of service group 61. Using the same example shown in Figure 4-11, Figure 4-12 shows service group 62 configured inbound on the router's WAN interface. The following figure shows the complete placement and configuration using both service groups.

WCCP Configuration

This section provides a basic overview of configuring WCCPv2 within both IOS and WAAS. Detailed WCCPv2 configurations specific to various design options are presented in Chapters 5 and 6.

There are three primary steps involved when configuring WCCPv2 in WAAS. First, you must define which routers the WAE will establish WCCPv2 communication with. WCCPv2 can be configured to use either unicast or multicast for communication. Unicast is the most commonly deployed configuration. For unicast communication, you must define the IP address of each router in the service group that the WAE will communicate with. This is done using a router list. A router list is configured using the following syntax:

   wccp router-list 1-4 ip_addr...

Example 4-12 shows a basic WCCP router list configuration.

Example 4-12. WAAS WCCP Router List Configuration

   wccp router-list 1 10.10.10.1

Up to six IP addresses may be defined per line. For deployments where there are more than six routers in the service group, additional router IP addresses can be defined by configuring a second line using the same router list number. Example 4-13 shows a WCCPv2 router list configured with ten IP addresses.

Example 4-13. WCCP Router List Using Multiple IP Addresses

   wccp router-list 1 10.10.10.1 10.10.10.2 10.10.10.3 10.10.10.4 10.10.10.5 10.10.10.10.6
   wccp router-list 1 10.10.10.7 10.10.10.8 10.10.10.9 10.10.10.10

For the second step, the WCCPv2 tcp-promiscuous service is configured and associated with the router list created in the first step. The following command syntax is used:

   wccp tcp-promiscuous router-list-num 1

The final configuration step is to enable WCCPv2 using the command wccp version 2. This command starts the WCCPv2 negotiation with any IOS devices configured in the router list. Example 4-14 shows a complete WCCPv2 configuration in Cisco WAAS.

Example 4-14. Complete WAAS WCCP Configuration

!
wccp router-list 1 10.10.20.1
wccp tcp-promiscuous router-list-num 1
wccp version 2
!

The IOS WCCPv2 configuration involves two steps. First, the WCCPv2 services are configured in global configuration mode. The WCCPv2 services in IOS are configured using the numeric service ID, as opposed to the service name used on the WAAS configuration. Example 4-15 shows the tcp-promiscuous services configured in IOS.

Example 4-15. Cisco IOS WCCP Global Configuration

!
ip wccp 61
ip wccp 62
!

The second step involves configuring WCCPv2 redirection on each interface through which client and server data passes. Unless you are using the WCCPv2 negotiated return egress method discussed later in this chapter, WCCPv2 redirection should never be configured on the interface connecting to the WAE. Interception is configured in either the inbound or outbound direction. When using outbound redirection, the ip wccp redirect exclude in command must be configured in the interface connecting to the WAE. This prevents traffic coming into the WCCPv2 server (router) from being re-intercepted, which would cause a redirection loop. Example 4-16 demonstrates a complete IOS WCCPv2 configuration, including the use of the ip wccp redirect exclude in command.

Example 4-16. Complete Cisco IOS WCCP Configuration

!
ip wccp 61
ip wccp 62
!
ip cef
!
interface Serial0/0
 bandwidth 1536
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.100
 ip add 10.88.80.18 255.255.255.252
 ip wccp 61 redirect out
 ip wccp 62 redirect in
 frame-relay interface-dlci 100
!
interface GigabitEthernet0/0
 no ip address
 duplex auto
 speed auto
!
interface GigabitEthernet0/0.1
 description ** Branch Client VLAN **
 encapsulation dot1q 10
 ip address 10.10.10.1 255.255.255.0
!
interface GigabitEthernet0/0.20
 description ** Branch WAE VLAN **
 ip address 10.10.20.1 255.255.255.0
 ip wccp redirect exclude in
!
end

Note that the ip wccp redirect exclude in command is configured on the subinterface connecting to the WAE. This is required because outbound redirection is used on the serial interface connecting to the WAN. An alternative configuration is shown in Example 4-17.

Example 4-17. Cisco IOS WCCP Configuration Using Inbound Redirection

!
ip wccp 61
ip wccp 62
!
ip cef
!
interface Serial0/0
 bandwidth 1536
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.100
 ip add 10.88.80.18 255.255.255.252
 ip wccp 62 redirect in
 frame-relay interface-dlci 100
!
interface GigabitEthernet0/0
 no ip address
 duplex auto
 speed auto
!
interface GigabitEthernet0/0.1
 description ** Branch Client VLAN **
 encapsulation dot1q 10
 ip address 10.10.10.1 255.255.255.0
 ip wccp 61 redirect in
!
interface GigabitEthernet0/0.20
 description ** Branch WAE VLAN **
 ip address 10.10.20.1 255.255.255.0
!
end

This example uses inbound redirection on the interface connecting to the client subnet and the serial interface connecting to the WAN. Because outbound redirection is not used, the ip wccp redirect exclude in command is not required on the interface connecting to the WAE.

Hardware-Based Platforms

In addition to running WCCPv2 on software-based IOS platforms such as the Cisco Integrated Services Router (ISR), WCCPv2 is supported on Cisco Catalyst Series switches. At the time of this writing, the Cisco Catalyst Series switches listed in Table 4-3 support WCCPv2 for use with Cisco WAAS.

Table 4-3. Cisco Catalyst Platforms Supporting WCCPv2 with WAAS

Catalyst 3560/3750

Catalyst 4500/4900

Catalyst 6500, Sup2

Catalyst 6500, Sup32

Catalyst 6500, Sup720

With the exception of the Catalyst 6500 with a Sup720, the hardware-based platforms require L2 forwarding and mask assignment for all of the redirection to happen in hardware. The Sup720 is capable of performing GRE forwarding in hardware, but still requires mask assignment for hardware acceleration. In addition to the requirements for forwarding and assignment methods, only inbound WCCPv2 redirection should be used on hardware-based platforms. In fact, the Catalyst 3560/3750 and 4500/4900 only support inbound redirection. While it is possible to configure outbound redirection on the Catalyst 6500 platform, it is not recommended because it causes the first packet for every redirected connection to be processed in software by the MSFC. Likewise, using the ip wccp redirect exclude in command on a Catalyst 6500 causes the first packet for every flow entering the interface to be processed by the MSFC and switched in software. However, because inbound redirection is the recommendation for hardware-based platforms, this command is not required.

The following configuration guidelines should be followed to ensure WCCPv2 redirection on hardware-based platforms is handled completely in hardware:

• Use L2 forwarding instead of GRE forwarding.
• Always use mask assignment.
• Only use inbound redirection.
• Do not use the ip wccp redirect exclude in command.

The L2 forwarding and mask assignment options are configured as part of the service definition in WAAS. These capabilities are advertised to the WCCPv2-enabled IOS devices when a WAE first joins the service group. Example 4-18 demonstrates the WAAS WCCPv2 configuration with the L2 forwarding and mask assignment options.

Example 4-18. WCCP Configuration Using L2 Forwarding and Mask Assignment

!
wccp router-list 1 10.10.20.1
wccp tcp-promiscuous router-list-num 1 l2-redirect mask-assign
wccp version 2
!

Unlike the hash algorithm used with hash assignment, the mask used for mask assignment is configurable. As mentioned previously in this chapter, the default mask used by WAAS is 0x1741. The default mask is applied to the source IP address for service group 61 and is applied to the destination IP address for service group 62. Depending on the IP addressing used in your environment, you may want to change the default mask to provide for better load distribution among the WAEs in a service group. The default mask is changed on the WAE using the following command syntax:

   wccp tcp-promiscuous mask src-ip-mask 0-4261412864

The configured mask is applied to service group 61. Service group 62 mirrors the configuration and cannot be configured separately. Example 4-19 shows using a non-default mask with WCCPv2.

Example 4-19. Custom WCCP Mask

!
wccp router-list 1 10.10.20.1
wccp tcp-promiscuous mask src-ip-mask 0xf                     
wccp tcp-promiscuous router-list-num 1 l2-redirect mask-assign
wccp version 2
!

Policy-Based Routing

Policy-based routing (PBR) provides another alternative for transparent interception with WAAS, although it is less commonly deployed than WCCPv2 and inline interception. PBR can be used in situations where customers are unable to run WCCPv2 or inline interception. PBR can also be used in conjunction with a content switch, such as the Cisco Application Control Engine (ACE), to provide transparent interception and load balancing for large-scale data center deployments. Deployment examples using PBR for transparent interception are provided in Chapters 5 and 6.

PBR functions in a similar manner to WCCPv2, in that a router/switch running Cisco IOS is configured to intercept interesting traffic and redirect it to a WAE. Unlike WCCPv2, no configuration is required on the WAE to support interception using PBR. The following configuration steps are required for a basic PBR configuration:

Step 1 Create an access list to define interesting traffic for redirection.

Step 2 Create a route map that matches the ACL created in Step 1 and sets an IP next-hop address of the target WAE.

Step 3 Apply the route map to interfaces through which client and server traffic traverses.

Example 4-20 demonstrates a basic PBR configuration used for redirecting all TCP traffic to a single WAE.

Example 4-20. PBR Configuration

!
ip cef
!
access-list 199 permit tcp any any
!
route-map WAAS-INTERCEPT 10
 match ip address 199
 set ip next-hop 10.10.20.5
!
interface Serial0/0
 bandwidth 1536
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.100
 ip add 10.88.80.18 255.255.255.252
 ip policy route-map WAAS-INTERCEPT
 frame-relay interface-dlci 100
!
interface GigabitEthernet0/0
 no ip address
 duplex auto
 speed auto
!
interface GigabitEthernet0/0.1
 description ** Branch Client VLAN **
 encapsulation dot1q 10
 ip address 10.10.10.1 255.255.255.0
 ip policy route-map WAAS-INTERCEPT
!
interface GigabitEthernet0/0.20
 description ** Branch WAE VLAN **
 ip address 10.10.20.1 255.255.255.0
!
end

Because PBR evaluates only traffic entering an interface, the route map entries are configured on both the client and server-facing interfaces. This is the equivalent of using only inbound redirection with WCCPv2. The set ip next-hop command in the route map is configured with the IP address of the WAE. By default, PBR does not validate to availability of the IP address specified as the next-hop address. As long as the next-hop address exists in the routing table, the route map entry will be applied. On software-based platforms (ISR, and so forth), Cisco Service Assurance Agent (SAA) can be used to track the availability of the next-hop IP address. If the next-hop address becomes unreachable, traffic matching the route map entry is forwarded normally using the routing table. However, this capability does not currently exist on hardware-based platforms.

Other difference between WCCPv2 and PBR is that PBR does not perform automatic load distribution and failover when multiple WAEs exist. The first next hop IP address configured in the route map is used until it becomes unavailable. Only at that point is traffic redirected to a secondary next hop IP address in the route map. Chapters 5 and 6 provide examples of PBR deployments that include next hop availability tracking using SAA and load distribution among multiple WAEs.

Inline Interception

An alternative to the various off-path interception mechanisms is to place the WAE physically inline between two network elements, such as a WAN access router and local-area network (LAN) switch. Figure 4-13 shows a basic topology with the WAE deployed physically inline.

Physical inline interception is an attractive option for situations where it is not possible or ideal to run WCCPv2. It is also possible that the networking equipment at a site is provided and managed by a managed service provider (MSP). The MSP may not be able to configure or support a WCCPv2 solution on the managed devices.

To support physical inline interception, the WAE requires a separate inline module. The inline module is a 4-port, fail-to-wire NIC that supports two separate inline groups. Each inline group has a synchronous pair of inline ports that interconnect two network elements. Traffic entering one inline port is optimized by WAAS (when applicable) and switched out the opposite inline port in the same group. The inline group functions like a transparent Layer 2 bridge.

By providing two inline groups on a single module, the WAE can support designs where multiple paths out of a site exist for redundancy and load sharing. Each unique path is connected to the WAE through a separate inline group. Figure 4-14 shows a sample remote site topology with multiple WAN routers and a single WAE deployed with inline interception.

As the arrows in Figure 4-14 indicate, traffic can enter or leave the site through either router. Even though the same flow enters the site through one inline group and exits the site through another inline group, the connection will still be optimized. The optimized connection state is not tied to a physical interface, but is tracked for the WAE as a whole independent of the interfaces traversed by the traffic.

Each inline group functions in one of two operating modes:

• Intercept operating mode: Traffic entering the inline group is evaluated against the Application Traffic Policy (ATP) for optimization.
• Bypass operating mode: All traffic entering the inline group is bridged without any optimization.

The bypass operating mode is designed to allow the WAE to continue passing traffic if the WAE looses power. A keepalive mechanism between the network drivers and the inline module is used to determine if the WAE is functioning properly and can optimize connections.

The keepalive frequency is configurable between 1 and 10 seconds. The default failover timer is set to 3 seconds. The transition between intercept operating mode and bypass operating mode does cause a momentary loss of line protocol. If one or more of the inline ports are connected to a LAN switch, this transition in interface state can cause the Spanning Tree Protocol (STP) recalculation. To prevent the STP calculation from interrupting traffic forwarding, the switchport connected to the inline module on the WAE should have the STP PortFast feature enabled. Failure of a single inline port in the group is propagated to the other port in the group. For example, if the LAN0 port in InlineGroup 1/0 goes down, the WAE will take down line protocol on the WAN0 port in the same inline group. This propagation of interface state between the ports in the same inline group prevents situations where adjacent devices connected to an operational InlinePort believe the network path to be online and usable, when in reality the connection on the other side of the WAE is unavailable.

When a WAE is deployed physically inline, all traffic between the two network elements will be seen by the WAE. Non-TCP traffic is bridged through the inline module without modification. In addition, packets associated with a connection that was first seen on the opposite inline port in a group are bridged. This type of traffic flow is common when a WAE is deployed inline on a trunk between a router and LAN switch. If the router is providing routing for traffic going between VLANs locally, it is possible for traffic to traverse the inline module twice. Figure 4-15 shows an example of this type of traffic flow.

The inline module also supports 802.1Q trunk connections between the two network elements. An added benefit to using the inline module is the ability to define which VLANs are evaluated for interception. Traffic that is received by the inline module tagged with a VLAN ID that is excluded from interception will be bridged without any optimization. This capability is supported only for tagged VLANs. Traffic received by the inline module on untagged VLANs will be intercepted and evaluated against the ATP for optimization and acceleration. By default, TCP traffic received on all VLANs is intercepted and evaluated against the ATP. VLANs can be excluded or included for interception using the following commands:

   no inline vlan all
   inline vlan 100

Example 4-21 shows the resulting InlineGroup configuration.

Example 4-21. WAE InlineGroup Configuration

!
interface InlineGroup 1/0
 inline vlan all
 no inline vlan native,0-99,101-4095
 exit
!

There are different sequences of the inline CLI command that will result in the same VLAN filter being applied. For example,

   inline vlan all
   no inline vlan 100

results in all VLANs except for 100 being intercepted. But so does the following:

   inline vlan native
   inline vlan 0-4095
   no inline vlan 100-110
   inline vlan 101-200

In terms of VLAN assignment, the most permissive command takes precedence. If the inline group is already configured with inline vlan all, then you need to selectively remove VLANs from interception or remove all VLANs and selectively add individual VLANs back for interception.

When an inline group is in bypass operating mode, a physical cross-connect is enabled between the two ports in the inline group. This behavior essentially creates a crossover cable between the two network elements. In cases where the two network elements are unable to communicate using a crossover cable, line protocol will not be restored when the inline group is in bypass operating mode. This is generally a nonissue when the switchport that the LAN InlinePort is connected to supports automatic medium-dependent interface crossover (MDIX). MDIX allows the switchport to automatically detect the pinouts of the cables used to connect two devices. In cases where the switchport does not support this capability, the cabling guidelines outlined in Table 4-4 should be followed.

Table 4-4. WAE Inline Module Cabling Guidelines

Connection	Required Cable
Switch to switch (no WAE)	Crossover
Switch to router (no WAE)	Straight-through
Router to router (no WAE)	Crossover
Switch to WAE	Straight-through
WAE to switch	Crossover
Switch to WAE	Straight-through
WAE to switch	Straight-through
Router to WAE	Straight-through
WAE to router	Straight-through
WAE to WAE	Crossover

Content Switching

Content switching is the final interception mechanism discussed in this chapter. Content switches have traditionally provided load-balancing services for servers, firewalls, and content caches. Within the context of WAAS, content switching provides dedicated hardware for intercepting and load balancing connections across a farm of WAEs. Using content switches for transparent interception with WAAS is useful for large data center deployments, complex topologies, and integration with other advanced features such as application protocol optimization and SSL-offload. In addition, customers with existing content switching deployments can leverage their experience and investments in content switches for transparent interception with WAAS. The Application Control Engine is the Cisco content switch that will be discussed in this section. Deployment and configuration examples for integrating ACE with Cisco WAAS are provided in Chapter 6.

Application Control Engine

The Cisco Application Control Engine (ACE) module is a service module for the Cisco Catalyst 6500 series switches and Catalyst 7600 series routers. ACE provides intelligent load balancing and security services for enterprise applications and network devices. ACE can be used in a large-scale data center environment to transparently intercept and load balance connections for WAAS. The following are some of the key performance characteristics of Cisco ACE:

• Up to 16 Gbps of throughput and 345,000 connections per second per module
• Up to 4 million concurrent connections
• Support for up to 250 virtual partitions, allowing customers to create virtual ACE modules using a single hardware module
• Up to 16,000 real servers, which when used with Cisco WAAS provides nearly infinite scalability
• High availability and scalability by using up to four ACE modules in the same Catalyst 6500 chassis or across multiple chassis

There are two common deployment models for integrating ACE into the network infrastructure: bridge mode and routed mode.

In bridge mode, ACE is used to merge two VLANs together. In order for traffic to pass between the two VLANs, it must pass through the ACE module. As traffic passes through the ACE module, it is evaluated against the configured service policies to determine whether or not it should be acted upon. The IP subnet used on the bridged VLAN is the same. Figure 4-16 shows an ACE module deployed using bridge mode.

The WAN-facing VLAN in Figure 4-16 is referred to as the client-side VLAN. The VLAN facing the data center resources is referred to as the server-side VLAN. As traffic enters the client-side VLAN, it is evaluated against the configured service policy. Traffic matching the service policy is redirected to a WAE, which has a dedicated VLAN interface configured on the ACE module. Traffic egressing the WAE comes back into the ACE module, where it is switched out the server-side VLAN toward the origin server.

In contrast to bridge mode, deploying ACE in routed mode allows for traffic to be routed between two different IP subnets. Using this deployment model, the client and server-side VLANs are on different IP subnets. Because the ACE module is a Layer 3 hop, traffic must be directed to the ACE module through the routing configuration of the hosts or network infrastructure. Figure 4-17 shows an ACE module deployed using routed mode.

ACE is typically deployed in conjunction with WAAS using transparent, or directed, mode. This means that the ACE module does not perform any Network Address Translation (NAT) of traffic passing through it.