BGP の障害は「セッションが張れていない」「セッションは張れているが経路が届かない・出ていかない」「経路が不安定に出入りする」の3つに分けると、確認する場所が決まります。この記事では、FRRouting（vtysh）を例に、影響範囲の把握から原因の特定、安全な復旧と事後対応までを、可能性の高い順に確認できるように整理します。Cisco や Juniper など他の実装でも、見るべき項目は同じです。
最初の5分でやること：影響範囲と変更履歴の確認
コマンドを打つ前に、次の2点を押さえておくと切り分けが速くなります。
- どの方向が壊れているか：自分のプレフィックスが外から見えないのか（広報側の問題）、外の宛先に行けないのか（受信側の問題）、両方なのか。
- 直前に何が変わったか：設定変更、機器の再起動、上流プロバイダーのメンテナンス通知、回線工事、証明書や RPKI 関連の更新など。障害の多くは「直前の変更」に原因があります。
復旧作業は設定を触る前に、現在の running-config を保存してから始めます。焦って clear を繰り返すと、相手側でダンプニング（フラップ抑制）がかかり、復旧がかえって遅れることがあります。
# 現在の設定を退避（FRRouting の例）
sudo vtysh -c "show running-config" > ~/frr-running-$(date +%Y%m%d-%H%M).confセッション状態を読む
まず全ピアの状態を一覧で確認します。
sudo vtysh -c "show bgp summary"State/PfxRcd の列に数字が出ていれば Established（確立済み）で、その数字が受信プレフィックス数です。文字が出ている場合はセッションが確立していません。状態ごとの意味は次のとおりです。
- Idle：接続を試みていない、または管理的に止まっている。
shutdownの設定や、最大プレフィックス超過による停止を疑います。 - Connect / Active：TCP 179 番ポートの接続が成立していない。到達性・ACL・ファイアウォール・相手側設定の問題が多い状態です。
- OpenSent / OpenConfirm：TCP は張れたが OPEN メッセージの交換で止まっている。AS 番号やルーター ID、ケイパビリティの不一致を疑います。
個別ピアの詳細は次のコマンドで確認します。特に「最後にセッションが切れた理由（Last reset）」と、送受信した NOTIFICATION の内容が手がかりになります。
sudo vtysh -c "show bgp neighbors 192.0.2.1"NOTIFICATION には RFC 4271 などで定義されたエラーコードが入っています。代表的なものは、Hold Timer Expired（キープアライブが届かなくなった）、OPEN Message Error の Bad Peer AS（AS 番号の設定違い）、Cease の Maximum Number of Prefixes Reached（最大プレフィックス数の超過）です。表示の文言は実装やバージョンで異なるため、コードとサブコードの意味で読み取ってください。
原因別の確認と対処（可能性の高い順）
1. TCP 179 番が通っていない（Active のまま）
最も多いのがこのパターンです。相手のアドレスへ到達できるか、179 番の接続が出入りしているかを確認します。
ping -c 3 192.0.2.1
sudo ss -tnp | grep ':179'
sudo tcpdump -ni eth0 tcp port 179SYN が出ているのに応答が無ければ、経路上のフィルタか相手側の設定を疑います。サーバーの nftables / iptables やクラウドのセキュリティグループで 179 番を許可しているかも確認します。eBGP でループバック同士を結んでいる場合は、TTL の扱い（ebgp-multihop の設定）と、ループバックへの静的経路があるかも見ます。
2. 設定の不一致（OpenSent で止まる・すぐ切れる）
remote-as の値、ピアアドレス、更新元アドレス（update-source）、MD5 パスワードを両側で突き合わせます。MD5 パスワードが一致しないと TCP 自体が成立せず、Active に見えることもあります。Linux ではカーネルログに MD5 関連のメッセージが出る場合があるので dmesg や journalctl -k も確認します。
3. セッションは確立しているのに経路が 0 件
FRRouting の比較的新しい版では、eBGP ピアにポリシー（route-map）が設定されていないと経路を受け取らず、送り出しもしない動作が既定になっています（bgp ebgp-requires-policy）。この場合、summary の表示に「(Policy)」と出ることがあります。受信・送信の route-map と prefix-list を設定して解消します。
router bgp 64512
neighbor 192.0.2.1 remote-as 64511
address-family ipv4 unicast
neighbor 192.0.2.1 route-map RM-IN in
neighbor 192.0.2.1 route-map RM-OUT out
exit-address-familyフィルタの書き間違いで想定外の経路まで落としていないかは、ピアごとの受信・広報内容で確認します。受信前の経路を見るには、ピアに soft-reconfiguration inbound を設定しておく必要があります。
sudo vtysh -c "show bgp ipv4 unicast neighbors 192.0.2.1 routes"
sudo vtysh -c "show bgp ipv4 unicast neighbors 192.0.2.1 advertised-routes"4. 自分のプレフィックスが外から見えない
広報側の問題では、まず BGP テーブルに対象プレフィックスが載っているかを見ます。network 文で広報する場合、同じプレフィックスがルーティングテーブル（RIB）に存在しないと広報されません。集約経路なら Null0（blackhole）への静的経路を置くのが一般的です。
sudo vtysh -c "show bgp ipv4 unicast 203.0.113.0/24"自分の側で正しく出ていても、上流で拒否されていることがあります。IRR のルートオブジェクトが無い、RPKI の ROA と起点 AS が一致しない（Invalid 扱い）、プレフィックス長が /24 より長い（IPv4 では多くのネットワークが受け付けない）などが典型例です。
5. 最大プレフィックス超過で停止した
maximum-prefix の上限を超えるとセッションが落ち、自動では復帰しない設定のこともあります。相手が誤ってフルルートを流したのか、正当に経路が増えたのかを確認してから上限を見直します。原因が分からないまま上限だけを上げると、経路リークを受け入れることになります。
6. 経路が不安定（フラップ）
回線品質の低下やリンクの up/down が主な原因です。インターフェースのエラーカウンタ、光レベル、show bgp summary の Up/Down 時間の短さで判断します。BFD を使っている場合は、BFD のタイマーが厳しすぎて誤検知していないかも確認します。
外から自分の経路がどう見えているかを確認する
自分の機器の表示だけでは、インターネット側での見え方は分かりません。上流事業者が公開しているルッキンググラスや、RIPEstat などの公開サービスで、プレフィックスの起点 AS・AS パス・可視性を確認します。自分の AS 以外が同じプレフィックスを起点として広報している場合は、経路ハイジャックや設定ミスによるリークの可能性があるため、上流事業者の NOC に連絡します。連絡時は、プレフィックス、AS 番号、発生時刻、確認した AS パスをまとめて伝えると話が早く進みます。
安全に復旧させるコツ
- ソフトリセットを優先する：ポリシー変更を反映させたいだけなら、セッションを切らない
softオプションを使います。 - 変更は1つずつ：複数を同時に変えると、どれが効いたか分からなくなります。
- 相手側と時刻を合わせて作業する：両側で同時にログを見られると、NOTIFICATION の送受信の向きが把握しやすくなります。
# セッションを切らずに受信ポリシーを再適用（FRRouting の例）
sudo vtysh -c "clear bgp ipv4 unicast 192.0.2.1 soft in"コマンドの書式はバージョンによって細かく異なることがあるため（2026年10月現在）、利用中の版のマニュアルで確認してから実行してください。
再発防止：障害後に残しておくもの
復旧したら、発生時刻、影響範囲、原因、対処、所要時間を記録します。そのうえで、セッション状態と受信プレフィックス数を監視対象に加え、急な増減でアラートが出るようにします。IRR と RPKI の登録内容を定期的に見直すこと、設定変更の前後で受信・広報経路の差分を取ることも、同じ障害を繰り返さないために役立ちます。
まとめ
- BGP 障害は「セッション断」「経路が届かない・出ない」「フラップ」の3つに分けて考える。
show bgp summaryの状態表示と、ピア詳細の Last reset・NOTIFICATION が最初の手がかり。- Active なら TCP 179 番の到達性、OpenSent なら設定の不一致、経路 0 件ならポリシーを疑う。
- 外からの見え方はルッキンググラスや公開サービスで確認し、不審な起点 AS は上流に連絡する。
- 復旧はソフトリセットを優先し、変更は1つずつ。事後に監視と記録を整える。