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


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.


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-WE-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 CIDR subnet in a few regions.

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, 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: any resources that are created from the Controller and not Terraform, will not be destroyed by Terraform if/when you decide to remove the infrastructure from Terraform. In other words, the terraform destroy command will only destroy resources that were created by Terraform. If you create a resource such as a VPC from the Controller UI, you are responsible for its lifecycle and charges incurred.

If you have the default environment and decide to create, you should receive screens similar to the following:


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 Controller and executed by an Aviatrix gateway instance in the VPC in the 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-EW1-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-EW1-Spoke1-VPC-Public-0-eu-west-1a Public Subnet in AWS-EW1-Spoke1-VPC as shown here:
  3. Issue a few Egress FQDN actions:

    [ec2-user@ip-10-61-29-14 ~]$ ping google.com
    PING google.com ( 56(84) bytes of data.
    --- google.com ping statistics ---
    4 packets transmitted, 0 received, 100% packet loss, time 3052ms
    [ec2-user@ip-10-61-29-14 ~]$ curl aviatrix.com
    [ec2-user@ip-10-61-29-14 ~]$ curl google.com
    [ec2-user@ip-10-61-29-14 ~]$

    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-29-14 ~]$ ping google.com
    PING google.com ( 56(84) bytes of data.
    64 bytes from ig-in-f101.1e100.net ( icmp_seq=1 ttl=49 time=1.63 ms
    64 bytes from ig-in-f101.1e100.net ( icmp_seq=2 ttl=49 time=1.62 ms
    64 bytes from ig-in-f101.1e100.net ( icmp_seq=3 ttl=49 time=1.53 ms
    64 bytes from ig-in-f101.1e100.net ( icmp_seq=4 ttl=49 time=1.61 ms
    64 bytes from ig-in-f101.1e100.net ( icmp_seq=5 ttl=49 time=1.57 ms
    --- google.com ping statistics ---
    5 packets transmitted, 5 received, 0% packet loss, time 4006ms
    rtt min/avg/max/mdev = 1.530/1.596/1.636/0.052 ms
    [ec2-user@ip-10-61-29-14 ~]$ 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>.
    [ec2-user@ip-10-61-29-14 ~]$ curl aviatrix.com
    <head><title>301 Moved Permanently</title></head>
    <center><h1>301 Moved Permanently</h1></center>
    [ec2-user@ip-10-61-29-14 ~]$ ping www.aviatrix.com
    PING aviatrix.com ( 56(84) bytes of data.
    64 bytes from ( icmp_seq=1 ttl=31 time=107 ms
    64 bytes from ( icmp_seq=2 ttl=31 time=107 ms
    --- aviatrix.com ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1001ms
    rtt min/avg/max/mdev = 107.289/107.501/107.713/0.212 ms
    [ec2-user@ip-10-61-29-14 ~]$

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

  6. Stop Egress FQDN Discovery and enable Egress FQDN Filter that permits HTTP traffic to *.aviatrix.com only. To do so, navigate to SECURITY > Egress Control > 3 Egress FQDN Filter > + New Tag and give the Tag a name, such as KS-Tag. Specify Domain Name Filters, such as here:

  7. Next, edit this tag and add new filters, such shown below. Click + Insert Rule to add new rules. Then click on Update to Save.

    Note the usage of wild cards.
    These two filters will match HTTPS (TCP 443) traffic to *.aviatrix.com and ICMP traffic to google.com. However, they will not match (HTTP TCP 80) traffic to *.aviatrix.com or ICMP to www.google.com.
    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-29-14 ~]$ curl http://www.aviatrix.com
    curl: (52) Empty reply from server
    [ec2-user@ip-10-61-29-14 ~]$ curl https://www.aviatrix.com
    <head><title>301 Moved Permanently</title></head>
    <center><h1>301 Moved Permanently</h1></center>
    [ec2-user@ip-10-61-29-14 ~]$
    [ec2-user@ip-10-61-29-14 ~]$
    [ec2-user@ip-10-61-29-14 ~]$ curl https://google.com
    curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to google.com:443
    [ec2-user@ip-10-61-29-14 ~]$ ping google.com
    PING google.com ( 56(84) bytes of data.
    64 bytes from ig-in-f102.1e100.net ( icmp_seq=1 ttl=49 time=1.68 ms
    64 bytes from ig-in-f102.1e100.net ( icmp_seq=2 ttl=49 time=1.86 ms
    64 bytes from ig-in-f102.1e100.net ( icmp_seq=3 ttl=49 time=1.63 ms
    --- google.com ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2003ms
    rtt min/avg/max/mdev = 1.639/1.729/1.861/0.101 ms
    [ec2-user@ip-10-61-29-14 ~]$ ping www.google.com
    PING www.google.com ( 56(84) bytes of data.
    --- www.google.com ping statistics ---
    6 packets transmitted, 0 received, 100% packet loss, time 5108ms
    [ec2-user@ip-10-61-29-14 ~]$

    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

Reply Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
Like Follow
  • 3 mths agoLast active
  • 339Views
  • 1 Following