CUBEおよびTDMゲートウェイのデバッグ収集の設定

はじめに

このドキュメントでは、Cisco IOS®/IOS XE®音声ルータで音声デバッグを収集するためのベストプラクティスについて説明します。

前提条件

要件

• サービス統合型ルータ(ISR)内のCisco IOS/IOS XEの基礎知識
• ISRルータでコマンドを実行するための特権アクセス。
• Voice-over-IP(VoIP)プロトコルに関する以前の経験が必要です。
• VoIPトレースには、Cisco IOS XE 17.4.1または17.3.2以降が必要です。

使用するコンポーネント

このドキュメントの目的に従い、次のコンポーネントを使用します。

• Cisco ISR 3925
• Cisco ISR 4451
• PuTTY

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

これらのプラットフォームでのデバッグ収集のプロセスには課題があり、デバイスのパフォーマンスに影響を与える可能性があります。音声ルータで複数のアクティブコールが確立されると、課題とリスクが増大します。一部のシナリオでは、デバッグが正しく収集されないと、CPUの使用率が高くなり、ルータのキャパシティが低下したり、ソフトウェアがクラッシュしたりする可能性があります。このドキュメントでは、Cisco Unified Border Element(CUBE)と時分割多重(TDM)/アナログゲートウェイの違いについて説明します。

TDM音声ゲートウェイとCUBE

TDM音声ゲートウェイは、主に内部電話システムを別の構内交換機(PBX)または公衆電話交換網(PSTN)と相互接続するために使用されます。 TDMゲートウェイで使用される接続のタイプは、T1/E1コントローラ（ISDNまたはCAS）、およびFXSポートやFXOポートなどのアナログ回線です。Digital Signal Processor（DSP；デジタル信号プロセッサ）は、オーディオを未加工の形式からRTPパケットに変換します。同様に、DSPがRTPパケットを処理し、その音声を特定の回線に送信した後、RTPパケットはraw音声に変換されます。これらのゲートウェイは、PSTNまたはエンドポイントへの最も一般的な接続として、VoIP側ではH323、MGCPまたはSkinny Call Control Protocol(SCCP)、TDM側ではISDN PRI回線またはアナログと相互運用できます。

図に示すように、TDMゲートウェイは、内部VoIPインフラストラクチャとアナログまたはISDNサービスプロバイダー間のブリッジを提供します。

VoIPの導入により、顧客はレガシーシステムを最新のVoIPインフラストラクチャに迅速に変更し始めました。同じことがサービスプロバイダー側でも発生しました。サービスプロバイダー側では、より良いサービスを提供するために、接続を使用してオンプレミステレフォニーサービスとサービスプロバイダーのVoIPインフラストラクチャを相互接続し、機能を拡張しています。現在最も一般的に使用されているVoIPプロトコルはSession Initiation Protocol（SIP；セッション開始プロトコル）で、現在は世界中のお客様やInternet Telephony Service Provider（ITSP；インターネットテレフォニーサービスプロバイダー）で広く使用されています。

CUBEは、SIPをプライマリVoIPプロトコルとするITSPを介して、これらの内部VoIPシステムを外部ネットワークに相互接続する方法を提供するために導入されました。CUBEは、T1/E1コントローラやアナログポートのようなTDMタイプの接続を必要としない単なるIP-IPゲートウェイです。CUBEは、TDMゲートウェイと同じプラットフォームで動作します。

最も一般的に使用されるVoIPプロトコルは、コールの確立とティアダウンに使用されるSIPと、メディア転送に使用されるRTPです。CUBEでは、トランスコーダが必要でない限り、DSPは不要です。RTPトラフィックフローはITSPからエンドポイントへのエンドツーエンドで行われ、CUBEはアドレス隠蔽を備えた中間者として機能し、多数の機能の1つとして提供されます。

図に示すように、CUBEは内部VoIPインフラストラクチャとSIP ITSPを分割します。

Cisco IOS/IOS XE音声デバッグのコレクション

音声機能は、特にISR、ASR、CAT8Kなどの異なるプラットフォームリストで実行されますが、共通のソフトウェアであるCisco IOSまたはCisco IOS XEのいずれかを使用します（Cisco IOSとCisco IOS XEの違いについてはこの記事では説明しません）。 Cisco IOSルータへのアクセス方法の基本は次のとおりです。

コマンドラインインターフェイス(CLI)からCisco IOS/IOS XEルータにアクセスする方法

ルータは、他のCLIベースのデバイスと同様に、Secure Shell(SSH)またはTelnetを介してコマンドを実行するためのアクセスを取得するために端末モニタを必要とします。SSHは、現在提供されているデバイスにアクセスするために使用されている最も一般的なプロトコルです。デバイスへのセキュアで暗号化された接続を提供するルータのCLIへのアクセスに使用される一般的な端末モニタには、次のようなものがあります。

showコマンドまたはデバッグを収集するための端末モニタの設定方法

CLIから出力を収集する方法はいくつかあります。ルータのCLIから別のファイルに情報をエクスポートすることを推奨します。これにより、外部の関係者と情報を共有しやすくなります。

デバイスから出力を収集する方法は、次のとおりです。

• ターミナルですべての出力をダンプします。十分な数のscrollback行があることを確認する必要があります。十分でない場合、scrollbackは出力の最初のセクションを失い、データが不完全になる可能性があります。Puttyのスクロールバック行を増やすには、Putty Configuration > Window > Lines of Scrollbackに移動します。通常、scrollbackの出力を十分に確保するには、この値を非常に高い値に設定します。

後で、[すべてをクリップボードにコピー]オプションを使用してターミナルモニタから情報を収集し、出力をテキストファイルに貼り付けることができます。

• もう1つのオプションは、セッション出力全体を.txtファイルに記録することです。このオプションを使用すると、入力したすべてのコマンドと収集した出力が即座にテキストファイルに記録されます。これは、セッション内のすべての出力をログに記録するための一般的な方法です。Puttyのファイルにすべてのセッション出力を記録するには、次のようにPutty Configuration > Session > Loggingの順に選択し、All Session Outputを選択します。

注：他の名前が指定されていない場合は、デフォルトのログファイル名が使用されます。Browseボタンをクリックして、ファイルが保存されている場所を正確に確認し、後で見つけます。また、同じファイルパスにある別のputty.logファイルを上書きしないでください。

CLIからの基本的なshowコマンド出力の収集

showコマンドは、デバッグの収集が行われる前にルータから基本情報を収集するために必要です。showコマンドは収集が高速で、ほとんどの場合、ルータのパフォーマンスに影響を与えません。showコマンドの出力だけで、問題の切り分けをすぐに開始できます。

ルータに接続した後、ターミナル長を0に設定できます。これにより、すべての出力を一度に表示するために収集が高速化され、スペースバーの使用を避けることができます。ルータに関する詳細情報を収集するコマンドはshow techだけです。代わりに、ルータで有効になっている音声機能に固有のデータを表示するshow tech voiceを収集することもできます。

Router# terminal length 0
Router# show tech
!or
Router# show tech voice
Router# terminal default length !This cmd restores the terminal length to default

CLIからのデバッグ出力の収集

Cisco IOS/IOS XEのデバッグ出力の収集は、ルータのクラッシュのリスクがあるため、困難な場合があります。ただし、問題を回避するために、いくつかのベストプラクティスについては次のセクションで説明します。

メモリチェック

デバッグを有効にする前に、出力をバッファに保存するのに十分なメモリがあることを確認する必要があります。

show process memoryコマンドを実行して、バッファ内のすべての出力をログに記録するために割り当てることができるメモリの量を確認します。

ヒント：端末に表示される限られた行数に戻るには、コマンドterminal length defaultまたはterminal length <num_lines> を使用します。

Router# show process memory
Processor Pool Total: 8122836952 Used: 456568400 Free: 7666268552
lsmpi_io Pool Total: 6295128 Used: 6294296 Free: 832

この例では、ルータで使用できる空き容量は7666268552バイト(7.6 GB)です。このメモリは、すべてのシステムプロセスの間でルータによって共有されます。これは、バッファに出力を記録するために空きメモリ全体を使用することはできませんが、必要に応じて十分な量のシステムメモリを使用できることを意味します。

ほとんどのシナリオでは、十分なデバッグ出力を収集するために少なくとも10 MBを必要とするため、出力が失われたり上書きされたりしてしまいます。まれに、より多くのデータを収集する必要がある場合があります。このような特定のシナリオでは、バッファに50 ～ 100 MB相当の出力を得るか、使用可能なメモリがある限り高い出力を得ることができます。

