This lab covers how to set up a home WAAS lab and notes from the recent WAAS training I received.
The lab uses ESXi as hypervisor, CSR1000v as router with AppNav-XE interception service enabled, vWAAS 200 as WAN accelerator and vCM 100N as WANx management tool. ESXi vswitch is also used with multiple VLANs to simulate switching connection.
- ESXi (WAAS OVA and Central Manager OVA don’t support virtualbox, vmware workstation etc.)
- Cisco-WAAS_vWAAS-200.ova (Virtual WAAS, download from: https://software.cisco.com/download/release.html?mdfid=280484571&catid=268437639&softwareid=280836712&release=5.3.5f&relind=AVAILABLE&rellifecycle=&reltype=latest)
- ISR-WAAS-5.3.5f.7.ova (ISR WAAS, download from: https://software.cisco.com/download/release.html?mdfid=280484571&catid=268437639&softwareid=280836712&release=5.3.5f&relind=AVAILABLE&rellifecycle=&reltype=latest)
- Cisco-VCM-100N-6.1.1-b-26.ova (Virtual Central Manager, request from Cisco PDI helpdesk: https://supportforums.cisco.com/discussion/12301901/how-download-cisco-wass-vcm-virtual-central-manager)
- csr1000v-universalk9.03.16.01a.S.155-3.S1a-ext.iso (CSR1000v router, download from: https://software.cisco.com/download/release.html?mdfid=284364978&softwareid=282046477&release=3.16.1aS&relind=AVAILABLE&rellifecycle=ED&reltype=latest
Topology is as below:
Setup AppNav and WAAS
Step 1: Install vWAAS, vCM and CSR1000v on ESXi
Step 2: Configure ESXi server network and VM vNICs
Step 3: Configure vCM by using “setup” wizard
- Execute command ‘setup’ from CLI.
- WAAS default credential is “admin/default”. Configuration reference:
- vWAAS interface is virtual interface. Therefore, use “show interface virtual 1/0” and “show interface virtual 2/0” to verify interface status.
- WAAS hardware appliance mode can be changed between accelerator and central manager. However, mode change is not allowed on virtual appliance. Therefore, we need to download vWAAS OVA for accelerator and vCM OVA for central manager. Mode change will cause WAAS hardware appliance to reboot.
- Execute “cms enable” to enable GUI access
- Use “https://x.x.x.x:8443” to access Central Manager.
- Standby CM can be configured: http://www.cisco.com/c/en/us/td/docs/app_ntwk_services/waas/waas/v413/configuration/guide/cnfg/maint.html#wp1162642
Step 4: Configure WAAS accelerator using “setup” wizard
- During the wizard it will ask for CM IP, make sure WAAS accelerator can ping CM IP.
- Execute “show cms info” on the WAAS accelerator to confirm CM registration information. CM should also show registration status. If CM cannot see WAAS accelerator, re-register WAAS accelerator to CM by issuing “cms deregister force” and then “cms enable”.
- WAAS registration can be verified on CM under “Devices” tab as below:
Step 5: Register CSR1000v router to CM
- Enable HTTPS (“ip http secure-server”)
- Make sure CM and routers have same time (i.e.NTP)
- Register router via Home –>Admin –>Registration –>Cisco IOS Routers
- If AppNav-XE (interception) service is required on the router, the router credential is also to be entered for “AppNav-XE Credentials” under Device –>select the router –> Admin –> AppNav-XE Credentials. Not doing so, the router will show “registered” in “Cisco IOS Routers” registration window, but “offline” under “Devices” tab.
Step 6: Configure AppNav cluster from CM or CLI
- AppNav cluster can be configured from wizard under “AppNav Clusters” tab.
- AppNav cluster can also be configured from CLI on the hosting router. I developed the following ER diagram to demonstrate the configuration logic of AppNav cluster. AppNav cluster is also called service context with identifier as waas / [1-32]. The service context/AppNav cluster ID is locally significant. AppNav controller group, service node group (i.e. WAAS group), AppNav service policy and VRF are required to define the AppNav cluster. AppNav service policy will match traffic based on pre-defined optimisation class-maps, and distribute traffic to WAAS node group.
- Some rules are as below and demonstrated on the ER diagram:
– Each AppNav cluster has one and only one AppNav controller group
– Each AppNav cluster can have one or multiple WANx groups
– Each AppNav cluster has one and only one AppNav policy applied
– Each AppNav cluster has one and only one VRF associated
– Each AppNav controller group can have one or multiple AppNav controllers as member
– Each WANx group can have one or multiple WAAS nodes as member
- WAAS optimisation class-map and policy are configured on WAAS.
Enable AD Authentication to Access CM GUI and CLI
Step 1: Join CM to Windows domain
The domain join requires AD, NTP and DNS setup as pre-requisites. Configuration can be done via GUI or CLI. However, it turned out to be a pain to configure via GUI due to its weird refresh mechanism and insufficient feedback information.
GUI: Device –> the CM device–> Configure –> AAA –> Windows Domain Settings
(If it doesn’t show the correct status; then go to “Device –> the CM device –> Configure –> AAA –> Authentication Methods –> refresh authentication status)
CLI: WAE# windows-domain join domain-name DomainName user UserName
(“show windows-domain” to check status)
Step 2: Relate AD user group to CM authorisation
GUI: Device –> the CM device –> Configure –> AAA –> Windows User Authentication Settings
Step 3: Configure authentication method and failover sequence
GUI: Device –> the CM device –> Configure –> AAA –> Authentication Methods –> Refresh authentication status
If the authentication sequence is configured as 1st AD and 2nd local, the local authentication will not work till AD DS inactivated (tested by deactivate AD DS). After AD DS is resumed, better to “refresh authentication status” to resume AD authentication on CM.
The authentication sequence was configured as 1st local and 2nd AD to allow local authentication to work while AD DS was activated.
User name must be unique, which means local username and AD username cannot have duplication.
Step 4: Assign CM role to user group for CM GUI authorisation
If this step is not done, there will be no problem for user to be authenticated and authorised to CLI; however, user can be authenticated to CM GUI but without authorisation to view any information.
GUI: Home –> Admin –> AAA –> User Groups (directly type in AD group name such as “waas_admin” and “waas_user”) and assign CM role to the user group.
- WAAS vs. Akamai: WAAS alone supports TCP flow optimisation (TFO), data redundancy elimination (DRE) and persistent Lempel-Ziv (LZ) compression. Akamai adds the content object caching capability.
- AppNav controller is configured on ASR/ISR/CSR1kv router and used to re-direct (like WCCP) to WAAS nodes. It is easier than WCCP without the risk of WCCP loop; L2 is recommended for WCCP but L3 works well with AppNav; AppNav is more aware what happens on WAAS nodes than WCCP does.
- Similar to WCCP, AppNav also create GRE tunnel between AppNav and WAAS nodes.
- It is recommended to use device group on CM to standardise policies.
- If CM fails, it will not affect AppNav and WAAS optimisation, not affect Akamai either.
- WAAS appliance will reload after mode change
- CM will not automatically update managed device configuration. Force change to device is to be clicked upon configuration change.
- vWAAS can be installed on ESXi, HyperV and KVM hypervisors. If use KVM then need to install some drives such as Brocade NIC drive. Cisco custom ESXi can be downloaded from VMWare.
- Use thick provision for WAAS OVA
- WAAS supports pre-position/pre-population, disk encryption
- One device will only be the member of 2 device groups on CM
- Reports can be scheduled on CM: Home –> Monitor –> Reports –> Report Central and can be integrated with Prime Infrastructure.
- CM email is not integrated with Exchange at the moment, need to use SMTP server
- If WAAS is not registered appropriately force reregistration by issuing command “cms deregister force” and then “cms enable”
- WAAS node pull rules from Akamai not Akamai push. If CM fails, WAAS node can still talk to Akamai. CM is used for Akamai initial license registration and assigns Akamai point of presence a unique ID.
- Akamai and WAAS nodes must have DNS and NTP setup.
- Akamai transparent policy allows bypass Akamai and hand over to WAAS directly if Akamai fails. If “advanced” transparent caching policy is used, test internal before production and external websites
- Activate Akamai takes very long time such as 1 hour to populate rules to WAAS nodes.
- License upload can only be done via GUI, the rest can be done via GUI or CLI.
- WAAS is not VRF aware at the moment and AppNav is, with VRF defined under AppNav cluster service context.
- ISR WAAS is actually OVA installed on built-in KVM hypervisor. vWAAS container version is on the roadmap for UCS-C only?
- For non-IOS XE devices, traditional WCCP can be used to redirect traffic to WAAS nodes. WCCP session initially negotiated from WAE. Layer 2 re-direction is recommended for WCCP, less CPU usage and avoid asymmetric routing and loop risk. 2 GRE tunnels (Service 61 and 62) will be created between the router with WCCP and WAAS node. N7K cannot do Layer 3 re-direction, not support. “show ip wccp summary” on router and “show wccp routers” on WAAS provides WCCP verification.
- AppNav cannot fail to wire automatically; therefore, not recommended to be inline.
- Branch model WAAS can be configured as accelerator or central manager mode.
- WAAS upgrade pack is universal to vWAAS, ISR WAAS and appliance. ISR WAAS has its own initial OVA.
WAAS troubleshooting guide: http://docwiki.cisco.com/wiki/Cisco_WAAS_Troubleshooting_Guide_for_Release_4.1.3_and_Later
AppNav configuration guide: http://www.cisco.com/c/en/us/td/docs/app_ntwk_services/waas/waas/v501/configuration/guide/cnfg/servicescontroller.pdf
IWAN Application Optimisation Using Cisco WAAS and Akamai Connect (Technology Design Guide IOS XE): http://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Mar2015/CVD-IWAN-WAASDesignGuide-Mar15.pdf