SlideShare uma empresa Scribd logo
1 de 32
Baixar para ler offline
OpenFlow OAM ツール 
OKINAWA Open Days 
2014/12/11 
Satoshi KOBAYASHI 
(satoshi-k@stratosphere.co.jp)
目次 
• 自己紹介 
• ツールの概要 
• 現時点での成果 
• 今後の展望 
• まとめ
自己紹介
自己紹介 
• 名前 
– 小林智史(Satoshi KOBAYASHI) 
• 所属 
– 株式会社ストラトスフィア 
• 備考 
– Ryu SDN Framework コントリビュータ
ツールの概要
概要 
• OpenFlow OAM ツール 
– NTTコミュニケーションズ様が主導 
– ストラトスフィアが開発を担当 
• 目的 
– うちのOpenFlow ちゃんと動いてる? 
• あるべきネットワーク構成に今なってる? 
• おかしくなったことをどうやって知る? 
• お客さんから問い合わせがあったときどう調べる?
ゴールまでの道のり 
• トポロジの管理 
– 大体できた 
• フローエントリの管理 
– 今やってる 
• 疎通性の確認 
– これから
現時点での成果
トポロジの管理 
• ゴール 
– あるべきネットワーク構成と現状が比較できる 
• スイッチがコントローラに繋がっているか 
• ポートは生きているか 
• 隣のスイッチと繋がっているか 
• etc
トポロジを調べる 
• スイッチ同士がどう繋がっているか 
OpenFlow 
スイッチ 
ポートポート 
OpenFlow 
スイッチ 
OpenFlow 
スイッチ 
ポート 
リンク 
OpenFlow 
スイッチ 
ポート 
ポート 
ポートポート 
ネットワークトポロジ 
ポート
一般的な手法 
• LLDP (Link Layer Discovery Protocol) 
– 主要なOpenFlow コントローラに実装がある 
• Ryu, Floodlight, OpenDaylight, etc 
機器識別子、ポート識別子など 
Ethernet LLDP
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
もうあるなら、それ使えばいいじゃん? 
• LLDP の問題点 
– 間に普通のスイッチやFW がいると落とされる 
• 既存の機器をLLDP が通るようにしなければいけない 
OpenFlow 
スイッチ 
OpenFlow 
ポートスイッチポート 
LLDP 
何だこれ…? 
ポート既存の機器ポート
Ryu の組み込みアプリにも問題あり 
• Ryu のトポロジ検出アプリの問題点 
– 発見したオブジェクトを永続化できない 
• スイッチ、ポート、リンク 
• いなくなった時点で消えてしまう 
– コードが汚い!
どう解決するか(LLDP) 
• LLDP の問題解決 
– 落とされにくいプロトコルを使う 
• TCP/UDP/ICMP 
• ユーザのトラフィックに紛れ込ませる 
– 区別できるように使っていないポートなどを選んで使う 
機器識別子、ポート識別子など 
Ethernet IP TCP 
Probe 
落とされにくいパケットの例
どう解決するか(Ryu) 
• Ryu のトポロジ検出アプリの問題解決 
– オブジェクトをデータベースに永続化する 
– スクラッチで書く
システム構成 
管理用Web UI 
Ryu SDN 
Framework 
OpenFlow 
スイッチ 
OpenFlow 
スイッチ 
OAM 
アプリケーション 
トポロジ 
DB 
オペレータ 
開発範囲 
操作 
REST / WebSocket 
OpenFlow 
Connection 
検出したトポロジ 
情報を永続化
動作デモ
今後解決すべき課題 
• あるべき姿と現状の比較部分の実装 
– トポロジの検出まではできた 
– こうなっていてほしいトポロジと比較したい 
Switch 
Port 
理想 
Port 
Switch 
Switch 
Port 
Port 
Switch 
Port 
現実 
Port 
Switch 
Switch 
Port 
Port 
比較
今後の展望
フローエントリの管理 
• ゴール 
– 想定通りの内容が入っているか調べられる 
• こういう通信がしたい 
• なら、このフローエントリがないといけない 
• 余計なフローエントリが入っていないか?
現状の問題点 
• こういう通信がしたい、を表すモデル 
– 例えばあるポートとポートの間をつなぎたい 
– 現状、ない 
Switch A 
Switch B 
OpenFlow ネットワーク 
Switch Z 
a b 
c 
d 
e z
ちょっと抽象度を落として 
• もう一段モデルを作る 
– スイッチ毎の「こういう通信がしたい」を表す 
もの 
Switch A 
Switch B 
OpenFlow ネットワーク 
Switch Z 
a b 
c 
d 
e z 
モデル 
モデル 
モデル
フローエントリに変換する 
• モデルからフローエントリを自動生成する 
Switch A 
Switch B 
OpenFlow ネットワーク 
Switch Z 
a b 
c 
d 
e z 
モデル 
モデル 
モデル 
フロー 
テーブル 
など 
フロー 
テーブル 
など 
フロー 
テーブル 
など
今後解決すべき課題 
• モデリング 
– OpenFlow の表現力をなるべく落とさない 
• フロールールへの変換 
– スイッチ実装の差異*1を吸収するアルゴリズム 
• フローエントリの比較 
– 意図どおりの内容が入っているか 
*1 参考: Ryu Certification 
http://osrg.github.io/ryu/certification.html
疎通性の確認 
• ゴール 
– 実際にトラフィックが流れるか試せる 
• Ping 
• Traceroute 
• Traceroute + α
Ping 
• あるポートからあるポートまで疎通があるか 
Switch A 
Switch B 
OpenFlow ネットワーク 
Switch Z 
a b 
c 
d 
e z 
Ping 
– a -> z
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
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 
+ α
今後解決すべき課題 
• 各手法の検討 
– Ping やTraceroute に関しては幾つか論文あり 
– Traceroute + α は未知の領域
まとめ 
• OpenFlow を便利にするツール作ってます 
– トポロジ検出までできました 
– フローエントリのモデリングしてます 
– コントローラにRyu 使ってます
ご清聴ありがとうございました

