要約

  • RFC 2918では、協議済みAFI/SAFIについて、対応peerの現在のAdj-RIB-Outを再広告するよう依頼できる。相手のoutbound policyは相手に残る。
  • RFC 7313はBoRRとEoRRで完全な再広告を囲み、旧経路をstaleにし、戻った経路を置換し、戻らない経路を終了時に除去する。
  • command成功やsession継続だけでは不十分であり、prefix、attribute、選択、FIB、trafficの差を確認する必要がある。

誤って二百prefixを拒否したinbound filterを修正したとする。commitは通った。それでも、未加工のUPDATEを保存していなければ、新ルールへ渡す入力がない。設定だけが新しく、RIBは旧判断のままになり得る。

拒否を増やす変更でも同じだ。既に採用した経路を再びpolicyへ入れなければ、repositoryの意図とrunning stateは一致しない。

従来のinbound soft reconfigurationは、拒否分を含む全受信広告の未加工copyを保持した。再評価を本地だけで行える代わりに、まれな変更のために常時memoryと処理を支払う。

RFC 2918はstateの置き場所を変える。Route Refresh Capability code 2を広告したspeakerは、ROUTE-REFRESHを受け取って処理できると示す。requesterはpeerからそのcapabilityを受信した後に限り、sessionで協議したAFI/SAFIを指定して送信できる。

peerは現在のoutbound filtering policyに従って、その隣接者向けAdj-RIB-Outを再広告する。requesterは遠隔databaseを読まず、filter済みrouteを強制できない。相手が今この関係へ出す情報を、もう一度聞く仕組みである。

従ってarchive replayではない。昨日のrouteはwithdrawされたかもしれず、remote policyやbest pathが変わったかもしれない。昨日なかったrouteが今日は出ることもある。結果は両ASの現在のpolicyが交差したものだ。

countだけでは因果を説明できない。refresh後に五百減っても、新import、remote withdraw、remote export変更を区別できない。exact prefix、attribute、timestampが必要である。

基本RFC 2918には完全なreplayの開始・終了境界がなかった。通常UPDATEが混ざり、まだ来ていないrouteと消えたrouteを途中で区別しにくい。

RFC 7313のEnhanced Route Refresh code 70は、subtype 1をBoRR、subtype 2をEoRRと定める。BoRRを受信すると、そのpeerとAFI/SAFIのrouteをstaleにする。再広告されたrouteが置換し、EoRRで残存staleを削除する。

networkはreplay中も変化する。operation開始時のAdj-RIB-Outを概念的な全体としつつ、変化したentryは新状態で送られる。EoRRはepoch完了を示すが、個々のrouteの正しさや歴史再現を証明しない。

receiverはstale保持の本地上限を設定できる。EoRRが永遠に来ないとき旧reachabilityを残さないためだが、短すぎるtimerは遅い正常refreshの途中でrouteを消す。

EoRRとGraceful RestartのEnd-of-RIBは別物である。前者は再広告epoch、後者はcontrol plane restart時の継続を扱う。RFC 7313はpremature cleanupを防ぐ順序を定める。

inbound softとoutbound softも所有者が違う。inboundではpeerに再送を依頼するかlocal copyを使う。outboundでは自分の広告を再生成する。同じsoftという語がdependencyを隠す。

Ciscoのdocumentationでは、capabilityがあればdynamic inbound request、なければ保存済みcopy、どちらもなければsession hard resetが候補になる。最後は関係全体のrouteを一度失う。

これはresourceとsovereigntyの交換である。raw input保存はmemoryで独立性を買う。Route Refreshは常設memoryを減らすがpeerの能力、応答、現在のexportに依存する。hard resetはblast radiusをsession全体へ広げる。

FRRoutingは、拒否routeまで数えるmaximum-prefixの一部動作など、保存が引き続き必要な場合を示す。現在のstreamを再取得できることは、別のcontrolが必要とする履歴inventoryとは同じでない。

RFC 5291のOutbound Route Filteringは別に協議するcapabilityである。receiverのfilter情報をsenderへ渡せるが、通常refreshがremote policy editorになるわけではない。

証拠はchange前から集める。方向別、AFI/SAFI別にbasic/enhanced capabilityのadvertisedとreceivedを分ける。local supportだけではpeer responseを証明せず、basic supportだけではBoRR/EoRRを証明しない。

baselineにはexact prefix/attribute、accepted set、best path、policy version、session uptime、FIB next hopを含める。rejected inputが見えないなら、そのblind spotを明記する。

最初は一つのpeerとAFI/SAFIに限定する。request、BoRR、EoRR、durationを記録し、missing EoRR、stale timeout、control-plane load、unexpected reset、withdraw、best-path changeを監視する。

集合を比較する。十件減って十件増えればcountは同じである。aggregateがmore-specific群へ変わればcountは増える。同じNLRIでもcommunity変更でpolicy resultが変わる。

最後にforwardingを見る。accepted routeがbestにならない、next hopがresolveしない、選択先linkのcapacityが足りないことがある。Route Refreshはinputを提供するだけでpacket deliveryを証明しない。

rollbackもreplayを要する。旧policy fileを戻すだけではroute decisionは戻らない。期間中にremote exportが変われば、開始時stateの完全再現はできない。

automationはconcurrencyを制限する。大量peerとfamilyへの同時requestはUPDATEと再計算を発生させる。softはsessionを意図的に壊さないという意味で、control-plane workがないという意味ではない。

Heng Luのminimum initial specificationは、peer、family、requestという小さな共有mechanismに現れる。各ASはpolicyを保持する。running-code primacyでは、capability、観測epoch、RIB diff、FIB resultがcommand成功より強い。

Route Refreshはpolicy修正とsession破壊を分離するが、修正と証拠は分離しない。peerが再び語った後、戻ったrouteとforwardingの変化だけが新policyの実効権限を示す。

Sources