Trema Day #2 参加メモ #tremaday

はじめに

Trema Day #2 参加してきました。

• TremaDay
• Trema Day #2 | 集客ならイベントアテンド
• Trema Day #2 #tremaday - Togetter
• Giving is Taking - Networking: Trema Day #2 に参加してきた

Trema Day #1 のときは参加できずに Ust 視聴 + Twitter 実況というのをやったりしました。今回も Twitter 実況はやろうかと思ったのだけど、当日会場についてテザリングでネットつなごうとしたら上手くつながらず。仕方がないのでローカルでメモを取ってました。ちょっと整理して出しておきます。括弧付き[こういうの]は編集者註です。

内容的に問題がありそうなのがあったらご連絡ください。

議事次第

OpenFlow 1.2 でトラフィックエンジニアリングを試してみました (@ttsuboさん)

発表資料: TremaDay #2

自己紹介

• DCNW engneer
• IaaS/openstack の勉強
• NW屋もプログラミング必要だよね。

伝えたいこと

• OpenFlow で取り上げられている物の大半が OpenFlow 1.0 ベース
• 仕様としては OpenFlow1.3 まで用意されているけど実装は世の中に出回っていない。
• このままシュリンクするともったいないよね。まず OpenFlow 1.2 ベースで新しいことを実験してみました。

今のネットワークで満足していますか?

• 新しいネットワークで3拠点つなぐことを考えてみる
  • 課題1: 拠点間帯域の増速が難しい、帯域逼迫
  • 課題2: 拠点間で故障が発生した場合、すぐに復旧が難しい

理想的な構成

• いろんなルートを確保できる環境が望ましい。
  • トラフィック分散をはかることで拡張しやすい
  • 迂回ルートへの切り替えも可能
• 理想の環境を今の技術だけで構築するのは難しい
  • ループ防止
  • L2マルチパスの制御実現は難しい。

L2マルチパス制御が今の技術でいつ実現できるのか?

• OpenFlowでトラフィックエンジニアリングで可能なのでは。

OpenFlow-TEのまえにNW仮想技術の整理

• 最近のNW仮想化: 拠点間オーバーレイでL2透過なネットワークを作る
  • L3 underlay
  • L2 overlay: flat L2 を構築するのが要素技術(テナントネットワーク)
    • overlay - 従来のVLANの相互接続とか

overlayの特徴

• overlayも万能ではない
• hop-by-hop で実現できないか?
• サイト間でパスを張っておいて、そこにテナントネットワークを載せる階層型ネットワークにしておけば可能では?

OpenFlow 制御の留意事項

• 効率的なフロー設定
  • プロアクティブなフロー設定が必要になってい
    • いかにリアクティブなエントリをなくしてプロアクティブに生きていくか。
• リアルタイムなフロー監視が重要だろう
  • 従来は一つの機器にルーティング・フローテーブルがあるので同期がはかりやすい
  • OpenFlow だとルーティング情報が上位のコントローラにある。筐体をまたがったルーティング・フォワーディング情報の整合性をどうとっていくか。整合性が損なわれたとしても検出していく監視技術が大切。

ためしてみた。

• OpenFlow-TE 検証環境
  • Underlay: OpenFlow Switch
• 特徴: エッジ感でパスを張った上でホストのトラフィックを収容する。
  • 拠点間パス用フローエントリは事前に登録しておく。従来はMPLSとかが使われる。が、今回はうまくいかなかったのでToSを使ってる
  • どのパスに収容するかはエッジで指定しておく。
  • 障害時もパスの切り替えを行うことで自動的に通信回復を

デモ

• 高品質パス(ICMP)
  • 経路障害があった場合も迂回パスを作り直す
• 低品質パス(TCP)
• OVS1.9.0(OpenFlow1.2 mode)を使用
  • flow stats request/responce でフロー情報を表示している
• ICMP 高品質パス上でリンク断
  • ToS4 → ToS12に切り替え

QA

• [Q.] 環境作るのに要した時間
  • OVS 設定：2週間?
  • コントローラプログラミング
    • OpenFlow1.3 → C言語の壁があって…
    • スクリプトレベルだと1ヶ月半?
    • 今回使ったのがAPIリファレンスが整備されていないのでかなり手探り。Trema edge のリファレンスが充実してくるとうれしい。
• [Q.] 切り替えの通信断の時間
  • 今日のデモでは10秒くらい。説明上の都合でそうした。故障検知については検出メカニズムのインターバルによって1秒以内でもできるだろう。ネットワーク装置数によって故障区間特定はリニア。今回はスイッチ6台くらいなのでそれほど問題にならない。
• [Q.] 故障検知時間、検出方法は？
  • 一般的にはOFS側でポートダウン検出してポートステータスメッセージ。ただこれだとあまりおもしろくないな、と。コントローラ側からEdge間にパケット流し込んで疎通性確認してコントローラに戻すみたいなことをやってる。故障があるとOAM戻ってこないのでそれで検出。
• [Q.] リンクが落ちて自動復旧、tos4→12に。使用するToSの値を変えて復旧?
  • edge-edge間でいっぱいパスを張っておく。今回は tos4 パス と tos12 パスがあってそれを使ってる。
  • tos4 パスは最短で、tos12 パスは迂回で、あらかじめ用意しておいたパスを切り替えている。
  • フロー切り替えは、通過するスイッチごとにエントリスイッチ設定しないといけないという壁。マルチテーブルにしてエッジ間パスはっておいて、パスの切り替えだけでやれるのがマルチテーブルのメリット。
• [Q.] 間にあるスイッチの数が増えたときの経路パターンについては代表的なパスで複数設定なのか?
  • パスをどう作っておくのがよいかはユースケースごとにまちまちだろう。L3NWを間に挟む場合はGRE併用とかもあり得る。今回やったのは6台のスイッチの中で2つパスを張っておくというやり方だが、それがすべてではない。
• [Q.] パスの話とパスに乗せるパケットのToSの話。ToSの値でマッチ。ToSをつけるのは誰か?
  • ToSの設定はコントローラが入ってきたところでつける?
  • フローテーブルを多段で仕込んでいる。1段目は相手先を見てToS設定して次のテーブルに渡す。
• [Q.] 故障検知、OAM的な物を投げてるという点について; コントローラの中でOAMのフレームを定義してPacketoutしてる?
  • ホスト1とホスト2のリアルなICMP相当の物をコントローラがエッジに流し込む、というところまでやってる。

Tremaでつくる商用実用OpenFlowコントローラ(仮) (@chibacchieさん)

発表資料: Developing production OpenFlow controller with Trema

• 大人の事情により実用コントローラというテーマに…。詳細を話せなくなったので半分くらいは与太話になりました。
  • Trema C lib で作る場合のはまりポイントを紹介。
  • OFC の、そこそこマジな物を作るとどうなるかをざっくり紹介。

はまりポイント

• Trema は OpenFlow Controller ではありません。
  • Trema はコントローラを作るためのただの部品なので、ほかの部品も勝手に使えばいいと思います。
  • ほかのライブラリを使えばできることは、ほかのよいライブラリを使う。
    • たとえば: 冗長会、性能を上げる、OpenFlow 以外のプロトコルをサポートしてスイッチ制御したい、など。
• OFSはデータベースではありません。
  • Transaction の処理をちゃんとやってくれるわけじゃない。DBみたいな動きはしない。flow_mod とか送ったところでどのタイミングで実行されるかもわからない。そもそも実行される保証はどこにもない。
  • 確実に実行してもらうために barrier Request/Reply がある。
  • flow_mod を送信したからといって確実に反映されている保証はなくて、それではまることがあります。
    • 宣伝: trema-apps に apps/transaction_manager というのを今週おいておきました。
• 非同期でスイッチからコントローラへイベントが上がります。
  • イベントはスイッチとコントローラが接続したときの Features Request/Reply, 初期化の処理の前にも非同期イベントが発生することがあります。
  • Features Request/Reply で Datapath ID をもらう。コントローラからするとそういった情報がわかる前にイベントが上がってくる可能性があります。そういった事象に対応する必要があります。(通常は無視するだけ)
    • 無視しないで落ちちゃったりしないようにね。
• send_openflow_message() API, send とあるけど openflow message は送信しません。
  • 送信キューにメッセージを積むだけです。
  • 複数スイッチにメッセージ送ったとしても、スイッチ間の順序保証(メッセージが記載した順にスイッチに送られる保証)はありません。
• libtrema は thread-safe ではありません。
  • thread 使う場合は要注意。
    • openflow application interface is NOT thread-safe
  • 個人的に thread-safe 化プロジェクトやってたけど力尽きて停まっています。協力者募集。
• OpenFlop メッセージキューは固定長。
  • send_openflow_message をたくさん呼ぶと false を返すことがあるので気をつけましょう。
• flush_messenger
  • send_openflow_message から false が返ったときに、キューを消そうとして気軽に呼ぶのは危ない。
  • 送信キューも受信キューも空にする。
  • OpenFlow メッセージ処理のハンドラの中で flush_messenger よぶと再帰的に同じハンドラが呼ばれる可能性がある
• start_trema が fork(2) を呼ぶことがある
  • start_trema 前に、PID取得とか、forkされると困る処理を入れないように注意。
    • 0MQ(?) 併用に伴うトラブル報告アリ?

Controller development use case

• マジなコントローラを作るとどうなるのか
• 要件
  • 物理ネットワーク上に仮想的な L2 いっぱいある。VLAN? VPLS? VXLAN? なんでもいい。その先にOFS, エンドホストがある。
  • OFC が超巨大パッチパネルをやる。
• 問題は規模
  • 10000+ end host
  • 1000+ switch
  • 10000+ virtual network

設計

• スイッチ→LB→Worker(Trema OFC)→DBに状態を集約→Config I/F→[REST]→external app
• LBはスイッチ単位にworkerを割り当てる。
• バックエンドには最小限の状態を保持しておいて、Worker間で共有させる。
• Workerはロスしてもいい情報だけ持っておく。Workerはいつ死んでも大丈夫。

具体的な実装

• VXLANで10000以上のL2
• 結構コンサバなデザイン

vxlan tunnnel end-point
  + VXLAN Agent (Virtual Network Agent)
          |
         OFS
          |
OFLB(LVS/keepalived)
          |
       worker ---- worker watchdog
         + trema
         + VXLAN Agent (Virtual Network Agent)
          |
       mysql
          |
[configuration frontend]

評価

• 管理できるスイッチの数、一つのWorkerあたり410-412スイッチを処理、Workerのメモリ上限(2GB)による。
  • 3Workerで1024(評価環境の上限)
• 16384仮想ネットワーク、各8ホスト、全部フルメッシュでPing撃ってパケットロスなし。
• 外部アプリから設定入れて完了するまでの時間
  • 大人の事情でデータは見せられません。
  • セットアップタイムは増えない。16000とか作ったところでもコンスタント。DB状態同期とかはDBちゃんと設計してあればほとんど問題にならない。
• よくOpenFlowネットワークはスケールしないっていわれるけど、使い方によってはこういうのもできる。どこをあきらめてどこを拾うか。

QA

• [Q.] VXLANの目的, テナントの区別は?
  • 1テナント1VNI, VMがどのテナントに所属するのかを制御。VNIごとにポートで識別
• [Q.] 8ポートまでっていうのは理由が?
  • (いえないですが)とあるところのとあるネットワークでVLANに入っているホストの平均がこれに近いというのがあったので。何かの制限ではなくて、あるユースケースを元に妥当な値として設定。
• [Q.] このソースは公開されないのか?
  • 回答できません。
  • よくわからないリポジトリが Trema の下にありますがよくわかりません。
    • 一部で使っている Transaction Manger とかは公開しています。
    • 個人的には公開したい
• [Q.] スイッチはノーエントリ状態から始まる? 最初に packet_in とかで時間食ったりしない?
  • エントリはない。Trema に地味な機能があって、つながった瞬間にパケット落とすことができて、5秒くらい黙らせる。素早く黙らせる、という作戦。
• [Q.] Virtual Network Agent は誰とコミュニケートしている?
  • OFSとかVXLANの設定をしたりする。制御元はWorkerのVirtual Network Manager。スイッチについてはOVSコマンドをたたく。
• [Q.] packet_in のデータからマッチルールを生成するファンクション。Trema Edge のECNをセットしないように改造したい。openflow_message.c?
  • (ここで github ひらいて Trema Edge の openflow_message.c のコード見ながら話が始まりましたが、書き取りようがなかったです)
• [Q.] DBにある情報、Workerにある情報ってどういうもの?
  • DBはスイッチのポートと仮想ネットワークの対応、設定の状態: 外部アプリからの設定が入ってきたときにWorkerが処理を始めるのについて、開始とか成功とか失敗とか。フローエントリ情報とかは持たない。
  • Workerが設定中で Seg って死んだとか、ほかの Worker が引き継いだらどうかとか。flow_mod_strict でフローエントリを上書きしても大丈夫、という地味なのをやってる。（flow_mod_add は使っていない)

SDN人生相談

[このへんはちゃんとメモ取れてません]

何か相談したいこととか聴いてみたいことないですか?

• Open Daylight って何者?
  • ソースダウンロードした。Javaが大量。サブプロジェクトが大量にあってよくわからない。
  • networkstatic の記事とかみると ONE Controller と daylight のでロゴがかわってるくらい。
• とある会社で OpenFlow 構築してくれといわれ。物理サーバが OpenFlow 全く対応していない。物理サーバ通信どうするか。RINGネットワーク、マルチパスにしたい
  • 既存のインフラでマルチパス通信可能なインフラが必要だよね
  • etc etc
• 目的ベース、会社の中のポジションをねじ込みたい。導入に当たっては実績と有効性、何がうれしいのかをどう出すか。
  • OpenFlow はネジクギなので何を作るかで攻める
  • 課題の設定。最初のとっかかりとして好きだから、やってみたいから、は良い。ただ、見せるときにはそれによって何が解決できるのか、どういうことが実現できるのか、というところにつなげて説明していかないといけない。
    • 上の人はどういう問題を持っているか、自分がどう解決できるか。
  • N社の事例とか?
    • ネットワークの管理コスト減らしたい。ネットワークの面倒見たくない。
  • 昔の話。IPv6とかでも似たような状況が。最終的には IPv6 になっても何も変わりませんという話をした。プロトコル開発者は作ったきり。OpenFlow も何でもできるのでって期待するけど、実は何でもできるってのは危険が大きい。どんどん期待だけが上がる。現場の人はアプリケーションを示してやらないといけない。現場からどうすればいいかというのを作って、出していって、メーカーにあげるとか、要望を出してく。メーカーも作ってるけどアプリどうしようとか見えていない。何か示さないと広まっていかない。
  • 大学の状況。卒検レベルでもコントローラとか出てきてる。POXベースので作った学生もいる。
• Northbound API の件、統一の動き? OFC持ってる機能それぞれ違うのに標準化ってナンセンスなんじゃないの?
  • APIはRESTでだいたい提供されている。REST API って twitter, facebook, いろいろある。すぐ書けるから、統一する必要は特にないんじゃないか。統一されていれば楽だと思うけど、誰が得をするかというと想像しにくい。簡単につなげられるから。
    • RESTで出てればNWの知識がなくても、Web屋のひととかでもやれるでしょう。段階を飛ばして統一とかの話をすると訳がわからないよね。
  • 標準化、通信業界からするとベンダロックイン排除という意味でも必須。非標準で作ると逃げられないので。乗り換えられるようにしたい。プロセスとして、いま使い方もモデルも決まってないのに統一っていっても意味がないというのは同意。L2スライス切るだけなら単純なので API 切れるだろうということで Trema ではそのへんの API 定義はしている。そういう試みはしているがあれだけで十分かというのは正直よくわからない。
• 会場にいる人はネットワークとか基盤周りの話をやっていてOpenFlowに興味を持った人なのか? それともアプリケーションとかもっと上のシステムをやっていてOpenFlowに興味を持った人なのか?
  • 挙手 → ネットワーク系7割、サーバ系3割、その他少数
    • その他: 大学1〜2名, 映像配信的なところをみていて, [あと1-2名あったのですが記録漏れ]
