【事故速報】MARS・インターネット相互接続申請
sdccadmin
島根データセンター友の会 SDCC OWN本部 ネットワークオペレーションセンタでは、日々のシステム運用や障害対応を通じて得られた技術的な知見を、技術ブログとして積極的に公開しています。
ITインフラの運用現場では、ネットワーク障害、サーバーの不具合、ソフトウェアの予期せぬ挙動など、さまざまな技術的課題に直面します。
こうした問題の中には、公式ドキュメントだけでは解決が難しく、試行錯誤や詳細な調査を重ねることで、ようやく原因の特定や復旧に至るケースも少なくありません。
一方で、そうした貴重な経験やノウハウは、担当者や組織の内部にとどまり、十分に共有されないまま埋もれてしまうことがあります。
私たちは、障害対応を通じて得られた知見は、自分たちだけのものではなく、同じ課題に直面する技術者にとっても価値のある情報であると考えています。
そのため、実際に発生した障害の事象、原因分析、調査過程、解決方法、再発防止策などを可能な範囲で整理し、技術ブログを通じて発信していきます。
MARS インターネット相互接続申請の投入失敗について
2026-10-10、MARS 本番環境でインターネット相互接続申請の Config 投入が失敗しました。
原因は管理画面の操作誤りで、MARS のソフトウェアの不具合ではありません。
経緯と対処内容を共有します。時刻はすべて JST です。
※ 本報告書では、契約・申請番号・装置名・アドレスを匿名化しています。
申請は発生順に S〜Z の記号で表記します。
1. 事象の概要
契約 A（VRF-A・L3VPN の ER 経由インターネット接続）の IPv4 インターネット相互接続申請申請 Y（広報 198.51.100.160/28）を投入したところ、leaf スイッチ leaf 1 で次のエラーにより投入が失敗した。
ip prefix-list PL-VRF-A-ADV seq 5 permit 198.51.100.160/28 le 32
% Insertion failed - seq # exists with different policy: 5実機には、撤去済みのはずの旧申請 S の行（seq 5 permit 198.51.100.92/30 le 32）が残っていた。
同じ seq 番号に別の CIDR を書き込もうとしたため、NX-OS に拒否された。
失敗したのは 1 行目で、それ以降の行は投入されていないため、この失敗による実機への影響は無かった。
2. 発生原因
2.1 直接原因
AdminUI に習熟していない担当者が、承認画面で撤去申請を「承認」したあと、ConfigDeployer で装置に投入しないまま「投入完了にする」を押した。
その結果、台帳（MARS の DB）からは旧構成が削除されたが、実機には旧 Config が残った。
「承認済みの申請を、投入せずに完了にできる」のは、手作業で投入したあとに記録するための仕様である。
2.2 時系列
| 日時 | 事象 |
|---|---|
| 2026-09-02 | 申請 S（IPv4・198.51.100.92/30）と申請 T（IPv6）を両 leaf へ正常に投入 |
| 10-10 17:50:24 | 撤去申請 U（S の撤去）を承認 |
| 17:50:44 | U を**投入せずに「投入完了」**にした（承認の 20 秒後）。台帳から S が消え、実機には IPv4 の Config が残る |
| 18:50:25 → 18:50:46 | 作成申請 V（203.0.113.104/29）を承認し、同じく投入せずに完了 |
| 19:08:30 → 19:09:18 | 撤去申請 W（V の撤去）を承認し、投入せずに完了 |
| 19:09:27 → 19:09:38 | 撤去申請 X（T＝IPv6 の撤去）を承認し、投入せずに完了 |
| 20:00:20 → 20:01:14 | 申請 Z（IPv6・2001:db8:1108::/64）を承認・投入・完了（正常） |
| 20:00:25 | 申請 Y（IPv4・198.51.100.160/28）を承認 |
| 20:01:38 | Y の投入を開始 |
| 20:01:48 | Y の投入が失敗（1 章のエラー） |
| 20:25:21 | Y を却下（新規に申請し直す方針） |
2.3 人による操作と判断した根拠
- 操作記録（audit_logs）では、U／V／W／X の 4 件とも「承認」の直後が「投入完了」で、
「投入開始」と「装置ごとの投入結果」の記録が無い。 - 装置ごとの投入状態の記録（vpc_deploy_states）も 0 件だった。
- 自動投入（ConfigDeployer）は必ず「投入開始」を記録してから投入するため、自動処理ではなく人が完了にしたと判断した。
2.4 誤操作を招いた要因（画面）
- 「承認」と「投入完了にする」のボタンが同じ青色だった。
- 承認の前は「承認」が、承認の後は同じ行の同じ位置に「投入完了にする」が表示される。
- 承認時には申請内容が表示されるが、投入完了は見出しとボタンだけの画面で、注意を引かなかった。
2.5 発見が遅れた要因
撤去申請を投入せずに完了にすると、台帳上の構成記録が削除される。
そのため実機に残った Config に誰も気付かず、次の申請が衝突して初めて表に出た。
3. 影響
本件は解約後回線及び開通前案件に対する設定投入事故であり、ユーザー影響は発生しておりません。
| 対象 | 影響 |
|---|---|
| 契約 A の IPv4 相互接続の新設（Y） | 投入できなかった。再申請は未実施（7 章） |
| 契約 A の既存 IPv4（S の残骸） | 台帳からは消えていたが、実機では 20:33 の是正まで動作しており、ER から default route を受けて使われていた。広報していた経路は 0 件 |
| 契約 A の IPv6（T → Z） | X も投入されていなかったが、Z が同じ内容で上書きしたため実害なし |
| V／W | 作成・撤去とも投入されていないため、実機への影響なし |
| 他の契約 | なし |
4. 是正作業中に発生した二次影響
- IPv6 の default route の受信停止（約 2 時間半）
21:05:59、手作業での撤去の際に、IPv6（Z）用の route-mapRM-VRF-A-ADV6／RM-VRF-A-ERIN6も両 leaf から削除した。
このため VRF-A が ER から IPv6 の default route を受け取れなくなった（受信 0 件。広報は継続）。
23:13 の再検査で発見し、手作業で復元して受信 1 件に戻した。 - IPv6 BGP セッションの一時リセット
トランスポート SVI（Vlan3109）から IPv4 アドレスを外したことで VRF の BGP router-id が変わり、IPv6 の BGP セッションがリセットされた（leaf 1 は 20:33:06、leaf 2 は 21:05 ごろ）。
いずれもすぐに再確立した。router-id の変更に伴う装置の仕様上の挙動である。
5. 実施した対処
- Y を却下した（20:25）。
- 両 leaf から S の IPv4 の残骸（neighbor・route-map・prefix-list・集約・SVI の IPv4 アドレス）を手作業で撤去した。
- 再検査で見つかった撤去漏れ（leaf 2 の Vlan3109 の IPv4 アドレス）を是正した。
- 誤って削除した IPv6 の route-map を両 leaf で復元した。
- 台帳と実機 7 台の全数照合を行い、差分 0 を確認した。
照合対象: leaf の VRF・VLAN／VNI・SVI・ポート・相互接続、ER の BGP ピア・広報セット・route-map の本文・トンネル、POI の L2 トンネル。
6. 再発防止策
6.1 画面の改修（改修済み）
- 「投入完了にする」を押すと、画面中央に最終確認ウィンドウを表示する。
「装置への投入は行わず台帳だけを完了にする」「ConfigDeployer で投入が終わっていなければ押さない」という注意と、申請の内容を表示する。実行ボタンの名前は「投入せずに完了にする」とした。 - 一覧の「投入完了にする」ボタンを、承認とは別の注意色（黄）にした。
6.2 運用面
- 担当者への教育と手順書の整備（承認 → ConfigDeployer で投入 → 完了は自動、という流れの周知）
＼ 最新情報をチェック ／
