02. ルーティングポリシーと実測したコンバージェンスのクイズ
最終更新日: 2026年9月15日
ワークブックに戻ります。各設問では1つ選び、その回答を裏付ける観測結果も説明してください。これらは推論の練習であり、ラボを実行したという主張ではありません。
- 選択したBGPラボでAS65000内にOSPFも構成するのはなぜですか？
- A) OSPFがBGPのすべてのポリシー判断に置き換わるため
- B) iBGPで使うループバックを含め、内部の到達可能性をOSPFが提供するため
- C) OSPFが外部プロバイダーにLOCAL_PREFを配布するため
回答を表示
回答: B
解説: BGPはポリシー情報を含む宛先情報を配布し、この設計ではOSPFが内部ルートを提供します。OSPFの隣接関係に加え、実際のBGP next hopへの経路も確認してください。隣接関係だけでは、必要なプレフィックスが存在する証拠になりません。
- iBGPで学習したプレフィックスがBGPテーブルに表示されていますが、そのNEXT_HOPを解決できません。次に何をすべきですか？
- A) next hopへの経路、next-hopポリシー、カーネルの経路検索を確認する
- B) セッションが確立しているため転送も成功したと判断する
- C) 到達不能なnext hopに到達できるよう、LOCAL_PREFを増やす
回答を表示
回答: A
解説: 優先度を上げても到達可能性は生まれません。実際のNEXT_HOPを特定し、ルーティングテーブルでインターフェイス/隣接先まで解決してください。その後、経路の適格性、選択されたルート、FIB、送信元を指定したトラフィックの証拠を比較します。
- c2は、c1経由でLOCAL_PREF 200の適格な経路と、x2経由でLOCAL_PREF 100の経路を学習しました。内部ホップ数が1つ多くてもc1を優先するのはなぜですか？
- A) BGPは常に最小のIPアドレスを選ぶため
- B) c1からweight 200が自動的に伝播したため
- C) LOCAL_PREFはAS内部のポリシーを表し、このFRRの選択過程ではAS-path長より先に評価されるため
回答を表示
回答: C
解説: BGPの選択は単純なIGPホップ数の計算ではありません。LOCAL_PREFは内部で伝達されますが、weightは実装/ルーター内だけで有効です。両方の経路が適格であること、前段の選択基準やポリシーによって前提が変わっていないことを確認してください。
- Route reflectorで解決できることと、引き続き確認が必要なことは何ですか？
- A) 不足するアンダーレイルートをすべて作成するため、クライアントにIGPが不要になる
- B) iBGPセッションの必要数を減らせるが、クライアントには使用可能なnext hopと転送の証拠が引き続き必要である
- C) すべてのクライアントがすべての代替経路を見られることを保証する
回答を表示
回答: B
解説: Route reflectionは広告ルールを変更し、ループ防止にORIGINATOR_ID/CLUSTER_LISTを使います。next hopへの到達性を修復するわけでも、すべての代替経路を見せる保証でもありません。また、reflectorがテナントのデータトラフィックを転送する必要はありません。
- 提案するexportフィルターでは
192.168.42.0/24だけを許可します。この契約により拒否する必要がある候補はどれですか？- A)
192.168.42.0/25。プレフィックスと長さの完全一致では、より具体的な経路は自動的に含まれない - B) 何もない。許可リストは明示的に拒否されない限りすべての経路を許可する
- C) MEDが大きい経路だけ
- A)
回答を表示
回答: A
解説: この契約で許可するのは1つのプレフィックスと長さだけです。/25、プロバイダーの192.168.100.0/24、デフォルトルートはいずれも対象外です。実際の広告は別途調べてください。文書上のフィルター設計は、フィルターが導入済みである証拠にはなりません。
- BGPポリシー属性について、妥当な説明はどれですか？
- A) コミュニティを付ければ、意図した動作が必ず強制される
- B) MEDは隣接するすべてのAS間で常に比較される
- C) コミュニティを解釈するにはポリシーが必要であり、MEDの比較は受信側のルールに依存する
回答を表示
回答: C
解説: コミュニティはラベルを伝えますが、そのラベルを運用上の意味にするのは受信側のポリシーです。MEDやAS-path prependが選択に影響するかどうかは、受信側の決定プロセスによります。他ASへの無条件の指示ではありません。
- このFRR/clabラボで、ルーティングCLIに入る正しい手順はどれですか？
- A) VMのシェルで
show ip routeを直接実行する - B) ラボのディレクトリから
netlab connect c1を実行し、c1のLinuxシェルでvtyshを実行する - C)
c1(config-router)#プロンプトでip route getを実行する
- A) VMのシェルで
回答を表示
回答: B
解説: 接続するとFRRコンテナのLinuxシェルが開きます。vtyshからFRR CLIを使います。Linuxのipやpingは引き続きシェルのコマンドです。単一のFRR showコマンドを実行する場合は、VM上のnetlab connect c1 --show ip routeも検証済みの方法です。
- ワークブックのポリシー変更を適用する前に、c1にはLOCAL_PREF 150が明示的に設定されています。どうすべきですか？
- A) 既存のポリシーを削除せず、意図したベースラインを確認する
- B) よくあるデフォルトが100なので、100だと仮定する
- C) 200を適用してから設定を削除し、元どおりに復元したとみなす
回答を表示
回答: A
解説: 提示された逆操作は、明示的な設定がなく有効な優先度が100であることを前提とします。既存の150を削除しても元の状態には戻りません。事前状態を把握することは、承認と再現性の一部であり、任意の注記ではありません。
- ピアの停止中、200ミリ秒間隔のタイムスタンプ付きプローブではパケット損失が観測されませんでした。妥当な結論はどれですか？
- A) コンバージェンス時間は正確に0ミリ秒だった
- B) すべてのアプリケーションとパケットサイズに影響がなかった
- C) このサンプリングでは停止を検出できなかった。経路/FIBの観測結果を残し、測定上の限界を報告する
回答を表示
回答: C
解説: サンプリングでは短時間の中断を見逃すことがあります。管理者による停止は、無応答の障害やタイマー満了とも異なります。一般的なタイマーに関する主張を推測するのではなく、実施した操作、観測された経路/FIBの変化、プローブ間隔、回復が持続したと判断する基準を報告してください。
- 障害実験を完了できるのは、どの結果が得られた場合ですか？
- A) プローブ出力を保存していなくても、BGPが再び確立した
- B) 対象ピアとポリシーの変更を正確に元に戻し、ベースラインの経路/FIB/プローブが回復し、測定上の制限も記録した
- C) ワイルドカードでのclearとホスト全体の経路flushによって出力が正常に見えるようになった
回答を表示
回答: B
解説: まずc1の名前付きピアを復元し、次に追加したlocal-preference設定を元に戻して、元の動作を確認します。テレメトリが欠けている場合は成功とはみなせません。管理対象のcloneとリビジョンを保持し、範囲を限定しないクリーンアップを行わずに失敗を報告してください。上流のc2=50バリデーターが通過したと主張してはいけません。
完了条件: すべての回答を説明し、ワークブックのベースライン/変更/障害/復元のマトリックスを添付するか、実作業を未実行と記載してください。