White Paper: CSG2 Key Performance Indicators CSG2 Release 3.5

Document Number: EDCS-830127
Revision: 4
White Paper
CSG2 Key Performance Indicators
CSG2 Release 3.5
Overview
The Cisco CSG2 delivers best-in-class content-aware billing, content filtering, service
control, traffic analysis, and data mining in a highly scalable, fault-tolerant package. Its
deep packet inspection (DPI) capability allows mobile operators to analyze, optimize,
secure, and meter all traffic flows, including content-based services.
The Cisco CSG2 is supported on SAMI (Service and Application Module for IP). SAMI
is a next-generation high performance Cisco IOS software application module that
occupies a single slot in the Cisco 7600 series router platform.
This document is intended to provide key performance indicators for monitoring and
maintaining Cisco CSG2, and will be updated as needed.
© 2009 Cisco Systems, Inc. All right reserved.

Page 1 of 15
Revision History
Rev
Date Originator Comment
1 04/07/08 Jue Cao First Version of Document provided
2 01/28/09 Jue Cao Updated for Release 3
3 02/11/09 Jue Cao Updated based on engineering review comments
4 10/23/09 Jue Cao Updated for Release 3.5

Page 2 of 15
Table of Contents
Overview ............................................................................................................................. 1
Revision History ................................................................................................................. 2
Table of Contents ................................................................................................................ 3
1. CSG2 Architecture Overview ................................................................................. 4
2. CSG2 Performance and Capacity KPIs .................................................................. 4
2.1. CPU .......................................................................................................................... 4
2.2. Memory .................................................................................................................... 5
2.3. Throughput ............................................................................................................... 6
2.4. Protocol Transaction Rate ........................................................................................ 8
2.5. Critical System Resources - CSG2 Load Management ........................................... 9
2.6. CSG2 User and Session KPIs ................................................................................ 13
2.7. MIBs ...................................................................................................................... 13
3. Additional CSG2 KPIs .......................................................................................... 14
3.1. BMA Statistics ....................................................................................................... 14
3.2. QS Statistics ........................................................................................................... 14
3.3. MIBs ...................................................................................................................... 15
4. CSG2 Performance Reference .............................................................................. 15

Page 3 of 15
1. CSG2 Architecture Overview
To better understand KPI monitoring for CSG2, it is important to be familiar with the hardware
architecture of SAMI/CSG2.
SAMI is a multi-processor blade, it contains 6 power PCs with one dedicated to be the control
processor (processor 3 referred as CP) and five used as traffic processors (processor 4 to 8
referred as TPs). The CP is used to process the control messages including Radius, GTP’ etc. The
user traffic gets directed to the individual TP for processing.
This document focuses on the key performance indicators that should be monitored by the
operator at an on-going base for network capacity planning. These major KPIs, including CPU,
memory, throughput, load management, user and session statistics are discussed in details in
section 2 below. Additional KPIs that can be used for further analysis are discussed in section 3
below. Most of the KPIs discussed in this document are supported with SNMP MIB; operators
can use Cisco MWTM (Mobile Wireless Transport Manager) or other network management tools
to retrieve the KPIs via SNMP.
2. CSG2 Performance and Capacity KPIs
To optimize the CSG2 performance/capacity, the following KPIs should be closely monitored and
capacity growth shall be considered based on the recommendations below:
a. CSG2 CPU Utilization

b. CSG2 Memory Utilization
c. CSG2 Throughput Utilization
d. CSG2 Load Management Statistics
e. CSG2 User and Session Statistics
Monitoring commands should be executed from the CP only, for CPU, memory, interface
throughput, statistics from each processor are displayed and shall be monitored respectively.
MIBs, if available, are listed at the end of this section
2.1. CPU
CPU utilization on Control Processor is mainly driven by the control (Radius, GTP’) traffic,
and CPU utilization on Traffic Processors is mainly driven by user data traffic.
As a general guideline, the following recommendations should be followed:

 The data packet per second rate should not exceed the CSG2 capacity *.
 The data transaction rate should not exceed the CSG2 capacity *.
 The radius accounting message rate should not exceed the CSG2 capacity*.

Page 4 of 15
 Operator shall start planning capacity growth when CPU utilization hits 70%, and shall
