This section provides information to configure Application Assurance entities using the command line interface. It is assumed that the user is familiar with basic configuration of policies.
The following illustrates syntax to provision AA ISA2 and configure ingress IOM QoS parameters (the egress IOM QoS is configured in the config>isa>application-assurance-grp>qos context).
The following output displays an AA ISA configuration example.
Classic CLI commands
MD-CLI commands
To enable AA on the router:
The following example illustrates AA ISA group configuration with:
The following commands illustrate the AA ISA group configuration context.
The following output displays an AA ISA group configuration example.
Use the following CLI syntax to configure thresholds for logs and traps when under high consumption of the flow table. The flow table has a limited size and these thresholds can be established to alert the user that the table is approaching capacity. These flow table watermarks represent number of flow contexts allocated on the ISA, which will be slightly higher than the actual number of existing flows at the point when the watermark is reached.
The low threshold is used while the high threshold is used as an alarm.
To enter the mode to create or edit Application Assurance policies, you must enter the begin keyword at the config>app-assure>group>policy prompt. The commit command saves changes made to policies during a session. Changes do not take effect in the system until they have performed the commit function. The abort command discards changes that have been made to policies during a session.
The following error message displays when creating or modifying a policy without entering begin first.
There are no default policy options. All parameters must be explicitly configured.
Use the following CLI syntax to begin a policy configuration.
Use the following CLI syntax to commit a policy configuration.
Use the following CLI syntax to abort a policy configuration.
An operator can use IP lists to define a list of IP addresses (along with any masks). This list can be later referenced in AQPs, application filters and/or session-filters.
Use the following CLI syntax to configure an application filter entry.
Session filters can be configured to allow stateful firewall use-cases.
An operator can configure an application group to group multiple application into a single application assurance entity by referencing those applications in the group created.
Use the following CLI syntax to configure an application group.
The following example displays an application group configuration.
An operator can configure an application to group multiple protocols, clients or network applications into a single Application Assurance application by referencing it later in the created application filters as display in other sections of this guide.
Use the following CLI syntax to configure an application.
The following example displays an application configuration.
An operator can use an application filter to define applications based on ALU protocol signatures and a set of configurable parameters like IP flow setup direction, IP protocol number, server IP address and server TCP/UDP port. An application filter references an application configured as previously shown.
Use the following CLI syntax to configure an application filter entry.
The following example displays an application filter configuration.
Use the following CLI syntax to configure an application profile.
The following example displays an application profile configuration.
For information about SRRP, refer to the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide.
In the context of an ESM SRRP deployment, the operator can define at the app-profile level if the subscriber will be diverted to the ISA-AA card per SRRP group interface. This can be useful to reduce the total number of ISA cards required in the event of a switch-over from a primary to backup SRRP node when AA is used as a value-add service for selected subscribers.
To configure the network for suppressible app-profiles in the context of SRRP the operator needs to:
Use the following CLI syntax to enable the capability to suppress ESM subscribers from a backup SRRP group interface:
The following example displays an application profile configuration used for premium subscribers, this type of subscriber will always be diverted to Application Assurance, it is also the default configuration:
The following example displays an application profile configuration for best effort / value-add subscribers not diverted to Application Assurance on the SRRP group interface configured with “suppress-aa-sub”:
Use the following CLI syntax to configure application service options.
The following example displays an application service options configuration.
Use the following CLI syntax to configure a policer.
The following example displays an Application Assurance policer configuration.
Use the following CLI syntax to configure an application QoS policy.
The following example displays an application QoS policy configuration.
The following example displays an AQP entry configuration to mirror all positively identified only P2P traffic (AppGroup P2P) for a subset of subscribers with ASO characteristic aa-sub-mirror enabled.
The following example displays an AQP entry to mirror all P2P traffic (all positively identified P2P traffic and any unidentified traffic that may or may not be P2P - AppGroup P2P) for a subset of subscribers with ASO characteristic aa-sub-mirror enabled (the order is significant).
In the context of URL content charging, also known as zero rating, the DNS IP cache (dns-ip-cache command) feature ensures that only legitimate traffic is classified in a given application and charging-group. Subscribers’ DNS responses matching a list of domain names used for content charging populate the DNS IP cache. The system can then be configured to create app-filters matching HTTP or HTTPS expressions as well as the IP cache ensuring that traffic is properly classified. If the operator utilizes proxies in their network, they may also configure a maximum of 8 IP addresses which match the IP addresses of the proxies used. Traffic whose destination IP address matches one of the configured proxies will be assumed to be legitimate traffic.
To configure the system for URL content charging strengthening with a dns-ip-cache the operator needs to:
Use the following CLI syntax to create a dns-ip-cache:
The following example displays a configuration for a dns-ip-cache configured to snoop DNS responses for two different domains “*.domain1.com” and “*domain2.com” which are zero rated or charged specifically by the operator. The configuration only uses DNS responses from the DNS server addresses configured within the dns-match to populate the ip-cache:
The domains configured in the dns-ip-cache must match the app-filter expressions for the applications zero rated or charged specifically by the operator. The following example displays the charging-group Zero Rated and application Sponsor Content #1 configuration:
The following example displays the AQP entry to enable the dns-ip-cache to snoop DNS responses; this can be optionally based on ASO characteristics:
Use the following CLI syntax to configure an HTTP error redirect policy:
The following example displays an Application Assurance HTTP redirect configuration.
Use the following CLI syntax to configure an HTTP header Enrichment policy:
The following example displays an Application Assurance HTTP header enrichment configuration.
In addition, the following show routine displays various HTTP enrichment-related statistics:
Use the following CLI syntax to configure an HTTP redirect policy:
The following example displays an AA HTTP redirect configuration.
The following example displays an Application Assurance http-redirect configuration using macro substitution to append url parameters within the redirect url:
The following example displays AQP entry to block all http gaming traffic (AppGroup BlockedContent) and perform redirect:
Use the following CLI syntax to configure an HTTPS redirect policy:
The following example displays the configuration of an HTTPS redirect object to redirect traffic to the operator's portal:
After creating the HTTP Redirect object, an AQP is used to configure the traffic to be redirected:
The traditional HTTP redirect policy is used to redirect flows on the HTTP response packet, meaning the TCP three-way handshake and the original HTTP request are allowed by the 7750 SR to the Internet before the subscriber is redirected. The captive redirect HTTP redirect policy is used to redirect flows without sending any traffic to the Internet unless it matches a configurable allowlist by terminating TCP sessions in the ISA-AA cards, in which case HTTP flows are redirected to a predefined redirect URL while non-HTTP TCP flows are TCP reset.
The captive redirect HTTP redirect policy can be optionally configured to redirect HTTPS sessions in addition to HTTP to a pre-defined redirect landing page, typically the captive-portal URL in the context of a WiFi network.This capability is particularly useful when the router is used to provide a captive-portal type of access, as it allows the operator to improve the user experience by redirecting the subscriber’s web browser sessions to the desired captive-portal landing page when the user first connects to the network using HTTPS instead of HTTP.
Prior to the introduction of this feature, users opening their web browsers to an HTTPS URL when first connecting to a new Wi-Fi network and expecting to be redirected to a captive portal were instead presented with an error page automatically generated by the web browser since the session was dropped or reset by the network, thus ultimately preventing the user from connecting. Most non-technical users connecting to a captive-portal network may not know the difference between HTTP and HTTPS when it comes to login/redirection, and a number of subscribers may not connect or may get frustrated trying multiple different links prior to a successful Wi-Fi authentication.
When the system is configured for captive-redirect redirect-https it will terminate transport layer security (TLS) TCP sessions in the ISA-AA cards and return a self-signed certificate back to the user. Upon the user acceptance of the security warning generated by the web browser, the web session will then automatically be redirected to the configured captive-portal landing page.
Captive redirect policy supports redirection for HTTP, HTTPS, HTTP2, SPDY, and TCP Fast Open connections.
A session-filter is used to define the criteria for permitting or redirecting flows using the captive redirect HTTP redirect policy. Typically the operator needs to permit UDP on port 53 for DNS and they can optionally permit other content based on IP address, port number, IP prefix list, or DNS IP cache thus allowing specific on-net of off-net applications through the captive redirect policy.
To configure the system for captive redirect HTTP redirect the operator needs to:
Use the following CLI syntax to create a captive redirect HTTP redirect policy:
The following example displays a typical configuration for a session filter user in the context of captive redirect:
The following example displays a typical configuration for the AA interface used by the captive redirect HTTPS redirect policy for ESM Subscribers (DSM does not require the configuration of the AA Interface):
The following example displays a typical configuration for the HTTPS redirect policy for ESM Subscribers (DSM does not require the configuration of the VLAN ID):
To configure the system for ICAP URL filtering, the operator needs to.
Use the following CLI syntax to configure the AA interface for each AA ISA:
The following example displays an AA interface created for the ISA card 1/2 using IP address 172.16.2.1/31:
In the example above, 172.16.2.1 is used by the IOM side of the interface while the ISA itself is automatically assigned 172.16.2.0 based on the /31 subnet.
Recommendations:
Use the following CLI syntax to configure the URL filter:
If the apply-function-specific-behavior command is enabled, the operator may configure an ICAP-specific default-action and redirect. This is done by configuring default-action and http-redirect in config>app-assure>group>url-filter>icap context.
The following example displays a URL filter configuration:
Enabling the apply-function-specific-behavior command allows the operator to configure a default-action and HTTP redirect which are specific to ICAP URL filtering only. Alternatively, the operator configures the same default-action and http-redirect for all url-filter functions by disabling the apply-function-specific-behavior and configuring a default-action and http-redirect in the config>app-assure>group>url-filter context.
The following example displays an AQP entry to enable ICAP URL filtering for opted-in subscribers based on ASO characteristics:
Optionally, the operator can add a custom x-header to the ICAP request in order for the ICAP server to filter traffic based on this new x-header value instead of filtering based on subscriber names. This is done by defining a new ASO characteristic for the different ICAP filtering service packages used in the network and referring the characteristic name in the URL filter AQP action.
The following example displays a URL filter configuration with the custom-x-header field added to the ICAP request:
The following example displays the ASO characteristic used to define the type of filtering policy available:
The following example displays the AQP action required to add the appropriate ASO value to the ICAP custom-x-header field:
The following example describes how to configure web-service URL classification.
To configure the system for local URL-list filtering, the operator needs to:
Use the following CLI syntax to create a URL-list:
Wildcards are supported on hostname entries. To enable wildcard support, the url-list must have expression-match (in config>app-assure-group>url-list) enabled (the default is disabled). An entry may contain the following:
The same capabilities with those described in Application Filters section are provided.
When expression-match is set to enabled, the list should contain hostnames only, with wildcards.
The decryption key is optional. If the decryption key is not specified, the system will assume that the file is not encrypted. To encrypt a file in Linux using the supported encryption format, use the following command:
The following example displays a URL list configuration:
Use the following CLI syntax to create a url-filter policy for local-filtering:
The following example displays a deny-list URL filter configured for local-filtering:
The default action should always be configured to “allow” when the url-filter is configured for local-filtering. The default-action in this context represents the action the system will take in case the local-list file is not accessible; this scenario may happen if the source file was corrupted or if the compact flash card was not accessible.
The following example displays the AQP entry to enable ICAP url-filtering for opted-in subscribers based on ASO characteristics:
Use the following CLI syntax to configure an HTTP Notification policy.
The following example displays an HTTP notification policy configured with a minimum interval of 5 minutes:
The operator then needs to enable the http-match-all-req feature for any HTTP request sent the messaging server domain which will be used to monitor HTTP notification success/failures. This is done by creating a new application and enabling http-match-all-req within the app-filter.
The following examples displays the AQP entry required to match this policy based on an ASO characteristic:
To configure tethering detection, enable the tethering detection option and specify the tethering state of the subscriber for which the specified application QoS policy match entry will be applied.
To configure tethering detection use the following commands:
A network operator can configure AA volume statistic collection and accounting on both AA ISA system and subscriber levels.
The following commands illustrate the configuration of statistics collection and accounting policy on an AA group/partition aggregate level (without subscriber context).
The following commands illustrate the configuration of statistics collection and accounting policy for each AA subscriber in the system.
The following commands illustrate configuration of special study mode for a subset of AA subscribers (configured) to collect all protocol and/or application statistics with an AA subscriber context.
For details on accounting policy configuration (including among others AA record type selection and customized AA subscriber record configuration) refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide.
The following output illustrates per AA-subscriber statistics configuration that elects statistic collection for a small subset of all application groups, applications, protocols:
The following output displays an Application Assurance cflowd collector configuration example:
The following commands show the configuration of an AA cflowd collector.
The following output displays an AA direct export cflowd collector configuration example.
Example:
![]() | Note: The VLAN-ID must match the one configured under the AA ISA interface. For an example of how to configure an AA interface, see Configuring ICAP URL Filtering. |
The following commands show the configuration of AA comprehensive reporting.
The following commands show the configuration of AA RTP performance reporting.
The following commands show the configuration of AA TCP performance reporting.
The following commands show the configuration of AA volume reporting.
The following commands show the configuration of AA comprehensive, RTP performance, TCP performance, and volume reporting.
The following example shows a configuration that includes the following:
Example:
Because no template selection is made in the above example for any of the configured cflowd templates (volume, RTP/TCP performance), the legacy template is used.
Alternatively, if the operator wants to have specific fields within, for example, volume templates, then the dynamic option must be selected under:
The following is an example of the dynamic option selected.
Example: