loopdetect検証
富士通製L2スイッチ「SR-X324T2」のループ検知機能の検証
ループ検知機能とは
ループ検知機能をONにしたポートから一定間隔でフレームを送出し、自身が送出したフレームを受信した場合にループとみなす機能(らしい)。
参考・・・ループ検知の機能説明
検知時にポートを自動でシャットダウンする機能などもある。
検証の目的
STP機能がない末端のHUBでループが発生してしまった時に、上位スイッチ側で検知したい。
末端のHUBはユーザーが勝手に接続を変えたり新しいHUBを接続するなど、管理が行き届かないケースがある。そして、ループさせることも稀によくある。
構成
・SR-XでloopdetectをON
・SR-Xの配下にほかのL2スイッチ(Catalyst)を繋いでループ構成とする
・配下のスイッチはSTPをOFFにしておく
設定
〇STP無効化設定(Catalyst)
Switch(config)#no spanning-tree vlan 1
⇒ポート単位での設定は不可。vlan単位で無効化する。
〇loopdetect有効化(SR-X)
SR-X324T2(config)# loopdetect use on
⇒有効化
SR-X324T2(config)# loopdetect portdisable no
⇒とりあえずポートの自動閉塞はしない設定
事前検証
loopdetectの検証の前に、実際にブロードキャストストーム発生の様子を観測してみる。
SR-Xの代わりにPC(Windows 10)を接続し、L2ループ発生時のトラフィック量を測定。
結果は以下。
〇タスクマネージャー(ネットワーク)
⇒ワイヤーレートに近いトラフィックが流れていることがわかる。
⇒主にSSDPというプロトコルのパケットがキャプチャされている。PC(10.15.1.2)から239.255.255.250というマルチキャストアドレスへのパケットがループしている様子。
本検証
念のため、loopdetectの監視フレームの情報は以下になる。
「Ethernet-Configuration-Test-protocol」とあるが、調べてもよくわからない。規格化されているわけではないのだろうか。
では、ループ検証に移る。
〇まずは、ループ発生前の状態
⇒undetectedになっている。
〇ループ発生時
⇒port 1でdetectedに変化。構成図の条件で検知に成功することが確認できた。
ちなみに「count」が0/60と表示されているが、こちらはループ復旧と判断するまでの監視フレームの送出回数であり、実際にループ構成を解消させるとcountの数字が増加し、60になると「undetected」に戻る。
⇒ループ構成を解消させるとcountが増えていき、、、
⇒最終的にundetectedに戻る。上記設定では10秒×60なので復旧と判断するまで10分かかることになる。もっと少なく10回くらいでもよい気がする。
まとめ
ループ検知機能は意図した通りに機能することがわかった。ただし、あくまでもループしていることがわかるだけで、どのHUBのどのポートがループの原因となっているかまではわからない。
また、今回はポートの自動閉塞は設定していないが、ループ解消後に自動で閉塞も解除されるのかなどについても検証したい。下手に閉塞させると余計に影響が大きくなる可能性もあるので、実際の運用も考慮して最適な設定を検討すべきである。
-------------------------------------------------------------------------------------------------------------
初めての記事がこれて…。どうせ誰も見ないからいいや。今後もネットワーク機器やサーバの検証メモとして記事にできればいいな。