Troubleshooting guide

1-6
Cisco Wide Area Application Services Configuration Guide
OL-26579-01
Chapter 1 Configuring AppNav
Information About AppNav
The AppNav policy is specific to each ANC, though typically all ANCs in a cluster have the same policy.
Each ANC consults its AppNav policy to determine which WNG to use for a given flow. Different ANCs
in a cluster can have different AppNav policies, which allows you to customize distribution in certain
cases. For example, when a cluster contains ANCs and WNs that are in different locations, it may be
more desirable for an ANC to distribute traffic to WNs that are closer to it.
Nested Policies
A policy rule can specify one nested policy, which allows traffic identified in a class to be subdivided
and handled differently. Nested policies provide two advantages:
• It allows another policy to be used as a common subclassification tool.
For example, you can define a policy that contains monitoring actions and apply it as a subpolicy to
multiple classes in the primary policy.
• It provides a method of including class maps with both match-any and match-all characteristics into
a single subclass.
The nested policy feature is designed for use with site-based classes (matched by peer ID) at the first
level and application-based subclasses (matched by IP address/port) at the second level. Only the first
level policy can contain classes that use match peer conditions.
Site and Application Affinity
You can provision a WNG for serving specific peer locations (site affinity) or applications (application
affinity) or a combination of the two. Using a WNG for site or application affinity provides the following
advantages:
• Provisioning—Localize a class of traffic to achieve control over provisioning and performance
monitoring. For example, a business-critical application like Sharepoint or a business-critical site
can be given assured capacity and monitored closely for performance.
• Enhanced application performance—Better compression performance is achieved by limiting data
that belongs to a site to one or a few WNs, which results in better utilization of the Data Redundancy
Elimination (DRE) cache.
Figure 1-3 depicts how sites and applications can be associated with node groups. The following WNGs
are defined:
• WNG-1—Consists of two WNs that process flows coming only from sites A and B.
• WNG-2—Consists of two WNs that process HTTP and SSL flows from any site. Whether HTTP and
SSL flows from Site A and Site B should be processed by WNG-2 or WNG-1 is determined by the
order of rules in the policy.
• WNG-3—Consists of two WNs that process MAPI flows coming from any site. Whether MAPI
flows from Site A and Site B should be processed by WNG-3 or WNG-1 is determined by the order
of rules in the policy.
• WNG-4—Consists of three WNs. The class-default class is applied to this WNG so that it is sent all
flows that do not match any other class map.