Deploy Use-Cases and Experience Aviatrix Platform - Test Plan

After building the Aviatrix Sandbox Starter environment, it is highly recommended to first deploy Aviatrix CoPilot and follow the instructions to experience advanced visibility and monitoring capabilities.

Even if you don't deploy CoPilot, here are a few test cases to familiarize yourself with the platform.

You may also refer to https://docs.aviatrix.com to deploy use-cases beyond to what is discussed here in this post.

UI Walkthrough

Dashboard

Once you are signed in, if you chose to build the Transit in AWS as well as in Azure, your Controller dashboard will look like this: 

Access Accounts

To verify that everything is working like it should, go on the menu on the left and click “Accounts”, and then “Access Accounts”.

Confirm that the Account Number or ID are accurate, which can be found here for AWS and here for Azure.

Operations

End-to-end Verification from Test Instances

You should be able to perform an end-to-end ping from one Test instance to the other using the Private IP address.

SSH to workloads using the following example, make sure you are in the directory where the key pair is stored.

$ chmod 400 <your-key.pem>
$ ssh -i “<your-key.pem>” ec2-user@<test-instance-publicIPAddress>

Multi-Cloud Transit List of Transit Gateways

In the UI, go to MULTI-CLOUD TRANSIT > List > Transit tab. If you built both the AWS and the Azure Transits and left the names, regions, and VPC/VNet CIDRs as default, then you should receive a screen similar to this:

Multi-Cloud Transit List of Spoke Gateways

In the UI, go to MULTI-CLOUD TRANSIT > List > Spokes tab. If you built both the AWS and the Azure Transits and left the names, regions, and VPC/VNet CIDRs as default, then you should receive a screen similar to this:

End-to-end Verification from FlightPath

From the Controller, go to TROUBLESHOOT > FlightPath and run a series of end-to-end test from one Test instance to the other using their Private IP addresses. Note that the Test instances have a prefix of Spoke. Run the following tests:

• ICMP – This should succeed
• SSH (TCP 22) – This should succeed
• HTTPS (TCP 443) – This should fail because a Security Group denies it

Sample results from the HTTPS test are shown below:

 

Gateway Utility

Navigate to TROUBLESHOOT > Diagnostics > Network tab. From any Gateway, perform an ICMP test. For example, if you have the default environment, from AZ-EU-Spoke1-GW, issue a Ping to www.aviatrix.com. You should receive output such as this:

 

Network Connectivity Utility

Navigate to TROUBLESHOOT > Diagnostics > Network tab. In the Hostname field, enter the IP address of a test instance, protocol TCP, and port 22. Pick an AWS Gateway (either Spoke or Transit). You should receive a screen similar to this:

  

Packet Capture

Navigate to TROUBLESHOOT > Diagnostics > Packet Capture to perform a packet capture. This shows a capture taken while SSH was attempted on one of the test instances:

Network Validation

Navigate to TROUBLESHOOT > Diagnostics > Network Validation to select the Source and Destination Account, Region, and Network to perform a connectivity test in AWS. The Aviatrix Controller will spin up two instances and run a connectivity test. You can leave these instances running or delete them when you’re done. You should receive a screen similar to this:

Deployment and Provisioning

VPC Tracker

Go to USEFUL TOOLS > VPC Tracker If you built both the AWS and the Azure Transits and left the names, regions, and VPC/VNet CIDRs as default, then you should receive a screen similar to this:

Notice the following:

This list of VPCs is pulled from all the accounts you have onboarded. If you have a new AWS account, then typically you have a default VPC with default 172.31.0.0/16 CIDR subnet in a few regions as per AWS documentation.

Enter a few CIDRs in the text field at the top and hit Test. Deliberately pick a CIDR that already exists. For example, if you have the default environment and test the availability of 10.62.0.0/16, you should receive a screen similar to this:

If you have the default environment and test the availability of 10.63.0.0/16, you should receive a screen similar to this:

 

Create a VPC

After verifying that the Network CIDR does not overlap anywhere in your network, create a new VPC directly from the Controller.

Note: The Destroy button in the top right corner of Sandbox Starter Tool will only destroy resources that it created. If you manually create a resource such as a VPC from the Controller UI, you are responsible for its lifecycle and charges incurred.

To create a VPC, navigate to USEFUL TOOLS > Create a VPC

Secure Egress Traffic - FQDN Filter

Note: This test will require creating additional resources from the Controller UI. You are responsible for their lifecycle and the charges incurred. The charges will be about $0.02 an hour if you choose AWS t2.micro instances.

In this lab, you can test the Egress FQDN feature, an inexpensive replacement for an AWS NAT Gateway that can filter Internet-bound egress traffic initiated from workloads in a VPC. This service is centrally managed by the Aviatrix Controller and executed by an Aviatrix gateway instance in the VPC in a distributed architecture.

This adds one test instance and one Aviatrix Gateway to the architecture as shown in the red oval here:

 

To perform this test, follow these steps:

1. The Aviatrix Controller already builds a few private subnets. Pick one and from the AWS Console, create a t2.micro test instance in Spoke1-VPC in that private subnet. Make sure Auto-assign Public IP is set to Disable. Give it a name such as AWS-UE2-Egress-FQDN-test. Ensure that its Security Group allows all traffic.
2. From the Aviatrix Controller, deploy a Gateway in Spoke1-VPC as follows:
   Navigate to GATEWAY > + CREATE NEW
   Create a Gateway in AWS-UE2-Spoke1-VPC-Public-0-us-east-2a Public Subnet in AWS-UE2-Spoke1-VPC as shown here:
     

