静的ルート管理の限界点
6ヶ月前、私たちのネットワークは手動設定では対応できないほど複雑化していました。アシュバーンとフランクフルトのデータセンターにまたがる12のサブネットを抱えるまでにインフラが拡大し、ルーティングテーブルは静的エントリの脆弱な集合体となっていました。新しいVLANをプロビジョニングしたり、拠点間VPNトンネルが不安定になったりするたびに、システム管理者は数台のサーバーを手動で更新しなければなりませんでした。
破綻は火曜日の夜に訪れました。ip route addコマンドの単純なタイポ（打ち間違い）により、ステージング環境全体が40分間停止したのです。あるゲートウェイは、新しく作成されたサブネットへの戻りパスがなかったため、パケットをブラックホール化し始めました。これは単なる人的ミスの問題ではなく、スケーラビリティの壁でした。人間が介入することなく、自己修復できるネットワークが必要だったのです。
根本的な問題：静的ルートは「賢くない」
静的ルーティングが失敗するのは、状態を認識できない（ステートレスである）ためです。Linuxカーネルにとって、静的ルートは「盲目的な指示」に過ぎません。ターゲットのインターフェースが「UP」であれば、カーネルはそのインターフェースにパケットを流し続けます。ネクストホップのルーターがクラッシュしていようが、上位のプロバイダーで大規模なルーティングリークが発生していようが関係ありません。パケットはただ虚無へと消えていくだけです。
回復力のあるスタックを運用するには、静的ルートでは提供できない3つの機能が必要でした：
- 1秒未満のフェイルオーバー： プライマリリンクが切断された場合、トラフィックを自動的に再ルーティングすること。
- 自動検出： 新しいサブネットがその存在をネットワーク全体に即座に通知すること。
- ヘルスモニタリング： 宛先が到達不能になった瞬間、ルートが削除されること。
適切なスタックの選択：Quagga vs. BIRD vs. FRR
私は1週間かけて、Linuxルーティングの主要な3つの候補をテストしました。それぞれに特定の特徴がありますが、私たちの本番環境のニーズに合致したのは1つだけでした。
1. Quagga
QuaggaはLinuxルーティングの元祖ですが、古さが目立ちます。開発は停滞しており、最新のマルチスレッドワークロードへの対応に苦労しています。テスト中も動作が鈍く、将来の自動化に不可欠な堅牢なAPIサポートも不足していました。
2. BIRD
BIRDは非常に強力です。数百万のルートを処理するインターネットエクスチェンジ（IXP）では業界標準となっています。しかし、その設定構文は独自のプログラミング言語のようです。BGPポリシーを管理する専任のネットワークエンジニアがいない限り、標準的なDevOpsチームにとって学習コストは非常に高くなります。
3. FRRouting (FRR)
FRRはQuaggaの現代的なフォークであり、NvidiaやBroadcomなどの大手企業によって支えられています。Cisco IOSやArista EOSのワークフローを模倣したシェルであるvtyshを使用します。ハードウェアスイッチを触ったことがある人なら、馴染みやすく感じるでしょう.OSPF、BGP、EVPNを容易に処理できるため、私たちのハイブリッド環境において最も汎用性の高い選択肢でした。
実装：本番環境でのOSPFとBGP
本番環境での180日間を経て、私たちの構成は驚くほど安定していることが証明されました。内部（East-West）トラフィックにはOSPFを、外部（North-South）の接続にはBGPを使用しています。このデュアルプロトコルアプローチにより、速度と細かな制御のバランスを保っています。
ステップ1：インストール
Ubuntu 22.04または24.04では、デフォルトのOSリポジトリは避けてください。最新の安定版から遅れていることが多いからです。代わりに、最新のセキュリティパッチを確実に適用できるよう、FRRの公式リポジトリを使用します。
# 公式リポジトリを追加
curl -s https://deb.frrouting.org/frr/keys.asc | sudo apt-key add -
FRRVER="frr-stable"
echo deb https://deb.frrouting.org/frr/ $(lsb_release -s -c) $FRRVER | sudo tee -a /etc/apt/sources.list.d/frr.list
sudo apt update && sudo apt install frr frr-pythontools次に、/etc/frr/daemonsを編集して必要なプロトコルを有効にします。私たちのセットアップでは、bgpd=yesとospfd=yesに設定し、サービスを再起動しました。
ステップ2：OSPFによる内部ルーティング
OSPFは、内部サブネット向けの「一度設定すればあとはお任せ」のツールです。すべてのゲートウェイが他のすべてのゲートウェイを認識できるようにします。設定にはテキストファイルを直接編集するのではなく、vtyshを使用します。
sudo vtysh
conf t
router ospf
network 10.0.0.0/24 area 0
network 192.168.1.0/24 area 0
exit
wr memoryこの設定により、手動での管理が不要になりました。エリア0に新しいインターフェースを追加すると、ルートは200ミリ秒以内にクラスタの残りの部分に伝播します。
ステップ3：BGPによる外部ピアリング
BGPは、AWSやAzureなどのクラウドプロバイダーと接続するために不可欠です。以下は、AWS Direct Connectゲートウェイ用のピア設定を簡略化したものです。
router bgp 65001
neighbor 169.254.0.1 remote-as 65002
neighbor 169.254.0.1 description AWS-Primary
!
address-family ipv4 unicast
network 10.50.0.0/16
exit-address-family
exit現場で得た苦労の教訓
動的ルーティングへの移行は、私たちの運用哲学全体を変えました。この6ヶ月間で得られた3つの重要な教訓を紹介します。
1. 可視性がすべて
動的ルーティングは素晴らしいものですが、リンクが「フラッピング」（短時間での切断と再接続の繰り返し）を始めると厄介です。これはルート再計算の嵐を引き起こす可能性があります。現在、私たちはFRRのメトリクスをPrometheusにエクスポートしています。ユーザーが遅延のスパイクを報告するずっと前、BGPセッションが切断されたことを数秒以内に把握する必要があります。
2. vtyshのワークフローを尊重する
/etc/frr/frr.confを手動で書き換えたいという誘惑に負けないでください。vtyshを使用すれば、リアルタイムの構文チェックが可能です。また、既存のトラフィックフローを遮断することなく、変更をライブで適用できます。show ip routeやshow ip bgp summaryに慣れておきましょう。これらは最高の診断ツールです。
3. 隣人を決して信用しない
常にプレフィックスリストを実装してください。BGPネイバーをフィルタリングしないと、設定ミスのあるピアが誤ってデフォルトルート（0.0.0.0/0）を送信してくる可能性があります。これにより、すべての送信トラフィックが実質的にハイジャックされてしまいます。私たちは厳格なフィルタを使用して、特定の期待されるサブネットのみを許可しています。
ip prefix-list ONLY-OUR-SUBNETS permit 10.0.0.0/8 ge 24
!
route-map IMPORT-FILTER permit 10
match ip address prefix-list ONLY-OUR-SUBNETS
!結論
私たちのネットワークは、現在、大幅に耐障害性が向上しています。最近、エッジゲートウェイでハードウェア障害が発生した際、FRRは約2.4秒でバックアップパスにトラフィックを再ルーティングしました。エンジニアリングチームの誰も夜中に起きる必要はありませんでした。もし数台以上のLinuxノードを管理しているなら、静的ルートの使用はやめましょう。FRRoutingの設定にかかる時間は、最初のリンク障害が発生し、ユーザーが何も気づかなかった瞬間に、十分すぎるほど元が取れるはずです。
