Geneve on Open vSwitch

先日のBlogでGeneveという新しいEncapsulation方式について紹介をしましたが、さっそくOpen vSwitch(OVS)に実装されmasterにマージされましたので試してみました。今回はGeneveを検証する事が目的ですので、KVMなどは使わずに、単純に異なるホストにある2つのOVS BridgeをGeneveトンネルで繋いでみることにします。VMware FusionでUbuntu 14.04を2つ(host-1、host-2)動かし、それぞれgithubから取ってきた最新のOVSをインストールしました。各仮想マシンにはNATによるEthernetインターフェースを1つ設定し、DHCPでアドレスをとる事にします。以下の例ではそれぞれのホストで192.168.203.151と192.168.203.149というIPアドレスがDHCPで取れた場合の例です。Bridgeを2つ(br0、br1)作成し、br0を物理ネットワークと接続するブリッジとし、br1の間にGeneveのトンネルを張る事にします。

Geneve Test with Open vSwitch Geneve Test with Open vSwitch

host-1, host-2でのOVSの設定は以下の通りです。

[shell]mshindo@host-1:~$ sudo ovs-vsctl add-br br0
mshindo@host-1:~$ sudo ovs-vsctl add-br br1
mshindo@host-1:~$ sudo ovs-vsctl add-port bra eth0
mshindo@host-1:~$ sudo ifconfig eth0 0
mshindo@host-1:~$ sudo dhclient br0
mshindo@host-1:~$ sudo ifconfig br1 10.0.0.1 netmask 255.255.255.0
mshindo@host-1:~$ sudo ovs-vsctl add-port br1 geneve1 — set interface geneve1 type=geneve options:remote_ip=192.168.203.149[/shell]

[shell]mshindo@host-2:~$ sudo ovs-vsctl add-br br0
mshindo@host-2:~$ sudo ovs-vsctl add-br br1
mshindo@host-2:~$ sudo ovs-vsctl add-port bra eth0
mshindo@host-2:~$ sudo ifconfig eth0 0
mshindo@host-2:~$ sudo dhclient br0
mshindo@host-2:~$ sudo ifconfig br1 10.0.0.2 netmask 255.255.255.0
mshindo@host-2:~$ sudo ovs-vsctl add-port br1 geneve1 — set interface geneve1 type=geneve options:remote_ip=192.168.203.151[/shell]

このような設定をすれば、host-1とhost-2のbr1間のpingが通るようになり、物理ネットワーク側にパケットが出る際にはGenveでトンネルされます。
[shell]mshindo@host-1:~$ ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.759 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.486 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.514 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.544 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=0.527 ms
^C
— 10.0.0.2 ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.486/0.566/0.759/0.098 ms
mshindo@host-1:~$ [/shell]

Wiresharkでパケットを見てみましょう。Wiresharkにも2014/06/16にGeneveのdissectorが追加されていますので、最新のWiresharkをビルドすればGeneveパケットの中身を見る事ができます。

Geneve Frame by Wireshark
Geneve Frame by Wireshark

Geneveが使うポート番号は6081/udpです(このポート番号は2014/03/27にIANAに登録されています)。また、今回のように単純にOVSのBridge同士を繋ぐだけであれば特にVNIは必要はありませんので、明示的にVNIの値を指定していません。その場合はVNIの値は0になります。VNIの値を明示的に設定したい場合は、

[shell]mshindo@host-1:~$ sudo ovs-vsctl add-port br1 geneve1 — set interface geneve1 type=geneve options:remote_ip=192.168.203.149 options:key=5000[/shell]

というようにoptionsでkeyというパラメータで指定すればOKです。その際のパケットは以下のようになります(10進数の5000は16進数では0x1388)。

Geneve Frame with VNI 5000 by Wireshark
Geneve Frame with VNI 5000 by Wireshark

GeneveはEthernetフレームだけではなく、他のタイプのフレームもトンネルできるようになっています。そのためにProtocol Typeというフィールドが用意されています。今回の例ではEthernetフレームをトンネルしていますので、Protocol Typeの値はTransparent Ethernet Bridgingを示す0x6558が指定されています。

現時点の実装では、Geneveの特徴であるGeneve Optionsを指定する事はまだできません。追ってサポートが加えられると思います。

