Session Goal
このセッションで終わらせたいこと
Session 09 のゴールは、peer down を「1 本の route が消える話」ではなく「その peer 由来の state が消えて、affected prefix ごとに recompute が走る話」として説明できるようになることです。
- peer loss が複数 prefix に影響しうると説明できる
- Adj-RIB-In の cleanup が先だと説明できる
- backup path が best に昇格すると説明できる
- 代替がなければ Loc-RIB entry が消えると説明できる
Bridge
withdraw を peer 単位の state cleanup に広げる
Session 02 では UPDATE withdrawal を見ました。Session 09 ではそれを peer state に拡張して、session loss が「その peer から受け取っていた path 全体の removal」になることを読みます。そのあとに best-path recompute が走ります。
Read Order
この順番で読むと迷いにくい
recompute_best_path_for_prefix()を読むhandle_peer_loss()を読むlost_prefixesの作り方を見る- peer state の削除が先に来ていることを確認する
- walkthrough で backup path への切り替わりを見る
Read The Source
peer loss は affected prefix の再計算を呼ぶ
lost_prefixes = tuple(adj_rib_in.paths_by_peer.get(peer_id, {}).keys())
adj_rib_in.paths_by_peer.pop(peer_id, None)
for prefix in lost_prefixes:
results[prefix] = recompute_best_path_for_prefix(adj_rib_in, loc_rib, prefix)この code が示しているのは、peer down の直後に Loc-RIB を直接いじるのではなく、まず received state を消してから prefix ごとに candidate を組み直す、という順番です。
Outcomes
recompute の結果は 2 通りある
| result | 意味 |
|---|---|
| replacement path exists | surviving peer の path から新しい best path を install する。 |
| no replacement path | Loc-RIB から prefix を remove する。 |
Walkthrough
best path の持ち主が消えたあとを追う
walkthrough では 2 peer から同じ prefix を受け取り、より良い path を Loc-RIB に install したあと、その peer を失って backup path が best に上がる様子を見ます。
cd protocol-in-code PYTHONPATH=src python3 examples/bgp/session_09_walkthrough.py
Done Check
Session 09 を終えたと言える条件
- peer down は per-prefix recompute を呼ぶと説明できる
- Adj-RIB-In cleanup が先だと説明できる
- backup path への切り替わりを説明できる
- 代替 path がないと Loc-RIB から消えると説明できる
Next Session
次は複数 candidate を含む integration を読む
Session 09 では recompute を単体で見ました。次の Session 10 では、received state、validation、import policy、best-path、install、export を 1 本の toy pipeline として再接続します。