ナレッジセンター
匠コラム

ハイパースケール環境で磨かれるルーティングプロトコル～RIFT～

匠コラム: ネットワーク; データセンター

2020.03.10

ビジネス開発本部
第3応用技術部第3チーム
平河内竜樹

現在、ハイパースケールやクラウドスケールなどと表現されるデータセンターのネットワーク要求に応える形で、様々なルーティングプロトコル仕様が提案されています。今回はその中の一つである「RIFT」に着目し、その特徴について検証データを交えて紹介します。

RIFT：はじめに

RIFT(Routing In Fat Trees)は、既存のIGPやBGPの拡張ではなく新規に定義されたルーティングプロトコルで、その名の通りClosおよびそのバリエーションに相当するfat-tree（□□）トポロジに最適化されています。levelの概念を有し、上り方向（Northbound）と下り方向（Southbound）で異なるパス計算を行う点が特徴的です（図1）。

図1：RIFT概要の図（引用：draft-ietf-rift-applicability-00）

levelは値が小さいほどtreeの端に近づきます。なお、構成に応じてリーフとなるノードのlevelが0でないことはある一方、levelが0のノードは常にリーフとなります。RIFTは現在IETFのRIFT WGでStandards Trackの技術として標準化が進められており、仕様は2020年2月時点でdraft-ietf-rift-rift-10が最新のものです。この中でRIFTはトランスポートにUDPが想定されており、利用されるポート番号として後述するLIEの交換では914、TIEの交換では915が提示されています。なお本稿では仕様情報を確認する際、後述する検証環境の実装でリファレンスとして挙げられているdraft-ietf-rift-rift-09（□）を参照して行います。公開されているRIFTの技術情報については末尾にURLを記載しており、必要に応じてこちらもご参照頂ければと思います。本稿でも検証データを紹介する前段階として、以下よりRIFTの技術的な特徴について取り上げます。

RIFTでは、以前のコラムで挙げられていたフラッディングに関する問題への対策としてフラッディングの部分的な排除および最適化が行われ、従来のIGPと比較してスケーラビリティの向上が実現されています。具体的には、上り方向に流れネクストホップが下りに向く経路は、リンクステート情報に基づいて個別経路が算出されるものの、代表してフラッディングを実行するFR(Flood Repeater)（別名Flood Leader）の選出により従来のリンクステート型IGPと比較して量が削減されます【flood reduction】。また、下り方向に流れネクストホップが上りに向く経路にはデフォルトルートが利用され、下り方向への個別経路の配送は必要となりません。なお経路集約に関しては、個別のステートを勘定できなくなるため障害時にsuboptimal routingやブラックホールを誘発する原因となりますが、RIFTでは障害時に限定して迂回に必要な個別経路を必要な箇所にだけ配送することによってこの問題に対処しています【automatic disaggregation】。

デフォルトルートの利用に関連して、RIFTではFIBサイズの圧縮を期待できます。RIFTの基本的な動作として上位に向かう通信はデフォルトルートによって転送されるため、全ての個別経路を保持するノードは最上位のみとなり、またノードが下位に向かうほどデフォルトルートによって集約される対象は拡大します。また、RIFTの情報交換はNeighbor Discovery（LIE Exchange）とTopology Exchange（TIE Exchange）から構成され、パス計算に利用されるTIE(Topology Information Elements)はNorthboundとSouthboundが区別されて交換されます。これに合わせて、パス計算機能もNorthboundとSouthboundに分かれています。とりわけ最下位に配置されるノードは、直接接続ではない宛先に対する通信は基本的に上り方向のデフォルトルートによって転送され、また下り方向のパス計算を行う機会がありません。RIFTでは最下位で不要となる機能を省略した実装【Leaf-Only Implementation】が想定されており、その際には実装の簡素化やリソース消費の低減が期待できます。これは特に収容対象のサーバをIP Fabricの一部として構成する場合において利点に映ると考えられます。

また、プロトコルとして必要なパラメータの自動化機構が定められており、これがRIFTにおけるZTP(Zero Touch Provisioning)機能に相当します。RIFTで考慮が必要なlevelの値はLIE(Link Information Elements) Exchangeの過程で自動決定が可能であり【Automatic Level Derivation】、ノードを識別する情報の自動生成にも対応しています【Automatic SystemID Selection】。RIFTにおけるコントロールプレーンのトランスポートにはIPv4もしくはIPv6が利用され、RFC5549の様にIPv6ネットワーク上でIPv4 Prefixを直接広報することも可能です（□□）。リンクにはlink-localアドレスの適用も想定されており、トランジットリンクに対するアドレス設計を省略した構成が実現できます。実装としての初期状態に依存しますが、最上位以外に配置されるノードはzero configurationで動作可能な素地があります。ZTP機能を利用した際も最上位に位置するノードのレベル定義は必要となりますし、OAMまで考慮するとIPアドレスの排除が常に適切であるとは限りませんが、選択肢としてノードおよびリンク固有の情報指定を排して構成可能な点はRIFTの特徴として挙げることができます。

なおRIFTではlevelの概念により、対象のトポロジを崩す隣接関係の構築は許容されず、これはミスケーブリングの検出機構として機能します。またPoD(Point of Delivery)の概念をサポートしており、PoD番号もLIEにエンコーディングされミスケーブリングの判断材料として利用されます。図2はRIFT I-Dの“4.2.2. Link (Neighbor) Discovery (LIE Exchange)”から引用した記述で、隣接関係を構築するためにはこの条件を満たす必要があります。

図2：隣接関係が構築される条件（引用：draft-ietf-rift-rift-09）

図3は本節で挙げたRIFTの機能とその効用を整理したものです。

図3：RIFTの代表的な機能と価値

補足としてRIFTでは、デフォルトルートを活用したfat-treeネットワークが実現される一方、トポロジに関してはtreeにおける同一レベルのノード同士を接続するリンク（East-West LinkおよびLeaf shortcuts）の利用もオプションとして許容されています（□）。East-West Linkの用途としては、サービス停止時間を極小化するためのローカルリペアが挙げられます。経路に関しては、最上位からのデフォルトルート生成元の移行や、伝送路特定のため平常時に下り方向へ個別経路を配送することも想定されています。さらに、モビリティのサポートやBFDの自動構成・等コストではないマルチパスの自動計算など環境に応じて有用となる動作が定められている他、Segment RoutingやMulticastといった新たな機能を追加するための仕様も存在しています（図4）。この中には改版の過程で基本仕様から切り出されたものもあります。このようにRIFTは多くの要素で構成され、段階的な具体化および実装が行われています。とりわけ発展的な機能は後から実装される傾向にあると考えられるため、必要とする機能が利用可能であるかは留意すべき点となります。

図4：本稿作成時にInternet-Draft ArchiveをRIFTで検索した結果

基本的な事項となりますが、RIFTはIP Fabricの構築に適したルーティングプロトコルであり、ベースの仕様としてはIPv4 / IPv6ユニキャストの接続性を提供する技術です。サブネット内通信に対するホストルートの生成機構の利用など、要求によってはプロトコルの追加無しで対応可能な範囲もありますが、例えばマルチテナントの要求がある場合などはオーバーレイ技術の併用が必要なケースとなります。RIFTはKey-Value の配送機構を有しその用途にはオーバーレイのプロビジョニングも例に挙げられていますが（□）、現時点でそれを実現するための具体的な仕様や実装は見当たらず、現状RIFT環境でオーバーレイ技術を併用する際には要求に応じて対応するシグナリングおよび設定が追加で必要となります。

RIFT：試験の環境と結果

ここからはトランスポートネットワークにIPv6とRIFTを利用した際の検証データを紹介します。今回は試験環境にJuniper Network社のvMXを用い、サービスとしてはIPv4の接続性のみを提供する形態としました。本試験ではJunos OS 19.4R1.10と同時期にリリースされたRIFT packageを利用しています。以下の図5は試験の構成図、表1・表2は設定の抜粋となります。なお今回の環境では試験の都合上トランスポートのインタフェースに対してVLANの設定をさらに行っており、こちらの設定を行った場合のサポート可否については確認を行っていない点にご留意頂ければと思います。

