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 を使う。
- 本番作業は設定のバックアップを取り、ソフトリセットで反映する。