経路優先順位の設定の例

• /32 接頭部と優先順位が 1 の経路、および宛先が /31 と優先順位が 0 の経路がある場合、 /32 が最初に使用されます (最長の接頭部一致)。 つまり、同じ接頭部を持つ経路が複数ある場合にのみ、優先順位が重要になります。
• 0.0.0.0/0 (デフォルト経路) を持つ経路が 3 つある場合は、最も高い優先順位を持つ経路のみが使用されます。 選択した経路が (例えば、自動化によって) 除去されると、残りの 2 つの経路から最も高い優先順位が選択されます。
• カスタム ルーティング テーブルに特定のプレフィックスを持つルートが 1 つだけある場合、そのルートは優先度に関係なく常に使用されます。 特定のプレフィックスごとに最適なルート選択が実行され、優先度が最も高いルートが選択されます。

等価コスト・マルチパス (ECMP) ルーティングは、2 つの経路の宛先と優先順位が同じ場合に使用されます (同じ宛先を持つ 2 つの経路に対して ECMP が使用される現在の動作を拡張します)。 1 つのルーティング・テーブル内の 2 つの経路は、最大で同じ宛先と優先順位を持つことができます。 例えば、カスタム・ルーティング・テーブルに同じ宛先を持つ 3 つの経路、優先順位 1 を持つ 1 つの経路、および優先順位 4 (ECMP) を持つ他の 2 つの経路がある場合、優先順位 1 を持つ経路が選択され、ECMP 経路は無視されます (ECMP なし)。 ここで、同じ宛先と優先順位を持つ 2 つの経路が最高の優先順位を持つ場合、システムはこれらの 2 つの経路を選択し、ECMP を実行します。 その後、これらの経路の 1 つが削除されると、まだ存在する経路が選択され、ECMP は実行されません。

経路優先順位の制限については、 制限とガイドライン を参照してください。

広告経路の考慮事項

ルートをアドバタイズするときは、次の点に注意してください。

• VPCに割り当てられたルートアドレスプレフィックスの外側にルートをアドバタイズできるので、外部ネットワークやVPCの外側にあるネットワークをVPCにアドバタイズすることができます。Direct LinkまたはTransit Gateway。

• 複数のトランジットゲートウェイまたはダイレクトリンクがVPCに接続されている場合は、個別にルートフィルタリングを使用できます。Transit GatewayまたはDirect Linkどのルートをどの接続にアドバタイズするかを微調整するための接続。

• 複数のルートが異なる優先度で宛先プレフィックスにアドバタイズされる場合、優先度の高いルート (優先度の値が小さい) がプライマリとして使用され、優先度の低いルート (優先度の値が大きい) がバックアップとして使用されます。

• 2つの異なるルートを宣伝する場合、例えば 172.16.0.0/31 を通して 10.1.1.0 そして 172.16.0.0/32 を通して 10.1.2.0、ルートは /32 プレフィックスは常にルートよりも優先されます /31 接頭辞。 これは、「最も長いプレフィックスの一致」ルール・セットと整合性があります。 ホストの宛先へのプレフィックスが長い方が、常に狭いプレフィックスよりも優先されます。

• 現在、 Transit Gateway または Direct Linkからの重複経路にフラグを立てるメカニズムはありません。 のTransit Gateway最も具体的なプレフィックスと最短の AS パスを使用して、最適なパスを選択します。 そうでなければ、Transit Gateway最初に受信したルートを選択します。 このルートはVPC側で最も古いルートではない可能性があり、Transit Gateway内部的に更新されます。

ユース・ケース 1: エッジ・プロキシー・ファイアウォール

ユース・ケース 2: パブリック・ロード・バランサー

ユース・ケース 3: VPN

VPN ゲートウェイを VPC ルーティング・テーブルのネクスト・ホップとして使用するために、ゲートウェイは専用サブネット内に作成されます。 このサブネットは VPN ゲートウェイにのみ使用され、経路 0.0.0.0/0 があり、ネクスト・ホップが VPN 接続である場合は、異なるルーティング・テーブルを持つ VPN ゲートウェイ・サブネットに関連付けられます。

以下に例を示します。

