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).

  1. Classic CLI commands
    configure card slot-number mda mda-slot mda-type isa2-aa
  2. 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

*A:cpm-a>config>app-assure# show mda 1/1 
===============================================================================
MDA 1/1
===============================================================================
Slot  Mda   Provisioned           Equipped              Admin     Operational  
            Mda-type              Mda-type              State     State        
-------------------------------------------------------------------------------
1     1     isa2-aa                isa2-ms                 up        up         
===============================================================================
*A:cpm-a>config>app-assure#
 
 
*A:cpm-a>config>card# info 
----------------------------------------------
        card-type iom4-e-b
        mda 1
            mda-type isa2-aa
        exit
----------------------------------------------
*A:cpm-a>config>card# 

MD-CLI commands

(gl)[/]
A:admin@Dut-E# show mda 9/1
===============================================================================
MDA 9/1
===============================================================================
Slot  Mda   Provisioned Type                            Admin     Operational
                Equipped Type (if different)            State     State
-------------------------------------------------------------------------------
9     1     isa2-aa                                     up        up
                me-isa2-ms                                            
===============================================================================
 
 
(gl)[/]
A:admin@Dut-E# configure card 9 
(gl)[/configure card 9]
A:admin@Dut-E# info
    card-type iom4-e-b
    mda 1 {
        mda-type isa2-aa
    }
    fp 1 {
    }

3.3.2. Configuring an AA ISA Group

To enable AA on the router:

  1. Create an AA ISA group.
  2. Assign active and optional backup AA ISAs to an AA ISA group.
  3. Select the forwarding classes to divert.
  4. Enable the group.
  5. Optionally:
    1. Enable group policy partitioning
    2. Configure capacity cost threshold values
    3. Configure the number of transit prefix IP policies
    4. Configure IOM egress queues to the MS-ISA
    5. Enable overload cut through and configure the high and low watermarks values
    6. Configure performance statistics accounting

The following example illustrates AA ISA group configuration with:

  1. Primary AA ISA and warm redundancy provided by the backup AA ISA.
  2. “fail-to-wire” behavior configured on group failure.
  3. BE forwarding class selected for divert.
  4. 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.

CLI Syntax:
config>isa>application-assurance-group isa-aa-group-id [create] [aa-sub-scale sub-scale]
backup mda-id
description description
divert-fc fc-name
no fail-to-open
http-enrich-max-pkt size-in-octets
isa-capacity-cost-high-threshold threshold
isa-capacity-cost-low-threshold threshold
isa-overload-cut-through
partitions
minimum-isa-generation min-isa-generation
overload-sub-quarantine
[no] shutdown
partitions
primary mda-id
qos
egress
from-subscriber
pool [name]
resv-cbs percent-or-default
slope-policy slope-policy-name
port-scheduler-policy port-scheduler-policy-name
queue-policy network-queue-policy-name
wa-shared-high-wmark percent
wa-shared-low-wmark percent
to-subscriber
pool [name]
resv-cbs percent-or-default
slope-policy slope-policy-name
port-scheduler-policy port-scheduler-policy-name
queue-policy network-queue-policy-name
wa-shared-high-wmark percent
wa-shared-low-wmark percent
shared-resources
tcp-adv-func size
[no] shutdown
statistics
performance
accounting-policy acct-policy-id
collect-stats
transit-prefix-ipv4-entries entries
transit-prefix-ipv4-remote-entries entries
transit-prefix-ipv6-entries entries
transit-prefix-ipv6-remote-entries entries

The following output displays an AA ISA group configuration example.

A:ALU-A>config>isa>aa-grp# info detail
 ----------------------------------------------
    no description
    primary 1/2
    backup  2/2
    no fail-to-open
    isa-capacity-cost-high-threshold 4294967295
    isa-capacity-cost-low-threshold 0
    no partitions
    divert-fc be
    qos 
       egress
        from-subscriber
            pool 
                slope-policy "default"
                resv-cbs default
            exit
            queue-policy "default"
            no port-scheduler-policy
        exit
        to-subscriber
            pool
                slope-policy "default"
                resv-cbs default
            exit
            queue-policy "default"
            no port-scheduler-policy
        exit
       exit
    exit
     no shutdown
----------------------------------------------
A:ALU-A>config>isa>aa-grp#
 

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.

CLI Syntax:
config>application-assurance
flow-table-high-wmark high-watermark
flow-table-low-wmark low-watermark

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.

A:ALA-B>config>app-assure>group>policy#
MINOR: AA #1005 Invalid Set - Cannot proceed with changes when in non-edit mode

There are no default policy options. All parameters must be explicitly configured.

Use the following CLI syntax to begin a policy configuration.

CLI Syntax:
config>app-assure# group group-id
policy
begin

Use the following CLI syntax to commit a policy configuration.

CLI Syntax:
config>app-assure# group group-id
policy
commit

3.3.3.2. Aborting a Policy Configuration

Use the following CLI syntax to abort a policy configuration.

CLI Syntax:
config>app-assure# group group-id
policy
abort

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.

CLI Syntax:
config>aa>group>policy>app-assurance>group <aa-group-id>[:<partition>]
ip-prefix-list <prefix-list-name> [create]
no ip-prefix-list <prefix-list-name>
description <description>
no description
prefix <address/mask> [name <prefix-name>]
no prefix <address/mask>
 
*A:Dut-A>config>app-assure>group# ip-prefix-list AllowedLAN1Hosts create
*A:Dut-A>config>app-assure>group>pfx>$ description "allowed hosts"
*A:Dut-A>config>app-assure>group>pfx>$ prefix 10.10.8.2/32
*A:Dut-A>config>app-assure>group>pfx>$ prefix 10.10.8.180/32
*A:Dut-A>config>app-assure>group>pfx>$ prefix 10.10.8.231/32
*A:Dut-A>config>app-assure>group>pfx>$ exit
*A:Dut-A>config>app-assure>group#
 
 
*A:Dut-A>config>app-assure>group# ip-prefix-list "AllowedLan1Hosts"
*A:Dut-A>config>app-assure>group>pfx># info
----------------------------------------------
                description "allowed hosts"
                prefix 10.10.8.2/32
                prefix 10.10.8.180/32
                prefix 10.10.8.231/32
----------------------------------------------
*A:Dut-A>config>app-assure>group>pfx>#

3.3.3.4. Configuring AA Session Filters

Session filters can be configured to allow stateful firewall use-cases.

