BFDとは？ わかりやすく10分で解説

はじめに

ネットワークは「つながっていて当たり前」に見えますが、実際にはリンク断、機器故障、片方向だけの不通（片系断）、一時的なパケットロスなど、さまざまな要因で通信品質が崩れます。問題は、障害そのものよりも「検知が遅れる」ことです。検知が遅いと、冗長経路があっても切り替えが間に合わず、ユーザーからは“止まった”ように見えてしまいます。

そこで使われるのがBFD（Bidirectional Forwarding Detection）です。BFDは、リンクや転送経路の異常を短い間隔で監視して素早く検知し、OSPFやBGPなどのルーティングプロトコル、あるいは静的ルートの運用に「切り替えのきっかけ」を渡すための仕組みです。この記事では、BFDが何をしているのか、どんな場面で効くのか、そして設定や運用で気をつけたいポイントを整理します。

BFDとは？

BFD（Bidirectional Forwarding Detection）は、2つの装置間で小さな制御パケットをやり取りし、転送パスが生きているかを短い間隔で確認する仕組みです。主な狙いは、OSPFやBGPなどのルーティングプロトコルが持つ「標準のタイマー（Hello/Keepaliveなど）」よりも速く障害を検知し、経路切り替えの起点を作ることにあります。

重要なのは、BFD自体が「経路を選ぶ」わけではない点です。BFDはあくまで生存監視（検知）を担当し、経路の再計算や切り替え（ルート変更）は、OSPF/BGP/静的ルート＋トラッキングなど、別の仕組みが行います。

高速な障害検出の仕組み

BFDは、相手に向けて定期的にBFD制御パケットを送信し、相手からの応答（または相手からの定期送信）を監視します。一定回数、所定の時間内にパケットが届かなければ、BFDはそのセッションを「Down」と判断します。

この「短い間隔での監視」により、例えば次のような状況で“気づくのが遅い”問題を補いやすくなります。

• 物理リンクはUpのままなのに、上流で転送できていない
• 片方向だけ通らない（片系断）
• 一時的なパケットロスが断続的に起きる

ただし、速くすればするほど良いわけではありません。タイマーを攻めすぎると、CPU負荷や輻輳（混雑）の影響でBFDパケットが落ち、誤検知（フラップ）が起きやすくなるため、設計はバランスが重要です。

BFDの主な目的

BFDの目的は、大きく次の3つです。

• 障害検知を速くする（リンク断・経路断・片系断などを素早く検出）
• 切り替えを速くする（OSPF/BGPなどへDownを通知し、再計算や引き上げを早める）
• 監視を共通化する（プロトコルごとに検知方法を作り込まず、BFDを“検知レイヤー”として使う）

結果として、ダウンタイムが短くなり、利用者から見た「止まっている時間」を減らせる可能性が高まります。

BFDの必要性

ネットワークの冗長化（複数経路、二重化）をしていても、切り替えの判断が遅ければ意味が薄れます。BFDは、冗長構成の“最後の詰め”として、切り替えを素早く成立させたい場面で効果を発揮します。

ハードウェア検出との比較

機器は通常、物理リンクのUp/Down（ケーブル断、光断など）をハードウェアで検出できます。これは速くて確実ですが、次のようなケースは拾えないことがあります。

• リンクはUpのままでも、上流が詰まって転送できない
• 中継区間で障害が起きている（特にL3区間やトンネル区間）
• 片方向だけ通らない（受信だけ落ちるなど）

BFDは、こうした「物理リンクだけ見ても分からない」状況を、パケットの往復・到達性で検知しやすくします。つまり、ハードウェア検出の代替ではなく、補完として捉えるのが現実的です。

リンク障害の迅速な検出

BFDを入れると、障害を検知してから切り替えに入るまでの時間を詰めやすくなります。例えばデータセンターや拠点間で複数経路がある場合、1経路の劣化や断が起きた際に、BFDがDownを通知し、OSPF/BGPが経路を更新して健全なパスへ寄せる流れを作れます。

ただし、BFDがDownを出した直後に必ず“即時に復旧する”とは限りません。復旧速度は、ルーティングプロトコル側の収束（収束条件・再計算・広告抑制など）や、設計（ECMP、フィルタ、ポリシー）にも左右されます。

