This section describes the debugging capabilities for troubleshooting a Diameter or Diameter application problem.
Debugging should be as specific as possible and limited to relevant messages only. Enabling detailed debugging for all diameter messages on a production node generates a flood of information and is not very helpful in isolating the problem; it can, however, be a valid scenario for lab testing.
Diameter debug output can be limited to:
messages to a specified origin or destination realm
Messages that have no origin or destination realm AVP to match against are also shown in this configuration.
debug
diameter
dest-realm dest.com
origin-realm origin.com
exit
exit
messages of specified message types
debug
diameter
message-type ccr cca
exit
exit
messages sent or received on peers belonging to a specific Diameter peer policy. Up to eight diameter peer policies can be specified
debug
diameter
diameter-peer-policy "diameter-peer-policy-1"
exit
diameter-peer-policy "diameter-peer-policy-2"
exit
exit
exit
messages sent or received on a specific Diameter peer
debug
diameter
diameter-peer "peer-1"
exit
exit
Only messages that match all specified criteria are shown in the debug output.
The diameter debug detail-level command can be set to
debug
diameter
detail-level medium
exit
exit
For a per-diameter peer policy additional criteria can be specified to further restrict the debug output to:
messages sent or received on a specific Diameter peer
overrides the peer configuration at the debug diameter level
debug
diameter
diameter-peer-policy "diameter-peer-policy-1"
diameter-peer "peer-1"
exit
exit
exit
messages of specified message types
overrides the message type at the debug diameter level
debug
diameter
diameter-peer-policy "diameter-peer-policy-1"
message-type ccr cca rar raa
exit
exit
exit
messages from a diameter session where the diameter session is learned from Diameter application messages matching specified AVP values (avp-match criteria)
debug
diameter
diameter-peer-policy "diameter-peer-policy-1"
avp-match 1
avp 443.444 octetstring ascii value "1/1/1:10.20@bng1"
message-type ccr
no shutdown
exit
exit
exit
exit
Only messages sent or received on a peer that belongs to the diameter peer policy and matches all specified criteria are shown in the debug output.
To restrict debug output to messages from a diameter session, AVP matching with session learning is required. AVP 263 Session-Id is the only Diameter AVP that is present in all messages of a Diameter session and is dynamically assigned when the Diameter session is initiated. The session ID is not useful to specify as criteria in debugging because its value is unknown upfront. Instead, using AVP matching, it is possible to learn the session ID from Diameter application messages (NASREQ, Gx, and Gy) matching a message type and one or multiple AVP values. All subsequent Diameter application messages that belong to the learned session ID are then included in the debug output, as shown in the following example:
debug
diameter
detail-level medium
diameter-peer-policy "diam-pol-1"
avp-match 1
avp 25 octetstring ascii value "trace-me"
avp 10415-1005 octetstring ascii value "sub-id:vip-1"
message-type cca
no shutdown
exit
avp-match 2
avp 443.444 octetstring ascii value "1/1/1:10.20@bng1"
message-type ccr
no shutdown
exit
message-type ccr cca rar raa
exit
message-type all
exit
exit
In this configuration, the debug output for Diameter messages is restricted to messages of type ccr, cca, rar, or raa that are sent or received on diameter peer policy ‟diam-pol-1” and that belong to Diameter sessions for which:
a CCA message is received with Class AVP = ‟trace-me” and 3GPP Charging-Rule-Name AVP = ‟sub-id:vip-1”. The session ID is learned from the message. All subsequent ccr, cca, rar, and raa messages with the same session ID are also shown until a relearning occurs: a new CCA message received matching the AVP criteria specified for this AVP match ID. If still available in the system, the corresponding CCR message is also shown.
a CCR message is received with subscription-id-data AVP = "1/1/1:10.20@bng1" (grouped within the subscription-id AVP). Session ID learning occurs for this AVP match ID and all subsequent ccr, cca, rar, and raa messages with the same session ID are shown as described above.
The rules for Diameter debug AVP matching are summarized below:
Diameter debug AVP match criteria are specified in an avp-match id command. Up to five AVP match IDs can be specified per diameter peer policy. For each AVP match ID, a unique Session ID is learned and the corresponding messages are logged in debug: OR function for all debug diameter diameter-peer-policy policy avp-match id commands.
For each AVP match ID, a message-type and at least one AVP ID criteria must be specified. Up to five AVP ID criteria can be specified per each AVP match ID. Session ID learning or relearning occurs when all specified AVP ID criteria are matched in any of the specified application message types: AND function for all debug diameter diameter-peer-policy policy avp-match id avp avp-id commands.
For each AVP in an AVP match, the AVP ID, type, and value should be specified:
avp-id is specified as [vendor-id-]avp-code[.avp-id] with nesting up to five levels deep. For example: ‟443.444” to indicate Subscription-Id. Subscription-Id-Data and ‟456.10415-871” to indicate Multiple-Services-Credit-Control.Quota-Holding-Time.
type corresponds to the type as defined in the standards or as defined in the Diameter Interface Specification document for vendor-specific AVPs. The following types are supported: octetstring (used for utf8string, octetstring and diameterid), integer32, integer64, unsigned32, unsigned64, and address. Any AVP can be specified as an octetstring in hex format.
value is the AVP value to be matched. Optionally the format in which the value is specified can be configured as ASCII or hex. A hex string is specified as "0xaabbcc…" (starting with "0x" followed by the hex nibbles).
The message type specified in an avp-match id command is only used as match criteria and does not limit the debug output:
debug
diameter
diameter-peer-policy "diam-pol-1"
avp-match 1
avp 443.444 octetstring ascii value "1/1/1:10.20@bng1"
message-type ccr
no shutdown
exit
message-type ccr cca rar raa
exit
exit
exit
In this configuration, the session ID is learned only from CCR messages with subscription-id data AVP = ‟1/1/1:10.20@bng1”. When the session ID is learned, all CCR, CCA, RAR and RAA messages from that session ID are shown in the debug output.
When at least one AVP match ID is configured with the debug diameter diameter-peer-policy policy avp-match id no shutdown command, only the messages for learned session IDs for the specified diameter peer policy are shown in the debug output. An AVP match ID in shutdown state is not active (session ID learning disabled and no debug messages are logged for this AVP match ID).
If the session ID learning happens based on a match in an Answer message, then the corresponding Request message is also logged in debug only if it was still available in the system.
Relearning occurs when a message from a session ID different from the learned session ID matches all specified AVP ID criteria in any of the specified application message types. The learned session ID for the AVP match ID is overwritten.
Messages from a learned session ID are no longer matched against the AVP match criteria. The same session ID is learned only once.
Learning or relearning events are reported in the debug output:
174 2016/01/21 15:31:02.63 UTC MINOR: DEBUG #2001 Base DIAMETER
"DIAMETER: Session-Id learning
diameter-peer-policy diameter-peer-policy-1 avp-match 1 learned Session-Id bng.origin.com;1453294062;8 (replacing Session-Id bng.origin.com;1453294062;7)"
The learned session ID is deleted when the corresponding AVP match ID debug command is deleted or shutdown.
The tools>dump>debug>diam>avp-match-learned-session-id command displays the current learned Diameter session IDs for each Diameter application policy AVP match ID.