ナビゲーション全体を読み込み中です。

Elevate 2026へのカウントダウンが始まりました。 今すぐ登録 シカゴ、ロンドン、またはシドニーで私たちと一緒に過ごしませんか。

Partners

ドキュメント

LMアカデミー

LMコミュニティ

価格

Platform
解決策
業種
職種
結果はありません。
無料トライアル

14日間フルアクセス LogicMonitor プラットフォーム

BGPモニタリング

BGP諸国

BGPセッションは、完全に確立されるまでに6つの状態を経ます。BGP有限状態機械を理解することで、セッションがどこで、なぜ失敗しているのかを正確に把握できます。ここでは、6つの状態すべてを詳しく解説します。

6〜9分
デントン千倉

章

    ニュースレター

    最新情報のメール配信を登録

    最新のブログ、ホワイトペーパー、電子ガイドなどを直接受信ボックスにお届けします。

    シェア

    クイックダウンロード:

    BGPはセッションを確立するために6つの状態を持つ有限状態機械を使用するため、セッションがどの状態に陥っているかを知ることで、どのような問題に直面しているかを正確に把握できます。

    • セッションがアクティブ状態のままになっている場合は、TCP接続に問題が発生していることを示しています。BGP設定を変更する前に、ACL、ルーティング、およびMTUを確認してください。

    • OpenSentからOpenConfirmへの移行は、OPENメッセージの交換が成功することに依存します。パラメータの不一致（ASN、ホールド時間、機能）があると、ここでセッションが切断されます。

    • 「確立済み」状態のみが、BGPが完全に機能し、ルーティングアップデートを交換していることを意味します。

    • ネットワーク内のすべてのBGPセッションに対して状態変化アラートを設定してください。セッションが確立状態から切断されることは、ネットワーク運用において最も優先度の高いイベントの1つです。

    ルーティングプロトコルはインターネットを「つなぎ合わせる」役割を果たしており、その中でも最も重要なものの1つがボーダーゲートウェイプロトコル（BGP）です。この記事では、2つのデバイス間の近隣関係を表すBGPステートと、セッションを正常に確立する方法について説明します。 

    これらの状態は必須です。新しいセッションはすべて、BGP接続が正常に確立されるまで、さまざまな段階を経ます。

    BGPステートの概要

    BGP有限状態機械（FSM）で定義されるように、BGPプロセスには6つの状態が関与します。FSMは、BGPセッション確立の各段階でどのようなアクションが役割を果たすかを示しています。下の図は、状態間の遷移がどのように発生するかを示しています。

    BGP有限状態機械

    以下の表は、すべてのBGP状態と、それぞれに関連するプロセスをまとめたものです。最初の3つの状態はTCPに関係する一方、最後の3つの状態はBGPのみに関係する点に注意してください。これらはTCPフェーズとBGPフェーズという2つの異なるセットとして言及されることも珍しくありません。

    BGP諸国
    アイドル設定済みのBGPピアへのTCP接続を開始します。着信TCP接続を待ち受けます。接続再試行タイマーが開始されます（120秒 - 変更不可）。
    つながり、TCP接続が完了するまで待機します。TCPが成功した場合：ピアにOPENメッセージを送信します。状態をOpenSentに変更し、CRタイマーをクリアします。TCPが失敗した場合：ConnectRetryタイマーがリセットされます。BGPはActive状態になります。
    有効BGPスピーカーは、別のTCP接続を開始することでピアを取得しようとします。TCPが成功した場合：ConnectRetryタイマーがクリアされます。ピアにOPENメッセージを送信し、状態をOpenSentに変更します。TCPが失敗した場合：ConnectRetryタイマーがリセットされます。BGPはアイドル状態になります。
    OpenSentピアからOPENメッセージを受信するまで待機し、すべてのフィールドを確認します。メッセージには、BGPバージョン、AS番号、フォールドタイム、およびBGP IDが含まれます。成功した場合：BGPはキープアライブの送信を開始し、ホールドタイマーとキープアライブタイマーを設定します。失敗した場合：ConnectRetryタイマーがリセットされます。BGPはアイドル状態になります。
    OpenConfirmBGP はピアからキープアライブを受信するまで待機します。成功した場合:状態が確立状態に変更されます。失敗した場合:接続再試行タイマーがリセットされます。BGP はアイドル状態になります。
    設立更新、通知、およびキープアライブメッセージの交換は、ピアとの間で行われます。更新またはキープアライブが行われるたびに、ホールドタイムがリセットされます。デフォルトのキープアライブは60秒、ホールドタイムは180秒です。

    BGPステートの詳細分析

    ここでは、BGPの各状態を詳細に解説し、それらの状態間の遷移がどのように発生するかを説明します。

    アイドル

    最初のBGP状態では、ピアルータからの接続要求を待ち受けます。この接続要求は、新しいBGPセッションが設定された場合、またはConnectRetryタイマーが再起動された場合に発生します。

    BGPは、さまざまな理由でこの状態に陥る可能性があります。TCPポート179または1023番を超えるポートが何らかの理由で閉じられている場合、接続は拒否されます。

    ConnectRetryタイマーは、デフォルトではルーター間の接続要求が完了するまで120秒間待機し、その後次の状態に移行します。この間、BGPは着信接続を待ち受け、リモートネイバーとの接続を積極的に試みます。2つのルーターがTCP接続を開始すると、BGPはConnect状態に移行します。

    つながり、

    Connect状態では、BGPは3ウェイTCPハンドシェイクの完了を試みます。成功した場合、ConnectRetryタイマーをリセットし、OpenSent状態に移行します。

    TCP接続が確立される前にタイマーが経過した場合、時間はリセットされ、BGPはアクティブ状態に移行します。

    予期せぬ事態が発生した場合、BGPはアイドル状態に戻り、処理を再開します。

    有効

    BGPはアクティブ状態から起動し、新しいTCP接続を試みます。接続が正常に確立されると、ピアにOpenメッセージを送信し、OpenSent状態に移行します。

    TCPセッションが確立される前にConnectRetryタイマーが期限切れになった場合、進行状況はConnect状態に戻る可能性があります。また、BGPリセットイベントが発生した場合は、Idle状態に戻る可能性があります。

    OpenSent

    OpenSent状態では、BGPはネイバーからのOpenメッセージを待機しています。メッセージを受信すると、一致するパラメータと潜在的なエラーがないかを確認します。Openメッセージの中で特に注目すべき変数は以下のとおりです。

    • BGPバージョン（両端で一致している必要があります）。
    • 自律システム（AS）の数値。
    • 設定されたネイバーの送信元IPアドレス。
    • ルーターIDの一意性（重複があってはならない）。
    • セキュリティパラメータ（TTL、パスワードなど）。
    • 機能（例：AS番号を2バイトではなく4バイトで使用する、IPv6のマルチプロトコルを有効にする）。

    エラーがない場合、BGPはキープアライブメッセージの送信を開始し、ホールドタイムの​​ネゴシエーションを行います。

    BGPは、Openメッセージにエラーまたは不一致が見つかった場合、通知を送信してアイドル状態に戻ります。TCPセッションが何らかの理由で切断された場合、BGPはアクティブ状態に移行し、3ウェイハンドシェイクの完了を試みます。

    OpenConfirm

    OpenConfirm状態では、BGPはピアからのKeepaliveメッセージを待機します。メッセージの送受信が正常に完了すると、BGPは最終的なEstablished状態に移行します。

    この時点で、通知（エラーメッセージ）を受信すると、BGPは再びアイドル状態に戻ります。

    設立

    確立状態では、BGPネイバー隣接関係が確立されています。更新メッセージとキープアライブメッセージが交換され、メッセージが送信されるたびにホールドタイマーがリセットされます。 

    これらのメッセージのいずれかを受信する前にホールドタイマーが期限切れになった場合、BGPはアイドル状態に戻ります。通知メッセージを受信した場合も、アイドル状態に戻ります。

    実験室デモ

    このセクションでは、ラボ環境でBGPを設定する方法を説明し、Wiresharkを使用してBGPステートがどのように機能するかを詳しく見ていきます。

    既に2台のルーターにIPアドレスを設定し、接続性を確認済みです。

    次に、R20上でBGPを設定し、そのネイバーを指定します。

    R20(config)#router bgp 20
