TremaでOpenFlowプログラミング

今年もエアコンの活躍する季節がやってきました。

ところが友太郎君のエアコンはどうにも調子がよくありません。取扱説明書に載っていたカスタマーサポートに電話し、自動音声に従ってしばし自分で直そうとしてみたものの、いっこうに解決しません。

結局、自動音声はあきらめて電話サポートに相談することにしました。

「はい、こちらカスタマーサポートセンターです。担当はわたくし青井がうけたまわります。ご要件は何でしょうか？」

青井さんはヨーヨーダイン・エアコン社で働く電話オペレータです。青井さんの普段のオペレータ業務は、主に次の 2 つです (図1-1)。

友太郎君は聞きます。

「なんだかリモコンの調子が悪いんです。温度表示がずっと点滅してるんですけど、どうしたら直りますか？」

青井さんは手元の対応マニュアルを開きます (表 1-1)。対応マニュアルには 3 つの項目があり、お客さんからの「問い合わせ内容」、電話オペレータの「対応方法」、そしてお客さんからの「問い合わせ件数」を調べられるようになっています。

青井さんはちょうどマニュアルの先頭に、探していた「リモコンの不調」の項目を見つけました。

「ご不便をおかけしました。リモコン担当の技術サポートにただいまお繋ぎいたします」

電話の転送を終えると、青井さんはリモコン不調の問い合わせ件数を 8 件から 9 件にアップデートしました (表 1-2)。

このように問い合わせ件数を控えておくことで、どんな故障が多いかを上司にフィードバックできます。たとえばリモコンに関する問い合わせが多ければ、上司は次の製品開発で「リモコンを改良せよ」という指示を飛ばせます。あるいは、周辺機器担当の技術サポートメンバーをもっと増やそうという判断もできます。

OpenFlow の世界では、パケットを送信するホストがお客さんの友太郎君、パケットを転送する OpenFlow スイッチが電話オペレータの青井さんに対応します (図 1-2)。ホストがパケットを送ると、OpenFlow スイッチはパケットの中身に応じてパケットを適切に処理します。これはちょうど、青井さんが友太郎君からの問い合わせ内容に応じ、適切な技術サポートに電話を転送するのと同じです。

OpenFlow スイッチは、動作がマニュアル化されています。カスタマーサポートの例では、青井さんはマニュアルから対応方法を調べました。いっぽう OpenFlow スイッチでは、スイッチ内のフローテーブルからパケットの処理方法を調べます。フローテーブルとは一種のデータベースで、パケットごとの処理方法が入っています。青井さんの業務がすべてマニュアル化されているのと同じく、OpenFlowスイッチの動作はすべてこのフローテーブルの内容によって決まります。

フローテーブルには、「こういうパケットが届いたら、こう処理する」というルールがいくつか入っています。このルールをフローエントリと呼びます。フローエントリはちょうど「リモコンの故障に関する問い合わせがきたら、リモコン担当の技術サポートに電話を転送する」といったマニュアルの各項目に対応します。

実際のフローテーブルの例を見てみましょう。表 1-3 はあるスイッチのフローテーブルで、各行がフローエントリです。フローエントリは主に、マッチフィールド・アクション・カウンタの 3 つの要素からなります^[4]。

このように、実は OpenFlow はとても単純で理解しやすい仕組みです。

エアコンもしばらくは順調でしたが、1 ヶ月後また調子が悪くなってしまいました。友太郎君は再びカスタマーサポートへダイヤルします。

「エアコンの排水ホースがすぐ詰まっちゃうんです」

どうやらまったく新しい不具合のようです。青井さんはいつものように手元の対応マニュアルを調べましたが、困ったことに排水ホースの項目は載っていません。

「申し訳ございませんが少々お待ちください。対応可能な技術サポートがいるかどうか確認いたします」

そして電話口にはどこか軽快な音楽と、「しばらくお待ちください」のメッセージが繰り返し流れはじめました。

こういうとき、青井さんがいつも頼るのは上司の宮坂部長です (図1-3)。

「宮坂さん、排水ホースについての問い合わせがきたのですが、どの技術サポートにつなげばよいですか？」

「それだったら消耗品技術サポートだよ」

転送先がわかった青井さんは、友太郎君の待つ電話に戻ります。

「大変お待たせいたしました。担当の技術サポートに転送いたします」

一度目の問い合わせと比べてかなり時間がかかってしまいましたが、これでようやく一件落着です。青井さんは忘れないうちに、宮坂部長から教わった消耗品技術サポートの連絡先をマニュアルに追加します (表 1-4)。もしも同じ問い合わせがきた場合には、素早く答えられるようにするためです。

カスタマーサポートセンターでは、お客さん対応はすべて電話オペレータがやってくれます。上司があらかじめ適切なマニュアルを作っておけば、あとはほとんどの仕事を電話オペレータにおまかせできるのです。これによって、電話オペレータが対応している間、管理職は他の部署との連携に集中できます。

OpenFlow では上司であるコントローラ自体をソフトウェアとして書けるので、ネットワークだけでなくその管理も自動化できます。さらにコントローラが Ruby や Python、Java などの汎用言語で書いてあれば、既存のシステムやサービスとの連携も簡単です。たとえば、アプリケーションからの要求やビジネスポリシーの変更、問題発生などさまざまなトリガーに応じてネットワークの設定を変更するといった、一歩進んだ自動化もできます。

カスタマーサポートセンターでは問い合わせ件数の情報はすべて上司に上がってくるため、混み具合の把握や全体の交通整理が楽です。もし特定の技術サポートに問い合わせが集中しても、問い合わせがうまくバラけるようにマニュアルを通じて電話オペレータの全員に指示できます。反対にもし各オペレータが個々に判断してしまうと、おなじ技術サポートに問い合わせが偏ることは避けられません。

OpenFlow でもすべての情報はコントローラに上がってくるため、全体を見たトラフィックの最適化が可能です。フローエンントリ内のカウンタを集計し、検出したスイッチの接続関係 (ネットワークトポロジ) と突き合わせることで、コントローラはネットワーク全体のトラフィックを把握できます。そしてその情報をもとに各スイッチのフローテーブルを更新することで、全体的に見て最適となるパケットの通り道を引けます。反対に、もし個々のスイッチが判断してしまうと、効率的にトラフィックを分散できません。

コントローラはソフトウェアの一種なので、ソフトウェア開発で長年培われているさまざまなテクニックやツールをネットワーク構築に応用できます。

たとえば近年主流のアジャイル開発手法でコントローラを開発すれば、反復的な機能追加が可能です。ユーザからのフィードバックを受けながら少しずつバージョンアップしてくことで、ネットワークを段階的に構築できます。

またコントローラのテストコードを書くことで、ネットワーク全体を自動的にテストできます。テストコードやテスト結果の出力は、そのまま仕様書の一部として使えます。もう Excel や Word で書いた仕様書を別個に管理する必要はありません。

従来のネットワーク機器を OpenFlow コントローラで置き換えれば、アップグレード方法の選択肢が広がります。従来のスイッチ・ルータ・ファイアウォールといったネットワーク機器では、ポート数を増やしたい場合にはワンランク上のハイエンドな機器との入れ換えが必要でした。これは、コストのかかる垂直方向のアップグレードです。しかし、ネットワーク機器を OpenFlow のコントローラとして汎用サーバ上にソフトウェア実装すれば、並べるサーバを増やすだけでポート数を増やせます。こうした水平方向へのアップグレードは垂直方向のアップグレードと比べて低コストで実現できます。

さらに、ネットワーク機器の機能アップグレードも、OpenFlow ではソフトウェアの書き換えで済みます。従来のようにワンランク上の高機能なネットワーク機器を購入するかわりに、新機能をコントローラにソフトウェアとして実装すればよいのです。

ただし、これらはもちろん自分で実装しなければならないという前提付きです。たとえば水平方向にサーバを増やす場合には、サーバ間での設定情報の同期や、一部のサーバがダウンした場合の障害復旧といった機能を自分で実装しなければなりません。また、ハイエンドなネットワーク機器の機能の中には、ソフトウェアによる実現がむずかしい複雑な機能もあるでしょう。これらを実現するには、既存の分散データベースといったミドルウェアを利用したり、OpenFlow で実装しやすい機能に置き換えたり、といった工夫が必要になります。

最初にコントローラとスイッチは TCP 接続を確立します。これを OpenFlow チャンネルと呼びます。この TCP 接続は、仕様によるとスイッチとコントローラのどちらが始めてもよいことになっています。しかし多くの場合、図 2-1 のようにスイッチからコントローラへと接続する実装となっています。

なお OpenFlow チャンネルには普通の TCP 接続だけでなく、よりセキュアな TLS (Transport Layer Security) も使えます。ただし、コントローラとスイッチの両方が TLS に対応している必要があります。また、TLS は暗号化・復号化に多くのリソースを必要とするので、大量にメッセージをやりとりする場合には性能が低下します。

次にスイッチとコントローラは、使う OpenFlow バージョンをお互いに確認します。これを一般にバージョンネゴシエーションと呼びます。OpenFlow チャンネルの確立後、スイッチとコントローラは自分のしゃべれるバージョン番号を乗せた Hello メッセージをお互いに出し合います (図 2-2)。

もしここで、相手と同じバージョンを話せるようであればネゴシエーションに成功です。成功すると、Hello 以外のメッセージもやりとりできるようになります。

次にコントローラは接続したスイッチの Datapath ID を確認します。コントローラがスイッチに Features Request メッセージを送ると、スイッチは Datapath ID とスペックを乗せた Features Reply メッセージを返答します。

Features Reply メッセージには Datapath ID に加えて、主に次のスペック情報が入っています。

スイッチは、受信したパケットと関連情報を Packet In メッセージでコントローラへ通知できます。たとえば、フローテーブルに登録していない通信を検知した場合など、Packet In メッセージを使ってパケットの情報をコントローラへ送ります (図 2-4)。

Packet Out メッセージは Packet In メッセージの逆で、スイッチからパケットを出力するためのメッセージです (図 2-5)。

Packet Out の典型的な利用例は、Packet In でコントローラへ届いたパケットを宛先に届ける場合です。もしも Packet In の後に Packet Out をやらないと、パケットはコントローラに残ったままで宛先には届きません。

Flow Mod メッセージはスイッチのフローエントリを追加・削除・変更するためのメッセージです (図 2-6)。Flow Mod メッセージを受け取ったスイッチは、メッセージ内容に従って自身のフローテーブルを更新します。

OpenFlow 仕様によると、スイッチはフローテーブルの更新完了をコントローラに通知しません。その理由は、もしも Flow Mod メッセージごとに応答メッセージを返すことにすると、多くのフローエントリを設定する場合に時間がかかってしまうためです。

Flow Mod メッセージによるフローテーブルの更新完了を確認するには Barrier メッセージを使います (図 2-8)。コントローラが Barrier Request メッセージを送ると、それ以前に送った Flow Mod メッセージの処理が全て完了した後、スイッチは Barrier Reply メッセージを返します。

フローエントリが消えると、消えたフローエントリーの情報は Flow Removed メッセージとしてコントローラに届きます。Flow Removed メッセージには、消えたフローエントリの内容とそのフローエントリにしたがって処理したパケットの統計情報が入っています。これを使えば、たとえばネットワークのトラフィック量の集計ができます。

フローエントリには、優先度 (0 〜 65535) が設定できます。受信パケットが、フローテーブル中に複数のフローエントリにマッチする場合、この優先度の値が高いフローエントリが優先されます。

OpenFlow 1.3 ではフローエントリごとにカウンタを持っており、次の統計情報を取得できます。

フローエントリにはタイムアウト (寿命) を設定できます。寿命の指定には次の 2 種類があります。

どちらのタイムアウトも 0 にして打ち込むと、そのフローエントリは明示的に消さない限りフローテーブルに残ります。

フローエントリには、クッキーを設定できます。クッキーに設定された値は、スイッチにおけるパケット処理には全く影響を与えません。例えば、フローエントリを管理するために、コントローラがクッキーフィールドに管理用の ID を付与するといった使い方ができます。

マッチフィールドとは、OpenFlow スイッチがパケットを受け取ったときにアクションを起こすかどうかを決める条件です。たとえば「パケットの宛先が http サーバだったら」とか「パケットの宛先がブロードキャストアドレスだったら」などという条件に適合したパケットにだけ、スイッチがアクションを起こすというわけです。

OpenFlow 1.3 では、40 種類の条件が使えます。主な条件を 表2-1 に示します。これらの条件はイーサネットや TCP/UDP でよく使われる値です。

OpenFlow の世界では、このマッチフィールドで指定できる条件を自由に組み合わせて通信を制御します。たとえば、

などといった具合です。

インストラクションには、そのフローエントリにマッチしたパケットを、次にどのように扱うかを指定します。OpenFlow 1.3 では主に、以下のインストラクションを利用可能です。

これらのうち Write-Actions, Clear-Actions, Write-Metadata, Goto-Table は、マルチプルテーブルを使う際に用いるインストラクションです。そのため、マルチプルテーブルを説明する際に、合わせて詳しく説明します。

Apply-Actions にて指定するアクションとは、スイッチに入ってきたパケットをどう料理するか、という 動詞 にあたる部分です。よく「OpenFlow でパケットを書き換えて曲げる」などと言いますが、こうした書き換えなどはすべてアクションで実現できます。OpenFlow 1.3 では、次の 7 種類のアクションがあります。

アクションは動詞と同じく指定した順番に実行されます。「おにぎりを作って、食べて、片付ける」といったふうに。たとえば、パケットを書き換えて指定したポートから出したいときには、

と、複数のアクション並べて指定します。この実行順に並べられた複数のアクションのことを、アクションリストと呼びます。Apply-Actions インストラクションや Write-Actions インストラクションには、アクションリストを用いることで、複数のアクションを指定できます。

ここで、アクションリストは指定された順番に実行されることに注意してください。アクションリストの順番を変えてしまうと、違う結果が起こります。たとえば「おにぎりを食べてから、おにぎりを作る」と最後におにぎりが残ってしまいます。同様に先ほどの例を逆にしてしまうと、まず先にパケットがフォワードされてしまいます。その後 Set-Field が実行されても、書き換えられた後、そのパケットは破棄されるだけです。

同じ動詞を複数指定することもできます。

この場合は、フィールド A と B を書き換えて、ポート A と B へフォワードする、と読めます。このように、複数のフィールドを書き換えたり、複数のポートにパケットを出したりする場合には、アクションを複数連ねて指定します^[5]。

Drop は特殊なアクションで、実際に Drop アクションというものが具体的に定義されているわけではありません。アクションのリストに Output アクションを1つも入れなかった場合、そのパケットはどこにもフォワードされずに捨てられます。これを便宜的に Drop アクションと呼んでいるわけです。

それでは、もっともよく使われる Output アクションと Set-Field アクションで具体的に何が指定できるか見て行きましょう。

Output アクションでは指定したポートからパケットを出力します。出力先にはポート番号を指定しますが、特殊用途のために定義されている論理ポートを使うこともできます。

この中でも FLOOD や NORMAL は OpenFlow スイッチ機能と既存のスイッチ機能を組み合わせて使うための論理ポートです。

Set-Field アクションでは、パケットのさまざまな部分を書き換えられます。パケットで書き換えられるフィールドは、マッチフィールドで指定可能なフィールドと同じです (表2-1)。例えば、以下に示す書き換えが可能です。

それでは Set-Field アクションの代表的な使い道を順に見ていきましょう。

Chante-TTL アクションは、パケット中の TTL (Time-To-Live) の値を変更するためのアクションです。TTL は、なんらかの不具合によりネットワーク中でパケットがループすることを防ぐための仕組みです。パケットを受信したネットワーク機器は、ヘッダ中の TTL の値を一つ減らしてからパケットを転送します。もし、受信したパケットの TTL の値が 0 だった場合、そのパケットを破棄します。このようにすることで、パケットがループ中を転送され続けることを防ぎます。Change-TTL アクションでは、以下に示す TTL の書き換えが可能です。

例えば、内側が IP ヘッダで外側が MPLS ヘッダである時、Copy TTL outwards では、IP ヘッダの TTL 値を MPLS ヘッダの TTL のフィールドに設定します。一方、Copy TTL inwards では、MPLS ヘッダの TTL 値を IP ヘッダの TTL のフィールドに設定します。

Apply-Actions に指定されたアクションは、フローテーブルが参照された段階で即座に実行されます。一方で、Write-Actions を使うと、一旦アクションセットに格納されます。そしてフローテーブルの参照が全て終わった段階で、アクションセットに格納されたアクションが実行されます。

例えば、表2-6 と 表2-7 のようにフローエントリが格納されていたとします。宛先ポート番号 25 のパケットを受信した時、このパケットは Table1 の 1 番目のエントリにマッチします。そのため、Write-Actions インストラクションで指定されている Set-Field A というアクションがアクションセットに格納されます。1 番目のエントリには、Goto-Table インストラクションも指定されていますので、次に Table2 の参照を行います。受信パケットは Table2 の 1 番目のエントリにもマッチしますので、同様にアクションセットに Output 2 というアクションが格納されます。最終的にアクションセットには、Set-Field A および Output 2 という二つのアクションが格納されている状態になります。

アクションセットに格納された複数のアクションは、次の優先順位に従って実行されます。格納された順に実行されるわけではない点に注意が必要です。

表2-6 と 表2-7 で示した例の場合、Output アクションより優先度が高い Set-Field アクションが先に実行され、その後 Output アクションが実行されます。

アクションセットは、一連の処理が終わった後にクリアされます。前に受信したパケットのアクションがアクションセットに入ったままになり、次のパケットの処理に用いられることは起こりません。

マルチプルテーブルを使ったパケットの処理中であっても、Clear-Actions インストラクションを使うことで、アクションセットの中身をクリアできます。Clear-Actions インストラクションを使えば、Write-Actions で格納したアクションをアクションセット中から全て消去できます。

Write-Metadata インストラクションを使って、メタデータを付与できます。付与されたメタデータは、Goto-Table インストラクションで次のフローテーブルを参照する際に、マッチフィールドの一部として利用できます。

例えば、送信元 IP アドレスが 192.168.1.101, 102 の場合、宛先ポート番号が 25, 110 のパケットのみをポート 2 から出力し、また送信元 IP アドレスが 192.168.1.103, 104 の場合、宛先ポートが 80, 443 のパケットのみをポート 2 から出力することを考えます。この例をメタデータを使って実現したのが 表2-8 と 表2-9 です。

表2-8 には、送信元 IP アドレスをマッチとしたフローエントリが格納しています。表2-9 には、宛先ポートをマッチとしたフローエントリが格納されています。このように、メタデータを用いることで、複雑な条件であっても、シンプルなフローエントリの組み合わせで設定できます。

メタデータは 64bit 長のビット列で、初期値は All 0 です。Write-Matadata インストラクションは、各ビットの値を変更します。Write-Metadata インストラクションを使うときは、値とマスクの組を指定します。マスクで指定されたビットの値がメタデータに反映されます。

例を使って説明します。実際にはメタデータは 64bit ですが、ここでは 8bit であるとします。メタデータの現在の値が 11111111 であり、Write-Metadata インストラクションでの指定した値は 00001010、マスクは 00001111 であったとします。マスクは下位 4bit が 1 であるため、値の下位 4bit 分だけをメタデータに反映します。その結果、メタデータは 11111010 となります。

また、メタデータをマッチフィールドで用いる場合にも、値とマスクを指定します。マスクで指定されたビットのみ、マッチに用います。

Rubyのインストール方法は、Linuxディストリビューションごとに異なります。

Bundler は次のコマンドでインストールできます。

なお gem は Ruby の標準ライブラリ形式 .gem をインストールするコマンドです。ここでは最新版の Bundler の .gem を自動的にダウンロードしてインストールしています。

Open vSwitchのインストール方法も、Linuxディストリビューションごとに異なります。

コントローラの実装はプロジェクト用ディレクトリを作ることから始めます。まずは次のように、Hello Trema!用の空のディレクトリ hello_trema/ と、ソースコード用ディレクトリ hello_trema/lib/ を mkdir -p コマンドで新たに作ってください。

HelloTrema や Trema::Controller など、大文字で始まる名前が定数です。Rubyの定数は英語や日本語といった自然言語における固有名詞にあたります。

英語でも固有名詞は大文字で始めることになっています。たとえば英語のTokyo Tower(東京タワー)がそうです。東京タワーは動かすことができませんし、何か別なものに勝手に変えることもできません。このように、固有名詞は時間とともに変化しないものを指します。そして固有名詞と同様、Rubyの定数は一度セットすると変更できません。もし変更しようとすると、次のように警告が出ます。

class に続く定数はクラス定義です。Hello, Trema!の例では HelloTrema がクラス名です。「class +クラス名」から始まるクラス定義は、同じ字下げレベルの end までの範囲です。

さて、こうして定義した HelloTrema クラスはどこから実行が始まるのでしょうか。C言語で言う main() 関数に当たるものがどこにも見あたりません。

その答はTremaの動作モデルであるイベントドリブンモデルにあります。Tremaのコントローラは、さまざまなイベントに反応するイベントハンドラ (以下、ハンドラと呼びます) をいくつも持ちます。コントローラが動作するのは、さまざまなイベントに対してハンドラが反応したときです。

ハンドラの定義は def に続く名前から end までの部分で、実際にはメソッド定義です。たとえば HelloTrema の例では start ハンドラと switch_ready ハンドラを定義しています。ハンドラ名の後のカッコで囲まれた部分 (_args と datapath_id) はそれぞれのメソッドに渡される引数です。

このほかにTremaでよく使うハンドラをリストアップしておきます。

Rubyにはたくさんの組込みの語 (キーワード) があり、それぞれに意味があります。これらのキーワードを変数として使ったり、自分の目的に合わせて意味を変えたりはできません。

このうち、Hello, Trema!では class・def・end の 3 つのキーワードを使いました。先ほど説明したように、class キーワードは続く名前のクラスを定義します。そして def キーワードは続く名前のメソッドを定義します。

この def や class で始まって end で終わる領域のことをブロックと呼びます。すべてのRubyプログラムはこのブロックがいくつか組み合わさったものです。

さて、ここまででHello Trema!に必要なRubyの文法は学びました。再びHello Trema!のソースコードに戻りましょう。

新しくスイッチが起動すると switch_ready ハンドラが起動します。switch_ready ハンドラは、接続したスイッチのDatapath IDを16進形式(0xで始まる文字列)でログに出力します。

それでは、スイッチの切断をうまく検出できるか確かめてみましょう。仮想スイッチを停止するコマンドは trema stop です。trema run を実行したターミナルはそのままで別ターミナルを開き、次のコマンドで仮想スイッチ 0x3 を落としてみてください。

すると、trema run を実行したターミナルで新たに 0x3 is down の行が出力されます。

うまくいきました! それでは逆に、さきほど落した仮想スイッチを再び起動してみましょう。仮想スイッチを起動するコマンドは trema start です。

0x3 is up の行が出力されれば成功です。

このように、trema stop と trema start は仮想ネットワークのスイッチを制御するためのコマンドです。引数にスイッチのDatapath IDを指定することで、スイッチを停止または起動してコントローラの反応を確かめられます。

スイッチ監視ツールの動作イメージがわかったところで、そろそろソースコードの解説に移りましょう。

switch_ready ハンドラでは、スイッチ一覧リスト @switches に新しく接続したスイッチのDatapath IDを追加し、接続したスイッチの情報を画面に表示します。

@switches は start ハンドラで空の配列に初期化されます。

アットマーク(@)で始まる語はインスタンス変数です。インスタンス変数はたとえば人間の歳や身長などといった、属性を定義するときによく使われます。アットマークはアトリビュート (属性) を意味すると考えれば覚えやすいでしょう。

インスタンス変数は同じクラスの中のメソッド定義内であればどこからでも使えます。具体的な例として次の Human クラスを見てください。

Human クラスで定義される Human オブジェクトは、初期化したときにはそのインスタンス変数 @age は0、つまり0歳です。birthday を呼び出すたびに歳を取り、@age が 1 増えます。このように @age は initialize および birthday メソッドのどちらからでもその値を変更できます。

switch_disconnected ハンドラでは、スイッチ一覧リストから切断したスイッチのDatapath IDを削除し、切断したスイッチの情報を画面に表示します。

ここでは switch_ready とは逆に、配列の引き算 (-=) で切断したスイッチのDatapath IDを @switches から除いていることに注意してください。

スイッチの一覧を一定時間ごとに表示するには、Tremaのタイマー機能を使います。次のように timer_event に続いて一定間隔ごとに呼び出したいメソッドと呼び出し間隔を指定しておくと、指定したメソッドが指定した間隔ごとに呼ばれます。

この定義は Human クラス定義の先頭に書けるので、まるで Human クラスの属性としてタイマーをセットしているように読めます。このようにTremaを使うとタイマー処理も短く読みやすく書けます。

タイマーから呼び出すメソッドは、クラスの中だけで使うのでよくプライベートなメソッドとして定義します。Rubyでは private と書いた行以降のメソッドはプライベートメソッドとして定義され、クラスの外からは見えなくなります。

これを踏まえてスイッチ監視ツールのソースコードのタイマー部分を見てみましょう。

クラス名定義直後のタイマー定義より、10秒ごとに show_all_switches メソッドを呼んでいることがわかります。

スイッチの情報を取得するには、取得したい情報をリクエストするメッセージを send_message でスイッチに送信し、そのリプライメッセージをハンドラで受け取ります。たとえば、今回のようにスイッチの詳細情報を取得するには、DescriptionStats::Request メッセージを送信し、対応するハンドラ description_stats_reply でメッセージを受け取ります。

スイッチの詳細情報のほかにも、さまざまな統計情報を取得できます。OpenFlow 1.0がサポートしている統計情報の一覧は次のとおりです。

Cbench のソースコードにはいくつかのメソッド呼び出しがあります。

このようにメソッドは普通、変数や定数の後にドットでつなげます。定数や変数が名詞なら、メソッドはちょうど動詞と同じです。

上の例では open がメソッドです。英語のopenは動詞なので、当然メソッドであるとも言えます。

ふつう、メソッド呼び出しによって何らかの動作をすると新しい結果が得られます。

この場合、文字が逆順になった新しい文字列が返ってきました。

メソッドは引数を取るものもあります。次の例は配列の各要素の間に指定した文字をはさんで連結 (join) します。

Rubyにはこのようなメソッドが何百種類もあります。それぞれの動作は名前から大体想像できるものがほとんどです。

前章と同じく、start ハンドラでコントローラの起動をログに書き込みます。引数は今回も使っていないので、名前を _args のようにアンダースコアで始めます。

コントローラに上がってくる未知のパケットを拾うには、Packet Inハンドラをコントローラクラスに実装します。Packet Inハンドラは次の形をしています。

packet_in ハンドラはその引数として、Packet Inを起こしたスイッチ(cbenchプロセス)の Datapath ID とPacket Inメッセージを受け取ります。

Cbenchの仕様によると、コントローラからCbenchへと送るFlow Modメッセージは、次の内容にセットする必要があります。

それぞれの指定方法を順に見ていきましょう。

スレッド間の競合を解決する代表的な方法が Mutex による排他制御です。スレッド間で競合の起こる箇所を Mutex で囲むことで、その箇所へは同時に 1 つのスレッドしか入れなくなります。

これでひとまず競合は回避できたので、packet_in をスレッド化してみましょう。次のように高速化したいハンドラメソッドの中身を別スレッドで起動し、インスタンス変数へのアクセスを Mutex で排他制御してやります。

しかし、これでもまだ問題は残ります。Thread.start によるスレッド起動はそれなりにコストのかかる処理なので、Packet In が届くたびに Tread.new でスレッドを作っていては速くなりません。

そこで、次のようにあらかじめいくつかワーカースレッドを作って待機させておく、いわゆるスレッドプールという手法が使えます。そして packet_in ハンドラが呼ばれるたびに待機中のスレッドに packet_in の処理をまかせます。

このスレッドプールを使った、最終的なマルチスレッド版 Cbench コントローラは次のようになります。

実際に性能を計測してみましょう。

別ターミナルで Cbench を起動します。

おや？シングルスレッド版よりも若干遅くなってしまいました。これには 2 つの原因があります。まず、Ruby のスレッドは OS のネイティブスレッドであるため、スレッド切り替えのオーバーヘッドが大きくかかります。しかも、Packet In 処理は一瞬で終わるため、マルチスレッド化しても並列性はあまり上がりません。これらの原因から、マルスレッド化によって新たにスレッド切り替えのオーバーヘッドがかかった分、元のバージョンより遅くなってしまったのです。

仮想ネットワーク設定ファイル patch_panel.conf では、パッチパネルの動作テストのためにパケットを送受信できる仮想ホストを定義しています。vhost で始まる行が仮想ホスト、そして link で始まる行がスイッチやホストをつなげるための仮想リンクです。

この設定ファイルでは仮想スイッチ 0xabc に 3 つの仮想ホスト host1, host2, host3 を接続しています (図 6-3)。仮想スイッチと仮想ホストの接続は、仮想リンク (link で始まる行) によって記述できます。link を書いた順で、それぞれのホストはスイッチのポート 1 番、ポート 2 番、ポート 3 番、…​ に接続されます。

パッチパネルをこの仮想ネットワーク内で実行するには、仮想ネットワーク設定ファイルを trema run の -c オプションに渡します。次のように trema run コマンドでパッチパネルコントローラを起動してください。

パッチパネルは起動しただけではまだパッチングされていないので、ホスト間でのパケットは通りません。これを確認するために、trema send_packets コマンドを使ってhost1とhost2の間でテストパケットを送ってみましょう。

正常に動いていれば、それぞれのホストでの受信パケット数は0になっているはずです。これを確認できるのが trema show_stats コマンドです。

trema show_stats コマンドは引数として渡したホストの送受信パケットを表示します。host1 と host2 の両ホストともパケットを 1 つ送信していますが、どちらにもパケットは届いていません。

パッチパネルの設定は ./bin/patch_panel コマンドで指定できます。たとえば、スイッチ 0xabc のポート 1 番とポート 2 番をつなぐには次のコマンドを実行します。

これで、host1 と host2 が通信できるはずです。もういちどパケットの送受信を試してみましょう。

たしかにパケットが届いています。パッチパネルの動作イメージがわかったところで、ソースコードを見ていきます。

startハンドラではコントローラを初期化します。

@patch は現在のパッチング情報を入れておくハッシュテーブル (後述) です。このハッシュテーブルは、キーにスイッチの Datapath ID、バリューに現在のパッチ情報を持ちます。たとえば、スイッチ 0x1 のポート 1 番と 4 番をパッチングし、スイッチ 0x2 のポート 1 番と 2 番、および 3 番と 4 番をパッチングした場合、@patch の中身は次のようになります。

ハッシュテーブルは中カッコで囲まれた ({}) 辞書です。辞書とは「言葉をその定義に対応させたデータベース」です。Rubyでは、この対応を : という記号で次のように表します。

たとえば ”boar” を日本語で言うと何だろう? と辞書で調べたくなったら、次のようにして辞書を引きます。

この辞書を引くときに使う言葉 (この場合は :boar) をキーと言います。そして、見つかった定義 (この場合はイノシシ) をバリューと言います。

新しい動物を辞書に加えるのも簡単です。

Rubyのハッシュテーブルはとても高機能なので、文字列だけでなく好きなオブジェクトを格納できます。たとえば、パッチパネルでは Datapath ID をキーとして、パッチング情報 (配列) をバリューにします。

実は、すでにいろんなところでハッシュテーブルを使ってきました。たとえば、send_flow_mod_add などの省略可能なオプションは、コロン (:) を使っていることからもわかるように実はハッシュテーブルなのです。Rubyでは、引数の最後がハッシュテーブルである場合、その中カッコを次のように省略できます。

switch_ready ハンドラは、起動してきたスイッチに対してパッチング用のフローエントリを書き込みます。すでにパッチ情報 @patch にフローエントリ情報が入っていた場合(スイッチがいったん停止して再接続した場合など)のみ、フローエントリを入れ直します。

イテレータとは繰り返すものという意味で、繰り返し処理を短く書きたいときに使います。イテレータは一般に次の形をしています。

ここでは配列 fruits の each というイテレータで fruits の各要素をプリントアウトしています。do のあとにある each は fruits の各要素が入る仮引数です。この each にバナナ・みかん・りんごが順にセットされ、続くブロック (do…​end) が呼び出されます。

イテレータの利点は、同じ繰り返し処理をループで書いた場合よりもずっと簡単に書けることです。

