このプレイブックは、サイトのBGPセッションが切断されたときに問題を解決する手順を説明します。
BGPセッションが切断されると、2つのBGPルーター間の接続が終了し、ルーティング情報の交換が妨げられる可能性があります。 切断されたセッションの影響はネットワークの冗長性やフェイルオーバーメカニズムにより異なる可能性があります。 代替経路が存在するシナリオでは、影響は最小限に抑えられることがあります。 しかし、耐障害性の低いセットアップでは、切断が一時的なルーティング問題やサービス中断を引き起こすことがあります。
BGPの詳細については、CatoクラウドでのBGPの使用をご覧ください。
サイトのBGPセッションが切断されたことを確認する方法は複数あります:
-
ストーリーワークベンチページに移動し、ネットワークXDRプリセットを使用してBGPセッション切断ストーリーを見つけます。
ストーリーは、インシデントのタイムライン、現在のソケットステータスなどの情報を提供します。
-
アクション切断を伴うBGPセッションサブタイプのルーティングイベント
-
BGPピア切断プリセットフィルターを使用し、必要に応じて時間枠を調整します
-
- BGPメール通知
- BGPピアに対してメール通知が有効化されると、メールはメーリングリストに送信されます(管理者以外を含む可能性があります)
サイトオペレーションストーリーに対応する際、問題が継続していることをまず確認し、その後問題をトラブルシューティングし、最終的に解決したことを確認することが重要です。
ステップ1 - BGPセッションが切断されていることの確認
このセクションでは、サイトのBGPセッションが切断されていることを確認するために使用できるCatoツールと、その根本原因について説明します。
BGPセッションのリアルタイムステータスを表示するためにCato管理アプリケーションを使用します。 サイトのBGPページ (ネットワーク > サイト > {サイト名} > サイト構成 > BGP)で、BGPステータス表示をクリックします。
切断されたBGPセッションのステータスの例:
BGPルートの表示
Cato管理アプリケーションを使用してアカウントのルーティングテーブルを表示します(監視 > ルーティングテーブル)。 該当するサイト名でフィルターできます。
以下の例では、ルートテーブルにDYNAMICルートが含まれていないことが示されています。つまり、BGPピアからルートが学習されていないことを示しています。
クラウドインターコネクトサイトのBGP切断ステータス確認
クラウドインターコネクトサイトでは、クラウド環境のアンダーレイとPoPsの間の接続にBGPが使用されます。
-
サイトのクラウドインターコネクトページで (ネットワーク > サイト > {サイト名} > サイト構成 > クラウドインターコネクト)、接続テストをクリックしてアンダーレイのBGPステータスを表示します
-
サイトページで、サイトのステータスを確認します
ステップ2 - BGP切断ステータスのトラブルシューティング
このセクションでは、Catoで使用可能なツールを活用し、この種類のインシデントに数多くの手順で対処する方法を説明します。 これらのステップは一般的には順に従いますが、確認結果によって次のステップが決まることがあります。
BGPセッション切断理由の明確化
Cato管理アプリケーションのホームページ(ホーム > イベント)を使用して、BGPセッションが切断された理由を明確にします。
プリセットBGPピア切断を使用して、選択した時間枠内のすべての切断されたBGPセッションの履歴を確認できます。 これらのイベントには関連するBGP切断エラーコードも含まれており、切断の理由を明確にすることができます:
このインシデントが進む前に変更が行われていないことを確認する
Cato管理アプリケーションの監査証跡ページで変更を確認し、この問題に関連する設定があるかどうかを確認します。 設定変更がこのインシデント直前に行われた場合、それを元に戻し、設定が何であるべきかを確認することを検討します。
BGP設定が正しいかどうか確認する
BGPセッションのリアルタイムステータスを表示するためにCato管理アプリケーションを使用します。 サイトのBGPページ (ネットワーク > サイト > {サイト名} > サイト構成 > BGP)で、BGPステータス表示、そして生ステータスをクリックします。 この詳細なステータスには構成パラメーターも一覧表示されます。 これらは正しい設定が適用されていることを確認するためにチェックする必要があります。
設定のソフトリセット
待機中のBGPネイバーが切断されていることを確認した後、BGPネイバーの1つを変更し、保存をクリックします。 これにより新しい設定がプッシュされ、問題解決に役立ちます。 その後、元の設定を復元し、元の構成を保存します。
BGPプロトコルトラフィックがピア間で双方向であることを確認する
BGPセッションを確立し機能させるためには、BGP TCPポート179で双方向トラフィックがある必要があります。 Catoパケットキャプチャを使用して、このトラフィックの双方向性を調査および確認することができます。
ソケットサイトの場合、ソケットLANインターフェース(BGPトラフィックに使用されるポート)でパケットキャプチャ(PCAP)を行います。 詳細については、ソケットでのパケットキャプチャの方法を参照してください。
-
PCAPをポート179でフィルタリングします。 トラフィックが双方向である場合は、TCPの三方向ハンドシェイクが正常に完了していることを確認します。
-
ハンドシェイクが正常に完了している場合でも、セッションが確立されていない場合、ピアのいずれかでエラーが報告されている可能性があります。 これらのエラーはパケットキャプチャで確認できるはずです。 報告されたエラーはBGP標準エラーであり、BGPエラー文書を確認することでさらに調査できます。
- トラフィックが一方向のみの場合、ソケットから送信されてもピアによって返されない場合は、次のセクションに進んでレイヤ3の到達可能性を調査します。
IPSECサイトについては、IPsecサイト接続トラブルシューティングプレイブックで強調表示されたパケットキャプチャ手順を参照してください。
ピアへのレイヤ3到達可能性の確認
サイトの既知のホストページを使用して、ホストに活動があった最近の時間を確認します。 これにより、接続問題のタイミングとBGPセッションに関する情報がより詳しく得られます。
ソケットサイトの場合は、ソケットWebUIを使用してLANインターフェースからBGPピアにピングを行うことができ、BGPピアがICMPトラフィックを許可することを確認してください。 詳細については、ソケットWebUIツールの使用を参照してください。
-
ソケットWebUIから次の設定でホストにピングを行います:
-
経路 - LAN
-
ホスト名/IP - BGPピアのIPアドレス
-
IPSECサイトについては、IPsec接続のトラブルシューティングで概要の手順に従ってパケットキャプチャを取得することができます。 ピングの有効な送信元は、ICMPを介してBGPピアのアドレスに到達できる必要があるWAN越しの任意のホストです。
BGPネイバーがサイトに接続されると、アクション確立でBGPセッションイベントが生成されます。 イベントページで、アクションが確立であることを手動でイベントフィルターを構成してイベントを表示できます。
BGPセッションのリアルタイムステータスにはルーティング状態と情報が表示されます。 サイトのBGPページ (ネットワーク > サイト > {サイト名} > サイト構成 > BGP)で、BGPステータス表示をクリックします。
受信したすべてのプレフィックスを確認
Cato管理アプリケーションを使用してアカウントのルーティングテーブルを表示します(監視 > ルーティングテーブル)。 該当するサイト名でフィルターできます。
以下の例では、期待されるDYNAMICルートがルートテーブルに含まれていることが示されています。つまり、意図されたルートがBGPピアから学習されていることを意味します。
Catoサポートへのケースの提出
このプレイブックに従った後も問題を修正できない場合は、Catoサポートにチケットを提出することを検討する価値があります。 これを行う際に、最も迅速な解決を図るため、以上の手順を通じて収集した洞察をすべて含めることが重要です。
サポートチケットの提出をご覧ください。
0件のコメント
サインインしてコメントを残してください。