FRRによるLinux BGP経路制御本番導入｜ECMP冗長構成と経路切り戻し検証

FRRとBGP経路制御：本番環境で選ばれる理由

FRR（FRRouting）は、Linuxカーネル上で動作するOSSのルーティングデーモン群です。もともとQuaggaから派生し、現在はLinux Foundationのプロジェクトとして活発にメンテナンスされています。BGP、OSPF、ISIS、RIPなど主要なルーティングプロトコルをサポートし、Cisco IOSライクなCLI（vtysh）で設定できる点が商用ルーターからの移行ハードルを下げています。

本番環境でFRRが採用される背景には、クラウドネイティブなインフラ構成の普及があります。BGPをアンダーレイとして使うCLOS（Spine-Leaf）構成や、物理サーバーへの直接BGPピアリング（BGP unnumbered）が標準的な設計になりつつあり、汎用Linuxサーバーで経路制御を担う機会が増えています。また、MetalLBやCiliumなどKubernetes周辺ツールがFRRをBGPスピーカーとして利用するケースも広がっています。

この記事では、FRRを使ってLinuxサーバーにBGP経路制御を本番導入する流れを解説します。特にECMP（Equal-Cost Multi-Path）による冗長構成と、障害時の経路切り戻し検証を中心に扱います。

FRRのインストールとsystemd統合

2026年時点の主要ディストリビューション（Ubuntu 24.04 LTS、Debian 12、RHEL 9系）では、FRRはパッケージリポジトリから直接インストールできます。ただし、ディストリのデフォルトパッケージはFRRのバージョンが古い場合があるため、FRR公式リポジトリを使うことを推奨します。

# Ubuntu 24.04 / Debian 12 の場合（FRR公式リポジトリ）
curl -s https://deb.frrouting.org/frr/keys.asc | sudo apt-key add -
echo deb https://deb.frrouting.org/frr $(lsb_release -s -c) frr-stable | \
  sudo tee /etc/apt/sources.list.d/frr.list
sudo apt update
sudo apt install frr frr-pythontools

インストール後、BGPデーモン（bgpd）を有効にするため /etc/frr/daemons を編集します。

# /etc/frr/daemons
bgpd=yes
ospfd=no   # 不要なデーモンはnoのまま
zebra=yes  # カーネルとの経路同期に必須

systemdでのサービス管理は以下の通りです。

sudo systemctl enable --now frr
sudo systemctl status frr

FRR 9.x以降では、サービス起動時に設定ファイルの構文チェックが自動で走ります。誤設定による起動失敗は journalctl -u frr -e で確認できます。

BGP基本設定とECMP冗長構成

FRRの設定はvtyshインタラクティブCLIか、設定ファイル /etc/frr/frr.conf を直接編集する方法で行います。本番環境ではテキストファイルとしてバージョン管理できる後者が多く使われます。

以下は想定例として、2台のToRスイッチ（AS 65001、AS 65002）と1台のLinuxサーバー（AS 65100）がeBGPでピアリングする構成です。

! /etc/frr/frr.conf（想定例）
frr version 9.1
hostname server-leaf01
log syslog informational

router bgp 65100
  bgp router-id 10.0.0.1
  no bgp ebgp-requires-policy  ! 検証時のみ。本番ではroute-mapで明示制御する

  neighbor 10.1.0.1 remote-as 65001  ! ToR-A
  neighbor 10.1.0.2 remote-as 65002  ! ToR-B

  address-family ipv4 unicast
    network 192.168.100.0/24
    neighbor 10.1.0.1 activate
    neighbor 10.1.0.2 activate
    maximum-paths 2          ! ECMPで最大2経路を並列使用
    maximum-paths ibgp 2
  exit-address-family

line vty

maximum-paths 2 の設定でECMPが有効になり、2つのピアから同じプレフィックスを受信した場合にカーネルの経路テーブルへ等コスト経路として登録されます。実際にカーネルに複数経路が入っているかどうかは以下で確認できます。

# vtyshでのBGP経路確認
vtysh -c "show bgp ipv4 unicast"
vtysh -c "show ip route"

# カーネル側の経路確認
ip route show

ECMPが正しく機能している場合、ip route show の出力に同一プレフィックスに対して2つのnexthopがマルチパスとして表示されます。

BGP unnumberedを使う場合の注意点

BGP unnumberedは、インターフェース名を直接ネイバーとして指定し、IPv6リンクローカルアドレスを使ってBGPセッションを確立する手法です。アドレス設計を簡素化できますが、対向のスイッチ側もunnumberedに対応している必要があります。FRRでは以下のように設定します。

router bgp 65100
  neighbor swp1 interface remote-as external  ! swp1はインターフェース名
  neighbor swp2 interface remote-as external

フェイルオーバーと経路切り戻しの検証手順

本番導入前に必ず実施すべきなのが、ピア障害時の経路収束動作の検証です。以下のシナリオを基本として確認します。

• 一方のBGPピアのセッションをdown状態にし、もう一方のピア経由で通信が継続するか確認する
• ピアを復旧させたとき、ECMPが再確立されるか確認する
• 両ピアが同時にdownしたとき（経路消失）の挙動を確認する

ピアのセッションをclearするには vtysh から次のコマンドを使います。

