この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、Ciscoルータでのpingおよびtracerouteコマンドの使用方法について説明します。
このドキュメントに特有の要件はありません。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
ドキュメント表記の詳細は、「シスコ テクニカル ティップスの表記法」を参照してください。
注:実稼働ルータでdebugコマンドを使用すると、重大な問題が発生する可能性があります。debugコマンドを発行する前に、「debugコマンドの使用」セクションを参照してください。
このドキュメントでは、次の基本設定をこの記事の例で使用します。
IPおよびルータの基本設定
pingコマンドは、デバイスのアクセシビリティのトラブルシューティングに使用される非常に一般的な方法です。次に挙げた事項を決定する際に、一連の Internet Control Message Protocol(ICMP; インターネット制御メッセージ プロトコル)Echo メッセージを使用します。
リモート ホストがアクティブか、非アクティブか
ホストとの通信に使用されるラウンドトリップ遅延。
パケットの損失
ping コマンドはまず、アドレスにエコー要求パケットを送信し、応答を待ちます。ping は、次の場合にだけ成功します。
エコー要求が宛先に到達する場合。
事前定義された時間(タイムアウト)内に、送信先がエコー応答を送信元に返すことができた場合。Cisco ルータでは、このタイムアウトのデフォルト値は 2 秒です。
ping パケットの TTL 値は変更できません。
次のコード例は、debug ip packet detailコマンドを有効にした後のpingコマンドを示しています。
警告:実稼働ルータでdebug ip packet detailコマンドを使用すると、CPU使用率が高くなる可能性があります。その結果、パフォーマンスが著しく低下したり、ネットワークが停止したりする可能性があります。
Router1#debug ip packet detail IP packet debugging is on (detailed) Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms Router1# Jan 20 15:54:47.487: IP: s=172.16.12.1 (local), d=172.16.0.12 (Serial0), len 100, sending Jan 20 15:54:47.491: ICMP type=8, code=0 !--- This is the ICMP packet 172.16.12.1 sent to 172.16.0.12.
!--- ICMP type=8 corresponds to the echo message. Jan 20 15:54:47.523: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 100, rcvd 3 Jan 20 15:54:47.527: ICMP type=0, code=0 !--- This is the answer we get from 172.16.0.12. !--- ICMP type=0 corresponds to the echo reply message.
!--- By default, the repeat count is five times, so there will be five
!--- echo requests, and five echo replies.
可能なICMPタイプ値
ICMP タイプ | 内容 |
---|---|
0 | エコー応答 |
3 | destination unreachable code 0 = net unreachable 1 = host unreachable 2 = protocol unreachable 3 = port unreachable 4 = fragmentation needed, and DF set 5 = source route failed |
4 | ソース クエンチ(始点抑制要求) |
5 | リダイレクト コード 0 = ネットワークのリダイレクト データグラム 1 = ホストのリダイレクト データグラム 2 = タイプ オブ サービスとネットワークのリダイレクト データグラム 3 = タイプ オブ サービスとホストのリダイレクト データグラム |
6 | 代替アドレス |
8 | エコー |
9 ミリ秒 | ルータ アドバタイズメント |
10 | ルータ要求 |
11 | 時間超過コード 0 = トランジット中の存続時間超過 1 = フラグメント再構成時間超過 |
12 | パラメータ問題 |
13 | timestamp-request |
14 | タイムスタンプ応答 |
15 | 情報要求 |
16 | 情報応答 |
17 | マスク要求 |
18 | マスク応答 |
31 | 変換エラー |
32 | モバイル リダイレクト |
Ping機能から出力される可能性のある文字
文字 | 説明 |
---|---|
! | 各感嘆符(!)は、応答の受信を示します。 |
. | 各期間は、ネットワークサーバが応答を待っている間にタイムアウトしたことを示します。 |
U | PDU が受信した宛先到達不能エラー |
Q | ソース クエンチ(宛先がビジー状態) |
M | 断片化不可 |
? | パケット タイプ不明 |
& | パケットの存続時間超過 |
IPアドレスに対してpingを正常に実行できない場合は、このセクションで説明する原因を考慮してください。
次に、pingの失敗の例、問題を特定する方法、および問題を解決するための方法を示します。次のネットワークトポロジ図に例を示します。
ルータの問題
Router1# ! interface Serial0 ip address 172.16.12.1 255.255.255.0 no fair-queue clockrate 64000 ! Router2# ! interface Serial0 ip address 10.0.2.23 255.255.255.0 no fair-queue clockrate 64000 ! interface Serial1 ip address 172.16.0.12 255.255.255.0 ! Router3# ! interface Serial0 ip address 172.16.3.34 255.255.255.0 no fair-queue ! interface Serial1 ip address 10.0.3.23 255.255.255.0 ! Router4# ! interface Serial0 ip address 172.16.4.34 255.255.255.0 no fair-queue clockrate 64000 !
Router1からRouter4にpingを実行します。
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
[Results]:
Router1#debug ip packet IP packet debugging is on
警告:実稼働ルータでdebug ip packetコマンドを使用すると、CPU使用率が高くなる可能性があります。その結果、パフォーマンスが著しく低下したり、ネットワークが停止したりする可能性があります。
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: Jan 20 16:00:25.603: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:27.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:29.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:31.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:33.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Success rate is 0 percent (0/5)
Router1ではルーティングプロトコルが実行されていないため、パケットの送信先が認識されず、「unrouteable」メッセージが発生します。
Router1にスタティックルートを追加します。
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#ip route 0.0.0.0 0.0.0.0 Serial0
[Results]:
Router1#debug ip packet detail IP packet debugging is on (detailed) Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5) Jan 20 16:05:30.659: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:30.663: ICMP type=8, code=0 Jan 20 16:05:30.691: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:05:30.695: ICMP type=3, code=1 Jan 20 16:05:30.699: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:30.703: ICMP type=8, code=0 Jan 20 16:05:32.699: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:32.703: ICMP type=8, code=0 Jan 20 16:05:32.731: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:05:32.735: ICMP type=3, code=1 Jan 20 16:05:32.739: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:32.743: ICMP type=8, code=0
Router2の問題を調べます。
Router2#debug ip packet detail IP packet debugging is on (detailed) Router2# Jan 20 16:10:41.907: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:41.911: ICMP type=8, code=0 Jan 20 16:10:41.915: IP: s=172.16.0.12 (local), d=172.16.12.1 (Serial1), len 56, sending Jan 20 16:10:41.919: ICMP type=3, code=1 Jan 20 16:10:41.947: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:41.951: ICMP type=8, code=0 Jan 20 16:10:43.943: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:43.947: ICMP type=8, code=0 Jan 20 16:10:43.951: IP: s=172.16.0.12 (local), d=172.16.12.1 (Serial1), len 56, sending Jan 20 16:10:43.955: ICMP type=3, code=1 Jan 20 16:10:43.983: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:43.987: ICMP type=8, code=0 Jan 20 16:10:45.979: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:45.983: ICMP type=8, code=0 Jan 20 16:10:45.987: IP: s=172.16.0.12 (local), d=172.16.12.1 (Serial1), len 56, sending Jan 20 16:10:45.991: ICMP type=3, code=1
Router1はパケットをRouter2に正しく送信しましたが、Router2はアドレス172.16.4.34へのアクセス方法を認識していません。Router2は「unreachable ICMP」メッセージをRouter1に返信します。
Router2とRouter3でRouting Information Protocol(RIP)を有効にします。
Router2# router rip network 172.16.0.7 network 10.0.7.23 Router3# router rip network 10.0.7.23 network 172.16.0.34
[Results]:
Router1#debug ip packet IP packet debugging is on Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: Jan 20 16:16:13.367: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:15.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:17.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:19.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:21.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Success rate is 0 percent (0/5)
Router1はRouter4にパケットを送信しますが、Router4は応答を返しません。
Router4で発生する可能性のある問題:
Router4#debug ip packet IP packet debugging is on Router4# Jan 20 16:18:45.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:45.911: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:47.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:47.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:49.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:49.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:51.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:51.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:53.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:53.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable
ルータ4はICMPパケットを受信し、172.16.12.1に応答しようとしますが、このネットワークへのルートがないため失敗します。
Router4にスタティックルートを追加します。
Router4(config)#ip route 0.0.0.0 0.0.0.0 Serial0
これで、両側が互いにアクセスできます。
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
これは、インターフェイスが動作しなくなった状況です。次の例では、Router1からRouter4にpingを実行します。
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5)
ルーティングが正しいため、問題のトラブルシューティングを順を追って実行します。Router2にpingを実行します。
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
前の例の問題は、Router2とRouter3の間の問題です。Router3のシリアルインターフェイスがシャットダウンされた可能性があります。
Router3#show ip interface brief Serial0 172.16.3.34 YES manual up up Serial1 10.0.3.23 YES manual administratively down down
これは簡単に修正できます。
Router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router3(config)#interface serial1 Router3(config-if)#no shutdown Router3(config-if)# Jan 20 16:20:53.900: %LINK-3-UPDOWN: Interface Serial1, changed state to up Jan 20 16:20:53.910: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
このシナリオでは、TelnetトラフィックだけがインターフェイスSerial0経由でRouter4に入ることを許可されています。
Router4(config)# access-list 100 permit tcp any any eq telnet Router4(config)#interface serial0 Router4(config-if)#ip access-group 100 in Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#access-list 100 permit ip host 172.16.12.1 host 172.16.4.34 Router1(config)#access-list 100 permit ip host 172.16.4.34 host 172.16.12.1 Router1(config)#end Router1#debug ip packet 100 IP packet debugging is on Router1#debug ip icmp ICMP packet debugging is on
Router4:
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5) Jan 20 16:34:49.207: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:34:49.287: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:34:49.291: ICMP: dst (172.16.12.1) administratively prohibited unreachable rcv from 172.16.4.34 Jan 20 16:34:49.295: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:34:51.295: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:34:51.367: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:34:51.371: ICMP: dst (172.16.12.1) administratively prohibited unreachable rcv from 172.16.4.34 Jan 20 16:34:51.379: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending
access-listコマンドの最後には、常に暗黙のdeny allが存在します。これは、Router4のSerial 0インターフェイスに入るICMPパケットが拒否されることを意味し、Router 4はICMPの「administratively prohibited unreachable」メッセージを、debugメッセージに示すように、元のパケットの送信元に送信します。解決策は、access-listコマンドに次の行を追加することです。
Router4(config)#access-list 100 permit icmp any any
このシナリオでは、イーサネット接続は次のようになります。
アドレス解決プロトコルの問題
Router4#ping 172.16.100.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.100.5, timeout is 2 seconds: Jan 20 17:04:05.167: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:05.171: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:07.167: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:07.171: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:09.175: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:09.183: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:11.175: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:11.179: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:13.175: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:13.179: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Success rate is 0 percent (0/5) Router4#
この例では、「encapsulation failed」メッセージが原因でpingが機能しません。これは、ルータがパケットを送信する必要があるインターフェイスを認識しているが、その方法を認識していないことを意味します。この場合、アドレス解決プロトコル(ARP)の動作を理解する必要があります。
ARP はレイヤ 2 アドレス(MAC アドレス)をレイヤ 3 アドレス(IP アドレス)にマップするのに使われるプロトコルです。 これを確認するには、show arpコマンドを使用します。
Router4#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 172.16.100.4 - 0000.0c5d.7a0d ARPA Ethernet0 Internet 172.16.100.7 10 0060.5cf4.a955 ARPA Ethernet0
「encapsulation failed」の問題に戻りますが、今回はdebug arpコマンドを有効にします。
Router4#debug arp ARP packet debugging is on Router4#ping 172.16.100.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.100.5, timeout is 2 seconds: Jan 20 17:19:43.843: IP ARP: creating incomplete entry for IP address: 172.16.100.5 interface Ethernet0 Jan 20 17:19:43.847: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d, dst 172.16.100.5 0000.0000.0000 Ethernet0. Jan 20 17:19:45.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d, dst 172.16.100.5 0000.0000.0000 Ethernet0. Jan 20 17:19:47.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d, dst 172.16.100.5 0000.0000.0000 Ethernet0. Jan 20 17:19:49.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d, dst 172.16.100.5 0000.0000.0000 Ethernet0. Jan 20 17:19:51.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d, dst 172.16.100.5 0000.0000.0000 Ethernet0. Success rate is 0 percent (0/5)
上記の出力は、Router4がパケットをブロードキャストし、イーサネットブロードキャストアドレスFFFF.FFFF.FFFFに送信することを示しています。ここで、0000.0000.0000は、Router4が宛先172.16.100.5のMACアドレスを検索することを意味します。この例では、ARPが要求されている間、Router4はMACアドレスを認識しないため、インターフェイスEthernet 0から送信されるブロードキャストフレームのプレースホルダとして0000.0000.000を使用し、10.5 If.応答はありません。show arpの出力のIPアドレスに対応するMACアドレスは不完全としてマークされます。
Router4#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 172.16.100.4 - 0000.0c5d.7a0d ARPA Ethernet0 Internet 172.16.100.5 0 Incomplete ARPA Internet 172.16.100.7 2 0060.5cf4.a955 ARPA Ethernet0
事前定義した期間が経過した後、この不完全なエントリは ARP テーブルから消去されます。MACアドレスがARPテーブルにない限り、pingは「encapsulation failed」の結果として失敗します。
デフォルトでは、2 秒以内にリモート エンドから応答を受信しないと、ping は失敗します。
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
リンクが遅い、または遅延が長いネットワークの場合、2 秒では不十分です。このデフォルトは、拡張pingを使用して変更できます。
Router1#ping Protocol [ip]: Target IP address: 172.16.0.12 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: 30 Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 30 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1458/2390/6066 ms
拡張pingコマンドの詳細については、「拡張pingおよび拡張tracerouteコマンドについて」を参照してください。
前の例では、タイムアウトが増加したときにpingは成功しました。
注:ラウンドトリップの平均時間は 2 秒を超えています。
次の例は、一般的なシナリオです。
正しい送信元アドレス
Router1にLANインターフェイスを追加します。
Router1(config)#interface ethernet0 Router1(config-if)#ip address 10.0.0.1 255.255.255.0
LAN上のステーションからRouter1にpingを実行できます。Router1からRouter2にpingを実行できます。ただし、LAN上のステーションからRouter2にpingを実行することはできません。
Router1 からは、Router2 へ ping できます。なぜならば、デフォルトで、ICMP パケット中のソースアドレスとして、発信インターフェイスの IP アドレスを使用するからです。Router2には、この新しいLANに関する情報がありません。このネットワークからのパケットに応答する必要がある場合、パケットの処理方法が認識されません。
Router1#debug ip packet IP packet debugging is on
警告:実稼働ルータでdebug ip packetコマンドを使用すると、CPU使用率が高くなる可能性があります。その結果、パフォーマンスが著しく低下したり、ネットワークが停止したりする可能性があります。
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/9 ms Router1# Jan 20 16:35:54.227: IP: s=172.16.12.1 (local), d=172.16.0.12 (Serial0), len 100, sending Jan 20 16:35:54.259: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 100, rcvd 3
上記の出力例は、送信されたパケットの送信元アドレスが172.16.12.1であるために機能します。LANからパケットをシミュレートするには、拡張pingを使用する必要があります。
Router1#ping Protocol [ip]: Target IP address: 172.16.0.12 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 10.0.0.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: Jan 20 16:40:18.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Jan 20 16:40:20.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Jan 20 16:40:22.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Jan 20 16:40:24.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending Jan 20 16:40:26.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Success rate is 0 percent (0/5)
この場合、送信元アドレスは10.0.0.1であり、機能しません。パケットは送信されるが、応答は受信されない。この問題を解決するには、Router2で10.0.0.0へのルートを追加します。基本的なルールは、pingを実行するデバイスがpingの送信元に応答を送信する方法も認識している必要があることです。
パケットがルータに到着すると、ルータはそれを割り込みレベルで転送しようとします。該当するキャッシュ テーブル内に一致するものが見つからない場合、そのパケットはプロセス処理のために入力インターフェイスの入力キューに入れられます。一部のパケットは常にプロセス処理されていますが、設定が適切でネットワークが安定していれば、プロセス処理されるパケットで入力キューがいっぱいになることはありません。入力キューがいっぱいになると、パケットは廃棄されます。
インターフェイスはアップしていますが、入力キューのドロップが高いためにデバイスにpingを実行できません。show interfaceコマンドで入力ドロップを確認できます。
Router1#show interface Serial0/0/0 Serial0/0/0 is up, line protocol is up MTU 1500 bytes, BW 1984 Kbit, DLY 20000 usec, reliability 255/255, txload 69/255, rxload 43/255 Encapsulation HDLC, loopback not set Keepalive set (10 sec) Last input 00:00:02, output 00:00:00, output hang never Last clearing of "show interface" counters 01:28:49 Input queue: 76/75/5553/0 (size/max/drops/flushes); Total output drops: 1760 Queueing strategy: Class-based queueing Output queue: 29/1000/64/1760 (size/max total/threshold/drops) Conversations 7/129/256 (active/max active/max total) Reserved Conversations 4/4 (allocated/max allocated) Available Bandwidth 1289 kilobits/sec !--- Output supressed
出力からわかるように、Input Queue Drop が high になっています。入出力キューの廃棄のトラブルシューティングについては、「入力キュー廃棄と出力キュー廃棄のトラブルシューティング」を参照してください。
traceroute コマンドは、パケットが宛先に向かうときに実際に通過するルート検出するのに使用されます。デバイス(たとえば、ルータまたは PC)は、User Datagram Protocol(UDP; ユーザ データグラム プロトコル)データグラムのシーケンスを、リモート ホストの無効ポート アドレスに送信します。
3 つのデータグラムが送られ、それぞれの Time-To-Live(TTL; 生存可能時間)フィールド値が 1 に設定されています。TTL 値が 1 の場合には、データグラムがパス上の最初のルータに到達した時点で、すぐにタイムアウトになります。このルータは、データグラムが時間切れになったことを示す、ICMP Time Exceeded Message (TEM)で応答します。
次に、別の 3 つの UDP メッセージが送信され、それぞれの TTL 値は 2 に設定されているため、2 番目のルータは ICMP TEM を返します。このプロセスは、パケットが実際に他方の宛先に到達するまで続きます。これらのデータグラムは宛先ホストで無効なポートへのアクセスを試みるため、ICMP Port Unreachableメッセージが返され、到達不能なポートであることを示します。このイベントは、終了の信号を traceroute プログラムに送ります。
ここでの目的は、各 ICMP TEM の送信元を記録し、宛先に到達するのにパケットがとったパスのトレースを提供することです。
Router1#traceroute 172.16.4.34 Type escape sequence to abort. Tracing the route to 172.16.4.34 1 172.16.0.12 4 msec 4 msec 4 msec 2 10.0.3.23 20 msec 16 msec 16 msec 3 172.16.4.34 16 msec * 16 msec Jan 20 16:42:48.611: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.615: UDP src=39911, dst=33434 Jan 20 16:42:48.635: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.639: ICMP type=11, code=0 !--- ICMP Time Exceeded Message from Router2. Jan 20 16:42:48.643: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.647: UDP src=34237, dst=33435 Jan 20 16:42:48.667: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.671: ICMP type=11, code=0 Jan 20 16:42:48.675: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.679: UDP src=33420, dst=33436 Jan 20 16:42:48.699: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.703: ICMP type=11, code=0
これはTTL=1で送信されるパケットの最初のシーケンスです。最初のルータ(この場合はRouter2(172.16.0.12))はパケットをドロップし、送信元(172.16.12.1)にtype=11 ICMPメッセージを返信します。これは、Time Exceeded Message(TEM)に相当します。
Jan 20 16:42:48.707: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.711: UDP src=35734, dst=33437 Jan 20 16:42:48.743: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.747: ICMP type=11, code=0 !--- ICMP Time Exceeded Message from Router3. Jan 20 16:42:48.751: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.755: UDP src=36753, dst=33438 Jan 20 16:42:48.787: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.791: ICMP type=11, code=0 Jan 20 16:42:48.795: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.799: UDP src=36561, dst=33439 Jan 20 16:42:48.827: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.831: ICMP type=11, code=0
TTL=2のRouter3(10.0.3.23)でも同じプロセスが発生します。
Jan 20 16:42:48.839: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.843: UDP src=34327, dst=33440 Jan 20 16:42:48.887: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.891: ICMP type=3, code=3 !--- Port Unreachable message from Router4. Jan 20 16:42:48.895: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.899: UDP src=37534, dst=33441 Jan 20 16:42:51.895: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:51.899: UDP src=37181, dst=33442 Jan 20 16:42:51.943: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:51.947: ICMP type=3, code=3
TTL=3で、Router4に最終的に到達します。このとき、ポートは有効ではないため、Router4 は Router1 に type=3(Destination Unreachable Message)、code=3(Port Unreachable)の ICMP メッセージを返信します。
次の表に、tracerouteコマンド出力に表示される可能性のある文字を示します。
IP traceroute テキスト文字
文字 | 説明 |
---|---|
nn ミリ秒 | 各ノードについての、指定プローブ数に対するラウンドトリップ時間(ミリ秒) |
* | プローブがタイムアウト |
A | 管理上の理由による禁止(例:, access-list) |
Q | ソース クエンチ(宛先がビジー状態) |
I | ユーザ割り込みテスト |
U | ポート到達不能 |
H | ホスト到達不能 |
N | ネットワーク到達不能 |
P | プロトコル到達不能 |
T | [タイムアウト(Timeout)] |
? | パケット タイプが不明 |
ラウンドトリップ時間(RTT)は、pingコマンドとtracerouteコマンドで取得できます。これは、エコー パケットを送り、返答を受け取るのに必要な時間です。これにより、リンク上の遅延の大まかな概念が得られます。しかし、この数字はパフォーマンス評価に使えるほど正確ではありません。
パケットの宛先がルータ自体である場合、このパケットはプロセススイッチされる必要があります。プロセッサは、このパケットからの情報を処理し、返答を戻さなければなりません。これは、ルータの第一の目的ではありません。定義上、ルータはパケットをルート付けるように構築されています。応答されたpingは、ベストエフォート型サービスとして提供されます。
これを説明するために、Router1からRouter2へのpingの例を次に示します。
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
RTT は約 4 ミリ秒です。Router2 でプロセスを多用する機能を有効にした後、Router1 から Router2 へ ping を実行してください。
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms
これで、RTT が大幅に増加します。Router2は非常にビジーで、pingに応答しないことがプライオリティです。ルータのパフォーマンスをテストするより良い方法は、ルータを通過するトラフィックを使用することです。
ルータを通過するトラフィック
トラフィックはルータにより最優先として、ファストスイッチされます。基本的なネットワークは次の点を示しています。
基本的なネットワーク3ルータ
Router1からRouter3にpingします。
Router1#ping 10.0.3.23 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.3.23, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms
トラフィックはRouter2を通過し、ファーストスイッチングされます。Router2でプロセス集約機能を有効にします。
Router1#ping 10.0.3.23 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.3.23, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms
ほとんど違いはありません。これは、Router2 で、パケットが割り込みレベルで扱われるためです。
debug コマンドを使用する前に、「debug コマンドの重要な情報」を参照してください。
この記事で使用されているさまざまなdebugコマンドは、pingまたはtracerouteコマンドを使用した場合の動作を示しています。これらのコマンドは、問題のトラブルシューティングに役立ちます。ただし、実稼働環境では、デバッグは注意して使用する必要があります。使っている CPU が強力でない場合、またはプロセス交換されるパケットが大量にある場合、使用中のデバイスの処理速度が簡単に低下してしまう可能性があります。ルータに対する debug コマンドの影響を最小に抑える方法がいくつかあります。アクセス リストを使用して、監視が必要な特定のトラフィックに限定するのもその 1 つです。
以下が一例です。
Router4#debug ip packet ? <1-199> Access list <1300-2699> Access list (expanded range) detail Print more debugging detail Router4#configure terminal Router4(config)#access-list 150 permit ip host 172.16.12.1 host 172.16.4.34 Router4(config)#^Z Router4#debug ip packet 150 IP packet debugging is on for access list 150 Router4#show debug Generic IP: IP packet debugging is on for access list 150 Router4#show access-list Extended IP access list 150 permit ip host 172.16.12.1 host 172.16.4.34 (5 matches)
この設定では、Router4はアクセスリスト150に一致するデバッグメッセージのみを出力します。Router1からのpingにより、次のメッセージが表示されます。
Router4# Jan 20 16:51:16.911: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.003: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.095: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.187: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.279: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3
この問題に対する答えはRouter4からのものではありません。これは、これらのパケットがアクセスリストと一致しないためです。表示するには、次を追加します。
Router4(config)#access-list 150 permit ip host 172.16.12.1 host 172.16.4.34 Router4(config)#access-list 150 permit ip host 172.16.4.34 host 172.16.12.1
[Results]:
Jan 20 16:53:16.527: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.531: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.627: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.635: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.727: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.731: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.823: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.827: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.919: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.923: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending
debugコマンドの影響を小さくするもう1つの方法は、デバッグメッセージをバッファに入れ、デバッグがオフになったらshow logコマンドで表示することです。
Router4#configure terminal Router4(config)#no logging console Router4(config)#logging buffered 5000 Router4(config)#^Z Router4#debug ip packet IP packet debugging is on Router4#ping 172.16.12.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.12.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/37 ms Router4#undebug all All possible debugging has been turned off Router4#show log Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) Console logging: disabled Monitor logging: level debugging, 0 messages logged Buffer logging: level debugging, 61 messages logged Trap logging: level informational, 59 message lines logged Log Buffer (5000 bytes): Jan 20 16:55:46.587: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:55:46.679: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3
pingおよびtracerouteコマンドは、ネットワークアクセスの問題のトラブルシューティングに使用できる便利なユーティリティです。使い方は非常に簡単です。これらの2つのコマンドは、ネットワークエンジニアによって広く使用されています。
改定 | 発行日 | コメント |
---|---|---|
2.0 |
04-Oct-2022 |
再認定 |
1.0 |
10-Dec-2001 |
初版 |