The previous chapters have introduced the capabilities of the Cisco WAAS solution and described how the WAE appliances and network modules are integrated into the network. This chapter focuses on how the Cisco WAE devices are initially deployed in the network and then managed centrally by the Cisco WAAS Central Manager.
This chapter provides an overview of Cisco WAE device management and system management, including the capabilities of each. The chapter then focuses on the installation and configuration of each of the components. Device groups, which help minimize ongoing configuration and management overhead, are discussed and examined. Provisioned management capabilities, enabled through role-based access control (RBAC), are discussed and a focus is provided on integrating with external authentication systems. The chapter concludes with a discussion focusing on integration of Cisco WAAS into third-party management and monitoring systems using SNMP and syslog.
It should be noted that this chapter does not provide an exhaustive review of everything that can be configured within Cisco WAAS. Rather, it examines the items necessary to get a system of devices functionally available and ready for central management. Other chapters in this book focus on the details of configuring specific components on a device or within the system. Thus, this chapter lays the management framework foundation that other chapters build upon.
Each Cisco WAE device can be managed through one of two primary interfaces: the command-line interface (CLI) or the Central Manager (CM) GUI. Deploying a Cisco WAE device requires that you connect to the device through a serial connection to run a CLI initial setup script, which is able to apply the appropriate configuration to the device to make it reachable on the network. Once the WAE device is reachable on the network, you can then connect it to the CM, through the Central Management Subsystem (CMS) service discussed later in this section, or configure it further from the CLI. Use of the CM is recommended, because it is designed to simplify management of each device and the system as a whole while also providing individual device reports and aggregate reports.
This section examines the Cisco WAE setup script and CLI, and provides an overview of the CM and CMS service that runs on each Cisco WAE. This section provides a foundation for future sections in the chapter.
Cisco WAE devices are configured to automatically run the setup script when the device boots for the first time and the administrator is connected to the WAE via a serial connection (9600 baud, 8 data bits, 1 stop bit, no parity bits). The setup script walks you through a series of questions to define the initial configuration of key device settings, including:
Network interface speed and duplex (or auto-negotiate)
Network layer configuration (DHCP or static configuration with IP address, subnet mask, default gateway, DNS server, and domain name)
At the end of the initial setup script, you are prompted to save the configuration defined by the responses provided to the script. An example of the initial setup script is shown in Example 7-1.
Note
Cisco WAE devices use the startup-config and running-config files in an identical manner to Cisco IOS devices. The setup script ultimately populates these files with the relevant configuration components based on the responses supplied by you.
Example 7-1. Initial Setup Script
WARNING: Changing any of the network settings from a telnet session may render the device inaccessible on the network. Therefore it is suggested that you have access to the console before modifying the network settings. Please choose an interface to configure from the following list: 1: GigabitEthernet 1/0 2: GigabitEthernet 2/0 Enter choice: 1 Do you want to configure speed and duplex mode of this interface (y/n) [y]: y Please enter the speed of this interface (10/100/1000) [100]: 100 Please enter duplex mode (half/full) [full]: full Do you want to enable DHCP on this interface (y/n) [n]: n Please enter the IP address of this interface: 10.10.10.10 Please enter the netmask of this interface: 255.255.255.0 Please enter the default gateway: 10.10.10.1 Please enter the domain name server ip: 10.10.10.100 Please enter the domain name: cisco.com Please enter the hostname: WAE Based on the following input, the following CLIs will be configured: interface GigabitEthernet 1/0 ip address 10.10.10.10 255.255.255.0 no autosense bandwidth 100 full-duplex exit ip default-gateway 10.10.10.1 ip name-server 10.10.10.100 ip domain-name cisco.com hostname WAE Do you want to apply the configurations (y/n) [y]: y
Note
When using auto-negotiate on the WAE, ensure that the adjacent device switchport (for instance, on the switch) is configured as auto-negotiate or full-duplex. Always verify that the connection between the WAE and the adjacent device uses full-duplex operation by using the relevant show interface commands on both the switch and the WAE. Use of half duplex will result in lower performance than what is possible when using full duplex.
It is recommended that duplex be hard-coded when working with interface speeds other than Gigabit. Gigabit configurations are automatically full duplex.
This setup script is available upon subsequent boot operations by interrupting the boot sequence by pressing Enter when prompted by the CLI and setting boot flags. Alternatively, you can execute the command setup to run the setup script again in the future. Example 7-2 shows where the boot sequence is interrupted, and what prompts are provided.
Example 7-2. Interrupting the WAE Boot Sequence
Cisco WAAS boot:hit RETURN to set boot flags:0009 Available boot flags (enter the sum of the desired flags): 0x4000 - bypass nvram config 0x8000 - disable login security [CE boot - enter bootflags]:0x8000 You have entered boot flags = 0x8000 Boot with these flags? [yes]:yes Setting the configuration flags to 0x8000 lets you into the system, bypassing all security. Setting the configuration flags field to 0x4000 lets you bypass the NVRAM configuration.
Although the setup script will get the Cisco WAE onto the network, further configuration is necessary to leverage the full acceleration capabilities of Cisco WAAS and centralized management. Along with supplying the basic network information, you must also set the primary interface, define the device mode, define the CM (when configuring an accelerator), enable CMS, and finally save the configuration.
The primary interface of the WAE is used to determine which interface will be used for CM registration, status and health message exchange, and CIFS acceleration transport binding. The primary interface must be assigned prior to enabling CMS, and is performed through the command shown in Example 7-3.
Example 7-3. Defining the WAE Primary Interface
WAE1# config term WAE1(config)# primary-interface gigabitEthernet 1/0
It is important to ensure that the WAE is able to reach any management-related peers (CM, syslog servers, SNMP servers). Always ensure that the primary interface defined is either on the same subnet as the default gateway or that the appropriate static routes are defined. In most deployments, the primary interface is adjacent to the default gateway, but in situations where multiple addressable WAE interfaces are configured, there may be situations where the default gateway is adjacent to an interface that is not the primary interface. In such deployments, static routes must be defined that point to the next-hop router for the interface that is not the primary interface.
The next step after defining the primary interface is to specify the device mode. The device mode dictates the “personality” of the WAE. For WAEs that are being deployed as a CM (whether it is primary or standby), the “central-manager” device mode would be applied, whereas for WAEs that are being deployed in the network for the purposes of acceleration, the “application-accelerator” device mode would be used (a detailed examination of Central Manager is provided later in the chapter). A Cisco WAE can run only one device mode at a time and cannot run both device modes concurrently. Example 7-4 shows how to specify the device mode for a Cisco WAE.
Note
Cisco WAEs default to the “application-accelerator” device mode. When configuring a Cisco WAE with the “central-manager” device mode for the first time, you need to reboot the WAE. The console session will notify you of this requirement. Be sure to save your configuration prior to rebooting the WAE. This step can be skipped when deploying devices that will participate in acceleration services, because the configuration will default to the appropriate device mode.
When configuring a Cisco WAE as a CM, it is important to also specify the role (either a primary or standby CM). Configuring a Cisco WAE as a “primary” makes it the active CM in the deployment. Configuring a Cisco WAE as a “standby” makes it a backup for the primary. Standby CM WAEs will, like WAEs configured as accelerators, continually synchronize with the primary CM, including all configuration and reporting data for the entire WAAS network. WAEs configured as standby CMs may be configured before the primary CM has been configured; however, CMS cannot be enabled on a standby CM until the primary CM is configured, operational, and reachable on the network. Example 7-5 shows the command syntax for specifying a CM role.
Example 7-5. Configuring Central Manager Role
WAE1(config)# central-manager role ? primary Set Central Manager role to primary standby Set Central Manager role to standby WAE1(config)# central-manager role primary
Note
Cisco WAEs that have been configured as CMs through the device mode command default to a CM role of primary. To configure a CM as a standby, be sure to use the command shown in Example 7-5.
The next configuration step for each Cisco WAE other than the primary CM is to specify who the CM is (WAEs that are defined as a primary CM use themselves as the primary CM). This step tells the WAE either the IP address or the hostname of the primary CM WAE. If you are using a hostname for the CM address definition, ensure that DNS is configured and working properly. Use of a hostname for the CM address definition is recommended, because it provides IP address portability for the CM WAE. Should you need to change the IP address of the CM, and each managed WAE uses the DNS name of the CM WAE in its configuration, no change is needed to all of the WAEs in the network. If managed WAEs in the network use the IP address of the CM in their configuration and you need to change the IP of the CM, you would need to change the definition on each managed WAE in the network. Example 7-6 shows how to point a WAE to the CM.
Once the CM has been defined, and you have verified that the CM is reachable through the network (by ping or other mechanism), you can then enable CMS on each of the WAEs in the network. CMS is a service that runs locally on each WAE that allows it to remain loosely synchronized with the current primary CM based on a scheduled defined within the CM itself. The CMS service allows you to employ configuration changes from the CM GUI and have those changes propagate to the relevant WAEs managed by that CM. Additionally, the CM continuously collects health, monitoring, and reporting data from each of the managed WAEs and provides visualization and reports for you. You must enable CMS not only on the CM WAEs but also on all accelerator WAEs in the network. Example 7-7 shows how to enable CMS services on a WAE.
Example 7-7. Enabling Centralized Management Services
WAE1(config)# cms enable
Generating new RPC certificate/key pair
Restarting RPC services
Registering WAAS Central Manager...
Please wait, initializing CMS tables
Successfully initialized CMS tables
Registration complete.
Please preserve running configuration using 'copy running-config startup-config'.
Otherwise management service will not be started on reload and node will be shown
'offline' in WAAS Central Manager UI.
management services enabledNote
This command must be completed after the definition of the primary interface, device mode and role, and specifying the IP or hostname of the CM. Always use the IP or hostname of the primary CM and not the standby. CMS must be enabled on every WAE in the network.
Finally, it is best practice to save your configuration often. As with other Cisco devices, using the trusted write mem or copy run start command will suffice.
As demonstrated in the previous section, each WAE is equipped with a fully functional Cisco IOS–like CLI. This CLI is available through a serial connection, Telnet, or SSH. By default, Telnet is enabled and SSH is disabled. Example 7-8 shows how to disable Telnet and enable SSH if so desired.
Example 7-8. Controlling Console Access to the WAE
WAE1(config)# no telnet enable WAE1(config)# ssh-key-generate key-length 1024 WAE1(config)# sshd version 2 WAE1(config)# sshd enable
Note
The ssh-key-generate command supports key lengths between 512 and 1024 bytes. The key length should not be less than 768 bytes due to compatibility problems with most modern SSH clients.
The WAE CLI enables you to adjust every aspect of the WAE configuration that is isolated to that particular WAE. This includes network integration, network interception, and local optimization policies. Functions that are implemented at a system level that involve interaction between multiple WAEs, such as CIFS acceleration, must be configured from the CM GUI. It is recommended that, due to its simplicity, you use the CM for all aspects of device configuration when possible. This also helps ensure configuration and policy consistency across a global network of devices, which will minimize ongoing administration and troubleshooting.
The WAE CLI also provides you with insight into detailed statistics about the WAE. Such statistics include network statistics, optimization statistics (including compression ratios and connections optimized), and hardware utilization (CPU, disk, memory). This data is also captured during the CMS synchronization process and is sent to the CM for reporting and monitoring. An examination of key statistics and reports is provided in Chapter 8, “Configuring WAN Optimization,” and Chapter 9, “Configuring Application Acceleration.”
The Cisco WAAS Central Manager is a secure, scalable, and simple management system built on a distributed computing architecture that is designed to simplify the deployment, management, and monitoring of a large-scale Cisco WAAS network. Central Manager is a device mode that is configured on a WAE in the network. After services have been initialized and activated, this WAE then provides a web GUI for management users, while also communicating directly with each Cisco WAE in the network for the purposes of
Synchronizing device configuration
Gathering health and liveliness information
Retrieving monitoring and statistics data
Central Manager is secure in that it uses HTTP over Secure Sockets Layer (HTTPS using TCP port 8443) for management GUI access. Users must authenticate to the CM either using a preconfigured local user account or through integration with a back-end authentication provider such as RADIUS, TACACS, or Active Directory. Furthermore, all data exchange between the CM and managed WAE accelerators is done using HTTPS over TCP port 443. Key management is simplified with Cisco WAAS in that keys are self-signed and generated by the CM and the managed nodes.
Note
If firewalls exist in your environment, be sure to allow TCP ports 443 and 8443 to pass through. These ports are used for management and CMS services. It is also recommended that ports for Telnet (TCP 23), SSH (TCP 22), SNMP (UDP 161, 162) and syslog (UDP 514) be permitted. NetBIOS (TCP 135, 137, 138, 139) should be enabled if registering a WAE into a domain when a firewall is deployed between the WAE and the domain controller. CIFS ports should be enabled when using WAE print services where users are connecting through a firewall (TCP 139, 445, 50139). DNS ports should be enabled when performing name resolution on a WAE through a firewall (UDP 53).
Central Manager is scalable in that up to 2500 nodes can be managed under a single CM. The number of nodes that can be managed by a single CM is based on which hardware platform is selected. Sizing for CM was discussed in detail in Chapter 2, “Cisco Wide Area Application Engine (WAE) Family”. Additionally, a standby CM can be deployed to ensure high availability. Because the standby CM WAE synchronizes its local CMS database with the primary CM (including configuration, monitoring data, reporting data, and more), if the primary fails, the standby can take over operation. Deploying a standby CM provides only high availability and does nothing to increase the number of nodes that can be managed. For deployments larger than 2500 nodes, multiple autonomous (independent) CMs will be necessary.
Central Manager is simple in that it provides a powerful yet easy-to-use interface for managing a large WAAS deployment and powerful reporting capabilities. CM has the ability to logically group WAE devices into device groups, which allows you to apply a configuration change to a single entity. Changes applied to a device group are automatically propagated to the managed WAEs within that device group by the CM. With device groups, you can apply a configuration change across the entire WAAS network with a few clicks, and the CM handles the distribution of the configuration change automatically to all WAE devices in the device group.
Figure 7-1 shows the CM GUI login page, which is accessible by browsing to the IP address or DNS name of the CM WAE using HTTPS and specifying port 8443 (that is, https://ip_address_of_cm_wae:8443). The default administrator account is admin and the default password for this account is default.
Figure 7-2 shows the CM homepage that is displayed after login. Notice that the CM homepage provides the following information and functions:
System Status: Health indicator showing whether or not any alarms have been triggered and their severity. System status is displayed as a series of lights of different colors (including green, amber, yellow, and red).
Devices: Displays the number of WAE devices in the Cisco WAAS network, and the number of WAE devices configured as core or edge CIFS acceleration devices.
Software Version(s): Displays the software versions installed on the WAE devices in the Cisco WAAS network. If disparate software versions are detected, each is listed.
Reports: Include the application traffic mix for the last week, and the top 10 applications by percent reduction for the last week.
Active Alarms and Acknowledged Alarms: Provide details of the alarms that have been triggered, the associated device, severity, and additional data.
The CM allows you to configure virtually every aspect of the Cisco WAAS network, including device configuration, network configuration, network interception, domain integration, optimization policies, and local services (such as print services). Instead of providing an exhaustive examination of each here, details about each are provided in the appropriate sections for each of these topic areas.
As shown in Figure 7-2, the CM has a hierarchical table of contents; that is, task items are nested within three major tabs, or groupings:
Devices: All configuration aspects of devices and device groups within the Cisco WAAS network, WAN optimization policies, device activation, network interception, and location groups
Services: Configuration of system-wide acceleration services, including CIFS acceleration, print services configuration, application groups, and optimization topology
System: Configuration of system-wide management-related parameters, including CMS intervals, software upgrade and rollback, AAA (authentication, authorization, and accounting), and system logs
The Centralized Management System (CMS) service is the heart of the management and monitoring framework for Cisco WAAS. CMS is the process that runs on each WAE in the network—whether it is a CM WAE or an accelerator—and ensures that configuration and statistical information remain synchronized between the CM WAE and each managed WAE. CMS uses self-signed and self-generated certificates to encrypt communications between the CM WAE and each managed WAE, and all transmission occurs over TCP port 443. The certificates that are used by CMS are generated when CMS is initialized for the first time, as shown in Example 7-7 earlier in the chapter.
The CMS processes on the CM and on managed WAEs synchronize on a schedule known as the Local Central Management (LCM) cycle. The LCM cycle triggers the synchronization of the CMS processes on a schedule that is configured within the CM GUI itself. A series of variables and their associated parameters dictate the rate of synchronization between the CM and managed WAEs:
Data Feed Poll Rate: Defines the rate at which configuration data is synchronized between the CM and managed WAEs. The configuration synchronization is bidirectional, meaning a configuration change applied on the CM will propagate to a managed WAE. Conversely, a configuration change applied on a managed WAE itself (for instance, via the CLI) will propagate back to the CM. The default value for this parameter is 300 seconds.
Health Monitor Collect Rate: Defines the rate at which the CM examines the health of each managed WAE. This includes service status, load conditions, and subsystem status. Alarms displayed in the CM GUI are based on information gathered during the collection of health monitoring information. The default value for this parameter is 120 seconds.
Monitoring Collect Rate: Defines the rate at which the CM gathers statistics about the optimization components from the WAEs it is managing. This includes information about optimized connections, compression ratios, byte count, traffic mix, and other acceleration data. Graphs displayed in the CM GUI that visualize how the system or an individual WAE is optimizing are based on data collected on this interval. The default value for this parameter is 60 seconds.
Note
The preceding variables are configurable within the CM GUI under System > Configuration. Along with these variables, this page allows you to configure other system-wide parameters, including CM GUI session timeout, device recovery key, data retention monitoring, and whether or not overlapping device groups are permitted. Additionally, this page allows you to globally enable or disable monitoring from the CM.
The default values provided by the CM for each of the preceding parameters allow the CM to scale to a level where it can manage the number of WAEs specified in Chapter 2. For smaller deployments, these timers can be decreased to allow for more frequent updating of configuration, health, and monitoring data. Changing these numbers is not recommended unless the number of devices being managed by a CM WAE is less than one-half the supported maximum for that device. Figure 7-3 shows the CM GUI page where the timers can be found.
The state of the CMS service can be verified from the CLI of the WAE. The show cms info command can be executed on a CM WAE or a managed WAE. This command shows the following:
Device registration information, including device mode and role. Role is displayed only if the WAE is configured as a CM.
CMS service information, including the state of the CMS service (shown as cms_cdm in the command output) and management GUI service (shown as cms_httpd in the command output).
Example 7-9 demonstrates the output of this command. In this example, the service is not running, as evidenced in the output of the first execution of sh cms info. The example then shows the service being enabled, and then the output of sh cms info with the services running correctly.
Example 7-9. Viewing CMS Registration and Service Status
CM1# sh cms info Device registration information : Device registered as = WAAS Central Manager Current WAAS Central Manager role = Primary CMS services information : Service cms_httpd is not running Service cms_cdm is not running CM1# conf t CM1(config)# cms enable Please preserve running configuration using 'copy running-config startup-config'. Otherwise management service will not be started on reload and node will be shown 'offline' in WAAS Central Manager UI. CM1(config)# exit CM1# copy running-config startup-config CM1# sh cms info Device registration information : Device registered as = WAAS Central Manager Current WAAS Central Manager role = Primary CMS services information : Service cms_httpd is running Service cms_cdm is running
Note
If the cms_cdm service is not running, the device cannot be managed centrally (if configured as an accelerator) or cannot manage WAEs (if configured as a CM). If the cms_httpd service is not running, the management GUI will not be accessible. In situations where the CMS service is disabled on a WAE, it will report as Offline in the CM GUI.
The previous sections provided details on establishing basic network connectivity to each WAE in the network, defining the CM, and enabling CMS services. During the process of enabling CMS services, a WAE device will “register” with the CM WAE. That is, the WAE will contact the CM and announce that it is interested in associating itself with the CM. In doing so, the WAE can then be managed by the CM, and report monitoring and statistical information back to the CM for visualization. Because the exchange of information between the CM and its managed WAE devices is encrypted, the first step of the process is for the WAE that is attempting to register to generate a self-signed certificate. This certificate, along with the CM WAE certificate, is used to encrypt information exchanged between the CM and the managed WAE.
When a WAE registers with the CM, the CM creates an entry in the CMS database for the registering WAE. This entry is linked to the WAE hostname to provide a simplified means of recovering device identity and configuration if a WAE needs to be replaced. If an entry with that name already exists, the registration of the new WAE fails. In such cases, the existing entry needs to be deleted from the CM GUI, or in the case of device replacement, the identity should be recovered onto the new WAE from the entry that exists in the CM database.
To recover a device identity from the CM database onto a new WAE that is replacing a failed WAE, use the cms recover identity command. This command takes an additional argument—the global device identity recovery password—which is set in the CM GUI on the same page as the system timers. For instance, if the global device identity recovery password is default, the command shown in Example 7-10 could be used to recover the identity from the CM.
Example 7-10. Recovering Device Identity
WAE1# cms recover identity default
Registering WAAS Application Engine...
Sending identity recovery request with key default
Registration complete.After executing the device identity recovery process shown in Example 7-10, the WAE device, in terms of its relationship with the CM, is left in a state of “inactive”. This is identical to the state that a newly configured WAE device is in after having executed cms enable to register with the CM, as shown in Example 7-7. While a WAE is in a state of inactive, either immediately after registration or after identity recovery, it is unable to establish a connection with the CM to synchronize configuration data, reporting information, or health and liveliness information. In this way, it is registered with the CM but not manageable. Taking a newly registered WAE and enabling it for active participation in the WAAS network through the CM is called device activation.
Device activation is a function performed on the CM that can take one or all inactive WAE devices and enable them for active participation within the Cisco WAAS network. Activation is a process that can be done only through the CM GUI and cannot be done through the device CLI. Activation takes a few simple clicks within the CM GUI, and then up to three iterations of the LCM cycle. Therefore, device activation can take up to three times the time interval configured for the CM system data feed poll rate, which is shown in Figure 7-3. Device activation can be performed from one of two locations:
On the Devices tab homepage, against any and all inactive devices that have registered with the CM
On the device homepage, for that particular device
When activating all devices from the CM GUI, also known as global activation, any devices in an inactive state are changed to active. The icon for this operation is found in the toolbar on the devices homepage at Devices > Device, and is also shown in Figure 7-4. Figure 7-4 also shows the device list homepage.
Although it is certainly possible to activate all inactive devices from the device list homepage, it is more common to activate devices as each is registered to the CM. The primary reason that you may want to activate WAE devices individually is that individual activation allows you to define the location group of each WAE (as opposed to putting them all in a single location group or creating a new location group for each). Location groups are not used as of this writing, but will play an integral part in WAAS network design in future releases. Figure 7-5 shows the activation link on the homepage of the inactive WAE device (left) and the activation window (right).
After a device has been activated, it goes through a state called Pending where the initial configuration is being propagated to the device and synchronization is being performed. As mentioned earlier, it generally takes three LCM iterations for the activation to finalize, and the WAE will remain in the Pending state until activation is complete. Once activation is completed, the WAE device will have generated keys and established a secure session to the CM, synchronized its configuration, and had its state changed to Online.
One of the most powerful usability features of the CM is the ability to logically group devices into single configuration containers. These containers, called device groups, allow you to rapidly apply a configuration change across multiple WAEs simultaneously. With device groups, the daunting tasks of implementing a seemingly simple configuration change across a large number of devices becomes a painless click of the mouse button.
The CM provides a configuration facility for you to create up to 256 device groups. The configuration page for device groups can be found in the CM GUI at Devices > Device Groups. Devices are added to device groups either during the creation of the device group or by going directly to the device homepage and assigning the WAE to a series of groups. Once a device group has one or more members, configuration changes applied to the device group in the CM GUI are automatically distributed to each of the WAEs that are members of the device group. This distribution of configuration changes happens behind the scenes and without user intervention, which can significantly streamline management. An example of assigning WAE devices to a device group, from the device group configuration page at Devices > Device Groups > (Device Group) > Assign Devices, is shown in Figure 7-6.
The CM provides a default device group, called AllDevicesGroup, which all Cisco WAE devices are automatically joined to upon creation within the CM database. Although the AllDevicesGroup device group is commonly used for smaller deployments, it is recommended that you take the small amount of time necessary to think through which device groups are relevant to your organization and minimize use of the AllDevicesGroup device group for anything other than configuration items that are absolutely necessary across the entire infrastructure and will not vary from device to device. Some functional uses of the device grouping capabilities of Cisco WAAS CM include the following:
Device group by time zone: Allows you to employ a common time, date, timezone, and NTP configuration for each device within the same timezone. Also, this allows you to isolate configuration changes to all devices within a specific timezone when necessary.
Device group by location type: Allows you to group devices by classification of the type of location they are deployed in. For instance, you may choose to create a group for all devices that are deployed in data center locations, or create a device group for all devices deployed as router modules. This allows you to apply common configuration settings across all devices in similar location types.
Device group by WAN link capacity: Allows you to group devices by the WAN link type that the device supports. For instance, you may define a “T1” device group, or an “LFN” device group for WAEs that are supporting high-BDP networks. This enables you to apply a common configuration across all devices that are supporting similar link speeds, distances, or other similar characteristics.
Device group by services configured: Allows you to group devices by the types of services configured. For instance, you may have specific devices that perform TCP optimization only, whereas some devices perform full optimization. Alternatively, you may bundle a series of neighboring CIFS core devices together to act as a CIFS core cluster (this is examined in more detail in Chapter 9).
As outlined in the preceding list, there are countless uses for device groups. Device groups can be created to serve just about any configuration purpose. Keep in mind that a device group allows an administrator to configure nearly anything that can be configured directly against an individual WAE, thereby enabling the administrator to “scale themselves”, that is, minimize their administrative burden. Also note that changes made to a device group are synchronized with managed WAE devices within that device group on the same schedule that configuration changes applied directly to a managed WAE are made—the LCM cycle. If a WAE is a member of two or more device groups such that configuration conflicts exist, the configuration contained in the last modified device group is applied. Therefore, try to define your device groups and assign devices in such a way that there is very little, if any, overlap.
The CM is also designed to allow multiple discontiguous departments within the same organization to have provisioned management authority. In many environments, it is necessary to allow different teams with different responsibilities—potentially even in different parts of the company—to have some level of administrative privilege over a portion of the infrastructure. Furthermore, many organizations prefer to leverage a centralized, unified platform for authenticating and authorizing users that attempt to access enterprise infrastructure resources. The CM integrates cleanly into environments that have requirements such as these by providing:
Role-based access control (RBAC): Allows for the definition of users, roles, and domains to segregate management responsibility and user privilege across devices in the Cisco WAAS network
Integration with authentication providers: Allows for delegation of authentication functions for users accessing a WAE or the CM to a trusted third party such as TACACS, RADIUS, or Microsoft Active Directory
By providing these two capabilities, the Cisco WAAS CM allows IT organizations with disparate management teams and centralized authentication providers to streamline integration of Cisco WAAS management into their existing IT fabric. The following sections examine each of these systems in detail, along with their configuration.
RBAC is a feature within the Cisco WAAS CM that provides a flexible means of creating management and administrative domains. With RBAC, the network team can have the appropriate permissions within the CM to adjust the networking parameters on all or specific devices (or groups of devices) within the Cisco WAAS network, while the desktop team is provided access to only configuring CIFS acceleration services or print services.
RBAC is built upon three fundamental components:
User: The entity that is attempting to authenticate with the CM
Role: A template that identifies which pages and functions within the CM that an associated user is able to access
Domain: A template that identifies either a specific set of devices or a specific set of device groups that an associated user is able to access
With the combination of users, roles, and domains, the system-wide administrator for WAAS can, in a very granular fashion, allocate a specific set of configuration pages to all users associated with a particular role. The administrator can then filter the area within the WAAS network from which those configuration pages can be used by applying a domain. In this way, a user, once authenticated, is associated with one or more roles, which determine the pages within the CM the user is allowed to access and functions that the user is able to perform. The user is then associated with a domain, which identifies which devices or device groups a user is able to perform those functions against.
Note
Domains can be defined only as a series of unique devices or as a series of device groups. You cannot configure a single domain that contains a list of unique devices along with a list of specific device groups. In such cases, two domains would be necessary.
Users can be assigned to multiple roles and also to multiple domains. Permissions provided to a user in the CM are additive; that is, the sum of all permissions provided to the user by all associated roles is the net effective set of operations the user is allowed to perform. Similarly with domains, the sum of all devices and device groups listed in all domains assigned to the user is the net effective domain of control the user is allowed to impact.
Figure 7-7 shows the configuration page for roles and domains. Note that these pages can be accessed in the CM GUI by going to System > AAA > Roles and System > AAA > Domains.
Consider the following example. Zach is a Cisco WAAS administrator and hires Joel to manage his U.S. Cisco WAAS network. Zach also hires Baruch to manage his Cisco WAAS network in Israel. Zach does not want Joel to be able to apply any configuration changes to Baruch’s devices in Israel, and he does not want Baruch to be able to change any of Joel’s devices in the United States. Zach also has a location in Switzerland where there are two WAEs deployed. Rather than hire an administrator in Switzerland, Zach decides to assign one WAE each to Joel and Baruch, thus dividing management responsibilities for Switzerland between the two.
Using a combination of device groups, users, roles, and domains, Zach’s job provisioning Cisco WAAS management is simplified. A single device group for all WAEs in the United States is created, and all WAEs in the United States are assigned to this device group. Similarly, a device group is created for all WAEs in Israel. Joel and Baruch are each assigned to two domains: Joel to a U.S. domain, which calls out the device group for the WAEs in the United States, and another domain that identifies one of the WAEs in Switzerland. Baruch is assigned to the domain that represents the Israel WAEs, and another domain that identifies the other WAE in Switzerland.
Figure 7-8 shows the configuration page for assigning roles and domains to a particular user. Note that this page can be accessed in the CM GUI by going to System > AAA > Users.
As evidenced in this section, the available permissions and devices against which a user is able to employ change is the sum of the available permissions provided by the assigned roles and domains. Configuration of users, roles, and domains can all be found under System > AAA.
Authentication for users attempting to access the CM is, by default, performed against a local database stored in the CM WAE itself. Users that are created in the CM are automatically synchronized to each of the WAEs that are managed by that CM. In some deployments, it may be desirable to allow the CM to leverage a third-party centralized authentication provider, such as TACACS, RADIUS, or Active Directory, to manage user accounts and passwords. Cisco WAAS can leverage these third-party providers to authenticate users, which allows you to avoid having to manage user credentials on yet another system deployed within the infrastructure.
While integration with third-party authentication providers does not require that the users be explicitly defined within the CM or within each device, it is recommended that the users be defined. By defining the users (even without supplying the credentials), you can specify either:
Role assignment within the CM, which dictates the permissions provided to the user upon successful login. Although users can authenticate with the third-party systems, authorization (that is, permission) is still determined by the CM. Thus, roles and domains should be configured, and users should be assigned to roles and domains to specify privilege.
Privilege level within the device CLI, which dictates the commands that can be executed by the user upon successful login.
In short, a user can log into the system if it is configured for third-party authentication, and will be assigned the default role or permissions upon successful authentication. It is recommended as a best practice that you undertake the following steps to ensure successful integration and security:
When using third-party authentication, create a series of new roles based on the permissions that authenticated users should have per user type.
Define all administrative users and assign them to the appropriate groups.
Minimize the permissions available in the default roles such that any undefined user will have little or no privileges on the system.
Specify secondary and tertiary servers as needed, with a failover to the local user database. This ensures availability of management access if third-party authentication providers all are unavailable.
Example 7-11 shows how to configure primary and secondary authentication servers as needed, with failover to the local user database. Note that the CLI also allows for the definition of tertiary and quaternary servers as well. Be sure to use the authentication fail-over server-unreachable command shown below to only allow login authentication to fail over to the next service in the configuration should the current login server service be unavailable or unreachable. It is best practice to have local authentication at the end of the list as an authentication provider of last resort.
Example 7-11. Configuring Primary and Secondary Servers, and Authentication Failover
WAE# config WAE(config)# authentication login tacacs enable primary WAE(config)# authentication configuration tacacs enable primary WAE(config)# authentication login local enable secondary WAE(config)# authentication configuration local enable secondary WAE(config)# authentication fail-over server-unreachable
Note
authentication login commands determine what authentication provider to consult to see if the user has permission to log into the WAE. authentication configuration commands determine what authentication provider to consult to see what configuration access privileges the user has on the WAE should he or she authenticate successfully.
Figure 7-9 shows the configuration page for defining an authentication provider. Note that this page can be accessed in the CM GUI by going to Devices > (Devices or device groups) > (device or device group homepage) > General Settings > Authentication. In this example, the WAE will use a Windows Domain for authentication.
Note
When using Windows Domains as third-party authentication providers, it is necessary to join the WAE to the domain. This can be accomplished on the Windows Domain page shown in Figure 7-9. A test tool is supplied on this page to notify you of any issues preventing you from joining the WAE into the domain. Joining the domain requires that the following hold true:
The domain name must be correctly configured on the WAE, or on a device group that the WAE is a member of.
The WAE can resolve, using either DNS or explicit configuration, and identify the IP address of a domain controller.
The WAE has the appropriate authentication protocol enabled (either NTLM or Kerberos) based on the domain type. NTLM should be used only for legacy Windows NT domains, and Kerberos should be used for Windows 2000 and newer domains (mixed mode or native mode).
System time must be synchronized to the Windows Domain using NTP or static time configuration. The time variance must be less than 5 minutes, and this variance must also account for the date on the system.
Cisco WAAS also provides support for AAA accounting using TACACS, and also honors privilege levels 0 and 15 as supplied by TACACS.
The past sections have focused primarily on initial configuration, system management, and integration. This section, in contrast, focuses on the device-specific configuration and management capabilities of the CM, particularly from a device perspective and not from an optimization or service perspective. Chapters 8 and 9 include an examination of using CM to configure and monitor optimization services. Thus, this chapter focuses on configuration and reporting aspects that are not related to the optimization capabilities of Cisco WAAS. This section examines the device homepage, device reports, configurable items, status and health monitoring, and software upgrade and rollback.
The CM provides you with a tabular list of all the registered WAEs. This tabular list is found on the Devices tab, as shown in Figure 7-10. The device list table provides the following columns, which are helpful in understanding what devices are registered and their status within the system:
Device Name: The name provided using the hostname command on the device CLI.
Services: The services that are running on the system beyond basic Layer 4 optimization services. This includes CIFS acceleration services (either Edge, Core, or both), local services, and CM services (either primary or secondary).
IP Address: The IP address on the device.
CMS Status: The status of the CMS services on the device, which can also be representative of status of connectivity from the device to the CM itself. Status will always be one of the following:
Online: The device is online, healthy, and exchanging information with the CM on the configured schedule.
Offline: The device is either offline or the network connectivity between the device and the CM has been severed for two or more successive LCM cycles.
Inactive: The device has registered with the CM but the administrator has yet to activate the device.
Pending: The device has registered with the CM and the administrator has activated the device, but the CM and the device have not yet finished synchronizing configuration data with one another.
Device Status: The status of the device and its services, visualized in a colorful tree display. The colors displayed include:
Green: The device is healthy and all configured services are operational.
Yellow: A warning is present; for instance, a load threshold has been exceeded or an interface is operating in half duplex.
Amber: An error is present; for instance, an inline group has gone into bypass, a service is down, or a device requires a reboot.
Red: The device is offline or unavailable and requires attention.
Location: The location that the device is associated with.
Software Version: The version of software that is installed on the device. If a software upgrade is in place, this column also displays details about the software installation.
You can select a specific device from the tabular device view by clicking the edit icon shown on the left of each device name in the table. Clicking this icon takes you to the device homepage. Figure 7-11 shows an example of the device homepage.
The device homepage provides an immediate status and configuration summary of the device, and a configurable dashboard of reports. The Contents pane on the left side lists the areas in which you can configure the device from the GUI; each configuration change is automatically propagated to the WAE during the LCM cycle:
Activation: Control the activation status of the device, which is useful when first activating a device, or when deactivating a device and making it recoverable during a device recovery scenario
File Services: Configure the CIFS acceleration components of the system, including edge and core services
Acceleration: Configure WAN optimization policies, including enabled features, buffer settings, and classifiers
Print Services: Configure local print services, which allows the WAE to act as a print server in the remote office
General Settings: Configure basic network configuration and integration parameters
Interception: Configure network interception, including WCCPv2 and inline interception
Monitoring: Gather reports from the device for optimization and acceleration services
Assign Groups: Manipulate the group membership of the WAE device
In the middle of the page, the Device Info pane provides a snapshot of the device configuration, including status, alarms, number of device groups, hardware model, memory, software version, network configuration, and disk configuration.
The right side of the screen presents up to four reports as determined by the dashboard configuration. These reports, which primarily deal with WAN optimization and application acceleration services as opposed to device services, can be configured using the “configure dashboard” icon in the toolbar to the right of the text that says “Device Home for xyz”. The dashboard configuration, which is shown in Figure 7-12, allows you to select up to four reports to visualize on the device homepage. These reports are discussed in detail in Chapters 8 and 9.
Of particular interest on the device homepage, which is also present in the tabular device view and system status view, is the “tree of lights,” which is a series of four “bulbs”. One or more bulbs are “lit” to reflect the status of the system as an entity (for instance, the bulb for one WAE may be red and the bulb for another may be orange). In the case of a device-specific tree of lights, a single bulb is lit. The tree of lights is displayed not only on the device homepage, which specifies the condition of that particular device, but another tree of lights that represents the system as a whole is presented in the toolbar of every GUI page. Figure 7-13 calls out the locations of the device-specific status indicator and the system-wide status indicator.
By clicking this status indicator (whether from the system homepage or the device homepage), you are presented with a tabular view of all the alarms and notifications that caused the indicator to be lit. These alarms and notifications could include a variety of situations, such as duplex mismatch, service overload, service failed, reboot required, and so on. When you click the system status indicator, you see an aggregate list of all alarms causing the status indicator color to change—from any device in the system—on a page called Troubleshooting Devices (see Figure 7-14, which shows an example of the window with alarms on two devices). When you click the device status indicator, you see only the list of alarms causing the status indicator color to change relative to that particular device.
The tabular list view on the Troubleshooting Devices page includes all the relevant information needed to appropriately respond to the alarm condition:
Device Name: The name of the device experiencing the alarm condition
IP Address: The IP address of the device experiencing the alarm condition
Status: The status of the device experiencing the alarm condition
Severity: The severity of the alarm represented on that particular row within the tabular list view
Alarm Information: The severity and description of the alarm that caused the status indicator to change
By clicking the alarm information, you are presented with a series of options for resolving the issue:
Edit/Monitor Device: Click to go to the device homepage to examine configuration details and relevant log or statistical data
Telnet to Device: Click to open a Telnet window to allow CLI access to the device in question
View Device Log: Click to examine the log entries that have been generated by the device that has experienced an alarm condition
Run Show Commands: Click to execute CLI commands from the GUI in an effort to troubleshoot or resolve the alarm condition
The homepage for the CM, which is presented to the user immediately after login or by clicking the Home link in the upper-right corner, also presents an alarm window. The primary difference between the alarm window on the CM homepage and on the Troubleshooting Devices page is that the alarm window on the CM homepage allows you to filter alarm names and even acknowledge alarms without actually resolving the condition that caused the alarm to be triggered. For instance, if a condition continues to surface, and the appropriate support team has plans to resolve the alarm, you can “acknowledge” the alarm. Acknowledging an alarm does not resolve the issue, but rather keeps the alarm from continuing to display in the alarm list, and from continuing to cause the system status bar to light up.
Figure 7-15 shows the alarm window on the CM homepage, along with the acknowledged alarms.
The Acknowledged Alarms tab provides you with a means of “unacknowledging” alarms as well. That is, if an alarm is accidentally acknowledged, and you want the alarm to continue to be displayed in the alarm list and impact the system status indicator, you can select and unacknowledge that alarm. This returns the alarm to the alarm list.
The CM provides facilities that enable you to upgrade or downgrade the software version installed on a WAE within the WAAS network seamlessly. From within the CM itself, you can define a software image and all related parameters. This entry, called a software file entry, is nothing more than a link to the actual binary file used to install the software onto the WAE. When a software file entry is applied to a WAE, the details of the entry are sent to that WAE, which causes it to initiate a connection to the download location to begin downloading. If the WAE is successful in its connection attempt, it downloads the file referenced in the link provided to it by the CM. If the download succeeds, the WAE attempts to install the software, and then reboots if the Reboot flag was specified in the software file entry.
The configuration page for defining a software file entry can be found in the CM GUI at System > Software Files, and is shown in Figure 7-16. The parameters associated with a software file entry include:
Software File URL: Includes HTTP and FTP.
URL path: Path and filename for the software image file.
Username: The username that should be supplied by the system (if prompted) to authenticate in order to download the software file.
Password: The password that should be supplied by the system (if prompted) to authenticate in order to download the software file.
Software Version: The version of the software that the file contains, in the format X.Y.Z.b.B, where X is the major version, Y is the minor version, Z is the maintenance version, b is literally the character b, and B is the build number.
File Size: Allows you to specify the size of the file. The value supplied in this field is checked for accuracy if the repository permits it.
Auto Reload: Checking this check box causes the WAE to automatically reboot if it successfully downloads the software file.
Along with these configuration parameters, the CM GUI provides a Validate Software File Settings button that allows you to validate the configuration. When you use this tool, the CM itself connects to the repository, attempts to authenticate using the supplied credentials, and validates the presence of the file in the path supplied by you.
Any time a software upgrade or downgrade is applied to a WAE, that WAE must be rebooted for the new version to take effect. It is important to note that when applying a software image to a CM WAE, if the software image contains an earlier version than the previously installed image, it may be necessary to downgrade the CMS database to support the schema used by the newly installed version.
Example 7-12 shows the output of show cms info and cms database downgrade, which are used, respectively, to verify that a database downgrade is required and to perform a downgrade of the database. Be sure to disable CMS services prior to the downgrade, and enable CMS services after the downgrade.
Example 7-12. Downgrading the CMS Database
CM1# sh cms info DOWNGRADE REQUIRED ------------------ A database downgrade is required to enable CMS services. Please use the 'cms database downgrade' command to perform the database downgrade. Device registration information : Device Id = 142 Device registered as = WAAS Central Manager Current WAAS Central Manager role = Primary CMS services information : Service cms_httpd is not running Service cms_cdm is not running CM1# cms database downgrade The system will perform a database downgrade without applying a downgrade script. Please refer to product documentation to confirm that the previously-installed software release does not require a downgrade script for this release. Proceed with database downgrade [no]? yes Creating database backup file cms-db-01-05-2007-03-32.dump Database downgrade succeeded. CM1# sh cms info Device registration information : Device Id = 142 Device registered as = WAAS Central Manager Current WAAS Central Manager role = Primary CMS services information : Service cms_httpd is not running Service cms_cdm is not running CM1# config term CM1(config)# cms enable
When upgrading a CM to a newer software version, the software installation automatically adjusts the schema of the CMS database if necessary during the reboot. All of the information necessary about prior version database schemas is retained in the CM; thus, when performing an upgrade, the system can automatically identify what version was installed prior and make the appropriate changes to the database to support the new version’s schema. However, older versions have no way of knowing what schema a future version will use. As such, a database downgrade may be necessary if downgrading software versions on the CM itself.
An issue related to software upgrade is the recommended order of upgrade. The CM is capable of managing any device that has an equal or newer version of software installed upon it. That is, the CM makes the assumption that any item configurable on the CM GUI can be successfully applied on any WAE managed by that CM. Thus, if the CM is of a newer version than the WAEs that it is managing, it may attempt to configure a feature that the currently installed WAE software is not able to implement or even recognize. Thus, it is required that the CM be the last device in the Cisco WAAS topology to receive a software upgrade.
Software upgrades can be applied directly to a device or to an entire device group. Software upgrades can be done from one of three places:
Device homepage: Click the Update Software button in the Device Info pane (refer to Figure 7-11 earlier in the chapter)
Device group homepage: Click the Software Update link in the Contents menu, as shown in Figure 7-17
Device CLI: Use the copy command as shown in Example 7-13
Figure 7-17 shows the Software Update link on the Device Group homepage. Notice that you can choose a particular software file, and that a hyperlink is provided to modify the software file definitions if necessary.
It is important to reiterate that if the Auto Reload check box is not checked during the definition of the software image (see Figure 7-16), the WAE must be rebooted in order to apply the new software version. Also, the CM GUI homepage provides details on what software versions are installed within the WAAS network and on how many WAE devices. This provides you with a quick glimpse of any software version conflicts that may be present.
Software upgrade can also be performed manually from the CLI of a WAE by using the cop command. Example 7-13 shows the use of the copy command to install a software version from an FTP server.
Cisco WAAS supports internal and external reporting and logging mechanisms. As mentioned earlier in the chapter, alarms that are generated on a particular WAE will cause a light to be lit in the CM system status or device status tree of lights. The CM also provides robust audit logging for any configuration changes that were made while a user was logged into the CM. These audit trails are enabled automatically and require no additional user configuration. An example audit trail is shown in Figure 7-18.
The internal audit trail logs can be found at System > Logs > Audit Trail Logs. The logs contain the following information:
When: When the action was taken
Who: Which user performed an action on the system
What: What action the user performed on the system
Where: What IP address the action came from
Similarly, system messages, which include alarm data, can be viewed from the CM UI at System > Logs > System Messages. The system message repository contains all of the system messages that have been sent to the CM from the managed WAEs and generated locally on the CM itself. Figure 7-19 shows an example of the CM system messages table.
Whereas the audit trail shows what function was performed by a particular user, the system messages table contains information about alarms and events that have been generated on the CM or managed nodes. The system messages table also includes a Severity column to identify how critical the message is and an icon that allows you to export the table for offline viewing and analysis.
The CM, as well as any WAE device, also supports definition of up to four syslog servers and SNMP configuration. Syslog is configured from the device or device group homepage under General Settings > Notification and Tracking > System Logs. From the CLI, syslog servers are defined using the global configuration command shown in Example 7-14.
Example 7-14. Defining Syslog Servers in the CLI
WAE# config term WAE(config)# logging host 10.10.10.100
Note
Similar to when using the GUI, from the CLI you can configure additional syslog parameters such as port, default priority level, and a rate limit on the number of messages that can be sent per second. These items are all configured under the logging host global configuration mode command.
Messages sent to external syslog servers are sourced from the local syslog.txt file found on the WAE in the /local/local1 directory.
Similarly, SNMP can be configured from within the device or device group homepage under General Settings > Notification and Tracking > SNMP. A number of subitems exist under SNMP, each of which provides a separate configuration area. SNMP settings can be configured from the device CLI using the global configuration mode command snmp-server.
Cisco WAAS provides support for the MIBs listed and described in Table 7-1.
Table 7-1. SNMP MIBs Supported by Cisco WAAS
MIB | Description |
|---|---|
MIB-II | Published in RFC-1213, also known as the “Internet Standard MIB,” and is used for network management protocols in IP networks |
HOST-RESOURCES-MIB | Published in RFC-1514, provides information about hardware resources in the WAE device |
EVENT-MIB | Published in RFC-2981, defines event triggers and actions for network management purposes |
ACTONA-ACTASTOR-MIB | Provides CIFS acceleration statistics, print services statistics, and service liveliness and statistics information |
CISCO-CDP-MIB | Provides interface information and CDP-related information |
CISCO-CONTENT-ENGINE-MIB | Provides platform-level statistics for the Cisco WAE hardware platform, which are shared with the legacy Cisco Content Engine |
CISCO-CONFIG-MAN-MIB | Provides configuration manager data, including information on data existing in memory (running configuration), hardware, local (NVRAM or flash memory), and remote network locations |
CISCO-ENTITY-ASSET-MIB | Provides data about installed items with orderable part numbers that comprise the system; includes information about part number, serial number, hardware revision, and more |
The previous sections in this chapter have provided details on connecting WAE devices to the network, registering them with the CM, and organizing them into device groups. The previous sections have also examined other integration aspects, including provisioned management, reporting, and logging.
Although some level of availability can be provided by deploying a primary and a standby CM, it is best practice to keep up-to-date backups of the CM database on hand in case of a system-wide outage or other disaster scenario.
The CMS database can be backed up and restored in a manner similar to performing a configuration file backup or restore on any other Cisco device. The only caveats associated with these procedures are the following:
A CMS database restore must be performed on a WAE running the same version of the WAAS software that the backup was taken from.
Prior to restoring a CMS database, the CMS service must first be disabled.
When creating a backup of the CMS database, the WAAS software automatically drops the backup file into the directory /local/local1 filesystem. The way in which you navigate a filesystem on a WAE device is identical to how you navigate a Linux server.
Example 7-15 shows how to make a backup of the CMS database, and then copy the backup to an FTP server.
Example 7-15. Backup of the CMS Database
waas-cm# cms database backup Creating database backup file cms-db-09-13-2007-05-07.dump Backup file local1/cms-db-09-13-2007-05-07.dump is ready. Please use `copy' commands to move the backup file to a remote host. waas-cm# pwd /local waas-cm# cd /local/local1 waas-cm# ls cms-db-09-13-2007-05-07.dump waas-cm# copy disk ftp 10.10.10.100 / cms-db-09-13-2007-05-07.dump Enter username for remote ftp server: administrator Enter password for remote ftp server: Initiating FTP upload... Sending: USER administrator Microsoft FTP Service Password required for administrator. Sending: PASS *********** User administrator logged in. Sending: TYPE I Type set to I. Sending: PASV Entering Passive Mode (10,10,10,100,128,149). Sending: CWD / CWD command successful. Sending PASV Entering Passive Mode (10,10,10,100,128,150). Sending: STOR cms-db-09-13-2007-05-07.dump Data connection already open; Transfer starting. Transfer complete. Sent 146747 bytes
The process of restoring a CMS database is similar to the process of backing up the CMS database. To restore the CMS database, you must first copy the CMS database files to the local filesystem. Then, you must disable CMS services. You should then issue the cms database restore command and, upon successful restore, re-enable CMS services.
Example 7-16 shows how to perform a CMS database restore.
Example 7-16. Restore of the CMS Database
waas-cm# copy ftp disk 10.10.10.100 / cms-db-09-13-2007-05-07.dump /local/local1/ cms-db-09-13-2007-05-07.dump Enter username for remote ftp server: administrator Enter password for remote ftp server: Initiating FTP upload... Sending: USER administrator Microsoft FTP Service Password required for administrator. Sending: PASS *********** User administrator logged in. Sending: TYPE I Type set to I. Sending: PASV Entering Passive Mode (10,10,10,100,128,149). Sending: CWD / CWD command successful. Sending PASV Entering Passive Mode (10,10,10,100,128,150). Receiving: STOR cms-db-09-13-2007-05-07.dump Data connection already open; Transfer starting. Transfer complete. Received 146747 bytes waas-cm# pwd /local waas-cm# cd /local/local1 waas-cm# ls cms-db-09-13-2007-05-07.dump waas-cm# config term waas-cm(config)# no cms enable waas-cm(config)# exit waas-cm# cms database restore /local/local1/cms-db-09-13-2007-05-07.dump
This chapter provided a detailed examination of how to move from unconfigured WAE devices to registered, grouped, and upgraded devices that are integrated into the enterprise framework. An intuitive and easy-to-use setup script is provided that walks you through basic network configuration. From there, you can register and activate devices within the CM, which provides a scalable, secure, and simple means of centralized system administration and monitoring. The CM and the managed WAEs remain in constant communication through the CMS service and the frequent synchronization of configuration, monitoring, and reporting data based on the configured LCM cycle. The CM provides powerful and flexible capabilities for centralized system management, including device groups, which help automate the distribution of configuration to its managed devices. The CM also provides facilities for centralized software upgrade and rollback using a scalable architecture that allows the managed nodes to directly download software images, thereby eliminating the CM as a bottleneck in the download and upgrade.
The CM provides intuitive alarm visualization mechanisms that alert you when a threshold has been exceeded. You can act upon an alarm or, if you do not want to be notified of that particular alarm again in the future, acknowledge the alarm. The CM and each of the managed WAEs can be integrated into existing monitoring architectures that leverage syslog and SNMP. Protection of the CM database is simple and straightforward, similar to protecting the running-configuration and startup-configuration files on a router.
With the power to configure nearly every aspect of a WAE and in a scalable manner, most enterprise organizations will find that their day-to-day administration, management, and monitoring tasks will be performed through the CM’s easy-to-use interface. Having a scalable, secure, and simple architecture for centralized management of a large fabric of distributed nodes is essential for controlling operational costs associated with IT systems, which is exactly what the CM affords organizations that have deployed Cisco WAAS.