Upcoming SlideShare
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. ご清聴ありがとうございました
Login to see the comments