Free Memoryが低い場合は、メモリリークの問題が発生している可能性があります。その場合は、アーキテクチャTACチームに依頼して、このようなメモリ不足の原因を修正してもらいます。

中央処理装置(CPU)のチェック

CPUは、システム内でアクティブなプロセス、機能、およびコールの数に影響されます。システム内でアクティブな機能やコールが多いほど、CPUの使用率が高くなります。

適切なベンチマークは、ルータのCPU使用率を30 %以下にすることです。これは、基本から高度なデバッグを安全に実行できることを意味します（高度なデバッグを使用する場合は常にCPUを監視してください）。 ルータのCPU使用率が約50 %の場合は、基本的なデバッグを実行して、CPUを注意深く監視できます。CPUの使用率が80 %を超えた場合は、すぐにデバッグを中止し（この文書の後半で説明）、TACにサポートを依頼してください。

show process cpu sorted | exclude 0.00コマンドを使用して、上位プロセスとともに最近の5秒間、60秒間、および5分間のCPU値を確認します。

Router# show processes cpu sorted | exclude 0.00
CPU utilization for five seconds: 1%/0%; one minute: 0%; five minutes: 0%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
211 4852758 228862580 21 0.15% 0.06% 0.07% 0 IPAM Manager
84 3410372 32046994 106 0.07% 0.04% 0.05% 0 IOSD ipc task
202 3856334 114790390 33 0.07% 0.05% 0.05% 0 VRRS Main thread

出力では、ルータのアクティビティはそれほど多くなく、CPUは低く、デバッグは安全にイネーブルにできます。

注意：アクティブな上位のCPUプロセスに特に注意してください。CPUの使用率が50 %以上で、トッププロセスが音声プロセスのみの場合は、基本的なデバッグを有効にできます。コマンドを使用してCPUを継続的に監視し、ルータの全体的なパフォーマンスが影響を受けていないことを確認します。

現在のアクティブコールのチェック

各ルータには異なるキャパシティしきい値があります。ルータ内でアクティブになっているコールの数をチェックして、最大容量に近づいていないことを確認することが重要です。Cisco Unified Border Elementバージョン12データシートに、各プラットフォームの参照用キャパシティに関する情報が記載されています。

show call active total-callsコマンドを使用して、システム内でアクティブなコールの数を把握します。

Router# show call active total-calls
Total Number of Active Calls : 0

アクティブな特定のコールタイプの詳細情報を取得するには、show call active voice summaryコマンドを使用します。

Router# show call active voice summary
Telephony call-legs: 0
SIP call-legs: 0
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 0
STCAPP call-legs: 0
Multicast call-legs: 0
Total call-legs: 0

一般的な値の一部を次に示します。

• テレフォニーコールレッグ：TDMゲートウェイコール（アナログコールとPRI/ISDNコールを含む）
• SIPコールレッグ：SIPコールの合計。これがCUBEルータの場合、コールごとに2つのコールレッグを示します。正確な数値を得るには、ここに示されているコールの合計を2で割ります
• H323コールレッグ：H323コール合計
• SCCPコールレッグ：トランスコーダやMTPなど、ルータで使用されるCisco Unified Communications Manager(CUCM)制御メディアリソース

ロギングバッファの設定

デバッグ出力をバッファに保存するようにルータを設定するには、configure terminalモードに入ってCLIの設定を手動で調整します。この設定はルータには影響しませんが、前のセクションで示したように、設定をロールバックする必要がある場合には、ルータからのshow techコマンドまたはshow running-configコマンドが必要です。

次に設定例を示します。これは、TACエンジニアが使用する一般的なベースラインです。この例では、10MBのバッファメモリを割り当てますが、必要に応じて増やすことができます。 

# configure terminal
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
service sequence-numbers
logging buffered 10000000
no logging console
no logging monitor
logging queue-limit 10000
logging rate-limit 10000
voice iec syslog

これらのコマンドは、次のタスクを実行します。

