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


Lab Overview - HOL-2137-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-2137 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: 

  • Sergey Marunich, Staff Customer Success Architect, Canada
  • Nick Robbins, Senior Technical Product Manager, United States

 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

For over a decade, we have collaborated with Intel® to deliver innovative solutions that enable IT to continually transform their data centers. We have incorporated Intel® product and technology information within this lab to help users understand the benefits of how both hardware and software technology matter when trying to deploy in VMware’s ecosystem. We believe that this collaboration will have tremendous benefits for our customers.


 

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.

 

 

Click once in active console window

 

In this example, you will use the Online Keyboard to enter the "@" sign used in email addresses. The "@" sign is Shift-2 on US keyboard layouts.

  1. Click once in the active console window.
  2. Click on the Shift key.

 

 

Click on the @ key

 

  1. Click on the "@ key".

Notice the @ sign entered in the active console window.

 

 

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.

 

Module 1 - Introduction to Cloud Connectors (30 minutes)

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 Networks load balancers, powered by 2nd Generation Intel® Xeon® Scalable processors, directed over 1 million SSL TPS. This strong performance indicates that an Avi-Intel solution could handle large numbers of encrypted transactions.

Moving from appliance-based load balancers to software-defined Avi Networks balancers could enable your organization to modernize load balancing services with efficient use of standard computing infrastructure and reduce over provisioning. Because Avi Networks can elastically scale load balancing capacity up or down based on demand, your applications can better utilize available compute power from Intel® Xeon® Scalable  processors.

For enterprises moving to software-defined data centers, the combination of Avi Networks deployed on servers with Intel® Xeon® Scalable processors represents a high-performance solution to load balance large volumes of encrypted traffic.


 

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

 

 

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:

  • Avi Controller (control plane) The Avi Controller stores and manages all policies related to services and management. Through vCenter, the Avi Controller discovers VMs, data centers, networks, and hosts. Based on this auto-discovered information, virtual services can quickly be added using the web interface. To deploy a virtual service, the Avi Controller automatically selects an ESX server, spins up an Avi SE (described below), and connects it to the correct networks (port groups).

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.

  • Avi Service Engines (data plane) Each Avi Service Engine runs on its own virtual machine. The Avi SEs provide the application delivery services to end-user traffic, and also collect real-time end-to-end metrics for traffic between end-users and applications.

Note: VM migration of the Controller and Service Engine images using vMotion is not supported. It is recommended to use NSX ALB's 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

 

  • Login to the Avi Vantage Controller in Region A using the following credentials:
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.

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

  • vCenter URL
  • vCenter credentials
  • vSphere Data Center (Shown on the Datacenter tab)
  • Management Network - port group where NSX ALB service engines management nic will be attached (Shown on the Network tab)

These configuration items are needed for the NSX ALB controller to communicate with vCenter in order to manage the lifecycle of the service engine virtual machines.  

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. 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

 

Here we will select the Data Center in vCenter where the NSX ALB service engines will be created.  We can also select some defaults around how the service engines are addressed, as well as some advanced networking configuration.

  1. Click the Network tab to advance to the next section.

 

 

Edit Cloud - Network

 

Here we'll choose a management port group for the NSX ALB service engines to use for their management nics.  NSX ALB will also create a port group on a standard switch called Avi-Internal  that is used for parking NICs that aren't needed for the current load balancing configuration.  We can also select a template service engine group to use for the automatically created service engines.  This template is an NSX ALB construct, and not the same as a vSphere template.  It allows you to specify things like CPU count, memory, and disk size.

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.

  • Folders: The Avi Controller creates the SE VM in the default AviSeFolder or a folder the user specifies. It creates the folder AviSeFolder if it is not present.
  • Datastores: The Avi Controller performs the data transfer for the SE VM directly to the ESX hosts datastore.
  • Network: 9 out of 10 vNICs for the SE VM are placed in the Avi Internal portgroup of vSwitch0. The Avi Internal standard portgroup is created in vSwitch0 of the ESX host. If vSwitch0 (default standard switch) is not present, then the Avi Controller creates vSwitch0 in the ESX host.
  • vApp: The Avi Controller updates OVF parameters of the SE VM which relate to vApp functionality.
  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:

  • Login: admin
  • Password: VMware1!

 

 

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:

  • Proxy the clients network connection.
  • Perform security, acceleration, load balancing, gather traffic statistics, and other tasks.
  • Forward the clients request data to the destination pool for load balancing.

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

 

  • Login to the Avi Vantage Controller in Region A using the following credentials:
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 30001
    • Ensure the box next to Passive Health Monitor is ticked.  (behind select health monitor window)
  3. Click on the Add Active Monitor 
  4. Click the Select A Health Monitor dropdown
  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 APP_Region01A - 172.16.20.0/24 (note that you may have to scroll down to see it).
    • Note: you may see more than one subnet after 172.16.20.0/24.  This is due to a traffic generator that is spoofing different source IPs, and NSX ALB is discovering these extra subnets via vCenter.  They should not impact the virtual service IP allocation.
  2. Select both k8sworker-01a and k8sworker-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 are not shown when the page loads. 
  • To show the non-significant logs, click on the highlighted button  “Non-Significant Logs”.  
  • The non-significant logs are only collected for 30 minutes from time of Virtual Service creation.

 

 

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

 

  • As mentioned before, the default setting is to collect non-significant logs for 30 minutes from time of Virtual Service creation.
  • To permanently enable non-significant logs for the Virtual Service:  Proceed to Virtual Service: app-01a >  Analytics tab and enable “Non-significant logs”, if the “Non-significant log duration” is set to 0 - non-significant logs will be permanently collected. 
  • To enable logging of all headers in HTTP traffic between clients and servers - enable “Log All headers”. 

Note: https://avinetworks.com/docs/latest/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 arrow icon for the pool selection menu
  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 30001
    • Ensure the box next to Passive Health Monitor is ticked.  (hidden behind health monitor selection window)
  3. Click on the Add Active Monitor box.
  4. Click on the Select a Health Monitor dropdown
  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 APP_Region01A - 172.16.20.0/24 (note that you may have to scroll down to see it).
  2. Select both k8sworker-01a and k8sworker-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.

  • Verify Virtual Service: app-02a by accessing the domain name using the browser on multiple ports, check corresponding logs.
  • Verify Virtual Service: app-02a leveraging curl utility within avitools management virtual machine.

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

 

  • To enter the docker container, execute:
sudo docker exec -it avitools bash

 

 