CLI Syntax:
*A:Dut-A>config>app-assure>group# session-filter <session-filter-name> [create]
default-action {permit | deny} [event-log <event-log-name>]
description <description-string>
entry <entry-id> [create]
action {permit | deny} [event-log <event-log-name>]
match
dst-ip <ip-address>
dst-ip ip-prefix-list <ip-prefix-list-name>
no dst-ip
dst-port {eq | gt | lt} <port-num>
dst-port range <start-port-num> <end-port-num>
dst-port port-list <port-list-name>
no dst-port
ip-protocol-num <ip-protocol-number>
no ip-protocol-num
src-ip <ip-address>
no src-ip
src-ip ip-prefix-list <ip-prefix-list>
src-port {eq | gt | lt} <port-num>
src-port range <start-port-num> <end-port-num>
src-port port-list <port-list-name>
no src-port
*A:Dut-A>config>app-assure>group# session-filter " denyUnsolictedwMgntCntrl" create
       description “S-FW opted-in sub – allow ISP access"
       default-action deny event-log “FW_log”
    entry 10 create
         description "allow ICMP access from ISP LAN#1"
         match
             ip-protocol-num icmp
             src-ip 10.10.8.0/24
         exit
         action permit
        exit
       entry 30 create
         description "allow all TCP (e.g. FTP/telnet)access from ISP LAN#2"
         match
             ip-protocol-num tcp
             src-ip 192.168.0.0/24
         exit
         action permit
       entry 40 create
         description "allow TCP on port 80 /HTTP access from a IP List on ISP LAN#1"
         match
             ip-protocol-num tcp
             src-ip ip-prefix-list AllowedLAN1Hosts
             dst-port eq 80
         exit
         action permit
 
       exit
 
 
*A:Dut-A>config>app-assure>group>sess-fltr$ info
----------------------------------------------
                description "S-FW opted-in sub . allow ISP access"
                default-action deny event-log “FW_Log”
                entry 10 create
                    description "allow ICMP access from ISP LAN#1"
                    match
                        ip-protocol-num icmp
                        src-ip 10.10.8.0/24
                    exit
                    action permit
                exit
                entry 20 create
                    description "allow ICMP access from ISP LAN#2"
                    action deny
                exit
                entry 30 create
                    description "allow all TCP (e.g. FTP/telnet)access from ISP LAN#2"
                    match
                        ip-protocol-num tcp
                        src-ip 192.168.0.0/24
                    exit
                    action permit
                exit
                entry 40 create
                    description "allow TCP on port 80 /HTTP access from a IP List on 
ISP LAN#1"
                    match
                        ip-protocol-num tcp
                        src-ip ip-prefix-list "AllowedLan1Hosts"
                        dst-port eq 80
                    exit
                    action permit
                exit
 
 
----------------------------------------------
*A:Dut-A>config>app-assure>group>sess-fltr$
 
 
*A:Dut-A>config>app-assure>group>policy>eqp>
   entry 110 create
    description “FW for managed opted-in subs”
       match
         traffic-direction network-to-subscriber
       exit
       action
           session-filter “ denyUnsolictedwMgntCntrl "
          fragment-drop all event-log "FW_log"
        error-drop event-log “FW_log”
       overload-drop
 
       exit
   exit
 
 
*A:Dut-A>config>app-assure>group>policy>aqp>entry# info
----------------------------------------------
                        description "FW for managed opted-in subs."
                        match
                            traffic-direction network-to-subscriber
                        exit
                        action
                            session-filter "denyUnsolictedwMgntCntrl"
                            fragment-drop all event-log "FW_log"
                            error-drop event-log “FW_log”
                            overload-drop
                         
                        exit
                        no shutdown
----------------------------------------------
*A:Dut-A>config>app-assure>group>policy>aqp>entry#

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.

CLI Syntax:
config>app-assure>group>policy# app-group application-group-name [create]
description description

The following example displays an application group configuration.

*A:ALA-48>config>app-assure>group>policy# app-group "Peer to Peer" create
*A:ALA-48>config>app-assure>group>policy>app-grp# info 
----------------------------------------------
                    description "Peer to Peer file sharing applications"
----------------------------------------------
*A:ALA-48>config>app-assure>group>policy>app-grp# 

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.

CLI Syntax:
config>app-assure>group>policy# application application-name [create]
app-group app-group-name
description description

The following example displays an application configuration.

*A:ALA-48>config>app-assure>group>policy# application "SQL" create 
*A:ALA-48>config>app-assure>group>policy>app# info
----------------------------------------------
                    description "SQL protocols"
                    app-group "Business Critical Applications"
----------------------------------------------
*A:ALA-48>config>app-assure>group>policy>app#

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.

CLI Syntax:
config>app-assure>group>policy# app-filter
entry entry-id [create]
application application-name
description description-string
expression expr-index expr-type {eq | neq} expr-string
flow-setup-direction {subscriber-to-network | network-to-subscriber | both}
http-match-all-requests
ip-protocol-num {eq | neq} protocol-id
network-address {eq | neq} ip-address
network-address {eq | neq} ip-prefix-list ip-prefix-list-name
protocol {eq | neq} protocol-signature-name
server-address {eq | neq} ip-address
server-address {eq | neq} dns-ip-cache dns-ip-cache-name
server-address {eq | neq} ip-prefix-list ip-prefix-list-name
server-port {eq | neq | gt | lt} server-port-number
server-port {eq | neq} range start-port-num end-port-num
server-port {eq} {port-num | range start-port-num end-port-num} first-packet-trusted | first-packet-validate}
no shutdown

The following example displays an application filter configuration.

*A:ALA-48>config>app-assure>group>policy>app-filter# entry 30 create
*A:ALA-48>config>app-assure>group>policy>app-filter>entry# info 
----------------------------------------------
                        description "DNS traffic to local server on expected port #53"
                        protocol eq "dns"
                        flow-setup-direction subscriber-to-network
                        ip-protocol-num eq *
                        server-address eq 192.0.2.0/32
                        server-port eq 53
                        application "DNS_Local"
                        no shutdown
----------------------------------------------
*A:ALA-48>config>app-assure>group>policy>app-filter>entry# 
 

3.3.3.8. Configuring an Application Profile

Use the following CLI syntax to configure an application profile.

CLI Syntax:
config>app-assure>group>policy# app-profile app-profile-name [create]
characteristic characteristic-name value value-name
description description-string
[no] aa-sub-suppressible
divert

The following example displays an application profile configuration.

*A:ALA-48>config>app-assure>group>policy# app-profile "Super" create 
*A:ALA-48>config>app-assure>group>policy>app-prof# info 
----------------------------------------------
                    description "Super User Application Profile"
                    divert
                    characteristic "Server" value "Prioritize"
                    characteristic "ServiceBw" value "SuperUser"
                    characteristic "Teleworker" value "Yes"
                    characteristic "VideoBoost" value "Priority"
----------------------------------------------
*A:ALA-48>config>app-assure>group>policy>app-prof# 

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:

  1. Enable the capability to suppress AA subscribers on a given SRRP group interface, typically by selecting backup SRRP group interfaces.
  2. 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:

CLI Syntax:
config>service>vprn>sub-if>grp-if# suppress-aa-sub [create]
characteristic characteristic-name value value-name
description description-string
[no] aa-sub-suppressible
divert

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:

7750>config>app-assure>group>policy# info
----------------------------------------------
                app-profile "Premium" create
                    characteristic "Parental-Control" eq "Yes"
                    divert
                exit
----------------------------------------------

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”:

7750>config>app-assure>group>policy# info
----------------------------------------------
                app-profile "1-default" create
                    divert
                    aa-sub-suppressible
                exit
----------------------------------------------

3.3.3.10. Configuring Application Service Options

Use the following CLI syntax to configure application service options.

CLI Syntax:
config>app-assure>group>policy# app-service-options
characteristic characteristic-name [create]
default-value value-name
value value-name

The following example displays an application service options configuration.

*A:ALA-48>config>app-assure>group>policy>aso# info 
----------------------------------------------
                    characteristic "Server" create
                        value "Block"
                        value "Permit"
                        value "Prioritize"
                        default-value "Block"
                    exit
                    characteristic "ServiceBw" create
                        value "Lite_128k"
                        value "Power_5M"
                        value "Reg_1M"
                        value "SuperUser"
                        default-value "Reg_1M"
                    exit
                    characteristic "Teleworker" create
                        value "No"
                        value "Yes"
                        default-value "No"
                    exit
                    characteristic "VideoBoost" create
                        value "No"
                        value "Priority"
                        default-value "No"
                    exit
----------------------------------------------
*A:ALA-48>config>app-assure>group>policy>aso# 
 

3.3.3.11. Configuring a Policer

Use the following CLI syntax to configure a policer.

CLI Syntax:
config>app-assure>group>policy# policer policer-name type type granularity granularity create
action {priority-mark | permit-deny}
adaptation-rule pir adaptation-rule
description description-string
mbs maximum burst size
rate pir-rate
tod-override tod-override-id [create]

The following example displays an Application Assurance policer configuration.

*A:ALA-48>config>app-assure>group# policer "RegDown_Policer" type dual-bucket-
bandwidth granularity subscriber create
 
*A:ALA-48>config>app-assure>group>policer# info 
----------------------------------------------
                description "Control the downstream aggregate bandwidth for Regular 
1Mbps subscribers"
                rate 1000 cir 500
                mbs 100
                cbs 50
----------------------------------------------
*A:ALA-48>config>app-assure>group>policer# 
 

3.3.3.12. Configuring an Application QoS Policy

Use the following CLI syntax to configure an application QoS policy.

CLI Syntax:
config>app-assure>group>policy# app-qos-policy
entry entry-id [create]
action
bandwidth-policer policer-name
drop
error-drop [event-log event-log-name]
flow-count-limit policer-name
flow-rate-limit policer-name
fragment-drop {all | out-of-order} [event-log event-log-name]
http-error-redirect redirect-name
mirror-source [all-inclusive] mirror-service-id
overload-drop [event-log event-log-name]
remark
dscp in-profile dscp-name out-profile dscp-name
fc fc-name
priority priority-level
url-filter url-filter-name characteristic characteristic-name
description description-string
match
aa-sub sap {eq | neq} sap-id
aa-sub esm {eq | neq} sub-ident-string
aa-sub spoke-sdp {eq | neq} sdp-id:vc-id
app-group {eq | neq} application-group-name
application {eq | neq} application-name
characteristic characteristic-name {eq} value-name
dscp {eq | neq} dscp-name
dst-ip {eq | neq} ip-address[/mask]
dst-ip {eq | neq} ip-prefix-list ip-prefix-list-name
dst-port {eq | neq} port-num
dst-port {eq | neq} range start-port-num end-port-num
src-ip {eq | neq} ip-address[/mask]
src-ip {eq | neq} ip-prefix-list ip-prefix-list-name
src-port {eq | neq} port-num
src-port {eq | neq} range start-port-num end-port-num
traffic-direction {subscriber-to-network | network-to-subscriber | both}
no shutdown

The following example displays an application QoS policy configuration.

*A:ALA-48>config>app-assure>group>policy>aqp# entry 20 create
----------------------------------------------
                        description "Limit downstream bandwidth to Reg_1M subscribers"
                        match
                            traffic-direction network-to-subscriber
                            characteristic "ServiceBw" eq "Reg_1M"
                        exit
                        action
                            bandwidth-policer "RegDown_Policer"
                        exit
                        no shutdown
----------------------------------------------
*A:ALA-48>config>app-assure>group>policy>aqp# 
 

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.

A:ALA-48>config>app-assure>group>policy>aqp# 
-------------------------------------------------------------------------------
   entry 100 create
    match
      app-group eq P2P
      characteristic aa-sub-mirror eq enabled
    exit
    action                   # mirror to an existing mirror service id
      mirror-source 100
    exit
   no shutdown
   exit
-------------------------------------------------------------------------------
A:ALA-48>config>app-assure>group>policy>aqp#

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).

A:ALA-48>config>app-assure>group>policy>aqp>entry#
-------------------------------------------------------------------------------
  entry 100 create
    match
      app-group eq P2P
      characteristic aa-sub-mirror value enabled
    exit
    action
      mirror-source all-inclusive 100
    exit
   no shutdown 
   exit
-------------------------------------------------------------------------------
A:ALA-48>config>app-assure>group>policy>aqp#

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:

  1. Create an application of interest and its related app-filter’s URL expressions. This application is typically mapped into a charging-group.
  2. 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.
  3. Configure a AQP to enable the dns-ip-cache.
  4. Optionally, configure static IP addresses matching the IP addresses of the trusted proxies.

Use the following CLI syntax to create a dns-ip-cache:

CLI Syntax:
config>app-assure>group#
dns-ip-cache dns-ip-cache-name [create]
dns-match
description <description-string>
no description
domain <domain-name> expression <expression>
no domain <domain-name>
server-address <server-address> [name <server-name>]
no server-address <server-address>
ip-cache
size <cache-size>
high-watermark <percent>
low-watermark <percent>
[no] static-address <static-ip-address>
[no] shutdown

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:

7750>config>app-assure>group# info
----------------------------------------------
dns-ip-cache "dns-ip-cache1" create
                description "DNS IP Cache #1"
                dns-match
                    domain "Sponsor#1-Domain#1" expression "*.domain1.com$"
                    domain "Sponsor#1-Domain#2" expression "*.domain2.com$"
                    server-address 10.8.4.4 name "CompanyName"
                    server-address 10.8.8.8 name "CompanyName"
                    server-address 192.168.100.11 name "OperatorX-DNS1"
                    server-address 192.168.100.12 name "OperatorX-DNS2"
                exit
                ip-cache
                    size 1000
                    high-wmark 90
                    low-wmark 80
                exit
                no shutdown
            exit
----------------------------------------------

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:

7750>config>app-assure>group>policy# info 
----------------------------------------------
                charging-group "Zero Rated" create
                    description "Zero Rated Content"
                    export-id 10
                exit
                app-group "Web" create
                exit
                application "Sponsor Content #1" create
                    description "Application#1 - Content Zero Rated"
                    app-group "Web"
                    charging-group "Zero Rated"
                exit
                app-filter
                    entry 100 create
                        expression 1 http-host eq "*.sponsor1-domain1.com$"
                        server-address eq dns-ip-cache "dns-ip-cache1"
                        application "Sponsor Content #1"
                        no shutdown
                    exit
                    entry 110 create
                        expression 1 http-host eq "*.domain2.com$"
                        server-address eq dns-ip-cache "dns-ip-cache1"
                        application "Sponsor Content #1"
                        no shutdown
                    exit
                exit
---------------------------------------------------------------------------

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:

A:7750>config>app-assure>group>policy>aqp# entry 100 create 
        match
            characteristic "dns-ip-cache" eq "yes"
        exit
        action
            action dns-ip-cache "dns-ip-cache1"
        exit
        no shutdown

3.3.3.14. Configuring an HTTP Error Redirect

Use the following CLI syntax to configure an HTTP error redirect policy:

CLI Syntax:
config>app-assure>group>
http-error-redirect redirect-name create
no http-error-redirect redirect_name
description description-string
no description
error-code error-code [custom-msg-size custom-msg-size]
no error-code error-code
http-host http-host // eg. www.demo.barefruit.com
no http-host
participant-id participant-id // 32-char string used by template 1
no participant-id
no] shutdown
template template-id // {1, 2} one for Barefruit, 2= Xerocole
no template

The following example displays an Application Assurance HTTP redirect configuration.

*A:ALA-48>config>app-assure>group# http-error-redirect "redirect-404" create
        description “redirect policy of 404 to Barefruit servers”
        error-code 404
        http-host 
          att.barefruit.com
        participant-id att-ISP
        template 1
 
 
*A:ALA-48>config>app-assure>group> http-error-redirect# redirect-404 info   
----------------------------------------------
                description "redirect policy of 404 to Barefruit servers"
                template 1
                http-host "att.barefruit.com"
                participant-id "att-ISP"
 
                error-code 404 
 
*A:ALA-48>config>app-assure>group>http-error-redirect#

3.3.3.15. Configuring HTTP Header Enrichment

Use the following CLI syntax to configure an HTTP header Enrichment policy:

CLI Syntax:
config>app-assure>group> http-enrich <http_enrich_name> [create]
[no] description <description-string>
[no] shutdown
[no] field <field_name> name <header_name>
// Where “Field name” can be:
// subscriber-ip: Header name for subscriber IP
// subscriber-id: Header name for the subscriber ID
// static-string: Header name for inserted string
// static-string-2: Header name for inserted string
//imsi: Header name for subscriber IMSI
//imsi-2: Header name for subscriber IMSI
//msisdn: Header name for subscriber MSISDN
//imei-sv: Header name for subscriber IMEI-SV
//rat-type: Radio Access technology
//pgw_ggsn-address: Header name for Packet Gateway (GGSN or UPF) IP address serving the UE
//apn: Header name for APN used by the UE
//user-location: Header name for UE location(ULI)
//billing-type: Header name for charging type
//plmn-id: Public land mobile network ID of the SGSN/MME
//timestamp: Header name for the timestamp (inserted in unix time format. For example: 1531204313)
//apn-ni: Header name for APN-NI (Network Identifier) used by the UE
//msisdn-without-cc: Header name for subscriber MSISDN without country code
//imei-hyphenated: Subscriber's IMEI with format AABBBBBB-CCCCCC-EE
//imei-hyphenated-2: Subscriber's IMEI with format AABBBBBB-CCCCCC-EE
//user-location-raw: Header for ULI in raw format <uli-type1>[+<uli-type2>]=<ULI data in hex>
//user-location-raw-2: Header for ULI in raw format <uli-type1>[+<uli-type2>]=<ULI data in hex>
//user-location-3gpp: ULI encoded as defined in 3GPP TS2.061
//static-acr: static ACR
//dynamic-acr: dynamic ACR
[no] http-enrich <http_enrich_name>

The following example displays an Application Assurance HTTP header enrichment configuration.

*A:BNG>config>app-assure>group# http-enrich enrich_example create
*A:BNG>config>app-assure>group>http-enrich$ description "enrich HTTP headers with 
subscriber IP and subscriber ID"
*A:BNG>config>app-assure>group>http-enrich$ field "static-string" name "x-string"
*A:BNG>config>app-assure>group>http-enrich$ field "static-string" static-string 
"orange"
*A:BNG>config>app-assure>group>http-enrich$ field "subscriber-id" name "x-subID"
*A:BNG>config>app-assure>group>http-enrich$ field "subscriber-id" anti-spoof
*A:BNG>config>app-assure>group>http-enrich$ field "subscriber-ip" name x-subIP
*A:BNG>config>app-assure>group>http-enrich$ field "subscriber-ip" encode type md5 key 
"secret10"
----------------------------------------------
*A:BNG>config>app-assure>group>http-enrich$ info
----------------------------------------------
                field "static-string"
                    name "x-string"
                    static-string "orange"
                exit
                field "subscriber-id"
                    name "x-subID"
                    anti-spoof
                exit
                field "subscriber-ip"
                    name "x-subIP"
                    encode type md5 key 
"bF0sZZDNT8DbZoVJHD1vrYr5mJaEggEqWbSvPhgIcPW6hym0sc08O." hash2
                exit
----------------------------------------------
*A:BNG>config>app-assure>group>http-enrich$

In addition, the following show routine displays various HTTP enrichment-related statistics:

show application-assurance group 1 http-enrich "MyTemplate"        
===============================================================================
Application Assurance Group 1 HTTP Enrichment "MyTemplate"
===============================================================================
Description   : (Not Specified)
Admin Status  : Up
AQP Referenced: No
 
-------------------------------------------------------------------------------
Name                             Field                            Enabled
                                                                  Features
-------------------------------------------------------------------------------
subscriber-ip                    MyField                          M
subscriber-id                    Sub-ID                           AC
-------------------------------------------------------------------------------
                                        A=anti-spoof,C=encode-cert,M=encode-md5,R=encode-rc4
 
----------------------------------------------------------------------
Group               Enriched                 Not Enriched
----------------------------------------------------------------------
1                   0                        0
----------------------------------------------------------------------
Total               0                        0
----------------------------------------------------------------------
===============================================================================

3.3.3.16. Configuring an HTTP Redirect Policy

Use the following CLI syntax to configure an HTTP redirect policy:

CLI Syntax:
config>app-assure>group# http-redirect redirect-name [create]
description <description-string>
no description
[no] redirect-https
[no] template <template-id >
redirect-url URL // redirect URL e.g. www.isp.com/redirect.html
no redirect-url
[no] shutdown
[no] tcp-client-reset
no http-redirect <redirect-name>

The following example displays an AA HTTP redirect configuration.

