続報を氷室に渡したあと、机の上に紙が三枚並んだままになっている。
朝礼の終わる時刻と、対象スイッチで同報通信が桁違いに増える時刻、CPU が跳ねる時刻、新しい MAC が短い時間に集中して覚え直される時刻、これらが同じ数分間に重なる。営業部 VLAN を収容する対象アクセススイッチで、その時間だけ同報通信が短時間に積み上がり、処理が一時的に詰まる、までは続報で並んだ。引き金は同時起動端末群の重なりにありそうだ。ただし新人 PC 側の同報送信の設定意図、過去に同じ事象が起きていたかの長期推移、Wake-on-LAN を残す業務上の理由は、まだ手元では確かめられていない。
「観測の向きが揃ったなら、もう新人グループを別の VLAN へ移して、ぜんぶ片付けちゃっていいですよね」と瀬戸が紙を持ち直す。
そこで一度止まる。次の朝礼までに動かす範囲はどこか、後から進める範囲はどこか、変更前にそろえる戻し方は何か、復旧を「直った」と書ける確認は何方向か。営業部窓口にも、変更時間と復旧後の確認内容を短く返しておく必要がある。
次の朝礼までに動かす範囲と、後から進める範囲を分ける
修正の候補を、氷室と並べて紙の上に三つ書く。
ひとつめ。対象アクセススイッチのアクセス側ポート群に、同じ VLAN 内の同報通信が短時間に増えた時だけ抑える設定を入れる。範囲は対象スイッチのアクセス側ポート群に限る。閾値は段階的に決め、戻すのも対象範囲の no コマンド一行だ。
ふたつめ。新人 12 名のグループだけを別の VLAN に移し、営業部 VLAN の収容範囲を分割する。同報通信が広がる範囲そのものを小さくする案だが、新人 PC 側の切替で短時間の通信影響が出る可能性があり、部門責任者の承認も要る。
みっつめ。対象アクセススイッチを上位機種へ交換し、処理能力で押し切る。営業部全体に長時間の影響が出るうえ、戻しにくい。
「みっつめは、止まる人が多すぎますね」と瀬戸が首を振る。
「数分の周期障害に対して、営業部全体を長時間止めるのは合わない」と氷室。「副作用のほうが本事象より大きい修正は、最初に外しなさい」
ふたつめは、向きとしては恒久対処に近い。ただし新人 PC 側の切替に短時間の影響が出る変更で、承認にも時間がかかる。次の朝礼まで時間がないことが、いま手元にある制約だ。ひとつめが残る。同時刻に積み上がっていた観測と、抑える範囲が同じ向きでそろっている。
「ひとつめだけで、本当に新人の PC を放っておいて大丈夫なんですか? 朝礼後に 12 台同時に立ち上がるのが原因なら、利用を控えてもらうほうが早いんじゃないですか」と瀬戸。
「はぁ? なんでそうなるのよ」と氷室。「原因として言えてるのは、同じ VLAN の中で短時間に同報通信が積み上がる構造のほうよ。同時起動は引き金の一つでしかない。新人 PC 側の設定意図も Wake-on-LAN の業務上の理由も、まだ手元では確かめられていないの。原因が確定する前に利用者の運用に手を入れたら、何が効いたか分からなくなるし、新人側に責任が引っ張られる」
「えっと…観測が支えてる範囲と修正の範囲をそろえる、です」
「そう。対象スイッチで同時刻に同報通信が積み上がってる、までは観測で言える。だから対象スイッチのアクセス側ポート群で同報通信が増えた時だけ抑える。範囲も小さく、戻すのも一行よ」
「つまり、新人 PC への運用変更は恒久対処の判断材料として後に回して、いまはアクセス側ポート群だけで動かせる暫定対処を先に入れる、ってことですか?」
「やっとまともな文になったじゃない」
ふたつめの VLAN 分割は「やらない」ではなく「いま即日では動かさない」だ。承認手順をそろえてから別の ticket として進める前提で、報告書には恒久対処の候補として残す。
戻し方を、入れる前に決めておく
修正の方向が決まっても、コマンドを構える前に戻し方を決める。戻すための条件を二つ、氷室と合わせて決める。
- 抑制設定を入れた直後から、想定外の方向で業務通信が落ちる申告が入った場合
- 次回朝礼後の同じ時間に観測した時、対象 VLAN 側の broadcast pps の跳ねや CPU の跳ねに、抑制前と変わらない動きしか見えない場合
このどれかが当てはまったら、対象アクセス側ポート群の storm-control broadcast level と storm-control action trap を no コマンドで外し、変更前の状態へ戻す。戻したあとは、運用リーダーと氷室へ判断を仰ぐ。判断の期限は、次回再現時刻が終わったあと 30 分以内。それ以上長く様子を見ても、次の機会は一週間後にしか来ない。
「戻し方を先に決める、っていうのは、設定を入れる前に書いておくんですか?」と瀬戸。
「ちょっと、今の本気で言ってる?」と氷室。「決めずに入れて、何か起きてから戻し方を考えていたら、戻すまでの時間が延びるでしょう。戻す条件、戻す手順、判断の期限、戻したあとどこへ上げるか、まとめて先に書きなさい」
「つまり、戻る道を確保してから、進む、ってことですか?」
「その分け方なら残せる」
抑制の強さも戻しの設計の一部だ。閾値は最初から絞り切らず、次回朝礼後の counters と cpu の動きを見て段階的に決める。一発で絞ると、効きすぎた時に業務通信を巻き込みやすい。
変更前の状態を保存し、営業部へ短く予告する
実際に手を動かす前に、変更前の確認結果をテキストに残す。
SW-ACC-SALES# show running-config | section interface Ethernet0/
interface range Ethernet0/0 - 3
switchport mode access
switchport access vlan 10
!
! 同報通信が短時間に増えた時に抑える設定は未投入
抑制設定が入っていない状態を、変更前として記録する。
営業部窓口には、変更の予告だけ短く入れる。
朝礼後の数分間ネットがつながらない件、原因の方向が見えました。本日この後、ネットワーク側で予防的な設定をひとつ入れる予定です。業務通信に影響が出ない範囲で組んでいますが、設定後の最初の朝礼の数分間は、念のため通信状況を見ていただけると助かります。完了後、改めて結果をお知らせします。
復旧見込みの時刻は出さない。次回朝礼後の同時刻まで観測の機会が来ない。書くのは変更が入ること、業務通信に影響が出ない方向で組んでいること、次回朝礼後の状況を見てほしいこと、終わったら次の連絡が来ること、の四つだ。
入れる
運用リーダーから承認を取ったあとで、コンソールから設定を入れる。
SW-ACC-SALES# configure terminal
SW-ACC-SALES(config)# interface range Ethernet0/0 - 3
SW-ACC-SALES(config-if-range)# storm-control broadcast level pps <段階的に決めた閾値>
SW-ACC-SALES(config-if-range)# storm-control action trap
SW-ACC-SALES(config-if-range)# end
SW-ACC-SALES# write memory
storm-control broadcast level pps が、同じ VLAN 内の同報通信が短時間にどれだけ増えたら抑えるかを決める設定だ。storm-control action trap は抑制が発火した時に SNMP trap を運用監視側へ送る設定で、装置側の履歴管理ではなく、監視側で発火を拾える経路を用意する役割になる。閾値は初回投入を控えめに置く。
変更後、対象範囲の running-config に抑制設定が並んだことと、show storm-control の Filter State が Forwarding（抑制設定が有効で、現在は通常転送中）になっていることを合わせて見る。投入から数分、業務通信側の追加申告は入ってこない。
「設定が入った確認まで済んだなら、もう完了じゃないですか」と瀬戸が紙を伏せようとする。
「はぁ? なんでそうなるのよ」と氷室の赤ペンが机を一度叩く。「設定を入れた事実と、次に同じ時刻で抑えられる事実を混ぜてるでしょう。今回の障害は月曜の朝礼後にしか出ない。設定後の今日の counters を見ても、もともと跳ねが出ない時間帯よ。判定材料は次回再現時刻にしかそろわないの」
復旧確認は、次回朝礼後にしかそろわない
周期障害では、復旧の判定は次の同時刻まで遅らせる。今日の出力で完了にすると、抑制が効いたか分からないまま来週の朝礼後を迎えることになる。次回朝礼後の同じ時間帯に、確認を三方向そろえる。
ひとつめ、技術的な確認。対象アクセススイッチで、抑制が発火した記録と、broadcast pps の動きを見る。発火そのものは storm-control action trap で送られる SNMP trap を運用監視側で拾い、装置側では show storm-control の Filter State と Current で再現時刻の状態を確認する。
SW-ACC-SALES# show storm-control broadcast
Interface Filter State Upper Lower Current
--------- ----------------- ---------- ---------- ----------
Et0/0 Forwarding <閾値> <閾値> <観測値>
... (Et0/1〜Et0/3 同様)
! 朝礼直後の数分間、抑制が発火している瞬間は Filter State が "Blocking" に
! 切り替わり、Current が閾値を超えている。数分後に Forwarding へ戻る。
SW-ACC-SALES# show interfaces counters ! 影響時刻の二点取得で増分を比較
Port InOctets InUcastPkts InBcastPkts InMcastPkts
Et0/0 <観測値> <観測値> <観測値> <観測値>
朝礼後の同じ時刻に、運用監視側へ storm-control 由来の SNMP trap が届き、装置側でも一時的に Filter State が Blocking へ切り替わる瞬間がある。抑制前は桁違いに跳ねていた InBcastPkts の増分が、影響時刻の二点差分でも緩和される、という方向で並ぶ。
ふたつめ、CPU の動きを見る。グラフ用途と、その時刻にどのプロセスが上位にいたかを別の出力で見る。
SW-ACC-SALES# show processes cpu history
CPU% per minute (last 60 minutes)
60
50
40
30
20 *
10 * * **
0 ## #####################
SW-ACC-SALES# show processes cpu sorted 1min ! 影響時刻に取得し、上位プロセスを確認
PID Runtime(ms) Invoked uSecs 1Sec 1Min 5Min TTY Process
... （CPU を多く使ったプロセスが 1 分平均で上から並ぶ。抑制後は上位の数値も平常水準に近づく方向）
抑制前の続報では、影響時刻に CPU 利用率が桁の上で跳ねて数分で平常へ戻る出方だった。抑制後は同じ時刻でも、history グラフが平常水準に近づき、sorted 1min で上位のプロセスの値も抑制前より低くなる方向に動いていれば、処理の詰まりが緩和された方向だ。
みっつめ、利用者確認。営業部窓口経由で、朝礼後の業務開始時に通信状況を確認する。
今週は止まっていません。普段の月曜と違って、朝礼後すぐに共有フォルダが開けました。
「直りました、って書きそうになりますね」と瀬戸。
「『何が直ったか』を分けて書きなさい」と氷室。「抑制設定が発火したこと、broadcast pps の跳ねが緩和されたこと、CPU の跳ねが平常に近づいたこと、業務利用の感覚で詰まらなかったこと。それぞれ別の観測なの。一つだけだと、別の理由でたまたま今週だけ静かだった可能性が残るの」
「つまり、抑制発火、broadcast の跳ね、CPU の跳ね、業務利用の感覚、これだけそろって初めて『次回朝礼後の数分間は抑えられた』と書ける、ってことですか?」
「やっとまともな文になったじゃない」
営業部へ返す、短い完了共有
営業部窓口へは、別の経路で短い完了連絡を入れる。
朝礼直後の数分間ネットがつながらない件、ネットワーク側の設定変更が完了しました。次回朝礼後の同じ時間帯の観測で、止まる時間が短くなる、または止まらない方向に出ています。これまで朝礼の数分間に使っていた口頭連絡や紙のメモは、通常の運用にお戻しいただいて問題ありません。同様の症状が再発した場合のみ、改めてご連絡ください。
復旧したこと、通常の運用に戻ってよいこと、追加連絡が必要な条件、の三つだ。同報通信や閾値、新人 PC の話は、営業部窓口が業務を回す判断に使う情報ではない。
氷室に残す報告書
確認がそろったあとで、報告書を六つの欄に分けて組み立てる。暫定対処と恒久対処は同じ報告書の中で分けて並べる。
-
復旧した事実
毎週月曜の朝礼直後に営業部だけ数分間ネットワークが止まっていた事象について、対象アクセススイッチのアクセス側ポート群に、同じ VLAN 内の同報通信が短時間に増えた時だけ抑える設定を投入。次回朝礼後の同じ時間帯に抑制発火の履歴が残り、broadcast pps と CPU の跳ねが緩和され、営業部窓口経由で業務利用に支障が出なかったことを確認した。
-
原因として言える範囲
対象アクセススイッチで、朝礼直後の数分間に同報通信が短時間に積み上がり、スイッチ処理が一時的に詰まる現象であった。引き金は朝礼の終わる時刻に重なる端末群の同時起動。続報で同時刻の broadcast pps の桁違いの増加、CPU 利用率の跳ね、新規 MAC 学習の短時間集中が同じ向きで揃い、抑制投入後に反対側で同じ向きの動きが見えたことで、観測の向きが補強された。
-
まだ言えない範囲
新人 PC が待機時にも同報通信を送り出す設定の構成と、その設定がいつ・誰の判断で有効になったか。Wake-on-LAN の運用を業務上残す理由。同様の事象が過去に同じスイッチや他フロアの収容スイッチで起きていたかの長期推移。
-
実施した修正（暫定対処と恒久対処の分離）
- 暫定対処: 対象アクセス側ポート群 Ethernet0/0 から Ethernet0/3 に
storm-control broadcast level pps <段階的に決めた閾値>とstorm-control action trapを投入。閾値は次回朝礼後の counters と CPU の動きを見ながら段階的に決定。変更前の running-config を保存。切り戻し手順は対象範囲でno storm-control broadcast levelとno storm-control action trapを投入して変更前へ戻し、運用リーダーと氷室へ判断を上げる形で事前に確定。判断期限は次回再現時刻が終わったあと 30 分以内。 - 恒久対処: 新人グループの別 VLAN 分離と営業部 VLAN の収容範囲見直しを、別の ticket として記録。変更影響と承認手順をそろえてから着手する。
- 暫定対処: 対象アクセス側ポート群 Ethernet0/0 から Ethernet0/3 に
-
検証結果
- 設定確認:
show running-configで対象アクセス側ポート群にstorm-control broadcast levelとstorm-control action trapが並ぶことを確認 - 抑制発火確認: 次回朝礼後の同じ時間帯に、運用監視側で
storm-control由来の SNMP trap を受領し、装置側show storm-control broadcastでFilter Stateが一時的にBlockingへ切り替わったことを確認 - broadcast 跳ね確認: 影響時刻の前後で
show interfaces countersを二点取得し、InBcastPktsの増分が抑制投入前と比べて緩和されたことを確認 - CPU 跳ね確認:
show processes cpu historyで影響時刻周辺の CPU 跳ねが平常水準に近づき、show processes cpu sorted 1minでも上位プロセスの値が抑制前より低い方向に動いたことを確認 - 業務利用確認: 営業部窓口経由で、次回朝礼後の数分間に社内システムと共有フォルダの利用に支障が出なかったことを確認
- 設定確認:
-
記録へ戻す事項
- 部署別の収容範囲と、新規端末を VLAN へ追加する時の確認手順を、運用部の定例の候補に上げる
- 朝礼後の周期障害として運用ログへ記録し、次の同種申告で counters と CPU を最初に重ねる手がかりとして残す
- 暫定対処の閾値と抑制発火履歴を定期的に見直す。効きすぎ方向と効かなさすぎ方向の両方を見る
- 恒久対処（別 VLAN 分離）の判断条件と着手目安を、設計課と運用部の定例で議題に上げる
- 新人 PC の同報送信設定と Wake-on-LAN 運用の業務上の理由を、運用部と人事側で確認する候補にする
「直したから終わり」と書かない理由
「未確認のところを、報告書から消したくなりますね」と瀬戸が紙の余白を見る。「抑制が効いて朝礼後の数分間が静かになったんだから、新人 PC の設定意図とか Wake-on-LAN の業務上の理由とか、書かなくても困らないんじゃないですか」
氷室の赤ペンが机を一度叩く。「いま入れたのは、対象スイッチで同報通信が増えた時だけ抑える設定よ。同じ VLAN の中で同報通信が増える構造そのものは、まだ残ってる。新人 PC 側の設定意図を未確認のまま残しておけば、将来、別フロアの別の VLAN で同じ事象が出たときに最初に当たる先として残せる。確定として閉じてしまうと、その情報経路が無くなるの。暫定で抑えた事実と、恒久で根を切る話を、同じ欄にまとめない」
「つまり、まだ言えない範囲と恒久対処の計画は、報告書から消さずに別の欄として並べておく、ってことですか?」
「やっとまともな文になったじゃない」
報告書の三つめの欄にはまだ言えない範囲が並び、四つめの欄では暫定対処と恒久対処が別の段落として分かれている。観測で言える範囲と言えない範囲、いま動かした範囲と後で動かす範囲が混ざらずに並ぶことが、次の対応をしやすくする。
朝礼の後の数分間が、また同じように戻ってきた時のために
報告書が氷室の手元に渡る。営業部窓口にも、別の経路で短い完了共有が入っている。新人グループの別 VLAN 分離、新人 PC の同報送信設定と Wake-on-LAN 運用の確認は、別の ticket として運用部と設計課の定例に乗る。ここまでで、毎週月曜の朝礼直後に営業部だけ数分間止まる事象は、技術的にも業務的にも、いったん閉じる。
机の上には、修正候補の紙、変更前後の設定の紙、次回朝礼後の確認の紙、恒久対処の候補の紙が並んでいる。順に重ねていって、一番下に来る紙が報告書だ。修正候補、戻し方、次回朝礼後の確認、未確認事項の紙が、報告書の六つの欄にそのまま残る。どれか一枚でも欠けていれば、報告書のどこかの欄が薄くなる。