筆致についてはタイトル毎に統一されていません。あらかじめご了承ください。
本件はフィクションであり、実際に発生した事象に脚色を加えております。
シリーズ記事一覧：
【現場SE奮闘記 VOL.2】 「天狗となったエンジニア」~FortiGate NATの仕様編~

プロローグ

災害大国、日本。
内閣府の防災白書には以下のように綴られている。

我が国は，その位置，地形，地質，気象などの自然的条件から，台風，豪雨，豪雪，洪水，土砂災害，地震，津波，火山噴火などによる災害が発生しやすい国土となっている。
災害を受けやすい日本の国土

逆に、災害が発生しにくい国も存在する。
プレートの性質によっては、地震が発生しにくいとされ、古い遺跡が残存している国もある。
また、内陸国での津波や、ヨーロッパでの台風による被害はまれだ。
このように「陸海空」の災害は地域によって発生する、しないが決まっているものだ。

しかし、サイバー空間には地域を問わず、人工的に発生しうる「災害」が存在する。
ここに綴るのは、私の愛すべき後輩が社内ネットワークにて「嵐」を引き起こし、一部のネットワークを利用できなくした記録である。

ネットワークの「嵐」、ブロードキャストストーム

ブロードキャストストームとは、データリンク層で起こるフレームのループに伴う機器障害のことである。
よくあるブロードキャストストームの発生原因は、スタックやVlan設定、LAGなども組まずに二つのスイッチを結線して通信を流すというものがある。
（かくいう私は自分が作った検証環境において、Vlan設定を後で入れようと思い、2つのネットワーク機器間を2本のケーブルで結線したときにブロードキャストストームを引き起こしたことがある。）

慣れてくると、ブロードキャストが発生しそうな構成に気が付けるようになるものだ。

嵐、起く

私がいつものように、検証サーバからBIG-IPへ鼻歌交じりにリクエストを投げていたところ、急に通信ができなくなった。

通信障害。

私は、検証環境でスイッチをいじっていた後輩、K君のもとに向かった。
検証環境は1台のFortiGateを中心に構成されており、恐らくFortiGateが障害の原因だろうとは一瞬であたりがついた。

「Kくん、いま検証環境ダウンしたっぽいんだけど、何か心当たりない？」

「いやー、ちょっと心当たりないです。」

「どういうことをしていたか教えてもらってもいい？」と他の後輩であれば、聞き返していただろう。

しかし、彼となると話は別だ。
彼は入社当時から情報処理安全確保支援士資格、ネットワークスペシャリスト資格を保持しており、ネットワークに関しては私よりも遥かに詳しい。
また、業務においては作業も報告も正確だった。そんな彼が「心当たりがない」と言ったのだ。私は彼を疑うこともなく、障害対応に立ち会うことになった。

だが、この時の小さな違和感を無視したことを、のちに後悔することになる。

なにがはっせいした？

私とK君はサーバルームで障害対応を始めた。しかし、FortiGateのWebの管理画面からは一向に応答が返ってこなかった。

「筐体に負荷がかかっているんじゃないか。」

「FortiGuardの更新とかによる不具合で、CPU使用率が上がってるんですかね。」

こんなことを言いながら、FortiGateの不具合に関するつぶやきを探してみた。しかし、不具合が起きているのは1台だけのようだった。

「検証機だし、一旦機器を再起動してみるか。それが原因でFortiが壊れたら、私がみんなに謝っとくよ。頭こすりつければ許してもらえるんじゃないか。」

「じゃあ、コンソールからrebootしてみます。」

沈黙の後、再び目を覚ましたFortiGateだったが、徐々に機嫌を悪くしていった。
会話がなくなり、エンジニア二人の重くなった雰囲気を察してか、ある重役がCPUファンの重奏響くサーバルームに現れたのだった。

FortiGate取り扱いのスペシャリスト、セキュアヴェイルグループLogStare社 堀野取締役である。
弊社の技術出身の取締役と同じく、自宅でFortiGateを運用している。
また、前職では日本のセキュリティを支えるとある会社で、あらゆる構成でFortiGateを導入してきた。

私はFortiGateの専門ではないが、堀野取締役が玄人のそれであることは、明らかだった。
原因不明な中、多忙の堀野取締役にお時間を割いていただいた。

堀野取締役は、迷いなく以下のコマンドを実行した。

diag sys top
src-vis      229      R      64.5     1.2    6

src-visというプロセスがかなり重い。
src-visはソース可視化のデーモンだ。

diagnose src-vis stats　を実行すると以下のような結果が出力された

analyzer.arp.packets: 452824410
analyzer.arp.bytes: 20829899554

4億、20GBのarpが受信されていた。

これは、機器を一度再起動した直後であった。

（半年以上起動している弊社東京オフィスを保護するFortiGateは現在、500万、162MBとなっている。）

「あ、これブロードキャストストームじゃない？」

堀野取締役の一声が、さながら嵐の中にとどろく一閃の雷鳴のような衝撃をサーバルームに与えた。

私の経験上、ブロードキャストストームは直前の作業によって発生することが多い。
K君が沈黙したまま、自分が作業していたPCの前に戻り、能面のような無表情でスイッチの設定を確認し始めた。

「すみません、スイッチのvlanのrange指定の範囲が広すぎました…」

嵐は止んだ、嵐は止んだのである。

今回の反省点

人を疑わないというのは美しいことだが、エンジニアにおいてはどうであろうか。そんな哲学的な問いを投げかけられたようだった。我々エンジニアは事実を基に行動をしなければいけない。

後輩が試験結果を報告してきたときにはどのようなコマンドで、どういった方法で確認したのかを明らかにするべきであり、逆もまたしかりである。

K君の作業が問題ない、つまりネットワークレベルの問題ではないと考えてしまったために、インターフェースのランプの点滅にも気が回らなかった。
エンジニアの最大の敵は、「思い込み」なのだとひしひしと感じさせられた。

精神的なものとは別に、障害切り分け時の手札を増やさないといけないことも同時に感じた。
堀野取締役のように、FortiGateの仕様を理解し、CLIからデバッグを行えるレベルにならなければならない。

今回の嵐が過ぎた後に、自身の進むべき道がはっきりとみえ、晴れ渡るような気持ちになった。

補足・追記

セキュアヴェイルは作業時には必ず2名体制のダブルチェックのもと、設定変更を実施しております。
内部検証環境の構築だったため、発生してしまった不幸な事故でした。

ブロードキャストストームの対策はいくつもあります。
・スイッチでループ検知機能を有効化する
・スパニングツリープロトコル（STP）を有効化する
・トラフィック量制限をする　等
一番手軽なのは、ループ検知機能だとはおもいますが、ループ検知時にスイッチが積極的にインターフェースをダウンする仕様なのかは確認しましょう。

ケーブルの片端のみをスイッチに挿して、もう片端がどの機器にも挿さっていない場合に、エンジニア以外の方が、良かれと思い片端を同じスイッチに挿してしまう事故が少なからずあるようです。（同じスイッチの別ポートが同一のケーブルで結線されてしまう。）
この場合にもブロードキャストストームが発生するので、エンジニア以外の方が触れるスイッチにはポートをコンフィグから落とすほか、使わないケーブルは残さない等の対策を取りましょう。

記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。

当社製品以外のサードパーティ製品の設定内容につきましては、弊社サポート対象外となります。