SMF supports the following interfaces:

• Gx interface

• Gy interface

For the features related to the Gx and Gy interfaces, see the Interfaces Support chapter.

Important

It should not be assumed that the Diameter interface features available on the SMF have full feature parity and functionality with StarOS or CUPS product. Furthermore, it should not be assumed that any constructs (including, but not limited to, commands, statistics, attributes, MIB objects, alarms, logs, services) referenced in this document imply functional parity with StarOS legacy or CUPS products. Please contact your Cisco Account or Support representative for any questions about parity between this product and any StarOS legacy or CUPS products.

A Diameter endpoint instance is used to configure the Diameter endpoints for different interfaces, such as Gx and Gy. This configuration determines the number of Diameter endpoint pods to be deployed. Configuring a Diameter endpoint instance is mandatory.

A Diameter client is a Diameter node that supports Diameter client applications and the base protocol. A Diameter client is implemented in the devices that are placed at the edge of a network and provides access control services for that network.

A Diameter profile provides network access information for the Diameter application. Each Diameter client profile is associated with an existing endpoint profile and with a failure handling template by its name. SMF uses the client profile name to allow the Diameter endpoint fetch the associated endpoint profile. SMF uses this profile to evaluate the matching endpoint to send the messages.

For encoding Credit Control Requests (CCR) and decoding of the corresponding responses, Credit Control Answer (CCA) messages, you have to configure a dictionary in the Diameter client profile. A dictionary includes the list of AVPs with their descriptions that are used in the CCR and CCA messages, with the standard AVPs or vendor-specific AVPs.

A Diameter endpoint profile provides the following information:

• Origin configuration, such as the origin realm, origin host name, origin state ID, and origin address.

  For the origin state ID, the SMF provides the Diameter endpoint-originated OSI support for the Credit Control Request (CCR) or Device Watchdog Request (DWR) messages. You can enable or disable the dynamic OSI value through Ops Center using the dynamic-origin-state-id CLI command. The Nodemgr updates the OSI value in the cache pod. Then, the Diameter endpoint uses this value to send the Capability Exchange Request (CER), CCR, and DWR messages.

• Peer configuration, such as the peer realm, destination host name, peer IP, and peer port.

• Global parameters, such as destination host AVP, VSA support, and maximum outstanding messages.

• Timeout duration.

You can configure the Diameter endpoint profiles for each interface. These profiles are provisioned to the Diameter endpoint pods corresponding to the interface. Then, these profiles are associated with a specific Diameter client profile.

Note	Configure the Diameter endpoint profile for the Diameter pods deployment.

This section describes about the Disconnect Peer Request (DPR), Disconnect Peer Answer (DPA), and its related CLI commands to configure the DPR and DPA in the Diameter endpoint.

Diameter common stack, which is the Diameter endpoint, is an interface between the NFs and both client and server modes for a supported application.

The following diagram shows the architecture of the common Diameter stack.

The common Diameter stack includes the following components:

• Network Functions—Policy and Charging Rules Function (PCRF) and Online Charging System (OCS)

• Diameter Endpoint

• Diameter interfaces on SMF—Gx and Gy clients

For more information on the supported Diameter interfaces and their related features, see the Interfaces Support chapter.

The Diameter endpoint complies with the following standards:

• 3GPP 29.212 version 15.3.0

• 3GPP 32.299 version 12.9.0

The Diameter endpoint has the following limitation:

• The Diameter endpoint supports only one pair of pods for each interface.

To configure the Diameter endpoint instances, use the following sample configuration:

config 
   instance instance-id instance-id 
      endpoint diameter  
      interface interface_name 
         internal-vip ip_address 
         vip-ip ip_address 
         mode mode_value 
      exit 

NOTES:

• instance instance-id instance-id endpoint diameter : Specify the number of Diameter endpoint pods to be deployed.

• interface interface_name : Specify the interface, such as Gx and Gy, for the Diameter endpoints.

