BGPネイバーの状態遷移

BGPネイバーの状態遷移とは

BGPは、ピアとのセッションを確立するまでの過程を6つの状態（ステート）として定義しています。この状態遷移は有限状態機械（FSM: Finite State Machine）としてRFC 4271に規定されており、セッションが正常に確立できないときは、どの状態で止まっているかが原因の切り分けに直結します。本記事では各状態の意味と遷移の条件を解説し、IOS XR（XRd）の検証環境で実際の状態変化を確認します。

BGPの基本的な仕組みはBGP（Border Gateway Protocol）を、状態遷移の中でやり取りされるメッセージはBGPメッセージを参照してください。

6つの状態

状態	意味
Idle	初期状態。すべての接続を拒否し、リソースも確保していない。Startイベントを受けるとTCP接続を開始してConnectへ移る。エラーが起きたときも必ずこの状態へ戻る。
Connect	TCPの3ウェイハンドシェイクの完了を待っている状態。成功するとOPENを送ってOpenSentへ、失敗するとActiveへ移る。
Active	自分からのTCP接続に失敗し、相手からの接続を待ちながら再試行している状態。接続が成立するとOpenSentへ移る。
OpenSent	OPENメッセージを送り、相手のOPENを待っている状態。受け取ったOPENの内容（バージョン、AS番号、BGP Identifier、Hold Time）を検証し、問題なければKEEPALIVEを送ってOpenConfirmへ移る。
OpenConfirm	相手からのKEEPALIVEを待っている状態。受信するとEstablishedへ移る。
Established	セッションが確立し、UPDATEで経路情報を交換できる状態。

Activeという名前は「アクティブに動いている正常な状態」という意味ではありません。自分からのTCP接続が失敗して再試行している状態なので、ここで止まっている場合はTCPの到達性やピアアドレスの設定を疑う必要があります。

状態が戻る条件

どの状態にいても、次のいずれかが起きるとIdleに戻ります。

NOTIFICATIONメッセージを送信または受信した
TCPセッションが切断された
Hold Timeの間にKEEPALIVEもUPDATEも受信しなかった（Hold Timer Expired）
管理者がshutdownやセッションのリセットを実行した

Idleに戻ったあとは、接続再試行タイマー（Connect Retry Timer、既定60秒）が満了してから再接続を試みます。繰り返し失敗する場合、実装によってはこの待ち時間を指数的に延ばします。

状態の確認方法

IOS XRではshow bgp summaryのSt/PfxRcd列で各ピアの状態を確認できます。Establishedのピアはこの列に受信プレフィックス数（数値）が表示され、それ以外の状態では状態名がそのまま表示されます。

Neighbor        Spk    AS MsgRcvd MsgSent       TblVer  InQ OutQ  Up/Down  St/PfxRcd
10.2.3.3          0 65002     108     105           12    0    0 00:30:41          2

個々のピアの詳細はshow bgp neighbor <アドレス>で確認します。BGP stateが現在の状態、Previous Stateが直前の状態、Last resetにセッションが切れた理由が表示されます。

状態が変化するとsyslogにも記録されます。IOS XRでは%ROUTING-BGP-5-ADJCHANGEとして、ピアのUp / Downとその理由が出力されます。

状態が停滞する主な原因

止まる状態	主な原因
Idle	ピアアドレスへの経路がない。`shutdown`が設定されている。BGPプロセスが起動していない。
Active	TCPポート`179`に到達できない。ピアアドレスの指定を間違えている。ACLやファイアウォールで遮断されている。eBGPで直接接続されておらず`ebgp-multihop`が未設定。
OpenSent	相手の`remote-as`の指定が食い違っている。BGP Identifier（Router ID）が重複している。提示されたHold Timeが受け入れられない。
OpenConfirm	KEEPALIVEが届かない。片方向の通信障害が起きている。

いずれの場合も、NOTIFICATIONのError codeとサブコードが原因を示します。エラーコードの一覧はBGPメッセージを参照してください。

実機での検証

BGP（Border Gateway Protocol）と同じ、3つのASにIOS XR（XRd）のルータ4台を配置した検証環境を使います。R1 - R2間がiBGP、R2 - R3、R3 - R4間がeBGPです。

正常な状態から意図的に異常を作り、状態がどう変化するかを確認します。実施した操作は次の3つで、いずれも設定を元に戻して復旧を確認しています。

テスト	操作
A	R2でR3向けネイバーを`shutdown`する
B	R2に存在しないピア（`10.2.3.99`）を設定する
C	R2でR3の`remote-as`を誤った値（`65999`）にする

テストA: 管理者によるshutdown

R2でR3向けのネイバーをshutdownします。

R2 ネイバーのshutdown
router bgp 65001
 neighbor 10.2.3.3
  shutdown

同じ事象でも、shutdownした側とされた側で状態の表示が異なります。R2はIdle (Admin)と、管理者操作による停止であることが明示されます。

R2 show bgp summary（shutdown後）
RP/0/RP0/CPU0:R2#show bgp summary
<snip>
Neighbor        Spk    AS MsgRcvd MsgSent       TblVer  InQ OutQ  Up/Down  St/PfxRcd
10.0.0.1          0 65001     104     110           14    0    0 01:40:22          1
10.2.3.3          0 65002     115     113            0    0    0 00:00:09  Idle (Admin)

一方のR3はIdleと表示されたあとActiveに移ります。R2からのCEASE NOTIFICATIONでセッションが切れたあと、R3は自分からTCP接続を再試行し続けるためです。

R3 show bgp summary（同時刻）
RP/0/RP0/CPU0:R3#show bgp summary
<snip>
Neighbor        Spk    AS MsgRcvd MsgSent       TblVer  InQ OutQ  Up/Down  St/PfxRcd
10.2.3.2          0 65001     111     115            0    0    0 00:00:17  Idle
10.3.4.4          0 65003     106     113           14    0    0 01:40:28          1

show bgp neighborを見ると、R2にはAdministratively shut downの行が加わり、Last resetの理由が「管理者によるshutdown（CEASE NOTIFICATIONを送信）」と記録されています。

R2 show bgp neighbor 10.2.3.3（抜粋）
RP/0/RP0/CPU0:R2#show bgp neighbor 10.2.3.3
Sat Sep  5 04:50:39.569 UTC

BGP neighbor is 10.2.3.3
 Remote AS 65002, local AS 65001, external link
 Administratively shut down
 Description: eBGP to R3
 Remote router ID 0.0.0.0
  BGP state = Idle
  Previous State: Closing
  Last Received Message: KeepAlive
  NSR State: None
  Last read 00:00:00, Last read before reset 00:00:41
  Hold time is 180, keepalive interval is 60 seconds
  Configured hold time: 180, keepalive: 60, min acceptable hold time: 3
  Received 115 messages, 0 notifications, 0 in queue
  Sent 113 messages, 2 notifications, 0 in queue
  Connections established 2; dropped 2
  Local host: 10.2.3.2, Local port: 179, IF Handle: 0x00000020
  Foreign host: 10.2.3.3, Foreign port: 35164
  Last reset 00:00:29, due to Admin. shutdown (CEASE notification sent - administrative shutdown)
  Time since last notification sent to neighbor: 00:00:29
  Error Code: administrative shutdown

R3側はBGP state = Activeで、Last Received MessageがNotification、Last resetの理由が「NOTIFICATIONを受信した」になっています。ここから、Activeが「正常に動作している状態」ではなく「接続を再試行している状態」であることがわかります。

R3 show bgp neighbor 10.2.3.2（抜粋）
RP/0/RP0/CPU0:R3#show bgp neighbor 10.2.3.2
Sat Sep  5 04:51:04.588 UTC

