Cisco WAE devices can be configured to encrypt the data, swap, and spool partitions on the hard disk drives using encryption keys that are stored on and retrieved from the Central Manager. The disk encryption feature uses AES-256 encryption, the strongest commercially available encryption, and keys are only stored in the WAE memory. Should a WAE be physically compromised or a disk stolen, power is removed from the device, which destroys the copy of the key in memory. This renders data on the disk useless. Keys are stored in the Central Manager database and synchronized among Central Manager WAEs for high availability. If a WAE device is not able to retrieve its key from the Central Manager during boot time, it remains in pass-through mode until connectivity is restored or disk encryption is administratively bypassed.

CMS is a process that runs on each WAE device, including accelerators and Central Managers. This process manages the configuration and monitoring components of a WAE and ensures that each WAE is synchronized with the Central Manager based on a scheduler known as the Local Central Manager (LCM) cycle. The LCM cycle is responsible for synchronizing the Central Manager CMS process with the remote WAE CMS process to exchange configuration data, fetch health and status information, and gather monitoring and reporting data. The CMS process is also tied to the available management interfaces. For instance, the CMS process on the Central Manager must be running before the secure web user interface is made available (if it weren’t, there wouldn’t be much to show).

The Cisco WAE interface manager manages the physical and logical interfaces that are available to the WAE. Each WAE includes two integrated Gigabit Ethernet interfaces (including the WAE network modules, one interface is internal, the other is external). Each WAE appliance has expansion slots to support one or more additional feature cards, such as the inline bypass adapter, which has two two-port fail-to-wire pairs. The interface manager also provides management over logical interfaces that can be configured over physical interfaces. Logical interfaces include active/standby interfaces, where one physical interface is used as a primary interface and a second interface is used as a backup in the event the primary interface fails. Another logical interface is the PortChannel interface, which can be used to team WAE interfaces together for the purposes of high availability and load balancing. It should be noted that active/standby interfaces are used when WAE interfaces connect to separate switches, whereas PortChannel interfaces are used when the WAE interfaces connect to the same switch.

Cisco Linux provides an interface for the Cisco WAAS software to use for purposes of reporting and generating alarms. Cisco Linux supports the Simple Network Management Protocol (SNMP) versions 1, 2c, and 3, as well as definition of up to four syslog servers.

The network interception and bypass manager is used by the Cisco WAE to establish relationships with intercepting devices where necessary and ensure low-latency bypass of traffic that the WAE is not intended to handle. The Web Cache Coordination Protocol version 2 (WCCPv2) is a protocol managed by the network interception and bypass manager to allow the WAE to successfully join a WCCPv2 service group with one or more adjacent routers, switches, or other WCCPv2-capable server devices. WCCPv2 is discussed in more detail in Chapter 4, “Network Integration and Interception”. Other network interception options, which are also discussed in Chapter 4, include policy-based routing (PBR), physical inline interception, and Application Control Engine (ACE). As flows are intercepted by the WAE and determined to be optimization candidates, they are handed to the Application Traffic Policy (ATP) engine, which is discussed in the next section.

While the foundational platform component of Cisco WAAS is Cisco Linux, the foundational optimization layer of the Cisco WAAS software (which is as much a component of the Cisco Linux platform as it is the software) is the ATP engine. The ATP is responsible for examining details of each incoming flow (after being handled by the interception and bypass mechanisms) in an attempt to identify the application or protocol associated with the flow. This association is done by comparing the packet headers against a set of predefined or administratively configured classifiers, each with its own set of one or more match conditions. Flows that do not have a match with an existing classifier are considered “other” traffic and are handled according to the policy defined for other traffic.

When a classifier match is found, the ATP examines the policy configuration for that classifier to determine how to optimize the flow. The ATP also notes the application group that the classifier belongs to in order to route statistics gathered to the appropriate application group for proper reporting. The configured policy dictates which optimization subsystems are enacted upon the flow. The list of optimization actions that can be configured within a policy include the following:

Policies from the preceding list can be employed in conjunction with one another. For instance, the CIFS policy is, by default, configured to leverage the CIFS accelerator prior to leveraging the “full optimization” (DRE, PLZ, TFO) capabilities of the underlying WAN optimization layer. This is defined in a single policy, thereby simplifying overall system policy management. Classifiers within the ATP can be defined based on source or destination IP addresses or TCP port numbers, or ranges of these values. The ATP is examined during the establishment of a new connection when a TCP synchronize (SYN) packet is seen. By making a comparison against the ATP using the SYN packet of the connection being established, the ATP does not need to be consulted for traffic flowing in the reverse direction. Classification performed by the ATP is done once against the SYN packet and is applicable for both directions of traffic flow. In this way, classification does not need to be performed for traffic flowing in the reverse direction.