• internal-vip ip_address : Specify the internal VIP IP address for the Diameter endpoint to listen for requests from the service. internal-vip is a mandatory parameter.

• vip-ip ip_address : Specify the VIP IPv4 address for the corresponding to the Diameter clients. vip-ip is a mandatory parameter.

• mode mode_value : Specify the Diameter endpoints with a specific mode. mode is a mandatory parameter.

  Note	SMF supports only the client as mode_value .

To configure the Diameter client profile, use the following sample configuration:

config 
   profile diameter-client diameter_client_name 
      endpoint endpoint_profile_name 
      failure-handling-profile profile_name 
      dictionary-name { dcca-custom8 | default | r8-gx-standard } 
      end 

NOTES:

• profile diameter-client diameter_client_name : Specify a Diameter client profile name.

• endpoint endpoint_profile_name : Specify an existing endpoint profile name to associate it with a Diameter client profile. You can define a maximum of 100 client profiles.

• failure-handling-profile profile_name : Specify an existing failure handling profile to associate it with a Diameter client profile.

• dictionary-name { dcca-custom8 | default | r8-gx-standard } : Specify one of the following dictionaries:

  • dcca-custom8 : This dictionary is the standard Gy dictionary.

  • default : This dictionary is the default dictionary.

  • r8-gx-standard : This dictionary is the standard Gx dictionary.

  Note	The specified dictionary is used for Credit Control - Initial (CCR-I), Credit Control - Update (CCR-U), Credit Control - Terminate (CCR-T), and Re-Authorization Request (RAR) messages.

To configure the Diameter profile endpoint on the Gx and Gy interfaces, use the following sample configuration:

config 
   profile diameter-endpoint interface_name 
      name profile_name 
      internal-vip ip_address 
         destination-host-avp message_type 
         vsa-support vendorId-source 
         max-outstanding number_of_messages 
         response-timeout response_timeout_value 
         connection-timeout connection-timeout_value 
         basemsg retransmission-timeout retransmission_timeout_value 
         basemsg retransmissions max_retry_value 
         basemsg watchdog-interval interval_value 
         dscp [ dscp_value | af11 | af12 | af13 | af21 | af22 | af23 | af31 | af32 | af33 | af41 | af42 | af43 | be | cs1 | cs2 | cs3 | cs4 | cs5 | cs6 | cs7 | ef ]  
         origin realm realm_name 
         origin host host_name address ipv4 ip_address  
         origin peer origin_peer_name  
         realm  realm_name 
         address ipv4 ip_address 
         address vrf vrf_name 
         port peer_port 
         destination-host-name  destination_host_name 
         load-balancing-algorithm highest-weight 
         route-entry host [ host-name | * ] realm [ realm-name | * ] peer peer_name weight weight_value 
         route-failure deadtime deadtime_value result-code result_code_value threshold  number 
         route-failure result-code result_codes_value 
         route-failure threshold  threshold_number 
         route-failure recovery-threshold percent  recovery_threshold_percentage 
         dynamic-route expiry-timeout  expiry_timeout_value  
         dynamic-origin-state-id  boolean_value  
         exit 

NOTES:

• profile diameter-endpoint interface_name : Specify a Diameter profile for the Gx or Gy interface.

• name profile_name : Specify the profile name of the Diameter profile interface. Each profile configures the Diameter source information and the peer information for the Diameter messages that go toward those peers.

  Note	You can define a maximum of 100 profiles per interface.

• internal-vip ip_address : Specify an internal VIP IP address for communication with service pods. internal-vip is a mandatory parameter.

• destination-host-avp message_type : Specify the type of message in which the destination host AVP is to be encoded.

  Note	SMF supports only the always value for the message_type .

• vsa-support vendorId-source : Specify the source of vendor IDs DIABASE to be used for negotiation of Diameter peer capabilities.

  Note	SMF supports only the all-from-dictionary value for the vendorId-source .

• max-outstanding number_of_messages : Specify the maximum number of Diameter messages to be sent to any peer in the profile, while awaiting the responses. The default value is 256. number_of_messages must be in the range of 1–4096.

• response-timeout response_timeout_value : Specify the maximum allowed response time for request messages that the Diameter applications send to the Diameter server. The default value is 60. response_timeout_value must be in the range of 1–300.

• connection-timeout connection-timeout_value : Specify the maximum allowed time for establishing the transport layer connectivity, such as the TCP connection, toward the Diameter server. The default value is 30. connection-timeout_value must be in the range of 1–300.

• basemsg retransmission-timeout retransmission_timeout_value : Specify the timeout value between retransmissions of the base messages, such as Device Watchdog Request (DWR) and Capability Exchange Request (CER), toward the Diameter server. The default value is 30. retransmission_timeout_value must be in the range of 1–120.

• basemsg retransmissions max-retries : Specify the maximum number of times the base messages must be retransmitted. The default value is 1. max-retries must be in the range of 1–10.

• basemsg watchdog-interval interval_value : Specify the minimum time interval between the two DWR messages that are sent toward the Diameter server.

• dscp [ dscp_value | af11 | af12 | af13 | af21 | af22 | af23 | af31 | af32 | af33 | af41 | af42 | af43 | be | cs1 | cs2 | cs3 | cs4 | cs5 | cs6 | cs7 | ef ] : Specify the Differential Services Code Point (DSCP) value in the IP header of the Diameter messages that are sent toward the Diameter server. The default value is be . dscp_value must be in the range of 0–63. Choose in the following other DSCP values, as required:

  • af xx: Specify this value for the use of an assured forwarding xx per hop behavior (PHB).

  • be : Specify this value for the use of the best effort forwarding PHB. be is the default value.

  • cs x: Specify this value for the use of class selector x per PHB.

  • ef : Specify this value for the use of expedited forwarding PHB.

• origin realm realm_name : Specify the name of the realm for the Diameter endpoint. This parameter is mandatory.

• origin host host_name address ipv4 ip_address : Specify the host name, which is the FQDN of the Diameter endpoint. Specify the IPv4 address, which is the Diameter endpoint Bind IP address for the Diameter client connections.

• origin peer origin_peer_name : Specify the identifier for a Diameter peer. This parameter is mandatory.

  Note	You can configure a maximum of 5000 peers.

• realm realm_name : Specify the name of the realm for a peer with the name of the peer. This parameter is mandatory.

• address ipv4 ip_address : Specify the IP address of the Diameter peer.

• address vrf vrf_name : Specify the VRF name that is to be referenced from the Diameter endpoint.

• port peer_port : Specify the port of the Diameter peer. This parameter is mandatory.

• destination-host-name destination_host_name: Specify the custom destination host name to be used in destination host AVP. This parameter is optional.

• load-balancing-algorithm highest-weight : Choose an idle server with the highest weight in failure scenarios. If multiple servers have the same high weight, then the load balancing happens among those servers.

• route-entry host [ host-name | * ] realm [ realm-name | * ] peer peer_name weight weight_value : Use this command to configure two static entries, such as a peer in the route table. If you configure an entry with the existing same flag, host, realm, then only the weight is updated with the higher of the two of them. The host and realm parameters allow wildcard character values. The weight is an optional parameter with the default value as 10. The peer is a mandatory parameter.

  Note	You can configure multiple route entries with the same host and realm but a different peer without being overridden.

• route-failure deadtime deadtime_value result-code result_code_value threshold number : Specify the duration in seconds for which the system keeps the route in the FAILED status. After the configured duration expires, the system changes the status to AVAILABLE . deadtime_value must be an integer in the range of 1–86400. The default value is 60.

