コンテンツにスキップ

スループットと速度のトラブルシューティング

送信中のトラフィックと受信予定のトラフィックに異常がある場合、ネットワークのスループットや速度に問題が生じている可能性があります。以下のトラブルシューティングの手順に従って、原因を特定することをお勧めします。

トラブルシューティング

アクション ステップ
デバイスのインターフェイス、CRC エラー、パケット ドロップを確認する インターフェイスの統計情報やログは、構内配線のどちら側に障害が発生しているかを特定し、その解決策を探るのに役立ちます。例えば、あるネットワーク インターフェイスで受信エラーが増加すると、一般的に特定の SFP は除外され、構内配線の他のコンポーネントに問題がある可能性を示します。
デバイスの Tx および Rx 光量を確認する 送信 (Tx) および受信 (Rx) の光量を確認します。このヘルス チェックでは、物理的な接続を確認することができます。考慮事項:
  • Rx の光が受信されない場合、サービスはダウンしています。
  • Tx および Rx の光量の低下が観察された場合、サービスが中断される可能性があります。Megaport では、物理的な接続を確認することをお勧めします。
  • Megaport との間で光の送信 (Tx) と受信 (Rx) ができない場合、以下の原因が考えられます。
    • ファイバーの極性の問題 – お客様の側でファイバーを巻いて確認します。
    • 環境内または構内配線での接続の問題 – 環境内で物理的なループバック テストを実施して確認します。
    • Megaport 環境内の接続の問題 – お客様の環境から Megaport に向けて物理的なループバック テストを実施して確認します。
データ センターとの物理的な接続を確認する (SFP の再装着と交換、ケーブルの清掃と交換、ループバック テスト) データ センターとのチケットを開きます:
  1. 構内配線に損傷がないか確認し、必要に応じてクリーニングを行います。
  2. データ センターが、接続の端にある責任分界点の外側で十分な光を送信しているか確認します。データ センターでは、検光器を使って責任分界点の光を確認する必要があります。
通信事業者回線のステータスを確認する (ある場合) 一部の構内配線は、Megaport ネットワークに到達する前に、1 つまたは複数の通信事業者のネットワーク デバイスを経由して設定されています。構内配線パスのデバイス インターフェイスにエラーがなく、送信および受信の光量が正しく機能していることを確認します。
機器の性能を確認する トラブルシューティングの際、Megaport にはそのネットワーク外での可視性やアクセス権はありません。問題の原因が Megaport ネットワーク内にあることを確認するため、Megaport サポートではお使いの機器の性能確認をお願いしています。これには、ハードウェアの仕様と制限が Megaport の 技術仕様と互換性があることを確認し、ネットワーク トラフィックとハードウェアの作業負荷を監視して、混雑やパフォーマンスの低下を回避することが含まれます。ハードウェアやネットワークが期待通りに動作していることを確認するために、以下の性能を確認することをお勧めします。
    ハードウェア
  • 光 (SFP タイプ、速度、波長) およびファイバー タイプ
  • ポート容量
  • スイッチ、ルーター、およびファイアウォールのモデル
  • ファームウェア バージョン
    ネットワーク
  • トラフィック フロー
  • ポート使用率
  • CPU 使用率
  • 構成
  • ネットワーク全体の設計
異常が確認された場合は、ログ、グラフの詳細、または関連するエラー メッセージをキャプチャします。
症状を特定するために traceroute などのテストを実施する traceroute テストは、宛先が到達可能かどうかを判断するのに役立ちます。traceroute は、2 点間で一連の UDP (User Datagram Protocol) パケットを送信し、パケットが通る経路を示します。traceroute は、IP ネットワーク上のパケットの通過遅延を測定することもできます。

エンドツーエンドの traceroute テストを実施する
  • トラフィックを発信しているホスト (A エンド) から宛先ホスト (B エンド) に向けて traceroute を開始します。次に、宛先ホストから発信ホストへの traceroute を実行します。コマンドやフラグはデバイスによって異なる場合があります。
結果を分析する
  • 非対称ルーティングの可能性を調べます。traceroute の結果が同じパスを通っていない場合、traceroute を使用すると、ネットワークのどこに非対称なルーティングがあるかを特定するのに役立ちます。
  • traceroute で応答時間が大幅に増加した箇所はありますか?その場合、それらの遅延はネットワーク内にありますか?
    トラフィックが宛先に到達するのを禁止するファイアウォールやアクセス リストのルールはありますか?
スループット テストを実施する iPerf は、標準化されたパフォーマンス測定値を作成し、ネットワークを調整するために使用されるクロスプラットフォームのツールです。iPerf にはクライアントとサーバーの両方の機能があり、データ ストリームを作成して、片方向または両方向の 2 つのエンド間のスループットを測定することができます。

テストを実施する
Megaport では、各サイド (A エンドのクライアントと B エンドのサーバー、次に B エンドのクライアントと A エンドのサーバー) で 15 分のテストを合計 30 分行い、各テストの間に約 10~15 分の時間を置くことをお勧めします。このテストは UDP を使用して実行する必要があります。以下は、A エンドまたは B エンドで実行するコマンドの例です。

iperf3 -c <IP address> -b1000m -t 900 -u

注意: UDP ストリームは、TCP ネゴシエーション、輻輳回避、ウィンドウウィングのオーバーヘッドなしに、接続の両端間のスループットを測定するために使用する必要があります。

結果を分析する
  • 非対称ルーティングの可能性を調べます。traceroute は、traceroute の結果が異なるパスを通っているかどうかを特定するのに役立ちます。同じパスを通っていない場合、ネットワークのどこかに非対称なルーティングがある可能性があることを示します。
  • traceroute で応答時間が顕著に増加した箇所はありますか?その場合、それらの遅延はネットワーク内にありますか?
  • テスト終了後、インターフェイスの統計情報と次のスクリーンショットを提出してください。
    • トラフィックのグラフ (可能な場合)
    • Megaport に最も近いネットワーク上のイングレス/エグレス ポイント
    • B エンドのイングレス/エグレスのトラフィックのグラフ (可能な場合)
  • グラフが関連するネットワーク図上のデバイス、ポート、VLAN を特定します。

次のステップ

トラブルシューティングを行っても問題が解決しない場合は、サポートにお問い合わせください。サポートを依頼する前に、以下の情報を収集してください。

  • トラブルシューティングの結果 – 実施したすべてのトラブルシューティングの手順に関する詳細を提出します。例えば、ループが設置されている場合は、その位置と向きを記録します。
  • 送信元 IP アドレスと宛先 IP アドレス – 送信元 IP アドレスは、パケットを送信したホストの IP アドレスです。宛先 IP アドレスは、そのパケットを受信することになっているホストの IP アドレスです。
  • ハイレベルのネットワーク図 – ネットワーク設計の実装方法と Megaport ネットワークへの接続方法を理解することで、トラブルシューティングのプロセスでさらに注力すべき領域を特定することができます。パスのすべてのデバイスを含むネットワーク図を作成し、各デバイスの関係する IP アドレスと VLAN を記入します。
  • ping テストの結果 – サービスで実施した各 ping テストの出力を提出します。異なるプロダクト (例:ポートや VXC) に関連する複数のサービスがある場合は、すべての出力テストを提出してください。
  • traceroute の結果 – 接続のどちら側でテストが開始され、どちら側が宛先であるかを示す traceroute の結果を提出します。VXC の A エンドと B エンドの情報を使用することをお勧めします。
  • iPerf (スループット) テストの結果 – 上記の手順に基づいたすべてのデータと、以下の質問に関連するすべての情報を提出します。
    • ネットワークでは、トラフィック シェーピングを使用していますか?
      Megaport に到達する前にトラフィックをシェーピング、ポリシング、フィルタリングしている場合、Megaport ネットワークでシェーピングされたイングレス トラフィックのみが表示されてしまうことがあります。顧客や販売店は、Megaport のネットワーク外で使用する機器が希望の速度をサポートできることを確認する必要があります。
    • 接続の B エンドに連絡して、相手側のパスに問題がないかどうか確認しましたか?
      該当する場合は、ケース番号を提出してください。Megaport のネットワーク インターフェイスからプロバイダーのインターフェイスにトラフィックが送り出されると、当社ではそのフローを制御できません。
    • 通信事業者など、他のプロバイダーが関与していませんか?ネットワークに通信事業者が関わっている場合、潜在的なルーティングの問題を調査するために、ケースを開きましたか?
      該当する場合は、ケース番号を提出してください。当社では、自社デバイスを介したフローのトラブルシューティングしかできませんので、お客様のネットワークと Megaport との間のトラフィック フローのルーティングに通信事業者を使用しているかどうかを確認することが重要です。例えば、当社のネットワークに到達する前の損失などに対する責任は負えません。
    • これが Azure 接続の場合、「Q-in-Q の構成」の説明に従って、Megaport Portal の Q-in-Q オプションを使用していますか?
      Q-in-Q を使った Azure は厄介です。トラフィックを適切に Megaport に送り、さらに Azure に送るためには、正しく構成しなければなりません。
  • パケット キャプチャ ログ (オプション) – パケット キャプチャ (または PCAP) ログは、ネットワーク トラフィックの収集、帯域幅の監視、マルウェアの検出、インシデント レスポンスの支援に役立ちます。問題に関連する場合は、ネットワークの理解を深めるために、パケット キャプチャ ログを提出してください。

最終更新日: 2022-02-03