CUBEおよびTDMゲートウェイのデバッグ収集の設定
内容
はじめに
このドキュメントでは、Cisco IOS®/IOS XE®音声ルータの音声デバッグを収集するためのベストプラクティスの一部について説明します。
前提条件
要件
- ISRルータでコマンドを実行するための特権アクセス。
- Voice-over-IP(VoIP)プロトコルに関する以前の経験が必要です。
- VoIPトレースには、少なくともCisco IOS XE 17.4.1または17.3.2が必要です。
- サービス統合型ルータ(ISR)内のCisco IOS/IOS XEの基礎知識
使用するコンポーネント
このドキュメントでは、次のコンポーネントを使用します。
- PuTTY
- Cisco ISR 3925
- Cisco ISR 4451
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
バックグラウンド情報
これらのプラットフォームでのデバッグ収集のプロセスには課題があり、デバイスのパフォーマンスに影響を与える可能性があります。音声ルータで複数のアクティブコールが確立されると、課題とリスクが増大します。一部のシナリオでは、デバッグが正しく収集されないと、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音声に変換され、その音声が特定の回線に送信されます。これらのゲートウェイは、VoIP側およびTDM側でH323、MGCP、またはSkinny Call Control Protocol(SCCP)と相互運用できます。PSTNまたはエンドポイントへの最も一般的な接続は、ISDN PRI回線またはアナログです。
図に示すように、TDMゲートウェイは、内部VoIPインフラストラクチャとアナログまたはISDNサービスプロバイダー間のブリッジを提供します。
VoIPの導入により、顧客はレガシーシステムを最新のVoIPインフラストラクチャに迅速に変更しました。同じことがサービスプロバイダー側でも起こり、接続を使用してオンプレミステレフォニーサービスとサービスプロバイダーのVoIPインフラストラクチャを相互接続し、より良いサービスを提供するために機能を拡張しています。現在最も一般的に使用されているVoIPプロトコルはSession Initiation Protocol（SIP；セッション開始プロトコル）で、現在は世界中のお客様やInternet Telephony Service Provider（ITSP；インターネットテレフォニーサービスプロバイダー）で広く使用されています。
CUBEは、プライマリVoIPプロトコルとしてSIPを使用するITSPを介して、これらの内部VoIPシステムを外部と相互接続する方法を提供するために導入されました。CUBEは単なるIP-IPゲートウェイであり、T1/E1コントローラやアナログポートのようなTDMタイプの接続を必要としません。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を選択します。
CLIからの基本的なshowコマンド出力の収集
showコマンドは、デバッグの収集が発生する前にルータから基本情報を収集するために必要です。showコマンドは収集が迅速で、ほとんどの場合、ルータのパフォーマンスに影響を与えません。showコマンドを実行すると、問題の切り分けをすぐに開始できます。
ルータに接続した後、ターミナル長を0に設定できます。これにより、すべての出力を一度に表示するための迅速な収集が可能になり、スペースバーを使用する必要がなくなります。ルータに関する詳細情報を収集するコマンドの1つに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を使用します。
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相当の出力を受け取るか、使用可能なメモリがある場合にはさらに大きな出力を受け取ることができます。
メモリの空き容量が少ない場合は、メモリリークの問題がある可能性があります。その場合は、アーキテクチャ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エンジニアが使用する一般的なベースラインです。これにより、10 MBのバッファメモリが割り当てられますが、必要に応じて増やすことができます。
# 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：ローカルルータの時刻が、ロギングされたすべてのメッセージにミリ秒単位の精度で書き込まれるようにします。これは、time. millisecondタイムスタンプに基づいてコールを検索する場合に便利です。これにより、同じミリ秒内に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
このコマンドは、バッファ出力全体をファイル名debug.txtのFTP IPアドレス192.168.1.2にコピーします。ファイル名は常に指定する必要があります。データのエクスポートに使用できるその他の宛先は次のとおりです。
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実行プロンプトレベルRouter#で有効にします。このレベルでは、特権のある実行モードの権限が必要になります。
基本的なデバッグと高度なデバッグがあり、SIP、H323、またはMGCPのいずれかでシグナリング情報を収集するために基本的なデバッグが使用されます。これは、ルータとピアデバイスとの通信を示しています。
高度なデバッグは非常に詳細で、内部スタックエラーで基本的なデバッグを表示できない場合に、追加情報の収集に使用されます。これらのデバッグは通常、CPUに負荷をかけます。
内部コール制御API(CCAPI)のデバッグ
各Cisco IOS/IOS XEルータ内には、異なるVoIPアプリケーションまたはプロトコル間の通信を担当するコール制御APIがあります。RTP、DSP、音声カードなどのデータプレーンコンポーネントは、このレイヤからデータをキャプチャします。使用できる特定のデバッグが1つあります。
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エラー
- ダイヤルピアの一致
- 割り当てられたRTPポート
- IECエラーとSIPシグナリングの相関関係
- SIPトランク間コールのSIPメッセージ
- 有限状態マシン(FSM)の状態とイベント
- SIPレイヤからCUBEの他のレイヤへのイベントおよびAPIコール
- コール制御（CUBEで処理されるユニファイドコミュニケーションのコールフロー）
制約事項
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トレースからのデータを表示するには、特定の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
-----------------------------------------------
各フィールドの詳細については、次の表を参照してください。
| フィールド |
説明 |
| 検索キー |
発信側、着信者番号、およびコールIDの組み合わせが含まれる |
| タイムスタンプ |
カバーバッファの作成時間 |
| バッファID |
カバーバッファのバッファID |
| コールID |
カバーバッファへの各コールレッグのコールID |
| ピアコールID |
ピアレッグのコールID |
| 相関器 |
コールのFPIコリレータ |
| 着信番号 |
カバーバッファの各コールレッグの着番号 |
| 発信者番号 |
カバーバッファの各コールレッグの発信番号 |
| SIPコールID |
カバーバッファのそれぞれのコールレッグのSIPコールID |
| SipセッションID |
カバーバッファのそれぞれのコールレッグのSIPセッションID |
| GUID |
カバーバッファの各コールのGUID |
| アンカー脚 |
それぞれのコールレッグがコール分岐フローまたはメディアプロキシ展開のアンカーレッグである場合、アンカーレッグは「はい」に設定されます |
| フォーク脚 |
各コールレッグがコールフォーキングフローまたはメディアプロキシ展開のアンカーレッグである場合、フォークされたレッグは「はい」に設定されます |
| 関連付けられたCalI-ID |
フォークされた関連レグのコールID |
カバーバッファをフィルタするには、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
各フィールドの詳細については、次の表を参照してください。
| フィールド |
説明 |
| トレース状態 |
VoIPトレースが有効になった日時を含む、トレースのステータスを表示します。 |
| メモリ制限の設定 |
設定されているメモリ制限を表示します。これは、プロセッサプールのメモリサイズの10 %です。 |
| 消費メモリ |
VoIPトレース用に動的に消費されるメモリ量を表示します。 |
| ダンプされたコールレッグの総数 |
ロギングバッファにダンプされた失敗したコールレッグの数を表示します。ダンプされたコールとは、IECエラーに関連付けられたコールレッグを指します。 |
| ダンプされた最も古いトレース |
VoIPトレースが有効になってから最も古く失敗したコールのタイムスタンプと検索キーを表示します。 |
| 最新のダンプされたトレース |
VoIPトレースが有効になってから最後に失敗したコールのタイムスタンプと検索キーを表示します。 |
| キャプチャされたコールレッグの合計 |
VoIPトレースが有効になった後にキャプチャされた合計レッグを表示します。 |
| 使用可能なコールレッグの合計 |
履歴で使用可能なコールレッグの合計を表示します。これはキャプチャされたコールレッグの合計と同じであることも、異なることもあります。これはメモリの制限によって異なります。 |
| 使用可能な最も古いトレース |
メモリ内で使用可能な最も古いカバーバッファのタイムスタンプと検索キーを表示します。 |
| 利用可能な最新のトレース |
メモリ内の使用可能な最新カバーバッファのタイムスタンプと検索キーを表示します。 |
| 失われたトレース総数 |
メモリの制限のために失われたコールレッグの数を表示します。 |
その他の show コマンド
| フィールド |
用途 |
説明 |
| show voip trace correlator <コリレータ> |
show voip trace correlator 4（ベータ版） |
カバーバッファから始まる特定のコールIDのVOIPトレースをフィルタリングして表示します。 |
| show voip trace session-id <セッションID> |
show voip trace session-id（隠しコマンド） 87003120822b5dbd8fd80f62d8e57c48 |
SIPセッションIDに基づいて、コールのVoIPトレースをフィルタリングして表示します。SIPメッセージのセッションIDヘッダーのローカルまたはリモートのUUIDを使用して、コールの両方のレッグを表示できます。 |
| show voip trace sip-call-id <コールID> |
show voip trace sip-call-id 01e60dfa9d8442848336d79e3155a8a1 |
SIPコールIDに基づいてVoIPトレースをフィルタリングして表示します。 |
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
4.0 |
17-Aug-2026
|
概要、スペルチェック、文法、読みやすさを考慮したセクションへの横線の挿入、CCWのエラーの修正を更新。 |
3.0 |
13-Feb-2025
|
ブランディング要件、スタイル要件、フォーマット、文法を更新。 |
2.0 |
13-Apr-2023
|
代替テキストが追加されました。
タイトル、概要、ブランディング要件、スタイル要件、Gerunds、フォーマット、文法を更新。 |
1.0 |
13-Aug-2021
|
初版 |
フィードバック