3.3. Configuring Application Assurance with CLI
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.
3.3.1. Provisioning AA ISA MDA
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).
- Classic CLI commandsconfigure card slot-number mda mda-slot mda-type isa2-aa
- MD-CLI:configure card slot-number mda mda-slot mda-type isa2-aa
The following output displays an AA ISA configuration example.
Classic CLI commands
MD-CLI commands
3.3.2. Configuring an AA ISA Group
To enable AA on the router:
- Create an AA ISA group.
- Assign active and optional backup AA ISAs to an AA ISA group.
- Select the forwarding classes to divert.
- Enable the group.
- Optionally:
- Enable group policy partitioning
- Configure capacity cost threshold values
- Configure the number of transit prefix IP policies
- Configure IOM egress queues to the MS-ISA
- Enable overload cut through and configure the high and low watermarks values
- Configure performance statistics accounting
The following example illustrates AA ISA group configuration with:
- Primary AA ISA and warm redundancy provided by the backup AA ISA.
- “fail-to-wire” behavior configured on group failure.
- BE forwarding class selected for divert.
- Default IOM QoS for logical ISA egress ports. The ISA ingress QoS is configured as part of ISA provisioning (config>card>mda>network>ingress>qos).
The following commands illustrate the AA ISA group configuration context.
The following output displays an AA ISA group configuration example.
3.3.2.1. Configuring Watermark Parameters
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.
3.3.3. Configuring a Group Policy
3.3.3.1. Beginning and Committing a Policy Configuration
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.
3.3.3.2. Aborting a Policy Configuration
Use the following CLI syntax to abort a policy configuration.
3.3.3.3. Configuring an IP Prefix List
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.
3.3.3.4. Configuring AA Session Filters
Session filters can be configured to allow stateful firewall use-cases.
3.3.3.5. Configuring an Application Group
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.
3.3.3.6. Configuring an Application
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.
3.3.3.7. Configuring an Application Filter
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.
3.3.3.8. Configuring an Application Profile
Use the following CLI syntax to configure an application profile.
The following example displays an application profile configuration.
3.3.3.9. Configuring Suppressible App-Profile with SRRP
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:
- Enable the capability to suppress AA subscribers on a given SRRP group interface, typically by selecting backup SRRP group interfaces.
- ESM subscribers with a valid app-profile are diverted to AA by default, to suppress selected group of subscribers using AA for optional value-add services. The operator then specifies which app-profile will be suppressed and therefore not diverted to AA.
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”:
3.3.3.10. Configuring Application Service Options
Use the following CLI syntax to configure application service options.
The following example displays an application service options configuration.
3.3.3.11. Configuring a Policer
Use the following CLI syntax to configure a policer.
The following example displays an Application Assurance policer configuration.
3.3.3.12. Configuring an Application QoS Policy
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).
3.3.3.13. Configuring an Application and DNS IP Cache for URL Content Charging Strengthening
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:
- Create an application of interest and its related app-filter’s URL expressions. This application is typically mapped into a charging-group.
- Create a dns-ip-cache. Configure parameters so the IP cache is populated by the domain names from the application mapped to the zero rating charging group and specify which DNS server IP addresses the IP cache will listen from.
- Configure a AQP to enable the dns-ip-cache.
- Optionally, configure static IP addresses matching the IP addresses of the trusted proxies.
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:
3.3.3.14. Configuring an HTTP Error Redirect
Use the following CLI syntax to configure an HTTP error redirect policy:
The following example displays an Application Assurance HTTP redirect configuration.
3.3.3.15. Configuring HTTP Header Enrichment
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:
3.3.3.16. Configuring an HTTP Redirect Policy
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:
3.3.3.17. Configuring an HTTPS Policy 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:
3.3.3.18. Configuring a Captive Redirect HTTP Redirect Policy
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.
3.3.3.18.1. Captive-Redirect and HTTPS Flows Redirection
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:
- Create an http-redirect policy. If the ISA group aa-sub-scale mode is configured for residential or VPN, then configure the http-redirect policy for captive-redirect and associate the appropriate VLAN id AA Interface (an aa-interface routable within the subscriber’s service must be created for each ISA-AA card in the system). If the ISA group aa-sub-scale mode is configured for DSM, then there is no need to associate the http-redirect policy to a VLAN id and no need to create an AA Interface.
- Create a session filter policy to allow at the minimum UDP on port 53. Additional traffic can be allowlisted based on a statically defined IP prefix list or a dynamic DNS IP cache policy. The redirect landing page should be configured using IP prefixes.
- The last action of the session filter should be set to http-redirect the remaining flows using a predefined captive redirect HTTP redirect policy.
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):
3.3.3.19. Configuring ICAP URL Filtering
To configure the system for ICAP URL filtering, the operator needs to.
- Create an AA interface and assign an IP address to each AA ISA within an IES or VPRN service. This routed interface is then used by the system to establish TCP communication with the ICAP server.
- Create an HTTP redirect policy (used by the URL filter to redirect HTTP or HTTPS traffic).
- Create a URL filter, configure the ICAP server IP address, redirect policy, and default action.
- Verify that the AA interface and URL filter are operationally up.
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:
- More than one AA interface can be configured for each AA ISA card, however, the operator must use the same service VLAN across all these interfaces for a given URL filter object.
- Configure an egress IP filter under the SAP towards the ISA AA interface to only allow selected IP addresses or subnets (for example, ICAP servers or network management).
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:
3.3.3.20. Configuring Web-service URL Classification
The following example describes how to configure web-service URL classification.
- Configure the shared resources to be used for the cache.Example:config>isa>aa-grp>shr-res-pool# info detail----------------------------------------------web-service-url-filter 100----------------------------------------------In this example configuration, 100% of shared resources are allocated to web-service URL classification.
- Configure the HTTP redirect policy:Traffic that belongs to one of the blocked categories (as defined in the profile activated for the user), is redirected.The operator can append the category name and category ID to the redirect URL (that is, the category that resulted in the redirect action).Example:config>app-assure>group 1----------------------------------------------http-redirect "redirect-ws-filter" createdescription "Redirect for Web Service URL Filtering"template 5tcp-client-resetredirect-httpsredirect-url "http://10.154.90.1/redirect.html?catname=$CATNAME&catid=$CATID"no shutdownexit---------------------------------------------
- Configure the URL filter and category profiles.The operator defines a new URL filter with the following attributes:
- classifier = "web-service-1"defines the URL categorization database to use
- category-set-id = 1defines the URL categories to use
- fqdn = nokia-api.webtitancloud.comdefines the URL categorization database endpoint that the AA connects to
- dns-serverdefines the DNS server to resolve the FQDN
- profiledefines up to eight profile names
- categorydefines the category to be blocked in the configured profile
In the following URL filter configuration example, the three profiles defined in Table 18 of the Web-service URL Classification section are configured. Two classification-overrides entries are also configured.Example:configure application-assurance group 1 url-filter "ws-filter"config>app-assure>group>url-filter# info----------------------------------------------apply-function-specific-behaviorweb-serviceclassifier web-service-1 category-set-id 1vlan-id 100default-action block-http-redirect "redirect-ws-filter"http-redirect "redirect-ws-filter"fqdn nokia-api.webtitancloud.comdns-server 8.8.8.8classification-overridesentry 1 expression www.site1.abc category "Phishing/Fraud"entry 2 expression www.site2.def category "Illegal Drugs"profile low createcategory "Internet Watch Foundation List" blockcategory "Spyware And Malicious Sites" blockcategory "Phishing/Fraud" blockprofile medium createcategory "Internet Watch Foundation List" blockcategory "Spyware And Malicious Sites" blockcategory "Phishing/Fraud" blockcategory "Illegal Drugs" blockcategory "Violence" blockcategory "Weapons" blockprofile high createcategory "Internet Watch Foundation List" blockcategory "Spyware And Malicious Sites" blockcategory "Phishing/Fraud" blockcategory "Illegal Drugs" blockcategory "Violence" blockcategory "Weapons" blockcategory "Nudity" blockcategory "Alcohol" blockcategory "Criminal Skills/Hacking" blockcategory "Hate Speech" blockdefault-category-profile "low"no shutdown----------------------------------------------Enabling apply-function-specific-behavior allows the operator to configure a default-action and http-redirect which are specific to web-service URL Classification only. Alternatively, the operator may configure the same default-action and http-redirect for all url-filter functions by disabling the apply-function-specific behavior (which is the default) and configuring a default-action and http-redirect in the config>app-assure>group>url-filter. - Configure the ASO.The ASO is used to dynamically allocate a profile to a user.Example:config>app-assure>group>policy>aso# info----------------------------------------------characteristic "url-filter-policy" createvalue "high"value "medium"value "low"default-value "low"exit----------------------------------------------
- Configure the AQP.The AQP is used to execute the URL filter policy. The URL filter uses the ASO value that is active for the user to select the category profile.Example:>config>app-assure>group>policy>aqp# entry 100 createactionurl-filter "ws-filter" characteristic "url-filter-policy"exitno shutdownIn the AQP defined in this example, there is no match condition. Therefore, the web-service URL classification is applied to all subscribers.
3.3.3.21. Configuring Local URL-List Filtering
To configure the system for local URL-list filtering, the operator needs to:
- Create a URL-list policy referencing a valid file located on the compact flash
- Create a url-filter policy for local-filtering by referencing this URL-list
- Create an AQP to apply this url-filter policy
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:
- head anchors character set [^ *]
- tail anchors character set [$ *]
- mid expression character set [\d \I \. \**]
- hex escape characters [\x00-\xFF]
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:
3.3.3.22. Configuring HTTP Notification
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:
3.3.3.23. Configuring Tethering Detection
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:
3.3.4. Configuring AA Volume Accounting and Statistics
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:
3.3.4.1. Configuring Cflowd Collector
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. |
3.3.4.2. Configuring AA Comprehensive, RTP Performance, TCP Performance, and Volume Reporting
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:
- Enables per-flow volume statistics for group 1, partition 1 and configures sampling rate to 1/1000.
- Enables per-flow TCP performance statistics for web_traffic application within group 1, partition 1 and configures TCP sampling rate to 1/500.
- Enables per-flow TCP performance statistics for citrix_traffic application within group 1, partition 1 using TCP sampling rate2 to 1/100.
- Enables per-flow RTP A/V performance statistics for voip_traffic application within group 1, partition 1 and configures RTP sampling rate to 1/10.
- Enables per-flow comprehensive statistics for web_traffic.
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: