続報を氷室に渡したあと、机に紙が並んだままになっている。
支店ルータの経路表に、午後の時間帯だけ外部行きの経路が並んでいない時刻があり、設定上は主回線側 next-hop を指す default route が track と紐付いて残っている。主回線方向の到達確認は timeout を返し、track は down 判定。二本目の回線は up しているが、経路としては誰も使っていない。ここまでは続報で並んだ。主回線側 flap がなぜ起きるのかと、二重化が用意されなかった当時の設計判断は、まだ追えていない。
「観測の向きがそろったなら、もう二本目を経路として入れて終わりですよね」と瀬戸が紙を持ち直す。
そこで一度止まる。直す範囲をどこまで小さく絞るか、戻す条件は何か、戻ったと言える確認は何方向か。主回線が復旧した瞬間にどう振る舞ってほしいか。支店側の窓口にも、変更時間と確認内容を短く返しておく必要がある。
どの手を打って、どれを取らないか
修正の候補を、氷室と並べて紙に三つ書く。
ひとつめ。支店ルータに、二本目の回線向けの default route を一行だけ足す。動かす対象は一行だ。ただし、ただ足すのではなく、主回線側経路より「低い優先度」で待たせておく書き方にする。主回線側が経路表から消えた時間帯だけ経路表へ昇格し、主回線が復旧して戻ってきたら、自分は経路表から下がる。日中の主回線側到達確認や、主回線側経路の設定そのものには触らない。
ふたつめ。二本目の回線向け経路を、主回線側と同じ優先度で並べる。同じ優先度の経路が二本並ぶと、外向き通信は二本に分散される。主回線が生きているあいだも、戻ってくる通信が行きと別の経路から戻る可能性が出る。意図せぬ片寄り、外向き通信の左右非対称、外側装置との接続の覚えの整合性。本日この時間で動かすには、副作用の範囲が広い。
みっつめ。支店ルータの running-config を、旧 backup で丸ごと上書きする。抜けていた経路はまとめて拾えるが、主回線側到達確認、track 設定、その他の設定の差分も同時に入れ替わる。今日の症状は二本目の回線向け経路の欠落だが、上書きの範囲はそれより広い方向に出る。
「みっつめは、上書きする範囲が、いま見えている事象より広いですね」と瀬戸が首を振る。
「症状より大きい修正は、最初に外しなさい」と氷室。「ふたつめは、主回線が戻った瞬間に二本の経路が同じ重みで並ぶ。戻り経路が非対称になる可能性は、本日この時間に走らせるには重いの」
ひとつめが残る。動かす対象は default route 一行だけ。主回線側より低い優先度で、二本目の回線向けに待たせる書き方を取る。
「優先度を低くしておく、っていうのは、書いた瞬間からその一行が使われるわけじゃないんですか」と瀬戸。
「はぁ? なんでそうなるのよ」と氷室。「優先度の低い経路は、優先度の高い経路が経路表に並んでるあいだは経路表に出ない。主回線側到達確認が up で track が up なら、主回線側経路が経路表に並ぶでしょう。そのあいだは、二本目側の一行は経路表には載らないの。主回線側が消えた時間帯にだけ、その一行が代わりに経路表へ出る。戻ってきたら、また下がる」
「つまり、いつもは寝ていて、主回線側が消えた時間帯だけ起きて、戻ってきたらまた寝る、ってことですか?」
「やっとまともな文になったじゃない」
戻し方を、入れる前にそろえる
方向が決まっても、コマンドを構える前に戻し方を決める。戻す条件と手順と判断期限を、氷室と合わせて先に書いておく。
戻す条件は、次のどれかが当てはまったとき。
- 追加コマンド投入後 3 分以内に、支店端末から外部宛の ping が戻らないとき
- 主回線側到達確認が up に戻ったあと、経路表に主回線側経路が戻らない、または別経路への片寄りが起きるとき
- 支店窓口に追加の業務影響が出始めたとき
このどれかが当てはまったら、追加した一行を no ip route で取り消し、追加前の状態へ戻す。戻したあとは、上位の判断を仰ぐためにエスカレーションする。判断期限は変更後 3 分以内。経路の追加は書いた瞬間に効き、主回線側が今 down 状態であれば、書いた数秒後には経路表で二本目側経路が並ぶか並ばないかが見える。長く様子を見ても、出るときは出ていて、出ないときは出ない。
「戻し方を先に決めておくのは、入れる手前で書いておくんですか?」と瀬戸。
「ちょっと、今の本気で言ってる?」と氷室。「決めずに入れて、何か起きてから戻し方を考えていたら、戻すまでの時間が延びるでしょう。判断期限、戻す手順、戻したあとどこへ上げるか、まとめて先に書いとくの」
それと、もう一つ。投入はピーク時間帯を避ける。毎日の不通が出るのは午後の時間帯だ。そこへ重ねて変更を入れると、もし切り戻しが必要になったとき、戻している最中も支店の業務時間と被る。投入は、午後の時間帯に当たらない時刻に組む。
変更前の写しを残し、支店側へ短く予告する
コマンドを構える前に、変更前の状態を残す。支店ルータで、外部行き経路の設定を引いておく。
BR-OSK# show running-config | section ip route
ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1
主回線側 next-hop を指す経路が一行だけ。二本目の回線向けの経路はどこにも書かれていない。続報で並んだ観測と一致する状態だ。これを変更前として記録する。
支店側の窓口には、変更の予告だけ短く入れる。
午後だけ外部に出られない件、原因の方向が見えました。本日この後、支店ルータで設定を一行入れる予定です。いま業務で動いている社内通信には影響が出ない方向で組んでおり、変更直後の数分は念のため見続けます。完了後、改めて結果をお知らせします。
長くしない。変更が入ること、社内通信には影響が予想されないこと、終わったら次の連絡が来ること、の三つだ。原因の細部や、優先度をどう設計したかの説明は、いま支店側の窓口が午後の業務を別経路で回す判断に使う情報ではない。
一行だけ、低い優先度で待たせる
運用リーダーから承認を取ったあと、ピーク時間帯を外した時刻に、支店ルータのコンソールから設定を入れる。
BR-OSK# configure terminal
BR-OSK(config)# ip route 0.0.0.0 0.0.0.0 198.51.100.1 250
BR-OSK(config)# end
BR-OSK# write memory
末尾の数値は、優先度の低さを表す指定だ。主回線側経路の指定は今までと同じで、こちらが優先される側にいる。続けて、追加された一行が設定に並んだことを引く。
BR-OSK# show running-config | section ip route
ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1
ip route 0.0.0.0 0.0.0.0 198.51.100.1 250
変更前との差は、この一行だけ。主回線側経路の行と、二本目の回線向けの一行が、設定上に並んだ。期待した変更後の状態とそろっている。
「ping が返ったから完了」と書かない
「設定が入って、ping も戻ったなら、もう完了ですよね」と瀬戸が紙を伏せようとする。
「はぁ? なんでそうなるのよ」と氷室の赤ペンが机を一度叩く。「あんた、設定を入れた事実と ping が戻った事実と、業務が戻った事実と、翌日も戻る事実を、ぜんぶひとつにまとめてるでしょう。確かめる方向が、まだ五つ残ってるの」
ひとつめ、支店端末から外部宛の ping。投入直後、午後の時間帯はまだ主回線側到達確認が timeout を返している。
PC-OSK# ping 8.8.8.8 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5)
5 発打って 5 発戻る。続報で 0 発だった時間帯と同じ状況で、5 発が戻る方向に出た。
ふたつめ、支店ルータの経路表。
BR-OSK# show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "static", distance 250, metric 0, candidate default path
Routing Descriptor Blocks:
* 198.51.100.1
Route metric is 0, traffic share count is 1
経路表に並んでいる default route の next-hop は、二本目の回線側だ。主回線側到達確認が timeout を返しているあいだは、優先度の低い側の経路が代わりに経路表へ昇格していることが、ここで初めて並んだ方向に出た。
みっつめ、主回線が戻ったときの挙動。主回線側到達確認が up に戻る時刻まで待つ。
BR-OSK# show ip sla statistics 1
IPSLAs Latest Operation Statistics
IPSLA operation id: 1
Latest RTT: 2 milliseconds
Latest operation start time: 17:42:11 UTC Mon May 18 2026
Latest operation return code: OK
BR-OSK# show track 1
Track 1
IP SLA 1 reachability
Reachability is Up
7 changes, last change 00:04:21
Latest operation return code: OK
Tracked by:
STATIC-IP-ROUTING 0
BR-OSK# show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "static", distance 1, metric 0, candidate default path
Routing Descriptor Blocks:
* 203.0.113.1
Route metric is 0, traffic share count is 1
到達確認が OK を返し、track が Up へ戻ると、経路表の next-hop が二本目の回線側から主回線側へ入れ替わる。優先度の高い側が戻ってきたので、低い側が経路表から下がった。経路を奪い合うのではなく、上下が入れ替わる動きで戻る。
よっつめ、支店側の業務確認。支店窓口にチャットで聞く。
午後の時間帯、外部のサイトとクラウド業務、開けるようになりました。別経路で回していた急ぎ業務は、通常の運用に戻していいですか?
通常運用に戻してよい旨を伝える。技術的に通った確認と、業務が回せる感覚の確認は、別の方向から来る。
いつつめ、翌日の午後の時間帯に同じ場所をもう一度引く。投入直後だけで終わらせない。翌日 14 時頃、再観測する。
BR-OSK# show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "static", distance 250, metric 0, candidate default path
Routing Descriptor Blocks:
* 198.51.100.1
PC-OSK# ping 8.8.8.8 repeat 3
!!!
Success rate is 100 percent (3/3)
午後の時間帯にもう一度主回線側到達確認が timeout を返す状況になっても、二本目側へ経路表が切り替わり、ping は戻る方向に出た。毎日の自然復旧待ちが、ここで初めて消える方向に出る。
念のため、本社と他支店からも追加の申告が来ていないことを監視で確認する。他拠点への影響は出ていない。
「直りました、って書きそうになりますね」と瀬戸。
「『何が戻ったか』を分けて書きなさい」と氷室。「設定が入ったこと、ping が通ったこと、経路表が時間帯で入れ替わること、主回線復旧時に経路を奪い合わずに戻ったこと、支店利用者の業務感覚で戻っていること、翌日の同じ時間帯にも戻っていること、他拠点に追加影響が出ていないこと。どれも別の観測なの。ひとつだけだと別のところが落ちている可能性が残るの」
「つまり、設定、経路表、優先度の戻り、業務確認、翌日の再観測、他拠点影響なし、これだけそろって『戻った』と書ける、ってことですか?」
「やっとまともな文になったじゃない」
支店側へ返す、短い完了共有
支店側の窓口へは、別経路で完了の短い連絡を入れる。
午後の時間帯に外部のサイトとクラウド業務が開けなかった件、本日の設定変更が完了しました。午後の時間帯にもう一度同じ症状の出る時刻が来ても、外部に出られる側へ経路が切り替わる動きが入っており、こちらでも実機で確認しました。別経路で回していただいた急ぎ業務は、通常の運用にお戻しください。同様の症状が再発した場合のみ、改めてご連絡ください。
復旧したこと、通常運用に戻ってよいこと、追加連絡が必要になる条件、の三つだ。原因の細部や、どんな優先度設計をしたかの説明は、いま支店側の窓口が業務を回す判断に使う情報ではない。
氷室に残す報告書
確認がそろったあと、氷室に残す報告書を組み立てる。報告書は、暫定対処と恒久対処の境界を分けて、六つの欄に分ける。
-
復旧した事実
大阪支店から外部のサイトとクラウド業務が、午後の時間帯にも開けるようになり、毎日の自然復旧待ちが解消した。投入直後の外部 ping、経路表、主回線復旧時の経路の入れ替わり、支店利用者の業務確認、翌日午後の時間帯の再観測のいずれでも、外部疎通が維持される側にそろった。他拠点（本社・他支店）への追加申告と影響は、確認の範囲では出ていない。
-
原因として言える範囲
支店ルータの外部行き経路が、主回線側 next-hop だけを指す一本に限られており、主回線側到達確認が timeout を返す時間帯には、その一本が経路表から外れる構造になっていた。二本目の回線は up していたが、経路としては待機していなかった。続報で見えた経路表の欠落、到達確認の timeout、track の down 判定、二本目の回線が経路として設定上にも無い観測の向きが、変更後の経路追加と時間帯横断の経路表の入れ替わりで同じ向きにそろい、補強された。
-
まだ言えない範囲
主回線側 flap がなぜ起きるのかは、本日時点で確認できていない。事業者側の保守状況、混雑、装置側の状態、どこに当たるかは別途調査が必要だ。当初の構成で二本目の回線向けの待機経路がなぜ用意されていなかったかも、当時の設計判断の経緯としては未確認のまま残る。
-
実施した修正
- 暫定対処: 支店ルータに
ip route 0.0.0.0 0.0.0.0 198.51.100.1 250を一行投入。主回線側経路が経路表に並ぶあいだは待機側として下がり、主回線側経路が経路表から外れた時間帯だけ昇格する書き方を採った。変更前の running-config を保存。切り戻し手順は、追加した一行をno ip routeで取り消し、変更前の状態に戻したうえで上位へエスカレーションする形で事前に確定。判断期限は変更後 3 分以内。投入はピーク時間帯を外した時刻に組んだ。 - 恒久対処（候補）: 主回線側 flap の事業者要因の確認を、事業者連絡判断とともに別途調整。二重化漏れの設計レビュー手順を、変更管理に組み込む方向で別途整理。本日の修正では実装まで進めず、記録事項として残す。
- 暫定対処: 支店ルータに
-
検証結果
- 経路表確認: 投入後、主回線側到達確認が timeout を返す時間帯に、二本目の回線側 next-hop が default route として経路表に並ぶことを確認。主回線側到達確認が OK に戻ったあと、主回線側経路が経路表へ戻り、待機側が下がることを確認
- 主回線側到達確認と track 状態: 主回線が復旧したときに、IP SLA の Latest operation return code が OK、track が Up へ戻ることを確認
- 疎通確認: 支店端末から外部宛
ping 8.8.8.8を 5 発打って 5 発戻ることを、午後の時間帯と通常の時間帯のどちらでも確認 - 翌日午後の再観測: 翌日の 14 時頃に同じ場所で経路表と外部 ping を引き直し、外部疎通が維持されていることを確認
- 利用者確認: 支店窓口経由で、午後の時間帯も外部のサイトとクラウド業務が開けることと、通常運用に戻してよい旨の確認
- 副作用範囲確認: 本社と他支店からの追加申告が無いこと、監視上も追加影響が出ていないことを確認
-
記録へ戻す事項
- 主回線側 flap の事業者要因の確認を、事業者連絡判断と一緒に別の案件として残す。本日の修正は二本目の回線向け待機経路の追加で、主回線側 flap そのものを止めるものではない
- 二重化漏れの設計レビュー手順を、変更管理の恒久対処候補として残す。同じ書きぶりで主回線側 next-hop だけに依存する default route が、他の拠点でも並んでいないかの定期確認も候補に上げる
- 待機側経路の優先度設計と、主回線復旧時に経路を奪い合わない動きの観測点を、設計課レビューへ戻す
- 周期的な flap が観測された時間帯、主回線側リンクの状態履歴、本日の変更時刻と切り戻し条件、復旧確認の各観測結果、翌日午後の再観測結果を、拠点二重化チェックリストとして次回早く見つける材料へ戻す
「直したから終わり」と書かない理由
「未確認のところを、報告書から消したくなりますね」と瀬戸が紙の余白を見る。「戻ったんだから、主回線側 flap がなぜ起きるかとか、当時なぜ二重化が用意されなかったかとか、書かなくても困らないんじゃないですか」
「ちょっと、今の本気で言ってる?」と氷室。「消したい気持ちは分かる。だけど、消したらどうなるかを考えなさいよ」
「えっと…次に同じ周期障害が別の支店で出たとき、最初に何を見ればいいか分からなくなる、です」
「そう。『主回線側 flap がなぜ起きるか』を未確認のまま残しておけば、別の拠点で同じ時間帯依存の不通が出たとき、最初に当たる先として残せる。確定として閉じてしまうと、その情報経路が無くなるの。事業者要因を推測で断定して書くのも違う。それと、暫定で一行足した事実と、恒久で設計レビュー手順を変更管理に組み込む話を、同じ欄にまとめないで」
「つまり、まだ言えない範囲と恒久対処の候補は、報告書から消さずに別の欄として並べておく、ってことですか?」
「やっとまともな文になったじゃない」
報告書の三つめの欄に、まだ言えない範囲が並び、四つめの欄では暫定対処と恒久対処が別の段落として分かれている。観測で言える範囲と言えない範囲、いま動かした範囲と後で動かす範囲が混ざらずに並ぶことが、次の対応をしやすくする。
二本目の線を、いつでも待たせておくということ
報告書が氷室の手元に渡る。支店側の窓口にも、別経路で短い完了共有が入っている。主回線側 flap の事業者要因確認と、二重化設計レビュー手順を変更管理に組み込む案は、別の流れで運用部と設計課の定例に乗る。
ここまでで、毎日 14 時頃から始まり 19 時頃に自然復旧していた周期的な不通は、技術的にも業務的にも、いったん閉じる。
外部行きの経路が主回線側 next-hop 一本だけを指していた、主回線側到達確認が timeout を返す時間帯にその一本が経路表から外れていた、二本目の回線は up しているが経路としては誰も使っていなかった、という観測の向きが見えてから、二本目の回線向けに一行だけ、低い優先度で待たせる最小修正にたどり着くまで、五本のレールが並んでいた。動かす範囲を一行に絞ったレール、戻し方を入れる前に決めたレール、ピーク時間帯を避けて投入を組んだレール、復旧確認を経路表・優先度の戻り・利用者の業務確認・翌日午後の再観測・他拠点影響なしの方向でそろえたレール、まだ言えない範囲と恒久対処の候補を消さずに残したレール。どれか一本でも欠けていれば、報告書のどこかの欄が薄くなる。
外部行きの線を一本だけにしておくと、その線が揺れた瞬間に外部はいなくなる。二本目を「いつでも待たせる」だけで、毎日の自然復旧待ちは終わる。机の上から、修正候補、変更前後の設定、復旧確認の紙を、順に重ねていく。一番下に来る紙が、報告書だ。次に別の拠点で同じ「午後だけ外に出られない」事象に当たったとき、今日机に並んだ五本のレールが、最初に置く下敷きとして残る。