*A:ALA-48>config>app-assure>group# http-redirect "redirect1" create
   description “redirect policy for blocked http content traffic without url 
parameters”
   template 3
   redirect-url http://www.isp.com/redirect.html
   no shutdown

The following example displays an Application Assurance http-redirect configuration using macro substitution to append url parameters within the redirect url:

*A:ALA-48>config>app-assure>group# http-redirect "redirect2" create
   description "redirect policy for blocked http content traffic with url parameters"
   template 5
   redirect-url "http://www.isp.com/
redirect.html?requestedurl=$URL&subscriberid=$SUB&subscriberip=$IP&routerid=$RTRI
D&vsa=$URLPRM"
   no shutdown

The following example displays AQP entry to block all http gaming traffic (AppGroup BlockedContent) and perform redirect:

A:ALA-48>config>app-assure>group>policy>aqp>entry#
------------------------------------------------------------------------------- 
    entry 100 create
        match
            app-group eq BlockedContent
        exit 
        action
            drop
            http-redirect redirectgaming flow-type dropped-flows
        exit
    no shutdown 
    exit
------------------------------------------------------------------------------- 
A:ALA-48>config>app-assure>group>policy>aqp#

3.3.3.17. Configuring an HTTPS Policy Redirect

Use the following CLI syntax to configure an HTTPS redirect policy:

CLI Syntax:
config>app-assure>group# http-redirect redirect-name [create]
description <description-string>
no description
[no] redirect-https
redirect-url <redirect-url>
no redirect-url
[no] shutdown
[no] tcp-client-reset
template <template-id >
no template
no http-redirect <redirect-name>

The following example displays the configuration of an HTTPS redirect object to redirect traffic to the operator's portal:

A:ALA-1>config>app-assure>group# http-redirect "https-redirect-portal" create
    description "simple https redirect policy"
    redirect-url https://www.portal.com/info.html
    redirect-https
    no shutdown

After creating the HTTP Redirect object, an AQP is used to configure the traffic to be redirected:

A:ALA-1>config>app-assure>group>policy>aqp>entry#
--------------------------------------------------------------
   entry 100 create
      match
         application eq BlockedHTTPS_page
      exit
      action
         drop
         http-redirect https-redirect-portal flow-type dropped-flows
      exit
   no shutdown
   exit
--------------------------------------------------------------

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:

  1. 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.
  2. 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.
  3. 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:

CLI Syntax:
config>app-assure>group# http-redirect <redirect-name> [create]
captive-redirect
vlan-id <service-port-vlan-id>
no vlan-id
description <description-string>
no description
[no] redirect-https
redirect-url <redirect-url>
no redirect-url
[no] shutdown
[no] tcp-client-reset
template <template-id>
no template
no http-redirect <redirect-name>

The following example displays a typical configuration for a session filter user in the context of captive redirect:

A:7750# configure application-assurance group 1:1 create 
A:7750>config>app-assure>group# info 
----------------------------------------------
            session-filter "wifi-unauthenticated" create
                default-action deny
                entry 5 create
                    match
                        ip-protocol-num udp
                        dst-port eq 53
                    exit
                    action permit
                exit
                entry 10 create
                    match
                        dst-ip dns-ip-cache "whitelist"
                    exit
                    action permit
                exit
                entry 15 create
                    description "Allow traffic to the redirect landing page server"
                    match
                        ip-protocol-num tcp
                        dst-port eq 80
                        dst-ip 172.16.70.100/32
                    exit
                    action permit
                exit
                entry 20 create
                    match
                        ip-protocol-num tcp
                    exit
                    action http-redirect "redirect-portal"
                exit
            exit
----------------------------------------------

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):

A:7750# configure service ies 1 customer 1 create 
A:7750>config>service>ies# info 
----------------------------------------------
            aa-interface "aa-if-captive-redirect-isa_1-2" create
                description "AA Interface for ISA-AA card 1/2"
                address 172.16.3.1/31
                sap 1/2/aa-svc:20 create
                    no shutdown
                exit
                no shutdown
            exit
----------------------------------------------

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):

A:7750# configure application-assurance group 1 
A:7750>config>app-assure>group>http-redir# info 
----------------------------------------------
                template 5
                tcp-client-reset
                redirect-https
                redirect-url "http://172.16.70.100/Redirect/redirect-
portal.html?RequestedURL=$URL"
                captive-redirect
                    vlan-id 20
          exit
                no shutdown
----------------------------------------------

3.3.3.19. Configuring ICAP URL Filtering

To configure the system for ICAP URL filtering, the operator needs to.

  1. 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.
  2. Create an HTTP redirect policy (used by the URL filter to redirect HTTP or HTTPS traffic).
  3. Create a URL filter, configure the ICAP server IP address, redirect policy, and default action.
  4. 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:

CLI Syntax:
config>service>vprn# aa-interface <aa-if-name> [create]
config>service>vprn>aa-if# aa-interface interface <ip-int-name> [create]
description <description-string>
no description
address <ipv4_subnet/31>
no address
sap <card/mda/aa-svc:vlan> [create]
description <description-string>
no description
egress
[no] filter
[no] qos
exit
ingress
[no] qos
exit
[no] shutdown
exit

The following example displays an AA interface created for the ISA card 1/2 using IP address 172.16.2.1/31:

A:7750>config>service>ies# info 
----------------------------------------------
            aa-interface "aa-if1" create
                address 172.16.2.1/31
                sap 1/2/aa-svc:10 create
                    egress
                        filter ip 10
                    exit
                    no shutdown
                exit
                no shutdown
            exit

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:

  1. 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.
  2. 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:

CLI Syntax:
config>app-assure>group#
url-filter <url-filter-name> [create]
default-action {allow | block-all | block-http-redirect <redirect-name>}
no default-action
http-redirect <http-redirect-name>
no http-redirect
http-request-filtering {all | first}
no apply-function-specific-behavior
icap
custom-x-header <x-header-name>
[no] custom-x-header
vlan-id <service-port-vlan-id>
no vlan-id
default-action {allow | block-all | block-http-redirect <redirect-name>}
no default-action
http-redirect <http-redirect-name>no http-redirect
server <ip-address[:port]> [create]
description <description-string>
no description
[no] shutdown
no server <ip-address[:port]>
no url-filter <url-filter-name>

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:

*A:7750>config>app-assure>group# url-filter "filter1" create
   apply-function-specific-behavior
   icap
      vlan-id 10
      default-action block-http-redirect "http-redirect-portal"
      server 172.16.1.101 create
        no shutdown
      exit
   exit
   no shutdown

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:

A:7750>config>app-assure>group>policy>aqp# entry 100 create 
        match
            characteristic "url-filter" eq "yes"
        exit
        action
            url-filter "filter1"
        exit
        no shutdown

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:

A:7750>config>app-assure>group# url-filter "filter1" create
  apply-function-specific-behavior
  icap
    default-action block-http-redirect "http-redirect-portal"
    http-redirect "http-redirect-portal"
    custom-x-header "Filtering-Policy"
    vlan-id 10
    server 172.16.1.101 create
      no shutdown
    exit
  exit
  no shutdown

The following example displays the ASO characteristic used to define the type of filtering policy available:

A:7750>config>app-assure>group>policy>aso# info 
----------------------------------------------
                    characteristic "url-filter-policy" create
                        value "filtering-policy-1"  #less than 10 years old
                        value "filtering-policy-2"  # less than 16 years old
                        value "example1"
                        value "none"
                        value "example2"
                        default-value "none"
                    exit
----------------------------------------------

The following example displays the AQP action required to add the appropriate ASO value to the ICAP custom-x-header field:

A:7750>config>app-assure>group>policy>aqp# entry 100 create
        match
            characteristic "url-filter" eq "yes"
        exit
        action
            url-filter "filter1" characteristic "url-filter-policy"
        exit
        no shutdown

3.3.3.20. Configuring Web-service URL Classification

The following example describes how to configure web-service URL classification.

  1. 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.
  2. 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" create
    description "Redirect for Web Service URL Filtering"
    template 5
    tcp-client-reset
    redirect-https
    redirect-url "http://10.154.90.1/
    redirect.html?catname=$CATNAME&catid=$CATID"
    no shutdown
    exit
    ---------------------------------------------
  3. Configure the URL filter and category profiles.
    The operator defines a new URL filter with the following attributes:
    1. classifier = "web-service-1"
      defines the URL categorization database to use
    2. category-set-id = 1
      defines the URL categories to use
    3. fqdn = nokia-api.webtitancloud.com
      defines the URL categorization database endpoint that the AA connects to
    4. dns-server
      defines the DNS server to resolve the FQDN
    5. profile
      defines up to eight profile names
    6. category
      defines 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-behavior
    web-service
    classifier web-service-1 category-set-id 1
    vlan-id 100
    default-action block-http-redirect "redirect-ws-filter"
    http-redirect "redirect-ws-filter"
    fqdn nokia-api.webtitancloud.com
    dns-server 8.8.8.8
    classification-overrides
    entry 1 expression www.site1.abc category "Phishing/Fraud"
    entry 2 expression www.site2.def category "Illegal Drugs"
    profile low create
    category "Internet Watch Foundation List" block
    category "Spyware And Malicious Sites" block
    category "Phishing/Fraud" block
    profile medium create
    category "Internet Watch Foundation List" block
    category "Spyware And Malicious Sites" block
    category "Phishing/Fraud" block
    category "Illegal Drugs" block
    category "Violence" block
    category "Weapons" block
    profile high create
    category "Internet Watch Foundation List" block
    category "Spyware And Malicious Sites" block
    category "Phishing/Fraud" block
    category "Illegal Drugs" block
    category "Violence" block
    category "Weapons" block
    category "Nudity" block
    category "Alcohol" block
    category "Criminal Skills/Hacking" block
    category "Hate Speech" block
    default-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.
  4. 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" create
    value "high"
    value "medium"
    value "low"
    default-value "low"
    exit
    ----------------------------------------------
  5. 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 create
    action
    url-filter "ws-filter" characteristic "url-filter-policy"
    exit
    no shutdown
    In 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:

  1. Create a URL-list policy referencing a valid file located on the compact flash
  2. Create a url-filter policy for local-filtering by referencing this URL-list
  3. Create an AQP to apply this url-filter policy

Use the following CLI syntax to create a URL-list:

CLI Syntax:
config>app-assure>group# url-list <url-list-name> [create]
description <description-string>
no description
decrypt-key <key | hash-key | hash2-key> [hash | hash2 |custom]
no decrypt-key
file <file-url>
no file
[no] shutdown
size <url-list-size>
[no] expression-match
[standard | extended] - Default : standard

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:

  1. head anchors character set [^ *]
  2. tail anchors character set [$ *]
  3. mid expression character set [\d \I \. \**]
  4. 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:

Linux# openssl des3 -nosalt -in <input-file.txt> -out <output.enc>
 

The following example displays a URL list configuration:

A:7750>config>app-assure>group# url-list url-list1 create
----------------------------------------------
                description "Local List for URL Filtering"
                decrypt-key ".i84/P1uS0lMGoQkae7mAV2Oj10n726Z" hash2
                file "cf3:\url-list1.enc"
                no shutdown
----------------------------------------------
 

Use the following CLI syntax to create a url-filter policy for local-filtering:

CLI Syntax:
config>app-assure>group# url-filter <url-filter-name> [create]
url-filter <url-filter-name> [create]
description <description-string>
no description
default-action {allow | block-all | block-http-redirect <redirect-name>}
no default-action
[no] http-redirect <redirect-name>
http-request-filtering {all | first}
[no] apply-function-specific-behavior
local-filtering
deny-list <url-list-name>
default-action {allow | block-all | block-http-redirect <redirect-name>}
no default-action
[no] http-redirect <redirect-name>
[no] allow-list <url-list-name>
[no] shutdown

The following example displays a deny-list URL filter configured for local-filtering:

A:7750>config>app-assure>group# url-filter "url-denylist1" create
A:7750>config>app-assure>group>url-filter# info
----------------------------------------------
apply-function-specific-behavior
local-filtering
  default-action allow
  http-redirect "http-redirect-portal"
  deny-list "url-list1"
exit
no shutdown
----------------------------------------------

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:

A:7750>config>app-assure>group>policy>aqp# entry 100 create 
        match
            characteristic "child-protection" eq "yes"
        exit
        action
            url-filter "url-blacklist1"
        exit
        no shutdown

3.3.3.22. Configuring HTTP Notification

Use the following CLI syntax to configure an HTTP Notification policy.

CLI Syntax:
config>app-assure>group#
http-notification <http-notification-name> [create]
description <description-string>
no description
script-url <script-url-name>
no script-url
interval {one-time | <minimum-interval>}
template <template-id>
no template
[no] shutdown
no http-notification <http-notification-name>

The following example displays an HTTP notification policy configured with a minimum interval of 5 minutes:

A:7750>config>app-assure>group# http-notification "in-browser-notification" create 
A:7750>config>app-assure>group>http-notif# info 
----------------------------------------------
                description "In Browser Notification Example"
                template 1
                script-url "http://10.1.1.1/In-Browser-Notification/script.js"
                interval 5
                no shutdown
----------------------------------------------

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.

A:7750>config>app-assure>group>policy# application "IBN Messaging Server" create
A:7750>config>app-assure>group>policy>app$ app-group "Web"
 
A:7750>config>app-assure>group>policy# app-filter entry 100 create
A:7750>config>app-assure>group>policy>app-filter>entry$ info
----------------------------------------------
                        expression 1 http-host eq "^10.1.1.1$"
                        http-match-all-req
                        application "IBN Messaging Server"
                        no shutdown
