OpenFlow1.2 で、
トラフィックエンジニアリングを
     試してみました



      2013.4.20
       @ttsubo
                    1
自己紹介




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

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



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




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

3拠点(ホスト1、ホスト2、ホスト3)をイーサSWで接続す
るには、カスケード接続が一般に用いられていると思います。

                               ホスト2
                        イーサ
                        SW


    ホスト1
           イーサ   イーサ
                              ホスト3
           SW    SW

                       イーサ
                       SW




この構成の課題を、少し考えてみますと...
                                      5
イーサNWの課題 その1

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


 ホスト1
        イーサ     イーサ
                             ホスト3
        SW      SW

                      イーサ
                      SW

         帯域   迫の可能性
                                     6
イーサNWの課題 その2

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


 ホスト1
        イーサ      イーサ
                              ホスト3
        SW       SW

                       イーサ
                       SW
              故障に伴う
               通信断
                                      7
理想的なイーサNWとは...

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


 ホスト1
        イーサ
                     ホスト3
        SW

              イーサ
              SW



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


  ホスト1
                トラフィック
         イーサ    分散
         SW                     ホスト3
                         イーサ
                         SW

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


   ホスト1
                トラフィック
          イーサ
                 回              ホスト3
          SW

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


   ホスト1
          イーサ
                       ホスト3
          SW

                イーサ
                SW


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




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




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

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

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

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


                 詳細は、割愛させて頂きます!!                    13
OpenFlow-TEの話題に入る前に、
ネットワーク仮想技術を再整理
させてください。




                       14
最近のネットワーク仮想化について
IaaS側のテナントネットワークと拠点間ネットワークを
オーバレイ方式で接続する利用形態が、増えてきています。
  テナント
                                             テナント
  NW
                                             NW
                    ネットワーク抽象化                       企業A
企業A
                    (オーバレイNW)

                                                企業B
企業B   エッジ                              エッジ
      装置                               装置




                R          R       R



            R          R       R


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

テナント管理
   テナント                                   テナント
                                          NW
(VLAN, OpenFlow...)ネットワーク抽象化
   NW                                        企業A
 企業A                   (オーバレイNW)


             テナント/トンネル連結エッジ                 企業B
 企業B   エッジ
       装置    (NVGRE, VxLAN...) 装置

                              L3技術
                   R          R       R



               R          R       R


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

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

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

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

階層ネットワークをOpenFlowで制御するホップByホップ方式は、どうだろうか?   17
ホップByホップで実現する場合…
OpenFlow1.xのフローエントリ管理手法を活用すれば、オーバ
レイ方式と同様の階層ネットワークを構築可能となります。
  テナント                                   テナント
  NW                                     NW
企業A                 OFC                      企業A


      エッジ                          エッジ
                                             企業B
企業B
      装置                           装置




                   拠点間パス
             OFS     OFS    OFS




            OFS     OFS    OFS    アンダーレイNW
                                  (OpenFlowスイッチ)
                                                   18
ホップByホップNWの技術要素
エッジ装置間の拠点間パス経路と、テナントNWとの連結を
OpenFlowのマルチTableにて一括管理する感じです。
 テナント                                     テナント
 NW                                       NW
                     OFC                     企業A
企業A テナント管理
      (OpenFlow)

企業B
      エッジ                           エッジ       企業B
       装置                           装置

                  テナント/パス連結
                  (OpenFlow)
                    拠点間パス
             OFS      OFS    OFS




            OFS      OFS    OFS    アンダーレイNW
                                   (OpenFlowスイッチ)
                                                    19
OpenFlowでのフロー制御の留意点
 拠点間パスを構築するには、プロアクティブでのフローエン
 トリ構築が必須となります。リアクティブな動作を如何に抑
 止するかが、 となります。

(1)効率的なフロー設定
  – リアクティブなFlowEntry
     • OpenFlowスイッチ側での転送処理が完結せず、
       Packet-In動作によるコントローラへの問い合わせ処
       理がオーバヘッドとなり、NW全体のパフォーマンス
       が劣化する(=スケールしない)
  – プロアクティブなFlowEntry
     • OpenFlowスイッチ側での転送処理が完結するため、
       NW全体のパフォーマンス向上が期待できる
     • FlowEntry量の肥大化を防止する工夫が必要となる    20
OpenFlowでのフロー制御の留意点
(2)リアルタイムなフロー監視
 – 従来のNW機器モデル
   • ルーティングTBL/フォワーディングTBLが同一筐体
     で保持されるため、データ整合性が保証しやすい。



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

    ルーティングTBL             ルーティングTBL




   データプレーン               データプレーン


                データ整合が
    フォワーディング              フォワーディング
       TBL                   TBL


                保証しやすい
                                      21
