サービスチェーンルートリオリジネーション
概要:Contrail のサービス チェイニング
Contrailでは、サービスチェイニング機能により、オペレータは動的サービスを挿入して2つの仮想ネットワーク間のトラフィックを制御できます。サービスチェイニングは、ネクストホップスティッチングの基本的なルールに基づいて機能します。
図1では、左VNと右VNの間にサービスチェーンが挿入されています。サービスチェーンには、必要なネットワークポリシーを達成するための1つ以上のサービスインスタンスが含まれています。
この例では、右 VN の VM のルートが左 VN のルーティング テーブルに追加され、トラフィックがサービス チェーンの左インターフェイス経由で送信されるようにネクスト ホップが変更されます。これは、ルート再オリジネーションの例です。

サービス チェイニングでルートの再発信を使用する(たとえば、右側のネットワークのルートを左側のルーティング テーブルに配置する)には、次の機能が必要です。
ルートアグリゲーション
スケーリングの目的で、各 VM のすべてのルート (/32) を公開するのではなく、集約されたルートをサービス チェーン ルートとして公開すると便利です。これにより、ゲートウェイルーターのルートテーブルのメモリフットプリントが削減され、制御ノードとゲートウェイルーター間のルート交換も削減されます。ルートは、デフォルトルート(0/0)、VNサブネットプレフィックス、または任意のルートプレフィックスに集約できます。
再発信ルートのパス属性の変更
BgpPath
サービス チェーン ルートの属性を変更する必要がある場合があります。たとえば、サービス チェーンのフェールオーバーの場合で、同じ 2 つの VN 間で接続されている同一のサービスを持つ 2 つのサービス チェーンがあります。オペレーターは、フェイルオーバーサポートを提供することで冗長性と高可用性を確保することに加えて、2つのネットワーク間のトラフィックに使用するサービスチェーンを制御する必要があります。再発信ルートのパス属性の変更は、MED(マルチ出口識別子)またはlocal-pref
再発信されたサービスチェーンルートを変更するオプションを提供することにより、ルーティングポリシーによって実装されます。ルートの再発信を有効または無効にするコントロール
一部のシナリオでは、たとえば、サービス VM インターフェイスで静的ルートが構成されている場合、オペレーターはサービス チェーン ルートとしてのルートの再発信を停止するコントロールを必要とします。ルートの再発信を有効または無効にする制御は、コミュニティで
no-reoriginate
ルートをタグ付けすることで実装されます。コミュニティタグがあるルートはno-reoriginate
、ルート再発信のためにスキップされます。
Contrail リリース 5.0 以降、サービス チェーン内の 1 つ以上のサービス インスタンスに障害が発生すると、サービス チェーンの両側のルートの再発信が停止し、ルートは別の Contrail クラスタの一部であるバックアップ サービス チェーンに自動的に収束します。詳細については、「 サービス インスタンスの正常性チェック」を参照してください。
ルートアグリゲーション
ルートアグリゲーション構成オブジェクトには、集約するプレフィックスのリストが含まれています。ルート集合オブジェクトの next-hop フィールドには、集約ルートのネクストホップとしてネクストホップがステッチされているルートのアドレスが含まれています。
ルート集約は、サービス インスタンスで構成されます。オペレーターは、複数のルート集約オブジェクトをサービス インスタンスにアタッチできます。例えば、右のVNからのルートを集約し、左のVNのルートテーブルに再発信する必要がある場合、右のVNのサブネット接頭辞のプレフィックスでルート集約オブジェクトが作成され、サービスインスタンスの左のインターフェイスにアタッチされます。
サービスチェーンに複数のサービスインスタンスがある場合、ルートアグリゲートオブジェクトは、左端のサービスインスタンスの左側のインターフェイスと、右端のサービスインスタンスの右側のインターフェイスにアタッチされます。
関係を 図 2 に示します。

スキーマトランスフォーマーは、ルートアグリゲートオブジェクトのネクストホップフィールドをサービスチェーンインターフェイスアドレスに設定します。また、スキーマ トランスフォーマーは、ルート集計オブジェクトを、サービス インスタンス用に作成された内部ルーティング インスタンスにリンクします。
説明されている構成を使用して、Contrail 制御サービスはルーティング インスタンスのルート アグリゲーション オブジェクトを読み取ります。最初のより具体的なルートまたは貢献ルートが起動されると (最初の VM が右側の VN で起動された場合)、集約ルートが公開されます。同様に、集約されたルートは、最後のより具体的なルートまたは貢献ルートが削除されると(最後のVMが右側のVNで削除されたとき)削除されます。集約されたルートは、集約されたルートのネクストホップが解決されると公開されます。
デフォルトでは、BGPまたはXMPPルート交換では、制御ノードは集約ルートの寄与ルートを公開しません。
ルート集約のスキーマ
ルートアグリゲートオブジェクト
ルート集約オブジェクトのスキーマを次に示します。1つのルートアグリゲートオブジェクトに複数のプレフィックスを指定できます。
<xsd:element name="route-aggregate" type="ifmap:IdentityType"/> <xsd:complexType name="RouteListType"> <xsd:element name="route" type="xsd:string" maxOccurs="unbounded"/> </xsd:complexType> <xsd:element name='aggregate-route-entries' type='RouteListType'/> <!--#IFMAP-SEMANTICS-IDL Property('aggregate-route-entries', 'route-aggregate') --> <xsd:element name='aggregate-route-nexthop' type='xsd:string'/> <!--#IFMAP-SEMANTICS-IDL Property('aggregate-route-nexthop', 'route-aggregate') -->
ルート集合オブジェクトへのサービスインスタンスリンク
次に示すのは、集計オブジェクトのルートへのサービス インスタンス リンクのスキーマです。オペレーターは、複数のルートアグリゲートオブジェクトを単一のサービスインターフェイスにリンクできます。
<xsd:element name="route-aggregate" type="ifmap:IdentityType"/> <xsd:complexType name="RouteListType"> <xsd:element name="route" type="xsd:string" maxOccurs="unbounded"/> </xsd:complexType> <xsd:element name='aggregate-route-entries' type='RouteListType'/> <!--#IFMAP-SEMANTICS-IDL Property('aggregate-route-entries', 'route-aggregate') --> <xsd:element name='aggregate-route-nexthop' type='xsd:string'/> <!--#IFMAP-SEMANTICS-IDL Property('aggregate-route-nexthop', 'route-aggregate') --> <xsd:simpleType name="ServiceInterfaceType"> <xsd:restriction base="xsd:string"> <xsd:pattern value="management|left|right|other[0-9]*"/> </xsd:restriction> </xsd:simpleType> <xsd:complexType name='ServiceInterfaceTag'> <xsd:element name="interface-type" type="ServiceInterfaceType"/> </xsd:complexType> <xsd:element name="route-aggregate-service-instance" type="ServiceInterfaceTag"/> <!--#IFMAP-SEMANTICS-IDL Link('route-aggregate-service-instance', 'bgp:route-aggregate', 'service-instance', ['ref']) -->
ルート集合オブジェクトへのルーティングインスタンスリンク
以下は、ルートアグリゲーションオブジェクトへのルーティングインスタンスリンクのスキーマです。ルーティング インスタンスを複数のルート アグリゲート オブジェクトにリンクして、複数のルート プレフィックスのルート アグリゲーションを実行できます。
<xsd:element name="route-aggregate-routing-instance"/> <!--#IFMAP-SEMANTICS-IDL Link('route-aggregate-routing-instance', 'route-aggregate', 'routing-instance', ['ref']) -->
ルートアグリゲーションの設定とトラブルシューティング
ルート集約オブジェクトの設定
Contrail UI の [> ネットワーク>ルーティングの設定] > [>ルートアグリゲートの作成] 画面を使用して、ルートアグリゲートオブジェクトに名前を付け、 アグリゲートするルート を指定できます。 図3を参照してください。

ルートアグリゲートオブジェクトを作成するVNCスクリプトの例
次の例のように、VNC スクリプトを使用してルートアグリゲートオブジェクトを作成できます。
from vnc_api.vnc_api import * vnc_lib = VncApi("admin", "<password>.", "admin") project=vnc_lib.project_read(fq_name=["default-domain", "admin"]) route_aggregate=RouteAggregate(name="left_to_right", parent_obj=project) route_list=RouteListType(["<ip address>"]) route_aggregate.set_aggregate_route_entries(route_list) vnc_lib.route_aggregate_create(route_aggregate)
サービス インスタンスの構成
ルート集約オブジェクトが、右側の仮想ネットワークの左側のネットワーク サブネット プレフィックスの集合体にリンクされているサービス インスタンスを作成します。 図 4 の例を参照してください。

仮想ネットワークとネットワーク ポリシーを作成する
サブネット 1.1.1/24 と 2.2.2/24 を持つ左右の仮想ネットワークを作成します。左側のVNと右側のVNの間にサービスチェーンを適用するネットワークポリシーを作成します。次の例を参照してください。

ネットワーク ポリシーをアタッチして、左右の VN の間にサービス チェーンを作成します。次の例を参照してください。

