Help us understand the problem. What is going on with this article?

[Oracle Cloud] 東京-大阪リージョン間リモートピアリングを、複数のVCNで共有する

背景

Oracle Cloud 大阪リージョンがGAしました!
これは、東京-大阪間の接続試してみたい。どうせだったら、リモートピアリングで閉域接続試したい。

リモート・ピアリングするには、まずは各リージョンでDRGを作る必要がある。

よし、作ろう!

drg-1.png

なんと。。Service Limitにひっかかった。。しかも、SRで拡張依頼しても現状5個が上限という(人伝て) ※ 増やせるらしい(未確定)。確かに、ここ(Service Limits)を見ても増やせない制限は書いてない。

そうか、DRGはそんな気軽に使って遊べるものではなかたのか。これは共有環境が必要だ。ということで、複数VCN間で東京-大阪のリモートピアリングを共有できる方法を検証した。

作ったもの

いろいろと調べた結果、DRGを複数VCNで共有するためには、Transit Routingを利用したHub & Spoke構成にする必要があるという結論になりました。

drg-2.png

各VCNに対してルーティングを設定する必要があるため、各VCNに割り当てるCIDRブロックを管理して採番してあげる必要がありそうです。

参考にしたリンク

Oracle Cloud:VCN Transit Routing で Hub and Spoke構成をしてみてみた

ポイント

手順は煩雑なので、ポイントだけ

CIDRの採番

ルーティングを意識する必要があるので、東京と大阪で重複しない範囲のCIDRを割り当てます。
ルーティング設定がシンプルになるように、以下のように決めました。

東京側のVCN CIDRブロック

10.0.0.0/16 ~ 10.127.0.0/16 を割り当てることとする。
(第二オクテットの先頭ビットが0)

大阪側のVCN CIDRブロック

10.128.0.0/16 ~ 10.255.0.0/16 を割り当てることとする。
(第二オクテットの先頭ビットが1)

DRGのVCN

上記と異なるアドレス帯を適当に。

構成

HUB用VCN

以下を、大阪と東京で2セット作ります
・DRG
 ・リモートピアリング接続
   東京と大阪それぞれで作成した後、「接続の確立」でピアリング
   (なぜか、東京側からやったら、なぜかap-osaka-1がプルダウンにでてこなかったので大阪側から実施した)
・VCN (作ったDRGをアタッチ)
 ・Local Peering GW (Spokeの数だけ)
 ・ルート表×2 (DRG割り当て用とLocal Peering GW割り当て用)

 - 東京側
  ルート表(DRG割り当て用)には、以下のエントリを登録
   10.0.0.0/16 → LPG -000- # 10.0.0.0/16のパケットをLPG -000-に転送
   10.1.0.0/16 → LPG -001- # 10.1.0.0/16のパケットをLPG -001-に転送

  ルート表(Local Peering GW割り当て用)には、以下のエントリを登録
   10.128.0.0/9 → DRG -Tokyo- # 10.128.0.0/9(大阪のCIDR)のパケットをDRG -Tokyo-に転送

 - 大阪側

  ルート表(DRG割り当て用)には、以下のエントリを登録
   10.128.0.0/16 → LPG -128- # 10.128.0.0/16のパケットをLPG -128-に転送
   10.129.0.0/16 → LPG -129- # 10.129.0.0/16のパケットをLPG -129-に転送

  ルート表(Local Peering GW割り当て用)には、以下のエントリを登録
   10.0.0.0/9 → DRG -Osaka- # 10.0.0.0/9(東京のCIDR)のパケットをDRG -Osaka-に転送

Spoke用VCN

Spoke用VCNごとに、以下のセットを作成します
・VCN
 ・Subnet
  - ルート表
   → 大阪側CIDR宛てのパケットをLocal Peering GWに転送する設定
  - セキュリティ・リスト
   → イングレス・エグレスに、大阪側CIDRとの通信許可設定
 ・Local Peering GW
  → 作成後、HubのLocal Peering GWとPeeringします。

結果

通信できました!!

[opc@tokyo2 ~]$ ping 10.129.2.2
PING 10.129.2.2 (10.129.2.2) 56(84) bytes of data.
64 bytes from 10.129.2.2: icmp_seq=1 ttl=62 time=7.86 ms
64 bytes from 10.129.2.2: icmp_seq=2 ttl=62 time=7.83 ms
64 bytes from 10.129.2.2: icmp_seq=3 ttl=62 time=7.83 ms
64 bytes from 10.129.2.2: icmp_seq=4 ttl=62 time=7.87 ms
64 bytes from 10.129.2.2: icmp_seq=5 ttl=62 time=7.84 ms
64 bytes from 10.129.2.2: icmp_seq=6 ttl=62 time=7.85 ms
64 bytes from 10.129.2.2: icmp_seq=7 ttl=62 time=7.85 ms
64 bytes from 10.129.2.2: icmp_seq=8 ttl=62 time=7.85 ms
NSO-KC
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした