JP6402078B2 - ネットワークシステムおよびパケット転送方法 - Google Patents
ネットワークシステムおよびパケット転送方法 Download PDFInfo
- Publication number
- JP6402078B2 JP6402078B2 JP2015150249A JP2015150249A JP6402078B2 JP 6402078 B2 JP6402078 B2 JP 6402078B2 JP 2015150249 A JP2015150249 A JP 2015150249A JP 2015150249 A JP2015150249 A JP 2015150249A JP 6402078 B2 JP6402078 B2 JP 6402078B2
- Authority
- JP
- Japan
- Prior art keywords
- vtep
- network
- termination point
- tunnel
- router
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Description
一方、大規模な広域NWは、スケール性や耐障害性の観点からIPルーチングを用いたL3NW(レイヤ3ネットワーク)で構築されることが多い。そこで、NFVにおいて、L3NW上に仮想的なL2トンネルを構築することでL2転送を実現するNVO3(Network Virtualization Over L3)が検討されている(非特許文献2参照)。
NVO3としては、VXLAN(Virtual eXtensible Local Area Network)(非特許文献3参照)やNVGRE(Network Virtualization Generic Routing Encapsulation)をはじめとした様々な技術が検討されている(非特許文献4参照)。
NVO3では、トンネル端点にあたるルータ(VTEP)で宛先解決が必要である。VXLANでは、宛先解決方法として、(1)宛先不明トラヒックは一度全ての端点ルータにフラッディングし、D-Planeで学習する方法と、(2)あらかじめC-Planeで学習する方法とがある(E−VPN)(非特許文献5参照)。
図8(a)に示すように、NVO3に係るネットワークシステムは、ユーザ端末11,12が、ルータ21,22,23(ここではルータ22)を介して中継NWであるL3 広域NW3に接続されている。L3 広域NW3には、ルータ41,42,43を介してサービスを提供するサーバ51〜56が接続されている。ユーザ端末11,12は、ルータ22、L3 広域NW3、およびルータ4を経由してサーバ51〜56からアプリケーションなどの各種サービスA〜Fの提供を受ける。なお、ルータ21,22,23を総称する場合は、ルータ2と呼び、ルータ41,42,43を総称する場合は、ルータ4と呼び、サーバ51〜56を総称する場合は、サーバ5と呼ぶ。ユーザ端末11,12を特に区別しない場合にはユーザ端末1と表記する。
なお、本明細書中において、サービスとは、各種転送機能を有するアプリケーション(アプリ)、または、アプリにより提供されるサービスをいう。
ルータ2は、例えばマルチキャスト配信中に最終マルチキャストポイントとなるエンドルータである。
L3 広域NW3は、L3NWである。
サーバ5は、各種サービスA〜Fを提供する配信サーバである。
例えば、ある仮想マシンが、VXLAN経由で別のサーバ上の仮想マシンと同じセグメントに属していて、これに対するL2の通信を開始すると、VTEPは送信先のMACアドレスがローカルにないと判断したうえで、送信元のVTEPはそのMACフレームの前に適切な仮想L2トンネル識別子(以下、トンネル識別子という)VNI(送信元仮想マシンの属するVXLANセグメントのID)を付加する。VTEPは、さらに自分のIPアドレスとMACアドレスを付け、送信先VTEPのIPアドレスに通信を開始する。送信先のVTEPは、トンネル識別子VNIを見て確認した後、送信元のVTEPが付けた情報をすべて削除し、送信先の仮想マシンに対してこのMACフレームを送る。
(1)あらかじめ設定したVTEPすべてに転送する方法。
例えば、ユーザ端末11は、サービスFを提供するサーバ56に接続しようとする。この場合、VTEPはその返信パケットを見てMACアドレスを学習し、図8(b)に示すようなテーブルを学習する。図8(b)は、VTEPが管理する各仮想マシンのMACアドレスと、その仮想マシンのトンネル識別子VNIの対応関係を示すテーブルである。
図8(b)の例では、ユーザ端末1が接続されるルータ22は、該当サービスFを提供するサーバ56のMACアドレス(L2(MAC))とルータ43のIPアドレス(L3(RemoteVTEP))のテーブルを学習する。
(2)VTEPに直接接続されたMACアドレスをあらかじめE-VPNなどのコントロールプレーンで広告する方法。
広告されたVTEPは、図8(b)に示すようなテーブルを学習する。
はじめに、ユーザ端末11がサービスFを利用する際、ユーザ端末11はサービスFのMACアドレス宛パケットを送出する。そして、発側VTEPであるルータ2は、図8(b)に示すようなテーブルを保持するため、VXLAN・GRE(Generic Routing Encapsulation)ヘッダなど各NVO3で規定されたヘッダによりカプセリングし、ルータ43宛に転送する。着側VTEPであるルータ43では、そのヘッダをデカプセリングしてサービスFのMACアドレス宛にパケットを転送する。この一連の動作により、ユーザ・サービスから見るとL2転送が行われたように見せることができる。
図9に示すように、図8のカプセリング後のフレームフォーマット10は、Outer Dst. MAC、Outer Src. MAC、Outer Dst. IP(router 2)、Outer Src. IP(ルータ21)、Outer Src. UDP、Outer Dst. UDP(VXLANport)およびVXLAN ID(id=1)からなるVXLANフレーム11と、Inner Dst. MAC(サービスA)、Inner Src. MAC(ユーザ(11))およびPayloadからなるオリジナルフレーム12と、から構成される。
VTEP以外のL3網(広域NW)では、図9に示すヘッダ(VXLANフレーム11部分)のみを見て転送する。このため、単純なL3転送(IP転送)を行うのみでよい。
図10に示すように、サービス機能が搭載されたサーバ5は、DC(Data Center)20に収容される。DC20は、DC20内に構築されたL3 DC NW21を介して広域NW3と接続される。図10の例では、DC20内のルータ41,42を着側VTEP(対向VTEPともいう)とし、ルータ41(着側VTEP)が、アプリケーションA機能(サービスA)を有するサーバ51に接続される。サーバ51は、現用系であり稼働中であるものとする。また、ルータ42(着側VTEP)およびサーバ52は、予備系である。
ルータ2(発側VTEP)は、ルータ4(着側VTEP)宛のカプセリングを行う。具体的には、ルータ2(発側VTEP)は、MACフレームの前に適切なトンネル識別子VNI(送信元仮想マシンの属するVXLANセグメントのID)と自分および対向ルータのIPアドレスとMACアドレスを付け、ルータ41(着側VTEP)のIPアドレスに通信を開始する。ルータ41(着側VTEP)は、トンネル識別子VNIを見て確認した後、ルータ2(発側VTEP)が付けた情報をすべて削除し、送信先のサーバ51に対してこのMACフレームを送る(図10の破線矢印参照)。
DC20内で障害が発生した場合、現用系のサーバ51を予備系のサーバ52にマイグレーションする必要がある。特に、仮想L2トンネル利用時にDC20内で障害が発生した場合、発側VTEP(図10ではルータ2)で予備系への経路切り替えのために多くの時間を要する。すなわち、この切り替えのためには、ルータ42(着側VTEP)は、発側VTEP(図10ではルータ2)に対してMACテーブルを更新するような指示を出さなくてはならない。
例えば、上記(1)のMAC取得方法の場合、サービスAのサーバ51側からDC20外の全VTEPに向かってパケットを送出し、全VTEPは受け取ったパケットによって学習する。
また、上記(2)のMAC取得方法の場合、DC20外の全VTEPに対しコントロールプレーンでMACアドレスを広告し、全VTEPは受け取った結果によって学習する。
いずれの場合もDC20側障害を受けて広域NW3(L3)側の全VTEPに通知しなくてはならない。図10の符号aに示すように、この切り替えのためには、ルータ42(着側VTEP)は、全ての発側VTEP(図10ではルータ4)に対してARP(E-VPN)で即座に通知が必要である。図10の符号bに示すように、広域NW3(L3)側のVTEP数が多い場合は、NWへの負荷が大きいため、切り替えに時間を要する。
このように、従来技術では、サーバ5を収容するDC20と広域NWが同一L2NWになってしまうため、耐障害性や運用性の観点で問題があった。
また、正常時は、トラヒックがOpenFlowスイッチに流入しないので、OpenFlowスイッチは中継動作に関与せず、通常のVXLAN環境そのものとすることができる。
本実施形態は、大規模な物理ネットワーク上に仮想パスを生成する際、その中継区間における転送方法およびそれを実現するネットワークシステムに適用することができる。NFV環境において必要となるNVO3、すなわちL3NW上に仮想L2NWを構築する技術について説明する。
図1に示すように、ネットワークシステム1000は、ユーザ端末11,12,13(L2サービス提供端末)が、ルータ21,22,23(発側VTEP201,202,203)を介してL3 広域NW3(L3ネットワーク)に接続され、DC100(DC#1)のルータ1101,1102,DC200(DC#2)のルータ2101,2102を介してL3 DC NW120,220に接続される。
DC100は、L3 広域NW3に接続されたルータ1101,1102と、L3 DC NW120と、L3 DC NW120に接続されたルータ1301,1302(着側VTEP1311,1312)と、サービスA機能を有するサーバ1401,1402と、を有する。
DC100内では、L3 DC NW120に接続されたルータ1301,1302(着側VTEP1311,1312)を介してサービスA機能を有するサーバ1401,1402に接続される。図1のサーバ1401,1402は、共にサービスAのための転送機能を有するものとし、サーバ1401を現用系、サーバ1402を予備系とする例である。
DC200内では、L3 DC NW220に接続されたルータ2301,2302(着側VTEP2311,2312)を介してサービスB機能を有するサーバ2401,2402に接続される。図1のサーバ2401,2402は、共にサービスBのための転送機能を有するものとし、サーバ2401を現用系、サーバ2402を予備系とする例である。
OpenFlowスイッチ300は、L3 広域NW3(L3ネットワーク)に接続される。OpenFlowスイッチ300は、故障切替え中(後記)、一時的に、あらかじめ設定しておいたルール(規則)に従い、宛先IPを現用系着側VTEPから予備系着側VTEPに書き換える。OpenFlowスイッチ300は、VTEP故障時に最初の数パケットのみ処理する。なお、正常時およびVTEP故障時(障害時)の定義については、後記する。
OpenFlowスイッチ300は、OpenFlow対応ルータ310を備え、OpenFlow対応ルータ310は、OpenFlowコントローラ(OpenFlowCTL)320(処理部)、ルーチングエンジン321および予備VTEP対応表322(記憶部)を有する。
特に、OpenFlowコントローラ320は、着側VTEPの故障時、あらかじめ設定した規則に従って、予備VTEP対応表322を参照して故障した着側VTEPを対応する予備系着側VTEPに書き換えて転送する。
マッチ条件:宛先UDP(User Datagram Protocol)ポート:VXLANポート番号
宛先IPアドレス:故障VTEP(図1のVTEP1311)のIPアド
レス
カプセリングID:L2トンネルの識別子
アクション条件:宛先IPアドレス:予備系VTEP(図1のVTEP1312)のI
Pアドレス
出力ポート:予備系VTEP(図1のVTEP1312)へ転送できるポ
ート
ネットワークシステム1000は、L3 広域NW3上に仮想L2トンネルを構築して、L3 広域NW3上に接続されるユーザ端末1と、L3 広域NW3に接続されたDC100内のL3 DC NW120に接続されるサーバ140およびDC200内のL3 DC NW220に接続されるサーバ240との間でパケットを送受信するものである。
DC100,200は、それぞれルータ110,210を介してL3 広域NW3と接続される。DC100,200は、L3 DC NW120,220、ルータ130,230(着側VTEP)やサーバ140,240を大規模で効率的に収容する。DC100,200は、サーバやネットワーク機器などのIT(Information Technology)機器を設置、運用する施設・建物の総称であり、複数のルータ130,230(着側VTEP)を運用するものであればどのような名称でも構わない。
DC100,200内は、L3 DC NW120,220によりネットワークが構築され、ルータ130,230(着側VTEP)を介してサーバ140,240が接続される。
なお、DC100,200は、通常のゲートウェイ機能と、ファイアウォール機能とを備える。
ルータ130,230(着側VTEP)は、DC100,200内のサーバ140,240とL3 DC NW120,220の接続点に実装される。
サーバ140は、サービスAを提供するサーバ、サーバ240は、サービスBを提供するサーバである。
正常時の動作(図2参照)、故障切替え中(故障直後)の動作(図4参照)、故障切替え完了時の動作(図6参照)の3つに分けて述べる。
正常時とは、ユーザ側VTEPへ定期的に経路広告がある場合をいう。
故障とは、ユーザ側VTEPへの経路広告がとまる(経路広告がこない)ことをいう。
故障切替え中とは、ユーザ側VTEPが優先度の低い(高コスト)経路広告のOpenFlowスイッチ300に一時的にルーチングし、OpenFlowスイッチ300があらかじめ設定しておいたルール(規則)に従い、宛先IPを宛先VTEPから予備系着側VTEPに書き換えるまでをいう。
故障切替え完了時とは、宛先IPが書き換えられた予備系着側VTEPが、ユーザ側VTEPにトラヒックを一回返して、トラヒック疎通した時点をいう。故障切替え完了時は、故障から一定期間が経った後の動作となる。
図2は、ネットワークシステム1000の正常時(通常時)のトラヒックフローを説明する図である。
図2の白抜きに斜線の矢印(⇒(矢印))は、正常時の経路広告を示し、図2の矢印(→(矢印))は、正常時のトラヒックフローを示し、図2の丸印(○(丸印))で囲んだ数値(xx(数値))は、ルーチングコストである優先度イメージをそれぞれ示している。なお、後記図4および図6についても、上記記号は同じ表記で用いる。
各ルータ21,1101,1102,1301,1302は、正常時(通常時)、VTEP保持のためのMACテーブル(図1の符号a,b,d参照)を有する。具体的には、ルータ21の発側VTEP201は、図1の符号aに示すMACテーブル(MAC:サービスA RemoteVTEP:VTEP1311)を保持する。DC100のルータ1301の着側VTEP1311は、図1の符号bに示すMACテーブル(MAC:サービスA RemoteVTEP:VTEP201)を保持する。DC100のルータ1302の着側VTEP1311は、図1の符号dに示すMACテーブル(MAC:−(無し) RemoteVTEP:−(無し))を保持する。
図3は、ネットワークシステム1000の正常時のVXLAN環境のフレームフォーマットを示す図である。図3は、ルータ21(発側VTEP)がDC100宛のカプセリング動作によってVXLANカプセリングを行った場合のフレームフォーマットを示す。キャリア網(L3 広域NW3)−DC網(L3 DC NW130)間のL2延伸は、トンネルの宛先をDC100のルータ1301とする。図3は、正常時のVTEP201からVTEP1312間のフレームフォーマットを示す。
図3に示すように、図1のカプセリング後のフレームフォーマット400は、Outer MAC、Outer IP(Dst:VTEP1311)、UDP(Dst:4789)、およびVXLAN ID(VNI:10000)からなるVXLANフレーム410と、Inner MAC(Dst:サービスA)およびPayloadからなるオリジナルフレーム420と、から構成される。図3の符号aに示すように、トンネルの宛先を「Outer IP(Dst:VTEP1311)」とする。これにより、ルータ21(発側VTEP201)は、ルータ21(着側VTEP1311)宛のカプセリングを行う。
ルータ1301(着側VTEP1311)は、処理部(図示省略)がトンネル識別子VNIを見て確認した後、ルータ21(発側VTEP201)が付けたVXLANフレーム410(図3参照)をすべて削除する。
(1)着側VTEPから対向VTEP宛ての経路広告
図2の白抜きに斜線の矢印(⇒(矢印))に示すように、ルータ1301,1302(着側VTEP1311,1312)は、自身のVTEP1311,1312に直接接続されたMACアドレスをあらかじめE-VPNなどのコントロールプレーンを用いて経路広告する(図2の符号e−h参照)。図2の例では、ルータ1301,1302(着側VTEP1311,1312)は、ルータ1101,1102を経由してルータ21(発側VTEP201)に経路広告する。ネットワークシステム1000は、元々、コアNW(L3 広域NW3)とDC100とが冗長構成を採っているので、ルータ1301(着側VTEP1311)は、ルータ1101のみならず、ルータ1102を経由する経路についても経路広告を行う(図2の符号g,h参照)。同様に、ルータ1302(着側VTEP1312)は、ルータ1101を経由する経路についても経路広告を行う(図2の符号e,f参照)。
ここで、対向VTEP宛ての経路広告には、優先度が設けられており、対向VTEP(この場合、着側VTEP1311)は、優先度を基に、優先度の最も高い経路広告を学習する(後記)。なお、この優先度は、ルーチングコストと呼称される場合がある。
OpenFlowスイッチ300は、優先度を高くして対向VTEP宛ての経路広告を行う(図2の符号i参照)。具体的には、OpenFlow対応ルータ310は、E-VPNなどのコントロールプレーンを用いて経路広告する。
ルータ1301,1302(着側VTEP1311,1312)は、対向VTEP宛ての経路広告の際、図2の丸印(○(丸印))で囲んだ数値(xx(数値))に示すような優先度を付与する。一方、OpenFlowスイッチ300は、あらかじめ、対向VTEP宛てに優先度を高くした経路広告を行う。
優先度は、対向VTEP宛ての経路広告に付与されるルーチングコストであり、どこに仮想L2トンネルをはればよいのかを決めるときに用いる。対向VTEPは、当該優先度を基に、最適なVTEP経路を決定することができる。優先度は、例えば、各経路広告に付された、数値10,20,30,…,100である。一例として、数値100を最も高コストと取り決めておけば、対向VTEPは、数値100のVTEP経路が、ルーチングの際に最もコストがかかる経路であると判別できるので、最後に選択されることになる。対向VTEPは、コストが小さい、すなわち優先度の数値が小さいVTEP経路から順に伝送に用いる。
なお、優先度は、ルーチングコストを決定できるものであればよく、優先度が高い場合の数値を大きく、優先度が低い場合の数値を小さくするものでもよい。この場合、優先度の数値が大きいとルーチングコストが小さくなる。
図2の正常時のトラヒックフローを参照して正常時(通常時)の転送の流れを説明する。
図2に示すように、ネットワークシステム1000は、正常時には、ルータ21(発側VTEP201)とルータ1301(着側VTEP1311)間でL2トンネル(トンネル識別子(VNI)=10000)を形成する。ルータ21(発側VTEP201)は、トンネル識別子VNIを参照してVTEP(ここでは着側VTEP1311)に転送することになる。アンダーレイ(VXLANのL2トンネルに対比されるインフラ)では、VTEP1311のIPアドレス宛の転送を行う必要がある。この経路制御は、従来技術の通常時と同様であり、静的・動的なルーチングによりルータ1301へ転送を行うものである。
図3(a)の符号aに示すように、トンネルの宛先を「Outer IP(Dst:VTEP1311)」とする。また、図2に示すように、発側VTEPと着側VTEP(以下、発着VTEPという)にトンネル識別子VNIを付与する。具体的には、図2に示すように、ルータ21(発側VTEP201)とルータ1301(着側VTEP1311)にトンネル識別子(VNI)=10000を付与する。これにより、ルータ21(発側VTEP201)は、ルータ1301(着側VTEP1311)宛のカプセリングを行う。
図2の符号jに示すように、正常時、ルーチングで優先度(コスト差)をつけることでVTEP故障時以外はOpenFlowスイッチ300へトラヒックを流入させないようにする。正常時は、トラヒックがOpenFlowスイッチ300を通らず、通常のVXLAN環境そのものとなる。
図4は、ネットワークシステム1000の故障切替え中のトラヒックフローを説明する図である。
図4の符号aに示すように、ルータ21の発側VTEP201は、VTEP保持のため、MAC学習されたMACテーブル(MAC:サービスA RemoteVTEP:VTEP1311)を保持している。このため、前記図3の符号aに示すように、トンネルの宛先を「Outer IP(Dst:VTEP1311)」とし、ルータ21(発側VTEP201)は、ルータ1301(着側VTEP1311)宛のカプセリングを行う(正常時)。また、図4に示すように、ルータ21(発側VTEP201)とルータ1301(着側VTEP1311)にトンネル識別子(VNI)=10000を付与する(正常時)。
図5は、ネットワークシステム1000の故障切替え中のVXLAN環境のフレームフォーマットを示す図である。図5(a)は、対向VTEP故障時の故障切替え中のVTEP201からOpenFlowスイッチ300のOpenFlow対応ルータ310間のフレームフォーマットを示し、図5(b)は、OpenFlow対応ルータ310からVTEP1312間のフレームフォーマットを示す。
図5(a)のフレームフォーマットと、前記図3のフレームフォーマットとは、同じである。ルータ21(発側VTEP201)は、ルータ1301(着側VTEP1311)宛のカプセリングを行おうとするが、故障であるので、故障切替え中に移行する。
ここで、OpenFlowスイッチ300は、正常時、故障切替え中、故障切替え完了時のいずれかにかかわらずOpenFlowコントローラ320が予備系着側VTEP対応表322にコントロール保持情報(図4の符号c参照)を記憶する。OpenFlowコントローラ320は、予備系着側VTEP対応表322にコントロール保持情報(VTEP(0系):VTEP1311 VTEP(1系):VTEP1312)を記憶する。OpenFlowスイッチ300への優先度は、優先度が最も低い(高コスト)「100」である。
このため、ルータ21(発側VTEP201)は、図5(a)のフレームフォーマットを有する場合、故障切替え中、一時的に、優先度の低い(高コスト)OpenFlowスイッチ300にルーチングする。
図4の白抜きに斜線の矢印(⇒(矢印))に示すように、ルータ1301,1302(着側VTEP1311,1312)は、ルータ1101,1102を経由してルータ21(発側VTEP201)に経路広告する(図4の符号e,f,g,h参照)。図4の符号e,f,g,hに示すように、対向VTEP宛ての経路広告は、正常時にVTEP1311経路(図4の打ち消し線参照)であったものが故障切替え中ではVTEP1312経路となる。一方、OpenFlowスイッチ300は、優先度を低くして対向VTEP宛ての経路広告(優先度は「100」)を行う(図4の符号i参照)。すなわち、ルータ1301(着側VTEP1311)から、ルータ1101を経由してルータ21(発側VTEP201)に経路広告されたVTEP経路(図4の符号e,f参照)の優先度は「10」、ルータ1302(着側VTEP1312)から、ルータ1102を経由してルータ21(発側VTEP201)に経路広告されたVTEP経路(図4の符号g,h参照)の優先度は「20」である。また、OpenFlowスイッチ300のOpenFlow対応ルータ310から、L3 広域NW3を経由してルータ21(発側VTEP201)に経路広告されたVTEP経路(図4の符号i参照)の優先度は「100」である。
ここで、経路広告は、本来、自己の先に該当経路がある時に広告するものである。しかし、OpenFlowスイッチ300による経路広告は、自己の先に該当経路(ここではVTEP1311宛て経路)がないにも拘わらず経路広告する、という点で一般的なものとは異なる。
OpenFlowスイッチ300は、図5(b)の符号bに示すように、あらかじめ設定しておいたルールに従い、宛先IPを宛先VTEPから予備系着側VTEPに書き換える。この場合、OpenFlowスイッチ300は、トンネルの宛先を「Outer IP(Dst:VTEP1311)」から、「Outer IP(Dst:VTEP1312)」に変更する。一般に、対向のVTEP1311以外がMACテーブルのトンネルの宛先を書き換えることは、従来技術では行われていない。本実施形態では、ネットワークシステム1000は、OpenFlowスイッチ300を備え、対向VTEP故障時に限り、OpenFlowスイッチ300が宛先IPを書き換える点に特徴がある。
DC100のルータ1302の着側VTEP1312は、図4の符号dに示すように、MAC学習されたMACテーブル(MAC:ユーザA RemoteVTEP:VTEP201)を保持する。
故障が発生すると、発着VTEPのみで構成される従来技術では、VTEPの経路が消失するため、宛先が分からず転送ができなくなる。具体的には、例えば図4に示すルータ1301が故障した場合、VTEP1311宛の経路が失われ、DC100側へルーチングすべきという経路情報は失われる。
その後、予備系のルータ1302(着側VTEP1312)へ至るトラヒックフロー(図4の矢印(→)参照)に示すように、通常のルーチングにより予備系のルータ1302まで転送が行われる。これにより、OpenFlowスイッチ300のみで切替可能であるので、高速な故障切替が実現できる。
図6は、ネットワークシステム1000の故障切替え完了時のトラヒックフローを説明する図である。
故障切替え中のOpenFlowスイッチ300の動作によって、予備系のルータ1302の着側VTEP1312までトラヒックが転送される。ルータ1302の着側VTEP1312は、図6の符号dに示すように、MAC学習されたMACテーブル(MAC:ユーザA RemoteVTEP:VTEP201)を保持する。
そして、図6の破線矢印(→)に示すように、ルータ1302の着側VTEP1312(サーバVTEP側)からユーザAのルータ21の発側VTEP201(ユーザVTEP側)へトラヒックが疎通する。
この場合、図6の符号jに示すように、ユーザAへの返答は優先度(ルーチングコスト差)からルータ1101経由になる(図6の破線トラヒックフロー(→(破線矢印))参照)。
このように、OpenFlowスイッチ300によって、一度、ルータ1302の予備系VTEP1312にパケット転送ができているので、高速切替が実現できる。
一般に、予備系サーバ側(図6ではサーバ1402)がリクエストに対する応答を返すことが想定される。この応答の仕組みについて説明する。
着側VTEP1312(サーバVTEP側)からルータ21の発側VTEP201(ユーザVTEP側)へのトラヒック疎通によって、VTEP201(ユーザVTEP側)は、図6の符号aに示すMACアドレステーブルが書き換わる。
すなわち、故障切替え完了時には、図6の符号aに示すように、ルータ21の発側VTEP201は、MAC学習により、MACテーブルの「RemoteVTEP:VTEP1311」がMACテーブルの「RemoteVTEP:VTEP1312」に書き換えられる。
例えば、サービスAがユーザAに通信を行うとVTEP201にパケットが到達する。これを受けて、VTEP201は、VTEP201が有するMACアドレステーブルを書き換える。これにより、VTEP201は、サービスAが、故障前、VTEP1311の先のサーバ1401に存在していたが、故障後、VTEP1312に存在することを知ることになる。
その結果、OpenFlowスイッチ300経由の通信は行われなくなり、ルーチングによる最適な経路で転送が可能となる。
図7の符号aに示すように、トンネルの宛先を「Outer IP(Dst:VTEP1312)」とする。MAC学習により、宛先VTEPの変更を知り、素早く予備系へ切り替えできる。下記の利点がある。(1)ARP(またはE−VAN)等による切替ではなく、トラヒックデータそのものだけで切替可能であるため、切替が高速である。(2)フラッディング不要なため、NWやサーバ装置への負荷が小さくて済む。
故障切替え中、OpenFlowスイッチ300宛のVTEP経路が一時的に使用され、OpenFlowスイッチ300宛に転送が行われる。OpenFlowスイッチ300は、あらかじめ設定しておいたルールに従い、宛先IPアドレスを予備系VTEP(VTEP1312)に書き換える。すなわち、OpenFlowスイッチ300は、図5(b)の符号bに示すように、フレームフォーマット400のVXLANフレーム410の宛先IPを、「Outer IP(Dst:VTEP1311)」から、「Outer IP(Dst:VTEP1312)」に変更する。
故障切替え完了時、予備系着側VTEPは、対応する着側VTEPが有していた発側VTEP宛てにトラヒックを疎通し、トラヒックが疎通した発側VTEPは、予備系着側VTEPを仮想L2トンネルの宛先としてパケットをカプセリングする。
宛先VTEPを変更し、経路切替を実現することで、VTEP故障を救済し、広域NWにおける耐障害性や運用性を向上させることができる。VTEP故障時もフラッディングなしで実現可能となる。
図1に示すように、ルータ23(発側VTEP)とルータ2301およびルータ1301(着側VTEP)に仮想L2トンネル識別子(VNI)=10000を付与する。これにより、DC100,200は、付与されたトンネル識別子VNIを参照するだけでどのVTEPに転送すればよいかを判別可能となる。また、ルータ23(発側VTEP)に、ルータ2301とルータ1301(着側VTEP)とが接続されるマルチポイント接続も可能となる。
(1) NFV環境においてサーバ障害時の切り替え時間が短縮される。特に、ユーザ側のVTEPの数が多い環境になればなるほど顕著になる。一般に、NFVでは、DC側VTEPよりユーザ側VTEPの方が圧倒的に多いため、本ネットワークシステム1000による耐障害性向上は重要となる。
(2) DC故障に対してその影響が広域NWまで波及しない。
以上により、耐障害性や運用性が向上する。
(3) 全トラヒックを一般に転送処理能力の低いOpenFlowで処理する必要がないので、大規模ネットワークへ適用することができる。
(4) 図1に示すように、ルータ23の発側VTEP203に、ルータ1301の着側VTEP1311とルータ2301の着側VTEP2311とが接続されるマルチポイント接続も可能となる。
(6) 正常時はOpenFlowスイッチ300宛のルーチング優先度を低くしておくことで、スケールする構成を実現している。
(7) 故障時は一時的にOpenFlowスイッチ300宛に転送を実行し、宛先IPアドレスを書き換えることで予備系ルータへの転送を実現する。
(8) 経路切替後に予備系ルータ発の通信が一度でも発生すると、MACアドレス学習の仕組みにより最適なルートで経路転送を実現することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
3 L3 広域NW(L3ネットワーク)
2,21,22,110,1101,1102,130,1301,1302,210,2101,2102,230,2301,2302 ルータ
20,201,202,203 発側VTEP(発側トンネル終端ポイント)
100,200 DC
1401,2401 現用系サーバ
1402,2402 予備系サーバ
131,1311,1312,231,2311,2312 着側VTEP(着側トンネル終端ポイント)
120,220 L3 DC NW
300 OpenFlowスイッチ
310 OpenFlow対応ルータ
320 OpenFlowコントローラ(処理部)
321 ルーチングエンジン
322 予備VTEP対応表(記憶部)
1000 ネットワークシステム
VNI トンネル識別子
Claims (4)
- L3(レイヤ3)ネットワーク上に仮想L2(レイヤ2)トンネルを構築して、前記L3ネットワーク上に接続されるL2サービス提供端末と前記L3ネットワークに接続されたDC(Data Center)内のDCネットワークに接続される端末との間でパケットを送受信するネットワークシステムであって、
前記L3ネットワークと前記L2サービス提供端末のL2ネットワークの接続点に実装された発側トンネル終端ポイントと、
前記DC内の前記端末と前記DCネットワークの接続点に実装された着側トンネル終端ポイントと、
前記L3ネットワークに接続されたOpenFlowスイッチと、を備え、
前記OpenFlowスイッチは、
前記着側トンネル終端ポイントに対応する予備系着側トンネル終端ポイントを記憶する記憶部と、
前記着側トンネル終端ポイントの故障時、あらかじめ設定した規則に従って、故障した前記着側トンネル終端ポイントを、対応する前記予備系着側トンネル終端ポイントに書き換えて転送する処理部と、を備え、
前記予備系着側トンネル終端ポイントは、対応する前記着側トンネル終端ポイントが有していた前記発側トンネル終端ポイント宛てにトラヒックを疎通し、
前記トラヒックが疎通した前記発側トンネル終端ポイントは、前記予備系着側トンネル終端ポイントを仮想L2トンネルの宛先としてパケットをカプセリングし、
前記発側トンネル終端ポイントは、前記故障時以外は前記OpenFlowスイッチへトラヒックを流入させないこと
を特徴とするネットワークシステム。 - 前記着側トンネル終端ポイントと前記予備系着側トンネル終端ポイントと前記OpenFlowスイッチとは、ルーチングの優先度をあらかじめ経路広告し、前記OpenFlowスイッチの優先度は、前記着側トンネル終端ポイントの優先度および前記予備系着側トンネル終端ポイントの優先度よりも、優先度が低いこと
を特徴とする請求項1に記載のネットワークシステム。 - 前記発側トンネル終端ポイントは、前記着側トンネル終端ポイントからの経路広告がない場合を当該着側トンネル終端ポイントの故障と判定し、当該故障時に前記OpenFlowスイッチ宛てに転送を行うこと
を特徴とする請求項1または請求項2に記載のネットワークシステム。 - L3(レイヤ3)ネットワーク上に仮想L2(レイヤ2)トンネルを構築して、前記L3ネットワーク上に接続されるL2サービス提供端末と前記L3ネットワークに接続されたDC(Data Center)内のDCネットワークに接続される端末との間でパケットを送受信するネットワークシステムのパケット転送方法であって、
前記L3ネットワークと前記L2サービス提供端末のL2ネットワークの接続点に実装された発側トンネル終端ポイントと、
前記DC内の前記端末と前記DCネットワークの接続点に実装された着側トンネル終端ポイントと、
前記L3ネットワークに接続されたOpenFlowスイッチと、を備え、
前記OpenFlowスイッチにおいて、
前記着側トンネル終端ポイントに対応する予備系着側トンネル終端ポイントを記憶する記憶工程と、
前記着側トンネル終端ポイントの故障時、あらかじめ設定した規則に従って、故障した前記着側トンネル終端ポイントを、対応する前記予備系着側トンネル終端ポイントに書き換えて転送する処理工程と、を有し、
前記予備系着側トンネル終端ポイントにおいて、
対応する前記着側トンネル終端ポイントが有していた前記発側トンネル終端ポイント宛てにトラヒックを疎通し、
当該トラヒックが疎通した前記発側トンネル終端ポイントにおいて、
前記予備系着側トンネル終端ポイントを仮想L2トンネルの宛先としてパケットをカプセリングし、
前記発側トンネル終端ポイントにおいて、前記故障時以外は前記OpenFlowスイッチへトラヒックを流入させないこと
を特徴とするパケット転送方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2015150249A JP6402078B2 (ja) | 2015-07-30 | 2015-07-30 | ネットワークシステムおよびパケット転送方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2015150249A JP6402078B2 (ja) | 2015-07-30 | 2015-07-30 | ネットワークシステムおよびパケット転送方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2017034365A JP2017034365A (ja) | 2017-02-09 |
JP6402078B2 true JP6402078B2 (ja) | 2018-10-10 |
Family
ID=57989496
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015150249A Active JP6402078B2 (ja) | 2015-07-30 | 2015-07-30 | ネットワークシステムおよびパケット転送方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP6402078B2 (ja) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6549996B2 (ja) * | 2016-01-27 | 2019-07-24 | アラクサラネットワークス株式会社 | ネットワーク装置、通信方法、及び、ネットワークシステム |
JP7052580B2 (ja) | 2018-06-13 | 2022-04-12 | 日本電信電話株式会社 | ネットワーク制御装置、ユーザ端末、通信システム、ネットワーク制御方法およびネットワーク制御プログラム |
WO2022176030A1 (ja) * | 2021-02-16 | 2022-08-25 | 日本電信電話株式会社 | 通信制御装置、通信制御方法、通信制御プログラム及び通信制御システム |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH07264233A (ja) * | 1994-03-24 | 1995-10-13 | Hitachi Ltd | ルート高速切替方法及びルータ装置 |
JP4773981B2 (ja) * | 2007-01-12 | 2011-09-14 | 富士通株式会社 | 通信制御プログラム |
JP5367764B2 (ja) * | 2011-06-14 | 2013-12-11 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | 仮想ネットワークシステム、構成変更方法、トンネル接続装置、及びプログラム |
CN102333028B (zh) * | 2011-06-22 | 2013-02-13 | 杭州华三通信技术有限公司 | 一种分层式二层虚拟专用网发送报文的方法及通信设备 |
-
2015
- 2015-07-30 JP JP2015150249A patent/JP6402078B2/ja active Active
Also Published As
Publication number | Publication date |
---|---|
JP2017034365A (ja) | 2017-02-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11411770B2 (en) | Virtual port channel bounce in overlay network | |
US10333836B2 (en) | Convergence for EVPN multi-homed networks | |
US11271905B2 (en) | Network architecture for cloud computing environments | |
US9100213B1 (en) | Synchronizing VPLS gateway MAC addresses | |
CN111740913B (zh) | 在计算机网络内转发网络流量的方法、路由器及可读介质 | |
JP5991424B2 (ja) | パケット書換装置、制御装置、通信システム、パケット送信方法及びプログラム | |
US20180351858A1 (en) | Virtual machine migration | |
US11336485B2 (en) | Hitless linkup of ethernet segment | |
CN112887188B (zh) | 一种报文转发方法及设备 | |
EP3641241A1 (en) | Node protection for bum traffic for multi-homed node failure | |
CN111988222A (zh) | 数据传输方法及装置、电子设备和计算机可读存储介质 | |
WO2020182085A1 (zh) | 报文的传输方法和设备 | |
JP6402078B2 (ja) | ネットワークシステムおよびパケット転送方法 | |
US11228459B2 (en) | Anycast address configuration for extended local area networks | |
JP2015512587A (ja) | パケット交換網における擬似回線グループ | |
JP2015512588A (ja) | パケット交換網における擬似回線拡張グループメッセージング | |
JP4388464B2 (ja) | パケット中継装置およびパケット通信ネットワーク | |
JP6718739B2 (ja) | 通信装置および通信方法 | |
JP6261001B2 (ja) | 経路制御システムおよびその方法 | |
US11296907B2 (en) | Systems and methods for transitioning of virtualized transport networks | |
Cisco | Configuring DECnet | |
US9270588B2 (en) | Host route convergence based on sequence values | |
JP2016149701A (ja) | ネットワークシステムおよびパケット転送方法 | |
US20240039832A1 (en) | Hitless migration of interconnected data center networks for network virtualization overlay using gateways | |
JP2017130789A (ja) | パケット転送装置、パケット転送方法、および、プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20170830 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20180620 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20180626 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180802 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20180904 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20180910 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 6402078 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |