VMware Hands-on Labs - HOL-2037-01-NET


Lab Overview - HOL-2037-01-NET - VMware NSX Advanced Load Balancer (Avi Networks) - Getting Started

Lab Guidance


Note: It will take more than 90 minutes to complete this lab. You should expect to only finish 2-3 of the modules during your time.  The modules 1, 2, 3 don't have dependencies, however modules 4, 5, 6 will require lab 3 to be completed. In order to start lab 4, 5 or 6 - please use "HOL-2037 Module Switcher" script located on desktop of main console.  There are optional sections within each of module, that can be skipped and don't create dependencies on next tasks or modules. You can use the Table of Contents to access any module of your choosing.

The Table of Contents can be accessed in the upper right-hand corner of the Lab Manual.

Avi Networks provides a next-generation application delivery fabric that spans on-premises and cloud environments. The centrally managed solution consists of a Smart Load Balancer and Intelligent Web Application Firewall (iWAF) that provides automation, analytics, and security for all applications across hybrid environments.

In this lab, you will be introduced to the core capabilities of Avi Load Balancer in a vSphere environment. You will gain hands-on experience with Infrastructure and Application components of Avi Load Balancer such as Cloud Connector, Service Engine Groups, Virtual Services, Rules and Policies, Operations and Analytics.

Lab Module List:

 Lab Captains: 

 This lab manual can be downloaded from the Hands-on Labs Document site found here:

http://docs.hol.vmware.com

This lab may be available in other languages.  To set your language preference and have a localized manual deployed with your lab, you may utilize this document to help guide you through the process:

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

Location of the Main Console

 

  1. The area in the RED box contains the Main Console.  The Lab Manual is on the tab to the Right of the Main Console.
  2. A particular lab may have additional consoles found on separate tabs in the upper left. You will be directed to open another specific console if needed.
  3. Your lab starts with 90 minutes on the timer.  The lab can not be saved.  All your work must be done during the lab session.  But you can click the EXTEND to increase your time.  If you are at a VMware event, you can extend your lab time twice, for up to 30 minutes.  Each click gives you an additional 15 minutes.  Outside of VMware events, you can extend your lab time up to 9 hours and 30 minutes. Each click gives you an additional hour.

 

 

Alternate Methods of Keyboard Data Entry

During this module, you will input text into the Main Console. Besides directly typing it in, there are two very helpful methods of entering data which make it easier to enter complex data.

 

 

Click and Drag Lab Manual Content Into Console Active Window

You can also click and drag text and Command Line Interface (CLI) commands directly from the Lab Manual into the active window in the Main Console.  

 

 

Accessing the Online International Keyboard

 

You can also use the Online International Keyboard found in the Main Console.

  1. Click on the Keyboard Icon found on the Windows Quick Launch Task Bar.

 

 

Activation Prompt or Watermark

 

When you first start your lab, you may notice a watermark on the desktop indicating that Windows is not activated.  

One of the major benefits of virtualization is that virtual machines can be moved and run on any platform.  The Hands-on Labs utilizes this benefit and we are able to run the labs out of multiple datacenters.  However, these datacenters may not have identical processors, which triggers a Microsoft activation check through the Internet.

Rest assured, VMware and the Hands-on Labs are in full compliance with Microsoft licensing requirements.  The lab that you are using is a self-contained pod and does not have full access to the Internet, which is required for Windows to verify the activation.  Without full access to the Internet, this automated process fails and you see this watermark.

This cosmetic issue has no effect on your lab.  

 

 

Look at the lower right portion of the screen

 

Please check to see that your lab is finished all the startup routines and is ready for you to start. If you see anything other than "Ready", please wait a few minutes.  If after 5 minutes your lab has not changed to "Ready", please ask for assistance.

 

Introduction



 

Architectural Overview

The Avi Vantage platform is built on software-defined principles, enabling a next generation architecture to deliver the flexibility and simplicity expected by IT and lines of business. The Avi Vantage architecture separates the data and control planes to deliver application services beyond load balancing, such as application analytics, predictive autoscaling, micro-segmentation, and self-service for app owners in both on-premises or cloud environments. The platform provides a centrally managed, dynamic pool of load balancing resources on commodity x86 servers, VMs or containers, to deliver granular services close to individual applications. This allows network services to scale near infinitely without the added complexity of managing hundreds of disparate appliances.

 

The Avi Controller cluster uses big data analytics to analyze the data and present actionable insights to administrators on intuitive dashboards on the Avi Admin Console.

Avi Vantage provides out-of-the-box integrations for on-premises or cloud deployments. These integrations with private cloud frameworks, SDN controllers, container orchestration platforms, virtualized environments and public clouds enable turnkey application services and automation.

 

 

Avi Vantage Components

The Avi Vantage Platform has three core components  Avi Service Engines, Avi Controller cluster, and Avi Admin Console

 

 

Service Engine

 

Avi Service Engines (SEs) handle all data plane operations within Avi Vantage by receiving and executing instructions from the Controller. The SEs perform load balancing and all client- and server-facing network interactions. It collects real-time application telemetry from application traffic flows. High availability is supported.

In a typical load balancing scenario, a client will communicate with a virtual service, which is an IP address and port hosted in Avi Vantage by an SE. The virtual service internally passes the connection through a number of profiles. For HTTP traffic, the SE may terminate and proxy the client TCP connection, terminate SSL, and proxy the HTTP request. Once the request has been validated, it will be forwarded internally to a pool, which will choose an available server. A new TCP connection then originates from the SE, using an IP address of the SE on the internal network as the requests source IP address. Return traffic takes the same path back. The client communicates exclusively with the virtual service IP address, not the real server IP.

 

 

Controller

 

 The Avi Controller is a single point of management and control that is the brain of the entire Avi Vantage system, and typically deployed as a redundant three-node cluster. The entire Avi Vantage system is managed through a centralized point (and IP address) regardless of the number of new applications being load balanced and the number of SEs required to handle the load. Via its REST API, it provides visibility into all applications configured . Controllers can automatically create and configure new SEs as new applications are configured via virtual services (in write access mode deployments).

Controllers continually exchange information securely with the SEs and with one other. The server health, client connection statistics, and client-request logs collected by the SEs are regularly offloaded to the Controllers, which share the processing of the logs and analytics information. The Controllers also send commands down to the SEs, such as configuration changes. Controllers and SEs communicate over their management IP addresses.

 

 

Console

The Avi Console is a modern web-based user interface that provides role-based access to control, manage and monitor applications. Its capabilities are likewise available via the Avi CLI. All services provided by the platform are available as REST API calls to enable IT automation, developer self-service, and a variety of third party integrations.

 

 

Data Plane Scaling

Virtual services may be scaled across one or more SEs using either native (L2 punting) or BGP-based load balancing techniques.

When a virtual service is scaled across multiple SEs, each of those SEs share the load. This sharing may not be equal, because the actual workload distribution depends on the available CPU and other resources that may be required of the SE. SEs typically process traffic for more than one virtual service at a time.

 

 

When native SE scaling is used, one SE will be the primary for a given virtual service and will advertise that virtual services IP address from the SEs own MAC address. The primary SE may either process and load balance a client connection itself, or it may forward the connection via layer 2 to the MAC address of one of the secondary SEs having available capacity.

Each SE will load balance and forward traffic to servers using its own IP address within the server network as the source IP address of the client connection. This ensures that even though multiple SEs may be sending traffic to the same pool of servers, return traffic takes the same path from the servers back through the same SE. When deployed in a VMware environment and the SEs are scaled out, the secondary SEs will respond directly back to clients without passing the return traffic back through the primary SE.

 

 

Lab Architecture

 

 

Module 1 - Cloud Connector Configuration Review (15 minutes)

Cloud Connector Configuration Review


The goal of this module is to introduce and review the basics of VMware Cloud Connector configuration. Please use Chrome or Firefox for the lab exercises.

Clouds are containers for the environment that Avi Vantage is installed or operating within. During initial setup of Avi Networks platform, a default cloud, named Default-Cloud, is created. This is where the first Controller is deployed, into Default-Cloud. Additional clouds may be added, containing SEs and virtual services.

For deploying redundant Controllers in a 3-node cluster, all three Controllers must be deployed in the same cloud.

Avi Vantage runs on virtual machines (VMs) managed by VMware vCenter. When deployed into a vCenter-managed VMware cloud, Avi Networks platform performs as a fully distributed, virtualized system consisting of the Avi Controller and Avi Service Engines each running as a VM.

The Avi Vantage platform is built on software-defined architectural principles which separate the data plane and control plane. The product components include:

Note: Avi Controllers need access to the desired ESXi hosts (over port 443) to allow the Avi Controller-to-vCenter communication.

The Avi Controller can be deployed as a single VM or as a high availability cluster of 3 Avi Controller instances, each running on a separate VM.

Note: VM migration of the Controller and Service Engine images using vMotion is not supported. It is recommended to use Avi Vantages built-in virtual service migration functionality.

Knowledge base references(s): 


 

Launch Chrome

 

From the Main Console, launch Chrome.

 

 

Access Avi Vantage Controller in Region A

 

  1. Open the Avi Controller in Region A from the bookmarks on Chrome browser and click on Avi Vantage Controller A.

 

 

Log in

 

Username: admin
Password: VMware1!

 

 

Review Cloud Connector Configuration

 

  1. Navigate to top corner to open the list of tabs
  2. Click Infrastructure tab.

 

 

Clouds

 

Next, validate the state of existing cloud “Default-Cloud

  1. Click on the Cloud tab
  2. Hover your mouse over the status button.

 

 

Edit Cloud

 

  1. Review cloud Default-Cloud configuration by clicking on Pencil button.

 

 

Edit Cloud - Infrastructure

 

Avi Vantage can be deployed with a VMware cloud in either no access, read access, or write access mode. Each mode is associated with different functionality and automation, and also requires different levels of privileges for Avi Controller within VMware vCenter. For complete information, refer to attached knowledge base references.

  1. Write access is the recommended deployment mode. It is the quickest and easiest way to deploy and offers highest levels of automation between Avi Vantage and vCenter.
  2. Click on the Data Center and then the Network tab to review them.

 

 

 

Edit Cloud - Data Center

 

As you have noticed, VMware Write Access integration requires a few infrastructure configuration details to be successfully initialized:

IPAM and DNS profiles are optional and will be used in the lab to perform auto-allocation of IPs and FQDNs to Virtual Services.

  1. Click the Network tab.

 

 

Edit Cloud - Network

 

When Avi Cloud Connector indicates Cloud is ready for Virtual Services placement that means all prerequisites met to perform the deployment of Avi Service Engines and proceed with Virtual Services placement.

The Avi Controller interacts with vCenters OVF Manager to spawn an SE VM. The Controller needs the following access while in write access mode.

  1. Click the Save button.

 

 

(Optional) Review Cloud Connector Configuration leveraging REST API interface

 

  1. Open a new Chrome tab

 

 

Access URL

 

  1. Access the following URL in the next Chrome tab:
https://avicon-01a.corp.local/api/cloud?include_name

NOTE: You can highlight the URL in the manual and drag/drop it in to the Chrome browser on the Main Console.

As you can observe Avi REST API interface allows to easily access the configuration state of the cloud component.

To access the runtime state of cloud configuration Inventory API. Inventory APIs bring together configuration, runtime, health score, alert, and metrics information about objects under 1 API. While the information provided will not be as complete as making a request to each specific endpoint, these APIs provide a good snapshot of your objects with 1 request.

 

 

Access Cloud Inventory URL

 

  1. Open another Chrome tab and enter this URL:
https://avicon-01a.corp.local/api/cloud-inventory?include_name

Compare with the previous REST API tab

Learn more about Avi REST API interface using built-in swagger: https://avinetworks.com/docs/18.2/openapi-swagger-2-0-specification-integration/

 

 

(Optional) Review Cloud Connector Configuration leveraging Avi Command Line Interface

 

  1. From the taskbar, Open SSH client Putty.

 

 

Select Avi Controller - Region A

 

  1. Select Avi Controller in Region A -  avicon-01a.corp.local
  2. Click Load
  3. Click Open

 

 

Log In

 

When prompted for the password, use the following:


Password: VMware1!

 

 

Access AVI CLI

 

Type the following command to access the Avi command line interface:

shell

 

 

Log in

 

Log in with the following credentials:

 

 

Show Cloud

 

Type the following to show the cloud configuration for the Default-Cloud:

show cloud Default-Cloud

 

 

Show Cloud Status

 

To see the status, type the following command:

show cloud Default-Cloud status

 

 

Display API Details

 

Any interaction with Avi Control Plane are based on REST API and Avi Command Line Interface is not exception. Avi Shell REST API queries can be seen by entering typing:

terminal display_api_details

Then enter:

show cloud Default-Cloud status

As you can observe similar REST API path was used to obtain runtime state of Default-Cloud as in REST API exercise.

 

Module 1 Conclusion


In this module you learned the Day 0 configuration of Avi Cloud Connector which allows Avi Controller to interface with vCenter and discover all the required resources to automate Virtual Service placement.

Knowledge base references(s):


 

You have finished Module 1

Congratulations on completing Module 1.

It is recommended that you proceed to next module in order to understand basics of Virtual Service before starting with any other module:

 

Module 2 - Introduction to Applications (Virtual Services and Related Components) (60 minutes)

Introduction to Applications (Virtual Services and Related Components)


The goal of this module is to introduce and review the basics of Virtual Service configuration and related components. Please use Chrome or Firefox for the lab exercises.

Virtual services are the core of the Avi Vantage load-balancing and proxy functionality. A virtual service advertises an IP address and ports to the external world and listens for client traffic. When a virtual service receives traffic, it may be configured to:

A virtual service can be thought of as an IP address that Vantage is listening to, ready to receive requests. In a normal TCP/HTTP configuration, when a client connects to the virtual service address, Vantage will process the client connection or request against a list of settings, policies and profiles, then send valid client traffic to a back-end server that is listed as a member of the virtual services pool.

Typically, the connection between the client and Vantage is terminated or proxied at the SE, which opens a new TCP connection between itself and the server. The server will respond back directly to the Vantage IP address, not to the original client address. Vantage forwards the response to the client via the TCP connection between itself and the client.

A typical virtual service consists of a single IP address and service port that uses a single network protocol. Vantage allows a virtual service to listen to multiple service ports or network protocols.

For instance, a virtual service could be created for both service port 80 (HTTP) and 443 SSL (HTTPS). In this example, clients can connect to the site with a non-secure connection and later be redirected to the encrypted version of the site. This allows administrators to manage a single virtual service instead of two. Similarly, protocols such as DNS, RADIUS and Syslog can be accessed via both UDP and TCP protocols.

It is possible to create two unique virtual services, where one is listening on port 80 and the other is on port 443; however, they will have separate statistics, logs, and reporting. They will still be owned by the same Service Engines (SEs) because they share the same underlying virtual service IP address.

To send traffic to destination servers, the virtual service internally passes the traffic to the pool corresponding to that virtual service. A virtual service normally uses a single pool, though an advanced configuration using policies or DataScripts can perform content switching across multiple pools. A script also can be used in lieu of a pool, such as a virtual service that only performs an HTTP redirect.

A pool or poolgroup can be assigned to multiple virtual services.

When creating a virtual service, that virtual service listens to the client-facing network, which is most likely the upstream network where the default gateway exists. The pool connects to the server network.

Normally, the combined virtual service and pool are required before Vantage can place either object on an SE. When making an SE placement decision, Avi Vantage must choose the SE that has the best reachability or network access to both client and server networks. Alternatively, both the clients and servers may be on the same IP network.

Knowledge base references(s):


 

Launch Chrome

 

From the Main Console, launch Chrome.

 

 

Access Avi Vantage Controller in Region A

 

  1. Open the Avi Controller in Region A from the bookmarks on Chrome browser and click on Avi Vantage Controller A.

 

 

Log in

 

Username: admin
Password: VMware1!

 

 

Create Virtual Service app-01a

 

Let's create your first HTTP virtual service which will load balance HTTP traffic across two web servers.

  1. On the Dashboard, select Create Virtual Service
  2. Select Advanced Setup

 

 

New Virtual Service

 

Create HTTP Virtual Service “app-01a” with the parameters below:

  1. Name: app-01a
  2. Enable Auto Allocate under Floating IPv4
  3. Click the scroll bar to move further down in the dialog box.

 

 

New Virtual Service (cont.)

 

  1. Click in the Network for VIP Address Allocation box and select VIP-RegionA01-vDS-COMP - 192.168.130.0/24
  2. In the IPv4 Subnet box, select 192.168.130.0/24
  3. Scroll to the bottom of the dialog box.

 

 

Create Pool

 

  1. Note that the service port is 80
  2. Click in the box under Pool
  3. Select Create Pool (this will bring up a new wizard to create the pool).

 

 

New Pool - Settings

 

Create the new pool with these parameters:

  1. Leave the Name set to app-01a-pool
  2. The Default Service Port should be set to 80
  3. Ensure the box next to Passive Health Monitor is ticked.
  4. Click on the Add Active Monitor box.
  5. Select System-HTTP.

 

 

New Pool - Verify

 

Make sure the setting are correct.

  1. Click Next to continue.

 

 

New Pool - Servers

 

  1. Click on Select Servers by Network.

 

 

Select Servers

 

  1. From the Select a Network drop-down box, choose VM-RegionA01-vDS-COMP - 192.168.120.0/24 (note that you may have to scroll down to see it).
  2. Select both web-01a and web-02a from the list of servers.
  3. Click the Add Servers button.

 

 

 

Members Added

 

  1. Click Next

 

 

New Pool - Advanced

 

Nothing will be changed in the Advanced section.

  1. Click Next to continue.

 

 

New Pool - Review

 

Here you can review the settings for the new pool.

  1. Click Save to create the new pool.

 

 

New Virtual Service - Advanced

 

  1. Back in the New Virtual Service wizard, click on the Step 4 - Advanced tab.

 

 

New Virtual Service - Save

 

  1. Click the Save button to create the new Virtual Service.

 

 

Virtual Service - app-01a

 

  1. Click on Virtual Service: app-01a

 

As Virtual Service “app-01a” has been created, it was mapped to default service engine group Default-Group and placed on one of service engines within the group.

 

 

Web Service - app-01a

 

Open new tab within the browser and reach the newly created virtual service app-01a using http://app-01a.region01a.corp.local

 

 

Virtual Service Logs

 

  1. Go back to the Avi Vantage Controller tab.
  2. Click Logs.


By default:

 

 

Non-Significant Logs

 

  1. Click on Non-Significant Logs button to view Non-Significant Logs.

 

 

Log Details

 

  1. Click on + on the first log entry to examine the details.

Note: You may need to use the scroll bar to see it.

 

 

Log Details (cont.) - Enable Non-significant log collection

 

Note: https://avinetworks.com/docs/18.2/logging-all-headers-in-client-server-http-traffic/logging-all-headers-in-client-server-http-traffic.pdf

  1. Click on Pencil and proceed to Analytics tab to enable the discussed properties above.

 

 

Edit Virtual Service: app-01a

 

  1. Select the Analytics Tab
  2. Select the Check box for Log all headers
  3. Ensure Non-Significant Logs is selected
  4. Set Non-significant log duration to 0
  5. Click Save

 

 

 

Click to go back to Virtual Services

 

  1. Click the Arrow to go back to the Virtual Services page

 

 

Create Virtual Service app-02a with multiple service ports

 

Let's create your second HTTP virtual service which will load balance HTTP traffic across two web servers and will expose the web servers via multiple service ports.

  1. Click on Create Virtual Service
  2. Select Advanced Setup

 

 

Create app-02a - Virtual Service

 

  1. Enter name app-02a
  2. Select that is Enabled
  3. Traffic Enabled is Selected
  4. Auto Allocate is Selected
  5. Floating IPv4 - Auto Allocate is Selected
  6. Network for VIP Address Allocation - Select VIP-RegionA01-vDS-COMP - 192.168.130.0/24 from the drop down list
  7. IPv4 Subnet - select 192.168.130.0/24
  8. Application Profile - Set to System-HTTP
  9. Click on button to switch Service Port section to advanced (NOTE in Screenshot it is the opposite but in the same place) - Select switch to Advanced
  10. Edit the service Port so Service range goes from 80-85 as in Screenshot above
  11. Click on Add Port
  12. In the new field, enter 8080 as the port range as in Screenshot above
  13. Click on the Pencil Icon to edit Pool
  14. Click to Create Pool

 

 

Create app-02a Cont - (Create Pool)

 

Create the new pool with these parameters:

  1. Leave the Name set to app-02a-pool
  2. The Default Service Port should be set to 80
  3. Ensure the box next to Passive Health Monitor is ticked.
  4. Click on the Add Active Monitor box.
  5. Select System-HTTP.

 

 

New Pool (app-02a) - Verify

 

Make sure the setting are correct.

  1. Click Next to continue.

 

 

New Pool (app-02a) - Servers

 

  1. Click on Select Servers by Network.

 

 

Select Servers (app-02a)

 

  1. From the Select a Network drop-down box, choose VM-RegionA01-vDS-COMP - 192.168.120.0/24 (note that you may have to scroll down to see it).
  2. Select both web-01a and web-02a from the list of servers.
  3. Click the Add Servers button.

 

 

 

Members Added (app-02a)

 

  1. Click Next

 

 

New Pool - Advanced (app-02a)

 

Nothing will be changed in the Advanced section.

  1. Click Next to continue.

 

 

New Pool - Review (app-02a)

 

Here you can review the settings for the new pool.

  1. Click Save to create the new pool.

 

 

Create app-02a Virtual Service - Advanced

 

  1. Back in the New Virtual Service wizard, click on the Step 4 - Advanced tab.
  2. Click the Save button to create the new virtual service.

 

 

Verify app-02a Virtual Service

We can verify the service in two ways.

Note: The avitools management virtual machine includes the avitools container. The container is designed to host all the required migration and verification tools needed in the field. Please refer to the github for more details: https://github.com/avinetworks/avitools

 

 

Verify app-02a (via avitools - open Putty)

 

To access avitools management virtual machine open SSH client Putty.

  1. Select avitools.corp.local
  2. Click Load
  3. Then Open

 

 

Verify via avitools - enter Container service

 

sudo docker exec -it avitools bash

 

 

Verify via avitools - Verify app-02a

 

curl -I http://app-02a.region01a.corp.local
curl -I http://app-02a.region01a.corp.local:81
curl -I http://app-02a.region01a.corp.local:8080

 

 

Verify via avitools - HTTP test

 

http http://app-02a.region01a.corp.local:8080

 

 

Create HTTPS Virtual Service

Avi Vantage fully supports termination of SSL- and TLS-encrypted HTTPS traffic. The SSL and TLS names are used interchangeably throughout the documentation unless otherwise noted.

