BGPの設定をして「neighbor 〜 remote-as」まで打ったのに、show ip bgp summaryのStateが永遠にIdleやActiveを行ったり来たり。これ、現場で何度も出くわす光景です。深夜のメンテで30分粘ってもEstablishedに上がらず、結局TCPの到達性で詰まってた、なんてことも個人的には何度かありました。
この記事ではCisco IOSでのeBGP/iBGPピアリングを前提に、BGPの状態遷移とそれぞれの状態で止まったときの切り分け手順を、実機検証ベースでまとめました。「Idle」「Active」「OpenSent」「OpenConfirm」のどこで止まっているかでアプローチが全然違うので、まずは状態を正しく読むところから始めます。
FSMは6段階。詰まる場所は大体2〜3か所に集中する
BGPはRFC 4271で定義されたFSM（Finite State Machine）に沿って動きます。全部で6段階。Idle → Connect → Active → OpenSent → OpenConfirm → Established、と進んでいって、最後のEstablishedにたどり着いて初めて経路交換が始まります。
で、現場で詰まるのって実はだいたい3パターンに集中してるんですよね。「Idleから動かない」「ActiveとIdleを延々と繰り返す」「OpenSentで切れる」。この3つで体感9割以上です。
数年前、データセンター移設の本番作業中にeBGPがどうしても上がらず、深夜2時にラックの前で頭抱えてました。show ip bgp summaryではActive、tracerouteは通る。原因はキャリア側のフィルタでTCP 179が落ちてた、というオチ。手元の機器だけ見てても分からない時はあります。状態がActiveで張り付いたら「TCPセッションを誰かが落としてる」と疑うのが鉄則。
| 状態 | 何をしてる段階か | そこで止まる主因 |
|---|---|---|
| Idle | 初期状態。何も始まっていない | ピアIPの設定ミス・BGP未起動・shutdown状態 |
| Connect | TCP 3-way handshakeを試行中 | 経路はあるがSYNが通らない / TCP RST |
| Active | TCPコネクション確立に再挑戦中 | ACL/FW遮断・ルーティング不通・MD5不一致 |
| OpenSent | OPENメッセージを送信して応答待ち | AS番号不一致・Router-ID重複・Hold Timer不一致 |
| OpenConfirm | 最初のKeepaliveを待っている | ここで止まるのは稀。MTU不一致が最有力 |
| Established | 確立済み。経路交換中 | ここまで来ればOK（経路出ない場合は別問題） |
図1: 詰まる頻度（実務体感ベース）
55%
25%
15%
5%
show ip bgp summaryをまず読む
show ip bgp summaryは情報量が地味に多くて、State/PfxRcdの列を見るだけで状況が大体わかります。経路を受け取れていればここに数字（受信プレフィックス数）が出る。Idle/Active/OpenSentなら文字列が出る、というシンプルな見方です。
R1# show ip bgp summary BGP router identifier 10.0.12.1, local AS number 65001 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.12.2 4 65002 0 0 0 0 0 never Active
この例だとState/PfxRcdが「Active」、Up/Downが「never」。一度もEstablishedになっていないことがすぐ読み取れます。MsgRcvd/MsgSentが0なのも重要なヒント。OPENメッセージすら届いていない状態です。
summaryで状態が確認できたら、次はshow ip bgp neighbors。出力が長いので、Last reset reasonとBGP stateだけまず見るのがコツです。
R1# show ip bgp neighbors 10.0.12.2 | include state|reset BGP state = Active Last reset 00:02:14, due to BGP Notification received from neighbor: invalid AS number
「invalid AS number」が出てれば、ピアのremote-as設定がこちらと食い違ってる、というのが一発でわかります。Last reset reasonは状態遷移の原因を一番ピンポイントに教えてくれる項目です。
Last reset reasonが「Peer closed the session」だった場合は、相手側で何かが起きてます。自機だけ見ても解決しないので相手機器のログを確認しに行くこと。BGPのトラブルは「両側を見る」が原則。片側だけ見て3時間溶かすのは現場あるあるです。
Idle / Active / OpenSent それぞれで打つ手は違う
「BGPがEstablishedにならない」と一括りで語られがちですが、止まっている状態によって調べる順番は全然違います。状態ごとに最短ルートを切り分けていきます。
Idleは「そもそも何も始まってない」状態。BGP自体が動いてない可能性が高いので、設定そのものから疑います。
! 設定確認 R1# show running-config | section router bgp router bgp 65001 bgp router-id 10.0.12.1 neighbor 10.0.12.2 remote-as 65002 neighbor 10.0.12.2 shutdown ← これが入ってると永遠にIdle ! 解除 R1(config)# router bgp 65001 R1(config-router)# no neighbor 10.0.12.2 shutdown
「neighbor 〜 shutdown」が残ってるパターン、案外多いです。検証時に止めて、本番で外し忘れる、というやつ。あとはピアIPのタイポ、route-mapで全拒否してるケースも要確認。
Activeは「TCP 179でつなぎに行ってるけど通じてない」状態。ここまで来てるならBGP設定そのものはOK、レイヤ3〜4のどこかで通信が落ちてる、と切り分けます。
! ピアまでL3疎通確認 R1# ping 10.0.12.2 source 10.0.12.1 !!!!! ← ICMPは通る ! TCP 179へ実際に届くか確認 R1# telnet 10.0.12.2 179 /source-interface GigabitEthernet0/0 Trying 10.0.12.2, 179 ... % Connection refused by remote host ← 相手にBGP設定がない % Connection timed out ← 経路上のFW/ACLでブロック
「Connection refused」と「timed out」は意味が全然違います。前者は宛先までは届いてるけどBGPが待ち受けてない（相手の設定漏れ）。後者は途中で落とされてる（ACL・FWを疑う）。この差を見られるかでデバッグ時間が10倍くらい変わります。
BGPのMD5認証（neighbor 〜 password）が片側だけ入ってる/パスワード違いだと、TCPセッションがそもそも張れずActive連発になります。Last reset reasonには直接出ないので気付きにくい。両側のpasswordが完全一致してるか目視で必ず確認。
ここまで来るとTCPは張れてる。BGPのOPENメッセージ交換でパラメータが合わずNotificationが飛んでるパターンです。debugでメッセージ内容を見るのが手っ取り早い。
R1# debug ip bgp 10.0.12.2 BGP: 10.0.12.2 went from OpenSent to Idle BGP: 10.0.12.2 received NOTIFICATION 2/2 (peer in wrong AS) 2 bytes FDE9 BGP: 10.0.12.2 reset due to BGP Notification received ! ピア側に正しいremote-asを設定し直す R1(config-router)# no neighbor 10.0.12.2 remote-as 65003 R1(config-router)# neighbor 10.0.12.2 remote-as 65002
Notificationのコード（上の例だと2/2）はRFC 4271のSection 4.5に対応表があります。「Bad Peer AS」「Bad BGP Identifier」「Unsupported Optional Parameter」あたりが頻出。debug出力に英文の理由も出るのでまずそれを読めば足ります。
show系・debug系・clear系の使い分け
BGPトラブルで実際に頻用するコマンドを表にまとめました。debugは本番機でうかつに打つと負荷が跳ねるので、まずshow/clearで様子を見るのがおすすめです。
| コマンド | 見るべき項目 | 使いどころ |
|---|---|---|
| show ip bgp summary | State/PfxRcd, Up/Down | 最初の状態確認 |
| show ip bgp neighbors | Last reset reason | 直近のフラップ原因 |
| show tcp brief | 179のESTAB有無 | L4到達確認 |
| debug ip bgp | FSM遷移・Notification | Open交換の中身 |
| debug ip tcp transactions | SYN/RSTの動き | Active張り付き調査 |
| clear ip bgp 10.0.12.2 soft | 経路再送信 | 設定変更後の反映 |
| clear ip bgp 10.0.12.2 | セッション再確立 | 最終手段。瞬断あり |
Cisco IOS XE/XRやNX-OSではコマンドが微妙に違います（show bgp ipv4 unicast summary など）。本記事は古典的なIOSベースですが、考え方の流れ（状態確認→原因の絞り込み→デバッグ）はどのプラットフォームでも同じです。Junosなら show bgp summary / show bgp neighbor、FortiGateなら get router info bgp summary。
eBGPと違ってiBGPはハマりどころが独特
iBGPはAS内ピアリングなので、ループバック同士で張ることが多い。そこで起きがちなのが「update-source忘れ」と「next-hop問題」。あと、iBGPで受け取った経路を別のiBGPピアに広告しないっていうルール（split horizon）も知らないとハマります。
ぶっちゃけ、フルメッシュiBGPだと数台でも面倒くさい。route-reflector構成にした方が楽です。ただ、最初の1〜2台ならまず素直にneighborを書いて検証する方がデバッグもしやすい。
! ループバック同士でiBGPを張る場合 router bgp 65001 neighbor 1.1.1.1 remote-as 65001 neighbor 1.1.1.1 update-source Loopback0 ← これがないとIdle/Active行き neighbor 1.1.1.1 next-hop-self ← eBGP経路をiBGPに流すなら必須
eBGPピアにいきなりclear ip bgp *を打つのは厳禁。ピアが多いとフルテーブルの再交換が走って、CPUが跳ねるしルーティングテーブルが瞬間的に空になります。本番環境では必ずsoftリセット（clear ip bgp 〜 soft in/out）から試すこと。
状態を読む→原因を絞る→Notificationを見る、の3ステップ
BGPがEstablishedにならない時は、まずshow ip bgp summaryでStateを確認。Idleなら設定そのもの、ActiveならTCP/L3経路、OpenSentならASやMD5などのパラメータを疑う。Last reset reasonとdebug ip bgpのNotificationを読めば、原因はほぼ特定できる。両側の機器を確認するのを忘れずに。
よくある質問（FAQ）
Q. BGPピアがActiveとIdleを繰り返してフラップしています。何を疑えばいいですか？
9割はTCP 179が落ちてます。経路上のACL/FW、片側だけ設定されたMD5パスワード、NATを挟んでるケースが代表例。telnet 〜 179でConnection refusedかtimed outかをまず確認してください。
Q. show ip bgp summaryで「Idle (Admin)」と出るのは何ですか？
「neighbor 〜 shutdown」が設定されている状態。意図的に止められてるので、no neighbor 〜 shutdown で解除すれば動き出します。検証時の止め忘れが多い印象です。
Q. EstablishedにはなったけどPfxRcdが0のままです
セッションは張れてるけど経路がもらえてない状態。相手側のnetwork文・redistribute設定・送信route-mapを疑うのが基本です。自分側のrouter bgp配下にneighbor 〜 route-map 〜 inでフィルタしている可能性もあるので両方見ます。
Q. eBGPピアでループバック同士は組めますか？
組めますが、デフォルトのebgp-multihopが1なのでneighbor 〜 ebgp-multihop 2以上を入れる必要があります。あとupdate-source Loopbackと、相手のループバックへの経路（スタティック等）も忘れずに。
