![implementation
• 本当に動くのだろうか?
• Ryu アプリとして実装
OFS
OFC
APP
Frontend[HTTP POST]
調査したいヘッダを持つフレーム，
Traceroute 開始地点
受け取ったフレームに
Probe マーク挿入
metadata 付けて
PACKET_OUT
……
PACKET_IN
[HTTP WebSocket]
フレーム内容を解析して
ユーザに報告
……](https://image.slidesharecdn.com/tremaday8-151212034112/85/OpenFlow-Traceroute-11-320.jpg)
お手軽 OpenFlow Traceroute
- 2. self • ISP 勤務 – システム/ソフトウェア開発 – ここ最近は OpenFlow とか Overlay とか – 対外 (趣味?) でもたまにネタがあれば • Web ブラウザ上で L2 Learning Switch とか • Linux カーネルの PF_PACKET 周りとか vxlan ドライバとか • libpcap の Q-in-Q (IEEE 802.1ad) 対応とか • etc… 著者近影
- 3. OpenFlow traceroute • 欲しかったもの – ある L2 フレームの本番 flow entries に従った転送経路を調べたい • ethertype へのマッチ等はよく使うので IP には限定したくない – OFC での静的解析ではなく，実際にフレームを流す動的解析がしたい • 条件 – なるべく本番 flow entries に手を入れたくない • 本番トラフィックが流れてる最中でも使えるのが理想だが… – なるべく条件を緩くしたい (可搬性) • 例えば「VLAN ID を 100 個ほどシステム予約します」とか… • 例えば「システム都合で 10,000 個ほど flow entries 突っ込みます」とか… – なるべく vendor extensions は使いたくない (可搬性) – 手軽に実装したい (人間の負荷) – 手軽に使いたい (人間/機械の負荷)
- 4. related works • アカデミアの偉大な先人達 – Stanford: “ndb” (SDN Debugger) • flow entries を細工して，経路途中の OFS からデータを PACKET_IN • OFC で PACKET_IN データを集めて backtrace を生成 – IBM: “SDN Traceroute” • 経路途中の OFS から PACKET_IN するのは一緒だが， flow entry に細工せず済むように色々と頑張っている • 前段で OFS の隣接関係を調査し，更にグラフ彩色問題を解いて， 隣接 OFS が同色にならないようにする • 隣接 OFS の色の数ほどシステム側で flow entries を追加投入 • 色の数ほど VLAN PCP 値を (全体で) 予約 – 必ずしも PCP である必要はなく，本番で使わないフィールドなら何でも良い – etc, etc, etc…
- 5. survey • 欲しいものに一番近いのは IBM “SDN Traceroute” – 前段で OFS の隣接関係 (トポロジ) 検出? • トポロジ情報がないと traceroute の実施ができない – グラフ彩色? • トポロジをグラフに見立てて OFS を色分け • グラフ彩色問題と言えば NP 困難/完全の代名詞では… • トポロジが変化するとグラフ彩色やり直しになる もうひと工夫すれば，グラフ彩色等せずとも実現できるのでは…?
- 6. strategy • 基本構造は既存研究と同じで良い OFS OFS OFSOFS OFC 始点を指定して traceroute 実行命令 Probe マーカに反応して PACKET_IN 以降繰り返し… 通過した OFS を報告 Probe マーカを付けたフレームを OFPP_TABLE 指定して PACKET_OUT ※ もし転送と PACKET_IN を全部 OFS に任せる形にすると， OFS-OFC 間の遅延状況等次第で報告順が前後してしまう
- 7. study • この場合 traceroute に必要な flow entry とは… – 基本形は下記だが，何も考えずに投入すると… priority=0xffff,<marker-field>=<reserved> actions=output:controller OFS OFC Probe マーカを付けたフレームを OFPP_TABLE 指定して PACKET_OUT Probe マーカに反応して PACKET_IN たいへん危険ですのでおやめください
- 8. review • 外から来た probe と，controller から来た probe を判別するための「何か」が必要 – “SDN Traceroute” では，これを “色” で解決していた • 隣接する OFS はそれぞれ別の色になっている • 自分以外の色でマークされた Probe だけ OFC へ渡す • 必要な flow entry 数は，隣接 OFS の色の数 • 色の数ほど Probe マークのための値を (全体で) 予約 • この “色” を着けるために，トポロジ検出したりグラフ彩色問 題を解いたりする必要があった
- 9. design • “判別” に，外に出たら消えてしまうフィールドを用いれば良い! – metadata • 一番使いやすく，side effect もない • 仕様上は set-field action が許可されるのは OF 1.5 から – とはいえ OVS などは 1.3 とかでも可能 – tunnel_id • 仮想ネットワーク ID を OpenFlow 的に操作しない環境では metadata と同じと 考えることができる • 上記環境以外では side effect があるため使いづらい “判別” 出来さえすれば，無理にフレーム自体を書き変える必要はないのでは…?
- 10. flow entry • 例えば VLAN PCP=7 を probe マークに使う場合 table=0,priority=0xffff,metadata=0,dl_vlan_pcp=7 actions=controller – OFC は，PACKET_OUT メッセージの actions に set_field:1->metadata, output:OFPP_TABLE などと指定するだけで良い – traceroute に必要な flow entry は 1 つだけ! – probe マークに必要な予約値も 1 つだけ! – トポロジ検出やグラフ彩色等の前処理も必要なし! – お手軽!!
- 11. implementation • 本当に動くのだろうか? • Ryu アプリとして実装 OFS OFC APP Frontend[HTTP POST] 調査したいヘッダを持つフレーム， Traceroute 開始地点 受け取ったフレームに Probe マーク挿入 metadata 付けて PACKET_OUT …… PACKET_IN [HTTP WebSocket] フレーム内容を解析して ユーザに報告 ……
- 13. topology • やっぱりトポロジも知りたい? • OFS 隣接関係検出機能は持っていない • でも他アプリとの共存は可能なので • 例えば Ryu ビルトインのトポロジ検出と連携
- 15. ありがとうございました