Open vSwitch (OVS)はかなり以前（2009年頃から）NetFlowをサポートしています。OVSでNetFlowをenableするには以下のようなコマンドを使います:

また、NetFlowをdisableにするには次のようにすれば良いです。

NetFlowには幾つかのバージョンがあります。その中でV5とV9が最もよく使われいるバージョンだと思います。OVSがサポートしているのはNetFlow V5のみです。NetFlow V9は現時点ではサポートしていません（OVSはNetFlow V9の直接の後継にあたるIPFIXをすでにサポートしているので、OVSがNetFlow V9をサポートするようになることはまずないと思われます）。

以下に、NetFlow V5パケットのヘッダーとフローレコード（1 NetFlowパケットに最大30個まで入ります）を示します。

NetFlow V5 header format

NetFlow V5 flow record format

NetFlow V5はIPv6のフローレコードを扱うことができません。IPv6トラフィックをモニターしたい場合は、sFlowかIPFIXを使ってください。

一般的なルータ/スイッチでのNetFlow実装と比較して、OVSのNetFlowの実装にはいくつかユニークな点がありますので、それらについて以下で述べます。

多くのNetFlow対応ルータ/スイッチではいわゆる「サンプリング」をサポートしてます。サンプリングとは、全パケットを処理するのではなく、一部だけを処理対象とするものです（サンプリング手法はいくつかありますが、このBlogの趣旨からはずれるのでここでは詳しくは述べません）。一方、OVSのNetFlowはサンプリングを行いません。OVSでサンプリングを使ったフロー処理をしたい場合はsFlowかIPFIXを使う必要があります。

OVSのNetFlowがサンプリングをしない、という点とも若干関連しますが、NetFlowフローレコード中にある「バイト数(dOctets)」と「パケット数(dPkts)」が32bitのフィールドなので、巨大なフロー（elephantフローなどと呼ばれることもあります）があると、これらのフィールドは比較的容易に溢れてしまいます。OVS内部では64bit値でバイト数、パケット数を数えていますので、これらの数が32bitでは収まらないフローがあった場合には、1つのフローの情報を複数のフローレコードに分けてエクスポートするようになっており、できるかぎり正確な値をコレクターに伝えるように努力をしています。

典型的なルータ/スイッチのNetFlow設定では、グローバルな設定（例えばエクスポート先の指定、など）に加え、インターフェース毎にNetFlow処理のenable/disalbe設定がある場合が多いと思います。一方、OVSではインターフェース毎の設定ではなく、ブリッジ毎にNetFlowの設定を行う形になっています。

多くのルータ/スイッチベースのNeflowエクスポータは、NetFlowパケットのソースIPアドレスを明示的に設定することができます（この際loopbackアドレスを使うのが一般的でしょう）。一方、OVSにはこのような設定はありません。OVSのNetFlowパケットのソースIPアドレスはホストOSのIPスタックによって決定さます。通常、このアドレスはパケットが送出されるインターフェースに紐付いているIPアドレスになります。NetFlow V5にはsFlowの「agent address」のような概念がないため、コレクターはNetFlowパケットのソースIPアドレスでエクスポータを区別するのが一般的です。OVSではNetFlowパケットのソースIPアドレスを明示的に設定することができませんので、なにかしらの理由でNetFlowパケットを送出するインターフェースが変わった場合は、NetFlowパケットのソースIPアドレスも変わる可能性があることに留意をしておきましょう。

ドキュメントにははっきりとは書かれていませんが、OVSはNetFlowエクスポータを複数指定するすることができるようになっています。これによりコレクタの冗長構成を実現することができます。設定は以下のとおりです:

通常フローベースのネットワーク管理を行う場合、フローレコードに含まれるインターフェースのIn/Outの番号がとても重要な意味を持ちます。なぜなら、このインターフェース番号の情報を使って、興味関心のあるトラフィックのフィルタをすることが多いからです。商用コレクターの多くは洗練されたフィルタ機能を持っていることが多いです。ルータ/スイッチのNetFlowエクスポータの場合は、このインターフェース番号にはSNMPのIfIndexが使われます。一方、OVSのNetFlowではOpenFlowのポート番号が使われます。この番号はovs-ofctlコマンドで確認することができます。

この例ではeth1のOpenFlowポート番号が1であることを示しています。幾つかのインターフェース番号は特定の意味を持っています。ホスト自身が持つインターフェース（上の例で”LOCAL”と示されているインターフェース）のインターフェース番号は65534になります。また、パケットがブロードキャスト/マルチキャストの場合にはOutのインターフェース番号は65535になります。一般的なルータ/スイッチではこれはどちらの場合もインターフェース番号は0になることが多いと思います。

