新しい ExpressRoute 回線への移行

  • [アーティクル]

ある ExpressRoute 回線から別の同回線に切り替える場合は、サービスの中断を最小限に抑えてスムーズに切り替えましょう。 このドキュメントは、重大な中断やリスクを引き起こさずに、実稼働トラフィックを移行するステップに従うために役立ちます。 この方法は、新規または同一のピアリングの場所のどちらに移行する場合でも使用できます。

レイヤー 3 サービス プロバイダーを介して ExpressRoute 回線を使用している場合は、Azure portal でサブスクリプションに新しい回線を作成します。 サービス プロバイダーと連携して、トラフィックを新しい回線にシームレスに切り替えましょう。 サービス プロバイダーによって古い回線のプロビジョニングが解除されたら、Azure portal から削除します。

この記事の続きは、レイヤー 2 サービス プロバイダーまたは ExpressRoute ダイレクト ポートを介して ExpressRoute 回線を使用している場合に適用されます。

シームレスな ExpressRoute 回線移行のステップ

Diagram showing an ExpressRoute circuit migration from Circuit A to Circuit B.

上の図は、回線 A と呼ばれる既存の ExpressRoute 回線から、回線 B と呼ばれる新しい ExpressRoute 回線への移行プロセスを示しています。回線 B は、回線 A と同一または別のピアリングの場所に配置できます。この移行プロセスは、以下のステップで構成されています。

  1. 回線 B を分離してデプロイする: トラフィックが回線 A 上を流れ続けている間は、運用環境に影響を与えずに新しい回線 B をデプロイします。

  2. 回線 B 上の実稼働トラフィック フローをブロックする: 完全にテストおよび検証されるまで、トラフィックによって回線 B が使用されないようにします。

  3. 回線 B のエンドツーエンド接続を完了して検証する: 回線 B で必要なすべてのエンドポイントと安定した安全な接続を確立し、維持できることを確認します。

  4. トラフィックを切り替える: 回線 A から回線 B へのトラフィック フローをリダイレクトして、回線 A 上のトラフィック フローをブロックします。

  5. 回線 A の使用を停止する: ネットワークから回線 A を削除して、そのリソースを解放します。

新しい回線を分離してデプロイする

「ExpressRoute を使用した回線の作成」のステップに従って、目的のピアリングの場所に新しい ExpressRoute 回線 (回線 B) を作成します。 次に、「チュートリアル: ExpressRoute 回線のピアリングの構成」のステップに従って、必要なピアリングの種類 (プライベートおよび Microsoft) を構成します。

テストして検証する前に回線 B がプライベート ピアリングの実稼働トラフィックによって使用されないようにするには、運用環境にデプロイされた仮想ネットワーク ゲートウェイを回線 B にリンクしないでください。同様に、回線 B が Microsoft ピアリングの実稼働トラフィックによって使用されるのを避けるために、ルート フィルターを回線 B に関連付けないでください。

新規作成された回線で実稼働トラフィック フローをブロックする

CE デバイス上の新しいピアリングでのルート アドバタイズを防止します。

Cisco IOS の場合は、route-map と prefix-list を使用して、BGP ピアリングでアドバタイズされたルートをフィルター処理できます。 次の例は、この目的のために route-map と prefix-list を作成して適用する方法を示しています。

route-map BLOCK ADVERTISEMENTS deny 10
 match ip address prefix-list BLOCK-ALL-PREFIXES

ip prefix-list BLOCK-ALL-PREFIXES seq 10 deny 0.0.0.0/0 le 32

router bgp <your_AS_number>
 neighbor <neighbor_IP_address> route-map BLOCK-ADVERTISEMENTS out
 neighbor <neighbor_IP_address> route-map BLOCK-ADVERTISEMENTS in

エクスポート/インポート ポリシーを使用し、Junos デバイス上の新規のピアリングでアドバタイズおよび受信されたルートをフィルター処理します。 次の例は、この目的のためにエクスポート/インポート ポリシーを構成する方法を示しています。

user@router>show configuration policy-options policy-statement BLOCK-ALL-ROUTES

term reject-all {

    the reject;
}

protocols {
    bgp {
        group <your_group_name> {
            neighbor <neighbor_IP_address> {
                export [ BLOCK-ALL-ROUTES ];
                import [ BLOCK-ALL-ROUTES ];
            }
        }
    }
}

新規作成された回線のエンド ツー エンド接続の検証

プライベート ピアリング

「仮想ネットワークを ExpressRoute 回線に接続する」のステップに従い、新しい回線をテスト仮想ネットワークのゲートウェイにリンクして、プライベート ピアリング接続を確認します。 仮想ネットワークを回線にリンクした後、回線のプライベート ピアリングのルート テーブルを調べて、仮想ネットワークのアドレス空間がテーブルに含まれていることを確認します。 次の例は、Azure の管理ポータルにおける ExpressRoute 回線のプライベート ピアリングのルート テーブルを示しています。

Screenshot of the route table for the primary link of the ExpressRoute circuit.

次の図は、テスト仮想ネットワークにおいて構成されたテスト VM と、ExpressRoute プライベート ピアリングを介した接続を確認するためにオンプレミスに配置されたテスト デバイスを示しています。

Diagram showing a VM in Azure communicating with a test device on-premises through the ExpressRoute connection.

アドバタイズされたルートをフィルター処理して、オンプレミスからテスト デバイスの特定の IP アドレスを許可するように、適用したルート マップまたはポリシーの構成を変更します。 同様に、Azure からのテスト仮想ネットワークのアドレス空間を許可します。

route-map BLOCK ADVERTISEMENTS permit 5
 match ip address prefix-list PERMIT-ROUTE

route-map BLOCK ADVERTISEMENTS deny 10
 match ip address prefix-list BLOCK-ALL-PREFIXES

ip prefix-list PERMIT-ROUTE seq 10 permit 10.17.1.0/24
ip prefix-list PERMIT-ROUTE seq 20 permit 10.1.18.10/32

ip prefix-list BLOCK-ALL-PREFIXES seq 10 deny 0.0.0.0/0 le 32

Junos 上のテスト デバイスに対して特定の IP プレフィックスを許可するには、プレフィックス リストを構成します。 次に、これらのプレフィックスを許可して、その他のすべてを拒否するように BGP インポート/エクスポート ポリシーを構成します。

user@router>show configuration policy-options policy-statement BLOCK-ADVERTISEMENTS

term PERMIT-ROUTES {
    from {
        prefix-list PERMIT-ROUTE;
    }
    then accept;
}

term reject-all {
    then reject;
}

user@router>show configuration policy-options prefix-list PERMIT-ROUTE

10.1.18.10/32;
10.17.1.0/24;

プライベート ピアリングを介したエンド ツー エンド接続を確認します。 たとえば、オンプレミスのテスト デバイスから Azure のテスト VM に ping を実行し、結果を確認してみましょう。 段階的で詳細な検証については、「ExpressRoute 接続を確認する」を参照してください。

Microsoft ピアリング

Microsoft ピアリングの検証には、実稼働トラフィックへの影響を回避するための綿密な計画が必要です。 2 つの回線間におけるルーティングの競合を防ぐために、回線 B の Microsoft ピアリングには、回線 A に使用されているものとは異なる個別のプレフィックスを使用する必要があります。 また、「Microsoft ピアリングにルート フィルターを構成する」のステップに従って、回線 B の Microsoft ピアリングを、回線 A にリンクされたものとは別のルート フィルターにリンクする必要があります。 さらに、回線 A と回線 B の間の非対称ルーティングを回避するために、両方の回線のルート フィルターに、オンプレミス ネットワークにアドバタイズされる共通のルートがないことを確認する必要があります。これを実現するには、次のいずれかを行います。

  • 回線 A 上の実稼働トラフィックによって使用されていない回線 B をテストするサービスまたは Azure リージョンを選択する
  • 2 つのルート フィルター間の重複を最小限に抑えて、回線 B を介して受信したより具体的なテスト パブリック エンドポイントのみを許可する

