This section illustrates examples of executing common management tasks with the NSX Advanced Load Balancer CLI.

CLI: Virtual Service and Pool Creation

During virtual service creation, a pool must be configured. This pool has to be created before creating the virtual service.

Create the following using the CLI:

  1. The Pool

  2. The VsVIP

  3. The Virtual Service

Note:

The examples below shows only the minimum configuration required to successfully deploy a new application. Many additional options are available for customizing virtual services and pools.

Create the Pool

: > configure pool Test
: pool> servers ip 10.1.1.100 port 80
: pool:servers> save
: pool> servers ip 10.1.1.101 port 80
: pool:servers> save
: pool> where
Tenant: admin
+------------+------------+
| Field      | Value      |
+------------+------------+
| name       | Test       |
| servers[1] |            |
| ip         | 10.1.1.100 |
| port       | 80         |
| servers[2] |            |
| ip         | 10.1.1.101 |
| port       | 80         |
+------------+------------+
: pool> save

Create the VsVIP

: > configure vsvip Test_vsVip
: vsvip> vip ip_address 10.10.10.10
: vsvip:vip> save
: vsvip> save

Create the Virtual Service

: > configure virtualservice Test_VS
: virtualservice> vsvip_ref Test_vsVip
: virtualservice> pool_ref Test
: virtualservice> services port 80
: virtualservice:services> save
: virtualservice> save

Modify Pool Servers

A common task is to add and remove servers from an existing pool or to activate or deactivate servers within the pool. While servers can be added to a pool without specifying a port (they will inherit the port of the pool or virtual service), the CLI requires the IP and port to manipulate the server for tasks such as enable and disable.

The following commands will delete the .101 server and add a new .102 server to the pool named Test.

configure pool Test
no servers ip 10.1.1.101 port 80
servers ip 10.1.1.102 port 80
[admin]: pool:servers save

The following commands will enter the sub-mode for the .100 server and disable it.

ip 10.1.1.100 port 80
where
Tenant: admin
+-------+------------+
| Field | Value      |
+-------+------------+
| ip    | 10.1.1.100 |
| port  | 80         |
+-------+------------+
no enabled
+---------+------------+
| Field   | Value      |
+---------+------------+
| ip      | 10.1.1.100 |
| port    | 80         |
| enabled | False      |
+---------+------------+
save

Export / Import Configuration

The NSX Advanced Load Balancer Controller has a database to store its configuration information. This includes all configurations related to tenants, virtual services, pools, policies, and accounts. Export this configuration as a JSON file for backup or to migrate parts of the config to another NSX Advanced Load Balancer Controller.

The configuration may be backed up or moved to another Controller cluster through the CLI. The exported configuration might be the entire system configuration, a more limited version based on the access rights of the current user and tenant of the administrator, or a single virtual service and its child properties.

To export only a single virtual service and its child objects, such as pools, use the virtualservice flag instead of the configuration flag with the export command.

The following commands will export the configuration to a file named config_export, SCP it to a remote location, and then return it to the NSX Advanced Load Balancer shell.

export configuration file config_export
Completed writing the export configuration to config_export
bash

pwd
/home/admin
ls
config_export
scp ./config_export [email protected]:/root
[email protected]'s password:
config_export 100% 232KB 431.8KB/s 00:00
exit

Before starting a configuration import:

  • Ensure that all Controller members of the cluster are up and the cluster leader has the following configuration:
    • Admin Account

    • Cluster Configuration

    • OpenStack Infrastructure (OpenStack only)

  • Edit the configuration file and remove the _last_modified field.

The following commands will import a backed-up configuration to a Controller cluster.

import configuration file /home/admin/myconfig keep_uuid
Successfully imported the configuration file

You can restore this configuration information to an empty NSX Advanced Load Balancer Controller. The restoration steps are:

  • Deploy three new Controller nodes; the image type (OVA, qcow2, ami) should match that of the original Controller node from which the configuration was exported.

  • Choose one Controller as the leader and go through the initial setup page to enter the initial setup information and the redundant Controller cluster information.

  • Use the CLI or API to import the configuration.

After these steps, the cluster will return to the same running state as the original one.

Export Configuration Filters

You can also tune the exported file by using filters. The following filters are supported:

Filter Name

Description