----------------------------------------------

The following examples displays the AQP entry required to match this policy based on an ASO characteristic:

A:7750>config>app-assure>group>policy>aqp# info 
----------------------------------------------
                    entry 200 create
                        match
                            characteristic "in-browser-notification" eq "yes"
                        exit
                        action
                            http-notification "in-browser-notification"
                        exit
                        no shutdown
                    exit
----------------------------------------------

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:

CLI Syntax:
configure application-assurance group group-number tethering-detection no shutdown
CLI Syntax:
configure application-assurance group group-number policy
begin
app-qos-policy entry match aa-sub-tethering-state {detected | not-detected}
commit
exit

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).

CLI Syntax:
config>app-assure>group>statistics>app-group
accounting-policy act-policy-id
collect-stats
CLI Syntax:
config>app-assure>group>statistics>application
accounting-policy act-policy-id
collect-stats
CLI Syntax:
config>app-assure>group>statistics>protocol
accounting-policy act-policy-id
collect-stats

The following commands illustrate the configuration of statistics collection and accounting policy for each AA subscriber in the system.

CLI Syntax:
config>app-assure>group>statistics>aa-sub
accounting-policy acct-policy-id
aggregate-stats
app-group app-group-name export-using export-method [export-method]
application application-name export-using export-method [export-method]
charging-group charging-group-name export-using export-method [export-method]
collect-stats
exclude-tcp-retrans
max-throughput-stats
protocol protocol-name export-using export-method
radius-accounting-policy rad-acct-plcy-name

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.

CLI Syntax:
config>app-assure>group>statistics# aa-sub-study {application | protocol}
accounting-policy acct-policy-id
collect-stats

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:

*A:ALU-40>config>app-assure>group>statistics>aa-sub# info 
----------------------------------------------
                    accounting-policy 4
                    collect-stats
                    app-group "File Transfer"
                    app-group "Infrastructure"
                    app-group "Instant Messaging"
                    app-group "Local Content"
                    app-group "Mail"
                    app-group "MultiMedia"
                    app-group "Business_Critical
                    app-group "Peer to Peer"
                    app-group "Premium Partner"
                    app-group "Remote Connectivity"
                    app-group "Tunneling"
                    app-group "Unknown"
                    app-group "VoIP" 
                    app-group "Web"
                    app-group "Intranet"
                    application "BitTorrent"
                    application "eLearning"
                    application "GRE"
                    application "H323"
                    application "TLS"
                    application "HTTP"
                    application "HTTPS"
                    application "HTTPS_Server"
                    application "HTTP_Audio"
                    application "HTTP_Video"
                    application "eMail_Business"
                    application "eMail_Other"
                    application "Oracle"
                    application "Skype"
                    application "SAP"
                    application "SIP"
                    application "SMTP"
                    application "SQL_Alltypes"
                    application "TFTP"
                    protocol "bittorrent"
                    protocol "dns"
                    protocol "sap"
                    protocol "skype"
----------------------------------------------
*A:ALU-40>config>app-assure>group>statistics>aa-sub#

3.3.4.1. Configuring Cflowd Collector

The following output displays an Application Assurance cflowd collector configuration example:

Example:
*A:ALA-48# configure application-assurance group 1 cflowd collector 192.168.131.149:55000 create
*A:ALA-48>config>app-assure>group>cflowd>collector$description
"cflowd_collector_NewYork"
*A:ALA-48>config>app-assure>group>cflowd>collector# no shutdown
*A:ALA-48>config>app-assure>group>cflowd>collector# exit
*A:ALA-48>config>app-assure>group>cflowd# info
----------------------------------------------
    collector 192.168.131.149:55000 create
         description "cflowd_collector_NewYork"
    no shutdown
---------------------------------------------- 
*A:ALA-48>config>app-assure>group>cflowd# 

The following commands show the configuration of an AA cflowd collector.

CLI Syntax:
config>application-assurance>group isa-aa-group-id cflowd
collector <ip-address[:port]> [create]
no collector <ip-address[:port]>
[no] description - Configure description for this cflowd collector
[no] shutdown - Administratively enable/disable this cflowd collector
direct-export
collector <collector-id> [create]
no collector <collector-id>
[no] address + Configure cflowd direct export collector remote address
[no] description - Configure description for this cflowd direct export

The following output displays an AA direct export cflowd collector configuration example.

Example:

*A:Dut-C>config>app-assure>group>cflowd# direct-export vlan-id 300 
*A:Dut-C>config>app-assure>group>cflowd# direct-export collector 1 create
*A:Dut-C>config>app-assure>group>cflowd>dir-exp-coll$ description "direct export to collector in Toronto/CA"
*A:Dut-C>config>app-assure>group>cflowd>dir-exp-coll$ address 10.10.1.1:55000
*A:Dut-C>config>app-assure>group>cflowd>dir-exp-coll>addr$ no shutdown
*A:Dut-C>config>app-assure>group>cflowd>dir-exp-coll>addr$ exit
*A:Dut-C>config>app-assure>group>cflowd>dir-exp-coll$ exit
*A:Dut-C>config>app-assure>group>cflowd# no shutdown
*A:Dut-C>config>app-assure>group>cflowd# info
----------------------------------------------
                no shutdown
                direct-export
                    vlan-id 300
                    collector 1 create
                        address 10.10.1.1:55000
                            no shutdown
                        exit
                        description "direct export to collector in Toronto/CA"
                    exit
                exit
----------------------------------------------
*A:Dut-C>config>app-assure>group>cflowd#
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.

CLI Syntax:
config>application-assurance>group isa-aa-group-id cflowd comprehensive
[no] flow-rate - Configure cflowd comprehensive flow sample rate
[no] flow-rate2 - Configure secondary cflowd comprehensive flow sample rate
[no] shutdown - Administratively enable/disable comprehensive sampling
          template + Configure comprehensive template|
[no] dynamic-fields + Configure the list of dynamic fields
[no] field <field-name> - Configure a dynamic field
[no] shutdown - Administratively enable/disable comprehensive template
              [no] field-selection <field-selection>     Configure the field selection : legacy|dynamic

The following commands show the configuration of AA RTP performance reporting.

CLI Syntax:
config>application-assurance>group isa-aa-group-id cflowd rtp-performance
[no] flow-rate - Configure cflowd RTP performance flow sample rate
[no] flow-rate2 - Configure secondary cflowd RTP performance flow sample rate
[no] shutdown - Administratively enable/disable RTP performance sampling
   audio-template + Configure rtp performance audio fields template
[no] dynamic-fields + Configure the list of dynamic fields
[no] field <field-name> - Configure a dynamic field
[no] shutdown - Administratively enable/disable audio template
[no] field-selection <field-selection> Configure the field selection : legacy|dynamic
   video-template + Configure rtp performance video fields template
