Ubuntu 26.04 を単なるサーバーではなく、ルーター的に使う場合、static route や Policy Based Routing だけでは運用が重くなることがあります。複数のネットワーク間で経路情報を交換する場合は、FRR を使うことで OSPF や BGP などの routing daemon を Linux 上で扱えます。
ただし、FRR を入れることと、ルーティング設計ができていることは別です。FRR は routing protocol を動かすための実装であり、どの経路を広告し、どの経路を受け取り、どこで集約し、どこで firewall と分けるのかは設計として決める必要があります。
FRR は routing daemon 群である
FRR は、Linux 上で動く routing daemon 群です。単体のコマンドではなく、複数の daemon が連携して kernel routing table や routing protocol を扱います。
| 要素 | 役割 | 見方 |
|---|---|---|
zebra | kernel routing table との連携 | FRR の中心になる daemon |
ospfd | OSPFv2 | IPv4 の OSPF を扱う |
ospf6d | OSPFv3 | IPv6 の OSPF を扱う |
bgpd | BGP | 経路交換や外部 peer との接続を扱う |
vtysh | 設定・確認用 shell | FRR の状態をまとめて確認する |
FRR は、OS の routing table を直接置き換えるものではありません。routing protocol で受け取った情報を整理し、必要に応じて kernel routing table へ反映します。そのため、ip route、vtysh、FRR の設定を合わせて確認する必要があります。
static route / PBR / FRR を分ける
FRR を使う前に、通常の static route や Policy Based Routing で十分かを確認します。すべての経路制御を FRR に寄せる必要はありません。
| 方式 | 向いている場面 | 注意点 |
|---|---|---|
| static route | 経路が少なく固定的な環境 | 変更や冗長化に弱い |
| Policy Based Routing | 送信元ごとに経路を分ける環境 | table と rule の管理が必要 |
| FRR | 経路交換や動的ルーティングが必要な環境 | routing protocol の設計が必要 |
Ubuntu を router 的に使う場合でも、小規模な構成なら static route で済むことがあります。FRR は、複数 router 間で経路を交換したい場合、障害時に経路を自動で切り替えたい場合、手作業で経路を追うことが現実的でない場合に検討します。
一方で、送信元アドレスごとに出口を変える話は PBR の領域です。FRR は経路を交換する仕組みであり、送信元ごとの table 選択そのものを置き換えるものではありません。
FRR をインストールする
Ubuntu 26.04 では、FRR package をインストールします。まず package と service の状態を確認します。
sudo apt update
sudo apt install -y frr
systemctl status frr.service --no-pager
ls -l /etc/frrFRR の設定は主に /etc/frr/daemons と /etc/frr/frr.conf で扱います。daemon の有効化と routing protocol の設定は分けて考えます。
有効にする daemon を決める
FRR では、使う routing protocol に応じて daemon を有効化します。不要な daemon は有効にしません。OSPF だけ使うのか、BGP も使うのか、IPv6 の OSPFv3 が必要なのかを先に決めます。
zebra=yes
bgpd=no
ospfd=yes
ospf6d=no
ripd=no
ripngd=no
isisd=no
pimd=no
ldpd=no
nhrpd=no
eigrpd=no
babeld=no
sharpd=no
pbrd=no
bfdd=no
fabricd=nosudo cp -a /etc/frr/daemons /etc/frr/daemons.bak.$(date +%Y%m%d%H%M%S)
sudo sed -i 's/^ospfd=.*/ospfd=yes/' /etc/frr/daemons
sudo sed -i 's/^bgpd=.*/bgpd=no/' /etc/frr/daemons
sudo systemctl restart frr.service
systemctl status frr.service --no-pagerこの例では OSPFv2 を有効化し、BGP は無効のままにしています。BGP を使う場合は bgpd=yes にします。daemon を有効化しただけでは経路交換は始まりません。実際の neighbor、area、AS 番号、広告する network は別途設定します。
ルーティング前提の sysctl を確認する
Ubuntu を router 的に使う場合は、IPv4 / IPv6 forwarding と Reverse Path Filtering を確認します。FRR が動いていても、kernel 側で転送が無効なら通過通信は転送されません。
sysctl net.ipv4.ip_forward
sysctl net.ipv6.conf.all.forwarding
sysctl net.ipv4.conf.all.rp_filter
sysctl -a | grep '\.rp_filter'複数 NIC や非対称経路がある場合、rp_filter が通信を落とすことがあります。FRR の問題に見えて、実際には kernel の forwarding や Reverse Path Filtering が原因であることもあります。
OSPF の最小構成を確認する
OSPF は、同一組織内や閉域ネットワーク内で経路を交換する用途に使われます。次は、OSPFv2 の考え方を示す最小例です。実環境では area 設計、router-id、広告範囲、認証、passive interface を検討します。
frr defaults traditional
hostname ubuntu-router
service integrated-vtysh-config
!
interface enp1s0
ip ospf area 0
!
interface enp2s0
ip ospf area 0
!
router ospf
ospf router-id 10.0.255.1
passive-interface default
no passive-interface enp1s0
no passive-interface enp2s0
!OSPF を有効化する interface は慎重に選びます。すべての interface で隣接関係を作る必要はありません。管理用、外部公開用、内部通信用のどこで routing protocol を話すのかを明確にします。
BGP の最小構成を確認する
BGP は、AS 間の経路交換だけでなく、閉域網、DC 間接続、Kubernetes / CNI / MetalLB 周辺でも使われることがあります。BGP を使う場合は、AS 番号、neighbor、広告する prefix、受け取る経路の制御を明確にします。
frr defaults traditional
hostname ubuntu-router
service integrated-vtysh-config
!
router bgp 65010
bgp router-id 10.0.255.1
neighbor 10.0.20.1 remote-as 65020
!
address-family ipv4 unicast
network 10.0.10.0/24
neighbor 10.0.20.1 activate
exit-address-family
!BGP は「peer が張れたら終わり」ではありません。どの経路を広告してよいのか、どの経路を受け取るのか、default route を受け取るのか、経路フィルタをどうするのかを決めます。経路を広げすぎると、障害範囲も広がります。
vtysh で状態を確認する
FRR の状態確認は vtysh で行います。OS 側の ip route と、FRR 側の状態を合わせて確認します。
sudo vtysh -c 'show running-config'
sudo vtysh -c 'show ip route'
sudo vtysh -c 'show ip ospf neighbor'
sudo vtysh -c 'show bgp summary'
ip route
ip -6 route
journalctl -u frr.service -n 100 --no-pagerOSPF では neighbor が期待通りに張れているか、BGP では session が Established になっているか、FRR が受け取った経路が kernel routing table に反映されているかを確認します。
nftables と rp_filter との関係
FRR を使うサーバーでは、nftables と rp_filter も合わせて確認します。routing daemon が正しく動いていても、firewall が routing protocol の通信を止めていたり、Reverse Path Filtering が非対称経路を落としていたりすると通信できません。
- OSPF や BGP の通信が nftables で許可されているか
- forward chain の policy が用途に合っているか
- IPv4 / IPv6 forwarding が有効か
rp_filterが複数 NIC や非対称経路と矛盾していないか- 受け取った経路をどこまで広告してよいか
FRR は経路交換を担当します。nftables は通信の許可・拒否を担当します。rp_filter は受信 packet の経路妥当性に関係します。これらを一つの「ネットワーク設定」として潰すと、障害時にどこを見ればよいのか分からなくなります。
まとめ
Ubuntu 26.04 で FRR を使うと、Linux を router 的に扱い、OSPF や BGP による経路交換を構成できます。ただし、FRR は routing protocol の実装であり、ルーティング設計そのものを自動で決めてくれるものではありません。
static route、Policy Based Routing、FRR、nftables、Reverse Path Filtering は、それぞれ責務が違います。FRR を導入する前に、どの経路を交換するのか、どの daemon を使うのか、どの通信を firewall で許可するのか、kernel 側の forwarding と rp_filter が設計に合っているのかを確認することが重要です。
- Ubuntu 26.04 Multiple NIC basic – 経路と役割を分けて考える
- Ubuntu 26.04 Policy Based Routing basic – 複数 NIC の出口を分ける
- Ubuntu 26.04 Reverse Path Filtering basic – 複数 NIC と PBR で rp_filter を確認する
- Ubuntu 26.04 nftables basic – OS firewall の設計と通信制御
- Ubuntu 26.04 Netplan の基本設定 – IP アドレス / DNS / route を整える
- Ubuntu 26.04 障害時の切り分け – OS / ネットワーク / サービスを層で見る

