在ASR5K上配置故障处理和服务器不可达机制，以解决OCS故障

简介

本文档介绍如何在Gy接口上配置故障处理(FH)和服务器不可达(SU)机制，以解决在线计费系统(OCS)上或与策略和计费实施功能(PCEF)与OCS之间的连接相关的问题。本文档中介绍的信息适用于在Cisco 5000系列聚合服务路由器(ASR5K)上运行的家庭代理(HA)、网关通用分组无线业务(GPRS)支持节点(GGSN)和分组数据网络网关(PGW)功能。

先决条件

要求

思科建议您的系统满足以下要求，以便使用FH和SU机制：

• 增强计费服务(ECS)可用
  
  
• PCEF存在于HA、GGSN或PGW中
  
  
• 通过辉绿岩有适当的直径连接
  
  
• Diameter信用控制应用(DCCA)可用

使用的组件

本文档中的信息基于ASR5K的所有版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。

背景信息

PCEF通过Gy接口连接到OCS，该接口使用Diameter作为基本协议和DCCA。以下是PCEF和OCS之间的消息流：

• 信用控制请求€(CCR)“ — 此消息从PCEF发送到OCS。CCR消息有三种类型：初始、更新和终止。
  
  
• 信用控制答案€(CCA)“ — 此消息从OCS发送到PCEF以响应CCR。还有三种类型的CCA消息：初始、更新和终止。
  
  
• 重新授权请求(RAR)€ - “此消息在需要重新授权会话时从OCS发送到PCEF。
  
  
• 重新授权答案(RAA)€ - “这是对RAR的响应，从PCEF到OCS。

在PCEF和OCS之间建立直径连接以启用消息流。OCS可能会发送负消息，PCEF和OCS之间的传输连接可能会失败，或者消息可能超时，这可能导致用户会话建立失败。这会阻止用户使用服务。

以下两种机制可用于解决此问题：

• 跳频机制
  
  
• SU机制

配置

本节介绍支持FH和SU机制所需的配置。

网络图

本文档中的信息使用以下拓扑：

Tx到期

这是DCCA的应用级计时器，可在直径信用控制设置中配置。该值的范围为1到300秒。

示例如下：

[local]host_name(config-dcca)# diameter pending-timeout 
     
     

响应超时

这是禁用超时，可在“直径终端”设置中配置。该值的范围为1到300秒。

注意：为此计时器配置的值应大于Tx-Expiry计时器的值。

示例如下：

[context_name]host_name(config-ctx-diameter)# response-timeout 
     
     

Diameter会话故障转移

此功能用于启用或禁用直径信用控制会话故障切换，允许系统在主服务器无法访问时使用辅助服务器。这可在直径信用控制设置中配置。

示例如下：

local]host_name(config-dcca)# diameter session failover

FH机制

FH机制仅在存在直径会话故障切换时运行。FH允许系统选择是继续会话并转换为脱机，还是在发生连接或消息级错误时终止会话。

注意：默认情况下，FH已启用并配置。

FH机制配置

FH机制可以在直径信用控制设置中配置。以下是FH配置中使用的语法：

failure-handling { initial-request | terminate-request | update-request } { continue
 [ go-offline-after-tx-expiry | retry-after-tx-expiry ] | retry-and-terminate,
 [ retry-after-tx-expiry ] | terminate }

第一部分指定请求类型:初始(CCR-I)、更新(CCR-U)和终止(CCR-T)。

第二部分指定激活FH机制时应执行的操作。FH机制可以执行以下三种操作：

• 继续 - € “ — 这允许会话继续并将其转换为脱机。此函数使用两个与Tx-expiry相关的选项：
  
  
  • Go-offline-after-tx-expiry € — 此“操作在Tx-expiry发生后开始脱机计费。
    
    
  • Retry-after-tx-expiry € ⠓ — 在Tx-expiry发生后重试辅助服务器。
    
    
• 重试并终止 € ⠓ — 如果辅助服务器也不可用，则在系统重试辅助服务器后终止会话。这还使用Retry-after-tx-expiry选项，该选项在Tx-expiry发生后重试辅助服务器。
  
  
• 终止 € - “此操作将终止会话，而不会尝试联系辅助服务器。

FH机制默认行为

