Disclaimer
This is the 1st work in a series of 3 (what I have in mind so far) documents describing my experience with Aviatrix. In this document the steps I’ll take are assumptions and or guesses.
The second document will go deeper on each of the steps of this document, while the third document will focus on automation.
Quick Overview
The Aviatrix Cloud Network Platform consists of a centralized controller that is multi-cloud aware and intelligent cloud routers called gateways.
The scenario I’ll like to test is depicted on the diagram below. VM1 on spoke1 should ping VM2 on spoke2 :
Deploying a Controller
Aviatrix Controller _is_ deployed in a existent VPC in a public subnet. I created a new vpc for ease of management:
I created two public subnets:
Moving to the marketplace and searching for aviatrix I found several offers:
There are three business model for Aviatrix consumption:
- Bring your Own License (BYOL)
- Enterprise Subscription
- Metered (Pay as you Go (PAYG))
The following metrics are used for charging back:
- Number of VPC-to-VPC IPSec Tunnel Connections within AWS
- Number of User or Client SSL VPN Connections
- Number of Gateways running Security Services
- Number of VPC to Site or Multicloud IPSec Tunnel Connections
If you need professional help Implementation services can be procured directly from AWS Marketplace:
I’ll use the BYOL offer:
Terms and Conditions:
Product Support Connection:
Configuration:
Launch software:
Controller is deployed using a CloudFormation stack:
I need to create a key before launching the stack:
Stack details:
Once the stack is completed successfully, we can https to the public ip of the controller instance:
Controller Configuration
One can access the GUI interface using a browser. The default user is admin, and the default password is the private instance IP address:
Change the default password after first access:
If a proxy is required one can be configured at this moment or later.
Initial Setup
I will use the latest software available (didn’t see another option on the drop-down menu). The setup takes several minutes to complete.
After the setup is finished, we can log in:
Onboard
The first step is to license the product. We can do it providing the Aviatrix customer id:
And then the Primary Access Account (the same where the controller was deployed):
Transit Hub using TGW (TGW Orchestrator)
Aviatrix can create and manage a hub-spoke topology based on TGW:
The TGW Orchestrator workflow is under Usecases:
The workflow provides a friendly guide to help picking up the scenario:
Once the scenario is chosen, steps are presented scrolling down the page. The first step is to create a tgw:
Once the button create is pressed, a bar shows the progress of the deployment:
The TGW Orchestrator has options to list and view TGWs deployed:
Spokes
VPC spokes can be create using the Useful Tools:
I’ll deploy a couple of instances (VM1 and VM2) to test control, data, and security planes.
Attachment
The next step is attaching the VPCs to the TGW. This step is done using the Build under TGW Orchestration:
Spoke1 and Spoke 2 were attached to the default domain. Once the VPCs are attached to the TGW we can test the scenario.
Testing
I ssh to the VM2 and from the VM2 I tried to ssh to the instance VM1, what worked. I tried to ping, but it failed because the default SG for Centos only allows SSH:
We can also test using Flightpath. Flightpath will check route tables, security groups, and network acls:
Multi-Cloud Transit
I’m going to use Aviatrix Gateways to build the same scenario as above but providing more functionalities.
I’ll discuss the differences among aviatrix hubs in a next post. To setup a multi-cloud transit we will use the multi-cloud transit setup flow. First, we deploy a transit gateway, spoke gateways, and then attach them:
I’ll enable HA for the transit gateway:
And then spoke gws for vpc spoke1 and spoke2:
HA is also optional to the spokes. I won’t enable at this time. The last step is to attach the spoke gws to the transit gw:
The last step before testing the deployment is to enable transit. By default, Aviatrix Spoke VPCs do not have routing established to communicate with each other via Transit:
Testing
I ssh to the VM2 and from the VM2 ping VM1:
We can also test using Flightpath. Flightpath will check route tables, security groups, and network acls:
References
https://docs.aviatrix.com/StartUpGuides/aviatrix-cloud-controller-startup-guide.htmlhttps://docs.aviatrix.com/StartUpGuides/aviatrix-cloud-controller-startup-guide.htmlhttps://docs.aviatrix.com/StartUpGuides/aviatrix-cloud-controller-startup-guide.html
