IOS ルータで適切かつ安全にデバッグ情報を収集する方法

ドキュメント

2013/04/12 - 01:25
8月 6th, 2012
User Badges:
  • Silver, 250 points or more
目的

実稼動環境のゲートウェイでデバッグを実行した場合のパフォーマンスに与える影響について、懸念する声がよく聞かれます。このドキュメントの主な目的は、このように考える理由を明らかにすることです。


このような懸念を理解する必要がなく、入力するコマンドだけを知りたい場合は、下の「推奨構成」セクションを参照してください。


実稼動環境のルータでのデバッグ実行は安全か?

IOS ルータ上で音声が実行されるほぼすべての環境で、デバッグを安全に実行できます。それでも、実稼働環境でデバッグを有効にする際は適切な配慮が必要です。影響を最小限にするため、デバッグは一度に 1 つずつ有効にし、「show processor cpu history」(CPU の使用履歴)に注意します。


ここで紹介する推奨構成の実稼働環境での IOS デバッグの安全性については、ラボの 300 の電話機が登録された CME で「debug all」(すべての IOS のデバッグを有効にする)を実行して証明できます。デフォルトのレート制限とキューイングを有効にした場合、CPU に対する影響は 40 % のアップに留まっています。実際の状況では、メッセージの大多数がレート制限され、ログが作成される前に破棄されるため、「debug all」を有効にすることは決してお勧めしませんが、コンソールとモニタおよびレートとキューの制限を無効にすることによって、ビジーなルータでの詳細なデバッグの安定性がどの程度高まるかを実証することができます。通常は最も詳細なデバッグでも 10 ~ 20 % の CPU オーバーヘッドが必要となるだけです。


syslog サーバへのデバッグ出力は不要

個人的な経験によると、syslog サーバから送られるデバッグ情報の 80 % にメッセージの欠落があり、正確な分析を不可能にしています。IOS 側でシーケンス番号を有効にしておくと、この現象を確認できます。syslog はデフォルトで UDP を使用するため、メッセージは通常、厳しいレート制限を受けるためです。もっと信頼性の高い方法で syslog にデバッグすることも可能ですが(syslog に TCP を使用する、または BEEP による Reliable Delivery and Filtering を使用する)、これらの概念はこのドキュメントでは説明しません。


「ターミナル モニタ」でモニタにログを出力できない理由

一気に送信されたデバッグ メッセージが欠落することのないように、ログにデバッグ情報を出力したいと思います。たとえば、H.245 のデバッグでは、同じミリ秒内で 40 ~ 50 行のデバッグ情報が到着することがあり、モニタで表示するには速すぎるため、デバッグ出力の大部分が画面出力から欠落することになります。ログをバッファに出力することで、ターミナル モニタでメッセージが欠落する状況を排除できます。


推奨構成:

Router(config)# service sequence-numbers
Router(config)# service timestamps debug datetime localtime msec
Router(config)# logging buffered 10000000 debug
Router(config)# no logging console
Router(config)# no logging monitor

Router(config)# default logging rate-limit

Router(config)# default logging queue-limit

Router(config)# voice iec syslog


<デバッグを有効にして、問題の発生を待ちます。>

...

<ターミナル プログラムでセッションの txt ファイルへのキャプチャを有効にします。>

Router# terminal length 0

Router# show logging



コマンドによって実行される動作

シナリオによってはこのテンプレートをそのまま適用できない場合もあるため、それぞれのコマンドとその動作について説明していきます。


service timestamps debug datetime localtime msec - ローカル ルータの時刻がミリ秒の精度ですべてのデバッグ結果に書き込まれます。これは、時間に基づいてコールを検索するときに役立ちます。通常、ミリ秒単位の時間は、同じミリ秒内に 2 つの行が発生した場合にデバッグ行を論理的な関連イベントにグループ分けすることを可能にします。


logging buffered 10000000 debug - デバッグ情報をシステム メモリ内のローカル バッファ ログに送信するようにルータに指示します。バッファ サイズはバイト単位で設定され、この例では 10 MB です。必要なバッファ サイズは、コール量、バッファを保存する時間の長さ、利用可能なシステム メモリ(「show memory statistic history」および「show memory summary」を使用して確認)によって異なります。


no logging console - デフォルトでは、ルータのデバッグ情報はコンソールに送信されます。IOS では、コンソールがほかのプロセスより優先度が高いためです。また、コンソールへの送信は、非常に遅い速度で実行されます(通常 9,600 bps)。このため、コンソールの速度よりも速くデバッグ情報がルータに送信された場合、コンソールが入力不能になったり、CPU の使用率が 100 % に達することになります。


このような状況を回避するため、IOS でデバッグを実行するときは、このコマンドを入力して、コンソールへのデバッグ送信を無効にすることが不可欠です。


no logging monitor - このコマンドは、デバッグ情報をリアルタイムにルータの VTY(telnet/SSH)セッションに送信しないようにします。デバッグを事後に取得するため、リアルタイムでスクロールする必要はありません。また、ほとんどの音声デバッグと同様に、メッセージが一気に到着すると、ターミナル モニタでメッセージの欠落が生じます。