本节介绍当没有配置时的FH默认行为。默认情况下，FH机制在响应超时(RT)期间激活，除非配置了终止操作。

如果从服务器接收信用控制故障处理属性值对(AVP)，则应用接收的设置。

例如：

• 初始请求>终止
  
  
• 更新请求(Update-Request)>重试并终止(Retry-and-Terminate)
  
  
• Terminate-Request > Retry-and-Terminate

FH机制详细呼叫流

本节介绍FH机制的详细呼叫流程以及所有可能的选项。

初始请求

CCFH设置	CLI命令	Tx的行为	RT的行为	辅助为Up	辅助关闭
继续	初始请求 继续	不适用	继续	辅助 之后 RT	在另一个RT后脱机。 不再执行配额请求 对于会话中的任何评级组 DCCA故障后(即使 与DCCA的连接已恢复)
	初始请求 继续脱机后 tx-expiry	离线	不适用	在Tx处脱机	在Tx处脱机
	初始请求 继续重试后 tx-expiry	继续	不适用	辅助 之后 Tx	在另一个Tx后脱机
重试并终止	初始请求 retry-and-terminate	不适用	重试	辅助 之后 RT	在另一个RT后终止
	初始请求 retry-and-terminate retry-after-tx-expiry	重试	不适用	辅助 之后 Tx	在另一Tx后终止
终止	初始请求 终止	终止	不适用	Tx后终止	Tx后终止

更新请求

CCFH设置	CLI命令	Tx的行为	RT的行为	辅助为Up	辅助关闭
继续	更新请求 继续	不适用	继续	辅助 之后 RT	在另一个RT后脱机
	更新请求 继续脱机后 tx-expiry	离线	不适用	在Tx处脱机	在Tx处脱机
	更新请求 继续重试后 tx-expiry	继续	不适用	辅助 之后 Tx	在另一个Tx后脱机
重试并终止	更新请求 retry-and-terminate	不适用	重试	辅助 之后 RT	在另一个RT后发送CCR-T
	更新请求 retry-and-terminate retry-after-tx-expiry	重试	不适用	辅助 之后 Tx	在另一个Tx之后发送CCR-T
终止	更新请求 终止	终止	不适用	在Tx之后发送CCR-T	在Tx之后发送CCR-T

Terminate-Request

CCFH设置	CLI命令	Tx的行为	RT的行为	辅助为Up	辅助关闭
继续	terminate-request 继续	不适用	重试	CCR-T已发送 辅助 RT后	在另一个RT后终止
	terminate-request 继续脱机后 tx-expiry	重试	不适用	CCR-T已发送 辅助 Tx之后	在另一Tx后终止
	terminate-request 继续重试后 tx-expiry	重试	不适用	CCR-T已发送 辅助 Tx之后	在另一Tx后终止
重试并终止	terminate-request retry-and-terminate	不适用	重试	CCR-T已发送 辅助 RT后	在另一个RT后终止
	terminate-request retry-and-terminate retry-after-tx-expiry	重试	不适用	CCR-T已发送 辅助 Tx之后	在另一Tx后终止
终止	terminate-request 终止	终止	不适用	终止于 Tx	Tx后终止

SU机制

SU机制与FH机制相似，但它对故障过程提供更精细的控制。除了消息和连接级别（传输）故障后会话继续，当OCS的响应速度慢时，还可以使用此机制。它还提供以下选项：在终止之前继续会话一段时间持续时间/配额耗尽，或在会话转换为脱机或终止之前使用可配置的临时配额（卷和时间）和可配置服务器重试。 

SU机制配置

SU机制可在直径信用控制设置中配置。SU配置中使用的语法因使用的版本而异。

对于版本12.1及更低版本，以下是用于SU机制配置的语法：

servers-unreachable { initial-request { continue | terminate [ after-timer-expiry
 <timeout_period> ] } | update-request { continue | terminate [ after-quota-expiry
 | aftertimer-expiry <timeout_period> ] } }

对于版本12.2及更高版本，以下是用于SU机制配置的语法：

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> ] } }

注意：在12.2版之前的版本中，可以灵活地独立配置FH和SU机制；但是，在版本12.2及更高版本中，SU机制在配置时优先于FH机制。

如果服务器返回CC-FH AVP，并且SU机制配置为一组行为触发器，则应用SU配置；否则，应用CC-FH AVP值。默认情况下，结果代码（如3002、3004和3005）处于传递失败状态，并被视为RT。