Verify via avitools - Verify app-02a

 

  • Verify Virtual Service app-02a.region01a.corp.local leveraging curl utility and examine the corresponding logs.

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

 

  • Verify Virtual Service app-02a.region01a.corp.local leveraging http utility and examine the corresponding logs. (output will be very long)

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:

  • None: SSL traffic is handled as pass-through (layer 4), flowing through Avi Vantage without terminating the encrypted traffic.
  • Client-side: Traffic from the client to Avi Vantage is encrypted, with unencrypted HTTP to the back-end servers.
  • Server-side: Traffic from the client to Avi Vantage is unencrypted HTTP, with encrypted HTTPS to the back-end servers.
  • Both: Traffic from the client to Avi Vantage is encrypted and terminated at Avi Vantage, which then re-encrypts traffic to the back-end server.
  • Intercept: Terminate client SSL traffic, send it unencrypted over the wire for taps to intercept, then encrypt to the destination server.

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 30443
  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 APP_Region01A - 172.16.20.0/24
  2. Select both k8sworker-01a and k8sworker-02a from the server list
  3. Click on Add Servers
    (the following steps are not shown in the screenshot)
  4. Once added, Click Next at the bottom of the form, click Next two more times to proceed through the Advanced and Review tabs, 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
  • Make sure SSL Profile System-Standard-PFS and SSL Certificate *.region01a.corp.local options are set for the virtual service secure-app-02a.

 

 

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, and the certificate is shown as valid

 

 

 

Verify Virtual Service - Check Certificate

 

Click on the certificate line in the security menu

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-app-02a 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 -k -i https://secure-app-02a.region01a.corp.local

Minimize Putty when finished

 

 

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

  • Pools maintain the list of servers assigned to them and perform health monitoring, load balancing, persistence, and functions that involve service engine to server interaction. A typical virtual service will point to one pool; however, more advanced configurations may have a virtual service content switching across multiple pools via HTTP request policies or DataScripts. A pool may only be used or referenced by only one virtual service at a time.
  • A Pool will be considered failed when none of the servers are operational, i.e. marked active by associated health monitors. Only active health monitors can mark a server down, servers can be taken down as well by administrator in graceful or non-graceful fashion. The default behavior when none of the servers are active within the pool is to reset incoming client connections.

 

 

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

(-I will suppress the response body but show the headers)

3.   Minimize Putty when finished

 

 

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

 

  • Click on Pools as part of Application tab
  • Click on app-02a-pool

 

 

Pool: app-02a-pool view

 

When in Pool: app-02a-pool view

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

 

 

Access app-02a leveraging browser or curl utility

  • Access virtual service app-02a - http://app-02a.region01a.corp.local leveraging browser or curl utility. Capture virtual service IP address and try to reach virtual service using IP address.
  • Below we show an example of the behavior via avitools (using the Putty session we have running)
root@avitools:/opt/avi# curl -i http://app-02a.region01a.corp.local
curl: (52) Empty reply from server
  • As you can observe, virtual service went down and was taken off the service engine. The end result is TCP connection cannot be established towards virtual service.  In this example, the dynamic FQDN is still registered in DNS, however this is not out-of-the-box behavior.  We have a flag changed for lab purposes to enable DNS registration.  See the following knowledge base article for more information: https://avinetworks.com/docs/latest/dns-record-additions-independent-of-vs-state/ .

 

 

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 FQDN using browser or curl utility.

  1. Maximize the Putty session running avitools
  2. Run:
root@avitools:/opt/avi# curl -i http://app-02a.region01a.corp.local
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>
root@avitools:/opt/avi#

As failure behavior was changed, the virtual service was placed back on service engine and client can get a 503 response.  As mentioned before, the DNS entry is still maintained for lab purposes.

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.

  • The health monitors are attached to a pool for the virtual service.
  • A pool that is not attached to a virtual service will not send health monitors and is considered an inactive configuration.
  • A pool may have multiple active health monitors (such as ping, TCP, and HTTP) configured, as well as a passive monitor.
  • All active health monitors must be successful for the server to be marked up.

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

  • We will modify secure-app-02a-pool adding more granular health monitors that will monitor pool members on port 80 and 443.

 

 

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

 

  • The pool state has changed to Down. If one of the active monitors fails, the pool member will be marked as down. As you probably have noticed, Default Server Port is set to port 30443, that will by default force both of health monitors to monitor the pool member on port 30443. As result, HTTP health monitor will fail on non-HTTP port.
  • The health monitor configuration can include monitor port as well which will take precedence over the pool port.

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 30080 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 30080
  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

 

  • As you can observe, the pool state has changed to Up.
  • The goal of this exercise was to emphasize on extensive health monitoring capabilities, contrast between active and passive health monitors, and highlight importance of proper active health monitors.
  • If you cannot find the health monitor that you are looking for from presets, the Avi Vantage platform provides the ability to write customer external health monitors.
  • The external monitor type allows scripts to be written to provide highly customized and granular health checks. The scripts may be Linux shell, Python, or Perl, which can be used to execute wget,netcat,curl,snmpget,mysql-client, or dig. External monitors have constrained access to resources, such as CPU and memory to ensure normal functioning of Avi Service Engines. As with any custom scripting, thoroughly validate the long term stability of the implemented script before pointing it at production servers.
  • Note: https://avinetworks.com/docs/latest/external-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

 

  • Switch to the Administration screen

 

 

Access Tenants - Create

 

  1. Click on Tenants
  2. Click Create

 

 

New Tenant

 

  1. Enter engineering as the name
  2. Click 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 30443
  2. Click Add Active Monitor and select System-HTTPS as the option
  3. Click check box for Enable SSL
  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 APP_Region01A - 172.16.20.0/24 as the network
  2. Select k8sworker-01a and k8sworker-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

 

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



 

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

 

  • Login to the Avi Vantage Controller in Region A using the following credentials:
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
  • High Availability Mode:
    • Elastic HA Active/Active
    • Elastic HA N + M
  • Compact Placement: When enabled, new virtual services are placed on existing SEs with other virtual services. Disabling this option places each new virtual service in its own SE until the maximum number of SEs for the SE group is reached. At that point, a new virtual service will be placed on the SE with the least number of virtual services. When this option set, Vantage will attempt to conservatively create new SEs.
  • Virtual Services per Service Engine: Controls the maximum number of virtual services that may be deployed on a single SE. Another SE must be created or used if this maximum is reached. If Vantage reaches the maximum number of SEs, then no more virtual services can be deployed within the SE group.
  • Scale per Virtual Service - Minimum: The virtual service may be scaled across multiple SEs, which both increases potential capacity and ensures recovery from any failure while minimizing impact. Setting the minimum above 1 ensures that every virtual service starts out scaled across multiple SEs regardless of capacity requirements.
  • Scale per Virtual Service - Maximum: Sets the maximum number of SEs across which a virtual service may be scaled.
  • Service Engine Failure Detection: Sets the maximum amount of time a primary SE can remain silent before the SE is declared dead by the Avi Controller.
    • Standard: Primary SE can remain silent (stop sending heartbeats) for a maximum of 9 seconds before being declared dead.
    • Aggressive: Primary SE can remain silent (stop sending heartbeats) for a maximum of 1.5 seconds before being declared dead.
    • Buffer Service Engines: This option sets the value of M for elastic HA N+M mode. Compact placement should be left in its default state for N+M, which is OFF. Vantage will maintain spare capacity in the SE group to be used to replace any failed SE.
    • Health Monitoring on Standby SE: Enables the standby SE in a legacy HA configuration to send health checks to back-end servers.

 

 

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



 

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.

  • Scaling out a virtual service distributes that virtual service to an additional SE. By default, Avi Vantage supports a maximum of four SEs per virtual service when native load balancing of SEs is in play.  In BGP environments the maximum can be increased to 32.
  • Scaling in a virtual service reduces the number of SEs over which its load is distributed. A virtual service will always require a minimum of one SE.

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

