Kamuee: SRv6対応の設計と実装に関して

Transcript

1. Copyright © NTT Communications Corporation. All rights reserved. SHIROKURA Hiroki

   slankdev@nttv6.jp NTT Communications Technology Development Division 2019/02/22 ENOG55 Kamuee: SRv6対応の設計と実装に関して

2. Copyright © NTT Communications Corporation. All rights reserved. 1. 背景:

   KamueeでSRv6のD-planeを作ってます a. ルータとしてより先進的なルーティング機能をサポートしたい b. ソフトウェアルータの威力をアピールしたい c. オペレータの会社としてプロアクティブな運用課題解決の準備をしたい d. 設計はイメージできていて , PoCも動く状態 2. 動機: SRv6コミュニティの活用と活性 a. 近隣知識の探求と, 情報交換. 情報は出す人に集まる . b. 他の作ってる人に役立てばハッピー . 3. 概要: 今日はKamueeでどのようにSRv6を作っているかを紹介 a. D-planeの設計と実装に関して . b. ルータとしてどのように完全対応するかのストーリー c. softwareルータとSRv6の美味しい話 d. 実例としてKamueeとして話す 既存のソフトウェアルータに対する SRv6実装の手段 背景 / 動機 / 概要 2

3. Copyright © NTT Communications Corporation. All rights reserved. 議論の流れ 3

   • Kamuee 設計と実装を説明 • SRv6対応の設計, 実装の検討, 現状 • SRv6対応の課題と展望 • 参考資料等 ◦ 迅速な開発のための検証環境 ◦ SRv6関連の他ソフトウェアの情報. 調査結果

4. Copyright © NTT Communications Corporation. All rights reserved. Kamuee 概要

   4 • 既存OSSを活用した高性能ソフトウェアルータの D-plane ◦ DPDK, Poptrie, FRRouting ◦ コア数でスケールするアーキテクチャ ◦ Netlinkを活用しLinuxとの高親和性 ◦ 性能に関しては本日は説明しない • Interop Tokyo 2018 (Shownet) コアルータとして導入 • 現在は導入実験 & 機能追加を実施中

5. Copyright © NTT Communications Corporation. All rights reserved. Kamuee Feature

   Spec Beta1: 100GbE • Hardware: about 400万 yen • supermicro 4U Tower • 100GbE (QSFP28: SR4/LR4) x12 Beta2: 10GbE • Hardware: about 45万~ yen • Fujitsu Primergy 1U • 10GbE (10GBase-T/LR) Beta3: NFV • 6vcpu,8G-ram • 10GbE/100GbE/Virtio • SR-IOV/Vhost-net/Vhost-user IPv4/IPv6 forwarding, ARP/NFP ICMP/ICMPv6 handling, RIP, OSPF, BGP, SNMP/LLDP, IEEE802.1Q tagged VLAN, VRRP, Proxy-arp, VRF, ACL , CLI, Port-mirror, DHCP-srv/cli, Pkt-Cap, BFD, Interface-eBPF(exp), Custom-linux-distro(exp), ECMP, Multicast Supported Feature SRv6, EVPN/VXLAN, ISIS xFlow, MPLS, LAG, debian-package, Full-API, VMware-virtualization Will be supported soon L2-Switching, STP, GRE, NAT, PBR, SR-MPLS, IPsec, BGP-flowspec Other TODO CPU: Xeon E5, Xeon-SP platinum IXGBE (intel 10GbE) x540, x550 I40E (intel 40GbE) x710, xl710 MLX5 (Mellanox 100GbE) ConnectX5 Virtio-net (KVM vNIC traditional) Vhost-net (KVM vNIC better perf) Vhost-user (KVM vNIC good perf) Tested Hardware

6. Copyright © NTT Communications Corporation. All rights reserved. Kamuee 全体構成

   6 • DPDK, Poptrieで実現した高速D-plane • LinuxをC-planeとして活用する親和性 特徴

7. Copyright © NTT Communications Corporation. All rights reserved. D-plane 転送部分の全体像

   7 • 例) 各NICに4コア消費する構成 ◦ 四角: NIC ◦ 車輪: NICのQueue ◦ 楕円: Thread • NICでの負荷分散はRSSを利用 • データパスで気をつけていること ◦ Write Shared Nothing ◦ Lock free