Geneveの真価が発揮されるのは、Geneveのフレームフォーマットを理解してTSOをすることができるNICが出現した場合です。そのようなNICは現時点ではまだ世の中には出てないですが、少なくともソフトウェア的(OVS的)にはGeneve Readyになりました。現在はまだmasterブランチにしかGeneveのコードが入っていなかったのでgithubの最新masterブランチから取ったコードをビルドして試しましたが、OVSのバージョン2.2がリリースされれば、今回試したコードも含まれてくることになるので、簡単に試す事ができるようになるはずです。

Geneve Encapsulation

L2 over L3のencapsulationとしては、GRE, NVGRE, VXLAN, STTなどが良く知られているものですが、新たなencapsulationとして “Geneve” というものがIETFに提案されています(draft-gross-geneve-00.txt)。ドラフトにはWorking Group名は入っておらずまだ個人名になっていますが、現在nvo3 (Network Virtualization Overlays) Worging Groupで議論がされています。ドラフトを書いているのはVMware, Microsoft、RedHat、Intelの人たちです。

現時点でも十分にいろいろな種類のL2 over L3 encapsulation方式があり、それぞれ実装も多数あるのに、なぜさらに新しいencapsulation方式を作る必要があるのでしょう? まず、前提として各種L2 over L3 encapsulationは、多少の差こそあれ、本質的にはL2フレームをL3データグラムで包んでやる事が主目的であり、それを実現するために幾つもの方式があるのは、作る側(ベンダー)にとっても使う側(ユーザ)にとっても嬉しい事ではないであろう、ということがあります。

その上で、Geneveが目指すのは、主に以下のの2点となります。

  • 拡張性を備える事
  • オフロード機能を有効に活用できる事

NVGRE, VXLAN, STTヘッダはいずれも固定長で自由に拡張する事ができないため、今後新たに必要となるさまざまな要件に対応するのが困難です。そのような新たな要件として1つ想定されるのが “metadata” のサポートです。ここでいうmetadataとは、パケット自体ではなくそれに付随するさまざまなcontext情報の事を意味します。例えばパケットがどのようなサービスを経由すべきか(いわゆるservice chaining)や、そのパケットが誰が出したどのようなアプリケーションのパケットであるのか、などと言った情報がmetadataにあたります。NVGRE, VXLANはいずれも原則仮想ネットワーク識別子しか扱えず、このようなメタな情報を伝えるのが困難です。STTには64bit長の “Context ID” というフィールドがあるので、ここを利用する事でNVGREやVXLANよりは多くの情報を伝える事ができますが、64bitという固定長フィールドですので伝えられる情報量には限りがあります。

そこでGeneveでは、encapsulationに拡張性を持たせられるように、固定フィールドに加え、自由に伝える情報を拡張する事が出来る可変長のOptionフィールドが定義されています。このフィールドはいわゆるTLV (Type/Length/Value)形式を取っており、自由に拡張をすることができます。また、Typeの前にはOption Classというフィールドがあり、Typeの名前空間を定義できます。ここに(IANAから割り当てられた)ベンダーIDを入れる事でベンダー固有のTypeを自由に定義・追加できるように設計されています。

Geneve class= Geneve Options

Geneveヘッダには2種類のフラグ(O、C)が定義されいます。OフラグはOAMフレームを表し、CフラグはCriticalフレームを表しています。GeneveのOAMはEnd-to-EndのOAMを想定しており、途中の経由するノードがこのフラグを見てなにかしらの解釈してはしてはいけない事になっています。また、GeneveのEndノードはOフラグが立ったパケットを優先的に処理する事が期待されています。一方、Cフラグが立っているオプションを受け取ったEndノードはそれを解釈しなければなりません。逆に言うと、Cフラグが立っていなければ、それを受け取ったノードはそれを無視しても良い、ということになります。

VXLAN、NVGREと同様、Geneveでも仮想ネットワークを識別するための識別子(VXLANではVNI、NVGREではVSID)は24bit長となっています。また、VXLANと同様、GeneveでもUDPでトランスポートするよう定められており、UDPソースポート番号を適切に使うこととにより、ファブリックのようなマルチパスネットワークの帯域を最大限有効に使えるようにになっています。