Figure 2-2 shows how the ATP engine interacts with a flow and a particular policy.

Figure 2-2. Connection Interaction with Application Traffic Policy

The Cisco WAE router-integrated network modules are designed to provide optimization services for the remote branch office or enterprise edge. These modules, which are single-processor systems based on the Network Module Enhanced (NME) hardware, can occupy an open NME-capable slot in a Cisco Integrated Services Router (ISR), including models 2811, 2821, 2851, 3825, and 3845. The ISR is an ideal platform for the branch office in that it provides a converged service platform for the remote office, including routing, switching, wireless, voice, security, and WAN optimization in a single chassis (platform, software version, and slot capacity dependent). Figure 2-3 shows a picture of the Cisco NME-WAE family and the ISR family.

Figure 2-3. Cisco ISR Family and WAAS Network Modules

The Cisco NME-WAE family includes three models: the NME-WAE-302, NME-WAE-502, and NME-WAE-522. Each network module has a single hard disk with capacity ranging from 80 to 160 GB. With only a single drive, the NME-WAE is not capable of RAID. NME-WAE devices integrate into the network using WCCPv2 as a means of interception (PBR can also be used, but WCCPv2 is preferred). Each NME-WAE has two network interfaces—one internal (connected to the ISR backplane) and one external (accessible through the front of the module). Figure 2-4 shows the architecture of the NME, internal and external interfaces, and intersection points between the NME and the ISR.

Figure 2-4. Cisco WAAS Network Module Architecture

The Cisco WAE appliance family is designed to be deployed in a location of any size, including the small branch office, campus networks, or the largest of enterprise data center networks. The Cisco WAE appliance family includes models 512, 612, 7326, 7341, and 7371. Each WAE appliance has externally accessible hard disk drives and RAID (some models support hot-swappable disk drives). The WAE appliance has two built-in Gigabit Ethernet interfaces, which can be deployed independently of one another or as a pair in either an active/standby configuration or PortChannel configuration. Such interface configurations are discussed in Chapter 5, “Branch Office Network Integration,” and Chapter 6, “Data Center Network Integration”. The WAE appliance family also has one or more PCI expansion slots that support installation of additional feature cards, such as the in-path card. Each WAE appliance can be deployed using a variety of network interception techniques, including physical inline interception, WCCPv2, PBR, and ACE (all of which are described in Chapter 4). Any appliance model can be used as a core or edge device. Figure 2-5 shows an image of the Cisco WAE appliance family.

Figure 2-5. Cisco WAAS Appliance Family

The amount of memory installed in a device dictates the level of performance and scalability the device can provide. As the memory capacity increases, the ability of a WAE to handle a larger number of connections or a larger addressable index space for compression also increases. Having larger amounts of memory also enables the WAE to run additional services, such as application acceleration or disk encryption, and positions the device to accept additional features that may be introduced in future software releases.

The NME-WAE family members all have fixed memory capacity and cannot be upgraded. From the WAE appliance family, the WAE-7326, 7341, and 7371 have fixed memory configurations. The WAE-512 and WAE-612, however, have configurable memory options, in that the WAE-512 can be configured with 1 GB or 2 GB of memory, and the WAE-612 can be configured with 2 GB or 4 GB of memory.

The amount of installed memory directly impacts what license is supported on each of the WAE models. The Transport license can be configured on any WAE model that has 512 MB of memory or more, which includes the entire product family. WAE models that have 1 GB of memory or more can be configured with the Enterprise license, which allows the WAE to operate some or all of the Enterprise license features. 1-GB WAE models configured with the Enterprise license (that is, NME-WAE-502 and WAE-512-1GB) can use disk encryption and perform application acceleration for CIFS as an edge device but not as a core device, but can terminate WAN optimized connections as a core device. WAE models with 2 GB or more (including the NME-WAE-522, WAE-512-2GB, WAE-612, WAE-7326, WAE-7341, and WAE-7371) can run the full suite of Enterprise license features as either a core or edge device.

Optimization services within the Cisco WAE leverage both memory and disk. From a disk perspective, the larger the amount of available capacity, the larger the amount of optimization history that can be leveraged by the WAE during run-time operation. For instance, a WAE-502 has 120 GB of physical disk capacity, of which 47 GB is available for use by DRE for compression history. With 47 GB of compression history, one can estimate the length of the compression history given WAN conditions, expected network utilization, and assumed redundancy levels.