3. Since the Egress FQDN test VM has no Public IP, you will need to use one of the other test VMs as a jump box (i.e. bastion host). Also copy the private SSH key to the ~/.ssh directory and then SSH to the Private IP. For example,

   [ec2-user@ip-10-61-53-107 ~]$ chmod 400 .ssh/acelab.pem
   [ec2-user@ip-10-61-53-107 ~]$ ssh -i .ssh/acelab.pem ec2-user@10.61.0.199
   Last login: Sat May 22 21:12:59 2021 from ip-10-61-53-107.us-east-2.compute.internal
   
          __|  __|_  )
          _|  (     /   Amazon Linux 2 AMI
         ___|\___|___|
   
   https://aws.amazon.com/amazon-linux-2/
   [ec2-user@ip-10-61-0-199 ~]$
   

   
   Once you are on the Egress FQDN test VM, issue a few Egress FQDN actions:

   [ec2-user@ip-10-61-0-199 ~]$ curl google.com
   ^C
   [ec2-user@ip-10-61-0-199 ~]$ sudo yum update -y
   Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
   Could not retrieve mirrorlist https://amazonlinux-2-repos-us-east-2.s3.us-east-2.amazonaws.com/2/core/latest/x86_64/mirror.list error was
   12: Timeout on https://amazonlinux-2-repos-us-east-2.s3.us-east-2.amazonaws.com/2/core/latest/x86_64/mirror.list: (28, 'Connection timed out after 5000 milliseconds')
   
   
   One of the configured repositories failed (Unknown),
   and yum doesn't have enough cached data to continue. At this point the only
   safe thing yum can do is fail. There are a few ways to work "fix" this:
   
        1. Contact the upstream for the repository and get them to fix the problem.
   
        2. Reconfigure the baseurl/etc. for the repository, to point to a working
           upstream. This is most often useful if you are using a newer
           distribution release than is supported by the repository (and the
           packages for the previous distribution release still work).
   
        3. Run the command with the repository temporarily disabled
               yum --disablerepo=<repoid> ...
   
        4. Disable the repository permanently, so yum won't use it by default. Yum
           will then just ignore the repository until you permanently enable it
           again or use --enablerepo for temporary usage:
   
               yum-config-manager --disable <repoid>
           or
               subscription-manager repos --disable=<repoid>
   
        5. Configure the failing repository to be skipped, if it is unavailable.
           Note that yum will try to contact the repo. when it runs most commands,
           so will have to try and fail each time (and thus. yum will be be much
           slower). If it is a very temporary problem though, this is often a nice
           compromise:
   
               yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true
   
   Cannot find a valid baseurl for repo: amzn2-core/2/x86_64
   [ec2-user@ip-10-61-0-199 ~]$

   Notice that this test instance, which is in a Private Subnet, has no way to communicate externally. Therefore, all Egress traffic fails.

4. Enable Egress FQDN Discovery. Navigate to SECURITY > Egress Control > 2 (Optional) Egress FQDN Discovery. Enable the Egress FQDN Gateway you created in this section from the Controller UI as shown in here:
   

5. Now try issuing those same Egress FQDN commands again.

   [ec2-user@ip-10-61-0-199 ~]$ curl google.com
   <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
   <TITLE>301 Moved</TITLE></HEAD><BODY>
   <H1>301 Moved</H1>
   The document has moved
   <A HREF="http://www.google.com/">here</A>.
   </BODY></HTML>
   [ec2-user@ip-10-61-0-199 ~]$ sudo yum update -y
   Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
   amzn2-core                                                                                                                                                                         | 3.7 kB  00:00:00
   amzn2extra-docker                                                                                                                                                                  | 3.0 kB  00:00:00
   (1/5): amzn2-core/2/x86_64/group_gz                                                                                                                                                | 2.5 kB  00:00:00
   (2/5): amzn2-core/2/x86_64/updateinfo                                                                                                                                              | 367 kB  00:00:00
   (3/5): amzn2extra-docker/2/x86_64/updateinfo                                                                                                                                       |   76 B  00:00:00
   (4/5): amzn2extra-docker/2/x86_64/primary_db                                                                                                                                       |  78 kB  00:00:00
   (5/5): amzn2-core/2/x86_64/primary_db                                                                                                                                              |  52 MB  00:00:01
   No packages marked for update
   [ec2-user@ip-10-61-0-199 ~]$

   The new Aviatrix Gateway allows all outbound traffic and you can see domains that were reached above:
     

6. Click on the Download button to download the results, then Stop Egress FQDN Discovery, and enable Egress FQDN Filter that permits HTTP traffic to google.com and HTTPS traffic to the amazonaws.com domain that is needed for AWS yum updates. To do so, navigate to SECURITY > Egress Control > 3 Egress FQDN Filter > + New Tag and give the Tag a name, such as SST-Tag, shown here:   

7. Next, edit this tag and add new filters based on the discovery results, such shown below. Click Import to upload the results file. Then click on Update to Save.
   

   These two filters will match HTTPS (TCP 443) traffic to amazonlinux-2-repos-us-east-2.s3.us-east-2.amazonaws.com and HTTP (TCP 80) traffic to google.com. However, you will not be able to access facebook.com over HTTP/HTTPS or ping google.com. You can add new rules with wildcards.
   
   Set the Tag to White List, attach it to the Egress FQDN gateway, and ensure that the Tag is Enabled so that the configuration resembles this:
   

   Now, the same Egress actions result in the following:

   [ec2-user@ip-10-61-0-199 ~]$ curl google.com
   <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
   <TITLE>301 Moved</TITLE></HEAD><BODY>
   <H1>301 Moved</H1>
   The document has moved
   <A HREF="http://www.google.com/">here</A>.
   </BODY></HTML>
   [ec2-user@ip-10-61-0-199 ~]$ sudo yum update -y
   Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
   amzn2-core                                                                                                                                                                         | 3.7 kB  00:00:00
   No packages marked for update
   [ec2-user@ip-10-61-0-199 ~]$ curl facebook.com
   ^C
   [ec2-user@ip-10-61-0-199 ~]$ ping google.com
   PING google.com (142.250.191.174) 56(84) bytes of data.
   ^C
   --- google.com ping statistics ---
   6 packets transmitted, 0 received, 100% packet loss, time 5113ms
   
   [ec2-user@ip-10-61-0-199 ~]$

   As you can see, there are fine controls for Egress Traffic based on FQDNs.

If you have any questions about Aviatrix Sandbox Starter Tool, don't hesitate to contact us at kickstart@aviatrix.com.