• 分野について聞いた理由: SDNとかやるのに人増やしたい。必要な知識が多岐にわたってどこから手をつけるのがいいのだろうか? ネットワーク屋にプログラミングを教えていくのかアプリ屋にネットワーク見てもらうのか。実際コントローラ使うとネットワークの知識がないと手に負えないなあと思ったりする。あるいはネットワーク屋さんとアプリ屋さんの間にある考え方や認識の溝を埋めるためには何がいいのか?
  • [この辺自分がしゃべってたのでメモちゃんととれてないです]
  • (高宮さん) 考え方や知識の差はある。Trema チームだと隣にネットワークの人が座ってる。直接話をしながら間柄教えてもらったりできる環境にしてしまうというのはアリだと思う。
  • どういうところに考え方の違いがあるのか、どういったコミュニケーションが必要なのか、という話とかも面白そうですね。

OpenFlowネットワークの見えるかと設定を行うGUIツール (@user_localhostさん)

発表資料: Trema Day #2 発表資料（大山裕泰）

これまでの活動まとめ

• 就職
• OpenFlow導入のポイント
  • 信頼と実績
• 社内勉強会
  • 盛況
• 興味を持ってもらう
  • 有効性を、わかりやすく伝える(OpenFlowならではの物を、一目でわかるように)
    • GUIツール
• GUIツール: Trema Graph
  • NW全体の俯瞰
  • 経路の可視化
• アーキテクチャ
  • Trema内部のAPIイベントをフックしたりして情報を持ってくる

環境作り

• 最終目標は社内環境の OpenFlow 化
• Trema-Graphの動作環境作り
  • OpenWRT?
• Overlay 対応の検討
• 本を書きました。5/1発売予定。
  • Amazon.co.jp： 次世代ネットワーク制御技術 OpenFlow入門: 石井秀治, 大山裕泰, 河合栄治: 本

QA

• [Q.] 可視化、大量のフローやデータをどう見せるか。GUI的なアイデア?
  • Processing (java) を使っている
  • 社内プロモーション活動
• GUIを作るときの問題点: 工数。目的によってみたいポイントが違うので全部入れられない。DSLを使って、スクリプト書いたら見たいところだけ図が出てくるとか。Queryを投げるようなので出てくるとかそういうのもいいのでは。ブラウザでリッチに燃えるのもいいけど、別なアプローチがあってもいいんじゃないかな。いろんな視点を全部見せられないので。
• フローの可視化、今のリアルなフローがどうなっているかを知りたいというのはある。それに加えて、変更した後の振る舞い, what-if simulation みたいなのができるといいなあ。
• プロダクト(N)でもパスマッピングとかの機能はある。ただ実際使っていくと、トラフィックの流量とかそういうのを見たいというのが出てくる。どれだけ流れてるかとかも可視化できるとうれしい。

Tremaで構築! 中小企業の社内LAN (近藤さん)

会社のネットワークをOpenFlowで構築してみた話。

• ネットワークエンジニアです。
• Trema ユーザ的視点で発表します。
• プログラミングは初めて、くらい。
• Trema + Pica8 を使いました。
  • L3まで、地味な話。
  • ツールとしてのOpenFlow評価を兼ねています。

社内LANの構成

• 元々
  • クライアント30，サーバ40，プリンタ、ファイルサーバ、など。
  • ネットワーク更改、「OpenFlowでやれ」
  • すべてのホストが一つのブロードキャストドメイン
• 移行後
  • セグメント(サブネット)の分割
  • DHCPリレーが必要

作ったスクリプト

• LLDPでトポロジの管理、描画、フルメッシュシングル構成で L3ルーティング + L2スイッチング
• DHCPリレー
• ブロードキャスト・マルチキャスト制御
• 経路切り替え

動作の仕組み

• エントリの優先度、12タプルの内殿情報を使うべきか
  • ARP/LLDP などの特殊な用途
  • DHCP
  • そのほかIP
• フローテーブルの作り(エントリの設計)
  • DHCPなので誰がどのIP使うかわからない → 原則リアクティブ制御
  • 社内LAN: 多様なパケットが流れる環境。これらをどう処理しなければいけないかが重要。
