要約

  • BGP PICは多数のプレフィックスに階層化されたnext-hopオブジェクトを共有させる。対象障害では少数のpathlistやポインターを変え、プレフィックスごとのFIB書き換えを避ける。
  • 高速切替には、利用可能な代替経路が事故前に学習、選択、インストールされている必要がある。二本目のrouteや異なるBGP next hopだけでは、物理的独立性、容量、ハードウェア実装を証明できない。
  • 管理すべき対象は、候補の可視性、予備の資格、shared fate、検知権限、FIB階層、実パケット、そして安定経路への復帰までを含む。

午前2時14分、ingress PEが優先egressを失う。BGPはVPN routeを処理中で、route reflectorも新しい状態を配り終えていない。それでも何十万プレフィックス分のトラフィックが別のPEから出始める。

運用室は「なぜこれほど速く収束したのか」と問う。先に問うべきは「その経路を誰が、いつ選んだのか」である。

答えは障害より何時間も前かもしれない。ルーターは代替候補を受け取り、policyに照らして資格を認め、next hopを解決し、共有転送オブジェクトに結び付けていた。detectorが主依存を利用不能と判定すると、forwarding planeは少数のポインターを変更した。各destination entryを書き直したわけではない。

これがBGP Prefix Independent Convergenceの狭く正確な意味である。ネットワーク収束の全段階が規模から自由になるという意味ではない。カバーされた障害を検知し、予備状態が既にあるとき、ローカルな転送切替時間を影響プレフィックス数から切り離す設計である。

本稿公開時点でIETFの中心文書はdraft-ietf-rtgwg-bgp-pic-23だ。Informationalを目指す現役のInternet-Draftであり、work in progressである。RFCでも、新しいBGP wire protocolでもない。共有された階層FIB、recursive resolution、事前計算backupを組み合わせる内部アーキテクチャを説明している。

フラットなFIBでは、各prefix leafが転送情報を重複して持つ。50万routeが同じegressへ解決され、その依存が変われば、50万leafの更新が必要になり得る。階層型ではleafが共通のBGP pathlistを参照し、その先にIGP next-hop object、adjacency、label stack、interfaceが続く。

共通分岐を変えれば、依存するleaf全体が新しい道を引き継ぐ。50万個の荷物の宛先を書き直すのではなく、すべてが通る一つの仕分けポイントを切り替えるようなものだ。処理はゼロではないが、荷物ごとには繰り返さない。

したがってprefix independentは境界付きのスケーリング主張である。Failure detectionには時間がかかる。Reflectorは候補を隠し得る。Control planeはwithdraw、selection、advertisementを続ける。遠隔ルーターは別々に収束する。復路は壊れ、予備帯域は不足し得る。PICが除くのは一つのローカル工程におけるプレフィックス数であり、事故全体ではない。

速さはprecomputationで買う。主経路が正常な間に、保護ルーターはpolicy上有効で、reachableで、対象failure domainに対して十分に異なり、forwarding chainへ実装済みのalternateを必要とする。障害時判断の一部は、過去に下された判断である。

監査対象も変わる。通常の障害後選路なら、届いたUPDATE、勝ったattribute、書かれたFIB entryを追える。PICでは休眠中の意図を監査しなければならない。数週間使われなかったbackupが、古いtopology、policy、resource判断のまま起動される可能性がある。

最初の証拠は候補供給だ。DraftはADD-PATH、best-external、diverse-path distribution、VPNで異なるRoute Distinguisherなどを挙げる。いずれも主経路以外を届ける手段になり得るが、同じ保証ではない。

Route reflectionはalternateをPEへ届く前に消せる。ADD-PATH capability表示も十分ではない。send/receive方向、AFI/SAFI、送信側path-set policy、path数、import policy、実際のAdj-RIB-Inが決める。切替を行うルーター上で候補を証明する必要がある。

次は資格である。Nokia SR Linuxの現行文書はEdge PIC候補について、有効でreachable、primaryとは異なるBGP next hopを持つことを求め、通常のBGP Decision Processで最良候補を選ぶ。明確な実装規則だが、独立性の証明書ではない。

二つのnext-hop addressが同じ光ファイバー、line card、transport tunnel、電源室、upstream providerへ再帰することはある。別々のPEが同じservice nodeに依存することもある。論理的差異が同一障害で失われるなら、予備にはならない。

多様性はfailure classごとに宣言すべきだ。別interfaceはport障害を守れてもline-card障害は守れない。同じPE上の第二経路はPE喪失を守らない。同一providerへの二sessionは、商業的にも物理的にも独立とは限らない。

Core PICとEdge PICは修復層を整理する。Core PICではBGP next hopはreachableのままで、そこへ至るIGPやtransport pathが変わる。共有recursive objectが修復点になる。Edge PICではegress next hopの喪失に備え、別の事前計算BGP next hopへ移り、VPN labelやtunnelも変わり得る。

製品間で用語と範囲は一定ではない。Address family、service、software release、ASIC、line cardごとに確認が要る。Draftも効果はBGP protocolではなくforwarding-plane designに結び付くと明記する。

起動権限はdetectorが持つ。物理信号、interface state、IGP adjacency、BGP session、BFDは異なる現象を見る。RFC 5880ではBFD Detection Timeを、交渉されたintervalとmultiplierから各方向で独立に計算する。双方向で同じとは限らない。

