Migrate to a new ExpressRoute circuit

If you want to switch from one ExpressRoute circuit to another, you might want to do it smoothly with minimum service interruption. This document helps you to follow the steps to migrate your production traffic without causing major disruptions or risks. You can use this method whether you're moving to a new or the same peering location.

If you've got your ExpressRoute circuit through a Layer 3 service provider, create the new circuit under your subscription in the Azure portal. Work with your service provider to switch the traffic seamlessly to the new circuit. After the service provider has deprovisioned your old circuit, delete it from the Azure portal.

The rest of the article applies to you if you've got your ExpressRoute circuit through a Layer 2 service provider or ExpressRoute direct ports.

Steps for seamless ExpressRoute circuit migration

The diagram above illustrates the migration process from an existing ExpressRoute circuit, referred to as Circuit A, to a new ExpressRoute circuit, referred to as Circuit B. Circuit B can be in the same or a different peering location as Circuit A. The migration process consists of the following steps:

1. Deploy Circuit B in isolation: While the traffic continues to flow over Circuit A, deploy a new Circuit B without affecting the production environment.

2. Block the production traffic flow over Circuit B: Prevent any traffic from using Circuit B until it's fully tested and validated.

3. Complete and validate end-to-end connectivity of Circuit B: Ensure that Circuit B can establish and maintain a stable and secure connection with all the required endpoints.

4. Switch over the traffic: Redirect the traffic flow from Circuit A to Circuit B and block the traffic flow over Circuit A.

5. Decommission Circuit A: Remove Circuit A from the network and release its resources.

Deploy new circuit in isolation

For a one-to-one replacement of the existing circuit, select the Standard Resiliency option and follow the steps outlined in the Create a circuit with ExpressRoute guide to create your new ExpressRoute circuit (Circuit B) in the desired peering location. Then, follow the steps in Configure peering for ExpressRoute circuit to configure the required peering types: private and Microsoft.

To prevent the private peering production traffic from using Circuit B before testing and validating it, don't link virtual network gateway that has production deployment to Circuit B. Similarly to avoid Microsoft peering production traffic from using Circuit B, don't associate a route filter to Circuit B.

Block the production traffic flow over the newly created circuit

Prevent the route advertisement over the new peering(s) on the CE devices.

For Cisco IOS, you can use a route-map and a prefix-list to filter the routes advertised over a BGP peering. The following example shows how to create and apply a route-map and a prefix-list for this purpose:

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

Use export/import policy to filter the routes advertised and received on the new peering(s) on the Junos devices. The following example shows how to configure export/import policy for this purpose:

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 ];
            }
        }
    }
}

Validate the end-to-end connectivity of the newly created circuit

Private peering

Follow the steps in Connect a virtual network to an ExpressRoute circuit to link the new circuit to the gateway of a test virtual network and verify your private peering connectivity. After linking virtual networks to the circuit, examine the route table of the private peering of the circuit and verify that the address space of the virtual network is included in the table. The following example shows a route table of the private peering of an ExpressRoute circuit in the Azure Management portal:

The following diagram illustrates a test VM configured in a test virtual network and a test device located on-premises for verifying the connectivity over the ExpressRoute private peering.

Modify the route-map or the policy configuration that you have applied to filter the routes advertised and allow the specific IP address of the test device from on-premises. Similarly, allow the test virtual network's address space from 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

To allow specific IP prefixes for test devices on Junos, configure a prefix-list. Then, configure the BGP import/export policy to allow these prefixes and reject everything else.

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;

Verify the end-to-end connectivity over the private peering. For example, you can ping the test VM in Azure from your on-premises test device and check the results. For step-by-step detailed validation, see Verifying ExpressRoute connectivity.

Microsoft peering

The verification of your Microsoft peering requires careful planning to avoid any effect on the production traffic. You need to use distinct prefixes for the Microsoft peering of Circuit B that are different from the ones used for Circuit A, to prevent any routing conflicts between the two circuits. You also need to link the Microsoft peering of Circuit B to a separate route filter than the one linked to Circuit A, following the steps in configuring route filters for Microsoft peering. Additionally, you need to ensure that the route filters for both circuits don't have any common routes that are advertised to the on-premises network, to avoid asymmetrical routing between Circuit A and Circuit B. To achieve this, you can either:

• select a service or an Azure region for testing Circuit B that isn't used by the production traffic on Circuit A, or
• minimize the overlap between the two route filters and permit only more specific test public endpoints received through Circuit B

Once you have linked a route filter, you need to check the routes that are advertised and received over the BGP peering on the CE device. To filter the routes that are advertised and allow only the on-premises prefixes of the Microsoft peering and the specific IP address of the selected Microsoft public endpoints for testing, you need to modify the route-map or the Junos policy configuration that you have applied.

Switch over the production traffic

Private peering

1. Disconnect Circuit B from any test virtual network gateways that you have connected it to.
2. Remove any exceptions that you have made to the Cisco route-maps or Junos policy.
3. Follow the steps in Connect a virtual network to an ExpressRoute circuit and connect Circuit B to production virtual network gateway(s).
4. On the CE, make sure that you're ready to advertise all the routes that you're currently advertising over Circuit A, over Circuit B when you remove the route-map or policy applied to Circuit B interfaces on CE. This also includes ensuring that the interfaces of Circuit B are associated with the appropriate VRF or routing-instance, if any.
5. Remove the route-maps or policy on Circuit B interfaces. Apply the route-maps or policy on Circuit A interfaces to block the route advertisement over Circuit A. This will switch the traffic flow over Circuit B.
6. Verify the traffic flow over Circuit B. If the verification fails, undo the route-map or firewall association that you did in the previous step and switch the traffic flow back over Circuit A.
7. If the verification of traffic flow over Circuit B is successful, delete Circuit A.

Microsoft peering

1. Remove Circuit B from any test Azure route filter that you have linked it to.
2. Remove any exceptions that you have made to the route-maps or policy.
3. On CE, make sure that the interface of Circuit B is associated with the appropriate VRF or routing-instance.
4. Validate and confirm the advertised prefix over the Microsoft peering.
5. Associate Circuit B Microsoft peering to the Azure route filter that is currently associated to Circuit A.
6. Remove the route-maps or export/import policy on Circuit B interfaces. Apply the route-maps or export/import policy on Circuit A interfaces to block the route advertisement over Circuit A. This will switch the traffic flow over Circuit B.
7. Verify the traffic flow over Circuit B. If the verification fails, undo the route-map or policy association that you did in the previous step and switch the traffic flow back over Circuit A.
8. If the verification of traffic flow over Circuit B is successful, delete Circuit A.

Next step

For more information about router configuration, see Router configuration samples to set up and manage routing.