要約

  • RFC 5185では、遠端が隣接をpoint-to-pointとして扱えば、両端が同じmulti-area設定を持たなくても互換性を保てる。これはプロトコル上の柔軟性であり、運用上の同一表現を保証しない。
  • 障害対応には、双方のRouter ID、Area ID、隣接名、インターフェース、回線、容量、共有リスクを結ぶ証拠が必要である。複数のFULL状態は複数の物理経路を意味しない。

片側の担当者は「Area 1のmulti-area adjacencyが落ちた」と報告した。反対側の担当者は、その名前の隣接は存在しないと答えた。相手の装置には通常のpoint-to-point関係として表示されていたからである。

両者のOSPFは正常だった。障害は一つの回線で起き、異なる表現を持つ複数の隣接が同時に消えた。難しかったのは収束ではなく、二つの正しいローカル説明を一つの物理事実へ結び直すことだった。

相互運用性は表現の一致ではない

RFC 5185は2008年5月のStandards Track文書である。高速なbackboneリンクを別エリアでもintra-area経路として利用するため、共通インターフェース上にエリア別の隣接を追加する。

遠端はその隣接をpoint-to-pointとしてモデル化すればよく、同一のmulti-area構成を必須とはしない。文書は、トポロジー表現とトラブルシューティングを容易にするため対称構成を推奨する。つまり非対称は違反ではないが、説明コストを持つ。

自発的採用を支える良い設計でもある。一方が拡張を導入するために、相手の内部データモデルまで統一する必要はない。ただし運用システムが片側の名称だけをグローバルな真実として使えば、柔軟性が断絶へ変わる。

一つの媒体に複数の状態機械

追加隣接ごとにOSPF interface data structureが作られ、下位媒体のnetwork typeにかかわらずpoint-to-pointとして動く。interface FSMもpoint-to-pointであり、neighbor structureとneighbor FSMは標準OSPFのままである。primary adjacencyはRFC 2328どおり継続する。

物理point-to-pointなら隣接アドレスを個別設定する必要はない。その他のnetwork typeでは、相手アドレスを設定するかOSPF外の仕組みで発見し、制御パケットをunicastする。Area IDが受信パケットを各隣接へ振り分ける。

FULLに達すると、そのエリアのRouter-LSAへtype 1 linkとして追加される。Link IDは遠端Router ID、Link Dataは隣接IP、unnumberedならIfIndexである。通常のnumbered point-to-pointに伴うtype 3 linkは追加されない。

各状態は実在する。しかしそれらが同じport、line card、carrier circuitを使うなら、物理障害は同時に届く。ソフトウェア上の独立性はshared fateを消さない。

ルート改善が依存を集中させる

この拡張が必要になった理由はOSPFの優先順位にある。別エリアの遅いintra-area経路は、高速backboneリンクを使うinter-area経路より優先され得る。追加隣接は高速リンクをそのエリアのintra-area経路にする。

結果として経路は改善できるが、トラフィックは共通回線へ集中する。変更の成功判定には隣接状態だけでなく、前後のLSDB、SPF、RIB、FIB、利用率、損失、代替経路容量が必要である。

RFC 6987のstub-router advertisementやRFC 9355のreverse metricは経路選択を変えられる。それでもケーブルは増えない。maintenanceでmetricを変更した後、本当に転送が抜けたかはcounterとpathで確かめる。

容量は物理IDで一度だけ数える

RFC 3630のTE metric、maximum bandwidth、maximum reservable bandwidth、unreserved bandwidth、administrative groupはリンク資源の属性である。同じ100 Gb/s回線を三つのエリアedgeが参照しても300 Gb/sにはならない。

必要なのはphysical resource IDである。local interface、line card、LAG member、circuit、provider order、conduit、shared-risk groupをそのIDへ結ぶ。primaryと追加隣接はconsumerとして参照する。論理状態は別々に監視し、容量合計は親資源でdeduplicateする。

Heng Luのreality layersで言えば、Router-LSAのedgeは実行可能な記号層であり、optic、回線とpacket forwardingは別の現実層である。両層を明示的にjoinしなければ、グラフの複数性が資源の複数性へ誤変換される。

実行時に選ばせてはいけない曖昧性

受信Area IDは通常、対応するmulti-area adjacencyを選ぶ。backbone packetはvirtual linkにもmulti-area adjacencyにも該当し得るため、双方に同時一致する構成はconfiguration errorとして作成時に処理する。

これは運用にも使える原則である。二つの解釈が同じpacketを所有できるなら、到着順で選ばない。二つのedgeが同じcircuitか判断できないなら、独立だと仮定してcapacityを計上しない。不明は冗長性ではない。

OSPFv3は住所を増やさずedgeを作る

OSPFv3のRouter-LSAはaddress semanticsから独立している。RFC 5185はmulti-area adjacencyのprefixをintra-area-prefix-LSAへ載せず、link-LSAも広告すべきでないとする。neighborのIPv6 link-local addressはHello headerから得られる。

したがってtopology edgeに対応する新しいaddress objectがないことは欠陥ではない。住所台帳、OSPF topology、物理資源を別々に保存し、証拠のあるキーで結ぶ必要がある。

二つの説明を一つの障害へ戻す記録

最低限、change ID、topology snapshot、双方のRouter IDとABR role、software build、local interface、neighbor addressと発見元、primaryと追加隣接、Area ID、network type、FSM時刻、Router-LSAのLink ID・Link Data・metric、type 3の不在、OSPFv3挙動、回線・カード・provider、LSDB・SPF・RIB・FIB、物理容量、利用率、shared risk、構成対称性、virtual-link検査、drainとrollbackを保持する。

RFC 5185はローカルな将来判断の余地を残す。双方の表現を無理に一つへ正規化する必要はない。必要なのは、違う表現が同じ稼働資源を指すと証明できることだ。running codeを優先するとは、名称を捨てることではなく、名称の権限を観測された実体までに限定することである。

情報源

  1. RFC 5185 HTML
  2. RFC 5185 text
  3. RFC Editor情報
  4. IETF Datatracker文書
  5. IETF Datatracker履歴
  6. IETF Datatracker参照
  7. RFC 5185 errata
  8. RFC 2328 OSPFv2
  9. RFC 2328情報
  10. RFC 5340 OSPF for IPv6
  11. RFC 5340情報
  12. RFC 3630 Traffic Engineering
  13. RFC 6987 Stub Router
  14. RFC 7770 Optional Capabilities
  15. RFC 8665 Segment Routing
  16. RFC 9355 Reverse Metric
  17. RFC 3137 Stub Router
  18. Heng Lu：現実の層
  19. Heng Lu：最小仕様と自発的採用
  20. Heng Lu：稼働コードの優先