Ubuntu 22.04 FRR FIB 不整合の復旧 – Zebra とカーネル経路がずれたときに見ること

Ubuntu 22.04 上の FRR で、OSPF や BGP の経路は FRR 内では正常に見えているのに、Linux カーネルのルーティングテーブルから動的経路が消えることがあります。この状態では、FRR の RIB には経路があっても、実際の転送に使うカーネル FIB に経路が入っていないため、通信は期待どおりに流れません。

この記事は、Ubuntu 22.04 の既存環境で FRR と Linux カーネル FIB のずれを切り分けるための記事です。新規構築では Ubuntu 26.04 側の記事を優先しつつ、22.04 環境の運用確認や古い障害記録の読み替えに使ってください。

RIB と FIB を分けて見る

FRR が内部で保持する経路情報は RIB として確認します。一方、実際に Linux がパケット転送に使う経路はカーネル FIB です。FRR の Zebra は、FRR 内部の経路を Linux カーネルへ反映する役割を持ちます。

• FRR の show ip route は FRR 内部の経路を見る
• Linux の ip route show はカーネル FIB を見る
• 実際のパケット転送はカーネル FIB に従う
• Zebra は FRR とカーネル FIB の間をつなぐ
• FRR 内で正常でも、カーネルへ反映されていなければ通信は失敗する

現象を確認する

FRR 側では OSPF や BGP の経路が存在しているにもかかわらず、Linux 側の ip route show から動的経路が消えている場合があります。まず、FRR 側と Linux 側を分けて見ます。

vtysh -c 'show ip route'
vtysh -c 'show ip route summary'
ip route show
ip route get 10.201.0.10

show ip route に経路があり、ip route show に同じ宛先の経路がない場合は、プロトコルの学習そのものではなく、Zebra からカーネル FIB への反映を疑います。

プロトコル状態を確認する

BGP や OSPF のセッションが落ちている場合は、FIB 不整合ではなく単純に経路を学習できていない可能性があります。まず隣接関係と学習状態を確認します。

vtysh -c 'show bgp summary'
vtysh -c 'show ip bgp'
vtysh -c 'show ip ospf neighbor'
vtysh -c 'show ip ospf route'

プロトコル側で経路が学習できていない場合は、ピア、インターフェイス、ACL、フィルタ、経路ポリシーを先に見ます。FRR 内では経路が正しく見えているのに Linux 側へ出ていない場合に、Zebra と FIB の確認へ進みます。

Zebra とログを見る

Zebra や FRR のログに、カーネル経路反映の失敗や netlink 周辺のエラーが出ていないかを確認します。障害が一時的に復旧しても、発生時刻付近のログを残しておくことが重要です。

systemctl status frr.service
journalctl -u frr.service --since '1 hour ago' --no-pager
journalctl -u frr.service --no-pager

ログを見るときは、FRR が起動しているかどうかだけでなく、経路追加や削除に失敗していないか、インターフェイス状態の変化と同じ時刻に問題が出ていないかを合わせて確認します。

暫定復旧する

暫定的には、FRR の再起動でカーネル FIB への反映が戻ることがあります。ただし、これは根本原因の特定ではありません。復旧操作の前後で、FRR 内の経路と Linux 側の経路を残します。

vtysh -c 'show ip route'
ip route show
sudo systemctl restart frr.service
systemctl status frr.service
vtysh -c 'show ip route'
ip route show

再起動で戻った場合も、Zebra とカーネル FIB の同期が一時的に戻っただけです。再発する場合は、発生条件を追うための記録が必要です。

再発時に記録する情報

FRR 再起動で直る障害は、復旧操作を急ぐほど証拠が消えます。再発時は、少なくとも次の情報を記録します。

• 発生時刻
• FRR 内の経路状態
• カーネル FIB の状態
• インターフェイスの link up / down
• FRR / Zebra のログ
• 経路数や対象 prefix の変化
• 再起動で復旧したかどうか

特に Kubernetes、MetalLB、Calico、外部ルーターとの BGP 接続を組み合わせている場合、アプリケーション側の疎通問題に見えて、実際は Linux ルーターや FRR 側の FIB 反映が原因ということがあります。

Kubernetes や BGP 経路広告との関係

Kubernetes で Calico や MetalLB の BGP 経路広告を使う場合、FRR やルーター側の FIB 不整合はアプリケーション疎通に直結します。Kubernetes 側で Service や Pod が正常に見えても、外側の経路制御が壊れていれば通信は成立しません。

そのため、Kubernetes ネットワークを BGP と接続する場合は、Kubernetes 側のリソース状態だけでなく、FRR、ルーター、Linux カーネル FIB を合わせて確認します。どこが制御面で、どこが転送面なのかを分けると切り分けが進みます。

まとめ

FRR で経路が見えているのに通信できない場合は、FRR 内部の RIB と Linux カーネル FIB を分けて確認します。show ip route が正常でも、ip route show に反映されていなければ、実際の転送はできません。

22.04 の既存環境では、FRR 再起動で復旧するかどうかだけで終わらせず、発生時刻、経路状態、ログ、インターフェイス状態を残します。動的ルーティングをサーバーや Kubernetes と接続する場合、この責務の分離を理解しておくと切り分けがかなり楽になります。

関連記事

Ubuntu 26.04 FRR routing の基本設定 – OSPF / BGP を使う前に決めること Ubuntu 26.04 nftables の基本設定 – OS firewall の責務と通信制御 Ubuntu 22.04 Docker Engine の導入 – Ubuntu 標準パッケージでコンテナ実行環境を構築する Ubuntu 22.04 デスクトップ環境 – Server に ubuntu-desktop を追加する Ubuntu 22.04 Kubernetes 管理ツールのインストール – kubectl / Helm / calicoctl の使い分け Ubuntu 22.04 update-ca-certificates – 内部 CA を信頼ストアへ登録する Ubuntu 22.04 389 Directory Server #1 – インスタンス作成と suffix 設計 Ubuntu 22.04 netplan apply の ovsdb-server.service 警告 – Open vSwitch を使わない環境での考え方