Table 2-1 shows how the length of the compression history can be calculated for a particular WAE device, along with an example. This example assumes a T1 WAN that is 75 percent utilized during business hours (8 hours per day) and 50 percent utilized during nonbusiness hours (16 hours per day), and assumes that data traversing the network is 75 percent redundant. This table also assumes an NME-WAE-502 with 50 GB of allocated capacity for DRE compression history.

It is generally recommended that at minimum ten days of compression history be available in a WAE device. In the example in Table 2-1, the NME-WAE-502 contains enough storage capacity to provide an effective compression history of almost three weeks.

The disk capacity available to a WAE device is split among four major components:

Table 2-2 shows the storage allocation for each WAE device for each of these components.

Each WAE device has a static number of TCP connections that can be optimized concurrently. Each TCP connection is allocated resources within the system, and if the concurrently optimized TCP connection static limit is met, additional connections are handled in a pass-through fashion. The TCP connection limit of each WAE can be roughly correlated to the number of users supported by a given WAE model, but note that the number of TCP connections open on a particular node may vary based on user productivity, application behavior, time of day, and other factors. It is commonly assumed that a user will have 5 to 15 connections open at any given time, with roughly 4 to 7 of those connections requiring optimization. If necessary, policies can be adjusted on the WAAS Central Manager to pass through certain applications that may realize only a small amount of benefit from WAAS. This type of change could potentially help increase the number of users that can be supported by a particular WAE device.

Table 2-3 shows the optimized TCP connection capacity per Cisco WAE model.

WAE devices are not restricted in software or hardware in terms of the amount of WAN bandwidth or LAN throughput supported. However, recommendations are in place to specify which WAE should be considered for a specific WAN environment. WAN bandwidth is defined as the amount of WAN capacity that the WAE can fully utilize when employing the full suite of optimization capabilities (this includes DRE and PLZ). LAN throughput is defined as the maximum amount of application layer throughput (precompression) that can be achieved with the particular WAE model and an equivalent or more-powerful peer deployed in the path.

Another factor is for deployments where the WAE is providing TCP optimization only. Cisco WAAS TFO provides a powerful suite of optimizations to better allow communicating nodes to “fill the pipe” (that is, fully leverage available WAN bandwidth capacity) when the application protocol is not restricting throughput due to application-induced latency. Each Cisco WAE has a TFO-only throughput capacity that can be considered when WAEs are deployed strictly for TCP optimization only (compression and other optimizations are not being applied).

Table 2-4 shows the WAN bandwidth supported by each WAE model and the maximum LAN-side throughput and TFO-only throughput capacity.

Each Cisco WAE has a static system limit in terms of the number of concurrent peers it can actively communicate with at any one given time. When designing for a particular location where the number of peers exceeds the maximum capacity of an individual device, multiple devices can be deployed, assuming an interception mechanism that uses load balancing is employed (such as WCCPv2 or ACE; these are discussed in Chapter 4). In cases where load balancing is used, TCP connections are distributed according to the interception configuration, thereby allowing for near-linear scalability increases in connection count, peer count, and WAN bandwidth, as devices are added to the pool.

Peer relationships time out after 10 minutes of inactivity (that is, no active connections are established between two peers for 10 minutes). When the peer relationship is timed out, it becomes reusable by another peer. Data stored in the DRE compression history remains intact even if a peer becomes disconnected due to inactivity, unless the DRE compression history becomes full. In cases where the DRE compression history becomes full, an eviction process is initiated to remove the oldest set of data in the DRE compression history to make room for new data.

Table 2-5 shows the maximum number of concurrent peers supported per WAE platform. If peers are connected beyond the allocated limit, the WAE permits the connections to be established and gracefully degrades performance as needed. Connections associated with peers in excess of the maximum fan-out ratio are able to use the existing compression history but will not be able to add new chunks of data to it. The end result is lower effective compression ratios for the connections using peers that are in excess of the specified fan-out ratio.

Each Cisco WAAS deployment must have a Central Manager. The Central Manager is responsible for system-wide policy definition, synchronization of configuration, device monitoring, and reporting. The Central Manager can be deployed only on appliances, and may be deployed in an active/standby fashion. When a certain WAE device is configured as a Central Manager, it is able to, based on the hardware platform selected for the Central Manager, manage a maximum number of WAEs within the topology. Only WAE appliances can be configured as Central Manager WAEs, and in high-availability configurations, each Central Manager WAE should be of the same hardware configuration. While hardware disparity between Central Manager WAEs will work, it is not a recommended practice given the difference in the number of devices that can be managed among the WAE hardware models.

Table 2-6 shows the maximum number of managed nodes that can be supported by each WAE appliance when configured as a Central Manager.