> Rulebase Configuration Mode Commands
> The Rulebase Configuration Mode is used to create and manage Active Charging Service Rulebase configurations.
> Important: The commands or keywords/variables that are available are dependent on platform type, product version, and installed license(s).
> action priority
> This command configures the action priority for a ruledef / group-of-ruledefs in the rulebase.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> no action priority action_priority
> no
> Removes the previously configured action priority from this rulebase.
> priority action_priority
> Specifies a priority for the specified ruledef / group-of-ruledefs in this rulebase.
> The priority controls the ordering of the instance of the CLI command. Lower numbered priorities are examined first. Up to 2048 instances may be configured, totaled among all rulebases.
> action_priority must be an integer from 1 through 65535.
> dynamic-only
> Default: disabled
> Enables matching of dynamic rules with static rules for this action priority on a flow.
> The dynamic-only option 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.
> static-and-dynamic
> Default: enabled
> 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.
> Important: When R7 Gx is enabled, “static-and-dynamic” rules behave exactly like “dynamic-only” rules. I.e. they must be activated explicitly by the 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 enable activation/deactivation of ruledefs/groups-of-ruledefs such that they are available for rule matching only when they are active.
> timedef_name must be the name of a timedef, and must be an alpha and/or numeric string of 1 through 63 characters in length.
> 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
> Assigns the specified ruledef to this rulebase.
> ruledef_name must be the name of an existing ruledef, and must be an alpha and/or numeric string of 1 through 63 characters in length.
> If the specified ruledef does not exist, there will be no ruledef triggers for this action priority within this 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 group_name
> Assigns the specified group-of-ruledefs to this rulebase.
> group_name must be the name of an existing group-of-ruledefs, and must be an alpha and/or numeric string of 1 through 63 characters in length.
> When a group-of-ruledefs is specified, if any of the ruledefs within the group matches, the specified charging-action is performed, 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 an existing charging action, and must be an alpha and/or numeric string of 1 through 63 characters in length.
> If the specified charging action does not exist, there will be no charging action triggers for this action priority within this rulebase.
> Important: If the charging action specified here is deleted or not configured, the system accepts it without applying 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 alpha and/or numeric string of 1 through 63 characters in length.
> 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 of test, and a charging action of test1 to the current rulebase:
> action priority 23 ruledef test charging-action test1
> bandwidth default-policy
> This command configures the default bandwidth policy for the current rulebase.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> bandwidth default-policy policy
> no bandwidth default-policy
> no
> Removes previously configured default bandwidth policy.
> policy
> Specifies the default bandwidth policy to be configured for the current rulebase.
> policy must be an alpha and/or numeric string of 1 through 63 characters in length.
> Usage
> Use this command to configure the default bandwidth policy for the current rulebase. This bandwidth policy will be used for subscribers using this rulebase for whom in the APN/Subscriber Configuration Mode 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 configures the type of billing to be performed for subscriber sessions.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> billing-records { egcdr | radius | rf | udr udr-format udr_format_name } +
> no billing-records
> no
> Deletes the current billing-records configuration.
> egcdr
> Generates an enhanced G-CDR (eG-CDR) 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.
> udr udr-format udr_format_name
> Generates UDRs with specified format on the occurrence of an interim trigger condition, at the end of a subscriber session or ahandoff.
> udr_format_name must be the name of an existing UDR format, and must be a string of 1 through 63 characters in length.
> +
> 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), 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 configures Diameter specific AVPs in Requested-Service-Unit group AVP with DCCA Credit Control Requests (CCRs).
> Product
> All
> 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
> Disables the Diameter AVP configuration for DCCA CCRs.
> 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 4,294,967,295.
> 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 4,000,000,000.
> 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 to 4,000,000,000.
> +: More than one of the above 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 Requested-Service-Unit group 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 is used to set various time and threshold-based quotas in the prepaid credit control service.
> Product
> All
> Privilege
> Security Administrator, Administrator
> Syntax
> { no | default } cca quota { holding-time content-id cont_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.
> holding_time must be an integer from 1 to 4000000000.
> After holding_time seconds has passed without user traffic, the quota is reported back and the charging stops until new traffic starts.
> content-id cont_id
> Specifies the content ID (Rating group AVP) to use for the Quota holding time for this rulebase.
> cont_id is the specified content id for credit control service in an active charging service and must be an integer from 0 through 4,294,967,295.
> retry-time retry_time [ max-retries retries ]
> Default: 60
> Specifies the retry time in seconds for the quota request.
> retry_time must be an integer from 0 to 86400. To disable this assign 0.
> This defines the maximum frequency at which the CC application tries to obtain quota for a subscriber passing traffic for a category with no/exhausted quota.
> For a subscriber not passing traffic, the CC application will not try to obtain quota (except once at session start time, if so configured). i.e. 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, 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 large value for retry-time in quota charging or top up scenario.
> max-retries retries option configures the maximum number of retries allowed for blacklisted categories. This option has default value of maximum retries of 65535 retries.
> 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 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 exausted earlier.
> When server sends the quota holding time (QHT) it has highest priority to use that QHT irrespective of the value configured in rulebase or Credit Control Application configuration mode. QHT configured here has second priority for the content ID (rating group) configured here.
> In case of QHT is not available from server and rulebase configuration mode, the QHT values configured at Credit Control Application configuration mode is used.
> Example
> The following command sets the prepaid credit control request retry time to 30 sec.:
> cca quota retry-time 30
> The following command sets the system to use the QHT from Credit Control Application mode:
> no cca quota holding-time content-id content_id
> The following command sets the system to ignore the QHT from Credit Control Application mode:
> default cca quota holding-time content-id content_id
> The following command sets the prepaid credit control request retry time to 60 seconds and maximum numbers of retries to 65535.
> default cca quota retry-time max-retries
> cca quota time-duration algorithm
> This command is used to define the algorithm used to compute time duration for prepaid credit control application quotas in the rulebase service.
> Product
> All
> 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
> Removes the previously configured quota time-duration algorithm.
> default
> Sets the default configurations.
> consumed-time seconds
> Default: 0 (disabled)
> Specifies the Quota Consumption Time (QCT) in seconds. QCT is used with active time-based quotas and to determine chargeable time envelopes for the purposes of consuming time quota.
> 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).
> seconds must be an integer from 1 through 4,294,967,295.
> plus-idle
> Defines 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
> Default: 0 (disabled)
> Specifies the charging quota continuous period in seconds.
> The Continuous Time Periods (CTP) mechanism constructs a time-envelopes out of 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, i.e. the one which contained no traffic.
> seconds must be an integer from 1 through 4294967295.
> parking-meter seconds
> Default: 0 (disabled)
> Specifies the Parking Meter (PM) period, in seconds, for particular rating group.
> 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).
> seconds must be an integer from 1 through 4294967295.
> content-id content_id
> Specifies the content ID (Rating group AVP) to use for the CCA Quota time duration algorithm selection in this rulebase.
> content_id is the specified content ID for credit control service in an active charging service, and must be an integer from 1 through 65535.
> session-time
> Specifies the session period in seconds. This is the default setting.
> 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 sets time duration to 400 seconds for prepaid credit control time duration algorithm:
> cca quota time-duration algorithm consumed-time 400
> cca radius accounting
> This command specifies the accounting interval duration for RADIUS prepaid service parameters.
> Product
> All
> Privilege
> Security Administrator, Administrator
> Syntax
> [ no ] cca radius accounting interval interval
> no
> Removes previously configured RADIUS accounting interval in the rulebase.
> interval interval
> Default: 0 (Disabled).
> Specifies the time interval, in seconds, between accounting actions.
> interval must be an integer from 0 through 3600.
> 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 a rulebase.
> cca radius accounting interval 20
> cca radius charging
> This command specifies the charging context where RADIUS parameters are configured.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> [ no ] cca radius charging context vpn_context [ group group_name ]
> no
> Removes the previously configured RADIUS charging context in a rulebase.
> context vpn_context
> Specifies the charging context where RADIUS prepaid charging are configured.
> vpn_context is an alpha and/or numeric string of 1 through 63 characters in length.
> group group_name
> Specifies the RADIUS server group name configured for RADIUS prepaid charging parameters.
> group_name must be an alpha and/or numeric string of 1 through 63 characters in length.
> 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 a rulebase:
> cca radius charging context prepaid_rad1
> cca radius user-password
> This command specifies the RADIUS prepaid service subscriber’s user password parameters in a Rulebase.
> Product
> All
> Privilege
> Security Administrator, Administrator
> Syntax
> [ no ] cca radius user-password [ encrypted ] password password
> no
> Removes the previously configured RADIUS prepaid service user password in a rulebase.
> [ encrypted ] password password
> Specifies the password to use for the user being given privileges for prepaid services within the current rulebase. The encrypted keyword indicates that the password specified uses encryption.
> password without encryption must be an alpha and/or numeric string of 1 through 63 characters, and when encrypted must be alpha and/or numeric string of 1 through 127 characters in length.
> 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 defines the user password user_123 without encryption for a prepaid service subscriber with RADIUS charging in a rulebase.
> cca radius user-password password user_123
> charging-rule-optimization
> This command enables and sets the charging rule-optimization level for rule matching in a rulebase.
> Product
> All
> Privilege
> Security Administrator, Administrator
> Syntax
> charging-rule-optimization { high | low | medium }
> default charging-rule-optimization
> default
> Sets the default charging rule search and matching optimization level.
> Default: Low
> high
> Enables the highest efficient rule-searching organization with high memory utilization.
> low
> Enables minimally efficient rule-searching organization with minimal memory utilization.
> medium
> Enables moderately efficient rule-searching organization with medium memory utilization.
> Usage
> Use this command to specify the amount of internal optimization that is done for improved performance when evaluating each instance of the action CLI command.
> Example
> The following command specifies the highest optimization level for rule search and matching in a rulebase.
> charging-rule-optimization high
> constituent-policies
> This command configures the bandwidth, CBB, and Firewall/Firewall-and-NAT constituent policies. The combination of the values of all three policies will uniquely identify a rulebase associated.
> Product
> All
> Privilege
> Security Administrator, Administrator
> Syntax
> constituent-policies { bandwidth-policy bandwidth_policy | cbb-policy cbb_policy | firewall-policy fw_policy | fw-and-nat-policy fw_nat_policy }+
> no constituent-policies
> no
> Removes the previous configuration.
> bandwidth-policy bandwidth_policy
> Specifies the Bandwidth policy.
> bandwidth_policy specifies the bandwidth policy name, and must be a string of 1 through 63 characters in length.
> cbb-policy cbb_policy
> Specifies the CBB policy.
> cbb_policy specifies the CBB policy name, and must be a string of 1 through 63 characters in length.
> firewall-policy fw_policy
> Important: This keyword is customer-specific.
> Specifies the Firewall policy.
> fw_policy specifies the Firewall policy name, and must be a string of 1 through 63 characters in length.
> fw-and-nat-policy fw_nat_policy
> Important: This keyword is customer specific, and is only available in StarOS 8.1.
> Specifies the Firewall-and-NAT policy.
> fw_nat_policy specifies the Firewall-and-NAT policy name, and must be a string of 1 through 63 characters in length.
> Usage
> Use this command to configure the bandwidth, CBB, and Firewall/Firewall-and-NAT constituent policies that will identify a rulebase. The combination of the values of all three policies will uniquely identify a 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 configures the Content Filtering Category Policy Identifier for Policy-based Content Filtering support in a rulebase.
> Product
> CF
> Privilege
> Security Administrator, Administrator
> Syntax
> content-filtering category policy-id cf_policy_id
> no content-filtering category policy-id [ cf_policy_id ]
> no
> Removes the Content Filtering Category Policy configuration from the rulebase.
> In StarOS 8.1 and later, 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.
> 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: In case 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 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 a rulebase.
> The Content Filtering Category Policy is created/deleted in the Active Charging Service Configuration mode, and is configured in the Content Filtering Policy Configuration mode.
> Example
> The following command configures the policy ID 101 in the rulebase:
> content-filtering category policy-id 101
> content-filtering flow-any-error
> This command configures allowing/discarding of Content Filtering packets in case of ACS error scenarios.
> Product
> ECS, CF
> Privilege
> Security Administrator, Administrator
> Syntax
> content-filtering flow-any-error { deny | permit }
> default content-filtering flow-any-error
> default
> Configures the default setting.
> Default: Permit
> deny
> Configures Content-Filtering flow-any-error as Deny.
> All the denied packets will be accounted by “discarded-flow-content-id” configuration in the Content Filtering Policy ID Configuration Mode. I.e. this very content ID will be used to generate UDRs for the denied packets in case of Content Filtering.
> permit
> Configures Content-Filtering flow-any-error 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 ACS error:
> content-filtering flow-any-error permit
> content-filtering mode
> This command enables the specified Content Filtering mode within a rulebase.
> Product
> CF
> Privilege
> Security Administrator, Administrator
> Syntax
> content-filtering mode { category { static-only | static-and-dynamic } | server-group cf_server_group }
> no content-filtering mode
> no
> Removes/disables a previously configured content filtering mode in this rulebase.
> It implies that content filtering in not to be performed for this rulebase.
> This is the default mode.
> category { static-and-dynamic | static-only }
> This keyword specifies the category-based content filtering mode.
> static-only Configures Content Filtering mode as Static only. Compares all URLs agains internal database to determine the category or categories of the requested content.
> Use of this category-based content filtering support requires configuration of the require active-charging content-filtering category CLI command in the Global Configuration mode.
> static-and-dynamic Configures Content Filtering mode as Static-and-Dynamic, wherein first static rating of the URL is performed, and only if the static rating fails to find a match dynamic rating of the content that the server returns is 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 CLI command.
> server-group cf_server_group
> This keyword enables and configures the CFSG mode within a rulebase to manage an external content filtering server with an ICAP client system.
> cf_server_group specifies the name of a pre-configured unique content filtering server group in Content Configuration Mode, and must be an alpha and/or numeric string of 1 through 63 characters in length.
> If this keyword is used every ACS attempt to establish TCP connections to every server in the named group.
> Usage
> Use this command to enable and apply the content filtering mode with in a 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 with in this rulebase.
> content-filtering mode server-group CF_Server1
> The following command enables the category based static and dynamic content filtering mode for with in this rulebase.
> content-filtering mode category static-and-dynamic
> dynamic-rule
> This command configures the order of comparing the dynamic rules to static rules for the flow.
> Product
> GGSN
> Privilege
> Security Administrator, Administrator
> Syntax
> dynamic-rule order { always-first | first-if-tied }
> no dynamic-rule order
> no
> Removes the previously configured dynamic rule comparing order for this rulebase.
> order { always-first | first-if-tied }
> This command configures the way in which rules are selected for matching from dynamic rules list (per subscriber) and static rules list (from rulebase).

