Migrating sub 1 Gbps hosted connection to use AWS Transit Gateway – Part 1

Introduction

This blog will describe the recommended migration approach for migrating existing hybrid connectivity architectures with sub 1 Gbps AWS Direct Connect hosted connections to AWS Transit Gateway. It will provide you with a target architecture along with step-by-step prescriptive guidance on how to migrate from your existing state.

Key benefits you can derive from migration are:

• Scale – In case you are not using Transit Gateway today, it will allow you to extend the hybrid connectivity seamlessly to a large number of VPCs with Transit Gateway.
• Simplified hybrid connectivity – Removing the need for custom networking constructs, such as transit VPC, that were typically used for Transit Gateway connectivity at sub 1 Gbps speeds.

Customers have been asking to use transit virtual interface (transit VIF) on sub 1 Gbps hosted connections. This solution allows native integration with Transit Gateway for those connections.

Since the August 2022 launch of expanded connections speed support, you can now connect to Transit Gateway at sub 1 Gbps speeds. Prior to this launch, it was required that you had at minimum a 1 Gbps Direct Connect connection to natively the connect with Transit Gateway. Now, when you are using Transit Gateway and Direct Connect you have seamless connectivity and a cost-effective choice when higher speed connections are not required.

Migration scenarios

There are two common migration scenarios where customers can benefit from using Direct Connect and Transit Gateway:

1. Existing architectures that are using a sub 1 Gbps Direct Connect hosted connection but not using Transit Gateway
2. Existing architectures that are using Direct Connect, Transit Gateway, and transit VPC for hybrid connectivity

This post (Part 1) describes the migration approach for scenario 1. In the subsequent post (Part 2), we cover migration scenario 2.

High-level approach

This migration approach involves deleting the existing private VIF (private virtual interface) and creating a new transit VIF (transit virtual interface) on an existing Direct Connect connection.

If you want to minimize hybrid connectivity downtime during a migration, provision redundant Direct Connect connections in your existing setup. Then, proceed with migration in stages. First, delete the private VIF and create new transit VIF on your passive connection, next repeat this process for your active connection. Where you can, keep the new transit VIF configurations the same as the old private VIF.

This post assumes that you built the architecture with resilient Direct Connect connections, where one Direct Connect connection is active (or primary) and the other is passive (or secondary). We assume that both primary and secondary Direct Connect connections are of equal capacity. For example, both are 500 Mbps hosted connections.

Migrating to Transit Gateway

The following figure shows the scenario 1 example connectivity architecture of a customer using a sub 1 Gbps Direct Connect hosted connection and not using Transit Gateway. It shows two hosted Direct Connect connections, private VIFs, BGP peering details, and the route propagation between on-premises and AWS.

Fig.1 Existing connectivity using two hosted Direct Connect connections (active/passive)

The migration occurs in three stages.

Stage 1: Build Direct Connect – connectivity for Test VPC on secondary Direct Connect connection

The following figure shows a high-level diagram of the existing network deployment. And the next figure after that shows intermediate stage 1 with connectivity established using the second Direct Connect connection and a new Transit Gateway for the Test VPC.

Fig.2 Initial State: Hosted Direct Connect Connections (active- passive) with Direct Connect Gateway

The intermediate stage provides a mechanism to validate the new architecture’s use of Transit Gateway with a Test VPC, before moving the production VPC to the new architecture.

Fig.3 Intermediate Stage 1: Hosted Direct Connect Connections (active- active) with Test VPC using Transit Gateway

Migration steps:

• Step 1: Create a new Transit Gateway. The ASN used here should differ from the ASN used on-premises and in Direct Connect Gateway.
• Step 2: Create a new Direct Connect Gateway (shown as Direct Connect Gateway 2 in the diagram). Use the same ASN as the existing Direct Connect Gateway 1.
• Step 3: Copy the configuration of private virtual interface 2. You can use the describe-virtual-interfaces CLI command to do this. The key information to capture is as follows. You can reuse this in step 5) to reduce router configuration changes.

1. 1. VLAN
   2. Customer ASN
   3. Customer Peer IP
   4. AWS Peer IP
   5. BGP Auth Key

• Step 4: Delete private virtual interface 2 (on Direct Connect Connection 2).
• Step 5: Create the new transit virtual interface, selecting Direct Connect connection 2 and specifying the exact configuration parameters as collected in step 3). If everything is set up correctly, then the transit virtual interface will show the status as available and the BGP status as up. This will be seamless, with no change to the on-premises router configuration. However, if you’ve changed any of the virtual interface configuration, then you can always download the new router configuration from the transit VIF console page and change the router config accordingly. For example, reconfigure the router if you used a different ASN for Direct Connect gateway 2, a different VLAN, a different AWS/Customer peer IP, or a different BGP Auth Key, while configuring the transit VIF.
• Step 6: Attach Direct Connect Gateway 2 with Transit Gateway.
• Step 7: Specify the Test VPC CIDR that you want to reach from on-premises in the allowed prefixes.
• Step 8: Verify that the Transit Gateway route table associated with the Direct Connect attachment has the on-premises routes. For example, the above on-premises CIDR 192.168.0.0/24 populated in the Transit Gateway route table. Verify that the on-premises router is receiving the route advertisement of Test VPC CIDR 10.2.0.0/24 from Direct Connect connection 2. This confirms that there is IP reachability between Transit Gateway and the on-premises router.
• Step 9: Disassociate the Test VPC from the Direct Connect Gateway 1. Note that this removes the on-premises connectivity from the Test VPC.
• Step 10: Attach Transit Gateway to the Test VPC. Verify that the associated route table associated with the Test VPC in Transit Gateway has routes from the on-premises networks. Check that the routes from the Test VPC are in the route table associated with the Direct Connect attachment.
• Step 11: Modify the Test VPC route table and add route(s) to send traffic to the on-premises networks via Transit Gateway. Add 192.168.0.0/24 to the VPC route table with a destination of the Transit Gateway. This will restore connectivity from the Test VPC to on-premises, now using Transit Gateway and Direct Connect.

Since the reachability for the Test VPC is only via Direct Connect connection 2, Direct Connect connection 2 becomes the active path for traffic to and from the Test VPC. Note that there is no standby Direct Connect connection for the primary Direct Connect connection during this intermediate stage of the migration.

The following figure shows the detailed intermediate state 1 architecture with updated virtual interface configurations, BGP peering details, and the updated routes at on-premises and AWS.

Fig.4 Intermediate stage 1: Hosted Direct Connect Connections (active- active) with Test VPC using Transit Gateway

Stage 2: Build Transit Gateway / Direct Connect – connectivity for Production VPCs

This stage will involve making some of the same Direct Connect connectivity changes for the production VPCs.

Fig.5 Intermediate Stage 2: Hosted Direct Connect connections with Test VPC and Production VPC both using Transit Gateway.

Migration steps:

• Specify the Production VPC CIDR in the allowed prefixes of Direct Connect Gateway association.
• Repeat steps 9-11 for each of the production VPCs.

The production VPC connectivity to on-premises will now use the Transit Gateway and Direct Connect connections.

During this time, the reachability for the Production VPC is only via Direct Connect connection 2. This makes it active for traffic from Production VPCs. There is no standby Direct Connect connection during this intermediate stage.

Stage 3: Migrate to active/passive connections using Transit Gateway

In the third and final stage, we re-establish the primary Direct Connect connection, connect it to Transit Gateway, and have all VPCs use it as the primary Direct Connect connection, returning the second Direct Connect connection to a passive role.

Fig.6 Final State: Hosted Direct Connect Connections with Transit Gateway and Direct Connect Gateway

Repeat steps 3) to 5) of stage 1 on Direct Connect connection 1 (Primary). Once both of the Transit VIF are active, the original BGP preferences on the on-premises router is used. Direct Connect connection 1 becomes active, and Direct Connect connection 2 becomes passive for all the traffic flows to and from on-premises. Finally, verify if all the VPC CIDR ranges are being received correctly on the customer gateway from both active and passive Direct Connect connections.

The following figure shows the final architecture with updated virtual interface configurations, BGP peering details, and the updated routes on-premises and in AWS.

Fig.7 Final State: Hosted Direct Connect connections (active- passive) with all VPC using Transit Gateway

Conclusion

In this post, we worked through a migration pattern that integrated Direct Connect sub 1 Gbps hosted connections with Transit Gateway. This will allow you to scale your hybrid connectivity from on-premises to a large number of VPCs using Transit Gateway.

We migrated from a private VIF, Direct Connect Gateway, Virtual Gateway architecture, to one that uses Transit VIF, Direct Connect Gateway, and Transit Gateway while minimising downtime.

In the next post (Part 2 of the series), we describe how to migrate an existing environment that uses Transit VPC.

About the Author