画面に「BFD 50 ms」と一つ表示されても、実際の交渉値やどちらが先にdownを宣言するかは分からない。Aggressive timerにはコストもある。Congestion、control-plane starvation、filter、attackで正当なBFD packetが消えると、false downまたはfalse upがDoSを生み得る。少ない欠測に大きな転送変更を許す設定なのである。

Detectorは対象依存を観測しなければならない。Local carrierは直結断を早く知るが、数hop先のblack holeは見ない。Single-hop BFDはadjacencyを測り、遠端service全体は証明しない。Multi-hop probeの道が保護トラフィックと同じかも検証が必要だ。

IGP summarisationも故障を隠す。RFC 9929のUnreachable Prefix Announcementは、summaryに覆われたcomponent prefixが到達不能になってもsummaryが残る問題を扱い、BGP PICのようなfast-convergence use caseに触れる。UPAを全網へ義務付ける話ではない。decision pointから見えない故障は修復できないという境界である。

ハードウェア階層も制約になる。Draftは複数レベルのindirectionを想定する。階層が浅いplatformはプログラム時にchainをflattenし、状態を複製する場合がある。Packet lookupは減ってもFIB memoryを使い、sharingやECMP、PICの性質が弱くなり、故障時にper-prefix workが戻り得る。

同じprimaryとbackupを表示する二台が同じ速度で切り替わるとは限らない。一台は共有pathlistを変更し、もう一台は大量のflat entriesを書き換える。Chassis全体のfeature表示ではなく、line card、ASIC、release、route family、encapsulationごとに測定すべきである。

L3VPNではalternate egressが別VPN labelを必要とし、その下にLDPやSegment Routingのstackがある。Next hopだけ正しく変わりlabelが古ければ、速く誤転送する。検証は最終adjacencyと実際のencapsulationまで追う。

事前計算stateは老朽化する。Import policy、route withdrawal、recursive resolution、label、部分的reachability、hardware resource pressureによって不適格になり得る。最も危険なのは消えたbackupではなく、依然readyと表示される古いbackupだ。

Candidate受信時刻、eligibility再計算、FIB programming、根拠となるtopology/policy epochを記録する。関連する変更後はstandby chainを再検証する。RIBに存在することと、現在使えることは別だ。

Capacityも認可条件である。Loop-freeでreachableでも、保護負荷を運べないpathは失敗する。多数のprimaryが一つのstandbyを共有すれば、一障害で巨大なaggregateが集中する。同時障害では別々に妥当なbackupsが衝突する。Transitやpeering契約に反する技術的候補もあり得る。

RFC 5714は時間軸を分ける。Fast rerouteは検知後にlocal repairを起動し、その間もdistributed routingが障害を広めて最終状態へ収束する。Repairは橋であって、最終経路とは限らない。

少なくとも六つの時計を測るべきだ。Detection、event delivery、FIB activation、最初の成功packet、control-plane convergence、最終steady-state FIBである。一つの「収束時間」では責任もdeliveryも分からない。

Data-plane probeで切替前後のinterface、next hop、label stackを記録する。復路も独立に試験する。Stateful firewall、NAT、service chainは、往路が正しく切り替わってもsessionを維持できないことがある。

試験にはlocal link、remote transport、egress PE、BGP session、BFDの遅延・誤判定、backup先行withdraw、policy変更、FIB resource枯渇、line-card restart、primary復帰を含める。各scenarioで、発火detector、変更object、期待backup、許容loss、最終stateを事前に定める。

False positiveは巨大なprefix setを高速に使えない経路へ送る。False negativeはbackup未実装やtrigger誤接続のまま、保護があるように見せる。共有状態は効率の源であると同時に、誤りの増幅器だ。

そこで選択と認証を分ける。Routing ownerが候補policyを定め、transport ownerがfailure-domain separationを証明し、platform ownerが実機FIBを示し、service ownerがcapacityとbidirectionalityを試す。独立reviewerが拡大を認可する。

運用成果物の第一はprotection matrixである。Failure class、route family、platform、serviceごとに、primary dependency、candidate source、backup、diversity evidence、detector、timer、hardware object、capacity、ownerを記す。

第二はdormant-state ledgerで、RIB上だけのbackupとhardware内のbackupを区別する。第三はdetector event、pathlist change、observed packetを結ぶtimed traceで、repairから安定収束への移行も含める。

Primary復帰も制御が要る。即時に戻すとreordering、oscillation、二度目のlossを招く。Hold-down、観察期間、承認付きrevertが必要な場合がある。RollbackはPICを切ることではなく、証明された安定状態へ戻すことだ。

Lu Hengのminimum initial specificationはこの仕組みに合う。共有mechanismを狭く保ち、適用route family、platform、failure class、timerはoperatorが現地事情で選ぶ。Running-code primacyは証拠順を決める。Config、RIB、FIBは主張であり、最終的にpacketが結果を示す。

Practical data sovereigntyとは、proprietary hardware内のstandby decisionを照会、試験、失効、交換、撤回できることである。Config repositoryを所有していても、休眠状態を見られなければ象徴的な支配にすぎない。

BGP PICは緊急時の仕事を平時へ移す。統治可能にするには、証拠も同じ時点へ移さなければならない。Backupの由来、独立性、trigger、hardware realization、capacity、expiryは、警報より前に知られているべきだ。

情報源