Using Avi Vantage as the endpoint for SSL enables it to maintain full visibility into the traffic and also to apply advanced traffic steering, security, and acceleration features. The following deployment architectures are supported for SSL:

Avi Vantage supports multiple architectures for terminating SSL traffic. For client-to-Avi-Vantage SSL, the configuration is done on the virtual service page. For Avi-Vantage-to-server SSL encryption, the configuration is performed by editing the pool. For either, a virtual service or pool must be configured with an SSL profile and an SSL certificate, described below.

 

 

Create New HTTPS Virtual Service - secure-app-02a

 

Let's create your third Virtual Service, a HTTPS virtual service which load balances traffic across two web servers, with client-side and server-side traffic encryption.

Back on the Avi Vantage Controller tab

  1. On the Dashboard, select Create Virtual Service
  2. Select Advanced Setup

 

 

Create HTTPS Virtual Service - secure-app-02a

 

  1. Enter name Secure-app-02a
  2. Select that is Enabled
  3. Traffic Enabled is Selected
  4. Auto Allocate is Selected
  5. Floating IPv4 - Auto Allocate is Selected
  6. Network for VIP Address Allocation - Select VIP-RegionA01-vDS-COMP - 192.168.130.0/24 from the drop down list
  7. IPv4 Subnet - select 192.168.130.0/24
  8. Application Profile - Set to System-Secure-HTTP
  9. Click on Add Port (button not in screenshot)
  10. In the new field, enter 443 as the port range and check for SSL as in Screenshot above
  11. Click on the dropdown Icon to edit Pool
  12. Click to Create Pool

 

 

Create Pool - secure-app-02a

 

  1. Set default Server Port to 443
  2. Click to Add Active Monitor
  3. Select System-HTTPS from the list
  4. Select Check box for SSL to Backend Servers
  5. Under SSL Profile, select System-Standard
  6. Click Next

 

 

Create Pool - Add Servers - secure-app-02a

 

Click on Select Servers by Network

 

 

