目次
今回は社内で行ったSRv6の相互接続性に関する試験の様子をご紹介いたします。
はじめに…
昨今SP/DCネットワークにおける構成要素として挙げられることの多いEVPNやSegment Routingといった技術も成熟が進み、日本国内でも様々な事例が紹介されるようになりました。
その中でもSRv6は商用実装が登場してからまだ日が浅いと言え、こちらの実装状況を注視されている方は弊社のお客さまにも多くいらっしゃる印象があります。そのSRv6に関して、相互接続性試験はこれまで各所のイベントで行われており、情報がまとめられたInternet-Draftsも発行されています。
|
SRv6 Implementation and Deployment Status https://datatracker.ietf.org/doc/html/draft-matsushima-spring-srv6-deployment-status-10#section-4
An Experiment of SRv6 Service Chaining at Interop Tokyo 2019 ShowNet https://datatracker.ietf.org/doc/html/draft-upa-srv6-service-chaining-exp-00
draft-filsfils-spring-srv6-interop-02 - SRv6 interoperability report https://datatracker.ietf.org/doc/html/draft-filsfils-spring-srv6-interop-02
|
上記で紹介されているEANTC（European Advanced Networking Test Center）にて行われた試験では、詳細なレポートや動画も公開されています。
|
MPLS + SDN + NFV World Congress Public Multi-Vendor Interoperability Test 2018 https://eantc.de/showcases/mpls_sdn_2018/intro.html
MPLS + SDN + NFV World Congress Public Multi-Vendor Interoperability Test 2019 https://eantc.de/showcases/mpls_sdn_2019/intro.html
MPLS + SDN + NFV World Congress Public Multi-Vendor Interoperability Test 2020 https://eantc.de/showcases/mpls_sdn_2020/intro.html
|
上記の様な情報を参照すると、これまで何の機能がどのようなトポロジで試験されていたか窺い知ることができます。一方、GA（General Availability）でない項目の含有率や詳細な環境条件、パケットへのエンコーディング模様など、読み解くことができない情報があることも確かです。
試してみると…
今回はGAとなった商用OSを用い、パケットキャプチャが可能となる状態で、SRv6の相互接続環境を社内に用意しました。また全体を通じて正式にサポートされるかは考慮せず、仮想化環境を活用して構築を行っています。以下の図1・図2はその試験の構成図です。
図１：構成図（主にアドレッシング関連） |
図2：構成図（主にルーティング関連） |
上記には以下の要素が含まれています。
- SRv6ドメインを経由したIPv4セグメント間の接続
- SRv6非対応のノードによる中継
- SRv6ドメインにおけるIS-IS / OSPFv3間の再配送
- SRv6ドメインにおけるECMP区画の存在
- SRv6 TI-LFAの部分的な有効化
- SRv6 TEの利用
各SRv6ノードのデータプレーンはIPv6/SRHで共通しており、サービスのコントロールプレーンにはBGPが利用されている状態です。図3・図4・図5は上記の要素を実現するために所定の設定を終えた後、データ通信に対してパケットキャプチャを行った結果の抜粋になります。
図3：パケットキャプチャ結果の抜粋（シングルパスとマルチパス） |
図4：パケットキャプチャ結果の抜粋（IGPの最短パスとTEパス） |
図5：パケットキャプチャ結果の抜粋（障害点で迂回を行うパスと収束後のパス） |
各種キャプチャの結果を含め、得られた手元のデータを見るとやはり様々な気づきが得られます。その例として、以下に二つほど問いかけを挙げました。特定のノードを経由する通信に対し下記のような現象が起きていたと仮定して、それは本当だと感じられるでしょうか？
|
○「ある方向の通信は疎通するが、逆方向は疎通しない」 ○「あるアドレスファミリの通信は疎通するが、同じbehaviorを利用する別のアドレスファミリは疎通しない」 |
このような問いを作っている時点で真偽はお察しかと思いますが、その背景やギャップが埋まる可能性については関心をお持ち頂けるかもしれません。
SRv6に関して、利用されるヘッダのSRHは既にRFC 8754（□）として発行され、SRv6 Network Programmingの基本仕様に相当する文書のRFC化も間近に迫っています（□）。実装の多様性も勘定した支援を早い段階からお届けできる様、このような取り組みも引き続き進めていければと思います。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
