↓ メインコンテンツへスキップ
KAZULOG.INFO
  1. ネットワーク 記事一覧/
  2. BGP記事一覧/

BGPネイバーの状態遷移

目次

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

BGPはセッション確立までの過程を6つの状態で定義しています（RFC 4271 第8章の有限状態機械）。セッションが確立しないとき、どの状態で止まっているかが原因の切り分けに直結します。この記事では各状態の意味と遷移条件を解説し、IOS XR（XRd）で実際の状態変化を確認します（メッセージの構造はBGPメッセージ）。

6つの状態

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

Connect・OpenSent・OpenConfirmは、ふつう一瞬で通り過ぎます。TCPの接続やOPENの交換は数ミリ秒〜数秒で終わるので、showで止まって見えるのは主にIdle・Active・Establishedの3つです。SYNに応答が無く再送を続けている間も、IOS XRの表示はConnectではなくActiveです。

状態が戻る条件

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

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

Idleに戻ったあとは、ConnectRetryTimerの満了後に再接続を試みます。RFC 4271の推奨値は120秒です（第10章）。IOS XRはこの値をshowに表示しませんが、この記事の検証では、切断から約28秒後に相手が再接続を始めています。

OPENの検証で弾かれる値

OpenSentでは、受け取ったOPENを検証し、問題があればNOTIFICATION（Error code 2、OPEN Message Error）を返します。サブコードで理由が分かります。

サブコード名前条件
2Bad Peer ASOPENのAS番号が、こちらが期待するAS番号と違う
3Bad BGP IdentifierBGP Identifierが0、または同一AS内（iBGP）のピアから自分と同じ値が来た（RFC 6286）
6Unacceptable Hold Time提示されたHold Timeを受け入れられない。1秒と2秒は必ず拒否しなければならない（RFC 4271 6.2）

NOTIFICATIONには診断用のデータ部が付きますが、中身が規定されているのは一部だけです。RFC 4271の6.2が内容を定めているのはUnsupported Version Number（2オクテットのバージョン番号）で、Bad Peer ASのデータ部については何も定めていません。何が入るかは実装しだいです。

BGP Identifierの重複が問題になるのは同一AS内（iBGP）だけです。RFC 6286が一意性の要件を「AS内で一意」に緩和し、OPEN処理でも「内部ピアからのOPENで自分と同じ」場合に限ってBad BGP Identifierとするよう定めているためです。

状態の確認方法

IOS XRではshow bgp summaryのSt/PfxRcd列に、Establishedなら受信プレフィックス数、それ以外なら状態名が出ます。 詳細はshow bgp neighbor <アドレス>で、BGP stateに状態と止まっている理由（例: Idle (Neighbor is shutdown)）、Previous State、Last reset（切断理由）と、NOTIFICATIONによる切断ならError CodeとNotification dataが残ります。状態変化はsyslogに%ROUTING-BGP-5-ADJCHANGEとして記録されます。

状態が停滞する主な原因

止まる状態主な原因（IOS XRのBGP stateの表示）
Idleshutdownが設定されている（Idle (Neighbor is shutdown)）。eBGPで直接接続されておらずebgp-multihopが未設定（Idle (eBGP neighbor not directly connected)）。ピアへの経路がNull0を向いていて送信元アドレスが決まらない（Idle (No best local address found)）。OPENの検証に失敗してNOTIFICATIONを送受信した直後。
ActiveTCPポート179に到達できない。相手がRSTで拒否している。ARPが解決できず接続要求そのものが出ていない。ACLやファイアウォールで遮断されている。MD5認証のパスワードが食い違っている（BGPのセキュリティで解説します）。
OpenSent相手のremote-asの指定が食い違っている。同一AS内（iBGP）でBGP Identifier（Router ID）が重複している。提示されたHold Timeが受け入れられない。
OpenConfirmKEEPALIVEが届かない。片方向の通信障害が起きている。

OpenSentとOpenConfirmの原因は、状態としてはほとんど見えません。検証に失敗するとすぐNOTIFICATIONを送ってIdleに戻るためで、showではIdleと、Last reset・Error Codeの理由として現れます。NOTIFICATIONのError codeとサブコードの一覧はBGPメッセージにあります。

実機での検証

3つのASにXRd 26.1.1を4台置き、R1 - R2間がiBGP、R2 - R3・R3 - R4間がeBGPです。各ルータは192.168.N.0/24を広告しています。

正常な状態から意図的に異常を作り、状態の変化を確認します。キャプチャーはR2 - R3間で取り、R2 - R4のマルチホップのSTEPではR3 - R4間、iBGPのSTEPではR1 - R2間も取りました。eBGPの出方向ルートポリシーはネイバーごとに別名にしています（中身はpassだけ）。