• service timestamps debug or log：ローカルルータの時刻が、記録されたすべてのメッセージにミリ秒単位の精度で書き込まれるようにします。これは、時間に基づいてコールを検索する場合に便利です。ミリ秒のタイムスタンプを使用すると、同じミリ秒以内に2つの回線が発生したときに、デバッグ回線を論理的な関連イベントにグループ化できます。
• service sequence-numbers:デバッグのシーケンス番号を行に書き込みます。これは、ログがsyslogサーバに転送される場合に便利です（基本的に必要です）。これは、syslogサーバへのデバッグメッセージがネットワークでドロップされたかどうかを識別するために非常に役立ちます。シーケンス番号は、タイムスタンプと実際のログメッセージの前にある、デバッグの最初の項目です。これは、syslogサーバがファイルにローカルで書き込むことができるタイムスタンプ/シーケンス番号とは異なることに注意してください。
• logging buffer：ローカルバッファメモリにデバッグを送信するようにルータに指示します。バッファサイズはバイト単位で設定されます。この設定では、バッファサイズは10 MBに設定されています。
• no logging consoleおよびno logging monitor:コンソールまたは端末モニタには、ログメッセージは表示されません。これらのコマンドが設定されていない場合、ルータのパフォーマンスとデバッグ出力の精度に悪影響を及ぼす可能性があります。
• voice iec syslog:音声内部エラーコードメッセージを有効にして、切断理由を判別します。

syslog 設定の編集

問題はランダムに発生することがあり、イベントが発生するまでデバッグを継続的に収集する方法が必要になる場合があります。バッファにデバッグを保存すると、デバッグが継続的に収集されます。割り当て可能なメモリの量に制限され、そのメモリの量に達すると、バッファが最も古いメッセージを循環してドロップします。これにより、問題の切り分けに必要な情報が不完全になります。

Syslogを使用すると、ルータはすべてのデバッグメッセージを外部サーバに送信できます。外部サーバでは、Syslogサーバソフトウェアがメッセージをテキストファイルに保存します。デバッグ出力を収集するには適切な方法ですが、ログ収集には適していません。Syslogサーバは、サーバ内の輻輳のために、受信した出力の行をスキップしたり、出力から削除したりする傾向があります。デバッグ出力がサーバに過大な負荷を与えたり、ネットワークの状態が原因でパケットが廃棄されたりすることがあるからです。ただし、一部のシナリオでは、syslogが問題を進行させる唯一の方法です。

可能であれば、情報の損失を避けるためにTCPなどの信頼性の高い転送方式を使用してください。推奨方法として、Syslogサーバをルータが接続されているのと同じスイッチに接続するか、できるだけルータに近い場所に接続します。すべてのデータがファイルに保存されることを保証するわけではありませんが、データ損失の可能性を減らします。

デフォルトでは、syslogサーバはトランスポートプロトコルとしてポート514でUDPを使用します。

#configure terminal
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
service sequence-numbers

!Optional in case you still want to store debug output in the buffer.
logging buffered 10000000

no logging console
no logging monitor

logging trap debugging

!Replace the 192.168.1.2 with the actual Syslog Server IP Address
logging host 192.168.1.2 transport [tcp|udp] port 

コマンドが設定されるとすぐに、ルータはsyslogサーバのIPアドレスにメッセージを転送します。

デバッグ収集

デバッグをイネーブルにした後、問題が再現される前にバッファをクリアする必要があります。これは、出力が可能な限りクリーンであり、分析に不要な余分なデータを回避するために行われます。clear logコマンドを実行します。 これにより、バッファが確実にクリアされます。ルータで他のコールがアクティブになっているときに、デバッグが有効になっている場合、出力は即座にバッファに出力されます。

Router# clear log
Clear logging buffer [confirm]
Router#

問題が再現した後は、デバッグをただちに無効にして、バッファ内のその他の出力を停止します。次に、ログを収集します。次のコマンドを使用して、端末ですべての出力をダンプできます。

Router# undebug all
Router# terminal length 0
Router# show log

すべての出力を同時に処理する必要がないため、PuTTYが閉じることがあります。これは正常な状態であり、障害が発生したことを意味するものではありません。この場合は、セッションを再度開いて、通常の状態で続行します。ロギングバッファが大きすぎるか、または出力する必要のあるデータ量が原因でターミナルモニタがクラッシュする場合は、show log | redirect コマンドを使用してバッファ出力を外部デバイスに直接コピーします。

Router# show log | redirect ftp://username:password@192.168.1.2/debugs.txt

このコマンドは、バッファ出力全体をIPアドレス192.168.1.2のFTP（ファイル名debug.txt）にコピーします。ファイル名は常に指定する必要があります。そのデータをエクスポートできるその他の宛先は次のとおりです。