あれ、最近OVSにはIfIndexが追加されたんじゃ、と思われる方もおられるかもしれません。ご指摘の通りで、最近OVSの”Interface”テーブルにIfIndexが追加されています。ではNetFlowでもこのIfIndexを使うべきではと考えるのはごもっともですが、実はそんなに簡単な話ではありません。例えば、OVSによって作られるトンネルインターフェース（GRE, VXLAN, STTなど）はIfIndexを持っていませんので、単純にNetFlowのフローレコードでIfIndexを使おうとすると、これらのインターフェースに流れるトラフィックの情報を伝えられなくなってしまいます。

NetFlow V5のヘッダには「Engine ID」と「Engine Type」というフィールドがあります。デフォルトでこれらのフィールドがどのような値になるかはデータパスの種類によって異なります。OVSがnetdevを使ったユーザスペースで動いている場合、Engine ID、Engine Typeはおのおのデータパス名のハッシュから得られた値の上位８bit、下位8bitになります。一方、Linux Netlinkを使ったkernelデータパスの場合は、Engine ID、Engine TypeともにデータパスのIfIndexが使われます。OVSのデータパスのIfIndexは以下のコマンドで確認することができます:

もちろんこららのデフォルト値は明示的に設定することも可能です。例えば以下のお通り:

上のコマンドは最初にNetFlowの設定を行うのと同時にEngine TypeとEngine IDを設定をする場合の例ですが、NetFlowの設定をしたあとに、関連パラメータを変更をすることも可能です。

典型的なEngine TypeとEngine IDのユースケースは、物理的には一つだが論理的には複数あるエクスポータを区別するというものだと思います。Cisco 6500のケースなどがいい例です。Cisco 6500はMSFCとPFCがそれぞれ独立したNetFlowエンジンを持っているので、これらを区別したい場合にEngine Type、Engine IDを使う場合があります。OVSの場合はには、複数のブリッジから出力されるNetFlowフロレコードを区別したいケースなどで使用することができます。先に述べた通り、OVSでは、NetFlowパケットのソースIPアドレスはホストの標準的なIPスタックにによって決められます（そしてこれは、必ずしもNetFlowがenableにされたブリッジインターフェスのIPアドレスと同じものにはなりません）。したがって、NetFlowパケットのソースIPアドレスを使ってどのブリッジからエクスポートされたフローレコードなのかを特定することができません。しかし、Engine TypeやEngine IDにそれぞれ個別な値を設定することによって、どのブリッジからのフローレコードなのかを識別することができるようになります。とはいうものの、Engine Type/Engine IDをみて論理的なエクスポータを識別することができるコレクターは私の知る限りそう多くはないと思います。

Engine IDに関してはもう一つの使い道があります。既に述べたように、OVSはNetFlowフローレコードのIn/Outのインターフェース番号としてOpenFlowのポート番号を使用します。OpenFlowのポート番号はブリッジごとにユニークな値です。したがって、複数のブリッジでは同じOpenFlowポート番号が使われる可能性があります。このままではコレクターはそれらのインターフェースを区別することができません。このような場合にはadd_to_interfaceという設定をtrueにしてやることで解決することができます。

このパラメータがtrueの場合、In/Outのインターフェース番号の上位7bitがEngine IDの下位7bitで置き換えられるようになります。ブリッジごとに異なるEngine IDを振るようにすれば、ブリッジ間のインターフェース番号の衝突を避けることができるようになります。

一般的なルータ/スイッチベースのNetFlowエクスポータと同様、OVSのNetFlowにもactiveおよびinactiveなタイムアウトの概念があります。activeタイムアウトは以下のようなコマンドで設定できます（秒で指定）。

明示的に設定されたない場合はactiveタイムアウトは600秒になります。また、activeタイムアウトに-1が指定された場合はactiveタイムアウトはしないようになります。

OVSのNetFlowにもinactiveタイムアウト機構が備わっていますが、明示的にこれを設定することはできません。OVSが管理しているフローの情報がinactiveタイムアウトでdatapathから削除された際にNetFlowのフローレコードもエクスポートされるようになっています。このinactiveタイムアウトは動的であり、さまざまな要素（OVSのバージョン、CPUやメモリの使用状況、など）によって決まります。このタイムアウト時間は最近のOVSでは通常1〜2秒と短めになっています。これは一般的なルータ/スイッチベースのNetFlowエクスポータのデフォルトのinactiveタイムアウト時間（通常15秒）と比べるとかなり短い時間となっています。

ICMPのフローがエクスポートされる際の扱いですが、OVSは一般的なルータ/スイッチと同様な動きをします。すなわち、フローレコードのソースポート番号に “ICMP Type * 256 + Code” の値を入れ、デスティネーションポート番号には0を入れる、というものです。

