初めまして！
k.katoです。
先日、OCI Networking Professionalに合格することができました(ﾟ∀ﾟﾉﾉ"☆ﾊﾟﾁﾊﾟﾁ
OCI Networking Professionalでは、転送ルーティングという概念が登場します。
あるVCNを経由して、別のVCNへ…っていうやつですね。
これは、デフォルトで備わっているDRGルート表ではルーティングできません。
そのためには、ルート・ディストリビューションのインポートを行い、それで作成したDRGルート表をアタッチメントに紐づける…そんな作業が必要になります。
これについて理解していきたいと思います。
※注意
本記事はあくまで個人の検証に基づく内容です。
詳細情報については、以下のドキュメントをご参照ください。
より詳細に知りたい方には、こちらの記事もおすすめです。
目次
DRGルート表とは
DRGルート表とは、DRGに進入するパケットを、どのアタッチメントに送るかを決めるためのルート表です。
各DRGアタッチメントに1つのDRGルート表を関連付けて、その表の中のルートに従って次のアタッチメントを決める、そういう仕組みになっています。
ルートの決め方
ここで重要なのが、そのDRGルート表の「次のルート」の決め方です。
それは2通りあります。
1. ルート・ディストリビューション
ルートディストリビューションは、「どのアタッチメントから受信したルートを、DRGルート表に取り込むか」を決めるポリシーです。
このポリシーに従って、自動的に接続されたアタッチメントからルート情報をインポートすることが可能です。
後ほど詳しく見ますが、デフォルトでは以下2点の自動生成のルートディストリビューションが生成されます。
・Autogenerated Import Route Distribution for VCN Routes・・・
IPSecトンネルアタッチメント、仮想回線アタッチメント、 RPCアタッチメント用のDRGルート表に対して、デフォルトでアタッチされるルート・ディストリビューションです。
アタッチメントタイプがVCNアタッチメントからのルートをインポートする設定になっています。
・Autogenerated Import Route Distribution for ALL routes・・・
VCNアタッチメント用のDRGルート表に対して、デフォルトでアタッチされるルート・ディストリビューションです。
全てのアタッチメントタイプから、ルートをインポートする設定になっています。
2. 静的ルート・ルール
こちらはDRGルート表のルート・ルールを手動で設定する方法です。
どの宛先CIDRに対して、どのアタッチメントに誘導するのかを細かく設定することが可能です。
静的ルート・ルールと、動的ルート・ルール（ルートディストリビューションによるルート・ルール）が混在する場合は、静的ルート・ルールの方が優先されます。
DRGルート表の使われ方を見てみよう。
先ほど、DRGルート表の定義について、このように説明しました。
DRGルート表とは、DRGに進入するパケットを、どのアタッチメントに送るかを決めるためのルート表です。
では実際にどのようにルーティングされて、目的地まで届いているのか見てみましょう！
やりたいこと
ここでは、東京リージョンのTokyo-VCNから、大阪リージョンのOsaka-VCNへ行くまでの経路を追っていきます。全体像を載せておきます。
実際に見ていきましょう
まず、Tokyo-VCNにいるパケットは、サブネットに紐づいたルート表によってDRGに誘導されますね。
パケットは、VCNアタッチメントに到着しました。
ここで、次にパケットはどこに行けばいいかを確認するために、VCNアタッチメントに紐づいているDRGルート表を確認します。
ここでパケットは、Osaka-VCNに行くためには、RPCアタッチメントから出ればいいとわかるんですね。
続いて、大阪側のDRGの PRCアタッチメント に到着したパケットは、RPCアタッチメントに紐づいているDRGルート表を確認します。
DRGルート表には、「大阪VCNに行くためにはVCNアタッチメントに行け」と書いてありますね。
なので、あとはVCNアタッチメントを抜けて、大阪VCNに到着です！！
これで行きのルーティングは理解できましたね！
帰りのパケットは入るアタッチメントが逆になりますが、同様です。
重要なのは、DRGの入り口となるアタッチメントに紐づいているDRGルート表によって、次の出口が決まっているということです！
「アタッチメントの入り口で次のルートを見る」
それを覚えておけば、頭がこんがらがることも少なくなりますし、複雑な構成図を確認する際も、目で追いやすくなりますね！
（私は出口となるアタッチメントでもDRGルート表を見るものだと思っていました…。）
ルート・ディストリビューションのインポートとは
「ルート・ディストリビューションのインポート」とは、外から入ってきたルート情報をDRGの中にどう取り込むか、というルールのことです。
と言われても、この時点で当時の私はよくわからなかったので、詳しく解説していきます！
先ほどの画像に戻りましょう。
VCNアタッチメントに到着したパケットが次に向かいたいのはOsaka-VCN、つまり次の経由地点である、東京DRG側のRPCアタッチメントに向かわせたいですよね。
先ほども確認した通り、パケットはアタッチメントに入ってきた時にDRGルート表を確認します。
それならば、DRGルート表に「RPCアタッチメントに行けば、Osaka-VCNに行けるよ」っていう情報を書き込んであげれば、パケットは正しく導かれると思いませんか？
この「こっち(RPC-atch)が大阪行きだよ」と書いてあるのが、「ルート・ディストリビューションのインポート」によって得られたルート情報です。
このルート情報をDRGルート表に関連づけることで、パケットはRPCアタッチメントに向かえば良いとわかるようになります。
今はRPCから大阪までのルートを例に出しましたが、例えば、
- 仮想回線アタッチメントからオンプレミスへのルート
- IPSec接続アタッチメントからオンプレミスへのルート
- VCNアタッチメントからVCNへのルート
を教えてあげたいこともあるかもしれません。
または、そのすべてのルートを教えてあげたいかもしれません。
「どのアタッチメントからのルートを取り込むのか」を決めるルール・フィルタを「ルート・ディストリビューションのインポート」によって決めることができます。
デフォルトのDRGルート表はどんな設定になっているのか見てみよう
ここでは、実際のDRGルート表がどんな設定になっているのかを知りましょう。
でないと、どんな場面でデフォルト以外のカスタム設定を作れば良いかわかりませんからね。
Autogenerated Import Route Distribution for ALL Routes
一致タイプが「すべてに一致」により、「全アタッチメントタイプからのルート」をインポートしています。
これは、VCNアタッチメント用のDRGルート表に紐づくものです。
VCNアタッチメントからは、すべてのアタッチメントへ（VCN/IPSec/VC/RPCアタッチメント）ルーティングされるというのがデフォルトなんです！
VCNから、VCNアタッチメントに入ってきたパケットは、宛先に応じて、下の図のようなルートへデフォルトで行けます。
もちろん、まだ作成していないアタッチメントの情報は取り込まれません。
「ルートディストリビューションのインポート」を紐付けてできたDRGルート表は、アタッチメントを作成すると、そのアタッチメント先にあるルート情報を「動的に」取り込み、DRGルート表が更新されます。
手動で新しく追加したアタッチメントへのルーティングを設定しなくても、勝手にDRGルート表が更新されているのはありがたいですね！
これによって、「Autogenerated Drg Route Table for VCN attachments」というDRGルート表が作成されます。
実際のアタッチメントを見てみましょう。
これはデフォルトでVCNアタッチメントへ紐づきます。
Autogenerated Import Route Distribution for VCN Routes
こちらは、一致タイプが「アタッチメント・タイプ」、一致条件が「仮想クラウドネットワーク」を指定しています。
つまり、「VCNアタッチメントからのルートのみ」をインポートしています。
これが関連づけられたDRGルート表は、IPSec、仮想回線、RPCアタッチメントに自動的に紐づきます。
なので、例えば、オンプレからIPSecアタッチメントに入ってきたパケットが次にルーティングされるのは、デフォルトで「VCNアタッチメントのみ」ということです。
下の画像のようにルーティングされます。
このルート・ディストリビューションで作成されるのが、「Autogenerated Drg Route Table for RPC, VC, and IPSec attachments」というDRGルート表です。
例えば、RPCの設定を見てみると、紐づいていることがわかりますね。
これも先ほどと同様に、VCNアタッチメントが作成されれば、「動的に」ルートが取り込まれます。
これによって、RPC/IPSec/仮想回線アタッチメントからVCNアタッチメントへデフォルトでルーティングされます。
カスタマイズする上での考え方の例
先ほど、東京VCNから大阪VCNへリモートピアリング接続する例を出しました。
しかし、PRC間の接続を確立して、通信を確かめたことがある方ならわかると思いますが、DRGルート表をいじらずとも、サブネットのルート表と、セキュリティリストを設定するだけで、通信が通ります。
なので、先ほどの例であれば、デフォルトの自動生成ルート表を使うだけで通信が通るんですね！
では、ルートディストリビューションをカスタマイズする必要のある具体的な場面について、どのようにカスタマイズするのか見てみましょう！
様々な構成があるので、今回は一つの例だけご紹介して終わりたいと思います。
例：リモート・オンランプ
この図を見てみると、オンプレミスからVCN１との接続が確立されており、VCN同士はリモートピアリングによって接続されていますね。
このように、オンプレミスから単一の回線を通じて、2つのVCNにアクセスできるようにする構成のことを、「リモートオンランプ」と言います。
では、この構成において、デフォルトの設定でオンプレミス→ VCN1→ VCN2へルーティングされるでしょうか？
もちろんこの流れなので、答えはNOです。
IPSecアタッチメント（もしくは仮想回線）に届いたパケットは、RPCアタッチメントにデフォルトでルーティングされそうな気がしますよね。でも、されません。
なぜこれがデフォルトでルーティングされないのでしょうか？
理由は単純なのですが、「RPC/IPSec/仮想回線アタッチメントからは、デフォルトでVCNアタッチメントにしか、ルーティングされない」からです。
先ほど、「Autogenerated Import Route Distribution for VCN Routes」で、そういう設定であることは確認しましたね！
なので、VCN01側のDRGでは、以下のように設定する必要があります。
行きの通信
RPCアタッチメントからインポートしたルートディストリビューションをIPsec（or仮想回線）アタッチメントのDRGルート表に紐付ける。
帰りの通信
IPSec（or仮想回線）アタッチメントからインポートしたルートディストリビューションをRPCアタッチメントのDRGルート表に紐づける。
この作業が必要なんです！
終わりに
長い記事でしたが、ここまで読んでいただき、ありがとうございました。
私がリモート・オンランプという構成を知り、ルート・ディストリビューションという概念の理解に苦しんだのは、OCI Architect Professional 2025のデモ問題に取り組んだことがきっかけです。
Professional自体はここら辺を試験で聞いてくることはあまりないと思いますが、Networking Professionalではしっかり理解しておかなければなりません。
もしこの記事のおかげで理解できるようになったという方がいれば幸いです！