increase capacity when CPU utilization exceeds 90%.
CPU Utilization on CSG2 can be monitored via the following CLI:
 “show proc cpu | include CPU”
CSG2#sh proc cpu | include CPU

----------- Slot 1/CPU 3, show processes cpu -------------
CPU utilization for five seconds: 12%/10%; one minute: 11%; five minutes: 10%
Note:
 The number of quota server messages processed mostly impacts CPU utilization of the
CP; increasing quota grant would help reducing the CPU utilization of the CP.
 The number of CDRs generated impacts the CPU utilization of both the CP and the TPs,
configuring service level CDRs would help reducing CPU utilization of both the CP and
the TPs.
2.2. Memory
Memory usage on CSG2 is driven by the number of concurrent users, data sessions, active
services per user, RADIUS attributes reported per user etc. Here we are mostly referring to
the usage on each Traffic processor.

 The number of concurrent users in KUT should not exceed the CSG2 capacity*.
 The number of concurrent data sessions should not exceed the CSG2 capacity*.
 Operator shall start planning capacity growth when process memory utilization hits 70%,
and shall increase capacity when process memory utilization exceeds 90%.
Memory Utilization on CSG2 can be monitored via the following CLI:

 “show memory statistics”

Page 5 of 15
CSG2#show mem stat
----------- Slot 4/CPU 3, show memory statistics -------------
Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)

Processor 48E80660 907540892 263212444 644328448 636360564 636215644
I/O 7C000000 67108864 42304332 24804532 24804532 24804284
----------- Slot 4/CPU 4, show mem stat -------------

Processor 48E80660 907540892 331204692 576336200 562171504 562539600
I/O 7C000000 67108864 42013516 25095348 25095348 25095100

Processor 48E80660 907540892 331194972 576345920 547922000 548288640
I/O 7C000000 67108864 42013516 25095348 25095348 25095100

Processor 48E80660 907540892 331202492 576338400 549349428 549717200
I/O 7C000000 67108864 42013516 25095348 25095348 25095100<~

Processor 48E80660 907540892 331199972 576340920 548055992 548423504
I/O 7C000000 67108864 42013516 25095348 25095348 25095100

Processor 48E80660 907540892 331187736 576353156 557555416 557930000
I/O 7C000000 67108864 42013516 25095348 25095348 25095100
2.3. Throughput
Throughput usage on CSG2 is driven by the packets per second rate and average packet size.
 The data packet per second rate should not exceed the CSG2 capacity*. Note the
maximum throughput rate could vary depending on the average packet size.
 Operator shall start planning capacity growth when data packet per second rate hits 70%
of the maximum capacity, and shall increase capacity when data rate exceeds 90%.
 Operator shall start planning capacity growth when control and management data usage
hits 70% of the maximum capacity, and shall increase capacity when control and
management data rate exceeds 90%.
Data throughput utilization on CSG2 can be monitored via the following CLI:
 show interfaces gigabit Ethernet 0/0 | include bits/s
CSG2#execute all show int | include bits/s

----------- Slot 4/CPU 4, show int | include bits/s-------------
30 second input rate 520304000 bits/sec, 67412 packets/sec
30 second output rate 518502000 bits/sec, 67265 packets/sec

Page 6 of 15



Note: Overall date rate of CSG2 card can be calculated by summing up the input or output
packet per second rate of all the traffic processors (4-8). Data traffic going through CSG2
shows up as both input and output traffic under the interface stats, only one rate should be
used for calculation to avoid counting the data traffic twice. Interface load interval can be
configured from a default of 5 minutes to the lowest 30 seconds to get a more accurate rate
for the peak time usage.
Control and management traffic utilization on CSG2 can be monitored via the following CLI:
CSG2#show interfaces gi 0/0 | include bits/s

Note: Control and management traffic utilization on CSG2 can be monitored on the control
processor (3), this includes Radius, GTP’ traffic etc.
Interface packet drops and errors should also be monitored for operator to be alarmed that an
overload or error condition has occurred:
CSG2#show interfaces g0/0 | incl errors|throttles|drops
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 output errors, 0 collisions, 0 interface resets
CSG2#execute-on all show inter gi0/0 | inc errors|throttles|drops