R20(config-router)#neighbor 172.16.1.21 remote-as 21
R20# 
*Apr 10 21:17:02.569: %SYS-5-CONFIG_I: Configured from console by console

    この時点で、R20がTCPセッションを確立しようとしていることがわかりますが、R21の設定がまだ完了していないため、失敗しています。

    R21側でのBGPの設定：

    R21(config)#router bgp 21
R21(config-router)#neighbor 172.16.1.20 remote-as 20
R21(config-router)#  
*Apr 10 21:18:53.382: %BGP-5-ADJCHANGE: neighbor 172.16.1.20 Up

    ほぼ瞬時に、隣接関係が正常に形成されるのが確認できます。

    R21(config-router)#
*Apr 10 21:23:52.808: %BGP-5-ADJCHANGE: neighbor 172.16.1.20 Up

    Wiresharkでトラフィックを検査すると、先に説明した状態やメッセージの一部を確認できます。これは、BGP接続がスムーズに確立された場合の最良のシナリオです。

    • TCP接続
    • オープンメッセージ
    • キープアライブ/アップデートメッセージ

    ここで、何らかの原因でBGPセッションが切断されたと仮定します。以下のコマンドでその状況をシミュレートしてみましょう。

    R21(config-router)#no neighbor 172.16.1.20 remote-as 20
