デバイス間のパケット損失のトラブルシューティング

パケット損失とは、1 台のネットワーク デバイスから別のデバイスに送信されたデータの一部が届かない事象を指します。これはさまざまな理由で発生します。トラブ ルシューティングの際にまず行うべきことは、損失が発生している場所を特定することです。たいていの OS では、これを行うのに ping および  traceroute または tracert ツールが役立ちます。この記事では、8.8.8.8 に到達しようとした際に Windows PC でパケット損失が発生 したサンプル ケースを取りあげ、順を追って説明します。

ルーテッド リンク上で発生したパケット損失の場所の特定

パケット損失が発生したかどうかを確認するには以下の手順に従います。

1. [スタート（Start）] メニューで「cmd」を検索して、クライアント PC のコマンド プロンプトを開きます。
2. 「ping -n 20 8.8.8.8」と入力します。
   これはアドレス 8.8.8.8 に ping を 20 回送信します。「8.8.8.8」を、テストする必要がある実際のアドレスに置き換えてください。
3. コマンドが実行されると、損失が発生したかどうかを示すサマリが表示されます。
   
4. 損失が発生しない場合は、「-n」の値を大きくし（100 など）、テスト回数を増やしてください。

注：これは、ICMP またはすべてのトラフィックに影響を与えるパケット損失のみをテストします。プロトコル固有の損失は検知できない可能性があります。

パケット損失が確認された場合、次の手順は、パケット損失が発生した場所を特定することです。「tracert」を使用して、宛先までのパスにある各レイヤ 3 デバイスを確 認できます。

1. [スタート（Start）] メニューで「cmd」を検索して、クライアント PC のコマンド プロンプトを開きます。
2. 「tracert -d 8.8.8.8」と入力します。
   これは 8.8.8.8 へのルートを追跡し、宛先までの途中の各ホップをIPアドレスで表示します。「8.8.8.8」を、テストする必要がある実際のアドレスに置き換えてください。
3. トレースが完了するのを待ちます。「要求がタイムアウトしました（Request timed out）」で終了する行が複数発生した場合は CTRL+C を押します。

応答がない場合はアスタリスク（*）で表されます。パケット損失が発生したか、またはデバイスが ICMP に応答しないように設定されている可能性を意味します。場合によ っては、損失発生場所を特定するためにテストを複数回実行する必要があります。特定のホップの後にパケット損失が頻繁に発生する場合、その問題は該当デバイス、または 該当デバイスと前のホップとの間で発生している可能性が最も高いと言えます。次のスクリーンショットは、パケット損失がない tracert の結果を示しています。応答しない デバイス（ホップ 11）は、その後にパケット損失が発生していないため、応答しないように設定されているようです。

次のスクリーンショットでは、ホップ 2 からパケット損失が定期的に発生しています。これは、ISP ゲートウェイ、またはクライアント ゲートウェイと ISP ゲートウェイの間のリンクに問題がある可能性があることを示しています。テストを実行する際は、ネットワーク内の異なる場所にある複数のクライア ントから行うことをお勧めします。そうすることでクライアント固有の問題を排除し、問題が発生しているクライアントの共通点を把握できます。

より詳細なテストとして、MTR ツールを使用して一連 のトレースを実行し、パスの各ホップにおける損失の割合を提示できます。これにより、損失が発生している場所をより明確に識別できます。上記シナリオの出力は、以下の ようになります。

ワイヤレス/スイッチ ネットワークにおけるパケット損失発生場所の特定

tracert は、パスにおけるレイヤ 3 デバイス（ルータなど）の情報のみを提供します。ただし、パケット損失が最初のホップで発生していて、そこに到達するためにワイ ヤレス アクセス ポイントとスイッチを通過する必要がある場合、その問題箇所を特定するには、追加のテストが必要になります。この場合、レイヤ 3 デバイスに徐々に近づきな がら、テストを複数回実行する必要があります。以下の手順を、下の図に示します。

1. アクセス ポイントに ping を送信してワイヤレス品質をテストします。Cisco Meraki AP を使用している場合、my.meraki.com に ping を実行します。
   ここで損失が発生し始める場合、ナレッジ ベースの記事「ワイヤレスのパフォーマンスに関するトラブルシューティング」[英語] を参照してください。
2. ワイヤレス クライアントが接続されているスイッチで、同じ VLAN（設定されている場合）に接続されているクライアントに ping を送信します。パス上に複数のス イッチが存在する場合は、必要に応じてこの手順を繰り返します。
   ここで損失が発生し始めている場合、次のような問題がある可能性があります。
   - AP とスイッチ間、またはスイッチと有線クライアント間のリンクにおけるデュプレックス/速度設定が一致していない
   - AP とスイッチ、またはスイッチと有線クライアント間のケーブルに不具合がある
3. ワイヤレス クライアントと同じ VLAN 上のルータ/ファイアウォールに直接クライアントを接続し、ワイヤレス クライアントからそのクライアントに ping を送信します。
   ここで損失が発生し始めている場合、次のような問題がある可能性があります。
   - スイッチとルータ/ファイアウォール間、またはルータ/ファイアウォールと有線クライアント間のリンクにおけるデュプレックス/速度設定が一致していない
   - AP とスイッチ、またはルータ/ファイアウォールと有線クライアント間のケーブルに不具合がある

Cisco Meraki デバイスをテストする場合、パスの最初の MS スイッチを switch.meraki.com として、MX セキュリティ アプライアンスを wired.meraki.com として ping を送信することもできます。

パケット損失の一般的な原因

パケット損失を引き起こす潜在的な原因はたくさんあります。この記事では、一般的な理由をいくつか挙げ、その対処方法について説明します。

デュプレックス ミスマッチ

これは、リンクの両端が異なる速度/デュプレックスの設定（たとえば、100 Mbps/ハーフデュプレックスと 1000 Mbps/フルデュプレックス）を使用しているときに発生し ます。このエラーが発生すると、一部またはすべてのトラフィックがリンク上で失われます。これを修正するには、リンクの両側の設定を同じにします。接続の両端の速度と デュプレックスを [自動（Auto）] に設定することを推奨します。一端の速度またはデュプレックスの設定を手動で設定する場合は、もう一端も同じ値に設定されていることを確認します。

リンクの輻輳（トラフィックが多すぎる）

これは、サポートされている容量よりも多くのトラフィックが、ネットワーク リンクを通過しようとするときに発生します。たとえば、20 Mbps のリンクを 60 Mbps のトラフィックが通過しようとする場合です。これにより、ボトルネックが生じ、い くつかのトラフィックがドロップされてしまいます。 

以下のように、この問題を解決する方法はいくつかあります。

• すべてのトラフィックを処理できるように、許容量を超えているリンクの容量を増やします。
• MX セキュリティ アプライアンスまたは MR アクセス ポイントにトラフィック シェーピング ルールを適用し、トラフィック量を制限します。望ましくないトラフィックを中心に減らします。
• MX セキュリティ アプライアンスまたは MR アクセス ポイントにトラフィック シェーピング ルールを適用し、より重要なトラフィックを優先させます。

ファイアウォールが特定のトラフィックをブロックする

パケット損失が発生しているトラフィック の種類が限定される場合は、上流のファイアウォールで特定のトラフィックがフィルタリングされている可能性はあります。これにより、あるWeb サイトはアクセスできる が、他のサイトはできないといった状況やアクセスできるサービスが限定されるといった状況が生じる可能性があります。これらの症状が見られる 2 台のデバイス（または 2 か所）間にファイアウォールが存在している場合、問題が発生しているトラフィックが、ファイアウォールによってブロックされていないか確認します。

ケーブル不良または接触不良

終端処理が不十分または不適切なケーブルや、破損したケーブルは、デバイス間で不完全または不正確な電気信号を伝送する可能性があります。疑わしいケーブルを新しい ケーブルと交換するか、ケーブル テストを実行することで問題を解決したり検知できる可能性があります。ポートに完全に装着されていないケーブルや、粉塵などの非導電性の破片がピンに堆積しているケ ーブルでも同様の問題が生じる可能性があります。すべてのポートにほこりやその他の蓄積物が溜まらないようにし、ケーブルがしっかりと接続されていることを確認してく ださい。