Create Pool - Add Servers (Cont') - secure-app-02a

 

  1. Click on dropdown for 'Select Servers by Network' and select VM-RegionA01-vDS-COMP - 192.168.120.0/24
  2. Select both web-01a and web-02a from the server list
  3. Click on Add Servers
  4. Once added, Click Next (Click Next two more times and then Save to complete the New Pool wizard)

 

 

Create HTTPS Virtual Service (Cont') - secure-app-02a

 

Returning to the New Virtual Service wizard for secure-app02a

  1. Use the drop down list to select *.region01a.corp.local for the SSL Certificate (Note - delete any other settings that may already be selected)
  2. Click Step 3: Analytics

 

 

Create HTTPS Virtual Service (Analytics) - secure-app-02a

 

We want to allow log collection in the same way we did earlier for app-01a

  1. Click the checkbox to enable Log all headers
  2. Ensure checkbox is selected for Non-significant logs
  3. Set Non-significant log duration to 0
  4. Click Next then Click Save

 

 

Verify Virtual Service secure-app-02a.region01a.corp.local

Avi Vantage supports the ability to terminate SSL connections between the client and the virtual service, and to enable encryption between Avi Vantage and the back-end servers.

The Templates>Security>SSL/TLS Profile contains the list of accepted SSL versions and the prioritized list of SSL ciphers. To terminate client SSL connections, both an SSL profile and an SSL certificate must be assigned to the virtual service. To also encrypt traffic between Avi Vantage and the servers, an SSL profile must be assigned to the pool. When creating a new virtual service via the basic mode, the default system SSL profile is automatically used.

Each SSL profile contains default groupings of supported SSL ciphers and versions that may be used with RSA or an elliptic curve certificates, or both. Ensure that any new profile created includes ciphers that are appropriate for the certificate type that will be used. The default SSL profile included with Avi Vantageis optimized for security, rather than just prioritizing the fastest ciphers.

Creating a new SSL/TLS profile or using an existing profile entails various trade-offs between security, compatibility, and computational expense. For example, increasing the list of accepted ciphers and SSL versions increases the compatibility with clients, while also potentially lowering security.

Note: Starting with release 18.2.3, Avi Vantage can accommodate a broader set of security needs within a client community by associating multiple SSL profiles with a single virtual service, and have the Service Engines choose which to use based on the clients IP address. For more information, read Client-IP-based SSL Profiles.

 

Verify virtual service secure-app-02a.region01a.corp.local

  1. Access the virtual service using Browser on non-secure http url: http://secure-app-02a.region01a.corp.local.

As you can observe the request was redirected to secure https connection

 

 

Verify Virtual Service - Check Certificate

 

The provided certificate will be shown as valid,

  1. Investigate the certificate details

 

 

Verify Virtual Service - Check Certificate (Cont')

 

The Certificate shows the correct configuration details we selected earlier

  1. Click OK

 

 

Examine the corresponding Virtual Service logs

 

  1. Switch back to Avi Vantage Controller tab to check the logs
  2. Ensure secure-app02a is selected
  3. Click on Logs

 

 

Examine Virtual Service logs (Cont')

 

HTTP to HTTPS redirection is enabled by default as part of System-Secure-HTTP Application Profile.

  1. Click to expand the first entry
  2. Investigate HTTP Headers by clicking on View All Headers as part of the log entry.

 

 

Examine Virtual Service logs (Cont') - Investigate Headers

 

  1. Click on + to see all the headers

 

 

View Modified Headers

 

By default only modified headers are shown.

  1. Once you have finished reviewing, Click Close

 

 

Verify secure-app-02a.region01a.corp.local leveraging curl utility

 

We can go back to use avitools Curl utility to check further:

  1. Maximize the putty session we started earlier for avitools
  2. Run:
curl -i http://secure-app-02a.region01a.corp.local
curl -i https://secure-app-02a.region01a.corp.local

Minimize Putty when finished

 

 

Modifying pool failure behavior for pool app-02a-pool

 

 

Investigate Pool Failure Settings default configuration of app-02a-pool.

 

 

  1. Click on Pools as part of Application tab
  2. Click on pencil next to app-02a-pool

 

 

Edit Pool: app-02a-pool

 

When in Edit Pool: app-02a-pool mode

  1. Click on Advanced tab
  2. Investigate Pool Failure Settings configuration. As mentioned, the default behavior is Close Connection

Click Cancel when finished

 

 

Access virtual service app-02a  leveraging browser or curl utility

 

  1. Maximize the Putty session running avitools
  2. Run:
curl -i http://app-02a.region01a.corp.local

3.   Minimize Putty when finished

 

 

Perform graceful shutdown of all pool members within app-02a-pool

 

 

 

Pool: app-02a-pool view

 

When in Pool: app-02a-pool view

  1. Click on Servers
  2. Select web-01a and web-02a servers
  3. Click Disable

 

 

Access app-02a leveraging browser or curl utility

10:28:42:root@[avitools_container]:/opt/avi# curl -i http://app-02a.region01a.corp.local
curl: (6) Could not resolve host: app-02a.region01a.corp.local
10:38:50:root@[avitools_container]:/opt/avi# curl -i http://192.168.130.93
curl: (52) Empty reply from server

 

 

Access app-02a via Avi Controller

 

Back on the Avi Controller page, you can see the default behavior is to refuse the connection, to modify the behavior the pool configuration has to be changed. The desired behavior can be supplying custom error code like 503 as well as supplying custom error page profile. Status code and custom page can be supplied as part of pool configuration, however error page profiles provides easier configuration management against multiple objects based on produced status code. The lab exercise will focus on modifying the pool configuration to return code 503, however the custom error page profile can be used to futher modify the 503 page output.

  1. Click on Pools tab

 

 

Modify pool app-02a-pool

 

Once on the Pools tab

  1. Click on the Pencil icon to edit app-02a-pool

 

 

Edit Pool: app-02a

 

Modify pool app-02a-pool configuration with the parameters below:

  1. Click on the Advanced tab
  2. Set Fail Action to HTTP Local Response
  3. Note the Status code = 503
  4. Click Save

 

 

Access virtual service app-02a via avitools

 

Access virtual service app-02a via avitools.  Capture virtual service IP address and try to reach virtual service using IP address using browser or curl utility.

  1. Maximize the Putty session running avitools
  2. Run:
10:39:49:root@[avitools_container]:/opt/avi# curl -i http://192.168.130.93
HTTP/1.1 503 Service Temporarily Unavailable
Content-Type: text/html
Content-Length: 204
Connection: keep-alive
<html>
<head><title>503 Service Temporarily Unavailable</title></head>
<body bgcolor=white>
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>avi</center>
</body>
</html>

As failure behavior was changed, the virtual service was placed back on service engine and client can get a 503 response, however dynamic fqdn did not get injected back.  To disable state based DNS registration follow the knowledge base reference: https://avinetworks.com/docs/18.2/dns-record-additions-independent-of-vs-state/ .

Minimize Putty when finished.

 

 

Access virtual service app-02a via Avi Vantage Controller

 

  1. Click back on Avi Vantage Controller tab
  2. Select Logs
  3. Expand the first entry
  4. You can see 503 errors

 

 

Customizing Health Monitors for “secure-app-02a-pool”

Avi Vantage must validate whether servers are working correctly and are able to accommodate additional workloads before load balancing a client to a particular server. Health monitors perform this function by either actively sending a synthetic transaction to a server or by passively monitoring client experience with the server. Avi Vantage sends active health monitors on a periodic basis that originate from Service Engines hosting the virtual service.

Active Health Monitors

Active health monitors proactively send queries to servers, synthetically mimicking a client. Send and receive timeout intervals may be defined, which statically determines the server response as successful or failed.

Active health monitors originate from the Service Engines hosting the virtual service. Each SE must be able to send monitors to the servers, which ensures there are no routing or intermediate networking issues that might prevent access to a server from all active Service Engines. If one SE marks a server up and another SE marks a server down, each SE will include or exclude the server from load balancing according to their local monitor results.

Passive Health Monitor

While active health monitors provide a binary good/bad analysis of server health, passive health monitors provide a more subtle check by attempting to understand and react to the client-to-server interaction. An active health monitor sends a periodic check to the servers that mimics an end user transaction with a synthetic request, then statically validates the response against an expected string. Passive health monitors do not send a check to the servers. Instead, Avi Vantage monitors end user interaction with the servers. If a server is quickly responding with valid responses (such as HTTP 200), then all is well; however, if the server is sending back errors (such as TCP resets or HTTP 5xx errors), the server is assumed to have errors. Errors are defined by the analytics profile attached to the virtual service. The analytics profile also defines the threshold for response time before a server is considered responding slowly.

With active health monitors, Avi Vantage will mark a server down after the specified number of consecutive failures and will no longer send new connections or requests until that server is able to correctly pass the periodic active health monitors.

With passive health monitors, server failures will not cause Avi Vantage to mark that server as down. Rather, the passive health monitor will reduce the number of connections or requests sent to the server relative to the other servers in the pool by about 75%. Further failures may increase this percentage. After a server is satisfactorily handling the reduced load, it will once again be sent normal volumes of traffic.

Note: Best practice is to enable both a passive and an active health monitor to each pool.

 

 

Modify secure-app-02a adding Health Monitors

 

 

Review secure-app-02a-pool configuration

 

Review secure-app-02a-pool configuration

  1. Click on Pools
  2. Click on pencil next to secure-app-02a-pool

Note (Optional) Review the configuration using REST API interface, open a new browser tab and access the following url: https://avicon-01a.corp.local/api/pool?name=secure-app-02a-pool&include_name

 

 

Add  active health monitor as System-HTTP

 

Let's add one more active health monitor as System-HTTP and observe the pool status change.

  1. Click on Add Active Monitor
  2. Choose System-HTTP
  3. Click Save

 

 

Review pool status

 

Let's remove inappropriate System-HTTP health monitor and create a new Custom-HTTP health monitor that will respect the application conditions, meaning it will include the monitor port as 80 specified.

Note: Default profiles can be modified as well, however it is not considered best practice.

  1. Click the Pencil icon to edit the pool

 

 

Remove Health Monitor

 

  1. Remove health monitor by clicking on the trashcan icon next to System-HTTP health monitor.

 

 

Invoke Create Health Monitor wizard

 

  1. Click on Add Active Monitor button
  2. Click on Create Health Monitor

 

 

Create new health monitor “Custom-HTTP”

 

  1. For Name enter Custom-HTTP
  2. For Type, set to HTTP
  3. Set Health Monitor Port to 80
  4. Click scroll bar to view further down page

 

 

Create new health monitor “Custom-HTTP” (Cont')

 

  1. For Response Code select 2XX from the drop down list
  2. Click Save

 

 

Create new health monitor “Custom-HTTP” - Review

 

  1. Now we have our Custom-HTTP Health Service configured
  2. Click Save

 

 

Review new health monitor

 

 

 

Create Virtual Service secure-app-03a within separate tenant “engineering”

Tenants

A tenant is an isolated instance of Avi Vantage. Each Avi Vantage user account is associated with one or more tenants. The tenant associated with a user account defines the resources that a user can access within Avi Vantage. When a user logs in, Avi Vantage restricts their access to only those resources that are in the same tenant.

If a user is associated with multiple tenants, each tenant still isolates the resources that belong to that tenant from the resources in other tenants. To access resources in another tenant, the user must switch the focus of the management session to that other tenant.

Notes:

Default Tenant

By default, all resources belong to a single, global tenant: admin. The admin tenant contains all Avi Vantage resources.  The default admin user account belongs to the admin tenant and therefore can access all resources. If no additional tenants are created, all new Avi Vantage user accounts are automatically added to the admin tenant.

 

 

Create a new tenant engineering

 

Create a new tenant engineering

 

 

Access Tenants - Create

 

  1. Click on Tenants
  2. Click Create

 

 

New Tenant

 

  1. Enter engineering as the name
  2. Clcik Save

 

 

Switch to engineering tenant

 

Switch to engineering tenant

  1. Click on the dropdown arrow next to  admin
  2. Then select engineering

 

 

Navigate to Applications

 

  1. Navigate to Applications tab
  2. Create a new virtual service secure-app-03 with the parameters below under the tenant engineering (Note use Advanced Setup)

 

 

Create secure-app-03a Virtual Service

 

  1. For Name, enter secure-app-03a
  2. Select check box for Auto Allocate under Floating IPv4
  3. Under Network for VIP Address Allocation select VIP-RegionA01-vDS-COMP - 192.168.130.0/24
  4. For IPv4 Subnet select 192.168.130.0/24
  5. For Application Profile select System-Secure-HTTP
  6. Scroll down the page to continue

 

 

Create secure-app-03a Virtual Service (Cont')

 

  1. Click to add 443 as a new service and select SSL check box
  2. Create a new pool

 

 

Create Pool for secure-app-03a

 

  1. For Default Server Port enter 443
  2. Click Add Active Monitor and select System-HTTPS as the option
  3. Click check box for SSL to Backend Servers
  4. Select System-Standard as the SSL Profile
  5. Click Next 

 

 

Select servers for secure-app-03a pool

 

On the Add servers page, like we did on the previous virtual services, we can add the hosts via networks

  1. Select VM-Region01a-vDS-COMP - 192.168.120.0/24 as the network
  2. Select web-01a and web-02a
  3. Click Add Servers
  4. Click Next - then Next again and finally Save

 

 

 

Set logging for new Virtual Service

 

Back in the Create new Virtual Service wizard

  1. Click Step 3: Analytics
  2. Click to select Log All Headers
  3. Set Non-Significant log duration to 0
  4. Click Next and then Save

 

 

Review New Virtual Service secure-app-03a

 

Validate newly created Virtual Service

  1. Click on  secure-app-03a

 

 

Review New Virtual Service secure-app-03a (Cont')

 

As you can observe, tenants at this stage share the same data plane, however the configuration is grouped within the actual tenant.

 

Module 2 Conclusion


In this module you learned how to configure Virtual Services, Pools, Health Monitors, Certificates, SSL Profiles, Application Profiles and Tenants.

Knowledge base references(s):


 

You have finished Module 2

Congratulations on completing Module 2.

You can now proceed to any of the remaining modules :

 

Module 3 - Introduction to Service Engine Groups (30 minutes)

Configure a Service Engine Group


In this lesson, we review and perform configuration of Service Engine Group(s).

Avi Service Engines (SEs) handle all of the data plane operations within Avi Vantage. SEs host the virtual services and require either direct or routable access to all client and server networks a virtual service touches.

A typical Avi Vantage deployment may have many SEs for various purposes, such as redundancy, scalability, and accommodating large numbers of applications being served. SEs are always grouped within the context of a SE group, which provides settings for high availability, scalability, and potentially resource isolation for tenants.

Service Engines are created within a group, which contains the definition of how the SEs should be sized, placed, and made highly available. Each cloud will have at least one SE group. The options within an SE group may vary based on the type of cloud within which they exist and its settings, such as no access versus write access mode. SEs may only exist within one group. Each group acts as an isolation domain. SE resources within an SE group may be moved around to accommodate virtual services, but SE resources are never shared between SE groups.

When creating a new SE group in write access mode, no new SEs will be created until a virtual service is deployed to the SE group. In read access mode or no access mode deployments, the new SEs must be manually created. They will attempt to connect back to the Controller after they have booted up, at which point they will be added to the Default SE group. SEs in read access mode and no access mode deployments can be migrated to a new SE group, provided all virtual services deployed on the SE are disabled.

SEs in write access mode deployments cannot be migrated to new SE groups. Instead, the old SE is deleted and a new SE is created. This process is automatic if the virtual services are migrated.

Knowledge base references(s):


 

Launch Chrome

 

From the Main Console, launch Chrome.

 

 

Access Avi Vantage Controller in Region A

 

  1. Open the Avi Controller in Region A from the bookmarks on Chrome browser and click on Avi Vantage Controller A.

 

 

Log in

 

Username: admin
Password: VMware1!

 

 

Service Engine Group

 

  1. Click on the 3 dash line (Menu) and navigate to Infrastructure
  2. Click on Service Engine Group

 

 

Default-Cloud

 

  1. Click the Create button

 

 

Create Service Engine Group

 

  1. Name the Service Engine Group Test-SG

Continue to the next step.

 

 

New SEG - Basic Settings

 

Observe the default options under the 'Basic Settings' and 'Advanced' tabs (some differing between ecosystems).

Some options to understand:

  1. High Availability mode
  2. VS Placement across SEs
  3. SE instance sizing
  4. Max Number of Service Engines

 

 

Basic Settings

 

  1. Use the scroll bar to move to the bottom of the window.

Note the different license type options.

  1. Click the Advanced tab.

 

 

Create the Service Engine Group

 

Note some of the additional, more advanced options on the screen.

  1. Click on Save to create the Service Engine Group

 

 

Newly Created SG

 

The new Service Engine Group has been created.

This concludes this module on configuring a Service Engine Group.

 

Conclusion


In this module you learned different HA modes available, SE sizing, scale, and license configuration

Knowledge base references(s):


 

You have finished Module 3

Congratulations on completing Module 3.

You can now proceed to any of the remaining modules :

 

Module 4 - Introduction to Application Scaling (30 minutes)

Scale Out, Scale In and Migrate operations


Avi Vantage supports scaling virtual services, which distributes the virtual service workload across multiple SEs to provide increased capacity on demand, thus extending the throughput capacity of the virtual service and increasing the level of high availability.

Native load balancing of SEs. The primary SE (in the middle) is flanked by two secondary SEs.

Knowledge base references(s):


 

Module Switcher

 

From the desktop, launch the HOL-2037-1 Module Switcher.

 

 

Start Module 4

 

  1. Click the Start button under Module 4

 

 

PowerShell Script

 

The script will progressively catch you up to the current Module.  You will need to press the Enter as it goes through each module's script.

In this case, you will need to press the Enter key four times to execute the needed configuration for this module.  It make take a minute or two to run, but you will be presented with one final Enter key to continue.

 

Press the Enter key to continue.

 

 

Launch Chrome

 

From the Main Console, launch Chrome.

 

 

Access Avi Vantage Controller in Region A

 

  1. Open the Avi Controller in Region A from the bookmarks on Chrome browser and click on Avi Vantage Controller A.

 

 

Log in

 

Username: admin
Password: VMware1!

 

 

Scaling Out a Virtual Service

 

  1. On the Application dashboard, select the Virtual Service app-01a on which the scale/migrate operations will be performed

 

 

Scale Out

 

  1. Hover on the Virtual Service: app-01a to display Scale Out, Scale In and Migrate options
  2. Click Scale Out to perform a scale out of the Virtual Service to another SE.

 

 

Scale Out - app-01a

 

The SE on which the Virtual Service is scaled out to may be an existing SE or an SE which is newly spun up by checking the ‘Create Service Engine’ option.

  1. For this step just click on the green Scale out button and let Avi controller automatically choose the available SE.

How Scaling Operates in VMware

For VMware deployment, the scaled out traffic behaves as follows:

Wait for the scale out operation to complete.

 

 

 

Verify Scale out

 

Check that the VS is now scaled out to two SEs by hovering the mouse over the Virtual Service name.

 

 

Scaling In a Virtual Service

 

  1. Hover over Virtual Service: app-01a to display Scale Out, Scale In and Migrate options
  2. Click on Scale In to perform a scale in of the Virtual Service from the SEs on which it is hosted.

 

 

Scale In

 

Selecting the SE to scale in is optional.

  1. Click on the green Scale In button and let Avi controller automatically decide the SE to scale in.

 

 

Scale In Complete

 

Wait for the scale in operation to complete.

Scaling In

To manually scale in a virtual service in when Avi Vantage is operating in Write Access mode:

  1. Open the Virtual Service Details page for the virtual service that you want to scale.
  2. Hover the cursor over the name of the virtual service to open the Virtual Service Quick Info popup.
  3. Click the Scale In button to open the Scale In popup window.
  4. Select Service Engine to scale in. In other words, which SE should be removed from supporting this Virtual Service.
  5. Scale the virtual service in by one Service Engine per SE selection, down to a minimum of one Service Engine.

The prompt Currently scaling in displays the progress while the operation is taking place.

Note: When Scaling In, existing connections are given thirty seconds to complete. Remaining connections to the SE are closed and must restart.

 

 

Verify Scale In

 

  1. Hover over Virtual Service: app-01a to verify there is only one Service Engine

 

 

Migrating a Virtual Service

 

  1. Hover on Virtual Service: app-01a to display Scale Out, Scale In and Migrate options

Note the current Service Engine is seg01a-se-neadm

  1. Click on Migrate to move a Virtual Service from one of the SEs to either another existing SE or a new SE using the ‘Create Service Engine’ option

 

 

Migrate

 

Migrating

The Migrate option allows graceful migration from one Service Engine to another. During this process, the primary SE will scale out to the new SE and begin sending it new connections. After thirty seconds, the old SE will be deprovisioned from supporting the virtual service.

Note: Existing connections to the migrations source SE will be given thirty seconds to complete prior to the SE being deprovisioned for the virtual service. Remaining connections to the SE are closed and must restart.

Selecting the SE to migrate is optional.

  1. Select seg-01a-se-neadm as the SE to migrate.
  2. Click on the green Migrate button to let the Avi controller automatically decide the SE to migrate to, which is pre-populated for you.

Wait for the migration operation to complete.

Check that the VS is now placed on the new SE.

 

 

Verify Migrate

 

  1. Hover over Virtual Service: app-01a

Note the Service Engine is seg01a-se-fryat.

 

Module 4 Conclusion


In this module you learned how to manually scale in/out a Virtual Service in order to handle traffic fluctuations. Also you learned how to migrate a Virtual Service from one SE to another or disable a Virtual Service in order to put the application in maintenance mode.

Knowledge base references(s):


 

You have finished Module 4

Congratulations on completing Module 4.

You can now proceed to any of the remaining modules :

 

Module 5 - Introduction to Application Services and Security (60 minutes)

Introduction to Application Services and Security


Virtual Service Policies

Policies allow advanced customization of network layer security, HTTP security, HTTP requests, and HTTP responses. A policy may be used to control security, client request attributes, or server response attributes. Policies are comprised of matches and actions, similar to an if/then logic. If something is true, then it matches the policy, and therefore Avi Vantage performs the following action.

Policies are comprised of one or more rules, which are match/action pairs. A rule may contain many matches, or have many actions. Multiple policies may be configured for a virtual service. Policies may alter the default behavior of the virtual service, or if matching criteria are not met, they may be benign for a particular connection, request, or response.

Policies are not shared; they are defined on a per-virtual-service basis. While powerful, policies are intended to be simple point-and-click functionality.

For more advanced capabilities, see https://avinetworks.com/docs/18.2/overview-of-datascript/

Knowledge base references(s):

This lab exercise demonstrates some of the possible use cases for modifying your traffic flows. By the end of this lab you will have created three policies, including a Network Security Policy, HTTP Security Policy and HTTP Request policy.


 

Module Switcher

 

From the desktop, launch the HOL-2037-01 Module Switcher.

 

 

Start Module 5

 

  1. Click the Start button under Module 5

 

 

PowerShell Script

 

The script will progressively catch you up to the current Module.  You will need to press the Enter as it goes through each module's script.

In this case, you will need to press the Enter key five times to execute the needed configuration for this module.  It make take a minute or two to run, but you will be presented with one final Enter key to continue.

 

Press the Enter key to continue.

 

 

Launch Chrome

 

From the Main Console, launch Chrome.

 

 

Access Avi Vantage Controller in Region A

 

  1. Open the Avi Controller in Region A from the bookmarks on Chrome browser and click on Avi Vantage Controller A.

 

 

Log in

 

Username: admin
Password: VMware1!

 

 

Insert X-Forwarded-For Header via Application Profile

 

  1. Click on the Menu and select Templates

 

 

Insert X-Forwarded-Proto Header via Application Profile

 

  1. Click on the Menu and select Templates

 

 

Insert X-Forwarded-For Header via HTTP Request Policy

 

  1. Select Templates from the Menu

 

 

Redirect HTTP to HTTPS via Application Profile

 

  1. Click on the Menu and select Templates

 

 

Redirect HTTP to HTTPS via HTTP Security Policy

 

Edit the Virtual Service secure-app-01a by clicking on the Pencil icon

 

 

Edit Virtual Service

 

  1. Change the Application Profile to Custom_App_Profile

 

 

New Policy

 

  1. Click on HTTP Security
  2. Click the Green Plus sign to create a new policy

 

 

New Rule

 

Create the new policy with the following parameters:

  1. Rule Name - Redirect to HTTPS
  2. Log Condition - Log
  3. Matching Rules - Service Port / is / 80
  4. Action - Redirect To HTTPS / 443
  5. Click Save Rule

 

 

Save Virtual Service

 

  1. Click the Save button to save the changes made

 

 

New Incognito Window

 

We will need to open an incognito window because the the browser redirect is likely cached from our last test.

  1. Click on the Chrome menu
  2. Select New incognito window

 

 

Test Redirect

 

  1. In the new incognito window, enter http://secure-app-01a.region01a.corp.local

Note that again it redirects http to https

For advanced users, you may follow the same procedures from the previous test to validate the redirect behavior using Putty

 

 

Back to Avi Vantage

 

  1. Go back to Chrome and the Avi Vantage tab

 

 

Logs

 

  1. Find the log entry with 307 and click the '+' next to it.
  2. Note that the Virtual Service IP port is 80
  3. The Security Rule is Redirect to HTTPS

 

 

Redirect URL

 

  1. In the Response Information note the Redirect URL (you may need to use the scroll bar to see it)
  2. Click on View All Headers

 

 

View All Headers

 

  1. Note the URL Redirect in the Headers sent to client field
  2. Click Close

 

 

Configure Network Security Policy to Block Access by Country

 

  1. From the Menu, select Templates

 

Module 5 Conclusion


In this module you learned how to create Network Security Policy, HTTP Security Policy and HTTP Request and Response policies

Knowledge base references(s):


 

You have finished Module 5

Congratulations on completing Module 5.

You can now proceed to any of the remaining modules :

 

Module 6 - Introduction to Application Troubleshooting (30 minutes)

Introduction to Application Troubleshooting


In this module, we are going to use the Virtual Service logs search feature to display only those logs that match various search criteria which can help debug application issues.

Knowledge base references(s):

Virtual Service Logs

Virtual services and pools are able to log client-to-application interactions for TCP connections and HTTP requests/responses. These logs can be indexed, viewed, and filtered locally within the Avi Controller. Logs can be useful for troubleshooting and surfacing insights about the end-user experience and success of the application.

Enabling Logs

See the Analytics tab of the Create Virtual Service popup for configuring, enabling, filtering, and/or disabling client logs.

Significant Logs

Avi Vantage automatically logs common network and application errors under the umbrella of significant logs. These significant logs may also include entries for lesser issues, such as transactions that completed successfully but took an abnormally long time.

Errors may include any of the following:

Errors can be omitted from the significant logs list by editing the analytics profile used by the virtual service.

Full Client Logs

In addition to significant logs, a virtual service may be configured to log all client connections or HTTP requests. The Full Client Logs option includes any significant logs, custom full log filters, and any logs generated by custom policies or DataScripts. By default, a new virtual service is configured to provide full client Logs for the first 30 minutes, then drop down to a reduced logging level by capturing significant logs only. From the Analytics tab, full client logs may be enabled for the virtual service, either temporarily or permanently.

Full client log filters may also be specified for IP addresses or URIs, which is recommended when capturing important information from busy production systems. An additional level of logging is provided by enabling the All Headers option in a client log filter. This option will capture all headers from the client and server within the logs. Keep in mind this may have significant impact on the size of the logs, as some applications send as much as 30 k within a single header. Even so, the All Headers option is very useful for quick troubleshooting to see what each side of the connection is sending and receiving.

Avi Vantage pulls logs from the SEs and indexes them on the Controllers only when an administrator attempts to view full client logs for the virtual service or pool. This may take anywhere from a few seconds to hours to process. Logs will be viewable while the indexing process is performed in the background. This time may depend on network latency from the SEs to the Controllers, the volume of logs, and the hardware used by the Controller for performing the resource-intensive task of indexing the data.


 

Module Switcher

 

From the desktop, launch the HOL-2037-1 Module Switcher.

 

 

Start Module 6

 

  1. Click the Start button under Module 6

 

 

PowerShell Script

 

The script will progressively catch you up to the current Module. You will need to press the Enter as it goes through each module's script.

In this case, you will need to press the Enter key five times to  execute the needed configuration for this module. It make take a minute  or two to run, but you will be presented with one final Enter key to  continue.

 

Press the Enter key to continue.

 

 

Launch Chrome

 

From the Main Console, launch Chrome.

 

 

Access and Log into Avi Vantage Controller in Region A

 

  1. Open the Avi Controller in Region A from the bookmarks on Chrome browser and click on Avi Vantage Controller A
  2. Login to the Avi Vantage Controller in Region A using the following credentials:

Username: admin

Password: VMware1!

 

 

Enable Full Client Logs

In this exercise, we are going to enable full client logs, and export those logs out of Avi.

 

 

Edit secure-app-02a Virtual Service

 

  1. Click on the Virtual Services Tab
  2. Click the pencil icon next the secure-app-02a to edit it

 

 

  1. Click on the Analytics tab
  2. Under Client Log Settings, check Log all headers and Non-significant logs.  This will enable the collection of non-significant logs, and log the headers.  
  3. Click Save to close the Edit wizard

 

 

Generate some logs

 

  1. Open a new Chrome tab and navigate to https://secure-app-02a.region01a.corp.local/
  2. Hit refresh the page few times to generate some logs
  3. Then return to the Avi Vantage Controller tab

 

 

Back to Avi Vantage Controller

 

  1. Click Virtual Services tab
  2. Click to open Virtual Service secure-app-01a

 

 

Export Logs for secure-app-02a

 

  1. Click on Logs subtab
  2. Make sure Non-Significant Logs are also enabled
  3. Click Export, and export the current page of logs

You can then open the downloaded csv file and examine the output

 

 

Determine which clients are experiencing SSL handshake failures

 

 

Open Putty to start avitools

 

  1. Start Putty from the shortcut
  2. Load and open avitools.corp.local from the saved session list

 

 

Run Curl commands via avitools

 

Run Curl commands:

curl -I --tlsv1.2 https://secure-app-02a.region01a.corp.local
curl -I --sslv3 https://secure-app-02a.region01a.corp.local

Observe that the SSL handshake fails for SSLv3 and is successful for TLSv1.2

 

 

Debug via Virtual Service Logs

 

 

 

Search for SSL errors

 

  1. To search for all SSL errors, Scroll down the page
  2. Click on Significance on right column
  3. Click on SSL Error

 

 

Check SSL errors

 

  1. All client requests with SSL Errors get listed
  2. Observe the failure cause and SSL version used by the client

Debug:

Some clients are getting connection reset because they are connecting with SSL version not configured on the Virtual Service

Resolution:

Edit the SSL profile used by the Virtual Service and enable SSLv3

 

 

Edit Virtual Service

 

  1. Click on the Virtual Services tab
  2. Click on the Pencil icon for secure-app-02a Virtual Service

 

 

Edit SSL Profile

 

On the Edit Virtual Service: secure-app-02a page

  1. Scroll down the page
  2. Click the pencil icon next to SSL Profile

 

 

Enable SSL 3.0

 

  1. Click the check box for SSL 3.0
  2. Click Save once set (not shown) and then Yes, save changes and then Save to save and close the Edit Virtual Service wizard

 

 

Debug application errors (HTTP status 404)

 

  1. Browse to http://secure-app-02a.region01a.corp.local/ on a new Chrome tab and refresh the page a few times.

 

 

Check logs for secure-app-02a

 

 

 

Check for 404 errors

 

  1. On right column, click on Response Code under Request Analytics
  2. Click on 404 (Not Found) to list all matching logs

 

 

Check URL paths

 

  1. To list all URIs causing the 404 status, click URL Path under Request Analytics

Debug:
The clients get 404 errors because file favicon.ico is missing on the backend server

Resolution:
Upload the missing file to the backend servers

 

 

How to Determine Client Location

 

 

 

Understanding Events and Alerts

Events Overview

Events are used throughout Avi Vantage to provide a history of relevant changes that have occurred. Events are a permanent record, and can be used to generate alerts which can take action on the event. In the UI, events may be viewed within the context of specific objects, such as a virtual service, a pool, or a server. In contrast, viewing events from the Operations menu provides an unfiltered view of all events across the system or the tenant. For Avi Vantage system debugging, this should be the first place to go for information.

Alerts Overview

In its most generic form, alerts are a construct intended to inform administrators of significant events within Avi Vantage. In addition to triggering based on system events, alerts may also be triggered based one or more of the 200+ metrics Avi Vantage is tracking. Once an alert is triggered, it may be used to notify an administrator through one or more of the notification actions. Or to take things a step further, alerts may trigger ControlScripts, which provide limitless scripting possibilities.

Alert Scope

Alerts may be viewed in multiple places within the UI, including within virtual services, pools, service engines, and the Operations > Alerts > All Alerts page. Alerts viewed within VS, pools or SEs are limited to the alerts pertinent to those objects. The All Alerts page shows all alerts on the system, or all alerts within the tenant if applicable.

Alerts are transient, and will only exist or be true for a defined period of time. After the configured alert expiry time lapses, the alert is removed. The underlying event or metric that triggered the alert still exists as a permanent log of what has transpired.

Alert Workflow

Configuring custom alerts requires walking through the workflow to build the alert config (the alerts trigger) based on one or more of 500+ events and metrics. When the alert configurations conditions are met, Avi Vantage processes an alert by referring to the associated alert action, which lists the notifications to be generated and potentially calls for further action, such as application autoscaling or execution of a ControlScript. The sections below provide a brief description of each component that plays a role in alerts.

 

 

Generate Pool failure and Create Alert

In this exercise we will cause a pool failure to observe the events generated. Also configure an Alert which can notify by sending an email with the pool failure info

Note: Email delivery will fail as the lab environment does not have internet access. The exercise is only to familiarize you with the configuration.

 

 

Create the Alert

 

 

 

Configure the Alert

 

  1. For Name enter Pool-Down-Action
  2. Set Alert Level to High
  3. For Email, select to Create Email Notification

 

 

Create the email notification

 

  1. For Name enter AlertNotification
  2. For To Address enter any email address

Click Save and Save again once finished

 

 

Create Alert Config

 

  1. Navigate to Alert Config
  2. Click Create

 

 

New Alert Configuration

 

Create the Alert according to the parameters below

  1. For Name enter Pool-Down-Alert
  2. Ensure Enable Alert Trigger is checked
  3. Ensure Source is checked to Event
  4. Select Pool as the Object
  5. For Event Occurs, select Pool Down (tip - type pool down in the search box to filter)
  6. For Alert Action, set to Pool-Down-Action (that we created earlier)
  7. Click to Save the new Alert

 

 

Cause pool failure to observe the alert

 

 

 

 

Edit Pool

 

  1. Change the Default Server Port to 8080 and Click Save

 

 

Observe Pool going Down

 

The health monitor fails as the server port is configured wrong and the pool goes down. This is shown with the pool health being red.

 

 

Check Events Generated

 

  1. Use the switcher to navigate to Operations
  2. Click on Events tab
  3. Click a Pool entry to expand and to observe the event generated

 

 

Change Default Server Port back

 

Note: Change the Default Server Port back to 80 via Edit Pool to bring the pool back up.

 

Conclusion



 

Module 6 Conclusion

In this module you learned how to use Analytics, Logs, Events and Alerts to debug and monitor your applications.

Knowledge base references(s):

 

 

You have finished Module 6

Congratulations on completing Module 6.

You have successfully completed all modules in the Avi Networks: Getting Started Guide.

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-2037-01-NET

Version: 20200602-171207