表1：設定の抜粋（トランスポート）

Core-01 / Core-02

set interfaces interface-range RIFT-INTERFACES member "ge-0/0/[0-3]"

set interfaces interface-range RIFT-INTERFACES unit 0 family inet

set interfaces interface-range RIFT-INTERFACES unit 0 family inet6

set policy-options policy-statement LB then load-balance per-packet

set routing-options forwarding-table export LB

set protocols rift node-id auto

set protocols rift level top-of-fabric

set protocols rift lie-receive-address family inet6 ff02::a1f7

set protocols rift interface RIFT-INTERFACES lie-transmit-address family inet6 ff02::a1f7

Core-100 / Core-105 / Core-200 / Core-205

set interfaces interface-range RIFT-INTERFACES unit 0 family inet

set interfaces interface-range RIFT-INTERFACES unit 0 family inet6

set policy-options policy-statement LB then load-balance per-packet

set routing-options forwarding-table export LB

set protocols rift node-id auto

set protocols rift level auto

set protocols rift lie-receive-address family inet6 ff02::a1f7

set protocols rift interface RIFT-INTERFACES lie-transmit-address family inet6 ff02::a1f7

Edge-10 / Edge-20

set interfaces interface-range RIFT-INTERFACES member "ge-0/0/[0-1]"

set interfaces interface-range RIFT-INTERFACES unit 0 family inet

set interfaces interface-range RIFT-INTERFACES unit 0 family inet6

set policy-options policy-statement LB then load-balance per-packet

set routing-options forwarding-table export LB

set protocols rift node-id auto

set protocols rift level auto

set protocols rift lie-receive-address family inet6 ff02::a1f7

set protocols rift interface RIFT-INTERFACES lie-transmit-address family inet6 ff02::a1f7

表2：設定の抜粋（サービス）

Edge-10

set interfaces ge-0/0/2 vlan-tagging

set interfaces ge-0/0/2 unit 0 vlan-id 2

set interfaces ge-0/0/2 unit 0 family inet address 10.68.2.1/24

set policy-options policy-statement RIFT-EXPORT term 1 from protocol direct

set policy-options policy-statement RIFT-EXPORT term 1 from route-filter 10.0.0.0/8 prefix-length-range /24-/32

set policy-options policy-statement RIFT-EXPORT term 1 then accept

set policy-options policy-statement RIFT-EXPORT term 3 then reject

set protocols rift export northbound RIFT-EXPORT

Edge-20

set interfaces ge-0/0/2 vlan-tagging

set interfaces ge-0/0/2 unit 0 vlan-id 3

set interfaces ge-0/0/2 unit 0 family inet address 10.68.3.1/24

set policy-options policy-statement RIFT-EXPORT term 1 from protocol direct

set policy-options policy-statement RIFT-EXPORT term 1 from route-filter 10.0.0.0/8 prefix-length-range /24-/32

set policy-options policy-statement RIFT-EXPORT term 1 then accept

set policy-options policy-statement RIFT-EXPORT term 3 then reject

set protocols rift export northbound RIFT-EXPORT

図5：試験の構成図

最初に、対象のネットワークがIPv4サブネット間の接続性を提供できるかという点を確認します。表1・表2の設定を行ったところ、各リーフノードに存在するホスト収容想定のセグメント（図5中のVLAN 2およびVLAN 3）に対する経路が自身の上位となるノードでルーティングテーブルにインストールされ、また宛先に対して複数のネクストホップが存在する箇所はECMPとして有効になりました。また各ノードでネクストホップが上りに向く経路はデフォルトルートのみが存在し、個別経路のネクストホップは全て下りに向く状態となりました。図6はこの状態における各ノードのCLI出力結果になります。

