0

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

10replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Hi Umair

    In the VPC Tracker section of the 'Test Plan'  example,  the following is stated:

    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.

    I notice the VPC Tracker 'Screen shot' lists (for example)  10.61.0.0/16 CIDR that appears to be 'owned' by an account called  'aws-account'. therefore the question I have is:

    1 - Is 'aws-account' a new account as it has a 10.61.0.0/16 CIDR and also a 172.31.0.0/16 CIDR?

    Additionally - I notice that the VPC Tracker 'Screen shot' appears to show that these 172.31.0.0/16 CIDR have no 'instances', so - the question I have is:

    2 - Does this mean Aviatrix has 'onboarded' a VPC that had no Spoke Gateways configured for the VPC?

    regards

    Like
    • Hi  Jeffrey,

      1) If you look at line 65 of the source code, you'll notice that aws-account is the name of the AWS account that we onboard in the Controller. It is the one responsible for creating the 10.61.0.0/16 CIDR block in that screenshot.

      2) AWS created the default VPC in each region with the default 17.31.0.0/16 CIDR block as per their documentation. We report those VPCs for the accounts that have been onboarded to the Controller. In this case, it is for aws-account only. We didn't 'onboard' or create the VPC: AWS did that already.

      Hope that helps.

      Like
  • Yes it does, thanks.

    Like
  • Secure Egress Traffic - FQDN Filter

    Hi Umair

    While following the steps in this exercise I have noticed that the accompanying screenshots make reference to subnet 10.61.64.0/20 as being allocated to region eu-west (Ireland). However CIDR 10.61.0.0/16 is allocated to US East 2 (Ohio). I've looked at the 3 subnets listed for  eu-west1 (Ireland) under my AWS account and these are all 172.31.x.x /20 

    Can you confirm:

    Should the example - showing the gateway being deployed in eu-west1 (Ireland) - be ignored and I just pick another region/cloud of my choice?

    If - I have mis-read or mis-understood the steps, could you please clarify, what region/cloud/subnet in the FQDN filter test plan can be used for this deployment.

    regards

    Like
    • Hi Jeffrey Hazel , it's just a matter of an old screenshot. I will update it. Thanks for bringing to our attention.

      Like
  • Umair

    While you're there - Step 3 of the 'Egress FQDN' test plan states to do the following:


    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

    [ec2-user@ip-10-61-29-14 ~]$ curl aviatrix.com
    ^C
    [ec2-user@ip-10-61-29-14 ~]$ curl google.com
    ^C
    [ec2-user@ip-10-61-29-14 ~]$

    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    My question is:

    What AWS instance do I action these steps from? - as:

    1 - I have no access to the Spoke1-VM or Spoke2-VM (I have no keys/passwords to these instances)
    2 - Creation of the 'Egress-FQDN-test' instance stated to create 'Egress-FQDN-test' without a public address (is there a 'back door' to this instance via it's private address?)

    If there is somewhere on the forum site that holds the keys/passwords, can you please advise or maybe I have mis-understood what I need to do?

    Currently - the way I view things is that I have no way of being able to use any of these instances without creating another instance, with a public address, and use that as a 'jump-off server'.

    Like
    • Jeffrey Hazel You would use the "Key Pair" for example "ohio-kp" that you provided during the deployment process (https://community.aviatrix.com/t/g9hx9jh ) to ssh into the EC "Spoke1-VM". It has a public IP and it is your jumphost. From here, you would ssh into EC2 "AWS-EW1-Egress-FQDN-test" and run those tests.

      Like
    • Shahzad Ali  Looks like I forgot to mention that neither Spoke 1-VM or  Spoke 2-VM appear to have been built/created with a public IP. Please see below for Sandbox VM Instances screen print from AWS Console.

      ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

      Instance summary for i-017ab0dda118759e3 (Spoke1-VM) Info
      Updated less than a minute ago

      Connect

      Instance state
      Instance ID

       i-017ab0dda118759e3 (Spoke1-VM)
      Public IPv4 address

      Private IPv4 addresses

       10.61.64.131
      Instance state
       Stopped
      Public IPv4 DNS

      Private IPv4 DNS

       ip-10-61-64-131.us-east-2.compute.internal
      Instance type
      t2.micro
      Elastic IP addresses

      VPC ID

       vpc-00c43c253e461f34f (AWS-UE2-Spoke1-VPC) 
      AWS Compute Optimizer finding
      Opt-in to AWS Compute Optimizer for recommendations. | Learn more 
      IAM Role

      Subnet ID

       subnet-074d66dbfed4b8321 (AWS-UE2-Spoke1-VPC-Public-0-us-east-2a) 

      +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


      Instance summary for i-0814d1ab0f6006987 (Spoke2-VM) Info
      Updated less than a minute ago

      Connect

      Instance state
      Instance ID

       i-0814d1ab0f6006987 (Spoke2-VM)
      Public IPv4 address

      Private IPv4 addresses

       10.62.67.120
      Instance state
       Stopped
      Public IPv4 DNS

      Private IPv4 DNS

       ip-10-62-67-120.us-east-2.compute.internal
      Instance type
      t2.micro
      Elastic IP addresses

      VPC ID

       vpc-0e3026bec701f2826 (AWS-UE2-Spoke2-VPC) 
      AWS Compute Optimizer finding
      Opt-in to AWS Compute Optimizer for recommendations. | Learn more 
      IAM Role

      Subnet ID

       subnet-0e7c1e4bd749b4139 (AWS-UE2-Spoke2-VPC-Public-0-us-east-2a) 

      ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       

      Comments Welcome

      regards

      Like
  • Hi Shahzad

    Apologies - please ignore my last posting, looks like I checked on the wrong instances. I'll try the access from the Spoke gateways.

     

    regards

    Like
    • Jeffrey Hazel, not a problem. I know Umair Hoodbhoy is helping you too.

      Like
Like Follow
  • 4 mths agoLast active
  • 10Replies
  • 724Views
  • 4 Following