Knowledge base references(s):

VMware NSX Advanced Load Balancer (Avi Networks) delivers scalable application services including local and global load balancing, WAF, application analytics, and container ingress services for both VMware and non-VMware environments. In an independent lab, Principled Technologies put the Avi Platform to test delivering over 1 million SSL TPS powered by 2nd Generation Intel® Xeon® Scalable processors.

For enterprises moving to software-defined data centers, the combination of NSX Advanced Load Balancers deployed on servers with Intel® Xeon® Scalable processors helps deliver fast, multi-cloud load balancing with complete analytics-driven automation, and powerful application insights that simplify troubleshooting.

Principled technologies benchmark whitepaper:

 https://www.vmware.com/learn/578657_REG.html


 

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.

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

 

  • Login to the Avi Vantage Controller in Region A using the following credentials:
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:

  • The virtual service IP is GARPed by the primary SE. All inbound traffic from clients will arrive to this SE.
  • The primary SE may handle a percentage of traffic, which is handled normally.
  • Excess traffic is forwarded at layer 2 to the MAC address of additional secondary Service Engine(s).
  • The scaled-out traffic to the secondary SEs is processed as normal. The SEs will change the source IP address of the connection to their own IP address within the server network.
  • The servers will respond back to the source IP address of the traffic, which may the primary or one of the secondary SEs.
  • Secondary SEs forward their response traffic directly back to the origin client, bypassing the primary SE.

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-kkrsr

  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 seg01a-se-kkrsr as the source SE
  2. Select seg01a-se-exzef as the destination SE
  3. 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-exzef.

 

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 (30 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/latest/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.

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

 

  • Login to the Avi Vantage Controller in Region A using the following credentials:
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. If logs aren't populated, click the refresh button
  2. Find the log entry with 307 and click the '+' next to it. (you will likely have to scroll down a bit)
  3. Note that the Virtual Service IP port is 80
  4. 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


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:

  • HTTP errors, such as server or Vantage-originated 4xx and 5xx errors
  • Network errors, such as aborted connections, abnormal latency, or out of order packets.
  • See Log Events for a list of error events that may trigger a significant Log.

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.

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

 

 

 

Enter Credentials

 

  1. 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 check to see if full client logs are enabled, and show how to export those logs to a CSV file.

 

 

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, ensure Log all headers and Non-significant logs are checked.  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-02a

 

 

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 session for avitools.corp.local and use curl commands below to send traffic to secure-app-02a with different SSL Versions
  • Repeat the commands few times to send multiple requests.

 

 

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

  • To debug this from Virtual Service logs, go back to Avi Vantage Controller

 

  1. Open Virtual Service secure-app-02a
  2. Click on Logs subtab
  3. Make sure Non-Significant Logs are also enabled.
  4. Click the arrow icon to pop-out the right sidebar if it isn't already exposed.

 

 

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)

For this exercise, we will use a pre-built Virtual Service that has been receiving traffic from a traffic generator for us to analyze.

 

 

Check logs for demo-vs-01a

 

  • On Avi Controller UI, open Virtual Service: secure-app-02a
  • Click on Logs subtab
  • Make sure Non-Significant Logs are also enabled

 

 

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 128kb.txt is missing on the backend server

Resolution:
Upload the missing file to the backend servers

 

 

How to Determine Client Location

 

  • On a public Virtual Service, you can click on Location under Client Analytics on the right column.

As mentioned previously, we have a traffic generator sending traffic to this VS which includes traffic with the source IP address spoofed to facilitate this demo.  The Avi controller uses the source IP address to look up which country is responsible for that IP block, and uses that to determine location.

 

 

Additional Client Analytics

 

As you can see from the above screenshot, we can also see client information such as browser type, client OS, and device type.  This information is derived from the headers sent to the webserver, like User-Agent.

 

 

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

 

  1. On Avi controller UI, navigate to Operations using the tab switcher
  2. Click  Alert Actions Subtab
  3. Click on the Create button

 

 

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. Enter a short description.
  4. Ensure Source is checked to Event
  5. Select Pool as the Object
  6. For Event Occurs, select Pool Down (tip - type pool down in the search box to filter)
  7. For Alert Action, set to Pool-Down-Action (that we created earlier)
  8. Click to Save the new Alert

 

 

Cause pool failure to observe the alert

 

 

  • Use the switcher to navigate to Applications,
  • Click on the Pools tab
  • Click on the pencil icon to edit app-01a-pool

 

 

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 30001 via Edit Pool to bring the pool back up.

 

Module 6 Conclusion



 

You have finished Module 6

Congratulations on completing Module 6.

You can now proceed to any of the remaining modules:

 

Module 7 - Leveraging Automation Migration Toolkit to accelerate migrations from F5 to VMware NSX Advanced Load Balancer

Introduction to Leveraging Automation Migration Toolkit to accelerate migrations from F5 to VMware NSX Advanced Load Balancer


In this module, we are going to walkthrough a migration from F5 to VMware NSX Advanced Load Balancer using the automation migration toolkit and the AviTools Docker container.

NOTE: This module makes the assumption that you've completed the HOL 2137-01 modules before this one.

Reference(s):

Migration Toolkit

Several tools can be found in avinetworks/sdk repository, but our main focus in this lab will be the Migration toolkit.  The migration toolkit contains tools to take Loadbalancer configurations and convert them into NSX Advanced Loadbalancer configuration.  In this lab our focus will be leveraging the F5 migration toolkit process and scripts it contains.

Overview

In this lab we will complete two different migrations, a basic migration and an advanced migration utilizing the F5 migration tool.  We will walk you through the scripts available in the toolkit and common flags leveraged in migration process and any additional scripts in the toolkit to complete a full migration and the validation process.

Scripts Used in this Module:

f5_converter.py

Script takes a bigip.conf and translates it to NSX ALB configuration, this script comes with many flags, we will go through many of the common ones used.  If you want to dig on what other flags are available you can run f5_converter.py --help and dig further

config_patch.py  

Script reads a YML patch file to update the migration tool JSON output. The result is a patched JSON file with the file extension json.patched 

  • -c: Calls the JSON configuration to patch 
  • -p: Calls the YML patch file 

avi_config_to_ansible.py 

Script converts JSON file back to and Ansible playbook (.yml)  

  • -c: Calls the patched JSON file to convert to Ansible playbook 
  • –controller_version: Sets the api_version variable in the plays. This value should match the NSX ALB version 

migration_report.py

Script will log into the NSX ALB Controller and create a spreadsheet to easily evaluate objects that are created on the NSX ALB Controller.

  • -c: NSX ALB controller IP/FQDN
  • -u: NSX ALB Controller username
  • -p: NSX ALB Controller password
  • -v: NSX ALB API Version (20.1.2)

