OpenFlow1.2 で、トラフィックエンジニアリングを

試してみました

2013.4.20@ttsubo

1

自己紹介

2

・数年前は、通信事業者向けネットワークエンジニアでした。・最近は、データセンタ系ネットワークエンジニアに軸足のシフトを 試みてます。IaaS管理基盤技術として、OpenStack等を勉強中。・さらに「これからの時代、ネットワーク屋も、プログラミング　必要だよね。」という風潮に感化されて、OpenFlowプログラ　ミングも勉強中。

最近、書籍等でOpenFlowを題材とした記事をよく見かけますが、そのほとんどが、OpenFlow1.0ベースですよね。OpenFlow1.1以降では、マルチテーブルなどの新技術が利用可能となってますが、その活用方法などを入手できる場がありません。OpenFlow新技術が活用されていない状況は、もったいないと感じています。そこで、OpenFlow新技術の活用事例を、みなさんと共有したくて、OpenFlow1.2のユースケースを試してみました。

3

本日、みなさんにお伝えしたいこと。

4

みなさん、いまのネットワークで満足してますか？

たとえば、新たにネットワーク構築する場合...

３拠点（ホスト１、ホスト２、ホスト３）をイーサSWで接続するには、カスケード接続が一般に用いられていると思います。

この構成の課題を、少し考えてみますと...

イーサSW

イーサSW

イーサSW

イーサSW

ホスト１

ホスト２

ホスト３

5

イーサSW

イーサNWの課題　その１

拠点間の帯域の増速が行いにくい。リンクアグリゲーションみたいな手法は存在するが...

イーサSW

イーサSW

イーサSW

ホスト１

ホスト２

ホスト３

6

帯域逼迫の可能性

イーサSW

イーサSW

イーサSW

イーサSW

イーサNWの課題　その２

故障に伴う通信断

拠点間で故障が発生した場合、迅速に復旧できない。スパニングツリーみたいな手法は存在するが...

ホスト１

ホスト２

ホスト３

7

理想的なイーサNWとは...

イーサSW

イーサSW

イーサSW

拠点に配備されたイーサSW間で、複数の通信ルートが確保できる環境が望ましいです。

ホスト１

ホスト２

ホスト３

8

帯域逼迫への対応が容易拠点イーサSW間で、複数の通信ルートを確保できる環境では、トラフィック分散が可能となります。帯域増速を目的としたネットワーク拡張が図りやすくなります。

イーサSW

イーサSW

イーサSW

トラフィック分散

ホスト１

ホスト２

ホスト３

9

通信故障への対応が容易拠点イーサSW間で、複数の通信ルートを確保できる環境では、 通信故障時、迂回ルートへの切り替えが可能となります。よって、ネットワーク復旧が実施しやすくなります。

イーサSW

イーサSW

イーサSW

ホスト１

ホスト２

ホスト３トラフィック迂回

10

現行のイーサNW運用の肝は、ループの防止ですが、現在のネットワーク技術では、ループを防止しつつ、L２マルチパス制御が難しいという課題がありました。

イーサSW

イーサSW

イーサSW

ホスト１

ホスト２

ホスト３

11

12

そもそも、イーサループを防止しつつ、帯域有効活用/耐障害性への柔軟な対応をねらったL2マルチパス制御を実現する手段は、存在するのでしょうか？

答え「OpenFlowでTE」だと思います。

• トラフィックエンジニアリング(TE)は、WAN構築に限らず、エンタープライズ適用が可能な技術です。

• TEでは、トラフィック分散、プロテクション（高速復旧）を実現できる技術です。ただし、エンドエンドでの帯域制御は、まだまだ難しいですね。（TEなQoS制御は、結構、敷居が高いです。）

• TEを適用するためには、MPLSルータ機器を購入する必要がありません。汎用OpenFlow機器で実現可能です。（現時点では、制約条件が多いです...）

• 従来のTEでは、通信経路制御として、各種プロトコル知識（OSPF, BGP, LDP, RESV-TE ...）が必要でした。これからは、OpenFlowコントローラによるL２マルチパスな通信制御制御で代替可能となります。

13詳細は、割愛させて頂きます！！

OpenFlow-TEの話題に入る前に、ネットワーク仮想技術を再整理させてください。

14

最近のネットワーク仮想化について

エッジ装置

