hogeとはワイルドカードのようなものです。日々起こった、さまざまなこと −すなわちワイルドカード− を取り上げて日記を書く、という意味で名付けたのかというとそうでもありません。適当に決めたらこんな理由が浮かんできました。
12/15/2015 ふむ [長年日記]
■ [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 を返すまでの時間が，転送時間に乗ってきてしまっているということ． これはどうしたもんかなぁ... と思いつつ，今に至る...
何はともあれ，関係者の皆様，参加の皆様，お疲れ様でした & ありがとうございました．