如何對 Direct Connect 網路效能問題進行疑難排解？
我使用 AWS Direct Connect 連線時遇到輸送量低、流量延遲和效能問題。
解決方法
若要隔離並診斷網路和應用程式效能問題，請完成下列步驟：
**注意：**使用 Amazon Virtual Private Cloud (Amazon VPC) 設定內部部署專用測試機器是最佳做法。使用大小為 C5 或更大的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體類型。
檢閱網路或應用程式問題
安裝並使用 iPerf3 工具來測試網路頻寬基準，並與其他應用程式或工具交叉檢查結果。如需詳細資訊，請參閱 iPerf 網站上的什麼是 iPerf/iPerf3？
-
執行下列命令安裝 iPerf3：
Linux/REHEL
$ sudo yum install iperf3 -yUbuntu
$ sudo apt install iperf3 -y -
若要雙向測量輸送量，請在用戶端上執行 iPerf3：
Amazon EC2 執行個體 (伺服器)
$ iperf3 -s -V**內部部署本地主機 (用戶端) **
$ 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
上面的範例使用下列術語：
- **比特率：**測量的輸送量或傳輸速度。
- **傳輸：**用戶端與服務器之間交換的資料總量。
- **重試：**重新傳輸的封包數量。傳送端觀察到重新傳輸。
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
傳送端的遺失為 0%，因為傳送的 UDP 資料報已達數量上限。接收端的遺失/資料報總數表示有多少封包遺失以及遺失率。在此範例中，79% 的網路流量遺失。
**注意：**如 Direct Connect 連線透過公用虛擬介面 (VIF) 使用 Amazon Virtual Private Network (Amazon VPN)，則在沒有 VPN 的情況下執行效能測試。
檢查指標和介面計數器
檢查 Amazon CloudWatch Logs 中的下列指標：
- **ConnectionErrorCount：**套用總和統計值。請注意，非零值表示 AWS 裝置中的 MAC 層級錯誤。
- ConnectionLightLevelTx 和 ConnectionLightLevelRx： 光學訊號讀數必須在 -14.4 和 2.50 dBm 範圍內。
- ConnectionBpsEgress、ConnectionBpsIngress、VirtualInterfaceBpsEgress 和 VirtualInterfaceBpsIngress： 確保比特率未達到最大頻寬。
如需詳細資訊，請參閱 AWS Direct Connect 指標和維度。
如果您使用與其他使用者共用總頻寬的託管 VIF，請向 Direct Connect 擁有者查詢連線使用率。
檢查 Direct Connect 位置的路由器和防火牆的下列指標：
- CPU、記憶體、連接埠使用率、掉包數、丟棄數
- 使用 show interfaces statistics 或類似的命令來檢查介面輸入和輸出錯誤，如 CRC 錯誤、訊框錯誤、衝突以及載波問題
- 清潔或更換因磨損而計數器異常的光纖跳線和 SFP 模組
檢查 AWS Health 儀板表，確定 Direct Connect 未在維護中。
雙向執行 MTR 以檢查網路路徑
使用 Linux MTR 命令分析網路效能。對於 Windows 作業系統，最佳做法是開啟 WSL 2，以便在 Linux 子系統上安裝 MTR。從 SourceForge 網站下載 WinMTR。
-
執行下列命令以安裝 MTR：
Amazon Linux/REHEL installation
$ sudo yum install mtr -yUbuntu installation
$ sudo apt install mtr -y -
對於內部部署到 AWS 的方向，在本地主機上執行 MTR (ICMP 型和 TCP 型)：
$ 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 -
對於 AWS 到內部部署的方向，請在 EC2 執行個體上執行 MTR (ICMP 型和 TCP 型)：
$ 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 網站上的讀取 MTR 輸出網路診斷工具。
下列範例所示為與 BGP 對等裝置 10.110.120.1 以及 10.110.120.2 的 Direct Connect 連線。在第 4 和第 5 個目的地跳躍上觀察到遺失百分比。這可能表示 Direct Connect 連線或遠端路由器 10.110.120.1 有問題。由於使用 Direct Connect 連線的 TCP 優先順序優先於 ICMP，因此 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
擷取封包並分析結果
在本地主機和 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 進行疑難排解。
相關資訊
相關內容
- 已提問 1 年前
- 已提問 4 個月前
- 已提問 2 年前
- AWS 官方已更新 1 年前
- AWS 官方已更新 1 年前
- AWS 官方已更新 1 年前
- AWS 官方已更新 1 年前
