When helping customer migrate to Aviatrix, most of the time, we have standard migration process, which is documented here. Few customer may need customized migration architecture due to their existing architecture and special requirements. These customized migration architecture require additional testing to understand what would be the potential impact to traffic flow. While most enterprise customer may have monitoring system in place, but in the lab/dev/QA phrase, we may not have the luxury to have full fledge monitoring system deployed. In this blog post, I will show you a simple method to log connectivity between desired data paths without breaking a sweat or the bank.
Aviatrix developed Migration Toolkit to help customer migrate from existing AWS/ Azure environment to Aviatrix Transit and Spoke Multi-Cloud Networking Architecture (MCNA). I have discussed the process in blog: Migrate from Azure vNet hub and spoke architecture to Aviatrix Transit. The AWS migration process is similar, where the toolkit make copies of existing route tables, when Aviatrix Spoke is attached to Aviatrix Transit, we are using these copied route tables, hence no traffic interruption would happen. During the traffic switching phrase, subnets will be associated with the copied route table, and in TGW we disable the migrating VPC router advertisement, so the traffic would swing over to Aviatrix Spoke/Transit.
Some of our customers are using CloudFormation to manage the deployment of their environment, while Aviatrix Controller will handle bulk of the work such as populating RFC1918 and/or default route in the route table and/or non-RFC1918 routes from External connections, they still would like to have the ability to continue to use CloudFormation to manage endpoint routes. This created a split brain scenario, how do we handle this?
Enterprise customers values Aviatrix CoPilot for track and gather evidential data on their network. The platform aggregates abundant Syslog and Netflow data, which can be used to establish baseline metrics for alerting. Customers can choose to modify or add/remove metrics to suit their specific needs. Here is a list of recommended baseline metric, as well as detail of each one’s meaning.
In the last blog post: Learning GCP Interconnect: Step-by-Step Guide for Configuring BGP with ISR and Cloud Router, I have shown steps of creating Interconnect VLAN attachment to existing VPC, as well as how to configure Cloud Routers and VPC peerings to establish connectivity from on-prem to GCP spoke VPC. You may have noticed a few feature difference amongst AWS Direct Connect, Azure Express Route and GCP Interconnect, which leads to different architecture.
In this blog post, I will show you how to connect Aviatrix Edge 2.0 to Aviatrix Transit in GCP, using Interconnect as underlay.
This blog serves as a guide to configure GCP Interconnect, Cloud Router to form an BGP session with on-premise BGP capable devices. With VPC peering and import and export routes on the peering, it’s possible to connect up to 25 spoke VPCs to the interconnect VPC.
When tried to delete GCP VPC following error occurs:
[email protected]:~ (<gcp-project>)$ gcloud compute networks delete cloud-sql
The following networks will be deleted:
- [cloud-sql]
Do you want to continue (Y/n)? y
ERROR: (gcloud.compute.networks.delete) Could not fetch resource:
- The network resource 'projects/<gcp-project>/global/networks/cloud-sql' is already being used by 'projects/<gcp-project>/global/networkInstances/v-1171710760-6bcedd6c-b842-4dd0-9e64-65c2ef70f480'
Found out previously I had tried to enable App Engine access Cloud SQL privately by using Serverless VPC Connector
Then in App Engine app.yaml, following statement was used to tell App Engine to use the connector
This has resulting the App Engine to create a network interface with the VPC specified
Since you cannot purge App Engine, I have deployed another app that doesn’t require connection to the VPC:
git clone https://github.com/GoogleCloudPlatform/python-docs-samples
cd python-docs-samples/appengine/standard_python3/building-an-app/building-an-app-1
gcloud app deploy
Now that the App Engine is no longer bind with the VPC
Make sure to delete the Serverless VPC connector
In App Engine, make sure to purge versions that uses the Serverless VPC connector.
Then try to delete the VPC again
gcloud compute networks delete cloud-sql
The following networks will be deleted:
- [cloud-sql]
Do you want to continue (Y/n)? y
Deleted [https://www.googleapis.com/compute/v1/projects/jye-01/global/networks/cloud-sql].
Aviatrix Gateways – Spoke, Transit, CloudN, and Edge – offer a simple and efficient way to establish highly available and high-performing data planes. With the Aviatrix Controller, multiple encrypted tunnels can be automatically created, ensuring seamless redundancy and fast throughput. By deploying a pair of gateways at each end, Aviatrix builds four full mesh tunnels, creating a reliable data path with up to 5Gbps of throughput. But what makes Aviatrix truly stand out is its patented High Performance Encryption, which leverages multiple IP addresses and CPU cores to create multiple IPSec tunnels. This unique approach can achieve up to 70Gbps throughput, delivering exceptional performance.
However, not all customers are ready to implement CloudN or Edge. For these situations, Aviatrix still provides encryption and the ability to create multiple IPSec tunnels for higher throughput. In this blog post, we will delve into how to achieve this and explore the benefits of using Aviatrix Gateways for highly available and high-performing data planes.
As the number of customers onboarding to GCP Google Cloud Platform continues to grow, one of the most common questions asked is how to access GCP Global Services, such as Cloud SQL, privately and securely. The unique features of GCP networking, including the global VPC construct, single route table for all subnets, and regional Cloud Routers, can be challenging for enterprise customers seeking to access GCP global services. In this blog post, I will demonstrate how Aviatrix architecture enables customers securely and efficiently access GCP global services.
In our last blog, “AWS Hybrid Architecture and Edge 2.0,” we covered the workflow of registering an Edge 2.0 gateway, attaching it to Aviatrix Transit, and forming a BGP peering with on-premise devices. Now, let’s take a closer look at the features of the Edge 2.0 gateway. By leveraging Edge 2.0, enterprises gain high throughput and intelligent packet processing capabilities at the edge of their network. Edge 2.0 provides a robust set of features, including intelligent packet routing to streamline network traffic and advanced security features, such as network segmentation, to provide an added layer of protection to your network.