図6：試験環境におけるルーティングテーブルの出力（平常時）

この状態で各リーフノードのホスト収容インタフェース配下に存在するテスター間でIPv4のpingを複数回実行したところ、いずれも成功が確認できました。図7はそのキャプチャ結果になります。

図7：ICMP Echoの転送（行きと戻りのパスはそれぞれVLAN IDを参照）

図5中のVLAN 2からVLAN 3への通信に着目すると、フローによって異なるノードを経由している様子が伺えます。これよりRIFTによって構築されたFabricは、マルチパスの伝送が可能であり、フローベースで分散されることが確認できました。また表1で示される様に、本構成ではトランジットリンクに対してIPアドレスが設定されていない状態となります。他に注視すべき設定内容として最上位のノードを除いてlevelの指定が行われていない点、ノードIDに相当する固有の情報が指定されていない点も挙げられ、RIFTではノードおよびトランジットリンク単位で固有の情報指定を省略した状態でサービス提供可能となることが確認できました。結果として、最上位に位置するノードにおけるlevelの値と、各levelで異なるRIFTを有効にするインタフェースの組み合わせを除いて、トランスポートに関する設定は同一のものになりました。対象のインタフェースに関しては個別指定が無い限りRIFTを有効にするといった方針によって、levelを跨いで共通化することも可能です。

またRIFTではIS-ISと同じ名称となるoverload bitが存在し、例えばメンテナンス作業に際しトラフィックの迂回を行う場面で活用することができます。次に行う試験では、まず各方向に1種類ずつのフローを双方向で印加してパケットキャプチャで伝送路を確認し、改めて10ppsのレートでトラフィックを印加した後に、図5中のlevel 23となるノードのうちテスター間の通信が実際に伝送されるノードの1台でoverload bitを有効にしました。図8は有効にした後の経路状態で、パケットキャプチャの結果からもこの通りに転送されていることを確認しています。図8の経路状態とoverload bit設定前の図6を比較すると、隣接するノードが有する経路表のネクストホップからoverload bitの設定を行ったノードが切り離され、そうでないノードはマルチパスが維持されていることが窺えます。また、キャプチャ結果からパケットの損失数を確認したところ結果はどちらの方向も値はゼロであり、これはoverload bitの解除に伴う伝送路の復旧においても同様でした。今回の試験環境で観測された値となりますがoverload bitの利用によって、迂回の動作は可能であったことと、少なくともおよそ100ミリ秒未満で迂回・復旧可能なパターンは存在することが確認できました。

図8：試験環境におけるルーティングテーブルの出力（Core-100でのoverload bit設定時）

最後に障害想定のイベントを発生させ、経路状態にどのような変化があるか観察しました。まずトラフィックの印加をoverload bitの試験と同様の手順で行います。その後、図5中のlevel 24となるノードのうちテスター間の通信が実際に伝送されるノード上でVLAN 3宛の転送の際に出力され得る二つのインタフェースに対しシャットダウンを実行しました。図9はシャットダウン操作を行った後の各ノードの経路状態、図10はそのシャットダウン実行前後のパケットキャプチャ結果です。

図9：試験環境におけるルーティングテーブルの出力（Core-01でのge-0/0/2およびge-0/0/3インタフェースのシャットダウン後）

図10：試験環境におけるパケットキャプチャ結果

図10のキャプチャ結果を参照すると、転送される通信は一瞬疎通性が失われた後、再び同じホップ数で疎通する様になっていることが窺えます。また図9の経路状態をシャットダウン実行前の図6と比較すると、Core-100ではこれまで確認されなかった上り方向の個別経路が出力されており、対象トラフィックの転送にはデフォルトルートではなく個別経路が利用されるようになっていることが窺えます。併せて、この経路はEdge-10には出力されておらず、個別経路の影響範囲は迂回で必要となる箇所に限定される結果となりました。なおシャットダウンを無効にする操作を実施した後には、この個別経路は経路表から削除され、伝送路もシャットダウン実行前に戻ることを確認しています。