STEP操作確かめること
0初期状態全セッションがEstablished
1R2でR3向けネイバーをshutdown落とした側と落とされた側で表示がどう違うか
2no shutdownで戻す復旧までの時間と、どちらからTCPを張るか
3R2に存在しないピア（10.2.3.99）を設定同じセグメントのアドレスがARPで解決できないとき
4R2に、Null0を向く経路の先のピア（10.9.9.9）を設定経路はあるが出口の無いピアがどの状態で止まるか
5R2・R3の両側にsession-open-mode passive-only確立済みのセッションへの影響
6R2 - R4（R3をまたぐ2ホップ）をLoopback0でピアリングebgp-multihopが無いとどの状態で止まるか
7R2・R4にebgp-multihop 2確立すること
8試験用のピアを片付け、R2でR3のremote-asを誤った値（65999）にするOPENの検証で弾かれたときのNOTIFICATIONとデータ部
9remote-asを戻し、R3のBGP IdentifierをR2と同じ10.0.0.2にする（eBGP）ASが異なる場合の重複
10R3を戻し、R1のBGP IdentifierをR2と同じ10.0.0.2にする（iBGP）同一AS内での重複
11R1を戻し、R3にtimers 30 2を入れようとする1秒・2秒のHold Timeの扱い
12R3のACLでR2からのTCP179だけを遮断Hold Timeの満了と、SYNに応答が無いときの表示
13ACLを削除して元に戻す（最終状態）再確立

STEP 1: 管理者によるshutdown

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

R2 ネイバーのshutdown（STEP 1）
router bgp 65001
 neighbor 10.2.3.3
  shutdown
 !
!

shutdownした側のR2はIdle (Admin)、された側のR3はActiveです。R3はR2からのNOTIFICATIONで切れたあと、自分からTCP接続を再試行し続けています。

R2 show bgp summary（STEP 1、抜粋）
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      34      37            8    0    0 00:30:40          1
10.2.3.3          0 65002      31      32            0    0    0 00:04:12  Idle (Admin)
R3 show bgp summary（STEP 1、抜粋）
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      32      31            0    0    0 00:04:55  Active
10.3.4.4          0 65003      35      37            8    0    0 00:31:23          1

show bgp neighborでは理由まで分かります。R2はIdle (Neighbor is shutdown)で、CEASE NOTIFICATIONを送ったことがLast resetに残ります。R3はActiveで、理由はNOTIFICATIONの受信です。

R2 show bgp neighbor 10.2.3.3（STEP 1、抜粋）
BGP neighbor is 10.2.3.3
 Remote AS 65002, local AS 65001, external link
 Administratively shut down
<snip>
  BGP state = Idle (Neighbor is shutdown)
  Previous State: Closing
<snip>
  Connections established 1; dropped 1
  Local host: 10.2.3.2, Local port: 24097, IF Handle: 0x00000010
  Foreign host: 10.2.3.3, Foreign port: 179
  Last reset 00:04:14, due to Admin. shutdown (CEASE notification sent - administrative shutdown)
  Time since last notification sent to neighbor: 00:04:14
  Error Code: administrative shutdown
  Notification data sent:
    None
R3 show bgp neighbor 10.2.3.2（STEP 1、抜粋）
BGP neighbor is 10.2.3.2
 Remote AS 65001, local AS 65002, external link
<snip>
  BGP state = Active
  Previous State: Idle
<snip>
  Connections established 1; dropped 1
  Local host: 10.2.3.3, Local port: 179, IF Handle: 0x00000008
  Foreign host: 10.2.3.2, Foreign port: 24097
  Last reset 00:04:57, due to BGP Notification received: administrative shutdown
  Time since last notification received from neighbor: 00:04:57
  Error Code: administrative shutdown
  Notification data received:
    None

キャプチャーでは、R2がNOTIFICATIONを送ってTCPを閉じたあと（No.1〜4）、約28秒後からR3がSYNを送り、R2がすべてRSTで拒否しています（No.6〜14）。これがActiveの実体です。SYNは同じ送信元ポートから2秒・4秒・8秒の間隔で再送されています。

R2 - R3間 パケットキャプチャー（STEP 1、tshark一覧、TCPのACKのみの行は省略）
    1   0.000000     10.2.3.2 → 10.2.3.3     BGP 75 NOTIFICATION Message
    2   0.000261     10.2.3.2 → 10.2.3.3     TCP 54 24097 → 179 [FIN, ACK] Seq=22 Ack=1 Win=32040 Len=0
    4   0.006086     10.2.3.3 → 10.2.3.2     TCP 54 179 → 24097 [FIN, ACK] Seq=1 Ack=23 Win=32098 Len=0
    6  28.035243     10.2.3.3 → 10.2.3.2     TCP 62 16391 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
    7  28.038540     10.2.3.2 → 10.2.3.3     TCP 54 179 → 16391 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
    8  30.001146     10.2.3.2 → 10.2.3.3     TCP 54 24097 → 179 [RST, ACK] Seq=23 Ack=2 Win=32040 Len=0
    9  30.035837     10.2.3.3 → 10.2.3.2     TCP 62 [TCP Port numbers reused] 16391 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
   10  30.038199     10.2.3.2 → 10.2.3.3     TCP 54 179 → 16391 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
   11  34.036853     10.2.3.3 → 10.2.3.2     TCP 62 [TCP Port numbers reused] 16391 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
   12  34.039675     10.2.3.2 → 10.2.3.3     TCP 54 179 → 16391 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
   13  42.037529     10.2.3.3 → 10.2.3.2     TCP 62 [TCP Port numbers reused] 16391 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
   14  42.040952     10.2.3.2 → 10.2.3.3     TCP 54 179 → 16391 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