2つ目のGeneveのDesign Goalのである「オフロード機能を有効に使えるようにする」という点はL2 over L3 encapsulationする際に高い性能を実現する上でとても重要です。各種オフロード機能の中でも特にSegmentation Offload機能は性能向上において非常に有効に機能します。Segmentation Offload機能は、最近の多くのNICで実装されている機能の一つで、CPUの負荷を減らしつつ高いスループットを実現する事のできる仕組みです。具体的には、オペレーティングシステムからNICに対して非常に大きなパケットの送信を依頼しするようにします。そのような大きなパケットは実際にはネットワーク上に出す事は出来ませんので(MTUの制限)、パケットを小さく分断(segmentation)してネットワーク上に出してやる必要があるのですが、通常はこの処理はソフトウェア(オペレーティングシステム)が行います。Segmenation Offload機能を持つNICの場合は、このsegmenation処理をオペレーティングシステムに代わってNICがハードウェアで処理をしてくれます。このような機能は一般的にはLarge Segmenation Offload機能と呼ばれており、特にTCPパケットにに対して行う場合TSO (TCP Segmenation Offload)機能と呼ばれています。LSO/TSOが機能すればホストのCPUサイクルを使わずに済みますので、ホストのCPUに負荷をかけず高いスループットを実現する事ができます。実際STTではこのNICのTSO機能を上手く利用できるように工夫されていて、TCPでEncapsulationをするようになっています。

Encapsulationの拡張性と性能はトレードオフの側面があります。Encapsulationに拡張性を持たせるために、ヘッダにOptionフィールドを儲けて自由に情報を追加できるようにすると、NICからするとどこからデータが始まるのかが分からずにSegmentation Offloadを行うのが困難になるからです。そこで、GeneveヘッダにはOptionの長さがはっきり(一つ一つのOptionをパースしなくとも)とわかるように、明示的にOption長を入れるようになっています。このフィールドの値を見ればNICはすぐにデータがどこから始まるのか判断する事ができます。Geneveではこのフィールドは6bit長ありますが、実際のOptionの長さはこのフィールドの値の4の倍数の長さになるので、最大64*4=256バイトのOptionを扱う事ができる、ということになります。

STTはTSO機能を持った既存のNICでH/Wアクセラレーション効果を享受できますが、Geneveではどうでしょう? 上述したように、Geneveでencapsulationされたパケットに対してNICのSegmentaion Offload機能を利用するためには、GeneveのOption長フィールドを意識する必要があり、Segmentationする際にGeneveのヘッダ(Optionも含む)を全てのSegmentにコピーしてやる必要もありますので、NIC自体がGeneve対応(Geneve-aware)になっている必要があります。現在はこのようなNICは存在しませんが、Geveneではこのような実装をハードウェアで行いやすいように慎重に設計されているのが特徴になっています。今後GeneveのOptionがいかに増えようとも、Geveve自体の仕様を変える必要はなく、また、Geneve-awareなNICのSegmentaion Offload機能になんら影響を与えずにOptionを自由に追加していくことができます。Geneveでは拡張性と性能を両立させる事ができるわけです。

一方、Geneveに反対をしている人たちもいます。そのような人たちの主張はおおかた以下のよなものです。

  • Geneveで実現しようとしている事は、既存のencapsulation(L2TPv3のstatic tunnelingやVXLAN)の拡張で実現可能なので、新たなencapsulationは要らない。
  • metadataをencapsulationにbindするべきではない。
  • VNIが24bitでは不十分。最低でも32bitは欲しい。

一般的にはL2TPはシグナリングを含みますが、L2TPのシグナリングを使わずに両端で静的に必要な設定をする事でL2TPを使う事も可能です。これをL2TP static tunnelingといい、この場合は純粋なencapsulation (Pseudo Wire)方式ということになります。L2TPv3自体は2005年にRFCになっていますので、十分に枯れた仕様であり実装も十分にあります。例えばCisco IOSでも実装されていますし、Linuxでもip l2tpコマンドで利用できます。

L2TPv3のデータパケットのencapsulationには実質上Session IDとCookieしかありません(Tフラグは常に0、Verは3である必要があります)。

L2TPv3 Data Header

L2TPv3 encapsulationではSession IDがVXLAN/GeneveのVNIに相当する事になり、ここは32bit長となっています。

このパケットフォーマットを変えないままL2TPv3 static tunnelにGeneveのような拡張性を持たせる事も可能ですが、その場合は両端で(合意できる)設定をして、それをSeesion IDとして表す事になります(この点を考慮すると、Session IDを純粋にVNIとして使える訳ではない、ということになります)。この暗黙の合意はEnd Point同士でしか分かりませんので、途中のノードがそれを解釈することはできません。この「途中のノード」にはNICも含まれることに注意をすべきでしょう。

一方、Segmentation Offload機能を使えるか、という点については、現状のL2TPv3の仕様的には難しいでしょう。L2TPv3 encapsulationではCookieの長さもパケットを見ただけではわかりません(極端な話、その有無さえもわかりません)。これらはL2TPのシグナリングの過程(static tunnelの場合は両端の静的設定)で決められます。どこからデータが始まっているのかをNICなどに伝える事ができないためSegmentation Offloadを実現するのは困難です。ただしL2TPv3の前身のプロトコルであるL2TPv2には “Offset” というフラグとフィールドが定義されていて、これでデータがどこから始まるのかをヘッダー部分に入れる事ができるようになっています。L2TPv3 encapsulationにはこのOffsetフィールドは(RFC的には)定義されていませんが、L2TPv2時代の名残りでL2TPv3でもこのOffsetフィールドを使う事ができる場合が多いようです。

上記のような観点からは、VXLANもL2TPv3 encapsulationとあまり大きな違いはありません。

VXLAN Header

標準で規定されている以外の情報(現状はVNIしか伝える事しか出来ない)を伝えようとすると、現状のReservedとなっているフラグやフィールドを使って拡張をするか、パケットのフォーマットを大幅に変更をする事になるでしょう。例えば、現状のVXLANヘッダにはencpasulationするフレームがどのようなフレームなのかを示すフィールドがなくencapsulationの対象となるフレームはEthernetのみですが、VXLANでEthernetフレーム以外をencapsulationするようにするための拡張が提案されています(draft-quinn-vxlan-gpe)。この拡張はまさにReservedなフラグとフィールドを使ってVXLANを拡張しています。Encapsulation対象のフレームの種類を表すだけならなんとかReservedのフィールドでおさまるので、VXLANのパケットフォーマットを変更せずに済みますが、これ以外の拡張をしたくなったらもはや使えるフィールドはないので、フレームフォーマットの変更を余儀なくされるでしょう。

現状のVXLANヘッダは8バイトで固定なので、Segmentation Offloadはし易い仕様になっていますが、このフレームフォーマットを超えた拡張情報を扱いたくなった場合には、Segmentation Offloadするのは困難になってくるでしょう。

一方、metadataをencapsulationにbindすべきではない、という意見はそれなりに的を得ているように思います。metadataはencapsulationに対して直交しているべきで、どのようなencapsulation(VXLAN, NVGRE, L2TPv3, etc.)でも使えるべきだ、と考えるのは自然です。実際metadataを一般的な枠組みとしてどのように扱うかについては、IETFのsfc(Service Function Chaining)Working Groupというnvo3 WGとは別のWGで議論されています。ただ、だからといってGeneveがmetadataにbindされている、という指摘をするのはいささか勇み足でしょう。Geneveはmetadataを格納できるような仕組み(フレームワーク)を提供するだけで、そこにmetadataを入れる事を強要しませんし、metadataをどのように表現するかも規定していません。あくまで、Optionフィールドの使い方の一つとして考えられるのがmetadataの格納である、というだけです。Service Function Chaining方式とmetadataの表現方法が標準化されればそれに従えばよく、それまでの間はGeneveのOptionフィールドを使ってmetadataを運べるようそのような枠組みを用意しておく、というのは非常に合理的だと思います。Optionフィールドはmetadata以外の目的にも使えるわけですし。

