Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
P4とICTSCにおいての利活用例
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Takeru Hayasaka
March 07, 2021
Technology
620
1
Share
P4とICTSCにおいての利活用例
Takeru Hayasaka
March 07, 2021
More Decks by Takeru Hayasaka
See All by Takeru Hayasaka
Go Conference 2025: Goで体感するMultipath TCP ― Go 1.24 時代の MPTCP Listener を理解する
takehaya
10
2.7k
eBPF at Mobile Network Data Plane
takehaya
0
240
Programmable Bandwidth Management with eBPF
takehaya
2
460
eBPF Deep Dive: Architecture and Safety Mechanisms
takehaya
14
3.2k
Perlで始めるeBPF: 自作Loaderの作り方 / Getting started with eBPF in Perl_How to create your own Loader
takehaya
3
4.5k
Exploring XDP: Fundamentals and Real-World Implementations in Mobile Network Data Plane
takehaya
1
5k
JANOG53 LT 自作k6 Extension利用した NFVへの負荷計測手法の紹介
takehaya
0
1.1k
Wakamonog13 LT: VPPで始めるHigh Performance BGPルーター
takehaya
2
2.5k
自作パケット処理系の性能測定と可視化&改善のPDCAを回して最強のパケット処理系の作り方を学ぼう / Let's Measure the Performance of Packet Processing System with Python Tools.
takehaya
4
6k
Other Decks in Technology
See All in Technology
【関西製造業祭り2026春】現場を変える技術はここまで来た〜世界最大の製造業見本市から持って帰ってきたもの〜
tanakaseiya
0
190
Databricks 月刊サービスアップデートまとめ 2026年04月号
tyosi1212
0
130
SpeechTranscriber + AIによる文字起こし機能
kazuki1220
0
120
マンション備え付けのネットワークとLTE回線を組み合わせた ネットワークの安定化の考案
harutiro
1
140
そのSLO 99.9%、本当に必要ですか? 〜優先度付きSLOによる責任共有の設計思想〜 / Is that 99.9% SLO really necessary? Design philosophy of shared responsibility through prioritized SLOs
vtryo
0
850
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
15
100k
エンタープライズの厳格な制約を開発者に意識させない:クラウドネイティブ開発基盤設計/cloudnative-kaigi-golden-path
mhrtech
0
460
20260515 ID管理は会社を守る大切な砦!〜🔰情シス向け〜
oidfj
0
730
最新技術を"今は選ばない"という技術選定
leveragestech
PRO
0
280
AI飲み会幹事エージェントを作っただけなのに
ykimi
0
240
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
4.5k
"うちにはまだ早い"は本当? ─ 小さく始めるPlatform Engineering入門
harukasakihara
7
640
Featured
See All Featured
Agile that works and the tools we love
rasmusluckow
331
21k
Practical Orchestrator
shlominoach
191
11k
How to Get Subject Matter Experts Bought In and Actively Contributing to SEO & PR Initiatives.
livdayseo
0
120
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
2
810
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
YesSQL, Process and Tooling at Scale
rocio
174
15k
My Coaching Mixtape
mlcsv
0
130
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.8k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.3k
Everyday Curiosity
cassininazir
0
210
Large-scale JavaScript Application Architecture
addyosmani
515
110k
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
62
54k
Transcript
P4とICTSCにおいての 利活用例 Takeru Hayasaka(@takemioIO) 2021/03/07 ICTSC2020 LT会 https://unsplash.com/photos/JLkx0lRkXuk 1
アウトライン 1. Overview: P4とは 2. NAVTと実装について 3. まとめと感想 2
Overview https://unsplash.com/photos/ur7BDi9MpXg 3
パケット処理はどこでやる? • パケット処理可能な場所がいくつか存在する • Software?Hardware? • UserLand?KernelLand? • FPGA?ASIC?TPU?こんがり焼いた独自の石? •
処理技術も手法もいくつかある • LKM/netfliter queue/socket programing.. • XDP/ebpf/DPDK/netmap/PF_RING... • openflow/P4/SR-IOV/SmartNIC/Whitebox... • RSS/RPF/RFS/XPS... 4
ASICスイッチ • 近年ではパケット処理の速度がソフトウェアでは頭打ちへ CPU性能あたりの処理性能からASICを利用しつつ自由度の高い Programmable switchを選ぶようになってきた • CPU: 固定化された汎用チップ(ハーバード、フォンノイマン型など)に加え てGPIO,USBなどのペリフェラルが入ってるやつ
• FPGA: NANDなどできており、VHDLなどで書くと任意の回路を構築できる チップ • ASIC: 特定分野に特化したチップ. CPU, mem, 特定のパイプライン など従来の構成から肉抜きしたり増したりなどをした専用チップ つまりドメイン特化型のプロセッサの例となる 5
ASICスイッチを動かすOS(NOS) • 商用 • ArcOS (Arrcus) • Cumulus(NVIDIA) ←今年も使ってたNOS •
OcNOS (IP Infusion) • PicOS(Pica 8) • OSS • SONiC(frr-rpm + driver) • DENT(switchdev) • RARE(P4Runtime + P4)←今日の話はこれ これらを動かすOSひとつとってもかなりの種類があり、 また参画してる会社を見ても大規模データセンターでの 流行が見て取れることがわかる 6
P4: パケット処理特化プログラミング言語 P4: Programming Protocol-Independent Packet Processors ASICなどの専用ハードをターゲットとする プログラミング言語で、アーキテクチャごとのライブラリ とそれをもとにP4でパケット処理系を書くことができる
以下の図はP4の全体アーキテクチャ 7 cf. https://p4.org/assets/P4_D2_East_2018_01_basics.pdf
P4Switchアーキテクチャ 処理に関してもハードウェアごとにアーキテクチャがある 以下はBMv2と言われるP4で動くSoftwareSwitchだが 実際のハードウェアでも以下のように 「parser」「ingress」「egress」「deparser」でコンポーネント パケットを解析しつつ処理を行い最後に構築するというパイプラインで処理 される 8 cf. https://p4.org/assets/P4_D2_East_2018_01_basics.pdf
NAVTと実装について https://unsplash.com/photos/baII27W6z7k 9
NAVTの歴史 ICTSC6: LKMで実装 ICTSC7: Openflow+Ryu ICTSC8: LKM, ARP動的解決対応 ICTSC9-2018: Openflow+Ryu(7と同じ)
ICTSC2019: VPP SRv6 Function化(NAVTではなくこれは普通のNAT) 今回は.... P4 で 100GbE Ready!初めてのHW動作化!!!!! 10
NAVT with P4 Switch • NAVT: Network Address VLAN Translation
◦ トラコンの問題環境を支える変換プロトコル IP: src=172.16.2.1, dst=10.1.0.1 Ethernet: src=xxx, dst=yyy TCP: src=19485, dst=22 IP: src=172.16.2.1, dst=192.168.0.1 Ethernet: src=xxx, dst=yyy TCP: src=19485, dst=22 VLAN: vid=100 再掲
NAVT with P4 Switch 192.168.4.1 192.168.4.1 10.1.4.1 10.20.4.1 再掲
NAVT with P4 Switch • NAVT: Network Address VLAN Translation
◦ トラコンの問題環境を支える変換プロトコル IP: src=10.7.4.1, dst=160.16.73.123 Ethernet: src=xxx, dst=yyy TCP: src=58193, dst=443 IP: src=192.168.4.1, dst=160.16.73.123 Ethernet: src=xxx, dst=yyy TCP: src=58193, dst=443 VLAN: vid=700 再掲
NAVT with P4 Switch • 今年はP4を用いてNAVTの実装を行った ◦ https://github.com/takehaya/p4-navt • ハードウェアのP4スイッチをお借りした
◦ Edgecore Wedge 100BF-32X 再掲
機材と協賛様 実際のP4専用ハードとしては BarefootTofinoと呼ばれる専用ASIC が有名であり今回我々も採用した 機材はAPPRESIA SYSTEMS 様から Edgecore Wedge 100BF-32X
これを活かすためにコアで利用した 10G NICはさくらインターネット様よりお 借りした。 この場を借りて感謝申し上げる🙇♀🙇♀ 15 WedgeとMellanox が100Gで接続されている
P4Switchアーキテクチャ 処理に関してもハードウェアごとにアーキテクチャがある 以下はBMv2と言われるP4で動くSoftwareSwitchだが 実際のハードウェアでも以下のように 「parser」「ingress」「egress」「deparser」でコンポーネント パケットを解析しつつ処理を行い最後に構築するというパイプラインで処理 される 16 cf. https://p4.org/assets/P4_D2_East_2018_01_basics.pdf
再掲
NAVTの実装について NAVT(https://github.com/takehaya/p4-navt )について説明する P4は parser, ingress, egress, deparserというコンポーネントで 作られているので今回はどこでどのような処理をすると実装できるか を説明していく
Parser: P4においてパケットをどこまで読むかを示すところ。 例えばL3までのパケットしか処理をしないなどはここで示す 17
Parsing Graph 18 IPv4 Ethernet IPv6 dot1q TCP UDP L2
L3 L4
Parsingのコード 19
NAVTの実装について Ingress: P4においてパケット処理を行う場所。 多くのパイプラインではIngressで処理を行う。 また今回は実装していないがCPU側(つまりコントローラー側) にパケットを一度転送するかはここで判断する またNAVTの処理部分もここで行われる 20
ingressのコードのmain関数的部分 21
ingressのコードのdot1qがあるかの解析 22 ここでは vlanが存在すれば dot1qを変数に保存しておき tagであるとフラグを立てる もしそうでなければethertypeだけ保存 をしておく
ingressのコードのNAVT部分その1 23 二つのテーブルを宣言してる inside: 外側から内側へを司る key: vlanID value: vlan/100の値, dst
macaddr outside: 内側から外側へを司る key: /16の経路を表現できるlpm value: vlanID, dst macaddr
ingressのコードのNAVT部分その2 24 ←許可されないアドレスなのでdrop ↑皆さんからきたパケットではな いのでdrop ←ちょうどNATしているところ 内部=>外部 ←ちょうどNATしているところ 外部=>内部
Egress: P4において後処理を行うことが多い。 例えばDecapしたdot1q hdrをここで付け直したりどこのポートにルーティン グするかを判断する。 今回はここでdot1q encapを行っている NAVTの実装について 25
egressのコード 26 ingressで保存した値を利用して ここでdot1qをEncapをする
NAVTの実装について Deparser: 処理を行ったパケットのうちどのパケットを外部に構築して出力 するのかを司る。 27
deparserのコード 28 emitした順にパケットが出力される これだけ見るとdot1qもなんとなく 必ずつけられそうに見えるが dot1q hdrが不正であるという フラグを立てておくことで 回避できる(e.g. setInvalid
)
動作に関する情報 • 開発においての一週間のsflowのログを見るとピークで7Gbps ほどがパケットが流れていたが本大会ホットステージから 一度たりともハングや再起動がなく動作した 29
動作に関する情報 30 • 開発においての一週間のsflowのログを見るとピークで7Gbps ほど、合計で180GB程度流れていたが 一度たりともハングや再起動がなく動作した🎉
測定 • 今回のサーバー的に10GbE x 8本程度なので限界値を出すことは 難しいが、単純なperfだと9Gbpsぐらいは出そう 31
NAVT with P4 Switch 再掲 • 今回のサーバー的に10GbE x 8本程度なので限界値を出すことは 難しいが、単純なperfを同時にしたらこんな感じ
• おそらくだがバックエンドでcephが動いてるノードなので性能が 出ず...正しく測定する機材がなく....(涙)100GbE NICが欲しい
まとめと感想 • P4+Tofinoを利用したNAVTを実装した • Tofino実機デバッグがしんどい2021 • tcpdumpが使えない • RX,TXのカウンタが回っているか、Tableにつけておいた カウンタが動いているかなどで見るしかなく
Softwareでパケット処理するのは簡単なんだなと思った • シミュレーターと実機では全く挙動が違くてしんどい • OSS版(BMv2)は表現力が高く便利だがTofinoはつらい • bitshiftとかで表現ができなくて涙が出る • https://github.com/takehaya/p4-navt でBMv2バージョン は公開されているので遊んでみてください • https://github.com/takehaya/p4_vagrant_playground を使うと P4とBMv2で遊ぶ環境を手に入れれて便利 33