フローレコード中のNextHop、ソース/デスティネーションAS番号およびnetmaskは0になります。これはOVSが「スイッチ」であることを考えると妥当な動きと言えます。

ここまでで述べてきたように、OVSでNetFlowを使うにあたってはいくつかのポイントについて留意をしておく必要があります。sFlowやIPFIXと比べた時のNetFlowの強みの一つは、NetFlowをサポートしたオープンソースや商用のコレクタが豊富にあることだと思います。どのようなコレクタを選択してもまず間違いなくNetFlow V5はサポートされているはずです。ぜひ、OVSのNetFlow機能を試してみてください。きっとあなたのネットワークにいままでにない可視性を提供してくれることと思います。

私は2011年の5月に（当時の）Niciraに入りました。その当時、私は「Fivefront」という、以前Ascendで仕事をしていた時の同僚と起こした会社をやっていました。Fivefrontでは主にNetFlow / sFlowのコレクタ製品の販売に携わっていましたが、新しい商材も探すのも私のミッションの一つでした。あるとき米国の知人（彼もAscend時代の同僚でした）、彼が務めていた会社が日本に進出したいので一度話を聞いてくれないか、と相談があり、我々としても新しい商材を探していたので、一度話を聞かせて欲しいと返事をしました。彼の来日の日取りも決まり来日目前のところで、突然彼の会社が別の会社に買収されてしまったのです。彼はその買収元の会社で働く気はないとのことで、その会社を辞めてしまったため、来日の計画もパー、事業提携の話も白紙になりました。実はその彼が移った先の会社がNiciraだったのです。

彼が移った先の会社がどんなところか興味があったので、Webで調べてみたりしたのですが、当時のNiciraはまだステルスモードだったため、ホームページを見てもほとんど何も分かりません。でも、なんとなく面白そうな事をやっていそうな気配があったので、その彼に「前の会社の話はともかく、移った先の会社の話を聞かせて欲しい」と頼むと、ちょうどNiciraも日本に進出する計画があり、日本にも来る予定があるとの事だったので、その時に話を聞かせてもらう約束をしました。その前に少し勉強ておきたいので何か資料を送って貰えないかと頼んだところ「ステルスモード中なので資料は何も出せない。代わりにこの論文を読んでおけ！」と送られてきたのが、Martin Casadoらが書いた論文2本でした（笑）。そのうちの一本がこれです。

その論文を読んだところ、当時の私には100%理解はできかったものの、非常にドキドキしたの事を深く記憶しています。「ひょっとしたらネットワークが変わるかもしれない。もし変わるとしたら、こういうところから変わるはずだ！」と感じたのでした。後日、彼ともう一人エンジニアのボスが来日した際に話を聞きましたが、この直感は確信に近いものに変わりました。帰り際に「日本に進出するにあたりエンジニアを捜している。今回の来日でも何人かと面接をした。誰かいいエンジニアを知っていたら紹介してくれ」と頼まれました。心が揺れました。この会社に入ってこれからのネットワークを変える仕事に携わりたい、と思ったからでした。一方で、Fivefrontは本当に小さな会社だったので、仮に一人社員を欠くだけで会社に大きな影響を与える事は避けられません。ましてや会社を起業した一人として、一社員とはまったく違う次元の責任を負っています。一生懸命働いて小さな会社を支えている他の同僚の方々に対して大変申し訳なく思う気持ちはありました。しかし最終的には「僕をそのエンジニア候補の一人に加えてもらえないか？」とNicira側に申し出る決断をしました。

その後、Niciraの上層部の人たちから電話面接を受けました。その時の一人はMartinでした。あまり技術的な話をした記憶はありません。そもそも当時の私は仮想化に関する知識はほぼゼロでした。Hypervisorに触った事もありません。OpenFlowという言葉を知ってても、それがどんなものかも知りません。Open vSwitch？、何それ？状態です（笑）。当時、このへんの事についてアンテナを伸ばしていた人はNiciraがどんな会社で何をやろうとしているか、などなんとなく知っていたに違いありません。一方、私はド素人です。にもかかわらず、なぜか私は合格し（これはいまでも不思議でなりません）、晴れてNiciraで日本第一号の社員となりました。

