インフラまわりのプロになりたい

しかもサーバルームには職員さんたちがアクセスしているメールサーバ、ファイルサーバや SIP サーバなどがあり、そのサーバルームがダウンしたことで 職員さんたちの業務が止まってしまいました 。


↑図1：正常だったサーバルームが…。



↑図2：UDP パケットの暴走によりダウン。もう頭が真っ白。。。


こういうときの対処法はただ一つ。UDP パケットを絶えず投げ続けるテストマシンを シャットダウン させることです。LAN ケーブルを引っこ抜く ことも有効ですが、そこまで頭が回らなかった。。

幸いにもサーバルームの停止が 10 分程度（それでも重大）で済みましたが、ダウンした瞬間にシステム室には職員からの問い合わせが殺到。対応して下さった先輩をはじめ、各部署の方々には本当にご迷惑をおかけしてしまいました。。。

そこで今回はこの失敗を無駄にしないためにも、同様の現象であります 「ブロードキャストストーム」 についてメモしていこうと思います。

---

ブロードキャストとは

普段なにげなく使っている TCP/IP ネットワークの通信ですが、この通信には大きく分けて 3種類 の通信方法があります。通信相手の少ない順に書いていきますと、「ユニキャスト（1対1）」 「マルチキャスト （1対n）」 「ブロードキャスト （1対 ALL）」 といったところでしょうか。

　1．ユニキャスト通信
　2．マルチキャスト通信 ← 今回は華麗にスルーいたします
　3．ブロードキャスト通信

まず ユニキャスト通信 ですが、これは送信先が1つと決まっている通信を指しており、決められた相手以外とは通信を行いません。たとえば特定の一人の相手にファイルを送信したいときはユニキャスト通信をしますし、Google でインターネット検索したいときなども Google サーバへユニキャスト通信 していることから、意識をすればあらゆる場面でユニキャスト通信をしていることが分かると思います。


↑図3：ユニキャスト通信

一方の ブロードキャスト通信 ですが、これは送信先が同じネットワーク内の全てのノードに対する通信を指します。ブロードキャストはユニキャストとは違って、ユニキャスト通信を始める 「前準備」 に使われることが多いため、普段はあまり意識することはありません。


↑図4：ブロードキャスト通信


もしこれらをドラ○エの呪文でたとえるなら、、、

　1．ユニキャスト通信 → メラ （敵 1 人に有効）
　2．マルチキャスト通信 → ギラ （敵グループに有効）
　3．ブロードキャスト通信 → イオ （敵全体に有効）

こんな感じになるんですかね（笑）。


続いて、ブロードキャスト通信についてもう少しメモします。以下 DHCP を例に挙げます。

DHCP は IP アドレスを動的に割り当てるプロトコルで、通常ならクライアントマシンの IP アドレスを手動で設定すべきところを、DHCP サーバへリクエストメッセージを投げるだけで IP アドレスが付与されるという、とても便利で管理のしやすい仕組みのプロトコルです。


↑図5：DHCP のハンドシェイク

ところがネットワークは IP アドレスを持っているノードに限りユニキャスト通信ができますので、IP アドレスを持っていないノードはユニキャスト通信ができません。

たとえば DHCP サーバが IP アドレスを管理しているネットワークに新しいクライアントマシンを設置すると、クライアントマシンは 「IP アドレスをください」 というメッセージを DHCP サーバへ投げる必要がありますが、これをユニキャスト通信で試みるとどうなるでしょうか。そもそもクライアントは IP アドレスを持っていませんので、たとえ DHCP サーバの IP アドレスを知っていたとしてもユニキャスト通信するすべがありません。


↑図6：IP を持っていないとユニキャストできない

そこで登場するのがブロードキャスト通信です。ユニキャスト通信ができないクライアントは 「IP アドレスください」 というメッセージを ブロードキャスト送信 します。ブロードキャスト通信は同じネットワーク内の全てのノードに対してデータを送りますので、ブロードキャストしたメッセージは DHCP サーバへ必ず届きます。またメッセージを受け取った DHCP サーバも、クライアントの MAC アドレス をもとにオファーメッセージをブロードキャストし直せば、メッセージは確実にクライアントへ送り返せるようになっています。


↑図7：ブロードキャストを使ってパケットを送れる


このようにブロードキャストした通信は、同じネットワーク内に属するノードであればデータが確実に届く仕組みになっています。しかしこれは言い換えるなら 関係ないノードまでデータを受け取ってしまう ため、ユニキャストに比べてネットワーク回線などに負荷をかけやすい傾向にあります。

---

ブロードキャストストームとは

ブロードキャストストームを一言で表すとしたら 「ブロードキャスト パケットの無限ループ」 です。

基本的にブロードキャスト通信やユニキャスト通信は無限ループする仕組みにはなっておらず、ハブや LAN ケーブルを正しく設置していれば、今回僕が引き起こした パケットの暴走 などしない限り、回線が落ちることは基本的にはありません。


↑図8：いたって平穏なハブと LAN ケーブルの組合せ