NOTIFICATIONはError code 6（Cease）、サブコード2（Administratively Shutdown）です。clear bgpのサブコード4（Administratively Reset）と区別できます。

STEP 1 No.1 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)
上のtshark出力のパケット（STEP 1 No.1 NOTIFICATION）のpcapをダウンロード

STEP 2: no shutdownで復旧する

no shutdownで戻すと、commit（12:26:50）からUp（12:27:01）まで約11秒で復旧しました。

R2 syslog（STEP 2、抜粋）
RP/0/RP0/CPU0:Sep 21 12:26:50.085 UTC: config[67347]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'cisco'. Use 'show configuration commit changes 1000000002' to view the changes. 
RP/0/RP0/CPU0:Sep 21 12:27:01.302 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.2.3.3 Up (VRF: default) (AS: 65002)

接続を張ったのは、Activeで再試行を続けていたR3です。R3のSYNがR2に受け付けられた瞬間（No.8のSYN/ACK）から、OPEN・KEEPALIVE・UPDATEへ進んでいます。

R2 - R3間 パケットキャプチャー（STEP 2、tshark一覧）
    1   0.000000     10.2.3.3 → 10.2.3.2     TCP 62 16391 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
    3   2.000394     10.2.3.3 → 10.2.3.2     TCP 62 [TCP Port numbers reused] 16391 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
    5   6.001448     10.2.3.3 → 10.2.3.2     TCP 62 [TCP Port numbers reused] 16391 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
    7  14.002077     10.2.3.3 → 10.2.3.2     TCP 62 [TCP Port numbers reused] 16391 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
    8  14.005638     10.2.3.2 → 10.2.3.3     TCP 62 179 → 16391 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1240 WS=1
   10  14.010900     10.2.3.3 → 10.2.3.2     BGP 129 OPEN Message
   13  16.016593     10.2.3.2 → 10.2.3.3     BGP 129 OPEN Message
   14  16.020389     10.2.3.3 → 10.2.3.2     BGP 73 KEEPALIVE Message
   15  16.023160     10.2.3.2 → 10.2.3.3     BGP 73 KEEPALIVE Message
   16  16.057415     10.2.3.3 → 10.2.3.2     BGP 194 UPDATE Message, UPDATE Message, UPDATE Message
   17  16.060325     10.2.3.2 → 10.2.3.3     BGP 190 UPDATE Message, UPDATE Message, UPDATE Message

双方が同時に接続を試みて2本のTCPが成立した場合は、BGP Identifierの大きい側が開始した接続が残ります（RFC 4271 6.8）。

STEP 3: 到達できないピアを設定した場合

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

R2 show bgp summary（STEP 3、抜粋）
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      44      49           10    0    0 00:40:56          1
10.2.3.3          0 65002      43      44           10    0    0 00:07:04          2
10.2.3.99         0 65099       0       0            0    0    0 00:00:00  Active

ただし送受信メッセージ数も確立回数も0で、Local port: 0とローカルポートすら割り当てられていません。Activeでも、TCPの接続要求は1つも出ていません。

R2 show bgp neighbor 10.2.3.99（STEP 3、抜粋）
BGP neighbor is 10.2.3.99
 Remote AS 65099, local AS 65001, external link
<snip>
  BGP state = Active
  Previous State: Idle
  Last Received Message: None
<snip>
  Received 0 messages, 0 notifications, 0 in queue
  Sent 0 messages, 0 notifications, 0 in queue
<snip>
  Connections established 0; dropped 0
  Local host: 10.2.3.2, Local port: 0, IF Handle: 0x00000000
  Foreign host: 10.2.3.99, Foreign port: 0
  Last reset 00:00:00

10.2.3.99は同一セグメントのアドレスですが実体が無く、ARPが解決できないためです。

R2 show arp（STEP 3）
RP/0/RP0/CPU0:R2#show arp
Mon Sep 21 12:34:11.126 UTC

