02. ルーティングポリシーと収束時間の測定

最終更新日: September 15, 2026 ラボの範囲: 個別に準備し、所有権を持つ使い捨てのLinuxルーティングVMを1台使用します。FRRoutingコンテナはローカルでのみ実行します。 検証状況: 上流ドキュメント、トポロジー、CLIの情報を確認しました。執筆中にルーティングラボは実行していません。

このワークブックを終えると、あるプレフィックスが選択された理由、そのネクストホップが使用可能であることの確認方法、制御した障害時にトラフィックが受けた影響の測定方法を説明できるようになります。 まず初級編の8レッスンをすべて完了してください。コンテナ／クラウドの総合演習も含まれます。 プロトコルのルーティングテーブルを見てもパケットの経路が分からない場合は、Linuxのパケット転送を復習してください。

1. 問いを立てて読む

読む資料	自分の言葉で答える問い
BGP Labsの概要とFRRoutingの入門	Linuxシェルで行う操作と、vtyshで行う操作はそれぞれ何ですか。
Local Preferenceのラボ	一方のエッジで設定した優先度が、もう一方のエッジにどう影響しますか。
FRR BGPマニュアル	受信した経路は、いつ候補となり、選択・広告・インストールされますか。
FRR OSPFマニュアル	隣接関係が示すことは何ですか。また、IGPが運ぶプレフィックスはどれですか。
RFC 4271とRFC 4456	通常のiBGP広告ルールは、ルートリフレクションとどう異なりますか。

設定を始める前に、該当する節を読みます。ルーティングセッションとフォワーディングリンクを分けた図を作成してください。 BGPセッションはスピーカー間のTCP接続です。その接続を通じて広告されたすべての宛先に到達できる、という意味ではありません。

2. コントロールプレーンのモデルを作る

IGPとBGPは異なる問題を解決します。 OSPFは管理ドメイン内でリンクステート情報を配布し、コストを使って経路を計算します。 このラボでは、iBGPで使用するループバックを含む内部到達性を提供します。 BGPは属性とポリシーを使って宛先への到達性を交換します。単純にOSPFを最短ホップで置き換えるものではありません。 両プロトコル間ですべての経路を無条件に再配布すると、余計な経路、ポリシーの曖昧さ、フィードバックループが生じるおそれがあります。

eBGPは通常、異なる自律システム間で経路を交換し、iBGPは同じAS内でBGP情報を配布します。 AS_PATHはASレベルのループ検出に役立ちます。また通常のiBGP広告制限により、内部での単純な再広告ループを防ぎます。 iBGPで学習した経路は、通常、別のiBGPピアには広告されません。フルメッシュ、ルートリフレクター、または意図的に設計した別の方式が必要です。 セッションの接続関係からフォワーディングのトポロジーを推測しないでください。

ネクストホップの解決は、実際のフォワーディングに先立って必要です。 BGP経路が見えていても、そのネクストホップへの到達経路がなければ使用できません。 iBGPのネクストホップは、next-hop-selfなどで設計上変更しない限り、外部アドレスのままの場合があります。 実際に受信したNEXT_HOPを確認し、ルーティングテーブルをたどってインターフェースと隣接先まで再帰的に解決してください。 OSPFの隣接関係が確立しているだけでは、必要なネクストホップのプレフィックスが広告された証拠になりません。

レイヤー	確認できること	それだけでは確認できないこと
BGPセッション	状態とネゴシエート済みアドレスファミリー	目的のプレフィックスが受け入れられたこと
BGP RIB	候補経路、属性、有効性、ベストパスの表示	選択された経路がフォワーディングプレーンに反映されたこと
Zebraのルーティングテーブル	選択された経路とインストール状態	パケットが意図したインターフェースから実際に送出されたこと
LinuxのFIB検索	宛先への経路、送出インターフェース、ネクストホップ	戻り経路があること、またはパケットフィルタリングがないこと
パケット観測	送信元を指定したプローブとインターフェースキャプチャ	すべてのアプリケーション、パケットサイズ、ECMP経路が機能すること