APIサーバーでのルートアグリゲートオブジェクトの検証
API サーバー構成データベース内のルート集計オブジェクトを検証します。集合オブジェクトのルーティング インスタンス参照とサービス インスタンス参照を確認します。ルート集約オブジェクトのフィールドは aggregate_route_nexthop
、スキーマトランスフォーマーによってサービスチェーンアドレスに初期化されます。次の例を参照してください。

コントロールノード内のルートアグリゲートオブジェクトの検証
サービスインスタンスの内部ルーティングインスタンスの制御ノードintrospectをチェックして、ルートアグリゲートのインスタンス構成を検証します。例えば:
http://<control-node>:8083/Snh_ShowBgpInstanceConfigReq?search_string=default- domain:admin:right:service-ace7ae00-56e3-42d1-96ec-7fe77088d97f-default- domain_admin_si-aggregate
次の例を参照してください。

制御ノード上のルートアグリゲートオブジェクトの状態を確認するには、ブラウザで以下を指定します。
http://<control-node>:8083/Snh_ShowRouteAggregateReq
次の例を参照してください。

また、右側のVN BGPテーブルで集約ルートのルートテーブルを確認することもできます。例えば:
http://<control-node>:8083/Snh_ShowRouteReq?x=default-domain:admin:right:right.inet.0
次の例を参照してください。