BGP neighbor is 10.2.3.2
 Remote AS 65001, local AS 65002, external link
 Description: eBGP to R2
 Remote router ID 0.0.0.0
  BGP state = Active
  Previous State: Idle
  Last Received Message: Notification
  NSR State: None
  Last read 00:00:00, Last read before reset 00:00:54
  Hold time is 180, keepalive interval is 60 seconds
  Configured hold time: 180, keepalive: 60, min acceptable hold time: 3
  Received 111 messages, 2 notifications, 0 in queue
  Sent 115 messages, 0 notifications, 0 in queue
  Connections established 2; dropped 2
  Local host: 10.2.3.3, Local port: 35164, IF Handle: 0x00000010
  Foreign host: 10.2.3.2, Foreign port: 179
  Last reset 00:00:54, due to BGP Notification received: administrative shutdown
  Time since last notification received from neighbor: 00:00:54
  Error Code: administrative shutdown

syslogにも状態変化が記録されます。no shutdownで戻すと、約20秒後にUpのログが出ました。

R3 syslog（BGP関連のみ抜粋）
RP/0/RP0/CPU0:Sep  5 04:50:10.097 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.2.3.2 Down - BGP Notification received, administrative shutdown (VRF: default) (AS: 65001) 
RP/0/RP0/CPU0:Sep  5 04:51:33.388 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.2.3.2 Up (VRF: default) (AS: 65001) 

R2 - R3間のリンクでキャプチャーしたパケットです。R2がNOTIFICATIONを送ってTCPセッションを閉じたあと（No.3〜7）、R3が繰り返しTCP接続を試み、R2がすべてRSTで拒否しています（No.8〜15）。これがR3側でActiveと表示されていた状態の実体です。

R2 - R3間 パケットキャプチャー（テストA）
 0.000000     10.2.3.3 → 10.2.3.2     BGP 73 KEEPALIVE Message
 0.203173     10.2.3.2 → 10.2.3.3     TCP 54 179 → 35164 [ACK] Seq=1 Ack=20 Win=31708 Len=0
11.714561     10.2.3.2 → 10.2.3.3     BGP 75 NOTIFICATION Message
11.714775     10.2.3.2 → 10.2.3.3     TCP 54 179 → 35164 [FIN, ACK] Seq=22 Ack=20 Win=31708 Len=0
11.719860     10.2.3.3 → 10.2.3.2     TCP 54 35164 → 179 [ACK] Seq=20 Ack=23 Win=31814 Len=0
11.722405     10.2.3.3 → 10.2.3.2     TCP 54 35164 → 179 [FIN, ACK] Seq=20 Ack=23 Win=31814 Len=0
11.724591     10.2.3.2 → 10.2.3.3     TCP 54 179 → 35164 [ACK] Seq=23 Ack=21 Win=31708 Len=0
52.113483     10.2.3.3 → 10.2.3.2     TCP 62 29663 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
52.116845     10.2.3.2 → 10.2.3.3     TCP 54 179 → 29663 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
54.114524     10.2.3.3 → 10.2.3.2     TCP 62 [TCP Port numbers reused] 29663 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
54.117588     10.2.3.2 → 10.2.3.3     TCP 54 179 → 29663 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
58.114782     10.2.3.3 → 10.2.3.2     TCP 62 [TCP Port numbers reused] 29663 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
58.117419     10.2.3.2 → 10.2.3.3     TCP 54 179 → 29663 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
66.115859     10.2.3.3 → 10.2.3.2     TCP 62 [TCP Port numbers reused] 29663 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
66.119372     10.2.3.2 → 10.2.3.3     TCP 54 179 → 29663 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
92.990066     10.2.3.2 → 10.2.3.3     TCP 62 55616 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1

NOTIFICATIONの中身を見ると、Error codeは6（Cease）、サブコードは2（Administratively Shutdown）です。BGPメッセージで解説したclear bgpのときのサブコード4（Administratively Reset）とは異なり、shutdownによる停止であることが区別できます。