> • | always-first: If this option is configured, then all the dynamic rules are matched against the flow prior to any static rule.

> • | first-if-tied : If this option is configured, then rules are matched against the flow based on their priority with condition that dynamic rules match before a static rule of the same priority.

> Usage
> Use this command to configure the way in which rules are selected up for matching from dynamic rules list (per subscriber) and static rules list (from rulebase).
> Example
> The following command configures to match 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.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> [ no | default ] edr suppress-zero-byte-records
> no
> Disables the suppression of zero-byte EDRs.
> default
> Sets the default configuration.
> Default: no edr suppress-zero-byte-records
> 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.
> Example
> The following command disables the creation of zero-byte EDRs:
> edr suppress-zero-byte-records
> edr transaction-complete
> This command configures the generation of an EDR on the completion of a transaction.
> Important: This command is only available in StarOS 8.1 and StarOS 9.0 and later.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> edr transaction-complete http edr-format edr_format
> { default | no } edr transaction-complete
> default
> Sets the default configuration.
> Default: same as no edr transaction-complete
> no
> Disables the generation of EDR on transaction completion.
> http
> Specifies EDR generation on transaction completion for HTTP protocol.
> edr-format edr_format
> Specifies the EDR format name.
> edr_format must be an alpha and/or numeric string of 1 through 63 characters in length.
> Usage
> Use this command to configure the generation of an EDR on the completion of a transaction. In this release EDR generation is supported only for HTTP protocol.
> Example
> 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 generating Event Data Record (EDR) on the completion of voice calls.
> Product
> ECS, P2P
> Privilege
> Security Administrator, Administrator
> Syntax
> edr voip-call-end edr-format edr_format_name
> { default | no } edr voip-call-end
> default
> Configures the default setting.
> Default: no edr voip-call-end
> no
> Specifies to disable EDR generation on the completion of a voice call.
> edr-format edr_format_name
> Specifies EDR format name.
> edr_format_name must be an existing EDR format’s name, and must be a string of 1 through 63 characters in length.
> Usage
> Use this command to enable generating EDR on the completion of voice calls. This facilitates P2P voice duration reporting.
> Example
> The following command specifies generating EDR on completion of voice calls using the EDR format test13:
> edr voip-call-end edr-format test13
> egcdr inactivity-meter
> DescriptionThis command is obsolete. It is included in the CLI for backward compatibility with older configuration files. When executed performs no function. Use egcdr threshold interval interval [ regardless-of-other-triggers ] command for this functionality.
> egcdr service-data-flow
> This command assigns volume or interval threshold values to the interim Service Data Flow Containers in Flow Based Charging (FBC).
> Product
> GGSN, ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> egcdr service-data-flow threshold { interval interval | volume { downlink | total | uplink } bytes }
> { no | default } egcdr service-data-flow threshold { interval | volume }
> no
> Removes the previously configured eG-CDR service data flow threshold for FBC.
> default
> Disables the egcdr service data flow threshold settings for FBC.
> interval interval
> Specifies the time interval (in seconds) for closing the eG-CDR if the minimum time duration thresholds for service data flow containers satisfied in flow based charging. This option is disabled by default.
> interval must be an integer from 60 through 400,00,000.
> volume
> Specifies the uplink/downlink volume octet counts for the generation of the interim eG-CDRs to service data flow container in FBC.

