2026年9月9日

2026年9月9日

BGP のネイバー(近隣)を構築する方法|eBGP/iBGP の設定と Established までの確認手順

BGP のネイバーは「TCP 179番で相手とつながり、OPEN メッセージの中身(AS番号・ルーターID・タイマーなど)が合意できたとき」に Established になります。この記事では、FRRouting(FRR)と Cisco IOS を例に、ネイバーを張るまでの設定手順と、状態表示から「どこで止まっているか」を読む方法を説明します。読み終えるころには、自分の環境でネイバーを立ち上げ、経路の送受信まで確認できるようになることを目指します。

作業の前に決めておくこと

BGP の設定は数行ですが、事前に決めるべき値が揃っていないと、相手側との調整で何度もやり直すことになります。最初に次の項目を相手(ISP・データセンター・クラウド事業者、または自社の別拠点)と突き合わせてください。

  • 自分の AS 番号と相手の AS 番号(検証や閉じた環境ならプライベート AS の 64512〜65534 など)
  • ネイバーのアドレス(直結インターフェースのアドレスか、ループバックか)
  • 認証の有無と共有パスワード(TCP MD5 認証を使うか)
  • 自分が広報するプレフィックスと、相手から受け取るプレフィックス(フルルートか、デフォルトルートのみか)
  • BFD を併用するかどうか、タイマー値の希望

AS 番号が同じなら iBGP、異なれば eBGP です。インターネットに自分のアドレスを広報する場合は、AS 番号と IP アドレスの割り当て、IRR・RPKI の登録が前提になります。この準備は別記事で扱っているので、末尾のリンクを参照してください。

ネイバーが Established になるまでの流れ

ネイバーの状態は有限状態機械(FSM)で表され、show bgp summary などで確認できます。状態の意味を知っておくと、設定が正しいかどうかを推測ではなく表示から判断できます。

  • Idle:何もしていない状態。設定が無い、相手への経路が無い、管理的に shutdown されている、などで止まります。
  • Connect / Active:TCP 接続を試みている状態。名前から誤解されやすいのですが、Active に留まり続けるのは「TCP がつながっていない」ことを意味し、良い状態ではありません。
  • OpenSent / OpenConfirm:TCP はつながり、OPEN メッセージを交換している段階です。ここで止まる、または Idle に戻る場合は、AS 番号の不一致など OPEN の中身に問題があります。
  • Established:ネイバー確立。ここから UPDATE で経路を交換します。

つまり、Active なら「到達性・ファイアウォール・アドレス」、OpenSent 付近なら「AS 番号・認証・パラメーター」と、疑う場所が変わります。

FRRouting でネイバーを設定する(Linux)

Linux サーバーで BGP を話す場合は FRR が広く使われています。設定項目の既定値は FRR のバージョンで変わることがあるので(2026年10月現在)、導入したバージョンのドキュメントも合わせて確認してください。

bgpd を有効にする

FRR は機能ごとにデーモンが分かれており、BGP は bgpd です。/etc/frr/daemons で有効にしてから再起動します。

sudo sed -i 's/^bgpd=no/bgpd=yes/' /etc/frr/daemons
sudo systemctl restart frr
sudo vtysh -c "show daemons"

eBGP ネイバーの基本設定

以下は AS65001 の自分が、直結の 198.51.100.2(AS65002)と eBGP を張り、203.0.113.0/24 を広報して、相手からはデフォルトルートだけを受け取る例です。vtysh に入って configure terminal から投入します。

ip prefix-list PL-OUT seq 10 permit 203.0.113.0/24
ip prefix-list PL-IN  seq 10 permit 0.0.0.0/0
!
route-map RM-OUT permit 10
 match ip address prefix-list PL-OUT
!
route-map RM-IN permit 10
 match ip address prefix-list PL-IN
!
router bgp 65001
 bgp router-id 192.0.2.1
 neighbor 198.51.100.2 remote-as 65002
 neighbor 198.51.100.2 description to-AS65002
 neighbor 198.51.100.2 password your-shared-secret
 !
 address-family ipv4 unicast
  network 203.0.113.0/24
  neighbor 198.51.100.2 route-map RM-IN in
  neighbor 198.51.100.2 route-map RM-OUT out
 exit-address-family
!
end
write memory

ポイントは三つあります。

一つ目は、入出力のフィルターを最初から付けることです。近年の FRR では、RFC 8212 に沿って「ポリシーが無い eBGP ネイバーとは経路を送受信しない」動作が既定になっています(bgp ebgp-requires-policy)。ネイバーは Established になるのに経路が 0 件、という状態の多くはこれが原因です。フィルターを外して回避するのではなく、意図した経路だけを通す route-map を書くのが正しい対処です。

二つ目は、network で広報するプレフィックスが、ルーティングテーブルに実在している必要があることです。FRR は既定でこの存在確認を行うため、該当経路が無いと広報されません。集約アドレスを広報したい場合は、Null0 宛ての静的ルートを用意するのが一般的です。