ところが LAN ケーブルを挿し間違える などのボンミス行為がきっかけで、ハブ同士が ループ構造 になってしまうとサァ大変。Client A から送出されたパケットが HUB A に届いた瞬間に 2本 の LAN ケーブルそれぞれにパケットをフラッディングし、そのパケットを受け取った HUB B は Client B と HUB A へとフラッディングし、次は HUB A が………とパケットの無限ループが発生。一瞬のうちにパケットが届く範囲 （ブロードキャストドメイン） 内の回線がパンクしてしまい、ネットワークがダウンしてしまいます。


↑図9：無限ループ

ブロードキャストストームを防ぐには LAN 配線をループ構造にさせないことが第一ですが、こういったループ構造によるネットワークダウンを回避するプロトコルが存在します。それが 「スパニングツリー (Spanning Tree)」 です。

---

スパニングツリー

これは物理的なループ構造である LAN 配線を論理的にループ回避する方法です (IEEE 802.1D)。

仕組みはいたって単純で、ループが働いてしまっている機器 （ハブやスイッチ） のポートを無効化させる、というものです。こうすれば論理的にループ構造が解除され、ブロードキャストストームが止まってくれます。


↑図10：ポートを無効化


どのポートを無効化させるかは BPDU (Bridge Protocol Data Unit) フレームを使って決まります。動きとしては、同セグメントに属する全てのスイッチが BPDU を交換し合い、そこから帯域幅などの経路情報からコストを算出して不要と判断したポートの機能を止めます。


↑図11：BDPU の交換


もともとこのスパニングツリーはループ防止対策に使われるプロトコルでしたが、冗長化のアップにも使われることがあるそうです。なるほど。。。


↑図12：冗長化のアップ


あとルータにはスパニングツリー機能は搭載していないことが多いです。その理由はとても単純で、ルータはレイヤー3、フレームでなくパケットを扱うからです。パケットの TTL (Time To Live) が 0 になり次第パケットを破棄してくれるってことですね。パケットとフレームの違いの理解に一歩近づいた瞬間ｗ。


↑図13：青色が僕の知っている項目。まだ全然少ないｗ


残念ながら今はスパニングツリーを検証する環境がありませんので、せめて仕組みだけでも頭に叩き込んでおきます。今後、検証する機会が訪れたときには更に詳しくメモしていく予定です。

---

実験

意図的にブロードキャストストームを作り出す実験を行ってみます。

とはいっても内容は簡単です。レイヤー2のスイッチングハブを2つ用意し、互いに LAN ケーブルを挿し合ってループ構造のネットワークに PC を接続するだけです。PC は勝手にブロードキャストパケットを放出してくれますので、何か操作をする必要もありません（図9の状態です）。

ちなみにこのとき PC が放出したブロードキャストパケットは 「SSDP (Simple Service Discovery Protocol)」 でした。これは UPnP で使われるプロトコルですね。


ではさっそく、ループ構造のハブに Wireshark を起動させた PC を接続 （LAN ケーブルを挿す） しました。すると数秒した後 Wireshark がフリーズ。同時にハブのアクセスランプが勢いよく点滅し始めました。また、このとき ncpa.cpl からネットワーク接続画面を確認したところ、ローカルエリア接続がグレーアウトしていました。PC のネットワーク機能が停止してしまったようです。


↑図14：タスクマネージャ。凄まじい負荷がかかってます。


しかも、このときの CPU 使用率は 40%弱 を記録。使っていたマシンの CPU は Core i7-3610QM が詰まれており、ノート PC の中でもそこそこ （現時点では） 性能の高いモノだったことからフリーズは間逃れましたが、もっと性能の低い CPU を使っていたら、マシンがフリーズしていたかもしれませんね。


↑図15：CPU もかなりの負荷


ブロードキャストストームが発生して 約5秒 が経ったあと、ハブから LAN ケーブルを引っこ抜いたところ、ハブのアクセスランプが落ち着き始め、しばらくして PC のネットワーク状態が復旧しました。そして Wireshark の画面を確認したところ――なんと 400万以上 のパケットを受信し、そのデータ量はなんと 900MB強 でした。


塵も積もればなんとやら、たった数 byte の SSDP パケットがここまで膨れ上がるとは思ってもいなかった…。恐るべし、ブロードキャストストーム。。。

---

最後に

なんか最近、失敗ばかりしている気がします。

先々月は客先のサーバで Kernel Panic を引き起こしダウンさせてしまった。そして今回は自分が勤める病院のサーバルームまでもダウンさせてしまった。なんか デモリションマン になっている今日この頃。。

失敗とは嫌なものですよね。 トラブルに気づいた瞬間の （うわぁ…やっちった…） という瞬間に味わう心地の悪い心境、あれは何度経験しても慣れません…。でも一方で、直った瞬間の （ちょｗｗｗ直った嬉しいｗｗｗｗ） という瞬間は、ガッツポーズのようなホッとするような……そんな心地の良い心境でもあります。

でもインフラまわりのプロを目指す以上、職員に迷惑をかけることもっての外。いかにシステムを安定させるか、これに徹底しなければなりません。インフラまわりは日陰者の僕にはピッタリな仕事ですが、いかんせん仕事のミスもまだまだ多い。改めて気を引き締めなおした、そんな出来事でした。