要約

  • BGP-LSはIGP/TE情報からNode、Link、Prefixのオブジェクトを派生し、ポリシーに従って物理、抽象、または混合ビューを開示する。LSDBをそのまま転送する仕組みではない。
  • 冗長なProducerやEstablished状態は鮮度の証明にならない。Sourceのepoch、Protocol-ID、Instance-ID、withdraw、属性欠落、Consumerの統合規則からFIBとパケット結果までを同じ判断記録に束ねる必要がある。

リンク障害そのものはIGPが処理していた。ところが分断された両側のProducerは、それぞれ逆向きの古い半リンクを保持した。一方はAからB、もう一方はBからAを依然として開示する。Consumerが二つを重複情報として統合すると、物理的には消えたリンクが論理グラフ上で完成する。

RFC 9552 は、到達不能になった起点ノードと冗長Producerを扱う箇所で、この種の不正確なトポロジーを示している。2023年12月に公開された現行標準であり、RFC 7752を全面的に置き換え、RFC 9029の更新も取り込んだ。

ここで問うべきは「BGP-LSが動いていたか」ではない。どの主体が、どのSourceから、どのポリシーと時点でトポロジーを記述する権限を持ち、その記述をいつ失効させるべきだったかである。

LSDBを材料にしても、成果物はLSDBではない

Producerは一般にOSPFまたはIS-ISのLSDBとTEDから情報を取り出し、BGP Link-State NLRIとBGP-LS Attributeへ変換する。一つのオブジェクトが複数のLSA/LSP由来情報を組み合わせることもあり、元のsequence numberは運ばれない。

したがってConsumerが受け取るのは導出された証拠である。Source protocolがpurge、age、malformed、ignoreと判断した情報は、その規則に従って扱われる。すべてのフィールドを輸出する必要もなく、タイミングを含む開示ポリシーが介在する。

差異は正当な設計にもなり得る。RFC 9552は物理トポロジーだけでなく、集約Nodeや仮想Pathからなる抽象ビュー、さらに両者の混合を認める。ALTO向けの粗いcost mapとPCE向けの詳細なTEビューが同一である必要はない。

ゆえに、設備台帳との不一致だけで誤りとは断定できない。Consumerごとの開示契約に、対象domain、object、attribute、抽象度、更新と鮮度、機密区分、利用目的を明記し、その契約との違いを検査する。契約がなければ、許可された抽象と欠落、古さを区別できない。

三つの役割を一つの監査欄に押し込まない

RFC 9552はBGP-LS Producer、Propagator、Consumerを分ける。ProducerはIGPなどからLink-State情報をBGPへoriginateする。PropagatorはUPDATEを処理し、BGP Decision Processを実行して選択結果を伝える。Consumerはその情報を使うアプリケーションまたはプロセスであり、BGP speakerとは限らない。

一台のシステムが複数の役割を兼ねても、責任まで融合するわけではない。Producerは導出と開示を、Propagatorは受信・選択・広告を、Consumerは重複判定・統合・利用を説明しなければならない。

BGP speakerからConsumerへのinterfaceは一方向でなければならず、Consumerが同じ経路を通じてBGP-LS originationへ情報を戻してはならない。読む権限と書く権限を分ける原則である。ネットワークを変更する要求は、別の認証済みsouthbound interfaceへ渡し、別の承認と監査を持たせる。

単純な「IGP→BGP-LS→Controller」という図は、Source受理、導出、export policy、BGP選択、Consumer統合、計算、承認、装置実行という独立した判断を隠す。前段の成功は後段の正当性を保証しない。

Instance-IDは運用上の名前空間である

non-VPN Link-StateにはAFI 16388 / SAFI 71、VPNにはSAFI 72を使う。RFC 4760 がMultiprotocol CapabilityとMP_REACH_NLRI、MP_UNREACH_NLRIを提供する。Capabilityは交換面の成立を示すだけで、個別オブジェクトの真偽や鮮度を示さない。

Protocol-IDはIS-IS L1/L2、OSPFv2、OSPFv3、Direct、Staticなどを区別する。8 octetのBGP-LS Instance-IDはIGP instanceを区別する。同じIGP domainを表すすべてのProducerは同じInstance-IDを使い、別domainは固有値にしなければならない。

