SRv6によるTraffic Engineering + vxlan

今回はIPネットワークにおけるTraffic Engineering（以下、TE）の実現手法という視点でSRv6に着目します。試験環境としてLinux kernel 4.10を用意しSRv6によるトラフィックステアリングの動作確認を行いました。

まず、試験項目と結果のサマリは以下になります。

図1：今回の試験項目と結果のサマリ

今回想定した試験項目に対しては、全て期待通りに動作することが確認できました。

なお本試験においては、いずれのノードにおいてもMPLSは有効になっていないことを改めて確認しており、Pure IPの環境で試験項目の要求が実現された結果となりました。またSRv6 SIDの交換で必要となったプロトコルは通常のIPv6 Unicast用のものであり、一部の区間においてはStaticでデフォルトルートを設定している点も含め、SRv6では必要な箇所で必要なIPv6経路が保持されれば到達性を確保できることの示唆と言えます。

以降では各証項目の結果について、少し掘り下げて紹介したいと思います。試験の構成図（図2）SRv6設定前の経路状態（図3）およびそれぞれの項目に対し追加で投入したiproute2コマンド（表1）は以下の通りです。

図2：今回の試験構成図図3：平常時の経路状態

表1：各試験項目で追加した設定

項目[1][2] ： Edge-10

ip -6 route add 2001:db8::20/128 encap seg6 mode inline segs 2001:db8::2,fc00:2205::20 dev bond0.1100
        

項目[3][4] ： Edge-10

ip link add vxlan5003 type vxlan id 5003 dstport 4789 local 2001:db8:1100::13 remote 2001:db8::23
        ip link set vxlan5003 up
        ip link set dev vxlan5003 address 00:00:00:50:03:10
        ip address add 10.50.3.10/24 dev vxlan5003
        ip link add vxlan5004 type vxlan id 5004 dstport 4789 local 2001:db8:1100::14 remote 2001:db8::24
        ip link set vxlan5004 up
        ip link set dev vxlan5004 address 00:00:00:50:04:10
        ip address add 10.50.4.10/24 dev vxlan5004
        ip link add vxlan5044 type vxlan id 5044 dstport 4789 local 2001:db8:1100::14 remote 2001:db8::24
        ip link set vxlan5044 up
        ip link set dev vxlan5044 address 00:00:00:50:44:10
        ip address add 10.50.44.10/24 dev vxlan5044
        ip -6 route add 2001:db8::24/128 encap seg6 mode encap segs 2001:db8::2,fc00:2200::20 dev bond0.1100
        ip sr tunsrc set 2001:db8:1100::14
        

項目[3][4] ： Edge-20

ip link add vxlan5003 type vxlan id 5003 dstport 4789 local 2001:db8::23 remote 2001:db8:1100::13
        ip link set vxlan5003 up
        ip link set dev vxlan5003 address 00:00:00:50:03:20
        ip address add 10.50.3.20/24 dev vxlan5003
        ip link add vxlan5004 type vxlan id 5004 dstport 4789 local 2001:db8::24 remote 2001:db8:1100::14
        ip link set vxlan5004 up
        ip link set dev vxlan5004 address 00:00:00:50:04:20
        ip address add 10.50.4.20/24 dev vxlan5004
        ip link add vxlan5044 type vxlan id 5044 dstport 4789 local 2001:db8::24 remote 2001:db8:1100::14
        ip link set vxlan5044 up
        ip link set dev vxlan5044 address 00:00:00:50:44:20
        ip address add 10.50.44.20/24 dev vxlan5044
        ip -6 route add 2001:db8:1100::14/128 encap seg6 mode encap segs fc00:2200::2 dev ens192.2205
        ip sr tunsrc set 2001:db8::24
        

項目[5]a ： Edge-10

ip -6 route add 2001:db8::20/128 encap seg6 mode inline segs fc00:121::2,fc00:2200::20,fc00:2205::2,fc00:122::1 dev bond0.1100
        

項目[5]b ： Edge-10

 
        ip -6 route add 2001:db8::20/128 encap seg6 mode inline segs fc00:121::2,fc00:121::1 dev bond0.1100
        

項目[5]c ： Edge-10

ip -6 route add 2001:db8::20/128 encap seg6 mode inline segs fc00:121::2,fc00:122::1,fc00:121::2,fc00:122::1 dev bond0.1100
        

特定のIPv6通信に対するパス選択の可否を確認した試験項目[1]で、データ転送のキャプチャを行った結果が以下の図4になります。