full_system

Exports the complete configuration (including persistent runtime) in the format documented in Restore Configuration. This configuration cannot be imported through the CLI or the REST API.

obj_type

Limits exported objects to a specific set of object types.

recurse

Exports the entire tree of dependencies (including some runtime) for objects in filtered config.

passphrase

Encrypts sensitive data. The same passphrase must be provided to import the configuration.

search

Only exports objects that contain a certain string.

skip_default

Prunes defaulted values of objects in exported configuration.

tenant_ref

Only exports objects in the specified tenant.

Examples

To export all virtual services and dependencies, use the following command:

export configuration file config\_export obj\_type virtualservice recurse

To export all objects in tenant t1 and filter out defaulted values, use the following command:

export configuration file config\_export tenant\_ref t1 skip\_default

Packet Capture

The NSX Advanced Load Balancer Controller provides a convenient mechanism to capture data plane traffic processed by SEs. An administrator can initiate a capture command from the Controller CLI while the actual capture occurs on the SEs. The packet capture is saved in pcap format on the Controller. The SE captures packets on both the client-side and server-side of the SE. If a virtual service is scaled across multiple SEs, then all applicable SEs will participate in the packet capture. The Controller will aggregate the captures and sort the entries according to time. Once a capture is complete, it is uploaded to a personal computer or other systems for analysis with an appropriate tool such as tcpdump or Wireshark.

Enter the packet capture sub-mode for the specified virtual service:

debug virtualservice Test-VS
Updating an existing object. Currently, the object is:
+-------+--------------------+
| Field | Value              |
+-------+--------------------+
| uuid  | virtualservice-0-1 |
| name  | Test-VS            |
+-------+--------------------+

Parameters may be defined for the packet capture. By default, the capture is performed within the context of the selected virtual service, and it is also performed on all SEs handling the virtual service traffic, including the packets from the client and server sides.

Parameter Name

Description

capture_params duration

Time, in minutes. Default is unlimited.

capture_params num_pkts

Maximum number of packets to collect. Default is unlimited.

capture_params pkt_size

Packet size, or snap length, to capture. Default is unlimited.

debug_ip addrs

IP4 Address format <x.x.x.x>

debug_ip prefixes

IP4 Prefix format <x.x.x.x/x>

The debug_ip command enters a sub-mode. This allows multiple IP addresses or IP subnets to be entered (omit the debug_ip for subsequent entries). Save to commit the desired IPs and return to the previous menu.
Note:

By default, no maximum packets, or duration of time to be captured are defined. It is recommended to include a maximum packet capture, as shown in the following example. Without a limit, the capture will run until the SE disk is filled, potentially disrupting the service.

Specify parameters, including the maximum number of packets to capture:

capture_params num_pkts 1000
debug_ip addrs 10.10.10.10
save

Begin capturing based on the previously configured parameters:

capture
save
+----------------+--------------------+
| Field          | Value              |
+----------------+--------------------+
| uuid           | virtualservice-0-1 |
| name           | Test-VS            |
| debug_ip       |                    |
| addrs[1]       | 10.10.10.10        |
| capture        | True               |
| capture_params |                    |
| duration       | 0 mins             |
| num_pkts       | 1000               |
+----------------+--------------------+

Re-enter the packet capture sub-mode and stop an ongoing packet capture:

debug virtualservice Test-VS
no capture
save

Export the packet capture to a remote system to view it using tools such as tcpdump or Wireshark:

show debug virtualservice Test-VS capture
Please specify the destination directory: /tmp
Downloaded the attachment to /tmp/vs_virtualservice.20141205_192033.pcap
bash
scp /tmp/vs_virtualservice.192033.pcap [email protected]:/tmp

Monitor Concurrent Connections to a Server

To track the number of concurrent connections to a server, the server must be viewed within the context of a pool. By prepending the watch command in front of the show, it is possible to see a near real-time updates of the connection count. Keep in mind there is some delay between the time the connection is established and the polling interval when the SE sends information back to the Controller. Cancel the watch with Ctrl+C.

watch show pool Test-pool server detail | grep -e 'ip\|open_conns'
| ip_addr    | 10.1.1.17 |
| open_conns | 50        |
| ip_addr    | 10.1.1.16 |
| open_conns | 49        |