NWの仮想化とSDN

1.NWの仮想化とSDN

ネットワークの仮想化技術がSDN（Software Defined Network）です。SDNの定義は曖昧で、具体的な製品や技術を指すのではなく、概念になります。

SDN（Software Defined Network）とは、言葉の通りソフトウェア（Software）で定義（Define）できるネットワーク（Network）です。物理的な制約にとらわれずソフトウェアで実現するので、仮想化技術と考えてもいいでしょう。
　

仮想化なら、VLANなどもそうですよね。
はい、そうですね。ただ、SDNはもっと大胆に行えます。分かりやすい例でいうと、従来のネットワークでは、スイッチとFWと負荷分散装置が物理的に別々の機械で配置されていました。
それを各拠点にある機器の設定を変更するだけで、スイッチポートの設定やVLAN、ルーティングだけでなく、FW機能や負荷分散機能なども自由に設定できるのです。

過去問（H29秋AP午前問35）では、「ONF （Open Networking Foundation）が標準化を進めているOpenFlowプロトコルを用いたSDN （Software-Defined Networking）の説明」として「ネットワーク制御機能とデータ転送機能を論理的に分離し，コントローラと呼ばれるソフトウェアで，データ転送機能をもつネットワーク機器の集中制御を可能とするアーキテクチャ」と述べられています。

SDNの代表的な技術がOpenFlowです。H25年秋NW午後2問2に、OpenFlowの出題がありました。これを参考に、SDNについて整理していきます。以下は、K主任が調査を指示したネットワーク仮想化技術に関してです。

Ｔ君が調査したところ，大別して二つの新しい技術があることが分かった。 　一つは，オーバレイ方式と呼ばれるネットワーク仮想化方式で，レイヤ３ネットワーク上にレイヤ２をカプセル化して，同一テナントネットワークに属するサーバ間の接続用トンネルを作ることによって，ネットワーク仮想化を実現する。 　もう一つは，スイッチを，経路制御などの管理機能を実行するフローコントローラ（以下, OFCという）と，データ転送を行うフロースイッチ（以下, OFSという）に分け, OFSに入るパケットの経路制御をOFCが集中制御する方式（以下，OF方式という）である。OF方式は，カプセル化を使わず, OFSそれぞれの転送によって実現されることから，ホップバイホップ方式と呼ばれることもある。 　オーバレイ方式又はOF方式で実現されたネットワークは，どちらもソフトウェアで定義できることから，［　SDN　］と呼ばれている。

つまりネットワーク仮想化技術であるSDNは大きく2つがあります。
❶オーバレイ方式
　この問題の意味とは若干違うかもしれませんが、補足します。OpenFlowの場合、純粋なOpenFlowの機器だけを用いるのをホップバイホップ方式と言います。一方、既存のネットワーク機器をそのまま使い、OpenFlowの仮想スイッチでトンネルを張るものをオーバレイ方式と呼ぶ。オーバレイとは「重ね合わせる」という意味なので、既存の機器上でOpenFlowの仕組みを重ね合わせるという意味でしょう

❷ホップバイホップ方式
　その代表がOpenFlowです。上記のオーバレイ方式と対比すると、全てをOpenFlowの機器で構築します。

以下は、この過去問にある説明図です。詳しくは個別に解説します。

また、両者の比較もありましたので、引用します。

2.OpenFlowが登場した背景

時代の流れからすると、OpenFlowの発想は自然な流れでしょう。私の勝手な概念も入っていますが、以下の流れと通じると思います。
　【1】無線LANがWLCによる集中管理をすることが主流になった
　【2】サーバが仮想化され、一台のサーバに複数の機能を持たせるようになった。
　
【1】無線LANにてWLCによる集中管理
ただ、違いがあります。無線LANは、WLCと無線APは通常のネットワークでつながっています。
ですが、OpenFlowの場合は、コントローラであるOFCと各ネットワーク機器は、通常のNWとは別の専用ケーブルで接続されているのです。


【2】サーバの仮想化
　最近では、サーバの仮想化が主流です。1つのサーバ上に、Webサーバ、メールサーバ、DNSサーバなど、いくつものサーバを搭載し、複数の機能を実現します。仮想化していれば、冗長化の仕組みも簡単ですし、拡張や変更も柔軟に行えます。
　これが、ネットワークの世界でも起こっているのです。
　OpenFlowにより、一つのネットワーク機器上に、L2スイッチだけでなく、L3スイッチの機能や、FW、はたまた負荷分散装置（LB）の機能も持たせます。そして、冗長化機能や拡張、変更の柔軟さも持たせるのです。この仕組みが求められるのは自然な流れと思いませんか？