図4：IPv6通信に対するSRHの挿入とそれに基づいた転送

通信の宛先に対するFIBエントリでは選択されない、Core-01とCore-02間のリンクを経由していることが伝送路のVLAN IDから読み取れます。合わせて、SRH(Segment Routing Header)の挿入とIPv6ヘッダの宛先アドレスが通信の宛先からSegment Listで指定した値へ順次置き換えられている様子が確認でき、Active SegmentとなるSRv6 SIDがIPv6ヘッダの宛先アドレスに反映されていることが窺えます。

この状態で各ノードのFIBを確認すると、SRv6の設定が投入されたヘッドエンド以外のノードでは変化がありませんでした。また、戻りの通信に対してはSRv6が設定されていないため、FIBに従って最短ホップで転送されていることが合わせて確認できました。なお本項目の追加試験として、CONTINUE処理を担うCore-01でSRv6を無効にしたパターンにおいても同様に疎通が確認でき、IPv6転送の対応と必要な経路の保持がActive Segment中継のための要件であることを裏付ける結果となりました。

次いで、特定のサブネット内通信に対するパス選択の可否を確認した試験項目[3]で、データ転送のキャプチャを行った結果が以下の図5になります。

図5：VXLAN通信に対するSRHの挿入とそれに基づいた転送

IPv6通信と同じく、指定したレイヤ2ドメインの通信だけが任意のパスを選択できていることが窺えます。同様に、SRv6の設定が投入されたヘッドエンド以外のノードでは変化がありませんでした。なお、行きと戻りで経由するリンクが異なっている点は、そのリンクを経由する際に参照される経路がマルチパスとなっているためで、伝送路はActive Segmentに対するFIBエントリの影響を受けることが合わせて確認できました。

また、一時的なループを伴うパス形成を確認した試験項目[5]で、データ転送のキャプチャを行った結果が以下の図6になります。

図6：各要素で同一のものがパスに反映されたSegment Listの構成とそれに基づいた転送

今回は「同一のノードを経由する（2-armの迂回）」「同一のリンクを経由する（1-armの迂回）」「同一のSIDが同一のノード上で再度Active Segmentになる」という3パターンに対して確認を行い、それぞれパスの形成における阻害要因にはならない結果が得られました。

次項からは、検証の過程で確認された事項について補足したいと思います。

SRv6のモードとサービスマッピング

Linux kernel 4.10の実装ではオリジナルのIPv6ヘッダに対してSRHのみを追加で挿入するinline modeと、SRHと共に新規のIPv6ヘッダを挿入するencap modeの双方がサポートされており、iproute2のコマンドで選択して利用することができます。試験の過程でどちらも動作可能であることが確認でき試験項目[1][5]ではinline mode、試験項目[3]ではencap modeを適用しています。

なお前述の設定例で示される通り当該の環境では、Segment Listは経路に紐づけて設定することになり、関連して試験項目[3]では複数のパスを使い分けるためにパス単位でトンネル終端用のアドレスを用意しています。ノードに割り当てるSIDは現実的には漏れなく経路を交換する構成が多いと考えられ、VPNが伝送される環境においてもパスの追加に対しアドレッシング・ルーティングは影響を受けない形にできることが望ましいと言えます。試験の過程では事前に必要なスペースを広報する他にSegment Listの構成によって広報の省略が可能となることを確認しています（図7）。なお、この方法ではトンネルを終端する単一のノード上で複数回のNEXT処理を行うことになります。この回数に着目した試験を別途実施したところ、自分宛のSIDが連続してスタックされる条件下において、32個のSRv6 SIDがスタックされても疎通可能となっていました。サポートされるSID数の限界値に関しては、特にハードウェア実装においては制約を受けることが予想されます。今回の試験環境においても上限に関しては追跡調査を必要とする状況ですが、少なくとも上記の値まではヘッドエンドでスタック可能であり、また後続のノードで連続したNEXT処理を実施可能であることが合わせて確認できました。

図7：SRv6においてNEXT処理を行う中継ノードへの経路要求

そもそもトンネル終端アドレスが増加する状態は、Segment Listのマッピングが経路に対して行われ且つトンネル終端用のアドレスを使い分けられる、今回の環境に依存して発生しています。例えばVNIを識別情報に含めてSegment Listにマップできる実装であれば、単一のアドレスに対して複数のSegment Listが関連付けられるため、VPN環境においてもトランスポートに依存しないパスの追加が可能となります。また図8に示すSRv6-VPNにおいては、color extended communityも識別情報に利用可能とされており、より細かい粒度でSegment Listにマップできることが期待されます。