VNIが24bitでは足りない、という意見ですが、24bitでも1600万個のネットワークを表現できるので、これで足りないという主張は私はあまりピント来ません。このような主張をしている人たちは、このVNIを純粋にネットワークの識別子としてだけ使うのではなく、そこに何かしらのsemanticsやmetadata的なものを含めようとすると24bitでは足らなくなくなる、という事を懸念しているように思います。GeneveではOptionフィールドでmetadataなどのcontextを表現できますので、VNIは純粋に仮想ネットワーク識別子として使えます。であれば24bitあれば十分なのではないでしょうか?

結局のところ、Geneveの存在意義があるかないか(既存のencapsulationで十分ではないか)という議論は、encapsulation方法としてmetadata以外に想定される拡張機能が必要か否か、という点に行き着くのではないかと思います。もし、metadata以外に想定される拡張機能が必要ないのであれば、sfc Working Groupの標準化を待ち、既存のencapsulation(あるいはその若干の修正形)を使えば良いでしょう。Geneveが提供してくれる他の機能(OAMの識別や、Ethernet以外のフレームを扱える枠組み)は他のencpsulation方式もフレームフォーマットを大きく変更することなく対応できるでしょうし、そのような拡張もすでに提案されています。逆に、今後metadata以外での拡張の必要性が見込まれるのであれば、新たに必要となるOptionが増えてもNICのSegmenation Offload機能を利用できるGeneveは非常に理にかなったencpasulationであると言えます。

Geneveは拡張性を備えつつもVXLAN/NVGREのようにハードウェアで処理しやすいように(特にNICでのSegmentation Offloadが機能するように)設計された、STTとVXLAN/NVGREの両方のエッセンスを汲んだ新たなencpasulationです。この新しいencpasulation方式が市民権を得られるかどうかは、Geneveをサポートしたハードウェアやソフトウェアがどれくらい早く市場に現れてそれが受け入れられるか、という点にかかっていると思います。

私がNiciraに入ったわけ

私は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として進化し、今日に至っています。その間、沢山の苦労もありました。長かったようでもあり短かったようでもあり。でも、今、自分がここにいれて本当に良かったと思っています。

万里の長城に行ってみた

慕田峪長城入口
慕田峪長城入口

日航の北京発羽田着便は夕方発なので、それまでの時間を利用して万里の長城に行ってみる事にした。もちろん初体験。

万里の長城は全長3000キロ近くあるので、色々なエントリーポイントがあるわけだが、今回は北京からも近く、景色も良いとされる慕田峪長城に行ってみる事にした。北京市内からは車で1.5時間くらい。ホテルを朝の7時に出発して、現地に着いたのは8時半頃であった。

入り口から徒歩で上がる事もできるようだが、今回はケーブルカーである程度上まで登ってから万里の長城を楽しむ事にした(あとの事を考えると、この選択は正しかったと思われるw)。ケーブルカーを降りて右に行くコースと左に行くコースがあったが、今回は左のコースを選択した。朝早かった事もあり、客数は少ない。

Relatively easy slope
最初は比較的なだらかな道のり。

最初は比較的なだらかな坂道である。慕田峪長城は万里の長城の中でも比較的よく整備がされているそうで、石畳と階段がしっかりとしており歩き易い。しかし、徐々にきつい坂が続くようになり、場所によっては角度が60度くらいの階段もあり(こうなると階段と言うよりもむしろ梯子に近い)かなりしんどい。

Steep slope.
厳しい階段。

ポイントポイントに砦のようなものがある。ここからの眺めは抜群である。また、吹く風が心地よい。

一応最後の砦まで行ってもその先に進む事はできるようだ。ただし、その先には整備が一切されていないので、滑落の危険等があるため進まないほうが賢明、ということで、そこで引き返してくる事にした。良く言う事であるが、登りよりも下りのほうがつらい。登りで足が疲労しているせいもあるのだろうが、下りは踏ん張らなければいけないくて、それがかなりこたえる。フラフラしながら無事に下山。

Steep step. Almost like a ladder.
急な階段。というよりほとんど梯子w。

ともかく圧巻であった。よくもまあ、こんな事をやろうと思い、そしてそれをやってのけてしまったもんだと感心してしまった。普通に考えたら国の廻り3000キロも壁てくくってしまおうなんて、馬鹿げててとても実行には移せないと思う。それをやってのけてしまうところが中国の凄いところだ。

