> HA Service Configuration Mode Commands
> The Home Agent Service Configuration Mode is used to create and manage the Home Agent (HA) services associated with the current context.
> aaa
> Configures the sending of subscriber session AAA accounting by the HA service.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> aaa { accounting | group string }
> no { accounting | group }
> no
> Disables AAA accounting for the HA service.
> accounting
> accounting Enables the sending of AAA accounting information for subscriber sessions by the Home Agent (HA), by default is enabled.
> group
> group configures aaa group for ha-service, group has lower priority than subscriber/apn config.
> string: size ranges between 1 and 63.
> Usage
> Enabling the HA service will send all accounting data (start, stop, and interim) to the configured AAA servers.
> The chassis is shipped from the factory with the AAA accounting enabled.
> Important: In order for this command to function properly, AAA accounting must be enabled for the context in which the HA service is configured using the aaa accounting subscriber radius command.
> Example
> The following command disables aaa accounting for the HA service:
> no aaa accounting
> authentication
> Configures authentication parameters for a specific HA service of a specific context.
> Product
> HA, ASN-GW
> Privilege
> Security Administrator, Administrator
> Syntax
> authentication {aaa-distributed-mip-keys [ disabled | optional | required ]|dmu-refresh-key | imsi-auth| mn-aaa {allow-noauth | always| dereg-noauth | noauth | renew-reg-noauth | renew-and-dereg-noauth } | mn-ha { allow-noauth | always } | pmip-auth | stale-key-disconnect }
> no authentication {imsi-auth | pmip-auth }
> default authentication { aaa-distributed-mip-keys | dmu-refresh-key | imsi-auth | mn-aaa | mn-ha | pmip-auth | stale-key-disconnect }
> no
> Disable the parameter.
> default
> Reset the specified option to its default setting.
> aaa-distributed-mip-keys [ disabled | optional |required ]
> Configures use of AAA distributed MIP keys for authenticating RRQ for WiMAX HA calls.
> Default is disabled.
> disabled: Disables using AAA distributed WiMAX MIP keys for authenticating MIP RRQ.
> optional: Use AAA distributed WiMAX MIP keys for authenticating RRQ with fallback option to use static/3GPP2 based MIP keys.
> required: AAA distributed WiMAX MIP keys for authenticating MIP RRQ are mandatory
> dmu-refresh-key
> Typically, when a DMU resets then the next MIP re-registration causes MN-HA authorization failure and the HA rejects the MIP RRQ. This parameter enables the HA to retrieve the MN-HA key again from the AAA during the call and to use the freshly retrieved key value to recheck authentication.
> Default is disabled.
> imsi-auth
> Enable uses the IMSI to determine if MN-AAA or MN-FAC extensions are not present in the RRQ.
> Default is disabled.
> mn-aaa { allow-noauth | always | dereg-noauth | noauth | renew-reg-noauth | renew-and-dereg-noauth }
> Specifies how mobile node-to-AAA authentication extension in registration requests from the mobile node should be handled by the HA service.
> Default is always.
> allow-noauth: Specifies that the HA service does not require authentication for every mobile node registration request. However, if the mn-aaa extension is received, the HA service will authenticate it.
> always: Specifies that the HA service will perform authentication each time a mobile node registers.
> dereg-noauth: Disables authentication request upon de-registration.
> noauth: Specifies that the HA service will not look for mn-aaa extension and will not authenticate it.
> renew-reg-noauth: Specifies that the HA service will not perform authentication for mobile node re-registrations. Initial registration and de-registration will be handled normally.
> renew-and-dereg-noauth: Disables authentication request upon re-registration and de-registration.
> mn-ha { allow-noauth | always }
> Specifies whether the HA service looks for an MN-HA authentication extension in the RRQ.
> Default is always.
> allow-noauth: Allows a request that does not contain the auth extension.
> always: A request should always contain the auth extension to be accepted.
> pmip-auth
> Specifies whether the HA service looks for an MN-HA authentication extension in the RRQ.
> Default is always.
> allow-noauth: Allows a request that does not contain the auth extension.
> always: A request should always contain the auth extension to be accepted.
> stale-key-disconnect
> If MN-HA auth fails for MIP renew and dereg, disconnects the call immediately.
> Disabled by default.
> Usage
> The authentication command, combined with a keyword, can be used to specify how the system will perform authentication of registration request messages.
> Example
> The following command configures the HA service to always perform mobile node authentication for every registration request.
> authentication mn-aaa always
> The following command configures the HA service to always look for an MN-HA authentication extension in the RRQ.
> authentication mn-ha always
> bind
> Binds the HA service to a logical IP interface serving as the Pi interface and specifies the maximum number of subscribers that can access this service over the interface.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> bind address address [ max-subscribers count ]
> no bind address
> address
> Specifies the IP address (address) of the interface configured as the Pi interface. address is specified in dotted decimal notation.
> max-subscribers count
> Default: 500000
> Specifies the maximum number of subscribers that can access this service on this interface.
> count can be configured to any integer value between 0 and 4,000,000.
> Important: The maximum number of subscribers supported is dependant on the license key installed and the number of active PACs/PSCs installed in the system. A fully loaded system with 13 active PACs/PSCs can support 1,000,000 total subscribers. Refer to the license key command for additional information.
> Usage
> Associate the HA service to a specific logical IP address. The logical IP address or interface takes on the characteristics of an Pi interface. Only one interface can be bound to a service. The interface should be configured prior to issuing this command.
> This command also sets a limit as to the number of simultaneous subscribers sessions that can be facilitated by the service/interface at any given time.
> When configuring the max-subscribers option, be sure to consider the following:

> • | The total number of interfaces that you will configuring for use as Pi interfaces

> • | The maximum number of subscriber sessions that all of these interfaces may handle during peak busy hours

> • | The average bandwidth for each of the sessions

> • | The type of physical port (10/100Base-T or 1000Base-Tx) that these interfaces will be bound to

> Taking these factors into account and distributing your subscriber session across all available interfaces will allow you to configure your interfaces to optimally handle sessions without degraded performance.
> Use the no bind address command to delete a previously configured binding.
> Example
> The following command would bind the logical IP interface with the address of 192.168.3.1 to the HA service and specifies that a maximum of 600 simultaneous subscriber sessions can be facilitated by the interface/service at any given time.
> bind address 192.168.3.1 max-subscribers 600
> The following command disables a binding that was previously configured:
> no bind address
> default subscriber
> Specifies the name of a subscriber profile configured within the same context as the HA service from which to base the handling of all other subscriber sessions handled by the HA service.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> default subscriber profile_name
> no default subscriber profile_name
> profile_name
> Specifies the name of the configured subscriber profile. profile_name can be between 1 and 127 alpha and/or number characters and is case sensitive.
> Usage
> Each subscriber profile specifies “rules” such as permissions, PPP settings, and timeout values.
> By default, the HA service will use the information configured for the subscriber named default within the same context. This command allows for multiple HA services within the same context to apply different “rules” to sessions they process. Each set of rules can be configured under a different subscriber name which is pointed to by this command.
> Use the no default subscriber profile_name command to delete the configured default subscriber.
> Example
> To configure the HA service to apply the rules configured for a subscriber named user1 to every other subscriber session it processes, enter the following command:
> default subscriber user1
> encapsulation allow gre
> Enables or disables the use of Generic Routing Encapsulation (GRE) when establishing a MIP (Mobile IP) session with an FA. When enabled, if requested by the FA, GRE encapsulation is used when establishing a Mobile IP (MIP) session. If disabled, when an FA requests GRE encapsulation, the HA denies the request.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> encapsulation allow { gre | keyless-gre }
> no encapsulation allow { gre | keyless-gre }
> gre
> Default: Enabled.
> Configures the use of GRE in Mobile IP session with an FA.
> keyless-gre
> Default: Disabled.
> Configures the GRE without key encapsulation in Mobile IP session with an FA.
> Usage
> Use to disable or re-enable the use of GRE encapsulation or Key-less encapsulation for MIP sessions.
> In case of chassis HA operating with other vendor equipment, which does not support the 3GPP2 to exchange key, this command with keyless-gre keyword will make the chassis HA to accept MIP data with legacy GRE.
> Example
> To disable GRE encapsulation for MIP sessions, enter the following command:
> no encapsulation allow gre
> To re-enable GRE encapsulation for MIP sessions, enter the following command:
> encapsulation allow gre
> To enable Key-less GRE encapsulation for MIP sessions, enter the following command:
> encapsulation allow keyless-gre
> end
> Exits the HA service configuration mode and returns to the Exec mode.
> Product
> All
> Privilege
> Security Administrator, Administrator
> Syntax
> end
> Usage
> Change the mode back to the Exec mode.
> exit
> Exits the HA service configuration mode and returns to the context configuration mode.
> Product
> All
> Privilege
> Security Administrator, Administrator
> Syntax
> exit
> Usage
> Return to the context configuration mode.
> fa-ha-spi
> Configures the security parameter index (SPI) between the HA service and the FA.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> fa-ha-spi remote-address fa_ip_address spi-number number { encrypted secret enc_secret | secret secret } [ description string ] [ hash-algorithm { hmac-md5 | md5 | rfc2002-md5 } ] [ replay-protection { timestamp [timestamp-tolerance tolerance ]| nonce }] [ ] Sprint Only +
> no fa-ha-spi remote-address ha_ip_address spi-number number
> remote-address fa_ip_address
> Specifies the IP address of the FA. fa_ip_address is an IP address or an IP address and mask expressed in dotted decimal notation.
> Important: The system supports unlimited peer FA addresses per HA but only maintains statistics for a maximum of 8192 peer FAs. If more than 8192 FAs are attached, older statistics are identified and overwritten.
> spi-number number
> Specifies the SPI (number) which indicates a security context between the FA and the HA in accordance with RFC 2002.
> number can be configured to any integer value between 256 and 4294967295.
> encrypted secret enc_secret | secret secret
> Configures the shared-secret between the HA service and the FA. The secret can be either encrypted or non-encrypted.
> encrypted secret enc_secret: Specifies the encrypted shared key (enc_secret) between the HA service and the FA. enc_secret must be between 1 and 254 alpha and/or numeric characters and is case sensitive.
> secret secret: Specifies the shared key (secret) between the HA service and the FA. secret must be between 1 and 127 alpha and/or numeric characters and is case sensitive.
> The encrypted keyword is intended only for use by the chassis while saving configuration scripts. The system displays the encrypted keyword in the configuration file as a flag that the variable following the secret keyword is the encrypted version of the plain text secret key. Only the encrypted secret key is saved as part of the configuration file.
> description string
> This is a description for the SPI. string must be an alpha and or numeric string of from 1 through 31 characters.
> hash-algorithm { hmac-md5 | md5 | rfc2002-md5 }
> Default: hmac-md5
> Specifies the hash-algorithm used between the HA service and the FA.
> hmac-md5: Configures the hash-algorithm to implement HMAC-MD5 per RFC 2002bis.
> md5: Configures the hash-algorithm to implement MD5 per RFC 1321.
> rfc2002-md5: Configures the hash-algorithm to implement keyed-MD5 per RFC 2002.
> replay-protection { timestamp [timestamp-tolerance tolerance ]| nonce }
> Specifies the replay-protection scheme that should be implemented by the FA service for this SPI.
> nonce: Configures replay protection to be implemented using NONCE per RFC 2002.
> timestamp: Configures replay protection to be implemented using timestamps per RFC 2002.
> timestamp-tolerance: Specifies the allowable difference (tolerance) in timestamps that is acceptable. If the difference is exceeded, then the session will be rejected. tolerance is measured in seconds and can be configured to any integer value between 1 and 65535. The default is 60.
> traffic-group grp_num
> The traffic-group attribute is meant to tag the remote FA so that traffic policy can be enforced according to the traffic-group value. This attribute can be used by ECS to handle subscriber traffic coming from FAs with a specified traffic group differently.
> Note: the functionality controlled by this keyword is only available if a License for Content Access Control has been purchased and enabled.
> grp_num must be an integer from 1 through 255.
> +
> More than one of the above keywords can be entered within a single command.
> Usage
> An SPI is a security mechanism configured and shared by the HA service and the FA. Please refer to RFC 2002 for additional information.
> Though it is possible for FAs and HAs to communicate without SPIs being configured, the use of them is recommended for security purposes. It is also recommended that a “default” SPI with a remote address of 0.0.0.0/0 be configured on both the HA and FA to prevent hackers from spoofing addresses.
> Important: The SPI configuration on the HA must match the SPI configuration for the FA service on the system in order for the two devices to communicate properly.
> A maximum of 2048 SPIs can be configured per HA service.
> Use the no version of this command to delete a previously configured SPI.
> Example
> The following command configures the FA service to use an SPI of 512 when communicating with an HA with the IP address 192.168.0.2. The key that would be shared between the HA and the FA service is q397F65. When communicating with this HA, the FA service will also be configured to use the rfc2002-md5 hash-algorithm.
> fa-ha-spi remote-address 192.168.0.2 spi-number 512 secret q397F65 hash-algorithm rfc2002-md5
> The following command deletes the configured SPI of 400 for an HA with an IP address of 172.100.3.200:
> no fa-ha-spi remote-address 172.100.3.200 spi-number 400
> gre
> Configures Generic Routing Encapsulation (GRE) parameters.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> gre { checksum | checksum-verify | reorder-timeout timeout | sequence-mode { none | reorder } | sequence-numbers }
> no gre { checksum | checksum-verify | sequence-numbers }
> no
> Disables the specified functionality.
> checksum
> Default: disabled
> Enables the introduction of the checksum field in outgoing GRE packets.
> checksum-verify
> Default: disabled
> Enables verification of the GRE checksum (if present) in incoming GRE packets.
> reorder-timeout timeout
> Default: 100
> Configures maximum number of milliseconds to wait before processing reordered out-of-sequence GRE packets. timeout must be an integer from 0 through 5000.
> sequence-mode { none | reorder }
> Default: none
> Configures how incoming out-of-sequence GRE packets should be handled.
> none: Disables reordering of incoming out-of-sequence GRE packets.
> reorder: Enables reordering of incoming out-of-sequence GRE packets.
> sequence-numbers
> Default: Disabled
> Enables the insertion of sequence numbers into the GRE packets.
> Usage
> Use this command to configure how the HA service handles GRE packets.
> Example
> To set maximum number of milliseconds to wait before processing reordered out-of-sequence GRE packets to 500 milliseconds, enter the following command:
> gre reorder-timeout 500
> To enable the reordering of incoming out of sequence GRE packets, enter the following command:
> gre sequence-mode reorder
> To enable the insertion or removal of GRE sequence numbers in GRE packets, enter the following command:
> gre sequence-numbers
> idle-timeout-mode
> Configures the method the HA service uses to determine when to reset a session idle timer.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> idle-timeout-mode { aggressive | handoff | normal } [ upstream-only ]
> default idle-timeout-mode
> default
> Reset the idle timeout mode to the default settings.
> Defaults: aggressive, upstream -only is disabled.
> aggressive
> The session idle timer is reset only when MIP user data is detected. This is the default behavior.
> handoff
> The session idle timer is reset MIP user data is detected and when an inter-Access Gateway/FA handoff occurs.
> normal
> The session idle timer is reset when MIP user data is detected and when any MIP control signaling occurs.
> upstream-only
> Only upstream user data (data from the mobile node) resets the idle timer for the session. This is disabled by default.
> Usage
> Use this command to set how the current HA service resets the idle timer for a session.
> Example
> To reset the idle timer whenever user data is detected or whenever an inter-Access Gateway/FA occurs, use the following command:
> idle-timeout-mode handoff
> ip context-name
> Specifies name of the destination context to be applied to the subscribers; this would take precedence over the same in subscriber configuration and RADIUS return attributes.
> This new configuration overrides the local subscriber configuration as well as the return attributes sent by RADIUS. All calls coming to this HA service are assigned this particular destination context and IP address is allocated from the specified IP pool or group that is configured in the context specified in the service.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> [no] ip context-name name
> name
> Specifies the name of the context to assign the subscriber to once authenticated. name must be from 1 to 79 alpha and/or numeric characters.
> no
> Usage
> Removes the current assigned context from the subscriber’s data.Set the name of the destination context to be applied to the subscribers.
> Example
> ip context-name sampleName
> no ip context-name sampleName
> ip local-port
> Configures the local User Datagram Protocol (UDP) port for the Pi interfaces’ IP socket on which to listen for MObile IP Registration messages.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> ip local-port number
> number
> Specifies the UDP port number.
> number can be any integer value between 1 and 65535.
> Usage
> Specify the UDP port that should be used for communications between the FA service and the HA.
> The chassis is shipped from the factory with the local port set to 434.
> Example
> The following command specifies a UDP port of 3950 for the HA service to use to communicate with the HA on the Pi interface:
> ip local-port 3950
> ip pool
> Specifies name of the IP address pool or group to use for subscriber IP address allocation; this takes precedence over the same in subscriber configuration and RADIUS return attributes.
> This new configuration overrides the local subscriber configuration as well as the return attributes sent by RADIUS. All calls coming to this HA service are assigned this particular destination context and IP address is allocated from the specified IP pool or group that is configured in the context specified in the service.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> ip pool name
> name
> Specifies the logical name of the IP address pool. name must be from 1 to 31 alpha and/or numeric characters.
> no
> Indicates the IP address pool specified is to be removed from the current context’s configuration or disable the specified option for an IP pool.
> Usage
> Define a pool of IP addresses for the context to use in assigning IPs for this service.
> Example
> The specifies name of the IP address pool or group to use for subscriber IP address allocation:ip pool pool1
> The following command removes the specified IP address pool:no ip pool pool1
> isakmp
> Configures the crypto map for a peer HA and configures the default crypto map for the FA service.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> isakmp { peer-fa fa_address | ] } |skew-lifetime time | aaa-context context_name }
> no isakmp { peer-fa fa_address |default | skew-lifetime | aaa-context } default crypto map command is for Combo Phone license
> no
> Deletes the reference to the crypto map for the specified HA, deletes the reference for the default crypto map, resets the skew-lifetime to the default, or resets the aaa-context to the default.
> peer-fa fa_address { crypto map map_name [[ encrypted ] secret secret ]}
> Configures a crypto map for a peer FA.