• サブネット A は、仮想サーバーをホストするために使用され、デフォルトのルーティング・テーブルに関連付けられます。 経路 0.0.0.0/0があり、ネクスト・ホップは VPN 接続です。
• サブネット B は、VPN ゲートウェイをホストするために使用され、新しいルーティング・テーブル (ルーティング・テーブル B) を作成します。 これは、サブネット B をルーティング・テーブル B に関連付けます。 デフォルトでは、ルーティング・テーブル B に経路は必要ありません。

上記のように、経路 0.0.0.0/0 があり、ネクスト・ホップが VPN 接続である場合にサブネット間の接続を確立するには、以下の代行経路を追加します。

destination CIDR==zone3 VPC prefix, action==delegate, location==zone1
destination CIDR==zone1 VPC prefix, action==delegate, location==zone3

一般的な制限

• 現時点では、1 つのカスタム・ルーティング・テーブルを着信トラフィック用 (関連付けの対象はトラフィック送信元) と発信トラフィック用 (関連付けの対象はサブネット) の両方として使用することはできません。 また、デフォルトのカスタム・ルーティング・テーブルに着信トラフィック送信元を関連付けることはできません。
• 現在、非対称ルーティングが原因でリターン・トラフィックが失敗する可能性があります。 この問題は、ECMP 静的経路に依存するすべてのサービスに影響します。 例えば、宛先が 10.134.39.64/26 で、ネクスト・ホップがそれぞれ 192.168.2.4 と 192.168.2.5 の 2 つの ECMP 経路を VPC A に作成するとします。 これらのネクスト・ホップは、NFV デバイスの IP アドレスです。 VPC 内のインスタンス A からトラフィックを送信すると、パケットは次のホップの 1 つにランダムにルーティングされ、反対側の ECMP ハッシュ アルゴリズムにより、戻りトラフィックが転送トラフィックと同じパスをたどるという保証はありません。 この現象は、 _非対称ルーティング_と呼ばれます。 非対称ルーティングが発生した場合、問題はルーティング自体にあるのではなく、セキュリティ グループはトラフィックを 1 つのパスでのみ認識するため、セキュリティ グループのルールでこのトラフィックが許可されていても、セキュリティ グループはトラフィックをドロップします。 一般的に、ECMP ルートの使用は避けることをお勧めします。
• カスタム経路でネクスト・ホップ IP アドレスに到達できるかどうかは、その経路が転送トラフィックに使用されるかどうかを決定する要因ではありません。 そのため、接頭部が同じ (ただしネクスト・ホップの IP アドレスが異なる) 複数の経路を使用すると、問題が発生する場合があります。到達不可のネクスト・ホップの IP アドレスに転送されたトラフィックが送達されない可能性があるからです。
• IBM Cloud VPC では、RFC-1918 および IANA に登録された IPv4 アドレス・スペースを VPC 内でプライベートに使用できます。ただし、IANA の特殊目的の範囲は例外で、IBM Cloud サービスに割り当てられた範囲を選択できます。 企業内、およびIBM Cloud Transit Gateway または IBM Cloud Direct Linkとともに VPC 内で IANA 登録範囲を使用する場合は、各ゾーンにカスタム経路をインストールする必要があります。 詳しくは、Routing considerations for IANA-registered IP assignments を参照してください。
• 同じ宛先に 2 つの異なるアドバタイズされたルートが存在する場合、次の制限が適用されます。
  • 両方のルートのネクストホップが同じゾーンにある場合、優先度の高いルート（つまり、priority ）がプライマリパスとして使用され、優先度の低いルート（つまり、priority ) がバックアップ パスとして使用されます。 両方の経路の優先順位が同じである場合は、ECMP を使用して、2 つの経路にわたってトラフィックを均等に経路指定します。
  • 両方の経路のネクスト・ホップが異なるゾーンにある場合、 Transit Gateway または Direct Link ルーターが最適な経路を選択します。 この場合、これは最も古い公示された経路です。

経路優先順位

同じ宛先 CID/ 接頭部を持つ複数の経路が存在する場合は、優先順位の値が最も高い経路が使用されます。 同じ宛先 CIDR/prefix および優先順位を持つ経路は、ECMP ルーティングを使用します。

出口経路

