IBM Cloud Transit Gateway の計画

IBM Cloud® Transit Gateway を注文する前に、以下の考慮事項についてご確認ください。

一般的な考慮事項

VPCのすべてのプレフィックスと、クラシックネットワークのすべてのサブネットはTransit Gatewayに接続されるため、これらが重複しないようにすることが重要です。 中継ゲートウェイに接続する予定の VPC を作成するときには、重複していない VPC 接頭部を使用して VPC を作成してください。

  • IBM Cloud Transit Gateway は、IBM Cloud Transit Gateway のロケーションにリストされているリージョンにおける中継ゲートウェイのプロビジョニングをサポートしています。
  • 中継ゲートウェイは、ワークロードにとって合理的なロケーションに作成してください。 例えば、us-south (ダラス) 地域の 2 つの VPC と eu-de (フランクフルト) 地域の 1 つの VPC を接続する場合は、us-south 地域にゲートウェイを作成することが、ワークロードにとって最も効率的です。
  • Classic Access VPC をTransit Gatewayに直接接続することはできません。 クラシック・リソースを接続するには、IBM Cloud クラシック・インフラストラクチャー接続を使用します。そうすると、クラシック・アクセス VPC 内のすべてのリソースが自動的に接続されます。
  • 中継ゲートウェイは、ネットワーク・トラフィックが中継ゲートウェイを通過する前に、少なくとも 2 つの接続を必要とします。 45 日以上接続が 2 つ未満の中継ゲートウェイは、再利用されます (中断され、30 日後に削除されます)。
  • VPC、 Direct Link、またはクラシック・インフラストラクチャー、複数のローカルゲートウェイと1つのグローバルゲートウェイに接続することができます。
  • 中継ゲートウェイとその接続は、プロビジョニング後に使用可能になるまで数分かかることがあります。
  • 中継ゲートウェイの接続に名前を指定する場合は、説明的な名前にしてください。 複数のアカウントにまたがるリソースに接続する場合、接続名を指定する必要があります。 中継ゲートウェイと同じアカウントにあるリソースに接続する場合、VPC 名または「クラシック」という語がデフォルトで選択され、変更ができます。
  • IBM Cloud Transit Gateway は、ソフトウェアの単一インスタンスとそのサポート・インフラストラクチャーが複数のお客様にサービスを提供する、マルチテナント・アプリケーションです。 そのため、帯域幅の使用状況をモニターすることが重要になります。 使用する帯域幅が多すぎると、中継ゲートウェイ・インスタンスが中断される可能性があります。 これが原因であると思われる場合は、中継ゲートウェイ・インスタンスの接続状況を調べて、Suspended 状態になっているかどうかを確認してください。 その状態である場合は、サポート窓口によって復元されます。
  • 以下の ASN は、 Transit Gateway Generic Routing Encapsulation (GRE) 接続および Direct Link 接続でブロックされます。 これらの ASN は、AS パス内の公示された経路に組み込まれないように、アプライアンスでは使用しないでください。 これらの ASN が組み込まれていると、ネットワークが正しく機能しなくなります。

0, 13884, 36351, 64512, 64513, 65100, 65200-65234, 65402-65433, 65500, 65516, 65519, 65521, 65531 および 4201065000-4201065999

ECMPの考慮事項

  • ECMP(Equal-Cost Multi-Path)を計画する際は、スループットが直接リンクの数に比例して増加するわけではないことに留意してください。 たとえば、ECMP対応Transit Gatewayに2本の10 GBのダイレクトリンクを接続した場合、スループットは20 GBにはなりません。10 GB以上、20 GB未満のスループットとなります。 これは、ECMPがストリーム単位または送信元単位で機能するためです。つまり、トラフィックが単一のエンドポイントから送信される場合、両方のリンクではなく、どちらか一方のリンクが優先される可能性が高いということです。 よりバランスのとれたスループットを実現するには、複数の送信元からトラフィックを送信することをお勧めします。これにより、利用可能なダイレクトリンク全体に負荷がより均等に分散されるためです。

  • 制限:ECMPは単一ルーター上の直接リンクでは機能しない。 その代わり、ダイレクトリンクを持つ複数のルーター間で、それらのルーターが同じプレフィックスをアドバタイズしている限り、サポートされる。

  • 既知の制限:新しいトランジットゲートウェイは4ウェイECMPをサポートするが、既存のゲートウェイは サポートケースを開けない 限り、この機能を使用できない。

    トランジットゲートウェイでECMP機能を有効にしたくない場合は、サポートケースを開いて拒否リストに追加し、ゲートウェイでこの機能を無効にすることができます。