このNo.3（NOTIFICATION）だけを抜き出したもの(bgp-neighbor-state-no3.pcap) をダウンロード

No.3 NOTIFICATION（R2 → R3）tshark -V
Border Gateway Protocol - NOTIFICATION Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 21
    Type: NOTIFICATION Message (3)
    Major error Code: Cease (6)
    Minor error Code (Cease): Administratively Shutdown (2)

テストB: 到達できないピアを設定した場合

R2に、実在しないアドレス10.2.3.99をピアとして設定します。

R2 到達できないピアの設定
router bgp 65001
 neighbor 10.2.3.99
  remote-as 65099
  address-family ipv4 unicast
   route-policy PASS-ALL in
   route-policy PASS-ALL out

TCP接続に失敗し続けるためActiveになると予想されますが、XRdではIdleのままでした。

R2 show bgp summary（到達できないピアを追加）
RP/0/RP0/CPU0:R2#show bgp summary
<snip>
Neighbor        Spk    AS MsgRcvd MsgSent       TblVer  InQ OutQ  Up/Down  St/PfxRcd
10.0.0.1          0 65001     105     113           16    0    0 01:41:50          1
10.2.3.3          0 65002     120     118           14    0    0 00:00:14          2
10.2.3.99         0 65099       0       0            0    0    0 00:00:00  Idle

詳細を見ると、送受信メッセージ数も確立回数もすべて0で、ローカルポートすら割り当てられていません（Local port: 0）。相手が同一セグメント上に存在せずARPが解決できないため、TCPの接続要求自体が送出できず、Connect以降の状態に進んでいないことがわかります。

R2 show bgp neighbor 10.2.3.99（抜粋）
RP/0/RP0/CPU0:R2#show bgp neighbor 10.2.3.99
Sat Sep  5 04:51:59.349 UTC

BGP neighbor is 10.2.3.99
 Remote AS 65099, local AS 65001, external link
 Description: test: unreachable peer
 Remote router ID 0.0.0.0
  BGP state = Idle
  Previous State: Idle
  Last Received Message: None
  NSR State: None
  Last read 00:00:00, Last read before reset 00:00:00
  Hold time is 180, keepalive interval is 60 seconds
  Configured hold time: 180, keepalive: 60, min acceptable hold time: 3
  Received 0 messages, 0 notifications, 0 in queue
  Sent 0 messages, 0 notifications, 0 in queue
  Connections established 0; dropped 0
  Local host: 0.0.0.0, Local port: 0, IF Handle: 0x00000000
  Foreign host: 10.2.3.99, Foreign port: 0
  Last reset 00:00:00

ActiveはTCP接続を試みて失敗した状態であり、そもそもTCPの接続要求を送出できない場合はIdleにとどまります。ピアアドレスの設定ミスはActiveとIdleのどちらでも起こりうるため、Connections establishedやLocal portが0のままかどうかを併せて確認すると切り分けやすくなります。

テストC: AS番号が一致しない場合

R2でR3のremote-asを、実際とは異なる65999に変更します。

R2 remote-asの誤設定
router bgp 65001
 neighbor 10.2.3.3
  remote-as 65999

R2はOPENでAS番号65999を期待しますが、R3は65002を通知してくるため、OpenSentの段階で不一致を検出してセッションが確立しません。状態はIdleと表示されます。

R2 show bgp summary（AS番号の不一致）
RP/0/RP0/CPU0:R2#show bgp summary
<snip>
Neighbor        Spk    AS MsgRcvd MsgSent       TblVer  InQ OutQ  Up/Down  St/PfxRcd
10.0.0.1          0 65001     106     115           18    0    0 01:42:51          1
10.2.3.3          0 65999     123     119            0    0    0 00:00:09  Idle