帰りにケーブルカー降り場のトイレに同行したもう一人のエンジニア(彼は台湾人)が入ったが、彼がしばらくして居心地悪そうに出てきた。トイレットペイパーがなかったとのこと。なんとか持っていたパンフレットなどを使って対処をしてきたとのこと。海外からの観光客も多い施設なはずなのに、このへんにも中国らしさを感じてしまった(笑)

Unmaintained wall
最終の砦の先にも長城は続いているが、整備はされておらず、こんな感じの状態。危険なのでこれより先には行かず。

OpenStack APAC Conference

OpenStack APAC Conferenceに参加するために北京に来ています。台湾は前職で何度も行きましたが、中国本土は上海に一度だけ行った事があるだけで、北京は今回が初めてです。いきなりのチャレンジは、タクシードライバーがまったく英語が喋れなかった事。iPhone上の中国語辞書アプリを頼りに、片言の中国語でなんとか目的のホテルにたどり着きました。

OpenStack APAC ConferenceOpenStack Conferenceは大盛況でした! 500人くらい集まってたでしょうか? 日本でこれだけの人数が集まるか、というと正直少々疑問です。中国と日本では人口と言う母数が多いに違いますが、それにしても中国の盛り上がり方は半端ではない、という感じを受けました。

中国のインターネット事情は特に新鮮でした。いろいろ制限があると聞いてはいましたが、実際に体験してみるとやっぱり軽くカルチャーショックです。ホテルのインターネットからはFacebook、Twitter、YouTubeは繋がりません。Googleは香港のGoogle (www.google.com.hk) にリダイレクトされ、かつ著しく遅いです。Mixは問題なく繋がりました。肌色系のサイトもブロックの対象のようです(ただ、星の数ほどある肌色系サイトは全部はつぶし切れないようで、見れたり見れなかったりのようですw)Google was redirected to Hong Kong

モバイルの扱いは興味深いです。iPhoneから3GでChina Unicomに繋いでいると、Facebook, Twitter, YouTubeは普通に繋がりました。携帯経由のインターネットアクセスは個人が特定し易いので、地上系インターネットよりも制限が少し緩いのでしょうか?不思議なのは、iPhone 3G/China Unicom経由だとFacebookで他の人のタイムラインは見れますがメッセージは使えない事です。メッセージだけ制限する意味がどれだけあるのかはなはだ疑問ですが、同じサイトでもコンテンツによって制限をかけたりかけなかったりする、という「高度」(笑)な制限が行われているようです。

BGP4 library implementation by Ruby

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

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

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

#
# example1.rb
#
require 'bgp-server'

open = Open.new(7675, '172.16.167.1')
openmsg = BgpMsg.new(open)

origin = Origin.new
pathseg1 = AsPathSegment.new([100, 101, 102])
aspath = AsPath.new
aspath.add(pathseg1)
nexthop = NextHop.new('11.0.0.2')
localpref = LocalPreference.new

path_attr = PathAttribute.new
path_attr.add(origin)
path_attr.add(aspath)
path_attr.add(nexthop)
path_attr.add(localpref)

nlri = Nlri.new(['10.0.0.0/8', '20.0.0.0/16'])
update = Update.new(path_attr, nlri)
updatemsg = BgpMsg.new(update)

keepalive = KeepAlive.new
keepalivemsg = BgpMsg.new(keepalive)

bgp = Bgp.new
bgp.start
bgp.send openmsg
puts "OPEN sent"
bgp.send keepalivemsg
puts "KEEPALIVE sent"

bgp.send updatemsg
puts "UPDATE sent"

loop do
  sleep 30
  bgp.send keepalivemsg
  puts "KEEPALIVE sent"
end

このようなコードを書いたきっかけは、ま、ちゃんとしたルータを買うお金がなかったってこともありましたが(笑)、大量の経路を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に比べたら1万分の一の事もしていない「超なんちゃってBGP実装」ですから、あまり有用でないかも知れませんが、世の中の物好きな人に少しでも役に立てば、と思い、恥ずかしながら公開する事にしました。公開に関して私の背中を押してくれた田島@アイマトリックスさんに感謝をしたいと思います。

