このページは乱ことNobuoNakakoが運用する「Etherealを使おう」の一部です。お時間があれば表紙も訪れてやってください
リンク等についてはこちら。間違いを見つけた時や「ここはこうした方が良い」等の意見は遠慮なくこちらまで。
The Ethereal manual (WINDOWS&UNIX)
|
ブロードキャストストーム
|
障害対応 | ||||||
|
私の経験では「ネットワークがダウンした」という話しをでその原因を聞くと多くの解答にブロードキャストストームという言葉が入ります。 ブロードキャストストームは非常に単純に発生し、対策をとっていないとほぼすべてのネットワークが完全に沈黙します。Etherealはこの手のストームが発生した場合、その発生原因を知るのには非常に有効なソフトです。 ここでは下記の手順に従ってブロードキャストストームの概要とEtherealを使った原因の発見、障害対応にいて解説していきます。
「ブロードキャストストームは滅多に発生しない」という言葉を昔は聞いた事がありますが現在のスイッチングHUBの性能の向上に伴いこの現在はこの言葉は間違いとなりつつあります。 ブロードキャストストームは一般的にHUBとHUBの接続を間違えた時に出るのですが(ブリッジとブリッジでももちろん出ます)、従来のHUBはHUB同士を接続する場合、クロスケーブルを用意するかカスケードポートに接続するというのが常識でした。 しかし、現在復旧しているスイッチングHUBの多くはこのクロスを自動認識し、どのポートでもカスケードができる様になっているのが多いです。 従って、現在は昔に比べてケーブルの挿し間違いによりブロードキャストストームが発生しやすくなるのです。 ●スイッチングHUBの機能を知る ブロードキャストストームを知ると共に同時にスイッチングHUBの機能を知る必要があります。(ブリッジもほぼ同様です) スイッチングHUBと言うと一般的にはレイヤー2スイッチを指します。レイヤー2スイッチはその名の通り、IOS参照モデルのレイヤー2レベルでの信号の制御をするスイッチングHUBになります。 たとえば以下の様にケーブルをさしたとします。
この場合、青いケーブルは1番ポート、緑のケーブルは3番ポート、ケーブルは5番ポートにささっています。 それぞれのケーブルに繋がっているPCのMACアドレスは実際には12桁の英数字ですが分かりやすい様に各MACアドレスは青いケーブルはA緑はB赤はCとします。 同様にそれぞれIPアドレスは青をAA、緑をBB、赤をCCとします。 この時点でのスイッチングHUBのテーブルは以下の様になっています。(このテーブルは最初の信号が行われた時点で自動的に学習されます。)
たとえばMACアドレスAのPCからIPCCの赤いケーブルに繋がっているPCに対して下記の様にPingを打つとします。 ping CC そうするとスイッチングHUBは1番ポートのPCから来た信号を5番ポートに送ります。これがスイッチングHUBではなく通常のリピータHUBである場合は1番ポートから来た信号は3番ポートにも同時に発信されてしまいます。 つまりスイッチングHUBは誰宛の信号かを判断して必要なポートのみに信号を流します。 ●ブロードキャスト信号を知る ではスイッチングHUBではMAC=AのPCはMAC1=BとMAC=Cの2つのPCに同時に同じ信号を発信する事はできないのでしょうか? 結論から言うとできます。その様にする場合にはブロードキャストやマルチキャストといった複数のIPやMACに対して発信する方式で信号を送ります たとえば192.168.0.1/24(255.255.255.0)というネットワークが存在するとします。このネットワークは255個のIPが存在します。 実際に使用できるのは192.168.0.1〜192.168.0.254までで0と255という番号は特殊な意味を持ちます。この255がブロードキャストアドレスといわれ192.168.0.255というアドレスで192.168.0.1〜192.168.0.254までのアドレス全てを意味します。 このブロードキャストアドレスはIPだけではなくMACアドレスにも存在します。MACアドレスのブロードキャストアドレスはFF:FF:FF:FF:FF:FFを使用します。 実際に下記の様にpingを打つとするとPingのリクエスト信号は192.168.0.1から192.168.0.254まですべてのPCに対して信号が配信されます。 ping 192.168.0.255 上記のキャプチャデータを見てみましょう(実際は色付けされていません)
サンプルデータはココでダウンロードできます。開き方は「キャプチャ結果を開く」で参照して下さい これは送信元(Source)が発信したping情報です。Destination(宛先)が192.168.0.255のブロードキャストアドレスになっています。それでは1行目の詳細情報を見て下さい。
注目してほしいのがEthernetフレームの情報です。Srcの08:00:46:53:f8:34はPingを発信したPCのMACアドレスです。宛先はブロードキャストアドレスであるff:ff:ff:ff:ff:ffになっています。 これはスイッチングHUB(ブリッジ)は基本的にMACアドレスのみを見ているのでブロードキャスト信号を出す場合、IPのブロードキャストアドレスだけでは発信されない為です。 このMACアドレスff:ff:ff:ff:ff:ffがブロードキャストストームを発生させるのです。 ●ブロードキャストストームを発生させるネットワーク構成を知る まず下の様な非常に単純なネットワークあるとします。
通常に下記の様にpingを打つとします。 ping 192.168.0.3 この場合、信号は 次にブロードキャスト信号を発生させる為に192.168.0.5から下記の様にpingを打つとします。 ping 192.168.0.255 この場合、信号は正常に この様に上記のネットワーク構成ではブロードキャスト信号も正常に発信されます。 次に下記の様に赤いケーブルを足してネットワーク構成を変更したとします。
この時下記の様にブロードキャスト信号を出したとします。 ping 192.168.0.255 当然192.168.0.2にも192.168.0.3にも黄色いカスケードケーブルを伝って発信されます。その後にブロードキャスト信号はすべてのポートに信号を出さなければならない為、赤いケーブルにもブロードキャスト信号が発信されます。 赤いケーブルを伝ってスイッチHUB=Xからブロードキャスト信号をもらったスイッチングHUB=Zは発信元の192.168.0.5と更にカスケードケーブルに再び信号を流します。 カスケードケーブルを伝ってブロードキャスト信号をもらったスイッチHUBは再度192.168.0.2と192.168.0.3に信号を送りまた赤いケーブルにブロードキャスト信号を流します。 これにより
これだけではありません。この信号が一回回転するごとに再度 当然ルータやPCはフリーズしHUBは力続くかぎり信号を流し(回転)つづけます。これがブロードキャストストームと言われるものなのです。 「ブロードキャスト信号を発生さえしなければストームは発生しないのでは?」という考えは間違いではありません。しかし、通常、ネットワークにブロードキャスト信号はつきものです。 PCが出すブロードキャスト信号にはARPやNetBIOS(Windows)、ルータが出すRIP等非常に多くの種類があります。この手の信号は定期的にPCから出力され、新規にPCをネットワークに接続した際にもいくつかかならず発生します。 従ってブロードキャスト信号が流れないネットワークを作成するのは非常に困難なのです。 ストームが発生しているかどうかを判断するには4つほどあります。 まずスイッチングHUBのLEDを確認するのが一番です。ストームが発生するとHUBのLEDは規則正しく異常とも言えるほど常に点滅しつづけているはずです。とは言っても頻繁に点滅しつづけるLEDはストームが発生していなくてもけっこうあるものです。私の仕事場でも常に点滅しているポートは多くあります。 次にもしできるのであれば接続されているPCやルータ等のすべての電源を切っても点滅しつづけるかどうかを確認します。これはストームの大きな特徴です。ストームが発生していると実はループの原因になっているケーブルを切断しないかぎりはそれこそHUBの命がつきるまで点滅し続けます。 3つめは私もよく使う手ですが(とはいっても今まで1回しかやったことない)スイッチングHUBにスイッチングHUBを接続してみるという事です。つまりストームが発生しているネットワークのスイッチングHUBに通常のHUBを接続するとそのHUBのLEDも同じ様にLEDが頻繁に点滅しだします。この様にストームはHUBからHUBへ感染します(この表現が正しいかどうかはわからないが) 4つ目はストームが発生しているHUBにEtherealを搭載したPCを接続してキャプチャする事です。その際注意しなければならない事が何点かありますので以下の「Etherealでストームの発生原因を突き止める」を必ず読んで下さい。 やっと本格的なEtherealの説明に入れます。ここまで読んだ人はごくろうさまです。 まずEtherealでストームをキャプチャするには以下の様な注意が必要です。相当処理能力が高いPCでないと「接続してはいキャプチャ」という訳にはいきません。 尚、基本的なEtherealでのパケットキャプチャ方法については「キャプチャの手順」で解説しています。 ●Etherelのキャプチャ設定に注意する ブロードキャストストームは1秒間に数千を超えるパケットが常に流れています。したがってキャプチャする設定に注意しなければならない点が何点かあります。 まず実際の設定をした[Capture]→[Start]をクリックした後のキャプチャオプション画面では下記の通りが一番と思われます。
●Etherelaは前もって起動しておきキャプチャも開始しておく HUBに接続する前にEtherealは前もって起動してキャプチャも開始しておきます。繋げてからキャプチャを開始しても反応しない事がよくあります。 ●できる事ならばストームが発生しているHUBに直接繋げない できる事ならばスイッチングHUBをもう一台用意します。そこにEtherealを搭載したPCを繋げてしばらくしてからストームが発生しているHUBに接続します。 まずストームが発生しているHUBに接続する前にEtherealのPCをHUBに接続しておく事が必要です。これはEtherealを搭載したPCのNICが接続確立した際に出すブロードキャスト信号をまずストームが発生しているHUBに繋げる前に出させる為に行います。 ●HUBに接続した状態でキャプチャの停止を行わない これは「行わない」というより「行えない」と言った方が正しいかもしれません。キャプチャを開始すると下記の用なキャプチャウィンドウが立ち上がると思います。
ここにある[Stop]をクリックする事によりキャプチャを停止させる事ができますがまずHUBからLANケーブル等のケーブルを抜いてしばらくしてからクリックして下さい。 下記のPingによるストーム発生をサンプルに解説していきたいと思います。
サンプルはココで入手できます。開き方は「キャプチャ結果を開く」で参照して下さい 1行目を見て下さい
まずブロードキャストを発信したPCのIPが[Souce]を見る事で分かります。発信元は192.168.0.5となります。発生要因もICMPのEchoという事でPingと判断する事ができます。 さて、単純に考えると192.168.0.5のPCを落とせばストームはおさまるかの様に見えます。もちろん先ほども述べた様に実際はそれではストームはおさまりません。 又、よく勘違いされますが192.168.0.5が接続されたスイッチングHUBを切断しても下記の様なネットワーク構成の場合はおさまりません。
ループの要因はPC=Aの192.168.0.5ですが原因は 他にもよくストームが発生するネットワーク構成図として下記の用なリング形式のネットワークを構築した場合があります。
この場合はスイッチングHUBに接続されているどのカスケードケーブルを抜いてもストームはおさまります。従って「正しいケーブルなのに抜いたら直った」と戸惑う事が多多あります。
ジョークで作ってみました(笑)フルメッシュです。こうなるとネットワーク管理者はまず眠れません一本や2本抜いただけではなおらないでしょう。まあまずこんな事はないでしょうけど・・・・汗
ブロードキャスト信号を発生させない様にするにはネットワークに輪を書かない事と言えばそれだけですが。どうしても輪をかかなければならない場合もあります。 たとえばHUBをカスケードするケーブルが本店、支店間の専用線等で非常に長い場合、ケーブルが「切れる」という危険性があります。この場合当然ケーブルを2重化してバックアップを取るという形をとる事が多いです。その場合ネットワーク構成としては下記の用になります。
当然これではスイッチングHUBであるXとYの間でストームが発生します。そこで登場するのがSpanning-treeというプロトコルです。 Spaning-tree(スパニングツリー)は上記のような円を描いたネットワークでもループを発生させないようにする為にDEC社によって開発されたプロトコルです。Spanning-treeのプロトコルの企画には有名なIEEE802.1dやラピッドSTP(IEEE802.1w)等が存在します。 ここではCISCOのスイッチであるCatalyst等が使用しているIEEE802.1dについて解説していきたいと思います。 Spanning-treeを搭載したスイッチングHUB同士を接続すると下記の3つの事が自動的に決められます。
さて上記の事項はすべて自動で決定される訳ですが、これを上記のネットワーク構成図に反映させると以下の様になります。
とりあえずCISCOのCatalystの場合、スイッチのプライオリティはデフォルトで32768(0x8000)ですのでプライオリティは両方とも同じです。MACアドレスはスイッチXが00:04:27:99:88:xx、スイッチYは00:04:27:88:7b:xxになりMACアドレスではスイッチYの方が低くなります。Bプライオリティ+MACアドレスで足した数値(BID)が低い方がルートブリッジ(スイッチ)になりますのでスイッチYがルートとなります。 ルートになったスイッチYのポートは必然的にすべて「指定ポート」になります。 ルートポートはルートブリッジに対してコストが一番低いポートに対して割り当てられます。通常は回線が太い方、という事になりますが上記の場合バックアップ回線も本回線も同じ帯域の回線になります。その場合、ポート番号が低い方(MACが低い)が選択されます。従ってスイッチXの00:04:27:88:99:81のポートが「ルートポート」となります。 非ルートポートはルートスイッチに接続されている上記の「ルートポート」以外のポート、つまりスイッチングXの00:04:27:88:99:88が選択されます。 非指定ポートで接続されている回線は必然的に「バックアップ回線」となり実際の信号は流れませんので輪を書いた回線を作成してもブロードキャストストームが発生しません。
さてSpanning-treeのパケットの流れをEtherealでキャプチャして検証してみましょう。 まずバックアップの回線でのキャプチャ結果は下記の様になります。
ココでダウンロードできます。開き方は「キャプチャ結果を開く」で参照して下さい さて、Spainng-treeを搭載したスイッチではスイッチ間で上記の様なパケットが頻繁にやり取りされています。CISCOの場合、デフォルトで上記のパケットは2秒間に1回スイッチングHUBから発信される事になっています。 では下記の1番目の詳細データを見て下さい。
これはルートブリッジであるスイッチYの「指定ポート」からスイッチXの「非指定ポート」に対して送信されたSpanning-tree信号です。 まず最初に その下のLogical-Link Controlですがこれは物理リンク制御服装(LLC)といわれるものです。IEEE802で規定したデータリンクプロトコルでエラー制御、フロー制御、フレーミング、MAC服装アドレッシングを行います。ここではあまり深くは解説しませんがご希望であればお問い合わせ下さい。 さてさらにその下のSpaning tree protocolの 本回線がなんらかの問題で切断された時スイッチはバックアップ回線に切り替える訳ですが、もちろんそうするにはスイッチHUB自体が本回線が切れたという事実を知る必要があります。又、同時にバックアップ回線が正常な状態で存在するのかも確認しなければなりません。 Spanning-treeではこのBPDU(ブリッジプロトコルデータユニット)というマルチキャスト信号を常に(2秒に一回)スイッチ間で設定データをやりとりする事により。相手のスイッチの状態や回線の状態を即座に判断する事ができる様になっています。 一行目のBPDUは[BPDU flags 0x00]を見てわかるとおり「切り替えは必要ない状態」という主張をルートブリッジが行っています。つまり「正常な状態」という事になります。 さて本回線を切断して障害を発生させてみます。29番のパケットのSpanning-treeの部分を見て下さい。
これはスイッチングXからルートブリッジに対して送信されたSpanning-Tree信号です。BPDUのタイプが[Topology Change Notification]という「切り替えの通達」になています。
このBPDUメッセージを受け取るとルートブリッジYはスイッチXに対して下記の様なSpanning-tree信号を流しバックアップ回線のポートに切り替えパケットを流し始めます。サンプルでは30番からのパケットがこれに該当します。
BPDUのフラグでは先ほどの1番とうってかわって「切り替えをしても良い状態」となっています。これはいわゆる「パケットを流す状態」にある回線上で流れるBPDU信号で普段は正常な本回線で常にこのパケットが流れています。 さて、本回線が回復しました。回復するとルートブリッジはスイッチXに対して従来流していた下記Spanning-treeをバックアップ回線上に流しパケットが流れない状態にします。サンプルでは66番からのパケットがこれに該当します。
Spanning-treeはこの手順で障害が発生した時に本回線からバックアップ回線に切り替えます。 実は「Spanning-tree」がストームの要因となる可能性もあります。と言っても単純なミスによるものですが・・・・ Spanning-treeプロトコルはSpanning-tree機能が搭載されたHUBから発信されます。Catalystの場合はどれもSpanning-treeプロトコルがデフォルトで発信されますが一般の電気店で販売している安価なスイッチングHUBにはこの機能が搭載されたものは皆無に等しいです。 従って、下記の様なネットワークの場合実はSpanning-treeが要因でストームが発生する可能性が極めて高いです。
この様にSpanning-treeは万能ではありませんので注意して下さい。(よくSpanning-treeのHUB1台導入して安心される方がおられます) |
|||||||
Copyright 2003 by Nobuo Nakako All right reserved.