show bgp neighborではConnections established 3; dropped 3と、TCP接続の確立と切断が繰り返されていることがわかります。TCPまでは成功し、その先のOPENの検証で失敗しているためです。

R2 show bgp neighbor 10.2.3.3（抜粋）
RP/0/RP0/CPU0:R2#show bgp neighbor 10.2.3.3
Sat Sep  5 04:52:48.303 UTC

BGP neighbor is 10.2.3.3
 Remote AS 65999, local AS 65001, external link
 Description: eBGP to R3
 Remote router ID 0.0.0.0
  BGP state = Idle
  Previous State: Closing
  Last Received Message: Update
  NSR State: None
  Hold time is 180, keepalive interval is 60 seconds
  Configured hold time: 180, keepalive: 60, min acceptable hold time: 3
  Received 123 messages, 0 notifications, 0 in queue
  Sent 119 messages, 2 notifications, 0 in queue
  Connections established 3; dropped 3
  Local host: 10.2.3.2, Local port: 55616, IF Handle: 0x00000020
  Foreign host: 10.2.3.3, Foreign port: 179
  Last reset 00:00:10, due to Remote AS configuration changed

R3側のsyslogにも、相手がセッションを閉じたことが記録されています。

R3 syslog（BGP関連のみ抜粋）
RP/0/RP0/CPU0:Sep  5 04:52:38.290 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.2.3.2 Down - Peer closing down the session (VRF: default) (AS: 65001) 

パケットキャプチャーを見ると、TCPの3ウェイハンドシェイクは成立し（No.37〜39）、R3がOPENを送った直後にR2がNOTIFICATIONを返してセッションを閉じています（No.40〜47）。TCPまでは到達できているがOPENの検証で弾かれる、というOpenSentでの失敗の典型的な形です。

R2 - R3間 パケットキャプチャー（テストC）
191.652350     10.2.3.3 → 10.2.3.2     TCP 62 38683 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
191.656169     10.2.3.2 → 10.2.3.3     TCP 62 179 → 38683 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1240 WS=1
191.658813     10.2.3.3 → 10.2.3.2     TCP 54 38683 → 179 [ACK] Seq=1 Ack=1 Win=32768 Len=0
191.660056     10.2.3.3 → 10.2.3.2     BGP 129 OPEN Message
193.660811     10.2.3.3 → 10.2.3.2     TCP 129 [TCP Retransmission] 38683 → 179 [PSH, ACK] Seq=1 Ack=1 Win=32768 Len=75
193.665035     10.2.3.2 → 10.2.3.3     TCP 54 179 → 38683 [ACK] Seq=1 Ack=76 Win=32768 Len=0
193.665308     10.2.3.2 → 10.2.3.3     BGP 79 NOTIFICATION Message
193.665415     10.2.3.2 → 10.2.3.3     TCP 54 179 → 38683 [FIN, ACK] Seq=26 Ack=76 Win=32768 Len=0
193.668311     10.2.3.3 → 10.2.3.2     TCP 54 38683 → 179 [ACK] Seq=76 Ack=27 Win=32743 Len=0
193.670023     10.2.3.3 → 10.2.3.2     TCP 54 38683 → 179 [FIN, ACK] Seq=76 Ack=27 Win=32743 Len=0
193.672491     10.2.3.2 → 10.2.3.3     TCP 54 179 → 38683 [ACK] Seq=27 Ack=77 Win=32768 Len=0
223.666499     10.2.3.2 → 10.2.3.3     TCP 54 179 → 38683 [RST, ACK] Seq=27 Ack=77 Win=32768 Len=0

NOTIFICATIONのError codeは2（OPEN Message Error）、サブコードは2（Bad Peer AS）です。設定したremote-asと、相手が実際に通知してきたAS番号が一致しないことを示しています。

このNo.43（NOTIFICATION）だけを抜き出したもの(bgp-neighbor-state-no43.pcap) をダウンロード

No.43 NOTIFICATION（R2 → R3）tshark -V
Border Gateway Protocol - NOTIFICATION Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 25
    Type: NOTIFICATION Message (3)
    Major error Code: OPEN Message Error (2)
    Minor error Code (Open Message): Bad Peer AS (2)
    Bad Peer AS: 3942449152

復旧

remote-asを正しい65002に戻すと、セッションが再確立されます。

R2 syslog（BGP関連のみ抜粋）
RP/0/RP0/CPU0:Sep  5 04:54:23.213 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.2.3.3 Up (VRF: default) (AS: 65002) 

R2 show bgp summary（復旧後）
RP/0/RP0/CPU0:R2#show bgp summary
<snip>
Neighbor        Spk    AS MsgRcvd MsgSent       TblVer  InQ OutQ  Up/Down  St/PfxRcd
10.0.0.1          0 65001     108     118           20    0    0 01:44:45          1
10.2.3.3          0 65002     131     127           20    0    0 00:00:18          2

設定を戻したのが04:53:46、Upのログが04:54:23で、復旧までに約37秒かかっています。接続に繰り返し失敗した後は再接続までの待ち時間が延びるためで、設定を直した直後にEstablishedにならなくても、しばらく待つ必要があります。

復旧時のパケットです。TCP接続の確立からOPENの交換、KEEPALIVEによる受理、UPDATEによる経路交換までが一度に流れており、BGPメッセージで解説した正常なセッション確立の手順そのものになっています。

R2 - R3間 パケットキャプチャー（復旧時）
262.819168     10.2.3.2 → 10.2.3.3     TCP 62 23990 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
262.822744     10.2.3.3 → 10.2.3.2     TCP 62 179 → 23990 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1240 WS=1
262.825677     10.2.3.2 → 10.2.3.3     TCP 54 23990 → 179 [ACK] Seq=1 Ack=1 Win=32768 Len=0
262.827615     10.2.3.2 → 10.2.3.3     BGP 129 OPEN Message
264.828419     10.2.3.2 → 10.2.3.3     TCP 129 [TCP Retransmission] 23990 → 179 [PSH, ACK] Seq=1 Ack=1 Win=32768 Len=75
264.833015     10.2.3.3 → 10.2.3.2     TCP 54 179 → 23990 [ACK] Seq=1 Ack=76 Win=32768 Len=0
264.833261     10.2.3.3 → 10.2.3.2     BGP 148 OPEN Message, KEEPALIVE Message
264.837829     10.2.3.2 → 10.2.3.3     BGP 73 KEEPALIVE Message
264.869424     10.2.3.3 → 10.2.3.2     BGP 194 UPDATE Message, UPDATE Message, UPDATE Message
265.072809     10.2.3.2 → 10.2.3.3     TCP 54 23990 → 179 [ACK] Seq=95 Ack=235 Win=32534 Len=0
266.867355     10.2.3.2 → 10.2.3.3     BGP 190 UPDATE Message, UPDATE Message, UPDATE Message
267.072666     10.2.3.3 → 10.2.3.2     TCP 54 179 → 23990 [ACK] Seq=235 Ack=231 Win=32613 Len=0

bgp-neighbor-state.pcap をダウンロード

検証Config

R1 config(r1_bgp-neighbor-state.cfg) をダウンロード

 R2 config(r2_bgp-neighbor-state.cfg) をダウンロード

 R3 config(r3_bgp-neighbor-state.cfg) をダウンロード

 R4 config(r4_bgp-neighbor-state.cfg) をダウンロード

参考

資料	タイトル	概要
RFC 4271	A Border Gateway Protocol 4 (BGP-4)	BGP-4の基本仕様。第8章でFSM（状態遷移）を定義。
IANA	Border Gateway Protocol (BGP) Parameters	NOTIFICATIONのエラーコード / サブコードなど、BGPで使われる番号の割り当て一覧。