Wiresharkで「なんとなく不安定」を数値で突き止める5段階診断法
現場の失敗シーン
本番開始7分前、モニターに映るNDIソースが0.3秒だけフリーズした。担当者はスイッチを1台交換し、LANケーブルを挿し直し、送出機を再起動した。症状は止まったように見えたが、本番中に同じフリーズが2回再発した。原因は最後まで「ネットワークの調子が悪い」としか説明されなかった。
問題の構造化
「ネットワークが悪い」という言葉は、症状の説明であって原因の説明ではない。IP伝送で起きる異常は、パケット単位で見れば必ず数値として現れる。たとえばIGMPのクエリア（マルチキャストの管理者）が2台同時に存在すると、デフォルトのクエリ間隔125秒（RFC 3376 §8.2）に対して、競合が解消するまでに最大250秒（125秒×2）の不安定な期間が発生しうる。この250秒という数字は、目視や体感では測れないが、パケットキャプチャなら正確に切り出せる。
共感の深化
パケットキャプチャを使わない現場のトラブル対応は、レントゲンを撮らずに骨折の場所を当てようとする問診に近い。触診（機材の交換）で当たることもあるが、外れれば同じ処置を繰り返すだけで、患部（本当の原因）には一向にたどり着かない。数値という「レントゲン写真」を見れば、原因の位置は一度で特定できる。
解決策の存在
症状から原因までを一直線につなぐ診断手順は存在する。捕る・絞る・測る・診る・治すという5段階に分解すれば、経験に頼らずに誰でも同じ結論にたどり着ける。
この記事で得られること
有料部では次の3点を手に入れられる。
- ST2110／RTP／PTPのパケットをWiresharkで正しく分離するための具体的な設定手順
- ジッタ・パケットロス・シーケンス欠番を数値化し、正常・警告・危険を判定する基準表
- 現場で15分以内に一次切り分けを終えるための診断フローとチェックリスト
ここから先は有料部
この診断手順を知らないまま本番を迎えると、原因不明のまま機材交換を繰り返すことになる。SPANポート（ミラーポート）は、監視対象の合計帯域が受け口の帯域を超えると、優先度の低いミラーデータから間引かれる仕様がスイッチベンダー各社で共通して説明されている（出典：Garland Technology社公開資料「TAP vs SPAN」、Cisco Systems公式SPANポート仕様解説）。つまり「見ているはずなのに、実は一部しか見えていない」状態で本番に臨むことになりかねない。次の現場で同じ事故を防ぐ手順が、このあとにある。
コメント