In this lab we will also use VSCode and the AviTools docker container, which we will prepare next!


 

Differences that Toolkit takes into Consideration

OneConnect/Connection-Multiplexing 

F5 OneConnect is a LTM profile that allows you to reuse established server-side TCP connections to servers in pools behind the BIG-IP when sending HTTP traffic.  The NSX ALB equivalent is application profile that has ConnectionMultiplex enabled.  In cases where everything is shared on  F5 VirtualService except ConnectionMultiplex, the F5_converter.py will create a new Application Profile with a suffix of -cmd(connection multiplex disabled).

Pool Sharing

Pool Sharing in NSX ALB has some considerations that are different than F5 LTM, but the f5_converter.py captures these during the migration effort.  Keep this in mind in case you're wondering why there are different pools being created.

More Details can be found: https://avinetworks.com/docs/latest/pool-sharing-across-virtual-services

 

 

Open VSCode

Go to the desktop and open Visual Studio Code

 

Launch Visual Studio Code

Note: It may open with another file, just exit this one (click the x)

 

  1. Expand: AVI [SSH: AVITOOLS]
  2. Click on: hol
  3. Click on: migration
  4. Select: hol_basic_bigip.conf

Also the hol_advanced_bigip.conf can be found in this folder for you review.

Once the file is open, we can see this is a F5 bigip.conf file, which is the first one we will be migrating from F5 configuration into an NSX ALB configuration.

As the lab progresses new files and folders will be created, so if you want to review contents, you can leave VSCode open and review as we progress through the lab.

 

 

Log Into AviTools Container

We will be using AviTools docker container to run the scripts and push our migrated configurations to the NSX ALB controller, so lets first log in to this.

Note: This docker container is publicly available: https://github.com/avinetworks/avitools

 

Open Putty on taskbar

 

  1. Select avitools.corp.local
  2. click Open

Note: if prompted username: holuser and password: VMware1!

 

Once logged in:

  1. Become root user: sudo su (if prompted - password: VMware1!)
  2. Log into avitools docker container: docker exec -it avitools bash
  3. Navigate to hol/migration folder: cd hol/migration

 

In the hol/migration directory we will be focusing on the files labeled basic in the first part of this module.

  1. ls | grep basic

We will be using this avitools container and files in this directory throughout the lab.  This docker container also has scripts preloaded onto it as well.

If you ever want to see more examples or read about flags available for the scripts you can always run the script with a --help flag

 

 

example:

f5_converter.py --help

In Summary

  • AviTools will be used to run the scripts to migrate F5 configuration to NSX ALB configuration and to push the configuration to the NSX ALB
  • VSCode will be used to review the configuration files

 

 

Basic Migration

This migration is comprised of five Virtual Services (VS) that we will import into the admin tenant. These five Virtual Services will demonstrate the ability to migrate layer 4 and layer 7 VS's with different ports, with or without Secure Socket Layer (SSL) certificates/profiles and their dependency objects like pools. These pools with have backend servers, health monitors (TCP and HTTP) and different kinds of persistence profiles to include cookies and client IP.

F5 Migration Tool Flags for Basic Migration:

f5_converter.py script for the conversion from F5 configuration to NSX ALB configuration.

  • -f hol_basic_bigip.conf: Points the script to the configuration file you want to migrate, in this case, the file name is hol_basic_bigip.conf 
  • --no_object_merge: Doesn’t allow the tool to merge objects with similar attributes 
  • --not_in_use: Skips objects that aren’t in use. This is a great way to help clean up old config and not bring it over in the migration 
  • --vrf global: Reference vrf object that needs to be configured for, in this case, the “global” vrf 
  • --tenant admin: Reference the tenant the object that need to be created in, in this case, the “admin” tenant 
  • --controller_version 20.1.2: The software version of the NSX ALB, in this case, it's “20.1.2”  
  • --cloud_name Default-Cloud: Reference to whichever cloud the objects need to be created in; in this case, it is the “Default-Cloud”   
  • --segroup Default-Group: Reference to whichever service engine group the VS’s need to be a part of, in this case it is the “Default-Group” 
  • --ansible:  F5 migration tool creates Ansible playbooks as part of the output (avi_config_create_objects.yml and avi_config_delete_objects.yml
  • -o basic_migration: F5 migration tool creates a directory called “basic_migration” and will place all of the output files in it.  
  • --vs_level_status: Adds columns of VS reference and overall skipped settings in status migration excel sheet output 

 

 

Begin Basic Migration

In our putty session on the AviTools container we will now dive in and complete the migration of the hol_basic_bigip.conf file to NSX ALB configuration and get it install on our NSX ALB Controller.

As mentioned earlier, we have flags outlined for the Basic Migration so lets run the f5_converter.py script utilizing them.

In AviTools container run the f5_conveter.py script as follows:

f5_converter.py -f hol_basic_bigip.conf --no_object_merge --not_in_use --vrf global --tenant admin --controller_version 20.1.2 --cloud_name Default-Cloud --segroup Default-Group --ansible -o basic_migration --vs_level_status

 

Script will run through a conversion of all the F5 objects into NSX ALB objects with a status and at the end it will provide a summary of number of objects converted.

 

A new folder is created called basic_migration and we can view contents as follows

  • Navigate to new folder output from script: cd basic_migration
  • Check whats inside this new folder: ls -l

Or better yet, we can look at these files using VSCode which will be much easier to review the contents of the files.

  1. avi_config_create_object.yml and avi_config_delete_object.yml are the Ansible playbooks for configuring or deleting the migrated configurations
  2. converter.log has details about the script runtime
  3. hol_basic_bigip-ConversionStatus.xlsx will have a report of what was converted and if any errors occurred during conversion (in excel format to easily digest)
  4. hol_basic_bigip-Output.json is the new NSX ALB Configuration file

You can use VSCode to review these files.

 

 

Read Excel Report

Lets take a look at the hol_basic_bigip-ConversionStatus.xlsx a little closer, as it can help provide more detail on the migration process.

 

  1. In VSCode navigate to: hol -> migration -> basic_migration
  2. Right click hol_basic_bigip-ConversionStatus.xlsx
  3. Click Download

 

  1. Click on Desktop as the save Destination
  2. File Name: hol_basic_bigip-ConversionStatus.xlsx
  3. Click Download

 

Now we can open the file located on the Desktop, which will open using Libre Office.

The spreadsheet is full of information about what was converted during the script runtime, and can be used to determine if any further conversion is required.  The spreadsheet will outline the F5 Objects and details about them, if the migration completed successfully, and details regarding objects that were skipped, at the very end we can find details about the Avi Configuration that was created.

 

We navigate this spread sheet by enabling filters for the columns to easily navigate the spreadsheet.  To do this click on the AutoFilter Icon.

 

Now that we've enabled the AutoFilter we can see we get a dropdown icon beside each item in Row1.

This will allow us to drill down into specific objects, one of the more useful columns is the Status column, as this gives information about the migration objects and if any errors occurred.

 

  1. Click the dropdown for Status
  2. Uncheck everything except Partial
  3. Click Ok

Now we can drill down to only what was Partial converted and determine if any manual intervention is required to migrate the objects that weren't fully successful.  

For this one if you go to the Column VS Reference we can see NOT IN USE listed, so again we can use the filter to ignore these since they aren't used and focus more on the ones in use.  These filters are a good way to look through and to figure out what specific objects still need some attention.

 

 

Basic Migration Continued

What's Next?  So far, this is where we are:

  1. We ran the f5_converter.py to complete a migration from F5 configuration to NSX ALB Configuration
  2. We reviewed the files that were created
  3. And we took a look at the hol_basic_bigip-ConversionStatus.xlsx and how to consume it

So we could stop here and apply the configuration to the  Controller now, but what if there are some defaults that were applied that you might want to modify.  Well, this is a common scenario for us so we will share another little script named config_patch.py

What config_patch.py does: it will read over a NSX ALB Configuration file and look for specific details provided in a patch file and make the necessary changes.

 

Let's take a look at the patch file we will use in this example in VSCode:

  1. In VSCode navigate to: hol -> migration
  2. Open file named: hol_basic_patch.yml

 

In this file we can find comments describing what happens, but a quick rundown.

  1. Focus is on VirtualService objects
  2. Match type will be on the name of VirtualService, and this is using wildcard to match all names(.*)
  3. And action is a patch, which means we are looking to update the configuration to have the following settings

So in summary we are looking to update all VirtualService objects to have the properties updated to have the values as shown below patch

 

So now we need to go back to our AviTools container.

  1. Navigate to the basic_migration folder that was created when running the f5_converter.py: cd /opt/avi/hol/migration/basic_migration
  2. Now lets patch the JSON file that was created by the f5_converter.py with the patch file we reviewed previously: config_patch.py -c hol_basic_bigip-Output.json -p ../hol_basic_patch.yml
  3. Once script is executed it will have a debug output and Progress will read 100% when complete
  4. From this you should now see a new file called hol_basic_bigip-Output.json.patched type in ls

Now we have a new patched NSX ALB Configuration file hol_basic_bigip-Output.json.patched.  We will need to create new Ansible Playbook to push the NSX ALB configuration to the NSX ALB Controller. This can be done using avi_config_to_ansible.py script in our toolkit.

 

Lets do this:

avi_config_to_ansible.py -c hol_basic_bigip-Output.json.patched --controller_version 20.1.2

After script is completed running an ls we see we have 2 new Ansible Playbook files, avi_config.yml and avi_config_delete.yml

So now we have a F5 Config file that is migrated to NSX ALB Configuration and also patched some specific settings of all the converted Virtual Services.  Lets now apply these configuration to the NSX ALB Controller using the Ansible Playbooks!

 

On the AviTools Container in the hol/migration/basic_migration folder execute:

ansible-playbook avi_config.yml -e "controller=avicon-01a.corp.local username=admin password=VMware1!"

The Ansible Playbook will take some time to build all the objects, but will indicate how many changes took place and if any errors occurred.

 

 

Basic Migration Validation

Now lets look to validate all the configuration on the NSX ALB.  First we will log into the NSX ALB and review changes.

 

  1. Open Google Chrome

 

  1. On Chrome Bookmark Bar click: Region A
  2. Click on: Avi Vantage Controller A
  3. Username: admin
  4. Password: VMware1!
  5. Click Login

 

Once logged in, lets validate the VirtualServices that were deployed

  1. Select Applications
  2. Click VirtualServices to get a summary view
  3. Here we can see 5 VirtualServices were created with hol-basic in the name

Based off the F5 Migration, we can now validate the following settings were migrated to NSX ALB Configuration:

  1. 1-hol-basic-vs
    - Port 80
    and Custom Application Profile named http-cmd
    - Custom Persistence Profile Named cookie-vmware
    -
    Custom Health Monitor http_hol
  2. 2-hol-basic-vs
    - Port 443
    and Custom Application Profile named http-cmd
    -
    Custom SSL Profile client_ssl_profile and SSL Certificate client_ssl_cert.crt-dummy
    -
    Custom Health Monitor http_hol
  3. 3-hol-basic-vs
    - Port 8080
    and Application Profile System-L4-Application
    -
    Persistence Profile source_addr
    -
    Health Monitor tcp
  4. 4-hol-basic-vs
    - Port 443
    and Application Profile System-SSL-Application
    -
    SSL Profile client_ssl_profile and SSL Certificate client_ssl_cert.crt-dummy
    -
    Health Monitor tcp
  5. 5-hol-basic-vs
    - Port 80
    -
    Health Monitor http_hol

Once all this is validated on the NSX ALB Controller we have completed our first F5 Configuration to NSX ALB Configuration Migration with some minor customization using the patch utility.  

Next we will be diving into a more advanced migration!

 

 

Advanced Migration

This migration is comprised of one hundred Virtual Services that we will import into the hol tenant. These one hundred VS's demonstrate the ability to migrate layer 4 and layer 7 VS's with different ports, with or without Secure Socket Layer (SSL) certificates/profiles and their dependency objects like pools. These pools will have backend servers, health monitors (TCP and HTTP) and different kinds of persistence profiles to include cookies and client IP. These VS's are grouped into groups of 10  that will incorporate a number of different advanced topics that include: iRules, multiplexing, pool failure responses, load balancing algorithm updates, etc.

F5 Migration tool Flags for Advanced Migration 

f5_converter.py script for the conversion from F5 config to NSX ALB Configuration.

  • -f hol_basic_bigip.conf: Points the script to the configuration file you want to migrate; in this case, the file name is hol_basic_bigip.conf 
  • --no_object_merge: Does not allow the tool to merge objects with similar attributes 
  • --not_in_use: Skips objects that aren not in use. This is a great way to help clean up old config and not bring it over in the migration 
  • --vrf global: Reference vrf object that needs to be configured for, in this case, the “global” vrf 
  • --tenant hol: Reference the tenant the object that need to be created in, in this case, the “hol” tenant 
  • --controller_version 20.1.2: The software version of the NSX ALB, in this case, it's “20.1.2”
  • --cloud_name Default-Cloud: Reference to whichever cloud the objects need to be created in, in this case, it’s the “Default-Cloud”  
  • --segroup Default-Group: Reference to whichever service engine group the VS’s need to be a part of, in this case it’s the “Default-Group”  
  • --ansible: F5 migration tool creates Ansible Playbook as part of the output (avi_config_create_objects.yml and avi_config_delete_objects.yml
  • -o advanced_migration: F5 migration tool creates a directory called “advanced_migration” and will place all of the output files in it.  
  • --custom_config converted_irules.yml: references a file that has http policies in NSX ALB format converted from F5 irules
  • --reuse_http_policy: Attach the same http policy object to all the applicable VS's instead of creating a duplicate object of each policy for each applicable VS. A feature now available in 18.2.3+ 
  • --vs_level_status: Adds columns of vs reference and overall skipped settings in status migration excel sheet output 

Some other useful flags not in this Lab but to be aware of:

  • --prefix: Adds a prefix name to all objects 
  • --distinct_app_profile: Option to create distinct application profile for each VS even though VS’s share profiles in F5 config 
  • --vs_filter: Select a subset of VS’s to migrate 
  • -v: F5 config version. This flag is required when migrating F5 version 10 config. Not required for 11+ code 

 

 

Task 1 - iRule a Step by Step Approach

iRules do not get migrated in the conversion tool.  Which means we need to manually intervene and understand what the iRule is accomplishing in order to figure out what it would translate to NSX ALB configuration.

Lets start by looking at Task #1

Task Virtual Services Convert
1 VS1-10
  1. ltm data-group internal /Common/denylist_ips to NSX ALB IP Address Group
  2. ltm rule /Common/denylist to NSX ALB Network Security Policy leveraging NSX ALB IP Address Group
  3. NSX ALB Network Security Policy will be applied using custom_config file named converted_irules_student.yml

We can see we have 3 conversion tasks, lets tackle these one at a time, as it looks like we have a pre-requisite in this iRule being a data-group

 

Starting with the ltm datagroup /Common/denylist_ips conversion.  Now this looks like we could convert it to a NSX ALB IP Group configuration, but lets dig a bit to get a better idea.

  1. Jump back to VSCode and open the hol_advanced_bigip.conf
  2. click Edit and select Find
  3. enter denylist_ips into search box and hit enter
  4. Should present the data-group named /Common/denylist_ips

So this is what we want to convert to NSX ALB configuration, and it does look like NSX ALB IP Group after all.  For this one, since it is a shared object, let's configure it to get an idea of effort involved.

 

So, let's go back to the Chrome session that had you logged into the NSX ALB (username: admin / password: VMware1!)

  1. Click the top left corner (3 lines)

 

  1. Select Templates
  2. Click on Groups tab
  3. We should see we are in IP Groups
  4. Select Create IP Group

 

  1. IP Group Name: denylist_ips
  2. In IP Address box add the following IPs and click Add
    192.168.110.10/32
    192.168.110.11/32
    192.168.110.12/32
    192.168.110.13/32
    192.168.110.14/32
    192.168.110.15/32
    192.168.111.0/24
  3. Once confirmed we have everything, click Save

Now we should have our IP Group for the first part of Task 1.  With the f5_converter tool we have ability to use a custom configuration file that can be used to insert configuration that wasn't migrated, so let's look at the process to update the custom configuration file for the second part of Task 1.

 

 

Step by Step Custom Configuration for iRule Conversion

Now let's look at second part of Task1

2. ltm rule /Common/denylist to NSX ALB Network Security Policy leveraging NSX ALB IP Address Group

 

If we look in the hol_advanced_bigip.conf file like we did previously and search for the irule named /Common/denylist we should see the above.

Taking a second to read the code, there is a match on a client address and it reads a list of ips in denylist_ips datagroup then will drop the connection.  Or if you're lucky, the code is nicely commented and can help guide you to the objective of the irule.  This one will translate nicely to NSX ALB HTTP Security Policy

Another thing you might notice is when doing the search you can get the number of times the name you're searching for returns; in this case it was 14 and it's because there are Virtual Services using this rule.  Now, we saw how tedious converting the rule can get if you have to do it several times in the User Interface.

This time we will build a template and place it in a custom configuration file.  We can do this by adding the configuration required, extract the configuration from an API call, and place it in a custom configuration file, in this case it is converted_irules_student.yml

So Let's Build the Template 

 

  1. Switching back to the Google Chrome window that has NSX ALB, click the 3 lines and select Applications

 

There is a demo-vs-01a Virtual Service available to help build our templates for custom configurations.

  1. Click demo-vs-01a (it should bring you to analytics screen)
  2. Click Edit (pencil icon)

 

  1. Select Policies
  2. Should end up in Network Security
  3. Click the Green plus to add a rule
  4. Rule Name: denylist

 

A Rule should get generated

  1. Rule Name: denylist
  2. Click the Add New Match dropdown  
  3. Select Client IP (this will create a rule to match on client IP)

 

And finally:

  1. We want Client IP Address IS
  2. Use the IP Address dropdown and select the IP Address Group we created denylist_ips
  3. Action will be deny
  4. Click Save Rule
  5. Click Save

 

Now we have the configuration, how can we extract the configuration?

  1. Right click the Google Chrome tab for NSX ALB
  2. Click Duplicate

 

In the new tab, we want to look up configuration for the specific HTTP Security Policy, so in the URL bar insert the following URL:

  1. https://avicon-01a.corp.local/api/networksecuritypolicy?name.contains=demo-vs-01a

Note: if you get 401 - it just means your session logged out so just log back using the other tab

  1. Click on the value beside url

Note: NSX ALB configuration is all in JSON format for easy parsing, so what you're looking at is real configuration that is presented as key/value pairs.

What you see on this page is our template!

 

Now lets copy what we want.

  1. Click Raw
  2. Select All
  3. Right click and Copy

 

Going back to VSCode

  1. File -> New File
  2. Paste Raw output into the new File

 

  1. Select All the text in this New File
  2. Click View -> Command Pallet

 

An Input box in center of the screen should have appeared

  1. Type in YAML
  2. Click Convert selection to YAML
    Note
    : if this doesn't appear, verify that the text his highlighted

 

Now we have a block of text in YAML format, which will fit perfectly in our converted_irules_student.yml.

  1. Highlight everything under rules and everything under it
  2. Right click and click copy

 

In VSCode on left side panel:

  1. Open converted_irules_student.yml
    You will see that the file has been somewhat prepared for the irules that need to be converted
  2. As we are working on denylist we will be focusing on that section

 

YAML files are strict on how indentation is done, so if you're unsure refer to the picture above!

  1. Now add in the name: denylist and what we copied from the new file under it, and keep indentation in mind as it's YAML
    Note: if your not familiar with YAML files, refer to screenshot (all spaces are TABs)
  2. Also under groups we want to reference our ipaddrgroup name, so that if we did automate the creation of ipaddrgroup the NSX ALB will add it by name, instead of the uuid which might not exist
    - /api/ipaddrgroup/?name=denylist_ips
  3. Save File

And there we go!  We converted the irule that was bound to multiple VirtualServices to a Network Security Policy!  And we will include this in our f5_converter.py runtime so that it will find any VirtualService with an irule of denylist and bind this Network Security Policy to it!

Note: we have also have a file named converted_irules.yml.  This file is what your converted_irules_student.yml should look like at the end of this module.

 

 

Task 5 iRule

So we took a Step by Step Custom Configuration for iRule Conversion for this one we will run through it a bit more quickly and if needed just refer back to the Step by Step approach.

Task # Virtual Services Convert
5 VS - 41-50
  1. ltm rule /Common/insert_true_client_ip to a HTTP Request policy. 
  2. NSX ALB HTTP Request Policy will be added to custom config file

Let's go through another iRule example which can be found in Task 5.  In the last task we went step by step, so let's speed it up a little bit, if you get stuck on where something is, just refer to our step by step approach we took in Task 1.

 

The name of this one is /Common/insert_true_client_ip, just like the Task previous to this we can dig into what the irule looks like inside of the hol_advanced_bigip.conf file in VSCode (steps to do this can be found in Task1 conversion).

Just looking at the comments, it looks like a header insert leveraging the client IP Address, which in NSX ALB translates to HTTP Request Policy.  So, just like we did in the previous Task, let's create our template and get it in the converted_irules_student.yml file.

 

Jump back  to Google Chrome and open the NSX ALB tab.  

  1. Just like previous task we will use demo-vs-01a VirtualService
  2. Click on the pencil to edit the VirtualService

 

Now to convert the iRule into NSX ALB configuration using HTTP Request Policy, which in turn will become our template just like we did for the Step by Step Custom Configuration for iRule Conversion previously

  1. Click Policies tab
  2. Select HTTP Request
  3. Click the green Add (+) (not shown)
  4. Rule Name: insert_true_client_ip
  5. Click Add New Action dropdown and select Modify Header
  6. From the iRule we can see after the Request is received we want to insert a header named True-Client-IP and it will be the value of Client IP.  So now lets make the Rule
  7. Click Save Rule
  8. Click Save

 

Now we should have the configuration template, so just like before duplicate the NSX ALB tab, and let's grab the configuration from the following API call:

  1. https://avicon-01a.corp.local/api/httppolicyset?name.contains=demo-vs-01a
  2. Result click on the url

If you get stuck, Refer back to  Step by Step Custom Configuration for iRule Conversion.

  1. Now Click on the Raw button and we will copy it over to a new file in the VS Code.
  2. Convert the Raw JSON output to YAML via View -> Command Pallette
  3. And Copy rules section over to our converted_irules_student.yml file under the insert_true_client_ip rule_name
    Note: remember to format this properly (indents using TAB)
  4. Save the updated file

So now our converted_irules_student.yml should look as follows:

 

So now we have 2 iRule conversions completed that we can include when we run the f5_converter.py tool, and it will automatically incorporate the conversions during the migration process.

 

 

Task 8 - iRule

We've done 2 iRule conversions to the converted_irule_student.yml file now, and there is one more to look at.  Let's dive in!

Task # Virtual Services Convert
8 VS - 71-80
  1. Create a string group that includes the paths in the iRule and configure an NSX ALB HTTP Request Policy.
  2. ltm rule /Common/path_match_respond_403 to a NSX ALB HTTP Request Policy 

Looking at the iRule named /Common/path_match_respond_403 in the hol_advanced_bigip.conf file, we look to have an iRule with very few comments, so this time we need to figure out what it's achieving.

  1. action occurs when HTTP_REQUEST is sent to the device
  2. And then match against a pattern in the URI being equal to the following paths is done:
    /secure/
  3. /system/
  4. /admin/
  5. /login/
  6. And finally if the paths do match with incoming request URI, respond with a 403

Well we could create on NSX ALB HTTP Security Policy and add all 4 of those paths, but let's leverage StringGroups which make modifications and management of this list so much easier. Let's quickly create this!

 

Create the String Group first on the NSX ALB. Navigate back to your Chrome TAB and go to Templates -> Groups and click on StringGroups

 

Click Create

  1. Name the stringgroup path_match_respond_403
  2. Add the 4 paths
  3. Click Save

Now that we have our stringgroup, let's go back to focusing on the iRule template creation

So Just like before, it's an HTTP Security Policy, but this time theres a match, so its just easier to build the template like we have done for previous iRule Conversions.

 

Go back to the demo-vs-01a Virtual Service and click the pencil icon to edit

Note: If you need a refresh on the step by step approach, refer to the first one we did Step by Step Custom Configuration for iRule Conversion

 

 

Navigate to Policies

To simplify the process, go to HTTP Request and delete the rule we created for Task5

Now go to HTTP Security

  1. Rule Name: path_match_respond_403
  2. Add New Match on Path
  3. Criteria is Contains (don't check Match Case)
  4. String Group will be the path_match_respond_403 we created earlier
  5. Add New Action Send Response
  6. Check the Status Code for 403
  7. Save Rule
  8. Save

Once saved, we can go back to the API and build our template and insert it into the converted_irules_student.yml file.

 

Go to your second tab and paste the following into the URL bar:

https://avicon-01a.corp.local/api/httppolicyset?name.contains=demo-vs-01a

and then click on the url similar to the previous Tasks.

 

Now click on Raw and copy all the text and move it over to a New File in VSCode.

In VSCode convert the code to YAML.

  1. Copy rules and content below to the converted_irules_student.yml file under the path_match_respond_403 rule_name
  2. stringgroup refs, we will point to the name of the stringgroup such as /api/stringgroup?name=patch_match_respond_403

Note: If you get stuck at any point in this process refer to the Step by Step Custom Configuration for iRule Conversion

We have now gone through the process of converting 3 iRules into NSX ALB Configuration.  You can compare your completed converted_irules_student.yml file against the converted_irules.yml file in the same folder; the only difference will be cosmetic, such as naming.

 

 

Time to Run Advanced Migration

Go back to the AviTools Container and make sure you're logged into the docker container and in folder:

cd /opt/avi/hol/migration

Note: Look to Log Into AviTools Container if you need the steps to get here again.

Once we are there, let's begin the migration, paste the following into the AviTools docker container:

f5_converter.py -f hol_advanced_bigip.conf --no_object_merge --not_in_use --vrf global --tenant hol --controller_version 20.1.2 --cloud_name Default-Cloud --segroup Default-Group --ansible -o advanced_migration --custom_config converted_irules_student.yml --reuse_http_policy --vs_level_status

Note: for more details on these flags refer to the beginning of the Advanced Migration

 

If you run into issues with the converted_irules_student.yml you can run the same command using the converted_irules.yml file.

f5_converter.py -f hol_advanced_bigip.conf --no_object_merge --not_in_use --vrf global --tenant hol --controller_version 20.1.2 --cloud_name Default-Cloud --segroup Default-Group --ansible -o advanced_migration --custom_config converted_irules.yml --reuse_http_policy --vs_level_status

And at the end we should get a summary similar to the Basic Migration

 

Again a new folder is created named advanced_migration

Review the files generated with VSCode

 

 

Config_Patch Advanced Migration

So, again we have some configuration we need to patch,  for which we helped put together a file.  Please find a patch file called hol_advanced_patch.yml and this file will cover all the other objectives we have outlined in the Tasks found at the beginning of the Advanced Migration.  Please review this file in the migration folder

 

In this patch file we accomplish the following:

  1. Enable all the Virtual Services (enable:true)
  2. Enable traffic on all Virtual Services (traffic_enabled: true)
  3. Enabling log all headers and non-significant logs (For verification later in the lab)
  4. Enable X-Forwarded-For header insert for http and http-cmd Application Profiles
  5. Change the load balancing algorithm on hol-advanced-pool-10 to Consistent Hash/Hash Source IP Address and Port

 

Jump back to the AviTools Docker Container, and we will now patch the configuration and convert the patched Configuration to Ansible

  1. Open Docker Container for Avitools
  2. Move to the advanced_migration folder: cd advanced_migration
  3. Execute Patch command: config_patch.py -c hol_advanced_bigip-Output.json -p ../hol_advanced_patch.yml

 

Now that we have patched the advanced configuration file, we can now re-create the Ansible Playbooks

avi_config_to_ansible.py -c hol_advanced_bigip-Output.json.patched --controller_version 20.1.2

 

 

Push Advanced Migration Configuration to NSX ALB

Note: all playbooks will be run from the advanced_migration folder

As this is Advanced Migration, we also prepared some pre-requisite playbooks for some of the advanced VirtualServices that will be applied Pre and Post of the larger migration.  The Pre-Migration Ansible Playbook achieves the following:

  1. hol_tenant_creation.yml Creates hol tenant
  2. app_profile_http_xff_redirect-cmd.yml Creates application profile named http_xff_redirect, which has HTTP to HTTPs redirect enabled along with X-Forwarded-For(XFF) header inserted
  3. hol_x-forwarded-port-datascript.yml Creates x-forwarded-port datascript

 

To run the pre-migration import execute the following in AviTools Docker Container:

ansible-playbook ../pre_migration_import_playbooks/execute_prerequisite_playbooks.yml -e "controller=avicon-01a.corp.local username=admin password=VMware1!"

 

Pre Migration Playbook is done without errors, now onto the Larger Migration playbook

Run the following in AviTools Docker Container:

ansible-playbook avi_config.yml -e "controller=avicon-01a.corp.local username=admin password=VMware1!"

If no errors, you're in good shape!

 

And now for the Post-Migration Ansible Playbook achieves:

  1. map_redirect_application_profile.yml Updates the application profile to http-xff-redirect-cmdand adds port 80 as a service port on VSs 11-20
  2. hol_map_xfp_datascript.yml Mapsx-forwarded-portdatascript to VS's 51-60
  3. hol_pool_failure_response.yml Configures a Pool Failure response hol-advanced-pool-3

ansible-playbook ../post_migration_import_playbooks/execute_post_import_playbooks.yml -e "controller=avicon-01a.corp.local username=admin password=VMware1!"

Again, ensure no errors and we can go ahead and validate the configuration!

 

 

Migration Validation

 

When you log into the NSX ALB Controller in GoogleChrome and switch to the hol tenant, you should  now see a bunch of new objects that have been migrated over.

Going through each object in the UI can be quite a bit of work as you will need to click through each object.  If that's not to your liking, we have a Migration Report script we can leverage.

 

 

Migration Report Validation

A good way to look through all the migrated objects and validate that everything was applied correctly is leveraging another tool called migration_report.py

 

To run the tool again use AviTools container and execute:

migration_report.py -c avicon-01a.corp.local -u admin -p VMware1!

After execution you should see a migration_report with a timestamp

 

To open it: open VSCode, right click the file, select Download, and save it to Desktop

 

Go to your Desktop and now open the migration_report file you downloaded.

The file is divided into different TABs to separate each NSX ALB Object, and each column is a configuration item for the specific NSX ALB Object

We can leverage this Migration Report for validation of most of the Advanced steps defined along with the NSX ALB Controller:

Virtual Services Validate
VS 1-10  
  1. Verify Network Security Policy “denylist” is present and accurate. Ensure it points to IP Address Group “denylist_ips” and that the IP Address Group contains all applicable IP’s/networks. 
  2. Using one of the VS’s IP addresses, attempt to navigate to the website in a web browserThe site should not be reachable because the client IP address of 192.168.110.10 is present on the “denylist_ips” IP Address Group. You can disable the Network Security Policy and attempt to reach the website again to verify the functionality of the policy
  3. In a web browser navigate to https://172.16.10.21
VS 11-20
  1. Verify VS’s have Services ports 80 & 443 and have application profile “https-xff-redirect-cmd.” The “http-xff-redirect-cmd” application profile needs to have “X-Forwarded-For” header insertion is enabled and “HTTP-to-HTTPS Redirect” is enabled on the security tab 
  2. In a web browser, navigate to http://172.16.10.31 and notice it is redirected to https, receiving invalid certificate error 
VS 21-30
  1. Verify hol-advanced-pool-03”, which is mapped to VS’s 21-30, has a pool failure response configured. 
  2. Edit the pool, navigate to server tab and disable the servers, this will cause the VS’s to go down. Navigate to one of the IP addresses in a web browser and notice the pool failure response.  
VS 31-40
  1. Verify “http” application profile is configured on these VS’s and that it has “Connection Multiplex” enabled  
VS 41-50
  1. Verify “insert_true_client_ip” HTTP Request Policy is attached to VS’s and accurate 
  2. Selecting one of the VS IP addresses, navigate to it in a web browser. Once the webpage has been reached, navigate to the same VS’s logs, select logs, view all headers and notice the header “True-Client-IP” has been sent to the server 
VS 51-60
  1. Verify “x-forwarded-port” data script was created, attached to VS’s and accurate. 
  2. Open the CLI where you ran the migration tool and run the following command belowThis is curling the webpage and manually inserting the X-Forwarded-Proto header with a value of https even though the client is actually coming in on a http connection. Navigate to the VS logs, view all headers and see how the data script changed the manually inserted value of “https” to the actual connection protocol of “http” 
    a) curl --header 'X-Forwarded-Proto:https' http://172.16.10.71 -I 
  3. Now run the command below. This is curling the webpage and manually inserting the X-Forwarded-Port header with a value of 1234 even though the client is actually coming in on a different TCP port connection. Navigate to the VS logs, view all headers and see how the data script changed the manually inserted value of “1234” to the actual TCP port your connection came in on 
    a) curl --header 'X-Forwarded-Port:1234' http://172.16.10.71 -I 
VS 61-70
  1. Verify the attached application profile has been migrated to a L4 profile, instead of a L7 profile on the F5 configuration. This is a default behavior for the F5 migration tool when the profile is not defined in the same partition/unable to find defined profile.  
VS 71-80
  1. Verify path_match_respond_403” HTTP Security policy is attached to VS’s and accurate. Ensure it points to path_match_respond_403” string group and that the string group contains all of the applicable paths 
  2. In the controller CLI run the command below you should receive a 200 OK 
    a) Command: curl http://172.16.10.91 -I 
  3. Now run the command below. Notice that the command has a path that is present on the path_match_respond_403 string group. Notice the response. You can also verify this in the UI logs 
    a) Command: curl http://172.16.10.91/admin/ -I 
VS 81-90
  1. This set of VS’s is free for the student to test/configure as they please 
VS 91-100
  1. Verify that hol-advanced-pool-10 has Consistent Hash” load balancing algorithm and the hash is “Source IP Address and Port”  
Additional Changes to All VirtualServices
  1. Verify X-Forwarded-For on http and http-cmd application profiles. 
  2. Verify VS’s are up and traffic is being processed 

 

Module 7 Conclusion


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

Reference(s):


 

You have finished Module 7

Congratulations on completing Module 7.

You have completed the Introduction to NSX Advanced Load Balancer lab!

 

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-2137-01-NET

Version: 20201201-040840