今日も秋田で IoT

旧 Trema 日記

OpenWRT with OpenFlow を trema と接続する(その3)

今回は、OpenWRT/WHR-G301N がきちんと OpenFlow スイッチとして動作するのかを確認してみたいと思います。今回使うコントローラは、loopback-test.rb を用います。

さっそく動かす。

それでは起動してみましょう。OpenWRT/WHR-G301N 中の OpenFlow スイッチとして動作する二つのポートを Ethernet ケーブルで接続し、loop を構成します。その上で、loopback-test.rb を起動し、OpenWRT/WHR-G301N からセキュアチャネルを接続してみましょう。

タイミングにより多少順序に違い等がでますが、正常ならば上記のように出力されるはずです。もし途中で止まってしまうようであれば、いずれかの OpenFlow メッセージが受け付けられていない、発生すべきイベントが発生していない等の原因が考えられます。

loopback-test.rb の解説

この原因追求のためには、loopback-test.rb がどのように動作するのかを理解する必要があります。基本的には非同期に発生するイベントに対してハンドラを設定しているだけなのですが、ざっくりいうと、以下の順序で動作します。

  • switch_ready イベントが発生したとき、スイッチに features_request メッセージを送信する。

switch_ready は、OpenFlow スイッチが Trema に接続し、制御ができるようになったときに発生するイベントです(詳しくはここ)。Feature Request を送ることで、スイッチの持つポート一覧の取得を行います。

  • features_reply メッセージを受信したとき、メッセージ中に含まれる全てのポートにダミーのパケットを出力する。

UDP パケットを作って packet_out メッセージで出力させています。loop が構成されているので、このパケットはいずれかのポートから packet_in で上がってくるはずです。

  • packet_in メッセージを受信した時、flow_mod メッセージおよび barrier_request メッセージを送信する。

packet_in に対する flow_mod を発行します。その後 barrier_request メッセージを送り、これに対する reply により flow_mod が要求通り設定されたことを確認します。

  • barrier_reply メッセージを受信した時、ログ出力。

ここでは特に何もしません。メッセージを受信した旨を表示するだけです。

  • flow_removed メッセージを受信した時、ログ出力。

先程の flow_mod では hard_timeout が 2 秒のフローエントリを設定しています。そのため、2 秒後に flow_removed がコントローラ側に上がってくるはずです。

この一連の流れが最後まで実行されない場合、どこかに問題があります。packet_in あたりであれば tcpdump を用いてさらに切り分けを行う必要があるかもしれません。