• route-failure recovery-threshold percent recovery_threshold_percentage : Specify the percentage value at which the failure counter is reset when provisionally changing the status from FAILED to AVAILABLE . For example, a failure counter of 16 caused the AVAILABLE status to change to FAILED status. After the configured deadtime expires, the status changes to AVAILABLE . If you configured recovery_threshold_percentage with 75 percent, the failure counter resets to 12, which is 75 percent of 16. The default value is 90.

• dynamic-route expiry-timeout expiry_timeout_value : Specify the expiration time for dynamic routes that you created after reaching the Diameter destination host. The default value is 86400 secs, which equals one day.

• dynamic-origin-state-id boolean_value : Specify whether you want to enable or disable the dynamic origin state ID. The default value is true.

  Note

  After the configuration changes from dynamic to static, if the peer is started with either the dynamic origin state ID or the static origin state ID, the peer sends the default static value. Similarly, for a configuration change from the dynamic to static, the peer sends the dynamic value that the Diameter endpoint fetches from the cache pod. In this case, there’s a reconnection.

To configure the busy time for DPR in diameter ep, use the following configuration:

config 
   profile diameter-client diameter_client_name 
      endpoint endpoint-profile-name 
         peer peer_name 
         disconnect peer request  
            busy time time_duration 
            end 

NOTES:

• profile diameter-client diameter_client_name : Specify a Diameter client profile name.

• endpoint endpoint-profile-name : Specify an existing endpoint profile name to associate it with a Diameter client profile.

• peer peer_name : Specify the name of the peer node.

• busy time time_duration : Specify the time duration after which the connection is reattempted to peer. The time duration value must be an integer in the range of 1–300 seconds. The default value is 3 seconds.

To configure the do not talk time for DPR in diameter ep, use the following configuration:

config 
   profile diameter-client diameter_client_name 
      endpoint endpoint-profile-name 
         peer peer_name 
         disconnect peer request  
            do not talk time time_interval 
            end 

NOTES:

• profile diameter-client diameter_client_name : Specify a Diameter client profile name.

• endpoint endpoint-profile-name : Specify an existing endpoint profile name to associate it with a Diameter client profile.

• peer peer_name : Specify the name of the peer node.

• do not talk time time_interval : Specify the time interval between receiving of DPR by diameter endpoint and sending of DPA response. The time interval value must be the integer in the range of 1–300 seconds. The default value is 3 seconds.

To configure the drain time for DPR in diameter ep, use the following configuration:

config 
   profile diameter-client diameter_client_name 
      endpoint endpoint-profile-name 
         peer peer_name 
         disconnect peer request  
            drain time time_interval 
            end 

NOTES:

• profile diameter-client diameter_client_name : Specify a Diameter client profile name.

• endpoint endpoint-profile-name : Specify an existing endpoint profile name to associate it with a Diameter client profile.

• peer peer_name : Specify the name of the peer node.

• drain time time_interval : Specify the time interval between receiving of DPR by diameter endpoint and sending of DPA response. The time interval value must be an integer in the range of 1 to 10 seconds. The default value is 3 seconds.

To configure the reboot time for DPR in diameter ep, use the following configuration:

config 
   profile diameter-client diameter_client_name 
      endpoint endpoint-profile-name 
         peer peer_name 
         disconnect peer request  
            reboot time time_duration 
            end 

NOTES:

• profile diameter-client diameter_client_name : Specify a Diameter client profile name.

• endpoint endpoint-profile-name : Specify an existing endpoint profile name to associate it with a Diameter client profile.

• peer peer_name : Specify the name of the peer node.

• reboot time time_duration : Specify the time duration after which the connection is reattempted to peer. The time duration value must be an integer in the range of 1–300 seconds. The default value is 3 seconds.

The SMF allows you to change the Diameter endpoint configuration dynamically without impacting the existing calls.

The following table lists the impact of dynamic update to the various Diameter endpoint configurations:

The destination-host AVP is used for forwarding or routing a Diameter request message. The destination host name that an application, such as Gx and Gy, uses is identified from the incoming application-level messages. The absence of the destination-host AVP causes a message to be sent to any Diameter server that supports the application within the realm specified in destination-realm AVP.

Based on the end user configuration, you can include the destination-host AVP for the CCR and the retried messages.

To configure the destination host AVP, use the following sample configuration:

config 
   profile diameter-endpoint interface_name 
      instance instance-id instance-id 
         name profile_name 
            destination-host-avp [ always | session-binding ] 
   exit 

NOTES:

• profile diameter-endpoint interface_name : Specify a Diameter endpoint profile, which is either Gx or Gy interface.

• instance instance-id instance-id : Specify the GR instance.

• name profile_name : Specify the Diameter endpoint profile name.

  Note	You can define a maximum of 100 profiles per interface.

• destination-host-avp [ always | session-binding ] : Specify one of the following types of message in which the destination host AVP is to be encoded:

  • always —If destination-host-avp is configured to this message type, include the destination-host-avp in both the CCR-I, CCR-U, or CCR-T messages and the retried messages. always is the default message type.

  • session-binding —If destination-host-avp is configured to this message type, encode the destination-host-avp in CCR-U and CCR-T messages, and not CCR-I and retried messages.

The SMF supports peer management in routing. It allows to choose an appropriate peer for a transaction to occur.

The peer selection logic depends on the Diameter Endpoint and Host Selection configuration.

The Diameter servers connect to the gateway in direct and indirect ways through DRA. The entities involved in the peer management are as follows:

1. Destination-Host: A Diameter entity servicing the request or the final destination for the Diameter message

2. Peer: Connects with the Diameter entity that establishes transport (TCP) connection directly. It can be either a DS or DRA.

3. Route Entry: Defines a path for reaching a Diameter entity from the gateway, essentially the next immediate peer to contact to reach a particular Diameter entity.

4. Routing Table: The diabase library maintains the table of route-entries. The construction of a routing table is through the configuration under the Diameter Endpoint (peer and route-entry CLI) and also dynamically learned from the response messages.

5. Multipath Routes: Multipath Routes are when there are more than one route entry to reach a particular Diameter entity.

The route selection process and its usage in retries are as follows:

1. While providing a response for a CCR-I or CCR-U message, the Diameter endpoint sends the details of the primary host, secondary host, realm, and bounded peer as part of the route data. The same details are provided by the service as part of subsequent requests.

2. In the absence of a route data field in the request from the service, the Diameter endpoint determines primary host, secondary host, and realm from the host selection profile, which is associated with the client profile, specified in the request.

3. Host selection profile has a mandatory primary and an optional secondary host-realm pair. While realm is an optional CLI, it sets to a default value.

4. The host and realm serve as an input to the route search algorithm to find possible multiple matching routes. The order depends on the status, flag and weight.

5. In the absence of host selection profile configuration, the peer management module selects and sorts all the active routes in the route table.

Note	Routes selection happens through the round robin method from the ordered routes list of the primary host or secondary host. This method avoids trying all the routes of the primary host and then trying all the routes of the secondary host.

This section describes about the host selection, its implementation, and the sample configuration for host selection on the Diameter endpoint.

Failure handling is managed by configuring the failure handling profiles for the Diameter messages and failures. With this configuration, the behavior of a Diameter pod is determined in failure scenarios. You can configure any number of failure handling profiles.

After configuring the failure handling profiles, associate them with a specific Diameter client profile. If you don't associate a configured failure handling profile with a Diameter client profile, then a default failure profile is considered.

Failure handling works in the following way:

• If there is a failure, the Diameter endpoint fetches the applicable failure handling profile.

• If the failure handling profiles are not defined or if a profile is defined with no message and failure type that should match the failed request, then the default failure handling is applied. The default failure handling is no retry with the action terminate and subaction as with-term-req , which implies with no termination request.

• Diameter endpoint reattempts request with the alternate peers or routes until the request is successful or the reattempt the reaches the configured retry count as specified by applicable failure handling profile.