> • | downlink bytes - Sets the limit for the number of octets downlink after which the eG-CDR is closed. bytes (in bytes) must be an integer from 10,000 through 400000000. Default is 400,000,000.

> • | total bytes - Sets the limit for the total number of octets (uplink+downlink) after which the eG-CDR is closed. bytes (in bytes) must be an integer from 10,000 through 400,000,000. This configuration is disabled by default.

> • | uplink bytes - Sets the limit for the number of octets uplink after which the eG-CDR is closed. bytes ( in bytes) must be an integer from 10,000 through 400,000,000. Default is 400,000,000.

> Usage
> Use this command to specify an eG-CDR threshold to generate it and write it to eG-CDR in service data flow container during flow based charging (FBC).
> Example
> The following command sets an eG-CDR threshold interval of 6000 seconds:
> egcdr service-data-flow threshold interval interval 6000
> egcdr tariff
> This command sets the eG-CDR tariff time information to close and open new eG-CDR.
> Product
> GGSN, ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> [ no ] egcdr tariff minute minute hour hour
> no
> Removes the previously configured eG-CDR tariff.
> minute minute
> Specifies the minute in a specified hour.
> minute must be an integer from 0 through 59.
> hour hour
> Specifies the hour of the day. hour must be an integer from 0 through 23.
> Usage
> Use this command to specify an eG-CDR tariff time. Up to 4 different time-of-day may be configured. When any tariff time reached the current eG-CDR will be closed and a new eG-CDR will be opened.
> Example
> The following command defines an eG-CDR tariff for the 23rd minute of the 22nd hour of the day:
> egcdr tariff minute 23 hour 22
> egcdr threshold
> This command sets the eG-CDR volume or interval values to generate the interim eG-CDRs and write them to eG-CDR file.
> Product
> GGSN, ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> egcdr threshold { interval interval [ regardless-of-other-triggers ] | volume { downlink | total | uplink } bytes }
> { no | default } egcdr threshold { interval | volume }
> no
> Removes previously configured eG-CDR threshold.
> default
> Disables the egcdr threshold settings.
> interval interval [ regardless-of-other-triggers ]
> Specifies the time interval (in seconds) for closing the eG-CDR if the minimum time duration thresholds are satisfied. This option is disabled by default.
> interval must be an integer from 60 to 40000000.
> regardless-of-other-triggers: This option enables the eG-CDR generation at the fixed time interval irrespective of any other eG-CDR triggers that may have happened in between.
> volume
> Specifies the uplink/downlink volume octet counts for the generation of the interim eG-CDRs.

> • | downlink bytes - Sets the limit for the number of octets downlink after which the eG-CDR is closed. bytes (in bytes) must be an integer from 100,000 through 4,000,000,000. Default is 4,000,000,000.

> • | total bytes - Sets the limit for the total number of octets (uplink+downlink) after which the eG-CDR is closed. bytes (in bytes) must be an integer from 100,000 through 4,000,000,000. This configuration is disabled by default.