ルート フィルターをリンクしたら、CE デバイス上の BGP ピアリングを介してアドバタイズおよび受信されるルートを確認する必要があります。 アドバタイズされたルートをフィルター処理し、Microsoft ピアリングのオンプレミス プレフィックスと、選択したテスト用 Microsoft パブリック エンドポイントの特定の IP アドレスのみを許可するには、適用したルート マップまたは Junos ポリシー構成を変更する必要があります。

Microsoft 365 エンドポイントへの接続をテストするには、「Microsoft 365 向け ExpressRoute の実装 – テスト手順を構築する」のステップに従います。 Azure パブリック エンドポイントの場合は、オンプレミスからの traceroute などの基本的な接続テストから開始し、要求が ExpressRoute エンドポイントを経由することを確認するとよいでしょう。 ExpressRoute エンドポイントを超えると、ICMP メッセージは Microsoft ネットワークを介して抑制されます。 基本的な ping テストに加えて、アプリケーション レベルで接続をテストするのもよいでしょう。 たとえば、Azure パブリック IP を持つ Azure VM で Web サーバーを実行している場合、ExpressRoute 接続を介してオンプレミス ネットワークから Web サーバーのパブリック IP にアクセスしてみてください。 これは、HTTP 要求などのより複雑なトラフィックが Azure サービスに到達できることを確認するうえで役立ちます。

実稼働トラフィックの切り替え

プライベート ピアリング

  1. 接続先のテスト仮想ネットワーク ゲートウェイから回線 B を切断します。
  2. Cisco ルート マップまたは Junos ポリシーに対して認めた例外を削除します。
  3. 「ExpressRoute 回線に仮想ネットワークを接続する」のステップに従って、回線 B を運用仮想ネットワーク ゲートウェイに接続します。
  4. CE で、CE 上の回線 B インターフェイスに適用したルート マップまたはポリシーを削除する際に、現在回線 A を介してアドバタイズしているすべてのルートを回線 B を介してアドバタイズする準備ができていることを確認します。 これには、回線 B のインターフェイスが適切な VRF またはルーティング インスタンス (存在する場合) に関連付けられていることの確認も含まれます。
  5. 回線 B インターフェイスでルート マップまたはポリシーを削除します。 回線 A のインターフェイスにルート マップまたはポリシーを適用し、回線 A を介したルート アドバタイズをブロックします。これにより、トラフィック フローが回線 B に切り替わります。
  6. 回線 B 上のトラフィック フローを確認します。検証に失敗した場合は、前のステップで行ったルート マップまたはファイアウォールの関連付けを元に戻し、トラフィック フローを回線 A に再び切り替えます。
  7. 回線 B 上のトラフィック フローの検証に成功した場合は、回線 A を削除します。

Microsoft ピアリング

  1. リンク先のテスト Azure ルート フィルターから回線 B を削除します。
  2. ルート マップまたはポリシーに対して認めた例外をすべて削除します。
  3. CE で、回線 B のインターフェイスが適切な VRF またはルーティング インスタンスに関連付けられていることを確認します。
  4. Microsoft ピアリングでアドバタイズされたプレフィックスを検証して確認します。
  5. 回線 B の Microsoft ピアリングを、現在回線 A に関連付けられている Azure ルート フィルターに関連付けます。
  6. 回線 B インターフェイスでルート マップまたはエクスポート/インポート ポリシーを削除します。 回線 A のインターフェイスにルート マップまたはエクスポート/インポート ポリシーを適用し、回線 A を介したルート アドバタイズをブロックします。これにより、トラフィック フローが回線 B に切り替わります。
  7. 回線 B 上のトラフィック フローを確認します。検証が失敗した場合は、前のステップで行ったルート マップまたはポリシーの関連付けを元に戻し、トラフィック フローを回線 A に再び切り替えます。
  8. 回線 B 上のトラフィック フローの検証に成功した場合は、回線 A を削除します。

次のステップ

ルーター構成の詳細については、「ルーティングをセットアップして管理するためのルーター構成のサンプル」を参照してください。