# BGPセッションをソフトリセット（経路の再アドバタイズ）
vtysh -c "clear bgp ipv4 10.1.0.1 soft"

# BGPセッションを強制切断（ハードリセット）
vtysh -c "clear bgp ipv4 10.1.0.1"

物理的な障害を模擬する場合は、インターフェースをdown/upさせる方法が確実です。

sudo ip link set eth1 down  # ピアAへのリンクをdown
sleep 10
sudo ip link set eth1 up    # 復旧

経路収束の観測には watch コマンドとの組み合わせが便利です。

watch -n 1 "ip route show 192.168.100.0/24"

BGPのデフォルトhold timeは180秒（keepalive 60秒）です。収束速度が要件となる本番環境では、タイマーを短縮します。

neighbor 10.1.0.1 timers 3 9   ! keepalive 3秒、hold time 9秒

タイマー短縮はCPU負荷に影響するため、ピア数が多い環境では慎重に設定します。BFD（Bidirectional Forwarding Detection）と組み合わせることで、より高速な障害検知が可能になります。FRRはBFDをネイティブサポートしています。

BFDを使った高速フェイルオーバー

router bgp 65100
  neighbor 10.1.0.1 bfd
  neighbor 10.1.0.2 bfd

bfd
  peer 10.1.0.1
    receive-interval 300
    transmit-interval 300
    detect-multiplier 3
  !
  peer 10.1.0.2
    receive-interval 300
    transmit-interval 300
    detect-multiplier 3
  !

上記の設定では最短で約900ms（300ms × 3）でリンク障害を検知できます。BGPのhold time切れを待つ必要がなくなるため、収束速度を大幅に改善できます。

本番導入前の注意点とよくあるつまずき

カーネルのIPフォワーディングを有効にすることを忘れがちです。FRRがBGP経路をカーネルに挿入しても、ip_forward が無効だとパケットが転送されません。

sudo sysctl -w net.ipv4.ip_forward=1
# 永続化
echo "net.ipv4.ip_forward = 1" | sudo tee /etc/sysctl.d/99-ip-forward.conf
sudo sysctl -p /etc/sysctl.d/99-ip-forward.conf

ルートフィルタリング（ポリシー設定）は本番環境では必須です。no bgp ebgp-requires-policy は設定確認を省略するオプションであり、プロダクション設定ではroute-mapを使って受信・送信経路を明示的に制御してください。意図しない経路を受信・広告するリスクを排除できます。

firewalldまたはnftablesがBGP（TCP 179）をブロックしているケースはよくあるつまずきです。新規サーバーへのFRR導入時はファイアウォールの設定も確認します。

# firewalldの場合
sudo firewall-cmd --add-port=179/tcp --permanent
sudo firewall-cmd --reload

# nftablesの場合（RHEL 9系のデフォルト）
sudo nft add rule inet filter input tcp dport 179 accept

SELinuxとFRRの相性についても注意が必要です。RHEL 9系でSELinuxがenforceモードで動いている環境では、FRRのソケット操作やログ出力が拒否される場合があります。audit2allow で不足ポリシーを確認してください。

ECMP経路がカーネルに反映されない場合は、カーネルのマルチパス上限数を確認します。デフォルト値を超えるマルチパス構成では、net.ipv4.fib_multipath_hash_policy の設定も合わせて見直します。

2026年現行環境での差分と留意点

FRR 10.x系の変更点として、設定ファイルのフォーマットに一部非互換があります。FRR 9.x以前の設定ファイルをそのまま利用する場合、起動時にdeprecation警告が出ることがあります。vtysh -c "show running-config" で現在の有効設定を確認し、必要に応じてフォーマットを更新してください。

Ubuntu 24.04 LTSの注意点として、デフォルトのnftables設定が強化されており、BGPトラフィックが初期状態で遮断される場合があります。また、同LTS上のFRRパッケージバージョンはFRR公式リポジトリより遅れることがあるため、機能面の差異を事前に確認してください。

Debian 12（Bookworm）ではFRR 8.4がベースリポジトリに含まれていますが、BFDのフル機能やBGP unnumberedの安定動作にはFRR 9.0以降が推奨されます。公式リポジトリのfrr-stableチャンネルを利用してください。

RHEL 9系（Rocky Linux 9、AlmaLinux 9含む）では、FRRはAppStreamリポジトリからインストール可能ですが、バージョンは8.x系に留まる場合があります。最新機能が必要な場合はFRR公式のRPMリポジトリを使用します。

systemdのサービス監視との統合については、FRR 9.x以降でsystemd notifyプロトコルへの対応が改善されています。systemctl status frr で各デーモン（zebra、bgpd）の起動状態が個別に確認できるようになっており、障害時のトリアージに役立ちます。Prometheusによるメトリクス収集にはFRR組み込みのPrometheusエクスポーターか、コミュニティメンテナンスの外部exporterが利用可能です。

本番導入に向けた事前検証には、ContainerLabを使った仮想構成が有効です。ContainerLabはFRRコンテナをネイティブサポートしており、数十ノード規模のBGP構成をローカル環境で手軽に再現できます。ECMP構成とフェイルオーバーの挙動を十分に確認したうえで、本番環境への展開を進めてください。