【事故速報】MARS・トンネル申請

島根データセンター友の会 SDCC OWN本部 ネットワークオペレーションセンタでは、日々のシステム運用や障害対応を通じて得られた技術的な知見を、技術ブログとして積極的に公開しています。
ITインフラの運用現場では、ネットワーク障害、サーバーの不具合、ソフトウェアの予期せぬ挙動など、さまざまな技術的課題に直面します。
こうした問題の中には、公式ドキュメントだけでは解決が難しく、試行錯誤や詳細な調査を重ねることで、ようやく原因の特定や復旧に至るケースも少なくありません。
一方で、そうした貴重な経験やノウハウは、担当者や組織の内部にとどまり、十分に共有されないまま埋もれてしまうことがあります。
私たちは、障害対応を通じて得られた知見は、自分たちだけのものではなく、同じ課題に直面する技術者にとっても価値のある情報であると考えています。
そのため、実際に発生した障害の事象、原因分析、調査過程、解決方法、再発防止策などを可能な範囲で整理し、技術ブログを通じて発信していきます。
MARS トンネル申請(GRE over IPv6)における Config 投入失敗について
トンネルの IPv6 申請において、下記の問題が発生しました。
本件は対処済みですが、経緯と対処内容を共有します。
1. 事象の概要
MARS の申請経由で GRE over IPv6 のトンネルを申請した際、エンドポイントアドレスを2406:7ec0:10:20::4:30:1 としたところ、Config の投入処理が失敗した。
※IPv6アドレスは本番環境とは異なる仮のものです。
2. 発生原因
トンネル作成の処理では、利用者が入力した情報に加えて IPAM から区間アドレスを確保し、Config を自動生成して物理機器へ投入する。
投入後には、投入した Config が装置に正しく保存されているかを確認する処理(読み戻し照合)がある。
IPv6 アドレスは RFC 4291 上、複数の表記が許される。今回の入力値と装置の保存値は次のとおり。
| 表記 | 根拠 | |
|---|---|---|
| 投入した Config(利用者の入力値) | 2406:7ec0:10:20::4:30:1 | RFC 4291 では有効(0 が 1 グループだけの部分も :: で省略してよい) |
| Cisco が保存した Config | 2406:7ec0:10:20:0:4:30:1 | RFC 5952 の推奨形(0 が 1 グループだけの部分は :: で省略しない) |
読み戻し照合は文字列をそのまま比べるため、同じアドレスの表記の違いを差分と判定し、処理が停止した。
MARS には Config 生成時に IPv6 を RFC 5952 の推奨形へ揃える処理がすでに実装されていた。
しかし、トンネルのユーザー側エンドポイント(利用者の入力値)はRFC4291による短縮を実施しており、このチェック機構に差分が生じていたことが根本原因である。
3. 実施した対処
3.1 発生時の対処
- 投入対象装置から、投入済みの Config を手動で削除した(照合で処理が停止しても、投入済みの設定は自動では切り戻されない)
- エンドポイントを RFC 5952 の推奨形(Cisco の保存形式)で入力し直すよう利用者に依頼し、正常に処理されることを確認した
3.2 恒久対策(対応済み)
- トンネルのユーザー側エンドポイント IPv6 を、Config 生成時に RFC 5952 の推奨形へ揃えるよう修正した。
- 修正後は、利用者がどの表記で入力しても、装置の保存形式と同じ表記で投入される。
4. 影響範囲
- IPAM から自動で確保するアドレスは、以前から Config 生成時に RFC 5952 の推奨形へ揃えており、同様の事象は起きない。
- 影響を受けたのは、トンネル申請のユーザー側エンドポイント IPv6 で、RFC 5952 の推奨形以外の表記(例: 0 が 1 グループだけの部分を
::で省略)で入力された場合に限られる。 - 開通前事案かつ他ユーザーへのConfig影響はないため、ユーザー影響なし。障害申告なし。
5. 今後の対応
- 万一、読み戻し照合で投入が停止した場合は、従来どおり NOC へエスカレーションし、投入済み Config の手動切り戻しを行う(照合で停止しても自動では切り戻されないため)。