価格設定の考慮事項

Transit Gateway プロビジョニングページにある IBM Cloud コスト見積もりは、ネットワーク接続タイプを解釈できません。 信頼性の高いコスト見積もりを取得するには、推定のトランジットゲートウェイ数と接続数を入力してください。 冗長 GRE を作成する場合、各トンネルは、 接続制限 に対してカウントされる個々の接続であることに注意してください。

クラシック・インフラストラクチャー接続に関する考慮事項

  • 中継ゲートウェイを使用して VPC を IBM Cloud クラシック・インフラストラクチャーに接続する場合、VRF (Virtual Routing and Forwarding) のクラシック・アカウントを有効にし、それを IBM Cloud アカウントにリンクする必要があります。 アカウントの VRF を有効にする方法については、VRF およびサービス・エンドポイントの有効化を参照してください。

  • VPC とクラシック・インフラストラクチャーを中継ゲートウェイに接続すると、10.0.0.0/8 スペースの IP アドレスを使用する、VPC 内のすべての接頭部がクラシック・インフラストラクチャー VRF に表示されます。 クラシック・インフラストラクチャーとの接続を確実に成功させるため、VPCでは、 10.0.0.0/1410.200.0.0/1410.198.0.0/15、および 10.254.0.0/16 の各ブロックと重複するプレフィックスを使用しないでください。 また、クラシック・インフラストラクチャーのサブネットに含まれるアドレスも使用しないでください。 クラシック・インフラストラクチャーのサブネットのリストを表示するには、すべてのサブネットの表示を参照してください。

  • Classic 仮想サーバー・インスタンスには、プライベート (eth0) とパブリック (eth1) の両方のネットワーク・インターフェースがある可能性があります。 現在、これらのインターフェースのルーティング・テーブルには、デフォルト・ゲートウェイとしてパブリック・インターフェース (eth1) が指定されます。プライベート・インターフェースを介して他の VPC のサブネットをルーティングするには、ルーティング・エントリーを追加する必要がある場合があります。

  • 中継ゲートウェイのロケーションやルーティング・タイプの指定にかかわらず、この接続を使用して、すべての MZR のすべての IBM Cloud クラシック・インフラストラクチャー・ネットワークにアクセスできます。

  • これらの データ・センターにあるクラシック・インフラストラクチャー・リソースは、中継ゲートウェイを経由して VPC リソースに接続します。

  • クラシック・インフラストラクチャー Transit Gateway接続される場合、 アカウントアタッチされているすべての Classic Access VPC も含まれます。これは、これらの VPC のサブネットが、 クラシック・インフラストラクチャー VRF に関連付けられているためです。 中継ゲートウェイをクラシック・アクセス VPC に接続するための唯一の方法は、クラシック・インフラストラクチャー全体を (特定のクラシック・アクセス VPC ではなく) 中継ゲートウェイに接続することです。

  • 同じデータ・センターにあるクラシック接続は、中継ゲートウェイとは異なる地域にある場合、相互に通信できません。