-------------------------------------------------------------------------------
0/RP0/CPU0
-------------------------------------------------------------------------------
Address         Age        Hardware Addr   State      Type  Interface
10.1.2.1        00:41:13   5254.0004.87f3  Dynamic    ARPA  GigabitEthernet0/0/0/0
10.1.2.2        -          5254.00c3.c843  Interface  ARPA  GigabitEthernet0/0/0/0
10.2.3.2        -          5254.0090.1ff4  Interface  ARPA  GigabitEthernet0/0/0/1
10.2.3.3        00:41:05   5254.00ed.b852  Dynamic    ARPA  GigabitEthernet0/0/0/1

STEP 4: 出口の無い経路の先にあるピア

R2に10.9.9.9/32をNull0へ向けるスタティック経路を入れ、そのアドレスをピアにします。経路はあるが、パケットの出口がありません。

R2 show route 10.9.9.9/32（STEP 4）
RP/0/RP0/CPU0:R2#show route 10.9.9.9/32
Mon Sep 21 12:38:54.238 UTC

Routing entry for 10.9.9.9/32
  Known via "static", distance 1, metric 0 (connected)
  Installed Sep 21 12:36:13.486 for 00:02:40
  Routing Descriptor Blocks
    directly connected, via Null0
      Route metric is 0
  No advertising protos.

状態はIdleで、理由はNo best local address foundです。出口のインタフェースが無いので送信元アドレスを決められず、TCPを始められません。STEP 3（Active、Local host: 10.2.3.2）と違い、Local hostも0.0.0.0です。

R2 show bgp neighbor 10.9.9.9（STEP 4、抜粋）
BGP neighbor is 10.9.9.9
 Remote AS 65099, local AS 65001, external link
<snip>
  BGP state = Idle (No best local address found)
  Previous State: Idle
<snip>
  Connections established 0; dropped 0
  Local host: 0.0.0.0, Local port: 0, IF Handle: 0x00000000
  Foreign host: 10.9.9.9, Foreign port: 0
  Last reset 00:00:00

STEP 5: 両側にsession-open-mode passive-only

session-open-mode passive-onlyは、自分からTCP接続を始めず、相手からの接続だけを受け付ける設定です。R2・R3の両側に入れると、設定は受け付けられ、TCP open mode: passive onlyと表示されます。

R2 show bgp neighbor 10.2.3.3（STEP 5、抜粋）
BGP neighbor is 10.2.3.3
 Remote AS 65002, local AS 65001, external link
<snip>
  BGP state = Established, up for 00:16:35
<snip>
  TCP open mode: passive only
<snip>
  Connections established 2; dropped 1

確立済みのセッションは切れません。この設定はTCPの接続を「始めるかどうか」を決めるもので、張ってあるセッションには作用しないためです。

STEP 6: 直接接続されていないeBGPピア

R2とR4は、R3をはさんで2ホップ離れています。互いのLoopback0へのスタティック経路を入れてから、Loopback0同士でeBGPピアを設定します（update-source Loopback0、ebgp-multihopは無し）。

R2 show bgp neighbor 10.0.0.4（STEP 6、抜粋）
BGP neighbor is 10.0.0.4
 Remote AS 65003, local AS 65001, external link
<snip>
  BGP state = Idle (eBGP neighbor not directly connected)
<snip>
  Connections established 0; dropped 0
  Local host: 0.0.0.0, Local port: 0, IF Handle: 0x00000000
<snip>
  Last reset 00:00:00
  External BGP neighbor not directly connected.

状態はIdle (eBGP neighbor not directly connected)で、TCPを始めていません（Connections established 0）。eBGPは既定で直接接続のピアとしか張らないためです。R4側も同じ表示になります。TTLの扱いを含む仕組みはiBGPとeBGPの違いで解説しています。

STEP 7: ebgp-multihopで確立する

R2・R4の両側にebgp-multihop 2を入れると確立し、表示がmay be up to 2 hops awayに変わります。

R2 show bgp summary（STEP 7、抜粋）
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      64      69           11    0    0 01:00:57          1
10.0.0.4          0 65003      10      12           11    0    0 00:02:54          2
10.2.3.3          0 65002      63      65           11    0    0 00:27:05          2
R2 show bgp neighbor 10.0.0.4（STEP 7、抜粋）
BGP neighbor is 10.0.0.4
 Remote AS 65003, local AS 65001, external link
<snip>
  BGP state = Established, up for 00:02:56
<snip>
  External BGP neighbor may be up to 2 hops away.

STEP 8: AS番号が一致しない場合

試験用のピアとスタティック経路を片付け、R2でR3のremote-asを実際とは異なる65999にします。R2は65999を期待し、R3は65002を名乗ってくるので、OpenSentで不一致を検出します。表示はIdleです。

R2 show bgp summary（STEP 8、抜粋）
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      72      79           14    0    0 01:08:39          1
10.2.3.3          0 65999      76      80            0    0    0 00:04:27  Idle

Error Codeはpeer in wrong ASで、NOTIFICATIONのデータ部（EAFD0000）も残ります。

