Direct Connect のネットワークパフォーマンスに関する問題をトラブルシューティングするにはどうすればよいですか?

最終更新日: 2021 年 11 月 30 日

AWS Direct Connect 接続で、低スループット、トラフィックレイテンシー、およびパフォーマンスの問題が発生しています。

解決方法

ネットワークとアプリケーションのパフォーマンスの問題を特定して診断するには、次の手順を実行します。

注: オンプレミスの専用テストマシンと Amazon Virtual Private Cloud (Amazon VPC) を設定するのがベストプラクティスです。C5 以上のサイズの Elastic Compute Cloud (Amazon EC2) インスタンスタイプを使用します。

ネットワークまたはアプリケーションの問題

iPerf3 ツールをインストールして使用すると、ネットワーク帯域幅のベンチマークを実行し、結果を他のアプリケーションやツールと照合できます。

1.    Linux/REHEL のインストール:

$ sudo yum install iperf3 -y

Ubuntu のインストール:

$ sudo apt install iperf3 -y

2.    クライアントとサーバーで iPerf3 を実行して、次のように、スループットを双方向に測定します。

Amazon EC2 インスタンス (サーバー):

$ iperf3 -s -V

オンプレミスの localhost (クライアント):

$ iperf3 -c <private IP of EC2> -P 15 -t 15
$ iperf3 -c <private IP of EC2> -P 15 -t 15 -R

$ iperf3 -c <private IP of EC2> -w 256K
$ iperf3 -c <private IP of EC2> -w 256K -R

$ iperf3 -c <private IP of EC2> -u -b 1G -t 15
$ iperf3 -c <private IP of EC2> -u -b 1G -t 15 -R 

----------------
-P, --parallel n
    number of parallel client threads to run; It is critical to run multi-threads to achieve the max throughput.
-R, --reverse
    reverse the direction of a test. So the EC2 server sends data to the on-prem client to measure AWS -> on-prem throughput.
-u, --udp
    use UDP rather than TCP. Since TCP iperf3 does not report loss, UDP tests are helpful to see the packet loss along a path.

TCP テスト結果の例:

[ ID] Interval          Transfer      Bitrate        Retry
[SUM] 0.00-15.00  sec  7.54 GBytes  4.32 Gbits/sec   18112   sender
[SUM] 0.00-15.00  sec  7.52 GBytes  4.31 Gbits/sec           receiver

Bitrate (ビットレート) – 測定されたスループットまたは伝送速度。

Transfer (転送) – クライアントとサーバー間で交換されるデータの総量。

Retry (再試行) – 再送信されたパケットの数。再送信は送信側で観察されます。

UDP テスト結果の例:

[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5] 0.00-15.00  sec  8.22 GBytes   4.71 Gbits/sec  0.000 ms   0/986756 (0%)  sender
[  5] 0.00-15.00  sec  1.73 GBytes   989 Mbits/sec   0.106 ms   779454/986689 (79%)  receiver

最大量の UDP データグラムが送信されるため、送信側では [Lost] (損失) は 0% です。

受信側の [Lost] (損失)/[Total] (合計) データグラムは、失われたパケット数と損失率を示します。この例では、ネットワークトラフィックの 79% が失われています。

注: Direct Connect 接続がパブリック仮想インターフェイス (VIF) 経由で Amazon Virtual Private Network (Amazon VPN) を使用する場合は、VPN なしでパフォーマンステストを実行します。

メトリクスおよびインターフェイスカウンターを確認する

Amazon CloudWatch Logs で次のメトリクスを確認します。

  • ConnectionErrorCount: sum 統計を適用します。ゼロ以外の値は AWS デバイス上の MAC レベルのエラーを示していることに注意してください。
  • ConnectionLightLevelTx および ConnectionLightLevelRx: 光信号の読み取り値が確実に -14.4~2.50 dBm の範囲内にあるようにします。
  • ConnectionBpsEgress、ConnectionBpsIngress、VirtualInterfaceBpsEgress、および VirtualInterfaceBpsIngress: ビットレートが最大帯域幅に達していないことを確認します。

詳細については、Direct Connect のメトリクスとディメンションを参照してください。

総帯域幅を他のユーザーと共有する Hosted Virtual Interface (Hosted VIF) を使用している場合は、接続使用率について Direct Connect の所有者に確認します。

次の点について Direct Connect の場所にあるルーターとファイアウォールを確認します。

  • CPU、メモリ、ポート使用率、ドロップ、破棄。
  • 「show interfaces statistics」などを使用して、CRC、フレーム、コリジョン、キャリアなどのインターフェイスの入出力エラーをチェックします。
  • カウンターが劣化している場合は、ファイバーパッチリードと SFP モジュールをクリーニングまたは交換します。

AWS Personal Health Dashboard で Direct Connect 接続がメンテナンス中でないことを確認します。