SU机制可以执行以下操作：

• Behavior-Trigger €â “ Â这指定可以是Initial-Requests(CCR-I)或Update-Requests(CCR-U)的消息类型。 有三个选项可用于这些触发器：
  
  
  • 结果代码€ - “ — 这允许配置特定结果代码、结果代码范围(3000-5999)或任何错误以及消息类型。
    
    
  • Transport-Failure € ⠓ Â此规范在传输失败时触发行为，该行为向后兼容版本12.0。此设置有两个可用选项：
    
    
    • Response-Timeout €â “ Â此选项在RT时触发行为，应始终用于传输故障。
      
      
    • Tx-Expiry €â “此选项在Tx-expiry时触发行为，应始终与传输失败一起使用。
      
      
  • 操作€ - “Â指定当发生CCR-I或CCR-U的SU触发器时执行的操作。此操作因消息类型和软件版本而异。
    
    
• 继续€ — 这“允许会话转换为脱机并继续。在版本12.2之前的版本中，没有其他可用于使用此操作的选项。在版本12.2及更高版本中，临时配额、服务器重试和计时器到期后选项可用于使用此操作进行配置。
  
  
• Terminate € - “Â当服务器无法访问时，会终止会话。此操作允许临时配额、服务器重试和计时器到期后选项。

这些选项可与“继续”或“终止”操作一起使用：

• After-time-time € ⠓此选项允许在中间超时期之后继续或终止呼叫。这类似于执行操作之前的时间配额。该值以秒为单位格式化，范围为1到4,294,967,295。
  
  
• After-interim-volume € “ — 此选项分配临时配额并允许在已配置卷耗尽之前继续或终止会话。该值以字节为格式，范围为1到4,294,967,295。
  
  
• Server-retries € ⠓此选项允许PCEF在会话继续或终止之前重试OCS。可以配置重试计数，其值范围为0到65,535。如果值为零，则不会重试，并立即应用操作。

注意：after-interim-time 和after-interim-volume 选项始终与server-retries 选项一起使用，或者这三个选项可同时使用，并应用于继续操作和终止操作。after-interim-time和after-interim-volume选项也分配了时间和卷配额，而用完的配额会首先触发服务器重试。

• After-timer-expiry € ⠓此选项指定会话在终止之前保持脱机状态的持续时间（以秒为单位）。值的范围为1到4,294,967,295。此选项仅适用于终止活动。
  
  
• After-quota-expiry € - “此选项在已分配的配额用尽时终止会话。

以下是一些需要记住的重要信息：

• after-time-time、after-time-volume和server-retries选项可单独或组合使用，并且它们适用于继续和终止操作。
  
  
• after-quota-expiry选项仅适用于Update-Requests行为触发器。
  
  
• after-timer-expiry选项仅适用于终止操作。
  
  
• after-interim-time、after-interim-volume和server-retries选项仅适用于版本12.2及更高版本。
  
  
• 如果支持（并配置了）直径会话故障切换，则始终在触发SU机制之前联系辅助服务器。
  
  
• 当中间时间或中间卷用尽且服务器重试选项配置了大于零的值时，始终与上次在触发SU机制之前联系的服务器联系。例如，如果先尝试OCS1，在OCS1发生错误后尝试OCS2，则与OCS2的通信将触发SU机制。在服务器重试尝试期间，如果从OCS2收到负响应，则首先联系OCS2，然后联系OCS1。

SU机制呼叫流

SU机制可能由CCR-I或CCR-U的故障触发，原因可能是错误代码、传输故障、Tx-expiry或RT。该操作可以是临时配额（时间和/或卷）分配、服务器重试次数、计时器值（导致会话在指定时间内脱机并仅终止）或配额到期（仅用于CCR-U和终止），然后会话离线或终止。

在多服务信用控制(MSCC)方案中，临时配额按会话提供，而不是按评级组(RG)提供。

主服务器可能触发传输失败，而辅助服务器可能触发Tx-expiry或response-timeout。在此场景中，最新错误被视为故障的触发因素。

如果SU机制未配置任何故障触发，则触发FH机制。

