opencontrailでのサービスチェイン
前回 (http://aaabbb-200904.hatenablog.jp/entry/2017/10/29/191914) に続いて、openstack上のopencontrailで、サービスチェインを試してみたので、まとめておく。
※ k8s版だと該当uiが無効化されており、使用不可
サービスチェインの設定方法は以下を参照。
https://www.juniper.net/documentation/en_US/contrail3.2/topics/task/configuration/service-chaining-vnc.html
https://www.juniper.net/documentation/en_US/contrail3.2/topics/task/configuration/service-chaining-example-ui.html
今回試した構成では、以下のように、1-to-2 というcirrosイメージを作成して、そちらを2つの仮想ネットワークの間に挟んでいる。
vm1(10.0.1.3) - vn1 - (10.0.1.4)1-to-2(10.0.2.4) - vn2 - vm2(10.0.2.3)
通常、この構成であれば、vm1 のデフォルトゲートウェイを 10.0.1.4, vm2のデフォルトゲートウェイを10.0.2.4 にむければ、そのままルーティング可能 (1-to-2で net.ipv4.ip_forward=1 の定義は必要) だが、今回はvm1のデフォルトゲートウェイは10.0.1.1, vm2 のデフォルトゲートウェイは10.0.2.1 となっており、どちらもvrouterが提供するipを向いている。
このため、サービスチェインが構成される前だと、vn1/vn2のVRFは、どちらも、10.0.(2/1).3 への経路を持っていないので、vm1, vm2の間で、pingは飛ばない状況になる。
一方、サービスチェインが構成されると、vn1/vn2はお互いが持っている経路を相互にインポートし、かつ、インポートした経路のnext-hop を1-to-2のip(実際には対応するmplsラベル) に変更する、という形で経路が配布される。
このため、サービスチェイン設定時には、以下のようにルーティングが行われる形になる
vm1(10.0.1.3) - (10.0.1.1: 10.0.2.xは10.0.1.4に送付)vn1 - (10.0.1.4)1-to-2(10.0.2.4) - vn2(10.0.2.1: 10.0.1.xは10.0.2.1に送付) - vm2(10.0.2.3)
※ 確認用に、サービスチェイン設定後のvn1 のルーティングテーブルと、ip/mplsラベルの対応を載せておく (label 22が10.0.1.4に対応)
実際の作業では、以下のような順で設定を行っている。
- service templateの作成
- service instanceの作成(v2テンプレートの場合、事前にhorizonで1-to-2を立ち上げておく必要あり)
- policyの作成
- network へのpolicy付与
結果の画面は以下のようになる。
- service templateの作成
- service instanceの作成
- policyの作成
- network へのpolicy付与
また、cirros自身の設定は、以下のように実施しておく。
# ifconfig eth1 10.0.2.4 netmask 255.255.255.0
# echo 1 > /proc/sys/net/ipv4/ip_forward
この状態で、vm1 から vm2に向けてping を実施すると、pingが通ることが確認できる。
ちなみに、contrailのサービスチェインでは、vn1からvn2への疎通で、複数のservice instance を通すこともできる。
※ 以下の例では 1-to-2-2 としてcirrosを作成
この場合、1-to-2 の 10.0.2.4側から出た後、そのパケットがそのまま 1-to-2-2 のvn1 側(下記の例では、10.0.1.6) に届く動作になる (ルーティング的には、1-to-2から出た側のVRFで10.0.2.3 のnext-hopが10.0.1.6のmplsラベル (38) にセットされている)
少々非直観的な感はあるが、慣れるとvlanを駆使する場合と比べてかなり表現力が増すので、覚えておくとよいのではなかろうか。