このように for ループで書くと、配列の要素にアクセスするための変数 i やループの終了条件 i < 3 などが必要になります。一方、イテレータはこうした煩雑なものを抽象化で見えなくしてくれるので、プログラマは各要素についてやりたいことだけをブロックに書けば動きます。

実は、5 章「マイクロベンチマークCbench」で登場した次のコードもイテレータです。

この times がイテレータで、続くブロックの内容を 10 回実行します。もし仮引数を使わない場合は書かなくても OK です。これによって、「10.times { start_worker_thread } (10 回 start_worker_thread を呼ぶ)」といったふうに繰り返しを非常に直感的に書けます。

1つのパッチ(2つのフローエントリ)を実際に書き込むのが add_flow_entries プライベートメソッドです。

add_flow_entries の中で2回呼び出している send_flow_mod_add のうち、最初の呼び出し部分を詳しく見てみましょう。

ここでは、ポート port_a 番へ上がってきたパケットをポート port_b 番へ出力するフローエントリを書き込んでいます。ここでは次の2つのオプションを指定しています。

delete_flow_entries は古いフローエントリを消すメソッドです。add_flow_entries でフローエントリを足す前に、いったん delete_flow_entries で古いフローエントリを消すことでフローエントリが重複しないようにします。

ここで呼び出している send_flow_mod_delete は send_flow_mod_add とは逆のメソッドで、match: に対応するフローエントリを削除します。

create_patch と delete_patch メソッドは、bin/patch_panel コマンドからパッチの作成と削除を行うためのAPIです。

create_patch メソッドは、add_flow_entries メソッドでフローエントリを追加し、パッチ設定 @patch にパッチ情報を追加します。

逆に delete_patch メソッドはフローエントリを削除しパッチ設定からパッチ情報を削除します。

PatchPanel クラスの操作コマンドが bin/patch_panel です。PatchPanel クラスの create_patch と delete_patch メソッドを呼び出します。patch_panel create と patch_panel delete という 2 つのサブコマンドを持っています。