発信のカスタム経路については、宛先経路を追加するときにゾーンを選択する必要があります。 ただし、その同じゾーン内にネクスト・ホップがある必要はありません。 着信のカスタム経路については、ネクスト・ホップは同じゾーン内になければなりません。

等コスト・マルチパス (ECMP)

暗黙ルーターは、ECMP ルーティング (宛先は同じであるがネクスト・ホップ・アドレスが異なる複数の経路) を実行しますが、以下の制限があります。

• これは、アクションが deliverの経路にのみ適用されます。
• 宛先が同じ経路はゾーンごとに 2 つのみ許可されます。ただし、ネクスト・ホップのアドレスが異なっている必要があります。
• ECMP を使用する場合は、戻りのパスに同じパスが使用されない可能性があります。
• ECMP は、IP アドレスのネクスト・ホップ・タイプのみをサポートします。

Ingress 経路

• 現在、パブリック・イングレス・ルーティング（public internet トラフィックの選択）はコンソールでのみ利用可能です。 CLI と API が予定されています。
• 各 Ingress 送信元タイプは、VPC ごとに最大 1 つの Ingress ルーティング・テーブルに関連付けることができますが、VPC は複数の Ingress ルーティング・テーブルを持つことができ、各 Ingress ルーティング・テーブルには 1 つ以上の Ingress タイプを関連付けることができます。
• 特定のトラフィック送信元からの着信トラフィックは、そのトラフィック送信元に関連付けられているカスタム・ルーティング・テーブルの経路を使用して転送されます。
• Ingress トラフィック送信元に関連付けられていて、アクションが deliverであるカスタム・ルーティング・テーブル内のカスタム経路には、経路が追加されるアベイラビリティー・ゾーン内の VPC のアドレス接頭部の 1 つに含まれているネクスト・ホップ IP が必要です。 さらに、そのネクスト・ホップ IP は、経路のターゲットとなる VPC およびアベイラビリティー・ゾーンの仮想サーバー・インターフェースに構成されたものでなければなりません。
• 特定のトラフィック送信元からの着信トラフィックは、そのトラフィック送信元に関連付けられているカスタム・ルーティング・テーブルの経路を使用して転送されます。 対応する経路がカスタム・ルーティング・テーブルで見つからなければ、VPC のシステム・ルーティング・テーブルを使用してルーティングが続行されます。 この動作は、カスタム・ルーティング・テーブルのデフォルト経路にドロップのアクションを指定することで回避できます。
• 宛先 IP (FIP) を持つカスタム経路を含む Ingress カスタム・ルーティング・テーブルは、FIP が関連付けられている仮想サーバー・インスタンスと同じゾーンに定義する必要があります。
• IBM Cloud VPNゲートウェイにバインドされているフローティング IP は、パブリック・インターネット route_internet_ingress ソース・タイプが有効な場合、イングレス・ルーティング・テーブルのカスタム・ルートの宛先として使用できません。

固有の接頭部の長さ

カスタム・ルーティング・テーブルごとに、接頭部の長さとして最大 14 個の固有の長さを使用できます。 同じ接頭部を持つ複数の経路を、1 つの固有の接頭部としてのみカウントすることができます。 例えば、接頭部が /28 である経路が複数あるとします。 これは固有の接頭部としては 1 つとカウントされます。

VPN

• スタティックなルートベースVPN接続のルートを作成する場合、ネクストホップのVPN接続IDを入力する必要があります。 VPN ゲートウェイは、ルーティング・テーブルが関連付けられているサブネットと同じゾーン内になければなりません。 ルーティング・テーブルに関連付けられているサブネットとは異なるゾーンで、VPN ゲートウェイをネクスト・ホップとして定義することは推奨されません。
• ネクスト・ホップとして VPN 接続を使用する経路は、VPN 接続がアクティブな場合にのみ有効になります。 VPN 接続がダウンしている場合、ルーティング・ルックアップ中にこの経路はスキップされます。
• ネクスト・ホップに VPN 接続を関連付けたカスタム経路が含まれているカスタム・ルーティング・テーブルに、着信トラフィック送信元を関連付けることはできません。
• カスタム経路は、経路ベースの VPN でのみサポートされます。 ポリシー・ベース VPN を使用している場合、経路は、デフォルトのルーティング・テーブル内の VPN サービスによって自動的に作成されます。