Router# sh log | redirect ?
bootflash: Uniform Resource Locator
flash: Uniform Resource Locator
ftp: Uniform Resource Locator
harddisk: Uniform Resource Locator
http: Uniform Resource Locator
https: Uniform Resource Locator
nvram: Uniform Resource Locator
tftp: Uniform Resource Locator

音声ルータでイネーブルにできるデバッグ

コールフローと機能のタイプ（TDM、CUBE、またはSCCPメディアリソース）はそれぞれ異なり、有効にできる特定のデバッグがあります。必要なすべてのデバッグを同時に有効にする必要があります。一度に1つのデバッグしか取得できなかった場合は効果がなく、データの分析時に混乱が生じます。

デバッグは、CLI execプロンプトレベルRouter#で有効にします。このレベルでは、特権のある実行モードの権限が必要になります。

基本的なデバッグと高度なデバッグがあります。基本的なデバッグは、SIP、H323、またはMGCPのいずれかでシグナリング情報を収集するために使用され、ルータとそのピアデバイスとの通信を示します。

高度なデバッグは非常に詳細で、通常は、基本的なデバッグでは表示できない内部スタックエラーが発生した場合により多くの情報を収集するために使用されます。これらのデバッグは通常、CPUに負荷をかけます。

ヒント：デバッグを有効にした後は、必ずclear logging コマンドを実行してください。このコマンドを使用すると、デバッグをより正確にキャプチャするためにバッファが確実にクリアされます。

内部コール制御API(CCAPI)のデバッグ

各Cisco IOS/IOS XEルータ内には、異なるVoIPアプリケーションまたはプロトコル間の通信、およびデータプレーンコンポーネント（RTP、DSP、音声カードなど）を担当するコール制御APIがあります。この層からデータをキャプチャするために使用できる特定のデバッグがあります：

debug voip ccapi inout

このデバッグには他のオプションもありますが、debug voip ccapi inoutでは、すべての基本的なダイヤルプランとコール確立情報がカバーされており、通常はこの層の状態を理解するのに十分な数以上です。

ヒント:debug voip ccapi inoutは通常、ルータのCPUへの影響が最小限であるため、コールとその他の状態に関する情報をログの完全なセットに提供するには、あらゆるシグナリングデバッグとともにイネーブルにすることを推奨します。

SIPコールフロー

これらのデバッグは、SIPコールフローで最も一般的に使用され、ルータとCUCM間またはその他の任意のSIPサーバやプロキシ間のSIPレッグを使用して、CUBEおよびTDMゲートウェイ内で有効にできます。

基本的なSIPデバッグ

debug ccsip messages
debug ccsip error
debug ccsip non-call !Optional, applies for SIP OPTIONS and SIP REGISTER Messages.

高度なSIPデバッグ

debug ccsip all
debug ccsip verbose
debug voice ccapi inout

デジタル(PRI、BRI)コールフロー

次のデバッグは、一次群速度インターフェイス(PRI)T1/E1または基本速度インターフェイス(BRI)に適用されます。

基本的なデジタルデバッグ

debug isdn q931

高度なデジタルデバッグ

debug isdn q921

アナログコールフロー

次のデバッグは、Foreign eXchange Subscriber(FXS)またはForeign eXchange Office(FXO)ポートなどのアナログ回線が含まれている場合に使用されます。

debug vpm signal
debug voip vtsp all

MGCPコールフロー

これらのデバッグは、音声ゲートウェイとCUCM間の音声プロトコルとしてMGCPが使用される場合に使用されます。

基本的なデバッグ

debug mgcp packets
debug mgcp errors

CCM-Managerのデバッグ

ccm-managerデバッグは、設定のダウンロード、およびCUCMと音声ゲートウェイ間のMoHおよびPRI/BRIバックホールメッセージの追跡に使用されます。これらのデバッグは必要に応じて使用され、障害のシナリオによって異なります。

debug ccm-manager backhaul !For PRI and BRI Deployments
debug ccm-manager errors
debug ccm-manager events
debug ccm-manager config-download !Troubleshoot Configuration download issues from CUCM TFTP
debug ccm-mananger music-on-hold !Troubleshoot internal MoH Process

高度なMGCPデバッグ

debug mgcp all

H323コールフロー

H323は広く使用されていませんが、H323が設定された導入は依然として存在します。

基本的なH323デバッグ

debug h225 asn1
debug h245 asn1
debug h225 events
debug h245 events

高度なH323デバッグ

debug cch323 h225
debug cch323 h245
debug cch323 all