ルーティングポリシー
Contrail は、ルーティング ポリシー インフラストラクチャを使用して、ルートとパス属性を動的に操作します。Contrail では、サービス インスタンスへのインポート ルーティング ポリシーのアタッチもサポートされています。
ルーティング ポリシーには、リスト条件が含まれています。用語は、指定された用語に一致すると、その用語のアクションに基づいて、それ以上の用語は評価されず、ルートがドロップまたは受け入れられる最終ルールにすることができます。
項が終端ルールでない場合、後続の項は指定されたルートに対して評価されます。
リスト用語は、次の例のように構成されています。
Policy { Term-1 Term-2 }
ポリシー用語リストの一致とアクションは、Junos 言語の一致とアクションの操作と同様に動作します。
各用語は次のように表されます。
from { match-condition-1 match-condition-2 .. .. } then { action update-action-1 update-action-2 .. .. }
用語に一致条件を含める any
ことはできません。例えば、空 from
は存在してはいけません。
any
一致条件が存在する場合、すべてのルートが条件に一致すると見なされます。
ただし、条件を空にすることも、アクションを then
未指定にすることもできます。
- ルーティング・ポリシーの適用
- ルーティング ポリシー設定
- ルーティングポリシーの設定とトラブルシューティング
- VNCスクリプトを使用したルーティングポリシーの作成
- APIサーバーでのルーティングポリシーの検証
- 制御ノードのルーティングポリシーの確認
- 制御ノードでのルーティングポリシー設定の確認
- ルーティングインスタンスでのルーティングポリシー設定の確認
ルーティング・ポリシーの適用
ルーティング ポリシーの評価には、次のキーポイントがあります。
ルーティング ポリシーの条件が複数の一致条件で構成されている場合、ルートがすべての一致条件を満たすと、条件で指定されたアクションが適用されます。
ポリシー内の条件が一致しない場合、すべてのルートが一致に対して評価されます。
一致が発生したが、ポリシーで受け入れ、拒否、または次の用語アクションが指定されていない場合は、次のいずれかが発生します。
次の項が存在する場合は、その項が評価されます。
他の項が存在しない場合は、次のポリシーが評価されます。
他のポリシーが存在しない場合、ルートは受け入れられます。デフォルトのルーティングポリシーアクションは「accept」です。
ポリシー内の項との一致が発生しず、同じポリシー内に後続の項が存在する場合は、次の項が評価されます。
ポリシー内のどの条件とも一致せず、後続のポリシーが存在する場合は、次のポリシーが評価されます。
ポリシーまたはすべてのポリシーの終わりまでに一致が発生しない場合、ルートは受け入れられます。
ルーティング・ポリシーは、複数の用語で構成できます。各用語は、一致するルートに適用する一致条件とアクションで構成されています。
各ルートは、ポリシーに対して次のように評価されます。
ルートは最初の項に対して評価されます。一致する場合は、指定されたアクションが実行されます。アクションがルートの受け入れまたは拒否である場合、そのアクションが実行され、ルートの評価が終了します。次の項アクションが指定されている場合、またはアクションが指定されていない場合、またはルートが一致しない場合、評価は上記のように後続の項に継続される。
与えられたルーティングポリシーの最後の非終端項にヒットすると、ステップ1で説明したのと同じ方法で、次のポリシー(存在する場合)に対してルートが評価されます。
一致条件: 差出人
一致条件には、条件で指定されたアクションを適用するために満たすべき一致条件 from
のリストが含まれます。項に一致条件がない可能性があります。これは、すべてのルートがこの条件に一致し、条件で指定されたアクションに従ってアクションが適用されることを示します。
次の表は、Contrail でサポートされる一致条件について説明しています。
一致条件 |
ユーザー入力 |
説明 |
---|---|---|
プレフィックス |
一致させるプレフィックスのリスト |
リスト内の各プレフィックスは、プレフィックスおよびマッチタイプとして表され、プレフィックスマッチタイプは以下のようになります。
例: 1.1.0.0/16 ルートのプレフィックスがリスト内のプレフィックスのいずれかと一致する場合、ルートはこの条件に一致します。 |
コミュニティ |
照合するコミュニティ文字列 |
または を含む |
プロトコル |
一致させるパスソースまたはパスプロトコルの配列 |
BGP |ティッカー |スタティックルート |サービスチェーン |集計。パスプロトコルがリスト内のプロトコルの1つである場合、パスはこの条件に一致すると見なされます。 |
ルーティングポリシーアクションと更新アクション
ポリシー・アクションには、アクションと更新アクションの2つの部分があります。
以下の表では、Contrail でサポートされる状況について説明します action
。
アクション |
ターミナル。 |
説明 |
---|---|---|
拒否 |
はい |
この条件に一致するルートを拒否します。この用語に達した後、それ以上の用語は評価されません。 |
受け入れる |
はい |
この条件に一致するルートを受け入れます。この用語に達した後、それ以上の用語は評価されません。ポリシーアクションで指定された更新を使用して、ルートが更新されます。 |
次学期 |
いいえ |
これは、ポリシー条件の一致時に実行されるデフォルトのアクションです。ポリシーアクションで指定された更新に従って、ルートが更新されます。ルーティングポリシーに存在する次の用語は、ルート上で処理されます。ポリシーにこれ以上の用語がない場合は、次のルーティング ポリシーが処理されます(存在する場合)。 |
更新アクションセクションでは、一致するルートに対して実行するルート変更を指定します。
以下の表では、Contrail でサポートされる状況について説明します update action
。
更新アクション |
ユーザー入力 |
説明 |
---|---|---|
コミュニティ |
コミュニティ一覧 |
ポリシーの更新の一環として、コミュニティに対して次のアクションを実行できます。
|
Med |
BGP パスの MED を更新する |
MED を表す符号なし整数 |
ローカル設定 |
BgpPath のローカル設定を更新する |
ローカル設定を表す符号なし整数 |
ルーティング ポリシー設定
ルーティング ポリシーは、サービス インスタンスで構成されます。複数のルーティング・ポリシーを1つのサービス・インスタンス・インターフェイスにアタッチできます。
ポリシーが左側のインターフェイスに適用されると、右側のVNに属するルートについて、左側のVNで再発信されたすべてのルートについてポリシーが評価されます。同様に、右側のインターフェイスにアタッチされたルーティングポリシーは、左側のVNに属するルートについて、右側のVNでのルート再発信に影響を与えます。
次の図は、ルーティング ポリシーの設定を示しています。

ルーティング ポリシー リンク データに指定されたポリシー シーケンス番号によって、ルーティング ポリシーが評価される順序が決まります。サービス インスタンスのルーティング ポリシー リンク データは、ポリシーを左側のサービス インターフェイス、右側のサービス インターフェイス、またはその両方のインターフェイスに適用する必要があるかどうかも指定します。
ポリシー評価の順序を変えて、サービス インスタンスの左右両方のインターフェイスに同じルーティング ポリシーをアタッチできます。そのため、ルーティング ポリシー リンク データには、左右のインターフェイス用に別々にポリシー評価用のシーケンス番号が含まれます。
スキーマ トランスフォーマーは、ルーティング ポリシー オブジェクトを、サービス インスタンス用に作成された内部ルーティング インスタンスにリンクします。また、トランスフォーマーは、同じポリシー順序を確保するために、ルーティング・ポリシー・リンク・データをコピーします。
ルーティングポリシーの設定とトラブルシューティング
このセクションでは、サービスチェーンのルーティングポリシーを作成する方法と、ポリシーを検証する方法について説明します。
ルーティング・ポリシーの作成
まず、ルーティングポリシー「 >ネットワーキング>ルーティングの設定」>「>ルーティングポリシーの作成」を作成します。次の例を参照してください。

Contrail UIとREST APIを使用してBGPルーティングポリシーを設定してから仮想ネットワークに割り当てることができますが、仮想ネットワークがL3VPNに接続されている場合、ルーティングポリシーは適用されません。
サービス インスタンスの構成
サービス インスタンスを作成し、左右両方のインターフェイスにルーティング ポリシーをアタッチします。ポリシーの順序は、一覧で指定されたポリシーの順序に基づいて UI によって計算されます。

サービスチェーンのネットワークポリシーの設定
[ ポリシーの編集] で、サービスチェーンのポリシーを作成します (次の例を参照)。

VNCスクリプトを使用したルーティングポリシーの作成
次の例は、VNC API スクリプトを使用してルーティングポリシーを作成する方法を示しています。
from vnc_api.vnc_api import * vnc_lib = VncApi("admin", "<password>", "admin") project=vnc_lib.project_read(fq_name=["default-domain", "admin"]) routing_policy=RoutingPolicy(name="vnc_3", parent_obj=project) policy_term=PolicyTermType() policy_statement=PolicyStatementType() match_condition=TermMatchConditionType(protocol=["bgp"], community="22:33") prefix_match=PrefixMatchType(prefix="1.1.1.0/24", prefix_type="orlonger") match_condition.set_prefix([prefix_match]) term_action=TermActionListType(action="accept") action_update=ActionUpdateType(local_pref=101, med=10) add_community=ActionCommunityType() comm_list=CommunityListType(["11:22"]) add_community.set_add(comm_list) action_update.set_community(add_community) term_action.set_update(action_update) policy_term.set_term_action_list(term_action) policy_term.set_term_match_condition(match_condition) policy_statement.add_term(policy_term) routing_policy.set_routing_policy_entries(policy_statement) vnc_lib.routing_policy_create(routing_policy)
APIサーバーでのルーティングポリシーの検証
ルーティング・ポリシーのサービス・インスタンス参照とルーティング・インスタンス参照を確認するには、API サーバー構成データベースを参照します。次の例を参照してください。

制御ノードのルーティングポリシーの確認
制御ノードでルーティングポリシーを検証できます。
ブラウザーで以下を参照します。
http://<control-node>:8083/Snh_ShowRoutingPolicyReq?search_string=failover
次の例を参照してください。

制御ノードでのルーティングポリシー設定の確認
ルーティングポリシー設定は、制御ノードで確認できます。
ブラウザーで以下を参照します。
http://<control-node>:8083/Snh_ShowBgpRoutingPolicyConfigReq?search_string=failover
次の例を参照してください。

ルーティングインスタンスでのルーティングポリシー設定の確認
内部ルーティングインスタンスでルーティングポリシー設定を確認できます。
ブラウザーで以下を参照します。
http://<control-node>:8083/Snh_ShowBgpInstanceConfigReq?search_string=<name-of-internal-vrf>
次の例を参照してください。

ルーティングインスタンス運用オブジェクトのルーティングポリシーを検証することもできます。
ブラウザーで以下を参照します。
http://<control-node>:8083/Snh_ShowRoutingInstanceReq?x=<name-of-internal-vrf>
次の例を参照してください。

ルート再発信の制御
インターフェイス静的ルートの再発信を防止する機能は、通常、サービス VM に属するインターフェイスでルートが構成されている場合に必要です。
例として、次の図は、1 つの in-net-nat
サービス インスタンスを最後のサービス VM とし、適切な VN をパブリック VN とする複数のサービス インスタンスを持つサービス チェーンを示しています。
最後のサービス インスタンスは、NAT プールを使用して NAT を実行します。サービス VM の適切なインターフェイスは、NAT プールのインターフェイス静的ルートを使用して構成し、適切な VN の宛先が NAT プール内のアドレスに到達する方法を認識できるようにする必要があります。ただし、NATプールプレフィックスを左のVNに再発信しないでください。
ルートの再発信を防ぐために、インターフェイスの静的ルートには、 と呼ばれる no-reoriginate
既知のBGPコミュニティがタグ付けされています。
制御ノードがルートを再発信する場合、BGP コミュニティでタグ付けされたルートをスキップします。

再生制御の設定とトラブルシューティング
サービスインスタンスのインターフェイス静的ルートの静的ルートのコミュニティ属性は、サービスインスタンスの作成時に指定されます。次の例を参照してください。

次の例を使用して、API サーバーのサービス インスタンス構成オブジェクトに、静的ルートの正しいコミュニティ セットが設定されていることを確認します。次の例を参照してください。