報告では両方を「ルーティングテーブル」と呼ばず、「BGPテーブル」と「カーネルのフォワーディングテーブル」を明記してください。 FRRはZebraを介してルーティング判断を渡します。この構成で選択したソフトウェアデータプレーンでは、Linuxがフォワーディングを実行します。

3. テスト前にポリシーを説明する

仕組み	運用上の目的	よくある誤解
プレフィックスフィルター	意図したプレフィックスとプレフィックス長だけを許可または広告する	/24を許可すると、より具体的な経路もすべて許可される
LOCAL_PREF	AS内部の出口の優先度を表す。値が大きい方が優先される	外部ASにどの入口を使うか指示する
Weight	ルーター1台だけで使う、実装固有の優先度	BGP属性として他のルーターにも伝わる
AS_PATH／プリペンド	ASの通過履歴を示し、ポリシーが許す範囲で経路選択に影響する	LOCAL_PREFが高くてもAS_PATHが短い経路が必ず勝つ
MED	受信側の比較ルールに従って入口の優先度を提案する	隣接するすべてのASとの間で必ず比較される
Community	受信側のポリシーが解釈できるラベルを運ぶ	対応するポリシーがなくてもラベル自体が動作を強制する
ルートリフレクター	経路を反射してiBGPセッション数を減らす	不足しているネクストホップ経路を補う、または必ず中継パケットを運ぶ

リフレクターのORIGINATOR_IDとCLUSTER_LISTはループ防止に使われます。リフレクターの経路選択によって、クライアントから別候補が見えなくなることもあります。 反射された経路については、クライアント、リフレクター、ネクストホップへの到達性を分けて調べてください。 このワークブックのトポロジーにリフレクターを追加せず、後日、別途準備した演習としてルートリフレクターのラボを利用してください。

このフィルター設計を、設定を適用せずに記述します。上流に広告するのは192.168.42.0/24だけです。 完全一致の/24はこの経路を許可し、192.168.42.0/25と、学習したプロバイダー側プレフィックス192.168.100.0/24を拒否する必要があります。 別途明記した契約で許可されない限り、0.0.0.0/0も拒否します。 暗黙の拒否、評価順序、フィルターを適用する方向を説明してください。 実際のフィルター演習には広告プレフィックスのフィルタリングを続けてください。このラボの既存ポリシーが、ここで提案するフィルターを実装しているとは限りません。

4. このラボの準備

選択した上流ラボは、bgplab/bgplabのpolicy/5-local-preference/topology.yml、リビジョン5a9fab68658ce69317b147396481714ee3478482です。 4台のルーターは、AS65000のc1/c2とAS65100のx1/x2です。 トポロジーにはOSPF、eBGP、iBGP、経路広告が設定されており、学習者は顧客側のポリシーを変更します。 トポロジーのソースには、netlab 2.0.0以降が必要です。

提示されているhttps://bgplabs.net/install/は確認日に404を返しました。代わりに公式のインストールとセットアップを参照してください。 このワークブックを始める前に、別のVM上でUbuntuのインストール前提条件に従います。 初級編のVM、共有Dockerホスト、Kubernetesノードは再利用しないでください。

• 所有権を持つx86-64版Ubuntu 24.04 VMを1台用意します。4 vCPU、8 GiB RAM、空きディスク20 GiBは、FRRコンテナ4台とツールのための計画上の目安であり、上流が定める最小要件やベンチマークではありません。
• 上流の手順に従ってnetlabとそのAnsible依存関係、Docker、containerlab（clabプロバイダー）、Git、iproute2、iputilsのping、GNU timeout、tcpdumpを準備します。
• インストールしたnetlabのリリースとプロバイダーのバージョンを記録してください。そのnetlabリリースが選択するFRRイメージを使い、タグ、イメージID／ダイジェスト、実際のshow versionを記録します。
• CLI例はFRR 10.6.1のソースを基に確認しました。実行時のリリースが異なる場合は、変更を加える前にコマンドヘルプを確認してください。「FRRイメージ」というだけでは互換性を保証できません。
• この構成で選択したFRRはオープンソースで、商用ルーターのライセンスは不要です。ただし、イメージの取得とツールの準備にはネットワークアクセスが必要です。
• プロバイダーの操作には、この使い捨てVM上での権限が必要です。FRRコンテナ内ではLinuxシェルとvtyshをrootで実行します。VMコンソールを利用可能な状態に保ち、管理インターフェースには手を加えないでください。
• VM、クローンディレクトリ、ラボ名を自分が専有していることを確認します。顧客側とプロバイダー側のリンクはシミュレーション用のローカルリンクであり、ISPやインターネットには接続されません。