RIFT：補足

RIFTはプロトコルとしてnode nameやadjacency nameの情報を共有できます。今回の試験環境では設定で指定可能なノード名にインタフェース名を組み合わせた文字列がLIEで交換され、その値が隣接関係を確認するコマンドの中で出力されることを試験の過程で確認しています。図11は別途ノード名を指定した際の出力結果です。System IDの値がノードの特徴と無関係である場合も、このような情報が出力されていれば、それだけ状態把握が容易になります。

図11：name指定の前（上）と後（下）

RIFTでは、受け取ったフラッディングを伝播する役割を担うFR(Flood Repeater)の選出が行われ、FRの数は冗長性の観点で2もしくはそれ以上の数が推奨とされています（□）。今回の試験環境では、上り方向へフラッディングを伝播しないノードが発生せず、flood reduction機能が有効であってもその効果は得られないことになります。なお、対象とするTIEのフラッディングが下り方向に行われないことは基本動作の上で保証されており（□）、試験の準備過程でEdge-10のホスト収容インタフェースに対するリンクダウンに伴い発生したTIEがEdge-20まで到達しないことを確認しています。

以下の図12は、今回の試験過程で、ネクストホップのIPv6アドレスに対してpingを実行した結果になります。これより、隣接ノードとの疎通確認手段としてIPv6 LLAに対するpingを利用できることが確認できました。

図12：LLAを利用したリンクの正常性確認

また今回の試験環境では、トランジットノードにIPv4アドレスが存在しない状態となっています。この状態でリーフ配下のホストからIPv4のtracerouteを実行した場合、経由したノードから応答が得られない現象の発生を試験の準備段階で確認しています。これは応答に必要なIPv4アドレスが存在しないことから期待された動作であると考えられ、この点に関しては、中継ノードのループバックインタフェースにIPv4アドレスを追加することで応答が得られるようになっていました。この場合、さらにpingの宛先として利用する場合などを想定すると、ループバックのアドレスに対し下り方向にも個別経路の広報が必要となります（□）。

なお、今回の試験環境に対してIPv6をサービスとして追加した際のIPv6のtracerouteに関しては、GUA / ULAが設定されていないノードからも、応答が得られることを別途確認しています。図13はリーフノードのループバックインタフェースに設定されたIPv6アドレス間でIPv6のtracerouteを実行した結果となり、出力されるホップ数と実際の経由ノード数が等しいことが窺えます。RIFTに限定されない内容となりますが、出力されるLLAの値からトポロジを推定できる様にアドレッシングを行うことができれば、トランジットネットワークには自動設定されたアドレスのみを用いる環境でもtracerouteなどを活用することが可能になります。

図13：トランジットノードがLLAのみで構成される環境のIPv6 traceroute出力

今回のまとめ

3 -levelのfat-treeを想定したトポロジにJunos OS 19.4R1とRIFT packageを適用して試験を行った結果、基本的なIPの到達性と共に、以下の内容を確認することができました。

デフォルトルートによって集約が行われたECMP構成の実現
ノードおよびトランジットリンクに対する固有アドレッシングの省略
障害想定のイベントに対する最短ホップ転送の維持と必要最低限のパス変更
計画停止を想定したトランジットノードの離脱操作

執筆者プロフィール

平河内竜樹
ネットワンシステムズ株式会社ビジネス開発本部
第3応用技術部第3チーム
所属

ルータ分野を核とした新旧技術の調査・検証と共に、エンタープライズ・パブリック・サービスプロバイダのネットワーク提案および導入を支援する業務に、10年以上にわたり従事

CCIE RS
CCIE SP

Webからのお問い合わせはこちらから

お問い合わせ窓口へ

ナレッジセンターを検索する

電子カタログ

ハイパースケール環境で磨かれるルーティングプロトコル～RIFT～

RIFT：はじめに

RIFT：試験の環境と結果

RIFT：補足

今回のまとめ

関連記事

執筆者プロフィール

ナレッジセンターを検索する