• 転送処理ルール
  • Pica8 のTCAMのサイズが小さい → なるべく不要なエントリは減らす。冗長なエントリは減らす。なるべく集約。
    • まとめるときの注意: マッチルールがかぶらないように社内インフラだと考える必要がある
  • フロー優先度を考える。
• DHCPリレー
  • Racketでパケットインしたデータを処理(relay agent ip address の書き換え)
  • packet_in のデフォルトのサイズがある。これをオーバーするとパケットインしない。max_len で広げてやる必要がある。
• ブロードキャスト転送
  • 前もって撃って二度と packet_in させないようにする。

導入後のフローテーブルの状態

• Pica8: 公称 2048エントリ, 今回は600エントリくらいだから余裕。
• LAN内通信のスループットもそれなりに出る。
  • 下りインターネット76Mbps とか

性能

• コントローラ: MEM 2Gbps, Xeon 2.4GHzくらい。メモリ2.5%, CPU30%程度で稼働

まとめ

• 小規模だけどRubyでも性能面は問題がない。
  • packet_in させないような工夫とかをすれば。もうちょっと小さいPCでもいけそう。
• スループットは実用レベルで出てる
• 通信制御はコードにベタに書いたので、編集とか変更が難しい。GUIとか動的に変更させるためのツールが必要。別件で作成中。
• H/W スイッチ, TCAMサイズの制限, 2048エントリはすぐ食うのではないか。小規模であれば大丈夫だけど、使い方やスイッチの使い方次第では足りなくなる気がする。TCAMからあふれた分って性能はどう?
• SET_NW_* をハードウェアでできる機材は?
• もうちょっと小さいスイッチがほしい(GbE48portはでかい)
• 小さいネットワークにOpenFlow入れるのって有効性とかどうなんだろう?

QA

• [Q.] 苦労したことは?
  • 思いの外安定していて、苦労したのはプログラム技術面くらい。
• [Q.] はじめてRubyさわってどれくらいでここまでいけたか？
  • 10月にプログラミングの学習開始〜先週からサービスイン。フルタイムではない。
  • 2000-3000行くらい。
• [Q.] 移行手順
  • 一気に切り替え
  • Tremaが止まっていた状態で、スタートするときに、ゴミファイル見たいのがあってうまくスイッチ認識しないことがあった、というのはあった。
  • 2回切り戻した。想定外の動作が多くて通信できるところとできないところがあるとか(バグだった)。
• [Q.] 実用導入、DHCPをリアクティブにフローしているところ、セキュアチャネルがダウンした時に故障発生を追求するのをどうするかとかどうしているか?
  • コントローラダウンなど、今回のスイッチはエントリを保持し続けるので残っていれば通信ができる。復旧したらまた正常な状態に切り戻る、というのは確認できた。
  • セキュアチャネルが切れたために困ったとかはない?
    • そういったトラブルは(まだ)ない
• [Q.] Rubyの知識ゼロからのスタート、そういう人に対してアドバイスするとしたら? どう学習アプローチするのがいいか?
  • ネットワークの基礎は知っていた。足りなかったのはコーディングのところ。Trema appsのソースとかExampleのソースとかひたすら読むというのをやった。