• Routes are selected in the round robin method from the ordered routes list of each host. For example, on failure for route of host1, the next route in the list of routes of host2 is used for retrying. During retries, if the route list of one of the hosts exhausts, then the remaining route of other hosts is used for retries.

• During retries if an already tried route is found, then the route is skipped.

• If the applicable peer or route count is lower than the retry count, then remaining retries are discarded after all the applicable peers or routes are attempted.

• Retry count, which is determined during the first failure after the request is sent out, is used. If there is a failure during retries and that failure corresponds to a different failure handling profile with a different retry count, then also Diameter endpoint continues with the retry count that is determined during the first failure.

• Retry counting starts only after a minimum of one request is sent. Failure before the retry count is not considered.

• Even after all the reattempts or all peers or routes reattempts, if the request is not successful, then the Diameter endpoint send the action and subaction as part of response to the service.

• Action and subaction applicable for the most recent failure is used in the response.

• No additional handling is done on the Diameter endpoint for any action or subaction because action for those are taken on the service side as follows:

  Action

  • continue : Continue with the session

  • terminate : Terminate the session. This action is the default action.

  Subaction

  • discard-traffic : Block or discard the data traffic. This subaction is associated with action with the continue . action and is applicable only for the Gy interface.

  • local-fallback : Apply local policies. This subaction is associated with the continue action.

  • none : No action. This subaction is associated with the Associated with continue action and is applicable only for the Gy interface. none is the default option for the Gy calls for the continue action.

  • retry-server-on-event : Reconnect to server on credit control update requests. This subaction is associated with the continue action and is applicable only for the Gx interface.

  • send-ccrt-on-call-termination : Send CCR-T request to PCRF for credit control update request failure. This subaction is associated with the continue action and is applicable only for the Gx interface. send-ccrt-on-call-termination is the default option for Gx calls for continue action.

  • with-term-req : Terminate the session by sending the termination request (CCR-T). This subaction is associated with the terminate action and is applicable only for the Gx interface. with-term-req is the default option for the Gx calls for terminate action.

Configuration of failure handling includes the following steps:

1. Configuring Failure Handling Profile

2. Associating the failure handling profile to the Diameter client profile. To configure the Diameter client profile, see the Configuring Diameter Client Profile procedure.

The SMF maintains the following metrics as part of the Diameter endpoint.

diameter_request_message_total

Description: Indicate the count of diameter requests processed by diameter endpoint.

Note

The peer_address counter is empty for inbound requests and depending on the point of failure, this counter can be empty for the outbound requests. The retry counter is always logged as zero for IPC timeout. The transaction_type counter is hard-coded to "origin". The endpoint_name counter is empty for inbound requests and depending on the point of failure, this counter can empty for outbound requests.

Metrics Type: Counter

Default Level: MetricsVerboseLevelProduction

Label Details:

• interface: gx, gy

• message_name: ccri, ccru, ccrt, rar, asr peer_address

• status: attempted, peer_down, err_cfg, err_maxout, timeout_ipc, err_ipc, err_unmarshal

• retry: retry count gr_instance transcation_type

• endpoint_name: name of endpoint profile used during processing

• message_direction: inbound, outbound

Label Production:

• interface

• message_name

• peer_address status

Label Debug:

• retry

• gr_instance

• transaction_type

Label Trace:

• endpoint_name

• message_direction

diameter_response_message_total

Description: Indicate the count of diameter responses that the Diameter endpoint processes.

Note

The peer_address counter is empty for inbound requests and depending on the point of failure, this counter can be empty for the outbound requests. The result_code counter is logged as " " for outbound responses, local failure, response timeout, and IPC timeout. The action or subaction counter is empty for outbound responses and "success" responses. The endpoint_name counter is empty for inbound requests and depending on the point of failure, this counter can empty for outbound requests.

Metrics Type: Counter