境界を誤ると、一つのdomainが二重化されたり、別々のdomainが同じグラフに潰れたりする。ASN、area、router identity、topology ID、Node/Link/Prefix descriptorも識別に参加し、optional TLVの不一致は重複や部分属性を生む。

descriptor TLVを追加、削除、変更した場合、NLRI keyが変わる。新しいNLRIの広告だけでは足りず、古いkeyをMP_UNREACHでwithdrawする必要がある。移行完了の証拠には、新keyの存在だけでなく、旧keyがProducer、RIB、Adj-RIB-Out、Consumer graphの全てから消えたことを含める。

二重化は同じ時刻を二度観測することではない

RFC 4271 に基づく通常のBGP選択は、複数copyから一つを選べる。しかし、そのbest pathはBGP属性上の選好であり、物理状態に最も近い観測だという保証ではない。

冒頭の故障では、二つのProducerが同じ完全Linkを独立に確認したわけではない。互いに補完する古い断片を出した。Consumerのmergeが、Sourceのどちらも単独では述べていない「Linkは完全に存在する」という強い主張を作った。

鮮度の確認には、各Producerから見たorigin nodeの到達性、LSA/LSPのidentityとage、LSDB/TED epoch、origination時刻、selected/alternate path、期待されたwithdraw、Consumerのmerge状態が要る。session数やobject数では代替できない。

RFC 9552は、明示的な用途で完全なLSDB viewを維持する場合を除き、到達不能なorigin node由来の情報をwithdrawするよう勧める。例外を使うなら、保持理由、期限、古さの表示、利用できる計算を定義する。無期限の保持を通常状態にしてはいけない。

属性が消え、NLRIだけが残る場合

識別情報はNLRIに、多くのpropertyはBGP-LS Attributeに入る。RFC 7606 のerror handlingを踏まえると、malformedなBGP-LS AttributeがdiscardされてもNLRIは保持され得る。

この状態を「metricなしの正常Link」として扱うのは危険である。policyにより意図的に省略された属性、未知だが伝搬されたTLV、errorでdiscardされた属性、元々存在しない属性を区別して表示しなければならない。

大きな属性集合はRFC 8654 のExtended Messageに依存する場合がある。経路上のcapabilityやProducerごとのTLV除外が違えば、同じNLRI identityでもConsumerが得る材料は異なる。完全なattribute setのfingerprintを比較する必要がある。

IANAのBGP-LS Parameters はcode pointの定義を確認する台帳である。登録済みという事実は、実装が正しく収集したことや物理状態が正しいことを保証しない。

Topology feedは制御権限ではない

RFC 4655 のPCE architectureはTED入力を必要とし、RFC 7285 のALTOはnetwork/cost mapを扱う。RFC 8571 はIGP TE performance metricをBGP-LSで広告する。だが、transport仕様はConsumerのalgorithmや実行権限を規定しない。

証拠は境界ごとに残す。SourceではLSA/LSP identity、protocol、origin reachability、epoch。Producerではsoftware、Protocol-ID、Instance-ID、descriptor、abstraction policy、originate/withdraw時刻。Propagationではcapability、UPDATE、selected/alternate path、attribute discard、delay。Consumerでは受信object set、merge rule、missing property、freshness、authorization。

さらにcomputed pathを正確なsnapshot、constraint、algorithm/policy version、approvalへ結び、southbound request、device acceptance、label/FIB、positive/negative packet canaryまで追う。API successはdevice stateではなく、device ACKはpacket pathではない。

更新負荷と機密性を分離する

Link-State updateは通常のprefix更新より高頻度になり得る。RFC 9552は一般のBGP prefix distributionへの干渉を警告し、専用route reflectorなどの隔離を推奨する。また配布範囲を一つのadministrative domainに限る。

隔離してもtopologyやTE情報の機密性は変わらない。容量、構造、故障条件は商業上または運用上重要である。peerは信頼済みspeakerに限定し、Consumer専用peerからのUPDATEを拒否する。

Cisco IOS XR/IOS XEとJuniperの公式資料は、Instance-ID、policy、queue、table、controller acquisitionを実装上確認する方法を示す。ただしcommandやdefaultは製品・release固有である。監査にはversion、inherit後の実効設定、live stateを同時に残す。

Sources