注意：以下各节提供一些与SU机制相关的呼叫流示例。这些呼叫流的提供假设是支持diameter-session-failover，并且辅助服务器配置了小于RT值的Tx-expiry值。此外，还假设SU机制配置为传输故障、Tx-expiry和RT。

不断开会话的初始请求

以下是此场景的消息流：

1. PCEF向OCS发送CCR-I。
   
   
2. 检测到超时或传输失败。如果检测到传输失败，则PCEF立即重试辅助服务器；否则，将触发Tx-expiry。
   
   
3. 如果辅助服务器也发生传输故障或超时，则会触发SU机制。对于传输失败，或在超时的Tx到期后，会立即发生这种情况。
   
   
4. 如果配置了临时卷和/或时间，则会为会话分配临时配额。
   
   
5. 在中间配额（时间或卷）耗尽后，如果服务器重试次数值大于零，则CCR-I将再次发送到触发SU机制的服务器。如果出现另一个故障，CCR-I将发送到另一台服务器。
   
   
6. 如果再次检测到传输失败或Tx超时，则重复步骤2至5，直到服务器重试值耗尽或OCS没有成功响应。
   
   
7. 如果问题仍然存在，则会根据配置继续（转换为脱机）或终止会话。

注意：会话进入SU模式时由于CCR-I而消耗的临时配额未在下一个CCR-I中报告。在CCR-U中报告所有使用的临时配额，CCA-I在成功之后。

会话断开时的初始请求

以下是此场景的消息流：

1. PCEF向OCS发送CCR-I。
   
   
2. 检测到超时或传输失败。如果检测到传输失败，则PCEF立即重试辅助服务器；否则，将触发Tx-expiry。
   
   
3. 如果辅助服务器也发生传输故障或超时，则会触发SU机制。对于传输失败，或在超时的Tx到期后，会立即发生这种情况。
   
   
4. 如果配置了临时卷和/或时间，则会为会话分配临时配额。
   
   
5. 在中间配额（时间或卷）耗尽后，如果服务器重试次数值大于零，则CCR-I将再次发送到触发SU机制的服务器。如果出现另一个故障，CCR-I将发送到另一台服务器。
   
   
6. 如果再次检测到传输失败或Tx超时，则重复步骤2至5，直到服务器重试值耗尽或OCS没有成功响应。此时，会话断开连接，不占用整个临时配额。
   
   
7. 会话终止后，PCEF再次发送CCR-I以开始新会话。如果成功，则PCEF会发送CCR-T，CCR-T会报告所使用的整个临时配额。

更新请求，不断开会话

以下是此场景的消息流：

1. PCEF向OCS发送CCR-U。
   
   
2. 检测到超时或传输失败。如果检测到传输失败，则PCEF立即重试辅助服务器；否则，将触发Tx-expiry。
   
   
3. 如果辅助服务器也发生传输故障或超时，则会触发SU机制。对于传输失败，或在超时的Tx到期后，会立即发生这种情况。
   
   
4. 如果配置了临时卷和/或时间，则会为会话分配临时配额。
   
   
5. 在中间配额（时间或卷）耗尽后，如果服务器重试次数值大于零，则CCR-U再次发送到触发SU机制的服务器。如果出现另一个故障，则CCR-U会发送到包含整个已消耗的未报告配额的另一台服务器。
   
   
6. 如果再次检测到传输失败或Tx超时，则重复步骤2至5，直到服务器重试值耗尽或OCS没有成功响应。
   
   
7. 使用成功的CCR-U，将整个消耗的配额报告给OCS。
   
   
8. 如果问题仍然存在，则会话将继续（转换为脱机）或根据配置在最大重试值耗尽后终止。

会话断开时的更新请求

以下是此场景的消息流：

1. PCEF向OCS发送CCR-U。
   
   
2. 检测到超时或传输失败。如果检测到传输失败，则PCEF立即重试辅助服务器；否则，将触发Tx-expiry。
   
   
3. 如果辅助服务器也发生传输故障或超时，则会触发SU机制。对于传输失败，或在超时的Tx到期后，会立即发生这种情况。
   
   
4. 如果配置了临时卷和/或时间，则会为会话分配临时配额。
   
   
5. 在中间配额（时间或卷）耗尽后，如果服务器重试次数值大于零，则CCR-U再次发送到触发SU机制的服务器。如果出现另一个故障，则CCR-U会发送到包含整个已消耗的未报告配额的另一台服务器。
   
   
6. 如果再次检测到传输失败或Tx超时，则重复步骤2至5，直到服务器重试值耗尽或OCS没有成功响应。此时，会话在消耗整个临时配额之前会断开连接。
   
   
7. PCEF向OCS发送CCR-T以报告整个消耗配额。
   
   
8. 如果OCS使用2002年结果代码做出响应，则不需要其他报告。