Mais conteúdo relacionado

Semelhante a OpenFlow OAM ツール - OKINAWA Open Days 2014 Day1

運用管理を楽にしたいという話
運用管理を楽にしたいという話運用管理を楽にしたいという話
運用管理を楽にしたいという話Hisashi HATAKEYAMA
 
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけてAgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけてShuji Morisaki
 
ユーザーストーリーワークショップ
ユーザーストーリーワークショップユーザーストーリーワークショップ
ユーザーストーリーワークショップYou&I
 
月間 250 億 imps 配信するために fluct が考えていること!
月間 250 億 imps 配信するために fluct が考えていること!月間 250 億 imps 配信するために fluct が考えていること!
月間 250 億 imps 配信するために fluct が考えていること!MasamichiIdeue
 
Open capi meetup20180409 (revised)
Open capi meetup20180409 (revised)Open capi meetup20180409 (revised)
Open capi meetup20180409 (revised)Yutaka Kawai
 
2015-10-31 クラウドネイティヴ時代の運用を考える 〜 ドキュメント駆動運用へ
2015-10-31 クラウドネイティヴ時代の運用を考える  〜 ドキュメント駆動運用へ2015-10-31 クラウドネイティヴ時代の運用を考える  〜 ドキュメント駆動運用へ
2015-10-31 クラウドネイティヴ時代の運用を考える 〜 ドキュメント駆動運用へOperation Lab, LLC.
 
Azureのサーバーレスで限界を超えよう~スマートスピーカースキル開発を題材に~
Azureのサーバーレスで限界を超えよう~スマートスピーカースキル開発を題材に~Azureのサーバーレスで限界を超えよう~スマートスピーカースキル開発を題材に~
Azureのサーバーレスで限界を超えよう~スマートスピーカースキル開発を題材に~拓将 平林
 
Apple審査を一発通過! iOS開発経験0でも出来る じげん流Swift開発のすべて
Apple審査を一発通過!iOS開発経験0でも出来るじげん流Swift開発のすべてApple審査を一発通過!iOS開発経験0でも出来るじげん流Swift開発のすべて
Apple審査を一発通過! iOS開発経験0でも出来る じげん流Swift開発のすべてMasaru Gushiken
 