[no] dynamic-fields + Configure the list of dynamic fields
[no] field <field-name> - Configure a dynamic field
[no] shutdown - Administratively enable/disable video template
[no] field-selection <field-selection> Configure the field selection : legacy|dynamic
   voice-template + Configure rtp performance voice template
[no] dynamic-fields + Configure the list of dynamic fields
[no] field <field-name> - Configure a dynamic field
[no] shutdown - Administratively enable/disable voice template
[no] field-selection <field-selection> Configure the field selection : legacy|dynamic

The following commands show the configuration of AA TCP performance reporting.

CLI Syntax:
config>application-assurance>group isa-aa-group-id cflowd tcp-performance
[no] flow-rate - Configure cflowd TCP performance flow sample rate
[no] flow-rate2 - Configure secondary cflowd TCP performance flow sample rate
[no] shutdown - Administratively enable/disable TCP Performance sampling
   template + Configure tcp performance fields template
[no] dynamic-fields + Configure the list of dynamic fields
[no] field <field-name> - Configure a dynamic field
[no] shutdown - Administratively enable/disable tcp-performance template
[no] field-selection <field-selection> Configure the field selection : legacy|dynamic

The following commands show the configuration of AA volume reporting.

CLI Syntax:
config>application-assurance>group isa-aa-group-id cflowd volume
[no] rate - Configure cflowd volume sampling rate
[no] shutdown - Administratively enable/disable volume sampling
  template + Configure volume template
[no] dynamic-fields + Configure the list of dynamic fields
[no] field <field-name> - Configure a dynamic field
[no] shutdown - Administratively enable/disable volume template
[no] field-selection <field-selection> Configure the field selection : legacy|dynamic

The following commands show the configuration of AA comprehensive, RTP performance, TCP performance, and volume reporting.

CLI Syntax:
config>application-assurance group isa-aa-group-id[:partition [create]]
*A:Dut-C>config>app-assure>group>cflowd#
   comprehensive + Configure cflowd comprehensive export
[no] app-group app-group-name [flow-rate | flow-rate2]
[no] application application-name [flow-rate | flowrate2]
[no] shutdown - Administratively enable/disable comprehensive sampling
      
   rtp-performance + Configure cflowd RTP performance export
[no] app-group app-group-name [flow-rate | flow-rate2]
[no] application application-name [flow-rate | flowrate2]
[no] shutdown - Administratively enable/disable RTP performance sampling
   tcp-performance + Configure cflowd TCP performance export
[no] app-group app-group-name [flow-rate | flow-rate2]
[no] application application-name [flow-rate | flowrate2]
[no] shutdown - Administratively enable/disable TCP performance sampling
   volume + Configure cflowd volume export
[no] shutdown - Administratively enable/disable volume sampling

The following example shows a configuration that includes the following:

  1. Enables per-flow volume statistics for group 1, partition 1 and configures sampling rate to 1/1000.
  2. Enables per-flow TCP performance statistics for web_traffic application within group 1, partition 1 and configures TCP sampling rate to 1/500.
  3. Enables per-flow TCP performance statistics for citrix_traffic application within group 1, partition 1 using TCP sampling rate2 to 1/100.
  4. 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.
  5. Enables per-flow comprehensive statistics for web_traffic.

Example:

*A:ALA-4# configure application-assurance group 1 cflowd
*A:ALA-4>config>app-assure>group>cflowd# volume rate 1000
*A:ALA-4>config>app-assure>group>cflowd# tcp-performance flow-rate 500
*A:ALA-4>config>app-assure>group>cflowd# tcp-performance flow-rate2 100
*A:ALA-4>config>app-assure>group>cflowd# comprehensive flow-rate 5
*A:ALA-4>config>app-assure>group>cflowd# rtp-performance flow-rate 10
*A:ALA-4>config>app-assure>group>cflowd# comprehensive flow-rate 5
*A:ALA-4>config>app-assure>group>cflowd# no shutdown
*A:Dut-C>config>app-assure>group>cflowd# info
----------------------------------------------
                shutdown
                direct-export
                    vlan-id 300
                    collector 1 create
                        address 10.10.1.1:55000
                            shutdown
                        exit
                        description "direct export to collector in Toronto/CA"
                    exit
                exit
                volume
                    rate 1000
                exit
                rtp-performance
                    flow-rate 10
                    flow-rate2 5
                exit
                tcp-performance
                    flow-rate 500
                    flow-rate2 100
                exit
----------------------------------------------
*A:Dut-C>config>app-assure>group>cflowd#
 
----------------------------------------------
*A:ALA-48>config>app-assure>group>cflowd#
*A:ALA-4# configure application-assurance group 1:1 cflowd
*A:ALA-4>config>app-assure>group>cflowd#
*A:ALA-4>config>app-assure>group>cflowd# volume no shutdown
*A:ALA-4>config>app-assure>group>cflowd# tcp-performance application "web_traffic"
*A:ALA-4>config>app-assure>group>cflowd# tcp-performance application "citrix" flow-rate2
*A:ALA-4>config>app-assure>group>cflowd# tcp-performance no shutdown
*A:ALA-4>config>app-assure>group>cflowd# rtp-performance application "voip_traffic"
*A:ALA-4>config>app-assure>group>cflowd# rtp-performance no shutdown
*A:ALA-4>config>app-assure>group>cflowd# info
----------------------------------------------
 
----------------------------------------------
volume
    no shutdown 
exit
rtp-performance 
    no shutdown
       application "voip_traffic"
exit
tcp-performance
    no shutdown
       application "web_traffic"
       application "citrix" flow-rate2
exit
----------------------------------------------
*A:ALA-4>config>app-assure>group>cflowd#

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:

CLI Syntax:
config>application-assurance>group isa-aa-group-id cflowd volume
template + Configure volume template
[no] dynamic-fields + Configure the list of dynamic fields
[no] field-selection <field-selection> Configure the field selection : legacy|dynamic

The following is an example of the dynamic option selected.

Example:

*A:Dut-C>config>app-assure>group>cflowd>volume# template
*A:Dut-C>config>app-assure>group>cflowd>volume>template# field-selection dynamic
*A:Dut-C>config>app-assure>group>cflowd>volume>template# dynamic-fields
*A:Dut-C>config>app-assure>group>cflowd>volume>template>dynamic-fields# field "hostName"
*A:Dut-C>config>app-assure>group>cflowd>volume>template>dynamic-fields# field "aaApp"
*A:Dut-C>config>app-assure>group>cflowd>volume>template>dynamic-fields# field"aaAppGrp"
*A:Dut-C>config>app-assure>group>cflowd>volume>template>dynamic-fields# exit    
*A:Dut-C>config>app-assure>group>cflowd>volume>template# info
----------------------------------------------
                        field-selection dynamic
                        dynamic-fields
                            shutdown
                            field "aaApp"
                            field "aaAppGrp"
                            field "hostName"
                        exit
----------------------------------------------
*A:Dut-C>config>app-assure>group>cflowd>volume>template#