MTR を双方向に実行してネットワークパスを確認する

Linux MTR コマンドを使用して、ネットワークパフォーマンスを分析できます。Windows OS については、Linux サブシステムに MTR をインストールできるように WSL 2 を有効にするのがベストプラクティスです。WinMTR は SourceForge のウェブサイトからダウンロードできます。

1.    Amazon Linux/REHEL のインストール:

$ sudo yum install mtr -y

Ubuntu のインストール:

$ sudo apt install mtr -y

2.    オンプレミス --> AWS の方向については、localhost (ICMP および TCP ベース) で MTR を実行します。

$ mtr -n -c 100 <private IP of EC2> --report
$ mtr -n -T -P <EC2 instance open TCP port> -c 100 <private IP of EC2> --report

3.    AWS --> オンプレミスの方向については、EC2 インスタンス (ICMP および TCP ベース) で MTR を実行します。

$ mtr -n -c 100 <private IP of the local host> --report
$ mtr -n -T -P <local host open TCP port> -c 100 <private IP of the local host> --report

MTR テスト結果の例:

#ICMP based MTR results
$ mtr -n -c 100 192.168.52.10 --report
Start: Sat Oct 30 20:54:39 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.7   0.7   0.6   0.9   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  266.5 267.4 266.4 321.0   4.8
  4.|-- 10.110.120.1              54.5%   100  357.6 383.0 353.4 423.7  19.6
  5.|-- 192.168.52.10             47.5%   100  359.4 381.3 352.4 427.9  20.6

#TCP based MTR results
$ mtr -n -T -P 80 -c 100 192.168.52.10 --report
Start: Sat Oct 30 21:03:48 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.9   0.7   0.7   1.1   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  264.1 265.8 263.9 295.3   3.4
  4.|-- 10.110.120.1               8.0%   100  374.3 905.3 354.4 7428. 1210.6
  5.|-- 192.168.52.10             12.0%   100  400.9 1139. 400.4 7624. 1384.3

ホップの各行は、データパケットがソースから宛先に渡すネットワークデバイスを表します。MTR テスト結果の読み方の詳細については、ExaVault のウェブサイトにアクセスしてください。

BGP ピア 10.110.120.1 および 10.110.120.2 との Direct Connect 接続の例を次に示します。損失率は、4 番目と 5 番目の宛先ホップで観察できます。これは、Direct Connect 接続またはリモートルーター 10.110.120.1 に問題があることを示している可能性があります。Direct Connect 接続では ICMP よりも TCP が優先されるため、TCP MTR の結果の損失率は低くなります。

#ICMP based MTR results
$ mtr -n -c 100 192.168.52.10 --report
Start: Sat Oct 30 20:54:39 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.7   0.7   0.6   0.9   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  266.5 267.4 266.4 321.0   4.8
  4.|-- 10.110.120.1              54.5%   100  357.6 383.0 353.4 423.7  19.6
  5.|-- 192.168.52.10             47.5%   100  359.4 381.3 352.4 427.9  20.6

#TCP based MTR results
$ mtr -n -T -P 80 -c 100 192.168.52.10 --report
Start: Sat Oct 30 21:03:48 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.9   0.7   0.7   1.1   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  264.1 265.8 263.9 295.3   3.4
  4.|-- 10.110.120.1               8.0%   100  374.3 905.3 354.4 7428. 1210.6
  5.|-- 192.168.52.10             12.0%   100  400.9 1139. 400.4 7624. 1384.3

ローカルファイアウォールまたは NAT デバイスのパケット損失率が 5% である例を次に示します。パケットの損失は、宛先を含むすべての後続のホップに影響します。

$ mtr -n -c 100 192.168.52.10 --report
Start: Sat Oct 30 21:11:22 2021
HOST:                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               5.0%   100    0.8   0.7   0.7   1.1   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               6.0%   100  265.7 267.1 265.6 307.8   5.1
  4.|-- 10.110.120.1               6.0%   100  265.1 265.2 265.0 265.4   0.0
  5.|-- 192.168.52.10              6.0%   100  266.7 266.6 266.5 267.2   0.0

パケットキャプチャを取得して結果を分析する

localhost と EC2 インスタンスでパケットキャプチャを取得します。tcpdump または Wireshark ユーティリティを使用して、分析のためにネットワークトラフィックを取得します。次の tcpdump コマンド例では、タイムスタンプとホスト IP アドレスを取得します。

tcpdump -i <network interface> -s0 -w $(date +"%Y%m%d_%H%M%S").$(hostname -s).pcap port <port>

Switch ウェブサイトの TCP スループット計算ツールを使用して、ネットワーク制限、帯域幅遅延積、および TCP バッファサイズを計算します。

詳細については、AWS Direct Connect のトラブルシューティングを参照してください。


この記事はお役に立ちましたか?


請求に関するサポートまたは技術サポートが必要ですか?