Quagga で AWS Direct Connect の疑似環境を作る

AWS とデータセンターを専用線ないし閉域網で接続する場合、AWS Direct Connect を利用するのが一般的である。利用の方法としてはまずはAWS Direct Connect パートナーに登録されている事業者と組むことになる。事業者はそれぞれ固有の接続サービスを提供しており、必要なネットワーク機器の管理やコンフィグレーションまですべてやってくれるようなものもあれば、回線だけを契約して機器の設置やコンフィグレーションはすべて自分で行うという選択肢も取れる。

今回は回線の契約を行い、ネットワーク機器の用意や設定はすべて自分でやるという選択肢を取る場合にそれを模擬するための環境を作ることについて書く。疑似環境を作っておけばオフィスで DC に設置する機器類の設定や実験がAWS側との疎通込みでできる。まず結論から書くとタイトルの通り Quagga を使って Direct Connect の AWS 側ルータを模擬する、という話だ。Quagga は BGP が喋れるルーティングソフトウェアの一種である。なお、今回の構成では冗長化は考慮しない。

背景

話のバックグラウンドを説明する必要がある。

金融関係をやっているとどうしても物理インフラが必要になってくる。外部接続ポリシーとして専用線が必要だったりするためだ。冒頭に少し書いたが、その疑似環境をなぜつくるのかというと、

というのがある。資金に余裕のある会社であれば、実際に現地に設置する機器に加えて実験用の機器も買えばいいのだが、できればコストを抑えたいし会社としても資産をあまり持ちたくない。またネットワーク機器は普通に買うと数十万~100万はする。高額である。

ということで低コストの練習環境を作る。個人的に、コストや要件などにキッツい制約がある環境下でうまいことやる方法を考えたりするのは結構好きだったりする。

ダイレクトコネクトの図解と本番の構成

まず先にダイレクトコネクトの図解と本番での構成について書く。ダイレクトコネクト経由で VPC と DC を接続する図は下記の通りになる。

01

登場人物を大きく分けると AWS, DC(DC事業者管理領域)、DC(自社管理領域)となる。AWS は自分たちの AWS アカウントである。

真ん中のDC(DC事業者管理領域)を見ていく。これは AWS 相互接続ポイントを表す。東京の場合 Equinix Japan の DC の一つである TY2 もしくはアット東京の CC1 が相互接続ポイントを持っておりここではそれを指している。「DC の SW(スイッチ)」の存在は俺の想像である。というのも Direct Connect の AWS 側設定時に VLAN ID が払い出され、DC(自社管理領域)側の設定時にも同様に DC 側の VLAN ID が払い出される。この VLAN ID はそれぞれ違う ID である。よっておそらく内部に VLAN マッピングを行うためのスイッチが存在していて、それが AWS 側と DC(自社管理領域)側を結ぶ L2 の土管を形成していると推測される。内部のセグメント (169.254.252.8430) はAWSの設定で行うことができる。

AWS 側を細かく見ていく。まず VPC (172.16.0.0/24)があり、そこに EC2 が置かれている。このインスタンスを今回の構成の AWS 側の最終エンドポイントとする。続いて Direct Connect の管理画面を見ると、「接続」「仮想インターフェース」「仮想プライベートゲートウェイ」などがある。「回線」は AWS 上で dxcon-xxxxxx という ID で示され、これは図でいうとオレンジ色の線である。AWS Direct Connect パートナーと契約して用意される回線がこれにあたる。「仮想インターフェース」は AWS 上では dxvif-xxxxx で表され(図では VIF)、ここの設定で VLAN ID 払い出しや、DC(自社管理領域)側の機器 (ここでは L3SW)とAWS ルーター(AWS Router)のピア IP (169.254.252.8530, 169.254.252.8630)をそれぞれ設定できる。この AWS Router と L3SW がレイヤー3で結ばれる。「仮想プライベートゲートウェイ」は図で VGW として表しており、これを AWS の設定で VIF と紐付け、さらに VPC にアタッチすることで、その VPC から Direct Connect を経由して物理データセンターへの経路を提供できる。 ダイレクトコネクトというのは AWS 側の ルータとそのインターフェイス、相互接続ポイントの機器を経由する回線までの範囲の接続設定を行うものといえる。

DC(自社管理領域)には L3SW, ルータ, 物理サーバなどが置かれている。ダイレクトコネクトについてネットで調べると「DC 側のルータ」という表現が出てくるが、今回の例ではこの L3SW がそれに該当し(ややこしくなってしまったが…)、こいつが BGP を喋って AWS Router と対になる。その下にぶら下がっているルータは俺がやっている要件として必要なのだがダイレクトコネクト自体には不要である。サーバは DC 側の最終エンドポイントとなる。これらセグメントはご存知の通り他とかぶらなければ何でも良い。

AWS Router と対になる機器は L3スイッチとしてあるが、条件を満たせばこれは何でもよい。条件というのは BGP が喋れて dot1q の VLAN が吐けることである。

DC - AWS 間の接続の設定

ここで本番環境の構築の手順についても触れておく。回線の申請 -> 機器のラッキング -> 各コンポーネントのコンフィグレーションの順に行う。

回線の申請