プレフィックス・フィルタリングの考慮点

  • プレフィックスフィルターは、レガシーGREトンネル接続を除くすべての Transit Gateway 接続タイプに対応しています。 GRE接続の場合、プレフィックスフィルタリングは冗長GRE接続と非結合GRE接続の両方のタイプでサポートされます。
  • 非 GRE 接続の場合、ネットワークオーナーはプレフィックスフィルタを追加できる。 GRE接続では、 Transit Gateway の所有者だけがプレフィックスフィルタを追加または変更できる。
  • アカウント間接続の場合、それぞれの接続のアカウント所有者のみが接頭部フィルターを変更できます。 他のアカウント接続内容を確認できますが、フィルタを変更することはできません。
  • 別のアカウントからの受信プレフィックスをフィルタリングすることはできません。
  • 冗長GREおよびVPNゲートウェイ接続では、プレフィックスフィルターは最上位接続でのみ設定できます。 トップレベルで適用されるフィルターは、関連するすべてのトンネルに適用されます。
  • リスト内の接頭部フィルターは、順次処理されます。 この順序はいつでも変更できます。
  • 接続範囲のオプションとして「 別のアカウントのネットワークへの接続をリクエストする 」を選択した場合、その接続のネットワーク所有者ではないため、プレフィックスフィルタを設定することはできません。 プレフィックスフィルターは、ネットワークを所有するアカウント設定する必要があります。 GRE接続の場合、接続の作成時にプレフィックスフィルタを設定できるのは Transit Gateway のオーナーだけです。
  • 接頭部フィルター・サブネット・マスクは固有です。 たとえば、 10.10.20.0/24 と定義されたルールは、 10.10.20.0/28 といったサブネットや、その他のどのサブネットプレフィックスとも一致しません。
  • 中継ゲートウェイの接頭部サービスの制限を確認します。

Generic Routing Encapsulation (GRE) 接続に関する考慮事項

特定の GRE 接続に関する以下の考慮事項を確認してください。

GRE 接続に関する一般的な考慮事項

  • GRE トンネルを構成するときは、トンネルを作成するアベイラビリティー・ゾーンを指定する必要があります。 そのため、何らかの理由でそのゾーンを使用できなくなると、そのゾーンの GRE トンネルを介して接続されているネットワークに到達できなくなります。 GRE トンネルを高可用構成にするには、GRE トンネルを複数のゾーンに作成して、同じエンドポイントを接続する必要があります。
  • GRE 接続では、GRE トンネル IP アドレス間で BGP サービスを使用する必要があります。 中継ゲートウェイは、他のトンネル・エンドポイントに接続する前に、トンネル接続で BGP サービスを構成します。 その後、BGP プロトコルが、接続されたエンドポイントと中継ゲートウェイの間で経路を交換すると、GRE トンネルは、経路指定されたトラフィックのデータ・パスになります。
  • GREトンネルの経路情報は、トンネルを介して確立されたBGPセッション上で直接学習されます。 このため、これらの接続では接頭部フィルターは使用できません。
  • 中継ゲートウェイに接続される GRE トンネルの数は制限されています。 デフォルトの割り当て量は 12 です。
  • GREと Direct Link (同じパス長)の間で等コストパスを使用している場合、GREと Direct Link の間で負荷分散を行うのではなく、 Direct Link を優先します。

GRE拡張ルート伝播に関する考慮事項

GRE enhanced route propagationは、同じトランジットゲートウェイに接続されているGREトンネルが、ゾーンをまたいで、または冗長GRE(RGRE)ペア内で、互いにルートを学習できるかどうかを制御します。

トランジットゲートウェイを作成または更新するときは、GREトンネルがルートを共有できるかどうかを評価する。 GRE enhanced route propagation トグルを有効にすると、同じトランジットゲートウェイ上のGRE間の相互接続が可能になり、冗長トンネル設定の必要性を減らすことができます。 トポロジーによっては、この設定によって、ルートがどのように伝搬され、どのようにトラフィックが流れるかについて、意味のある変化をもたらすことがある。

このトグルを有効または無効にすると、ルート伝搬が即座に変更されることがある。 本番環境で変更を行う前に、その影響を理解しておいてください。

トグルが無効の場合:

  • 同じRGRE内のGREトンネルはお互いにルートを学習しない。
  • 異なるトランジット・ゲートウェイ・ゾーンに着地するアンバインドGREトンネルは、互いにルートを学習しない。
  • 同じゾーン内のGREトンネルは、依然として互いにルートを学習する。

このコンフィギュレーションはGREトンネル間のルート伝搬を制限するが、厳密なネットワーク分離や強制的な分離を保証するものではない。

トグルが有効になっている場合:

  • RGREペア内のGREトンネルは、同じゾーン内であっても、互いにルートを学習する。
  • 異なるトランジットゲートウェイゾーンの未バインドGREも互いにルートを学習し、ゾーン間のルート伝播を可能にする。