LinuxCon Japan 2012

LinuxCon Japan 2012Open 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

ありがとう、Steve。

ほぼ2年ぶりに書くBlogがこの話になるとは思ってもみなかった。

Steve Jobs。

彼は間違いなく少なからず僕の人生に影響を与えてくれた人のうちの一人だ。

Appleの時の彼は、もちろんAppleの創業者の一人として認識していたものの、当時僕自身はAppleユーザではなかったこともあり、それ以上の存在では無かった。その後、Appleを追われ、NeXT Computer(以下NeXT)を立ち上げた頃から、彼との接点が多くなったように思う。

僕にとってNeXTは強烈であった。僕にとって初めてのUNIXワークステーションがNeXTであったというのもあるが、それ以上に、NeXTが僕がそれまで知っていたコンピュータとあまりに異なっていたせいだと思う。美しい筐体とディスプレー、そして当時としては先進的なMOを搭載。ハードウェアも奇抜だったが、一番驚いたのはソフトウェアだ。特にInterface Builder(IB)にはただ驚くばかりだった。なぜ、インタプリタ言語ではないObjective-Cで書いた自分のコードが、リンクする事なしにその場でユーザインターフェースと結合テストができるのか? 静的なバインディングの世界しか知らなかった僕にとって、あの動的な世界は衝撃であった。ウィンドウシステムも、当時一般的であったX WindowではなくDisplay PostScriptを採用。そして、カーネルにマイクロカーネルのMachを採用した。これも斬新であった。僕がMachを生んだカーネギーメロン大学(CMU)に行く大きな動機となった。

SteveがAppleに復帰後、傾きかけていたAppleにiMacを投入し、そこからの成功劇はみなさんも良くご存知の事と思う。無骨なコンピュータをスタイリッシュなものに変身させ、音楽をネットワークからダウンロードできるビジネスモデルを作り、携帯電話の世界を変えてみせた。単にコンピュータだけではなく、我々の生活環境を確実に変えてくれた。そんな人はいままでいなかったと思う。

彼が生きていたら、これからどれだけ我々の生活を変えてくれたのだろうか、と思うと本当に残念でならない。この言葉はもう彼には届かないけれども、とにかく心から感謝の意を表しておきたい。ありがとう Steve。

INTEROP2009講演アンケート結果

毎年恒例のINTEROPで行った講演のアンケート結果が返ってきました。今年私が担当したのは「無線LANセキュリティー2009 〜WEPは秒殺、WPA/WPA2もあぶない?!〜」というセッションです。アンケートは以下のような項目について5段階評価(1:低、5:高)で評価されます。今年の結果は、

 期待に添えたか: 4.24
 仕事に直接役立つか: 3.65
 資料の質: 4.06
 スピーカーの知識: 4.44
 発表内容: 4.29
 時間配分: 4.09
 ======
 総合評価(上記の平均): 4.13

となりました。

今年28個あった有料コンファレンスの総合評価の平均は3.91、総合第一位のコンファレンスは4.20だったとのこと。またしても今回も1位には一歩及びませんでした。。一度でいいから1位を取ってみたいんですけどね〜(笑)。仕事に役に立つか、という項目の点数が足を引っ張った形ですが、これはテーマによってはどうしようもない面があります。僕の話はどちらかというとコンシューマ向けの話(家庭での無線LAN)が大きな部分を占めるので、この部分はどうしても低くなりがちです。それを除けば自分としては非常に満足の行く結果だったと思います。いくつか寄せられたコメントには、

  • 現実的な対処策について、規模別、熟練度別に示してくれると効果的と思います。次回ご検討ください。
  • 大変面白かったです。
  • 満足。時間が短い!
  • 無線LANの最近の状況が確認できました。ありがとうございました。

というような意見がありました。

来年私が何かセッションをやるかどうかまだ分かりませんが、もし来年もまたやらせてもらえるなら、さらに質の良いセッションにできるように頑張りたいと思います。個人的にはフローに関するセッションを復活させたいな〜。

ちなみに去年の結果は

http://motonori.spaces.live.com/Blog/cns!E9A0896D01EF341E!856.entry

にあります。