要約

  • RFC 4456のroute reflectorは、通常のiBGPが禁じる内部経路の再広告を限定的に許す。ORIGINATOR_IDとCLUSTER_LISTが、その例外に発信元と通過履歴を与える。
  • local identityとの一致はadvertisementを無視する根拠になる。同一clusterの冗長RRでは正しいが、無関係なreflection domainへ値を再利用すると正当な経路が「戻ってきた経路」に見える。
  • raw UPDATE、判定理由、client role、候補、neighbor別出力、FIB、packetを結ぶ必要がある。EstablishedはNLRIの生存証明ではない。

同じ数字を二つの地域へ配った

東西に独立したreflection domainがあり、それぞれ二台の冗長RRを持つとする。東側の二台は10.0.0.42を共有する。同じlogical clusterを表すためであり、一台が既に反射した経路を他方が再び回さないという正当な設計である。

統合用の設定ひな型が、その値を西側にも投入した。階層設計では東西は別のままだが、protocol identityは同一と宣言した。東のclientから来た経路には10.0.0.42が記録されている。西のRRはlocal valueを見つけ、その経路を無視する。

TCP resetもNOTIFICATIONも必要ない。KEEPALIVEは続き、originatorのRIBにも経路は残る。session dashboardだけなら正常である。ところが一つのprefixは、選択処理より前の比較で消えている。

これはmechanismを示す合成例であり、実障害の主張ではない。重要なのは、loop-prevention labelがtopologyの意味を正しく表す場合にだけ安全だという点である。

Full meshを破るための例外

通常のiBGP speakerは、ある内部peerから学んだ経路を別の内部peerへ広告しない。AS_PATHによる外部ループ防止が使えない領域で再配布を止める単純な規則だが、大規模ASにfull meshを要求する。

Route reflectionはclient/non-client roleでこの負担を減らす。Non-clientから得たbest pathはclientsへ、clientから得たbest pathはclientsとnon-clientsへ送れる。他のRRもinternal peerであり、どちらのroleにもなり得る。

Roleはprotocol内で合意されない。両端のsessionが成立しても、互いの関係を異なるgraphとして設定できる。OPENが示すのはASとIdentifierであって、client membershipに対する共同署名ではない。

基礎的なreflectionは候補も減らす。RRがbest pathを選び、その結果を配る。ORRはclientのIGP視点を代行し、ADD-PATHは条件付きで複数候補を伝えるが、どちらも戻り経路を見分けるidentity ruleを無効にしない。

Originatorとclusterの記憶

ORIGINATOR_IDはtype 9のoptional non-transitive attributeで、長さは4 octetである。RRが最初に反射するとき、AS内で経路を起こしたspeakerのBGP Identifierを保存する。既存値を作り直してはならず、自分のIdentifierを受け取ったrouterは経路を無視すべきだ。

CLUSTER_LISTはtype 10で、通過したcluster identitiesを順序付きで持つ。各RRは反射時にlocal CLUSTER_IDを先頭へ追加する。受信側がlocal valueをリスト中に見つければ、そのinformationは同じclusterへ戻ったものとして扱う。

二つの属性は認証ではない。前者は最初のinternal originatorへの帰還を、後者はreflection domainへの帰還を検出する。外部originの権限、routerの所有、interfaceの到達性は証明しない。

RFC 6286ではBGP IdentifierはAS内でuniqueなnonzero 4-octet valueであり、割り当て済みIPv4 addressである必要はない。点区切り表示を資産やlocationと読み替えてはならない。Cluster IDも論理的な値であり、等号がroute acceptanceへ作用するからこそ厳密に管理する。

正しい共有と偽の等価性

同じclusterに複数のredundant RRを置く場合、RFC 4456は共通cluster IDを認める。互いを同じ防御領域のmemberと扱い、既処理の経路を捨てるためである。共有そのものはbugではない。

問題は、そのequivalence classを越えて値が広がることにある。設定の複製、router ID再利用、inventory統合、per-neighbor override、途中のhierarchy migrationが別領域を同一に見せる。Protocolは人間の意図を読まず、受信値とlocal valueだけを比較する。

ORIGINATOR_IDでは、同一ASの二台がBGP Identifierを重複させると、一方の経路を他方が自分の戻りとして拒否できる。実packet loopの観測は前提ではない。Symbol collisionだけで到達性に対するdecisionが成立する。

従ってglobal uniquenessという一語では足りない。BGP IdentifierはAS-wide uniqueである。Cluster IDは、真に同じ冗長clusterのmember間では共有し、異なるdomainを結ぶvalid path上では衝突させない。

Malformedとsemantic matchを分ける

Local cluster IDを含むwell-formed UPDATEは壊れたmessageではない。正しい構造の情報がloop ruleを発動したのである。RFC 7606が扱うmalformed attributeとは別の事象だ。Telemetryはparser error、import policy、originator match、cluster match、best-path lossを別々に残さなければならない。

Hard rejectがなくても属性はtie-breakへ入る。ORIGINATOR_IDは対応する段階でadvertising speakerのBGP Identifierとして使われ、さらに短いCLUSTER_LISTが優先される。Listなしは長さ0である。

この長さは物理距離でもdelayでもtrustでもない。Reflection historyの表現長にすぎない。Renumberingによりprefix countを維持したままbest pathが変わる可能性があるため、candidate set、選択理由、neighbor別Adj-RIB-Outを比較する。

ORRは選択視点、ADD-PATHは候補開示を扱う。RFC 3345/7964のoscillationは情報圧縮やMEDが繰り返し選択を揺らす問題である。False cluster matchは安定したabsenceを作れる。Transport authenticationが証明するのは受信byteの相手であり、cluster mapの正しさではない。

証拠を一つのledgerへ

AS、VRF、AFI/SAFIごとにBGP Identifier、global/explicit/per-neighbor cluster IDs、client direction、redundancy group、hierarchy level、software release、change ownerを保存する。共有値には「どの機器が、なぜ同一clusterを代表するか」という理由が必要だ。

対象NLRIにはraw UPDATE、ORIGINATOR_ID、ordered CLUSTER_LIST、比較したlocal values、syntax result、exact dispositionを付ける。次にcandidate rank、Loc-RIB、neighbor別advertised view、downstream Adj-RIB-In、FIB next hop、packet measurementをつなぐ。

Configは意図、UPDATEは観測state、comparisonは権限行使、RIBはcontrol decision、FIBは転送program、packetはservice outcomeである。一つの画面で全層を代表させない。

数字より先にgraphを試す

Migration前にdirected client/non-client graphと冗長clusterを宣言する。各valid source-to-client pathをsimulationし、目的地より前に自分のoriginator/cluster identityへ遭遇しないことを確認する。

Canaryは全client class、redundant pair、hierarchy、AFI/SAFI、vendor、releaseを横断する。Membershipだけでなくorderを検査し、各反射が既存sequenceの先頭へ期待値を足したか確認する。説明できない共有、session eventのないprefix loss、version間の構築差があれば停止する。

Rollbackはconfig復元で終わらない。Bounded replayまたはre-evaluationでdownstream RIBを置き換え、候補とpacketが戻ったことまで証明する。

情報源