三つ目は、パスワード(TCP MD5 認証)は両側で一致している必要があり、片側だけ設定するとネイバーは上がりません。値は例のような分かりやすいダミーにせず、相手と安全な経路で共有してください。

ファイアウォールで TCP 179 を相手だけに許可する

BGP は TCP 179 番を使います。サーバーのファイアウォールやクラウドのセキュリティグループで、ネイバーのアドレスからの 179 番だけを許可し、それ以外には開けないようにします。

# nftables の例(既存のテーブル・チェーン名に合わせて変更)
sudo nft add rule inet filter input ip saddr 198.51.100.2 tcp dport 179 accept

Cisco IOS での対向設定

相手が Cisco IOS の場合、対向の設定はおおむね次のようになります。IOS XE など系列やバージョンで細部が異なるため、実機のドキュメントで確認してください。

router bgp 65002
 bgp router-id 198.51.100.2
 bgp log-neighbor-changes
 neighbor 198.51.100.1 remote-as 65001
 neighbor 198.51.100.1 password your-shared-secret
 !
 address-family ipv4
  neighbor 198.51.100.1 activate
  neighbor 198.51.100.1 default-originate
 exit-address-family

bgp log-neighbor-changes を入れておくと、ネイバーの上下がログに残り、後の切り分けが楽になります。

iBGP とループバック、eBGP マルチホップ

iBGP では、物理リンクが一本落ちてもセッションが切れないよう、ループバック同士でネイバーを張るのが一般的です。このとき送信元アドレスをループバックに固定しないと、相手は「知らないアドレスから接続が来た」と判断して受け付けません。FRR・Cisco ともに neighbor X update-source lo(Cisco では Loopback0)で指定します。さらに、iBGP で受け取った経路のネクストホップは書き換わらないため、境界ルーターでは next-hop-self を設定するか、内部経路でネクストホップに到達できるようにします。iBGP は原則フルメッシュが必要で、台数が増えたらルートリフレクターを検討します。

eBGP は既定で TTL 1 のパケットを使うため、ループバック同士など直結でない相手とは、そのままではつながりません。neighbor X ebgp-multihop 2 のように必要なホップ数を指定します(FRR では直結チェックだけを外す disable-connected-check もあります)。

状態の確認方法

設定後は、まずサマリーで状態と受信経路数を見ます。

sudo vtysh -c "show bgp summary"
sudo vtysh -c "show bgp neighbors 198.51.100.2"
sudo vtysh -c "show bgp ipv4 unicast neighbors 198.51.100.2 advertised-routes"
sudo vtysh -c "show bgp ipv4 unicast"

サマリーで State/PfxRcd の列に数字が出ていれば Established です。状態名が出ている場合は、前述の FSM の考え方で原因を絞ります。

  • Active のまま:ping 198.51.100.2 で到達性、sudo ss -tn '( sport = :179 or dport = :179 )' で TCP の状況、sudo tcpdump -ni any tcp port 179 で SYN が出ているか、返事が来ているかを見ます。SYN に RST が返るなら相手側に該当ネイバーの設定が無い可能性、無応答ならファイアウォールを疑います。
  • OpenSent から Idle に戻る:show bgp neighbors の最終エラー表示に NOTIFICATION の内容が出ます。「Bad Peer AS」なら remote-as の値、認証関連のログならパスワードを確認します。ルーター ID の重複も見落としやすい原因です。
  • Established だが経路 0 件:入力ポリシーの有無、prefix-list の内容、相手が実際に送っているかを確認します。受信前の経路を見たい場合は soft-reconfiguration inbound を有効にすると received-routes で確認できますが、メモリを使うので常用するかは検討してください。

運用で気をつけること

本番のネイバーを触るときは、変更前に現在の設定(show running-config)を保存し、相手側と作業時間を合わせてください。route-map の変更は clear bgp 198.51.100.2 soft のようにソフトリセットで反映でき、セッションを切らずに済みます。ハードリセットはセッションが落ちて経路が引き直されるため、影響範囲を理解したうえで使います。

障害検知を速めたい場合は、BGP のタイマーを極端に短くするより、BFD を併用するほうが一般的です。タイマー値は両者の OPEN で小さいほうのホールドタイムに合わせて決まるため、片側だけ変えても期待どおりにならない点にも注意してください。

まとめ

  • 事前に AS 番号・ネイバーアドレス・認証・広報する経路を相手と合わせておく。
  • ネイバーの状態で疑う場所が変わる。Active は TCP の問題、OpenSent 付近は OPEN の中身の問題。
  • FRR では eBGP にポリシーが必須な動作が既定のため、最初から prefix-list と route-map を書く。
  • iBGP はループバックと update-source、eBGP で直結でない相手は ebgp-multihop を使う。
  • 本番作業は設定のバックアップを取り、ソフトリセットで反映する。

お気軽にご相談ください

お見積りへ お問い合わせへ
▲