8. Copyright © NTT Communications Corporation. All rights reserved. N多重のデータパスのうち一本にフォーカス 8

   • 受け取るパケットは二種 ◦ ICMP, BGP, OSPF等のC-planeパケット ◦ IP destinationが自分でない転送するパケット • pre-routingでコントロールパケットをkernelに転送. • poptrieの検索結果に転送先ポート番号と , 宛先macアドレスを格納

9. Copyright © NTT Communications Corporation. All rights reserved. さらにpre-routingにフォーカス 9

   • コントロールパケットは薄くフィルタして tap経由でLinuxに転送

10. Copyright © NTT Communications Corporation. All rights reserved. Revisit: Netlink

    10 • Netlink はカーネル/ユーザー空間のプロセス間で 情報をやりとりするために用いられる特別な IPC方 式. (RFC3549) • Netlinkソケットを監視することで , Linux KernelのNW機能の挙動がわかる ◦ ルーティング経路の追加 ◦ アドレス設定 ◦ リンクアップ等 • socket(3)で開いてlistenで購読すると, Netlinkのバイナリメッセージが流れてくる . Linuxやiproute2のソースがドキュメント ...

11. Copyright © NTT Communications Corporation. All rights reserved. 11 DEMO:

    Netlink購読でLinuxの設定変更を監視する https://youtu.be/0QdpGuKcUv4

12. Copyright © NTT Communications Corporation. All rights reserved. Kamuee 全体構成

    再確認 12

13. Copyright © NTT Communications Corporation. All rights reserved. SRv6機能に関する開発方針と現状 13

    • 世界の状態 ◦ すでにLinuxには豊富なWell known functionが実装されている. ◦ 今後FRRoutingやGoBGP, Birdの開発者たちがC-planeを実装する日は近い • 課題 ◦ End系 → local sid tableの参照は高速にする ◦ Transit系 → 計算機的オーバヘッドを減らしながらパケットの途中にデータを挿入する ◦ Linuxとの連携 → SRv6のNetlinkをサポートし, Linux FIBに対する設定と同期する • 原則 ◦ これまで通り, Linuxとの機能のpartial-offload方式を貫く. ◦ 既存の機能に対する性能影響は最小限にする . • 現状 (PoC状態) ◦ End, End.X, End.AM, T.Insert を実装完了 ◦ SRv6のNetlinkサポートも完了 (まだ全体が一つに合体してない )

14. Copyright © NTT Communications Corporation. All rights reserved. 実装のキーポイント 14

    • SRv6での処理の発火ポイント ◦ LinuxはIPのFIBにSegmentを登録できるのでKamueeも同じ扱いにしている ◦ End系の書き換えはIPv6の拡張ヘッダとして普通に処理するだけ (Kamueeは部分的なIP Stackと思える) ◦ T系の書き換えはmbufでメモリコピーを少なくする • SRv6のUser Interface ◦ Linux kernelに対する iproute2 からのアクセスを購読して経路を追加する . ◦ NetlinkのLWT系のメッセージを解析する ◦ End, End.X, End.T等のactionによってメッセージ形式が若干違うので注意する ◦ Linux UIに統一することでLinux上に今後実装されるC-planeを活用可能にする

15. Copyright © NTT Communications Corporation. All rights reserved. 現状の動作仕様: PoCで動いている

    or もうじき動く予定 15 • 現状の仕様のchoiceには基本的に深い意味はない . ◦ 今よくわかってないから以下のようにしているだけで , 標準化されている(WIP OK)部分だとユーザの要望である程度は自由自在です . ◦ 標準化されてなくてもソフトウェアなので結構すぐ作れたりもします . • End系に関して ◦ IPv6 prefixに対してFunctionを登録可能. (Linuxと同じ構成) ▪ fc00:1::1 End.x nh6 2001:12::2 ▪ fc00:1::/64 End.x nh6 2001:12::2 ▪ Argに関して対応可能な設計だが未検討レベル . ◦ IGPでlocator範囲を広告し, Function-idはstatic等でユニークにして運用することを想定 ◦ PSP / USP はどちらかに統一して動かす想定をしている . → 未開発 ◦ 複数のsegmentを連続で処理する部分がバグってる .. • Transit系に関して ◦ IPv4 / IPv6 Destinationに対してT系を実行可能 ◦ ACLのmatchとリンクさせたりすることも検討中 . ◦ 少なくともIP v4/v6 の src dst をpolicyとして実装予定 • OAM系は未検討. 必要と思われる

