97
35

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

本番環境でやらかしちゃった人Advent Calendar 2020

Day 16

知らないシステムを孤立させてしまった話

Last updated at Posted at 2020-12-15

はじめに

本番環境でやらかしちゃった人 Advent Calendar 2020」の16日目の記事になります。

大分昔の話なので記憶がおぼろげですが、干支一周以上前の業務経験の浅かった時にやらかした話。

某日、某データセンターにHSRPで冗長化されたCisco CatalystL3スイッチを本番環境に繋ぐ作業をしに行きました。

作業自体は一部機器を繋ぐだけの作業だったので予定していた作業時間も短く、「帰りに何のお土産を買って帰ろう?」と悠長に考えていたりしました。

データセンターは何度も行っている慣れた場所で、ネットワーク繋ぎこみ作業も何度か実施したこともあるので今考えれば気が緩んでいたのでしょう。

これから自分が障害を起こすとも知らずに・・・

何事もなく平穏な作業

いつものように作業準備を行い、作業開始。

確認項目 確認結果
LANケーブル接続 OK
LED確認 OK
インタフェース閉塞解除 OK
インタフェースリンクアップ確認 OK
ゲートウェイへのPing疎通確認 OK
冗長化状態確認 OK

何事もなく進む作業。

今回は一部機器繋ぎこみだけなので、そろそろ作業の終わりも見えてきたとき、一本の電話がかかってきた。

一本の電話

smartphone_vibration.png

電話の表示を見ると、その時の案件リーダの方の名前が表示されている。

このタイミングでかかってくる電話に良いことがあったためしがない。

でたくない、、、でたくないが、意を決して出る。


私:「どうしましたか?」
リ:「お客様から電話があって監視からエラーが出ていると連絡があったけど何かやった?」
私:「今、L3スイッチを繋いだところなのでリンクアップのメッセージとかじゃないですか?」
リ:「うちのシステムではなく、別のシステムの監視からエラーが出続けているそうなんだけど。」
私:「(別のシステム!?)」

自分のシステムならともかく、別のシステム!!!

tamashii_nukeru_man.png

しびれとも寒気ともいえぬ、血の気が引く感覚が全身を駆け巡りました。

惨劇はなぜおこってしまったのか

すぐに原因の当たりはついたので、即LANケーブルを抜き、切り戻し作業開始。

結論としては、L3スイッチで設定していたHSRPのグループIDが別システムの機器と同じになっており、さらに優先度が今回接続したL3スイッチのほうが高かったことで、別システムの機器からHSRPのエラーが出力し続けられていたわけです。

HSRPは共有する仮想IPが異なっていたとしても、HSRPグループIDが同じであれば優先度が高い機器に引っ張られ、状態遷移してしまいます。

後の検証で分かったことですが、優先度が高く、仮想IPが同じ機器同士はActiveStandbyの状態遷移を行いますが、優先度が低く、仮想IPが異なる機器同士は、たとえ元々ActiveStandbyの状態で動作していたとしてもListen状態に遷移し、優先度が高い機器がいなくなるまでそのままの状態となるので、今回L3スイッチを接続してからLANケーブルを抜くまでの間、意図せず知らないシステムを孤立させてしまったわけです。

AdventCalender.png

ちなみにVRRPも同じような動きをしますが、VRRPVRIDHSRPで言うとグループID)が同じでも仮想IPが異なれば、状態遷移までは行われないため、VRRPであれば気が付かなかったかもしれません。
※とはいえそのような設計をするものではありません。

なぜグループIDが被ってしまったのか

改めて振り返ると以下のような原因があったかと思います。

  • HSRPの状態遷移について把握しきれていなかった
  • グループIDが周りに与える影響を想像できていなかった
  • 結果として作業に対する認識が甘かった

今なら自システム外のネットワークに接続する前は事前にアドレス重複HSRPグループID重複などないかを事前に担当者に確認するのが当たり前だという感覚がありますが、このころは自システム外の機器が存在するネットワークに繋げるときの怖さ影響をイメージしきれておらず、結果、危険個所の予測事前の確認が疎かになっていたのだと思います。

二度と惨劇を起こさないためにどうしたのか

以下を徹底するようにしました。

  • 外部のシステムに接続する際にはグループIDが被っていないか等ヒアリング徹底。
  • グループIDが被っているか調べきれない場合はパケットキャプチャでHelloパケット有無を確認。
  • Helloパケットの出力があった場合はグループIDが被っていないか確認。

ヒアリングしても防げない場合

とはいえ、たまにあるのがお客様にヒアリングしてアドレスやIDなど被っていないと言われたのに被っているケース。

お客様のシステムと言えど、1システム担当だと全体を知っているわけでもなく、お客様が知らない間に追加されていたということもあるので、できれば前もってパケットキャプチャを取得させて頂くのがベスト。

パケットは嘘つかない。

おわりに

昔を思い返しながら記事を書いてみましたが、過去のことながら胃が痛くなってきます。

経験が浅いエンジニアと経験豊富なエンジニアを比べたとき、何が違うのかを考えると、知識や経験もそうですが、何かアクションを行ったとき、どういう影響が発生するかという仮説がどれだけ立てられるかどれだけ状況をイメージできるかという点があげられるかと思います。

本番環境でやらかしちゃった人」に載るような障害を起こさないために、心配性と言われるくらい気を配って作業するようにしましょう。

97
35
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
97
35

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?