デバイス間のパケット損失のトラブルシューティング
概要
パケット損失とは、1台のネットワーク デバイスから別のネットワーク デバイスに送信されたデータの一部が届かない事象を指します。これはさまざまな理由でします。パケット損失のトラブルシューティング時にまず行うべきことは、損失が発生している場所を隔離することです。
パケット損失の特定
PCの場合
パケット損失が発生しているかどうかを確認するには、以下の手順を実行します。
- 「スタート」メニューで「cmd」を検索して、クライアントPCのコマンド プロンプトを開きます。
- pingコマンドを使用します。
ping -n 20 8.8.8.8
これは、アドレス8.8.8.8にpingを20回送信します。8.8.8.8を、テストする必要があるアドレスに置き換えてください。
- コマンドが実行されると、損失が発生したかどうかを示すサマリーが表示されます。
- 損失が発生しない場合は、「-n」の値を大きくし（100など）、テスト回数を増やしてください。
注記：これは、ICMPまたはすべてのトラフィックに影響を与えるパケット損失のみをテストします。プロトコル固有の損失は反映されない場合があります。
ダッシュボードを使用する場合
ダッシュボードには、特定のIPアドレスへの接続を監視するのに効果的なツールがあります。ICMP pingが絶え間なく、MX WANからそれぞれのIPに送信されます。
このツールは、Security & SD-WAN（セキュリティ& SD-WAN） > Appliance Status（セキュリティ アプライアンス） > Uplink（アップリンク）の下に表示されます
「Historical data（過去のデータ）」データの下のパケット損失のセクションは、8.8.8.8にpingを送信しているときにICMPパケットの損失が発生しているかどうかを示します。
宛先IPアドレスは、Security & SD WAN（セキュリティ&SD-WAN）> SD-WAN & traffic shaping（SD-WAN &トラフィック シェーピング）> Uplink statistics（アップリンクの統計）で設定できます。
ルーテッド リンク上で発生したパケット損失の場所の特定
パケット損失が確認された場合、次の手順は、パケット損失が発生し始める場所を特定することです。「tracert」を使用して、宛先までのパスに沿って各レイヤー3デバイスを確認できます。
- 「スタート」メニューで「cmd」を検索して、クライアントPCのコマンド プロンプトを開きます
- pingコマンドを使用します
tracert -d 8.8.8.8
これは8.8.8.8へのルートを追跡し、途中の各ホップをIPアドレスで表示します。8.8.8.8を、テストする必要があるアドレスに置き換えてください。
- トレースが完了するのを待ちます。「Request timed out」で終了する行が複数表示された場合は、CTRL/CMD+Cキーを押します。
応答がない場合はアスタリスク（*）で表されます。これはパケット損失が発生しているか、またはデバイスが応答しないように設定されている可能性を意味します。場合によっては、損失発生場所を特定するためにテストを複数回実行する必要があります。特定のホップの後にパケット損失が頻繁に発生する場合は、その問題は当該デバイス、または当該デバイスと前のホップの間で発生している可能性が高いと言えます。次のスクリーンショットは、パケット損失がないtracertの結果を示しています。応答していない唯一のデバイス（ホップ11）は、その後にパケット損失が発生していないため、応答しないように設定されているようです。
次のスクリーンショットでは、ホップ2からパケット損失が定期的に発生しています。これは、ISPゲートウェイ、またはクライアント ゲートウェイとISPゲートウェイの間のリンクに問題がある可能性があることを示しています。テストを実行する際は、ネットワーク内の異なる場所にある複数のクライアントから行うことをお勧めします。そうすることで特定のクライアントの問題を排除し、問題が発生しているクライアントの共通点を把握できます。
堅牢性の追加テストとして、MTRツールを使用して一連のトレースを実行し、パス内の各ホップにおける損失の割合を表示できます。これにより、損失の発生場所をより明確に特定できます。上記シナリオの出力は、次のようになります。
WANアップリンクでのパケット損失の特定
WANアップリンクでパケット損失が確認された場合、次の手順は、損失がMX側か、ISP側かを特定することです。
LANとMXセキュリティ アプライアンスのインターネット インターフェースで「」パケット キャプチャを撮ることで、損失が生じているインターフェースを特定できます。
- PCからパブリックIPアドレスに定期的にpingを実行します
- LANとセキュリティ アプライアンスのWANで同時にパケット キャプチャを撮ります
- 送信元と宛先のIPアドレスとICMPを持つトラフィックをフィルタします
- ICMPリクエストがLANからMXのWANに適切に転送されていることを確認します
- LANからWANにトラフィックが適切に転送されている場合 – MXは問題の原因ではない可能性が高いため、ISP側でパケット損失をさらにトラブルシュートする必要があります
ワイヤレス/スイッチド ネットワークでのパケット損失の発生場所の特定
tracertは、パス内のレイヤー3デバイス（ルータなど）の情報のみを提供します。ただし、第1ホップでパケット損失が発生しており、そこに到達するためにワイヤレス アクセス ポイントとスイッチを経由する必要がある場合は、問題を切り離すために追加のテストが必要です。この場合、レイヤー3デバイスに徐々に近づいていく間、テストを複数回実行する必要があります。以下の画像は、次の手順を示しています。
- アクセス ポイントにpingを送信して、ワイヤレスの品質をテストします。Cisco Meraki APを使用している場合は、my.meraki.comにpingを送信します。
ここで損失が発生し始める場合は、ナレッジ ベースでワイヤレス パフォーマンスのトラブルシューティングに関する記事を参照してください。 - ワイヤレス クライアントが接続されているスイッチで、同じVLAN（設定されている場合）に接続されているクライアントにpingを送信します。パス上に複数のスイッチが存在する場合は、必要に応じてこの手順を繰り返します。
ここで損失が発生し始めている場合は、次のような問題が存在する可能性があります。
- APとスイッチ間、またはスイッチと有線クライアント間のリンクでデュプレックス/速度設定が一致していない
- APとスイッチ間、またはスイッチと有線クライアント間のケーブルに不具合がある - クライアントを、ワイヤレス クライアントと同じVLAN上のルータ/ファイアウォールに直接接続して、ワイヤレス クライアントからそのクライアントにpingを送信します。
ここで損失が発生し始めている場合は、次のような問題が存在する可能性があります。
- スイッチとルータ/ファイアウォール間、またはルータ/ファイアウォールと有線クライアント間のリンクでデュプレックス/速度設定が一致していない
- APとスイッチ間、またはルータ/ファイアウォールと有線クライアント間のケーブルに不具合がある
Cisco Merakiデバイスをテストする場合は、パス内の最初のMSスイッチまたはMXセキュリティ アプライアンスにpingを送信することもできます。スイッチの場合はswitch.meraki.com、MXセキュリティ アプライアンスの場合はwired.meraki.comに移動すると、IPアドレスが見つかります。
パケット損失の一般的な原因
パケット損失を引き起こす潜在的原因は数多くあります。このセクションでは、パケット損失が発生する一般的な理由をいくつか挙げ、その対処方法について説明します。
デュプレックスの不一致
これは、リンクの両端が異なる速度/デュプレックス設定（たとえば、一方が100Mbps/半二重で、もう一方が1000Mbps/全二重）を使用している場合に発生します。このような場合、リンク上の一部またはすべてのトラフィックが失われます。
これを修正するには、リンクの両側を同じ設定にします。理想的には、接続の両端で速度とデュプレックスの両方を「Auto（自動）」に設定ことを推奨します。一端の速度またはデュプレックスの設定を手動で設定する必要がある場合は、もう一端も同じ値に設定されていることを確認してください。
リンクの輻輳（トラフィックが多すぎる）
これは、サポートされている容量よりも多くのトラフィックが、ネットワーク リンクを通過しようとするときに発生します。たとえば、20Mbpsのリンクを60Mbpsのトラフィックが通過しようとする場合などです。これにより、ボトルネックが生じ、一部のトラフィックがドロップされてしまいます。
以下のように、この問題の解決する方法はいくつかあります。
- すべてのトラフィックを処理できるように、許容量を超えているリンクの容量を増やします。
- MXセキュリティ アプライアンスまたはMRアクセス ポイントにトラフィック シェービング ルールを適用し、トラフィック量を制限します。望ましくないトラフィックを中心に減らします。
- MXセキュリティ アプライアンスまたはMRアクセス ポイントにトラフィック シェーピング ルールを適用し、より重要なトラフィックを優先させます。
ファイアウォールが特定のトラフィックをブロックする
パケット損失が発生しているトラフィックの種類が限定される場合は、上流のファイアウォールで特定のトラフィックがフィルタリングされている可能性があります。これにより、一部のWebサイトは読み込めるが、他は読み込めないといった状況や、アクセスできるサービスが限定されるといった状況が生じる可能性があります。
このような症状が見られる2台のデバイス（または2か所）間にファイアウォールが存在する場合は、問題が発生しているトラフィックが、ファイアウォールによってブロックされていないか確認します。
ケーブル不良または接触不良
終端処理が不十分または不適切なケーブルや、破損したケーブルは、デバイス間で不完全または不正確な電気信号を伝送する可能性があります。
疑わしいケーブルを新しいケーブルと交換するか、ケーブル テストを実行することで、問題の原因を取り除くことができる可能性があります。同様に、ポートに正しく装着されていないケーブルや、粉塵などの非導電性の破片がピンに堆積しているケーブルでも同様の問題が生じる可能性があります。すべてのポートにほこりやその他の堆積物が溜まらないようにし、ケーブルがしっかりと接続されていることを確認してください。