インストール
apt install -y mtr-tiny # Debian
dnf install -y mtr # AlmaLinux正しく実行する
mtr -rwbc 200 <destination>-rレポートモードにして、貼り付けられる出力で終了させる-wワイド出力にして、長いホスト名も切れないようにする-b各ホップの名前とアドレスを表示する-c 200200サイクル、約3分半。これで、証拠と偶然の違いが分かる
10パケットでは何も証明できない。10サイクルの実行でロスが見えたら、何かを結論づける前に200サイクル実行すること。
最初に最後のホップを読む
ルーターは自分宛てのパケットの優先度を下げる。数百ギガビットを転送する中継ルーターは、余裕があるときに期限切れTTLのプローブに応答し、余裕がないときにそれを落とす。そのため、レポートの途中にロスが表示されても、実際に気にしているパケットはすべて無傷で到着している。
ほとんどのレポートには2つのルールが当てはまる:
- ホップ7でロスがあり、ホップ8以降にはない場合、それはレート制限である。無視してよい。
- ホップ7からロスが始まり、宛先まで続く場合、それは実際のロスであり、ロスが始まったホップが調査対象である。
レイテンシも同様に振る舞う。80ミリ秒を追加し、その後は前の値で次のホップに渡すホップは、応答が遅いのであって、転送が遅いのではない。
ICMPはお前のトラフィックではない
サービスがTCP上で動くなら、TCPでテストしろ:
mtr -rwbc 200 --tcp --port 443 <destination>ICMPを厳しくレート制限するネットワークでも、TCPは素通しのことが多い。逆のケース、つまりpingには喜んで応答するが、ユーザーが実際に使うポートを落とすファイアウォールというケースは、誰かのネットワークを非難する前に発見する価値がある。
毎回、両方向
ルーティングは非対称であることが多い。お前から我々への経路は、我々からお前への経路ではない。片方の端からのレポートは、そのうちの1つしか記述しない。インスタンスからクライアントに向けて、そしてクライアントからインスタンスに向けてMTRを実行し、両方を添付しろ。我々の経路の半分は、シェルなしでも、looking glass から調べられる。
TCPカウンタで裏付ける
MTRは経路を記述する。ソケット統計は結果を記述する:
ss -ti state established
nstat -az TcpRetransSegs TcpExtTCPLostRetransmitクリーンであるべき接続で、再送率が1%程度以上あれば、レポートを裏付ける。MTRにロスがたくさんあるのに再送がゼロなら、それはレート制限を見ているだけで、他でもない。
我々に送るもの
- 両方のMTRレポート、200サイクル、スクリーンショットではなくテキストで
- 宛先、トランスポート、ポート
- タイムゾーン付きのタイムスタンプ、そしてロスが一定かバーストか
- インスタンスID
これらの約半分はレート制限された中間ホップに起因し、最初の返信でその旨を伝える。残りは、通常1時間以内にルーティングを変更できる。我々のネットワーク内のロスは我々の問題であり、1つのトランジット経路のロスは、トラフィックを別の経路に移す問題である。