エネルギー分野のCISO向けネットワーク自動化に関するNERC CIP準拠
NERC CIP準拠自動化とは、NERCの重要インフラ保護基準およびFERCの2023年内部ネットワークセキュリティ監視規則の要件を満たすために、ネットワーク自動化を継続的に使用することです。
IPネットワークはクールです！これはオタクっぽい感情ですが、私がITに携わるようになった理由です。しかし、ネットワークサポートの仕事では、私の中のオタクも疲れ果ててしまいます。ルーティング、ワイヤレス、マルチキャストのトラブルシューティングで得たスキルは気に入っていますが、 マニュアル、単調な作業にうんざりしています。チケットの繰り返し、ゴースト問題、誤検知などは非常にイライラさせられます。さらに悪いことに、ネットワークの問題の解決が遅くなります。
1. NetBrain 自動ネットワークトラブルシューティング
NetBrain 遅くて単調な手作業のワークフローからの休息です。 NetBrain 自動診断が初めて機能したとき、私は驚きました。もちろん、それは驚くべきもので、インシデント対応へのアプローチ全体を変革しましたが、私が感銘を受けたのは、それがいかに明白であるかということでした。これは、何年も前からネットワーク サポートがそうあるべきだったということです。直感的ですが、自動化テクノロジーはこれまで私たちの想像力に追いつくことができませんでした。
2. 自動化されたマルチキャストトラブルシューティングと従来の方法
「証拠は実績にある」と言われているので、典型的なネットワークの問題の実例と、古い手動ワークフローと最新のワークフローでの対応がどのようになっているかを見てみましょう。 NetBrain 自動化されたアプローチ！
シナリオ: ITSMでビデオマルチキャストのダウンに関するインシデントを受け取りました。 マルチキャストのトラブルシューティング 必要とされる。
調査：
マニュアル
ボストンのユーザー VLAN は、ルータ US-BOS-R2 上にあります。そのルータにリモート接続して、マルチキャスト転送のアップストリームをトレースします。一連の CLI コマンドを使用して、最終的にマルチキャスト ストリームを転送する方法をマッピングし、静的ルートによって発生した RPF の不一致を検出します。根本原因を特定するために使用した手順とコマンドは次のとおりです。
- US-BOS-R2#show ip pim neighbor (Eth3/1 の上流ネイバー)
- US-BOS-R2#show ip mroute 224.1.1.1 (着信インターフェイス Eth2/0 はアップストリーム インターフェイスではありません)
- US-BOS-R1#show ip mroute 224.1.1.1 (送信元ルータからのmrouteは正しいようです)
- マルチキャストパスをマップできるようになりました
- US-BOS-R2#show ip mroute 224.1.1.1 count (RPF 障害によりマルチキャスト パケットがドロップされました)
- US-BOS-R2#show ip rpf 10.1.1.1 (RPF インターフェイスが Eth2/0 ではなく Eth3/1 で正しくありません)
- US-BOS-R2#show ip route 10.1.1.1 (根本原因は不正な静的ルートであると特定されました)
NetBrain オートメーション
チケットを開けて NetBrain ITSMによってトリガーされた自動マルチキャストトラブルシューティングについては、生成されたマップをクリックして確認し、 NetBrain 静的ルートが原因で RPF チェックが失敗したと判断しました。
3. 診断を自動化し、問題解決に集中する
手動による情報収集に煩わされることがなくなると、マルチキャストのトラブルシューティングの問題を実際に解決するまでの時間がどれだけ短縮されるかがわかります。節約される時間は、自動化によってデータの取得と問題の診断がどれだけ速くなるかということだけではなく、調査をより早く開始できることも意味します。 NetBrain チケットが送信されると、人間が確認する前に自動化が開始され、応答時間が短縮され、 MTTR 劇的に！
今後も「手動 vs. NetBrain 自動化シナリオを購読して blog 進化できるすべてのワークフローを理解する NetBrain トラブルシューティング、変更管理、停止防止などの自動化。
NetBrain 自動ネットワークトラブルシューティング
NetBrain 遅くて単調な手作業のワークフローからの休息です。 NetBrain 自動診断が初めて機能したとき、私は驚きました。もちろん、それは驚くべきもので、インシデント対応へのアプローチ全体を変革しましたが、私が感銘を受けたのは、それがいかに明白であるかということでした。これは、何年も前からネットワーク サポートがそうあるべきだったということです。直感的ですが、自動化テクノロジーはこれまで私たちの想像力に追いつくことができませんでした。
自動化されたマルチキャストトラブルシューティングと従来の方法
「証拠は実績にある」と言われているので、典型的なネットワークの問題の実例と、古い手動ワークフローと最新のワークフローでの対応がどのようになっているかを見てみましょう。 NetBrain 自動化されたアプローチ！
シナリオ: ITSM でビデオ マルチキャスト ダウンに関するインシデントを受け取りました。
調査：
マニュアル
ボストンのユーザー VLAN は、ルータ US-BOS-R2 上にあります。そのルータにリモート接続して、マルチキャスト転送のアップストリームをトレースします。一連の CLI コマンドを使用して、最終的にマルチキャスト ストリームを転送する方法をマッピングし、静的ルートによって発生した RPF の不一致を検出します。根本原因を特定するために使用した手順とコマンドは次のとおりです。
- US-BOS-R2#show ip pim neighbor (Eth3/1 の上流ネイバー)
- US-BOS-R2#show ip mroute 224.1.1.1 (着信インターフェイス Eth2/0 はアップストリーム インターフェイスではありません)
- US-BOS-R1#show ip mroute 224.1.1.1 (送信元ルータからのmrouteは正しいようです)
- マルチキャストパスをマップできるようになりました
- US-BOS-R2#show ip mroute 224.1.1.1 count (RPF 障害によりマルチキャスト パケットがドロップされました)
- US-BOS-R2#show ip rpf 10.1.1.1 (RPF インターフェイスが Eth2/0 ではなく Eth3/1 で正しくありません)
- US-BOS-R2#show ip route 10.1.1.1 (根本原因は不正な静的ルートであると特定されました)
NetBrain
チケットを開けて NetBrain ITSMによって自動化がトリガーされ、生成されたマップをクリックして確認します。 NetBrain 静的ルートが原因で RPF チェックが失敗したと判断しました。