----------- Slot 4/CPU 4, show inter gi0/0 | inc errors|throttles|drops-------------
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0



Page 7 of 15

* For CSG2 capacity and performance metrics, please refer to section 4.
2.4. Protocol Transaction Rate
Protocol transaction rate is another KPI on CSG2, R3.5 introduced a new feature to
provide additional statistics for transaction rates per protocol via “show ip csg stats
protocol” command*. It displays the statistics count, rate, maximum rate, and maximum
rate timestamp for the transaction, byte count, and packet count for each of the protocols
that is configured on the CSG2.
Router# show ip csg stats protocol

Protocol http Stats:
Total Transactions: 0
Transaction Rate: 0.000/sec
Peak Transaction Rate: 0.000/sec
Peak Transaction Rate Timestamp: 20090603-171440
Outgoing Traffic
Subscriber to Network
Total Packets: 0
Packet Rate: 0.000/sec
Peak Packet Rate: 0.000/sec
Peak Packet Rate Timestamp: 20090603-171440
Total Bytes: 0
Bit Rate: 0.000/sec
Peak Bit Rate: 0.000/sec
Peak Bit Rate Timestamp: 20090603-171440
Network to Subscriber
Total Packets: 0
Packet Rate: 0.000/sec
Peak Packet Rate: 0.000/sec
Peak Packet Rate Timestamp: 20090603-171440
Total Bytes: 0
Bit Rate: 0.000/sec
Peak Bit Rate: 0.000/sec
Peak Bit Rate Timestamp: 20090603-171440
Note for IP, TCP, and UDP accounting, the Transaction Rate fields display the
Layer 4 transaction rates.
For all other protocols, the Transaction Rate fields display the Layer 7
transaction rates.
To configure the interval, in seconds, that the CSG2 is to use when calculating
the rates for this command, use the ip csg statistics protocol interval command
in global configuration mode.

 The transaction rate should not exceed the CSG2 capacity*. Note the maximum
transaction rate could vary depending on the inspection type.

Page 8 of 15
 Operator shall closely monitor the data transaction rate in conjunction with CPU
utilization to plan for capacity growth.
Prior to R3.5, “show ip csg content detail” can be captured periodically to calculate the
per protocol transaction rates.
2.5. Critical System Resources - CSG2 Load Management
CSG2's load management feature provides a central facility for protecting the CSG2
when overloaded and warning the operator that an overload exists. The philosophy applied
throughout the CSG2 application is that existing users and sessions should continue to receive
service during an overload situation, and events related to new sessions should be discarded
to protect critical system resources.
This component monitors critical system resources and sheds load caused by external
events in a specific order. Those events, in the order of load-shedding are: radius accounting
start messages, user database requests, new data session creation, BMA messages, QS
messages, user idle processing. For each of these items, CSG2 reports:
Allowed (The total number of events allowed since last stats clear.)
[Allowed] (per second) (The number of events per second over the last 30 second period.)
Max per second (The highest number of events per second over a 30 second interval.)
IPC:
IPC Queue Depth Tolerance (The first number is the maximum number of queued IPC messages
allowed by load management for this transaction type. The second number is the maximum
number of queued IPC allowed for the entire CSG. The last number is the tolerance expressed as a
percentage of the overall IPC queue max.) These numbers are fixed and not meant to be tuned.
Denied (The total number of events denied due to exceeding the defined IPC queue depth since
the last stats clear.)
[Denied](per second) (The events / second denied over the last 30 second interval, due to
exceeding the defined IPC queue depth. )
Max per second (The highest number of events denied per second over a 30 second interval due to
exceeding the defined IPC queue depth.)
Rate(if applicable):
Limit (The number of transactions allowed per second.) It is recommended to leave these
settings as default.
Denied (The total number of events denied due to exceeding the defined rate limit since the last
stats clear.)
[Denied](per second) (The events / second denied over the last 30 second interval, due to
exceeding the defined rate limit. )

Page 9 of 15
Max per second (The highest number of events denied per second over a 30 second interval due to
exceeding the defined rate limit.)
Overload conditions may be triggered by busy-hour conditions, DOS attacks, or other

