ACS Rulebase Configuration
Mode Commands
The ACS Rulebase
Configuration Mode is used to configure Active Charging Service
(ACS) rulebases.
IMPORTANT:
The commands or keywords/variables
that are available are dependent on platform type, product version,
and installed license(s).
action priority
This command allows you
to configure the action priority for a ruledef / group-of-ruledefs
in the current rulebase.
Privilege:
Security Administrator,
Administrator
Syntax
action priority action_priority { [ dynamic-only | static-and-dynamic | timedef timedef_name ] { group-of-ruledefs ruledefs_group_name | ruledef ruledef_name } charging-action charging_action_name [ monitoring-key monitoring_key ] [ description description ] }
no action priority action_priority
no
If previously configured,
deletes the specified action priority configuration from the current rulebase.
priority action_priority
Specifies a priority
for the specified ruledef / group-of-ruledefs in the current
rulebase.
action_priority must
be unique in the current rulebase, and must be an integer from 1
through 65535.
The priority controls
the order in which this instance of the CLI command will be examined. Lower
numbered priorities are examined first. Up to 2048 instances may
be configured, totaled among all rulebases.
dynamic-only
Enables matching of dynamic
rules with static rules for this action priority on a flow.
Configuring the dynamic-only keyword
causes the configuration to be defined, but not enabled. If enabled,
the action associated with this option will not be matched against
a flow until it is enabled from a dynamic charging interface like
Gx. Gx can disable or enable this action entry in the rulebase using
Gx messages.
Default: Disabled
static-and-dynamic
The static-and-dynamic
option causes the configuration to be defined and enabled, and allows
a dynamic protocol (such as the Gx interface) to disable or re-enable
the configuration.
Default: Enabled
IMPORTANT:
When R7 Gx is enabled, “static-and-dynamic” rules
behave exactly like “dynamic-only” rules. That
is, they must be activated explicitly by the Policy and Charging
Rules Function (PCRF). When Gx is not enabled, “static-and-dynamic” rules
behave exactly like static rules.
timedef timedef_name
IMPORTANT:
This keyword is only
available in StarOS 8.1
and
StarOS 9.0 and later releases.
Associates the specified
time definition with the ruledef / group-of-ruledefs.
Timedefs activate or deactivate ruledefs / groups-of-ruledefs,
making them available for rule matching only when they are active.
timedef_name must
be the name of a timedef, and must be an alphanumeric string of
1 through 63 characters.
A timedef can be used
with several ruledefs / group-of-ruledefs.
When a packet is received, and a ruledef / group-of-ruledefs
is eligible for rule matching, if a timedef is associated with the ruledef / group-of-ruledefs,
before rule matching the packet-arrival time is compared with the timeslots
configured in the timedef. If the packet arrived in any of the timeslots
configured in the associated timedef, rule matching is undertaken,
else the next ruledef / group-of-ruledefs
is considered.
IMPORTANT:
The time considered for
timedef matching is the system’s local time.
ruledef ruledef_name
Adds the specified ruledef
to the current rulebase.
ruledef_name must
be the name of a ruledef, and must be an alphanumeric string of
1 through 63 characters.
If the specified ruledef
does not exist, there will be no ruledef triggers for this action
priority within the current rulebase.
IMPORTANT:
If the ruledef specified
here is deleted or is not configured, the system accepts it without applying
any ruledef under current rulebase for this action priority.
group-of-ruledefs ruledefs_group_name
Adds the specified group-of-ruledefs
to the current rulebase.
ruledefs_group_name must
be the name of a group-of-ruledefs, and must be an alphanumeric
string of 1 through 63 characters.
When a group-of-ruledefs
is specified, if any of the ruledefs within the group matches, the specified
charging-action is applied, any more of the action instances are
not processed.
IMPORTANT:
If the group-of-ruledefs
specified here is deleted or is not configured, the system accepts
it without applying any ruledefs under current rulebase for this
action priority.
charging-action charging_action_name
Specifies the charging
action.
charging_action_name must
be the name of a charging action, and must be an alphanumeric string
of 1 through 63 characters.
If the specified charging
action does not exist, there will be no charging action triggers
for this action priority within the current rulebase.
IMPORTANT:
If the charging action
specified here is not configured or is later deleted, the system
will not apply any charging action under current rulebase for this
action priority.
monitoring-key monitoring_key
Associates the specified
monitoring-key with ruledefs for usage monitoring.
monitoring_key must
be an integer from 1 through 4000000000.
description description
Adds specified text to
the rule and action.
description must
be an alphanumeric string of 1 through 63 characters.
Usage:
Use this command to configure
action priorities for ruledefs / group-of-ruledefs in a rulebase.
This CLI command can
be entered multiple times to specify multiple ruledefs and charging
actions. The ruledefs are examined in priority order, until a match
is found and the corresponding charging action is applied.
Example:
The following command
assigns a rule and action with the action priority of
23, a ruledef
named
test,
and a charging action named
test1 to the
current rulebase:
action priority 23 ruledef
test charging-action test1
bandwidth default-policy
This command allows you
to configure the default bandwidth policy for the current rulebase.
Privilege:
Security Administrator,
Administrator
Syntax
bandwidth default-policy bandwidth_policy_name
no bandwidth default-policy
no
If previously configured,
deletes the bandwidth default-policy configuration from the current
rulebase.
bandwidth_policy_name
Specifies the default
bandwidth policy for the current rulebase.
bandwidth_policy_name must
be the name of a bandwidth policy, and must be an alphanumeric string
of 1 through 63 characters.
Usage:
Use this command to
configure the default bandwidth policy for a rulebase.
For subscribers using
the current rulebase, the default bandwidth policy will be used
if in the APN/subscriber profile the default active-charging
bandwidth-policy command is configured, or no bandwidth
policy is configured.
Example:
The following command
configures a bandwidth policy named
standard for
the rulebase:
bandwidth default-policy standard
billing-records
This command allows
you to configure the type of billing to be performed for subscriber
sessions.
Privilege:
Security Administrator,
Administrator
Syntax
billing-records { egcdr | radius | rf | udr udr-format udr_format_name [ failure-handling-udr-format udr_format_name ] } +
no billing-records
no
If previously configured,
deletes the billing-records configuration from the current rulebase.
egcdr
Generates an enhanced
G-CDR (eG-CDR) for GGSN / P-GW-CDR for P-GW, and/or
UDR with specified format on the occurrence of an interim trigger
condition at the end of a subscriber session, or an SGSN-to-SGSN
handoff.
radius
Generates postpaid RADIUS
accounting records at the start and end of a subscriber session, and
on the occurrence of an interim trigger condition. RADIUS accounting
records are generated for each content ID.
IMPORTANT:
In the GGSN, if in the
APN configuration the “accounting-mode” is set
to “none”, the system continues to send ACS-generated
RADIUS accounting messages. In the PDSN, if in the subscriber
default configuration the “accounting-mode” is
set to “none”, the system does not send any RADIUS
accounting messages (including ACS accounting messages).
rf
Enables Rf accounting.
Rf accounting is applicable
only for dynamic and predefined rules that are marked for it. Dynamic
rules have a field offline-enabled to indicate this. To mark a predefined
rule as offline-enabled, use this keyword and the billing-action command
in the ACS Charging Action Configuration Mode.
udr udr-format udr_format_name
Generates UDRs with
specified the format on the occurrence of an interim trigger condition, at
the end of a subscriber session, or a handoff.
udr_format_name must
be the name of an UDR format, and must be an alphanumeric string
of 1 through 63 characters.
+
Indicates that more
than one of the keywords can be entered in a single command.
Usage:
Use this command to
generate
enhanced G-CDRs (eG-CDRs), P-GW-CDR for P-GW,
RADIUS CDRs and/or UDRs for billing records. The format
of eG-CDRs for the default GTPP group is controlled by the
inspector command
in the Context Configuration Mode.
If, in the APN configuration,
the “accounting-mode” is set as default (GTPP),
and in the rulebase configuration “billing-records egcdr” is
configured, both G-CDRs and eG-CDRs are generated if configured.
If, in the APN, the accounting-mode is set to “none” G-CDRs
will not be generated.
Example:
The following command
sets the billing record to UDR with UDR format named
udr_format1:
billing-records udr
udr-format udr_format1
cca diameter requested-service-unit
This command allows
you to specify the Diameter sub-AVPs to be included in the Diameter
group AVP “Requested-Service-Unit” sent with DCCA
Credit Control Requests (CCRs).
Privilege:
Security Administrator,
Administrator
Syntax
cca diameter requested-service-unit
sub-avp { time cc-time duration | units cc-service-specific-units charging_unit | volume { cc-input-octets bytes | cc-output-octets bytes | cc-total-octets bytes } + }
no cca diameter requested-service-unit
sub-avp
no
No sub-AVPs are included
in the Requested-Service-Unit grouped AVP.
time cc-time duration
Specifies requested
service unit for charging time duration in seconds in included sub-AVP.
duration specifies
charging time in seconds, and must be an integer from 1 through
4000000000.
units cc-service-specific-units charging_unit
Specifies requested
service unit by service specific units in bytes/packets
in included sub-AVP.
charging_unit specifies
service-specific charging unit and must be an integer from 1 through
4000000000.
volume { cc-input-octets bytes | cc-output-octets bytes | cc-total-octets bytes } +
Specifies requested
service unit for charging octets by input, output, and total volume
in included sub AVP.
- cc-input-octets:
Specifies input charging octets.
- cc-output-octets:
Specifies output charging octets.
- cc-total-octets:
Specifies total charging octets.
- bytes: Specifies
volume in bytes and must be an integer from 1 through 4000000000.
+:
Indicates that more than one of the previous keywords can be entered
within a single command.
Usage:
Use this command to
include sub-AVPs based on time, volume, and service specific unit in
the “Requested-Service-Unit” grouped AVP with
CCRs through Gy interface.
Example:
The following command
sets the time based sub-AVP with charging duration of 45 seconds in “Requested-Service-Unit” group
AVP on DCCA CCRs:
cca diameter requested-service-unit
sub-avp time cc-time 45
cca quota
This command allows
you to configure various time- and threshold-based quotas in the
Prepaid Credit Control Service (Credit Control Application).
Privilege:
Security Administrator,
Administrator
Syntax
cca quota { holding-time holding_time content-id content_id | retry-time retry_time [ max-retries retries ] }
{ default | no } cca
quota { holding-time content-id content_id | retry-time }
holding-time holding_time
Specifies the value
for the Quota Holding Time (QHT). QHT is used with both time-based and
volume-based quotas. After holding_time seconds
has passed without user traffic, the quota is reported back and
the charging stops until new traffic starts.
holding_time must
be an integer from 1 through 4000000000.
content-id content_id
Specifies the content
ID (Rating group AVP) to use for the Quota holding time for the current
rulebase.
content_id is
the content ID specified for credit control service in ACS.
In 12.1 and earlier
releases, content_id must
be an integer from 1 through 65535.
retry-time retry_time [ max-retries retries ]
Specifies the retry
time for the quota request, in seconds.
retry_time must
be an integer from 0 through 86400. To disable this assign 0.
Default: 60
This parameter defines
the maximum frequency at which the Credit-Control Application (CCA)
tries to obtain quota for a subscriber passing traffic for a category
with no/exhausted quota.
For a subscriber not
passing traffic, the CCA will not try to obtain quota (except once
at session start time, if so configured). The quota request from
the no quota state is sent in response to user packets only (never
based on a timer).
When subscriber hits
a charging action that is a flow redirect, the operator can optionally specify
that this redirection shall clear the retry-time timer.
This allows the immediately
following chargeable user traffic to trip a quota request, even
if it would otherwise have been subject to the retry time limit.
Such configuration allows quite a large value for retry-time in
quota charging or a top-up scenario.
max-retries retries configures
the maximum number of retries allowed for blacklisted categories.
This option has a default value of 65535 retries (the maximum value).
retries must
be an integer from 1 through 65535. To disable this assign 0.
Usage:
Use this command to
set the prepaid credit control quotas.
cca quota retry time allows
an operator to set the amount of time that the ACS waits before
it retries the prepaid server for a content ID for which quota was
exhausted earlier.
When the server sends
the quota holding time (QHT) it has highest priority to use that QHT
regardless of the value configured in the rulebase or Credit Control
Application Configuration Mode. QHT configured here has the second
priority for the content ID (rating group) configured here.
If the QHT is not available
from the server or rulebase configuration mode, the QHT values configured
via the Credit Control Application Configuration Mode are used.
Example:
The following command
configures the prepaid credit control request retry time to
30 seconds:
cca quota retry-time 30
The following command
specifies the system to use the QHT value configured in the Credit Control
Application Mode:
no cca quota holding-time
content-id 1
The following command
specifies the system to ignore the QHT value configured in the Credit
Control Application Mode:
default cca quota holding-time
content-id 1
The following command
configures the prepaid credit control request retry time to
60 seconds
and the maximum number of retries to
65535:
default cca quota
retry-time max-retries
cca quota time-duration
algorithm
This command allows
you to specify the algorithm to compute time duration for Prepaid
Credit Control Application quotas in the current rulebase.
Privilege:
Security Administrator,
Administrator
Syntax
cca quota time-duration
algorithm { consumed-time seconds [ plus-idle ] | continuous-time-periods seconds | parking-meter seconds } [ content-id content_id ]
default cca quota
time-duration algorithm
no cca quota time-duration
algorithm { consumed-time | continuous-time-periods | parking-meter } [ content-id content_id ]
no
If previously configured,
deletes the quota time-duration algorithm configuration from the current
rulebase.
default
Configures this command
with its default setting.
consumed-time seconds
Specifies the Quota
Consumption Time (QCT) in seconds. QCT is used with active time-based
quotas and to determine chargeable time envelopes for consuming
time quota.
seconds must
be an integer from 1 through 4294967295.
Default: 0 (disabled)
A time envelope is the
basis for reporting active usage. For each time envelope, the quota consumption
includes the last QCT (duration between first packet and last packet + QCT).
plus-idle
Specifies the idle time
for QCT.
When used along with consumed-time it
indicates the active usage + idle time, when no traffic
flow occurs.
continuous-time-periods seconds
Specifies the charging
quota continuous period, in seconds.
seconds must
be an integer from 1 through 4294967295.
Default: 0 (disabled)
The Continuous Time
Periods (CTP) mechanism constructs time-envelopes from consecutive
base time intervals in which traffic has occurred up to and including
a base time interval which contains no traffic. As with Quota-Consumption-Time
envelopes, the end of an envelope can only be determined “retrospectively”.
Again, as with Quota-Consumption-Time, the envelope for CTP includes
the last base time interval (the one which contained no traffic).
parking-meter seconds
Specifies the Parking
Meter (PM) period, in seconds, for a particular rating group.
seconds must
be an integer from 1 through 4294967295.
Default: 0 (disabled)
This mechanisms utilizes
time quota, but instead of consuming linearly—once a decision
to consume has been taken—the granted quota is consumed
discretely in “chunks” of the base time interval
at the start of each base time interval. Traffic is then allowed
to flow for the period of the consumed quota.
The time interval seconds
defines the length of the Parking Meter. A time-envelope corresponds
to exactly one PM (and thus to one base time interval).
content-id content_id
Specifies the content
ID (Rating group AVP) to use for the CCA Quota time duration algorithm
selection in the current rulebase.
content_id is
the content ID specified for credit control service in ACS.
In 12.1 and earlier
releases, content_id must
be an integer from 1 through 65535.
Usage:
Use this command to
set the various time charging algorithms/schemes for prepaid
credit control charging.
If operator chooses parking-meter seconds style
charging, then time is billed in seconds chunks.
Example:
The following command
configures the QCT to consumed-time duration of
400 seconds:
cca quota time-duration
algorithm consumed-time 400
cca radius accounting
interval
This command allows
you to configure how often interim updates are generated by the
RADIUS Credit Control Application to be sent to the prepaid server.
Privilege:
Security Administrator,
Administrator
Syntax
cca radius accounting
interval interval
{ default | no } cca
radius accounting interval
default
Configures the command
with its default setting.
Default: Disabled; same
as no cca radius
accounting interval
no
Disables interim updates.
interval
Specifies the time interval,
in seconds, between interim updates generated by the RADIUS Credit
Control Application.
interval must
be an integer from 1 through 3600.
Default: 1 (Disabled)
Usage:
Use this command to
specify the RADIUS accounting interval between accounting of a prepaid
subscriber. The same parameters are applicable for RADIUS server group.
Example:
The following command
defines RADIUS accounting interval of
20 seconds
for RADIUS prepaid service in the rulebase:
cca radius accounting
interval 20
cca radius charging
context
This command allows
you to specify the RADIUS servers used for the current rulebase
when RADIUS credit control is enabled.
Privilege:
Security Administrator,
Administrator
Syntax
cca radius charging
context vpn_context [ group server_group_name ]
no cca radius charging context
no
RADIUS credit control
will not be performed.
vpn_context
Specifies the charging
context where RADIUS prepaid charging parameters are configured.
vpn_context must
be an alphanumeric string of 1 through 79 characters.
group server_group_name
Specifies the RADIUS
server group.
server_group_name must
be the name of a RADIUS server group, and must be an alphanumeric
string of 1 through 63 characters.
Usage:
Use this command to
specify the RADIUS charging context where RADIUS prepaid charging
parameters are configured. The same parameters are applicable for
RADIUS server group.
Example:
The following command
defines RADIUS charging context
prepaid_rad1 for
RADIUS prepaid charging in the rulebase:
cca radius charging
context prepaid_rad1
cca radius user-password
This command allows
you to configure the value to use for the “User-Password” attribute
in RADIUS messages sent to the prepaid server.
Privilege:
Security Administrator,
Administrator
Syntax
cca radius user-password [ encrypted ] password password
no cca radius user-password
no
If previously configured,
deletes the RADIUS prepaid service user password configured in the
current rulebase.
[ encrypted ] password password
Specifies the password
for prepaid services within the current rulebase.
In
12.1 and earlier releases, password must
be an alphanumeric string of 1 through 63 characters with or without
encryption.
The encrypted keyword
is intended only for use by the system while saving configuration
scripts. The system displays the encrypted keyword
in the configuration file as a flag that the variable following
the password keyword
is the encrypted version of the plain text password. Only the encrypted
password is saved as part of the configuration file.
Usage:
Use this command to
specify the RADIUS user password for prepaid services within the current
rulebase.
Example:
The following command
configures the user password as
user_123 without
encryption in the current rulebase:
cca radius user-password
password user_123
charging-rule-optimization
This command allows
you to configure the internal optimization level to use, for improved
performance, when evaluating each instance of the action priority command.
Privilege:
Security Administrator,
Administrator
Syntax
charging-rule-optimization { high | low | medium }
default charging-rule-optimization
default
Configures this command
with its default setting.
Default:
In 11.0 and later
releases: high In
10.0 and earlier releases:
low
high
Enables the highest
level of optimization with high memory utilization.
low
Enables minimal level
of optimization with minimal memory utilization.
medium
IMPORTANT:
In 11.0 and later releases,
the medium keyword
is deprecated.
Enables medium level
of optimization with moderate memory utilization.
Usage:
Use this command to
specify the level of internal optimization for improved performance when
evaluating each instance of the action priority command.
Both the high and medium
options cause re-organization of the entire memory structure whenever
any change is made, such as on the addition of an action priority command.
Example:
The following command
specifies the highest optimization level for rule search and matching
in the rulebase:
charging-rule-optimization high
constituent-policies
This command allows
you to configure the Bandwidth, Content Based Billing (CBB), and
Firewall/Firewall-and-NAT constituent policies. The combination
of the values of all three policies will uniquely identify the associated
rulebase.
Privilege:
Security Administrator,
Administrator
Syntax
constituent-policies { bandwidth-policy bandwidth_policy_name | cbb-policy cbb_policy_name | firewall-policy fw_policy_name | fw-and-nat-policy fw_nat_policy_name } +
no constituent-policies
no
If previously configured,
deletes the constituent-policies configuration from the current rulebase.
bandwidth-policy bandwidth_policy_name
Specifies the Bandwidth
policy.
bandwidth_policy_name must
be the name of a bandwidth policy, and must be an alphanumeric string
of 1 through 63 characters.
cbb-policy cbb_policy_name
Specifies the Content
Based Billing (CBB) policy.
cbb_policy_name must
be the name of a CBB policy, and must be an alphanumeric string
of 1 through 63 characters.
firewall-policy fw_policy_name
IMPORTANT:
This keyword is customer
specific. For more information, please contact your Cisco account representative.
Specifies the Stateful
Firewall policy.
fw_policy_name must
be the name of a Stateful Firewall policy, and must be an alphanumeric
string of 1 through 63 characters.
fw-and-nat-policy fw_nat_policy_name
IMPORTANT:
This keyword is customer
specific
, and is only available
in StarOS 8.1 and in StarOS 9.0 and
later releases.
Specifies the Firewall-and-NAT
policy.
fw_nat_policy_name must
be the name of a Firewall-and-NAT policy, and must be an alphanumeric
string of 1 through 63 characters.
Usage:
Use this command to
configure the bandwidth, CBB, and Firewall/Firewall-and-NAT constituent
policies that will identify the rulebase. The combination of the
values of all three policies will uniquely identify the rulebase
associated.
Example:
The following command
configures the constituent bandwidth policy named
test123:
constituent-policies
bandwidth-policy test123
content-filtering
category policy-id
This command allows
you to configure the Content Filtering Category Policy Identifier
for Policy-based Content Filtering support in the current rulebase.
Privilege:
Security Administrator,
Administrator
Syntax
content-filtering category
policy-id cf_policy_id
no content-filtering
category policy-id [ cf_policy_id ]
no
If previously configured,
deletes the configuration from the current rulebase.
In StarOS 8.1 and later
releases, optionally the policy ID can be specified. If the
specified policy ID is invalid, or is not configured in the rulebase,
an error message is displayed. If no policy ID is specified, whatever
policy is configured, if any, is removed from the rulebase.
content-filtering category
policy-id cf_policy_id
Configures the specified
Content Filtering Category Policy in the current rulebase.
cf_policy_id must
be the ID of an existing Content Filtering Category Policy, and
must be an integer from 1 through 4294967295.
IMPORTANT:
If the specified Content
Filtering Category Policy does not exist, all packets will be passed regardless
of the categories/actions determined for such packets.
IMPORTANT:
The category policy
ID that is configured using the category policy-id cf_policy_id command
in the APN/Subscriber Configuration Mode prevails over
this configuration.
Usage:
Use this command to
configure the Content Filtering Category Policy ID for Policy-based Content
Filtering support in the rulebase.
The Content Filtering
Category Policy is created/deleted in the ACS Configuration
Mode, and is configured in the Content Filtering Policy Configuration
Mode.
Example:
The following command
configures the Content Filtering Category Policy ID
101 in the
rulebase:
content-filtering
category policy-id 101
content-filtering
flow-any-error
This command allows
you to specify action to take on Content Filtering packets in the
case of ACS error scenarios.
Privilege:
Security Administrator,
Administrator
Syntax
content-filtering
flow-any-error { deny | permit }
default content-filtering
flow-any-error
default
Configures this command
with its default setting.
Default: permit
deny
Configures flow-any-error
configuration as deny.
All the
denied packets will be accounted for by the discarded-flow-content-id configuration
in the Content Filtering Policy Configuration Mode. This content
ID will be used to generate UDRs for packets denied via content filtering.
permit
Configures flow-any-error
configuration as permit.
Usage:
Use this command to
allow/discard content filtering packets in case of ACS
error scenarios.
Example:
The following command
allows content filtering packets in case of an ACS error:
content-filtering
flow-any-error permit
content-filtering
mode
This command allows
you to enable/disable the specified Category-based Content
Filtering mode in the current rulebase.
Privilege:
Security Administrator,
Administrator
Syntax
content-filtering mode { category { static-and-dynamic | static-only } | server-group cf_server_group }
no content-filtering mode
no
If previously configured,
deletes the content-filtering mode configuration from the current rulebase.
Content filtering will not to be performed for the current rulebase.
This is the default setting.
category { static-and-dynamic | static-only }
Specifies the Category-based
Content Filtering mode.
- static-only:
Configures Category-based Content Filtering in static only mode,
wherein all URLs are compared against an internal database to categorize
the requested content.Using
Category-based Content Filtering support requires configuration
of the require
active-charging content-filtering category command in
the Global Configuration Mode.
- static-and-dynamic:
Configures Category-based Content Filtering in Static-and-Dynamic
mode, wherein a static rating of the URL is first performed, and
only if the static rating fails to find a match, dynamic rating
of the content that the server returns is then performed.
IMPORTANT:
Before enabling static-and-dynamic
rating in the rulebase, it must be enabled at the global level as
the resources required for dynamic rating are allocated at the global
level. To enable static-and-dynamic rating at the global level,
in the Global Configuration Mode use the require active-charging
content-filtering category static-and-dynamic command.
server-group cf_server_group
Enables and configures
the Content Filtering Server Group (CFSG) mode within the rulebase
to manage an external content filtering server with an Internet
Content Adaptation Protocol (ICAP) client system.
cf_server_group must
be the name of a CFSG, and must be unique, and must be an alphanumeric
string of 1 through 63 characters.
If configured, ACS attempts
to establish TCP connections to every server in the named group.
Usage:
Use this command to
enable and apply the content filtering mode in the rulebase to manage
a content filtering server with an ICAP client system.
Example:
The following command
enables the content filtering mode for external content filtering server
group
CF_Server1 in
the rulebase:
content-filtering mode
server-group CF_Server1
The following command
enables the category based static and dynamic content filtering mode
for in the rulebase:
content-filtering mode
category static-and-dynamic
dynamic-rule order
This command allows
you to specify whether dynamic rules are matched before statically
configured rules.
Privilege:
Security Administrator,
Administrator
Syntax
dynamic-rule order { always-first | first-if-tied }
no dynamic-rule order
no
If previously configured,
deletes the dynamic-rule order configuration from the current rulebase.
By default, dynamic rules are matched against the flow prior to
static rules.
always-first
Specifies to match all
the dynamic rules against the flow prior to any static rule.
first-if-tied
Specifies to match rules
against the flow based on their priority with the condition that dynamic
rules match before a static rule of the same priority.
A rule is a combination
of a ruledef, charging action, and precedence. Static rules are defined
by the action CLI
command in the ACS Rulebase Configuration Mode, and are applicable
to all subscribers that are associated with the rulebase. Dynamic
rules are obtained via a dynamic protocol, such as, the Gx-interface
for a particular subscriber session.
Usage:
Use this command to
configure the order in which rules are selected for matching in between
dynamic rules (per subscriber) and static rules (from rulebase).
Example:
The following command
matches all dynamic rules against the flow prior to any static rule:
dynamic-rule order
always-first
edr suppress-zero-byte-records
This command disables/enables
the creation of EDRs when there is no data for the flows.
Privilege:
Security Administrator,
Administrator
Syntax
[ default | no ] edr
suppress-zero-byte-records
default
Configures this command
with its default setting.
Default: Disabled; same
as no edr suppress-zero-byte-records
no
Disables the suppression
of zero-byte EDRs.
edr suppress-zero-byte-records
Suppresses zero-byte
EDRs.
Usage:
Use this command to
disable/enable the creation of EDRs that are empty. The
situation where there is a zero-byte EDR would typically be possible
when two successive EDRs are generated for a flow. This CLI command
suppresses the second such EDR for the flow.
edr transaction-complete
This command enables/disables
the generation of an EDR on the completion of a transaction.
IMPORTANT:
This command is available
only in StarOS 8.1
and in StarOS 9.0 and
later releases.
Privilege:
Security Administrator,
Administrator
Syntax
In StarOS 12.1 and
earlier releases:
edr transaction-complete
http edr-format edr_format_name
{ default | no } edr
transaction-complete
default
Configures this command
with its default setting.
Default: Disabled; same
as no edr transaction-complete
no
If previously configured,
deletes the configuration from the current rulebase.
edr-format edr_format_name
Specifies to generate
EDR on transaction completion, for HTTP protocol.
edr_format_name must
be the name of an EDR format, and must be an alphanumeric string
of 1 through 63 characters.
Usage:
Use this command to
configure the generation of an EDR when certain application transactions
(for example, request/response pairs) complete. In this
release EDR generation is supported only for HTTP protocol. Note
that these EDRs are in addition to those that might be generated
due to other conditions, for example, EDR configurations in a Charging Action.
Example:
In
12.1 and earlier releases, the following command configures the
generation of EDRs on the completion of transactions for HTTP protocol
specifying the EDR format as
test123:
edr transaction-complete
http edr-format test123
edr voip-call-end
This command enables/disables
generation of EDRs on the completion of Voice over IP (VoIP) calls.
Privilege:
Security Administrator,
Administrator
Syntax
In StarOS 12.1 and
earlier releases:
edr voip-call-end edr-format edr_format_name
{ default | no } edr
voip-call-end
default
Configures this command
with its default setting.
Default:
Disabled; same as no
edr voip-call-end
no
If previously configured,
deletes the edr voip-call-end configuration from the current rulebase.
edr-format edr_format_name
Specifies to generate
an EDR when a VoIP call ends.
edr_format_name must
be the name of an EDR format, and must be an alphanumeric string
of 1 through 63 characters.
Usage:
Use this command to
generate an EDR on the completion of voice calls. Note that these EDRs
are in addition to those that might be generated due to other conditions,
for example EDR configurations in a Charging Action. This command
facilitates P2P voice duration reporting.
Example:
In 12.1
and earlier releases, the following command specifies generating
EDRs on completion of VoIP calls using the EDR format
test13:
edr voip-call-end
edr-format test13
egcdr inactivity-meter
Description This
command has been deprecated. It is included in the CLI for backward
compatibility with older configuration files. When executed performs
no function. Use the egcdr
threshold interval interval [ regardless-of-other-triggers ] command
for this functionality.
egcdr cdr-encoding
This command allows
you to configure the eG-CDR encoding type.
Privilege:
Security Administrator,
Administrator
Syntax
egcdr cdr-encoding { ascii [ delimiter { colon | comma | pipe } ] | asn.1 }
default egcdr cdr-encoding
default
Configures the default
eG-CDR CDR-encoding format.
Default: asn.1
ascii [ delimiter { colon | comma | pipe } ]
Specifies to use ASCII
encoding type to generate eG-CDR in ASCII format.
delimiter { colon | comma | pipe }:
Specifies the delimiter character to use in eG-CDRs in ASCII format.
- colon: Specifies
to use “:” (colon) as a delimiter in eG-CDR.
- comma: Specifies
to use “,” (comma), as a delimiter in eG-CDR.
- pipe: Specifies
to use “|” (pipe) as a delimiter in eG-CDR.
Default: pipe
asn.1
Specifies to use ASN.1
encoding type to generate eG-CDR in ASN.1 format.
This is the default
setting.
Usage:
Use this command to
configure the eG-CDR encoding type.
For more information
on using eG-CDR ASCII encoding type in your deployment, contact your
Cisco account representative.
Example:
The following command
specifies to use ASCII encoding type to generate eG-CDR in ASCII
format while specifying the delimiter character as comma:
egcdr cdr-encoding ascii
delimiter comma
egcdr tariff
This command allows
you to configure the eG-CDR tariff time to generate new eG-CDRs
for GGSN and P-GW-CDRs for P-GW.
Privilege:
Security
Administrator, Administrator
Syntax
[ no ] egcdr
tariff minute minute hour hour
no
If
previously configured, deletes the configuration from the current rulebase.
minute minute
Specifies
the minute for the time-of-day configuration.
minute must
be an integer from 0 through 59.
hour hour
Specifies
the hour for the time-of-day configuration.
hour must
be an integer from 0 through 23.
Usage:
Use
this command to configure the eG-CDR tariff time to generate new
eG-CDRs for GGSN and P-GW-CDRs for P-GW. Up to four different time-of-day
settings may be configured. When any configured tariff time is reached,
the current eG-CDR/P-GW-CDR will be closed and a new eG-CDR/P-GW-CDR
is opened.
Example:
The following command
defines an eG-CDR tariff for the 23rd minute of the 22nd hour of the
day (10:23 PM):
egcdr tariff minute
23 hour 22
egcdr threshold
This command allows
you to configure the thresholds for generating eG-CDRs for GGSN
and P-GW-CDRs for P-GW.
Privilege:
Security Administrator,
Administrator
Syntax
egcdr threshold { interval interval [ regardless-of-other-triggers ] | volume { downlink |
total | uplink } bytes }
{ default | no } egcdr
threshold { interval | volume }
no
If previously configured,
deletes the eG-CDR threshold configuration from the current rulebase.
default
Configures this command
with the default settings.
Default:
Disabled; same as no
egcdr threshold interval and no egcdr threshold
interval volume commands.
interval interval [ regardless-of-other-triggers ]
Specifies the time interval,
in seconds, for closing the eG-CDR/P-GW-CDR if the minimum time
duration thresholds are satisfied.
interval must
be an integer from 60 through 40000000.
regardless-of-other-triggers:
This option enables eG-CDR/P-GW-CDR generation at the fixed
time interval irrespective of any other eG-CDR/P-GW-CDR
triggers that may have happened in between.
Default: Disabled.
volume { downlink | total | uplink } bytes
Specifies the uplink/downlink
volume octet counts for the generation of the interim eG-CDRs/P-GW-CDRs.
- downlink bytes: Specifies
the limit for the number of downlink (from network to subscriber)
octets after which the eG-CDR/P-GW-CDR is closed.bytes must
be an integer from 100000 through 4000000000.Default: 4000000000
- total bytes: Specifies
the limit for the total number of octets (uplink+downlink)
after which the eG-CDR/P-GW-CDR is closed.bytes must
be an integer from 100000 through 4000000000.Default: Disabled
- uplink bytes: Specifies the
limit for the number of uplink (from subscriber to network) octets
after which the eG-CDR/P-GW-CDR is closed.bytes must
be an integer from 100000 through 4000000000.Default: 4000000000
Usage:
Use this command to
configure thresholds to generate eG-CDRs/P-GW-CDRs.
Thresholds can be specified
for both time interval and for data volume, by entering the command
twice (once with interval and once with volume). When either configured
threshold is reached, the eG-CDR/P-GW-CDRs will be closed.
The volume trigger can be specified for uplink or downlink or combined
total (uplink + downlink) byte thresholds. The exact keyword forces
the configured volume to exactly match the volume in the eG-CDR/P-GW-CDRs,
so the triggering packet might have to be divided across two eG-CDRs/P-GW-CDRs.
When both interval
and volume triggers are configured, we'll reset the interval time
and accumulated volume amount whenever the eG-CDR/P-GW-CDRs
is closed regardless of whether it was due to the interval time
expiration or reaching the volume limit. Use the regardless-of-other-triggers
optional keyword, if you want the eG-CDRs/P-GW-CDRs closed
at the configured regular intervals, regardless of whether eG-CDRs/P-GW-CDRs
are being closed due to reaching a volume limit.
When the PDP context
is terminated, the eG-CDR/P-GW-CDRs will be closed regardless of
whether the thresholds have been reached.
Example:
The following command
defines an eG-CDR threshold interval of
600 seconds:
egcdr threshold interval 600
egcdr time-duration
algorithm
This command allows
you to specify the algorithm to compute the duration of time utilization
in an eG-CDR for the current rulebase.
Privilege:
Security Administrator,
Administrator
Syntax
egcdr time-duration
algorithm { consumed-time consumed_time [ plus-idle ] | continuous-time-periods ctp_time | parking-meter seconds }
{ default | no } egcdr
time-duration algorithm
no
If previously configured,
deletes the eG-CDR time-duration algorithm configuration from the
current rulebase.
default
Configures this command
with its default setting.
Default:
Algorithm configured for CCA, or the CCA default if none is configured.
consumed-time consumed_time [ plus-idle ]
Specifies the actual
consumption time in seconds. This is used to determine the actual
used chargeable time envelopes for the purpose of consuming time
quota.
consumed_time must
be an integer from 1 through 4294967295.
Default:
0 (disabled)
Time envelope is the
basis for reporting active usage. For each time envelope, the time consumption
includes the time duration between arrival of last packet and first
packet only.
plus-idle:
Specifies the idle time between arrival of two packets to include
in time usage record in eG-CDR.
When
used along with consumed-time it
indicates the active usage + idle time, when no traffic
flow occurs.
continuous-time-periods ctp_time
Specifies the continuous
time period to compute the usage record in eG-CDR.
ctp_time sets
the audition, in seconds, to start a counter on arrival of the first
packet and thereafter include only that period in charging in which
one or more packets arrived. For the period where no packets arrived
or no traffic was detected, usage will not be computed.
ctp_time must
be an integer from 1 through 4294967295.
parking-meter seconds
Specifies the Parking
Meter (PM) period, in seconds.
seconds must
be an integer from 1 through 4294967295.
Parking meter is the
method with which the usage time is set in the content-id containers
in eG-CDRs. When a parking meter value is set, the user is charged
for time in increments of the value set. For example, if the parking
meter is set to 300 seconds (5 minutes) and the subscriber only
uses one minute, the charge is for 5 minutes.
Usage:
Use this command to
set the various time charging algorithms/schemes for time
usage in eG-CDR.
For
example, packets arrive at times T1, T2, T3 and T4. Then the typical
time usage might be computed to be T4 – T1. However, if
say there is an idle period between times T2 and T3, then system
will compute the time usage to be (T2 – T1) + (T4 – T3).
consumed-time in
above scenario calculates the time duration as (T2 – T1) + (T4 – T3)
where consumed-time with plus-idle calculates
the time duration as (T2-T1)+I + (T4 – T3)+I
or (T4-T1).
Example:
The following command
sets consumed time duration to
400 seconds:
egcdr time-duration
algorithm consumed-time 400
end
Exits the current
configuration mode and returns to the Exec mode.
Privilege:
Security Administrator,
Administrator
Usage:
Use this command to
return to the Exec mode.
exit
Exits the current
mode and returns to the parent configuration mode.
Privilege:
Security Administrator,
Administrator
Usage:
Use this command to
return to the parent configuration mode.
extract-host-from-uri
This command allows
you to configure whether to use the host name embedded in the URI
as the host field, when the host field option in the HTTP or Wireless
Session Protocol (WSP) header is absent.
Privilege:
Security Administrator,
Administrator
Syntax
extract-host-from-uri { http | wsp
) +
{ default | no } extract-host-from-uri
default
Configures this command
with its default setting.
Default: Disabled; same
as no extract-host-from-uri
no
If previously configured,
disables the extract-host-from-uri configuration, for both HTPP and
WSP, from the current rulebase.
http | wsp
Specifies the protocol(s).
+
Indicates that more
than one of the previous keywords can be entered within a single command.
Usage:
If the host field is
not present in HTTP/WSP header, this command will extract
host from the URI, and store it in the host field to enable “http
host” and “wsp host” rule matches using
the stored value.
IMPORTANT:
Applying the extract-host-from-uri command
a second time will overwrite the previous configuration. For example,
if you apply the command extract-host-from-uri
http wsp http, and then apply the command extract-host-from-uri
http wsp, extraction of host from URI will happen only
for WSP analyzer.
Example:
The following command
configures extraction of host from URI for both HTTP and WSP protocols:
extract-host-from-uri
http wsp
fair-usage session-waiver-percent
This command allows
you to configure a waiver on top of average available memory credits
per session for the Fair Usage feature.
Product:
ACS, ADC, CF, FW, NAT
Privilege:
Security Administrator,
Administrator
Syntax
fair-usage session-waiver-percent waiver_percent
default fair-usage
session-waiver-percent
default
Configures this command
with its default setting.
Default: 20 percent
waiver_percent
Specifies the Fair Usage
session waiver above average available memory for subscribers using
the current rulebase.
waiver_percent must
be an integer from 1 through 1000.
Default: 20 percent
Usage:
Use this command to
configure a waiver on top of average available memory credits per session
at the rulebase level. That is, an allowance to use more than the
average amount of memory.
Example:
The following command
configures the Fair Usage Session Waiver setting to
25percent:
fair-usage session-waiver-percent 25
firewall dos-protection
This command allows
you to configure Stateful Firewall protection for subscribers from
Denial-of-Service (DoS) attacks.
IMPORTANT:
In StarOS 8.0, this
command is available in the ACS Configuration Mode. In StarOS 8.1
and StarOS 8.3, use this command for Rulebase-based Firewall-and-NAT
configuration. In StarOS 8.1 and
StarOS 9.0 and later releases, for
Policy-based Firewall-and-NAT configuration, this command is available
in the Firewall-and-NAT Policy Configuration Mode.
Privilege:
Security Administrator,
Administrator
Syntax
[ no ] firewall
dos-protection { all | flooding { icmp | tcp-syn | udp } | ftp-bounce | ip-unaligned-timestamp | mime-flood | port-scan | tcp-window-containment | source-router | teardrop | winnuke }
default firewall dos-protection
no
If previously enabled,
disables Stateful Firewall protection for subscribers from all or specified
DoS attack(s).
default
Configures this command
with its default setting.
Default:
Protection from all DOS attacks is disabled.
all
Enables protection against
all DoS attacks supported by the Stateful Firewall in-line service.
flooding { icmp | tcp-syn | udp }
Enables protection against
specified flooding attacks:
- icmp: Enables
protection against ICMP Flood attacks
- tcp-syn: Enables
protection against TCP SYN Flood attacks
- udp: Enables
protection against UDP Flood attacks
ftp-bounce
Enables protection against
FTP Bounce attacks.
In an
FTP Bounce attack, an attacker is able to use the PORT command to
request access to ports indirectly through a user system as an agent
for the request. This technique is used to port scan hosts discreetly,
and to access specific ports that the attacker cannot access through
a direct connection.
ip-unaligned-timestamp
Enables protection against
IP Unaligned Timestamp attacks.
In an
IP Unaligned Timestamp attack, certain operating systems crash if
they receive a frame with the IP timestamp option that is not aligned
on a 32-bit boundary.
mime-flood
Enables protection against
HTTP Multiple Internet Mail Extension (MIME) Header Flooding attacks.
In a MIME Flood attack
an attacker sends huge amount of MIME headers which consumes a lot
of memory and CPU usage.
port-scan
Enables protection against
Port Scan attacks.
tcp-window-containment
Enables protection against
TCP Sequence Number Out-of-Range attacks.
In a Sequence Number
Out-of-Range attack the attacker sends packets with out-of-range sequence
numbers forcing the system to wait for missing sequence packets.
source-router
Enables protection against
IP Source Route IP Option attacks.
Source routing is an
IP option mainly used by network administrators to check connectivity. When
an IP packet leaves a system, its path through various networks
to its destination is controlled by the routers and their current
configuration. Source routing provides a means to override the control
of the routers. Strict source routing specifies the path through
all the routers to the destination. The same path in reverse is
used to return responses. Loose source routing allows the attacker
to spoof both an address and sets the loose source routing option
to force the response to return to the attacker's network.
teardrop
Enables protection against
Teardrop attacks.
In a
Teardrop attack, overlapping IP fragments are exploited causing
the TCP/IP fragmentation re-assembly to improperly handle
overlapping IP fragments.
winnuke
Enables protection against
WIN-NUKE attacks.
This
is a type of Nuke denial-of-service attack against networks consisting
of fragmented or otherwise invalid ICMP packets sent to the target,
achieved by using a modified ping utility to repeatedly send this
corrupt data, thus slowing down the affected computer until it comes
to a complete stop.
The
WinNuke exploits the vulnerability in the NetBIOS handler and a
string of out-of-band data sent to TCP port 139 of the victim machine
causing it to lock up and display a Blue Screen of Death.
Usage:
Use this command to
enable Stateful Firewall protection from different types of DoS attacks.
This command can be used multiple times for different DoS attacks.
IMPORTANT:
The DoS attacks are
detected only in the downlink direction.
Example:
The following command
enables Stateful Firewall protection from all supported DoS attacks:
firewall dos-protection all
firewall flooding
This command allows
you to configure Stateful Firewall protection from Packet Flooding
attacks.
IMPORTANT:
In StarOS 8.0, this
command is available in the ACS Configuration Mode. In StarOS 8.1
and StarOS 8.3, use this command for Rulebase-based Firewall-and-NAT
configuration. In StarOS 8.1 and
StarOS 9.0 and later releases, for
Policy-based Firewall-and-NAT configuration, this command is available
in the Firewall-and-NAT Policy Configuration Mode.
Privilege:
Security Administrator,
Administrator
Syntax
firewall flooding { { protocol { icmp | tcp-syn | udp } packet
limit packets } | { sampling-interval interval } }
default firewall flooding { { protocol { icmp | tcp-syn | udp } packet
limit } | { sampling-interval } }
default
Configures this command
the default setting for the specified keyword.
protocol { icmp | tcp-syn | udp }
Specifies the transport
protocol:
- icmp: Configuration
for ICMP protocol.
- tcp-syn: Configuration
for TCP-SYN packet limit.
- udp: Configuration
for UDP protocol.
packet limit packets
Specifies the maximum
number of specified packets a subscriber can receive during a sampling
interval.
packets must
be an integer from 1 through 4294967295.
Default: 1000 packets
per sampling interval for all protocols.
sampling-interval interval
Specifies the flooding
sampling interval, in seconds.
interval must
be an integer from 1 through 60.
Default: 1 second
Usage:
Use this command to
configure the maximum number of ICMP, TCP-SYN, / UDP packets allowed
to prevent the packet flooding attacks to the host.
Example:
The following command
ensures a subscriber will not receive more that 1000 ICMP packets per
sampling interval:
firewall flooding
protocol icmp packet limit 1000
The following command
ensures a subscriber will not receive more than 1000 UDP packets per
sampling interval on different 5-tuples. That is, if an attacker
is sending lot of UDP packets on different ports or using different
spoofed IPs, those packets will be limited to 1000 packets per sampling
interval. This way only “suspected” malicious
packets are limited and not “legitimate” packets:
firewall flooding
protocol udp packet limit 1000
The following command
ensures a subscriber will not receive more than 1000 TCP-SYN packets
per sampling interval:
firewall flooding
protocol tcp-syn packet limi 1000
The following command
specifies a flooding sampling interval of 1 second:
firewall flooding
sampling-interval 1
firewall icmp-destination-unreachable-message-threshold
This command allows
you to configure a threshold on the number of ICMP error messages
sent by the subscriber for a particular data flow.
IMPORTANT:
In StarOS 8.0, this
command is available in the ACS Configuration Mode. In StarOS 8.1
and StarOS 8.3, use this command for Rulebase-based Firewall-and-NAT
configuration. In StarOS 8.1 and
StarOS 9.0 and later releases, for
Policy-based Firewall-and-NAT configuration, this command is available
in the Firewall-and-NAT Policy Configuration Mode.
Privilege:
Security Administrator,
Administrator
Syntax
firewall icmp-destination-unreachable-message-threshold messages then-block-server
{ default | no } firewall
icmp-destination-unreachable-message-threshold
default
Configures this command
with its default setting.
Default:
No limit
no
If previously configured,
deletes the configuration from the current rulebase.
messages
Specifies the threshold
on the number of ICMP error messages sent by the subscriber for
a particular data flow.
messages must
be an integer from 1 through 100.
Usage:
Use this command to
configure a threshold on the number of ICMP error messages sent
by the subscriber for a particular data flow. After the threshold
is reached, it is assumed that the server is not reacting properly
to the error messages, and further downlink traffic to the subscriber
on the unwanted flow is blocked.
Some servers that run
QChat ignore the ICMP error messages (Destination Port Unreachable
and Host Unreachable) from the mobiles. So the mobiles continue
to receive unwanted UDP traffic from the QChat servers, and their
batteries get exhausted quickly.
Example:
The following command
configures a threshold of 10 ICMP error messages:
firewall icmp-destination-unreachable-message-threshold
10 then-block-server
firewall max-ip-packet-size
This command allows
you to configure the maximum IP packet size (after IP reassembly)
allowed over Stateful Firewall.
IMPORTANT:
In StarOS 8.0, this
command is available in the ACS Configuration Mode. In StarOS 8.1
and StarOS 8.3, use this command for Rulebase-based Firewall-and-NAT
configuration. In StarOS 8.1 and
StarOS 9.0 and later releases, for
Policy-based Firewall-and-NAT configuration, this command is available
in the Firewall-and-NAT Policy Configuration Mode.
Privilege:
Security Administrator,
Administrator
Syntax
firewall max-ip-packet-size packet_size protocol { icmp | non-icmp }
default firewall max-ip-packet-size
protocol { icmp | non-icmp }
default
Configures the default
maximum IP packet size configuration.
Default: 65535 bytes
(for both ICMP and non-ICMP)
packet_size
Specifies the maximum
packet size.
packet_size must
be an integer from 30000 through 65535.
protocol { icmp | non-icmp }
Specifies the transport
protocol:
- icmp: Configuration
for ICMP protocol.
- non-icmp:
Configuration for protocols other than ICMP.
Usage:
Use this command to
configure the maximum IP packet size allowed for ICMP and non-ICMP
packets to prevent packet flooding attacks to the host. Packets
exceeding the configured size will be dropped for “Jolt
Attack” and “Ping-Of-Death Attack”.
Example:
The following command
allows a maximum packet size of
60000 for
ICMP protocol:
firewall max-ip-packet-size
60000 protocol icmp
firewall mime-flood
This command allows
you to configure Stateful Firewall protection from Multipurpose
Internet Mail Extensions (MIME) Flood attacks.
IMPORTANT:
In StarOS 8.0, this
command is available in the ACS Configuration Mode. In StarOS 8.1
and StarOS 8.3, use this command for Rulebase-based Firewall-and-NAT
configuration. In StarOS 8.1 and
StarOS 9.0 and later releases, for
Policy-based Firewall-and-NAT configuration, this command is available
in the Firewall-and-NAT Policy Configuration Mode.
Privilege:
Security Administrator,
Administrator
Syntax
firewall mime-flood { http-headers-limit max_limit | max-http-header-field-size max_size }
default firewall mime-flood { http-headers-limit | max-http-header-field-size }
default
Configures this command
with its default setting.
http-headers-limit max_limit
Specifies the maximum
number of headers allowed in an HTTP packet. If the number of HTTP
headers in a page received is more than the specified limit, the
request will be denied.
max_limit must
be an integer from 1 through 256.
Default: 16
max-http-header-field-size max_size
Specifies the maximum
header field size allowed in the HTTP header, in bytes. If the size
of HTTP header in the received page is more than the specified number
of bytes, the request will be denied.
max_size must
be an integer from 1 through 8192.
Default: 4096 bytes
Usage:
Use this command to
configure the maximum number of headers allowed in an HTTP packet,
and the maximum header field size allowed in the HTTP header to
prevent MIME flooding attacks.
Example:
The following command
sets the maximum number of headers allowed in an HTTP packet to
100:
firewall mime-flood
http-headers-limit 100
The following command
sets the maximum header field size allowed in the HTTP header to
1000 bytes:
firewall mime-flood
max-http-header-field-size 1000
firewall no-ruledef-matches
This command allows
you to configure the default action for packets when no Stateful
Firewall ruledef matches.
IMPORTANT:
In StarOS 8.0, this
command is available in the ACS Configuration Mode. In StarOS 8.1
and StarOS 8.3, use this command for Rulebase-based Firewall-and-NAT
configuration. In StarOS 8.1 and
StarOS 9.0 and later releases, for
Policy-based Firewall-and-NAT configuration, use the access-rule no-ruledef-matches command
available in the Firewall-and-NAT Policy Configuration Mode.
Privilege:
Security Administrator,
Administrator
Syntax
firewall no-ruledef-matches { downlink | uplink } action { deny [ charging-action charging_action_name ] | permit [ bypass-nat | nat-realm nat_realm_name ] }
default firewall no-ruledef-matches { downlink | uplink } action
default
Configures the default
action for packets with no Stateful Firewall ruledef match.
downlink | uplink
Specifies the packet
type:
- downlink:
Downlink (from network to subscriber) packets with no Stateful Firewall
ruledef match.Default: deny
- uplink: Uplink
(from subscriber to network) packets with no Stateful Firewall ruledef
match.Default: permit
action { deny [ charging-action charging_action_name ] | permit [ bypass-nat | nat-realm nat_realm_name ] }
Specifies the default
action for packets with no Stateful Firewall ruledef match.
permit [ bypass-nat | nat-realm nat_realm_name ]: Permit
packets.
IMPORTANT:
The bypass-nat keyword
is only available in StarOS 8.3 and later releases.
Optionally specify:
- bypass-nat:
Specifies to bypass Network Address Translation (NAT).
- nat-realm nat_realm_name:
Specifies a NAT realm to be used for performing NAT on subscriber
packets. nat_realm_name must
be the name of a NAT realm, and must be an alphanumeric string of
1 through 31 characters.
IMPORTANT:
If neither bypass-nat or nat-realm are
configured, NAT is performed if the nat policy nat-required CLI
command is configured with the default-nat-realm option.
deny [ charging-action charging_action_name ]:
Denies specified packets.
Optionally,
a charging action can be specified.
charging_action_name must
be the name of a charging action, and must be an alphanumeric string
of 1 through 63 characters.
Usage:
Use this command to
configure the default action to be taken on packets with no Stateful Firewall
ruledef matches.
If,
for deny action, the optional charging action is configured, the
action taken depends on what is configured in the charging action.
For the Stateful Firewall rule, the “flow action”, “billing
action”, and “content ID” of the charging
action will be used to take action. If flow exists, flow statistics
are updated.
Allowing/dropping
of packets is determined in the following sequence:
- Check is done to see
if the packet matches any pinholes. If yes, no rule matching is
done and the packet is allowed.
- Stateful Firewall ruledef
matching is done. If a rule matches, the packet is allowed or dropped
as per the firewall
priority configuration.
- If no Stateful Firewall
ruledef matches, the packet is allowed or dropped as per the no-ruledef-matches configuration.
For a packet dropped
due to Stateful Firewall ruledef match or no match (first packet
of a flow), the charging action applied is the one configured in
the firewall priority or
the firewall no-ruledef-matches command
respectively.
In StarOS 8.1, in the
case of Policy-based Stateful Firewall, the charging action applied
is the one configured in the access-rule priority or
the access-rule
no-ruledef-matches command respectively.
For action on packets
dropped due to any error condition after data session is created,
the charging action must be configured in the flow any-error charging-action command.
Example:
The following command
configures Stateful Firewall to permit downlink packets with no ruledef
matches:
firewall no-ruledef-matches
downlink action permit
firewall policy
This command allows
you to enable/disable Stateful Firewall support for all subscribers
using the current rulebase.
IMPORTANT:
In StarOS 8.0, this
command is available in the APN/Subscriber Configuration
Mode. In StarOS 8.1 and StarOS 8.3, use this command for Rulebase-based Firewall-and-NAT
configuration. In StarOS 8.1 and
StarOS 9.0 and later releases, for Policy-based Firewall-and-NAT
configuration, this command is available in the Firewall-and-NAT
Policy Configuration Mode.
Privilege:
Security Administrator,
Administrator
Syntax
firewall policy firewall-required
{ default | no } firewall policy
default
Configures this command
with its default setting.
Default:
Stateful Firewall support is disabled for all subscribers using
the current rulebase.
no
If previously enabled,
disables Stateful Firewall support for all subscribers using the
current rulebase.
firewall-required
Enables Stateful Firewall
support for all subscribers using the current rulebase.
Usage:
Use this command to
enable/disable Stateful Firewall support for all subscribers
using the current rulebase.
Example:
The following command
enables Stateful Firewall support:
firewall policy firewall-required
The following command
disables Stateful Firewall support:
no firewall policy
firewall priority
This command allows
you to add and specify the priority and type of a Stateful Firewall
ruledef in the current rulebase, and allows you to configure a single
or range of ports to be allowed on the server for auxiliary/data connections.
IMPORTANT:
In StarOS 8.1 and StarOS 9.0 and
later releases, for
Policy-based Firewall-and-NAT configuration, use the access-rule priority command
available in the Firewall-and-NAT Policy Configuration Mode.
Privilege:
Security Administrator,
Administrator
Syntax
firewall priority priority [ dynamic-only | static-and-dynamic ] firewall-ruledef firewall_ruledef_name { { deny [ charging-action charging_action_name ] } | { permit [ nat-realm nat_realm_name | [ trigger
open-port { aux_port_number | range start_port_number to end_port_number } direction { both | reverse | same } ] ] } }
no firewall priority priority
no
If previously configured,
deletes the specified Stateful Firewall ruledef priority configuration
from the current rulebase.
priority
Specifies the Stateful
Firewall ruledef’s priority in the current rulebase.
priority must
be a unique value in the current rulebase, and must be an integer
from 1 through 65535.
[ dynamic-only | static-and-dynamic ] firewall-ruledef firewall_ruledef_name
Specifies the Stateful
Firewall ruledef to add to the rulebase.
Optionally, the Stateful Firewall
ruledef type can be specified.
- dynamic-only:
Firewall Dynamic Ruledef—Predefined ruledef that can be
enabled/disabled by the policy server, and is disabled
by default.
- static-and-dynamic:
Firewall Static and Dynamic Ruledef—Predefined ruledef
that can be disabled/enabled by the policy server, and
is enabled by default.
- firewall_ruledef_name must
be the name of a Stateful Firewall ruledef, and must be an alphanumeric
string of 1 through 63 characters.
deny [ charging-action charging_action_name ]
Denies packets if the
rule is matched. An optional charging action can be specified. If
a packet matches the deny rule, action is taken as configured in
the charging action. For Stateful Firewall ruledefs, only the terminate-flow
action is applicable, if configured in the specified charging action.
charging_action_name must
be the name of a charging action, and must be an alphanumeric string
of 1 through 63 characters.
permit [ nat-realm nat_realm_name | [ bypass-nat ] [ trigger
open-port { aux_port_number | range start_port_number to end_port_number } ] ]
Permits packets.
direction { both | reverse | same }
Specifies the direction
from which the auxiliary connection is initiated. This direction
can be same as the direction of control connection, or the reverse
of the control connection direction, or in both directions.
- both: Provides
the trigger to open port for traffic in either direction of the
control connection.
- reverse: Provides
the trigger to open port for traffic in the reverse direction of
the control connection (from where the connection is initiated).
- same: Provides
the trigger to open port for traffic in the same direction of the
control connection (from where the connection is initiated).
Usage:
Use this command to
add Stateful Firewall ruledefs to the rulebase and configure the
priority, type, and port triggers.
Port trigger configuration is optional. Port trigger can be configured
only if a rule action is permit.
The rulebase specifies
the Stateful Firewall rules to be applied on the calls. The ruledefs within
a rulebase have priorities, based on which priority matching is
done. Once a rule is matched and the rule action is permit, if the
trigger is configured, the appropriate check is made. The trigger
port will be the destination port of an association which matches
the rule.
Multiple triggers can
be defined for the same port number to permit multiple auxiliary ports
for subscriber traffic.
Once
a rule is matched and if the rule action is deny, the action taken
depends on what is configured in the specified charging action.
If the flow exists, flow statistics are updated and action is taken
as configured in the charging action:
- If the billing action
is configured as EDR enabled, an EDR is generated.
- If the content ID is
configured, UDR information is updated.
- If the flow action is
configured as “terminate-flow”, the flow is terminated
instead of just discarding the packet.
If the billing action,
content ID, and flow action are not configured, no action is taken
on the dropped packets.
IMPORTANT:
For Stateful Firewall
ruledefs, only the terminate-flow action is applicable if configured
in the specified charging action.
For a packet dropped
due to Stateful Firewall ruledef match or no match (first packet
of a flow), the charging action applied is the one configured in
the firewall priority or
the firewall no-ruledef-matches command
respectively.
In StarOS 8.1, in the
case of Policy-based Firewall, the charging action applied is the
one configured in the access-rule
priority or the access-rule no-ruledef-matches command respectively.
For action on packets
dropped due to any error condition after data session is created,
the charging action must be configured in the flow any-error charging-action command.
The GGSN can dynamically
activate/deactivate dynamic Stateful Firewall ruledefs
for a subscriber based on the rule name received from a policy server.
At rule match, if a rule in the rulebase is a dynamic rule, and
if the rule is enabled for the particular subscriber, rule matching is
done for the rule. If the rule is disabled for the particular subscriber,
rule matching is not done for the rule.
Example:
The following command
assigns a priority of
10 to
the Stateful Firewall ruledef
fw_rule1,
adds it to the rulebase, and permits port trigger to be used for
the rule to open ports in the range of
100 to
200 in either
direction of the control connection:
firewall priority 10
firewall-ruledef fw_rule1 permit trigger open-port range
100 to 200 direction both
The following command
configures the Stateful Firewall ruledef
fw_rule2 as
a dynamic ruledef:
firewall priority 7
dynamic-only firewall-ruledef fw_rule2 deny
firewall tcp-first-packet-non-syn
This command allows
you to configure the action to take on TCP flows starting with a
non-syn packet.
IMPORTANT:
In StarOS 8.1 and StarOS
8.3, use this command for Rulebase-based Firewall-and-NAT configuration.
In StarOS 8.1 and StarOS 9.0 and
later releases, for
Policy-based Firewall-and-NAT configuration, this command is available
in the Firewall-and-NAT Policy Configuration Mode.
Privilege:
Security Administrator,
Administrator
Syntax
firewall tcp-first-packet-non-syn { drop | reset }
default firewall tcp-first-packet-non-syn
default
Configures this command
with its default setting.
Default: drop
drop
Specifies to drop the
packet or session.
reset
Specifies to send reset.
Usage:
Use this command to
configure action to take on TCP flow starting with a non-syn packet.
Example:
The following command
configures action to take on TCP flow starting with a non-syn packet
to drop:
firewall tcp-first-packet-non-syn drop
firewall tcp-idle-timeout-action
This command allows
you to configure the Stateful Firewall action to be taken on TCP
idle timeout expiry.
IMPORTANT:
In StarOS 8.1 and StarOS
8.3, use this command for Rulebase-based Firewall-and-NAT configuration.
In StarOS 8.1 and StarOS 9.0 and
later releases, for
Policy-based Firewall-and-NAT configuration, this command is available
in the Firewall-and-NAT Policy Configuration Mode.
Privilege:
Security Administrator,
Administrator
Syntax
firewall tcp-idle-timeout-action { drop | reset }
default firewall tcp-idle-timeout-action
default
Configures this command
with its default setting.
Default: reset
drop
Specifies to drop the
packet or session on TCP timeout expiry.
reset
Specifies
to send reset on TCP timeout expiry.
Usage:
Use this command to
configure action to take on TCP idle timeout expiry.
Example:
The following command
configures action to take on TCP idle timeout expiry to drop:
firewall tcp-idle-timeout-action drop
firewall tcp-reset-message-threshold
This command allows
you to configure a threshold on the number of TCP reset messages
sent by the subscriber for a particular data flow. After this threshold
is reached, further downlink traffic to the subscriber on the unwanted
flow is blocked.
IMPORTANT:
This command is only
available in StarOS 8.3 and later releases. In StarOS 8.3, use this
command for Rulebase-based Firewall-and-NAT configuration. In StarOS 9.0 and later
releases, for Policy-based Firewall-and-NAT configuration, this command
is available in the Firewall-and-NAT Policy Configuration Mode.
Privilege:
Security Administrator,
Administrator
Syntax
firewall tcp-reset-message-threshold messages then-block-server
{ default | no } firewall
tcp-reset-message-threshold
default
Configures this command
with its default setting.
Default: no firewall tcp-reset-message-threshold
no
If previously configured,
deletes the firewall tcp-reset-message-threshold configuration from the
current rulebase.
messages
Specifies the threshold
on the number of TCP reset messages sent by the subscriber for a particular
data flow.
messages must
be an integer from 1 through 100.
Usage:
Use this command to
configure a threshold on the number of TCP reset messages sent by the
subscriber for a particular data flow. After the threshold is reached,
assuming the server is not reacting properly to the reset messages
further downlink traffic to the subscriber on the unwanted flow
is blocked. This configuration enables QCHAT noise suppression for TCP.
Example:
The following command
sets the threshold on the number of TCP reset messages to
10:
firewall tcp-reset-message-threshold
10 then-block-server
firewall tcp-syn-flood-intercept
This command allows
you to configure the TCP intercept parameters to prevent TCP SYN
flooding attacks by intercepting and validating TCP connection requests
for DoS protection mechanism configured with the dos-protection command.
IMPORTANT:
In StarOS 8.0, this
command is available in the ACS Configuration Mode. In StarOS 8.1
and StarOS 8.3, use this command for Rulebase-based Firewall-and-NAT
configuration. In StarOS 8.1 and
StarOS 9.0 and later releases, for
Policy-based Firewall-and-NAT configuration, this command is available
in the Firewall-and-NAT Policy Configuration Mode.
Privilege:
Security Administrator,
Administrator
Syntax
firewall tcp-syn-flood-intercept { mode { none | watch [ aggressive ] } | watch-timeout intercept_watch_timeout }
default firewall tcp-syn-flood-intercept { mode | watch-timeout }
default
Sets the default values
of TCP intercept parameters for SYN Flood DoS protection.
mode { none | watch [ aggressive ] }
Specifies the TCP SYN
flood intercept mode:
- none: Disables
TCP SYN flood intercept feature.
- watch: Configures
TCP SYN flood intercept feature in watch mode. Stateful Firewall
passively watches to see if TCP connections become established within
a configurable interval. If connections are not established within
the timeout period, Stateful Firewall clears the half-open connections
by sending RST to TCP client and server. The default watch-timeout
for connection establishment is 30 seconds.
- aggressive:
Configures TCP SYN flood Intercept or Watch feature for aggressive
behavior. Each new connection request causes the oldest incomplete connection
to be deleted. When operating in watch mode, the watch timeout is
reduced by half. If the watch-timeout is 30 seconds, under aggressive
conditions it becomes 15 seconds. When operating in intercept mode,
the retransmit timeout is reduced by half (i.e. if the timeout is
60 seconds, it is reduced to 30 seconds). Thus the amount of time
waiting for connections to be established is reduced by half (i.e.
it is reduced to 150 seconds from 300 seconds under aggressive conditions).
Default: none
watch-timeout intercept_watch_timeout
Specifies the TCP intercept
watch timeout, in seconds.
intercept_watch_timeout must
be an integer from 5 through 30.
Default: 30
Usage:
This TCP intercept functionality
provides protection against TCP SYN Flooding attacks.
The system captures
TCP SYN requests and responds with TCP SYN-ACKs. If a connection
initiator completes the handshake with a TCP ACK, the TCP connection
request is considered as valid by system and system forwards the
initial TCP SYN to the valid target which triggers the target to
send a TCP SYN-ACK. Now system intercepts with TCP SYN-ACK and sends
the TCP ACK to complete the TCP handshake. Any TCP packet received before
the handshake completion will be discarded.
Example:
The following command
sets the TCP intercept watch timeout setting to
5 seconds:
firewall tcp-syn-flood-intercept
watch-timeout 5
flow any-error
This command allows
you to specify the charging action to be used for packets dropped
by Stateful Firewall due to any error conditions.
Privilege:
Security Administrator,
Administrator
Syntax
flow any-error charging-action charging_action_name
default flow any-error
default
Configures the default
action for packets dropped by Stateful Firewall due to any errors.
Default: Update the
flow statistics if flow is available
charging_action_name
Specifies the charging
action based on which accounting action is taken on packets dropped by
Stateful Firewall due to any errors.
charging_action_name must
be the name of a charging action, and must be an alphanumeric string
of 1 through 63 characters.
IMPORTANT:
The charging action
specified here should preferably not be used for action on packets dropped
due to Stateful Firewall ruledef match or no-match (in the firewall priority and firewall no-ruledef-matches commands)
and the content ID within the charging action must be unique so
that dropped counts will not interfere with other content IDs.
Usage:
Use this command to
configure the charging action for packets dropped by Stateful Firewall
due to any error conditions, such as, a packet being inappropriate
based on the state of the protocol of the packet's session, or DoS
protection causing the packet to be discarded, and so on.
For a packet dropped
due to Stateful Firewall ruledef match or no match (first packet
of a flow), the charging action applied is the one configured in
the firewall priority or
the firewall no-ruledef-matches command
respectively.
In StarOS 8.1, in the
case of Policy-based Firewall, the charging action applied is the
one configured in the access-rule
priority or the access-rule no-ruledef-matches command respectively.
For a packet dropped
due to any error condition after data session is created, the charging action
used is the one configured in the flow any-error charging-action command.
If the charging action
applied on a packet is the one specified in the flow any-error charging-action command,
flow statistics are updated and action is taken as configured in
the charging action:
- If the billing action
is configured as EDR enabled, an Event Data Record (EDR) is generated.
- If the content ID is
configured, Usage Data Record (UDR) information is updated.
- If the flow action is
configured as “terminate-flow”, the flow is terminated
instead of just discarding the packet.
If the billing action,
content ID, and flow action are not configured, no action is taken
on the dropped packets.
Example:
The following command
specifies the charging action
test2 for accounting
action on packets dropped/discarded by Stateful Firewall
due to any error:
flow any-error charging-action test2
flow control-handshaking
This command allows
you to specify how to charge for the control traffic associated
with an application.
Privilege:
Security Administrator,
Administrator
Syntax
flow control-handshaking { charge-to-application { [ all-packets ] [ initial-packets ] [ mid-session-packets ] [ tear-down-packets ] } | charge-separate-from-application }
default flow control-handshaking
no flow control-handshaking [ charge-to-application ]
default flow control-handshaking
Configures this command
with its default setting.
Default: Same as no flow control-handshaking
no flow control-handshaking [ charge-to-application ]
If previously configured,
deletes the flow control-handshaking configuration from the current
rulebase. The control packets will use whatever content-id is determined
by the normal use of the action commands.
In this command, the
optional keyword charge-to-application is
deprecated and has no effect.
charge-to-application { [ all-packets ] [ initial-packets ] [ mid-session-packets ] [ tear-down-packets ] }
Configures the charging
action to include the flow control packets either during initial handshaking
only or specified control packets during session for charging.
- all-packets:
Specifies that the initial setup packets will wait until the application
has been determined before assigning the content-id, and all mid-session
ACK packets as well as the final tear-down packets will use that
content-id.
- initial-packets:
Specifies that only the initial setup packets will wait for content-id
assignment.
- mid-session-packets:
Specifies that the ACK packets after the initial setup will use
the application's or content-id assignment.
- tear-down-packets:
Specifies that the final tear-down packets (TCP or WAP) will use
the application's or content-id assignment.
charge-separate-from-application
Configures the charging
action to separate the charging of the initial control packets or
all subsequent control packets from regular charging.
Usage:
Use this command to
configure how to charge for the control traffic associated with
an application ruledef. Applications like HTTP use TCP to set up
and tear down connections before the HTTP application starts. This
command controls whether the packets that set up and tear down the
connections should use the same content ID as the application's
flow.
In normal mode 3-way
handshake TCP packets (SYN, SYN-ACK, and ACK) and closing or intermittent
packets (FIN, RST, etc.) directed and charged based on configured
matched rules. This command makes the system to wait for the start
and stop of layer 7 packet flow and content ID and charge the initial,
intermittent, and closing TCP packets as configured to the same
matching rules and content ID as of the flow.
This command also affects
applications that do not use TCP but use other methods for control
packets, for example WAP, where WTP/UDP may be used to
set up and tear down connection-oriented WSP.
Example:
Following command enables
the charging for initial TCP handshaking control packets and wait
for content-id of data traffic flow:
flow control-handshaking
charge-to-application initial-packets
The following command
enables charging all mid-session ACKs as well as tear-down packets
to application:
flow control-handshaking
charge-to-application mid-session-packets tear-down-packets
flow end-condition
This command allows
you to configure the end condition of the session flows related
to a user session and triggers EDR generation.
Privilege:
Security Administrator,
Administrator
Syntax
In StarOS 12.1 and
earlier releases:
flow end-condition { { content-filtering | normal-end-signaling | timeout + } | { { hagr | handoff | session-end } [ flow-overflow ] + } [ url-blacklisting ] } edr edr_format_name
no flow end-condition
no
If previously configured,
deletes the flow end-condition configuration from the current rulebase.
content-filtering
Creates an EDR with
the specified EDR format whenever a flow ends due to Category-based Content
Filtering in-line service action. Possible actions include redirect-url,
terminate-flow, content-insert.
hagr
Creates an EDR with
the specified EDR format whenever a flow is terminated due to Inter-chassis
Session Recovery action.
handoff
Creates an EDR with
the specified EDR format whenever a flow ends due to hand-off. Whenever
a handoff occurs, ACS closes the EDRs for all current flows using
the specified EDR format, and begins new statistics collection for
the flows for the EDRs that will be generated when the flows actually
end.
normal-end-signaling
Creates an EDR with
the specified EDR format whenever flow end is signaled normally,
for example like detecting FIN and ACK for a TCP flow, or a WSP-DISCONNECT
terminating a connection-oriented WSP flow over UDP) and create
an EDR for the flow using the specified EDR format.
session-end
Creates an EDR with
the specified EDR format whenever a subscriber session ends. By
this option ACS creates an EDR with the specified format name for
every flow that has had any activity since last EDR was created
for the flow on session end.
url-blacklisting
Creates an EDR with
the specified EDR format whenever flow ends due to URL Blacklisting
action.
timeout
Creates an EDR with
the specified EDR format whenever a flow ends due to a timeout condition.
flow-overflow
IMPORTANT:
This keyword is
only available in StarOS
8.3 and later releases. And, is only applicable when used with
the
hagr,
handoff, and
session-end keywords.
Creates an EDR with
the specified EDR format whenever there is a flow-overflow condition. If
any of the specified end-conditions that affect subscriber information
stored at ACS (such as call line) is configured, the “flow-overflow” EDR
is generated.
+
Indicates that more
than one of the keywords can be entered within a single command.
edr edr_format_name
Specifies the EDR format
to record EDR for specified flow end condition.
edr_format_name must
be the name of an EDR format, and must be a unique alphanumeric
string of 1 through 63 characters.
Usage:
Use this command to
enable or disable the capturing of EDRs based on flow end condition.
Example:
In 12.1 and earlier
releases, the following command configures the flow end condition
as “handoff” and creates a charging EDR with format
named
EDR_format1:
flow end-condition
handoff edr-format EDR_format1
flow limit-across-applications
This command allows
you to limit the total number of simultaneous flows per Subscriber/APN
sent to a rulebase regardless of the flow type, or limit flows based
on the protocol type under the Session Control feature.
Privilege:
Security Administrator,
Administrator
Syntax
flow limit-across-applications { limit | non-tcp limit | tcp limit }
no flow limit-across-applications [ non-tcp | tcp ]
no
If previously configured,
deletes the flow limit-across-applications configuration from the current
rulebase.
flow limit-across-applications limit
Specifies the maximum
number of flows across all applications for the rulebase.
limit must
be an integer from 1 through 4000000000.
Default: No limits
non-tcp limit
Specifies the maximum
limit of non-TCP type flows.
limit must
be an integer from 1 through 4000000000.
Default: No limits
tcp limit
Specifies the maximum
limit of TCP flows.
limit must
be an integer from 1 through 4000000000.
Default: No limits
Usage:
Use this command to
limit the total number of flows allowed for a rulebase regardless
of flow type, or limit flows based on the protocol—non-TCP
(connection-less) or TCP (connection-oriented).
If a subscriber attempts
to exceed these limits system discards the packets of new flow. This
limit processing of this command has following aspects for UDP,
TCP, ICMP and some of the exempted flows:
- UDP/ICMP: System
waits for the flow timeout before updating the counter and removing
it from the count of number of flows.
- TCP: After a TCP flow
ends, system waits for a short period of time to accommodate the
retransmission of any missed packet from one end. TCP flows those
are ended, but are still in wait period for timeout are exempted
for this limit processing.
- Exempted flows: System
exempts all the other flows specified with the flow limit-for-flow-type command
in the ACS Charging Action Configuration Mode set to no.
Example:
The following command
defines the maximum number of
200000 flows
for the rulebase:
flow limit-across-applications 200000
fw-and-nat default-policy
This command allows
you to configure the default Firewall-and-NAT policy for the current
rulebase. This command must be used to configure the Policy-based
Firewall-and-NAT feature.
IMPORTANT:
This command is only
available in StarOS 8.1
and
StarOS 9.0 and later releases.
Privilege:
Security Administrator,
Administrator
Syntax
fw-and-nat default-policy fw_nat_policy_name
no fw-and-nat default-policy
no
If previously configured,
deletes the Firewall-and-NAT default policy configuration from the current
rulebase.
fw_nat_policy_name
Specifies the default
Firewall-and-NAT policy for the current rulebase.
fw_nat_policy_name must
be the name of a Firewall-and-NAT policy, and must be an alphanumeric
string of 1 through 63 characters.
Usage:
Use this command to
configure the default Firewall-and-NAT policy for a rulebase.
For subscribers using
the current rulebase, the default Firewall-and-NAT policy will be used
if in the APN/subscriber profile the default fw-and-nat policy command
is configured, and a policy to use is not received from the AAA/OCS.
For more information,
see the Personal Stateful
Firewall Administration Guide.
Example:
The following command
configures a Firewall-and-NAT policy named
standard to
the rulebase:
fw-and-nat default-policy standard
http header-parse-limit
This command allows
you to configure the HTTP header parse limit, on exceeding which
the flow is marked as permanent failure and is matched and charged
against http error = TRUE ruledef.
IMPORTANT:
This command is customer
specific. For more information contact your Cisco account representative.
Privilege:
Security Administrator,
Administrator
Syntax
http header-parse-limit parse_limit_bytes
{ default | no } http
header-parse-limit
default
Configures the default
setting for this command.
Default: 12000 bytes
no
If enabled, disables
the header-parse-limit configuration in the current rulebase.
CAUTION:
Disabling header parse
limit may lead to uncharged bytes (due to no rule-matching until header
is complete) if header is not correctly terminated.
parse_limit_bytes
Specifies the header-parse-limit,
number of bytes.
parse_limit_bytes must
be an integer from 1 through 256000.
Usage:
If a user sends HTTP
LF terminated traffic instead of the usual HTTP CRLF terminated traffic,
and similarly the server is responding with LF terminated traffic,
the traffic does not result in any rule match, and rule match happens
only at flow idle or at call clear when the quota for the same is
not requested/updated. This results in a revenue hole for
prepaid subscribers.
For operators who have
Stateful Firewall in-line service enabled, and are okay if packets are
dropped, a workaround is to configure the firewall mime-flood command
in the ACS Configuration Mode, which enables to configure the maximum
number of headers allowed in an HTTP packet and the maximum header
field size allowed in the HTTP header (in bytes). However, a limitation
of this workaround is that Stateful Firewall supports MIME flood
detection only in the downlink direction.
The support for LF
termination has been added in StarOS 14.0 and later releases. For
this release, with the help of configurable maximum header length
support, HTTP analyzer would be allowing such LF terminated HTTP
request/responses to pass through without rule matching only
until the configured maximum header length is reached. When this
threshold is reached, immediately the analyzer marks such HTTP session
as failure and rule match would occur for http error = TRUE for
the current packet as well as for all the previous packets that
passed through unmatched. At this point, the quota for all such
packets will be requested and reported.
Example:
The following command
sets the HTTP header parse limit to
10000 bytes:
http header-parse-limit 10000
ip reassembly-timeout
This command allows
you to configure how long to hold onto IP fragments for reassembly,
while waiting for the complete packet to arrive.
Privilege:
Security Administrator,
Administrator
Syntax
ip reassembly-timeout timeout_duration
default ip reassembly-timeout
default
Configures the default
setting for this command.
Default: 5000 milliseconds
timeout_duration
Specifies the timeout
duration, in milliseconds, to hold fragmented packets before reassembly.
timeout_duration must
be an integer from 100 through 30000.
Usage:
Use this command to
configure duration for timeout timer to hold IP fragmented packets before
reassembly is needed.
IP fragmented packet
are retained, until either all fragmented packets have been received or
the configured timeout has expired for the oldest fragment. If all
fragments have been received, a temporary complete packet is reconstructed
for analysis. Then all fragments are forwarded in order from first
to last. If all fragments are not received, the fragments will be forwarded
without being passed through the protocol analyzers, except for
the IP analyzer.
Example:
The following command
sets the timeout timer to
15000 milliseconds:
ip reassembly-timeout 15000
ip reset-tos
This command allows
you to reset the IP Type of Service (ToS) value of incoming packets
to zero, before proceeding with the rest of ACS processing.
Privilege:
Security Administrator,
Administrator
Syntax
[ default | no ] ip
reset-tos
default
Configures this command
with its default setting.
Default: Disabled
no
If previously configured,
deletes the IP reset-tos configuration from the current rulebase.
Usage:
Use this command to
reset the ToS field of any packet after it reaches ACS, or to broaden the
range of values that are used in the ToS field in the IP header
of any packet.
nat binding-record
This command allows
you to configure NAT Binding Record (NBR) generation.
IMPORTANT:
This command is only
available in StarOS 8.3. In
StarOS 9.0 and later releases this command is available in the Firewall-and-NAT
Policy Configuration Mode.
Privilege:
Security Administrator,
Administrator
Syntax
nat binding-record edr-format edr_format_name [ port-chunk-allocation ] [ port-chunk-release ] +
{ default | no } nat
binding-record
default
Configures this command
with its default setting.
Default: port-chunk-release
no
If previously configured,
deletes the configuration from the current rulebase.
edr-format edr_format_name
Specifies the EDR format.
edr_format_name must
be the name of an EDR format, and must be an alphanumeric string
of 1 through 63 characters.
port-chunk-allocation
Specifies generating
NBR when a port chunk is allocated.
port-chunk-release
Specifies generating
NBR when a port chunk is released.
+
Indicates that more
than one of the previous keywords can be entered within a single command.
Usage:
Use this command to
configure NBR generation.
Example:
The following command
configures an EDR format named
test123 and
specifies generating NBR when a port chunk is allocated, and when
a port chunk is released:
nat binding-record
edr-format test123 port-chunk-allocation port-chunk-release
nat policy
This command allows
you to enable/disable Network Address Translation (NAT) processing
for all subscribers using the current rulebase.
IMPORTANT:
In StarOS 8.1 and StarOS 9.0 and
later releases, for
Policy-based Firewall-and-NAT, this command is available in the
Firewall-and-NAT Policy Configuration Mode.
IMPORTANT:
Before enabling NAT
processing for a subscriber, Stateful Firewall must be enabled for
the subscriber. See the
firewall policy CLI
command.
Privilege:
Security Administrator,
Administrator
Syntax
nat policy nat-required [ default-nat-realm nat_realm_name ]
{ default | no } nat policy
default
Configures
this command with its default setting.
Default:
NAT processing is disabled for all subscribers using the current rulebase.
no
If previously enabled,
disables NAT processing for all subscribers using the current rulebase.
nat policy nat-required
Enables NAT processing
for all subscribers using the current rulebase.
default-nat-realm nat_realm_name
IMPORTANT:
This keyword is only
available in StarOS 8.3 and later releases.
Specifies the default
NAT realm to be used if one is not already configured.
nat_realm_name must
be the name of a NAT realm, and must be an alphanumeric string of
1 through 31 characters.
IMPORTANT:
Including the default
NAT realm, a maximum of three NAT realms are supported.
Usage:
Use this command to
enable/disable NAT processing for all subscribers using
the current rulebase.
After
NAT is enabled for a subscriber, the NAT IP address to be used is
chosen from the NAT realms defined in the rule priority lines within
the rulebase. See the
firewall priority CLI
command.
NAT enable/disable
status in the rulebase can be changed any time, however the changed NAT
status will not be applied for active calls using the rulebase.
The new NAT status is only applied to new calls.
Example:
The following command
enables NAT processing:
nat policy nat-required
The following command
disables NAT processing:
no nat policy
nat suppress-aaa-update
call-termination
This command allows
you to suppress sending NAT Bind Updates (NBU) to the AAA server
when a call gets terminated.
IMPORTANT:
This command is customer-specific.
For more information please contact your Cisco account representative. In release 9.0, this
command is available in the Firewall-and-NAT Policy Configuration
Mode.
Privilege:
Security Administrator,
Administrator
Syntax
nat suppress-aaa-update
call-termination
default nat suppress-aaa-update
default
Configures this command
with its default setting.
Default:
Disabled. No suppression of AAA updates.
Usage:
Use this command to
suppress the sending of NAT Bind Updates (NBU) to the AAA server
when the call gets terminated, as these NBUs would be cleared at
the AAA after receiving the accounting-stop. This enables to minimize
the number of messages between the chassis and AAA server. When
not configured, NBUs are sent to the AAA server whenever a port
chunk is allocated, de-allocated, or the call is cleared (PPP disconnect).
Example:
The following command
suppresses the sending of NBU to the AAA server when PPP disconnect
happens:
nat suppress-aaa-update
call-termination
p2p dynamic-flow-detection
This command allows
you to enable/disable the P2P analyzer to detect peer-to-peer
(P2P) applications.
Privilege:
Security Administrator,
Administrator
Syntax
[ default | no ] p2p
dynamic-flow-detection
default
Configures this command
with its default setting.
Default: Disabled
no
If previously enabled,
disables P2P dynamic flow detection in the current rulebase.
p2p dynamic-flow-detection
Enables dynamic P2P
flow detection.
Usage:
Use this command to
enable dynamic-flow detection. This allows the P2P analyzer to detect
the P2P applications configured for the ACS.
post-processing dynamic
This command allows
you to specify ruledefs/group-of-ruledefs as dynamic post-processing
ruledefs/group-of-ruledefs. This allows the system to differentiate
normal post-processing rules from preconfigured ones. By default,
this configuration is disabled.
Privilege:
Security Administrator,
Administrator
Syntax
post-processing dynamic { group-of-ruledefs ruledefs_group_name | ruledef ruledef_name } charging-action charging_action_name [ description description ]
no post-processing dynamic { group-of-ruledefs ruledefs_group_name | ruledef ruledef_name }
no
If previously configured,
deletes the specified configuration from the current rulebase.
group-of-ruledefs ruledefs_group_name
Adds the specified group-of-ruledefs
to the current rulebase.
ruledefs_group_name must
be the name of a group-of-ruledefs, and must be an alphanumeric
string of 1 through 63 characters.
ruledef ruledef_name
Adds the specified ruledef
to the current rulebase.
ruledef_name must
be the name of a ruledef, and must be an alphanumeric string of
1 through 63 characters.
charging-action charging_action_name
Specifies the charging
action.
charging_action_name must
be the name of a charging action, and must be an alphanumeric string
of 1 through 63 characters.
description description
Specifies an optional
description for this configuration.
description must
be an alphanumeric string of 1 through 31 characters.
Usage:
Use this command to
configure specific ruledefs/group-of-ruledefs as dynamic
post-processing ruledefs/group-of-ruledefs. This allows
the system to differentiate normal post-processing rules from the
preconfigured ones. This makes possible enabling/disabling
ruledefs/groups-of-ruledefs entry from an external server.
Example:
The following command
specifies the ruledef named
test_rule as
a dynamic post-processing ruledef configured with the charging action
ca13 and a
description of
testing:
post-processing dynamic
ruledef test_rule charging-action ca13 description testing
post-processing policy
This command allows
you to specify the post-processing policy to be applied on Limit-Reached
packets.
Product:
GGSN, PDSN, P-GW
Privilege:
Security Administrator,
Administrator
Syntax
post-processing policy { always | not-for-dynamic-discard }
default post-processing policy
default
Configures this command
with its default setting.
Default: not-for-dynamic-discard
always
Specifies to apply post-processing
even if the Credit Control Application (CCA) decides to discard
packets due to limit-reached condition. If there are post-processing
priority-based rules, CCA will check for any redirection rules.
Otherwise, by default, CCA will discard the packets. No other post-processing
actions like forward, next-hop, or xheader-insertion will be applied
on the limit-reached packets.
not-for-dynamic-discard
Specifies to apply post-processing
only if CCA decides not to discard packet. Will directly discard
the limit-reached context and will not apply post-processing priority
based rules.
Usage:
This command allows
to enable post-processing priority based rules for content in blacklisted
state. Whenever RADIUS/Diameter prepay server blacklists
content the packets are generally discarded. To enable redirection
of such content, post-processing should be enabled on the blacklisted
content. With this command, RADIUS/Diameter Credit-Control
application will decide whether to allow post-processing to be enabled
or not for the blacklisted content.
The following is a
sample configuration:
configure
active-charging service service1
ruledef http_low
http any-match = TRUE
cca quota-state = limit-reached
rule-application
post-processing
#exit
ruledef httpany
http any-match = TRUE
#exit
charging-action standard1
content-id 1
cca charging
credit
#exit
charging-action
redirect
flow action redirect-url http://aoc.com
#exit
rulebase base1
action priority 30 ruledef httpany
charging-action standard1
post-processing
policy always
post-processing
priority 1 ruledef
http_low charging-action redirect
#exit
end
Example:
The following command
will enable post processing on Limit-Reached packets:
post-processing policy always
post-processing priority
This command allows
you to configure the post-processing priority and action to be taken
on specific ruledef in the current rulebase.
IMPORTANT:
This command is only
available in StarOS 8.3 and later releases.
Privilege:
Security Administrator,
Administrator
Syntax
post-processing priority priority { group-of-ruledefs ruledefs_group_name | ruledef ruledef_name } charging-action charging_action_name [ description description ]
no post-processing priority priority
no
If previously configured,
deletes the specified post-processing priority configuration from the
current rulebase.
priority priority
Specifies priority for
the ruledef
/group-of-ruledefs in
the current rulebase.
priority must
be a unique value in the current rulebase, and must be an integer
from 1 through 65535.
group-of-ruledefs ruledefs_group_name
Specifies the group-of-ruledefs.
ruledefs_group_name must
be the name of a group-of-ruledefs, and must be an alphanumeric
string of 1 through 63 characters.
IMPORTANT:
The group-of-ruledefs
specified must be configured for post-processing. See the group-of-ruledefs-application command
in the ACS Group-of-Ruledefs Configuration mode.
ruledef ruledef_name
Specifies the ruledef.
ruledef_name must
be the name of a ruledef, and must be an alphanumeric string of
1 through 63 characters.
IMPORTANT:
The ruledef specified
must be configured for post-processing. See the rule-application command
in the ACS Ruledef Configuration
Mode Commands chapter.
charging-action charging_action_name
Specifies the charging
action.
charging_action_name must
be the name of a charging action, and must be an alphanumeric string
of 1 through 63 characters.
description description
Specifies an optional
description for this configuration.
description must
be an alphanumeric string of 1 through 31 characters.
Usage:
Use this command to
configure the post-processing priority and action to be taken on
a ruledef in the rulebase.
Example:
The following command
configures the ruledef named
test_ruledef with
a priority of
10,
and the charging action named
test_ca for
post processing:
post-processing priority
10 ruledef test_ruledef charging-action test_ca
qos-renegotiate timeout
This command allows
you to configure the timeout setting for the Quality of Service
(QoS) Renegotiation feature.
IMPORTANT:
This command is license
dependent. For more information contact your Cisco account representative.
Privilege:
Security Administrator,
Administrator
Syntax
qos-renegotiate timeout timeout
no qos-renegotiate timeout
no
If previously configured,
deletes the qos-renegotiate timeout configuration from the current rulebase.
timeout
Specifies the timeout
period for the QoS Renegotiation feature in the current rulebase.
timeout is
the timeout period in seconds, and must be an integer from 0 through
4294967295. If set to 0, timeout is disabled.
Usage:
Use this command to
configure timeout setting for the QoS Renegotiation feature.
Example:
The following command
sets the QoS renegotiate timeout period to 1000 seconds:
qos-renegotiate timeout 1000
radius threshold
This command allows
you to configure the interval and volume thresholds to generate
interim RADIUS Charging Data Records (CDRs) and write them to CDR
file for ACS postpaid billing.
Privilege:
Security Administrator,
Administrator
Syntax
radius threshold { interval interval | volume total volume }
{ default | no } radius
threshold { interval | volume total }
no
If previously configured,
deletes the RADIUS threshold configuration from the current rulebase.
default
Configures this command
with the default settings.
Default: Disabled
interval interval
Specifies the time
interval, in seconds, for generating RADIUS interim accounting requests.
interval must
be an integer from 60 through 40000000.
Default: Disabled
volume total volume
Specifies the limit
for the total number of octets (uplink+downlink) after
which a stop-start pair will be sent to RADIUS.
volume must
be an integer from 100000 through 4000000000.
Default: Disabled
Usage:
Use this command to
specify a time interval threshold to generate interim RADIUS CDRs and
write it to RADIUS CDR file for postpaid billing.
Example:
The following command
configures a time threshold interval of
600 seconds
for RADIUS CDRs:
radius threshold interval 600
route priority
This command allows
you to configure the routing of packets to protocol analyzers.
Privilege:
Security Administrator,
Administrator
Syntax
route priority route_priority ruledef ruledef_name analyzer { dns | file-transfer | ftp-control | ftp-data | h323 | http | imap | mms | p2p | pop3 | pptp | rtcp | rtp | rtsp | sdp | secure-http | sip [ advanced ] | smtp | tftp | wsp-connection-less | wsp-connection-oriented } [ description description ]
no route priority route_priority
no
If previously configured,
deletes the specified route priority configuration from the current rulebase.
route priority route_priority
Specifies the route
priority for the specified ruledef in the current rulebase.
route_priority must
be an integer from 1 through 65535.
Lower numbered priorities
are examined first. Up to 1024 instances can be configured across
all rulebases.
ruledef ruledef_name
Specifies the ruledef
to evaluate packets to determine analyzer.
ruledef_name specifies
the name of the ruledef configured for the route application using
the rule-application command
in the ACS Ruledef Configuration Mode.
ruledef_name must
be the name of a ruledef, and must be an alphanumeric string of
1 through 63 characters.
analyzer
Specifies the analyzer
for the ruledef, and must be one of the following:
- dns: Route
to DNS protocol analyzer.
- file-transfer:
Route to file analyzer.
- ftp-control:
Route to FTP control protocol analyzer.
- ftp-data:
Route to FTP data protocol analyzer.
-
h323: Route
to H323 protocol analyzer.
- http: Route
to HTTP protocol analyzer.
- imap: Route
to IMAP protocol analyzer.
- mms: Route
to MMS protocol analyzer.
- p2p: Route
to the P2P protocol analyzer.
- pop3: Route
to POP3 protocol analyzer.
-
pptp: Route
to PPTP protocol analyzer.
- rtcp: Route
to RTCP protocol analyzer.
- rtp: Route
to RTP protocol analyzer.
- rtsp: Route
to RTSP protocol analyzer.
- sdp: Route
to SDP protocol analyzer.
- secure-http:
Route to secure HTTP protocol analyzer.
- sip [ advanced ]:
Route to SIP protocol analyzer.
advanced:
For SIP calls to work with NAT/Stateful Firewall, a SIP
Application-Level Gateway (ALG) is required to do payload translation of
SIP packets and pin-hole (dynamic flow) creation for media packets.
A SIP routing rule must to be configured for routing the packets
to the SIP ALG for processing. If the keyword advanced is
configured, the packets matching the routing rule will be routed
to SIP ALG for processing and not to ACS SIP analyzer. If not configured,
then packets will not be routed to SIP ALG and will be routed to
ACS SIP analyzer for processing.Also, see firewall nat-alg CLI
command in the ACS Configuration Mode.
-
tftp: Route
to TFTP protocol analyzer.
- smtp: Route
to SMTP protocol analyzer.
- wsp-connection-less:
Route to WSP connection-less protocol analyzer.
- wsp-connection-oriented:
Route to WSP connection-oriented protocol analyzer.
IMPORTANT:
To route packets to
the P2P analyzer, the ruledef should have rules to match all IP
packets. Otherwise, the analyzer may not detect all P2P traffic.
IMPORTANT:
Use the show active-charging
analyzer statistics command in the Exec Mode to see the
list of supported analyzers.
description description
Enables to add a description
to the rule and action for later reference in saved configuration file.
description must
be an alphanumeric string of 1 through 63 characters.
Usage:
Instances of this CLI
command control which packets are routed to which protocol analyzers.
Packets sent to ACS are always passed through the IP protocol analyzer.
This CLI command controls which higher layer analyzers are also
invoked.
Analyzer |
Common
ways to route to the analyzer |
ip
|
All IPv4 packets are
automatically routed here.
|
icmp
|
All IPv4 packets with
IP protocol = ICMP (1) are automatically routed here.
|
tcp
|
All IPv4 packets with
IP protocol = TCP (6) are automatically routed here.
|
udp
|
All IPv4 packets with
IP protocol = UDP (17) are automatically routed here.
|
dns
|
UDP destination port
or source port is DNS (53).
|
http
|
TCP destination port
or source port is HTTP (80).
|
secure-http
|
TCP destination port
or source port is HTTPS (443). Note that HTTP may use the CONNECT
method (see RFC 2817), in which case, the subscriber will be upgraded with
transport layer security, but the traffic to/from the chassis
will still be HTTP and be passed through the http rather than the
secure-http analyzer (assuming that routing to the http analyzer
has been configured).
|
wsp
|
UDP destination port
or source port is connection-less WSP (9200) or connection-oriented
WSP (9201).
|
wtp
|
Packets are automatically
routed here, if you specified “wsp-connection-oriented” as
described above.
|
wap2
|
TCP destination port
or source port of the carrier-specific port number for WAP-2 (e.g.
one carrier uses 8799); or, send all HTTP traffic to the wap2 analyzer if the
carrier does not use a special port number.
|
ftp
|
TCP destination port
or source port is FTP control (21) or FTP data (20); or, ftp analyzer
(for FTP control packets) dynamically detected an FTP data flow
over TCP (tcp dynamic-flow = ftp-data).
|
file-transfer
|
FTP and the command
name is retr or stor; or, HTTP
and the request method is get or post.
|
mms
|
WSP content type is
application/vnd.wap.mms-message;
or, WSP uri contains “mms”;
or, HTTP content type is application/vnd.wap.mms-message;
or, HTTP uri contains “mms”.
|
sip
|
UDP destination port
or source port is SIP (5060).
|
sdp
|
RTSP or SIP content
type is application/sdp
|
smtp
|
TCP destination port
or source port is SMTP (25).
|
imap
|
TCP destination port
or source port is IMAP (143).
|
pop3
|
TCP destination port
or source port is POP3 (110).
|
rtp and rtcp
|
RTSP has embedded RTP/RTCP
payloads (you need to enable RTP dynamic flow detection to catch
those flows); or, RTSP or SDP (for SDP within SIP) creates an RTP/RTCP
flow over UDP (in addition to enabling the aforementioned dynamic
flow detection, you must make sure that UDP packets are routed to
the UDP analyzer) or, RTP/RTCP uses predefined UDP port
numbers (e.g. default UDP port numbers of 5004/5005).
|
rtsp
|
TCP destination port
or source port is RTSP (554).
|
p2p
|
Use the p2p dynamic-flow-detection CLI command
to enable detection of the different P2P applications specified
by the p2p application CLI
command; that will cause every TCP or UDP packet to be automatically
routed here
|
Example:
The following command
assigns a route and rule action with the route priority of 23, a ruledef
named
test,
and an analyzer
test_analyzer with
description as
route_test1 to
the current rulebase:
route priority 23 ruledef
test analyzer test_analyzer description route_test1
rtp dynamic-flow-detection
This command allows
you to enable/disable the Real Time Streaming Protocol (RTSP)
and Session Description Protocol (SDP) analyzers to detect the start/stop
of RTP and RTCP flows.
Privilege:
Security Administrator,
Administrator
Syntax
[ default | no ] rtp
dynamic-flow-detection
default
Configures this command
with its default setting.
Default: Disabled;
same as no rtp
dynamic-flow-detection.
no
If previously configured,
deletes this configuration from the current rulebase.
Usage:
Use this command to
enable the RTSP and SDP analyzer to detect the start/stop
of RTP and RTCP flows. This command is used in conjunction with
the route priority command.
Example:
The following command
enables RTP dynamic flow detection:
rtp dynamic-flow-detection
ruledef-parsing
This command allows
you to configure whether to consider or ignore the port number embedded
in the application header (for example, the ":80" in www.star.com:80)
when comparing the ruledef expressions to the packet contents.
Privilege:
Security Administrator,
Administrator
Syntax
[ no ] ruledef-parsing
ignore-port-numbers-embedded-in-application-headers analyzers { http
rtsp sip wsp }
default ruledef-parsing
no
If previously configured,
deletes the ruledef-parsing configuration from the current rulebase.
default
Configures this command
with its default setting.
Default: Same as no ruledef-parsing
ignore-port-numbers-embedded-in-application-headers analyzers { http
rstp sip wsp }— not ignoring port numbers
that are embedded in application headers.
ignore-port-numbers-embedded-in-application-headers
analyzers { http rtsp sip wsp }
Ignore the port numbers
present in application header.
Specifies analyzers
for which the port number must be ignored.
Usage:
Use this command to
make the HTTP, RTSP, SIP, and WSP analyzer ignore port numbers embedded
in application headers.
Example:
The following command
makes the HTTP analyzer in the current rulebase ignore port numbers
embedded in application headers:
ruledef-parsing ignore-port-numbers-embedded-in-application-headers
analyzers http
tcp 2msl-timeout
This command allows
you to configure how long to retain the TCP flow after the FIN has
been acknowledged.
Privilege:
Security Administrator,
Administrator
Syntax
tcp 2msl-timeout 2msl_timeout
{ default | no } tcp
2msl-timeout
default
Configures this command
with its default setting.
Default: 2 seconds
no
Disables the timeout
and sets the system to delete the flow immediately upon seeing the
FIN acknowledged.
tcp 2msl-timeout 2msl_timeout
Specifies the duration
to keep the TCP flow.
2msl_timeout specifies
the timeout duration, in seconds, and must be an integer from 1
through 20.
Usage:
Use this command to
configures how long to retain the TCP flow after the FIN has been acknowledged.
Acknowledgment to the
FIN is not guaranteed to be received by the destination, then the FIN
could be resent and re-acknowledged. In this scenario, it is desirable
to still have the flow, so that the re-sends do not create a new
flow.
Example:
The following command
sets the timeout to 4 seconds:
tcp 2msl-timeout 4
tcp check-window-size
This command allows
you to enable/disable TCP window-size checking.
Privilege:
Security Administrator,
Administrator
Syntax
[ default | no ] tcp
check-window-size
default
Configures this command
with its default setting.
Default: Enabled (packets
after the erroneous packet (with size greater than the receiver’s window
size) will hit tcp-error ruledef).
no
Disables the window-size
check and continues with normal L7 parsing.
tcp check-window-size
Enables the window-size
check and continues with normal L7 parsing.
Usage:
Use this command to
enable/disable TCP window-size check for packets out of
TCP window.
Example:
The following command
enables TCP window-size check:
tcp check-window-size
tcp mss
This command allows
you to configure the TCP Maximum Segment Size (MSS) in TCP SYN packets.
IMPORTANT:
This command is only
available in StarOS 8.1 and later releases.
Privilege:
Security Administrator,
Administrator
Syntax
tcp mss tcp_mss { add-if-not-present | limit-if-present } +
{ default | no } tcp mss
default
Configures this command
with its default setting.
Default: Disabled
no
If previously configured,
deletes the TCP MSS configuration from the current rulebase.
tcp mss tcp_mss
Specifies the TCP MSS.
tcp_mss must
be an integer from 496 through 65535.
add-if-not-present
Specifies to add the
TCP MSS if not present in the packet.
limit-if-present
Specifies to limit
the TCP MSS if present in the packet.
Usage:
Using this command,
TCP MSS can be limited if already present in the TCP SYN packets. If
there are no errors detected in IP header/TCP mandatory
header and there are no memory allocation failures, TCP optional
header is parsed. If TCP MSS is present in the optional header and
its value is greater than the configured MSS value, the value present
in the TCP packet is replaced with the configured one.
If the TCP optional
header is not present in the SYN packet and there are no errors
in already present TCP header, the TCP MSS value configured will
be inserted while sending the current packet out.
Example:
The following command
limits the TCP maximum segment size to
3000, and
if not present adds it to the packets:
tcp mss 3000 limit-if-present
add-if-not-present
tcp packets-out-of-order
This command allows
you to configure processing of TCP packets that are out of order,
while waiting for the earlier packet(s) to arrive.
Privilege:
Security Administrator,
Administrator
Syntax
tcp packets-out-of-order { timeout timeout_duration | transmit [ after-reordering | immediately ] }
default tcp packets-out-of-order { timeout | transmit }
default
Configures this command
with its default setting.
- timeout:
5000 milliseconds
- transmit: immediately
timeout timeout_duration
Specifies the timeout
duration for re-assembly of TCP out-of-order packets.
timeout_duration is
the timeout duration, in milliseconds, and must be an integer from
100 through 30000.
Default: 5000 milliseconds
transmit [ after-reordering | immediately ]
Configures the TCP
out-of-order segment behavior after buffering a copy.
- after-reordering:
Sends the TCP out-of-order segment after all packets are received
and successfully reordered. If reordering is not successful due
to a timeout, the received packets are forwarded without being passed
through the protocol analyzers. If memory allocation fails or the
received packet is partial retransmitted data, the packet will be
forwarded immediately without being passed through the protocol
analyzers, except for the IP analyzer.
- immediately:
Sends the TCP out-of-order segment immediately after buffering a
copy. The packets are transmitted as they are received without any in-line
services or charging action processing, but also a copy of each
packet is held onto. When the missing packet is received, complete
deep packet inspection of all the packets and all relevant in-line
services is done, and then the last packet is forwarded.
Default: immediately
Usage:
Use this command to
configure how to process TCP packets that are out of order, while waiting
for the earlier packet(s) to arrive.
Example:
The following command
sets the timeout timer to
10000 milliseconds:
tcp packets-out-of-order
timeout 10000
tcp proxy-mode
This command allows
you to enable/disable TCP Proxy mode for all subscribers using
the current rulebase.
Product:
ACS, CF, MVG, TPO
Privilege:
Security Administrator,
Administrator
Syntax
tcp proxy-mode { dynamic { all | content-filtering | dcca | ip-readdressing | nexthop-readdressing | xheader-insert } + | static [ port [ port_number [ to port_number ] ] ] }
default tcp proxy-mode
no tcp proxy-mode [ dynamic { content-filtering | dcca | ip-readdressing | nexthop-readdressing | xheader-insert } + | static [ port [ port_number [ to port_number ] ] ] ]
default
Configures this command
with its default setting.
Default: Disabled
no
If previously enabled,
disables TCP Proxy mode.
Optionally, TCP Proxy
can be disabled for specific options that were previously enabled.
dynamic { all | content-filtering | dcca | ip-readdressing | nexthop-readdressing | xheader-insert } +
Enables TCP proxy for
subscriber-initiated TCP flows under the specified condition(s).
- all: Specifies
that subscriber-initiated TCP flows be proxied if all/any
of the following conditions are satisfied.
- content-filtering:
Specifies that subscriber-initiated TCP flows be proxied if a URL
is requested, and that URL is checked because Category-based Content
Filtering is enabled in the rulebase.
- dcca: Specifies
that subscriber-initiated TCP flows be proxied if DCCA is enabled
in the charging action.
- ip-readdressing:
Specifies that subscriber-initiated TCP flows be proxied if IP Readdressing
feature is enabled in the charging action.
- nexthop-readdressing:
Specifies that subscriber-initiated TCP flows be proxied if Nexthop
Readdressing feature is enabled in the charging action.
- xheader-insert:
Specifies that subscriber-initiated TCP flows be proxied if x-Header
Insertion feature is enabled in the charging action.
static [ port [ port_number [ to port_number ] ] ]
Enables static TCP
proxy for every subscriber-initiated TCP flow, unless specific ports
are specified.
port [ port_number [ to port_number ] ] ]
Specifies port numbers
and/or range of port numbers.
port_number must
be an integer from 1 through 65535.
IMPORTANT:
Up to 32 port numbers
and eight port ranges can be specified.
Usage:
IMPORTANT:
In release 11.0, TCP
Proxy functions only in Static mode. Dynamic TCP Proxy mode is supported
only in 12.0 and later releases.
Use this command to
enable/disable TCP Proxy mode for all subscribers using
this ACS rulebase. Optionally, TCP Proxy can be enabled/disabled
for specific ACS features. Note that enabling/disabling
the TCP Proxy feature for any of the optional ACS features, does
not affect that feature.
IMPORTANT:
Regardless of the setting
of this command, TCP Proxy is enabled whenever a TPO profile is selected
for the subscriber's flow(s).
Note that the last
command overwrites any previous configuration. For example, when
the following commands are applied in sequence:
tcp proxy-mode dynamic
nexthop-readdressing
tcp proxy-mode dynamic
xheader-insert
The nexthop configuration
is overwritten by the x-header configuration.
Example:
The following command
enables TCP proxy for subscriber-initiated TCP flows whenever next-hop-forwarding-address
is configured in the charging action:
tcp proxy-mode dynamic
nexthop-readdressing
timestamp rounding
This command allows
you to enable/disable timestamp rounding in EDRs
or eG-CDRs.
Privilege:
Security Administrator,
Administrator
Syntax
timestamp rounding { edr | egcdr } { ceiling | floor | round-off }
{ default | no } timestamp
rounding { edr | egcdr }
default
Configures this command
with its default setting.
Default: round-off
no
Disables timestamp
rounding.
edr
Enables timestamp rounding
for EDRs.
egcdr
Enables timestamp rounding
for eG-CDRs.
ceiling
If the fractional part
of the seconds is greater than 0, adds 1 to the number of seconds
and discards the fraction.
floor
Discards the fractional
part of the second.
round-off
Sets the fractional
part of the seconds to nearest integer value. If the fractional
value is greater than or equal to 0.5, it adds 1 to the number of
seconds and discards the fractional part of second.
Usage:
Use this command to
configure the timestamp rounding setting.
The specified rounding
will be performed before system attempts any calculation. For example
using round-off, if the start time is 1.4, and the end time is 1.6,
then the calculated duration will be 1 (for example, 2 – 1 = 1).
This command may be
repeated for each type of EDR
or
eG-CDR.
Example:
The following command
sets the EDR timestamp to nearest integer value second; for example,
34:12.23 to 34:12.00:
timestamp rounding
edr round-off
tpo default-policy
This command allows
you to configure the default TPO policy for the current rulebase.
Privilege:
Security Administrator,
Administrator
Syntax
tpo default-policy tpo_policy_name
no tpo default-policy
no
If previously configured,
deletes the default TPO policy configuration from the current rulebase.
tpo default-policy tpo_policy_name
Specifies the default
TPO policy for the current rulebase.
tpo_policy_name must
be the name of a TPO policy, and must be an alphanumeric string
of 1 through 63 characters.
Usage:
Use this command to
configure the default TPO policy for a rulebase.
For subscribers using
a particular rulebase, the default TPO policy configured in it will
be used only if in the APN/subscriber profile no TPO policy
is configured, and a policy to use is not received from the AAA/OCS.
Example:
The following command
configures a TPO policy named
standard as
default TPO policy for the rulebase:
tpo default-policy standard
transport-layer-checksum
This command allows
you to enable/disable checksum verification for TCP and UDP
packets.
Privilege:
Security Administrator,
Administrator
Syntax
[ no ] transport-layer-checksum
verify-during-packet-inspection [ tcp | udp ]
default transport-layer-checksum
no
Disables the checksum
calculation for the specified packet type.
default
Configures this command
with its default setting.
Default: Same as transport-layer-checksum
verify-during-packet-inspection—to perform the
checksum verification calculation on all TCP and UDP packets.
[ tcp | udp ]
Specifies that either
TCP or UDP packets should be verified/not verified.
If neither of these
keywords is specified the command applies to both TCP and UDP packets.
Usage:
Use this command to
disable or enable performing checksum verification calculations
on TCP or UDP packets.
If the checksum is
not verified, the packets will go through the TCP/UDP analyzers
(and deeper analyzers, if so configured via the route command) regardless
of the value of the TCP/UDP checksum.
If the checksum is
verified, only packets with good checksums will go through the TCP/UDP
analyzers (and deeper analyzers, if so configured).
Example:
The following command
disables checksum verification calculations on all TCP and UDP packets:
no transport-layer-checksum
verify-during-packet-inspection
udr threshold
This command allows
you to configure the threshold limit to generate Usage Data Records
(UDRs) that provide Comma Separated Value (CSV) records written
periodically in a fixed schema designed to reflect a total billable
quantity.
Privilege:
Security Administrator,
Administrator
Syntax
udr threshold { interval interval | volume { downlink bytes [ uplink bytes ] | total bytes | downlink bytes [ uplink bytes ] } }
default udr threshold { interval | volume }
no udr threshold { interval | volume { downlink [ uplink ] | total | uplink [ downlink ] } }
no
If previously configured,
deletes the UDR threshold configuration from the current rulebase.
default
Configures this command
with its default setting.
Default: Disabled;
same as no udr
threshold interval and no udr threshold volume.
interval interval
Specifies the time
interval, in seconds, for closing the UDR if the minimum time duration thresholds
are satisfied. By default, this option is disabled.
interval must
be an integer from 60 through 40000000.
Default: 0 (Disabled)
volume
Specifies uplink/downlink
volume octet counts for the generation of interim UDRs.
- downlink bytes: Specifies
the limit for the number of downlink octets after which the UDR
is closed.bytes must
be an integer from 100000 through 4000000000.Default: 4000000000
- total bytes: Specifies
the limit for the total number of octets (uplink+downlink)
after which the UDR is closed. bytes must
be an integer from 100000 through 4000000000.Default: Disabled
- uplink bytes: Specifies the
limit for the number of uplink octets after which the UDR is closed.bytes must
be an integer from 100000 through 4000000000.Default: 4000000000
UDR records are generated
whenever either threshold is reached.
Usage:
Use this command to
enable thresholds for generation of UDRs.
Example:
The following command
specifies that UDR records should be generated every 10 minutes (
600 seconds):
udr threshold interval 600
udr trigger
This command allows
you to configure additional triggers for generating UDRs.
IMPORTANT:
This command is only
available in StarOS 8.3 and later releases.
Privilege:
Security Administrator,
Administrator
Syntax
[ no ] udr
trigger first-hit-content-id
default udr trigger
no
Disables first-hit-content-id
UDR trigger.
default
Configures this command
with its default setting.
Default: Disabled;
no additional triggers.
udr trigger first-hit-content-id
Specifies to generate
interim UDR on first packet hit per rating group/content ID.
Usage:
This command enables
to assign first packet trigger to interim UDRs—for generating UDR
for first packet hit per rating group/content ID. The first-hit-content-id
trigger when configured causes an UDR to be generated as soon as
a packet hits a Charging Action with a content ID. UDR generation
will be triggered when this command is configured and present in the
rulebase.
Example:
The following command
assigns first packet trigger to interim UDRs, for generating UDR for
first packet hit per rating group/content ID:
udr trigger first-hit-content-id
url-blacklisting
action
This command allows
you to enable/disable URL Blacklisting functionality for the
current rulebase, and configures the action to be taken when there
is a URL match.
Privilege:
Security Administrator,
Administrator
Syntax
url-blacklisting action { discard | redirect-url url | terminate-flow | www-reply-code-and-terminate-flow reply_code } [ content-id content_id ]
{ default | no } url-blacklisting action
default
Disables URL Blacklisting
in the current rulebase.
no
If previously
configured, deletes the URL Blacklisting action configuration from
the current rulebase.
discard
Configures URL Blacklisting “discard” action.
redirect-url url
Configures URL Blacklisting “redirect-url” action.
url specifies
the redirect URL/URI, which must be a fully qualified URL/URI,
and must be an alphanumeric string of 1 through 1023 characters.
terminate-flow
Configures URL Blacklisting “terminate-flow” action.
www-reply-code-and-terminate-flow reply_code
Configures URL Blacklisting “terminate-flow” action
with reply code.
reply_code specifies
the reply code, and must be an integer from 100 through 599.
Usage:
Use this command to
enable/disable URL Blacklisting at the rulebase level,
and configure the action to be taken.
Example:
The following command
enables URL Blacklisting in the rulebase, and configures the terminate-flow
action with reply code 300:
url-blacklisting action
www-reply-code-and-terminate-flow 300
The following command
disables URL Blacklisting feature in the rulebase:
no url-blacklisting action
url-preprocessing
This command allows
you to enable/disable a group-of-prefixed-urls for preprocessing
of embedded URLs.
IMPORTANT:
This command is customer
specific. For more information, please contact your Cisco account
representative.
Privilege:
Security Administrator,
Administrator
Syntax
[ no ] url-preprocessing
bypass group-of-prefixed-urls prefixed_urls_group_name
no
If previously configured,
deletes the URL-preprocessing bypass configuration from the current
rulebase.
group-of-prefixed-urls prefixed_urls_group_name
Specifies the group-of-prefixed-urls.
prefixed_urls_group_name must
be the name of a group-of-prefixed-urls, and must be an alphanumeric
string of 1 through 63 characters.
Usage:
Use this command to
enable/disable a group-of-prefixed-urls for preprocessing
of embedded URLs. This command can be issued multiple times to enable
multiple groups. If an embedded URL begins with the string specified
within any of the groups, that prefix text will be removed from
the URL.
Example:
The following command
enables looking for prefixed URLs of the group-of-prefixed-urls named
test5:
url-preprocessing
bypass group-of-prefixed-urls test5
wtp packets-out-of-order
This command allows
you to configure how to process Wireless Transaction Protocol (WTP)
packets that are out of order, while waiting for the earlier packet(s)
to arrive.
Privilege:
Security Administrator,
Administrator
Syntax
wtp packets-out-of-order { out-of-order-timeout timeout | transmit [ after-reordering | immediately ] }
default wtp packets-out-of-order { out-of-order-timeout | transmit }
default
Configures this command
with its default setting.
- out-of-order-timeout:
5000 milliseconds
- transmit: immediately
out-of-order-timeout timeout
Specifies the maximum
duration for which WTP out-of-order packets are retained, before reassembly
is needed.
timeout is
the timeout duration, in milliseconds, and must be an integer from
100 through 30000.
Default: 5000 milliseconds
transmit [ after-reordering | immediately ]
Specifies the WTP out-of-order
segment behavior after buffering a copy:
- after-reordering:
Sends WTP out-of-order segment after it becomes ordered
- immediately:
Sends WTP out-of-order segment immediately after buffering a copy
Default: immediately
Usage:
Use this command to
configure TCP out-of-order segment options.
If out-of-order-timeout
is specified, out-of-order packets are retained, until either all packets
have been received or the configured timeout has expired for the
oldest packet. If all packets have been received, a temporary complete
packet is reconstructed for analysis. Then all packets are forwarded
in order from first to last. If all packets are not received, the
packets will be forwarded without being passed through the protocol
analyzers, except for the IP analyzer.
If after-reordering transmitting
is specified, the packets are held onto and reordered. After successfully
reordering the packets, they are processed in the proper order.
If reordering is not successful due to timeout (wtp out-of-order-timeout),
the received packets are forwarded without being passed through
the protocol analyzers.
If immediately is
specified, the packets are transmitted as they are received without
any in-line services or Charging Action processing, however a copy
of each packet is retained. When the missing packet is received,
complete deep packet inspection of all the packets and all relevant
in-line services is undertaken, and then the last packet is forward
(unless otherwise configured by the in-line services or Charging Action).
Example:
The following command
sets the timeout timer to
10000 milliseconds:
wtp out-of-order-timeout 10000
xheader-encryption
This command allows
you to configure X-Header Encryption feature’s parameters.
Product:
IMPORTANT:
This command is license
dependent. For more information, please contact your Cisco account
representative.
ACS
Privilege:
Security Administrator,
Administrator
Syntax
xheader-encryption { certificate-name certificate_name | re-encryption period period }
default xheader-encryption
re-encryption period
no xheader-encryption { certificate-name | re-encryption }
default
Configures this command
with its default setting.
Default: Disabled
no
If previously configured,
deletes the configuration from the current rulebase.
certificate-name certificate_name
Specifies the encryption
certificate to use for the X-Header Encryption feature.
certificate_name must
be the name of an encryption certificate, and must be an alphanumeric
string of 1 through 63 characters.
Default: Disabled; no
encryption certificate
re-encryption period period
Specifies how often
to re-generate the encryption keys.
period specifies
the re-encryption time period in minutes, and must be an integer
from 1 through 10000.
Default: Disabled;
no re-encryption
Usage:
Use this command to
configure the X-Header Encryption feature’s certificate
and re-encryption parameters.
Example:
The following command
configures the X-Header Encryption feature to use the certificate named
testcert:
xheader-encryption
certificate-name testcert