LinuxでBIRD2を使ってBGPとOSPFを構築するガイド

Network tutorial - IT technology blog
Network tutorial - IT technology blog

スタティックルーティングかダイナミックルーティングか — どちらが自分に合っている?

ネットワークを学び始めた頃、ほとんどの人はスタティックルートから入る。ルーティングテーブルに手動で経路を追加していく方法だ。小規模なネットワークなら問題ないが、ノード数が増えてくると途端に管理が大変になる。

以前15台ほどのVMが動くラボを管理していたが、新しいノードを追加するたびに各マシンにSSHしてルートを更新しなければならなかった。ちょっとしたミスでセグメント全体が切断される。それがダイナミックルーティングへ移行するきっかけだった。

LinuxでダイナミックルーティングのOSSとして主に3つの選択肢がある:

  • FRRouting (FRR) — Quaggaの後継で、Cisco IOSに近い構文を持つ。最も広く使われている
  • BIRD2 — 軽量で高性能、独自の設定言語を採用
  • OpenBGPD / OpenOSPFD — OpenBSD発のデーモン、Linuxでの利用は少ない

BIRD2とFRRoutingの比較

FRRouting

FRRはCiscoに近いVTY(Virtual Terminal)構文を採用しているため、Ciscoデバイスの経験がある人はすぐに習得できる。BGP、OSPF、OSPFv3、IS-IS、PIM、MPLS、EVPNなど多くのプロトコルに対応している。

メリット:

  • Cisco IOSの知識があればすぐに使いこなせる
  • コミュニティが大きく、ドキュメントも充実している
  • 多くのディストリビューションのリポジトリに収録されており、導入しやすい

デメリット:

  • BIRD2より重い — プロトコルごとに独立したプロセスが起動する
  • VTY設定は初学者には複雑に感じることがある

BIRD2

BIRD Internet Routing Daemon バージョン2は独自構文の単一設定ファイルを使用する。最初は少し奇妙に見えるかもしれないが、非常に強力で柔軟だ。単一プロセスですべてのプロトコルを処理する。

メリット:

  • 軽量で高性能 — 小規模VPSやエッジルーターに最適
  • フィルター言語が強力で複雑なロジックも記述できる
  • 複数のルーティングテーブルをすっきり管理できる
  • プロダクション規模のBGPルートサーバーとして多くのISPが採用している

デメリット:

  • 独自構文のため最初から学ぶ必要があり、Ciscoとは異なる
  • 慣れるまでデバッグに時間がかかる

OSPFとBGP、どちらを選ぶべきか?

ネットワークを教えているとよく聞かれる質問だ。端的に答えるとこうなる:

  • OSPF — 自社インフラ内(単一AS内)で使う。コンバージェンスが速く(数秒)、データセンターや複数VMのラボに適している。
  • BGP — アップストリームプロバイダーへの接続や、異なる組織・データセンター間のピアリングに使う。OSPFより複雑だが、ポリシーの柔軟性が高い。

小規模ラボや社内プロダクションであれば、まずOSPFから始め、マルチホーミングや外部ピアリングが必要になった時点でBGPを追加するのがよい。

Ubuntu/DebianへのBIRD2インストール

# Ubuntu 22.04 / Debian 12
sudo apt update
sudo apt install bird2 -y

# バージョン確認
bird --version
# BIRD version 2.0.x

# サービスの起動と自動起動設定
sudo systemctl enable --now bird
sudo systemctl status bird

デフォルトの設定ファイルは /etc/bird/bird.conf にある。変更前にバックアップしておこう:

sudo cp /etc/bird/bird.conf /etc/bird/bird.conf.backup

BIRD2でOSPFを設定する

3台のLinuxノードがあるラボを例に説明する:

  • Node A: 192.168.10.1
  • Node B: 192.168.10.2
  • Node C: 192.168.10.3

Node Aの /etc/bird/bird.conf に以下の設定を記述する:

log syslog all;

router id 192.168.10.1;   # Router ID — 通常はそのノードのメインIPアドレスを使用する

protocol device {
    scan time 10;
}

protocol direct {
    ipv4;   # インターフェースのアドレスを自動的にルーティングテーブルにインポートする
}

protocol kernel {
    ipv4 {
        export all;   # BIRDのルートをカーネルのルーティングテーブルに反映する
    };
}

protocol ospf v2 OSPF_MAIN {
    area 0.0.0.0 {    # バックボーンエリア
        interface "eth0" {
            type broadcast;
            cost 10;
            hello 10;
            dead count 4;
        };
    };
}

Node BとCは router id をそれぞれのIPアドレスに変更するだけでよい。設定を反映させるには:

sudo birdc configure         # サービスを再起動せずにリロード
sudo birdc show ospf neighbors   # ネイバーを確認

設定が正しければ、出力は次のようになる:

BIRD 2.0.12 ready.
OSPF_MAIN:
Router ID       Pri          State      DTime   Interface  Router IP
192.168.10.2      1        Full/DR      00:38        eth0  192.168.10.2
192.168.10.3      1       Full/BDR      00:34        eth0  192.168.10.3

BIRD2でBGPを設定する

BGPは、パブリックIPを持つVPSでアップストリームにプレフィックスをアナウンスしたい場合や、2つのデータセンター間でBGPピアリングを設定する場合によく使われる。2ノード間の基本的なBGP設定を紹介する:

Node A (AS 65001, IP: 10.0.0.1):

log syslog all;
router id 10.0.0.1;

protocol device { scan time 10; }
protocol direct { ipv4; }
protocol kernel { ipv4 { export all; }; }

# フィルター:有効なプレフィックスのみ受け入れる
filter bgp_import {
    if net ~ [ 10.0.0.0/8+ ] then accept;
    reject;
}

filter bgp_export {
    if net ~ [ 10.0.0.0/24 ] then accept;
    reject;
}

protocol bgp PEER_B {
    local 10.0.0.1 as 65001;
    neighbor 10.0.0.2 as 65002;

    ipv4 {
        import filter bgp_import;
        export filter bgp_export;
    };

    hold time 90;
    keepalive time 30;
}

Node B (AS 65002) — localneighbor、AS番号を変更するだけでよい:

protocol bgp PEER_A {
    local 10.0.0.2 as 65002;
    neighbor 10.0.0.1 as 65001;

    ipv4 {
        import filter bgp_import;
        export filter bgp_export;
    };

    hold time 90;
    keepalive time 30;
}

BGPセッションを確認する:

sudo birdc show protocols all PEER_B
sudo birdc show route protocol PEER_B

トラブルシューティング

これまでで最も難しかったネットワーク障害は、2つのデータセンター間でBGPピアリングを構築した時のことだ。BGPセッションが断続的に上がったり下がったりするが、ピーク時間帯にしか発生しない。しばらく分析した結果、MTUミスマッチが原因だと判明した。片側のインターフェースはMTU 1500、VPNオーバーレイの影響でもう片側は1450だった。トラフィックが増加するタイミングで大きなBGPパケットがフラグメント化されてドロップされていたのだ。原因の方向性を知らなければ非常に特定しにくい、断続的なパケットロスの典型例だ。

役立つデバッグコマンド:

# 特定のプロトコルのデバッグログを有効化
sudo birdc debug OSPF_MAIN all
sudo birdc debug PEER_B all

# ルーティングテーブルの詳細を表示
sudo birdc show route all
sudo birdc show route for 10.0.0.0/24

# OSPFの詳細
sudo birdc show ospf state
sudo birdc show ospf lsadb

# BGPの詳細
sudo birdc show protocols all
sudo birdc show bgp sessions

重要なポイント:birdc configure で設定をリロードする際、BIRD2はApply前に構文チェックを行う。エラーがあれば即座に拒否して報告してくれるため、夜中に間違った設定を反映してしまう心配がない。

便利な追加機能

ルート再配布:スタティックルートをOSPFに取り込む

protocol static STATIC_ROUTES {
    ipv4;
    route 172.16.0.0/24 via 192.168.10.254;
    route 172.16.1.0/24 via 192.168.10.254;
}

protocol ospf v2 OSPF_MAIN {
    redistribute static;   # スタティックルートをOSPFにインポートする
    area 0.0.0.0 {
        interface "eth0";
    };
}

BFD — リンク障害の高速検出

BFD(Bidirectional Forwarding Detection)を使うと、Helloタイマーが切れるまで待つのではなく、数百ミリ秒以内にネイバーの障害を検出できる:

protocol bfd {
    interface "eth0" {
        min rx interval 100ms;
        min tx interval 100ms;
    };
}

protocol ospf v2 OSPF_MAIN {
    area 0.0.0.0 {
        interface "eth0" {
            bfd yes;   # インターフェースでBFDを有効化
        };
    };
}

実践的な学習ロードマップ

BIRD2は、ラボや小規模プロダクション向けに軽量で柔軟なルーティングデーモンが必要な場合に最適な選択肢だ。最初の設定構文はFRRと異なるが、慣れればフィルターやポリシーの記述が非常に快適になる。

おすすめの学習ロードマップ:3ノードのラボでOSPFから始める → スタティックルートをOSPFに再配布してみる → 2つの仮想AS間でBGPピアリングを追加する。このフローをしっかり習得すれば、実際のプロダクション環境への適用も自信を持って行える。

Share: