Syntax
Syntax Description
In 12.1 and earlier releases:
servers-unreachable { initial-request { continue | terminate [ after-timer-expiry timeout_period ] } | update-request { continue | terminate [ after-quota-expiry | after-timer-expiry timeout_period ] } }
no servers-unreachable { initial-request | update-request }
In 12.2 and later releases:
servers-unreachable { behavior-triggers { initial-request | update-request } result-code { any-error | result-code [ to end-result-code ] } | transport-failure [ response-timeout | tx-expiry ] | initial-request { continue [ { [ after-interim-time timeout_period ] [ after-interim-volume quota_value ] } server-retries retry_count ] | terminate [ { [ after-interim-time timeout_period ] [ after-interim-volume quota_value ] } server-retries retry_count | after-timer-expiry timeout_period ] } | update-request { continue [ { [ after-interim-time timeout_period ] [ after-interim-volume quota_value ] } server-retries retry_count ] | terminate [ { [ after-interim-time timeout_period ] [ after-interim-volume quota_value ] } server-retries retry_count ] | after-quota-expiry | after-timer-expiry timeout_period ] } }
no servers-unreachable { initial-request | update-request }
default servers-unreachable behavior-triggers { initial-request | update-request }
Usage Guidelines
Use this command to configure whether to continue/terminate calls when
Diameter server(s)/OCS are unreachable. This command can be used to verify the
functionality of the configurable action if the OCS becomes unreachable.
In 12.1 and earlier releases, the OCS
is considered down/unreachable when all transport/TCP connections are down for
that OCS.
In 12.2 and later releases, the OCS is declared unreachable when all
transport connections are down OR message timeouts happen (for example, a Tx
expiry or response timeout, for all available OCS servers) owing to slow
response from the OCS (may be due to network congestion or other network
related issues).
The following set of actions are performed if the servers become
unreachable:
This command works on the same lines as the
failure-handling command, which is very
generic for each of the xxx-requests.
The
servers-unreachable CLI command is
specifically for TCP connection error. In the event of TCP connection failure,
the
failure-handling and/or
servers-unreachable commands can be used.
This way, the operator has the flexibility to configure CCFH independent of
OCS-unreachable feature, that is having two different failure handlings for
same request types.
Important:
Please note that the flexibility to configure CCFH independent of
OCS-unreachable feature is applicable only to 12.1 and earlier releases. In
12.2 and later releases, if configured, the
servers-unreachable takes precedence over
the
failure-handling command.
This command can also be used to control the triggering of behavior
based on transport failure, response message timeouts or Tx expiry when OCS
becomes unreachable. The OCS could be unreachable due to no TCP connection and
the message timeout could be due to network congestion or any other network
related issues.
The following are the possible and permissible configurations with
respect to behavior triggering:
-
servers-unreachable behavior-triggers {
initial-request | update-request } transport-failure
-
servers-unreachable behavior-triggers {
initial-request | update-request } transport-failure
response-timeout
-
servers-unreachable behavior-triggers {
initial-request | update-request } transport-failure tx-expiry
Of these configurations, the first one is considered to be the default
configuration and it will take care of backward compatibility with 12.0
implementation.
If the server returns the CC-Failure-Handling AVP, it would apply for
transport-failure/response-timeout/tx-expiry when the CLI command
servers-unreachable is not configured. If the
servers-unreachable is configured for a set
of behavior-triggers, then servers-unreachable configuration will be applied
for them. For those behavior-triggers for which servers-unreachable is not
configured, the CC-Failure-Handling value provided by the server will be
applied.
By default, Result-Code such as 3002 (Unable-To-Deliver), 3004
(Too-Busy) and 3005 (Loop-Detected) falls under delivery failure category and
will be treated similar to response-timeout configuration.