SDNはソフトウェアにより全てのネットワーク機器を集中制御して、ネットワーク構成や設定などを柔軟に動的に変更することができる「技術の総称」のことであり、OpenFlowはそのSDNを実現する技術のひとつということを前回の記事で見てきました。
SDNを実現する技術としては、OpenFlow以外にもありますが、SDNと言えば、OpenFlowという見方も強く、OpenFlowを理解することで、SDNが何を目指し、従来の仕組みとどのように変化するのかが自然と見えてくると思います。
今回の記事では、そのOpenFlowについて詳しく見ていきます。
OpenFlowが登場した背景
ネットワーク機器は、事前に設定した情報や自律的に収集した情報を元にして、パケットを転送します。
例えばレイヤ2スイッチは、受信したパケットから学習したMACアドレスを用いてパケットの転送先を決めます。ルータやレイヤ3スイッチは、事前に管理者がルーティングテーブルを作成し、転送先を静的に決めたり、OSPFやBGPといった、ルーティングプロトコルを用いて取得した経路情報を用いています。
このような機能が各ネットワーク機器に搭載されており、我々エンジニアは、それぞれの機器を適切な位置に配置し、設定することでネットワークを構築しています。
シンプルなネットワークであれば良いのですが、昨今はネットワーク機器の種類も増え、かつ、ネットワーク構成が複雑になっています。それなのに、ネットワーク構成を素早く柔軟に変更することが求められるようになっています。特に、在宅ワークなど働き方が大きく変わった2020年は、ネットワーク管理者にとって大変な年だったと思います。「ネットワークが遅くて仕事にならない」といった厳しい言葉をもらった管理者も多かったのではないでしょうか。
ただ、あるところに負荷が集中したとき、別のところに余裕ができるのが世の常です。在宅ワークの例では、リバースプロキシサーバーなどが配置されるDMZネットワークはトラフィックが多くなった一方、人がいなくなった社内ネットワークのトラフィックは減少していたと考えられます。
このようなとき、従来は、負荷が高くなったDMZのネットワークを増強するしか手はないわけですが、OpenFlow技術を取り入れていれば、DMZネットワークに割り当てるリソースを増やし、社内ネットワークのリソースを減らすといった柔軟な構成変更が可能となります。
OpenFlowの登場の背景には、上記のような構成変更を素早く柔軟に実施したいというニーズに応えるためという理由があります。さらに、構成変更にかかる工数を抑えられるという面もあります。
ネットワーク構成を変更するというのは、簡単なようで実はとても難しいことです。サーバーの構成変更なら、途中、手順を間違えたなどで失敗したとしても、影響はそのサーバーが提供するサービスのみとなり、局所的なものとなりますが、ネットワークの場合は、影響範囲はすごく広くなります。万が一にもつながらくなってしまったら、すべての業務を停止させてしまうことにもなりかねません。
なので、例えば、FWのポリシーひとつ追加するにしても、手順書を作成して、有識者とレビューして、実機検証してと、かなりの工数がかかってしまいます。エンジニアからしたらそれだけの作業が必要になるわけだから、その分の対価を求めるわけですが、お客さんから見れば、何でそれだけの作業でこんな金額になるんだと激怒するわけです。複数の機器にわたる作業であれば、さらに工数が膨らむのは言うまでもありません。
こういったギャップによってお客さんともめることは昔から本当によくあり、私も何度も経験してます。
そこで、もっと工数を減らす方法ないかと、先人のエンジニアが考え、辿り着いたひとつの解決策がOpenFlow技術です。
OpenFlowを知る
平成29年のIPAネットワークスペシャリスト試験でSDN技術であるOpenFlowを扱った問題が出題されましたが、その問題を通してOpenFlowの理解を深めていきましょう。
国内外に顧客をもつ生産機器メーカーであるA社は、IoT時代に適応するために、新たな情報システム基盤を整備中であり、NWの拡張を予定しているという背景説明から問題は始まります。
NW拡張の目的を次に示す。
工場LANのSDN(Software-Defined Networking)化：
SDN技術を用いて、現在の工場LANを、ビジネス変化に対応できる柔軟性と拡張性を備えた新たな工場LANに刷新する。新工場LANでは、物理配線の変更なしに、自社要員だけで構成変更ができるようにする。
ベンダから提案があったSDN技術について、D君は次のように整理した。
従来のスイッチ機能を、経路制御などの管理機能を実行するフローコントローラ（OFC）と、データ転送を行うスイッチ（OFS）に分け、OFSに入るパケットの経路制御をOFCが集中制御する方式を採用する。
OFSとOFCは、管理のための専用NWを介して、通信メッセージを交換する。
OFCとOFS間の通信メッセージを下表に示す。
| 通信メッセージ名 | 通信の方向 | 用途 |
|---|---|---|
| Packet-In | OFS→OFC | 入力パケットと入力ポートIDを、OFCに通知する。 |
| Packet-Out | OFC→OFS | 出力パケットと出力ポートIDを送り、OFSに出力させる。 |
| Flow-Mod | OFC→OFS | 変更情報を送り、OFSの管理テーブルを変更させる。 |
OFSは、IPアドレス、MACアドレスなどのパケット識別子(Match Field、以下、MFという)を使ったパケット識別条件と、識別されたパケットの処理(以下、Actionという)の組み合わせ(以下、エントリという)を、OFS内の管理テーブルで管理する。
何を言っているのですか？ついていけません！
文章だけではわかりずらいので下図を見てください。
PC1からPC2宛てのパケットを受信したOFSであるスイッチは、そのパケットをどのように処理したら良いかをOFCに尋ねます（②Packet-In）。OFCは自身が持つ管理テーブルを参照して、OFSに「そのパケットはあっちへ転送してください」といったような指示を出します（③Packet-Out）。その際、このやり取りで把握した情報をOFSの管理テーブルに書き込みます（③’Flow-Mod）。以降、PC1からPC2宛てのパケットを受信しても、OFSはOFCに問い合わせることなく、転送できるという仕組みです。
従来は、ルータやスイッチなどのネットワーク機器自身で、上記のような制御をしていました。例えば、MACアドレスの学習やVLAN設定、OSPFなどのルーティング制御などの管理機能を持ち、かつ、MACアドレステーブルやルーティングテーブルなど自身が持つ情報を使って、受信したフレームやパケットを適切なポートから出力（データ転送）することをしていました。
OpenFlowでは、そのうちの管理機能をすべてOFCが担当し、OFSはデータ転送のみを担当するというように役割を分離させていることがポイントとなります。
OFSは、入力パケットに対して、管理テーブル内のパケット識別条件が一致するエントリを探し、そのエントリのActionを実行する。
下表がパケット識別子(MF)の例です。
| レイヤ | MF名 | 説明 |
|---|---|---|
| L1 | IN_PORT | 入力ポートID |
| L2 | ETH_DST | 宛先MACアドレス |
| ETH_SRC | 送信元MACアドレス | |
| ETH_TYPE | イーサネットタイプ | |
| VLAN_VID | VLAN ID | |
| L3 | IPv4_SRC | 送信元IPアドレス |
| IPv4_DST | 宛先IPアドレス |
続いて、識別されたパケットの処理(Action)の例です。
| Action名 | 説明 |
|---|---|
| Output( ) | ( )内に指定された次に示すパラメータに従い、パケットを出力する。 ・ポートID：指定ポートに出力する。 ・controller：Packet-Inメッセージを使い、OFCに転送する。 |
| Drop | パケットを破棄する。 |
| Set-Field | パケットのヘッダの一部を置き換える。 ・表記例：Set-Field ETH_DST=m1 (宛先MACアドレスをm1に書き換える場合) |
| Push-VLAN | パケットにVLANヘッダを付加する。 |
| Pop-VLAN | パケットのVLANヘッダを削除する。 |
管理テーブルでは、このMFとActionの組み合わせ（エントリ）を管理します。つまり、MFで「どのような条件のときに」を、Actionで「どう振る舞うか」を定義するというわけです。
エントリにはどんなことを指定できるんですか？
例えば、
- 入力ポートがP1
- 宛先MACアドレスがM1
- 送信元MACアドレスがM3
であった場合、「VLAN IDにV1を付与してポートP4から出力する」といったActionを設定することができます。
問題文は続きますが、一旦ここまでにして、OpenFlowでできることを簡単にまとめます。
OpenFlowでできること
OpenFlowは、ネットワークの構成変更だけでなく、負荷分散機能やパケットフィルタリング機能なども自由に設定できます。これまでは、それらの装置は別々の装置がその役割を担っていたので、「自由に設定する」ということは簡単にはできませんでした。例えば、営業部LANと技術部LANの間に通信を制限するFWを配置したいと言っても、そうそうにできるものではありません。それがOpenFlowならできるというわけです。
他にも、ポリシングやシェーピングといった帯域制御、リソース配分の動的な割り当て変更など、装置の追加や配置を物理的に変えずとも、左記のような高度な構成変更もOFCのエントリを追加・変更することで実現可能というわけです。
上記はあくまで一例に過ぎません。ソフトウェア制御となるOpenFlowでは、アプリケーションレイヤーまで網羅するので、実質何でもできると言えます。
まとめ
OpenFlowをうまく使えば、既存のネットワーク技術が抱える課題を解決することができます。
例えば、
- 素早く柔軟な構成変更
- 柔軟な機能追加
- ネットワーク管理の簡略化
- リソースの有効活用
OpenFlowを取り入れることで上記のようなメリットを享受できるというわけです。
しかし現状では、OpenFlowを取り入れている企業は少ないです。GoogleやFacebookなどが持つ巨大なネットワークや、データセンターやプロバイダなどのネットワークでは使われているそうですが、中小のネットワークで使われていることはほんとんどないと言えるでしょう。
ただそうは言ってもニーズはあるわけで、今後、OpenFlowがどうなっていくのか注目したいところです。