R2 show bgp neighbor 10.2.3.3（STEP 8、抜粋）
BGP neighbor is 10.2.3.3
 Remote AS 65999, local AS 65001, external link
<snip>
  BGP state = Idle
<snip>
  Connections established 2; dropped 2
<snip>
  Last reset 00:00:09, due to BGP Notification sent: peer in wrong AS
<snip>
  Error Code: peer in wrong AS
  Notification data sent:
    EAFD0000

キャプチャーでは、R3のOPENを受けた直後にR2がNOTIFICATIONを返しています（No.15）。OpenSentでの失敗の典型で、TCPが成立してOPENまで進み、そこで切れることを30〜40秒ごとに繰り返します。

R2 - R3間 パケットキャプチャー（STEP 8、tshark一覧、抜粋）
    1   0.000000     10.2.3.2 → 10.2.3.3     BGP 73 KEEPALIVE Message
    8  43.575979     10.2.3.2 → 10.2.3.3     TCP 62 45521 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
    9  43.580362     10.2.3.3 → 10.2.3.2     TCP 62 179 → 45521 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1240 WS=1
   11  43.584497     10.2.3.2 → 10.2.3.3     BGP 129 OPEN Message
   14  45.591283     10.2.3.3 → 10.2.3.2     BGP 148 OPEN Message, KEEPALIVE Message
   15  45.600958     10.2.3.2 → 10.2.3.3     BGP 79 NOTIFICATION Message

NOTIFICATIONはError code 2（OPEN Message Error）、サブコード2（Bad Peer AS）です。

STEP 8 No.15 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
上のtshark出力のパケット（STEP 8 No.15 NOTIFICATION）のpcapをダウンロード

Bad Peer AS: 3942449152は、R2がこのASを問題にしたという意味ではありません。データ部の4オクテットはea fd 00 00で、0xFDEA（= 65002、R3が名乗ったAS番号）の2オクテットが逆の順で入り、残りが0で埋められています。Wiresharkはこれを4バイトのAS番号として読むので、0xEAFD0000 = 3942449152と表示します。RFC 4271はBad Peer ASのデータ部の中身を定めていないので、これはXRdの実装が入れている診断情報です。

STEP 8 No.15 NOTIFICATION（R2 → R3）tshark -x
0000  52 54 00 ed b8 52 52 54 00 90 1f f4 08 00 45 c0   RT...RRT......E.
0010  00 41 b8 7f 00 00 01 06 e6 6f 0a 02 03 02 0a 02   .A.......o......
0020  03 03 b1 d1 00 b3 43 d0 95 a5 cd ac 7f ae 50 18   ......C.......P.
0030  7f a2 39 ad 00 00 ff ff ff ff ff ff ff ff ff ff   ..9.............
0040  ff ff ff ff ff ff 00 19 03 02 02 ea fd 00 00      ...............

対照として、STEP 10のBad BGP Identifierのデータ部は0a 00 00 02（= 10.0.0.2）で、そのままの並びです。

STEP 9: BGP Identifierを重複させる（eBGP）

remote-asを戻し、R3のBGP IdentifierをR2と同じ10.0.0.2にします。R2とR3はASの異なるeBGPピアです。セッションは張り直されますが、結果はEstablishedで、R2から見た相手のRouter IDは自分と同じ10.0.0.2です。

R2 show bgp neighbor 10.2.3.3（STEP 9、抜粋）
BGP neighbor is 10.2.3.3
 Remote AS 65002, local AS 65001, external link
<snip>
 Remote router ID 10.0.0.2
  BGP state = Established, up for 00:02:19

キャプチャーでも、R2とR3がどちらもBGP Identifier: 10.0.0.2のOPENを送り合い、KEEPALIVEに進んでいます。

R2 - R3間 パケットキャプチャー（STEP 9、OPENとKEEPALIVE）
6	10.2.3.2	10.2.3.3	10.0.0.2	OPEN Message
9	10.2.3.3	10.2.3.2	10.0.0.2	OPEN Message

RFC 6286のとおり、ASが異なる相手との重複はエラーになりません。

STEP 10: BGP Identifierを重複させる（iBGP）

R3を戻し、今度はR1のBGP IdentifierをR2と同じ10.0.0.2にします。R1とR2は同じASのiBGPピアです。今度は確立せず、R1向けがIdleのまま止まります。

R2 show bgp summary（STEP 10、抜粋）
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      89      97            0    0    0 00:03:24  Idle
10.2.3.3          0 65002      98     101           21    0    0 00:02:57          2

Error Code: BGP identifier wrongが送受信の両方に残り、R1とR2が互いのOPENを拒否し合っています。データ部の0A000002は10.0.0.2です。

R2 show bgp neighbor 10.0.0.1（STEP 10、抜粋）
BGP neighbor is 10.0.0.1
 Remote AS 65001, local AS 65001, internal link
<snip>
  BGP state = Idle
<snip>
  Last reset 00:00:11, due to BGP Notification received: BGP identifier wrong
