Mais conteúdo relacionado Semelhante a OpenFlow OAM ツール - OKINAWA Open Days 2014 Day1 (20) OpenFlow OAM ツール - OKINAWA Open Days 2014 Day11. OpenFlow OAM ツール
OKINAWA Open Days
2014/12/11
Satoshi KOBAYASHI
(satoshi-k@stratosphere.co.jp)
2. 目次
• 自己紹介
• ツールの概要
• 現時点での成果
• 今後の展望
• まとめ
4. 自己紹介
• 名前
– 小林智史(Satoshi KOBAYASHI)
• 所属
– 株式会社ストラトスフィア
• 備考
– Ryu SDN Framework コントリビュータ
6. 概要
• OpenFlow OAM ツール
– NTTコミュニケーションズ様が主導
– ストラトスフィアが開発を担当
• 目的
– うちのOpenFlow ちゃんと動いてる?
• あるべきネットワーク構成に今なってる?
• おかしくなったことをどうやって知る?
• お客さんから問い合わせがあったときどう調べる?
9. トポロジの管理
• ゴール
– あるべきネットワーク構成と現状が比較できる
• スイッチがコントローラに繋がっているか
• ポートは生きているか
• 隣のスイッチと繋がっているか
• etc
11. 一般的な手法
• LLDP (Link Layer Discovery Protocol)
– 主要なOpenFlow コントローラに実装がある
• Ryu, Floodlight, OpenDaylight, etc
機器識別子、ポート識別子など
Ethernet LLDP
12. LLDP を使った隣接スイッチの見つけ方
OpenFlow
コントローラ
OpenFlow
スイッチA
4. A:X とB:Y は隣接してる!
OpenFlow
スイッチB
Packet Out
送信: A:X
ポートX ポートY
LLDP
(送信元A:X)
Packet In
受信: B:Y
1. Packet Out
メッセージの送信
2. LLDP パケット
を送信
3. LLDP パケットを
コントローラへPacket In
13. もうあるなら、それ使えばいいじゃん?
• LLDP の問題点
– 間に普通のスイッチやFW がいると落とされる
• 既存の機器をLLDP が通るようにしなければいけない
OpenFlow
スイッチ
OpenFlow
ポートスイッチポート
LLDP
何だこれ…?
ポート既存の機器ポート
14. Ryu の組み込みアプリにも問題あり
• Ryu のトポロジ検出アプリの問題点
– 発見したオブジェクトを永続化できない
• スイッチ、ポート、リンク
• いなくなった時点で消えてしまう
– コードが汚い!
15. どう解決するか(LLDP)
• LLDP の問題解決
– 落とされにくいプロトコルを使う
• TCP/UDP/ICMP
• ユーザのトラフィックに紛れ込ませる
– 区別できるように使っていないポートなどを選んで使う
機器識別子、ポート識別子など
Ethernet IP TCP
Probe
落とされにくいパケットの例
17. システム構成
管理用Web UI
Ryu SDN
Framework
OpenFlow
スイッチ
OpenFlow
スイッチ
OAM
アプリケーション
トポロジ
DB
オペレータ
開発範囲
操作
REST / WebSocket
OpenFlow
Connection
検出したトポロジ
情報を永続化
19. 今後解決すべき課題
• あるべき姿と現状の比較部分の実装
– トポロジの検出まではできた
– こうなっていてほしいトポロジと比較したい
Switch
Port
理想
Port
Switch
Switch
Port
Port
Switch
Port
現実
Port
Switch
Switch
Port
Port
比較
21. フローエントリの管理
• ゴール
– 想定通りの内容が入っているか調べられる
• こういう通信がしたい
• なら、このフローエントリがないといけない
• 余計なフローエントリが入っていないか?
25. 今後解決すべき課題
• モデリング
– OpenFlow の表現力をなるべく落とさない
• フロールールへの変換
– スイッチ実装の差異*1を吸収するアルゴリズム
• フローエントリの比較
– 意図どおりの内容が入っているか
*1 参考: Ryu Certification
http://osrg.github.io/ryu/certification.html
26. 疎通性の確認
• ゴール
– 実際にトラフィックが流れるか試せる
• Ping
• Traceroute
• Traceroute + α
28. Traceroute
• どのスイッチ・ポートを通ったか
– a -> b -> d -> e -> h -> z
Switch A
Switch B
OpenFlow ネットワーク
Switch Z
a b
d
e
h
Switch C z
c
f
g i
Traceroute
29. Traceroute + α
• どのフローエントリにマッチしたか
– 2 -> 6 -> 7
Switch A
Switch B
OpenFlow ネットワーク
Switch Z
a b
d
e
h
Switch C z
c
f
g i
Traceroute
+ α
1
2
3
4
5
6
7
8
9
Traceroute
+ α
31. まとめ
• OpenFlow を便利にするツール作ってます
– トポロジ検出までできました
– フローエントリのモデリングしてます
– コントローラにRyu 使ってます
Notas do Editor このプレゼンは先ほど本田さんからお話があった OAM のツール (OFURO) を作っています、というものです
Ryu を使っているので、Ryu の活用事例としても見てもらえれば 今の構成がほんとにあってるのか?
昨日まで動いてたスイッチが突然死んだら?
OpenFlow でネットワークを組んだとして、お客さんから「なんか繋がらないんですけど〜?」って言われたらどう調べる?
OpenFlow のネットワークを管理するためのツールや知見が巷にほとんど無い、あるいはすごく探さないと見つからない状態
商用コントローラを買えばそこら辺も含めて一式用意してくれるのかもしれないけど… ツールでは主に3つのことをやりたい
それには上から一つずつ進めていく必要があると考えている
最終的なゴールは一番下
それぞれの詳細については後ほど詳しく まず、現状で基本的な部分ができているトポロジの管理で目指しているゴールは、本来こうあるべき、という構成と今が違っていないか調べられること それにはまず、今のトポロジ、ようするにスイッチ同士がどう繋がっているかを知らなきゃいけない トポロジを調べる一般的な方法としては LLDP というプロトコルを使うやり方がある
これは既に Ryu はもちろん、主要な OpenFlow コントローラフレームワークで実装がある LLDP を使ったスイッチ同士のつながり、リンクを見つける一般的な方法の解説
まず Packet Out メッセージで特定のスイッチ、ポートから LLDP パケットを投げさせる
メッセージを受け取ったスイッチは LLDP パケットを投げる
つながっているスイッチに LLDP パケットが届いたら、フローエントリや Table Miss に基いて Packet In する
これでコントローラはスイッチ同士がつながっていることがわかる
なら、もうあるやつをそのまま使えばいいじゃん?って話になる
LLDP は Ethernet に直接載るし、そうそう普段使われるものではないと思う
まっさらなネットワークをゼロから作るならいいのかもしれないけど、そうじゃないなら既存の機器を LLDP 対応のものに置き換えたり、通すルール入れて回らなきゃいけない
Ryu が実装している LLDP アプリにも問題がある
現状だと発見したリンクやスイッチを永続化できない
スイッチがコントローラから切断されると、もう見えなくなる
今の状態もそうだけど、過去何があったかも見たい
あとこれも問題になった。コードが汚い
途中まで既存のアプリを改修する形で進めてたけど、今後を考えるとちょっとないなと
じゃあ、さきほどの問題をどう解決していくか
まず、LLDP は落とされにくいプロトコルを使う
ユーザが普段使っているようなプロトコルを使うことで、間の機器に落とさせないようにする
ただし、普段使っているプロトコルでも、ユーザが使っていないポートとかを選んで使うことで完全には混ざらない (区別できる) ようにする
アルゴリズムは基本的な部分は変えない。プロトコルを変えるだけ。
これはもうそのまんまですね
汚いなら、スクラッチで書くと
ここからは実際に作ったものの説明
普通の Ryu のアプリケーションとして実装した
WebUI を通して操作できるようにしている
見つけたものはデータベースに永続化する
理屈ばかり見てもらっても仕方ないので、実際に動いているところを見てもらう
全然グラフィカルじゃないけど、そういうのは後回しで 現状でトポロジを見つけることはできた
こうなっていてほしいトポロジと比較して、あっているか調べる機能を作っていきたい ここまでは主に今できていること
ここからは今やっていることと、これからやること
夢を語る 次はフローエントリの管理について
ゴールは意図したフローエントリがスイッチに入っているか調べられるようにすること
こういう通信がしたいです、という意図の設定が入っているか?
じゃあ比較できるようにするには、何から始めたら良いか?
まずはトポロジなどの情報を元に「こういう通信がしたい」を表すモデルが必要になるはず
現状はない
例えばスイッチ A の a ポートとスイッチ Z の z ポートをつなぎたい、っていうのを表現するモデル こういう通信がしたいです、と直接フローエントリを比較するのはしんどそう
なので、もう一段モデルを作ることにした
さっきのモデルよりも抽象度を落として、スイッチ単位の「こういう通信がしたいです」というモデル
こちらから着手している
あとはモデルからフローエントリを自動で作れるようにする
「こういう通信がしたいです」モデルと、それをスイッチ単位にしたモデル、そしてフローエントリ
上のモデルから下のモデルに変換していく
OpenFlow はアセンブラに比喩されることもある
モデルは高級言語と言えるかも
フローエントリの管理で解決しなきゃいけないのは大きく3つあると考えている
まずモデリング、フローエントリを抽象化したい
ただし OpenFlow でできる表現力というか機能を落としたくない、けど分かりやすく絶妙なさじ加減で
次にフロールールへの変換
モデルをフロールールに変換するアルゴリズム
ここでの問題は OpenFlow スイッチの実装がバラバラなこと
参考までに、バラバラさは Ryu Certification を見るとよくわかる
OpenFlow スイッチはサポートしてる機能がバラバラなので、その違いをうまいこと吸収しなきゃいけないかも
残りはフローエントリの比較アルゴリズム
意図した通りのフローエントリなどが入っているか
最後に疎通性の確認
これのゴールは実際にトラフィックを流してみて動くか確認できるようにする
やりたいのは Ping っぽいこと、Traceroute っぽいこと、Traceroute + α
それぞれはこれから説明する まずは Ping
そのまま
あるポート a からあるポート z への疎通があるか 次に Traceroute
こちらはどのスイッチのどのポートを通ったのか知りたい
こっちを回ったのかそれともこっちを回ったのか 最後に Traceroute + α
これはさきほどの Traceroute に加えて、マッチしたフローエントリまで知ることができる、というもの
疎通性の確認で解決すべき課題は各手法の検討
Ping や Traceroute の手法は既にいくつか論文がある
マッチしたフローエントリを知る Traceroute + α はまだ誰もできていない未知の領域
ほんとにできるかわからないけど、これができるとうれしい
一言で言うと OpenFlow を便利にするツールを作ってる
今できているのはトポロジの検出まで
今はフローエントリを抽象化したモデルを考えている
コントローラには Ryu を使っている
最後にちょっとだけ Ryu を実際に使っている人間から宣伝みたいなもの
Ryu を使ったおかげで、実装が短時間でできた
使い慣れている言語に使い慣れているフレームワークという理由もあるが
トポロジを調べるところの基礎的な部分は UI 含めて正味 2 週間かからないくらいでできた