• [Q.] 今後の運用、コントローラのバグ修正、コントローラ停止などがあり得る。どう考えるか?
  • コントローラ止めるのに影響がないということはない(既存のフローが残る物はいいけどリアクティブなので新規のフローが処理できない
  • 待避用のスイッチをおいてある。
• 夜に人がいなくなって朝一気に使い始めたりすると、フローエントリが一気に増えてバーストとかありうる。もしフローエントリ数とかモニタリングしていなければとった方がいい。エントリ数の最初のバーストが激しい。突発的に来て減っていく。障害直前にフロー数変化がおかしくなるので、フローバーストとCPU利用率を合わせてモニタリングをしておくのがよいですよ。
  • エントリ数のピークが決まっていて、CPU利用率が最大でも40-50%くらい。とる必要はあると思うが今のところは大丈夫。コントローラの冗長化は今後OSSベースでやっていく想定。
  • いまは「モノが何かを検証する」というところがあったのでそこまで手が回っていない。
• [Q.] 社内NWを置き換えることで、従来のNWに比べてよくなったこと、今後どのように活用していきたいか。
  • 今回作ったコードの内容、通常のL3SWと変わらない。フルメッシュ構成できるというところが違う。拡張時の検証とかが不要で、スイッチをつなげば勝手に大きくなる。
  • 今後、OpenFlow 活かしてどうするか: SDNらしいネットワークとアプリケーションの連携について作って、お金につなげられたらいいな、ということを考えている。

LT: FPGAじゃだめなんです! (@SRCHACKさん)

TremaDay #2参加してきました - ＠SRCHACK.ORG（えす・あーる・しー・はっく）

• NW屋でも組込屋でもありません
• @ITデビューしました
  • TremaでSDNを手のひらに（1）：SDNの基本動作とアジャイルな開発が可能なSDN実装、「Trema」 (1/2) - ＠IT
• ORC出ます
  • 今年は5チーム
  • 一次審査通過

今年は何をやるのか?

• 「手はんだで作るEthernetスイッチ箱」
• 自作PCとか自作サーバとかあるけど自作スイッチ
  • ファームをカスタマイズできるスイッチがあったらいいな
    • ないから作ろう!
• 想像図?
  • FPGA? RasPI?
• Ethernet: 1port 16 I/O: FPGAだとおかねかかりすぎ
  • FPGAだと使いにくいから使うのやめればいい
• 2桁ポートほしい、4ポートまでは確認とれた。追加調達中
  • 利用するチップはQFPパッケージ、個人で入手できる100BASE-T
• Linux Driver作成中。
• 続きは 6/12 幕張で!

何か聞きたい話があれば

• [Q.] OpenFlow実践入門の続編は? 1.3の勉強用にとか。
  • [鈴木さんか高宮さんか] 個人的にはやりたい。販売は順調、増刷か新版か。やるならTrema Edgeの、1.3対応の話というのを検討中。
  • Trema Edge の Ruby Binding は Nick さんが実装してほとんどのメッセージが動く状況に。中身もだいぶ改善されていて、Featuresとってくるときとか、バイト列じゃなくてオブジェクトに変換されて処理できるようになっていたり。ソースコードもクラス階層とかが変更に。C言語の部分を押さえてなるべくRubyで書くようになっている。
  • コントローラの実装テクニック、レシピ的なモノ、テストをどうするかとか、Webアプリ屋さんは受け入れテストをするようなのを書くが、OpenFlowでもそういう開発手法などのアプリ寄りの話があったらいいな、という話は出てる。
    • テストフレームワークみたいなところでもう一歩進んだ話でも。
• [Q.] Trema switch がどうなっているか?
  • Nickさんと千葉さんががんばって、Trema Edge は vSwitch じゃなくて Trema Switch になってる。ビルドは通って基本的な動きはできる。コードが汚いとかはあるけどその辺の話もおもしろいかも。開発の人手が足りてない。
• 試すとなると小規模から始めたい、というので、小規模でも実例がいろいろあると。OpenFlow がどういうときにうれしいか。
• 近藤さんの進捗報告、その後の話を聞いていきたい
  • [近藤さん] 改善できるところは変えていきたい。コードにベタ書きになってる通信制御部分を、CLIとかGUIとかで操作できるようにするとか。活用の第1弾として、かっこいいGUIでNW制御したいというのでやって、Interopとか出すというのに注力していく。
• [鈴木さん] BGP/MPLS とかで興味のある人? 向けはちょっと考えておきます。

おわりに

懇親会とかでも話をしてたんだけど、1回目は Trema の開発状況とか技術の話が主体で、2回目になると実用、アプリケーション事例みたいな話がいろいろ出てきたという流れがとてもいいですねーという話をしたりした。この辺の活動がシュリンクしないようにいろいろ出していきたいよね、というのは結構聞いた気がする。

懇親会の話は…まあ書けない話とかも結構あったしやめとこうw 参加者マニアックな人たちが多くて面白かったです。