ログ解析基盤におけるストリーム処理パイプラインについて
ログ解析基盤におけるストリーム処理パイプラインについてログ解析基盤におけるストリーム処理パイプラインについて
ログ解析基盤におけるストリーム処理パイプラインについてcyberagent
 
OSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSCOSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSCDaisuke Nishino
 
コミュ障のためのPull Request 〜そしてプルリク充へ〜
コミュ障のためのPull Request 〜そしてプルリク充へ〜コミュ障のためのPull Request 〜そしてプルリク充へ〜
コミュ障のためのPull Request 〜そしてプルリク充へ〜EnsekiTT
 
Ocs2012 tokyo/spring plone
Ocs2012 tokyo/spring plone Ocs2012 tokyo/spring plone
Ocs2012 tokyo/spring plone Manabu Terada
 
Cloudn PaaSチームのChatOps実践
Cloudn PaaSチームのChatOps実践Cloudn PaaSチームのChatOps実践
Cloudn PaaSチームのChatOps実践Kazuto Kusama
 
nanapiのChatOps活用事例 #devops_LT
nanapiのChatOps活用事例 #devops_LTnanapiのChatOps活用事例 #devops_LT
nanapiのChatOps活用事例 #devops_LT晃 遠山
 
OpenCAPI meetup 20180702
OpenCAPI meetup 20180702OpenCAPI meetup 20180702
OpenCAPI meetup 20180702Yutaka Kawai
 
オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へ
オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へオブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へ
オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へEverforth Co., Ltd.
 
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説Daisuke Nishino
 

Semelhante a OpenFlow OAM ツール - OKINAWA Open Days 2014 Day1 (20)

運用管理を楽にしたいという話
運用管理を楽にしたいという話運用管理を楽にしたいという話
運用管理を楽にしたいという話
 
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけてAgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
 
ユーザーストーリーワークショップ
ユーザーストーリーワークショップユーザーストーリーワークショップ
ユーザーストーリーワークショップ
 
月間 250 億 imps 配信するために fluct が考えていること!
月間 250 億 imps 配信するために fluct が考えていること!月間 250 億 imps 配信するために fluct が考えていること!
月間 250 億 imps 配信するために fluct が考えていること!
 
Open capi meetup20180409 (revised)
Open capi meetup20180409 (revised)Open capi meetup20180409 (revised)
Open capi meetup20180409 (revised)
 
2015-10-31 クラウドネイティヴ時代の運用を考える 〜 ドキュメント駆動運用へ
2015-10-31 クラウドネイティヴ時代の運用を考える  〜 ドキュメント駆動運用へ2015-10-31 クラウドネイティヴ時代の運用を考える  〜 ドキュメント駆動運用へ
2015-10-31 クラウドネイティヴ時代の運用を考える 〜 ドキュメント駆動運用へ
 
Openflow超解釈
Openflow超解釈Openflow超解釈
Openflow超解釈
 
Azureのサーバーレスで限界を超えよう~スマートスピーカースキル開発を題材に~
Azureのサーバーレスで限界を超えよう~スマートスピーカースキル開発を題材に~Azureのサーバーレスで限界を超えよう~スマートスピーカースキル開発を題材に~
Azureのサーバーレスで限界を超えよう~スマートスピーカースキル開発を題材に~
 
Apple審査を一発通過! iOS開発経験0でも出来る じげん流Swift開発のすべて
Apple審査を一発通過!iOS開発経験0でも出来るじげん流Swift開発のすべてApple審査を一発通過!iOS開発経験0でも出来るじげん流Swift開発のすべて
Apple審査を一発通過! iOS開発経験0でも出来る じげん流Swift開発のすべて
 
ログ解析基盤におけるストリーム処理パイプラインについて
ログ解析基盤におけるストリーム処理パイプラインについてログ解析基盤におけるストリーム処理パイプラインについて
ログ解析基盤におけるストリーム処理パイプラインについて
 
OSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSCOSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSC
 