> • | fa_address: IP address of the peer FA to which this IPSEC SA will be established.

> • | crypto map map_name: The name of a crypto map configured in the same context that defines the IPSec tunnel properties. map_name is the name of the crypto map and can be from 1 to 63 alpha and/or numeric characters.

> • | encrypted: This keyword is intended only for use by the chassis while saving configuration scripts. The system displays the encrypted keyword in the configuration file as a flag that the variable following the secret keyword is the encrypted version of the plain text secret key. Only the encrypted secret key is saved as part of the configuration file.

> • | secret secret: The pre-shared secret that will be used to during the IKE negotiation. secret is the secret string and can be from 1 to 127 alpha and/or numeric characters.

> skew-lifetime time
> Default: 10 seconds
> Configures the IKE pre-shared key’s time skew.
> time is the amount of time the IKE S key fetched from AAA is considered valid after the key has expired. It is measured in seconds and can be configured to any integer value from 1 to 65534.
> aaa-context context_name
> Default: The context in which the service is configured
> Configures the name of the context on the system in which AAA functionality is performed.
> context_name is the name of the context through which the HA service accesses the HAAA server to fetch the IKE S Key and S Lifetime parameters. The name must be from 1 to 63 alpha and/or numeric characters and is case sensitive.
> Usage
> Use this command to configure the FA-service’s per-HA IPSec parameters. These dictate how the HA service is to establish an IPSec SA with the specified FA.
> Important: For maximum security, it is recommended that the above command be executed for every possible FA that the HA service communicates with.
> Note that once an IPSec tunnel is established between the FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.
> Example
> The following command creates a reference for an HA with the IP address 1.2.3.4 to a crypto map named map1:
> isakmp peer-fa 1.2.3.4 crypto-map map1
> The following command deletes the crypto map reference for the HA with the IP address 1.2.3.4.
> no isakmp peer-fa 1.2.3.4
> The following command sets the time an S key can used after the S lifetime expires to 120 seconds.
> isakmp skew-lifetime 120
> The following command creates the default reference for an HA to a crypto map named map1, where peer address is unknown:
> isakmp default crypto-map map1
> mn-ha-spi
> Configures the security parameter index (SPI) between the HA service and the mobile node.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> mn-ha-spi spi-number number [ description string ] [ encrypted secret enc_secret | secret secret ] [ hash-algorithm { hmac-md5 | md5 | rfc2002-md5 } ] [ permit-any-hash-algorithm ] [ replay-protection { nonce | timestamp } ] [ timestamp-tolerance tolerance ]
> no mn-ha-spi spi-number number
> spi-number number
> Specifies the SPI (number) which indicates a security context between the mobile node and the HA service in accordance with RFC 2002. number can be configured to any integer value between 256 and 4294967295.
> description string
> This is a description for the SPI. string must be an alpha and or numeric string of from 1 through 31 characters.
> encrypted secret enc_secret | secret secret
> Configures the shared-secret between the HA service and the mobile node. The secret can be either encrypted or non-encrypted.
> encrypted secret enc_secret: Specifies the encrypted shared key (enc_secret) between the HA service and the mobile node. enc_secret must be between 1 and 254 alpha and/or numeric characters and is case sensitive.
> secret secret: Specifies the shared key (secret) between the HA service and the mobile node. secret must be between 1 and 127 alpha and/or numeric characters and is case sensitive.
> The encrypted keyword is intended only for use by the chassis while saving configuration scripts. The system displays the encrypted keyword in the configuration file as a flag that the variable following the secret keyword is the encrypted version of the plain text secret key. Only the encrypted secret key is saved as part of the configuration file.
> hash-algorithm { hmac-md5 | md5 | rfc2002-md5 }
> Default: hmac-md5
> Specifies the hash-algorithm used between the HA service and the mobile node.
> hmac-md5: Configures the hash-algorithm to implement HMAC-MD5 per RFC 2002bis.
> md5: Configures the hash-algorithm to implement MD5 per RFC 1321.
> rfc2002-md5: Configures the hash-algorithm to implement keyed-MD5 per RFC 2002.
> permit-any-hash-algorithm
> Default: disabled
> Allows verification of the MN-HA authenticator using all other hash-algorithms after failure with configured hash-algorithm. Successful algorithm is logged to aid in troubleshooting and is used to create the MN-HA authenticator in the Registration Reply message.
> replay-protection { nonce | timestamp }
> Default: timestamp
> Specifies the replay-protection scheme that should be implemented by the HA service for this SPI.
> nonce: configures replay protection to be implemented using NONCE per RFC 2002.
> timestamp: configures replay protection to be implemented using timestamps per RFC 2002.
> timestamp-tolerance tolerance
> Default: 60
> Specifies the allowable difference (tolerance) in timestamps that is acceptable. If the difference is exceeded, then the session will be rejected. If this is set to 0, then time stamp tolerance checking is disabled at the receiving end.
> tolerance is measured in seconds and can be configured to any integer value between 0 and 65535.
> Usage
> An SPI is a security mechanism configured and shared by the HA service and the mobile node. Please refer to RFC 2002 for additional information.
> Use the no version of this command to delete a previously configured SPI.
> Example
> The following command configures the HA service to use an SPI of 640 when communicating with a mobile node. The key that would be shared between the mobile node and the HA service is q397F65.
> mn-ha-spi spi-number 640 secret q397F65
> The following command deletes the configured SPI of 400:
> no mn-ha-spi spi-number 400
> nat-traversal
> This command enables NAT traversal and also configures the forcing of UDP tunnels for NAT traversal.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> nat-traversal [force-accept]
> no nat-traversal [force-accept]
> default nat-traversal [force-accept]
> no
> Disables NAT traversal or disables forcing the acceptance of UDP tunnels for NAT traversal.
> default
> Reset the defaults for this command.
> Default: NAT traversal disabled, force-accept disabled.
> force-accept
> This keyword configures the HA to accept requests when NAT is not detected but the Force (F) bit is set in the RRQ with the UDP Tunnel Request. By default this type of request is rejected if NAT is not detected.
> Usage
> Use this command to enable NAT traversal and enable the forcing of UDP tunnels for NAT traversal.
> Example
> The following command enables NAT traversal for the current HA service and forces the HA to accept UDP tunnels for NAT traversal:
> nat-traversal force-accept
> optimize tunnel-reassembly
> Configures HA to FA optimization for tunnel reassembly.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> optimize tunnel-reassembly
> [no] optimize tunnel-reassembly
> Usage
> Enabling this functionality fragments large packets prior to encapsulation for easier processing.
> Tunnel reassembly optimization is disabled by default.
> Important: Cisco Systems strongly recommends that you do not use this command without first consulting Cisco Systems Technical Support. This command applies to very specific scenarios where packet reassembly is not supported at the far end of the tunnel. There are cases where the destination network may either discard the data, or be unable to reassemble the packets.
> Important: This functionality works best when the HA service is communicating with an FA service running in a system. However, an HA service running in the system communicating with an FA from a different manufacturer will operate correctly even if this parameter is enabled.
> Use the no version of this command to disable tunnel optimization if enabled.
> Example
> The following command enables tunnel reassembly optimization:
> optimize tunnel-reassembly
> policy bc-query-result
> Configures the response code to send in a binding cache (BC) query result in response to a network failure or error.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> policy bc-query-result network-failure code
> [ default ] policy bc-query-result network-failure
> network-failure code
> Default: 0xFFFF
> Specify the response code for BC responses sent on network failures.
> code must be either 0xFFFF or 0xFFFE.
> Usage
> Use this command to specify the type of response code to send in a P-MIP BC query result.
> Example
> The following command sets the P-MIP BC query result response code to 0xFFFE:
> policy bc-query-result network-failure 0xFFFE
> policy nw-reachability-fail
> Specifies the action to take upon detection of an up-stream network -reachability failure.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> policy nw-reachability-fail { reject [ use-reject-code { admin-prohibited | insufficient-resources } ] | redirect ip_addr1 [ weight value ] [ ip_addr2 [ weight value ] ... ip_addr16 [ weight value ] ] }
> no policy nw-reachability-fail [ redirect ip_addr1 ... ip_addr16
> ]
> no policy nw-reachability-fail [ redirect ip_addr1 ... ip_addr16 ]
> Deletes the network reachability policy completely or deletes the specified redirect addresses fro the policy.
> reject [ use-reject-code { admin-prohibited | insufficient-resources } ]
> Upon network reachability failure reject all new calls for this context.
> use-reject-code { admin-prohibited | insufficient-resources }: When rejecting calls send the specified reject code. If this keyword is not specified the admin-prohibited reject code is sent by default.
> reject [ use-reject-code { admin-prohibited | insufficient-resources } ]
> Upon network reachability failure reject all new calls for this context. If no reject code is specified, the HA sends a registration reply code of 81H (admin-prohibited).
> use-reject-code { admin-prohibited | insufficient-resources }: Use the specified reject code when rejecting traffic.
> admin-prohibited: When this keyword is specified and traffic is rejected, the error code 81H (admin-prohibited) is returned.
> insufficient-resources: When this keyword is specified and traffic is rejected, the error code 82H (insufficient resources) is returned.
> redirect ip_addr1 [ weight value ] [ ip_addr2 [ weight value ] ... ip_addr16 [ weight value ] ]
> Upon network reachability failure redirect all calls to the specified IP address.
> ip_addr1: This must be an IPv4 address specified in dotted decimal notation. Up to 16 IP addresses and optional weight values can be entered on one command line.
> weight value: When multiple addresses are specified, they are selected in a weighted round-robin scheme. If a weight is not specified the entry is automatically assigned a weight of 1. value must be an integer from 1 through 10.
> Usage
> Use this command to set the action for the HA service to take upon a network reachability failure.
> Important: Refer to the context configuration mode command nw-reachability server to configure network reachability servers.
> Important: Refer to the subscriber configuration mode command nw-reachability-server to bind the network reachability to a specific subscriber.
> Important: Refer to the nw-reachability server server_name keyword of the context configuration mode ip pool command bind the network reachability server to an IP pool.
> Example
> To set the HA service to reject all new calls on a network reachability failure, enter the following command:
> policy nw-reachability-fail reject
> Use the following command to set the HA service to redirect all calls to the HA at IP address 192.168.100.10 and 192.168.200.10 on a network reachability failure:
> policy nw-reachability-fail redirect 192.168.100.10 192.168.200.10
> policy overload
> Configures the overload policy within the HA service.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> policy overload { redirect address [ weight weight_num ] [ address2 [ weight weight_num ] ... address16[ weight weight_num ] ] | reject[ use-reject-code { admin-prohibited | insufficient-resources } ] }
> no policy overload [ redirect address [ address2...address16 ]
> no policy overload [ redirect address [ address2...address16 ] ]
> Deletes a previously set policy or removes a redirect IP address.
> overload: This keyword without any options deletes the complete overload policy from the PDSN service.
> overload redirect address [ address2 ... address16 ]: deletes up to 16 IP addresses from the overload redirect policy. The IP addresses must be expressed in IP v4 dotted decimal notation
> redirect address [ weight weight_num ] [ address2 [ weight weight_num ] ... address16 [ weight weight_num ]
> This option enables a redirect policy for overloading conditions. When a redirect policy is invoked, the HA service rejects new sessions with a Registration Reply Code of 136H (unknown home agent address) and provides the IP address of an alternate HA. This command can be issued multiple times.
> address: The IP address of an alternate HA expressed in IP v4 dotted decimal notation. Up to 16 IP addresses can be specified either in one command or by issuing the redirect command multiple times. If you try to add more than 16 IP addresses to the redirect policy the CLI issues an error message. If you specify an IP address and weight that already exists in the redirect policy the new values override the existing values.
> weight weight_num : When multiple addresses are specified, they are selected in a weighted round-robin scheme. Entries with higher weights are more likely to be chosen. If a weight is not specified the entry is automatically assigned a weight of 1. weight_num must be an integer from 1 through 10.
> reject [ use-reject-code { admin-prohibited | insufficient-resources } ]
> This option causes any overload traffic to be rejected. If no reject code is specified, the HA sends a registration reply code of 81H (admin-prohibited).
> use-reject-code { admin-prohibited | insufficient-resources }: Use the specified reject code when rejecting traffic.
> admin-prohibited: When this keyword is specified and traffic is rejected, the error code 81H (admin-prohibited) is returned.
> insufficient-resources: When this keyword is specified and traffic is rejected, the error code 82H (insufficient resources) is returned.
> Usage
> The system invokes the overload policy if the number of calls currently being processed exceeds the licensed limit for the maximum number of sessions supported by the system.
> The system automatically invokes the overload policy when an on-line software upgrade is started.
> Use the no version of this command to restore the default policy.
> The setting for overload policy is reject.
> Example
> The following command enables an overload redirect policy for the HA service that will send overload calls to either of two destinations with weights of 1 and 10 respectively:
> policy overload redirect 192.168.100.10 weight 1 192.168.100.20 weight 10
> policy null-username
> Configures the current HA service to accept or reject an RRQ without an NAI extension.
> Important: This command is customer specific and is license enabled.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> policy null-username { accept-static | reject }
> no policy null-username
> no
> Set the HA back to the default behavior of rejecting an RRQ without an NAI extension.
> accept-static
> This enable the HA to accept an RRQ with a static (i.e, non-zero) home address request but without NAI extension, when MN-AAA authentication is disabled at the HA. MN-NAI is required for MN-AAA authentication.
> reject
> Default. This is the default behavior of rejecting an RRQ without an NAI extension.
> Usage
> Use this command to enable or disable the HA from accepting an RRQ without an NAI.
> Example
> The following command enables the current HA service to accept RRQs that do not have an NAI extension:
> policy null-username accept-static
> private-address allow-no-reverse-tunnel
> This command allows the HA service to accept private addresses without using reverse tunneling.
> Important: This command is customer specific and is license enabled.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> private-address allow-no-reverse-tunnel
> no private-address allow-no-reverse-tunnel
> no
> Reject MIP calls that use private addresses and do not use reverse tunneling.
> Usage
> Use this command to enable or disable the HA from accepting calls that use private addresses without reverse tunneling.
> Example
> The following command enables the current HA service to accept MIP calls that use private addresses but do not use reverse tunneling:
> private-address allow-no-reverse-tunnel
> reg-lifetime
> Specifies the longest registration lifetime that the HA service will allow in any Registration Request message from the mobile node.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> reg-lifetime time
> no reg-lifetime
> no
> Sets the registration lifetime to infinite.
> time
> Specifies the registration lifetime.
> time is measured in seconds and can be configured to any integer value between 1 and 65534.
> Usage
> Use to limit a mobile nodes lifetime. If the mobile node requests a shorter lifetime than what is specified, it is granted. However, Per RFC 2002, should a mobile node request a lifetime that is longer than the maximum allowed by this parameter, the HA service will respond with the value configured by this command as part of the Registration Reply.
> The chassis is shipped from the factory with the registration lifetime set to 600 seconds.
> Example
> The following command configures the registration lifetime for the HA service to be 2400 seconds:
> reg-lifetime 2400
> The following command configures an infinite registration lifetime for MIP calls:
> no reg-lifetime
> reverse-tunnel
> Enables the use of reverse tunneling for a Mobile IP sessions when requested by the mobile node.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> reverse-tunnel
> no reverse-tunnel
> no
> Indicates the reverse tunnel option is to be disabled. When omitted, the reverse tunnel option is enabled.
> Usage
> Reverse tunneling involves tunneling datagrams originated by the mobile node to the HA service via the FA.
> When an MN arrives at a foreign network, it listens for agent advertisements and selects an FA that supports reverse tunnels. The MN requests this service when it registers through the selected FA. At this time, the MN may also specify a delivery technique such as Direct or the Encapsulating Delivery Style.
> Among the advantages of using reverse-tunneling are that:

> • | All datagrams from the mobile node seem to originate from its home network

> • | The FA can keep track of the HA that the mobile node is registered to and tunnel all datagrams from the mobile node to its HA

> Use the no version of this command to disable reverse tunneling. If reverse tunneling is disabled, and the mobile node does not request it, triangular routing will be performed.
> routing will be used.
> The chassis is shipped from the factory with the reverse tunnel enabled.
> Important: If reverse tunneling is disabled on the system and a mobile node requests it, the call will be rejected with a reply code of 74H (reverse-tunneling unavailable).
> Example
> The following command disables reverse-tunneling support for the HA service:
> no reverse-tunnel
> revocation
> Enables the MIP revocation feature and configures revocation parameters.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> revocation { enable | max-retransmission number | negotiate-i-bit | retransmission-timeout secs | send-nai-ext | trigger { handoff | idle-timeout } }
> no revocation { enable | negotiate-i-bit | send-nai-ext |trigger { handoff | idle-timeout } }
> no
> Completely disables registration revocation on the HA, disables trigger handoff, or disables revocation on idle timer expiration.
> enable
> Enables the MIP registration revocation feature on the HA. When enabled, if revocation is negotiated with an FA and a MIP binding is terminated, the HA can send a Revocation message to the FA. This feature is disabled by default.
> max-retransmission number
> Default: 3
> The maximum number of retransmissions of a Revocation message before the revocation fails. number must be an integer from 0 through 10.
> negotiate-i-bit
> Default: disabled
> Enables the HA to negotiate the i-bit via PRQ/RRP messages and processes the i-bit revocation messages.
> retransmission-timeout secs
> Default: 3
> The number of seconds to wait for a Revocation Acknowledgement from the FA before retransmitting the Revocation message. secs must be an integer from 1 through 10.
> send-nai-ext
> Default: off
> Enables sending the NAI extension in the revocation message.
> trigger { handoff | idle-timeout }
> handoff: Default: Enabled
> Triggers the HA to send a Revocation message to the FA when an inter-Access Gateway/FA handoff of the MIP session occurs. If this is disabled, the HA is never triggered to send a Revocation message.
> idle-timeout: Default: Enabled
> Triggers the HA to send a Revocation message to the FA when a session idle timer expires.
> Usage
> Use this command to enable or disable the MIP revocation feature on the HA or to change settings for this feature. Both the HA and the FA must have Registration Revocation enabled and FA/HA authorization must be in use for Registration Revocation to be negotiated successfully.
> Example
> The following command enables Registration Revocation on the HA:
> revocation enable
> The following command sets the maximum number of retries for a Revocation message to 10:
> revocation max-retransmission 10
> The following command sets the timeout between retransmissions to 3:
> revocation retransmission-timeout 3
> The behavior of send MIP revocation to FA is as follows:
> 1st retry: Retransmit in 3 seconds after previous MIP revocation send.
> 2nd retry : Retransmit in 6 seconds after previous MIP revocation send (9 seconds after sending initial MIP revocation).
> 3rd retry : Retransmit in 12 seconds after previous MIP revocation send (21 seconds after sending initial MIP revocation).
> 4th retry : Retransmit in 24 seconds after previous MIP revocation send (45 seconds after sending initial MIP revocation).
> 5th retry : Retransmit in 48 seconds after previous MIP revocation send (93 seconds after sending initial MIP revocation).
> Important: The value of retransmission-timeout doubles. HA disconnects the session forcibly in 120 seconds after sending initial MIP revocation.
> setup-timeout
> The maximum amount of time allowed for session setup.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> setup-timeout seconds
> seconds
> Default: 60 seconds
> The maximum amount of time, in seconds, to allow for setup of a session. must be an integer from 1 through 1000000
> Usage
> Use this command to set the maximum amount of time allowed for setting up a session.
> Example
> To set the maximum time allowed for setting up a session to 5 minutes (300 seconds), enter the following command:
> setup-timeout 300
> simul-bindings
> Specifies the maximum number of “care-of” addresses that can simultaneously be bound for the same user as identified by NAI and Home address.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> simul-bindings number
> number
> Configures the maximum number of simultaneous “care-of” bindings that the HA service will maintain for any given subscriber.
> number can be configured to any integer value between 1 and 3.
> Usage
> Per RFC 2002, the HA service creates a mobile binding record (MBR) for each subscriber session it is facilitating. Each MBR is associated with a care-of address. As the mobile node roams, it is possible that the session will be associated with a new care of address.
> Typically, the HA service will delete an old binding and create a new one when the information in the Registration Request changes. However, the mobile could request that the HA maintains previously stored MBRs. This command allows you to configure the maximum number of MBRs that can be stored per subscriber if the requested.
> The chassis is shipped from the factory with the simultaneous sessions set to 3.
> Example
> The following command configures the HA service to support up to 4 MBRs per subscriber:
> simul-bindings 4
> threshold init-rrq-rcvd-rate
> Set an alarm or alert based on the average number of calls setup per second for the context.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> threshold init-rrq-rcvd-rate high_thresh [ clear low_thresh]
> no threshold init-rrq-rcvd-rate
> no
> Deletes the alert or alarm.
> high_thresh
> Default: 0
> The high threshold average number of calls setup per second must be met or exceeded within the polling interval to generate an alert or alarm. It can be configured to any integer value between 0 and 100000.
> clear low_thresh
> Default:0
> The low threshold average number of calls setup per second that must be met or exceeded within the polling interval to clear an alert or alarm. It can be configured to any integer value between 0 and 100000.
> Important: This value is ignored for the Alert model. In addition, if this value is not configured for the Alarm model, the system assumes it is identical to the high threshold.
> Usage
> Use this command to set an alert or an alarm when the average number of calls setup per second is equal to or greater than a specified number of calls per second.
> Alerts or alarms are triggered for the number of calls setup per second based on the following rules:

> • | Enter condition: Actual number of calls setup per second > High Threshold

> • | Clear condition: Actual number of calls setup per second < Low Threshold

> Example
> The following command configures a number of calls setup per second threshold of 1000 and a low threshold of 500 for a system using the Alarm thresholding model:
> threshold init-rrq-rcvd-rate 1000 clear 500
> threshold ipsec-call-req-rej
> Configures a threshold for the total IPSec calls request rejected.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> threshold ipsec-call-req-rej high_thresh [ clear low_thresh ]
> no threshold ipsec-call-req-rej
> no
> Deletes the alert or alarm.
> high_thresh
> Default: 0
> The high threshold number of IPSec call requests rejected per second must be met or exceeded within the polling interval to generate an alert or alarm.
> high_thresh can be configured to any integer value between 0 and 1000000.
> clear low_thresh
> Default:0
> The low threshold number of IPSec call requests rejected per second that must be met or exceeded within the polling interval to clear an alert or alarm.
> low_thresh can be configured to any integer value between 0 and 1000000.
> Important: This value is ignored for the Alert model. In addition, if this value is not configured for the Alarm model, the system assumes it is identical to the high threshold.
> Usage
> Use this command to set an alert or an alarm when the number of IPSec call requests rejected is equal to or greater than a specified number per second.
> Alerts or alarms are triggered for the number of IPSec IKE requests on the following rules:

> • | Enter condition: Actual number of IPSec IKE requests > High Threshold

> • | Clear condition: Actual number of IPSec IKE requests < Low Threshold

> Example
> The following command configures a number of IPSec call requests rejected threshold of 1000 and a low threshold of 800 for a system using the Alarm thresholding model:
> threshold ipsec-call-req-rej 1000 clear 800
> threshold ipsec-ike-failrate
> Configures a threshold for the percentage of IPSec IKE failures.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> threshold ipsec-ike-failrate high_thresh [ clear low_thresh ]
> no threshold ipsec-ike-failrate
> no
> Deletes the alert or alarm.
> high_thresh
> Default: 0
> The high threshold percentage of IPSec IKE failures per second must be met or exceeded within the polling interval to generate an alert or alarm.
> high_thresh can be configured to any integer value between 0 and 100.
> clear low_thresh
> Default:0
> The low threshold percentage of IPSec IKE failures per second that must be met or exceeded within the polling interval to clear an alert or alarm.
> low_thresh can be configured to any integer value between 0 and 100.
> Important: This value is ignored for the Alert model. In addition, if this value is not configured for the Alarm model, the system assumes it is identical to the high threshold.
> Usage
> Use this command to set an alert or an alarm when the percentage of IPSec IKE failures is equal to or greater than a specified number per second.
> Alerts or alarms are triggered for the percentage of IPSec IKE failures on the following rules:

> • | Enter condition: Percentage of IPSec IKE failures > High Threshold

> • | Clear condition: Percentage of IPSec IKE failures < Low Threshold

> Example
> The following command configures a percentage of IPSec IKE failures threshold of 1000 and a low threshold of 800 for a system using the Alarm thresholding model:
> threshold ipsec-ike-failrate 90 clear 80
> threshold ipsec-ike-requests
> Configures a threshold for the total IPSec IKE failures.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> threshold ipsec-ike-failures high_thresh [ clear low_thresh ]
> no threshold ipsec-ike-failures
> no
> Deletes the alert or alarm.
> high_thresh
> Default: 0
> The high threshold number of IPSec IKE failures per second must be met or exceeded within the polling interval to generate an alert or alarm.
> high_thresh can be configured to any integer value between 0 and 1000000.
> clear low_thresh
> Default:0
> The low threshold number of call IPSec IKE failures per second that must be met or exceeded within the polling interval to clear an alert or alarm.
> low_thresh can be configured to any integer value between 0 and 1000000.
> Important: This value is ignored for the Alert model. In addition, if this value is not configured for the Alarm model, the system assumes it is identical to the high threshold.
> Usage
> Use this command to set an alert or an alarm when the number of IPSec IKE failures is equal to or greater than a specified number per second.
> Alerts or alarms are triggered for the number of IPSec IKE failures on the following rules:

> • | Enter condition: Actual number of IPSec IKE failures > High Threshold

> • | Clear condition: Actual number of IPSec IKE failures < Low Threshold

> Example
> The following command configures a number of IPSec IKE failures threshold of 1000 and a low threshold of 800 for a system using the Alarm thresholding model:
> threshold ipsec-ike-failures 1000 clear 800
> threshold ipsec-ike-failures
> Configures a threshold for the total IPSec IKE failures.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> threshold ipsec-ike-failures high_thresh [clear low_thresh ]
> no threshold ipsec-ike-failures
> no
> Deletes the alert or alarm.
> high_thresh
> Default: 0
> The high threshold number of IPSec IKE failures per second must be met or exceeded within the polling interval to generate an alert or alarm.
> high_thresh can be configured to any integer value between 0 and 1000000.
> clear low_thresh
> Default:0
> The low threshold number of call IPSec IKE failures per second that must be met or exceeded within the polling interval to clear an alert or alarm.
> low_thresh can be configured to any integer value between 0 and 1000000.
> Important: This value is ignored for the Alert model. In addition, if this value is not configured for the Alarm model, the system assumes it is identical to the high threshold.
> Usage
> Use this command to set an alert or an alarm when the number of IPSec IKE failures is equal to or greater than a specified number per second.
> Alerts or alarms are triggered for the number of IPSec IKE failures on the following rules:

> • | Enter condition: Actual number of IPSec IKE failures > High Threshold

> • | Clear condition: Actual number of IPSec IKE failures < Low Threshold

> Example
> The following command configures a number of IPSec IKE failures threshold of 1000 and a low threshold of 800 for a system using the Alarm thresholding model:
> threshold ipsec-ike-failures 1000 clear 800
> threshold ipsec-tunnels-established
> Configures a threshold for the total IPSec tunnels established.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> threshold ipsec-tunnels-established high_thresh [ clear low_thresh ]
> no threshold ipsec-tunnels-established
> no
> Deletes the alert or alarm.
> high_thresh
> Default: 0
> The high threshold number of IPSec tunnels established per second must be met or exceeded within the polling interval to generate an alert or alarm.
> high_thresh can be configured to any integer value between 0 and 1000000.
> clear low_thresh
> Default:0
> The low threshold number of call IPSec tunnels established per second that must be met or exceeded within the polling interval to clear an alert or alarm.
> low_thresh can be configured to any integer value between 0 and 1000000.
> Important: This value is ignored for the Alert model. In addition, if this value is not configured for the Alarm model, the system assumes it is identical to the high threshold.
> Usage
> Use this command to set an alert or an alarm when the number of IPSec tunnels established is equal to or greater than a specified number per second.
> Alerts or alarms are triggered for the number of IPSec tunnels established on the following rules:

> • | Enter condition: Actual number of IPSec tunnels established > High Threshold

> • | Clear condition: Actual number of IPSec tunnels established £ Low Threshold

> Example
> The following command configures a number of IPSec tunnels established threshold of 1000 and a low threshold of 800 for a system using the Alarm thresholding model:
> threshold ipsec-tunnels-established 1000 clear 800
> threshold ipsec-tunnels-setup
> Configures a threshold for the total IPSec tunnels setup.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> threshold ipsec-tunnels-setup high_thresh [ clear low_thresh ]
> no threshold ipsec-tunnels-setup
> no
> Deletes the alert or alarm.
> high_thresh
> Default: 0
> The high threshold number of IPSec tunnels setup per second must be met or exceeded within the polling interval to generate an alert or alarm.
> high_thresh can be configured to any integer value between 0 and 1000000.
> clear low_thresh
> Default:0
> The low threshold number of call IPSec tunnels setup per second that must be met or exceeded within the polling interval to clear an alert or alarm.
> low_thresh can be configured to any integer value between 0 and 1000000.
> Important: This value is ignored for the Alert model. In addition, if this value is not configured for the Alarm model, the system assumes it is identical to the high threshold.
> Usage
> Use this command to set an alert or an alarm when the number of IPSec tunnels setup is equal to or greater than a specified number per second.
> Alerts or alarms are triggered for the number of IPSec tunnels setup on the following rules:

> • | Enter condition: Actual number of IPSec tunnels setup > High Threshold

> • | Clear condition: Actual number of IPSec tunnels setup < Low Threshold

> Example
> The following command configures a number of IPSec tunnels setup threshold of 1000 and a low threshold of 800 for a system using the Alarm thresholding model:
> threshold ipsec-tunnels-setup 1000 clear 800800
> threshold reg-reply-error
> Set an alarm or alert based on the number of registration reply errors per HA service.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> threshold reg-reply-error high_thresh [ clear low_thresh ]
> no threshold reg-reply-error
> no
> Deletes the alert or alarm.
> high_thresh
> Default: 0
> The high threshold number of registration reply errors that must be met or exceeded within the polling interval to generate an alert or alarm. It can be configured to any integer value between 0 and 100000.
> clear low_thresh
> Default:0
> The low threshold number of registration reply errors that must be met or exceeded within the polling interval to clear an alert or alarm. It can be configured to any integer value between 0 and 100000.
> Important: This value is ignored for the Alert model. In addition, if this value is not configured for the Alarm model, the system assumes it is identical to the high threshold.
> Usage
> Use this command to set an alert or an alarm when the number of registration reply errors is equal to or greater than a specified number of calls per second.
> Alerts or alarms are triggered for the number of registration reply errors on the following rules:

> • | Enter condition: Actual number of registration reply errors > High Threshold

> • | Clear condition: Actual number of registration reply errors < Low Threshold

> Example
> The following command configures a registration reply error threshold of 1000 and a low threshold of 500 for a system using the Alarm thresholding model:
> threshold reg-reply-error 1000 clear 500
> threshold rereg-reply-error
> Set an alarm or alert based on the number of re-registration reply errors per HA service.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> threshold rereg-reply-error high_thresh [ clear low_thresh]
> no threshold rereg-reply-error
> no
> Deletes the alert or alarm.
> high_thresh
> Default: 0
> The high threshold number of re-registration reply errors that must be met or exceeded within the polling interval to generate an alert or alarm. It can be configured to any integer value between 0 and 100000.
> clear low_thresh
> Default:0
> The low threshold number of re-registration reply errors that must be met or exceeded within the polling interval to clear an alert or alarm. It can be configured to any integer value between 0 and 100000.
> Important: This value is ignored for the Alert model. In addition, if this value is not configured for the Alarm model, the system assumes it is identical to the high threshold.
> Usage
> Use this command to set an alert or an alarm when the number of re-registration reply errors is equal to or greater than a specified number of calls per second.
> Alerts or alarms are triggered for the number of re-registration reply errors on the following rules:

> • | Enter condition: Actual number of re-registration reply errors > High Threshold

> • | Clear condition: Actual number of re-registration reply errors < Low Threshold

> Example
> The following command configures a reregistration reply error threshold of 1000 and a low threshold of 500 for a system using the Alarm thresholding model:
> threshold dereg-reply-error 1000 clear 500
> threshold dereg-reply-error
> Set an alarm or alert based on the number of de-registration reply errors per HA service.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> threshold dereg-reply-error high_thresh [ clear low_thresh]
> no threshold dereg-reply-error
> no
> Deletes the alert or alarm.
> high_thresh
> Default: 0
> The high threshold number of de-registration reply errors that must be met or exceeded within the polling interval to generate an alert or alarm. It can be configured to any integer value between 0 and 100000.
> clear low_thresh
> Default:0
> The low threshold number of de-registration reply errors that must be met or exceeded within the polling interval to clear an alert or alarm. It can be configured to any integer value between 0 and 100000.
> Important: This value is ignored for the Alert model. In addition, if this value is not configured for the Alarm model, the system assumes it is identical to the high threshold.
> Usage
> Use this command to set an alert or an alarm when the number of de-registration reply errors is equal to or greater than a specified number of calls per second.
> Alerts or alarms are triggered for the number of de-registration reply errors on the following rules:

> • | Enter condition: Actual number of de-registration reply errors > High Threshold

> • | Clear condition: Actual number of de-registration reply errors < Low Threshold

> Example
> The following command configures a de-registration reply error threshold of 1000 and a low threshold of 500 for a system using the Alarm thresholding model:
> threshold reg-reply-error 1000 clear 500
> wimax-3gpp2 interworking
> Configures the interworking between WiMAX and 3GPP2 network at HA. This support provides handoff capabilities from 4G to 3G (PDSN) network access and vice-versa.
> Product
> HA
> Privilege
> Security Administrator, Administrator
> Syntax
> [no | default] wimax-3gpp2 interworking
> no
> Disables the pre-configured interworking between WiMAX and 3GPP2 networks at HA level.
> default
> Configures the WiMAX-3GPP2 interworking to default setting; i.e. disabled.
> Usage
> Use this command to enable/disable the interworking between WiMAX and 3GPP2 network for seamless session continuity.
> This functionality provides HA support for both 4G and 3G technology HA (WiMAX HA and PDSN/HA) for handoff from 4G and 3G network access (ASN GW/FA and PDSN/FA) and vice-versa.
> Important: Use this command in conjunction with authentication aaa-distributed-mip-keys required command.
> Example
> The following command enables the interworking for a subscriber between WiMAX and 3GPP2 network.
> wimax-3gpp2 interworking

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