default logging rate-limit - デフォルトでは、ルータでメッセージのレート制限が行われます。ルータの安定性を確保するため、これは通常オンにしておくことを推奨します。デバッグ情報がルータのロギング バッファに到達する前に欠落している可能性を TAC 技術者が疑う場合は、この制限値をより大きな値にするか、制限を無効にするよう求めることができます。トラフィック量が多い環境でこれを変更すると、すべてのデバッグ メッセージがロギング バッファに必ず到達するよう処理されるため、CPU が不安定になることがあります。


default logging queue-limit - デフォルトでは、ルータでメッセージのキューも行われます。ロギング バッファへの書き込みを待っている間、ルータのキューに保存されるメモリの量は限られています。ルータの安定性を確保するため、これは通常オンにしておくことを推奨します。デバッグ情報がルータのロギング バッファに到達する前に欠落している可能性を TAC 技術者が疑う場合は、この制限値をより大きな値にするか、制限を無効にするよう求めることができます。ビジーな環境でこれを変更すると、前述と同じ理由で CPU が不安定になることがあります。


service sequence-numbers - このコマンドは、行にデバッグのシーケンス番号を書き込みます。これは syslog サーバに送信するとき、syslog サーバに送られたデバッグ メッセージがネットワーク上で欠落したかどうかを特定するのに役立ちます(実質的に必要)。シーケンス番号は、タイムスタンプと実際のメッセージの前に、デバッグ情報の最初の項目として書き込まれます。syslog ログ ファイルにはタイムスタンプやシーケンス番号を書き込むことができますが、これとは異なることに注意してください。


001033:  *Apr 27 14:29:25.867: %IPPHONE-6-REG_ALARM: NAME=SEP000A10000075  Load=P00308000500 Parms=Status/IPaddr  Last=CM-closed-TCP


こちらのシーケンス番号はレート制限の後に 書き込まれるため、これを使って、バッファ ログに書き込む前にデバッグ情報が欠落しているかどうかを特定することはできません。


voice iec syslog - このコマンドは、接続切断の原因がルータにある場合に追加情報を出力します。これは音声専用で、TAC 技術者にとって役立つ情報です。


%VOICE_IEC-3-GW: C SCRIPTS: 
Internal Error (Incompatible protocols): IEC=1.1.47.11.23.0 on callID 31102


The ouput can be decoded with:

Router# show voice iec description 1.1.47.11.23.0

    IEC Version: 1
    Entity: 1 (Gateway)
    Category: 47 (no resource (47))
    Subsystem: 11 (C SCRIPTS)
    Error: 23 (Incompatible protocols)
    Diagnostic Code: 0


デバッグを実行する方法

デバッグを設定したら、TAC 技術者や CSC メンバーからリクエストされた、または Multiservice Voice Debug Lookup ツールで要求された、関連デバッグを有効にします。


実行するデバッグの選択

デバッグ情報の収集方法について説明してきましたが、コールの問題に関するトラブルシューティングのためにどのデバッグを実行すればよいか迷うかもしれません。これをサポートするために非常に役立つツールが、Multiservice Voice Debug Lookup と呼ばれるツールです。


個人的に、IOS ゲートウェイで一般的なコール障害が発生したときに、まず収集したいデバッグ情報は次のとおりです。


H.323

debug voip ccapi inout

debug h225 asn1

debug h245 asn1

debug cch323 all

debug ip tcp transaction


SIP

debug voip ccapi inout

debug ccsip messages

debug voip rtp session named-event


MGCP

debug voip ccapi inout

debug mgcp packet

debug ip tcp transaction

<適切な POTS デバッグも有効にしてください。>


ISDN

debug voip ccapi inout

debug isdn q931


アナログまたは ISDN 以外の POTS

debug voip ccapi inout

debug vpm signal



デバッグ情報を収集する方法

バッファを構成し、デバッグを有効にすると、すべての出力がバッファに書き込まれます。このバッファはローリング バッファで、定義されたバッファ サイズの上限に達すると、バッファの一番上の最も古い情報が削除され、ログの一番下に最新情報が追加できるようになります。


問題の発生後、「terminal length 0」を発行し、ページごとに enter または space を押す必要がないようにします。その後、「show logging」を発行すると、現在のバッファの内容が画面にダンプ出力されます。Telnet はより高速に転送できるため、コンソールよりも好ましいです。理想的には、デスクトップ上で稼動するターミナル アプリケーションの設定を変更して、このセッションのすべてのターミナル出力をローカルの .txt ファイルに記録させるようにします。この用途で個人的に気に入っているアプリケーションは、PuTTy または SecureCRT です。Mac のターミナル アプリケーションは大量のバッファを非常に効率よく処理します。ログが画面にダンプ出力された後、メモ帳で [すべて選択]/[コピー]/[貼り付け] を行う方法が、個人的には最もよい方法と思われます。



デバッグを無効にする方法

問題についてデバッグ情報を収集した後、次のようにすべてを無効にすることができます。


Router# undebug all


これは必須ではありませんが、コンソールへの同期ロギングおよび VTY セッションを回復したい場合、次のように再度有効にします。

Router(config)# logging console
Router(config)# logging monitor



--------------------------------------------------------------

翻訳元

https://supportforums.cisco.com/docs/DOC-16310

Loading.

アクション

このドキュメントについて

Related Content