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