Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Exploring XDP: Fundamentals and Real-World Impl...

Takeru Hayasaka
August 19, 2024
630

Exploring XDP: Fundamentals and Real-World Implementations in Mobile Network Data Plane

eBPF Japan Meetup #1 ( https://ebpf.connpass.com/event/323368/ )で登壇した内容です。
XDPと呼ばれるソフトウェアによる高速パケット処理技術の解説と、弊社におけるXDPを活用したモバイルコアの開発事例についてご紹介いたしました。

Takeru Hayasaka

August 19, 2024
Tweet

More Decks by Takeru Hayasaka

Transcript

  1. Exploring XDP: Fundamentals and Real-World Implementations in Mobile Network Data

    Plane 2024/08/19 Takeru Hayasaka <[email protected]> Cloud Native Community Japan - eBPF Japan Meetup #1
  2. Agenda • XDPとは ◦ 概要 ◦ XDPの技術的な説明 ◦ XDPにおける実装テクニック •

    事例紹介 ◦ 他社の事例紹介 ◦ 弊社PGW-Uでの事例紹介
  3. 自己紹介 • 早坂 彪流 (Hayasaka Takeru|@takemioIO) • 仙台市出身, 東京都在住 ◦

    半年前に京都からお引越しした • 社会人4年目 • さくらインターネット に所属、 現在は、現職(BBSakura Networks)へ出向中 ◦ 前職はゲーム会社でゲーム機のファームを書いていた • 好きな技術: eBPF/XDP, Go • 近況: 最近結婚しました。 最近はイイお茶にハマって妻と飲んでる
  4. • BBIXとさくらインターネットの合弁会社 • 2019年8月1日設立 • ネットワークサービスのソフトウェア開発 • 親会社を通じてソフトウェアを世に出している • すべての「モノ」がつながる社会の実現に向け、プラットフォーム

    (OCX) 提供を通じてネットワークサービスのクラウド化を進めています 開発や運用をしているサービス • さくらのセキュアモバイルコネクト • さくらのショートメッセージサービス • BBIXお客様向けポータル • OCX (Open Connectivity eXchange)
  5. • BBIXとさくらインターネットの合弁会社 • 2019年8月1日設立 • ネットワークサービスのソフトウェア開発 • 親会社を通じてソフトウェアを世に出している • すべての「モノ」がつながる社会の実現に向け、プラットフォーム

    (OCX) 提供を通じてネットワークサービスのクラウド化を進めています 開発や運用をしているサービス • さくらのセキュア モバイルコネクト • さくらのショートメッセージサービス • BBIXお客様向けポータル • OCX (Open Connectivity eXchange) ここでXDPを使っています:)
  6. XDPとは? - eBPFを利用した高速なパケット処理系 - IOVisor Projectの技術として始まった - 実は結構時間が経っており、当時発表されてから約8年経過している - NetDev

    1.1 (Feb 2016)にJesper Dangaard Brouerからpacket-pageという基本デザインが発表された - Tom Herbert, Alexei and Brenden Blancoの三人がXDPの実際のパッチセットを実装した - 彼らはIOVisorの原型であるPLUMgridの開発者で、XDPに近しい技術を作ってた人が実装した - ※Tom HerbertはPLUMgridではなくFBのエンジニアで、RPS 等の作者 - cf. PLUMgridによるLinuxへの開発の様子(主にeBPFとNetwork関連に力を入れてる) - cf. 最初期のXDPのパッチ(Jul 2016) - NetDev 1.2 (Dec 2016)にDavid S. MillerがXDPでKeynoteを話している - NICドライバレベルでパケットの処理ができることから高速な処理ができる - これにより、1コアで24Mppsという高速なパケット処理を実現している - Linuxのカーネルネットワークスタックとの共存ができるのがめっちゃ強い
  7. 動作アーキテクチャ - パケット着信時にデバドラのhook pointでeBPFのプロ グラムが動く。ここで実行するモノをXDPと呼び、 Interfaceにアタッチして動作させる - XDPはパケットに基づいてデータ処理を行い、最終的に どのようにパケットを送り出すかを決定している -

    送り先は終了コードで制御できる - PASS: 通常のネットワークスタックに送る - DROP: ドロップさせる - TX: 同一Interfaceに返す - REDIRECT: 他のInterfaceに返す - ABORTED: 異常終了ステータスでドロップさせる - もし複数のXDPのプログラムをInterfaceにAttachした い場合はTailCallと呼ばれるeBPFから別のeBPFプログラ ムにJumpする方法を利用する - TCを併用することで帯域制限等も可能 cf. The eXpress data path: fast programmable packet processing in the operating system kernel / Figure 1
  8. - DPDK(従来の処理系) - コアの専有(特定コアでCPU100%で張り付かせてポーリングする) - カーネルバイパスでコンテキストスイッチを避けて高速化 - ネットワークスタックの再実装が必要 - VPPなどの既存の実装の仕組みに乗ることで多少は解決できる

    - XDP(今回紹介の技術) - 専有で割り当てるコアは必要ないので電力面で有利 - NAPI Basedで実装されているので、必要なとき(==負荷増大時)にポーリングする形式 - カーネルのネットワークスタックと共存できるのでARP等のケアは自分で書く必要がない - netnsでも動いて、nexthopを特定のコンテナに向けるような仕組みもあることから、 比較的コンテナとも高い親和性がある このことから良い塩梅のパケット処理フレームワークとして存在している 「最高の性能が出せるのがDPDK」「そこそこ凄くてお手軽に性能が出せるのがXDP」 と言う体感がある 従来のパケット処理系と比較する
  9. - IPv6パケットをDropするコードの例 - v6でなければカーネルのプロトコルスタックに渡す - 1.SEC()でeBPFのプログラム・アタッチタイプ を指定する - eBPFはhook point毎にタイプ指定する必要がある

    - SEC をつけた関数がエントリポイントとなる - タイプに応じて引数が変わり、xdp_mdというパケット のポインタを持つ構造体を受け取る - 2.プログラム終了コード - 境界値チェックの結果パース失敗でパケットDrop - 3.ライセンス - fiblookupやprintkを使うためにはGPLライセンスか どうかを検証されたうえで使う必要があるため、 明示的に指定しないとVerifierに怒られる XDPのプログラムアーキテクチャ #include <linux/bpf.h> #include <bpf/bpf_helpers.h> #include <linux/if_ether.h> #include <arpa/inet.h> SEC("xdp_drop") int xdp_drop_prog(struct xdp_md *ctx) { void *data_end = (void *)(long)ctx->data_end; void *data = (void *)(long)ctx->data; struct ethhdr *eth = data; __u16 h_proto; if (data + sizeof(struct ethhdr) > data_end) return XDP_DROP; h_proto = eth->h_proto; if (h_proto == htons(ETH_P_IPV6)) return XDP_DROP; return XDP_PASS; } char _license[] SEC("license") = "GPL"; cf. Get started with XDP/Task 2: Drop specific packets with XDP 1 2 3
  10. - コンパイルしてLinuxのdevice interfaceにAttachするだけでOK - XDPの期待されるユースケース - DDoSMitigation - ファイアウォール -

    ロードバランサー - NAT - 既存のLinuxの一部機能の拡張 - RXに対しての動作がメインでTCP再実装みたいなのは結構難しい。 - eBPF Verifierの影響もあり...L7とかの細かい操作もあまり向いてない。 XDPの活用方法
  11. XDPのコードを読んで開発をStartするには? - XDPTutorialをとりあえず眺めてちょっと触ってみる - linux/samples/bpfをとりあえず眺めてやりたいことに近いのを探す - libbpfやbcc,cilium/ebpfとかを眺めてどの言語でeBPFを制御するかを考える - あとは書く!(完) -

    ちなみにGoでBPFを制御するコードを実装したくなった方に朗報です。 unittestもついてる便利な実装テンプレートが実はこんなところに...!(宣伝) PRとかお待ちしてます... :) - https://github.com/takehaya/goxdp-template
  12. - Ingress / Egress を意識して、TailCallを利用したPipe Lineを実装すると良い - eBPF は100万命令まで行けるが、真面目にパケット処理を書くと超えるのはざらにある。 なのでプログラムの機能単位を意識して書くのが良い

    - e.g. Checksumの処理を実装する際には大きい値でループをさせることになりoverflow... 😇 - 大きな変数は長さ1のPerCPUのMapとして持っておくと良い - eBPF 特有の問題として 512bytes までのStackしか使えないことが知られてるが、 パケット処理をするとそれを余裕で超えることが多い - e.g. IPv6 のアドレスは128bytes…コピーしたり書き換えたら簡単に溢れる - eBPF Map は VerifierのStack Size の計算に含まれないのでワークアラウンドとして便利 XDP実装テクニック(開発編) より詳しくなりたい 人向けの余談
  13. XDP実装テクニック(テスト編) - BPF_PROG_RUN を利用してパケットパターンをテストしながらやると便利 - これを使うとXDPのプログラムに関してunittestが書ける - 注意点として状態を取得する機能はifdefマクロとか使ってmockしながら書くとよい - e.g.

    bpf_fib_lookupというNhopに繋がるIfaceとそのMACアドレスを返すヘルパー関数が ある, BPF_PROG_RUN はInterfaceとその対抗にあるサービスを模倣してくれる機能では ないのでbpf_fib_lookupがまともに動かない。mockするのがおすすめ - virtme を利用することで仮想環境でテストすると言う手もあるが、CIの速度などを考える とunittestの方から始める方が簡便でおすすめ - xdpcapを初めから使いながら実装する - tcpdumpは通常のプロトコルスタックで動く なのでXDP_PASSしたもの以外はパケットキャプチャできない - xdpcapはXDPの処理が終わる時にパケットをMapに詰めることによってpcapにしてくれる機能 - XDPでもtcpdumpができて便利。printkと併用して使うのがおすすめ より詳しくなりたい 人向けの余談
  14. - CPU毎に処理を分散させる事を意識する - 割り込みを単一のCPUに偏らせない実装が重要となる。irq_affinityなどの設定が大事。 - RSSフレンドリーなパケット構造で取り扱う - NICレベルで5TupleHash等のロードバランスすることでCPU毎にパケットを分散 できる。ただし、モノによっては十分にHashKeyが分散されない為、工夫が必要となる -

    Printkは実運用ではコンパイル時にマクロで無効化させておく - ioがあると速度に影響する。(ioがあると遅いのはそうですね...😅) - `#define DEBUG_PRINT(fmt, ...) (void)0` みたいな感じにifdefマクロで書き換えるのが便利 - eBPF Mapの取り扱いは PerCPU で利用するべき - PerCPUじゃない場合eBPF Mapの読み書きでロックが取られてしまうので遅くなる - できればMapLookupの回数を減らし、CPUキャッシュに乗ることを考慮して、Mapの中身を小 さくする XDPで意識するべき高速化テクニック より詳しくなりたい 人向けの余談
  15. より詳しくなりたい!知りたいぜ!という人向け資料 高速化の話が気になればぜひ 自作パケット処理系の性能測定と可視化&改善のPDCAを 回して最強のパケット処理系の作り方を学ぼう / Let's Measure the Performance of

    Packet Processing System with Python Tools. (弊社CTOが書いた資料) テクニックとかならぜひ パケット処理の独自実装や高速化手法の比較と実践 独自パケット処理実装方法の解説(XDP)
  16. XDPの採用事例紹介 - Isovalent, Cisco / Cilium(KubernetesのCNIやセキュリティ) - Meta / Katran(L4Loadbrancer)

    - Cloudflare / Gatebot(DDoS Mitigation), Unimog(L4Loadbrancer) - 国内だと - LINEヤフー / L4LB, SRv6 - MIXI / StaticNAT, PayloadCutterなど - さくらインターネット&BBSakura Networks /パケット交換機(PGW-U)
  17. XDPの採用事例紹介 - Isovalent, Cisco / Cilium(KubernetesのCNIやセキュリティ) - Meta / Katran(L4Loadbrancer)

    - Cloudflare / Gatebot(DDoS Mitigation), Unimog(L4Loadbrancer) - 国内だと - LINEヤフー / L4LB, SRv6 - MIXI / StaticNAT, PayloadCutterなど - さくらインターネット&BBSakura Networks /パケット交換機(PGW-U) 弊社も使ってます!
  18. • BBIXとさくらインターネットの合弁会社 • 2019年8月1日設立 • ネットワークサービスのソフトウェア開発 • 親会社を通じてソフトウェアを世に出している • すべての「モノ」がつながる社会の実現に向け、プラットフォーム

    (OCX) 提供を通じてネットワークサービスのクラウド化を進めています 開発や運用をしているサービス • さくらのセキュアモバイルコネクト • さくらのショートメッセージサービス • BBIXお客様向けポータル • OCX (Open Connectivity eXchange) ここでXDPを使っています:) 再掲
  19. LTEアーキテクチャ UE eNB HSS MME PGW-U SGW S1-U S5 SGi

    S6a LTE-Uu S1-MME UE: User Equipment eNB: eNodeB, evolved Node B MME: Mobility Management Entity HSS: Home Subscriber Server SGW: Serving-Gateway PGW-C: Packet Data Network-Gateway Controlplane PGW-U: Packet Data Network-Gateway Userplane The Internet & Cloud (& Operator network) S11 PGW-C GTPv1-Uトンネル: GTPv2-Cトンネル: MNO MVNO ここでXDPが 動いてます! スマホやIoT 機器とか... モバイル網では、 GTP-U ヘッダに カプセル化されている
  20. 自作PGW-Uの紹介 - eBPF/XDP製のPGW-U(パケット交換機) - クラウド上のスイッチたちとVLANで繋がってて、そこを通じてさくらの各種インスタンスまで繋がる - 必要な処理: GTP-UヘッダーのEncap/Decap, NAPT, 網内折り返し,

    Routing…etc - コントローラーやハンドラはGoで書かれている - 規模的にはCP: 9000行, DP: 1600行程度 ローミング網 PGW-C PGW-U さくらのクラウド上の スイッチたち VLAN VLAN VLAN VLAN IDを変換しつつ通信に必要な処理を全部やる インターネット さくらの各 種インス タンス ENOG63 モバイルネットワークのデータプレーンをXDPで作る話より図一部改訂し引用
  21. 自作PGW-Uの全体像 MGW - eBPF MapsにMGWと呼ばれる顧客毎のサービスエンティティを作成してる - PGW-C(交換機の制御装置)からのトンネル作成リクエストをハンドルして、 eBPF Mapsにセッションデータを書き込むことで実現している -

    帯域制御のためにTCも併用している - dummy InterfaceはProxy ARPのために設置 - Proxy ARPしたい経路をここに向けることでVLANインターフェースからのARPに応答する - XDP_PASSすることでARPの処理をカーネルに丸投げ mgw vrf vlan dummy roaming mgmt global vrf global default vrf eth0 XDP vlan vrf eth1 VLAN trunkなポートに接続さ れている TC eBPF Maps FIB Table C-Plane API netlink(3) bpf(2) netlink(3) bpf(2) スタティックルート機能で設定し た経路はここに入る インターネットに抜けるための VRF ENOG63 モバイルネットワークのデータプレーンをXDPで作る話より図一部改訂し引用
  22. - XDP metadataがVLAN対応をしていなかった - XDP_PASS時にXDP metadataにIDを書き込むことでTC(帯域制御)の対象を識別している - [v3] net: Fix

    missing meta data in skb with vlan packet - VLANのパケットはskbが生成されるときにuntagされる - その時に呼ばれる、skb_reorder_vlan_header()でXDP metadataがmemcpyされずに 置いて行かれてデータが破損していた - 弊社のCTOとお手伝いで自分もやった - virtio_net がXDP metadataに対応していなかった - [bpf-next,v6,2/2] virtio_net: add XDP meta data support - 弊社のCTOがスッと追加した 苦労話
  23. 更なるチャレンジへ - 研究開発でIntel ICEに対してGTPパケットに対してRSSを効かせられる機能 をLinuxに入れてもらった。ethtoolで使えるようになった - これは自分が実施した - https://www.spinics.net/lists/netdev/msg979517.html -

    現在はvirtio_netでも対応を目指している。これにより本プロダクション 環境でもより高速で高効率な動作が期待される(かも) - https://gitlab.com/takehaya/qemu/-/tree/feature/gtp_rss?ref_type=heads - お試し実装中...🐈