コミュ障のためのPull Request 〜そしてプルリク充へ〜
コミュ障のためのPull Request 〜そしてプルリク充へ〜コミュ障のためのPull Request 〜そしてプルリク充へ〜
コミュ障のためのPull Request 〜そしてプルリク充へ〜
 
Ocs2012 tokyo/spring plone
Ocs2012 tokyo/spring plone Ocs2012 tokyo/spring plone
Ocs2012 tokyo/spring plone
 
Cloudn PaaSチームのChatOps実践
Cloudn PaaSチームのChatOps実践Cloudn PaaSチームのChatOps実践
Cloudn PaaSチームのChatOps実践
 
nanapiのChatOps活用事例 #devops_LT
nanapiのChatOps活用事例 #devops_LTnanapiのChatOps活用事例 #devops_LT
nanapiのChatOps活用事例 #devops_LT
 
Net fringejp2016
Net fringejp2016Net fringejp2016
Net fringejp2016
 
OpenCAPI meetup 20180702
OpenCAPI meetup 20180702OpenCAPI meetup 20180702
OpenCAPI meetup 20180702
 
オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へ
オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へオブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へ
オブジェクト・関数型プログラミングからオブジェクト・関数型分析設計へ
 
20090828 Webconlocal
20090828 Webconlocal20090828 Webconlocal
20090828 Webconlocal
 
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
 

Último

TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfMatsushita Laboratory
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~arts yokohama
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦Sadao Tokuyama
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdfAyachika Kitazaki
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-LoopへTetsuya Nihonmatsu
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 

Último (12)

2024 04 minnanoito
2024 04 minnanoito2024 04 minnanoito
2024 04 minnanoito
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
 
2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 

OpenFlow OAM ツール - OKINAWA Open Days 2014 Day1

