Hierarchical Navigation |
目次概要 概要ここでは、Cisco IOS® プラットフォームで利用可能なデバッグを使用するための一般的なガイドラインと、debug ip packet コマンドや条件付きデバッグの正しい使用例について説明します。 注：このドキュメントでは、特定の debug コマンドの使用方法と出力の解釈方法については説明していません。特定の debug コマンドの詳細については、該当する Cisco デバッグ コマンド リファレンスのドキュメントを参照してください。 debug 特権 EXEC コマンドの出力には、一般的なプロトコル ステータスやネットワーク アクティビティに関連したさまざまなインターネットワーキング イベントについての診断情報が記載されています。 前提条件要件次の項目に関する知識があることが推奨されます。
使用するコンポーネントこのドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。 このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。 警告debug コマンドは、注意して使用してください。一般に、これらのコマンドは、特定の障害をトラブルシューティングする場合に限り、必ずルータの技術サポート担当者の指示に従って使用することをお勧めします。 インターネットワークに高い負荷が生じているときにデバッグを有効にすると、ルータの動作が中断する場合があります。そのため、ロギングが有効な場合、コンソール ポートがログ メッセージで過負荷になるとアクセス サーバは断続的にフリーズする場合があります。 debug コマンドを開始する前に、このコマンドが生成する出力とそれにかかる時間について必ず考慮してください。たとえば、ルータが Basic Rate Interface（BRI）を 1 つ装備している場合、debug isdn q931 によってシステムに悪影響が及ぶことはおそらくありません。しかし、同じデバッグをフル E1 設定の AS5800 で行うと、多くの場合、大量の入力が生成されて「ハング」し、応答が停止します。 デバッグを行う前に、show processes cpu コマンドを使用して CPU の負荷を調べます。デバッグを開始する前に、CPU を十分に使用できることを確認します。高い CPU 負荷に対処する方法の詳細は、『Cisco ルータの CPU 使用率が高い場合のトラブルシューティング』を参照してください。たとえば、Cisco 7200 ルータにブリッジングを実行する ATM インターフェイスを使用している場合、設定されたサブインターフェイスの量にもよりますが、ルータを再起動するのに CPU 能力を大量に使用する可能性があります。これは、各 Virtual Circuit（VC; 仮想回線）に Bridge Protocol Data Unit（BPDU; ブリッジ プロトコル データ ユニット）パケットを生成する必要があるためです。この臨界時にデバッグを開始すると、CPU 使用量が劇的に上昇して、ハングしたりネットワークが接続不能になったりする可能性があります。 注：デバッグの実行中、特にデバッグの負荷が高いときには、ルータのプロンプトは通常表示されません。しかし、ほとんどの場合、no debug all コマンドまたは undebug all コマンドを使用してデバッグを中止できます。デバッグを安全に使用する方法の詳細は、「デバッグ出力の取得」を参照してください。 表記法ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。 デバッグを行う前に上記の内容に加えて、デバッグがプラットフォームの安定性に与える影響についても、必ず把握してください。ルータのどのインターフェイスに接続するかについても検討する必要があります。次のセクションで、いくつかのガイドラインについて説明します。 デバッグ出力の取得ルータはデバッグ出力を、コンソール ポート、aux ポート、vty ポートなどさまざまなインターフェイスに表示できます。ルータは、内部バッファへのメッセージを外部 UNIX syslog サーバへログすることもできます。各方法の指示と注意について、次に説明します。 コンソール ポートコンソールから通常の設定で接続しているときは、特別な作業を行う必要はありません。デバッグ出力は自動的に表示されます。ただし、logging console level が目的どおりに設定されており、ロギングが no logging console コマンドにより無効になっていないことを確認してください。詳細は、『debug コマンドの使用』を参照してください。
注：コンソール ポートのログはデフォルトで有効になっています。そのため、ユーザが実際には他のポートや方法（Aux、vty、バッファなど）を使用して出力結果を取得する場合でも、コンソール ポートは常にデバッグ出力を処理しています。そのため、通常の稼働状況では常にコマンド no logging console を有効にしておいて、デバッグ出力の取得には別の方法を使用することをお勧めします。コンソールを使用する必要がある状況では、一時的に logging console をオンに戻します。 Aux ポートAux ポートを使用して接続している場合は、terminal monitor コマンドを入力します。また、no logging on コマンドがルータ上で有効になっていないことも確認してください。 注：ルータの監視に Aux ポートを使用する場合、Aux ポートには、ルータがリブートする際のブート シーケンスが表示されないことに注意してください。ブートシーケンスを表示するには、コンソール ポートに接続します。 VTY ポートAux ポートまたは telnet で接続している場合は、terminal monitor コマンドを入力します。また、no logging on コマンドが使用されていないことも確認してください。 内部バッファへのメッセージのロギングデフォルトのロギング デバイスはコンソールです。他のデバイスを指定しない限り、すべてのメッセージはコンソールに表示されます。 メッセージを内部バッファにログするには、logging buffered ルータ設定コマンドを使用します。このコマンドの全構文は次のとおりです。 logging buffered no logging buffered logging buffered コマンドは、ログ メッセージをコンソールに表示するのではなく、内部バッファにコピーします。バッファは実際には循環しており、新しいメッセージによって古いメッセージが上書きされます。バッファ内にログされているメッセージを表示するには、特権 EXEC コマンド show logging を使用します。最初に表示されるメッセージは、バッファ内で最も古いメッセージです。バッファのサイズを指定できるだけでなく、ログされるメッセージの重大度も指定できます。 ヒント：バッファ サイズを入力する前に、装置で十分なメモリが使用できることを確認します。IOS コマンド show proc mem を使用して、使用可能なメモリ量を確認します。 no logging buffered コマンドは、バッファの使用を取り消し、メッセージをコンソールに表示します（デフォルト）。 メッセージの UNIX Syslog サーバへのロギングメッセージを syslog サーバ ホストにログするには、logging ルータ設定コマンドを使用します。このコマンドの全構文は次のとおりです。 logging <ip-address> no logging <ip-address> logging コマンドは、ロギング メッセージを受信する syslog サーバ ホストを識別します。引数 <ip-address> は、ホストの IP アドレスです。このコマンドを何度も発行すると、ロギング メッセージを受信する syslog サーバのリストが作成されます。 no logging コマンドは、指定されたアドレスの syslog サーバを syslog のリストから削除します。 syslog サーバのセットアップについての詳細は、『debug コマンドの使用』を参照してください。 その他のデバッグ前の作業
これらのコマンドはタイム スタンプを MMM DD HH:MM:SS の形式でデバッグに追加し、日付と時間をシステム クロックに従って表示します。システム クロックをまだ設定していない場合は、日付と時刻の前にアスタリスク（*）が表示されて日付と時刻が正確でないことが示されます。 一般にはミリ秒のタイムスタンプを設定することをお勧めします。これによりデバッグ出力を見るときにより明確になります。タイムスタンプをミリ秒に設定すると、相互に関連しているさまざまなデバッグ イベントのタイミングをより明確に知ることができます。ただし、コンソール ポートから多くのメッセージが出力される場合は、タイムスタンプとイベントの実際の時刻が一致しない場合があることに注意してください。たとえば、200 個の VC がある装置で、すべてに対して debug x25 を有効にすると、（no logging console コマンドと logging buffered コマンドを使用して）バッファに出力がロギングされますが、（バッファ内の）デバッグ出力に表示されるタイムスタンプは、パケットがインターフェイスを通過した正確な時刻ではない可能性があります。そのため、ミリ秒のタイムスタンプはパフォーマンス問題を検査するために使用するのではなく、イベントがいつ発生したかに関する関連情報を取得するために使用します。 デバッグの停止デバッグを停止するには、no debug all コマンドまたは undebug all コマンドを使用します。デバッグがオフになっていることを、show debug コマンドを使用して確認してください。 no logging console コマンドと terminal no monitor コマンドで停止されるのは、それぞれコンソールへの出力と Aux または vty への出力だけであることに注意してください。デバッグは停止されないため、ルータのリソースは消費されています。 debug ip packet コマンドの使用debug ip packet コマンドは、ルータによりファースト スイッチングされないパケットに関する情報を作成します。しかし、すべてのパケットの出力を作成するため、出力は大規模になりルータがハングする可能性があります。このため、debug ip packet はこのセクションで説明している条件に準拠して使用してください。 debug ip packet の出力を制限する最もよい方法は、デバッグにリンクされたアクセスリストを作成することです。アクセスリストの基準に一致するパケットだけが debug ip packet の対象になります。このアクセスリストをインターフェイスに適用する必要はありません。デバッグ操作に適用します。 debugging ip packet を使用する前に、ルータがデフォルトでファースト スイッチングを行っているのか、CEF スイッチング（そのように設定されている場合）を実行しているのかに注意してください。これは、これらの技法が設定されていると、パケットはプロセッサに送られず、そのためデバッグには何も表示されないことを示します。これが正しく働くには、no ip route-cache（ユニキャスト パケットの場合）または no ip mroute-cache（マルチキャスト パケットの場合）を使用して、ルータでのファースト スイッチングを無効にする必要があります。これは、トラフィックが流れると思われるインターフェイスに適用します。show ip route コマンドで、これを確認してください。 警告：
たとえば、次のようなシナリオを考えてみましょう。
router_122 には、次のアクセスリストが設定されています。 access-list 105 permit icmp host 10.10.10.2 host 13.1.1.1 access-list 105 permit icmp host 13.1.1.1 host 10.10.10.2 このアクセス リストは、ホストの router_121（IP アドレスは 10.10.10.2）からホストの router_123（IP アドレスは 13.1.1.1）へ、および逆方向のすべての Internet Control Message Protocol（ICMP; インターネット制御メッセージ プロトコル）パケットを許可しています。どちらの方向のパケットも許可することが重要です。許可しないと、ルータは戻りの ICMP パケットを廃棄する場合があります。 ここで、router_122 の 1 つのインターフェイスでだけファースト スイッチングを解除します。つまり、パケットをインターセプトする IOS の観点から見ると、そのインターフェイスを宛先とするパケットのデバッグ情報だけが表示されることになります。デバッグの観点から見ると、そのようなパケットは「d=」付きで表示されます。他のインターフェイスではファースト スイッチングをオフにしていないため、戻りのパケットは debug ip packet の対象にはなりません。次の出力に、ファースト スイッチングを無効にする方法を示します。 router_122(config)#interface virtual-template 1 router_122(config-if)#no ip route-cache router_122(config-if)#end 次に debug ip packet を、先に定義したアクセスリスト（access-list 105）で有効にする必要があります。 router_122#debug ip packet detail 105 IP packet debugging is on (detailed) for access list 105 router_122# 00:10:01: IP: s=13.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:10:01: ICMP type=0, code=0 ! -- 13.1.1.1 から 10.10.10.2 への ICMP パケット。 ! -- このパケットが表示されるのは、 ! -- アクセス リスト 105 にある発信元と宛先の要件と一致するからです 00:10:01: IP: s=13.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:10:01: ICMP type=0, code=0 00:10:01: IP: s=13.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:10:01: ICMP type=0, code=0 今度は、（router_122 の）別のインターフェイスでファースト スイッチングを解除します。これによって、この 2 つのインターフェイス上のすべてのパケットがパケット交換されます（これは debug ip packet の要件）。 router_122(config)#interface serial 3/0
router_122(config-if)#no ip route-cache
router_122(config-if)#end
router_122#
00:11:57: IP: s=10.10.10.2 (Virtual-Access1), d=13.1.1.1
(Serial3/0), g=172.16.1.6, len 100, forward
00:11:57: ICMP type=8, code=0
! -- 10.10.10.2 から 13.1.1.1 への ICMP パケット（エコー）
00:11:57: IP: s=13.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1),
g=10.10.10.2, len 100, forward
00:11:57: ICMP type=0, code=0
! -- 13.1.1.1 から 10.10.10.2 への ICMP 戻りパケット（エコー応答）
00:11:57: IP: s=10.10.10.2 (Virtual-Access1), d=13.1.1.1 (Serial3/0),
g=172.16.1.6, len 100, forward
00:11:57: ICMP type=8, code=0
00:11:57: IP: s=13.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1),
g=10.10.10.2, len 100, forward
00:11:57: ICMP type=0, code=0
debug ip packet の出力には、アクセス リストの条件に一致しないパケットは表示されないことに注意してください。この手順のその他の情報については、『ping および traceroute コマンドについて』を参照してください。 アクセスリストの作成方法についての詳細は、『標準 IP アクセス リスト ロギング』を参照してください。 条件付きで起動されるデバッグデバッグの条件付き起動機能を有効にすると、ルータは指定したインターフェイスでルータを出入りするパケットのデバッグ メッセージを生成します。このルータは別のインターフェイスで出入りするパケットのデバッグ出力を生成しません。条件付きデバッグの使用に関する詳細は、『条件付きで起動されるデバッグ』を参照してください。 条件付きデバッグの簡単な実装を見てみましょう。次のシナリオを考えます。下記のルータ（trabol）には 2 つのインターフェイス（シリアル 0 とシリアル 3）があり、どちらも HDLC カプセル化を実行しています。 通常の debug serial interface コマンドを使用して、HDLC キープアライブがすべてのインターフェイスで受信されることを確認します。キープアライブを両方のインターフェイスで確認できます。 traxbol#debug serial interface Serial network interface debugging is on traxbol# *Mar 8 09:42:34.851: Serial0: HDLC myseq 28, mineseen 28*, yourseen 41, line up ! -- インターフェイス シリアル 0 上の HDLC キープアライブ *Mar 8 09:42:34.855: Serial3: HDLC myseq 26, mineseen 26*, yourseen 27, line up ! -- インターフェイス シリアル 3 上の HDLC キープアライブ *Mar 8 09:42:44.851: Serial0: HDLC myseq 29, mineseen 29*, yourseen 42, line up *Mar 8 09:42:44.855: Serial3: HDLC myseq 27, mineseen 27*, yourseen 28, line up 今度は、インターフェイス シリアル 3 の条件付きデバッグを有効にして、インターフェイス シリアル 3 のデバッグ情報だけが表示されるようにします。debug interface <interface_type interface_number> コマンドを使用します。 traxbol#debug interface serial 3 Condition 1 set show debug condition コマンドを使用して、条件付きデバッグが有効なことを確認します。インターフェイス シリアル 3 の条件が有効なことに注意してください。 traxbol#show debug condition Condition 1: interface Se3 (1 flags triggered) Flags: Se3 traxbol# 今度はインターフェイス シリアル 3 のデバッグだけが表示されていることに注意してください。 *Mar 8 09:43:04.855: Serial3: HDLC myseq 29, mineseen 29*, yourseen 30, line up *Mar 8 09:43:14.855: Serial3: HDLC myseq 30, mineseen 30*, yourseen 31, line up 条件付きデバッグを解除するには、undebug interface <interface_type interface_number> コマンドを使用します。条件付きの起動を解除する前に、（undebug all などを使用して）デバッグをオフにしておくことをお勧めします。これは、条件が解除されたときデバッグ出力が集中するのを回避するためです。 traxbol#undebug interface serial 3 This condition is the last interface condition set. Removing all conditions may cause a flood of debugging messages to result, unless specific debugging flags are first removed. Proceed with removal?[yes/no]: y Condition 1 has been removed traxbol 今度は、シリアル 0 とシリアル 3 の両インターフェイスのデバッグが表示されていることに注意してください。 *Mar 8 09:43:34.927: Serial3: HDLC myseq 32, mineseen 32*, yourseen 33, line up *Mar 8 09:43:44.923: Serial0: HDLC myseq 35, mineseen 35*, yourseen 48, line up
次のセクションでは、ATM パケット デバッグを 1 つのサブインターフェイスに制限する正しい方法を説明します。 arielle-nrp2#debug atm packet interface atm 0/0/0.1 !--- デバッグに使用するサブインターフェイスを明示的に指定していることに注意してください ATM packets debugging is on Displaying packets on interface ATM0/0/0.1 only arielle-nrp2# *Dec 21 10:16:51.891: ATM0/0/0.1(O): VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:16:51.891: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 01FE 0000 FF11 61C8 0A30 *Dec 21 10:16:51.891: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 0015 23B7 0000 8000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: arielle-nrp2# ATM デバッグを（適用された条件で）すべてのインターフェイスで有効にしようとすると、ルータに大量の ATM サブインターフェイスがある場合はハングする可能性があります。ここで示されているのは ATM デバッグの誤った方法の一例です。 この場合には条件が適用されていることがわかりますが、効果がないこともわかります。別のインターフェイスからのパケットも確認できます。この実験シナリオでは、インターフェイスは 2 つだけでトラフィックもほとんどありません。インターフェイスの数が多いと、すべてのインターフェイスのデバッグ出力は極端に高くなり、ルータが停止する原因になります。 arielle-nrp2#show debugging condition Condition 1: interface AT0/0/0.1 (1 flags triggered) Flags: AT0/0/0.1 ! -- 特定のインターフェイスに対する条件。 arielle-nrp2#debug atm packet ATM packets debugging is on Displaying all ATM packets arielle-nrp2# *Dec 21 10:22:06.727: ATM0/0/0.2(O): ! -- AT0/0/0.1 だけを条件に指定した場合でも、 ! -- インターフェイス ATM0/0/0/.2 のデバッグ情報は表示されます VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:06.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:06.727: 0002 000F 0000 *Dec 21 10:22:06.727: un a *Dec 21 10:22:08.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:08.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:08.727: 0002 000F 0000 *Dec 21 10:22:08.727: ll *Dec 21 10:22:10.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:10.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:10.727: 0002 000F 0000 *Dec 21 10:22:10.727: *Dec 21 10:22:12.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:12.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:12.727: 0002 000F 0000 *Dec 21 10:22:12.727: *Dec 21 10:22:13.931: ATM0/0/0.1(O): !--- 指定したとおりインターフェイス ATM0/0/0.1 のデバッグ情報も表示されます。 VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:22:13.931: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 027F 0000 FF11 6147 0A30 *Dec 21 10:22:13.931: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 001A 4481 0000 8000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.935: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 シスコ サポート コミュニティ - 特集対話Cisco サポート コミュニティ - 特集対話関連情報 |
| 
警告：ルータのコンソール ポートで過度のデバッグを行うとハングする場合があります。これは、ルータが自動的にコンソール出力を他のルータ機能より優先するためです。したがって、ルータがコンソール ポートへ大量のデバッグ結果を出力していると、ハングする可能性があります。そのためデバッグ出力が多過ぎる場合は、vty（telnet）ポートまたはログ バッファを使用してデバッグを行います。詳細については、次に説明します。 