3.OpenFlowの利点および欠点（課題）

▼▼利点
いろいろな考え方があります。以下は私の主観ですので、あくまでも参考程度に。
❶DCやクラウド事業者むけの柔軟なネットワーク
　拡張や変更、障害時の切り替わりに柔軟なネットワークが構築できる。
　
❷大規模なネットワークを作れる
　特にVLANの制約が大きい。VLAN数は4096というの制約があるが、これがなくなり、実質的な上限はありません。DCなどで、多くのユーザを抱えるネットワークを構築する場合には、適しています。
　
❸プログラムを書いて、複雑な処理ができる。
　たとえば、負荷分散の設定も書けますし、負荷や条件に応じた設定もできます。細かな優先制御も設定できますし、冗長化の仕組みもできます。
　しかも、複数台機器を用意せずに、1台でやることも可能です。
　
❹FW、L2,L3、LBなどを一つに集約
　パケットを見てDropするなどのFW設定もできます。通常であれば、それぞれの機器を準備しなくてはいけません。しかもLBなどは値段が効果です。ソフトウェアでやれば費用をおさえて実現することも可能です。

OpenFlowを含めたSDNにより、大規模なネットワークで効果が期待できます。
ですが、機器もまだまだ高いですし、仕様も発展途上です。小規模ユーザに普及するのはまだまだ先のことでしょう。

▼▼欠点（課題）
・設定は従来のCiscoのに比べて複雑になる。ネットワークエンジニアが弱い（？）プログラミングの知識も必要。
・コントローラのソフトがメーカ系のもの、OSSのものなどさまざまです。さらに、プログラミング言語がPython（パイソン）であったあり、Rubyであったり、Cであったりする。なので、マルチベンダといっても、CiscoのIOSとJuniperのJunosが全く違うように、書く人はそれぞれの書きかたが違うので大変です。
・互換性の問題があります。従来のNW機器でもRFCに準拠はしていても、細かなところは実装によって違ったりする。同じことがOpenFlowにも言えて、Openflowプロトコルの仕様に準拠していても、メーカごとに実装の違いがあるので、相互接続検証が必要です。
・製品の価格が高い。安価にをうたっているが、実際に構築してみると高い
・コントローラと各スイッチを物理的な別NWで接続する必要がある。
・RFC化はされておらず、本当の意味でのマルチベンダとか、業界標準化はされていない。
→ぜひとも統一していただきたい。

4.OpenFlowとは

OpenFlowのopenはオープンソースである。文字通り、ソース（ソースコード）がオープン（公開）されている。OpenFlowはSDNの概念の1つですので、SDNの言葉の通り、ソフトウェアでのネットワークです。

❶特徴
・無線LANのコントローラ（WLC）が無線APを集中管理するように、OpenFlowのコントローラが、各ネットワーク機器を集中管理します。よって、各ネットワーク機器に、個別に設定入れる必要はなく、OpenFlowコントローラのIPアドレスや使用するIFなど、最小限の設定で済む。これはかなり便利です。
・L2スイッチ、L3スイッチ、FW、LBなど、複数の機能をあわせもてる。
・特定のベンダに依存しない。これで、メーカ依存の、製品による制約がなくなる。→実際にはメーカやソフト間の互換性の問題があり、そう簡単ではない。とはいえ、そもそもの発想はこういうことである。
・プログラムすればいいので、やりたいことが自由にできる。たとえば、CiscoではVRFによって、ルータを仮想化できる。これは、VRFの機能が搭載された機器だけが実現できる。でも、このような機能を用いて1つのスイッチに同一セグメントを複数作ったり（VRFでできたかは要確認）、ルーティングポリシーを分けたりなどをやろうと思っても、機器やそのOS（CiscoではIOS）が対応していなければ、実現できない。
　他には、従来はSTPによるループ対策があった。OpenFlowでは、物理的にはループになっても、通信経路ではそもそもループにならないようにすればいい。そういう調整が自由にできる。
・実際のデータを転送する「データプレーン」と、経路計算などの制御をする「コントロールプレーン」を分離する。コントロールプレーンはOFCが担い、データプレーンはOFSが担う。


