English
/ 
Japanese
English
/ Japanese
近いうちに Arista から真っ当な OpenFlow スイッチの実装が出てくると思われますが、とりあえず今テストすることができません。（2011年7月現在） そこで Open vSwitch を利用して Arista を OpenFlow スイッチとして利用した実験ができる環境を用意してみました。
注意： この実装は Arista のハードウェアスイッチ機能を全く利用しておらず、またソフトウェアスイッチである Open vSwitch のカーネルモジュールも使わず、userspace モードだけで実現しています。 そのためパフォーマンスは非常に低く、安定性も確認していません。 あくまでまともな OpenFlow 実装が出てくるまでの実験用のものとお考え下さい。 何にしても 48 ポートの OpenFlow スイッチが手に入るのです。どんなに遅くてもそれだけで素晴らしいじゃないですか！
Yutaka Yasuda (Arista Square)
29/July/2011 : 最初のリリース。モデル 7048T・EOS 4.6.2・Open vSwitch 1.1.1 で実験。
02/Aug/2011 : カーネルモジュール版について考察を追記
1. 概要
1.1 構成・動作環境
2. セットアップ
2.1 Open vSwitch のインストール
2.2 ポートの設定
3. 起動
3.1 コントローラの用意
3.2 OpenFlow daemon の起動
3.3 動作の確認
4. パフォーマンスチェック
4.1 iperf による評価
4.2 性能評価に関する注意
今回セットアップする OpenFlow 環境を図1に示す。 まず OpenFlow スイッチ部分にはそのオープンな実装である Open vSwitch の userspace モードを利用する。 またコントローラ部分にはやはりそのオープンな実装である NOX を、外部の PC 上で動作させて利用する。 実験では Arista の全てのポートを OpenFlow 対応にしたわけではなく、一部のポートだけを用いて行った。
図1. 今回セットアップした環境
今回のセットアップではパフォーマンスがもともと出ない点に注意されたい。詳細は 4.2 性能評価に関する注意 を参照のこと。
また今回のセットアップでは OpenFlow 処理プロセス (ovs-openflowd) がインタフェイスを見張るために TUN/TAP インタフェイスを利用している。 幸いなことに Arista には tun カーネルモジュールが用意されている（念のため lsmod で確認すると良い）が、これがスイッチポートの Ethernet インタフェイスには直接作用させられないという問題がある。 試みに tcpdump -i et10 とした場合と、et10 ただ 1 ポートだけからなる VLAN10 に対して tcpdump -i vlan10 とした場合の結果の違いを見ると良い。 （実は両者は違う理由から同じ結果になっているだけかもしれないが）
この制限のため、今回のセットアップではポート単位の制御ではなく VLAN 単位の制御になっている。 これについては 2.2 ポートの設定 にも説明がある。
参考までに、テストした Arista での EOS / Linux バージョン情報を示す。
localhost>show version Arista DCS-7048T-4S-F Hardware version: 02.02 Serial number: JSH09494949 System MAC address: 001c.730c.0c0c Software image version: 4.6.2 Architecture: i386 Internal build version: 4.6.2-365580.EOS462 Internal build ID: 92d7cfd3-379e-4e05-b1f3-73b79cde051d ....（中略） localhost>enable localhost#bash Arista Networks EOS shell [admin@localhost ~]$ uname -a Linux localhost 2.6.32.23.Ar-359566.EOS462-i386 #1 SMP PREEMPT Fri Feb 18 12:51:54 EST 2011 i686 athlon i386 GNU/Linux [admin@localhost ~]$
Arista EOS で動作させるために i386 アーキテクチャ用の Open vSwitch のバイナリを用意する。 今回試した EOS 4.6.2 は Fedora 12 をベースにしていると思われるので、手元の PC に 32bit Linux 環境をインストールしてそこで http://openvswitch.org/ から取得した openvswitch-1.1.1.tar.gz をビルドした。 作業は大抵の場合非常に簡単で、以下のようにするだけである。
# tar xzf openvswitch-1.1.1.tar.gz # cd openvswitch-1.1.1 # ./boot.sh # ./configure # ./make # ./make install
Open vSwitch をビルドすると、utilities ディレクトリ以下に各バイナリが作られる。 このうち ovs-openflowd と ovs-ofctl コマンドをどこか Arista の bash のパスが通っているところに置いておく。 つまり Open vSwitch のうち OpenFlow 処理に関係するのはこの二つだけである。
ovs-openflowd は下記のディレクトリを必要とする。以下の作業を行う。
# /bin/mkdir -p /usr/local/var/run/openvswitch #
通常、Open vSwitch を使う場合（あるいはシンプルな OpenFlow スイッチであれば）、OpenFlow スイッチはポート単位の制御を行う。 しかし今回のセットアップでは VLAN ベースの制御しか行えない点に注意。 （これについては 1.1 構成・動作環境の「制限事項」も参照。）
図2. ポートベースの制御（左）と VLAN ベースの制御（右）
しかし実質あまり違いはない。つまり OpenFlow で制御されたポートの先に、自動的に L2 switch （と幾つかのポート）が付いている、と考えれば良く、極端な構成として「たった一つのポートしか含まない L2 VLAN をポート数ぶんだけ用意」してやれば、実質的にポートを直接操作しているのと同じ事ができる。
今回は 4 つのスイッチポートを OpenFlow 制御とし、残りは通常の EOS 管理ポートとする。具体的には et10, et11, et14, et15 である。 ただしコントローラが Private Network 上に存在するため、そこと Arista 上で動作する OpenFlow スイッチ管理ソフトウェア（ovs-openflowd）が通信するためにコントローラと同一セグメントの VLAN を一つ作っておく。 具体的には et12, et13 である。
図3. 今回のポート設定
以下にまず特定の 1 ポートだけを含む VLAN を作成する例を示す。
localhost#configure localhost(config)#vlan 10 localhost(config-vlan-10)#interface ethernet 10 localhost(config-if-Et10)#switchport mode access localhost(config-if-Et10)#switchport access vlan 10 localhost(config-if-Et10)#spanning-tree mode none localhost(config-if-Et10)#no shutdown localhost(config)#vlan 10 localhost(config-vlan-10)#name vlan10 localhost(config-vlan-10)#interface vlan 10 localhost(config-if-Vl10)#spanning-tree mode none localhost(config-if-Vl10)#no shutdown << これを忘れない localhost(config-if-Vl10)# localhost(config-if-10)#show vlan configured-ports VLAN Name Status Ports ----- -------------------------------- --------- ------------------------------- 1 default active Et1, Et2, Et3, Et4, Et5, Et6 ..... 10 vlan10 active Et10 localhost(config-vlan-10)#
VLAN10 に、スイッチポート一つだけが登録されていることが分かる。 これを OpenFlow 制御対象の 4 つのポート全てに対して行う。
ところで後半の vlan インタフェイスに対する no shutdown を忘れずに。 これをやらないと bash 上で ifconfig とやった時に vlan インタフェイスが現れてこず、結果的に OpenFlow の制御対象として指定することが出来ない。
次にコントローラとの接続のためのポートを設定する。 具体的には et12, et13 を一つの VLAN に設定し、それにコントローラと同セグメントの IP アドレスを割り当てる。 なお 2 ポート割り当てたのは、et13 に PC を接続してコントローラとの経路を確認する、といった作業を想定してのことであり、特別な意味はない。
（VLAN へのスイッチポートの割当についてはすぐ上の記述と同一なので省略） localhost(config)#interface vlan 12 localhost(config-if-Vl12)#ip address 192.168.12.111/24 localhost(config-if-Vl12)#show interfaces vlan12 Vlan12 is down, line protocol is lowerlayerdown (notconnect) Hardware is Vlan, address is 001c.730c.1e6b (bia 001c.730c.1e6b) Internet address is 192.168.12.111/24 Broadcast address is 255.255.255.255 Address determined by manual configuration MTU 1500 bytes localhost(config-if-Vl12)#show ip route << このとき route もなし Codes: C - connected, S - static, K - kernel, O - OSPF, B - BGP Gateway of last resort: S 0.0.0.0/0 [1/0] via 211.9.56.33 C 211.9.56.32/29 is directly connected, Management1 localhost(config-if-Vl12)#
Vlan 12 is down と出たり、ルート情報も無いものとして出るが、線を接続してやることで以下のように変化する。
localhost(config-if-Vl12)#show interfaces vlan12 Vlan12 is up, line protocol is up (connected) Hardware is Vlan, address is 001c.730c.1e6b (bia 001c.730c.1e6b) Internet address is 192.168.12.111/24 Broadcast address is 255.255.255.255 Address determined by manual configuration MTU 1500 bytes localhost(config-if-Vl12)#show ip route Codes: C - connected, S - static, K - kernel, O - OSPF, B - BGP Gateway of last resort: S 0.0.0.0/0 [1/0] via 211.9.56.33 C 192.168.12.0/24 is directly connected, Vlan12 << ここで route 情報が付く C 211.9.56.32/29 is directly connected, Management1 localhost(config-if-Vl12)#
このタイミングで ping を controller に飛ばすなりして確認すると良い。
localhost(config-if-Vl12)#ping 192.168.12.96 PING 192.168.12.96 (192.168.12.96) 72(100) bytes of data. 80 bytes from 192.168.12.96: icmp_seq=1 ttl=64 time=1.58 ms 80 bytes from 192.168.12.96: icmp_seq=2 ttl=64 time=0.115 ms 80 bytes from 192.168.12.96: icmp_seq=3 ttl=64 time=0.130 ms ^C
OpenFlow 制御対象となった 4 ポートをどのようにプログラムするかはコントローラ次第であるが、今回は単なる L2 MAC 学習スイッチとなるようコントローラ側を設定する。
具体的にはコントローラとなる NOX を起動する際に pyswitch あるいは switch を指定する。
（以下の操作は Arista 上ではなく NOX を起動する PC 上での作業）
# pwd /home/hoge/nox/build/src # ./nox_core -v -i ptcp:6633 pyswitch [root@pavilion src]# ./nox_core -v -i ptcp:6633 00001|nox|INFO:Starting nox_core (/home/ylb/nox/build/src/.libs/lt-nox_core) 00002|kernel|DBG:Assigned a new UUID for the container: 8351905445277066603 00003|pyrt|DBG:Loading a component description file 'nox/coreapps/examples/t/meta.json'. ...
先に用意した ovs-openflowd を Arista 上で起動する。 各オプションの説明についてはマニュアルを参照されたいが、userspace モードで実行する際にはブリッジ名（下の例では br0）もポート指定（vlan10以降）もすべて引数で行う点に注意。 Open vSwitch は普通これらを独自 DB に定義した情報を引いて行うが、userspace モードでの Open Flow 処理は実質 Open vSwitch のほとんどの機能を使わず、ovs-openflowd だけで完結している。
# ovs-openflowd netdev@br0 --ports=vlan10,vlan11,vlan14,vlan15 tcp:192.168.12.96 Jul 29 03:19:54|00001|openflowd|INFO|Open vSwitch version 1.1.1 Jul 29 03:19:54|00002|openflowd|INFO|OpenFlow protocol version 0x01 Jul 29 03:19:54|00003|ofproto|INFO|using datapath ID 0000002320d34d60 Jul 29 03:19:54|00004|rconn|INFO|br0<->tcp:192.168.12.96: connecting... Jul 29 03:19:54|00005|rconn|INFO|br0<->tcp:192.168.12.96: connected Jul 29 03:19:54|00006|ofp_util|WARN|received Nicira extension message of unknown type 8 Jul 29 03:19:54|00007|ofp_util|INFO|normalization changed ofp_match, details: Jul 29 03:19:54|00008|ofp_util|INFO| pre: wildcards=0xffffffff in_port= 0 dl_src=00:00:00:00:00:00 dl_dst=00:00:00:00:00:00 dl_vlan= 0 dl_vlan_pcp= 0 dl_type= 0 nw_tos= 0 nw_proto= 0 nw_src= 0 nw_dst= 0 tp_src= 0 tp_dst= 0 Jul 29 03:19:54|00009|ofp_util|INFO|post: wildcards= 0x23fffff in_port= 0 dl_src=00:00:00:00:00:00 dl_dst=00:00:00:00:00:00 dl_vlan= 0 dl_vlan_pcp= 0 dl_type= 0 nw_tos= 0 nw_proto= 0 nw_src= 0 nw_dst= 0 tp_src= 0 tp_dst= 0
この状態で、Arista の port #10, #11, #14, #15 のいずれかに接続されたホスト間では通信ができるはずである。 ping などで確認すると良い。
通信に成功しているのなら、ovs-ofctl ツールを用いてフローテーブルやポート状況などの確認ができる。
ovs-ofctl コマンドを用いて、OpenFlow daemon が管理しているポートの一覧が得られる。
# ovs-ofctl show br0 OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:0000000000001000 n_tables:2, n_buffers:256 features: capabilities:0x87, actions:0xfff 1(vlan10): addr:00:1c:73:0c:1e:6b, config: 0, state:0 2(vlan11): addr:00:1c:73:0c:1e:6b, config: 0, state:0 3(vlan15): addr:00:1c:73:0c:1e:6b, config: 0, state:0 4(vlan14): addr:00:1c:73:0c:1e:6b, config: 0, state:0 LOCAL(br0): addr:c2:d0:54:26:1a:f5, config: 0x1, state:0x1 current: 10MB-FD COPPER OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0 #
左端に表示されるポート番号はコントローラ側で処理を行うために重要なのだが、これがどうもランダムについてしまってコントロールできないように思える。（情報求む）
以下は二台のマシンを et10, et11 に接続して ping による通信を行ったときのフローテーブルの中身である。 ARP と ICMP が往復分、上に示したポート番号 1 (vlan10 = et10), 2 (vlan11 = et11) の間を結ぶように設定されていることが分かる。
# ovs-ofctl dump-flows br0 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=31.176s, table_id=0, n_packets=1, n_bytes=60, idle_timeout=53,arp,in_port=2,vlan_tci=0x0000,dl_src=00:d0:59:09:e3:9a,dl_dst=00:03:47:89:8f:e5,nw_src=0.0.0.0,nw_dst=0.0.0.0,opcode=0 actions=output:1 cookie=0x0, duration=76.176s, table_id=0, n_packets=78, n_bytes=7644, idle_timeout=53,icmp,in_port=2,vlan_tci=0x0000,dl_src=00:d0:59:09:e3:9a,dl_dst=00:03:47:89:8f:e5,nw_src=192.168.13.101,nw_dst=192.168.13.100,icmp_type=0,icmp_code=0 actions=output:1 cookie=0x0, duration=76.178s, table_id=0, n_packets=78, n_bytes=7644, idle_timeout=53,icmp,in_port=1,vlan_tci=0x0000,dl_src=00:03:47:89:8f:e5,dl_dst=00:d0:59:09:e3:9a,nw_src=192.168.13.100,nw_dst=192.168.13.101,icmp_type=8,icmp_code=0 actions=output:2 cookie=0x0, duration=31.175s, table_id=0, n_packets=1, n_bytes=60, idle_timeout=53,arp,in_port=1,vlan_tci=0x0000,dl_src=00:03:47:89:8f:e5,dl_dst=00:d0:59:09:e3:9a,nw_src=0.0.0.0,nw_dst=0.0.0.0,opcode=0 actions=output:2 #
まず今回のセットアップは全く性能が出ない組み合わせであることに注意されたい。 詳細については 4.2 性能評価に関する注意 を参照。
評価はポートの両端に 1Gbps インタフェイスの Macintosh を接続し、iperf で 10 秒間 TCP データを送信したときの平均帯域で行う。
これはほぼ考えられる最も高い性能数字であると考えられるが、何しろもともと性能が出ない構成であるためこれ以上悪い条件になった場合の落ち込みなどについて調べることはしなかった。 実際の利用状況ではもっと短いフローが多いため、CPU により高い負荷を掛けて更に低いスループットしか期待できなくなることが明らかである。
まず計測に用いる Macintosh や iperf の能力を調べるために、Arista (7048T) の OpenFlow 制御がかかっていない、同一 VLAN 設定のポートに二つの Macintosh を接続して計測した。 下に示すように 940Mbps 程度が楽に出ることを確認した。
% iperf -c 192.168.13.111 ------------------------------------------------------------ Client connecting to 192.168.13.111, TCP port 5001 TCP window size: 129 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.13.110 port 49242 connected with 192.168.13.111 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.09 GBytes 940 Mbits/sec %
OpenFlow 制御対象ポートの両端に Macintosh を接続した場合の結果を以下に示す。 150Mbps 前後の値となった。
% iperf -c 192.168.13.111 ------------------------------------------------------------ Client connecting to 192.168.13.111, TCP port 5001 TCP window size: 129 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.13.110 port 49239 connected with 192.168.13.111 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.2 sec 191 MBytes 157 Mbits/sec %
このとき ovs-openflowd は全プロセス中最大の CPU 使用率となった。 80％ ほども消費しているのでほぼいっぱいと考えて良いか。 以下に top の結果を示す。
top - 06:55:17 up 3:52, 3 users, load average: 0.10, 0.07, 0.01 Tasks: 134 total, 5 running, 129 sleeping, 0 stopped, 0 zombie Cpu(s): 38.9%us, 22.0%sy, 0.0%ni, 27.6%id, 0.0%wa, 0.0%hi, 11.4%si, 0.0%st Mem: 2054984k total, 1284636k used, 770348k free, 95632k buffers Swap: 0k total, 0k used, 0k free, 737564k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8536 root 20 0 2596 1212 976 R 78.8 0.1 0:18.40 ovs-openflowd 1422 root 20 0 165m 51m 18m R 29.6 2.6 63:55.00 PhyBcm54980 1386 root 20 0 155m 41m 12m R 19.9 2.1 43:17.18 Mdio 1413 root 20 0 181m 64m 26m S 7.6 3.2 23:01.05 SandCell 1354 root 20 0 172m 78m 38m S 2.0 3.9 4:34.26 Sysdb 1423 root 20 0 164m 50m 17m S 1.0 2.5 1:43.46 PhyAeluros 1355 root 20 0 171m 69m 32m S 0.7 3.5 1:53.24 Fru 1377 root 20 0 154m 40m 10m R 0.7 2.0 0:55.50 PhyEthtool 1396 root 20 0 154m 39m 9m S 0.7 2.0 0:52.62 Thermostat 8524 root 20 0 19132 10m 7900 R 0.7 0.5 0:00.56 top 1352 root 20 0 153m 30m 2136 S 0.3 1.5 0:54.25 ProcMgr-worker 1375 root 20 0 158m 45m 15m S 0.3 2.3 0:04.88 Lag+LacpAgent 1376 root 20 0 155m 42m 12m S 0.3 2.1 0:40.02 Adt7462Agent 1379 root 20 0 155m 41m 12m S 0.3 2.1 0:40.59 Smbus 1 root 20 0 2048 840 616 S 0.0 0.0 0:00.43 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root RT 0 0 0 0 S 0.0 0.0 0:00.01 migration/0 4 root 20 0 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/0 5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
比較のために一般的な PC 上に Open vSwitch で構成した OpenFlow スイッチでの計測結果を示す。 CPU は Intel Core 2 duo E7200 2.53GHz である。 OS は Fedora 12 64bit。 メモリが 2GB しか載せていないが、swap には出ていないことを確認している。
この PC がもつ三つの OpenFlow 制御象ポートの二つに Macintosh を接続した場合の結果を以下に示す。 370Mbps 前後の値となった。
% iperf -c 192.168.13.111 ------------------------------------------------------------ Client connecting to 192.168.13.111, TCP port 5001 TCP window size: 129 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.13.110 port 49259 connected with 192.168.13.111 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 442 MBytes 371 Mbits/sec %
このときの ovs-openflowd もやはり全プロセス中最大の CPU 使用率となった。 98％ ほども消費している。
top - 16:19:00 up 6 days, 23:47, 7 users, load average: 0.33, 0.09, 0.03 Tasks: 188 total, 2 running, 186 sleeping, 0 stopped, 0 zombie Cpu(s): 13.6%us, 30.0%sy, 0.0%ni, 43.3%id, 0.7%wa, 0.0%hi, 12.4%si, 0.0%st Mem: 2047912k total, 1800656k used, 247256k free, 259136k buffers Swap: 4128760k total, 0k used, 4128760k free, 939936k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 16248 root 20 0 39572 1880 1428 R 97.6 0.1 0:32.33 ovs-openflowd 1633 root 20 0 134m 20m 9504 S 2.3 1.0 24:08.65 Xorg 2218 ylb 20 0 298m 17m 9.9m S 1.3 0.9 12:41.13 gnome-terminal 4 root 20 0 0 0 0 S 1.0 0.0 0:00.57 ksoftirqd/0 7 root 20 0 0 0 0 S 0.7 0.0 0:38.41 ksoftirqd/1 1206 root 20 0 0 0 0 S 0.3 0.0 0:32.45 kondemand/0 16086 root 20 0 883m 21m 6360 S 0.3 1.1 0:06.43 lt-nox_core 16268 root 20 0 14928 1204 864 R 0.3 0.1 0:00.11 top 1 root 20 0 4144 888 620 S 0.0 0.0 0:00.66 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root RT 0 0 0 0 S 0.0 0.0 0:00.01 migration/0 5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0 6 root RT 0 0 0 0 S 0.0 0.0 0:00.01 migration/1 8 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/1 9 root 20 0 0 0 0 S 0.0 0.0 0:03.73 events/0 10 root 20 0 0 0 0 S 0.0 0.0 0:05.25 events/1 11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuset 12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khelper 13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 netns 14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 async/mgr 15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pm 16 root 20 0 0 0 0 S 0.0 0.0 0:00.25 sync_supers
なお、このマシンは NOX コントローラそのものであるが、iperf が行うような単一のフローしか来ない場合は NOX にはほとんど負荷が掛からないために性能上の大きな障害にはなっていないと考える。 実際、上記 top でも lt-nox_core はほとんど CPU を消費していない。
Arista 157Mbps、PC 370Mbps となり、およそ倍ほどの差がある。 CPU 能力が AMD Athron 1.8GHz と Intel Core 2 Duo 2.5GHz であることと、ネットワークインタフェイスへの I/O が一度 TUN/TAP 経由になっている点で Arista が不利なことから、およそ妥当な結果に思える。 少なくとも飛び抜けて Arista が低速なソフトウェア実行能力しかないわけではない。
ただし Open vSwitch は性能のためにカーネルモジュールの利用が可能である（むしろそれがデフォルトである）が、今回のセットアップでは Arista も、この PC もそれを利用していない。 Arista 用のカーネルモジュールの生成も不可能ではないと思われるので、飛躍的に性能があがるのであれば検討しても良いか。
PC 上でカーネルモジュールを使った場合の性能測定を行ったところ 840Mbps 程度となり、CPU 負荷もほとんど無い事がわかった。 370 : 840 をそのまま外挿すると Arista でもカーネルモジュールの利用によって 400Mbps 程度の性能が見込める。 また 840Mbps というとそろそろ各種の上限に押さえつけられていそうなので、低性能な Arista の方がヘッドルームがあると考えるともう少し出る可能性がある。 個人的には実験室で OpenFlow のテストを仮運用するには 500Mbps 出れば充分である。 カーネルモジュールの生成にトライしても良さそうに思える。
今回のセットアップは全く性能が出ない組み合わせであることに注意されたい。
本来、図4. の左側に示すように OpenFlow はソフトウェア処理による柔軟な経路選択と、ハードウェアによる高速なスイッチングを両立させることをカギとして設計されている。 Arista は充分な処理能力をもったプロセッサと厚いソフトウェアスタックをスイッチに積み込んでおり、もともと OpenFlow を実装するのに適した構造をしている。（図4. 右側。細かいことを言えば OpenFlow が定める Flow Table の全ての項目をサポートするためには、ソフト側で幾らか以上（あるいは丸ごとフローテーブルのコピーを）持つ必要があるかも知れないが、実際にはスイッチチップ内部にあるフローテーブル相当の何かに展開されてハードウェアレベルでパケットのフォワーディングが実行されることになるだろう。）
図4. 標準的な構成（左）と Arista による実装（右）
これに対して今回のセットアップは図5.左側に示すようにフローテーブルの管理だけではなく、パケットのフォワーディングを含めた全ての処理をソフトウェアで行う構成になっており、本来の OpenFlow スイッチの理念とはかけ離れた構造で実現している。 これではパフォーマンスなど出るはずもない。
図5. 今回の構成（左）と PC による構成（右）
しかし逆に言えば、これは図5.右側に示すような通常の PC をベースとした、Open vSwitch によるソフトウェアベースの OpenFlow スイッチと全く同じ構造である。
そうは言っても、Open vSwitch はそうしたソフトウェア処理での限界をできるだけ引き上げるためにカーネルモジュールを利用して高速化を図っている。 しかし今回のセットアップではこれを利用せず userspace モードでの実行によって実現している。 当然ながら更にパフォーマンスが犠牲になっている。
性能的には全く良いところがないが、メリットは他の面にある。そのひとつはポート数である。 2011年7月現在、商品として販売されているハードウェアベースの OpenFlow スイッチがほとんど無く、あっても高価であるため、ほとんどの OpenFlow の実験は Open vSwitch を用いた PC ベースで行われていると想像する。 しかし PC ベースでは実装できるポート数が非常に制限される。 今回のセットアップでは 48 port などといった、スイッチとしては当たり前だが PC では非常に実現が難しい環境が容易に手に入る。 そしてそのために必要なスペースも非常に小さい。
また、ovs-openflowd を複数起動し、一つの筐体に複数の OpenFlow Switch を構成することが可能である。 Mininet でもそのような環境を用意してくれるが、そこに実際のトラフィックを流し込むことは容易ではない。 Arista を用いた場合、ポート数に余裕があるため例えば 10 個の OpenFlow Switch を作り込み、相互に線を組み合わせたうえで、実機を複数台つないで現実のトラフィックを処理させることが可能である。 例えばメッシュネット的な物理配線の上で、消費帯域やプロトコルに応じて動的に経路選択を行うようなコントローラを書き、その上で YouTube を見ながら Skype で話したときに想定していたような変化が起きるか確認する、といったことが考えられる。