新しい ExpressRoute 回線への移行
ある ExpressRoute 回線から別の ExpressRoute 回線に切り替える場合は、それを最小限のサービス中断でスムーズに行うことができます。 このドキュメントでは、重大な中断やリスクを発生させることなく運用トラフィックを移行する手順について説明します。 この方法は、新しいピアリングの場所または同じ場所のどちらに移行していても適用されます。
レイヤー 3 サービス プロバイダー経由で ExpressRoute 回線を使用している場合は、Azure portal でサブスクリプションの下に新しい回線を作成します。 サービス プロバイダーと連携して、トラフィックを新しい回線にシームレスに切り替えましょう。 サービス プロバイダーによって古い回線のプロビジョニングが解除されたら、Azure portal から削除します。
この記事の残りの部分は、レイヤー 2 サービス プロバイダーまたは ExpressRoute ダイレクト ポート経由で ExpressRoute 回線を使用している場合に適用されます。
シームレスな ExpressRoute 回線移行のステップ
前の図は、既存の ExpressRoute 回線 (回線 A と呼ばれます) から新しい ExpressRoute 回線 (回線 B と呼ばれます) への移行プロセスを示しています。回線 B は、回線 A と同じピアリングの場所にあっても、別の場所にあってもかまいません。この移行プロセスは、次の手順で構成されます。
回線 B を分離してデプロイする: トラフィックが回線 A 上を流れ続けている間は、運用環境に影響を与えずに新しい回線 B をデプロイします。
回線 B 経由の運用トラフィック フローをブロックする: 完全にテストされ、検証されるまで、回線 B がどのトラフィックでも使用されないようにします。
回線 B のエンドツーエンド接続を完了して検証する: 回線 B で必要なすべてのエンドポイントと安定した安全な接続を確立し、維持できることを確認します。
トラフィックを切り替える: 回線 A から回線 B へのトラフィック フローをリダイレクトして、回線 A 上のトラフィック フローをブロックします。
回線 A の使用を停止する: ネットワークから回線 A を削除して、そのリソースを解放します。
新しい回線を分離してデプロイする
既存の回線を 1 対 1 で置き換える場合は、[標準の回復性] オプションを選択し、ExpressRoute を使用した回線の作成に関するガイドに記載されている手順に従って、目的のピアリングの場所に新しい ExpressRoute 回線 (回線 B) を作成します。 次に、「ExpressRoute 回線のピアリングを構成する」の手順に従って、必要なピアリングの種類 (プライベートと Microsoft) を構成します。
回線 B がテストおよび検証される前にプライベート ピアリングの運用トラフィックで使用されないようにするために、運用環境デプロイが存在する仮想ネットワーク ゲートウェイを回線 B にリンクないでください。同様に、Microsoft ピアリングの運用トラフィックで回線 B が使用されないようにするために、ルート フィルターを回線 B に関連付けないでください。
新規作成された回線で実稼働トラフィック フローをブロックする
CE デバイス上の 1 つ以上の新しいピアリング経由のルート アドバタイズを防止します。
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 回線のプライベート ピアリングのルート テーブルを示しています。
次の図は、ExpressRoute プライベート ピアリング経由の接続を確認するために使用されるテスト仮想ネットワーク内のテスト VM とオンプレミスのテスト デバイスを示しています。
アドバタイズされたルートをフィルター処理するようにルート マップまたはポリシー構成を変更し、オンプレミスのテスト デバイスの特定の 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 ピアリングの確認には、運用トラフィックへの影響を回避するための慎重な計画が必要です。 次の手順に従って、スムーズなプロセスを確保します。
- 個別のプレフィックスを使用する: ルーティングの競合を防止するために、回線 B の Microsoft ピアリングを、回線 A に使用されているものとは異なるプレフィックスで構成します。 ガイダンスについては、Microsoft ピアリングの作成を参照してください。
- 個別のルート フィルター: 回線 B の Microsoft ピアリングを、回線 A とは異なるルート フィルターにリンクします。Microsoft ピアリング用のルート フィルターの構成の手順に従ってください。
-
共通のルートを回避する: 非対称ルーティングを防止するために、両方の回線のルート フィルターが共通のルートを共有しないようにします。 これは、次のようにして行うことができます。
- 回線 A の運用トラフィックで使用されていない回線 B をテストするためのサービスまたは Azure リージョンを選択します。
- 2 つのルート フィルター間の重複を最小限に抑え、回線 B 経由の特定のテスト パブリック エンドポイントのみを許可します。
ルート フィルターをリンクしたら、CE デバイス上の BGP ピアリング経由でアドバタイズおよび受信されたルートを確認します。 アドバタイズされたルートをフィルター処理するようにルート マップまたは Junos ポリシー構成を変更し、テストのために Microsoft ピアリングのオンプレミス プレフィックスと、選択された Microsoft パブリック エンドポイントの特定の IP アドレスのみを許可します。
Microsoft 365 エンドポイントへの接続をテストするには、「Microsoft 365 向け ExpressRoute の実装 - テスト手順を構築する」の手順に従います。 Azure パブリック エンドポイントの場合は、オンプレミスからの traceroute などの基本的な接続テストから始めて、要求が ExpressRoute エンドポイント経由で転送されることを確認します。 ExpressRoute エンドポイントを超えると、ICMP メッセージは Microsoft ネットワーク経由で抑制されます。 さらに、アプリケーション レベルで接続をテストします。 たとえば、パブリック IP で Web サーバーを実行している Azure VM がある場合は、ExpressRoute 接続経由でオンプレミス ネットワークから Web サーバーのパブリック IP にアクセスしてみてください。 これにより、HTTP 要求などの複雑なトラフィックが Azure サービスに到達できることが確認されます。
プライベート ピアリング
- すべてのテスト仮想ネットワーク ゲートウェイから回線 B を切断します。
- Cisco ルート マップまたは Junos ポリシーに対して設定した例外をすべて削除します。
- 仮想ネットワークの ExpressRoute 回線への接続に関するページの手順に従って、回線 B を運用環境の仮想ネットワーク ゲートウェイに接続します。
- 回線 B が、現在回線 A 経由でアドバタイズされているすべてのルートをアドバタイズする準備ができていることを確認します。回線 B インターフェイスが適切な VRF またはルーティング インスタンスに関連付けられていることを確認します。
- 回線 B インターフェイス上のルート マップまたはポリシーを削除し、それらを回線 A インターフェイスに適用して、回線 A 経由のルート アドバタイズをブロックします。それにより、トラフィック フローが回線 B に切り替えられます。
- 回線 B 経由のトラフィック フローを確認します。確認に失敗した場合は、変更を元に戻し、トラフィック フローを元の回線 A に切り替えます。
- 確認に成功した場合は、回線 A を削除します。
Microsoft ピアリング
- すべてのテスト Azure ルート フィルターから回線 B を削除します。
- ルート マップまたはポリシーに対して設定した例外をすべて削除します。
- 回線 B インターフェイスが適切な VRF またはルーティング インスタンスに関連付けられていることを確認します。
- Microsoft ピアリング経由でアドバタイズされたプレフィックスを検証して確認します。
- 回線 B の Microsoft ピアリングを、現在回線 A に関連付けられている Azure ルート フィルターに関連付けます。
- 回線 B インターフェイス上のルート マップまたはエクスポート/インポート ポリシーを削除し、それらを回線 A インターフェイスに適用して、回線 A 経由のルート アドバタイズをブロックします。それにより、トラフィック フローが回線 B に切り替えられます。
- 回線 B 経由のトラフィック フローを確認します。確認に失敗した場合は、変更を元に戻し、トラフィック フローを元の回線 A に切り替えます。
- 確認に成功した場合は、回線 A を削除します。
次のステップ
ルーター構成の詳細については、「ルーティングをセットアップして管理するためのルーター構成のサンプル」を参照してください。