SCCPメディアリソース

メディアターミネーションポイント(MTP)またはCUCMサーバに登録されたトランスコーダに関連するSCCPメディアリソースの問題をトラブルシューティングするには、次のデバッグを使用します。

基本的なSCCPデバッグ

debug sccp messages
debug sccp events
debug sccp errors

高度なSCCPデバッグ

debug sccp all

VoIPトレース

Cisco IOS XE 17.4.1および17.3.2の導入により、Cisco Unified Border Element(CUBE)内で音声ログをキャプチャする新しいオプションが追加されました。 この新機能はVoIPトレースと呼ばれます。これは、デバッグを有効にせずにSIPシグナリングとイベントを記録するために作成された、新しいサービスアビリティフレームワークです。 

VoIPトレースはデフォルトで有効になっており、必要に応じていつでも無効にできます。VoIPトレースは、SIPコールに関する特定の情報のみをキャプチャします。

• SIPトランク間コールのSIPメッセージ
• SIPレイヤからCUBEの他のレイヤへのイベントおよびAPIコール
• SIPエラー
• コール制御（CUBEで処理されるユニファイドコミュニケーションのコールフロー）
• 有限状態マシン(FSM)の状態とイベント
• ダイヤルピアの一致
• 割り当てられたRTPポート
• IECエラーとSIPシグナリングの相関関係

制約事項

VoIPトレースは、アウトオブダイアログSIPメッセージに関連する情報をログに記録しません。

• REGISTER
• OPTIONS
• 登録/通知
• INFO

HAでのVoIPトレースはサポートされていますが、次の注意事項が適用されます。

• スタンバイルータでは、VoIPトレースがデフォルトで有効になっています。スタンバイプロセスに適用可能なトレースのみが、アクティブになるまで表示されます。
• スタンバイがアクティブになると、チェックポイントされたコールからの完全なトレースは含まれず、新しいコールだけが含まれます。
• show voip trace <key>は、スタンバイルータで引き続き動作し、コールのカバーバッファとメディアストリームデータを表示します。

VoIPトレースを有効にする方法

すでに説明したように、この機能はデフォルトで有効になっています。この機能を有効にするコマンドは次のとおりです。

Router# configuration terminal
Router(config)# voice service voip
Router(conf-voi-serv)# trace
Router(conf-serv-trace)#

VoIPトレースを無効にする方法

この機能を無効にするコマンドは次のとおりです。

Router(conf-serv-trace)# no trace
!or
Router(conf-serv-trace)# shutdown

注意:VoIPトレースを無効にすると、すべてのメモリがクリアされ、情報が失われます。

トレースコンフィギュレーションモードで使用できるコマンドは次のとおりです。

Router(conf-serv-trace)# ?
default       Set a command to its defaults
  exit          Exit from voice service voip trace mode
  memory-limit  Set limit based on memory used
  no            Negate a command or set its defaults
  shutdown      Shut Voip Trace debugging

メモリ制限の設定

メモリ制限は、データを保存するためにVoIPトレースが使用するメモリの量を決定します。デフォルトでは、これはプラットフォームで使用可能なメモリの10 %ですが、最大で1 GB、最小で10 MBに変更できます。メモリは動的に割り当てられます。つまり、この機能は必要に応じてメモリのみを使用し、コールの量に依存します。使用可能な最大メモリに達すると、古いエントリは循環して削除されます。

メモリ制限を修正して、使用可能なメモリの10 %を超えると、コマンドラインインターフェイス(CLI)に次のメッセージが表示されます。

Router(conf-serv-trace)# memory-limit 1000
Warning: Setting memory limit more than 10% of available platform memory (166 MB) will affect system performance.

デフォルトのメモリ使用率を10 %に設定するには、memory-limit platform コマンドを使用します。

Router(conf-serv-trace)# memory-limit platform
 Reducing the memory-limit clears all VoIP Trace statistics and data.
 If you wish to copy this data first, enter 'no' to cancel,
 otherwise enter 'yes' to proceed. Continue? [no]: 

注意：メモリ制限を減らすと、VoIPトレースデータはすべて失われます。メモリを削減する前に、データのバックアップを収集する必要があります。

VoIPトレースデータの表示方法

VoIPトレースからのデータを表示するには、特定のshowコマンドを使用する必要があります。データは同じターミナルセッションで表示することも、syslog経由でオフボックスsyslogサーバに送信することもできます。