*Apr 10 21:57:32.632: %BGP-3-NOTIFICATION: sent to neighbor 172.16.1.20 6/3 (Peer De-configured) 0 bytes
R21(config-router)#
*Apr 10 21:57:32.638: %BGP_SESSION-5-ADJCHANGE: neighbor 172.16.1.20 IPv4 Unicast topology base removed from session  Neighbor deleted
*Apr 10 21:57:32.638: %BGP-5-ADJCHANGE: neighbor 172.16.1.20 Down Neighbor deleted
R21(config-router)#

    R21はR20に通知メッセージと、TCPセッションを切断するためのFINメッセージを送信します。

    ここで、R21がeBGP（異なるAS）ではなくiBGPセッション（同じAS）を期待するように設定するとします。R20は依然としてAS20に属していますが、R21はR20がAS21に属することを期待します。

    R21(config-router)#neighbor 172.16.1.20 remote-as 21
R21(config-router)#
*Apr 10 21:58:45.113: %BGP-3-NOTIFICATION: sent to neighbor 172.16.1.20 passive 2/2 (peer in wrong AS) 2 bytes 0014
R21(config-router)#
*Apr 10 21:58:45.113: %BGP-4-MSGDUMP: unsupported or mal-formatted message received from 172.16.1.20:
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0039 0104 0014 00B4 AC10 0114 1C02 0601
0400 0100 0102 0280 0002 0202 0002 0246 0002 0641 0400 0000 14
R21(config-router)#
*Apr 10 21:58:49.211: %BGP-3-NOTIFICATION: sent to neighbor 172.16.1.20 active 2/2 (peer in wrong AS) 2 bytes 0014

    別の通知メッセージを受け取ります。 不良ピアAS.


    次に、その問題を修正してBGPを正常に動作させます。そして、ループバックアドレスを作成し、それをBGP経由でアドバタイズすることにします。

    R20(config)#interface loopback 1