❷用語
・OpenFlowコントローラ
・OpenFlowスイッチ
・FlowTable
・OpenFlowプロトコル


❸構成および動作
ネットワークスペシャリスト試験の過去問（H25秋NW午後Ⅱ問2）に基づいて、構成を確認しましょう。

OF方式では, OFSに入ってきたパケットのMACアドレス，IPアドレス, TCPポ－卜番号などの属性の組合せを“フロー”と呼び，そのパケットをどのように処理するかの判定に使用する。フローを識別し，入力されたパケットに対する処理を, OFS内のフローテーブル（以下, f-TBLという）に設定する。 OF方式でのOFCとOFSの構成を，図２に示す。OFCとOFS間の制御情報（以下，メッセージという）の交換のプロトコルを，0F Protocol と呼ぶ。 図２中のf-TBLの一つのエントリには，フローの識別情報（以下, Ruleという）を保持するRuleフィールド, Ruleに一致したフローをもつパケットに対する処理内容（以下, Actionという）を記述したActionフィールド，一致したフローのカウント値を保持するStatisticsフィールドなどがある。RuleとActionは, OFCが設定する。

❹団体
ONF（Open Networking Foundation）として、OpenFlowを推進する組織です。
また、ちょっと次元は違うかもしれないが、OpenDaylightという組織もあり、こちらもそうそうたるベンダが参加しています。こちらは、OpenFlowの概念も含めています。
Brocadeなどは、こちらに主軸を置いている気が……。


■R1秋NW午前Ⅱ

問12　OpenFlowプロトコルを使用するSDN （Software-Defmed Networking）において，コントローラとOpenFlowスイッチ間の通信に関する記述として，適切なものほどれか。 ア　オーバヘッドを避けるためにUDPやTCPは使用せずIPを直接使用する。 イ　信頼性や安全性を確保するためにTCPやTLSを使用する。 ウ　パラレル伝送を行うためにSANで利用されるファイバチャネル上のSCSIを使用する。 エ　リアルタイム性に関する要求を満たすためにUDPを使用する。

↓
↓
↓
↓
↓
正解は、イ

5.OpenFlowコントローラ

・OpenFLowスイッチとはOpenFlowプロトコルで通信をする。
・コントローラは、ソフトウェアであり、OpenFlowの仕様（2012年にVer1.3)にきちんと準拠していれば、どんなものでもいい。つまり、CiscoやHPなどの、メーカやベンダに依存しない。
　→とはいえ、実際には、メーカの癖が出てしまう。
・コントローラはソフトウェアで動作させればいいので、性能の問題は注意すべきであるが、普通のパソコンもコントローラになれる。
・オープンソース（OSS）系ではRyu（リュウ）やTrema（トレマ）、ちょっと古いがNOXなどがあります。一方のメーカ系では、NEC社のUNIVERGE PFシリーズのPFC（ProgrammableFlow Controller）やNTTデータの「バーチャルネットワークコントローラ」などがあります。

6.フローテーブル

フローテーブルはFWのおけるルールと考えればいいでしょう。この点に関して、ネットワークスペシャリスト試験の過去問（H25秋NW午後Ⅱ問2）にてきれいにまとめられているので、これを読むといいでしょう。

図２中のf-TBLの一つのエントリには，フローの識別情報（以下, Ruleという）を保持するRuleフィールド, Ruleに一致したフローをもつパケットに対する処理内容（以下, Actionという）を記述したActionフィールド，一致したフローのカウント値を保持するStatisticsフィールドなどがある。RuleとActionは, OFCが設定する。 Ruleとして利用できる情報, Action及びメッセージの例を，表１に示す。 　なお，ネットワークに参加するOFSは最初に必ずOFCに接続し, OFSのポート情報などをOFCに通知する。OFCは，OF Protocol を使ってトポロジを把握する。 　フローに対し, f-TBL内にRuleが一致するエントリがあった場合, OFSは当該エントリに記述されたActionの動作を行う。一方，なかった場合は, OFSはPacket In メッセージをOFCに送信し，そのパケットの処理方法を問い合わせるモードで動作する。Packet In を受信したOFCは, Flow Modメッセージを使用してf-TBLに処理のエントリを登録したり, Packet Out メッセージを使用して指定ポートからのパケット送信をOFSに指示したりする。 f-TBL内のRule及びAction内容の例を，表２に示す。

▼Rule

▼Action
この表の中で、Actionに関しては、Forward、Drop、Modify、Enqueueで考えましょう。内容は同じです。
　①Forward ：転送する
　②Drop　  ：破棄する
　③Modify  ：パケットを書き換える　※NATなど
　④Enqueue：キューに入れる　※優先制御など

▼Statistics
・Statisticsでは、該当通信の統計情報を持つことができる。

■動き
Flowテーブルですが、起動時にOpenFlowスイッチに送り込まれる場合もあれば、該当する通信が発生した都度、コントローラに問い合わせ（Packet In)して取得する場合もあります。一概には言えないが、後者の方が多いと感じています。また、従来のスイッチでもARPテーブルやMACアドレステーブルなどの情報はネットワークの接続状況によって、都度作成されます。なので、Flowテーブルは、FWルールのようにずっと同じというものではありません。また、取得したテーブルは、ある程度の時間がたつと、消されます。

▼補足：テーブルにルールが無かった場合
H30午後Ⅱ問2では、「どのマッチング条件にも一致しないパケットは廃棄される。」とあります。
基本は、Packet-Inを送るのですが、問題によって
条件が異なります。
H29NWでは，「事前の設定によって破棄するかPacketInにするか選択できる」とあるので，設定でどちらでも選べるようです。

7.OpenFlowスイッチ

コントローラの指令を受けて動作します。単なる箱と考えでもいいでしょう。

◆製品
・製品としては、HPのProcurveなどのOpenFlow対応のスイッチやNECのUNIVERGE PFシリーズであるProgrammableFlow Switch（PFSを用意するのが普通です。
・一方、仮想上で動かすのであれば、物理的なものは不要。Linuxなどのサーバ上にopenflowのソフトウェアを入れて動作させる。例えば、オープンソースの「Open vSwitch」があります。
・狙いとしては、OFSは単なる箱なので安価なものなのですが、まだまだ高いのが現状です。それは、OFSの機能だけでなく従来のスイッチの機能も持たしているからです。
・既存のSWにOSを入れ替えてできるものもあるかもしれない。実際、Buffaloの安価なルータでもOpenFlowスイッチ化できたそうです。興味がある方は、ネットで検索してみましょう。このルータはおそらくLinuxベースで動いているので、管理画面上からファームの更新処理をして、OpenFlowのソフトウェアを入れてしまうのです。

◆動き
・L2スイッチと同様に、各ポートには基本的にIPアドレスを設定しません。
　

普通、以下のようなネットワークの場合、
L3スイッチにIPをそれぞれ割り当てますよね？
 
たしかにそう。でも、IPは要らない。
以下のようになる。

　
でも、PC1はデフォルトGWである192.168.1.254にパケットを送ると思います。
OFSに192.168.1.254のIPアドレスを割り当てなければ、きちんと動作しないのでは？
OFCから指示をうけて、OFSが254のパケットに応答します。つまり、IPアドレスは割り当てられてはいないのですが、スクリプトによって応答します。PCからみたら、IPが割り当てられているように感じます。
※この点は、OFSによって実装が違う可能性がありますので、参考程度にお考えください。

8.OpenFlowプロトコル

　

Openflow関連の通信は、制御情報を流す通信と、実際の通信がありますよね。
そのプトロトコルは特殊なものなのですか？
まず、OpenflowスイッチとOpenflowコントローラ間の制御情報の通信に関して解説します。
制御情報はOpenFlowプロトコルを使います。この通信はイーサネット上のTCPで動作します。

次に、実際の通信ですが、OpenFlowの特殊なプロトコルとして通信しているのではありません。通常の通信そのままです。イーサネットファブリックでは拡張版のイーサネット（DCB：Data Center Bridging）が使われました。しかし、OpenFlowの場合は、通常のフレームがそのまま流れる。つまり、PCからTCPのパケットが来ればそのまま転送するし、UDPやICMPがくれば、そのまま転送する。　

9.OpenFlowのメッセージ

OpenFlowプロトコルでは、メッセージが規定されています。ネットワークスペシャリスト試験の過去問（H25秋NW午後Ⅱ問2）を確認しましょう。

フローに対し, f-TBL内にRuleが一致するエントリがあった場合, OFSは当該エントリに記述されたActionの動作を行う。一方，なかった場合は, OFSはPacket In メッセージをOFCに送信し，そのパケットの処理方法を問い合わせるモードで動作する。Packet In を受信したOFCは, Flow Modメッセージを使用してf-TBLに処理のエントリを登録したり, Packet Out メッセージを使用して指定ポートからのパケット送信をOFSに指示したりする。

また、この過去問では、メッセージの例が掲載されています。

過去問での解説は、シンプルではありますが、分かりやすく書かれています。

　

フローテーブルとは、FWのルールをイメージしています。OFCからOFSにルールが事前に送られるので、都度OFCにPacket Inで問い合わせるなんてことはないのでは？
無線LANのコントローラでも同じだと思います。
そういう設定もできるはずですが、最初のOFSにおけるフローテーブルは空です。ARPテーブルやMACアドレステーブルが、最初は空で、都度問い合わせ、数分後に消えるのと同じと考えてもらえばいいでしょう。このように、接続されている全ての機器の情報をOFCは把握できていません。MACアドレステーブルなどは通信をしながら都度学習していきますので、Packet Inなどのメッセージは必要です。
　
なるほど、Packet InメッセージをOFCに送信して処理方法を問い合わせ、OFCはFlow ModにてOFSのフローテーブルにエントリを追加するのですね。

10.OpenFlowスイッチとOpenFlowコントローラと接続

OFスイッチとOFコントローラとの接続に関して、ネットワークスペシャリスト試験の過去問（H25秋NW午後Ⅱ問2）には以下のように述べられています。

なお，ネットワークに参加するOFSは最初に必ずOFCに接続し, OFSのポート情報などをOFCに通知する。OFCは，OF Protocol を使ってトポロジを把握する。

OpenFlowスイッチにはコントローラのIPアドレスが設定されます。それに基づき、コントローラに通信をしTCPのコネクションを確立します。デフォルトではポート番号6633が使われます。
※接続先を設定ファイルに書いておいて、自動接続することがほとんどでしょう。
その後、コントローラではスイッチ側ののトポロジ把握をします。複数のOFSや端末がどのように接続されているかを把握するためです。LLDP( Link Layer Discovery Protocol )等のプロトコルを使うことが多くなります。

11.障害時の動作と2重化

　

無線LANの場合、コントローラがダウンすると、全通信が止まりました。
よって、2重化が必要ですね。
※メーカによって動作は違います。
そう。コントローラは2重化したほうがいい。ただ、多くの無線LANコントローラの仕組みと違い、データ通信はコントローラを通らない。だから、コントローラが壊れたとしても、通信はできる。しかし、コントローラへの問い合わせや変更などができないという制約がある。

▼▼コントローラの2重化の仕組み
スイッチ側にはMasterとSlaveなどと、複数のコントローラのが設定できる。よって、Masterが壊れてもSlaveと接続すればよい。一方、コントローラ同士の通信（Helloビートを送るなど）はOpenflowの仕様では規定されていない。各メーカにて実装を考える必要がある。

12.実際の設定をした感想

けっこう大変でした。 OpenFlowコントローラとしてNOXを使い、スイッチとしてOpen vSwitchという構成です。
簡単に紹介します。
①コントローラ、スイッチのソフトのインストール
②サービスの起動
③スイッチ側からコントローラへの接続。どのIFをデータプレーンとして使うかを指定し、コントローラのIPアドレスを指定して、接続 これだけで、L2スイッチとしての機能は実現できた。つまり、この仮想OpenFlowスイッチに接続されたPC間でPingが飛ぶ。 
④Flowテーブルの確認
実際に見てみましたが、かなり分かりにくいものです。FWのGUIで見れるようなポリシーとはちょっと違います。
⑤OFSにていろいろな設定
　コーディングがかなり大変です。その言語に精通していないと厳しいですね。

13.GUIのオープンフローコントローラ

OFCのGUIが発達してきた。
OpenDaylightは、2014年2月4日にHydrogenを公式リリース。Linux上で動くフリーソフトである。これにより、OpenDaylightに参加している（連携している？）OpenFlowの各スイッチが設定、制御できるらしい。
http://www.opendaylight.org/software/downloads

実際に画面をみたが、よくできている印象を受けた。実際に運用してみないと正しい判断はできないが。

NECは独自のものであり、こちらもGUIはドラッグして動かせるなど、よくできている。JR東日本での事例が紹介されている。
http://jpn.nec.com/press/201402/20140224_01.html