Notas do Editor

  1. このプレゼンは先ほど本田さんからお話があった OAM のツール (OFURO) を作っています、というものです Ryu を使っているので、Ryu の活用事例としても見てもらえれば
  2. 今の構成がほんとにあってるのか? 昨日まで動いてたスイッチが突然死んだら? OpenFlow でネットワークを組んだとして、お客さんから「なんか繋がらないんですけど〜?」って言われたらどう調べる? OpenFlow のネットワークを管理するためのツールや知見が巷にほとんど無い、あるいはすごく探さないと見つからない状態 商用コントローラを買えばそこら辺も含めて一式用意してくれるのかもしれないけど…
  3. ツールでは主に3つのことをやりたい それには上から一つずつ進めていく必要があると考えている 最終的なゴールは一番下 それぞれの詳細については後ほど詳しく
  4. まず、現状で基本的な部分ができているトポロジの管理で目指しているゴールは、本来こうあるべき、という構成と今が違っていないか調べられること
  5. それにはまず、今のトポロジ、ようするにスイッチ同士がどう繋がっているかを知らなきゃいけない
  6. トポロジを調べる一般的な方法としては LLDP というプロトコルを使うやり方がある これは既に Ryu はもちろん、主要な OpenFlow コントローラフレームワークで実装がある
  7. LLDP を使ったスイッチ同士のつながり、リンクを見つける一般的な方法の解説 まず Packet Out メッセージで特定のスイッチ、ポートから LLDP パケットを投げさせる メッセージを受け取ったスイッチは LLDP パケットを投げる つながっているスイッチに LLDP パケットが届いたら、フローエントリや Table Miss に基いて Packet In する これでコントローラはスイッチ同士がつながっていることがわかる
  8. なら、もうあるやつをそのまま使えばいいじゃん?って話になる LLDP は Ethernet に直接載るし、そうそう普段使われるものではないと思う まっさらなネットワークをゼロから作るならいいのかもしれないけど、そうじゃないなら既存の機器を LLDP 対応のものに置き換えたり、通すルール入れて回らなきゃいけない
  9. Ryu が実装している LLDP アプリにも問題がある 現状だと発見したリンクやスイッチを永続化できない スイッチがコントローラから切断されると、もう見えなくなる 今の状態もそうだけど、過去何があったかも見たい あとこれも問題になった。コードが汚い 途中まで既存のアプリを改修する形で進めてたけど、今後を考えるとちょっとないなと
  10. じゃあ、さきほどの問題をどう解決していくか まず、LLDP は落とされにくいプロトコルを使う ユーザが普段使っているようなプロトコルを使うことで、間の機器に落とさせないようにする ただし、普段使っているプロトコルでも、ユーザが使っていないポートとかを選んで使うことで完全には混ざらない (区別できる) ようにする アルゴリズムは基本的な部分は変えない。プロトコルを変えるだけ。
  11. これはもうそのまんまですね 汚いなら、スクラッチで書くと
  12. ここからは実際に作ったものの説明 普通の Ryu のアプリケーションとして実装した WebUI を通して操作できるようにしている 見つけたものはデータベースに永続化する
  13. 理屈ばかり見てもらっても仕方ないので、実際に動いているところを見てもらう 全然グラフィカルじゃないけど、そういうのは後回しで
  14. 現状でトポロジを見つけることはできた こうなっていてほしいトポロジと比較して、あっているか調べる機能を作っていきたい
  15. ここまでは主に今できていること ここからは今やっていることと、これからやること 夢を語る
  16. 次はフローエントリの管理について ゴールは意図したフローエントリがスイッチに入っているか調べられるようにすること こういう通信がしたいです、という意図の設定が入っているか?
  17. じゃあ比較できるようにするには、何から始めたら良いか? まずはトポロジなどの情報を元に「こういう通信がしたい」を表すモデルが必要になるはず 現状はない 例えばスイッチ A の a ポートとスイッチ Z の z ポートをつなぎたい、っていうのを表現するモデル
  18. こういう通信がしたいです、と直接フローエントリを比較するのはしんどそう なので、もう一段モデルを作ることにした さっきのモデルよりも抽象度を落として、スイッチ単位の「こういう通信がしたいです」というモデル こちらから着手している
  19. あとはモデルからフローエントリを自動で作れるようにする 「こういう通信がしたいです」モデルと、それをスイッチ単位にしたモデル、そしてフローエントリ 上のモデルから下のモデルに変換していく OpenFlow はアセンブラに比喩されることもある モデルは高級言語と言えるかも
  20. フローエントリの管理で解決しなきゃいけないのは大きく3つあると考えている まずモデリング、フローエントリを抽象化したい ただし OpenFlow でできる表現力というか機能を落としたくない、けど分かりやすく絶妙なさじ加減で 次にフロールールへの変換 モデルをフロールールに変換するアルゴリズム ここでの問題は OpenFlow スイッチの実装がバラバラなこと 参考までに、バラバラさは Ryu Certification を見るとよくわかる OpenFlow スイッチはサポートしてる機能がバラバラなので、その違いをうまいこと吸収しなきゃいけないかも 残りはフローエントリの比較アルゴリズム 意図した通りのフローエントリなどが入っているか
  21. 最後に疎通性の確認 これのゴールは実際にトラフィックを流してみて動くか確認できるようにする やりたいのは Ping っぽいこと、Traceroute っぽいこと、Traceroute + α それぞれはこれから説明する
  22. まずは Ping そのまま あるポート a からあるポート z への疎通があるか
  23. 次に Traceroute こちらはどのスイッチのどのポートを通ったのか知りたい こっちを回ったのかそれともこっちを回ったのか
  24. 最後に Traceroute + α これはさきほどの Traceroute に加えて、マッチしたフローエントリまで知ることができる、というもの
  25. 疎通性の確認で解決すべき課題は各手法の検討 Ping や Traceroute の手法は既にいくつか論文がある マッチしたフローエントリを知る Traceroute + α はまだ誰もできていない未知の領域 ほんとにできるかわからないけど、これができるとうれしい
  26. 一言で言うと OpenFlow を便利にするツールを作ってる 今できているのはトポロジの検出まで 今はフローエントリを抽象化したモデルを考えている コントローラには Ryu を使っている 最後にちょっとだけ Ryu を実際に使っている人間から宣伝みたいなもの Ryu を使ったおかげで、実装が短時間でできた 使い慣れている言語に使い慣れているフレームワークという理由もあるが トポロジを調べるところの基礎的な部分は UI 含めて正味 2 週間かからないくらいでできた