BFDの動作メカニズム

BFDは「セッション」という単位で隣接装置と状態を持ちます。セッションがUpの間は“到達している”と判断し、Downになったら連携先（OSPF/BGPなど）に通知します。

障害検出のプロセス

BFDの基本はシンプルです。

1. 双方が一定間隔でBFD制御パケットを送る
2. 相手からのパケット受信が一定回数途切れたらDownと判断する

実務では、送信間隔（interval）と検出回数（multiplier）の組み合わせで、「どれくらいでDownと見なすか」を決めることが多いです。速くしすぎると誤検知、遅くしすぎると切り替えが遅い、というトレードオフになります。

BFDセッションの確立

BFDは、相手とパラメータ（送受信間隔など）をやり取りし、合意できる条件でセッションをUpにします。ここでのポイントは、BFDが「相手がBFDを理解している」ことを前提に動くことです。片側だけ設定しても、相手が対応していなければセッションは上がりません。

また、BFDには用途に応じた使い分けがあります。代表的には次の2つです。

• 単一ホップ（Single-hop）：直接つながる隣接装置間（同一リンク/同一セグメント相当）で使う
• マルチホップ（Multi-hop）：BGPなどで、途中に別装置がある相手まで到達性を監視する

どちらを使うかで、設定や前提（到達性、ACL、経路の固定、NATの有無など）が変わるため、目的に合ったモードを選ぶことが重要です。

BFDの応用

BFDは単体で“便利な監視”というより、他の仕組みと組み合わせて初めて効果が出ます。特に多いのは「インターフェースの状態」と「ルーティングプロトコル」をつなぐ使い方です。

インターフェースステータスとの関連付け

インターフェースが物理的にDownになれば、当然BFDもDownになります。一方、物理Upのままでも転送できない状態があるため、BFDを入れることで「Upなのにダメ」を拾える可能性が増えます。

ただし、BFDパケットは制御プレーン（または専用の処理）で扱われることが多く、環境によっては次のような要因で誤検知が起きることがあります。

• CPU負荷が高い時間帯にBFD処理が間に合わない
• 制御プレーン保護（CoPP/ACL）でBFDが落ちている
• QoSや輻輳でBFDパケットが優先されず欠落する

このため、BFDを入れるときは「速さ」だけでなく、運用時に落ち着く値にする設計が必要です。

BFDの設定

BFD設定は機器ベンダーやOSでコマンドが異なりますが、考え方は共通です。ここでは、設計時に押さえたいポイントを整理します。

BFDセッションパラメータの設定

基本パラメータは次の通りです。

• 送信間隔：どの頻度でBFDパケットを送るか
• 受信期待値：相手からどの頻度で来ることを期待するか
• 検出係数（multiplier）：何回欠落したらDownと判断するか

短くしすぎるとフラップ、長くしすぎると切り替えが遅い、という関係があるため、まずは「そのネットワークで許容できる瞬断時間」と「誤検知が許容できない度合い」を基準に決めます。特にWANや混雑しやすい区間では、攻めすぎない方が安定します。

エコーモード

BFDにはエコーモード（Echo）を持つ実装があります。これは、ある装置が送ったエコーパケットが戻ってくることを利用して、よりデータプレーン寄りの到達性確認を行う考え方です。

一方で、エコーモードは相手装置や経路上の装置の挙動（フィルタ、ポリシー、ハードウェア処理）に左右されやすく、環境によっては期待通りに動かないこともあります。まずは通常のBFD（制御パケット）で安定させ、必要性が明確な場合に検討するのが安全です。

BFDと処理方式（負荷と安定性）

BFDは“速い監視”であるほど、機器側の処理負荷や設計の影響を受けます。特に大規模環境では次の視点が重要です。

• 同時セッション数が増えたときのCPU/ハードウェア処理能力
• 制御プレーン保護（CoPP等）とBFD許可の整合
• 機器再起動・アップグレード時の挙動（復帰直後のフラップ）

「最短の検知時間」を狙うより、運用上、安定して回り続ける値を優先する方が、結果的にトラブルが減ります。