R20(config-if)#ip address 20.20.20.20 255.255.255.255
*Apr 10 21:51:48.312: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1, changed state to up
R20(config-router)#network 20.20.20.20 mask 255.255.255.255

    R20は、新しいプレフィックスを含む更新メッセージを隣接ノードに送信します。

    ベストプラクティス

    セッションの問題を回避し、パフォーマンスを最適化するためにBGPを設定する際に考慮すべき重要なポイントをいくつかご紹介します。

    • BGPのバージョンは両端で一致している必要があります。
    • 正しいAS番号を使用してください。
    • 物理インターフェースの代わりにループバックアドレスを使用してBGPを設定します。
    • ルーティングテーブルが大きくなるのを避けるため、経路を要約する。
    • 広告されているルートと承認されたルートをフィルタリングします。

    結論

    この記事では、BGPステートについて解説し、セッション確立時にそれらがどのように動作するかを詳細に説明しました。また、これらの原理をラボ環境で実演し、リアルタイムでどのように動作するかを確認しました。さらに、BGPセッションの設定方法やパフォーマンス最適化のためのベストプラクティスについても触れました。

    BGPセッションの状態変化を見逃さないでください。

    LogicMonitorは、ネットワークインフラストラクチャ全体にわたるBGPセッションの状態を監視し、セッションが確立状態から外れた瞬間にチームにアラートを送信することで、ユーザーへの影響が出る前に対応できるようにします。

    よくあるご質問

    BGPの6つの状態とは何ですか？

    BGP有限状態機械によって定義される6つのBGP状態は次のとおりです。アイドル（BGPが初期化またはリセット中）、接続（TCP接続の完了を待機中）、アクティブ（TCP接続が失敗し、BGPが再試行中）、OpenSent（TCPが確立され、OPENメッセージが送信済み）、OpenConfirm（OPENメッセージが受信され、KEEPALIVEが交換中）、確立済み（BGPセッションが完全に稼働し、ルーティングアップデートが交換中）。

    BGPセッションがアクティブ状態のままになっている場合、それはどういう意味ですか？

    BGPセッションがアクティブ状態のままになっている場合、2つのピア間のTCP接続が失敗していることを意味します。ルーターはポート179でピアとのTCP接続を確立しようと積極的に試みていますが、成功していません。一般的な原因としては、ファイアウォールルールによるTCPポート179のブロック、ネイバーIPアドレスの誤り、ルーティングの問題による到達不能、MTUの不一致によるTCP SYNパケットのサイレントドロップなどが挙げられます。

    BGPセッションがアイドル状態のままになる原因は何ですか？

    BGPセッションは、プロトコルが管理上シャットダウンされた場合、ルーターが接続試行失敗後の再試行タイマーの期限切れを待っている場合、またはルーティングデーモンがまだセッションを開始していない場合、アイドル状態のままになります。一部の実装では、認証失敗（MD5パスワードの不一致）が発生した場合にもセッションがアイドル状態のままになります。アイドル状態を診断する最初のステップは、セッションのエラーカウンターとログを確認することです。

    BGPホールドタイマーはセッションの安定性にどのような影響を与えますか？

    BGPホールドタイマーは、ルーターがKEEPALIVEまたはUPDATEメッセージを受信せずにセッションが切断されたと判断するまでの待機時間を決定します。ホールドタイマーが期限切れになると、セッションはアイドル状態になり、再確立する必要があります。よくある設定ミスとして、ピア間でホールドタイマーが一致しないことがあり、これがセッションの不安定化につながる可能性があります。ベストプラクティスとしては、デフォルト値に頼るのではなく、ホールドタイマーを明示的にネゴシエートし、SNMPまたはBGP監視ツールを使用して監視することです。

    デントン千倉著

    テクニカルライター

    デントン・チクラは、テクニカルライターであり、長年にわたりオブザーバビリティを推進してきた人物です。彼は、サイト信頼性エンジニアやエンジニアリングチームがインターネットの回復力を強化するツールや機能を発見できるよう支援することに注力しています。監視、パフォーマンス、インフラストラクチャの交差点で活動し、複雑なシステムをより理解しやすく使いやすいものにすることで、高度な技術的詳細と実際の運用とのギャップを埋めています。彼の目標は、チームがより迅速に構築し、問題を早期に発見し、よりスマートに復旧できるよう支援し、最終的にはインターネットをすべての人にとってより良く、より信頼性の高い場所にすることです。

    免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

    © LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。