-
null
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes general guidelines, restrictions, and limitations that you should be aware of before you set up your Cisco Wide Area Application Services (WAAS) network.
Note Throughout this chapter, the term Cisco WAAS device is used to refer collectively to the Cisco WAAS Central Managers and Cisco Wide Area Application Engines (WAEs) in your network. The term WAE refers to WAE and Cisco Wide Area Virtual Engine (WAVE) appliances, and Cisco Virtual WAAS (vWAAS) instances.
This chapter contains the following sections:
Cisco Wide Area Application Engines (WAEs) that are running the Cisco WAAS software can be used by enterprises or service providers to optimize the application traffic flows between their branch offices and data centers. You should deploy WAE nodes at the WAN endpoints near the networked application clients and their servers, where they intercept WAN-bounded application traffic and optimize it. You must insert WAE nodes into the network flow at defined processing points.
Cisco WAAS software supports the following three typical network topologies:
The deployments are characterized according to the Cisco WAAS element connections, which follow the client-server access pattern and may differ from the physical network links. For more information, see the chapter “Introduction to Cisco WAAS” .
When you are planning your Cisco WAAS network, use the following checklist as a guideline. As the following checklist indicates, you can break the planning phase into the following three main categories of planning activities:
Note Although there are some interdependencies, you do not have to complete all of the steps in a particular planning phase before you start the next step.
To plan your network, follow these guidelines:
1. Complete the sizing phase that includes the following tasks:
2. Plan for management as follows:
3. Plan for application optimization as follows:
Note WCCP works only with IPv4 networks.
– If you plan to use the WCCP TCP promiscuous mode service as a traffic interception method, determine whether you should use IP access control lists (ACLs) on your routers.
Note IP ACLs that are defined on a router take precedence over the ACLs that are defined on the WAE. For more information, see Access Lists on Routers and WAEs.
– Determine whether you have to define IP ACLs or interception ACLs on the WAEs. For more information, see Access Lists on Routers and WAEs.
Note ACLs that are defined on a WAE take precedence over the Cisco WAAS application definition policies that are defined on the WAE.
– If PBR is to be used, determine which PBR method to use to verify PBR next-hop availability for your WAEs. For more information, see Methods of Verifying PBR Next-Hop Availability in the chapter “Configuring Traffic Interception” .
– Determine the major applications for your Cisco WAAS network. Verify whether the predefined application definition policies cover these applications and whether you should add policies if your applications are not covered by these predefined policies. For a list of the predefined application definition policies, see Appendix A, “Predefined Optimization Policy.”
– Consider day zero migration of file systems if file servers are to be centralized in the process. For more information, see Data Migration Process.
After you complete the planning tasks, you are ready to perform a basic configuration of a Cisco WAAS network, as described in the Cisco Wide Area Application Services Quick Configuration Guide.
Before you install and deploy Cisco WAAS devices in your network, collect information about your network to accommodate the integration of the Cisco WAAS devices.
In a typical distributed organizational layout, there are two types of networks where Cisco WAAS devices are installed:
In collaborative networks, colocated data center WAEs and branch WAEs are deployed throughout the network. These colocated WAEs are configured to share data in opposite directions (two cross-linked servers).
The WAE attaches to the LAN as an appliance. A WAE relies on packet interception and redirection to enable application acceleration and WAN optimization. Consequently, traffic interception and redirection to a WAE must occur at each site where a WAE is deployed. Traffic interception and redirection occurs in both directions of the packet flow. Because Layer 3 and Layer 4 headers are preserved, you should ensure that you always connect a WAE to a tertiary interface (or a subinterface) on the router to avoid routing loops between the WAE and the WCCP or PBR-enabled router that is redirecting traffic to it. For more information on this topic, see Using Tertiary Interfaces or Subinterfaces to Connect WAEs to Routers.
Note We strongly recommend that you do not use half-duplex connections on the WAE or on routers, switches, or other devices because half duplex impedes performance. Check each Cisco WAE interface and port configuration on the adjacent device (router, switch, firewall, or WAE) to verify that full duplex is configured.
Note The data center WAE and branch WAE communicate with each other only if the firewall is open.
This section contains the following topics:
To successfully integrate Cisco WAAS devices into the Microsoft Windows environment, you might have to perform certain tasks on both the data center WAE and branch WAE sides of the network. This section contains the following topics:
Before the initial configuration of the data center WAE, you should know the following parameters:
To successfully integrate Cisco WAAS into the Windows environment on the data center WAE side of a network where DHCP is not being used, you must manually add the name and IP address of the data center WAE to the DNS server. You should take this action before installing and deploying the Cisco WAAS devices.
Note User permissions are determined by the existing security infrastructure.
Before the initial configuration of the branch WAE, you should know the following parameters:
To successfully integrate Cisco WAAS into the Microsoft Windows environment on the branch WAE side of the network, you should take the following preliminary actions before installing and deploying the Cisco WAAS devices in your network:
Before the initial configuration of a Cisco WAAS device, you should know the following parameters:
To successfully integrate Cisco WAAS into the UNIX environment, you should perform these actions on both the data center WAE and branch WAE sides of the network:
Note To map users using automatic management, you must first configure the NIS server in both the data center WAE (primary) and branch WAE (secondary).
This section describes the SMB-related ports used between your clients, WAEs that are accelerating SMB traffic, and SMB file servers. Most SMB communication occurs between the branches and the central office. This communication is encrypted and delivered through the organization’s VPN. No ports on the firewall have to be opened because all communication is tunneled internally.
You only have to change the firewall setup if administrative or other maintenance work has to be done from a location outside the organization.
If you have deployed SMB acceleration services in your Cisco WAAS network, your WAAS network uses ports 139 and 445 to connect clients to a branch WAE and to connect a data center WAE to the associated file servers. The port that is used depends on the configuration of your Cisco WAAS network.
If WCCP is enabled or inline mode is used, the branch WAE accepts client connections on ports 139 or 445. If WCCP nor inline mode is enabled, the branch WAE accepts connections only over port 139.
Your Cisco WAAS network always tries to use the same port to communicate end-to-end. Consequently, if a client uses port 445 to connect to a branch WAE, the associated data center WAE will try to use the same port to connect to the file server. If port 445 is unavailable, the data center WAE will try to use port 139.
Note The CIFS application accelerator is removed from Cisco WAAS Version 6.0 and later, but the CIFS policy is continued for two ports: port 139 and port 445. For these ports only, the SMB application accelerator runs on CIFS policy. Therefore, an alarm generated by SMB on port 139 or port 445 is seen as a CIFS alarm.
Some organizations close port 139 on their networks to minimize the security risks associated with this port. If your organization has closed port 139 for security reasons, you can configure your Cisco WAAS network to bypass port 139. If this is the case in your organization, you should perform the following task to bypass port 139 and use port 445 in its place if you use the SMB application accelerator, running on CIFS policy, for these ports:
If you are using Windows Domain authentication with Kerberos enabled, the WAE uses ports 88 and 464 to authenticate clients with the domain controller.
Primary and standby Central Managers communicate on port 8443. If your network includes a firewall between primary and standby Central Managers, you must configure the firewall to allow traffic on port 8443 so that the Central Managers can communicate and stay synchronized.
Cisco WAAS combines Layer 4 TCP optimizations with Layer 7 application accelerators for various protocols. For some branch offices with high WAN bandwidth, for example, above 50 Mbps, if the native latency is low, for example, below 20 ms RTT, depending on the number of user sessions and data patterns, applying Layer 4 optimizations alone may provide optimal levels of performance. In such cases, we recommend that you measure end-user response times under production load to determine the appropriate operational state for the application accelerators and sizing.
Autoregistration automatically configures primary network settings and registers a WAE with the Cisco WAAS Central Manager device. On startup, a Cisco WAAS device (except for the Cisco WAAS Central Manager itself) that does not have an existing network configuration on its primary interface can automatically discover the Cisco WAAS Central Manager device and register with it. You do not have to manually configure the network settings of the primary interface on the Cisco WAAS device. This feature is useful for large-scale automated deployments of devices. After a WAE is registered, configure other interfaces and settings on the device remotely by using the Cisco WAAS Central Manager GUI.
In the example configuration provided in the Cisco Wide Area Application Services Quick Configuration Guide, the autoregistration feature is disabled on the WAEs when the setup utility is used to perform the initial configuration of the device and manually configure the interface settings.
Autoregistration uses a form of the Dynamic Host Configuration Protocol (DHCP). For autoregistration to function, you must have a DHCP server that is configured with basic settings.
Note The WAE sends CISCOCDN as the vendor-class identifier in option 60 of the DHCP DISCOVER message to facilitate your grouping of WAEs into device groups.
Autoregistration DHCP requires that the following options be present in the DHCP server’s offer:
Additionally, the DHCP offer can contain the WAE hostname (option 12), but it is not required. If the hostname option is not supplied, the WAE hostname is automatically set to NO-HOSTNAME- a-b-c-d, where a.b.c.d is the IP address that is assigned to the WAE by the DHCP server.
All of the above options, with the exception of domain name servers (option 6), replace the existing configuration on the system. The domain name servers option is added to the existing list of name servers with a restriction of a maximum of eight name servers.
After the WAE configures its network settings from DHCP, it requires the Central Manager hostname so that it can register with the Central Manager. The WAE queries the configured DNS server to obtain the Central Manager hostname. For autoregistration to work, you must configure the DNS server with the Central Manager hostname by configuring a DNS SRV (Service Location) record. This record is easy to configure and does not affect normal DNS operation. The DNS SRV record must be configured as follows:
To create an SRV record in Windows Server 2008, open the DNS Manager, navigate to Forward Lookup Zones, and select the correct DNS zone. Right click the zone, choose Other New Records, and then choose Service Location (SRV).
If the DNS request fails or if the domain is not configured, the WAE tries an alternative DNS query for an SRV record to the ciscowaas.local domain. If this alternative request also fails, the WAE cannot register with the Central Manager. However, the network configuration remains and allows you to connect through Telnet to perform additional configuration from the CLI.
Autoregistration is enabled by default on the first interface of the device. On a Cisco NME-WAE module, autoregistration is enabled on the configured interface. On an SRE-SM module (Cisco WAAS versions earlier than 6.4.x), autoregistration is disabled by default.
Note You must disable autoregistration when both device interfaces are configured as port-channel interfaces.
If you do not have a DHCP server, the device is unable to complete autoregistration and eventually times out. You can disable autoregistration at any time after the device has booted, and proceed with manual setup and registration.
To disable autoregistration, or to configure autoregistration on a different interface, use the no auto-register enable command in global configuration mode. If you want to preserve the dynamically configured IP address on the interface as a static IP address when you disable autoregistration, use the preserve-ip option with this command. This option prevents the WAE from losing network connectivity because its IP address is removed.
Note Autoregistration is automatically disabled if a static IP address is configured or if you configure interface-level DHCP on the same interface that autoregistration uses. (For more information, see Selecting Static IP Addresses or Using Interface-Level DHCP.)
The following example shows how to disable autoregistration on the interface GigabitEthernet 1/0:
Autoregistration status can be obtained by using the following show EXEC command:
For Cisco WAAS Release 6.0 and later, autoregistration is possible for a dual-stack Cisco WAAS device. In a dual-stack network, the Cisco WAAS device should be able to get a IPv6 DHCP address and an IPv6 Cisco WAAS Central Manager address through DNS entry or in the DHCP pool and then register with the Central Manager using IPv6. If IPv6 DHCP fails and IPv4 is also configured on the auto-registration interface, then the device should fall back to getting IPv4 address and proceed as it would in a IPv4-only network.
During the initial configuration, you have the option of configuring a static IP address for the device or choosing DHCP.
DHCP is a communications protocol that allows network administrators to manage their networks centrally and automate the assignment of IP addresses in an organization’s network. When an organization sets up its computer users with a connection to the network, an IP address must be assigned to each device. Without DHCP, the IP address must be entered manually for each computer, and if computers move to another location in another part of the network, the IP address must be changed accordingly. DHCP automatically sends a new IP address when a computer is connected to a different site in the network.
If you have a DHCP server configured, autoregistration automatically configures the network settings and registers WAEs with the Cisco WAAS Central Manager device upon bootup.
If you do not have a DHCP server configured, or you have a DCHP server, but do not want to use the autoregistration feature, manually configure the following network settings with the interactive setup utility or CLI, and then register the WAEs with the Cisco WAAS Central Manager device. Configure these settings:
When a Cisco WAAS device boots, you are prompted to run the first-time setup utility (enter basic configuration), which you use to set up the basic device network settings for the WAE.
This section describes Cisco WAAS interoperability with and support for how to identify and resolve interoperability issues. It contains the following topics:
The Cisco WAAS software supports Unicode in the Cisco WAAS Central Manager and the WAE Device Manager GUI interfaces.
Specifically, the root directory and file pattern fields in the preposition policies in the WAAS Central Manager GUI support Unicode.
Note the following about Unicode support limitations:
For a list of the hardware, SMB clients, and web browsers supported by the Cisco WAAS software, see the Release Note for Cisco Wide Area Application Services.
This section describes the interoperability of the WAAS software with the Cisco IOS features for a basic Cisco WAAS deployment that uses WCCP-based interception and transparent transport, and contains the following topics:
Note The Cisco WAAS software does not support Mobile IP.
We recommend that you use Cisco IOS Software Release 12.2 or later.
Classify packets by using a policy filter, for example, using QPM, that is defined on the packets. You can use the following policy filter properties:
Note Cisco WAAS software does not support QoS, MPLS QoS, ATM QoS, Frame Relay QoS, and Layer 2 (VLAN) QoS.
Unlike a traditional type of classification that is specified through a policy filter that is listed in Cisco WAAS and the Cisco IOS QoS Classification Feature, Network-Based Application Recognition (NBAR) classification needs to consider payload. The classification keeps track of any interceptor that modifies the payload because this modification might cause NBAR to not be able to classify the packets. However, the Cisco WAAS software does support NBAR.
The following is an example flow of how the Cisco WAAS software supports NBAR:
1. A packet, P1, which is a part of a TCP stream, S1, enters the router and is classified by NBAR on the LAN interface of the router as belonging to class C1. If the classification of P1 does not involve payload inspection, for example, only TCP/IP headers, no action is to be taken because the Cisco WAAS software preserves this information.
2. If P1 classification requires payload inspection, P1 should be marked using the TOS/DSCP bits in the packet (as opposed to using other internal marking mechanisms).
3. P1 is then intercepted through WCCP Version 2 (still on the LAN interface, WCCP is processed after NBAR) and is redirected to a WAE.
4. Cisco WAAS applies optimizations, if any, on the payload and copies the DCSP bits settings from the incoming TCP stream, S1, onto the outgoing stream, S2 (which is established between the local Cisco WAAS appliance and the remote Cisco WAAS appliance over the WAN). Because NBAR usually has to see some payload before performing the classification, it is unlikely that Cisco WAAS will have the proper bit settings at connection-establishment time. Consequently, the Cisco WAAS software uses polling to inspect the DSCP bits on the incoming TCP stream, and then copies it over to the stream from the Cisco WAAS device back to the router.
5. When S2 re-enters the router, NBAR will not classify S2 as belonging to C1 because the payload has been changed or compressed. However, the DSCP settings have already marked these packets as belonging to C1. Consequently, these packets will be treated appropriately as if they were classified through NBAR.
As long as the flow is not identified, NBAR will continue to search for classification in the packets. Because compressed packets will not be classified, this situation can unnecessarily burden the CPU (performing packet inspection). Because of the potential degradation in performance and the slight possibility of correctness issues, we strongly recommend that you use a subinterface or a separate physical interface to connect the WAE to the router (as described in Using Tertiary Interfaces or Subinterfaces to Connect WAEs to Routers). When you use a tertiary interface or subinterface to connect the WAE to the router, both the performance and correctness issues are addressed because each packet is processed only once.
6. For dynamic classifications, NBAR maintains a per-flow state. After certain flows are classified, NBAR does not continue to perform deep-packet inspection anymore. However, for other flows, for example, Citrix, NBAR does look at packets continuously because the classification may change dynamically in a flow. Therefore, in order to support all NBAR classifications, it is not sufficient to only poll the DSCP settings of packets coming in to Cisco WAAS once per flow; you should also poll periodically to identify flow changes. However, the Cisco WAAS system expects packets to appear in the sequence of packets belonging to the class C1, followed by a sequence of C2, and so forth, so that a polling method is sufficient to track such dynamic changes.
Note This dynamic classification support requires support for marking DSCP/ToS settings, as specified in Cisco WAAS and the Cisco IOS QoS Classification Feature, as well as the tracking of dynamic changes through polling.
Several router configurations should be followed in order to ensure NBAR-WAAS compliance, and you must ensure that the following router configurations are adhered to:
The Cisco IOS marking feature is supported by the Cisco WAAS software.
The Cisco IOS queuing feature for congestion management is supported by the Cisco WAAS software.
The Cisco IOS congestion avoidance feature is supported by the Cisco WAAS software.
The Cisco IOS traffic policing and rate-limiting feature is only partially supported by the Cisco WAAS software. This Cisco IOS feature will work properly when enabled on an outbound interface. However, when this feature is enabled on an inbound interface, it will see both compressed and uncompressed traffic, and will result in inaccurate rate limiting.
The Cisco IOS signaling (RSVP) feature is typically implemented in Multiprotocol Label Switching (MPLS) networks. Because the Cisco WAAS software does not interact with MPLS RSVP messages, the RSVP feature is supported.
The Cisco IOS link-efficiency operations are supported by the Cisco WAAS software.
The Cisco IOS AutoQoS feature is supported by the Cisco WAAS software, but requires additional configuration. This feature is closely connected with NBAR support because the AutoQoS feature uses NBAR to discover the various flows on the network. However, because the Cisco IOS AutoQoS feature is strictly on an outbound feature, for example, it cannot be enabled on the inbound side of an interface, this situation could create a potential problem because enabling NBAR on the outbound interface is not supported.
To avoid this potential problem, enable the trust option of the AutoQoS feature on the following interfaces so that classification and queuing are performed based on the marked value (NBAR is not enabled on the outbound interface using this solution):
For management instrumentation use with the Cisco WAAS software, note the following:
Note A Cisco WAAS device does not encrypt WAN traffic. If you require additional security measures, you should use a VPN. However, the VPN appliances must encrypt and decrypt traffic after and before the Cisco WAAS devices so that the Cisco WAAS device sees only unencrypted traffic. The Cisco WAAS device is unable to compress encrypted traffic and provides only limited TCP optimization to it.
MPLS is partially supported by the Cisco WAAS software. WCCP does not know how to operate with packets that are tagged with MPLS labels. Consequently, inside the cloud, WCCP redirection will not function, for example, WCCP redirection will not work for intermediate WAEs. However, as long as redirection occurs on interfaces that are outside the MPLS cloud, Cisco WAAS is supported.
A load balancer is used to balance network and application traffic across a set of servers, The resulting evenly-distributed traffic improves the response rate of network traffic, increases the availability of applications, and minimizes the risk of a single server becoming overloaded.
Table 2-1 shows the interoperability between Cisco WAAS application accelerators and the F5 load balancer. For more information about Cisco WAAS load balancing, see About Traffic Interception Methods and Configuring Policy-Based Routing in the chapter “Configuring Traffic Interception” . Also, see the Server Load-Balancing Guide vA5(1.0), Cisco ACE Application Control Engine.
Table 2-1 Cisco WAAS AOs Interoperability with Load Balancers
|
|
|
|
---|---|---|---|
If a firewall is placed between the clients and the WAE on one side, and the router on the other side of the firewall, default WCCP redirection does not work. However, if there is a router inside the firewall and another router outside the firewall, the default WCCP-based redirection does work and Cisco WAAS is supported.
Note Cisco Application and Content Networking Software (ACNS) devices, used with earlier Cisco WAAS versions to optimize web protocols, is end-of-life/end-of-sale. For more information, including migration options, see the End-of-Sale and End-of-Life Announcement for the Cisco Application and Content Networking System (ANCS) Software Version 5.5.
You must deploy the Cisco WAAS Central Manager on a dedicated appliance. Although the Cisco WAAS Central Manager device runs the Cisco WAAS software, its only purpose is to provide management functions. Cisco WAAS Central Manager communicates with the WAEs, that are registered with it in the network. Through the Cisco WAAS Central Manager GUI, you can centrally manage the configuration of the WAEs individually or in groups. The Cisco WAAS Central Manager also gathers management statistics and logs for its registered WAEs.
A WAE also runs the Cisco WAAS software, but its role is to act as an accelerator in the Cisco WAAS network.
In a Cisco WAAS network, you must deploy a Cisco WAAS device in one of the following device modes:
The default device mode for a Cisco WAAS device is WAAS accelerator mode. The device mode global configuration command allows you to change the device mode of a Cisco WAAS device.
For example, after you use the Cisco WAAS CLI to specify the basic network parameters for the designated Cisco WAAS Central Manager (the Cisco WAAS device named waas-cm) and assign it a primary interface, you can use the device mode configuration command to specify its device mode as central manager. You can also specify it to be set up as an IPv4 or an IPv6 interface during basic configuration. The following example shows the configuration of an IPv6 interface.
waas-cm#
configure
waas-cm(config)#
primary-interface gigabitEthernet 1/0 IPv6
waas-cm(config)#
device mode central-manager
waas-cm(config)#
exit
waas-cm#
copy run start
waas-cm#
reload
Proceed with reload?[confirm]
yes
Shutting down all services, will timeout in 15 minutes.
reload in progress..
Specifying the virtual interface as the primary interface for IPv6 traffic ensures that a device configured with IPv6 address only will be in Online state after registration to the Cisco WAAS Central Manager. Otherwise, the device may go into Offline state when it is registered to the Cisco WAAS Central Manager.
For more information on the primary-interface global configuration command, see the Cisco Wide Area Application Services Command Reference.
For more information about how to initially configure a WAAS device, see the Cisco Wide Area Application Services Quick Configuration Guide.
Note You cannot configure a WAE network module in the NME-WAE family of devices or SRE-SM (WAAS versions earlier than 6.4.x) family of devices to operate in Cisco WAAS Central Manager mode.
You can configure a WAE with a Cisco WAE Inline Network Adapter to operate in Cisco WAAS Central Manager mode, but the inline interception functionality is not available.
If you want to change the device mode of a device that is already registered with a Cisco WAAS Central Manager, you must first deregister the device from the Cisco WAAS Central Manager, change the device mode, reload the device, and then re-enable CMS services.
The following steps show how to change the device mode from application-accelerator to appnav-controller:
Step 1 Deregister the device from the Central Manager:
wae#
cms deregister
Step 2 Change the device mode to appnav-controller:
wae#
configure
wae(config)#
device mode appnav-controller
The new configuration will take effect after reload.
Step 3 Save the configuration and reload:
wae(config)#
exit
wae#
copy run start
wae#
reload
Step 4 Log in to the WAE after it finished rebooting:
Step 5 Re-enable CMS services:
wae
# config
wae
(config)# cms enable
Step 6 Save the configuration:
wae
(config)# exit
wae
# copy run start
Note On platforms WAVE-7571 and WAVE-8541, if the device mode is changed to Appnav controller, the connection limit is reduced for certain accelerators.
|
|
|
---|---|---|
When the threshold value of an operational system aspect is exceeded, Cisco WAAS may not meet its expected service level. This situation might result in degraded performance.
The source of the limitation might originate from a specific Cisco WAAS device (Cisco WAAS Central Manager, branch WAE, or data center WAE), the entire Cisco WAAS system, a hardware constraint, or the network connecting the distributed software entities. In some cases, the limitation might be resolved by adding more resources or by upgrading the hardware or software.
When planning your network, consider the operational capacity, such as the number of users it should support, how many files it should support, and how much data it should cache.
When planning your Cisco WAAS network, refer to the following additional guidelines:
When determining the number of the component types required by your organization, consider the following factors:
– Static capacities: Defines the number of user sessions that can connect to the system before it reaches its capacity.
– Dynamic capacities: Defines the amount of traffic handled by the servers, which means the amount of work being performed on the network. For example, consider whether the users currently connected to the system place a heavy or light load on it.
Note You should calculate dynamic limits based on the specific load assumptions that are particular to each customer.
In a Cisco WAAS network, traffic between the clients in the branch offices and the servers in the data center can be redirected to WAEs for optimization, redundancy elimination, and compression. Traffic is intercepted and redirected to WAEs based on the policies that have been configured on the routers. The network elements that transparently redirect requests to a local WAE can be a router using WCCP version 2 or PBR to transparently redirect traffic to the local WAE or a Layer 4 to Layer 7 switch, for example, the Catalyst 6500 Series Content Switching Module (CSM) or Application Control Engine (ACE).
Alternatively, a WAE that has the Cisco WAE Inline Network Adapter or Cisco Interface Module installed can operate in inline mode and receive and optimize traffic directly before it passes through the router.
In an AppNav deployment, an AppNav Controller in the data center receives intercepted traffic through WCCP, PBR, or inline mode, and distributes it to Cisco WAAS nodes that optimize the traffic. For more information on an AppNav deployment, see the chapter “Configuring Cisco AppNav” .
This section contains the following topics:
For detailed information about how to configure traffic interception for your Cisco WAAS network, see the chapter “Configuring Traffic Interception” .
Inline interception requires usage of a WAE appliance that has the Cisco WAE Inline Network Adapter, Cisco Interface Module, or Cisco AppNav Controller Interface Module installed. In inline mode, the WAE can physically and transparently intercept traffic between the clients and the router. When using this mode, you physically position the WAE device in the path of the traffic that you want to optimize, typically between a switch and a router.
Because redirection of traffic is not necessary, inline interception simplifies deployment and avoids the complexity of configuring WCCP or PBR on the routers.
The inline adapter or module contains one or more pairs of LAN/WAN Ethernet ports, each grouped into an inline or bridge group interface. If the inline adapter or module has multiple pairs of ports, it can connect to multiple routers if the network topology requires it.
The inline or bridge group interface transparently intercepts the traffic flowing through it or bridges traffic that does not have to be optimized. It also uses a mechanical fail-safe design that automatically bridges traffic if a power, hardware, or unrecoverable software failure occurs.
Note The AppNav Controller Interface Modules do not support automatic bypass mode to continue traffic flow in the event of a failure. For high availability, two or more AppNav Controller Interface Modules should be deployed in an AppNav cluster. For more information on using inline mode with the AppNav solution, see the chapter “Configuring Cisco AppNav”.
You can configure the inline or bridge group interface to accept traffic only from certain VLANs; for all other VLANs, traffic is bridged, and not processed. You can serially cluster WAE devices (not AppNav Controllers) in inline mode to provide higher availability in the event of a device failure. If the current optimizing device fails, the second WAE device in the cluster provides the optimization services. Deploying WAE devices in a serial inline cluster for the purposes of scaling or load balancing is not supported.
Any combination of traffic interception mechanisms on peer WAEs is supported. For example, you can use inline interception on the branch WAE and WCCP on the data center WAE. For complex data center deployments, we recommend that you use hardware-accelerated WCCP interception or load balancing with the Cisco Application Control Engine (ACE) and a Cisco WAAS AppNav deployment.
For more information on inline interception, see Cisco ITD Support in the chapter “Configuring Traffic Interception” .
Three elements can help ease traffic interception in data centers without using a WCCP-based approach:
WCCP (Web Cache Communication Protocol) specifies interactions between one or more routers (or Layer 3 switches) and one or more application appliances, web caches, and caches of other application protocols. The purpose of the interaction is to establish and maintain the transparent redirection of selected types of traffic flowing through a group of routers. The selected traffic is redirected to a group of appliances.
WCCP allows you to transparently redirect client requests to a WAE for processing. The Cisco WAAS software supports transparent intercept of all TCP traffic.
To configure basic WCCP, enable “WCCP” as the “interception method” on the router and WAE or ANC in the data center, and the router or WAE in the branch office. By default, WCCP Version 2 is used with Cisco WAAS. You do not have to configure all of the available WCCP features or services in order to get a WAE up and running.
Note You must configure the routers and WAEs to use WCCP Version 2 instead of WCCP Version 1, because WCCP Version 1 supports only web traffic (Port 80). The routers must be running a version of Cisco IOS software that also supports WCCP Version 2.
WCCP is much simpler to configure than PBR. However, you should have write access to the router in order to configure WCCP on the router, which typically resides in the data center and on the edge of the branch office. Another advantage of using WCCP is that you have to perform only a basic configuration of WCCP on your routers and WAEs in order to get your WAE up and running.
The WCCP Version 2 protocol also has a set of useful features built-in, for example, automatic failover and load balancing between multiple devices. The WCCP-enabled router monitors the liveliness of each WAE or ANC that is attached to it through the WCCP keepalive messages. If a WAE goes down, the router stops redirecting packets to the WAE. When you use WCCP Version 2, the branch WAE is not made a single point of failure for the Cisco WAAS services. The router or ANC can also load balance the traffic among a number of branch WAEs.
You can use CLI commands to configure basic WCCP on both the routers and the WAEs, or you can use CLI commands to configure the router for WCCP and use the Cisco WAAS Central Manager GUI to configure basic WCCP on the WAEs.
We recommend that you use the Cisco WAAS CLI to complete the initial basic configuration of WCCP on your first branch WAE and data center WAE, as described in the Cisco Wide Area Application Services Quick Configuration Guide. After you have verified that WCCP transparent redirection is working properly, you can use the Cisco WAAS Central Manager GUI to centrally modify this basic WCCP configuration or configure additional WCCP settings, for example, load balancing, for a WAE (or group of WAEs). For more information, see Configuring WCCP on WAEs in the chapter “Configuring Traffic Interception” . After you have configured basic WCCP on the router, you can configure advanced WCCP features on the router, as described in Configuring Advanced WCCP Features on Routers in the chapter “Configuring Traffic Interception” .
PBR allows IT organizations to configure their network devices (a router or a Layer 4 to Layer 6 switch) to selectively route traffic to the next hop, based on the classification of the traffic. WAAS administrators can use PBR to transparently integrate a WAE into their existing branch office network and data centers. PBR can be used to establish a route that goes through a WAE for some or all packets, based on the defined policies.
To configure PBR, you must create a route map and then apply the route map to the router interface on which you want the transparent traffic redirection to occur. Route maps reference access lists that contain explicit permit or deny criteria. The access lists define the traffic that is interesting to the WAE, that is, traffic that the network device should transparently intercept and redirect to the local WAE. Route maps define how the network device should handle interesting traffic, for example, send the packet to the next hop, which is the local WAE.
The following list summarizes the main advantages of using PBR instead of WCCP Version 2 to transparently redirect IP/TCP traffic to a WAE:
The following list summarizes the main disadvantages of using PBR instead of WCCP Version 2 to transparently redirect IP/TCP traffic to a WAE:
The primary function of Cisco WAAS is to accelerate WAN traffic. In general, Cisco WAAS accelerates TCP traffic, and uses a symmetric approach for application optimization. A WAE that has application-specific and network-specific intelligence is placed on each side of the WAN. These WAEs are deployed out of the data path in both the branch office and the data center.
Traffic between the clients in the branch offices and the servers at the data center is transparently redirected through the WAEs based on a set of configured policies with no tunneling. The routers use WCCP Version 2 or PBR to transparently intercept and redirect traffic to the local WAE for optimization, redundancy elimination, and compression. For example, Edge-Router1 uses PBR or WCCP Version 2 to transparently redirect traffic to Edge-WAE1, the local WAE in the branch office. Core-Router1 uses PBR or WCCP Version 2 to transparently redirect traffic to the Core-WAE1, the local WAE in the data center.
Note In this sample deployment, Edge-Router1 and Core-Router1 can be replaced with Layer 4 to Layer 7 switches, which are capable of redirecting traffic to the local WAE.
Figure 2-1 shows that the WAEs (Edge-WAE1 and Core-WAE1) must reside in an out-of-band network that is separate from the traffic’s destination and source. For example, Edge-WAE1 is on a subnet that is separate from the clients (the traffic source), and Core-WAE1 is on a subnet that is separate from the file servers and application servers (the traffic destination). Additionally, you may have to use a tertiary interface (a separate physical interface) or a subinterface to attach a WAE to the router, which redirects traffic to it, in order to avoid an infinite routing loop between the WAE and the router. For more information about this, see Using Tertiary Interfaces or Subinterfaces to Connect WAEs to Routers.
Figure 2-1 Using PBR or WCCP Version 2 for Transparent Redirection of All TCP Traffic to WAEs
Table 2-2 provides a summary of the router interfaces that you must configure to use PBR or WCCP Version 2 to transparently redirect traffic to a WAE.
This traffic redirection does not use tunneling; the full original quadruple (source IP address, source port number, destination IP address, and destination port number) of the TCP traffic is preserved end to end. The original payload of the TCP traffic is not preserved end to end because the primary function of Cisco WAAS is to accelerate WAN traffic by reducing the data that is transferred across the WAN. This change in payload can potentially impact features on the router that is performing the WCCP or PBR redirection, and that needs to see the actual payload to perform its operation, for example, NBAR. For more information on this topic, see Cisco WAAS and Cisco IOS Interoperability.
Using WCCP or PBR at both ends with no tunneling requires that traffic is intercepted and redirected not only in the near-end router but also at the far-end router, which requires four interception points, as opposed to two interception points in a tunnel-based mode.
You can enable packet redirection on either an outbound interface or inbound interface of a WCCP-enabled router. The terms outbound and inbound are defined from the perspective of the interface. Inbound redirection specifies that traffic should be redirected as it is being received on a given interface. Outbound redirection specifies that traffic should be redirected as it is leaving a given interface.
If you are deploying WAN optimization in your Cisco WAAS network, you must configure the router and WAE for WCCP Version 2 and the TCP promiscuous mode service (WCCP Version 2 services 61 and 62 by default).
Note Services 61 and 62 are always enabled together when configuring TCP promiscuous mode on the WAE. Services 61 and 62 must be defined and configured separately when configuring TCP promiscuous mode on the network device (router, switch, or other). Service 61 distributes traffic by source IP address, and service 62 distributes traffic by destination IP address. The service IDs are configurable; 61 and 62 are the defaults.
The TCP promiscuous mode service intercepts all the TCP traffic that is destined for any TCP port and transparently redirects it to the WAE. The WCCP-enabled router uses service IDs 61 and 62 to access this service. The service IDs used on the router must match those on the WAE if service IDs that are different from the defaults are configured.
By default, IP Protocol 6 is specified for the TCP promiscuous mode service. Consequently, the routers that have been configured to the TCP promiscuous mode service will intercept all the TCP traffic destined for any TCP port to the local WAE. Because the TCP promiscuous mode service is configured on the WAE, the WAE will accept all of the TCP traffic that is transparently redirected to it by specified WCCP routers, for example, Edge-WAE1 will accept all TCP traffic that Edge-Router1 redirects to it. In the branch office, you can intercept packets at the edge LAN and WAN interfaces on the Edge routers and redirect the TCP traffic to the local WAE (the branch WAE). In the data center, you can intercept packets at the core LAN and WAN interfaces on the core routers and redirect the TCP traffic to the local WAE (the data center WAE). For more information, see Configuring WAEs as Promiscuous TCP Devices in a Cisco WAAS Network.
Configure packet redirection on inbound interfaces of branch software routers whenever possible. Inbound traffic can be configured to use Cisco Express Forwarding (CEF), distributed Cisco Express Forwarding (dCEF), fast forwarding, or process forwarding.
Note CEF is required for WCCP, and must be enabled on the router.
To enable packet redirection on a router’s outbound or inbound interface using WCCP, use the ip wccp redirect interface configuration command.
For a WAE to function as a promiscuous TCP device for the TCP traffic that is transparently redirected to it by the specified WCCP Version 2 routers, the WAE uses WCCP Version 2 services 61 and 62 by default, though the service IDs are configurable. The WCCP services are represented by the canonical name tcp-promiscuous on the WAE CLI and TCP Promiscuous in the Cisco WAAS Central Manager GUI. (See Figure 5-3.)
For instructions on how to perform a basic WCCP configuration for a WAAS network, see the see the Cisco Virtual Wide Area Application Services Quick Configuration Guide.
For instructions about how to use the Cisco WAAS Central Manager GUI to modify the basic WCCP configuration for a WAE, see Configuring WCCP on WAEs in the chapter “Configuring Traffic Interception” .
If you plan to use WCCP Version 2 or PBR to transparently redirect TCP traffic to a WAE, make sure that the WAE is not attached to the same segment as the router interface on which the traffic redirection is to occur. Otherwise, an infinite routing loop between the router and the WAE will occur. These infinite routing loops occur because there is no way to notify the router to bypass the interception and redirection after it has redirected the traffic to the WAE the first time; the router will continuously redirect the same intercepted traffic to the local WAE, creating the infinite routing loop.
Note The WCCP GRE return and generic GRE egress methods allow you to place WAEs on the same VLAN or subnet as clients and servers. For information on configuring these egress methods, see Configuring Egress Methods for WCCP-Intercepted Connections in the chapter “Configuring Traffic Interception”.
For example, if you attach Edge-WAE 1 to the same segment (subnet) as the LAN router interface on which the PBR or WCCP traffic redirection occurs in the branch office, there will be an infinite routing loop between Edge-Router1 and Edge-WAE1. If you attach Core-WAE1 to the same segment (subnet) as the LAN router interface on which the PBR or WCCP traffic redirection occurs in the data center, there will be an infinite routing loop between Core-Router1 and Core-WAE1.
To avoid an infinite routing loop between the router and its local WAE, connect the WAE to the router through a tertiary interface (a separate physical interface) or a subinterface (a different virtual subinterface) from the router’s LAN port. By using a tertiary interface or a subinterface to connect a WAE to the router that is performing the PBR or WCCP redirection, the WAE has its own separate processing path that has no Cisco IOS features enabled on it. In addition, this approach simplifies the process of integrating WAEs into an existing network. Because the WAEs are being connected to the routers through a tertiary interface or subinterface that has no Cisco IOS features enabled on it, the Cisco IOS features that are already enabled on your existing Cisco-enabled network elements, for example, Edge-Router1 or Core-Router1, will generally not be affected when you connect WAEs to these routers. For more information about Cisco WAAS and Cisco IOS interoperability, see Cisco WAAS and Cisco IOS Interoperability.
For an example of how to use a subinterface to properly attach a local WAE to the router that is redirecting TCP traffic to it, see the Cisco Virtual Wide Area Application Services Quick Configuration Guide.
You can optionally configure the router to redirect traffic from your WAE based on the access lists that you define on the router. These access lists are also referred to as redirect lists. For information about how to configure access lists on routers that will be configured to transparently redirect traffic to a WAE, see Configuring IP Access Lists on a Router in the chapter “Configuring Traffic Interception” .
Note IP access lists on routers have the highest priority, followed by IP ACLs that are defined on the WAEs, and then interception ACLs that are defined on the WAEs.
This section contains the following topics:
In a centrally managed Cisco WAAS network environment, administrators need to be able to prevent unauthorized access to various devices and services. The Cisco WAAS software supports standard and extended IP access control lists (ACLs) that allow you to restrict access to or through particular interfaces on a Cisco WAAS device. For more information, see the chapter “Creating and Managing IP Access Control Lists for Cisco WAAS Devices” .
Note IP ACLs that are applied on interfaces, and WCCP ACLs, always take precedence over any interception ACLs and Cisco WAAS application definitions, if any, that have been defined on the WAE.
You can configure an interception ACL to control what incoming traffic across all interfaces should be intercepted by a WAE device. Packets that are permitted by the ACL are intercepted by the WAE and packets that are denied by the ACL are passed through the WAE without processing. By configuring interception ACLs on the WAE, you can control traffic interception without modifying the router configuration.
An interception ACL can be used both with WCCP and inline interception.
Interception ACLs that are defined on a WAE always take precedence over any Cisco WAAS application definitions that have been defined on the WAE, but they are applied after interface ACLs and WCCP ACLs.
For information about how to configure an interception ACL for a WAE, see the Configuring Interception Access Control Lists in “Configuring Traffic Interception” .
In a Cisco WAAS network, administrative login authentication and authorization are used to control login requests from administrators who want to access a Cisco WAAS device for configuring, monitoring, or troubleshooting purposes.
Login authentication is the process by which Cisco WAAS devices verify whether the administrator who is attempting to log in to the device has a valid username and password. The administrator who is logging in must have a user account registered with the device. User account information serves to authorize the user for administrative login and configuration privileges. The user account information is stored in an AAA database, and the Cisco WAAS devices must be configured to access the particular authentication server (or servers) where the AAA database is located. When the user attempts to log in to a device, the device compares the person’s username, password, and privilege level to the user account information that is stored in the database.
The Cisco WAAS software provides the following authentication, authorization, and accounting (AAA) support for users who have external access servers, for example, RADIUS, TACACS+, or Windows domain servers, and for users who need a local access database with AAA features:
For more information, see Configuring AAA Accounting for Cisco WAAS Devices in the chapter “Configuring Administrative Login Authentication, Authorization, and Accounting” .
In a centrally managed Cisco WAAS network, administrator accounts can be created for access to the Cisco WAAS Central Manager and, independently, for access to the WAEs that are registered with the Cisco WAAS Central Manager. There are two distinct types of accounts for WAAS administrators:
Note An administrator can log in to the Cisco WAAS Central Manager device through the console port or the Cisco WAAS Central Manager GUI. An administrator can log in to a Cisco WAAS device that is functioning as a data center or branch WAE through the console port or the Cisco WAE Device Manager GUI.
A Cisco WAAS device that is running Cisco WAAS software comes with a predefined superuser account that can be used initially to access the device. When the system administrator logs in to a Cisco WAAS device before authentication and authorization have been configured, the administrator can access the Cisco WAAS device by using the predefined superuser account (the predefined username is admin and the predefined password is default). When you log in to a Cisco WAAS device using this predefined superuser account, you are granted access to all the Cisco WAAS services and entities in the Cisco WAAS system.
After you have initially configured your Cisco WAAS devices, we strongly recommend that you immediately change the password for the predefined superuser account (the predefined username is admin, the password is default, and the privilege level is superuser, privilege level 15) on each Cisco WAAS device. For instructions on how to use the Cisco WAAS Central Manager GUI to change the password, see Changing the Password for Your Own Account in the chapter “Creating and Managing Administrator User Accounts and Groups” .
To streamline the configuration and maintenance of WAEs that are registered with a Cisco WAAS Central Manager, you can create a logical group and then assign one or more of your WAEs to the group. Groups not only save you time when configuring multiple WAEs, but they also ensure that configuration settings are applied consistently across your Cisco WAAS network. For example, you can set up a WinAuth group that defines the standard Microsoft Windows authentication configuration that is wanted for all of the WAEs in that group. After you define the WinAuth settings once, you can centrally apply those values to all of the WAEs in the WinAuth group instead of defining these same settings individually on each WAE.
With the Cisco WAAS Central Manager GUI, you can easily organize your branch and data center WAEs into device groups, which are a collection of WAEs that share common qualities and capabilities. Setting up groups based on their authentication settings is an example of a device group.
When you create a device group, you should identify the unique characteristics that distinguish that group of WAEs from others in your network. For example, in larger Cisco WAAS deployments, one set of WAEs may have to be configured with authentication settings that are different from another set of WAEs in your Cisco WAAS network. In such a scenario, you should create two device groups, each of which contain different authentication settings, and then assign your WAEs to the most appropriate group.
If you have WAEs that reside in different time zones, you can also create device groups based on geographic regions so that the WAEs in one group can have a different time zone setting from the WAEs in another group.
In smaller Cisco WAAS deployments where all WAEs can be configured with the same settings, you may only have to create one general device group. This practice allows you to configure settings for the group, and then apply those settings consistently across all your WAEs.
Note The AllWAASGroup and AllWAASExpressGroup are default device groups that automatically contain all Cisco WAAS and Cisco WAAS Express devices. In these or any other device groups, you should configure only the settings that you want to be consistent across all the devices in the group. Settings that apply to a single device should be configured on that device only and not on the device group.
By default, Cisco WAAS Central Manager allows you to assign a device to multiple device groups. Before you create a device group, make sure you understand the unique properties that you want the group to contain.
The Cisco WAAS Central Manager allows you to create locations that you can associate with a Cisco WAAS device. You assign a device to a location when you first activate the device. The main purpose of assigning a Cisco WAAS device to a location is to help you identify a Cisco WAAS device by the physical region in which it resides. Locations are different from device groups because devices do not inherit settings from locations.
You assign a device to a location when you activate the device, as described in the Cisco Wide Area Application Services Quick Configuration Guide. For more information about logically grouping your WAEs, see the chapter “Using Device Groups and Device Locations” .
If you have an existing network, you must perform some tasks before setting up your Cisco WAAS network. The first step in the data migration process is to back up the data at the branch offices and restore it to the data center.
After you back up data to the data center, you should preload the cache (called preposition) with the files for which you want to provide the fastest access. Set up the files from your branch office file server to the WAEs that are also located in the same branch office. You can then remove the file servers from the branch offices and point to the data center file server.
The final step in the data migration process is to set the SMB policies.
When performing the data migration process, note the following restrictions:
– You can use backup or restore software to restore an initial backup of the tree to the target server. This practice allows both the creation of ACLs as well as the creation of the initial file set that Rsync can take as an input for diff calculations. The replication inherits the existing ACLs in that tree.
– The other option is to perform a first run of Robocopy (including data and permissions), and then continue with sync iterations using Rsync.
After replicating, use one of Microsoft’s tools for copying only ACLs (no data) onto the replicated tree. You can use Robocopy.exe for copying the directory tree or file ACLs, and Permcopy.exe to copy share permissions.