具有未知会话的更新请求

以下是此场景的消息流：

1. PCEF向OCS发送CCR-U。
   
   
2. 检测到超时或传输失败。如果检测到传输失败，则PCEF立即重试辅助服务器；否则，将触发Tx-expiry。
   
   
3. 如果辅助服务器也发生传输故障或超时，则会触发SU机制。对于传输失败，或在超时的Tx到期后，会立即发生这种情况。
   
   
4. 如果配置了临时卷和/或时间，则会为会话分配临时配额。
   
   
5. 在中间配额（时间或卷）耗尽后，如果服务器重试次数值大于零，则CCR-U再次发送到触发SU机制的服务器。如果出现另一个故障，则CCR-U会发送到包含整个已消耗的未报告配额的另一台服务器。
   
   
6. OCS使用CCR-U的5002（未知会话ID）结果代码进行回复，在OCS重新启动并丢失会话ID信息的场景中，这是可能的。
   
   
7. PCEF启动与CCR-I的新会话并接收CCA-I。
   
   
8. PCEF在后续消息中通过CCR-U报告已消耗的整个临时配额。

使用多个RG的更新请求（MSCC方案）

以下是此场景的消息流：

1. PCEF将RG1的CCR-U发送到OCS。
   
   
2. 检测到超时或传输失败。如果检测到传输失败，则PCEF立即重试辅助服务器；否则，将触发Tx-expiry。
   
   
3. 如果辅助服务器也发生传输故障或超时，则会触发SU机制。对于传输失败，或在超时的Tx到期后，会立即发生这种情况。
   
   
4. 如果配置了临时卷和/或时间，则会为会话分配临时配额
   
   
5. 此时，RG2也会耗尽所分配的整个配额，但不会启动CCR-U，因为会话已处于SU模式并开始消耗临时配额。
   
   
6. 在中间配额（时间或卷）耗尽后，如果服务器重试次数值大于零，则CCR-U再次发送到触发SU机制的服务器。如果出现另一个故障，则CCR-U会发送到包含两个RG的全部未报告配额的另一台服务器。
   
   
7. 如果再次检测到传输失败或Tx超时，则重复步骤2到6，直到服务器重试次数值耗尽或OCS没有成功响应。
   
   
8. 使用成功的CCR-U，将整个消耗的配额报告给OCS。
   
   
9. 如果问题仍然存在，则会话将继续（转换为脱机）或根据配置在最大重试值耗尽后终止。

Terminate-Request

以下是此场景的消息流：

1. PCEF向OCS发送CCR-T。
   
   
2. 检测到超时或传输失败。如果检测到传输失败，则PCEF立即重试辅助服务器；否则，将触发Tx-expiry。
   
   
3. 如果辅助服务器也出现传输故障或超时，则会删除会话。

CCR错误代码处理

以下是此场景的消息流：

1. PCEF向OCS发送CCR，OCS回复错误代码。
   
   
2. 错误代码在SU机制中静态配置。
   
   
3. PCEF提供临时配额，无需向辅助服务器重试。

FH和SU示例配置

本节提供FH和SU机制的配置示例。同时配置FH和SU机制时，SU优先于FH，因为相同的行为触发器。

示例如下：

credit-control group test
 
 diameter origin endpoint test

 diameter peer-select peer test

 quota volume-threshold percent 10

 diameter pending-timeout 80 deciseconds msg-type any

 diameter session failover

 trigger type rat lac

 apn-name-to-be-included virtual

 quota request-trigger exclude-packet-causing-trigger

 failure-handling initial-request continue retry-after-tx-expiry

 servers-unreachable initial-request terminate after-interim-volume 200
  after-interim-time 3600 server-retries 0

 servers-unreachable behavior-triggers initial-request transport-failure
  tx-expiry

 servers-unreachable update-request continue after-interim-volume 200
  after-interim-time 3600 server-retries 50

 servers-unreachable behavior-triggers update-request transport-failure
  tx-expiry