このコンフィギュレーションにより、GREはゾーンを越えて、または同じRGRE内で、他のGREからルートを学習することができ、ルートがどのように伝搬され、トラフィックがどのようにネットワークを流れるかを変えることができます。

冗長 GRE に関する考慮事項

  • 冗長 GRE は、基本的に、少なくとも 2 つの GRE トンネルをグループ化したものです。

  • トンネルの数は、1ゾーンにつき2トンネルを超えてはならない。

  • トンネルは、同じゾーンまたは異なるゾーンの冗長 GRE 内に配置できます。

  • 中継ゲートウェイ上のすべての接続およびトンネルには、固有の名前が必要です。

  • 冗長 GRE 内のすべてのトンネルは、同じネットワークおよびアカウントをターゲットとします。

  • VPC ベース・ネットワーク・タイプを使用する場合:

    • VPC ネットワーク・タイプの IP スプーフィング・フラグを有効にする必要があります。 IP スプーフィング・チェックの有効化については、 IP スプーフィングについて を参照してください。
    • 仮想サーバー・インターフェース・プロファイルは v2でなければなりません。
    • ローカル・ゲートウェイ IP:
      • RFC 1918 に準拠している必要があります (そうでない場合は、VPC 上に浮動 IP またはパブリック・ゲートウェイがありません)。
      • マルチキャスト範囲( 224.0.0.0239.255.255.255 )内のIPアドレスであってはならず、トランジットゲートウェイに接続されている既存のネットワークと競合してはならない。
      • 同じアンダーレイネットワークを使用する別のGREの local-gateway-ip として使用することはできない。
  • GREによる拡張ルート伝搬:

    • 無効(デフォルト)の場合、冗長GRE内のすべてのトンネルは互いにルートが伝搬されず、互いに通信できない。 しかし、冗長GREトンネルは、同じトランジットゲートウェイに接続され、同じゾーンにある冗長GRE外のGREトンネルにルートを伝搬させることができる。

    • 有効にすると、すべてのGREトンネルは、同じトランジットゲートウェイに接続されている場合、そのルートを他のGREに伝播する。

バインドされていない GRE トンネルに関する考慮事項

  • クラシック経路は、アンバインドされた GRE トンネルを介して公示されます。
  • 同じアベイラビリティー・ゾーン内の同じ中継ゲートウェイに接続された、バインドされていない他の GRE トンネルを介して通信できます。
  • 異なるアベイラビリティゾーンにある同じトランジットゲートウェイ上の非バインドGREトンネルは、GRE拡張ルート伝搬が有効になっていない限り、通信できません。 しかし、GREの拡張ルート伝搬を無効にすることで、ネットワークの分離を行うことはできません。なぜなら、バインドされていないGREのクロスゾーントラフィックが存在しないからです。

ネットワーク分離が必要な場合は、別個の中継ゲートウェイを使用することを検討してください。

  • Transit Gateway でクラシック接続を必要としません。 従来のネットワークサブネットは、 Transit Gateway上の接続に対してアドバタイズされません(その逆も同様です)。
  • バインドされていない GRE トンネルによってターゲットにできる固有ベース・ネットワークのデフォルト数は 5 に制限されています。 これらのサービス制限の拡大が必要な場合は、 IBM サポートに 問い合わせることができます。

詳細および使用例については、「 高可用性 GRE トンネルを使用したネットワークの接続 」を参照してください。

レガシー GRE に関する考慮事項

  • クラシックルートは、レガシーGREトンネルを介して広告されません。
  • 同じトランジットゲートウェイ上の他のGREトンネルを経由して通信することはできない。
  • 作成する前に、中継ゲートウェイでのクラシック接続が必要です。 その結果、すべてのクラシック・サブネットが、中継ゲートウェイに接続されているすべての接続、およびクラシック・ネットワーク上の他のすべての接続のサブネットに通知されます。

Direct Link 接続に関する考慮事項