サブコマンドの実装には gli (https://github.com/davetron5000/gli) というRubyライブラリを使っています。gli を使うと、patch_panel create や patch_panel delete といったサブコマンド体系、いわゆるコマンドスイートを簡単に実装できます。詳細は gli のドキュメントにゆずりますが、書きかたを簡単に紹介しておきます。

gli を使ったサブコマンドの実装は、command サブコマンド名 do …​ end のブロックを記述するだけです。それぞれのブロック内で、サブコマンドに渡されたオプションの処理と実際の動作を記述します。

ポイントは、サブコマンド定義内での PatchPanel クラスのメソッド呼び出し部分です。

この Trema.trema_process.controller メソッドは、現在動いているコントローラオブジェクト(PatchPanel クラスオブジェクト)を返します。そしてその返り値に対して create_patch などのメソッドを呼び出すことで、コントローラのメソッドを呼び出せます。

この状態でホスト1がホスト2へパケットを送信すると、コントローラは次のようにホスト1のネットワーク上での位置情報を学習します(図 7-4)。

学習が終わると次はパケットの転送です。もちろん、パケットの宛先はまだ学習していないので、コントローラは次のようにパケットをばらまくことで宛先まで届けます。このばらまく処理をフラッディングと呼びます(図 7-5)。

この状態でホスト2がホスト1へパケットを送信すると次のようになります(図 7-6)。

さて、ここまでの段階でフローテーブルには「ホスト2からホスト1へのパケットはポート1へ出力せよ」というフローエントリが入りました。もし、ホスト2がホスト1へ再びパケットを送信すると、今度はPacket Inがコントローラまで上がることはなく、スイッチ側だけでパケットを転送します。

残りのホスト1からホスト2へのフローエントリはどうでしょう。すでにFDBはすべてのホストのMACアドレスとポート番号を学習しています。もし、再びホスト1からホスト2へパケットを送信すると、図 7-6と同様にコントローラが「ホスト1からホスト2へのパケットはポート5へ出力せよ」というフローエントリを書き込みます。もちろん、それ以降の通信ではPacket Inはまったく上がらずにすべてスイッチ側だけでパケットを処理します。

知らないパケットがPacket Inとして入ってきたとき、ラーニングスイッチは次のようにFDBにホストの位置情報を学習し、宛先のポート番号を調べます。

Packet OutはOpenFlowメッセージの1つで、スイッチの指定したポートからパケットを出力させるためのものです。TremaでPacket Outを送るためのメソッド send_packet_out は、次の2つの引数を取ります。

それぞれの引数の意味は次のとおりです。

Packet Outの使い道は、Packet Inメッセージとして入ってきたパケットをそのままスイッチのポートから送り出す場合がほとんどです。この場合、パケットの送信にスイッチのバッファを使う場合と使わない場合とで呼び出し方が変わります。

options に指定できる主なオプションは次のとおりです。

learning_switch.rb の一行目の require 'fdb' は、同じディレクトリ内の fdb.rb を読み込みます。require はちょうど、C の #include や Java の import みたいなものと思ってください。Ruby では、たとえば fdb.rb というファイルを読み込みたいときは、拡張子の .rb を外して require 'fdb' と書きます。読み込む対象のファイルは、lib/ ディレクトリを起点とした相対パスで書きます。たとえば lib/learning_switch/extensions.rb を読み込みたいときには require 'learning_switch/extensions' と書きます。

fdb.rb もざっと目を通しておきましょう。このファイルは FDB の機能をカプセル化する FDB クラスを提供します。

FDB クラスは3つのメソッド lookup・learn・age を持ちます。lookup メソッドを使うと MAC アドレスからポート番号を検索できます。逆に learn メソッドでは MAC アドレスとポート番号の組を学習できます。タイマで定期的に呼ばれる age メソッドでは、FDB に入っているすべてのエントリをエージングし、寿命を過ぎたもの (FDB::Entry#aged_out? で判定) を消します。

switch_ready ハンドラでは宛先 MAC アドレスが 01:80:C2:00:00:00 のパケットを落とすフローエントリを打ち込んでいました。

コードコメントにもあるように、ここで落としているのはスパニングツリーの制御フレームである BPDU フレームです。OpenFlow ではスイッチを集中制御できるため、ループを防ぎたい場合には分散アルゴリズムの一種であるスパニングツリーは不要だからです。OpenFlow でループを防ぐ方法について詳しくは、16 章「たくさんのスイッチを制御する」で解説します。

このパイプライン処理は、テーブル ID が 0 のテーブルから始まり GotoTable インストラクションによって次のテーブルに移動することで進みます。パイプライン処理の入口となるテーブル、つまり Packet In したときに最初に入るテーブルの ID は 0 と決まっています。現在のテーブルから次のテーブルへと処理を移行するには GotoTable インストラクションに次のテーブル ID を指定します。このとき指定するテーブル ID は、現在のテーブル ID よりも大きい必要があります。

さて「GotoTable インストラクション」という用語を今まで断りなく使ってきましたが、OpenFlow1.3 ではパケットに対する処理を「アクション」と「インストラクション」に分けて書きます。まずはアクションから説明しましょう。

アクションの1つの用途はパケットの書き換えです。書き換えアクションの種類は OpenFlow1.0 に比べて大幅に増えており、マッチフィールドで指定できるフィールドの書き換えや VLAN ヘッダの操作に加え、TTL や MPLS, IPv6 パケット等への操作が追加されています (表8-1)。

もう1つのアクションの用途はパケットの出力です。指定したポートへ出力したり、ポートに関連付けられたキューにパケットを追加するのに使います (表8-2)。

インストラクションはアクションよりも一段上の処理で、フローテーブルの移動とアクションの実行方法を記述できます。たとえば GotoTable インストラクションは、次のように Flow Mod の instructions パラメータに指定しておくことで、マッチしたパケットが到着するとそのパケット処理を指定したフローテーブルへと続けます。

インストラクションのもう1つの用途は、アクションを適用するタイミングの指定です。指定方法は次の 2 通りです。

Apply を使うと指定したアクションを直ちにパケットへ適用できます。これはちょうど、OpenFlow1.0 の Flow Mod で actions を指定した場合と同じ効果を持ちます。

WriteActions は指定したアクションを後でまとめて適用するために使います。GotoTable でテーブルを移動しながら、パケットに WriteActions で指定したアクションを「後で適用するアクション」に追加していきます。そして GotoTable を含まないフローエントリにパケットがマッチしたタイミングで、そのパケットの「後で適用するアクション」をまとめて適用します。

「この後で適用するアクション」をアクションセットと呼びます。アクションセットはいわゆる集合なので、同じアクションを複数入れることはできません。WriteActions 以外にも、アクションセットを空にする Clear インストラクションがあります。ここまでのインストラクションを含めてインストラクション一覧を紹介しましょう。

switch_ready ハンドラでは、まだ学習していないパケットのデフォルト処理を新しく起動したスイッチのフローテーブルに書き込みます。

最初に呼び出す add_bpdu_drop_flow_entry では、不要なスパニングツリーの BPDU フレームをドロップするフローエントリを書き込みます。

Flow Mod に指定するパラメータのうち、ポイントとなるのは次の 3 つです。

続く add_default_forwarding_flow_entry では、BPDU フレーム以外のパケットを FORWARDING_TABLE_ID で処理します。

ここで重要なパラメータは次の 3 つです。

最後の add_default_flooding_flow_entry では、宛先 MAC アドレスをまだ学習していない場合のデフォルト処理をフローテーブルに書き込みます。

packet_in ハンドラでは、Packet In したパケットの送信元 MAC アドレス + In Port の組を学習します。学習した組はテーブル ID が FORWARDING_TABLE_ID であるフローテーブルにフローエントリとして追加します。

ここでの Flow Mod パラメータのポイントは次のとおりです。

シナリオの前提条件 (Given) には、まずはコントローラにつなげるスイッチとホスト 3 台のネットワーク構成 (図 9-1) を記述します。Cucumber のテストファイル features/repeater_hub.feature はこうなります:

最初の行 Given a file named "trema.conf" with: …​ は、「…​ という内容のファイル trema.conf があったとき、」を表すテストステップです。このように、Cucumber では英語 (自然言語) でテストステップを記述できます。

それぞれの仮想ホストで promisc オプション (プロミスキャスモード。自分宛でないパケットも受け取れるようにするモード) を true にしていることに注意してください。リピータハブはパケットをすべてのポートにばらまくので、こうすることでホストがどんなパケットでも受信できるようにしておきます。

続いて、この仮想ネットワーク上でコントローラを起動する Given ステップを次のように書きます。

これは、シェル上で次のコマンドを実行するのと同じです。

Given が書けたところですぐに実行してみます。まだ lib/repeater_hub.rb ファイルを作っていないのでエラーになることはわかりきっていますが、エラーを確認するためにあえて実行します。次のコマンドを実行すると、受け入れテストファイル features/repeater_hub.feature を実行しテスト結果を表示します。

予想通り、trema run の箇所でエラーになりました。エラーメッセージによると lib/repeater_hub.rb というファイルが無いと言っています。このエラーを直すために、とりあえず空のファイルを作ります。

再びテストを実行すると、今度は次のエラーメッセージが出ます。

repeater_hub.rb にコントローラクラスが定義されていない、というエラーです。エラーを修正するために、RepeaterHub クラスの定義を追加してみます。エラーを修正できればいいので、クラスの中身はまだ書きません。

再びテストを実行してみます。今度はパスするはずです。

やりました! これで Given ステップは動作しました。

このようにテスト駆動開発では、最初にテストを書き、わざとエラーを起こしてからそれを直すためのコードをちょっとだけ追加します。テスト実行結果からのフィードバックを得ながら「テストを書き、コードを直す」を何度もくりかえしつつ最終的な完成形に近づけていくのです。

When には「〜したとき」というきっかけになる動作を記述します。ここでは、Given で定義したホスト host1 から host2 にパケットを送る処理を書きます。パケットを送るコマンドは、trema send_packets でした。Cucumber (Aruba) では、実行したいコマンドを次のように I run …​ で直接書けます。

テストを一行追加しただけですが、念のため実行しておきます。

問題なくテストが通りました。次は Then に進みます。

Then には「最終的にこうなるはず」というテストを書きます。ここでは、「ホスト 2・ホスト 3 がパケットを受け取るはず」というステップを書けばよいですね。これは次のように書けます。

このステップはテーブル形式をしており、ホスト 2・ホスト 3 それぞれについて、送信元 IP アドレス 192.168.0.1 からパケットを 1 つ受信するはず、ということを表しています。

ではさっそく実行してみます。

host2 に 1 つ届くはずだったパケットが届いておらず、失敗しています。RepeaterHub クラスはまだ何も機能を実装していないので当然です。

フラッディングをする Flow Mod を打ち込むコードを RepeaterHub クラスに追加して、もう一度テストしてみます。

失敗してしまいました。まだ host2 がパケットを受信できていません。そういえば、Flow Modしただけではパケットは送信されないので、明示的に Packet Out してやらないといけないのでした。そこで次のように Packet Out を追加します。

再び実行してみます。

すべてのテストに通りました! 次はテスト駆動開発で欠かせないステップであるリファクタリングに進みます。

ネットワーク管理者から届いた障害報告メールには次のようにありました「レガシーネットワークのホストどうしが通信できなくなった。スイッチはHost Flapping警告を出している」

Host Flappingとは、1つのホストがいくつかのポートの間で高速で移動しているように見えるという障害です。「なんでそんなことが起こるんだろう？」われわれはすぐにOpenFlowネットワークを切断し、そしてもちろんネットワーク管理者にはごめんなさいメールを出してから、原因の分析にとりかかりました。

分析の結果、図10-2のようなシナリオが起こっているという結論に至りました。

つまり、BuggyControllerがレガシーネットワークにパケットを逆流させたおかげでネットワークが大混乱し、通信できない状況が起きたのです。

振り返ると、失敗した原因は2つありました。

1つは、OpenFlowネットワークをいきなりレガシーネットワークとつないでしまったことです。OpenFlowネットワーク単体では動いていたのに、というのは言い訳にはなりません。若気の至りや経験不足から来る青いミスです。もう1つは、BuggyControllerがPacket Inと同じポートにPacket Outするという通常あり得ない動作をしていたことです。要所要所で assert を入れるといった防御的プログラミングや、ソフトウェアテスト(9章「Trema でテスト駆動開発」を参照)を徹底していれば防げるバグでしたが、当時の私たちは動かすことに精いっぱいでそこまで気が回りませんでした。

というわけで、大障害を起こして始めて気付くという最悪のパターンになってしまったわけです。

最初のパターンは、既存のレガシーネットワークにまったく手を加えずに、それとは独立したもう1つのOpenFlowネットワークを構築する方法です(図10-3)。それぞれのネットワーク間でパケットの行き来はなく、お互いに完全に独立しています。

この状態から、レガシーネットワーク内のサーバや端末を徐々にOpenFlowネットワークに移動することで移行していきます。

それぞれのネットワーク間ではパケットが行き来できないので、OpenFlowネットワークがレガシーネットワークに悪影響を及ぼす可能性はまずありません。ただし、OpenFlowネットワークに移行する際には関連する機器同士（ファイルサーバとクライアント群など）を一度に移行する必要があります。これはトラブルを起こす可能性が高いため、レガシーネットワークの規模が大きい場合には移行が難しいという問題があります。

次のパターンは、私たちがやったようにレガシーネットワークとOpenFlowネットワークをいきなりつなげてしまう方法です（図10-4）。

この方法だと、相互に通信できるのでネットワーク間でのサーバや端末の移動は自由にできます。このため、独立ネットワークパターンに比べて移行の手間はずっと小さいと言えます。

ただしこの方法は、私たちが失敗したようにとてもリスクの高い方法です。OpenFlowネットワークのコントローラが完璧に作られていれば、このようにいきなりつなげても問題はありませんが、完璧を期するのはなかなかむずかしいものです。というのも、実際のトラフィックをコントローラに流し込んでみて初めて見つかるバグもあるからです。よって、この方法は自宅ネットワークなど他人に迷惑のかからないネットワーク以外では推奨できません。

最後のパターンは、今までに挙げてきた2つのパターンのいいとこどりです。2つのネットワークを接続するのですが、そのときに逆流防止フィルタとなるOpenFlowスイッチを間にはさむことでパケットの逆流が起きないようにします（図10-5）。

この逆流防止フィルタはたとえば、レガシーネットワーク→OpenFlow ネットワークのような一方向のパケットは通しますが、同じパケットがレガシー側に戻ることを防ぎます。逆方向も同様です。

この方法の利点は、逆流を防ぐだけで今回のケースも含めたかなりの障害を未然に防げることです。また、使い勝手はいきなり接続した場合と同じなのでOpenFlowへの移行も楽です。ただし、2つのネットワーク間にもう1つフィルタ用のOpenFlowスイッチをはさまなければならないという手間はかかります。

逆流防止フィルタ（OneWayBridge コントローラ）のソースコードは GitHub の trema/one_way_bridge リポジトリ (https://github.com/trema/one_way_bridge) からダウンロードできます。

ダウンロードしたソースツリー上で bundle install --binstubs を実行すると、Tremaなどの実行環境一式を自動的にインストールできます。

このコントローラは、Packet In と Flow Removed のハンドラだけを定義したとてもシンプルなものです。

packet_in ハンドラでは、Packet Inしたスイッチポートとは別のポートへパケットを転送するフローエントリを設定し（add_flow メソッド）、Packet Inを起こしたパケットを転送します（send_packet メソッド）。また、同じパケットが逆向きに流れないようにするフローエントリを設定することで逆流を防ぎます（add_drop_flow メソッド）。同じパケットかどうかは送信元のMACアドレスが同じかどうかで判断します。

flow_removed ハンドラは、順方向または逆方向のフローエントリが消えたときに呼ばれます。これらのフローエントリはどちらも :source_mac_address に同じMACアドレスを指定しているので、delete_flow メソッドでもう片方の対になるフローエントリを消します。

逆流防止フィルタを実行するには、レガシーネットワークとOpenFlowネットワークの間にOpenFlowスイッチをはさみ、これをOneWayBridgeコントローラで制御します。でも実機のOpenFlowスイッチを準備するのは大変なので、Tremaの仮想ネットワーク機能でやってしまいましょう。NICが2枚挿さったサーバを用意し、仮想ネットワーク内で起動した仮想スイッチ(vswitch)の各ポートとそれぞれのNICを接続します(図10-6）。

この物理構成をTrema設定ファイルにしたものが以下です。仮想リンク（link で始まる行）の端点にインタフェース名eth0、eth1を指定していることに注目してください。

実行するには、この設定ファイルを trema run の -c オプションに渡します。

さっそくこの逆流防止フィルタを導入したところ、問題は起こらなくなりました。現在、OpenFlowスイッチ5台、ホスト約100台から構成されるOpenFlowネットワークを職場ネットワークと接続して運用しています。このOpenFlowネットワークは現在もどんどん拡大しつつあり、その上でOpenFlowを使ったたくさんのアプリケーションが生まれています。こうした実践あるのみという姿勢から生まれたたくさんのアプリケーション、それを支えるプログラミングフレームワークとして誕生したのがTremaです。

仮想ネットワークを使って BlockRFC1918 コントローラを起動してみます。ソースコードと仮想ネットワークの設定ファイルは GitHub の trema/transparent_firewall リポジトリ (https://github.com/trema/transparent_firewall) からダウンロードできます。

ダウンロードしたソースツリー上で bundle install --binstubs を実行すると、Tremaなどの実行環境一式を自動的にインストールできます。

GitHub から取得したソースリポジトリ内に、仮想スイッチ1台、仮想ホスト3台の構成を持つ設定ファイル trema.conf が入っています (図 11-3)。