Default Level: MetricsVerboseLevelProduction

Label Details:

• interface: gx, gy

• message_name: ccai, ccau, ccat, raa, asa

• peer_address

• status: success, err_cfg, err_maxout, err_send, timeout_res, timeout_ipc, err_ipc, err_unmarshal, err_rc, err_exp_rc

• result_code: result-code or experimental-result-code that the Diameter node encountered during the response processing

• action: continue, terminate

• subaction: discard-traffic, local-fallback, retry-server-on-event, send-ccrt-on-call-termination, with-term-req, without-term-req

• endpoint_name: name of endpoint profile used during processing

• gr_instance

• message_direction: inbound, outbound

Label Production:

• interface

• message_name

• peer_address status

• status

• result_code

Label Debug:

• action

• subaction

• gr_instance

Label Trace:

• endpoint_name

• message_direction

diameter_response_message_seconds_total

Description: Indicate the cumulative response time in seconds of diameter requests that the Diameter endpoint processes.

Note

The peer_address counter is empty for inbound requests and depending on the point of failure, this counter can be empty for the outbound requests. The result_code counter is logged as " for outbound responses, local failure, response timeout, and IPC timeout. The action or subaction counter is empty for outbound responses and "success" responses. The endpoint_name counter is empty for inbound requests and depending on the point of failure, this counter can empty for outbound requests. This counter is not incremented for local failure or IPC timeout.

Default Level: MetricsVerboseLevelProduction

Label Details:

• interface: gx, gy

• message_name: ccai, ccau, ccat, raa, asa

• peer_address

• status: success, err_cfg, err_maxout, err_send, timeout_res, timeout_ipc, err_ipc, err_unmarshal, err_rc, err_exp_rc

• result_code: result-code or experimental-result-code that the Diameter node encountered during the response processing

• action: continue, terminate

• subaction: discard-traffic, local-fallback, retry-server-on-event, send-ccrt-on-call-termination, with-term-req, without-term-req

• gr_instance

• endpoint_name: name of endpoint profile used during processing

• message_direction: inbound, outbound

Label Production:

• message_name

• origin_host

• origin_realm

• disconnect_cause

• result_code

Label Debug:

• action

• subaction

• gr_instance

Label Trace:

• endpoint_name

• message_direction

diam_base_msg_total

Description: Indicate the count of diameter base message requests that the Diameter endpoint processes.

Note	The DPR counter is supported only for the DPR that is received from a peer. The result_code counter is logged as 5012 if the DPR received has the mandatory AVP missing or if origin-host and origin-realm in DPR does not match with destination-host and destination-realm in connection details.

Metrics Type: Counter

Default Level: MetricsVerboseLevelProduction

Label Details:

• message_name: DPR

• origin_host

• origin_realm

• disconnect_cause: REBOOTING, BUSY, DO_NOT_WANT_TO_TALK_TO_YOU

• result_code: 2001, 5012

• gr_instance

Label Production:

• message_name

• origin_host

• origin_realm

• disconnect_cause

• result_code

Label Debug:

• gr_instance

Label Trace:

• endpoint_name

• message_direction

diam_base_msg_seconds_total

Description: Indicate the cumulative response time in seconds of diameter base message requests that the Diameter endpoint processes.

Note	The DPR counter is supported only for the DPR that is received from a peer. The result_code counter is logged as 5012 if the DPR received has the mandatory AVP missing or if origin-host and origin-realm in DPR does not match with destination-host and destination-realm in connection details.

Default Level: MetricsVerboseLevelProduction

Label Details:

• message_name: DPR

• origin_host

• origin_realm

• disconnect_cause: REBOOTING, BUSY, DO_NOT_WANT_TO_TALK_TO_YOU

• result_code: 2001, 5012

• gr_instance

Label Production:

• interface

• message_name

• diameter_dictionary_type

• status

• unknown_avp

Label Debug:

• gr_instance

diameter_encode_message_total

