ゲームラグ白書 › L4 インターネット回線
ECMP経路のうち1本の不良 ECMP / link bundle member fault
原因ID isp-ecmp · 主担当 インフラチーム・ネットワークインフラ · 副担当 ゲーム開発チーム・サーバー開発, 外部・外部
図と実験のあるメインページでこのカードを開く →
通信事業者やデータセンターは同じ宛先への経路を複数持ち、接続ごとに1本の経路を決めて送ります。1本の経路だけが故障すると、その経路に割り当てられた人だけにラグが出続けます。
なぜ 複数の回線を束ねた区間で、1本の回線や1台の機器が不良、または混雑 → すると アドレス・ポートの組み合わせ（ハッシュ）で経路が決まり、その経路に割り当てられた接続だけにパケットロス・遅延 → 画面では 同じ地域・同じ通信事業者なのに一部の人だけが継続的にワープ。再接続すると直ることもある
- 症状
- ワープ, 引き戻し, カクつき
- 要因
- パケットロス, ジッター
- 誰に起きるか
- 自分だけ, 特定の地域・ISP
- いつ
- 常に
- 担当
- 主担当 インフラチーム・ネットワークインフラ · 副担当 ゲーム開発チーム・サーバー開発, 外部・外部
- ゲーム開発チームの対応
- 接続ごとのパケットロス・再送の統計を残し、影響を受けている人のIP・ポートと時刻を抽出できるようにする（TCPはTCP_INFOの再送回数、UDPは抜けたパケットのシーケンス番号から計算）。
- インフラチームの対応
- 影響を受けている人のIP・ポートと時刻を集めて通信事業者・データセンターに伝える、経路ごとのパケットロス監視、経路の測定はゲームと同じプロトコル・ポートで行う（mtr --tcp・--udpと--port）、自社機器の経路なら不良の回線・機器を束から外す。
- 外部の対応
- 通信事業者に不良経路の確認・交換を依頼、ユーザーには再接続で一時的に回避するよう案内（再接続でポートが変わる場合）。
- 数値の目安
- 経路が4本なら、影響を受けるのはユーザーの約4分の1だけです。Pingの測定はゲームとは別の経路を通るため、正常な値が出ることもあります。
- グラフでは
- 一部だけ高い · 接続ごとのパケットロス・再送（IP・ポート別）
- 確認箇所
- 接続ごとのパケットロス・再送を送信元IP・ポートで分けて確認。mtrをUDP（-u）でゲームのポート（-P）宛てに送り、送信元ポート（-L）を固定して測定し、送信元ポートを変えて何度か繰り返す。-Lを付けずに-Pだけを指定すると、要求ごとに送信元ポートが変わって複数の経路が混ざる
- 該当する場合
- 同じ地域・通信事業者の中で、特定の送信元ポート（またはアドレス）の組み合わせだけで継続的にパケットロスが発生し、再接続してポートが変わると直る
- 該当しない場合
- ポートを変えてもすべて悪ければ、ある区間全体の混雑・障害
- 確認手段
- インフラのツールで確認（ゲームコード不要）
- もっと詳しく
- 1つの接続のパケットの順序が入れ替わらないよう、機器はアドレスとポート（機器の設定によってはアドレスだけ）から計算した値で、接続ごとに経路を固定します（ECMP、LAG）。アドレスだけを使う環境では、再接続しても同じ経路になるため改善しません。そのため「Pingは正常なのにゲームだけラグい」「再接続したら直った」といった報告が一緒に届いたら、この原因を疑います。
出典
- RFC 7424: Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks IETF
LAG・ECMPはヘッダーフィールドのハッシュでフローごとにリンクを1本決め、パケットの順序を守る（フロー→リンクの多対一の対応） - RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
フローを区別する基準は実装によって異なる（宛先アドレスのみ、アドレスの組、ポートまで）、マルチパスではping・tracerouteの結果を信用しにくい - mtr(8) manual page source mtr
-u（UDP）、-P（宛先ポート）、-L（UDPの送信元ポート）オプション、-Pだけを指定すると送信元ポートに要求の通し番号が入り、要求ごとに変わる
あわせて読みたい原因
同じ層：L4 インターネット回線
同じ症状（ワープ）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る