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