Description: Indicate the count of diameter base message requests that the Diameter endpoint processes.

Note	The DPR counter is supported only for the DPR that is received from a peer. The result_code counter is logged as 5012 if the DPR received has the mandatory AVP missing or if origin-host and origin-realm in DPR does not match with destination-host and destination-realm in connection details.

Metrics Type: Counter

Default Level: MetricsVerboseLevelProduction

Label Details:

• interface: gx, gy, ""

• message_name: ccri, ccru, ccrt, raa, asa

• endpoint_name: name of endpoint profile used during processing

• dict_name

• status: success, failure, partial

• unknown_avp: 0, 1

• gr_instance

Label Production:

• interface

• message_name

• diameter_dictionary_type

• status

• unknown_avp

Label Debug:

• status_code

• gr_instance

diameter_decode_message_total

Description: Indicate the count of decoding that the Diameter endpoint performed.

Note

The interface is empty for unsupported interface or command code. The message_name counter is empty for the unsupported interface or command code The dict_name counter is empty when default dictionary is used. Else, this counter indicates the name of dictionary that is used for an operation. The status counter is logged as failure only for the unsupported interface or command code. This counter is logged as partial if an issue that is seen during the encoding is ignored. For example, an unknown AVP. The unknown_avp counter indicates if any unknown AVPs are found during encoding, where zero indicates not found and 1 indicates found.

Metrics Type: Counter

Default Level: MetricsVerboseLevelProduction

Label Details:

• interface: gx, gy, ""

• message_name: ccai, ccau, ccat, rar, asr

• endpoint_name: name of endpoint profile used during processing

• dict_name

• status: success, failure, partial

• unknown_avp: 0, 1

• gr_instance

Label Production:

• interface

• message_name

• diameter_dictionary_type

• status

• unknown_avp

Label Debug:

• status_code

• result_code

• gr_instance

Label Trace:

• endpoint_name

diameter_pod_status

Description: Indicate the pod status as active or standby.

Note	Value 1 indicates the status as active and zero indicates the status as standby. The VIP counter is not used to determine the pod status when a Diameter pod is running in server mode. In this case, VIP is empty in the server mode.

Metrics Type: Gauge

Default Level: MetricsVerboseLevelProduction

Label Details:

• vip: VIP used for determining pod status

Label Production:

• vip

Label Debug:

• gr_instance

Label Trace:

• endpoint_name

dispatch_error_total

Description: Indicate the count of inbound requests that had error or timeout during dispatch to service.

Metrics Type: Counter

Default Level: MetricsVerboseLevelProduction

Label Details:

• application

• command_code

• error_code

• gr_instance

Label Production:

• application

• command_code

• error_code

Label Debug:

• gr_instance

dispatch_error_seconds_total

Description: Indicate the cumulative time in seconds spent during dispatching of inbound requests to service that had error or timeout.

Default Level: MetricsVerboseLevelProduction

Label Details:

• application

• command_code

• error_code

• gr_instance

Label Production:

• application

• command_code

• error_code

Label Debug:

• gr_instance

policy_engine_message_total

Description: Indicate the count of messages that are sent to service for which response is received.

Metrics Type: Counter

Default Level: MetricsVerboseLevelProduction

Label Details:

• application

• command_code

• gr_instance

Label Production:

• application

• command_code

Label Debug:

• gr_instance

policy_engine_message_seconds_total

Description: Indicate the cumulative time in seconds spent during processing of a message sent to service.

Default Level: MetricsVerboseLevelProduction

Label Details:

• application

• command_code

• gr_instance

Label Production:

• application

• command_code

Label Debug:

• gr_instance

While debugging issues with the Diameter, use the output of the following commands through the Ops Center:

• kubectl get pods -n namespace

• kubectl get statefulsets -n namespace

• kubectl get cm -n namespace

• kubectl get service -n namespace

• helm list

• show full-configuration or show running-configuration