16. Copyright © NTT Communications Corporation. All rights reserved. IPv4/v6検索結果の データの扱い方

    16 • 旧タイプ ◦ type ◦ nexthop mac-addr ◦ output port-id • 新タイプ ◦ type ◦ table-id ◦ output port-id • 一段遠くにmac-addr等があるので, 計算機的に性能が少し低下する 可能性がある. • tableの中にEnd.X, End.AM等の functionの情報を埋め込む

17. Copyright © NTT Communications Corporation. All rights reserved. mbuf構造による メモリシフト量の低減

    17

18. Copyright © NTT Communications Corporation. All rights reserved. Insert時の パケットの

    書き換え部分 18

19. Copyright © NTT Communications Corporation. All rights reserved. でも本当はmbufって chain可能だが...

    昨年のInteropでは 動かなかったんだ... 問題は積んで置いて 今回は大きなmbuf 空間を用意 メモリシフト分だけ コピー発生は許す 19

20. Copyright © NTT Communications Corporation. All rights reserved. 知見: 作ってわかるSRv6

    20 • 作りやすい ◦ 既存のIPv6のlookupをそのまま使える ◦ パケット処理部分はテーブルアクセスも少なくシンプル End系の軽い実装もソフトウェアなら数日 . (正直コード書いた時間は 5hほど.) ◦ SRコンセプトの「ルータ上のステート低減」が効いている ? • 今後のソフトウェアSRv6実装の世界の課題 ◦ C-planeソフトウェアを推進させること (FRR等) ◦ SRv6のNetlink形式を対応するのは難しいことではない ◦ SRv6 sandbox環境. (誰もが試し, 検証や開発を推進すること ) ▪ ソフトウェアなら作ること自体は結構簡単 ▪ 作ろうと思う環境がなさすぎる ◦ 今後LinuxからのUIを維持できるかどうか . ▪ 例: iproute2はEnd.AMのUIはあるけど, Kernelが対応してなくて, NetlinkをListenしても受け取れない ▪ Linux Contributionで解決ではある ▪ 本気ならD-planeだけでなくLinuxに貢献する必要がある

21. Copyright © NTT Communications Corporation. All rights reserved. 結論とこれから 21

    • KamueeでSRv6が動きそうです ◦ KamueeのSRv6 routing機能は, Linuxの構造を参照しており, 親和性が高いため, 今後FRR等にSRv6のC-planeが実装された場合(もしくわ我々で実装した場合)にその ままそれをKamueeで活用することができる. ◦ 性能もクリティカルになる内容があまり多くはない ◦ 性能はできてから測ります. • ソフトウェアとしての課題 ◦ 開発速度の向上 ◦ 堅牢性 • 現在取り組んでいること ◦ Segment Routing IPv6 実装中. ◦ 統合自動試験環境の構築. ◦ 導入実験を進める.

22. Copyright © NTT Communications Corporation. All rights reserved. 参考: 開発中に行なった作業

    22 • SRv6関連のRFC, draftをさらっと読む. (読破はまだできてない) https://github.com/slankdev/tinet/tree/master/docs/segment_routing • LinuxのSRv6の挙動を実装されている部分は全て動かす . (End.DT4とかないんすよね...) https://github.com/slankdev/tinet/tree/master/examples/basic_srv6 • RFCと平行しながら, Cisco 鎌田さん 竹田さんの資料を読む. → SRv6概念がわかる https://www.janog.gr.jp/meeting/janog40/program/sr • RFCと平行しながら, @ebiken さんの資料を読む. → SRv6のLinux実装がわかる https://www.slideshare.net/kentaroebisawa/srv6-enog53 https://www.slideshare.net/kentaroebisawa/zebra-srv6-cli-on-linux-dataplane-enog49 • 死ぬ気でSRv6のユースケースを考えてLinuxとコンテナで試しまくる https://github.com/slankdev/tinet/tree/master/examples/basic_srv6 • Linux, srext, VPPのソースコードを読みまくる https://github.com/torvalds/linux https://github.com/netgroup/SRv6-net-prog https://github.com/FDio/vpp • IETFに行ってみる決意をする... プラハ行きます. (panda先生のアドバイス)

23. Copyright © NTT Communications Corporation. All rights reserved. 参考: SRv6デモンストレーションの例

    (公式) 23 https://upload.apnic.net/uploads/apricot_srv6_20180225_final_1519556622.pptx https://www.cisco.com/c/dam/assets/sol/service-provider/digital-transformation/pdfs/0912-msn-ckn.pptx

24. Copyright © NTT Communications Corporation. All rights reserved. 参考: SRv6デモンストレーションの例

    (自力) 24 https://github.com/slankdev/tinet/tree/master/examples/basic_srv6

