ネットワーク稼働率の静かなる刺客：グレーフェイルオーバー
かつて、高トラフィックのフィンテッククラスターで、監視ダッシュボードがすべて正常（グリーン）なまま接続が失われるのを目の当たりにしました。一次経路でファイバー断線が発生しましたが、中間メディアコンバーターを経由していたため、Linuxのネットワークインターフェースは「UP」状態のままでした。OSから見ればすべて完璧に見えましたが、実際にはトラフィックはブラックホールへと消えていました。
標準的なOSPFを使用していたため、ネイバーがタイムアウトして再ルーティングされるまでに40秒近くかかりました。現代のアプリケーションにとって、40秒のダウンタイムは永遠にも等しい時間です。数千件のトランザクションが破棄され、ユーザーは不満を募らせます。これが「グレーフェイルオーバー (Gray Failure)」です。ハードウェアは機能しているように見えても、実際のデータ転送が壊れている状態を指します。
なぜ標準のルーティングタイマーでは不十分なのか
多くのエンジニアは、OSPFやBGPに組み込まれたデフォルトのタイマーに頼っています。デフォルトでは、OSPFは10秒のHello間隔と40秒のDead間隔を使用します。BGPはさらに遅く、多くの場合、60秒のKeepaliveと180秒のHold timeがデフォルトです。
OSPFタイマーを単純に1秒に下げたくなるかもしれません。理論上は機能しますが、実際にはCPUに大きな負荷をかけます。各ルーティングプロトコルには独自のヘルスチェックメカニズムがあります。OSPF、BGP、PIMを同時に実行すると、CPUは複数の「生存確認」パケットの処理にサイクルを浪費します。これらのプロトコルは1秒未満の精度を想定して設計されていません。無理に設定を詰めすぎると、ルートフラッピングや不安定さを招くのが一般的です。
BFD：軽量なハートビート
Bidirectional Forwarding Detection (BFD) は、独立した超高速のハートビートサービスとして機能することでこの問題を解決します。リンクがダウンすると、BFDは即座にそれを検知し、OSPFやBGPに「ダウン」通知を送信します。これにより、プロトコルはリンク監視ではなく、経路計算に集中できるようになります。
フェイルオーバー手法を比較すると、パフォーマンスの差は歴然としています：
- 標準タイマー： 安定性は高いが、復旧が非常に遅い（30〜180秒）。
- アグレッシブなプロトコルタイマー： 復旧は早まる（1〜3秒）が、高いCPU負荷と誤検知のリスクがある。
- BFD： 極めて高速な復旧（通常150〜300ms）で、CPUへの影響はごくわずか。
本番環境では、BFDが数百のセッションを処理してもCPU使用率が1%未満であるのを見てきました。標準的なLinuxマシンで、専用ハードウェアルーター並みの速度を実現します。
解決策：Linux上でのFRRouting (FRR)
FRRoutingは、Linuxマシンをプロフェッショナルグレード of ルーターに変えるための定番スイートです。古いルーティングスタックとは異なり、FRRには高速リンク監視専用に設計された bfdd デーモンが含まれています。
ステップ 1：FRRoutingのインストール
まずは、FRRの最新安定版をインストールします。UbuntuやDebianでは、最新機能を利用するために公式リポジトリを使用するのが最善です。
# 必要なツールのインストール
sudo apt update && sudo apt install -y curl gnupg2 lsb-release
# FRRのGPGキーとリポジトリを追加
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 /etc/apt/sources.list.d/frr.list
# スイートのインストール
sudo apt update && sudo apt install -y frr frr-pythontoolsステップ 2：BFDデーモンの有効化
FRRはリソース節約のため、デフォルトでほとんどのデーモンが無効になっています。bfdd と選択したルーティングプロトコルを手動で有効にする必要があります。
# デーモン設定を開く
sudo nano /etc/frr/daemons以下の値を yes に設定します：
bgpd=yes
ospfd=yes
bfdd=yes新しいデーモンを初期化するためにサービスを再起動します：
sudo systemctl restart frrステップ 3：BFDパラメータの定義
vtysh を使用してFRRシェルにアクセスします。ハートビートの強度を定義するためのBFDプロファイルを作成します。ほとんどのデータセンターネットワークでは、100msの間隔が最適です。
sudo vtysh
configure terminal
!
bfd
profile FAST-DETECT
detect-multiplier 3
receive-interval 100
transmit-interval 100
exit
!
end
write memoryこの設定では、100msごとにハートビートが送信されます。3回連続でパケットが失われる（計300ms）と、リンクはダウンしたとみなされます。これは、OSPFのデフォルトのDeadタイマーよりも約133倍高速です。
実践的な設定：BFDとOSPFの連携
BFDは単独では機能しません。プロトコルと連携させる必要があります。BFDが障害を検知すると、即座にOSPFへ通知してネイバーを切り離します。これにより、バックアップルートへの瞬時の切り替えが強制されます。
conf t
router ospf
network 192.168.1.0/24 area 0
bfd all-interfaces
exit
interface eth0
ip ospf area 0
bfd profile FAST-DETECT
exit
write memory実践的な設定：BFDとBGPの連携
BGPにとって、BFDは命綱です。特にデータセンター間のiBGPセッションにおいて、BGPのHoldタイマーがゆっくりとカウントダウンしている間にトラフィックがブラックホール化するのを防ぎます。
conf t
router bgp 65001
neighbor 10.0.0.2 remote-as 65002
neighbor 10.0.0.2 bfd
exit
write memory結果の確認
設定後、BFDセッションが「Up」であることを確認します。もし「Down」や「Init」のままであれば、ファイアウォールの設定を再確認してください。BFDはUDPポート 3784 を使用します。
# BFDピアの概要を表示
show bfd peers brief出力は以下のようになります：
Session Count: 1
Session Id LocalAddress PeerAddress Status
1 192.168.1.10 192.168.1.20 Up実際のパケット数やタイミングを確認するには、show bfd peer 192.168.1.20 を使用します。Remote State: Up を探してください。Control Plane Independent: Yes と表示されていれば、最大限の効率を得るために低レイヤーで検出が実行されています。
最後に
BFDをFRRoutingに統合したことで、私たちのネットワークはストレスの種から、静かで信頼性の高い基盤へと変わりました。40秒の障害から、ユーザーが気づくことさえない1秒未満のフェイルオーバーへと移行できました。Linuxでダイナミックルーティングを運用しているなら、本番環境の稼働率を確保するためにBFDは必須条件です。
この構成の本当の強みはその効率性にあります。一度ハートビートを定義してネイバーに関連付ければ、あとは bfdd が重い処理を引き受けてくれます。グレーフェイルオーバーを排除し、インフラの回復力を維持するための最も堅牢な方法です。
