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 provides detailed configuration information for AppNav-XE on the Cisco ISR 4451-X and contains the following sections:
To configure the AppNav-XE Controller, follow these configurations tasks:
The AppNav Controller group configures the AppNav Controller. To configure the AppNav Controller group, enter the IP addresses used by the AppNav Controllers.
You must configure a service node under a service node group. The AppNav-XE component intelligently distributes flows to the service node within the service node group.
Beginning with the Cisco IOS XE 3.13 release, a total of 64 service nodes may be included in a cluster. (Earlier releases permitted 32.)
You cannot use VRF with either the AppNav Controller or the service node IP address. The IP addresses must be explicitly accessible without VRF. For example, you cannot use the management interface's IP address (with vrf Mgmt-intf) as the AppNav Controller IP address. Routing through VRF leaking is not supported for service-node to Appnav controller communication..
The AppNav-XE component uses AppNav classes to determine the traffic to be used. Use the appnav type class-map to classify the traffic based on the following set of parameters:
|
|
|
|
|
|
---|---|---|---|---|---|
To create or modify a class map to be used for matching connections to a specified class, use the class-map command in global configuration mode. To remove an existing class map, use the no form of this command. The class-map command enters class-map configuration mode in which you can enter an optional description command and one or more of the match commands to configure the match criteria for this class.
The syntax for defining a class map is as shown below:
If you do not specify a match, the default is match-all.
The match access-group command specifies a numbered access-list or named access list whose contents are used as the match criteria against packets to determine if they belong to the class. The access list number ranges from 1 to 2699.
The match peer command identifies a peer service node that may be performing optimization at the client side of a connection and must be specified in 01:23:45:67:89:ab format. The match peer clause is only useful if the AppNav-XE component is acting as core, that is, receiving a connection that has already been through a peer WAAS device.
The match protocol command gets one of the following protocols:
The protocol is only used along with additional information provided by the service node to associate the packet with specific applications. The match protocol filter should not be confused with the monitor-load keyword in AppNav policy described below.
Network Based Application Recognition (NBAR) feature provides intelligent network classification for network infrastructure. NBAR is a classification engine that can recognize a wide variety of applications, including Web-based applications and client/server applications that dynamically assign port numbers. After the application is recognized, the network uses specific services for that particular application.
Using NBAR FIF (First In Flow) capability, AppNav-XE identifies the application information on the SYN packet itself and decides whether traffic needs to be redirected to WAAS. In order to allow APPNAV class maps to define rules based on APP-ID, an nbar-protocol filter is added in AppNav class-map.
The syntax for defining a class map is as shown below:
If you do not specify a match, the default is match-all.
(config-cmap)# [no] match protocol app_def
APPNAV app-id based class maps
To minimize the size of the app-id based class group, use app-id based class maps and then add similar types of app-id class maps with existing AppNav class map types. For every APPNAV class map type, a matching application-id based class map is created. The APPNAV genesis class maps are as follows:
For each of the above class map, a class map of application ids are created according to customer application policy. The following example shows the HTTP_Optimized_App class map:
APPNAV feature supports nested class maps in order to combine two class maps in single APPNAV class map. You can maintain the original class maps and continue the functionality of load reporting and traffic distribution under existing APPNAV protocol class.
The following is the example for HTTP applications:
After you configure the AppNav class maps, you can assign actions to them by using an AppNav policy map.
Limits for AppNav Policy Maps, Class maps, and Match Filters Per Class
Table 3-2 lists the limits for AppNav policy maps, class maps, and match filters per class.
To create or modify a policy map that defines the service policy for the candidate optimization traffic, use the policy-map command in global configuration mode.
The class command above enters the policy-map-class configuration submode:
The distribute command is the most common action in this class. The system sends the traffic that matches the class map to the service node group identified by the specified sng_name parameter. If no service node group is available, or if no distribute is specified, the default action is to pass-through the traffic.
To configure primary and backup service node groups, use two distribute command statements:
If the service nodes in the primary service node group are not available, the system will use the backup service node group.
The monitor-load command determines which load values should be monitored. When you monitor an application accelerator, the AppNav Controller checks for overload on that application accelerator and does not send new flows to a service node that is overloaded. Flows are sent to a different service node in the service node group.
This command is optional; if you use it, the system monitors the application accelerator indicated by the application_accelerator_name parameter. If you do not use this command, the system monitors the TFO accelerator status. If you specify an application accelerator, it replaces the existing monitor-load if one exists.
The supported application accelerators are:
Use the pass-through command to explicitly indicate that no redirection is to take place. You cannot use the pass-through command with the distribute or monitor-load commands. If you use the pass-through command, the system blocks any distribute or the monitor-load command actions and displays an error message. If you use either the distribute or the monitor-load command, then the system blocks any pass-through command actions.
A service context is used to tie the AppNav Controller group, service node group, and AppNav policy map together.
Note If AppNav-XE is managed by WCM, the authentication key in the service-context configuration cannot be modified using the command line interface (CLI).
Use the following command to create a service context:
interface_ID is a number that is unique across all service contexts. It determines the naming of the automatically-created virtual interfaces called AppNav-Compress interface_ID and AppNav-UnCompress interface_ID.
AppNav Controller Group Command
acg_name is the name of the AppNav Controller group to which this service context belongs. You can only configure one AppNav Controller group for each service context.
Authentication SHA1 Key Command
authentication_key is the shared authentication key used during AppNav Controller to service node registration. You must configure the key identically on service nodes in the same service context. Currently, the AppNav Controller group only supports one authentication key. All service contexts must use authentication or no service contexts can use authentication.
sng_name is the name of one or more service node groups that are part of the service context. The list is used to cross check the ones used in the AppNav policy. Note that the same service node group cannot be shared between two service contexts.
appnav_policy_name is the name of the AppNav policy for the service context.
VRF_name is the name of the VRF on the LAN interface for the traffic seen by AppNav. You can enter more than one VRF name. You can define up to 64 VRF names, but there is no limit to the number of VRFs supported. VRF global is the same as the other VRF definitions except that it identifies traffic with no VRF. The VRF names are listed one after another such as the following:
If you do not configure a VRF in the service context, the system automatically applies the default configuration of vrf default. The purpose of vrf default is to match traffic that does not match a configured VRF name or vrf global.
The following logic is used to pick the right service context for a packet: The system compares the VRF on the LAN interface traversed by the packet against the VRF names (or vrf global) that is configured in the service contexts. If there is a match, the system picks the corresponding service context. If there is no match, the system picks a service context with vrf default, if available. If there is no such service context, then the system passes through the packet.
Currently, the only service supported by the AppNav-XE component is WAAS. To enable the AppNav-XE component, identify your WAN interface and then use the service-insertion command.
Note Both the incoming and outgoing TCP traffic of the interface are subject to AppNav processing according to their VRF and the service policy associated with the service context identified by the VRF.
This section contains the following sub-sections:
Note Configuring the AppNav service node auto discovery feature is only applicable if you do not use the EZConfig program. If you do use the EZConfig program, you do not need to configure the AppNav service node auto discovery feature.
To configure the AppNav service node auto discovery feature, perform the following steps:
Step 1 In Cisco IOS-XE, enter the following command.
For the sng_name parameter, enter the name of the service node group for which you want to enable the AppNav service node auto discovery feature. Ensure that the WAAS device is in the same subnet as the AppNav-XE component.
Step 2 Enable the feature by entering the following:
Step 3 On the WAAS device, enter the following command:
Step 4 Select the interface to use and make sure it is in the same subnet as the AppNav service requestor:
Note If interface is not specified, the default is GigabitEthernet0/0
Step 5 Configure and enable the AppNav service node auto discovery feature by entering the following:
You can disable the AppNav service node auto discovery feature by doing either of the following:
Note Configuring the container is only applicable if you do not use the EZConfig program. If you use the EZConfig program, you do not need to configure the container.
Before you can install ISR-WAAS, you must copy the OVA package to the Cisco ISR 4451-X.
Use the following CLI command to copy the ISR-WAAS OVA package to the Cisco ISR 4451-X:
Use the virtual-service install name name package package command to install the ISR-WAAS OVA package onto the Cisco ISR 4451-X.
Here is the output of the show virtual-service detail command at this stage after installation.
Configure a virtual port group interface. Use the IP address of the host end of the bridge between the host and virtual service when activated. Here is an example of a part of the running config output:
The output of the show virtual-service profile name ISR-WAAS command displays the various profiles that are available in the installed ISR-WAAS OVA package. Using the detail keyword with this command displays the resource requirements associated with the profile description.
To create the ISR-WAAS application container, associate the virtual service with a profile name and a virtual port group. Configure the IP address of the virtual service end of the bridge that is created between the host and the virtual service when activated. Here is an example:
The following is an example of the commands used to activate the ISR-WAAS application container:
Note Ensure that the output of the show virtual-service list command displays the status of the virtual service as “Activated” to confirm that the service has started successfully.
Issue the following command to verify that the ISR-WAAS application container activated correctly:
To stop the ISR-WAAS application, enter the following commands and then issue the virtual-service list command to ensure that the application is deactivated:
When you uninstall the ISR-WAAS application, the system releases all the disk storage that was reserved for this virtual service and any associated saved data is lost.
The following commands demonstrate how to uninstall the ISR-WAAS application. Use the no activate command to stop the virtual service before you uninstall it.
Note Stopping the ISR-WAAS application can take some time. The show virtual-service list command will show the status as “Deactivating” when the application is de-activating. Ensure that the application is deactivated before you uninstall the application
To remove the AppNav-XE configuration, follow these steps:
Step 1 From configuration mode, remove the interception from the WAN interface. Use these CLI commands:
Step 2 Disable the AppNav service context. Use these CLI commands:
Step 3 Remove the AppNav service context, service node group, and AppNav controller group. Use these CLI commands:
Step 4 Remove the AppNav policy map, class map, and access list. Use these CLI commands:
You can configure port channel support for AppNav-XE by indicating to the dataplane to swap IP addresses in the packets so that they can be distributed between different port channels.
To do this, use the following command:
This command also enables AppNav-XE to handle packets from the Service Node whose ip addresses are swapped.