回線の申請は AWS Direct Connect パートナーの事業者や AWS によって手順が配られているのでそのとおりにやればよい。おそらくどこも同じだと思うのだが、簡単に手順の一例を書くと、

  1. AWSアカウントやAWS側のセグメントの情報をを事業者に提出する、もしくは事業者の管理画面から設定する
  2. 事業者側の設定完了を待つ
  3. AWS管理画面の Direct Connect に接続 (dxcon-xxxx) ができているので Accept Connection する
  4. AWS管理画面で仮想プライベートゲートウェイを作って VPC にアタッチする
  5. AWS管理画面で仮想インターフェイス作って仮想プライベートゲートウェイにアタッチする

となると思われる。やり方によっては先にAWS 側で Direct Connect の接続を作り、そのときに表示されるLOA(認可証)を事業者に提出するという手順もある。と、まあいくつかや手順があるので、契約した事業者の指示に従うのがよい。

機器のラッキング

する

各コンポーネントのコンフィグレーション

ラッキングが済むと設定の準備が整ったことになる。あとは AWS 側、DC側のコンポーネントに適切な IP やルーティングを設定する。

02

大したハマりどころは無いはずである。強いて言うなら次の点である。「仮想インターフェース」画面の「ルータ設定をダウンロードする」から DC 側の機器の設定を得ることができるのだが、中を見てみると次のように書かれている。

interface GigabitEthernet0/1.200
description "Direct Connect to your Amazon VPC or AWS Cloud"
encapsulation dot1Q 200
ip address 169.254.252.86 255.255.255.252

VLAN ID 200 を設定するようになっている。しかしながら、200 は AWS 側の VLAN であり、ここでは 100 にするのが正解である。データセンターによってはこうなっているのだろうか?よってこれはあくまでも参考までにすべきであると考える。自分が契約しているデータセンターおよびダイレクトコネクトそのものの構成を理解していればすぐに気付けると思われる。

疑似環境

さて、これの疑似環境を次のように作る。

03

最初の図と変化がある場所として、AWS Router は Quagga で置き換える。AWS Router に付いていた VIF と VGW は Quagga の eth0 の IP とする。Quagga の DC 側は VLAN を吐かせる必要があるので、eth0.100 として VLAN つきの仮想 NIC として設定する。Quagga の土台として Raspberry Pi を使ったので NIC が1つしかない。DC の SW は L2SW がありゃいいんだけど持ってねえから無し。Quagga についても本当は余りのルータかL3スイッチでも転がってりゃいいんだけどね。ここでの VLAN ID はDC(自社管理領域)側の VLAN の 100 とする。

物理構成はこう。

04

で構成されている。シングルモードファイバ、メディアコンバータ、SFPモジュールが必要なのは、L3 SW - DC の SW 間をシングルモードファイバで接続するため。なお L3スイッチが Cisco でルータが Juniper なのは諸事情あるためここでは言及しない。現場の状況はこう。

05

Quagga の設定

肝となる Quagga の設定を書く。適切な IP やルーティングを設定することに加えて VLAN を吐かせる、IP Forwarding を行う、BGP を設定する、あたりをクリアすれば良い。

VLAN

Debian 系であれば apt でパッケージが入る。他のディストリビューションでも同様と思われる。eth0にVLAN ID 100をつける。

apt install vlan
sudo su -c 'echo "8021q" >> /etc/modules'
sudo vconfig add eth0 100

/etc/network/interfaces

eth0 は AWS 側に向けた口として 172.16.0.124 を付与し、eth0.100 を VLANデバイスとして DC 側の IP 169.254.252.8530 を付与する。

auto eth0
  iface eth0 inet static
  address 172.16.0.1/24

auto eth0.100
iface eth0.100 inet static
  address 169.254.252.85/30
  vlan-raw-device eth0

IP forwarding

eth0 と eth0.100 間でパケット転送を行うため下記を設定する。/etc/sysctl.conf にも入れておくとよい。

sudo /sbin/sysctl -w net.ipv4.ip_forward=1

BGP

apt で入る。インストールして下記のような設定をブチこむ。

apt install quagga

/etc/quagga/zebra.conf

hostname zebra
password zebra
log stdout

/etc/quagga/bgpd.conf

hostname bgpd
password zebra

router bgp 10124
  bgp router-id 169.254.252.85
  neighbor 169.254.252.86 remote-as 65000
  network 169.254.252.85/30
  network 172.16.0.1/24

ここまでできたら L3SW 側でも BGP の設定を行い、L3SW および Quagga のターミナルそれぞれから show ip bgp neighbors などで BGP セッションの確立を確認する。BGPが確立したら DC側の機器の設定の練習や事前準備を行うことができるので、あとは好きなだけ遊んだら良い。

まとめ

AWS Direct Connect の図解を示し、Quagga で AWS ルータを模擬することによってオフィス内に Direct Connect の練習環境ができることを書いた。そして実際にこの環境のおかげで L3SW および DC 側に置く予定の機器類の設定の練習や検証がAWS側との疎通込みででき、DC作業を短時間で終わらせることができた。機器をそのまま持っていってラックにポンですわ。この記事では触れなかった BGP の経路冗長化の練習もきっとできると思うよ。

おわり


© 2020 Ore no homepage