> • | uplink bytes - Sets the limit for the number of octets uplink after which the eG-CDR is closed. bytes ( in bytes) must be an integer from 100,000 through 4,000,000,000. Default is 4,000,000,000.

> Usage
> Use this command to specify an eG-CDR threshold to generate it and write it to eG-CDR file.
> Example
> The following command defines an eG-CDR threshold interval of 600 seconds:
> egcdr threshold interval 600
> egcdr time-duration algorithm
> This command is used to define the algorithm used to compute the duration for time utilization in eG-CDR for specific Rulebase.
> Product
> All
> Privilege
> Security Administrator, Administrator
> Syntax
> egcdr time-duration algorithm { consumed-time con_time [ plus-idle ] | continuous-time-periods ctp_seconds | parking-meter seconds }
> { default | no } egcdr time-duration algorithm
> no
> Removes the previously configured eG-CDR time-duration algorithm.
> default
> Sets default time duration value to time duration algorithm for eG-CDR generation.
> consumed-time con_time [ plus-idle ]
> Default: 0 (disabled)
> Defines the actual consumption time in seconds. This is used to determine the actual used chargeable time envelopes for the purposes of consuming time quota.
> 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.
> con_time must be an integer from 1 through 4,294,967,295.
> plus-idle: Defines 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
> Defines 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 first packet and there after include only that period in charging in which one or more packets arrived. The period where no packets arrived or traffic detected no usage will be computed. ctp_time must be an integer from 1 through 4294967295.
> parking-meter seconds
> Defines the parking meter (PM) period in seconds.
> 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 value is set to 300 seconds (5 minutes) and the subscriber only uses one minute, the charge is for 5 minutes.
> seconds must be an integer from 1 through 4294967295.
> 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
> Returns to the Exec mode.
> Product
> All
> Privilege
> Security Administrator, Administrator
> Syntax
> end
> Usage
> Use this command to change to the Exec mode.
> exit
> Exits the Rulebase Configuration Mode and returns to the parent configuration mode.
> Product
> All
> Privilege
> Security Administrator, Administrator
> Syntax
> exit
> Usage
> Use this command to change to the parent configuration mode.
> extract-host-from-uri
> If the host field is not present in HTTP/WSP header, this command will extract host from URI, and store it in the host field.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> extract-host-from-uri { http | wsp + )
> { default | no } extract-host-from-uri
> default
> Configures the default setting.
> Default: no extract-host-from-uri
> no
> Removes the previous extract-host-from-uri configuration for all protocols.
> http | wsp
> Specifies protocol(s) for extract-host-from-uri configuration.
> +
> 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 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
> This command configures a waiver on top of average available memory credits per session for the Fair Usage feature.
> Product
> ECS, CF, FW, NAT, P2P
> Privilege
> Security Administrator, Administrator
> Syntax
> fair-usage session-waiver-percent waiver_percent
> default fair-usage session-waiver-percent
> default
> Configures the default setting.
> Default: 20 percent
> session-waiver-percent waiver_percent
> Specifies the Fair Usage session waiver above average available memory for subscribers using the rulebase.
> waiver_percent must be an integer from 0 through 1000.
> Usage
> Use this command to configure a waiver on top of average available memory credits per session as a rulebase configuration.
> Example
> The following command configures the Fair Usage Session Waiver setting to 25percent:
> fair-usage session-waiver-percent 25
> firewall dos-protection
> This command configures 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, for Policy-based Firewall-and-NAT configuration, this command is available in the Firewall-and-NAT Policy Configuration Mode.
> Product
> FW
> 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
> Disables protection for subscribers from all or specified DoS attack(s).
> default
> Disables protection from all DOS attacks.
> all
> Enables protection against all DoS attacks supported by the Stateful Firewall service.
> flooding { icmp | tcp-syn | udp }
> Enables protection against specified flooding attack:

> • | icmp: Enables protection against ICMP Flood attack

> • | tcp-syn: Enables protection against TCP Syn Flood attack

> • | udp: Enables protection against UDP Flood attack

> 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 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 protection from all supported DoS attacks in the Inline Firewall Service:
> firewall dos-protection all
> firewall flooding
> This command configures 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, for Policy-based Firewall-and-NAT configuration, this command is available in the Firewall-and-NAT Policy Configuration Mode.
> Product
> FW
> 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
> Sets the specified firewall flooding configuration to the default value.
> 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
> The maximum sampling-interval configurable is 60 seconds.
> 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 limit 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 configures 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, for Policy-based Firewall-and-NAT configuration, this command is available in the Firewall-and-NAT Policy Configuration Mode.
> Product
> FW
> Privilege
> Security Administrator, Administrator
> Syntax
> firewall icmp-destination-unreachable-message-threshold messages then-block-server
> { default | no } firewall icmp-destination-unreachable-message -threshold
> default
> Sets the default configuration.
> Default: No limit
> no
> Removes the previous configuration.
> 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 configures the maximum IP packet size (after IP reassembly) allowed over 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, for Policy-based Firewall-and-NAT configuration, this command is available in the Firewall-and-NAT Policy Configuration Mode.
> Product
> FW
> 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
> Sets the maximum IP packet size configuration to the default value.
> 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 configures firewall protection from 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, for Policy-based Firewall-and-NAT configuration, this command is available in the Firewall-and-NAT Policy Configuration Mode.
> Product
> FW
> 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
> Sets the specified firewall MIME flood configuration to the 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 configures the default action for packets when no 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, for Policy-based Firewall-and-NAT configuration, use the access-rule no-ruledef-matches command available in the Firewall-and-NAT Policy Configuration Mode.
> Product
> FW, NAT
> Privilege
> Security Administrator, Administrator
> Syntax
> firewall no-ruledef-matches { downlink | uplink } action { deny [ charging-action charging_action ] | permit [ bypass-nat | nat-realm nat_realm ] }
> default firewall no-ruledef-matches { downlink | uplink } action
> default
> Configures the default action for packets with no Firewall ruledef match.
> Default: uplink direction: permit, downlink direction: deny
> downlink | uplink
> Specifies the packet type:
> downlink: Downlink packets with no Firewall ruledef match.
> uplink: Uplink packets with no Firewall ruledef match.
> action { deny [ charging-action charging_action ] | permit [ bypass-nat | nat-realm nat_realm ] }
> Specifies the default action for packets with no Firewall ruledef match.
> permit [ bypass-nat | nat-realm nat_realm ]: Permit packets. Optionally specify:
> Important: The bypass-nat keyword is only available in StarOS 8.3 and later.

> • | bypass-nat: Specifies to bypass Network Address Translation (NAT).

> • | nat-realm nat_realm: Specifies a NAT realm to be used for performing NAT on subscriber packets. nat_realm must be an alpha and/or numeric string of 1 through 31 characters in length.

> 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 ]: Deny specified packets.
> Optionally, a charging action can be specified. charging_action must be the name of a charging action, and must be a string of 1 through 63 characters in length.
> Usage
> Use this command to configure the default action to be taken on packets with no 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 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.

> • | Firewall ruledef matching is done. If a rule matches, the packet is allowed or dropped as per the firewall priority configuration.

> • | If no firewall ruledef matches, the packet is allowed or dropped as per the no-ruledef-matches configuration.

> For a packet dropped due to 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.
> Example
> The following command sets Firewall to permit downlink packets with no ruledef matches:
> firewall no-ruledef-matches downlink action permit
> firewall policy
> This command enables/disables Stateful Firewall support for all subscribers using this 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, for Policy-based Firewall-and-NAT configuration, this command is available in the Firewall-and-NAT Policy Configuration Mode.
> Product
> FW
> Privilege
> Security Administrator, Administrator
> Syntax
> firewall policy firewall-required
> { default | no } firewall policy
> default
> Sets the default firewall support setting for all subscribers using this rulebase.
> Default: Disabled
> no
> Disables firewall support for all subscribers using this rulebase.
> firewall-required
> Enables firewall support for all subscribers using this rulebase.
> Usage
> Use this command to enable/disable firewall support for all subscribers using this 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 adds and specifies the priority and type of a firewall ruledef in the rulebase, and allows 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, for Policy-based Firewall-and-NAT configuration, use the access-rule priority command available in the Firewall-and-NAT Policy Configuration Mode.
> Product
> FW, NAT
> Privilege
> Security Administrator, Administrator
> Syntax
> firewall priority priority [ dynamic-only | static-and-dynamic ] firewall-ruledef firewall_ruledef { { deny [ charging-action charging_action ] } | { permit [ nat-realm nat_realm | [ trigger open-port { aux_port_number | range start_port_number to end_port_number } direction { both | reverse | same } ] ] } }
> no firewall priority priority
> no
> Removes the previously configured firewall ruledef priority from the rulebase.
> priority
> Specifies the firewall ruledef’s priority in the rulebase.
> priority must be unique, and must be an integer from 1 through 65535.
> [ dynamic-only | static-and-dynamic ] firewall-ruledef firewall_ruledef
> Specifies the firewall ruledef to add to the rulebase. Optionally, the 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 must be the name of a predefined firewall ruledef, and must be a string of 1 through 63 characters in length.
> deny [ charging-action charging_action ]
> 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 firewall ruledefs, only the terminate-flow action is applicable, if configured in the specified charging action.
> charging_action must be a string of 1 through 63 characters in length.
> permit [ nat-realm nat_realm | [ bypass-nat ] [ trigger open-port { aux_port_number | range start_port_number to end_port_number } ] ]
> Permits packets.
> nat-realm nat_realm: Specifies the NAT realm to be used for performing NAT on subscriber packets matching the firewall ruledef.
> If the NAT realm is not specified, then NAT will be bypassed. That is, NAT will not be applied on subscriber packets that are matching a firewall ruledef with no NAT realm name configured.
> nat_realm specifies the NAT realm name, and must be a string of 1 through 31 characters in length.
> bypass-nat: Specifies that packets bypass Network Address Translation (NAT).
> Important: If the nat-realm is not configured, NAT is performed if the nat policy nat-required CLI command is configured with the default-nat-realm option.
> trigger open-port { aux_port_number | range start_port_number to end_port_number }: Permits packets if the rule is matched, and allows the creation of data flows for firewall. Optionally a port trigger can be specified to be used for this rule to limit the range of auxiliary data connections (a single or range of port numbers) for protocols having control and data connections (like FTP). The trigger port will be the destination port of an association which matches a rule.
> aux_port_number: Specifies the number of auxiliary ports to open for traffic, and must be an integer from 1 through 65535.
> range start_port_number to end_port_number: Specifies the range of ports to open for subscriber traffic.
> start_port_number must be an integer from 1 through 65535. This is the start of the port range and must be less than end_port_number.
> end_port_number must be an integer from 1 through 65535. This is the end of the port range and must be greater than start_port_number.
> 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 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 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, 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 firewall ruledefs, only the terminate-flow action is applicable if configured in the specified charging action.
> For a packet dropped due to 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 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 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 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 configures the action to take on TCP flow 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, for Policy-based Firewall-and-NAT configuration, this command is available in the Firewall-and-NAT Policy Configuration Mode.
> Product
> FW
> Privilege
> Security Administrator, Administrator
> Syntax
> firewall tcp-first-packet-non-syn { drop | reset }
> default firewall tcp-first-packet-non-syn
> default
> Sets the default action setting.
> Default: drop
> drop | reset
> Specifies the action to take on TCP flow starting with a non-syn packet.
> drop: Drops the packet or session
> reset: Sends 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 configures action to take 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, for Policy-based Firewall-and-NAT configuration, this command is available in the Firewall-and-NAT Policy Configuration Mode.
> Product
> FW
> Privilege
> Security Administrator, Administrator
> Syntax
> firewall tcp-idle-timeout-action { drop | reset }
> default firewall tcp-idle-timeout-action
> default
> Sets the default action setting.
> Default: reset
> drop | reset
> Specifies the action to take on TCP timeout expiry.
> drop: Drops the packet or session
> reset: Sends reset
> 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 configures 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. In StarOS 8.3, use this command for Rulebase-based Firewall-and-NAT configuration. In StarOS 9.0 and later, for Policy-based Firewall-and-NAT configuration, this command is available in the Firewall-and-NAT Policy Configuration Mode.
> Product
> FW
> Privilege
> Security Administrator, Administrator
> Syntax
> firewall tcp-reset-message-threshold messages then-block-server
> { default | no } firewall tcp-reset-message-threshold
> default
> Configures the default setting.
> Default: The same as no firewall tcp-reset-message-threshold
> no
> Removes the previous configuration.
> 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 enables and configures 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, for Policy-based Firewall-and-NAT configuration, this command is available in the Firewall-and-NAT Policy Configuration Mode.
> Product
> FW
> 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. The firewall passively watches to see if TCP connections become established within a configurable interval. If connections are not established within the timeout period, the 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 specifies the charging action to be used for packets dropped by Firewall due to any error conditions.
> Product
> FW
> Privilege
> Security Administrator, Administrator
> Syntax
> flow any-error charging-action charging_action
> default flow any-error
> default
> Configures the default action for packets dropped by Firewall due to any errors.
> Default: Update the flow stats if flow is available
> charging-action charging_action
> Specifies the charging action based on which accounting action is taken on packets dropped by Firewall due to any errors.
> Important: The charging action specified here should preferably not be used for action on packets dropped due to 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.
> charging_action must be the name of a charging action, and must be a string of 1 through 63 characters in length.
> Usage
> Use this command to configure the charging action for packets dropped by 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 Firewall DoS protection causing the packet to be discarded, and so on.
> For a packet dropped due to 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, 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.
> Example
> The following command specifies the charging action test2 for accounting action on packets dropped/discarded by Firewall due to any error:
> flow any-error charging-action test2
> flow control-handshaking
> This command specifies how to charge for the control traffic associated with an application.
> Product
> ECS
> 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 ]
> no flow control-handshaking [ charge-to-application ]
> Removes the previous flow control-handshaking configuration. The control packets will use whatever content-id is determined by the normal use of the action CLI commands.
> In this command, the optional keyword charge-to-application is deprecated and has no effect.
> default flow control-handshaking
> Configures the default setting.
> Default: The same as no flow control-handshaking.
> charge-to-application
> This keyword 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
> This keyword 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 CLI 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 CLI command also affects applications that do not use TCP but use other methods for control packets, e.g., 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 sets the end condition of the session flows related to a user session and triggers the EDR generation.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> flow end-condition { { content-filtering | normal-end-signaling | timeout + } | { { hagr | handoff | session-end } [ flow-overflow ] + } [ url-blacklisting ] } edr edr_format
> no flow end-condition
> no
> Removes the previously configured end condition of the EDR flow related to a user session.
> content-filtering
> Specifies to create an EDR with format named edr_format when category-based content filtering application action leads to a flow end. Possible Content-filtering actions redirect-url, terminate-flow, content-insert.
> hagr
> Specify to create an EDR with format named edr_format when flow ended due to session handoff according to Interchassis Session Recovery support.
> handoff
> Specify to create an EDR with format named edr_format when flow ended due to hand-off. Whenever a handoff occurs, ACS closes the EDRs for all current flows using the EDR format edr_format, and begin new statistics collection for the flows for the EDRs that will be generated when the flows actually end.
> normal-end-signaling
> Specifies the flow end condition as normal when a flow end is signaled normally 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 EDR format edr_format.
> session-end
> Specify to create an EDR when a subscriber session ends. By this option ACS creates an EDR with format named edr_format for every flow that has had any activity since last EDR was created for the flow on session end.
> timeout
> Specify to create an EDT with format named edr_format when a flow ends or deleted due to a timeout condition.
> flow-overflow
> Important: This keyword is only available in StarOS 8.3 and later. And, is only applicable when used with the hagr, handoff, and session-end keywords.
> Specifies generation of flow-overflow EDR for conditions that affect the callline. If any of the specified end-conditions that affect subscriber information stored at ACS (i.e. callline) is configured the “flow-overflow” EDR is generated.
> url-blacklisting
> Specifies to create an EDR with format named edr_format when URL Blacklisting application action leads to a flow end.
> +
> More than one of the keywords can be entered within a single command.
> edr edr_format
> Specifies the EDR format name to record EDR in specified flow end condition.
> edr_format is a pre-configured format, and must be a unique alpha and/or numeric string 1 through 63 characters in length.
> Usage
> Use this command to enable or disable the capturing of EDRs based on flow end condition.
> Example
> The following command defines the end condition as handoff for flow and creates an EDR with as per format named EDR_format1:
> flow end-condition handoff edr-format EDR_format1
> flow limit-across-applications
> This command limits 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.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> flow limit-across-applications { limit | non-tcp limit | tcp limit }
> no flow limit-across-applications [ non-tcp | tcp ]
> no
> Removes previously configured flow limit related to a rulebase.
> limit
> Specifies the maximum number of flows across all applications for a 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 Charging Action Configuration Mode set to no.
> Example
> The following command defines the maximum number of 200000 flows for a rulebase:
> flow limit-across-applications 200000
> fw-and-nat default-policy
> This command configures the default Firewall-and-NAT policy for an ACS Rulebase.
> Important: This command is only available in StarOS 8.1 and StarOS 9.0 and later. This command must be used to configure the Policy-based Firewall-and-NAT feature.
> Product
> FW, NAT
> Privilege
> Security Administrator, Administrator
> Syntax
> fw-and-nat default-policy fw_nat_policy
> no fw-and-nat default-policy
> no
> Removes the previously configured Firewall-and-NAT policy configured for the current rulebase.
> fw_nat_policy
> Specifies the Firewall-and-NAT policy name.
> fw_nat_policy must be an alpha and/or numeric string of 1 through 63 characters in length.
> Usage
> Use this command to configure the default Firewall-and-NAT policy for an ACS rulebase.
> This policy is used for a subscriber only if:

> • | In the APN/subscriber configuration modes, the default fw-and-nat policy command is configured.

> • | Or, 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
> ip reassembly-timeout
> This command configures how long to hold onto IP fragments for reassembly, while waiting for the complete packet to arrive.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> ip reassembly-timeout timeout_duration
> default ip reassembly-timeout
> default
> Sets the timeout timer to 5000 milliseconds.
> timeout_duration
> Specifies the user configured value to timeout timer to hold fragmented packets before reassembly. timeout_duration is the duration, in milliseconds, and 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 enables the system to reset the IP Type of Service (ToS) value to zero.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> [ default | no ] ip tos-reset
> default
> Sets the default configuration.
> Default: Do not reset the ToS to zero
> no
> Removes the previous configuration.
> Usage
> Use this command to reset the ToS field of any packet after it reaches ECS, or to broaden the range of values that are used in the ToS field in the IP header of any packet.
> nat binding-record
> Configures the NAT binding record generation setting.
> Important: This command is only available in StarOS 8.3. In StarOS 9.0 this command is available in the Firewall-and-NAT Policy Configuration Mode.
> Product
> NAT
> Privilege
> Security Administrator, Administrator
> Syntax
> nat binding-record edr-format edr_format [ port-chunk-allocation ] [ port-chunk-release ] +
> { default | no } nat binding-record
> default
> Configures the default setting.
> Default: port-chunk-release
> no
> Deletes the previous NAT binding record configuration.
> edr-format edr_format
> Specifies the EDR format name.
> edr_format must be an alpha and/or numeric string of 1 through 63 characters in length.
> port-chunk-allocation
> Specifies generating NAT bind record when a port chunk is allocated.
> port-chunk-release
> Specifies generating NAT bind record 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 the NAT binding record generation setting.
> Example
> The following command configures an EDR format named test123 and specifies generating NAT binding record 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 enables/disables Network Address Translation (NAT) processing for all subscribers using this rulebase.
> Important: In StarOS 8.1 and StarOS 9.0 and later, 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, Firewall must be enabled for the subscriber. See the firewall policy CLI command.
> Product
> NAT
> Privilege
> Security Administrator, Administrator
> Syntax
> nat policy nat-required [ default-nat-realm realm_name ]
> { default | no } nat policy
> default
> Sets the default NAT processing setting for all subscribers using this rulebase.
> Default: Disabled
> no
> Disables NAT processing for all subscribers using this rulebase.
> nat-required
> Enables NAT processing for all subscribers using this rulebase.
> default-nat-realm realm_name
> Important: This keyword is only available in StarOS 8.3 and later.
> Specifies the default NAT realm to be used if one is not already configured.
> realm_name must be an alpha and/or numeric string of 1 through 31 characters in length.
> 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 this rulebase.
> Once 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
> This command suppresses the sending of NAT bind updates (NBU) to the AAA server when PPP disconnect happens.
> Important: This command is customer-specific. For more information please contact your local service representative. In StarOS 9.0, this command is available in the Firewall-and-NAT Policy Configuration Mode.
> Product
> NAT
> Privilege
> Security Administrator, Administrator
> Syntax
> nat suppress-aaa-update call-termination
> default nat suppress-aaa-update
> default
> Configures the default setting.
> Default: No suppression of AAA updates
> Usage
> Use this command to suppress the sending of NAT bind updates (NBU) to the AAA server when PPP disconnect happens, 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, NAT bind updates 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 NAT bind updates (NBU) to the AAA server when PPP disconnect happens:
> nat suppress-aaa-update call-termination
> p2p dynamic-flow-detection
> This command enables the P2P analyzer to detect P2P applications configured for the Active Charging service.
> Product
> P2P
> Privilege
> Security Administrator, Administrator
> Syntax
> p2p dynamic-flow-detection
> { default | no } p2p dynamic-flow-detection
> default
> Configures the default setting.
> Default: no p2p dynamic-flow-detection
> no
> Disables detecting P2P applications with the P2P analyzer.
> Usage
> Use this command to set up dynamic-flow detection. This allows the P2P analyzer to detect the P2P applications configured for the Active Charging service.
> post-processing priority
> This command configures the post-processing priority and action to be taken on the specified ruledef in the rulebase.
> Important: This command is only available in StarOS 8.3 and later.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> post-processing priority priority { group-of-ruledefs group_name | ruledef ruledef_name } charging-action charging_action_name [ description description ]
> no post-processing priority priority
> priority priority
> Specifies priority for the ruledef/group-of-ruledefs in the rulebase.
> priority must be an integer from 1 through 65535, and must be unique.
> group-of-ruledefs group_name
> Assigns the specified group-of-ruledefs to the rulebase.
> group_name must be the name of a group-of-ruledefs, and must be an alpha and/or numeric string of 1 through 63 characters in length.
> Important: The group-of-ruledefs specified must be configured for post-processing. See the group-of-ruledefs-application CLI command in the Group-of-Ruledefs Configuration mode.
> ruledef ruledef_name
> Assign the specified ruledef to the rulebase.
> ruledef_name must be an alpha and/or numeric string of 1 through 63 characters in length.
> Important: The ruledef specified must be configured for post-processing. See the rule-application CLI command in the Ruledef Configuration mode.
> charging-action charging_action_name
> Specifies the charging action.
> charging_action_name must be an alpha and/or numeric string of 1 through 63 characters in length.
> description description
> Specifies optional description for this configuration.
> description must be an alpha and/or numeric string of 1 through 31 characters in length.
> 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
> post-processing dynamic
> This command configures specified ruledefs/group-of-ruledefs as dynamic post-processing ruledefs/group-of-ruledefs enabling to differentiate between normal post-processing rules from pre-configured ones. Default: Disabled
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> post-processing dynamic { group-of-ruledefs group_name | ruledef ruledef_name } charging-action charging_action [ description description ]
> no post-processing dynamic { group-of-ruledefs group_name | ruledef ruledef_name }
> no
> Removes the specified post-processing dynamic configuration.
> group-of-ruledefs group_name
> Assigns the specified group-of-ruledefs to the current rulebase.
> group_name must be an alpha and/or numeric string of 1 through 63 characters in length.
> ruledef ruledef_name
> Assigns the specified ruledef to the current rulebase.
> ruledef_name must be an alpha and/or numeric string of 1 through 63 characters in length.
> charging-action charging_action
> Specifies charging action.
> charging_action must be an alpha and/or numeric string of 1 through 63 characters in length.
> description description
> Specifies optional description for this configuration.
> description must be an alpha and/or numeric string of 1 through 31 characters in length.
> Usage
> Use this command to configure specific ruledefs/group-of-ruledefs as dynamic post-processing ruledefs/group-of-ruledefs enabling to differentiate between normal post-processing rules from the pre-configured ones. This makes possible enabling/disabling ruledefs/groups-of-ruledefs entry from 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
> qos-renegotiate timeout
> This command configures the timeout setting for the Quality of Service (QoS) Renegotiation feature.
> Important: This command is controlled by the dynamic-qos-renegotiation license.
> Product
> All
> Privilege
> Security Administrator, Administrator
> Syntax
> qos-renegotiate timeout timeout
> no qos-renegotiate timeout
> no
> Disables timeout setting if previously configured.
> timeout timeout
> Specifies the timeout period for QoS Renegotiation feature in this rulebase.
> timeout must be 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 sets the interval and volume thresholds to generate the interim RADIUS CDRs and write them to CDR file for ECS postpaid billing.
> Product
> All
> Privilege
> Security Administrator, Administrator
> Syntax
> radius threshold { interval interval | volume total volume }
> { no | default } radius threshold { interval | volume total }
> no
> Removes the previously RADIUS threshold configuration.
> default
> Configures the default settings.
> interval interval
> Default: Disabled
> Specifies the time interval (in seconds) for generating RADIUS interim accounting requests. This option is disabled by default. interval must be an integer from 60 through 40000000.
> volume total volume
> Default: Disabled
> 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 100,000 to 4,000,000,000.
> 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 defines a time threshold interval of 600 seconds for RADIUS CDRs:
> radius threshold interval 600
> route priority
> This command controls routing of packets to protocol analyzers.
> Product
> All
> Privilege
> Security Administrator, Administrator
> Syntax
> route priority route_priority ruledef ruledef_name analyzer { dns | file-transfer | ftp-control | ftp-data | 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
> Removes the specified route configuration from the current rulebase.
> priority route_priority
> Specifies the route priority for the 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 the analyzer.
> ruledef_name specifies the name of an existing ruledef configured for the route application using the rule-application command in the Ruledef Configuration Mode.
> 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.

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

> For SIP calls to work with NAT/Stateful Firewall, a SIP 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 optional keyword advanced is configured, the packets matching the routing rule will be routed to SIP ALG for processing and not to ECS SIP analyzer. If not configured, then packets will be routed to ECS 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 alpha and/or numeric string of 1 through 63 characters in length.
> Usage
> Instances of this CLI command control which packets are routed to which protocol analyzers. Packets sent to Active Charging 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 of test, and an analyzer test_analyzer with description as route_test1 to the current rulebase:
> route priority 23 ruledef test analizer test_analyzer description route_test1
> rtp dynamic-flow-detection
> This command enables the RTSP and SDP analyzers to detect the start/stop of RTP and RTCP flows.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> [ no | default ] rtp dynamic-flow-detection
> no
> Disables the previous RTP dynamic flow detection configuration.
> default
> Sets the default RTP dynamic flow detection configuration.
> Default: no rtp dynamic-flow-detection
> 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 configures whether to consider/ignore the port number embedded in the application header (for example, the ":80" in www.starentnetworks.com:80) when comparing the ruledef expressions to the packet contents.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> [ no ] ruledef-parsing ignore-port-numbers-embedded-in-application-headers analyzers { http rtsp sip wsp }
> default ruledef-parsing
> no
> Disables the previous configuration.
> default
> Sets the default configuration.
> Default: 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 }
> Specifies to ignore the port numbers present in application header.
> Specifies analyzers for which 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 configures how long to retain the TCP flow after the FIN has been acknowledged.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> tcp 2msl-timeout seconds
> { default | no } tcp 2msl-timeout
> default
> Sets the default setting.
> Default: 2 seconds
> no
> Disables the timeout and sets the system to delete the flow immediately upon seeing the FIN be acknowledged.
> seconds
> The period of time, in seconds, to keep the TCP flow.
> seconds 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 enables/disables TCP window-size check.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> [ default | no ] tcp check-window-size
> default
> Sets the default setting.
> Default: enabled, i.e. packets after the erroneous packet (with size > receiver’s window size) will hit tcp-error ruledef.
> no
> Disables the window-size check, and will continue 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 configures the TCP Maximum Segment Size (MSS) in TCP SYN packets.
> Important: This command is only available in StarOS 8.1 and later releases.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> tcp mss tcp_mss { add-if-not-present | limit-if-present } +
> { default | no } tcp mss
> default
> Removes the previously configured setting.
> no
> Removes the previously configured setting.
> tcp_mss
> Specifies the TCP MSS value.
> tcp_mss must be an integer from 496 through 65535.
> add-if-not-present
> Adds the TCP MSS if not present in the packet.
> limit-if-present
> Limits 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 mem 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 out-of-order-timeout
> Description This command has been deprecated, and is replaced by the tcp packets-out-of-order command.
> tcp packets-out-of-order
> This command configures processing of TCP packets that are out of order, while waiting for the earlier packet(s) to arrive.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> tcp packets-out-of-order { timeout duration_ms | transmit [ after-reordering | immediately ] }
> default tcp packets-out-of-order { timeout | transmit }
> timeout duration_ms
> Default: 5000 milliseconds
> Specifies the timeout period for re-assembly of TCP out-of-order packets. duration_ms is the timeout period in milliseconds, and must be an integer from 100 through 30000.
> 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
> This command configures 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
> timestamp rounding
> This command enables the configuration of timestamp rounding in an EDR or eG-CDR.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> timestamp rounding { edr | egcdr ) { ceiling | floor | round-off }
> { no | default } timestamp rounding { edr | egcdr )
> no | default
> Default: round-off
> Sets the default setting for timestamp rounding.
> edr
> Perform the timestamp rounding for EDRs.
> egcdr
> Perform the timestamp rounding for eG-CDRs.
> ceiling
> If the fractional part of the seconds is greater than 0, then this keyword adds 1 to the number of seconds and discard the fraction.
> floor
> This keyword always discards the fractional part of the second.
> round-off
> This keyword sets the fractional part of the seconds to nearest integer value. If 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 (i.e., 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; i.e. 34:12.23 to 34:12.00:
> timestamp rounding edr round-off
> transport-layer-checksum
> This command enables/disables checksum verification for TCP and UDP packets.
> Product
> ECS
> 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
> Sets the default configuration.
> Default: 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 or 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 with the route CLI 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 defines and enables the threshold limit to generate User Detail Records (UDRs) that provide Comma Separated Value (CSV) records written periodically in a fixed schema designed to reflect a total billable quantity.
> Product
> All
> 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
> Removes the previous configuration.
> default
> Sets the default configuration.
> Default: no udr threshold interval; no udr threshold volume—disables the UDR threshold settings.
> interval interval
> Default: 0 (Disabled)
> Specifies the time interval in seconds for closing the UDR if the minimum time duration thresholds are satisfied. This option is disabled by default.
> interval must be an integer from 60 through 40000000.
> volume
> Specifies the uplink/downlink volume octet counts for the generation of the interim UDRs.

> • | downlink bytes: Sets the limit for the number of octets downlink after which the UDR is closed. bytes (in bytes) must be an integer from 100,000 to 4,000,000,000. Default is 4,000,000,000.

> • | total bytes: Sets the limit for the total number of octets (uplink+downlink) after which the UDR is closed. bytes (in bytes) must be an integer from 100,000 to 4,000,000,000. By default, this configuration is disabled.

> • | uplink bytes: Sets the limit for the number of octets uplink after which the UDR is closed. bytes ( in bytes) must be an integer from 100,000 through 4,000,000,000. Default is 4,000,000,000.

> UDR records are generated whenever either threshold is reached.
> Usage
> Use this command to enable the 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
> Use this command to assign first packet trigger to interim UDRs—for generating UDR for first packet hit per rating group/content ID.
> Important: This command is only available in StarOS 8.3 and later.
> Product
> ACS
> Privilege
> Security Administrator, Administrator
> Syntax
> [ no ] udr trigger first-hit-content-id
> default udr trigger
> no
> Disables assigning first packet trigger to interim UDRs.
> default
> Configures the default setting.
> Default: Disabled
> first-hit-content-id
> Specifies interim UDR generation on first packet hit per rating group/content ID.
> Usage
> This command enables generating UDR for first packet hit per rating group/content ID. Generation of UDR will be triggered when this CLI command is 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 enables/disables URL Blacklisting functionality for the rulebase, and configures the action to be taken when a URL matches one in the URL Blacklist.
> Product
> ECS, CF
> Privilege
> Security Administrator, Administrator
> Syntax
> url-blacklisting action { discard | redirect-url url | terminate-flow | www-reply-code-and-terminate-flow reply_code } [ edr ]
> { default | no } url-blacklisting action
> [ default | no ] url-blacklisting action
> Disables the URL Blacklisting feature for this rulebase.
> discard
> Configures URL Blacklisting discard action.
> redirect-url url
> Configures URL Blacklisting redirect-url action.
> url specifies the redirect URL/URI. url must be a fully qualified URL/URI, and must be a string of 1 through 1023 characters in length.
> 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 functionality, and configure the EDRs to be generated on Blacklisting match and the action to be taken.
> Example
> The following command enables URL Blacklisting functionality, 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 enables/disables a group-of-prefixed-urls for preprocessing.
> Important: This command is customer specific. For more information, please contact your local service representative.
> Product
> ECS
> Privilege
> Security Administrator, Administrator
> Syntax
> [ no ] url-preprocessing bypass group-of-prefixed-urls group_name
> no
> Removes configuration for the specified group-of-prefixed-urls.
> group_name
> Specifies the group-of-prefixed-urls name.
> group_name must be an alpha and/or numeric string of 1 through 63 characters in length.
> Usage
> Use this command to enable/disable a group-of-prefixed-urls. Multiple groups can be be enabled.
> 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 out-of-order-timeout
> Description This command has been deprecated, and is replaced by the wtp packets-out-of-order command.
> wtp packets-out-of-order
> This command configures how to process WTP packets that are out of order, while waiting for the earlier packet(s) to arrive.
> Product
> ECS
> 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 the default setting.
> out-of-order-timeout timeout
> Specifies the maximum duration for which WTP out-of-order packets are retained, in milliseconds, 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: Send WTP out-of-order segment after it becomes ordered
> immediately: Send 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 configures X-Header Encryption feature parameters.
> Important: This command is license dependent. For more information, please contact your local sales representative.
> Product
> ECS
> 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 the default setting.
> Default: no re-encryption
> no
> Removes the previously configured setting for the specified parameter.
> certificate-name certificate_name
> Specifies name of the encryption certificate to be used for X-Header Encryption feature.
> certificate_name must be the name of a certificate, and must be an an alpha and/or numeric string of 1 through 63 characters in length.
> re-encryption 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.
> 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

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883