unplanned network events. If the overload conditions persist, the operator will need to
identify the root cause and either add more CSG capacity or offload the unplanned traffic.
As a general guideline, any “Denied” counter increases indicate there has been an over
utilization of system resources on CSG2, “Max per second” rates record the historical
maximum to help operator perform traffic analysis and plan for capacity growth.
Load management statistics on CSG2 can be monitored via CLI:

 “show ip csg load”
Radius Start
Allowed (per second) = 0 (0), Max per second = 0
IPC: Queue Depth Tolerance 10000 / 50000 (20 percent)
Denied (per second) = 0 (0), Max per second = 0
Rate: Limit 5000 on control processor
Denied (per second) = 0 (0), Max Per Second = 0
 Allowed (per second) in the “Radius Start section” represent the total number of
new users and new user sign on rate.
 When critical system resources are running low (either the IPC queue depth
tolerance is exceeded or the transaction rate limit is exceeded), new Radius
accounting start messages will be dropped (Counter “Denied” would increase).
 When critical system resources become available again, CSG2 will start to
process new Radius accounting start messages again.
Database Request
Rate: Limit 1800 per traffic processor
 Allowed (per second) in the “Database Request section” represent the total
number of new users and new user sign on rate when the user database is
configured to look up username from subscriber IP address.
 When critical system resources are running low (either IPC queue depth
tolerance is exceeded or transaction rate limit is exceeded), new user database
request messages will be dropped (Counter “Denied” would increase).

Page 10 of 15
 When critical system resources become available again, CSG2 will start to
process new user database request messages again.
Session Create
 Allowed (per second) in the “Session Create section” represent the total number
of new data sessions and the data session rate.
 When critical system resources are running low (in this case, IPC queue depth
tolerance is exceeded), new data session will be dropped (Counter “Denied”
would increase).
 When critical system resources are available (in this case, IPC queue depth
tolerance dropped below threshold), CSG2 will start to process new data sessions
again.
BMA Messages
 Allowed (per second) in “BMA Messages section” represent approximately the

total number of CDRs sent to the BMA since the last module reload or counter
clearing and average rate over the last 30 seconds on CSG2.
tolerance is exceeded), CDRs will be dropped (Counter “Denied” would
increase).
tolerance dropped below threshold), CSG2 will start to process CDRs again.
Quota Server
 Allowed (per second) in the “Quota Server section” represent approximately the
total number of messages sent to QS since the last module reload or counter
clearing and average rate over the last 30 seconds on CSG2.
tolerance is exceeded), QS messages will be dropped (Counter “Denied” would
increase).

Page 11 of 15
tolerance dropped below threshold), CSG2 will start to process QS messages
again.
User Idle *
Rate: Limit 1000 per traffic processor
 Allowed (per second) in the “User Idle section” represent approximately the total
number of IPC messages sent due to a KUT element idling out to clean up the
KUT and average rate over the last 30 seconds on CSG2.
 When critical system resources are running low * (either IPC queue depth
tolerance is exceeded or transaction rate limit is exceeded), the User Idle IPC
messages will be dropped.
 When critical system resources are available again, these IPC messages will be
sent again to clean up the KUT.
* Idling out a user requires coordination between processors, temporarily increasing

processor and IPC load. Because of this, under stress conditions, the CSG2 temporarily
defers idling out users.
CSG2 buffer management is part of the load management feature, it tracks IO memory
usage for the following categories:
Radius (used to store Radius messages)

Application ( used to store data packets, i.e. out of order packets )
Fragments ( used to store IP fragments )
Unlimited ( used to store internal messaging including IPC etc )
CSG2 puts a fixed memory limit for each of the above category except “Unlimited”
to prevent the system from overloading due to specific network conditions
such as “large number of OOO packets or IP fragments”.
CSG Buffer Management Stats:

Category | Create Copy Free Deny
-----------------------------------------------------------------------------
Radius | 0 0 0 0
Application | 0 0 0 0
Fragments | 0 0 0 0
Unlimited | 6 0 0 0
 Create gives you the number of IO buffers that have been created for the category
since the last module reload or counter clearing.

Page 12 of 15
 Copy gives you the number of IO buffers that have been created for the purpose