入社して最初の週にたまたまSales/SEが一同に本社（カリフォルニア州パロアルト）に集まる機会があり、私もそれに出席しました。ただ、皆が何を話しているかさっぱり分かりません。新手のプロトコルかと思った4文字英語が実は客の名前だったりして、まったく話が噛み合いません（爆）。また、その日初めてNVP（NSXの前身）に触りました。「ほら、これ見てやってみろ」と、”Getting Started Guide” というドキュキュメントを渡されて、NVPの設定を初めて行いました。実はその時に初めてHypervisorというものに触りました。フムフム、Hypervisorって、こんなふうになってるのか。。ただ、ここをこうしてこう設定しろ、ってGetting Started Guideに書いてあるのですが、何のためにそれをしているのかさっぱりわかりません。そんな状態ですので、思ったように動かなかった場合の切り分けできようはずもありません。もうもなかば泣きながら設定をしました。当然予定されていた時間内に終わらず、居残り作業です。もう一人いた同時期入社のSEと夜遅くまで頑張りました。

そんな感じで始まったNiciraでの日々ですが、ステルスモードが明けてからあれよあれよという間にVMwareに買収され、NVPがNSXとして進化し、今日に至っています。その間、沢山の苦労もありました。長かったようでもあり短かったようでもあり。でも、今、自分がここにいれて本当に良かったと思っています。

前職にいた時に書いた拙作のBGPのライブラリコードをGitHubに公開する事にしました。

https://github.com/mshindo/bgp-server

このライブラリを使うと簡単にBGP4を喋るコードを書く事ができます。例えば以下のような感じ。

このようなコードを書いたきっかけは、ま、ちゃんとしたルータを買うお金がなかったってこともありましたが（笑）、大量の経路をGenieATMというBGPを喋るフローコレクターに注入する必要があったからです。最初はzebraを使って試そうと思ったのですが、さすがに100万経路くらいになると、いったんメモリに全経路を読み込まなければいけないzebraでは厳しくて（貧弱なマシンを使ってましたし）、じゃ、経路を注入するコードを書いちゃおう、と思い立ったのでした。

その後、いろいろなBGP関連の試験をする必要が出てきて、より汎用的なコードになっていきました。例えばJuniperとForce10のCapabilityの送り方が異なる事によるデバッグなどに役に立ちました。JuniperはOptional Parameterの中にCapability Advertisementを複数入れて、それぞれのCapability Advertisementの中に1つずつCapabilityが入っている形で広告されます。一方、Force10のほうはCapability Advertisementは1つだけで、その中に複数のCapabilityが並んだ形で広告されます。このような異なったBGPの実装をシミュレートするには、このコードは大変役に立つと思います。

このような経緯で生まれたコードなので、本コードはBGPの抽象度が少々低く実装されています。もう少し抽象度の高くする事もできたと思うのですが、そうするとBGPメッセージを組み立てる自由度が犠牲になるのでこのような形になっています。

また、このコードを使ってテストをする対象が主にGenieATMだったために、いくつか制限・制約があります。まず、本コードはBGPセッションを自分からは張りにいきません。相手からセッションが張られる事を期待しています（BGP「サーバー」の実装）。また、相手からBGPメッセージが来てもそれを読む事は基本せずに、自分からメッセージを送る事しかしません。いろいろなメッセージを送ってピアのBGPスピーカーの挙動を調べることに主眼を置いているためにこのようになっています。

もちろん、BGPの全ての機能を実装しているわけではありませんし、zebraに比べたら１万分の一の事もしていない「超なんちゃってBGP実装」ですから、あまり有用でないかも知れませんが、世の中の物好きな人に少しでも役に立てば、と思い、恥ずかしながら公開する事にしました。公開に関して私の背中を押してくれた田島＠アイマトリックスさんに感謝をしたいと思います。

Open vSwitchのリードエンジニアの一人であるJesse GrossがLinuxConでスピーカーを務める事になった事もあり、私も初めてLinuxConというイベントに参加することにした。

いくつかのトラックがあったが、私はVirtualization MiniSummitというトラックとoVirt Workshopに参加した。横浜パシフィコでの開催であり、参加者の8割くらいは日本人と思われる状態だが、全てのセッションは英語で行われる。日本人のスピーカーとほぼ日本人の受講者で構成されるセッションででも英語でやる、というのは私としては珍しい体験w

最後のパネルディスカッションも面白かった。Jesseが登壇した “Linux Virtualization” というセッションも面白かったが、Parallels社のCTOであるJames Bottomleyが行った”Social vs Technical Engineering in the Kernel: What This Means for Japanese Developers” は面白かった。昔はLinux Kernelに機能追加にしろバグフィックスにしろパッチを入れるのはさして難しい事ではなかったが、今はそれは簡単な事ではなくSocialな面も要求される。日本人のKernel Developerはどうするべきなのか、という話。

日本には優れたエンジニアが沢山いるのに、言葉や文化の障壁により世界に出て行く事が出来ないのはなんとももったいない事である。かくいう私も最近はすっかりご無沙汰な状況。深く反省。。まずはサンシャイン牧場を止めないと・・w