オンプレミス・ネットワークから IBM Cloud の他のネットワークに接続するために、中継ゲートウェイへの Direct Link 接続を作成することができます。 直接リンクで中継ゲートウェイに接続すると、オンプレミス・ネットワークから他のすべての中継ゲートウェイ接続にアクセスできるようになります。 同様に、中継ゲートウェイに接続されている他のすべてのネットワークも、オンプレミス・ネットワークにアクセスすることができます。 Direct Link 接続は、標準的な Direct Link オファリングと同じ物理相互接続または仮想相互接続のプロセスに従います。 中継ゲートウェイからその接続を削除した後は、中継ゲートウェイは直接リンクに接続されたことがなかった場合のように動作します。

中継ゲートウェイ接続のネットワーク・サブネットに関する考慮事項が、同じく Direct Link 接続にも適用されます。 接続を確実に成功させるため、 Direct Link で接続するネットワークでは、他の接続と重複するプレフィックスを使用しないでください。

Power Virtual Server 接続の考慮事項

Power Virtual Server インスタンスを中継ゲートウェイに接続できます。 これにより、 Power Virtual Server をダウンストリーム中継ゲートウェイに直接接続できます。 Power Virtual Server をTransit Gatewayに接続すると、 Power Virtual Server サービスインスタンスは、下流にあるすべてのTransit Gatewayリソースおよびサービスにアクセスできるようになります。 同様に、 Transit Gatewayに接続されているすべての下流ネットワークは、 Power Virtual Server インスタンスにアクセスできます。

Power Virtual Server 接続では、ローカル・ルーティングまたはグローバル・ルーティングを使用できます。 ただし、中継ゲートウェイと同じ地域の Power Virtual Server インスタンスのみがローカル・ルーティングを使用できます。 また、 Power Virtual Server インスタンスは、ローカル・ルーティングを使用して複数の中継ゲートウェイに接続できますが、グローバル・ルーティングを使用する中継ゲートウェイは 1 つのみです。 ダウンストリーム・サービスは、中継ゲートウェイ・タイプに基づいて経路設定を受け入れます。

Transit Gatewayに関するネットワークサブネットの考慮事項は、 Power Virtual Server 接続にも同様に適用されます。 接続を確実に成功させるために、 Power Virtual Server インスタンスで他の接続と重複するプレフィックスを使用しないでください。 なお、 Transit Gateway では、プレフィックスフィルタリングにより、公開するプレフィックスを制限することができる。また、ルーティングテーブルレポートにより、接続の作成後にオーバーラップを確認することもできる。

VPNゲートウェイ接続に関する考慮事項

Transit Gateway VPN ゲートウェイ接続を作成することで、オンプレミスまたは外部ネッ トワークが IBM Cloud 内の他のネットワークと接続できるようになります。 VPNゲートウェイは、 Transit Gateway内のスポークとして機能し、トンネルの複雑さを軽減しながら、複数のネットワーク間での効率的なピアリングを可能にします。 この設計では、冗長GREトンネル上で eBGP、ダイナミック・ルーティングを使用し、スケーラブルで回復力のある接続性を提供します。

  • 各VPNゲートウェイ接続は、VPNゲートウェイとTransit Gateway間に4つの冗長GREトンネルを自動的に用意する。 IBM はこれらのトンネルを管理し、 eBGP セッションがその上でダイナミック・ルーティングを実行する。 オンプレミス接続では、 eBGP over IPsecトンネルを使用してセキュアな通信を行う。 VPNゲートウェイ接続の作成、削除、名前の変更はできますが、個々のGREトンネルを変更または削除することはできません。

  • 料金は、1接続あたり4つのGREトンネルとデータトラフィックの料金に基づいています。

  • VPNゲートウェイの接続は、デフォルトではTransit Gatewayごとに4つ、ゾーンごとに2つに制限されている。

  • VPNゲートウェイ接続はプレフィックスフィルタリングをサポートしていません。 BGPセッションの自分側でルートフィルタリングを管理する責任があります。

  • いつでも動的または静的なVPN接続を作成できます。 静的接続は、 Transit Gatewayアタッチメントの有無にかかわらず機能する。 ダイナミック接続では、トラフィックを流す前にVPNゲートウェイをTransit Gateway接続する必要がある。

  • VPNゲートウェイがTransit Gatewayアタッチされた後、ローカルASNを変更することはできない。

  • VPNを Direct Link 接続のバックアップとして設定するには、 Direct Link からのルートが優先されるようにする必要があります。 そのためには、オンプレミス・デバイスのASパスのプリペンディングやMED(マルチエグジット・ディストリミネーター)などのメカニズムを活用することができる。

  • VPNゲートウェイ接続を作成する際、GREトンネルIPアドレスのCIDRブロックを定義する必要があります。 Delegate-VPC ルートを追加する必要がないため、 RFC1918 プライベートアドレス範囲を使用することを推奨する。 CIDRブロックは最低でも /27 、 Transit Gateway設定された他の接続CIDRと重複してはならない。

    VPN ゲートウェイに、標準のプライベート IP 範囲 (10.0.0.0/8, 172.16.0.0/12, または 192.168.0.0/16) の外側にある CIDR を割り当てる場合は、適切なトラフィックフローを有効にするために、VPC ルーティングテーブル (VPN ゲートウェイと同じゾーン) にルートを手動で追加する必要があります。 次の 2 つのオプションがあります。

    • 宛先をVPNに割り当てられた完全なCIDR(たとえば、 100.31.128.0/18)に設定し、アクションを Delegate-VPCに設定した単一のルートを追加します。
    • 各VPNトンネルのローカルゲートウェイIP(例えば、 100.31.128.1/32 )をターゲットとし、アクションを Delegate-VPCに設定した4つの別々のルートを追加する。

    最初のオプションはよりシンプルだが、2番目のオプションはよりきめ細かなルーティング制御を提供し、高度なネットワーク設計やトラブルシューティングに好まれるかもしれない。

VPC に関する考慮事項

  • IBM Cloud VPC では、 RFC-1918 およびIANAに登録された IPv4 アドレス空間を、VPC内でプライベートに利用できます。ただし、IANAの特殊用途範囲や、 IBM Cloud サービスに割り当てられた特定の範囲については、一部の例外があります。 エンタープライズ内で IANA 登録済みの範囲を、IBM Cloud Transit Gateway と連動させて VPC 内で使用する場合、ゾーンごとにカスタム経路をインストールする必要があります。 詳しくは、Routing considerations for IANA-registered IP assignments を参照してください。

  • 単一の中継ゲートウェイまたは複数の中継ゲートウェイを作成して、複数の IBM Cloud VPC を相互接続することができます。 IBM Cloud クラシック・インフラストラクチャーを中継ゲートウェイに接続して、クラシック・インフラストラクチャー・リソースとのシームレスな通信を実現することもできます。 詳しくは、VPC の相互接続を参照してください。

  • VPC のベア・メタルはサポートされていません。

ルーティングに関する考慮事項

  • 1 つの中継ゲートウェイの接続はすべて相互に接続されるので、ローカルとグローバルのどちらのルーティングが各ゲートウェイに適しているか判断する前に、相互接続するすべてのリソースについて慎重に検討してください。

    どのルーティング・オプションのトラフィックもプライベート IBM Cloud ネットワークの外に出ることはなく、パフォーマンスのために最適化されます。

  • ゲートウェイを使用して同じマルチゾーン・リージョン (MZR) 内の VPC 同士を接続する予定の場合は、同じ MZR (us-south (ダラス) など) にあるアクセス可能なリソースをすべて接続できる、ローカル・ルーティングを使用してください。

    ローカル・ルーティング
    ローカル・ルーティングの
    *

  • 中継ゲートウェイを使用してローカルな VPC に接続したり、異なる MZR 間で接続したりする予定の場合は、同じ MZR にある VPC にはローカル・ゲートウェイを使用し、MZR をまたがる VPC についてはグローバル・ゲートウェイを使用します。 高可用性 (HA) シナリオの例も使用できます。 VPC A と VPC B にあるすべてのデータは、VPC C と VPC D に複製できます。 米国南部リージョンで問題が発生した場合、接続は米国東部にルーティングされます。

    グローバル・ルーティング
    *ローカル・ルーティングとグローバル・ルーティングの組み合わせの

    指定するルーティング・タイプに関係なく、IBM Cloud Transit Gateway はどの MZR にあるクラシック・インフラストラクチャー・ネットワークにも接続できます。 このためには、クラシック接続を中継ゲートウェイに追加するだけです。

  • プロビジョン後に、ゲートウェイのルーティング・タイプを編集できます。 ただし、ルーティングタイプを「 グローバル 」から「 ローカル 」に変更するには、まずグローバル接続(つまり、ゲートウェイと同じロケーションにないリソースへの接続)をすべて削除する必要があります。 IBM Cloud クラシック・インフラストラクチャーへの接続は常にローカルと見なされることに注意してください。

  • ローカルルーティングからグローバルルーティングに変更する場合、関連するすべてのグローバル接続に対して課金されます。 ルーティング・タイプが変更されても、ネットワーク・トラフィックには影響しません。