of copying.
 Free gives you the number of IO buffers that have been freed.
 Deny gives you the number of buffer requests denied due to buffer management
maximums. This indicates the system has been in overload condition and buffer
management is working.
2.6. CSG2 User and Session KPIs

 The number of concurrent users in KUT should not exceed the CSG2 capacity*.
 The number of concurrent data sessions should not exceed the CSG2 capacity*.
 Operator shall start planning capacity growth when the number of concurrent users or
data sessions exceeds 70% of the maximum capacity, and shall increase capacity when
the number exceeds 90%.
The number of current users (current counter) and the maximum users existed (highwater
counter) in KUT can be monitored via the following CLI:
I. “show ip csg stats | section CSG User Stats”
CSG User Stats:
max = 500000, current = 4338, highwater = 7996
…
The number of current data sessions (current counter) and maximum sessions
existed(highwater counter) can be monitored via the following CLI:
II. “show ip csg stats | section CSG Session Stats”
CSG Session Stats:
user sessions = 133243, highwater = 156097, ha_overrun = 0
…
Please refer to section 4 for maximum users and data sessions supported per CSG2.
2.7. MIBs
The following table lists the MIBs that are available to monitor the KPIs discussed in this section:
KPI MIB
CPU CISCO-PROCESS-MIB
Memory CISCO-ENHANCED-MEMPOOL-MIB
Throughput IF-MIB

Page 13 of 15
CISCO-CONTENT-SERVICES-MIB
Load Management
User and Session
3. Additional CSG2 KPIs
This section discusses additional KPIs that can be monitored on CSG2 that helps the
operator to understand the overall system capacity.
As the performance of the external billing system plays a key role of the overall billing
solution, it is important to monitor the KPIs that are related, BMA, and QS statistics are discussed
in this section.
3.1. BMA Statistics
 CSG2 BMA statistics can be monitored via the following CLI:

I. “show ip csg bma detail”
show ip csg bma det
10.18.31.10:3333, priority = 1, ACTIVE
data packets sent = 53990, retransmits = 15, spurious acks = 0
echo req sent = 82, echo resp recv = 2
nodealive req sent = 0, nodealive resp recv = 0
packet rate = 0.00/sec, ack rate = 0.00/sec
queued = 0, highwater = 894
min tx win = 10, cur tx win = 10
unacked = 11, ack = 0, count = 0
failed sends:
queued send = 0, slow ack = 0
redirection response = 0, reject = 0
echo-response = 0, node-alive = 0
too many retries = 0
…
The key performance indicators ( highlighted in bold above ) to graph over time are:
 Packet rate vs ack rate – These 2 rates should be close to equal if the BMA is
acknowledging in time for all the packets that CSG2 is sending. And the rate itself
indicates the current message rate exchanged between CSG2 and BMA. This KPI gives
you an idea on how the BMA is performing at present.
 retransmits vs data packets sent – If this ratio is high, it indicates the total number of
messages that the BMA can receive is insufficient for the number of records the CSG2 is
sending. This KPI gives you a view of how the BMA has been performing over time, by
combining with the first KPI stated above, operator can determine if there is an issue with
BMA performance at present or in the past.
3.2. QS Statistics
 CSG2 QS statistics can be monitored via the following CLI:

I. “show ip csg quota-server detail”

Page 14 of 15
CSG2-1#show ip csg quota det
11.18.31.10:3385, priority = 1, ACTIVE
data packets sent = 341788, retransmits = 0, spurious acks = 0
echo req sent = 2, echo resp recv = 2
nodealive req sent = 0, nodealive resp recv = 0
packet rate = 4000.00/sec, ack rate = 4000.00/sec
queued = 200, highwater = 400
min tx win = 1, cur tx win = 128
unacked = 128, ack = 9200, count = 1
failed sends:
queued send = 0, slow ack = 0
redirection response = 0, reject = 0
echo-response = 0, node-alive = 0
too many retries = 0
…
The key performance indicators ( highlighted in bold above ) to graph over time are:
 Packet rate vs ack rate – These 2 rates should be close to equal if the QS is
acknowledging in time for all the packets that CSG2 is sending. And the rate itself
indicates the current message rate exchanged between CSG2 and QS. This KPI gives you
an idea on how the QS is performing at present.
 retransmits vs data packets sent – If this ratio is high, it indicates the total number of