ラボVMのシェルで、新しいクローンを1つ作成します。コピー先はまだ存在していない必要があります。

test ! -e "$HOME/expert-routing-bgplab"
git clone --no-checkout https://github.com/bgplab/bgplab.git "$HOME/expert-routing-bgplab"
git -C "$HOME/expert-routing-bgplab" checkout --detach 5a9fab68658ce69317b147396481714ee3478482
cd "$HOME/expert-routing-bgplab/policy/5-local-preference"
git rev-parse HEAD
git status --short
sha256sum topology.yml
python3 -c 'from importlib.metadata import version; print(version("networklab"))'
containerlab version
docker version
ansible --version
uname -r

コピー先が存在しないことを確認できなければ中止してください。既存ディレクトリに対して残りのクローンコマンドを実行してはいけません。 これらの出力はクローンの外にある証跡記録へ保存します。 準備が完了するのは、このディレクトリで所有者が上流の起動手順に従い、provider=clab、顧客側デバイスfrr、外部側デバイスfrrを指定した後です。 上流の起動操作はラボを作成・設定します。読み取り専用コマンドではなく、事前に必要な手順です。 VMの所有者は生成されたノード／コンテナのIDを記録し、実験前のVMチェックポイントを所有下で保存してください。 この章の執筆者は起動、インストール、ホスト設定、ティアダウンのいずれも実施していません。

5. 準備状況とターミナルの使い分け

同じラボディレクトリにいるVMシェルから、次を実行します。

netlab defaults --project
netlab status
netlab connect --dry-run c1
netlab connect c1 --show version
netlab connect c1 --show running-config
netlab connect c2 --show bgp ipv4 unicast summary
netlab connect c1 --show ip ospf neighbor
netlab connect c2 --show ip ospf neighbor

netlab defaults --projectにはnetlab 2.0.1以降が必要です。2.0.0では、クローンしたdefaults.ymlを確認してください。 接続方法のリファレンスでは、単一ノードへの接続と--showの両方を説明しています。 このFRR／clab構成でnetlab connect c1を実行するとc1のLinuxシェルが開き、そこからvtyshを実行するとc1のFRR CLIが開きます。 以下のプロンプトは表示例であり、入力する文字列ではありません。

lab-vm$ netlab connect c1
c1-linux# vtysh
c1# show version
c1# show running-config
c1# exit
c1-linux# exit

ip、ping、シェルコマンドはLinux側で実行し、c1#では実行しません。 configure terminalでFRRの設定モードに入り、endでFRRの運用プロンプトに戻ります。 VMからnetlab connect c1 --show ip routeを実行すると、適切なFRRラッパーが使われます。Linuxシェルにshowコマンドを直接送らないでください。

準備完了の条件は、iBGP／eBGPセッションが実際に確立していること、意図したOSPFネイバーが成立していること、c2でプロバイダー側の有効な経路候補が2つあること、上限時間を設定したプローブが成功することです。 記録したc1、c2、x1、x2のコンテナIDを1つずつ指定し、docker inspect --format '{{.Config.Image}} {{.Image}}' CONTAINERでイメージを確認してください。 ホスト全体のコンテナ一覧を、これらのノードのバージョンを示す証拠として代用しないでください。

6. ベースラインを予測し、観測して説明する

