#はじめに
2018年も残り一ヶ月、徐々に寒くなり、クリスマス・キャロルが聞こえてくる頃になりましたねw
こんな日は少しテクニカルな事に時間を割いて、熱量高めに、Linux Foundationプロジェクトの１つである、
FD.io VPPについて、shimadyuが紹介いたします！ 以下のサイトからVPPのdeepdiveが可能です。
FD.IOのリンクはこちら
FD.IO wikiのページはこちら
VPPとは何か
VPPデザインと実装のoverviewはこちら
Service Providers、Network Vendors,Chip Vendors、Integratorsさんにて、オープンソースコミュニティ活動を進めているVPPですが
VPPは約10年間、シスコ社内にて開発していた仮想スイッチモジュールとなっています。
NFVに携わるみなさんに使っていただけるように、2016年の早い段階にて、Linux Foundation project FD.ioとしてオープンソースになり、CommodityなCPUを搭載したx86/64サーバにて動作して、且つ、柔軟性がありスケーラブルなデータプレーン転送の実現を目指し、これからも新しいネットワーキングのチャレンジを解決していくことがプロジェクトの目的となります。2018年12月5日時点で最新のVPP Releaseは18.10となっており、タイムリーにソフトウェアがリリースされております。apt-get installでvppインストールは比較的簡単です。proxy環境の場合は、proxyオプションを忘れずに設定頂き、apt-getやcurl -x proxy...な形で事前準備します。
#オープンソースFD.IO/VPPの特徴
いろんなサイトにてVPPを日本語で紹介されておりますので、shimadyu目線にて以下8つのテクニカルなポイントを取り上げます。
-
VPPはDPDKに依存しておらず、IntelさんのAdaptive Virtual Function (AVF)がVPP native driverに対応しております。詳細はこちらです。 将来的にはVPPをSmart NICにオフロードしてくれるはず(期待)
-
VPPはOVS-DPDKよりもパフォーマンスが圧倒的に優れている
-
OVSのようにパケットを一個ずつ処理するのではなく、一度に256個までのパケットを、L2/L3ルックアップを実行するパイプラインに入れて処理する。マイクロプロセッサ上のinstruction cacheの読み込み再利用できたり、事前にパケットをデータキャッシュにプリフェッチさせることができるため、同様のシーケンスを持ったIPv4/IPv6パケットは、独立したIPv4/IPv6モジュールにて同時に処理可能となり、メモリーへのアクセス遅延とメモリー使用量を最小化します
-
VPPはvSwitchとしてVNFを接続し、ユーザスペースで動作する （OSS vSwitch)
-
VNFをbuildするためのフレームワークとして動作させる事も可能
-
コントロールプレーンを担当するOpen Day Light(ODL)連携も可能
-
OpenStack Neutron FD.io ML2 agentをサポート (本当はこれを試したかったのですが、次回への宿題とさせていただきます!)
-
様々なL2/L3機能のデータプレーンに対応 [本記事ではSRv6-VPNをご紹介します] (https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6)
ここで、2のパフォーマンスがどんなに優れているのか、一部、FD.IO wikiに公開されておりますが、触れたいと思います。最も、特徴的なのは、L2 MACエントリーやL3 FIB数のスケールに依存せず、スループットは安定、さらには、CPUコアあたり、約14Mppsの転送性能を持ち、24CPUコア搭載した場合には500Gbpsのスループットを実現可能な転送アーキテクチャとなっております。
#SRv6-VPN DX4 (IPv4 over IPv6)をVPPで設定してみよう
VPPのインストール説明は今回は割愛しまして、[draft-filsfils-spring-srv6-network-programming] (https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-06)で定義されているSRv6-VPN DX4 functionをVPPで動かして見たいと思います。
両端にR1とR2とCisco CSR1kvでIPv4のみを有効として、IPv4 over IPv6にてIPv4通信をSRv6-VPN NW経由で可能にしてみたいと思います。
1.VPP1,VPP2,VPP3はSRv6-VPNのデータプレーンに対応したVPPノード
2.VPP1は2.2.2.2/24を宛先とするIPv4パケットをR1から受信すると、SR policyにてL3 steeringし、T.Encaps functionを実施(IPv6headerと SRH with segment lists (B1::1, C4::4)の両方をencapして、B1::1を宛先としたIPv6パケットをVPP#2に送出)
3.VPP2はB1::1を宛先とした自分宛てのパケットをEnd functionし、Segment listsを1->0に減算し、IPv6 宛先アドレスはC4::4にrewrite
4.VPP3はC4::4を宛先とした自分宛てのパケットを受信すると、IPV6ヘッダーとSRHをdecapし、指定したIPv4 I/F経由でIPv4パケットをcross-connect (END.DX4 function)
VPP1では以下のような出力結果となります。VPP3も同じような設定となります。
SR policyにより、2.2.2.0/24を宛先とするIPv4パケットは、T.encapされ、B1::1,C4::4をSRH Segment Listにセットします。
以下のshowコマンドからもL3 SteeringのためのSR policyが正しく反映されていることがわかります。また、vpp1はDX4 functionを実行するSRv6ノードでもあるため、DX4 functionも合わせて設定しています。
VPP2では以下のような出力結果となります。B1::1をENDするための役割ですので、特に難しい設定はありません。
#VPP1＜−＞VPP2間のSRv6パケットをキャプチャしてみよう
R1からR2へICMPを実行した状態で、VPP1<->VPP2間のパケットキャプチャを実行します。
確かに、IPv4パケットがIPv6にてencapされて、転送されています！
#おわりに
今回は、オープンソースのVPPを使用して、SRv6-VPNのデータプレーンを確認しました。
VPPはvswitchとしてのユースケースもサポートしているため、次回はNeutron ML2連携やコンテナ(Contiv-VPP)にもチャレンジしたいとおもいます。
ご覧いただきまして有難うございます。
simadyu