ルーティングプロトコルとの連携

BFDがDownになったとき、その情報をどこへ渡すかが肝です。代表的には次の連携があります。

• OSPF + BFD：隣接が落ちたときの検知をBFDで速め、OSPFの隣接断として扱わせる
• BGP + BFD：BGPのKeepaliveより速く到達性を検知し、セッション断として扱わせる

ここで注意したいのは、BFDがDownを出すと「即座に経路が切り替わる」と思い込みやすい点です。実際には、OSPF/BGPの収束、再計算、ポリシー適用、上流の伝播などが絡むため、期待値は「切り替えを速めるための重要な要素」と捉えるのが適切です。

BFDの実用例

BFDが効くのは「止めたくない」「切り替えを素早くしたい」ネットワークです。例えば、冗長ルータ構成の上流区間、DCのリーフ・スパイン構成の上位接続、拠点間の冗長回線、クラウド接続の冗長経路などで採用されます。

ネットワークの信頼性向上

BFDを導入すると、障害の検知が遅れて“冗長が効かない時間”を短くしやすくなります。特にユーザー体験が厳しいシステム（業務アプリ、音声、リアルタイム処理など）では、切り替えの遅れがそのまま品質低下につながるため、BFDが有効なことがあります。

迅速な障害復旧

BFDのDown通知を起点にOSPF/BGPがルートを更新し、健全経路へ寄せることで、復旧時間を縮められる可能性があります。ただし、誤検知で頻繁に切り替わると逆に品質が落ちるため、導入後はログやメトリクスを見て、タイマーや保護設定を調整する運用が現実的です。

BFDとルーティングプロトコル

BFDは、多くの場合「ルーティングプロトコルの検知を速める」ために使われます。ここでは代表的な組み合わせを押さえます。

OSPF

OSPFはHello/Deadの仕組みで隣接断を検知しますが、標準設定だと検知までに時間がかかることがあります。BFDを併用すると、BFDのDownをきっかけにOSPF隣接を落とし、ルート再計算を早める構成が取りやすくなります。

BGP

BGPはKeepalive/Holdで隣接断を検知しますが、広域網やインターネット接続では「素早く切り替えたい」要件が出やすい領域です。BFDと連携させることで、BGPセッション断を早めに確定させ、経路の引き上げ（withdraw）を速める設計が可能になります。

BFDの設定とトラブルシューティング

BFDは“便利”な反面、設定を詰めすぎると誤検知しやすい領域でもあります。問題が起きたときの見方を押さえておくと、復旧が早くなります。

BFDのパラメータ調整

調整の基本は次の順で考えるとブレにくいです。

1. 許容したい瞬断時間（ビジネス要件）を決める
2. 対象区間（LAN/WAN/混雑しやすさ）を踏まえて、攻めすぎない値にする
3. 導入後にフラップやCPU負荷がないかを観測し、必要なら緩める

「最短値にする」のではなく、「継続的に安定して回る値」を作るのが現場向きです。

トラブルシューティングのポイント

BFDセッションが落ちる・上がらない場合、典型原因は次のあたりです。

• BFDが経路上でフィルタされている（ACL/CoPP/QoSなど）
• 片側だけ設定されていて、相手がBFDに応答しない
• タイマーを短くしすぎて、混雑やCPU負荷で欠落する
• マルチホップで前提（到達性や経路固定）が崩れている

切り分けのコツは、「BFDが原因で落ちている」のか「BFDが正しく障害を検知して落ちている」のかを分けることです。前者なら保護設定や負荷、後者なら実際の区間障害や経路断が疑わしい、という見立てになります。

まとめ

BFDは、ネットワークの到達性を短い間隔で監視し、障害を素早く検知してOSPF/BGPなどへ通知するための仕組みです。BFD自体が経路を選ぶわけではなく、あくまで「検知」を担い、実際の切り替えはルーティングや冗長設計が行います。

導入効果は大きい一方で、タイマーを攻めすぎると誤検知で不安定になりやすいという性質もあります。要件（許容瞬断）と環境（混雑・負荷・保護設定）を踏まえ、安定して運用できる値に落とし込むことが、BFDを活かす近道です。