Protocol in Code · BGP Session 06

Where Routes Live

Session 06 では GitHub 上の ribs.py を開いて、received path がどこに置かれ、best path がどこに入り、広告予定の route がどこに積まれるかを読みます。ここで Adj-RIB-In、Loc-RIB、Adj-RIB-Out を別の store として切り分けます。

IntermediateSession 06RIB structureRFC 4271
Open GitHub sourceOpen walkthrough

Session Goal

このセッションで終わらせたいこと

Session 06 のゴールは、BGP route が router の中でどこに住むかを、received state と selected state と outbound state に分けて説明できるようになることです。Session 02 と Session 03 の間を埋める橋として読みます。

  • Adj-RIB-In が per-peer の received state だと説明できる
  • Loc-RIB が selected state だと説明できる
  • Adj-RIB-Out が outbound state だと説明できる
  • PathAttributes が PathCandidate に変わる場所を説明できる

Bridge

Session 02 と Session 03 をつなぐ

Session 02 では UPDATE が state を変えることを見ました。Session 03 では candidate 同士を比較しました。Session 06 はその間をつないで、received path がまず Adj-RIB-In に入り、そこから candidate が作られ、best path が Loc-RIB に入る流れをコードで見えるようにします。

ここで大事なのは、best path selection は空中で起きるのではなく、どこかに保存された received state を材料にして走る、という感覚です。

Prerequisite

Session 02 の table model を更新する

Session 02 では prefix-wide の最初の table model を使いました。ここではそれを per-peer の Adj-RIB-In に置き換えて、同じ prefix に複数 peer の path が残りうる形へ refine します。

Read Order

この順番で読むと迷いにくい

  1. AdjRIBIn を読んで received state の置き場所を見る
  2. LocRIB を読んで selected state の置き場所を見る
  3. AdjRIBOut を読んで outbound state の置き場所を見る
  4. store_received_path() を読んで UPDATE の着地点を見る
  5. build_candidates() を読んで Session 03 への bridge を見る
  6. install_best_path() と stage_advertisement() を読む

Read The Source

どの store に何を入れているかを見る

src/protocol_in_code/bgp/ribs.py
store_received_path(adj_rib_in, peer_id, prefix, attributes)
candidates = build_candidates(adj_rib_in, prefix)
best = select_best_path(candidates)
install_best_path(loc_rib, best)
stage_advertisement(adj_rib_out, peer_id, best)

この流れをそのまま追うと、received path と best path と outbound path が別の箱に入っていることが見えます。特に build_candidates() は、Session 02 の PathAttributes を Session 03 の PathCandidate に写す bridge です。ここでは pure best-path comparison のために peer_id を落としていて、後半の policy-aware decision でその文脈を復元します。

Stores

3 つの RIB を混ぜない

store意味
Adj-RIB-In各 peer から受け取った path を保持する。
Loc-RIBlocal に install した best path を保持する。
Adj-RIB-Out各 peer に広告する予定の path を保持する。

Walkthrough

2 本の received path が 1 本の best path になる

walkthrough では 2 つの upstream から同じ prefix を受け取り、Adj-RIB-In に積んでから candidate を作り、Loc-RIB に 1 本 install し、Adj-RIB-Out に customer 向け広告を staged します。

run locally
cd protocol-in-code
PYTHONPATH=src python3 examples/bgp/session_06_walkthrough.py

Done Check

Session 06 を終えたと言える条件

  • received path と selected path と outbound path を別の state として話せる
  • build_candidates() が Session 02 と 03 の bridge だと説明できる
  • 複数 path が入っても Loc-RIB は 1 本だと説明できる
  • Adj-RIB-Out は Loc-RIB の単純コピーではないと説明できる

Next Session

次は import policy で candidate の shape を変える

ここで received path の置き場所は見えました。次の Session 07 では、その candidate が best-path に入る前に local policy でどう書き換えられるかを見ます。

Back to Session 05Open Session 07Back to course map