トップ «前の日記(09/30/2014) 最新 次の日記(01/01/2016)» 編集

本 日 の h o g e

hogeとはワイルドカードのようなものです。日々起こった、さまざまなこと −すなわちワイルドカード− を取り上げて日記を書く、という意味で名付けたのかというとそうでもありません。適当に決めたらこんな理由が浮かんできました。

更新情報の取得には rdflirs を使ってもらえると嬉しいです.


12/15/2015 ふむ [長年日記]

tDiary 4800日目

[Py][OpenFlow] Trema day #8 で発表してきた

あまりにも放置しすぎているので,たまには何か書こうか... ということで.

ひょんなことからお声かけ頂いて,先日 Trema day #8 で発表してきた. ネタは OpenFlow 環境での L2 traceroute について. 資料は slideshare に置いておいた ので興味のある方はどうぞ. コードも oftroute, oftgui に公開しているので,virtualenv でも作って

$ pip install git+https://github.com/atzm/oftroute.git
$ pip install git+https://github.com/atzm/oftgui.git

とか何とかやればインストールできると思います. コマンドとか使い方は簡単にドキュメントに書いてあるけど,基本的にはコントローラを起動して mininet とかを繋いでやれば動作を見るくらいはできる. Ryu アプリとして書いてあるので,ライブラリ的に (?) 扱って他の Ryu アプリと連携して動くこともできるはず.

L2 の traceroute と言えば IEEE 802.1ag とか Ethernet OAM とかまあそんなキーワードで語られることが多いというかそれがスタンダードなので当然なんだけども,さてそれがそのまま OpenFlow 環境下で使えるかというと,必ずしもそうとは限らない.

例えば IEEE 802.1ag では OAM フレームを Ethertype 0x8902 でぶん投げることによってその機能を果たすわけだけれども,OpenFlow Switch がそれをそのまま吸い上げてしまうようなことをすると,制御対象外ネットワークから入ってくる OAM フレームまで吸い上げてしまうことになるので,場合によっては好ましくないこともある.

また OpenFlow 環境では,普通の IEEE 802.1D 的な Learning Switch と違って,主に L2,3,4 のフィールドを使って転送経路を自由に設定できてしまうので,例えば ARP は経路 A を通るけど,IPv4 は経路 B を通る,というようなネットワークを組めてしまう. こうなると,特定のフレームが通る経路だけでなく,「どういうフレームだったら」どういう経路を通るのか,ということを確認する術が欲しくなる.

スライドにも書いてある通り,この手の話についてはいくつも論文が発表されているようで,今さら何か目新しいネタというわけでもなさそうなのだけれど,(公開されてるものだけだけど) 読んでみると頭の弱い自分にはどうにも難しすぎる... ということで,自分でも分かる/作れるくらいに簡素化/最適化したやり方をひねり出してみたのでした.

あと 1 つ注意点. 一応 traceroute 実行時にフレーム転送時間が出るようになってるけども,現状これはとても信用ならない値なので無視した方が良い. というのも,Ryu の (というか Ryu が内部で使ってる tinyrpc の?) WebSocket ライブラリの都合で,client が ack を返さないと server はそこで block してしまうらしい. 要するに,client (oft-traceroute コマンドや oftgui Web 画面) が server (oft-controller とか) に ack を返すまでの時間が,転送時間に乗ってきてしまっているということ. これはどうしたもんかなぁ... と思いつつ,今に至る...

何はともあれ,関係者の皆様,参加の皆様,お疲れ様でした & ありがとうございました.