「接続できるのにPing不安定...」原因（MTU値）を特定した話

前提

弊社はIaaSでお客様にサーバーを提供しています。
お客様拠点からサーバーまで閉域網接続を行っており、回線及び機器の管理はお客様（及びベンダー）の責任範囲です。

1．今回のトラブル内容

お客様からの問い合わせ内容は以下の通り

・サーバーに接続できるがPing不安定になり通信が落とされてしまう時がある
・端末及びサーバーの再起動を行っても改善がされなかった
・導入当初（半年前）は普通に使えていたが、4月から急に不安定になった

2-1．調査内容

上記の情報だけだったので、以下の切り分けを行いました。
（確認を行った理由は最後に補足）

◆お客様に確認
①特定の時間帯に集中して発生するか
②同じネットワークから別のサーバーへping等は不安定にならないか
③ルーターを再起動して改善されないか（正常性は問題ないか）

◆ネットワークベンダーに確認
④回線の工事や障害は発生していないか

◆サーバーのリソース状態を確認

⑤メモリ/CPU使用率の推移
⑥ネットワークパケットの制限値に引っかかっていないか
⑦サーバーに対する不正なアクセスや、意図しないパケット拒否がないか

2-2．原因特定（MTU値）

①～⑦全て正常（問題なし）であったため、
お客様の接続端末及びサーバー側のMTU値を確認しました。
今回のお客様は閉域網接続のため、パケットを送り出す際にルーター箇所で1500の上限を超えてしまい、パケットロスになっている可能性を疑いました。

※イメージ図

※MTUとは
Maximum Transmission Unitの略。
データを送信する際に細かく小分け（パケット）して送信しますが、この小分けにした1個の最大サイズが「MTU値」です。
身近なたとえで言うと、宅配時の段ボールの箱（パケット）の大きさの上限。

cmdを立ち上げ、以下のコマンドでMTU値を確認（お客様端末及びサーバーで実施）
「netsh interface ipv4 show subinterfaces」
（添付は私の自宅のもの）

実際の環境でも、
左列のMTUの部分が1500（デフォルト値）となっていました。
そのため、以下のコマンドを案内しMTUを変更して通信が安定するか確認してみました。
「netsh interface ipv4 set subinterface "イーサネット" mtu=1450 store=persistent」

MTU値を下げ運用いただき、
その後お客様から問題なく利用できていると連絡があり、本件はクローズとしました。

2-3．なぜ原因がMTUと追究できたか

・導入当初は問題なく使えていた
・サーバー側の被疑はなかった
・不安定といえど、サーバーに接続できていた

であったため、以下を仮説にしました。
●新年度に伴う業務処理量の増加や、システムの本格運用化が始まった
（日常的にMTU上限（1500）に触れるようになった）
●切り分けにより、サーバーではなくお客様環境及び経路に問題があると仮定
●完全に通信が切断されているわけではなかったので、Ping（小さなパケット）は通るが、システムの実データ（大きなパケット）が経路上で破棄されているのではないかと仮定。

3．再発防止をどうしたか

MTU値はお客様の利用するルーターやネットワーク構成により変動するため、一律の推奨値を指定することは困難です。また、これらは「お客様の責任範囲」の事象であり、本来であれば弊社が関知しない領域でもあります。

しかし、同様の問い合わせが発生するたびに今回のような長期の調査を行っていては、運用のコストが膨れ上がってしまいます。

そこで、今回のトラブルを今後回避するため、以下の再発防止策を講じました。
Ⅰ：サーバー構築チームへの標準化フィードバック
今回の事象が今後構築される他のサーバーでも再発するのを防ぐため、サーバー構築を担当するチームへ「サーバー側のデフォルトMTU値の最適化（検討依頼）」をエスカレーションしました。

Ⅱ：「サーバーは正常なのに通信が不安定」という特定のパターンに対して、チーム全体がMTU被疑を疑える共通認識（ナレッジ）を作りました。

4．最後に

直ぐに原因まで辿り着く事ができればとても楽なのですが、実際は問い合わせ受付時の情報は本当に僅かなものしかありません。そのため、お客様からどれだけ情報を引き出せるのか、ヒアリング力がエンジニアの成長に繋がる一歩だと思います。
また、自社に非がないと分かった時点で突っぱねることは簡単と思います。ただし、そこから一歩踏み込んで、一緒に原因（MTU値）まで辿り着く泥臭さが、サービスの安定を生みお客様の信頼に繋がると感じます。

おまけ

今回原因究明のために行っていた①〜⑦の切り分けの意図をまとめました。

①⇒バッチ処理の集中による一時的な帯域逼迫がないかを切り分けるため。
②⇒問題が「特定のサーバー（弊社IaaS）」にあるのか、「お客様拠点のLAN/回線全体」にあるのかを切り分けるため
③⇒とりあえず困ったら再起動（機器ハングアップを解消・確認するため）
④⇒キャリアの物理的な要因を除外するため
⑤⇒サーバー自体の処理負荷によって、パケットのドロップが発生していないか確認するため
⑥⇒基盤側あるいはOS側の帯域リミッターに到達していないかを確認するため
⑦⇒特定の通信が誤ってブロックされていないか確認するため

参考になれば幸いです。
＋