验证

要验证配置是否正常工作，请输入show active-charging service <service name>命令：

# show active-charging service name test
 
 
 
 Service name: test
 
 
 
  TCP Flow Idle Timeout : 300 (secs)
 
  UDP Flow Idle Timeout : 300 (secs)
 
  ICMP Flow Idle Timeout : 300 (secs)
 
  ICMP Flow Idle Timeout : 300 (secs)
 
  ALG Media Idle Timeout : 120 (secs)
 
 
 
 TCP Flow-Mapping Idle Timeout : 300 (secs)
 
 UDP Flow-Mapping Idle Timeout : Not Configured
 
 
 
 Deep Packet Inspection: Enabled
 
 Passive Mode : Disabled
 
 CDR Flow Control : Enabled
 
 CDR Flow Control Unsent Queue Size: 75
 
 Unsent Queue high watermark: 56
 
 Unsent Queue low watermark: 18
 
 
 
 Content Filtering: Disabled
 
 
 
 Dynamic Content Filtering: Disabled
 
 
 
 URL-Blacklisting: Disabled
 
 URL-Blacklisting Match-method: Exact
 
 
 
 Content Filtering Match-method: Generic
 
 
 
 
 
 Interpretation of Charging-rule-base-name: active-charging-group-of-ruledefs
 
 
 
 
 
 Selection of Charging-rule-base AVP : Last
 
 
 
 Credit Control:
 
 Group         : test
 
 
 
 Mode                   : diameter
 
 APN-name-to-be-included: gn
 
 Trigger-Type           : N/A
 
 
 
 Failure-Handling:
 
 Initial-Request  : continue retry-after-tx-expiry
 
 Update-Request   : retry-and-terminate
 
 Terminate-Request: retry-and-terminate
 
 
 
 Server Unreachable Failure-Handling:
 
 Initial-Request  : terminate
 
 Update-Request   : continue

故障排除

输入show active-charging credit-control statistics命令，以查看与SU和FH机制相关的统计信息。以下为示例输出：

#show active-charging credit-control statistics
 ...
 
 OCS Unreachable Stats:
 
 Tx-Expiry:               2291985       Response-TimeOut:        615
 
 Connection-Failure:      2             Action-Continue:         0
 
 Action-Terminated:       0             Server Retries:          2023700
 
 
 
 Assumed-Positive Sessions:
 
 Current:                 2             Cumulative:              2196851

以下是有关此示例输出的一些重要说明：

• Tx-Expiry € ⠓ — 这表示由于Tx-expiry而出现的SU条件。
  
  
• Response-Timeout € ⠓ Â表示由于RT而出现SU条件。
  
  
• Connection-Failure € ⠓ — 这表示由于传输故障而出现SU条件。
  
  
• Action-Continue € — 此“字段指示脱机的会话数。
  
  
• Action-Terminate €â “此字段指示已终止的会话数。
  
  
• 服务器重试€- “此字段指示重试OCS的次数。
  
  
• 假设积极的会话:
  
  
  • 当€前 — “此字段指示当前处于SU条件的会话数。
    
    
  • Cumulative € ⠓ This字段指示已进入SU状态的会话总数。

输入show active-charging sessions full all命令以查看与会话的SU状态相关的信息。以下为示例输出：

#show active-charging sessions full all
..
..

Current Server Unreachable State:                           CCR-I
 
 Interim Volume in Bytes (used / allotted):                 84/ 200
 
 Interim Time in Seconds (used / allotted):                 80/ 3600
 
 Server Retries (attempted / configured):                    1/ 50

以下是有关此示例输出的一些重要说明：

• 当前服务器不可达状态 € - “ A指定当前SU状态是由CCR-I还是CCR-U引起。
  
  
• 中间卷（以字节为单位）(已€使用/已分配) “ — 此部分显示中间卷（以字节为单位）与已分配的字节。
  
  
• 中间时间（秒）(已使用/已分配)€ - “此显示中间卷（以秒为单位）与已分配的秒数。
  
  
• Server Retries(tatted/configured) - € “ — 这是尝试的服务器重试次数与配置的服务器重试次数。

相关信息

• 命令行界面参考，StarOS版本16
  
  
• 技术支持与文档€— “ Cisco Systems