Troubleshooting guide

1-8
Cisco Wide Area Application Services Configuration Guide
OL-26579-01
Chapter 1 Configuring AppNav
Information About AppNav
You can also identify sites using source IP addresses or subnets in the class map, if you know what IP
addresses are used in the site and keep the policy configuration consistent with site IP addresses.
However, we recommend that you use peer device IDs in configuring site affinity.
Note A peer ID-based class map works only for matching flows that carry the WAAS auto discovery TCP
options. If you configure a class to match a site peer ID at the data center, the same class does not match
flows that originate in the other direction, such as those flows that originate from the data center and go
back to the same site. Such flows are usually small in number compared to the site to data center flows.
If you want flows in both directions to go to the same WNG, you must configure two class maps: one to
match in the site to data center direction, typically using the site device ID; and another to match the data
center to site direction, using destination IP subnets belonging to the site. Both class maps can be
configured to distribute traffic to the same WNG. A mesh network is a specific use case where flows can
originate in either direction.
If the site WAE is in overload or does not mark the SYN packet with auto discovery options for any other
reason, the ANC cannot match it to the peer match class map.
Application Affinity
Application affinity gives you the ability to always send certain application traffic to a specific WNG,
which allows you to reserve optimization capacity for different applications depending on business
priorities.
In the context of AppNav flow distribution, an application is defined using a three-tuple of the source IP,
destination IP, and destination TCP port. The actual type of traffic does not matter for flow distribution.
For example, you can use separate WNGs for HTTP traffic that is addressed to different destination ports
or different server IP addresses. Destination IP and ports are most useful in using application affinity,
but having the source IP also helps you to define the traffic of interest.
A small number of protocols, such as FTP, use dynamic destination ports. An FTP server in active mode
originates a data connection back to the FTP client using a dynamic destination port. This port is
exchanged over the control channel from client to server using the well-defined destination port 21.
Consider trying to define a class map for FTP. Because the destination port is not known in advance, you
cannot map both control and data connections to the same class. In this case, we recommend that you
use the client IP addresses or subnets to match against destination IP addresses for the data connections.
You must configure two class maps: one for the control channel, using destination port 21, and another
for the data channel, using destination IP addresses. You can configure policy rules so that both class
maps distribute traffic to the same WNG.
You can further classify traffic from a site into applications by combining the peer matches with
three-tuple matches in a match-all class map, called a Custom class map type in the Central Manager.
You can define separate WNGs, for example, for HTTP traffic from a particular site and CIFS traffic
from the same site.
Default Policy Behavior
The following default class maps are provided:
CIFS—Matches traffic for destination ports 139 and 445
Citrix-ICA—Matches traffic for destination port 1494
Citrix-CGP—Matches traffic for destination port 2598