OpenFlowでのフロー制御の留意点
(2)リアルタイムなフロー監視
 – OpenFlow機器モデル
   • ルーティングTBL/フォワーディングTBLが異なる筐
     体で保持されるため、データ整合性の保証が難しい。
                       監視     設計
  データ整合の              コントロールプレーン
                                      OpenFlow
                      ルーティング ルーティング   コントローラ
  保証が難しい                TBL    TBL


                       OpenFlow
                       Controller
  OpenFlowスイッチ                           OpenFlowスイッチ
                       OpenFlow
                       プロトコル
     OpenFlow-Agent                     OpenFlow-Agent
     データプレーン                            データプレーン

      フォワーディング                           フォワーディング
         TBL                                TBL
                                                         22
OpenFlow監視の理想形態
OpenFlowコントローラで                     NWオペレータ
保持しているフロー情報と、
                                     設計 監視
OpenFlowスイッチで保持                 コントロールプレーン
しているフロー情報が同期                    ルーティング ルーティング    OpenFlow
されていることを把握したい。                    TBL    TBL
                                                 コントローラ
                                 OpenFlow
                                 Controller

                                  OpenFlow
    OpenFlow                      プロトコル                          OpenFlow
    スイッチ       OpenFlow-Agent                   OpenFlow-Agent   スイッチ
               データプレーン                          データプレーン
                フォワーディング                         フォワーディング
                   TBL                              TBL




   OpenFlowスイッチ毎のFlowEntryの正常性を確認した上で、
   エンドエンド経路診断を実施したい。                                                   23
ようやく、本題に入ります




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




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

                 OFS        OFS    OFS



                OFS        OFS    OFS       アンダーレイNW
                                            (OpenFlowスイッチ)

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

     トラフィック分散          イ            トラフィック     回   イ



      イ                                 イ

                       イ                           イ

                                                             25
特徴1「拠点間フロー集約なパス構築」
事前に拠点間パスを構成するフローエントリを設定することに
よるホップByホップ環境を構築。
           拠点間パス用FlowEntryを         テナント
 テナント
 NW        事前に登録しておく                NW




               TOSによる高品質パス
                     OFS


         エッジ                  エッジ

               TOSによる低品質パス
                     OFS




拠点間パスを一意に識別できるよう、VlanタグやMPLSラベルが用いられるのが
今回のOVS環境では、いずれも、フローエントリ設定が成功せず、、、(原因不明)
よって、IPヘッダのTOS値を代用して、L2マルチパス環境を構築しました。   26
特徴2「柔軟なテナントNWの収容」
テナントNWに配備されたエンド端末が送出する通信パケット
種別に応じて、パス収容先を選択可能。
たとえば、TCPは、高品質パスに、UDPは低品質パスに収容とか。。。

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




                TOSによる高品質パス
                     OFS



          OFS
                              OFS



                TOSによる低品質パス
                    OFS

                                           27
特徴3「通信故障時の自動                    回制御」
拠点間パス毎に、複数の通信ルートを確保しておき、通常の通
信ルートで通信故障が発生した場合には、迅速に、別ルートへ
切り替えるような故障復旧の自動化が可能。
       故障復旧として、テナント用FlowEntry     テナント
テナント
NW     を自動修正(高品質→低品質)する           NW




             TOSによる高品質パス
                  OFS



       OFS
                           OFS


             TOSによる低品質パス
                 OFS


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




                          29
OpenFlowデモ実演(通常時)
拠点間パスを事前に構築した上で、ICMPトラフィックを高品質
パスに収容し、TCPトラフィックを低品質パスに収容したトラ
フィック分散を実現できます。



HOST-1                                    HOST-2
           OVS-1      OVS-2       OVS-3
                   高品質パス(ICMP用)




           OVS-4      OVS-5       OVS-6

                   低品質パス(TCP用)                     30
OpenFlowデモ実演(通信故障時)
ICMPトラフィックを収容した高品質パスの通信ルート区間に
おいて、通信故障が発生した場合、 回パスに自動切り替えを
行い通信復旧できます。
                       PortStatusメッセージ
                       が送出されないような
                        通信故障を想定!

HOST-1                                   HOST-2
         OVS-1      OVS-2       OVS-3

                      高品質
                        回パス
                      (ICMP用)



         OVS-4      OVS-5       OVS-6

                 低品質パス(TCP用)                      31

TremaDay #2