ルート・レポートの考慮事項

  • ルートレポートに表示されるASパスは、単一ゾーンの視点を提供します。 送信元または送信先が異なるゾーンにまたがっている場合、パスの長さが異なることがあります。 例えば、 DAL10DAL12 の2つの直接リンクを考えてみましょう。どちらも、VPCまたはクラシック環境に接続された DAL ベースのトランジットゲートウェイに向けて、同じASパス長を宣伝しています。 DAL10 仮想サーバーインスタンスから呼び出す場合:

    • DAL10
    • DAL12 からの接続の場合、 DAL12 のダイレクトリンクが優先される。
    • DAL13 の場合、ゲートウェイがECMPルーティングに対応していればECMPルーティングが適用される。 しかし、BGPリセットの間、もう一方のダイレクトリンクに切り替わる可能性がある。
  • 重複するルートは、中継ゲートウェイを構成する際の一般的な問題です。 2つ以上の接続からのルートが重なると、トラフィックが意図したとおりにルーティングされない可能性がある。 詳しくは、 経路の競合の対処 を参照してください。

  • 新しい仮想接続 (VPC、クラシック・インフラストラクチャー、または Direct Link) が 「アクティブ」 状態になったら、中継ゲートウェイによって経路が確認されるまで 5 分待ちます。 すべての経路が確認される前に経路レポートを生成すると、部分経路レポートが作成されます。

  • 接続が 0.0.0.0/0 のルートを公開している場合、重複する接頭部を計算する際にそのルートは無視されます。

  • 常に使用できるのは、ゲートウェイごとに 1 つのレポートのみです。 新しいレポートを生成すると、古いレポートは削除されます。

  • 接続を追加または削除すると、古いルート・レポートが不正確になる可能性があります。 その結果、これらの接続内のルートを更新する場合、新しいルートレポートを作成することをお勧めします。

  • 1つ以上のルートが プレフィックスフィルターによって 拒否された場合、それらのルートはルートレポートに表示されません。

サービスの制限

IBM Cloud Transit Gateway 使用時の以下のサービス制限に留意してください。

IBM Cloud Transit Gatewayサービスの制限
サービス制限 デフォルト
中継ゲートウェイの数 1 つのアカウントにつきゲートウェイ 10 台、1 つのリージョンにつきゲートウェイ 5 台
中継ゲートウェイあたりの接続数
  • 10 IBM Cloud VPC 接続
  • 5 IBM Cloud クラシック接続
  • 5 IBM Cloud Direct Link 接続
  • 5 Power Virtual Server 接続
接続あたりの接頭部の数
  • VPC 接続用 50 プレフィックス
  • クラシック接続用 120 プレフィックス
  • GRE 接続用 120 プレフィックス
  • Direct Link 接続用 120 プレフィックス
  • Power Virtual Server 接続用 120 プレフィックス
接頭部フィルターを使用した接続の数 1 つのゲートウェイにつき接頭部フィルターを使用した接続 2 個
接続あたりの接頭部フィルターの数 1 つの接続につき接頭部フィルター 10 個
中継ゲートウェイごとの GRE トンネルの数 ゲートウェイごとに 12 個の GRE トンネル
中継ゲートウェイごとの、アンバインドされた GRE トンネルのターゲットとなる固有の基本ネットワークの数 ゲートウェイごとに、アンバインドされた GRE トンネルのターゲットとなる 5 つの固有のベース・ネットワーク

サービス制限を拡張する必要がある場合は、IBM サポート Case をオープンできます。