エッジ装置

R R R

R R R

ネットワーク抽象化（オーバレイNW）

アンダーレイNW（従来のIP機器）

企業A 企業A

企業B 企業B

IaaS側のテナントネットワークと拠点間ネットワークをオーバレイ方式で接続する利用形態が、増えてきています。テナントNW テナント

NW

15

オーバレイNWの技術要素

エッジ装置

エッジ装置

R R R

R R R

ネットワーク抽象化（オーバレイNW）

アンダーレイNW

企業A企業A

企業B 企業B

テナントNW

テナントNW

L3技術

テナント／トンネル連結（NVGRE, VxLAN...）

現行のオーバレイNW技術では、OpenFlowを適用せずとも、環境構築が可能です。既存のテナント管理との相互接続として、OpenFlow適用が検討される程度です。

テナント管理（VLAN, OpenFlow...）

16

オーバレイNWの特徴

・エッジ装置間で仮想ネットワークを構築してしまえば、OpenStack等のクラウド　管理基盤との親和性が高くなり、ITリソースのスケールアウトに追従しやすい。

・アンダーレイNWとオーバレイNWの運用管理が独立してしまうので、柔軟かつ　包括的なネットワーク運営が行いにくい　１）アンダーレイNWの帯域逼迫の課題が顕在化した場合の対処は？　２）アンダーレイNWでNW機器等の故障時、L３ルーティング再計算構築に依存

・エッジ装置間で仮想ネットワークを構築するためには、ベンダ技術の適用に依存　してしまう（例；VxLAN、NVGRE、STT）　１）フルオープンソースでの環境構築が難しい　２）ベンダへの構築作業委託を前提とするならば、手間が省ける

オーバレイ方式の利点は、単一ベンダによる垂直統合モデルとの親和性が高いところだと思います。コスト低減を想定したマルチベンダ化を見据えた場合、逆にボトルネックになると思います。

階層ネットワークをOpenFlowで制御するホップByホップ方式は、どうだろうか？ 17

ホップByホップで実現する場合…

エッジ装置

エッジ装置

アンダーレイNW（OpenFlowスイッチ）

企業A 企業A

企業B企業B

テナントNW

テナントNW

OpenFlow1.xのフローエントリ管理手法を活用すれば、オーバレイ方式と同様の階層ネットワークを構築可能となります。

OFS OFS OFS

OFS OFS OFS拠点間パス

18

OFC

ホップByホップNWの技術要素

エッジ装置

エッジ装置

アンダーレイNW（OpenFlowスイッチ）

企業A 企業A

企業B 企業B

テナントNW テナント

NW

OFS OFS OFS

OFS OFS OFS拠点間パス

19

エッジ装置間の拠点間パス経路と、テナントNWとの連結をOpenFlowのマルチTableにて一括管理する感じです。

OFC

テナント／パス連結（OpenFlow）

テナント管理（OpenFlow）

OpenFlowでのフロー制御の留意点

（１）効率的なフロー設定–リアクティブなFlowEntry

• OpenFlowスイッチ側での転送処理が完結せず、Packet-In動作によるコントローラへの問い合わせ処理がオーバヘッドとなり、NW全体のパフォーマンスが劣化する（＝スケールしない）

–プロアクティブなFlowEntry• OpenFlowスイッチ側での転送処理が完結するため、

NW全体のパフォーマンス向上が期待できる• FlowEntry量の肥大化を防止する工夫が必要となる 20

拠点間パスを構築するには、プロアクティブでのフローエントリ構築が必須となります。リアクティブな動作を如何に抑止するかが、鍵となります。

OpenFlowでのフロー制御の留意点（２）リアルタイムなフロー監視

–従来のNW機器モデル• ルーティングTBL／フォワーディングTBLが同一筐体で保持されるため、データ整合性が保証しやすい。

コントロールプレーン

データプレーン

ルーティングTBL

フォワーディングTBL

監視 設計コントロールプレーン

データプレーン

ルーティングTBL

フォワーディングTBL

監視 設計ルーティングプロトコル

データ整合が保証しやすい

21

OpenFlowでのフロー制御の留意点（２）リアルタイムなフロー監視

– OpenFlow機器モデル• ルーティングTBL／フォワーディングTBLが異なる筐体で保持されるため、データ整合性の保証が難しい。