<snip>
  Error Code: BGP identifier wrong
  Notification data sent:
    0A000002
<snip>
  Error Code: BGP identifier wrong
  Notification data received:
    0A000002

Error code 2（OPEN Message Error）、サブコード3（Bad BGP Identifier）です（R1 - R2間のキャプチャーのNo.20）。

STEP 10 No.20 NOTIFICATION 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 BGP Identifier (3)
    Data: 0a000002
上のtshark出力のパケット（STEP 10 No.20 NOTIFICATION）のpcapをダウンロード

同じ重複でも、STEP 9とSTEP 10で結果が正反対です。

重複させた相手ASの関係結果
R3（eBGP）AS 65001 ↔ AS 65002（異なる）確立する。Remote router ID 10.0.0.2のままEstablished
R1（iBGP）AS 65001 ↔ AS 65001（同じ）確立しない。Bad BGP Identifier (3)でIdle

STEP 11: 1秒・2秒のHold Timeは設定できない

R1を戻したうえで、R3のR2向けネイバーにHold Time 2秒（timers 30 2）を入れようとします。XRdは設定モードの時点で% Invalid inputとして受け付けません。

R3 timers 30 2の投入（STEP 11）
RP/0/RP0/CPU0:R3#configure
<snip>
RP/0/RP0/CPU0:R3(config)#router bgp 65002
RP/0/RP0/CPU0:R3(config-bgp)#neighbor 10.2.3.2
RP/0/RP0/CPU0:R3(config-bgp-nbr)#timers 30 2
                                           ^
% Invalid input detected at '^' marker.
<snip>
router bgp 65002
 neighbor 10.2.3.2
<snip>
RP/0/RP0/CPU0:R3(config-bgp-nbr)#abort
RP/0/RP0/CPU0:R3#show running-config router bgp 65002 neighbor 10.2.3.2
<snip>
router bgp 65002
 neighbor 10.2.3.2

RFC 4271の6.2は「1秒と2秒のHold Timeは拒否しなければならない」と定めています。XRdはこれを、相手からのNOTIFICATION（Unacceptable Hold Time）に至る前に、自分の設定の段階で止めています。そのためこの検証では、サブコード6のNOTIFICATIONは観測していません。

STEP 12: Hold Timeの間に受信できなくする

R3にACLを設定してR2から来るTCP 179だけを落とし、片方向で届かない状態を作ります（ipv4 unreachables disableで、落としたことをICMPでも知らせません）。

R3 R2からのBGPだけを遮断（STEP 12）
ipv4 access-list BLOCK-BGP-FROM-R2
 10 deny tcp host 10.2.3.2 any eq bgp
 20 deny tcp host 10.2.3.2 eq bgp any
 30 permit ipv4 any any
!
interface GigabitEthernet0/0/0/0
 ipv4 unreachables disable
 ipv4 access-group BLOCK-BGP-FROM-R2 ingress
!

R2のKEEPALIVEは60秒ごとに送られていて、ACLの適用（13:20:49）より前に届いた最後の1つは13:20:18.821です（STEP 11のキャプチャーの最後のKEEPALIVE）。そのちょうど180秒後の13:23:18.825に、R3のHold Timerが満了しました。

R3 syslog（STEP 12、抜粋）
RP/0/RP0/CPU0:Sep 21 13:20:49.828 UTC: config[67373]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'cisco'. Use 'show configuration commit changes 1000000006' to view the changes. 
RP/0/RP0/CPU0:Sep 21 13:23:18.825 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.2.3.2 Down - BGP Notification sent, hold time expired (VRF: default) (AS: 65001)

キャプチャーには、ACLで落とされたR2のKEEPALIVE（13:21:18.821）と、R3が送ったNOTIFICATIONが入っています。

R2 - R3間 パケットキャプチャー（STEP 12、BGPのみ、時刻表示）
    1 2026-09-21 13:21:03.537977Z     10.2.3.3 → 10.2.3.2     BGP 73 KEEPALIVE Message
   13 2026-09-21 13:21:18.821789Z     10.2.3.2 → 10.2.3.3     BGP 73 KEEPALIVE Message
   26 2026-09-21 13:23:06.230332Z     10.2.3.2 → 10.2.3.3     BGP 73 [TCP ACKed unseen segment] , KEEPALIVE Message
   28 2026-09-21 13:23:18.828735Z     10.2.3.3 → 10.2.3.2     BGP 75 NOTIFICATION Message
   29 2026-09-21 13:23:18.831584Z     10.2.3.2 → 10.2.3.3     BGP 73 KEEPALIVE Message

Error codeは4（Hold Timer Expired）で、サブコードの定義が無いため0です。

STEP 12 No.28 NOTIFICATION（R3 → R2）tshark -V
Border Gateway Protocol - NOTIFICATION Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 21
    Type: NOTIFICATION Message (3)
    Major error Code: Hold Timer Expired (4)
    Minor error Code (Hold Timer Expired): 0