25. Copyright © NTT Communications Corporation. All rights reserved. 参考: 動作検証の迅速な用意

    (TiNetの紹介) 25 先ほどの仮想NWで作るのが大変だったので, それを簡単にやるためのDockerのWrapperを作った. yamlでNodeのL2 topoとconfigと動 作試験が記述可能で, 環境の構築,破棄,Nodeのconfig,試験を行うshellを生成することができる. 物理ルータを仮想NWに参加させることも 可能 → KamueeやVPPの動作試験をより迅速に行える. mininetはプログラムのsemanticsで仮想NWを作るのと比べ, tinetはyamlのsemanticsで仮想NWを定義. https://github.com/slankdev/tinet 仮想NW作成例

26. Copyright © NTT Communications Corporation. All rights reserved. 付録: DPDKに関して

27. Copyright © NTT Communications Corporation. All rights reserved. revisit: DPDK’s

    overview. ref:www.dpdk.org Distributions Gold Members Silver Members Associate Members Amazon, Atomic Rules, Broadcom, Cavium, Chelsio, Cisco, Intel, Marvell, Mellanox, Netcope, Netronome, NXP, Solarflar, Paravirtualization(VMware/KVM), Others Support Hardware ANS, BESS, Butterfly, DPVS, VPP, FastClick, Lagopus, MoonGen, mTCP, OPNFV, OpenDataPlane, Open vSwitch, Packet-journey, Pktgen-dpdk, PcapPlusPlus, Ruru, Seaster, SPDK, TRex, WARP, YANFF Open Source Projects consuming DPDK 6WIND, Calsoft Labs, Intel, Wind River Service/Support Calsoft Labs, Semihalf, Wind River Instructor-Led train DPDK is the Data Plane Development Kit that consists of libraries to accelerate packet processing workloads running on a wide variety of CPU architectures

28. Copyright © NTT Communications Corporation. All rights reserved. 復習: 100Gbps

    64byteだと148 Mpps!! 28 時間なんて圧倒的に足りない . たったの20clockで何ができますか... 現在はたくさんCPUのコアがあるよ 40コア程度は積む時代になってきた もうシングルスレッドでは間に合わない 必要な概念 • コンピュータ理論基礎 (NUMA,キャッシュ,etc..) • 並列処理の概念 • 強い心 上記は, 1コアで20clock 2コアだったら40clockでいける. (と考えることができる . わかりますか)

29. Copyright © NTT Communications Corporation. All rights reserved. revisit: DPDK’s

    approach Basics to achieve over x10 perf than linux There are some mechanisms makes network application slow, because of general purpose network stack on Linux. DPDK is set of libraries for fast packet processing. it uses some mechanizm to bypass Kernel NetStack. (UIO, pthread setaffinity, special Memory management with hugepages) 1. Memory Copy 2. Context Switch 3. Fat Network Stack 4. Kernel Scheduler 1. No Memory Copy 2. No Context Switch 3. Scratch for perf 4. Avoid K-Scheduler Linux Networking DPDK Networking Syscall is really really slow :( getuid(3) is one of the lowest overhead syscall. however, it takes about 500 clk per execute. https://gist.github.com/slankdev/bede218b67a452c982a71d886116f017

30. Copyright © NTT Communications Corporation. All rights reserved. 復習: 計算機は早いとこと遅いとこがある

    30

31. Copyright © NTT Communications Corporation. All rights reserved. 31 revisit:

    DPDK’s core consuming model Run to Completion Model & Pipeline Model FYI: Run to Completion - Kamuee - OvS-dpdk Pipeline - Lagopus - VPP • Run to Completion ◦ pros: Low latency, Utilize HW-option, ◦ cons: nic need be capable RSS, monolithic • Pipeline ◦ pros: low latency, moduler, don’t need RSS ◦ cons: high latency, can’t utilize HW-option • Scientific Comparison is nothing..? (old: M.Dobrescu et.al, RouteBricks, SOSP’09)

32. Copyright © NTT Communications Corporation. All rights reserved. revisit: Core

    Consumption (Fast/Slow thread) 32 Fast Thread • dplane: packet forwarding Slow Thread • cplane: routing protocol • cplane: UI

33. Copyright © NTT Communications Corporation. All rights reserved. revisit: マルチコアへの負荷分散方式

    (負荷分散ポイントに注目) 33 - RSS: Receive Side Scaling -> NICの機能 - RPS: Receive Packet Steering -> RSSをソフトウェア的に実現したもの