注：トレースは、コールに対するBYEを受信してから32秒後にダンプされます。

注:SIPシグナリングはレッグごとに表示され、通常のデバッグのように組み合わされることはありません。debug CCSIP messagesなどの通常のデバッグでは、イベントが発生した正確な順序でコールのSIPシグナリングが表示されます。VoIPトレースでは、各レッグは別々です。正しい順序を決定するために、タイムスタンプが使用されます。

データの表示に使用できるコマンドは次のとおりです。

Router# show voip trace ?
  all            Display all VoIP Traces
  call-id        Filter traces based on Internal Call Id
  correlator     Filter traces based on FPI Correlator
  cover-buffers  Display the summary of all cover buffers
  session-id     Filter traces based on SIP Session ID
  sip-call-id    Filter traces based on SIP Call Id
  statistics     Display statistics for VoIP Trace

Show VoIP Trace All（すべてのVOIPトレースを表示）

このコマンドは、バッファ内で使用可能なすべてのVoIPトレースデータを表示します。このコマンドの使用は、ルータのパフォーマンスに影響します。コマンドを入力すると、リスクに関する警告メッセージが表示され、続行を確認します。

Router# show voip trace all
 Displaying 11858 cover buffers
 This may severely impact system performance.
 Continue? [yes/no] no 

Show VoIP Trace Cover-Buffers（隠しコマンド）

このコマンドは、VoIPトレースの下で報告されたすべてのコールの詳細なコールの概要を表示します。各コールレッグには、ロギングされたコールの要約を含むカバーバッファが作成されます。

Router# show voip trace cover-buffers
------------------ Cover Buffer ---------------
Search-key = 8845:3002:659
Timestamp = *Sep 30 01:17:33.615
Buffer-Id = 1
CallID = 659
Peer-CallID = 661
Correlator = 4
Called-Number = 3002
Calling-Number = 8845
SIP CallID = 20857880-1ec12085-13b930-411b300a@10.48.27.65
SIP Session ID = 2b1289c400105000a0002c3ecf872659
GUID = 208578800000
-----------------------------------------------

------------------ Cover Buffer ---------------
Search-key = 8845:3002:661
Timestamp = *Sep 30 01:17:33.634
Buffer-Id = 2
CallID = 661
Peer-CallID = 659
Correlator = 4
Called-Number = 3002
Calling-Number = 8845
SIP CallID = 8D6DEC28-1F111EB-829FD797-1B22F6DB@10.48.55.11
SIP Session ID = 0927767800105000a0005006ab805584
GUID = 208578800000
-----------------------------------------------

各フィールドの詳細については、次の表を参照してください。

カバーバッファをフィルタリングするには、include コマンドとsection コマンドを使用できます。

Router# show voip trace cover-buffers | include Search-key | 8845 | 3002
Search-key = 8845:3002:661
!or
Router# show voip trace cover-buffers | section Search-key | 8845 | 3002
Search-key = 8845:3002:661

VoIPトレースコールIDの表示

前のコマンドと組み合わせて、show voip trace call-idを使用してコールを検索できます。コールIDが特定されたら、次のコマンドを使用して、特定のコールレッグに関するすべての情報を表示できます。

Router# show voip trace cover-buffers | include Search-key | 8845 | 3002
Search-key = 8845:3002:661
Router# show voip trace call-id 661

VoIPトレース統計情報の表示

このshowコマンドは、ステータス、メモリ消費、エラーまたは失敗コール、成功したコール、最新および最も古いエントリのタイムスタンプなどに関する詳細出力を表示します。

Router# show voip trace statistics
VoIP Trace Statistics
Tracing status             : ENABLED at *Sep 12 06:44:02.349
Memory limit configured    : 803209216 bytes
Memory consumed            : 254550928 bytes (31%)
Total call legs dumped     : 2
Oldest trace dumped        : *Sep 12 07:29:21.077 Search-key: 9898:30000:64
Latest trace dumped        : *Sep 12 07:29:21.010 Search-key: 9898:30000:63
Total call legs captured   : 11858
Total call legs available  : 11858
Oldest trace available     : *Sep 12 06:57:23.923, Search-key: 5250001:4720001:11
Latest trace available     : *Sep 13 05:08:25.353, Search-key: 19074502232:30000:13177
Total traces missed        : 0

各フィールドの詳細については、次の表を参照してください。

その他の show コマンド