指定リビジョンでは、c1の外部ピアは10.1.0.2、c2の外部ピアは10.1.0.6です。 iBGPのループバックは10.0.0.1と10.0.0.2、顧客セグメントは192.168.42.0/24です。 使う前に、実行中の設定でこれらの値を確認してください。 プローブ先192.168.100.10は、シミュレーションされたプロバイダーセグメント上にあるx1のアドレスです。

netlab connect c2 --show bgp ipv4 unicast 192.168.100.0/24
netlab connect c2 --show ip route 10.0.0.1/32
netlab connect c2 --show ip route 192.168.100.0/24
netlab connect c2 ip route get 192.168.100.10
netlab connect c2 ping -I 192.168.42.2 -c 5 -W 1 192.168.100.10
netlab connect c1 --show bgp ipv4 unicast neighbors 10.1.0.2 advertised-routes

両方の候補経路、ネクストホップ、AS_PATH、LOCAL_PREF、ベストパスになった理由、カーネルの経路検索結果を記録してください。 c2が直接接続された上流を選んだのか、c1経由の出口を選んだのかを説明します。 広告出力にある実際の各プレフィックスを、提案したエクスポート許可リストに照らして分類してください。想定外の広告は調査対象であり、提案フィルターが動作した証拠ではありません。 応答がないときに送信側ポリシーのせいにする前に、x1に192.168.42.0/24への戻り経路があるか確認します。

7. 顧客側の出口優先度を1つ変更する

変更前の状態: c1のAS65000インスタンスにはbgp default local-preferenceが明示的に設定されておらず、実効値は100であり、調べるプロバイダー経路に対する受信ポリシーの上書きもありません。 c2のベースライン実効値も100です。両方の設定を保持してください。 条件が異なる場合、既存のポリシーを削除せず、適切なベースラインを確立できるまで中止してください。

変更対象はc1のAS65000 BGPインスタンスです。元に戻すときは、ここで追加した設定だけを削除します。 c1のFRR CLIで次を実行します。

configure terminal
router bgp 65000
 bgp default local-preference 200
end
show bgp ipv4 unicast 192.168.100.0/24

このFRRコマンドは10.6.1のCLI実装で確認されています。この実装では、当該インスタンスで受信経路の再処理も行います。 共有環境で使う上流のワイルドカード付きclearコマンドを、そのままコピーしてはいけません。 6節の確認をc2で再実行します。c1経由の有効な経路はLOCAL_PREF 200となり、値100の経路より優先され、その後FIBとパケット経路にも反映される想定です。 属性が変化しない場合は、受信ポリシー、ネクストホップの有効性、実際の実行時バージョンを確認してください。設定行があるだけではPASSになりません。 このワークブックで変更するのはc1だけです。そのため、上流バリデーターが別途期待するc2=50は、ここでの合格基準ではありません。

8. 1つのピア障害を測定する

優先度の実験は有効なままにします。変更前の状態として、c1のネイバー10.1.0.2が確立済みで、shutdown設定がないことを確認してください。 元に戻すコマンドは、同じBGPインスタンスで実行するno neighbor 10.1.0.2 shutdownです。 これは管理操作によるピア障害であり、ケーブル切断、無通知のパケット損失、BFDの実験ではありません。

時刻付きプローブには、VM上でc2の記録済みコンテナのネットワーク名前空間内にあるiputilsを使います。 ラボのインベントリ／プロバイダーマッピングから名前を調べ、ip netns listで存在を確かめてください。曖昧なワイルドカードで選んではいけません。 2つ目のVMターミナルで使う前に、プレースホルダーを置き換えます。

routing_c2_ns='REPLACE_WITH_THIS_LABS_C2_NAMESPACE'
sudo ip netns exec "$routing_c2_ns" ip -br address
sudo ip netns exec "$routing_c2_ns" ping -D -O -n -I 192.168.42.2 -i 0.2 -c 150 -w 40 -W 1 192.168.100.10

表示されたアドレスがc2のものと一致することを確認してください。障害を発生させる前に、複数回のプローブ応答が成功する状態にします。 iputilsの-Oオプションは、応答待ちのパケットを表示します。シーケンス番号と後続の応答を照合し、応答待ちの表示を恒久的な損失とみなさないでください。 c1のFRR CLIで操作時刻を記録してから、次を適用します。

