sidetech

(元)インフラエンジニアの寄り道メモ。

Juniper EXのSplit and Merge機能の功罪

これは忘れないうちのメモ。
Juniper EXシリーズのvirtual-chassis機能(以下VC)。世間のスイッチで言う処のスタッキング機能ですが、スタッキングではない所がいいんすよ。あとはHPに買収されたH3Cもvirtual-chassisがありましたね。1度扱ってから嫌いになりました(苦笑)JunOSはGUIが遅くてイライラするんですが、まぁハイエンドでWEB-GUIが充実しているのが少ないもんで・・・。

で、VirtualChassisですが、構成によってちゃんと設定をしておかないと想定外の挙動を起こすので、結構ナーバスちゃんなので注意が必要です。

私がしでかしてしまったのは、以下の構成で事件は起きました。

EX3300 ID0 Master
EX3300 ID1 Backup
EX3300 ID2 Linecard
EX3300 ID3 Linecard

4台の構成でDAGケーブルによるバーチャルシャーシをしている環境なのですが、メンテナンス時にどうしてもID1とID2の電源を落とす必要があり、以下コマンドを実施しました。

>request system halt member 1
>request system halt member 2

確かこんな感じでhaltした所・・・・ID0のMasterとID3のLinecardも何故かHaltし始める。完全に青ざめました。実施時間が夜中の2時だったのでまだよかったけど、何かあったらやばいなと思っていたことが起きるのがツライす。

で、原因としては、Split and Merge機能が作動した際に2台も構成上失ったことで混乱をおこしたっぽい。さらにMasterとBackupを固定にした運用していたのが影響したのかな。本来であれば、Split and Marge機能はMaster機が複数になるのを防ぐ機能らしいので。
で、結果的にMasterがinactive状態になってVC構成がダウンした・・・ということらしい。

でも管理上、MasterとBackupとLinecardの関係を固定したい場合にこの仕様をどうすればいいかというと、Split and Marge機能を無効にすればいいらしい。

#set virtual-chassis no-split-detection
#commit

この機能を無効にする条件としては、Master,Backup,Linecardを設定で固定にした場合に適用する。固定にしていれば、Master機が複数になることはない為。

いやぁ・・・難しいねぇ。。。
前回のブログで落ちてしまった話をしたのもVCがパニック起こしたのかもね。でも設定を入れられる状態じゃなかったので(涙) メンテナンス用のHUBでよかった。さて、難解なJuniperのナレッジを読み漁りましょうかね…。