上のtshark出力のパケット（STEP 12 No.28 NOTIFICATION）のpcapをダウンロード

満了させたR3はError Code: hold time expiredをNOTIFICATIONの送信として、R2は受信として記録しています。

R3 show bgp neighbor 10.2.3.2（STEP 12、抜粋）
BGP neighbor is 10.2.3.2
 Remote AS 65001, local AS 65002, external link
<snip>
  BGP state = Active
<snip>
  Last reset 00:05:18, due to BGP Notification sent: hold time expired
<snip>
  Error Code: hold time expired
<snip>
  Error Code: peer in wrong AS
R2 show bgp neighbor 10.2.3.3（STEP 12、抜粋）
BGP neighbor is 10.2.3.3
 Remote AS 65002, local AS 65001, external link
<snip>
  BGP state = Active
<snip>
  Last reset 00:04:37, due to BGP Notification received: hold time expired
<snip>
  Error Code: peer in wrong AS
<snip>
  Error Code: hold time expired

SYNに応答が無いときの表示もここで分かります。切断後、R2は再接続を試みますが、そのSYNはR3のACLで黙って捨てられ、2秒・4秒・8秒の間隔で再送されています。この間のR2の表示はConnectではなくActiveです。

R2 → R3のSYN（STEP 12、tshark一覧）
   34 180.219906     10.2.3.2 → 10.2.3.3     TCP 62 56683 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=1
   38 182.220440     10.2.3.2 → 10.2.3.3     TCP 62 [TCP Retransmission] 56683 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=1
   42 186.220540     10.2.3.2 → 10.2.3.3     TCP 62 [TCP Retransmission] 56683 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=1
   46 194.221552     10.2.3.2 → 10.2.3.3     TCP 62 [TCP Retransmission] 56683 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=1
   50 260.170479     10.2.3.2 → 10.2.3.3     TCP 62 [TCP Port numbers reused] 56683 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=1
   54 262.170929     10.2.3.2 → 10.2.3.3     TCP 62 [TCP Retransmission] 56683 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=1
Hold Timer Expiredは相手が落ちたときだけでなく、片方向だけ通信できなくなったときにも起きます。pingは通ることもあり、L3の到達性だけでは切り分けられません。

STEP 13: 元に戻す

ACLを削除すると、次の接続試行でセッションが再確立します（削除のcommitから約51秒）。

R3 syslog（STEP 13、抜粋）
RP/0/RP0/CPU0:Sep 21 13:30:47.148 UTC: config[68614]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'cisco'. Use 'show configuration commit changes 1000000007' to view the changes. 
RP/0/RP0/CPU0:Sep 21 13:31:38.231 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.2.3.2 Up (VRF: default) (AS: 65001)

エラーコードのまとめ

観測したNOTIFICATIONの一覧です。show bgp neighborのError Codeとパケット上のコードが対応します。

STEP操作Error codeサブコードshow bgp neighborのError Code
1shutdown6 Cease2 Administratively Shutdownadministrative shutdown
8remote-asの誤設定2 OPEN Message Error2 Bad Peer ASpeer in wrong AS
10iBGPでのBGP Identifier重複2 OPEN Message Error3 Bad BGP IdentifierBGP identifier wrong
12Hold Timeの間に受信できず4 Hold Timer Expired0（定義なし）hold time expired

検証Configおよびshow結果

各STEPで4台すべてから、次の種類をルータごとに分けて取得しています。検証Configはこの..._run.txtです（最終状態はSTEP 13のもの）。

ファイル内容
..._show.txtshow version / show interface description / show route / show bgp / show bgp summary / show bgp <プレフィックス> / show bgp neighbors / ピアごとのadvertised-routes・routes・received routes / show bgp update-group / show rpl route-policy。R1・R2はshow ospf neighborも含む。STEP 3のR2はshow arp、STEP 4のR2はshow route 10.9.9.9/32、STEP 12・13のR3はshow access-lists ipv4も含む
..._log.txtそのSTEPの範囲だけに絞ったshow logging。各STEPの開始時にlogmsgでマーカーを入れ、その時刻をshow logging startに指定して取得したもの
..._run.txtそのSTEP時点のshow running-config（＝そのSTEPの検証Config）
..._ping.txtそのSTEPのpingとtraceroute（R1・R2・R4から192.168.4.1または192.168.1.1へ50発）
..._trace.txtshow bgp trace neighborとshow bgp trace error（BGPプロセス内部のイベント）
..._commit.cfgそのSTEPで実際にコミットされた設定（設定を変えたルータのみ）
..._exec.txt設定を入れようとして拒否された様子（STEP 11のR3）

最終状態は、R1 - R2がiBGP（Loopback0ピア、OSPF area 0）、R2 - R3とR3 - R4がeBGPで、各ルータが192.168.N.0/24を広告している初期状態と同じです。

STEP 0：初期状態

ルータshow出力syslogrunning-configpingtrace投入した設定
R1showlogrunpingtrace—
R2showlogrunpingtrace—
R3showlogrun—trace—
R4showlogrunpingtrace—

STEP 1：R2でR3向けネイバーをshutdown

ルータshow出力syslogrunning-configpingtrace投入した設定
R1showlogrunpingtrace—
R2showlogrunpingtracecommit
R3showlogrun—trace—
R4showlogrunpingtrace—

STEP 2：no shutdownで戻す

ルータshow出力syslogrunning-configpingtrace投入した設定
R1showlogrunpingtrace—
R2showlogrunpingtracecommit
R3showlogrun—trace—
R4showlogrunpingtrace—

STEP 3：R2に存在しないピア10.2.3.99を設定

ルータshow出力syslogrunning-configpingtrace投入した設定
R1showlogrunpingtrace—
R2showlogrunpingtracecommit
R3showlogrun—trace—
R4showlogrunpingtrace—

STEP 4：R2に、Null0を向く経路の先のピア10.9.9.9を設定

ルータshow出力syslogrunning-configpingtrace投入した設定
R1showlogrunpingtrace—
R2showlogrunpingtracecommit
R3showlogrun—trace—
R4showlogrunpingtrace—

STEP 5：R2・R3の両側にsession-open-mode passive-only

ルータshow出力syslogrunning-configpingtrace投入した設定
R1showlogrunpingtrace—
R2showlogrunpingtracecommit
R3showlogrun—tracecommit
R4showlogrunpingtrace—

STEP 6：R2 - R4をLoopback0でピアリング（ebgp-multihopなし）

ルータshow出力syslogrunning-configpingtrace投入した設定
R1showlogrunpingtrace—
R2showlogrunpingtracecommit
R3showlogrun—tracecommit
R4showlogrunpingtracecommit

STEP 7：R2・R4にebgp-multihop 2

ルータshow出力syslogrunning-configpingtrace投入した設定
R1showlogrunpingtrace—
R2showlogrunpingtracecommit
R3showlogrun—trace—
R4showlogrunpingtracecommit

STEP 8：試験用ピアを片付け、R2でR3のremote-asを65999にする

ルータshow出力syslogrunning-configpingtrace投入した設定
R1showlogrunpingtrace—
R2showlogrunpingtracecommit
R3showlogrun—tracecommit
R4showlogrunpingtracecommit

STEP 9：remote-asを戻し、R3のBGP Identifierを10.0.0.2にする（eBGP）

ルータshow出力syslogrunning-configpingtrace投入した設定
R1showlogrunpingtrace—
R2showlogrunpingtracecommit
R3showlogrun—tracecommit
R4showlogrunpingtrace—

STEP 10：R3を戻し、R1のBGP Identifierを10.0.0.2にする（iBGP）

ルータshow出力syslogrunning-configpingtrace投入した設定
R1showlogrunpingtracecommit
R2showlogrunpingtrace—
R3showlogrun—tracecommit
R4showlogrunpingtrace—

STEP 11：R1を戻し、R3にtimers 30 2を入れようとする

ルータshow出力syslogrunning-configpingtrace投入した設定
R1showlogrunpingtracecommit
R2showlogrunpingtrace—
R3showlogrun—traceexec
R4showlogrunpingtrace—

STEP 12：R3のACLでR2からのTCP179を遮断

ルータshow出力syslogrunning-configpingtrace投入した設定
R1showlogrunpingtrace—
R2showlogrunpingtrace—
R3showlogrun—tracecommit
R4showlogrunpingtrace—

STEP 13：ACLを削除して元に戻す（最終状態）

ルータshow出力syslogrunning-configpingtrace投入した設定
R1showlogrunpingtrace—
R2showlogrunpingtrace—
R3showlogrun—tracecommit
R4showlogrunpingtrace—

パケットキャプチャーはSTEPごとに取得しています（キャプチャーしていない区間は「—」）。

STEPR2 - R3間R3 - R4間R1 - R2間
0pcap——
1pcap——
2pcap——
3pcap——
4pcap——
5pcap——
6pcappcap—
7pcappcap—
8pcap——
9pcap——
10pcap—pcap
11pcap—pcap
12pcap——
13pcap——

参考

資料タイトル概要
RFC 4271A Border Gateway Protocol 4 (BGP-4)BGP-4の基本仕様。第8章でFSM（状態遷移）、6.2でOPENの検証、第10章でタイマーの推奨値を定義。
RFC 6286Autonomous-System-Wide Unique BGP Identifier for BGP-4BGP Identifierの一意性要件を「AS内で一意」に緩和。
IANABorder Gateway Protocol (BGP) ParametersNOTIFICATIONのエラーコード / サブコードなど、BGPで使われる番号の割り当て一覧。

関連記事