configure terminal
router bgp 65000
 neighbor 10.1.0.2 shutdown
end

上限時間を設定したプローブの実行中に、6節の手順でc2のBGPプレフィックスとカーネル経路をサンプリングします。 別のターミナルで、キャプチャコマンドを使い、c2のバックアップ用データインターフェースであることを確認してからキャプチャしてください。指定リビジョンのFRRトポロジーではeth2に対応します。

timeout 20s netlab capture c2 eth2 -nn -l -c 40 icmp

タイムアウトは収集時間に上限を設けます。該当パケットがない場合やアクセスエラーが起きた場合は、キャプチャ成功を意味しません。 c2はx2を選択し、その後、プロバイダー内部セグメント経由でx1に到達する想定です。 t_action、最初に観測された経路のwithdraw/change、FIBの変更、最後に失敗したプローブ、回復が継続し始めた時点を区別してください。 たとえば「連続5回の応答」など、回復が継続したとみなす条件を事前に定義し、サンプリング間隔と不確実性も報告します。 プローブと操作記録には同じVMの時計を使います。CLI操作の直前にVMシェルでdate -u +%FT%T.%NZを記録し、手動でターミナルを切り替える時間も不確実性に含めてください。 観測された損失がゼロなら、そのサンプリングレートでは停止時間を特定できなかったという意味であり、収束時間がゼロという意味ではありません。 ホールドタイマー、BFD、グレースフルリスタート、障害検出、経路処理、FIB登録はすべて結果に影響します。普遍的に適用できる固定の収束時間を断定しないでください。

9. 元に戻し、再試行して提出する

まずピアを戻します。c1のFRR CLIで実行してください。

configure terminal
router bgp 65000
 no neighbor 10.1.0.2 shutdown
end

ピアが再確立し、優先経路が戻り、プローブが回復することを確認します。 次にポリシー設定を元に戻します。

configure terminal
router bgp 65000
 no bgp default local-preference
end

実行中の設定、両方の候補経路、実効優先度、FIB検索、元の送信元指定プローブを再確認します。 実験設定をスタートアップ設定に保存したり、FRRを再起動したり、広範囲なクリーンアップコマンドを実行したりしないでください。 回復しない場合は、以降の実験を中止し、異なる設定対象を報告してください。証跡をエクスポートした後、所有者はこの使い捨てVMだけに保存したチェックポイントを復元できます。 新しいクローンは証跡として残します。後日廃棄する場合も、所有者のライフサイクル手順に従い、この所有VMだけを対象にしてください。

段階	必要な肯定的証拠	保存すべき否定的／障害の証拠
ベースライン	有効な経路候補が2つあること、ネクストホップが使用可能なこと、プローブ成功	戻り経路の欠落、未解決のネクストホップ、セットアップエラー
優先度変更	c1由来のLOCAL_PREF 200、出口の選択、それに合致するフォワーディング	属性が変わらない、RIBとFIBが一致しない
ピア障害	代替経路と、継続的なプローブ回復の観測	損失区間、代替経路なし、キャプチャエラー
復元	元の設定とフォワーディング動作	shutdownの残存、ポリシーのずれ、損失の継続

各復元の確認に合格した場合に限り、障害測定を3回繰り返します。個々の測定値と観測範囲を報告してください。 平均だけでなく、生のタイムスタンプと出力を保存します。各結果は「測定済み」「計画済み」「ブロック中」のいずれかとして明示してください。 経路がないこと、プローブ記録がないこと、キャプチャ結果が空であることは、肯定的な主張の証拠になりません。 ポリシー、ネクストホップの再帰的解決、「セッションが確立していればサービスも利用可能」という考えへの反例、測定の限界、復元確認について説明できれば、この章を完了です。 続けてEVPNを学び、その後、Kubernetesの専門編としてCalico BGPを参照してください。 結果の表を自動化の総合演習に提出し、クイズにも回答してください。