opencontrailでのexternal-router経由のサービスチェイン

前回の続きで、今回はexternal-router(以下、vMX)を通過するトラフィックに対して、サービスチェインを構成する場合の設定となる。
http://aaabbb-200904.hatenablog.jp/entry/2017/10/29/223844

前回、前々回はnest kvmを使用するため、gcp環境を使ったのだが、今回はvMXも使いたかった関係で、ハイパーバイザとしてqemuを使用して、aws環境での構築を行った。
※ ubuntu16.04.2(ami-ea4eae8c), t2.large 3台を使用
手順は前回と同じだが、追加で、以下の作業を実施している。

1. computeにログイン
2. 以下を実施
# docker exec -it -u root nova_compute bash
 # apt-get update
 # apt-get install vim-common
 # vi /etc/nova/nova.conf
  [libvirt] の節に、
  virt_type=qemu
 を追記
# reboot

※ なお、前回発生した、169.254関係の事象は、今回は発生しなかった、、


このあと本題の、vMXを通過するトラフィックについてサービスチェインを行う場合の設定なのだが、以下の順序で設定を行う必要がある。
1. contrail 上に、ルートターゲットを持ったvn2つ (以下、vn1, vn2、ルートターゲットはそれぞれ 64512:1, 64512:2 で設定) を作成する
2. vMXに上記のルートターゲットを設定した2つのVRF, および、該当VRFに入るためのfirewall filter を定義する
3. 2で作成したvnの間でサービスチェインを設定する

なお、vMX上で該当のVRFに入る条件、および出る条件については、今回はvpcの構成上、ge-0/0/0 のみが一つのサブネットに存在するような構成にしていたため、稼働確認用のインスタンス2台 (以下、pc1, pc2) を用意し、それぞれのソースアドレスで、vn1, vn2に出入りするように設定しておいた。
※ それぞれfirewall filterと VRF内のrouting-options で設定

最終的なvmxコンフィグは以下となる。
https://github.com/tnaganawa/contrail-k8s-tutorial/blob/master/vmx-config/vmx-config-for-service-chaining

contrail-controllerのIP: 172.31.4.76
computeノードのIP: 172.31.10.155
vMX ge-0/0/0のIP: 172.31.10.57
pc1のIP: 172.31.9.34
pc2のIP: 172.31.8.198

また、サービスチェイン設定前後の変化の確認用に、上記 2, 3 のタイミングでの、vmx 内 vn1, vn2 の、ルーティングテーブルを載せておく。
2, 3を比べると、サービスチェインの効果で、vn1のルーティングテーブルがvn2にコピー、vn2のルーティングテーブルがvn1にコピーされ、コピー後のnext-hopがサービスインスタンスのmplsラベルになっていることがわかる (前回同様、該当のmplsラベル (30, 34) が、サービスインスタンスのものとなっている)

(サービスチェイン前)
vn1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
  1. = Active Route, - = Last Active, * = Both
10.0.1.3/32 *[BGP/170] 00:09:34, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 26 10.0.1.4/32 *[BGP/170] 00:09:34, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 30 10.0.1.5/32 *[BGP/170] 00:09:34, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 30 172.31.9.34/32 *[Static/5] 00:08:24 to table inet.0 vn2.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
  1. = Active Route, - = Last Active, * = Both
10.0.2.3/32 *[BGP/170] 00:05:54, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 22 10.0.2.4/32 *[BGP/170] 00:05:54, MED 200, localpref 100, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 34 10.0.2.5/32 *[BGP/170] 00:05:54, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 34 172.31.8.198/32 *[Static/5] 00:05:55 to table inet.0 (サービスチェイン後) vn1.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
  1. = Active Route, - = Last Active, * = Both
10.0.1.3/32 *[BGP/170] 00:07:49, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 26 10.0.1.4/32 *[BGP/170] 00:07:49, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 30 10.0.1.5/32 *[BGP/170] 00:07:49, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 30 10.0.2.3/32 *[BGP/170] 00:07:49, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 30 10.0.2.4/32 *[BGP/170] 00:07:49, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 30 10.0.2.5/32 *[BGP/170] 00:07:49, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 30 172.31.8.198/32 *[BGP/170] 00:04:09, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 30 172.31.9.34/32 *[Static/5] 00:06:39 to table inet.0 vn2.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
  1. = Active Route, - = Last Active, * = Both
10.0.1.3/32 *[BGP/170] 00:04:09, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 34 10.0.1.4/32 *[BGP/170] 00:04:09, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 34 10.0.1.5/32 *[BGP/170] 00:04:09, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 34 10.0.2.3/32 *[BGP/170] 00:04:09, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 22 10.0.2.4/32 *[BGP/170] 00:04:09, MED 200, localpref 100, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 34 10.0.2.5/32 *[BGP/170] 00:04:09, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 34 172.31.8.198/32 *[Static/5] 00:04:10 to table inet.0 172.31.9.34/32 *[BGP/170] 00:04:09, MED 100, localpref 200, from 172.31.4.76 AS path: ?, validation-state: unverified > via gr-0/0/0.32771, Push 34


更に、pc1, pc2, 1-to-2 (サービスインスタンス) に対して、以下のルートを設定することで、pc1, pc2間で、1-to-2 を通過してpingが飛ぶことを確認出来た。(1-to-2 上で sysctl -w net.ipv4.ip_forward=0 で、pingが飛ばなくなることを確認)

(pc1)
ip route add 172.31.8.198/32 via 172.31.10.57

(pc2)
ip route add 172.31.9.34/32 via 172.31.10.57

(1-to-2)
ip route add 172.31.9.34/32 via 10.0.1.1
ip route add 172.31.8.198/32 via 10.0.2.1

f:id:aaabbb_200904:20171103020559p:plain


上記の例では、1つのサービスインスタンスだけを挟んでいるが、前回同様、複数のサービスインスタンスを挟むことも出来る。
また、firewall filterを工夫することで、適当なソースアドレス、行き先アドレスについてのみ、サービスを適用する、等も可能となる。
ルーターを通過するトラフィックごとに、適用するサービスを制御したい場合には、役にたつのではなかろうか。