コントロールプレーン

データプレーン

ルーティングTBL

フォワーディングTBL

監視 設計

OpenFlow-Agent

データプレーン

フォワーディングTBL

OpenFlow-Agent

OpenFlowController

ルーティングTBL

OpenFlowプロトコル

データ整合の保証が難しい

OpenFlowスイッチ OpenFlowスイッチ

OpenFlowコントローラ

22

OpenFlow監視の理想形態

コントロールプレーン

データプレーン

ルーティングTBL

フォワーディングTBL

設計 監視

OpenFlow-Agentデータプレーンフォワーディング

TBL

OpenFlow-Agent

OpenFlowController

ルーティングTBL

OpenFlowプロトコルOpenFlow

スイッチOpenFlowスイッチ

OpenFlowコントローラ

OpenFlowスイッチ毎のFlowEntryの正常性を確認した上で、エンドエンド経路診断を実施したい。

OpenFlowコントローラで保持しているフロー情報と、OpenFlowスイッチで保持しているフロー情報が同期されていることを把握したい。

NWオペレータ

23

というわけで、OpenFlow環境を構築して、トラフィックエンジニアリングを試してみました。

24

ようやく、本題に入ります

OpenFlow-TE検証環境というわけで、プロアクティブなFlowEntryで、ホップByホップな階層ネットワークをOpenFlowで構築してみました。

目標感OpenFlow-TEで、イーサループを防止しつつ、帯域有効活用をねらったL2マルチパスと通信故障に伴う迂回ルートへの復旧制御を実現する手段を試してみたい。

アンダーレイNW（OpenFlowスイッチ）

OFS OFS OFS

OFS OFS OFS

OFC OpenFlowチャネル

イ

イ

イ

トラフィック分散

イ

イ

イ

トラフィック迂回

25

OFS

特徴１「拠点間フロー集約なパス構築」

エッジOFS

エッジ

テナントNW

テナントNW

拠点間パスを一意に識別できるよう、VlanタグやMPLSラベルが用いられるのが今回のOVS環境では、いずれも、フローエントリ設定が成功せず、、、（原因不明）よって、IPヘッダのTOS値を代用して、L2マルチパス環境を構築しました。

TOSによる高品質パス

TOSによる低品質パス

拠点間パス用FlowEntryを事前に登録しておく

26

事前に拠点間パスを構成するフローエントリを設定することによるホップByホップ環境を構築。

OFS

特徴２「柔軟なテナントNWの収容」

OFS

OFS

OFS

テナントNW

テナントNW

テナントNWに配備されたエンド端末が送出する通信パケット種別に応じて、パス収容先を選択可能。たとえば、TCPは、高品質パスに、UDPは低品質パスに収容とか。。。

TOSによる高品質パス

TOSによる低品質パス

テナントNW／通信パケット種別毎にテナント用FlowEntryを登録する

27

特徴３「通信故障時の自動迂回制御」

OFS

OFS

OFS

OFS

テナントNW

テナントNW

TOSによる低品質パス

故障復旧として、テナント用FlowEntryを自動修正（高品質→低品質）する

TOSによる高品質パス

拠点間パス毎に、複数の通信ルートを確保しておき、通常の通信ルートで通信故障が発生した場合には、迅速に、別ルートへ切り替えるような故障復旧の自動化が可能。

28

実際、OpenFlowでTE適用したL2マルチパス通信制御の簡単なデモンストレーションをご覧いただきます。

29

OpenFlowデモ実演（通常時）

OVS-1 OVS-2 OVS-3

OVS-4 OVS-5 OVS-6

高品質パス（ICMP用）

低品質パス（TCP用）

拠点間パスを事前に構築した上で、ICMPトラフィックを高品質パスに収容し、TCPトラフィックを低品質パスに収容したトラフィック分散を実現できます。

HOST-1 HOST-2

30

OpenFlowデモ実演（通信故障時）

OVS-1 OVS-2 OVS-3

OVS-4 OVS-5 OVS-6

低品質パス（TCP用）

高品質迂回パス（ICMP用）

ICMPトラフィックを収容した高品質パスの通信ルート区間において、通信故障が発生した場合、迂回パスに自動切り替えを行い通信復旧できます。

PortStatusメッセージが送出されないような通信故障を想定！

HOST-1 HOST-2

31