図8：VPN signalingとしてSRv6 SIDの交換を行うBGP仕様

SRv6のLocal Segmentと迂回

試験の過程でAdjacencyを識別するSIDとしてlink-localアドレスを利用することを想定しSegment Listを変更したところ、位置情報としては同じ箇所を示す値であるにも関わらず、通信の成否は分かれる現象が確認されました。掘り下げて挙動を観察すると、「Segment Listの構成」「SRH Encapsulationを伴ったパケット送出」は行われており、link-localアドレスをIPv6ヘッダに反映するSRv6ノードでパケットが破棄されていました。Internet-Draftの記載としてはSRv6の場合Local Segmentには全てのアドレスが利用できるとされており、また過去の版数ではlink-localの文言も確認できるなど、当該の動作を許容する設定や実装が別途存在しているもしくは今後登場する可能性は残されていると言えます。一方SIDとしてlink-localアドレスの利用を検討する際には、link-localアドレスの位置付けを踏まえれば転送を許容しない振る舞いも妥当であるだけに、適用の可否について留意が必要です。

他に確認された現象として、Adjacencyに対するSIDを直接接続でないSRノードにおいてもActive Segmentにすることが可能であり、通信も成立したことが挙げられます。SRv6はSIDにIPv6アドレスを用いるため、Local Segmentに対してもGlobally Uniqueな値を適用することが容易です。一方SegmentがLocalであるかGlobalであるかは、値の一意性ではなく、直接接続されたSRノードだけが転送可能であるかそれともSRドメイン内の全ノードが転送可能であるかによって区別されます。SRv6の場合、Adjacencyに対するSIDであっても外部のノードでRoutableになっていれば、Global Segmentとして伝送パスはRoutingの影響を受けることになります。図9は今回の試験構成でインタフェースに対するIPv6アドレスを広報したケースとなり、Segment Listの構成によっては意図したパスが選択されない結果となりました。

図9：Adjacencyに対するSIDを外部でActive Segmentに利用した場合に起こり得る現象の例

このような場合、前段のノードに対するSIDを前に置いてからAdjacencyに対するSIDを指定するか、Local Segmentのみを指定してSegment Listを構成することによって特定のリンクを経由させることが可能になります。極端にはサブネットを細かく刻んで広報している・Staticでホストルートが設定されているなど直接接続に対して迂回し得る要因も残存しますが、トランスポートネットワークとしてそういった要素が排除できていれば、Segment Listの適切な構成によって意図したパスを形成することができます。

なお、Global Segmentに対する伝送パスはFIBの状態によって決定されるため、マルチパスやセカンドベストのパスが存在していれば障害時にはその範囲で速やかに復旧することが可能です。一方Local Segmentの場合、迂回路を提供するためにはプロテクションに類する技術を併用することになります。

まとめ

Linux kernel 4.10を対象としてSRv6によるトラフィックステアリングの試験を実施したところ、特定のIPv6通信およびIPv6 Encapsulationを伴うVXLAN通信に対し、任意のパスを選択できる結果が得られました。この時、MPLSは必要とならず、パス追加の前後で中継網における設定および転送テーブルのエントリに変化は見られませんでした。

SRv6においてSegment ListはIPv6拡張ヘッダとして新たに定義されたSRH (Segment Routing Header) 内に含められてヘッドエンドで挿入され、またActive Segmentは中継のSRv6ノードによって順次置き換えられる宛先IPv6アドレスで表現されることが想定されています。SRv6ではSIDとしてIPv6アドレスが利用されることから通常のIPv6ルーティングが行われていれば疎通可能となり、今回の試験ではこれに沿った結果を得ることができました。

TEを実現する手段としてSRv6に着目すると、パスプログラムの処理がネットワーク上のヘッドエンドに閉じて行われることに加え、MPLSやコントロールプレーンの拡張を必要としない点が特徴として挙げられます。SRv6は、改版過程で導入されたLocal SID Functionの概念も特徴的ですが、トポロジを表現したSRv6 SIDの範囲においてもよりシンプルなTEの実現手法として活用することができます。また、適用に際してはプロテクションの可否・連携可能なサービスの種類・サポートされるパス指定の方法なども同時に検討されるため、実際にはこのような周辺機能も重要な要素となります。