What happens if an enterprise already has a cloud presence as most of our customers and wants to adopt Aviatrix to boost their network and security capabilities?
Brownfield Topology
- hub and spoke topology
- hub is connected to on-prem
- spokes are vnet “peered” to the hub
- spoke has UDR pointing traffic towards a NVA running in the hub
Brownfield Environment
Spoke subnets have route tables with a single route pointing towards the NVA running in the hub (the /32 route is for my own access to the VM):
During this lab I’m continuously pinging a remote VM (192.168.10.10) from a VM (10.2.0.4) running in the spoke:
Aviatrix Deployment
In parallel to the production environment, we will deploy a new transit hub using Aviatrix:
We actually will deploy a Firenet. I blog about Firenet on Azure on the following posts:
After the new transit is built, an Express Route Gateway is deployed in the transit vnet and we connect the ERGW to the Express Route circuit.
Deploy Gateways
The next step is to deploy AVX gateways into the brownfield environment:
The controller is smart enough to pick up unused subnets as candidate for the deployment. If you don’t have an “empty” subnet, you can add another CIDR to the VNET and create a new set of subnets:
If a new CIDR was added you will need to resync your peerings:
I created a new /24 but if you need High Performance Encryption, the minimum size is /26. Once the subnet is created, I deploy a pair of gateways into it:
Attachment
Multi-Cloud Transit Attach Spoke Gateway to Transit Network connects a spoke to the hub creating the required configuration (tunnel interfaces, interfaces configuration, route tables, NSGs, among others).
There are different approaches for this step for making sure there is no traffic disruption and there are fail back mechanisms in place.
The Attachment gateway wizard allows to skip certain route tables using the advanced option:
Once the attachment is completed, the following diagram represents where we stand in the migration steps:
Traffic is still flowing through the brownfield hub
During a gateway attachment to an AVX transit gateway subnets route tables are analyzed and different actions are taken:
- If there is no route table attached to a subnet, the avx controller creates a route table with no routes and associates it to the subnet
- if the route table has a 0/0 entry, the controller will classify it as a “private” network where egress traffic to the internet can be configured to leave to the internet through FQDN gateways or centralized egress firenet. By default, the AVX controller will not overwrite the 0/0 and it is up to the administrator to correctly set its behavior or attaching/detaching the gateway or disabling/enabling centralized egress.
- If the route table does not have a 0/0, AVX controller will classify it as a “public” subnet, meaning endpoints with public ip can have access to the internet using a system default entry 0.0.0.0/0 pointing to Internet.
Cut-Over
At the proper time and following a detailed migration plan, the cut-over consists on moving (associating) route tables to the subnets redirecting traffic to the Aviatrix hub:
Once the cut-over for the vnet 10.3.0.0/21 is complete, the environment is represented below:
Clean up
After the workload migrated is tested and the migration is declared successful, cloud native objects can safely be removed like for example the vnet peering.
The steps are repeated until all the vnets are “under” the Aviatrix control. Of course the steps can change as can be automated.
If you do not want to do it by yourself, you can reach out to Aviatrix Professional Services team https://aviatrix.com/professional-services/ for help.