messages that the QS can receive is insufficient for the number of records the CSG2 is
sending. This KPI gives you a view of how the QS has been performing over time, by
combining with the first KPI stated above, operator can determine if there is an issue with
QS performance at present or in the past.
3.3. MIBs
The following table lists the MIBs that are available to monitor the KPIs discussed in this section:
KPI MIB
BMA Statistics
QS Statistics
4. CSG2 Performance Reference

Please refer to CSG2 performance whitepapers for details for the performance numbers for each
release.
CSG2 R1 performance whitepaper: EDCS-649222

CSG2 R2 performance whitepaper: EDCS-731879
CSG2 R3.5 performance whitepaper: EDCS-809840

Page 15 of 15

White Paper: CSG2 Key Performance Indicators CSG2 Release 3.5

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

White Paper: CSG2 Key Performance Indicators CSG2 Release 3.5

Uploaded by

Copyright:

Available Formats

Document Number: EDCS-830127

© 2009 Cisco Systems, Inc. All right reserved.

© 2009 Cisco Systems, Inc. All right reserved.

© 2009 Cisco Systems, Inc. All right reserved.

2. CSG2 Performance and Capacity KPIs

a. CSG2 CPU Utilization

MIBs, if available, are listed at the end of this section

As a general guideline, the following recommendations should be followed:

© 2009 Cisco Systems, Inc. All right reserved.

CPU Utilization on CSG2 can be monitored via the following CLI:

 “show proc cpu | include CPU”

CSG2#sh proc cpu | include CPU

As a general guideline, the following recommendations should be followed:

Memory Utilization on CSG2 can be monitored via the following CLI:

© 2009 Cisco Systems, Inc. All right reserved.

Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)

Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)

Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)

Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)

Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)

Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)

CSG2#execute all show int | include bits/s

© 2009 Cisco Systems, Inc. All right reserved.

----------- Slot 4/CPU 6, show int | include bits/s-------------

----------- Slot 4/CPU 7, show int | include bits/s-------------

----------- Slot 4/CPU 8, show int | include bits/s-------------

CSG2#show interfaces gi 0/0 | include bits/s

CSG2#execute-on all show inter gi0/0 | inc errors|throttles|drops

----------- Slot 4/CPU 5, show inter gi0/0 | inc errors|throttles|drops-------------

----------- Slot 4/CPU 6, show inter gi0/0 | inc errors|throttles|drops-------------

----------- Slot 4/CPU 7, show inter gi0/0 | inc errors|throttles|drops-------------

© 2009 Cisco Systems, Inc. All right reserved.

----------- Slot 4/CPU 8, show inter gi0/0 | inc errors|throttles|drops-------------

* For CSG2 capacity and performance metrics, please refer to section 4.

2.4. Protocol Transaction Rate

Router# show ip csg stats protocol

As a general guideline, the following recommendations should be followed:

© 2009 Cisco Systems, Inc. All right reserved.

2.5. Critical System Resources - CSG2 Load Management

© 2009 Cisco Systems, Inc. All right reserved.

Overload conditions may be triggered by busy-hour conditions, DOS attacks, or other

Load management statistics on CSG2 can be monitored via CLI:

© 2009 Cisco Systems, Inc. All right reserved.

 Allowed (per second) in “BMA Messages section” represent approximately the

© 2009 Cisco Systems, Inc. All right reserved.

* Idling out a user requires coordination between processors, temporarily increasing

Radius (used to store Radius messages)

CSG Buffer Management Stats:

© 2009 Cisco Systems, Inc. All right reserved.

2.6. CSG2 User and Session KPIs

As a general guideline, the following recommendations should be followed:

© 2009 Cisco Systems, Inc. All right reserved.

3. Additional CSG2 KPIs

3.1. BMA Statistics

 CSG2 BMA statistics can be monitored via the following CLI:

 CSG2 QS statistics can be monitored via the following CLI:

© 2009 Cisco Systems, Inc. All right reserved.

4. CSG2 Performance Reference

CSG2 R1 performance whitepaper: EDCS-649222

© 2009 Cisco Systems, Inc. All right reserved.

You might also like