Virtual Monitoring Point - VMware

The AppNeta v35 - VMware Enterprise Monitoring Point is software that can be downloaded and run as a virtual machine on a VMware hypervisor. It is used for monitoring in small office environments. A full list of features can be found on the Monitoring Point Feature Comparison page.

Specifications

Port descriptions

The following table shows how each port on the v35 - VMware is used.

Port # Preconfigured? Port type Used for
eth0 Yes Primary network connection port Connectivity to APM
Delivery monitoring
Experience monitoring
eth1 Yes Primary Usage monitoring port
(Out-of-band)
Usage monitoring

1Gbps NICs are supported.

Guest requirements

Any virtual machine that comes up without the following minimum requirements will show up in APM as a v25, which is an unsupported Monitoring Point type that cannot be licensed.

Guest requirements v35 VMware
CPU 2 cores
RAM 4 GB
Storage 16 GB
Network interfaces 1 vmxnet3 interface
Host kernel drivers vmxnet3

Monitoring is supported up to 1Gbps.

Setup

Monitoring Point setup

The AppNeta v35 is a virtual Monitoring Point that runs as a virtual machine on a host system. This version of the v35 runs on a host system running the VMware ESXi hypervisor.

Prerequisites

The following are the minimum requirements for an ESXi host:

  • The ESXi host must be running vSphere 5.5.0 or later.
  • The ESXi host must be capable of hosting a guest with the v35 requirements.
  • The ESXi host should have two physical NICs.
    • The first is for connectivity to APM and for Delivery and Experience monitoring.
    • The second is for Usage monitoring.
  • The ESXi host must be connected to your network via the first NIC.

In addition, you’ll need to do the following:

Create a v35 virtual machine

You can install the v35 onto a host running ESXi using vCenter or without it.

Set up a v35 using vCenter

If you are using vCenter to manage your VMware resources, you can use it to create a v35. There are a few steps required.

Download v35 template (vCenter) and generate a configuration file

To download the v35 template and generate a configuration file:

  1. Log in to APM.
  2. Select the organization you want the Monitoring Point to be part of.
  3. Navigate to > Manage Monitoring Points > Add Monitoring Points > VMware.
  4. Click Download VMware Base Image (vCenter).
    • A .ova image file is downloaded to your computer. This may take a while as the file is large.
  5. Click Continue.
  6. Follow the instructions provided to create a configuration .zip file.
    • Stop once you click Generate.
    • The .zip file is downloaded to your computer.
  7. Unzip the .zip file.
Create the v35 using the template and configuration file

To create the v35 using the template and configuration file:

  1. In a separate tab on your browser, log in to vCenter.
  2. In the inventory list, select the host on which you want to deploy the v35.
  3. Click Actions > Deploy OVF Template.
  4. Select Local file and click Browse.
  5. Browse for the .ova image file you downloaded, select the file and click Open.
  6. Click Next.
  7. Enter a name for the VM and select the deployment location.
  8. Click Next.
  9. Follow the instructions to create a virtual machine until you reach the Customize Template page.
  10. Copy the contents of the .json file you downloaded and paste them into the AppNeta Monitoring Point Configuration field.
  11. Click Next.
  12. Click Finish.
    • Wait for the v35 deployment to complete.
Power on the v35

To power on the v35:

  1. Within vCenter, select the v35 from the inventory in the Navigator panel.
  2. Click the “Power On” button.
  3. Click the “Open Console” button and wait for the login prompt.
    • The v35 is powered on.
  4. Continue at Configure for web proxy if required.
Set up a v35 without using vCenter

If you are not using vCenter to manage your VMware resources, you can create a v35 directly on ESXi using the vSphere Client. There are a few steps required.

Download v35 template (non-vCenter) and generate a configuration file

To download the v35 template and generate a configuration file:

  1. Log in to APM.
  2. Make sure you are using the correct organization
  3. Navigate to > Manage Monitoring Points > Add Monitoring Points > VMware.
  4. Click Download VMware Base Image (ESXi).
    • A .ova image file is downloaded to your computer. This may take a while as the file is large.
  5. Click Continue.
  6. Follow the instructions provided to create a configuration .zip file.
    • Stop once you click Generate.
    • The .zip file is downloaded to your computer.
  7. Unzip the .zip file.
Create a v35 using the template

To create a v35 using the template:

  1. Use the vSphere Client to login to the ESXi host.
  2. Click File > Deploy OVF Template.
  3. Click Browse.
  4. Browse for the .ova image file you downloaded, select the file and click Open.
  5. Click Next.
  6. Click Next.
  7. Enter a name for the VM and select the deployment location.
  8. Click Next.
  9. Follow the instructions to complete the VM deployment as you would other VMs.
  10. Click Finish.
    • Wait for the v35 deployment to complete.
Power on the v35 and apply the configuration

To power on the v35 and apply the configuration:

  1. Select the v35 from the inventory list.
  2. Click the “Power On” button.
  3. Click the “Launch Virtual Machine Console” button and wait for the login prompt.
  4. Log in as admin using the default v35 password.
  5. At the command prompt, enter sudo ifconfig eth0. Note the IP address.
  6. In a new browser tab, enter “https://<IP address>” to access the Monitoring Point Web Admin interface.
  7. Log in as admin using the default v35 password.
  8. Navigate to > API to load the Monitoring Point Admin API interface.
  9. Navigate to Batch > POST /batch/.
  10. Click Try it out.
  11. For the appliance_config_file parameter, click Choose File.
  12. Select the .json file you downloaded and click Open.
  13. Click Execute.
  14. Sign in as admin using the default v35 password.
    • Confirm that the response code is 200 and that there are no errors.
  15. In the Monitoring Point Web Admin interface tab in your browser, click > Restart Monitoring Point.
    • Wait for the Monitoring Point to restart (wait for the login prompt in the Virtual Machine Console).
    • To access the Monitoring Point, log in as admin using the password you specified when creating the configuration.

Configure for web proxy if required

If internet traffic on your network is forwarded by a web proxy, you must configure the Monitoring Point with the proxy details.

Assign a base license

Every v35 - VMware is sold with a base license that must be assigned to it in APM before it can be used.

  1. Within APM, navigate to > Manage Monitoring Points.
  2. Wait for the new v35 - VMware to show up in the list (you may need to refresh your screen).
    • The v35 - VMware’s status should show “Connection Established” (Green circle with white check mark).
    • If it doesn’t appear after a few minutes, you’ll need to troubleshoot the problem.
  3. To assign it a base license, navigate to > Manage Licenses.
  4. In the Parent Organization drop-down (if visible), select the parent organization containing the v35 - VMware.
  5. In the Organization drop-down, select the child organization containing the v35 - VMware.
  6. Click the APM Monitoring Points tab in the bottom table.
  7. For the v35 - VMware you want to add the license to, select > Assign Licenses.
  8. In the Base License section, select a base license.
  9. Click Submit. The v35 - VMware is ready to use.

Optional - Assign add-on licenses

In addition to a base license, you can add Standard Enterprise Application licenses, voice licenses, and video licenses to the v35 - VMware. Before they can be assigned, you need to purchase them. Once purchased, they will be added to your organization and available for assignment.

To assign an add-on license to the v35 - VMware:

  1. Navigate to > Manage Licenses.
  2. In the Parent Organization drop-down, select the parent organization containing the v35 - VMware.
  3. In the Organization drop-down, select the child organization containing the v35 - VMware.
  4. Click the APM Monitoring Points tab in the bottom table.
  5. For the v35 - VMware you want to add the license to, select > Assign Licenses.
  6. In the Add-on Licenses section, specify the types and quantities of licenses you want to add.
  7. Click Submit.
    • The new capabilities are ready to use.

Set the location

When adding a new v35 - VMware to APM, you need to specify its location. This setting provides essential geographical context for the data that the v35 - VMware collects. Typically, you specify its location during the setup procedure.

If you are outside the setup procedure, you’ll need to edit its location:

  1. Navigate to > Manage Monitoring Points
  2. For the v35 - VMware you want to edit, select > Edit Location.
  3. Specify the location of the v35 - VMware.
  4. Click OK.
    • The location is set.

Configure VMware for Usage monitoring

If you plan to use Usage monitoring, you need to associate the pre-configured Usage monitoring interface on the v35 (eth1) with the appropriately configured physical NIC on the ESXi host. The instructions below provide high level guidance. Consult the VMware documentation for detailed instructions.

  1. Configure an upstream physical switch to mirror the traffic you want to monitor to one of its ports.
  2. Using an Ethernet cable, connect this physical switch port to the physical NIC on the ESXi host to be used for Usage monitoring (Network Adapter 2).
  3. Within VMware, create a standard virtual switch and assign it the physical NIC to be used for Usage monitoring.
  4. On this virtual switch, create a portgroup dedicated to Usage monitoring.
  5. On the portgroup, configure promiscuous mode so that interfaces defined within it can detect all traffic passed on the switch and allowed under the VLAN policy for the portgroup.
  6. Configure the portgroup to limit traffic to the desired VLANs or set it to “ALL (4095)” to enable all VLANs.
  7. Assign eth1 to the portgroup by editing the hardware settings of your v35:
    1. Assign the port group to Network Adapter 2.
    2. Make sure the Connected option is enabled.

Change default password

For security reasons, you should change the v35 - VMware password from its default.

Set up monitoring

At this point the v35 - VMware setup is complete. Continue the APM setup procedure at Set up performance monitoring.

Troubleshooting connectivity to AppNeta

Your v35 - VMware is properly connected to AppNeta Performance Manager (APM) when the status icon in > Manage Monitoring Points shows Green circle with white check mark.

If this is not the case, use the troubleshooting procedure below to help determine why it is not connecting.

Requirements Things to check
The v35 - VMware must be running. Check that the virtual machine is running.
The v35 - VMware must be connected to the network (by default, use the Primary network connection port (eth0)) Check that LEDs on the port used by the v35 - VMware are on or blinking.
  Check that the cable is plugged into the correct port.
  Check that the cable is connected to an L2 switch on the network.
The v35 - VMware must be configured to access APM and its system time must be correct. Log in to Web Admin and verify that the following are as expected:
- General > Monitoring Point Connected - should be “Yes”.
- System Status > System Time - time and time zone must be correct.
- System Status > NTP Synchronized - should be “Yes”.
- Network State > eth0 - Status should be “Up” and IP Address and prefix should be as expected.
If a proxy is being used, the v35 - VMware must be configured to connect through it. Check the proxy configuration on the v35 - VMware (via Web Admin).
  Verify that the proxy is reachable from the network the v35 - VMware is on.
  Verify that the APM servers have been allowed in any access controls which may exist on the proxy.
Your firewall must be configured to allow the v35 - VMware to connect to APM. Check the firewall configuration.

If you are still unable to resolve the issue, contact AppNeta Support.

Access

View Monitoring Point status

To view a Monitoring Point’s status in APM:

  • Within APM, navigate to > Manage Monitoring Points.
    • The Monitoring Point status is indicated by the icon in the left column.
Icon Status Description
Green circle with white check mark OK The Monitoring Point is connected to APM.
Black circle with white minus sign Connection Lost The Monitoring Point is not connected to APM. Troubleshoot the issue.

Additional statuses can be found in the Additional Status columns. Hover over the icons for details and/or actions to take.

Icon Status Description
Shared The Monitoring Point is shared between organizations.
Unlicensed The Monitoring Point is unlicensed.
Monitoring Point Error There is a Monitoring Point error.
Upgrade Available There is a software upgrade available for the Monitoring Point.

Determine the Monitoring Point hostname or IP address

Once the v35 - VMware has connected to APM, you can view its hostname and IP address.

  1. Log in to APM.
  2. Make sure you are using the correct organization
  3. Navigate to > Manage Monitoring Points.
  4. Click the v35 - VMware you want to connect to. In the right pane:
    • the Host Name field contains the hostname.
    • the Public IP field contains the public IP address. Use this if you are connecting to the v35 - VMware across the internet.
    • the Host Networking Details section contains the active v35 - VMware interfaces and the local IP address of each. Use this if you are connecting to the v35 - VMware locally.

Access credentials

The v35 - VMware is shipped with a set of default credentials: a single username and password. The username cannot be changed but you can change the password. If you change the password and then forget it, there is a procedure to reset it.

Default credentials

You need v35 - VMware credentials to log into Web Admin or use the Admin API.

The default credentials for the v35 - VMware are:

  • Default username: admin
  • Default password: appneta.admin

Changing Monitoring Point password

To secure Web Admin and Admin API access your v35 - VMware, it is recommended that you change the password from its default.

Valid passwords require the following:

  • A minimum of 8 characters
  • At least one of each of the following:
    • A lower case character (a through z)
    • An upper case character (A through Z)
    • A number (0 through 9)
    • A special character (!“#$%&‘()*+,-./:;<=>?@[]^_`{|}~)

To change the password:

  1. Log in to Web Admin.
  2. Click Monitoring Point Settings.
  3. Click Password.
  4. Make your changes and click Submit.

Resetting Monitoring Point password

If you forget your v35 - VMware password you can reset it.

  1. Create a new v35 - VMware with a new password.
  2. Migrate monitoring from the old v35 - VMware to the new v35 - VMware.

Access via Web Admin

There are a few different methods to log into the Web Admin interface depending on its state.

The Monitoring Point is currently connected to APM

Log in via APM.

  1. Log in to APM.
  2. Make sure you are using the correct organization
  3. Navigate to > Manage Monitoring Points.
  4. Click the Monitoring Point you want to connect to.
  5. Click Launch Monitoring Point Web Admin… in the right side panel.
  6. Log in.
    • Use credentials for the v35 - VMware.
    • If you are unable to login, see Can’t log in.

The Monitoring Point has been connected to APM in the past but is not connected now

Log in directly (hostname or IP address from APM).

  1. Determine the v35 - VMware hostname or IP address from APM.

  2. Enter the IP address or hostname in the address bar of your web browser - https://<hostname-or-ip>.

  3. Log in.

    • Use credentials for the v35 - VMware.
    • If you are unable to login, see Can’t log in.

The Monitoring Point has never been connected to APM

Log in directly using the Monitoring Point hostname or IP address.

  1. Recall the hostname you supplied during setup. Alternatively, you’ll need the static IP address or DHCP-assigned IP address for the Monitoring Point.
  2. Enter the hostname or IP address in the address bar of your web browser - https://<hostname-or-ip>.
  3. Log in.
    • Use credentials for the v35 - VMware.
    • If you are unable to login, see Can’t log in.

Can’t log in?

  1. Try using the default v35 - VMware credential.
  2. Make sure the device status is OK Green circle with white check mark.
  3. Make sure the device is upgraded to the latest software.

  4. Make sure you’re using https://.

  5. If using a hostname, try again using its IP.
  6. If using a public IP, verify that port forwarding is enabled on the device performing NAT.
  7. Make sure you created a firewall rule for our capture server.
  8. Power the v35 - VMware off then on.
  9. If you are still unable to login, open a support ticket.

Access via Admin API

The v35 - VMware has a web hosted API for performing device management tasks. You can access the Admin API in two different ways: via Web Admin or by specifying the hostname or IP address directly.

Note that some API endpoints have limits to how often they can be called.

Access the Admin API from Web Admin

  1. Log in to Web Admin.
  2. Click > API.
    • The Monitoring Point Admin API appears.

Access the Admin API directly (hostname or IP address from APM)

  1. Log in to APM.
  2. Navigate to > Manage Monitoring Points.
  3. Click the Monitoring Point you want to connect to.
    • The Name field contains the hostname.
    • The Local Network Interface field in the right pane contains the IP address. Use the Public IP if you are connecting across the internet.
  4. Substituting the IP address or hostname, enter https://<hostname-or-ip>/swagger/index.html in the address bar of your web browser.
    • The Monitoring Point Admin API appears.

Rate limit

There are a number of Monitoring Point API endpoints that have restrictions on the number of requests they will process over a given time period.

Endpoint Rate limits
PUT /service/<service_name>/ 12/min and 1/sec
PUT /service//settings/ 12/min and 1/sec
POST /access_control/ldap/ 12/min and 1/sec
DELETE /access_control/ldap/ 12/min and 1/sec
POST /acccess_control/ldap/ 12/min and 1/sec
PUT /ntp/ 12/min and 2/sec
DELETE /ntp/ 12/min and 2/sec
POST /web/ssl/ 12/min and 2/sec
DELETE /web/ssl 12/min and 2/sec

Access via curl

The v35 - VMware has a web hosted API for performing device management tasks. You can interact with the API via the interactive Admin API interface, programmatically, or via a command line tool like curl.

Creating the curl command line from the Admin API

  1. Access the Admin API.
  2. Navigate to the endpoint you want to use.
  3. Fill in the appropriate fields.
  4. Click Submit. The Curl section displays the equivalent curl command line.
  5. Copy the curl command line and paste it to a terminal command line (e.g. Terminal app on macOS).
  6. Add Monitoring Point login credentials ( -k -u <MP-username>:<MP-password>) to the command line.
    • <username> - a username recognized by the v35 - VMware.
    • <password> - the password associated with the username.
  7. Generate an AIM-TOKEN using the following Python script (requires Python 3.6 or later and the “requests” package).

    import requests
    server_url = "<APM-server-url>"        # APM server url, for example https://app-01.pm.appneta.com/
    username = "<APM-username>"
    password = "<APM-password>"
    
    api_function = f"pvc/j_spring_security_check?j_username={username}&j_password={password}"
    r = requests.get(f"{server_url}{api_function}")
    print(r.cookies._cookies['.appneta.com']['/']['AIM-TOKEN'].value)
    
  8. Add the AIM-TOKEN (--cookie "AIM-TOKEN=<AIM-TOKEN>") to the command line for authentication.
    • Note: An AIM-TOKEN can be used more than once if is used within 15 minutes of the previous call using the same token. Once expired, a new AIM-TOKEN must be generated.
  9. Optionally, to format the output, add | python -m json.tool to the command line.
  10. Run the command. The output is the same as that returned using the Admin API interface.

Configure

Methods

AppNeta Performance Manager offers several tools to manage and configure the v35 - VMware:

Configuration method Description
APM Some management and configuration capabilities are accessed from within APM via > Manage Monitoring Points. For example, changing Monitoring Point location or renaming the Monitoring Point.
Web Admin This is a web interface hosted on the v35 - VMware. Use it to manage and configure the v35 - VMware. For example, restart networking, add static IPs, and VLAN tags.
Admin API This is a web-based API interface hosted on the v35 - VMware. Use it to manage and configure the v35 - VMware.
curl The Admin API interface can generate custom curl commands that can be used to manage and configure the v35 - VMware from a command line.

Basic settings

There are a few settings that should be configured on the v35 - VMware including Time zone, Location, and Name.

Time zone

There are two time zones that must be configured - your local time zone and the Monitoring Point time zone.

The Monitoring Point time zone is specified when the v35 - VMware is initially configured and it can be seen in APM by navigating to > Manage Monitoring Points.

Having the correct time zone on the v35 - VMware is important for a number of reasons:

  • In conjunction with the v35 - VMware’s system time, it is required in order for the v35 - VMware to connect to APM. If the time is not correct, then there could be an issue with certificate validity checks when connecting.
  • It is required for monitoring results to be timestamped correctly.
  • It is required in order to display the correct time in path performance charts when Source Monitoring Point Time Zone is set.
  • It is required for alert conditions to be applied at the right time according to alert time ranges you have set.
Set time zone using Web Admin
  1. Log in to Web Admin
  2. Navigate to Monitoring Point Settings >Timezone.
  3. In the Timezone field, select the time zone the v35 - VMware is located in.
  4. Click Submit.
    • The v35 - VMware’s time zone is set accordingly.
Set time zone using Admin API
  1. Access the Admin API.
  2. Navigate to Timezone > PUT /timezone/.
  3. Click Try it out.
  4. In the Parameters section, in the body field, set string to a string for the time zone. For example, “Canada/Pacific”.
    • Use GET /timezone/capability/ for a list of valid time zone strings.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The v35 - VMware’s time zone is set accordingly.

Location

The location specified for the v35 - VMware is necessary for a variety of reports and charts.

The v35 - VMware’s location is specified during the setup procedure but it can be edited at any time.

  1. Navigate to > Manage Monitoring Points
  2. For the Monitoring Point you want to edit, select > Edit Location.
  3. Specify the location of your Monitoring Point.
  4. Click OK.
    • The Monitoring Point’s location is set.

APM name and hostname

All Enterprise Monitoring Points (EMP) have two names: a hostname and an APM name. The hostname is used to identify the Monitoring Point on the network. The APM name is used to identify the Monitoring Point within APM. By default, both of these names are the same and are generated by APM. They are of the form: <device type>-<unique string>.

If you manually change the APM name, the hostname is not affected. If you change the hostname, the APM name is changed automatically unless the APM name was changed manually. In this case, changing the hostname does not affect the APM name.

Rename a Monitoring Point

To change the v35 - VMware’s APM name:

  1. Navigate to > Manage Monitoring Points.
  2. For the v35 - VMware you want to rename, navigate to > Rename.
  3. Either select the default or specify a new name.
  4. Click Confirm.
    • The v35 - VMware’s APM name is changed.
Change the hostname

When you change the v35 - VMware’s hostname, the APM name is changed automatically unless the APM name was changed manually. In this case, changing the hostname does not affect the APM name.

To change the v35 - VMware’s hostname:

Change the hostname using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Monitoring Point Settings > Hostname.
  3. In the Hostname field, add the new hostname.
  4. Click Submit.
  5. Click > Restart Monitoring Point.
  6. Click Confirm.
    • The hostname and the APM name are changed.
Change the hostname using Admin API
  1. Access the Admin API.
  2. Navigate to Hostname > PUT /hostname/.
  3. Click Try it out.
  4. In the Parameters section, in the body field, change “string” to the new hostname.
  5. Click Execute.
    • The Server response section should show Code “200”.
  6. Restart the v35 - VMware.
    • The hostname and the APM name are changed.

Restricting Access

Access to the v35 - VMware can be restricted using Access Control Lists (ACLs) or LDAP. 802.1X can be used to authenticate the v35 - VMware in order to access a LAN or WAN secured by 802.1X.

Access Control Lists (ACLs)

By default, all inbound access to a v35 - VMware is denied, with a few exceptions. These exceptions are in the form of Access Control Lists (ACLs). ACLs permit access to the v35 - VMware on a specified protocol and port (or port range), from an optional list of source IPv4/IPv6 addresses/networks, on an optional list of interfaces. They should be used in conjunction with firewall rules that provide access between the v35 - VMware and APM. Typically, ACLs are used to restrict inbound access to specific internal source addresses and/or subnets on specific interfaces. ACL rules can be viewed, created, added to, deleted from, and removed altogether using the Admin API. You can also remove all non-default ACL rules. Examples of various scenarios are provided below.

Default ACLs

Default ACLs are provided to permit access on the following ports from any source address.

  • TCP port 22 (SSH)
  • TCP port 80 (HTTP)
  • TCP port 443 (HTTPS)
  • TCP ports 1025-8080 (PathTest)
  • TCP ports 8082-65535 (PathTest)
  • UDP port 7 (Traceroute)
  • UDP port 123 (NTP)
  • UDP port 161 (SNMP)
  • UDP ports 1025-65535 (Delivery, including PathTest, voice, and video)
View ACLs
  1. Access the Admin API.
  2. Navigate to Access Control > GET /access_control/acl/.
  3. Click Try it out.
  4. Click Execute.
    • The Server response section should show Code “200” as well as the ACLs.
Add an ACL rule
  1. Access the Admin API.
  2. Navigate to Access Control > PUT /access_control/acl/.
  3. Click Try it out.
  4. In the Parameters section, in the body field:
    1. Set “action”: “permit”.
    2. Set “protocol”: to either “tcp” or “udp”.
    3. Set “from_port”: and “to_port”: to the beginning and end of the port range (from_port <= to_port). To specify a single port, set to_port and from_port to the same port number.
    4. For “source_addresses”:, provide an optional list of one or more source addresses to restrict inbound traffic to. An address can be a single IPv4 or IPv6 address, or an IPv4 or IPv6 network (with /mask) such as 192.0.2.0/24 or 2001:db8::1000/124. The list can contain any mix of address types. An empty list indicates all source addresses are permitted for the protocol and port range specified.
    5. For “interfaces”:, provide an optional list of one or more interfaces to restrict inbound traffic to. Any of the source_addresses specified are permitted on any of the interfaces specified.
    6. For “interfaces_and_source_addresses”:, provide an optional list of one or more interfaces and associated source addresses to restrict inbound traffic to. Only the source addresses associated with a given interface are permitted on that interface.
  5. Click Execute.
  6. Restart networking.
    • The ACL you created takes effect.

For example, to restrict incoming traffic on TCP port 22 (ssh) to subnets 192.0.2.0/24 and 198.51.100.0/24 on any interface, use the following:

  {
    "network_acl": [
      {
        "action": "permit",
        "protocol": "tcp",
        "from_port": 22,
        "to_port": 22,
        "source_addresses": [
          "192.0.2.0/24",
          "198.51.100.0/24"
        ]
      }
    ]
  }
Edit ACL rule content
  1. Access the Admin API.
  2. Navigate to Access Control > PUT /access_control/acl/.
  3. Click Try it out.
  4. In the Parameters section, in the body field:
    1. Set “action”: “permit”.
    2. Set “protocol”: to match the rule you want to add to.
    3. Set “from_port”: and “to_port”: to match the rule you want to add to.
    4. For “source_addresses”:, “interfaces”: and/or “interfaces_and_source_addresses”:, specify the content you want to add to the rule.
  5. Click Execute.
  6. Restart networking.
    • The ACL you updated takes effect.

For example, to add source address “198.51.99.99” to a rule for TCP port 22 (ssh), use the following:

  {
    "network_acl": [
      {
        "action": "permit",
        "protocol": "tcp",
        "from_port": 22,
        "to_port": 22,
        "source_addresses": [
          "198.51.99.99"
        ]
      }
    ]
  }
Delete ACL rule content
  1. Access the Admin API.
  2. Navigate to Access Control > PUT /access_control/acl/.
  3. Click Try it out.
  4. In the Parameters section, in the body field:
    1. Set “action”: “deny”.
    2. Set “protocol”: to match the rule you want to delete from.
    3. Set “from_port”: and “to_port”: to match the rule you want to delete from.
    4. For “source_addresses”:, “interfaces”: and/or “interfaces_and_source_addresses”:, specify the content you want to remove from the rule.
  5. Click Execute.
  6. Restart networking.
    • The ACL you updated takes effect.

For example, to remove source address “198.51.99.99” from a rule for TCP port 22 (ssh), use the following:

  {
    "network_acl": [
      {
        "action": "deny",
        "protocol": "tcp",
        "from_port": 22,
        "to_port": 22,
        "source_addresses": [
          "198.51.99.99"
        ]
      }
    ]
  }
Delete an ACL rule
  1. Access the Admin API.
  2. Navigate to Access Control > PUT /access_control/acl/.
  3. Click Try it out.
  4. In the Parameters section, in the body field:
    1. Set “action”: “deny”.
    2. Set protocol, from_port, and to_port to match the ACL rule you want to delete.
  5. Click Execute.
    • The Server response section should show Code “200”.
  6. Restart networking.
    • The ACL change takes effect.
Reset to default ACL rules
  1. Access the Admin API.
  2. Navigate to Access Control > DELETE /access_control/acl/.
  3. Click Try it out.
  4. Click Execute.
    • The Server response section should show Code “200”.
    • All but the default ACL rules are deleted.
  5. Restart networking.
ACL examples

The following are examples showing the content required to create, edit, and remove ACL rules for various scenarios.

Create an ACL rule

To create an ACL rule that restricts incoming traffic on TCP port 22 (ssh) to subnet 192.0.2.0/24 on any interface, use the following:

  {
    "network_acl": [
      {
        "action": "permit",
        "protocol": "tcp",
        "from_port": 22,
        "to_port": 22,
        "source_addresses": [
          "192.0.2.0/24"
        ]
      }
    ]
  }

The new rule looks as follows:

  {
    "protocol": "tcp",
    "from_port": 22,
    "to_port": 22,
    "source_addresses": [
      "192.0.2.0/24"
    ]
  }
Permit access on multiple source addresses

To add source addresses (subnet 198.51.100.0/24) to the previous example, use the following:

  {
    "network_acl": [
      {
        "action": "permit",
        "protocol": "tcp",
        "from_port": 22,
        "to_port": 22,
        "source_addresses": [
          "198.51.100.0/24"
        ]
      }
    ]
  }

The updated rule looks as follows:

  {
    "protocol": "tcp",
    "from_port": 22,
    "to_port": 22,
    "source_addresses": [
      "192.0.2.0/24",
      "198.51.100.0/24"
    ]
  }
Permit access on an interface

To restrict inbound access to a single interface (eth0) by adding an interface to the previous example, use the following:

  {
    "network_acl": [
      {
        "action": "permit",
        "protocol": "tcp",
        "from_port": 22,
        "to_port": 22,
        "interfaces": "eth0"
      }
    ]
  }

The updated rule looks as follows:

  {
    "protocol": "tcp",
    "from_port": 22,
    "to_port": 22,
    "source_addresses": [
      "192.0.2.0/24",
      "198.51.100.0/24"
    ],
    "interfaces": "eth0"
  }
Permit access on source addresses and interfaces

To create an ACL rule that restricts incoming traffic on TCP port 22 (ssh) to subnet 192.0.2.0/24 or subnet 198.51.100.0/24 on either eth0 or eth1, use the following:

  {
    "network_acl": [
      {
        "action": "permit",
        "protocol": "tcp",
        "from_port": 22,
        "to_port": 22,
        "source_addresses": [
          "192.0.2.0/24",
          "198.51.100.0/24"
        ],
        "interfaces": "eth0",
        "interfaces": "eth1"
      }
    ]
  }

The new rule looks as follows:

  {
    "protocol": "tcp",
    "from_port": 22,
    "to_port": 22,
    "source_addresses": [
      "192.0.2.0/24",
      "198.51.100.0/24"
    ],
    "interfaces": "eth0",
    "interfaces": "eth1"
  }
Permit access to source addresses on specific interfaces

To create an ACL rule that restricts incoming traffic on TCP port 22 (ssh) to subnet 192.0.2.0/24 on eth0 and subnet 198.51.100.0/24 and address 198.51.99.99 on eth1, use the following:

  {
    "network_acl": [
      {
        "action": "permit",
        "protocol": "tcp",
        "from_port": 22,
        "to_port": 22,
        "interface_and_source_addresses": [
          {
            "interface": "eth0",
            "source_addresses": [
              "192.0.2.0/24"
            ]
          },
          {
            "interface": "eth1",
            "source_addresses": [
              "198.51.100.0/24",
              "198.51.99.99"
            ]
          }
        ]
      }
    ]
  }

The new rule looks as follows:

  {
    "protocol": "tcp",
    "from_port": 22,
    "to_port": 22,
    "interface_and_source_addresses": [
      {
        "interface": "eth0",
        "source_addresses": [
          "192.0.2.0/24"
        ]
      },
      {
        "interface": "eth1",
        "source_addresses": [
          "198.51.100.0/24",
          "198.51.99.99"
        ]
      }
    ]
  }
Remove a source address from an existing rule

To remove a source address (subnet 198.51.99.99) from the previous example, use the following (Note that the action is deny):

  {
    "network_acl": [
      {
        "action": "deny",
        "protocol": "tcp",
        "from_port": 22,
        "to_port": 22,
        "interface_and_source_addresses": [
          {
            "interface": "eth1",
            "source_addresses": [
              "198.51.99.99"
            ]
          }
        ]
      }
    ]
  }

The updated rule looks as follows:

  {
    "protocol": "tcp",
    "from_port": 22,
    "to_port": 22,
    "interface_and_source_addresses": [
      {
        "interface": "eth0",
        "source_addresses": [
          "192.0.2.0/24"
        ]
      },
      {
        "interface": "eth1",
        "source_addresses": [
          "198.51.100.0/24"
        ]
      }
    ]
  }
Remove all interfaces from an existing rule

To remove all interfaces_and_source_addresses content from the previous example (i.e. permit all interfaces and sources), use the following (Note that the action is permit):

  {
    "network_acl": [
      {
        "action": "permit",
        "protocol": "tcp",
        "from_port": 22,
        "to_port": 22,
        "interface_and_source_addresses": []
      }
    ]
  }

The updated rule looks as follows:

  {
    "protocol": "tcp",
    "from_port": 22,
    "to_port": 22
  }
Remove a rule

To remove the rule in the previous example, use the following (Note that the action is deny):

  {
    "network_acl": [
      {
        "action": "deny",
        "protocol": "tcp",
        "from_port": 22,
        "to_port": 22
      }
    ]
  }

LDAP

The Lightweight Directory Access Protocol (LDAP) is an industry standard application protocol for accessing and maintaining directory services information. It allows administrative users to log in to Web Admin or the Admin API using their own credentials rather than the administrator credentials configured on the v35 - VMware. The benefits include:

  • More convenient for administrators - Administrators login the v35 - VMware using their own desktop credentials. No new credentials to remember.
  • More secure - Administrators never need to be given local admin credentials to the v35 - VMware. No sharing of credentials.
  • Easy to control access - The network administrator can centrally control who can login to the v35 - VMware simply by adding them to (or removing them from) an authorization group.
  • Centralized password policy - Password policy (eg: password strength, rollover, lockout) for v35 - VMware access remains under the control of the network administrator and follows central corporate policy.
  • Better security forensics - The audit trail for v35 - VMware activity can be traced back to individuals through their central authentication identity.
Key concepts

Key concepts include:

  • Network administrator - Has access to the directory server and controls authentication. Applies LDAP configuration to the v35 - VMware (using local v35 - VMware admin credentials). Retains control over local admin credentials for the v35 - VMware.
  • Monitoring Point administrator - Logs into the v35 - VMware (using their own desktop credentials) and assumes administrator privileges to perform v35 - VMware administration.
  • Authorization group - Created by the network administrator. Only members of this group can log in to the v35 - VMware to perform administration tasks.
  • LDAP configuration - Settings supplied by the network administrator that tell the v35 - VMware to authenticate via LDAP, and where to find the server and authorization group.
How it works

For the v35 - VMware to make use of LDAP you need an LDAPv3 compliant server (directory server) that is accessible by the v35 - VMware and an authorization group on the server containing v35 - VMware administrators. The v35 - VMware must then be configured to access the LDAP server and search the correct group for user credentials when a login attempt is made.

Once the v35 - VMware is configured, administrators can log in to it using their credentials as stored on the LDAP server. When they attempt to log in, the v35 - VMware makes a request to the LDAP server to authenticate the user. If the username is found and the password matches, the login attempt is successful.

The following diagram shows this workflow:

Diagram showing LDAP workflow.

Prerequisites for LDAP configuration

Assuming that your LDAP server is already set up, you’ll need to have a few things in place when configuring the v35 - VMware to access it:

  • Server URI - You need to know the address of the server and, if it is not using the default LDAP port, the port it is using.
  • Server type - Active Directory and Oracle DSEE use different schemas and will affect the LDAP queries required.
  • Authorization group - The DN of the authorization group containing the admin users who should be granted administrative access to the v35 - VMware.
  • Bind name/password - If required by the server, you’ll need the credentials required to bind to the LDAP server (note that these are read-only directory access credentials, not the authenticating user credentials).
  • Search base - You need to supply the base DN from which LDAP searches will be executed.
  • Encryption type - You need to know what type of encryption the LDAP server is using.
  • Certificate requirement - You need to know what your policy is for authenticating responses from the LDAP server. If a CA certificate is required, you’ll need to upload it to the v35 - VMware.

Note: LDAP setup on the v35 - VMware should be completed by a system administrator with good knowledge of LDAP system administration. Those without this expertise should contact AppNeta Support for help.

At this time, LDAP is configured on the v35 - VMware using the Admin API.

LDAP configuration steps

Configuring the v35 - VMware for LDAP and confirming that it is working requires only a few steps.

  1. If required in your environment, upload the LDAP server’s CA certificate file to the v35 - VMware.
  2. Configure LDAP using one of the JSON examples as a starting point.
  3. Test the configuration.
Upload a CA certificate file

If your security policies require that the v35 - VMware should authenticate responses from the LDAP server, the server’s CA certificate must be available on the v35 - VMware. The certificate file can contain one or more trusted CA certificates. The certificates must be in either PEM or DER format.

  1. Access the Admin API on the v35 - VMware.
  2. Navigate to LDAP > POST /access_control/ldap/file/.
  3. Click Try it out.
  4. In the tls_cacertfile field, specify the CA certificate file to upload.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The CA certificate file is uploaded to the v35 - VMware.
Configure LDAP

A convenient way to configure LDAP on the v35 - VMware is to start with the example JSON file that most closely matches your environment and modify fields as appropriate.

  1. Access the Admin API on the v35 - VMware.
  2. Navigate to LDAP > POST /access_control/ldap/.
  3. Click Try it out.
  4. Copy JSON text from the example that most closely matches your environment and paste it to the body field (in the Parameters section).
  5. Modify LDAP settings (within the body field) as appropriate.
  6. Click Execute.
    • The Server response section should show Code “200”.
    • the v35 - VMware’s LDAP service is enabled with the updated configuration.
Test the LDAP configuration

Once you have configured LDAP, you’ll want to confirm that you are able to login to the v35 - VMware using credentials stored on your LDAP server.

To test the configuration:

  1. Log in to Web Admin or the Admin API using credentials stored on the LDAP server.
    • You should also be able to login using the credentials configured on the v35 - VMware (unless you have explicitly disabled this).
View the LDAP configuration

The LDAP service configuration can be viewed using the Admin API interface.

  1. Access the Admin API on the v35 - VMware.
  2. Navigate to LDAP > GET /access_control/ldap/
  3. Click Try it out.
  4. Click Execute.
    • The Server response section should show Code “200”.
    • the v35 - VMware’s LDAP configuration is returned.
Disable LDAP

You can disable the LDAP service if you do not want to authenticate administrative users using LDAP (it is disabled by default). When LDAP is disabled, only the administrator credentials configured on the v35 - VMware can be used.

  1. Access the Admin API on the v35 - VMware.
  2. Navigate to LDAP > DELETE /access_control/ldap/
  3. Click Try it out.
  4. Click Execute.
    • The Server response section should show Code “200”.
    • The v35 - VMware’s LDAP service is disabled.
    • Reconfiguring LDAP will enable the LDAP service.
View LDAP field descriptions

Documentation for all LDAP fields configurable on the v35 - VMware can be found using its Admin API.

  1. Access the Admin API on the v35 - VMware.
  2. Navigate to LDAP > POST /access_control/ldap/
    • The LDAP field descriptions are provided in the Implementation Notes section.
Nested groups in Active Directory

In Active Directory, the default search does not check nested groups. In order to check all groups up to the root, use the string “1.2.840.113556.1.4.1941” in the authorization_search_filter field. For example, use:

  "authorization_search_filter" : "(&(memberOf:1.2.840.113556.1.4.1941:=cn=AppNeta MP Admin,cn=Users,dc=example,dc=com)(sAMAccountName=$uid))”

rather than:

  "authorization_search_filter" : "(&(memberOf=cn=AppNeta MP Admin,cn=Users,dc=example,dc=com)(sAMAccountName=$uid))”
Settings for Oracle DSEE

The default LDAP configuration works for Active Directory. If you use Oracle’s Directory Server Enterprise Edition (DSEE) you need to change the fields shown in the following table to the values shown.

Field Value
authorization_search_filter (&(isMemberOf=…)(uid=$uid))
filter_passwd (objectClass=person)
map_passwd_id uid
Troubleshooting

If you have configured the LDAP service on the v35 - VMware but are unable to login as one of the administrative users defined on the LDAP server, check the following:

  • Make sure the v35 - VMware has network access to the LDAP server. For example, make sure the appropriate firewall ports are open.
    • LDAP uses TCP and UDP port 389.
    • LDAPS uses TCP and UDP port 636.
  • Make sure all fields in the LDAP configuration have been set correctly for your LDAP environment. For example:
    • LDAP server URI(s).
    • Search base.
    • Correct filters for the LDAP server type you are using. Active Directory (default) and Oracle DSEE require different authorization_search_filter, filter_password, and map_password_uid strings.
    • Group name (default = “AppNeta MP Admin”).
    • Correct encryption type.
    • LDAP server CA Certificate file name.
    • Bind DN and password (if required).
Default LDAP configuration

The following table describes the default LDAP configuration on the v35 - VMware when LDAP is enabled (LDAP is enabled when there is a configuration present).

Field Required / Default? Description of default configuration
uris
(Example: “ldap://my-ldap-server.example.com”)
Required The LDAP server name is required.
search_base
(Example: “ou=MyOrg,dc=example,dc=com”)
Required The search base name on the LDAP server is required.
authorization_search_filter
(Example: “(&(memberOf=cn=AppNeta MP Admin,
cn=Users,dc=example,dc=com)(sAMAccountName=$uid))” - applicable to Active Directory)

(Example: “(&(isMemberOf=
cn=AppNeta MP Admin,
cn=Users,dc=example,dc=com)(uid=$uid))” - applicable to Oracle DSEE
Required Specifies the full LDAP path (distinguished name) of the group whose members will be allowed to login to the monitor point. This setting is critical where only a subset of users in the LDAP directory should be MP admins.
tls_cacertfile
(Example: “server-cert.crt”)
Required in default config The filename of the uploaded LDAP server CA certificate file (used to authenticate LDAP server certificates when using SSL or TLS. TLS is used by default.) is required. This field is required when ssl is set to use an encryption protocol and tls_reqcert is set to validate certificates.
ssl
(Default value: “start_tls”)
Default config Communication between the v35 - VMware and the LDAP server is encrypted using TLS.
tls_reqcert
(Default value: “hard”)
Default config Authentication will fail if the v35 - VMware is unable to validate the LDAP server’s certificate. This field is required when ssl is set to use an encryption protocol.
bind_dn
(Default value: “”)
(Example: “cn=Admin,dc=example,dc=com”)
Default config Binding to the LDAP server does not require a username.
bind_password
(Default value: “”)
Default config Binding to the LDAP server does not require a password.
filter_passwd
(Default value: “(objectClass=user)” - applicable to Active Directory)
Default config Within the group, the object class containing the user credentials is found using the default filter.
map_passwd_id
(Default value: “sAMAccountName” - applicable to Active Directory)
Default config Within the object class, the user ID is found in the default attribute.
admin_console_only
(Default value: “false”)
Default config By default, local v35 - VMware admin credentials can be used for remote access. This setting restricts the local admin credentials for use only on the v35 - VMware console, providing for additional physical security.
Examples

The examples shown in this section depict the configurations required in a range of different environments. The configurations are shown in JSON format. They can be copied and modified as required then applied using the Configure LDAP procedure. The examples that use a CA certificate file assume that it has already been uploaded.

Default configuration - Active Directory

This is an example environment that uses the default configuration. The environment is as follows:

  • An Active Directory LDAP server is used.
  • The LDAP server URI is “my-ldap-server.example.com”.
  • The search base is in organizational unit “MyOrg”.
  • User credentials are located in the “AppNeta MP Admin” group within “Users” on the LDAP server.
  • TLS encryption is used (with default LDAP port number - 389).
  • An LDAP server CA certificate is required.
  • The CA certificate file name is “server-cert.crt”.
  • The LDAP server uses an anonymous bind (no bind_dn or bind_password are required).
  • The v35 - VMware’s admin credentials can be used for remote access (in addition to credentials found on LDAP server).

JSON configuration:

{
  "uris": [
    "ldap://my-ldap-server.example.com"
  ],
  "search_base": "ou=MyOrg,dc=example,dc=com",
  "authorization_search_filter" : "(&(memberOf=cn=AppNeta MP Admin,cn=Users,dc=example,dc=com)(sAMAccountName=$uid))",
  "ssl": "start_tls",
  "tls_reqcert": "hard",
  "tls_cacertfile": "server-cert.crt",
  "bind_dn": "",
  "bind_password": "",
  "filter_passwd": "(objectClass=user)",
  "map_passwd_uid": "sAMAccountName",
  "admin_console_only": false
}
Default configuration - Oracle

This is an example environment that uses the default configuration except that the LDAP server is Oracle DSSE rather than Active Directory. The environment is as follows (differences from the default configuration are highlighted):

  • An Oracle DSEE LDAP server is used.
    • Changes to the authorization_search_filter, filter_passwd, and map_passwd_uid fields.
  • The LDAP server URI is “my-ldap-server.example.com”.
  • The search base is in organizational unit “MyOrg”.
  • User credentials are located in the “AppNeta MP Admin” group within “Users” on the LDAP server.
  • TLS encryption is used (with default LDAP port number - 389).
  • An LDAP server CA certificate is required.
  • The CA certificate file name is “server-cert.crt”.
  • The LDAP server uses an anonymous bind (no bind_dn or bind_password are required).
  • The v35 - VMware’s admin credentials can be used for remote access (in addition to credentials found on LDAP server).

JSON configuration:

{
  "uris": [
    "ldap://my-ldap-server.example.com"
  ],
  "search_base": "ou=MyOrg,dc=example,dc=com",
  "authorization_search_filter" : "(&(isMemberOf=cn=AppNeta MP Admin,cn=Users,dc=example,dc=com)(uid=$uid))",
  "ssl": "start_tls",
  "tls_reqcert": "hard",
  "tls_cacertfile": "server-cert.crt",
  "bind_dn": "",
  "bind_password": "",
  "filter_passwd": "(objectClass=person)",
  "map_passwd_uid": "uid",
  "admin_console_only": false
}
Credentials stored in a different group

This is an example environment that uses the default configuration except that the name of the group storing the credentials is “Admins” rather than “AppNeta MP Admin”. The environment is as follows (differences from the default configuration are highlighted):

  • An Active Directory LDAP server is used.
  • The LDAP server URI is “my-ldap-server.example.com”.
  • The search base is in organizational unit “MyOrg”.
  • User credentials are located in the “Admins” group (rather than “AppNeta MP Admin”) within “Users” on the LDAP server.
    • Change to the authorization_search_filter field.
  • TLS encryption is used (with default LDAP port number - 389).
  • An LDAP server CA certificate is required.
  • The CA certificate file name is “server-cert.crt”.
  • The LDAP server uses an anonymous bind (no bind_dn or bind_password are required).
  • The v35 - VMware’s admin credentials can be used for remote access (in addition to credentials found on LDAP server).

JSON configuration:

{
  "uris": [
    "ldap://my-ldap-server.example.com"
  ],
  "search_base": "ou=MyOrg,dc=example,dc=com",
  "authorization_search_filter" : "(&(memberOf=cn=Admins,cn=Users,dc=example,dc=com)(sAMAccountName=$uid))",
  "ssl": "start_tls",
  "tls_reqcert": "hard",
  "tls_cacertfile": "server-cert.crt",
  "bind_dn": "",
  "bind_password": "",
  "filter_passwd": "(objectClass=user)",
  "map_passwd_uid": "sAMAccountName",
  "admin_console_only": false
}
No server certificate validation

This is an example environment that uses the default configuration except that there is no server certificate validation required. The environment is as follows (differences from the default configuration are highlighted):

  • An Active Directory LDAP server is used.
  • The LDAP server URI is “my-ldap-server.example.com”.
  • The search base is in organizational unit “MyOrg”.
  • User credentials are located in the “AppNeta MP Admin” group within “Users” on the LDAP server.
  • TLS encryption is used (with default LDAP port number - 389).
  • An LDAP server CA certificate is not required.
    • Change to the tls_reqcert field.
  • The CA certificate file name is not specified.
    • Change to the tls_cacertfile field.
  • The LDAP server uses an anonymous bind (no bind_dn or bind_password are required).
  • The v35 - VMware’s admin credentials can be used for remote access (in addition to credentials found on LDAP server).

JSON configuration:

{
  "uris": [
    "ldap://my-ldap-server.example.com"
  ],
  "search_base": "ou=MyOrg,dc=example,dc=com",
  "authorization_search_filter" : "(&(memberOf=cn=AppNeta MP Admin,cn=Users,dc=example,dc=com)(sAMAccountName=$uid))",
  "ssl": "start_tls",
  "tls_reqcert": "never",
  "tls_cacertfile": null,
  "bind_dn": "",
  "bind_password": "",
  "filter_passwd": "(objectClass=user)",
  "map_passwd_uid": "sAMAccountName",
  "admin_console_only": false
}
SSL encryption

This is an example environment that uses the default configuration except that SSL encryption is used instead of TLS. The environment is as follows (differences from the default configuration are highlighted):

  • An Active Directory LDAP server is used.
  • The LDAP server URI is “my-ldap-server.example.com”.
  • The search base is in organizational unit “MyOrg”.
  • User credentials are located in the “AppNeta MP Admin” group within “Users” on the LDAP server.
  • SSL encryption is used (with default LDAP port number - 636).
    • Change to the uris field (“ldaps” rather than “ldap”).
    • Change to the ssl field.
  • An LDAP server CA certificate is required.
  • The CA certificate file name is “server-cert.crt”.
  • The LDAP server uses an anonymous bind (no bind_dn or bind_password are required).
  • The v35 - VMware’s admin credentials can be used for remote access (in addition to credentials found on LDAP server).

JSON configuration:

{
  "uris": [
    "ldaps://my-ldap-server.example.com"
  ],
  "search_base": "ou=MyOrg,dc=example,dc=com",
  "authorization_search_filter" : "(&(memberOf=cn=AppNeta MP Admin,cn=Users,dc=example,dc=com)(sAMAccountName=$uid))",
  "ssl": "on",
  "tls_reqcert": "hard",
  "tls_cacertfile": "server-cert.crt",
  "bind_dn": "",
  "bind_password": "",
  "filter_passwd": "(objectClass=user)",
  "map_passwd_uid": "sAMAccountName",
  "admin_console_only": false
}
No encryption

This is an example environment that uses the default configuration except that no encryption is used (instead of TLS). The environment is as follows (differences from the default configuration are highlighted):

  • An Active Directory LDAP server is used.
  • The LDAP server URI is “my-ldap-server.example.com”.
  • The search base is in organizational unit “MyOrg”.
  • User credentials are located in the “AppNeta MP Admin” group within “Users” on the LDAP server.
  • No encryption is used.
    • Change to the ssl field.
  • An LDAP server CA certificate is not required.
    • Change to the tls_reqcert field.
  • The CA certificate file name is not specified.
    • Change to the tls_cacertfile field.
  • The LDAP server uses an anonymous bind (no bind_dn or bind_password are required).
  • The v35 - VMware’s admin credentials can be used for remote access (in addition to credentials found on LDAP server).

JSON configuration:

{
  "uris": [
    "ldap://my-ldap-server.example.com"
  ],
  "search_base": "ou=MyOrg,dc=example,dc=com",
  "authorization_search_filter" : "(&(memberOf=cn=AppNeta MP Admin,cn=Users,dc=example,dc=com)(sAMAccountName=$uid))",
  "ssl": "off",
  "tls_reqcert": "never",
  "tls_cacertfile": null,
  "bind_dn": "",
  "bind_password": "",
  "filter_passwd": "(objectClass=user)",
  "map_passwd_uid": "sAMAccountName",
  "admin_console_only": false
}
Different port used

This is an example environment that uses the default configuration except that port 1389 is used. The environment is as follows (differences from the default configuration are highlighted):

  • An Active Directory LDAP server is used.
  • The LDAP server URI is “my-ldap-server.example.com”.
  • The search base is in organizational unit “MyOrg”.
  • User credentials are located in the “AppNeta MP Admin” group within “Users” on the LDAP server.
  • TLS encryption is used (with non-default LDAP port number - 1389).
    • Change to the uris field.
  • An LDAP server CA certificate is required.
  • The CA certificate file name is “server-cert.crt”.
  • The LDAP server uses an anonymous bind (no bind_dn or bind_password are required).
  • The v35 - VMware’s admin credentials can be used for remote access (in addition to credentials found on LDAP server).

JSON configuration:

{
  "uris": [
    "ldap://my-ldap-server.example.com:1389"
  ],
  "search_base": "ou=MyOrg,dc=example,dc=com",
  "authorization_search_filter" : "(&(memberOf=cn=AppNeta MP Admin,cn=Users,dc=example,dc=com)(sAMAccountName=$uid))",
  "ssl": "start_tls",
  "tls_reqcert": "hard",
  "tls_cacertfile": "server-cert.crt",
  "bind_dn": "",
  "bind_password": "",
  "filter_passwd": "(objectClass=user)",
  "map_passwd_uid": "sAMAccountName",
  "admin_console_only": false
}

802.1X

802.1X is an IEEE standard for providing port-based layer-2 access control to authenticate users or devices wishing to access a LAN or WAN. After successful authentication, the authenticating device uses source MAC filtering to allow only authenticated devices to communicate over the network. The v35 - VMware can be authenticated using PEAP, TLS, or MD5 authentication protocols.

Be aware that by changing or disabling the 802.1X configuration on an active network connection port you run the risk of disconnecting Monitoring Point access unless the switch port you are connected to has a compatible configuration.

How it works

There are three entities involved in 802.1X authentication:

  • Supplicant - The supplicant is the device that wishes to use network resources (for example, an AppNeta Monitoring Point).
  • Authenticator - The authenticator is the device that provides the physical link between the supplicant and the network, relays supplicant credentials to the authentication server, and enforces the network access policy (for example, a layer-2 switch).
  • Authentication server - The authentication server is a trusted server that validates network access requests from the supplicant (for example, a RADIUS server).

At a high level, the sequence of events is:

  1. The supplicant initiates an access request to the authenticator.
  2. The authenticator sets up secure links to the supplicant and to the authentication server and coordinates authentication of the supplicant.
  3. If the authentication is successful, the supplicant accesses the network resources through the authenticator.

Diagram showing 802.1X workflow. 1) Supplicant makes request to authenticator. 2) Authenticator communicates request to authentication server. 3) If authentication is successful, supplicant can access network resources behind authenticator.

Prerequisites and Restrictions

The following are required for the v35 - VMware to access a network using 802.1X authentication:

  • A Layer-2 switch with 802.1X support configured to access an authentication server.
  • An authentication server.
  • A user name and password recognized by the authentication server
  • For PEAP and TLS authentication protocols, additional authentication information including certificates.

The following restrictions should be noted:

  • For a VLAN to work with 802.1X, its underlying physical interface must be configured as DHCP or static.
  • For a VLAN to work with 802.1X, its underlying physical interface must be configured with 802.1X.
Add a physical interface with 802.1X
Add using Web Admin
  1. Complete Monitoring Point setup.
  2. Log in to Web Admin.
  3. Navigate to Network Settings > Network Interfaces.
  4. Click Add Interface and select Ethernet.
  5. Update the configuration as appropriate.
  6. Check the 802.1x security checkbox.
  7. For EAP type, select one of the EAP authentication types:
    • PEAP - PEAP / EAP-MSCHAPv2 or PEAP / EAP-TLS
    • TLS - EAP-TLS
    • MD5 - EAP-MD5
  8. Specify remaining configuration information depending on the EAP type selected. Use to upload any certificate or key files required.
  9. Click Submit.
  10. Restart networking. The interface is operational when networking restarts.
Add using Admin API
  1. Complete Monitoring Point setup.
  2. Access the Admin API.
  3. If you are using an authentication protocol that uses certificate/key files, load the required files:
    1. Navigate to Interface > POST /interface/file/.
    2. Click Try it out.
    3. In the Parameters section, for each of the files you need to load, click Choose File and browse to the file.
    4. Click Execute. The specified files are loaded onto the Monitoring Point
  4. To add the interface, navigate to Interface > POST /interface/.
  5. Click Try it out.
  6. Copy the section of JSON text depending on the authentication protocol you are using:
  7. In the Parameters section, in the body field, paste the JSON text replacing the existing content.
  8. Edit the JSON text replacing variables (those enclosed in arrow brackets “< >”) as appropriate (no arrow brackets should remain) and removing those that are not required.
  9. Click Execute. In the Response Body section, look for a Server response code of 200 to confirm that the interface was added successfully.
  10. Restart networking. You will briefly lose connectivity to the Admin API. The interface is available to use.
Add using curl
  1. Complete Monitoring Point setup.
  2. In APM, navigate to > Manage Monitoring Points to determine the device hostname.
  3. If you are using an authentication protocol that uses certificate/key files, load the required files:

     curl -k -X POST -H 'Expect:' -H 'Content-Type: multipart/form-data' -H 'Accept: application/json' -F wpa_ca_cert=@<file name> -F wpa_client_cert=@<file name> -F wpa_private_key=@<file name> -F wpa_ca_cert2=@<file name> -F wpa_client_cert2=@<file name> -F wpa_private_key2=@<file name> https://admin:<password>@<hostname>/api/v1/interface/file/
    
  4. To add the interface, copy the section of JSON text depending on the authentication protocol you are using:
  5. Edit the JSON text replacing variables (those enclosed in arrow brackets “< >”) as appropriate (no arrow brackets should remain) and removing those that are not required.
  6. Save the text to a file called 8021x-config.json.
  7. Create the interface.

         curl -k -X POST -H "Content-Type: application/json" --data-binary @8021x-config.json https://admin:<password>@<hostname>/api/v1/interface/
    
  8. Verify that your changes are pending.

     curl -k https://admin:<password>@<hostname>/api/v1/interface/?config_state=pending
    
  9. Restart networking. You will briefly lose connectivity to the Admin API.

     curl -k -X PUT -H "Content-Type: application/json" -d {} https://admin:<password>@<hostname>/api/v1/service/networking/action=restart
    
Edit an 802.1X configuration
Edit using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to edit, select > Edit.
  4. Check the 802.1x security checkbox.
  5. For EAP type, select one of the EAP authentication types:
    • PEAP - PEAP / EAP-MSCHAPv2 or PEAP / EAP-TLS
    • TLS - EAP-TLS
    • MD5 - EAP-MD5
  6. Specify remaining configuration information depending on the EAP type selected. Use to upload any certificate or key files required.
  7. Click Submit.
  8. Restart networking. The interface is reconfigured when networking restarts.
Edit using Admin API
  1. Access the Admin API.
  2. To read and copy the current configuration, navigate to Interface > GET /interface/{interface_name}/.
  3. Click Try it out.
  4. In the Parameters section, in the interface_name field, enter the name of the interface you are editing.
  5. In the config_state field, select active.
  6. Click Execute. The Response Code section should show “200”. The 802.1X configuration is shown in the Response Body.
  7. Copy the contents of the Response Body within “families” starting with “{“ and ending with “}”.
  8. To paste and edit the current configuration, navigate to Interface > POST /interface/.
  9. Click Try it out.
  10. In the Parameters section, in the body field, select the existing content and paste the copied content then edit attribute values you wish to change.
    • For PEAP / EAP-MSCHAPv2, specify the following:
    • “wpa_phase1”: “peapver=0”
    • “wpa_phase2”: “auth=MSCHAPV2” * For PEAP / EAP-TLS, specify the following:
    • “wpa_phase1”: “peapver=0”
    • “wpa_phase2”: “auth=TLS”
  11. Click Execute. The Response Code section should show “200”. The 802.1X configuration is shown in the Response Body.
  12. Restart networking. You will briefly lose connectivity to the Admin API. The 802.1X configuration changes take effect.
View an 802.1X configuration
View using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to view, select > Edit. The 802.1x security section contains the 802.1X configuration.
View using Admin API
  1. Access the Admin API.
  2. Navigate to Interface > GET /interface/{interface_name}/.
  3. Click Try it out.
  4. In the Parameters section, in the interface_name field, enter the name of the interface you are viewing.
  5. In the config_state field, select active.
  6. Click Execute. The Response Code section should show “200”. The 802.1X configuration is shown in the Response Body.
Enable an 802.1X configuration
Enable using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to enable 802.1X on, select > Edit.
  4. Check the 802.1x security checkbox.
  5. Click Submit.
  6. Restart networking. 802.1X is enabled on the selected interface.
Enable using Admin API

To enable an 802.1X configuration from the API, use Add a physical interface with 802.1X.

Disable an 802.1X configuration
Disable using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to disable 802.1X on, select > Edit.
  4. Uncheck the 802.1x security checkbox.
  5. Click Submit.
  6. Restart networking. 802.1X is disabled on the selected interface.
Disable using Admin API

To disable an 802.1X configuration from the API, use Add a physical interface with 802.1X and remove all “wpa_” fields.

Networking

The following networking-related features can be configured on the v35 - VMware.

Hostname

See APM Name and Hostname

Default interface

The default interface is the one the v35 - VMware uses to connect to APM. By default, it is the Primary network connection port (eth0).

You can view the default interface or change it to a Secondary network connection port if necessary once it has been added.

View default interface
View using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. In the Active column, Default Interface identifies the default interface.
View using Admin API
  1. Access the Admin API.
  2. Determine which interfaces is the default interface:
    1. Navigate to Interface > GET /interface/default/.
    2. Click Try it out.
    3. Click Execute. * The Server response section should show Code “200”. The name field shows the default interface.
Change default interface
Change using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings >Network Interfaces.
  3. For the interface you want to set as the default interface, click > Set Default Interface.
  4. Click Confirm.
  5. Restart networking.
  6. Connect the interface to your LAN with an Ethernet cable.
    • It will take several minutes before the Monitoring Point status shows as “Connection Established” in APM.
Change using Admin API
  1. Access the Admin API.
  2. Navigate to Interface > PUT /interface/{interface_name}/.
  3. Click Try it out.
  4. In the Parameters section:
    • For the interface_name field, specify the name of the interface you want to set as the default interface.
    • For the action field, select setdefault.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The default interface is changed.
  6. Restart networking.
  7. Connect the interface to your LAN with an Ethernet cable.
    • It will take several minutes before the Monitoring Point status shows as “Connection Established” in APM.

Physical interfaces

You can configure additional physical interfaces if required. You must set one as the default interface, which will be used for v35 - VMware connectivity, and use the other as the source interface for a network path.

For the purposes of configuration, an interface can be thought of as an interface name/address family pair. For example, eth0/IPv4 and eth0/IPv6 are separate interfaces.

Be careful not to put two interfaces on the same subnet.

Add a physical interface
Add using Web Admin
  1. Complete device setup.
  2. Log in to Web Admin.
  3. Navigate to Network Settings > Network Interfaces.
  4. Click Add Interface and select Ethernet.
    • The Add Network Interface page appears.
  5. Specify the interface:
    1. In the Interface Type field, select Ethernet.
    2. In the Interface ID field, select the Ethernet interface.
    3. In the Address Family field, select the type of IP addressing (IPv4 or IPv6) for the interface.
  6. Configure addressing.
  7. (optional) Configure DNS.
  8. (optional) Configure transmission parameters.
  9. (optional) Configure static routes.
  10. Click Submit.
  11. Restart networking.
    • You will briefly lose connectivity.
    • The interface is operational when networking restarts.
Add using Admin API
  1. Complete device setup.
  2. Access the Admin API.
  3. Navigate to Interface > POST /interface/.
  4. Click Try it out.
  5. In the Parameters section, paste the following in the body field (where <interface name> is the name of the interface you are adding (e.g., eth1), <method> is either ‘manual’, ‘static’, or ‘dhcp’, <IP address> is the IP address to use (if <method> is not ‘dhcp’), and <network mask> is the network mask to use (if <method> is not ‘dhcp’)):

    {
      "name": "<interface name>",
      "family": "<family>",
      "method": "<method>",
      "address":"<IP address>",
      "netmask":"<network mask>",
      "gateway":"<gateway>"
    }
    
  6. Click Execute.
    • The Server response section should show Code “200” to confirm that the interface was added.
  7. Restart networking. You will briefly lose connectivity to the Admin API.
    • The interface is available to use.
Add using curl
  1. Complete device setup.
  2. Discover your v35 - VMware hostname at > Manage Monitoring Points.
  3. Find out which interfaces are already configured.

    curl -k -u <username> -X GET -H 'Accept: application/json' 'https://<hostname>/api/v1/interface/?config_state=active' | python -m json.tool
    
  4. Add a new interface.

    curl -k -u <username> -X POST -H "Content-Type: application/json" -d '{"name": "<interface name>", "family": "<family>", "method": "<method>", "address":"<IP address>", "netmask":"<network mask>", "gateway":"<gateway>"}' 'https://<hostname>/api/v1/interface/' | python -m json.tool
    
    • <interface name> - the name of the interface you are adding (e.g., eth1).
    • <family> - either ‘inet’ for IPv4 or ‘inet6’ for IPv6.
    • <method> - either ‘static’ for static IP addresses, ‘dhcp’ for Stateless and Stateful DHCPv6 (IPv6), or ‘auto’ for SLAAC (IPv6).
    • <IP address> - (optional) the IP address to use (if <method> is ‘static’).
    • <network mask> - (optional) the network mask to use (if <method> is ‘static’).
    • <gateway> - (optional) the IP address of the gateway to use (if <method> is ‘static’). Omit optional key:value pairs you are not using. Remove the comma after the final key:value pair.
  5. Restart networking to apply the changes.

    curl -k -u <username> -X PUT -H 'Content-Type: application/json' -d {} 'https://<hostname>/api/v1/service/networking/?action=restart' | python -m json.tool
    
    • You will briefly lose connectivity.
    • The interface is operational when networking restarts.
  6. Verify that the new interface exists.

    curl -k -u <username> -X GET 'https://<hostname>/api/v1/interface/' | python -m json.tool
    

The variables above are defined as follows:

  • <username> - the user name on the v35 - VMware.
  • <hostname> - the hostname or IP address of the v35 - VMware.
Edit a physical interface configuration
Edit using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to edit, select > Edit. The Edit Network Interface page appears.
  4. Configure addressing, DNS, transmission parameters, and static routes as required.
  5. Click Submit.
  6. Restart networking. You will briefly lose connectivity. The interface is reconfigured when networking restarts.
Edit using Admin API
  1. Access the Admin API.
  2. Navigate to Interface > PUT /interface/{interface name}/.
  3. Click Try it out.
  4. In the Parameters section:
    1. In the interface_name field, enter the interface you want to edit (e.g., eth1).
    2. In the body field, update the fields as appropriate.
  5. Click Execute. The Server response section should show Code “200” to confirm that the interface was updated.
  6. Restart networking. You will briefly lose connectivity to the Admin API. The interface is available to use.
Delete a physical interface
Delete using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to delete, select > Delete
  4. Click Confirm.
  5. Restart networking. You will briefly lose connectivity. The interface is deleted when networking restarts.
Delete using Admin API
  1. Access the Admin API.
  2. Navigate to Interface > DELETE /interface/{interface name}/.
  3. Click Try it out.
  4. In the Parameters section, in the interface_name field, enter the interface you want to delete (e.g., eth1).
  5. Click Execute. The Server response section should show Code “200” to confirm that the interface was deleted from the configuration.
  6. Restart networking. You will briefly lose connectivity to the Admin API. The interface is deleted.
Delete using curl
  1. Discover your v35 - VMware hostname at > Manage Monitoring Points.
  2. Find out which interfaces are configured.

    curl -k -u <username> -X GET -H 'Accept: application/json' 'https://<hostname>/api/v1/interface/?config_state=active' | python -m json.tool
    
  3. Delete the interface.

    curl -k -u <username> -X DELETE -H 'Accept: application/json' 'https://<hostname>/api/v1/interface/<interface_name>/?family=<family>' | python -m json.tool
    
  4. Restart networking to apply the changes.

    curl -k -u <username> -X PUT -H 'Content-Type: application/json' -d {} 'https://<hostname>/api/v1/service/networking/?action=restart' | python -m json.tool
    
    • You will briefly lose connectivity.
    • The interface is deleted when networking restarts.

The variables above are defined as follows:

  • <username> - the user name on the v35 - VMware.
  • <hostname> - the hostname or IP address of the v35 - VMware.
  • <interface name> - the name of the interface you are deleting (e.g., eth1).
  • <family> - either ‘inet’ for IPv4 or ‘inet6’ for IPv6.

VLAN interfaces

802.1Q VLAN tagging can be enabled on the v35 - VMware by adding a VLAN interface type to an Ethernet port.

Add a VLAN interface

Video - A video is available for both APM Public and APM Private users that shows how to add a VLAN interface to a Monitoring Point.

Add using Web Admin
  1. Complete device setup.
  2. Log in to Web Admin.
  3. Navigate to Network Settings > Network Interfaces.
  4. Click Add Interface and select Ethernet. The Add Network Interface page appears.
  5. Specify the interface:
    1. In the Interface Type field, select VLAN.
    2. In the Interface ID field, select the Ethernet interface.
    3. In the VLAN/Virtual ID field, specify the VLAN ID you want to add.
    4. In the Address Family field, select the type of IP addressing (IPv4 or IPv6) for the interface.
  6. Configure addressing.
  7. (optional) Configure DNS.
  8. (optional) Configure transmission parameters.
  9. (optional) Configure static routes.
  10. Click Submit.
  11. Restart networking. You will briefly lose connectivity. The interface is operational when networking restarts.
Add using Admin API
  1. Complete device setup.
  2. Access the Admin API.
  3. Navigate to Interface > POST /interface/.
  4. Click Try it out.
  5. In the Parameters section, paste the following in the body field (where <interface name> is the name of the interface you are adding (in the form: ethX.Y), <method> is either ‘manual’, ‘static’, or ‘dhcp’, <IP address> is the IP address to use (if <method> is not ‘dhcp’), and <network mask> is the network mask to use (if <method> is not ‘dhcp’)):

    {
      "name": "<interface name>",
      "family": "<family>",
      "method": "<method>",
      "address":"<IP address>",
      "netmask":"<network mask>",
      "gateway":"<gateway>"
    }
    
  6. Click Execute. The Server response section should show Code “200” to confirm that the interface was added.
  7. Restart networking. You will briefly lose connectivity to the Admin API. The interface is available to use.
Add using curl
  1. Complete device setup.
  2. Discover your Monitoring Point hostname at > Manage Monitoring Points.
  3. Find out what interfaces are already configured.

    curl -k -u <username> -X GET -H 'Accept: application/json' 'https://<hostname>/api/v1/interface/?config_state=active' | python -m json.tool
    
  4. Add a new interface.

    curl -k -u <username> -X POST -H "Content-Type: application/json" -d '{"name": "<interface name>", "family": "<family>", "method": "<method>", "address":"<IP address>", "netmask":"<network mask>", "gateway":"<gateway>"}' 'https://<hostname>/api/v1/interface/' | python -m json.tool
    
    • <interface name> - the name of the interface you are adding (in the form: ethX.Y).
    • <family> - either ‘inet’ for IPv4 or ‘inet6’ for IPv6.
    • <method> - either ‘static’ for static IP addresses, ‘dhcp’ for Stateless and Stateful DHCPv6 (IPv6), or ‘auto’ for SLAAC (IPv6).
    • <IP address> - (optional) the IP address to use (if <method> is ‘static’).
    • <network mask> - (optional) the network mask to use (if <method> is ‘static’).
    • <gateway> - (optional) the IP address of the gateway to use (if <method> is ‘static’). Omit optional key:value pairs you are not using. Remove the comma after the final key:value pair.
  5. Restart networking to apply the changes.

    curl -k -u <username> -X PUT -H 'Content-Type: application/json' -d {} 'https://<hostname>/api/v1/service/networking/?action=restart' | python -m json.tool
    
    • You will briefly lose connectivity.
    • The interface is operational when networking restarts.
  6. Verify that the new interface exists.

    curl -k -u <username> -X GET 'https://<hostname>/api/v1/interface/' | python -m json.tool
    

The variables above are defined as follows:

  • <username> - the user name on the Monitoring Point.
  • <hostname> - the hostname or IP address of the Monitoring Point.
Edit a VLAN interface configuration
Edit using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to edit, select > Edit. The Edit Network Interface page appears.
  4. Configure addressing, DNS, transmission parameters, and static routes as required.
  5. Click Submit.
  6. Restart networking. You will briefly lose connectivity. The interface is reconfigured when networking restarts.
Edit using Admin API
  1. Access the Admin API.
  2. Navigate to Interface > PUT /interface/{interface name}/.
  3. Click Try it out.
  4. In the Parameters section:
    1. In the interface_name field, enter the interface you want to edit (e.g., eth1.4094).
    2. In the body field, update the fields as appropriate.
  5. Click Execute. The Server response section should show Code “200” to confirm that the interface was updated.
  6. Restart networking. You will briefly lose connectivity to the Admin API. The interface is available to use.
Delete a VLAN interface
Delete using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to delete, select > Delete
  4. Click Confirm.
  5. Restart networking. You will briefly lose connectivity. The interface is deleted when networking restarts.
Delete using Admin API
  1. Access the Admin API.
  2. Navigate to Interface > DELETE /interface/{interface name}/.
  3. Click Try it out.
  4. In the Parameters section, in the interface_name field, enter the interface you want to delete (e.g., eth1.4094).
  5. Click Execute. The Server response section should show Code “200” to confirm that the interface was deleted from the configuration.
  6. Restart networking. You will briefly lose connectivity to the Admin API. The interface is deleted.
Delete using curl
  1. Discover your Monitoring Point hostname at > Manage Monitoring Points.
  2. Find out which interfaces are configured.

    curl -k -u <username> -X GET -H 'Accept: application/json' 'https://<hostname>/api/v1/interface/?config_state=active' | python -m json.tool
    
  3. Delete the interface.

    curl -k -u <username> -X DELETE -H 'Accept: application/json' 'https://<hostname>/api/v1/interface/<interface_name>/?family=<family>' | python -m json.tool
    
  4. Restart networking to apply the changes.

    curl -k -u <username> -X PUT -H 'Content-Type: application/json' -d {} 'https://<hostname>/api/v1/service/networking/?action=restart' | python -m json.tool
    
    • You will briefly lose connectivity.
    • The interface is deleted when networking restarts.

The variables above are defined as follows:

  • <username> - the user name on the Monitoring Point.
  • <hostname> - the hostname or IP address of the Monitoring Point.
  • <interface name> - the name of the interface you are deleting (e.g., eth1).
  • <family> - either ‘inet’ for IPv4 or ‘inet6’ for IPv6.

Interface - Addressing

When you create an interface, it is configured as either IPv4 or IPv6. The next step is to set up the interface addressing using either dynamic and/or static IP addresses.

The v35 - VMware supports configuring DHCP and/or multiple static IP addresses on an interface. Up to 128 IP addresses can be configured on an interface and at least one is required (either static or DHCP). Both IPv4 and IPv6 addresses are supported.

Multiple static IP addresses are supported on Physical (Ethernet) and VLAN interface types.

It is possible to configure multiple IPv6 addresses. However, policy routing for IPv6 is not supported at this time.

Potential loss of connectivity: Care must be taken when changing the IP address configuration on the primary network connection. If the new address is in a different subnet than the old one, you will lose network connectivity to the v35 - VMware after restarting networking.

View addressing
View using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to view, the Active column contains the addressing information.
View using Admin API
  1. Log in to Admin API.
  2. Navigate to Interface > GET /interface/{interface_name}/.
  3. In the Parameters section, specify the interface_name you are interested in.
  4. Click Submit. The Response Body section shows the interface configuration including.
    • iftype - interface type (e.g., ethernet).
    • name - interface name (e.g., eth0).
    • family - “inet” indicates IPv4, “inet6” indicates IPv6.
    • method - “static” indicates static IP addresses, “dchp” indicates DHCP and Stateless and Stateful DHCPv6 (IPv6), “auto” indicates SLAAC (IPv6).
    • address - the list of static addresses configured on the interface.
    • dhcp_address - IP address provided by DHCP.
    • dhcp_netmask - the netmask provided by DHCP.
    • dhcp_gateway - the gateway address provided by DHCP.
View using curl
  1. In APM, navigate to > Manage Monitoring Points.
  2. Click the v35 - VMware you want to connect to.
    • The Name field contains the hostname.
    • The Local Network Interface field in the right pane contains the IP address. Use the Public IP if you are connecting across the Internet.
  3. View the interface configuration using:

    curl -k -u <username> -X GET -H 'Accept: application/json' 'https://<hostname>/api/v1/interface/<interface_name>/?config_state=active' | python -m json.tool
    

The variables above are defined as follows:

  • <username> - the user name on the v35 - VMware.
  • <hostname> - the hostname or IP address of the v35 - VMware.
  • <interface_name> - the interface you are interested in.

The response shows the interface configuration including:

  • iftype - interface type (e.g., ethernet).
  • name - interface name (e.g., eth0).
  • family - “inet” indicates IPv4, “inet6” indicates IPv6.
  • method - “static” indicates static IP addresses, “dchp” indicates DHCP and Stateless and Stateful DHCPv6 (IPv6), “auto” indicates SLAAC (IPv6).
  • address - the list of static addresses configured on the interface.
  • dhcp_address - IP address provided by DHCP.
  • dhcp_netmask - the netmask provided by DHCP.
  • dhcp_gateway - the gateway address provided by DHCP.
Add addressing

At least one IP address (either static or dynamic) must be configured on an interface.

The v35 - VMware allows you to configure additional addresses.

Add using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to add an address to, select > Edit.
  4. To add a dynamic address, in the Dynamic Address field, select one of the options. The selection is added to the Interface Addresses field.
  5. To add a static address, in the Static Address field, specify the Address, Netmask, and Gateway you want to add and click . The address is added to the Interface Addresses field.
  6. Repeat the previous step for all the static addresses you want to add.
  7. Click Submit. The address(es) specified are added to the interface but the change does not take effect until networking is restarted.
  8. Restart networking. The changes are applied to the interface.
Add using Admin API
  1. Log in to Admin API.
  2. To determine which interfaces are available, navigate to Interface > GET /interface/ and click Submit. The Response Body section shows the configured interfaces.
  3. To configure an additional IP address on an interface, navigate to Interface > POST /interface/{interface_name}/address/.
  4. In the Parameters section:
    1. Set interface_name to the name of the interface you are configuring (e.g., eth0).
    2. Set family as appropriate. “inet” for IPv4, and “inet6” for IPv6.
  5. In the body section, click the Model Schema on the right. The text is copied to the body field.
  6. Edit the text in the body field as follows:
    1. Change “string” in "address": "string" to the IP address you are adding to the interface. Either an IPv4 or an IPv6 address can be specified (depending on how family is set).
    2. Change “string” in "netmask": "string" to the netmask of the IP address you are adding. For IPv4, use either a prefix (e.g., 24) or a dotted decimal mask (e.g., 255.255.255.0). For IPv6, use a prefix (e.g., 64).
    3. Change “string” in "gateway": "string" to the IP address of the gateway the v35 - VMware uses to access the Internet for the configured address. Alternatively, remove the comma after "netmask": "<netmask>" as well as "gateway": "<gateway>" to use the default gateway configured on the interface.
  7. Click Submit. In the Response Body section, look for "success": true to confirm that the address was added successfully.
  8. Repeat the steps from 3 above for all the addresses you want to add.
  9. To restart networking to apply the changes, navigate to Service > PUT /service/{service_name}/.
  10. In the Parameters section:
    1. Set service_name to “networking”.
    2. Set action to “restart”.
    3. Click Submit. You will briefly lose connectivity to the Admin API.
  11. To verify that the new address exists on the interface, navigate to Interface > GET /interface/{interface_name}/address/.
  12. In the Parameters section:
    1. Set interface_name to the name of the interface you configured.
    2. Set config_state to “active”.
    3. Set family as appropriate. “inet” for IPv4, and “inet6” for IPv6.
    4. Click Submit. The Response Body section shows the addresses configured on the interface.
Add using curl
  1. In APM, navigate to > Manage Monitoring Points.
  2. Find the hostname of your v35 - VMware in the Name column of the table.
  3. Determine which interfaces are available.

    curl -k -u <username> -X GET -H 'Accept: application/json' 'https://<hostname>/api/v1/interface/?config_state=active' | python -m json.tool
    
  4. Configure an additional IP address on an interface.

    curl -k -u <username> -X POST -H 'Content-Type: application/json' -H 'Accept: application/json' -d '{"address": "<address>", "netmask": "<netmask>", "gateway": "<gateway>"}' 'https://<hostname>/api/v1/interface/<interface_name>/address/?family=<addr_type>' | python -m json.tool
    
    • gateway is optional. Remove the comma after "netmask": "<netmask>" if you omit "gateway": "<gateway>".
  5. Restart networking to apply the changes.

    curl -k -u <username> -X PUT -H 'Content-Type: application/json' -d {} 'https://<hostname>/api/v1/service/networking/?action=restart' | python -m json.tool
    
    • You will briefly lose connectivity to the Admin API.
  6. Verify that the new address exists on the interface.

    curl -k -u <username> -X GET 'https://<hostname>/api/v1/interface/<interface_name>/?config_state=active' | python -m json.tool
    

The variables above are defined as follows:

  • <username> - the user name on the v35 - VMware.
  • <address> - the IP address you are adding to the interface. Either an IPv4 or an IPv6 address can be specified.
  • <addr_type> - the type of IP address. Use “inet” for IPv4 and “inet6” for IPv6 addresses.
  • <gateway> - (optional) the IP address of the gateway the v35 - VMware uses to access the Internet for the configured address. If not specified, the default gateway configured on the interface is used.
  • <hostname> - the hostname or IP address of the v35 - VMware.
  • <interface_name> - the name of the interface you are configuring.
  • <netmask> - the netmask of the IP address you are adding. For IPv4, use either a prefix (e.g., 24) or a dotted decimal mask (e.g., 255.255.255.0). For IPv6, use a prefix (e.g., 64).
Edit addressing
Edit using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to edit, select > Edit.
  4. To edit dynamic addressing, in the Dynamic Address field, select the type of dynamic addressing to use (e.g., DHCP) or select None to disable dynamic addressing.
  5. To edit static addresses, in the Interface Addresses field, edit the static IP address configuration and click .
  6. Click Submit. The address is changed but the change does not take effect until networking is restarted.
  7. Restart networking. The changes are applied to the interface.
Edit using Admin API

To edit addressing on an interface you need to delete an address then add a different one.

Delete addressing
Delete using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to edit, select > Edit.
  4. In the Interface Address field, click next to the address you want to delete. The address is deleted from the Interface Addresses section.
  5. Repeat the previous step for all the addresses you want to delete.
  6. Click Submit. The address(es) specified are removed from the interface but the change does not take effect until networking is restarted.
  7. Restart networking. The changes are applied to the interface.
Delete using Admin API
  1. Log in to Admin API.
  2. To determine which addresses are configured on the interface, navigate to Interface > GET /interface/{interface_name}
  3. In the Parameters section:
    1. Set interface_name to the interface you are configuring (e.g., eth0).
    2. Click Submit. The Response Body section shows the interface configuration, including static IP addresses.
  4. To delete an IP address from the interface, navigate to Interface > DELETE /interface/{interface_name}/address/.
  5. In the Parameters section:
    1. Set interface_name to the interface you are configuring (e.g., eth0).
    2. In the body section, click the Model Schema on the right. The text is copied to the body field.
    3. Change “string” in "address": "string" to the address you are deleting.
    4. Click Submit. In the Response Body section, look for "success": true to confirm that the address was deleted successfully.
  6. To restart networking to apply the changes, navigate to Service > PUT /service/{service_name}/.
  7. In the Parameters section:
    1. Set service_name to “networking”.
    2. Set action to “restart”.
    3. Click Submit. You will briefly lose connectivity to the Admin API.
  8. To verify that the address was removed from the interface, navigate to Interface > GET /interface/{interface_name}/address/.
  9. In the Parameters section:
    1. Set interface_name to the name of the interface you configured.
    2. Set config_state to “active”.
    3. Set family as appropriate. “inet” for IPv4, and “inet6” for IPv6.
    4. Click Submit. The Response Body section shows the addresses configured on the interface.
Delete using curl
  1. In APM, navigate to > Manage Monitoring Points.
  2. Find the hostname of your v35 - VMware in the Name column of the table.
  3. Determine which addresses are configured on the interface.

    curl -k -u <username> -X GET 'https://<hostname>/api/v1/interface/<interface_name>/?config_state=active' | python -m json.tool
    
  4. Delete an IP address from the interface.

    curl -k -u <username> -X DELETE -H 'Content-Type: application/json' -H 'Accept: application/json' -d '{"address": "<address>"}' 'https://<hostname>/api/v1/interface/<interface_name>/address/' | python -m json.tool
    
    • You cannot delete the last address on an interface unless dynamic addressing (e.g., DHCP) is also configured.
  5. Restart networking to apply the changes.

    curl -k -u <username> -X PUT -H 'Content-Type: application/json' -d {} 'https://<hostname>/api/v1/service/networking/?action=restart' | python -m json.tool
    
    • You will briefly lose connectivity to the Admin API.
  6. Verify that the address was removed from the interface.

    curl -k -u <username> -X GET 'https://<hostname>/api/v1/interface/<interface_name>/?config_state=active' | python -m json.tool
    

The variables above are defined as follows:

  • <username> - the user name on the v35 - VMware.
  • <address> - the IP address you are deleting from the interface. Either an IPv4 or an IPv6 address can be specified.
  • <hostname> - the hostname or IP address of the v35 - VMware.
  • <interface_name> - the name of the interface you are configuring.
Legacy IPv6 support

If your v35 - VMware has software older than EMP 12.6.0, IPv6 is enabled and disabled globally on the v35 - VMware. Once it is enabled, interfaces can be configured with IPv6.

Enable IPv6
Enable using Admin API
  1. Complete Monitoring Point setup.
  2. Access the Admin API.
  3. Navigate to Appliance > PUT /appliance/.
  4. In the Parameters section, in the IPv6 field, select enable.
  5. Click Submit. The Response Code section should show “200”.
  6. Restart the v35 - VMware. IPv6 is enabled on the v35 - VMware.
Enable using curl
  1. Complete Monitoring Point setup setup.
  2. Discover your v35 - VMware hostname at > Manage Monitoring Points.
  3. Enable IPv6.

    curl -k -u <username> -X PUT -H 'Content-Type: application/json' -d '{}' 'https://<hostname>/api/v1/appliance/?ipv6=enable' | python -m json.tool
    
  4. Restart networking to apply the changes.

    curl -k -u <username> -X PUT -H 'Content-Type: application/json' -d {} 'https://<hostname>/api/v1/service/networking/?action=restart' | python -m json.tool
    
    • You will briefly lose connectivity to the Admin API.

The variables above are defined as follows:

  • <username> - the user name on the v35 - VMware.
  • <hostname> - the hostname or IP address of the v35 - VMware.
Disable IPv6
Disable using Admin API
  1. Access the Admin API.
  2. Navigate to Appliance > PUT /appliance/.
  3. In the Parameters section, in the IPv6 field, select disable.
  4. Click Submit. The Response Code section should show “200”.
  5. Restart the v35 - VMware. IPv6 is disabled on the v35 - VMware.
Disable using curl
  1. Discover your v35 - VMware hostname at > Manage Monitoring Points.
  2. Disable IPv6.

    curl -k -u <username> -X PUT -H 'Content-Type: application/json' -d '{}' 'https://<hostname>/api/v1/appliance/?ipv6=disable' | python -m json.tool
    
  3. Restart networking to apply the changes.

    curl -k -u <username> -X PUT -H 'Content-Type: application/json' -d {} 'https://<hostname>/api/v1/service/networking/?action=restart' | python -m json.tool
    
    • You will briefly lose connectivity.

The variables above are defined as follows:

  • <username> - the user name on the v35 - VMware.
  • <hostname> - the hostname or IP address of the v35 - VMware.
DHCP request ID

When the Monitoring Point requests a DHCP address from a DHCP server, it sends a unique DUID to identify itself. This ID (based on RFC4361) is both deterministic and persistent.

Interface - DNS

The Domain Name System (DNS) is essential internet functionality used for resolving domain names to IP addresses. When the target of a network or web path is identified by a domain name rather than by an IP address, the v35 - VMware uses DNS to resolve the target’s IP address.

How name servers are selected

Typically, the IP addresses of DNS name servers are configured within DHCP so, if the v35 - VMware uses DHCP, those name servers are available to it. Additional name server addresses can also be configured directly on a per address basis on v35 - VMware interfaces.

When a network or web path is initiated from the v35 - VMware, a DNS request is made. It must determine which name servers to pass the DNS request to. If there are one or more name servers configured on the address the path is initiated from (either configured directly on the interface address or returned via DHCP), only those servers are used. If no name servers are configured on the interface address or returned by a DHCP server servicing the interface, then all name servers known to the v35 - VMware are used.

From the v35 - VMware’s perspective, all name servers are considered equivalent. So, when a name resolution is required, the request is forwarded to the appropriate name servers. The first response received is used.

In cases where name servers are not equivalent (typically when providing sub-domain name resolution), this behavior may result in an incorrect name resolution. For example, a name server that cannot resolve a name may respond first with a negative result. This result is used by the v35 - VMware despite it receiving a positive result later on. In these instances, you want to associate a name server with a DNS Search Domain so that all requests for a given domain are forwarded to a specific name server (or set of servers).

In cases where the DNS Search Domain is configured on a specific interface address, when a network or web path is initiated from that address, only the name servers configured directly (or supplied by DHCP) on that address are used to resolve domain names matching the DNS Search Domain. If no DNS Search Domains are configured on the address, then all search domains known to the v35 - VMware are used.

View DNS configuration
View using Web Admin

To view name servers and/or DNS search domains configured on a dynamic address or the first configured address on an interface:

  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to view, select > Edit.
  4. The DNS Configuration section shows the name servers and/or DNS search domains configured on the dynamic address (if used) or the first static address shown in the Interface Addresses section. To view the name servers and/or DNS search domains for other addresses configured on the interface, use the Admin API.
View name servers using Admin API

You can view name servers configured on a dynamic address or the first configured address or on a specific address on an interface.

To view name servers configured on a dynamic address or the first configured address on an interface:

  1. Access the Admin API.
  2. Navigate to DNS > GET /interface/{interface_name}/dns_nameserver/.
  3. Click Try it out.
  4. In the Parameters section, in the interface_name field, enter the name of the interface you are viewing.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The name servers are shown in the Response body.

To view name servers configured on a specific address on an interface:

  1. Access the Admin API.
  2. Navigate to DNS > GET /interface/{interface_name}/{address}/dns_nameserver/.
  3. Click Try it out.
  4. In the Parameters section:
    1. In the interface_name field, enter the name of the interface you are viewing.
    2. In the address field, enter the address whose configuration you are viewing.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The name servers are shown in the Response body.
View DNS search domain using Admin API

You can view DNS search domains configured on a dynamic address or the first configured address or on a specific address on an interface.

To view DNS search domains configured on a dynamic address or the first configured address on an interface:

  1. Access the Admin API.
  2. Navigate to DNS > GET /interface/{interface_name}/dns_search/.
  3. Click Try it out.
  4. In the Parameters section, in the interface_name field, enter the name of the interface you are viewing.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The DNS search domains are shown in the Response body.

To view DNS search domains configured on a specific address on an interface:

  1. Access the Admin API.
  2. Navigate to DNS > GET /interface/{interface_name}/{address}/dns_search/.
  3. Click Try it out.
  4. In the Parameters section:
    1. In the interface_name field, enter the name of the interface you are viewing.
    2. In the address field, enter the address whose configuration you are viewing.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The DNS search domains are shown in the Response body.
Add/Edit DNS configuration
Add/Edit using Web Admin

To add/edit name servers and/or DNS search domains on the dynamic address or the first configured address on an interface:

  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to edit, select > Edit.
  4. In the DNS Configuration section, make your changes to the DNS configuration.
    • Note that the changes apply to the dynamic address (if used) or the first static address shown in the Interface Addresses section. To configure name servers and/or DNS search domains for other addresses configured on the interface, use the Admin API.
  5. Restart networking. The DNS configuration changes take effect.
Add name server using Admin API

You can add name servers to a dynamic address or the first configured address or to a specific address on an interface.

To add name servers to a dynamic address or the first configured address on an interface:

  1. Access the Admin API.
  2. Navigate to DNS > POST /interface/{interface_name}/dns_nameserver/.
  3. Click Try it out.
  4. In the Parameters section:
    1. In the interface_name field, enter the name of the interface you are configuring.
    2. In the body field, replace “string” with the IP address of the name server you are adding. You can enter additional name server addresses on separate lines. All but the last should have a “,” at the end.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The name servers are added.
  6. Restart networking. You will briefly lose connectivity to the Admin API. The DNS configuration changes take effect.

To add name servers to a specific address on an interface:

  1. Access the Admin API.
  2. Navigate to DNS > POST /interface/{interface_name}/{address}/dns_nameserver/.
  3. Click Try it out.
  4. In the Parameters section:
    1. In the interface_name field, enter the name of the interface you are configuring.
    2. In the address field, enter the address you are configuring.
    3. In the body field, replace “string” with the IP address of the name server you are adding. You can enter additional name server addresses on separate lines. All but the last should have a “,” at the end.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The name servers are added.
  6. Restart networking. You will briefly lose connectivity to the Admin API. The DNS configuration changes take effect.
Add DNS search domain using Admin API

You can add DNS search domains to a dynamic address or the first configured address or to a specific address on an interface.

To add DNS search domains to a dynamic address or the first configured address on an interface:

  1. Access the Admin API.
  2. Navigate to DNS > POST /interface/{interface_name}/dns_search/.
  3. Click Try it out.
  4. In the Parameters section:
    1. In the interface_name field, enter the name of the interface you are configuring.
    2. In the body field, replace “string” with the search domain. You can enter additional search domains on separate lines. All but the last should have a “,” at the end.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The DNS search domains are added.
  6. Restart networking. You will briefly lose connectivity to the Admin API. The DNS configuration changes take effect.

To add DNS search domains to a specific address on an interface:

  1. Access the Admin API.
  2. Navigate to DNS > POST /interface/{interface_name}/{address}/dns_search/.
  3. Click Try it out.
  4. In the Parameters section:
    1. In the interface_name field, enter the name of the interface you are configuring.
    2. In the address field, enter the address you are configuring.
    3. In the body field, replace “string” with the search domain. You can enter additional search domains on separate lines. All but the last should have a “,” at the end.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The DNS search domains are added.
  6. Restart networking. You will briefly lose connectivity to the Admin API. The DNS configuration changes take effect.
Delete DNS configuration
Delete using Web Admin

To delete name servers and/or DNS search domains from a dynamic address or from the first configured address on an interface:

  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to delete from, select > Edit.
  4. In the DNS Configuration section, make your changes to the DNS configuration.
    • Note that the changes apply to the dynamic address (if used) or the first static address shown in the Interface Addresses section. To delete name servers and/or DNS search domains for other addresses configured on the interface, use the Admin API.
  5. Restart networking.
    • The DNS configuration changes take effect.
Delete name servers using Admin API

You can delete all user-defined name servers from a dynamic address or the first configured address or from a specific address on an interface.

To delete all user-defined name servers from a dynamic address or the first configured address on an interface:

  1. Access the Admin API.
  2. Navigate to DNS > DELETE /interface/{interface_name}/dns_nameserver/.
  3. Click Try it out.
  4. In the Parameters section, in the interface_name field, enter the name of the interface you are deleting name servers from.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The name servers are deleted from the dynamic address or the first configured address on an interface.
  6. Restart networking. You will briefly lose connectivity to the Admin API.
    • The DNS configuration changes take effect.

To delete all user-defined name servers from a specific address on an interface:

  1. Access the Admin API.
  2. Navigate to DNS > DELETE /interface/{interface_name}/{address}/dns_nameserver/.
  3. Click Try it out.
  4. In the Parameters section:
    1. In the interface_name field, enter the name of the interface you are deleting name servers from.
    2. In the address field, enter the address you are deleting name servers from.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The name servers are deleted from the specified address.
  6. Restart networking. You will briefly lose connectivity to the Admin API.
    • The DNS configuration changes take effect.
Delete DNS search domain using Admin API

You can delete all user-defined DNS search domains from a dynamic address or the first configured address or from a specific address on an interface.

To delete all user-defined DNS search domains from a dynamic address or the first configured address on an interface:

  1. Access the Admin API.
  2. Navigate to DNS > DELETE /interface/{interface_name}/dns_search/.
  3. Click Try it out.
  4. In the Parameters section, in the interface_name field, enter the name of the interface you are deleting DNS search domains from.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The DNS search domains are deleted.
  6. Restart networking. You will briefly lose connectivity to the Admin API.
    • The DNS configuration changes take effect.

To delete all user-defined DNS search domains from a specific address on an interface:

  1. Access the Admin API.
  2. Navigate to DNS > DELETE /interface/{interface_name}/{address}/dns_search/.
  3. Click Try it out.
  4. In the Parameters section:
    1. In the interface_name field, enter the name of the interface you are deleting DNS search domains from.
    2. In the address field, enter the address you are deleting DNS search domains from.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The DNS search domains are deleted.
  6. Restart networking. You will briefly lose connectivity to the Admin API.
    • The DNS configuration changes take effect.

Interface - Transmission Parameters

In general, transmission parameters (Maximum Transmission Unit (MTU), Auto negotiation, Speed, and Duplex) use default values but can be changed if necessary.

View transmission parameters
View using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to view, select > Edit.
  4. Click Advanced Configuration (at the bottom of the page). The advanced configuration parameters appear.
View using Admin API
  1. Log in to Admin API.
  2. Navigate to Interface > GET /interface/{interface_name}/.
  3. In the Parameters section, specify the interface_name you are interested in.
  4. Click Submit. The Response Body section shows the interface configuration including.
    • mtu - Maximum Transmission Unit (“null” by default, meaning “1500”).
    • autoneg - Auto Negotiation (“on” by default).
    • speed - Speed (“null” by default, meaning “Auto”).
    • duplex - Duplex (“null” by default, meaning “Auto”).
View using curl
  1. In APM, navigate to > Manage Monitoring Points.
  2. Click the Monitoring Point you want to connect to.
    • The Name field contains the hostname.
    • The Local Network Interface field in the right pane contains the IP address. Use the Public IP if you are connecting across the Internet.
  3. View the interface configuration using:

    curl -k -u <username> -X GET -H 'Accept: application/json' 'https://<hostname>/api/v1/interface/<interface_name>/?config_state=active' | python -m json.tool
    

The variables above are defined as follows:

  • <username> - the user name on the Monitoring Point.
  • <hostname> - the hostname or IP address of the Monitoring Point.
  • <interface_name> - the interface you are interested in.

The response shows the interface configuration including:

  • mtu - Maximum Transmission Unit (“null” by default, meaning “1500”).
  • autoneg - Auto Negotiation (“on” by default).
  • speed - Speed (“null” by default, meaning “Auto”).
  • duplex - Duplex (“null” by default, meaning “Auto”).
Edit transmission parameters
Edit using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to edit, select > Edit.
  4. Click Advanced Configuration (at the bottom of the page). The advanced configuration parameters appear.
  5. Update the transmission parameters as required.
  6. Click Submit.
  7. Restart networking. The changes are applied to the interface.
Edit using Admin API
  1. Access the Admin API.
  2. Navigate to Interface > PUT /interface/{interface name}/.
  3. In the Parameters section, in the interface_name field, enter the interface you want to edit (e.g., eth1).
  4. In the body section, click the Model Schema on the right. The text is copied to the body field.
  5. Within body, update the fields as appropriate.
  6. Click Submit. In the Response Body section, look for "success": true to confirm that the interface was updated.
  7. Restart networking. You will briefly lose connectivity to the Admin API. The interface is reconfigured when networking restarts.
Edit using curl
  1. In APM, navigate to > Manage Monitoring Points.
  2. Click the Monitoring Point you want to connect to.
    • The Name field contains the hostname.
    • The Local Network Interface field in the right pane contains the IP address. Use the Public IP if you are connecting across the Internet.
  3. Edit the transmission parameters using:

    curl -k -u <username> -X PUT -H 'Content-Type: application/json' -H 'Accept: application/json' -d '{"mtu": "<mtu>", "autoneg": "<autoneg>", "speed": "<speed>", "duplex": "<duplex>"}' 'https://<hostname>/api/v1/interface/<interface_name>/'  | python -m json.tool
    
    • Omit optional key:value pairs you are not using. Remove the comma after the final key:value pair.

The variables above are defined as follows:

  • <username> - the user name on the Monitoring Point.
  • <hostname> - the hostname or IP address of the Monitoring Point.
  • <interface_name> - the interface you are configuring.
  • <mtu> - Maximum Transmission Unit (“1500” by default.).
  • <autoneg> - Auto Negotiation (“on” or “off”. “on” by default.).
  • <speed> - Speed (“10”, “100”, “1000”, or “auto”. “auto” by default.).
  • <duplex> - Duplex (“half”, “full”, or “auto”. “auto” by default.).

Interface - Static Routes

Depending on where a Monitoring Point is deployed, you may need to add static routes. Static routes are configured per interface.

Add static routes
Add using Web Admin
  1. Complete Monitoring Point setup.
  2. Log in to Web Admin
  3. Navigate to Network Settings > Network Interfaces.
  4. For the interface you want to add a static route to, select > Edit.
  5. Click Advanced Configuration.
  6. In the Static Routes section, enter the Address, Netmask, and Gateway address.
  7. Click to add another static route.
  8. Click Submit.
  9. Restart networking.
    • The static route can be used.
Add using Admin API
  1. Complete Monitoring Point setup.
  2. Access the Admin API.
  3. Navigate to Static Route > POST /interface/{interface_name}/static_route/.
  4. Click Try it out.
  5. In the body field, update the fields as appropriate.
  6. Click Execute.
    • The Server response section should show Code “200” to confirm that the static route is added to the interface.
  7. Restart networking.
    • You will briefly lose connectivity to the Admin API.
    • The static route can be used.
Edit static routes
Edit using Web Admin
  1. Log in to Web Admin
  2. Navigate to Network Settings Network Interfaces.
  3. For the interface with the static route you want to edit, select > Edit.
  4. Click Advanced Configuration.
  5. Update the fields as appropriate.
  6. Click Submit.
  7. Restart networking.
Edit using Admin API

To edit a static route you need to delete the route then add it again with a changed configuration.

Delete static routes
Delete using Web Admin
  1. Log in to Web Admin
  2. Navigate to Network Settings > Network Interfaces.
  3. For the interface you want to delete a static route from, select > Edit
  4. Click Advanced Configuration.
  5. For the static route you want to delete, click .
  6. Click Submit.
  7. Restart networking.
Delete using Admin API

Note: This procedure deletes all static routes from the specified interface.

  1. Access the Admin API.
  2. Navigate to Static Routes > DELETE /interface/{interface_name}/static_route/.
  3. Click Try it out.
  4. In the Parameters section, in the interface_name field, enter the interface you want to delete static routes from (e.g., eth1).
  5. Click Execute.
    • The Server response section should show Code “200” to confirm that the static routes were deleted from the configuration.
  6. Restart networking.
    • You will briefly lose connectivity to the Admin API.
    • The static route deletion is complete.

NTP

By default the v35 - VMware uses NTP to keep the clock accurate. A set of default NTP servers is pre-configured and additional servers can be added.

List currently configured NTP servers
List using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Monitoring Point Settings > NTP.
  3. Click the NTP Servers dropdown.
    • The currently configured NTP servers are listed.
List using Admin API
  1. Access the Admin API.
  2. Navigate to NTP > GET /ntp/.
  3. Click Try it out.
  4. Click Execute.
    • The Server response section should show Code “200”.
    • The preconfigured NTP servers are listed in "default_servers": [].
    • The NTP servers you added are listed in "servers": [].
Show the reachability status of each configured NTP server
  1. Log in to Web Admin.
  2. Navigate to Monitoring Point Settings > NTP.
  3. Click Check Reachability
    • The Monitoring Point tries to reach all configured NTP servers and reports the status.
    • The reachability status is displayed.
Add an NTP server
Add using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Monitoring Point Settings > NTP.
  3. In the NTP Servers field, specify the IP address of an NTP server.
  4. Click .
    • The NTP server at the specified IP address is added to the list.
Add using Admin API
  1. Access the Admin API.
  2. Navigate to NTP > PUT /ntp/.
  3. Click Try it out.
  4. In the Parameters section, paste the following in the body field (where <NTP server IP address> is the IP address of the NTP server you are adding):

    {
      "servers": [
        "<NTP server IP address>"
      ]
    }
    
    • You can add more than one NTP server to the list, but all but the last one requires a “,” after it.
  5. Click Execute.
    • The Server response section should show Code “200” to confirm that the list of servers was added.
Delete an NTP server
Delete using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Monitoring Point Settings > NTP.
  3. Click the NTP Servers dropdown.
  4. For the NTP server you want to delete from the list, click .
    • You can only delete an NTP server you have added. You cannot delete a pre-configured NTP server.
  5. Click Yes.
    • The NTP server is deleted from the list.
Delete using Admin API
  1. Access the Admin API.
  2. Navigate to NTP > DELETE /ntp/.
  3. Click Try it out.
  4. In the Parameters section, paste the following in the body field (where <NTP server IP address> is the IP address of the NTP server you are deleting):

    {
      "servers": [
        "<NTP server IP address>"
      ]
    }
    
    • You can delete more than one NTP server to the list, but all but the last one requires a “,” after it.
  5. Click Execute.
    • The Server response section should show Code “200” to confirm that the list of servers was deleted.
Enable the default NTP servers
Enable using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Monitoring Point Settings > NTP.
  3. Click the NTP Servers dropdown.
  4. Click the button next to Default servers (disabled).
    • The list of default servers is added.
Enable using Admin API
  1. Access the Admin API.
  2. Navigate to NTP > PUT /ntp/default/.
  3. Click Try it out.
  4. In the body field, specify: “enable”: true
  5. Click Execute.
    • The Response body field should contain “status”: 200.
Disable the default NTP servers
Disable using Web Admin
  1. Log in to Web Admin.
  2. Navigate to Monitoring Point Settings > NTP.
  3. Click the NTP Servers dropdown.
  4. Click the button next to Default servers (enabled).
    • The list of default servers is removed.
    • Note: This can only be accessed if there is at least one non-default NTP server configured.
Disable using Admin API
  1. Access the Admin API.
  2. Navigate to NTP > PUT /ntp/default/.
  3. Click Try it out.
  4. In the body field, specify: “enable”: false
  5. Click Execute.
    • The Response body field should contain “status”: 200.

Web proxy

For networks that require internet traffic to be forwarded by a web proxy, the v35 on VMware must be configured to connect to your proxy server so that it can communicate with APM.

The proxy settings on the v35 - VMware only affect how it connects and reports data back to APM. These settings are not used for performance monitoring. If you are using Experience monitoring, you will also need to configure access to the proxy either when you create a web app group or after the web app group is created.

  1. Log in to Web Admin.
  2. Navigate to Monitoring Point Settings > Proxy.
  3. Enter proxy information:
    • Proxy Address - the IP address of the proxy server.
    • Proxy Port - the port the proxy server is listening on.
    • Username - a valid user name on the proxy server (if authentication/authorization is required). Only basic and digest authentication protocols are supported. NTLM and Kerberos are not supported.
    • Password - the password for the username specified (if authentication/authorization is required).
  4. Click Submit.
  5. Wait for the sequencer process to restart.
  6. Click Home.
  7. Verify that the device connected to APM. The Monitoring Point Connected field should show “Yes”.

Usage monitoring

The following Usage monitoring related features can be configured on the v35 - VMware.

Compression

In order to increase Usage performance, you can configure “drop-port” compression on Usage interfaces. This technique drops port information from nfcapd files and results in significant compression of Usage data with a corresponding increase in responsiveness.

This feature is controlled from the v35 - VMware’s Admin API.

View Usage interfaces

Return a list of Usage interfaces on the v35 - VMware.

  1. Access the Admin API.
  2. Navigate to Flow > GET /flow/interface/.
  3. Click Try it out.
  4. Click Execute.
    • The Response body field shows a list of Usage interfaces on the v35 - VMware.
View Usage interface compression configuration

Return the configuration of a Usage interface.

  1. Access the Admin API.
  2. Navigate to Flow > GET /flow/interface/{interface_name}.
  3. Click Try it out.
  4. In the interface_name field, specify the Usage interface you are interested in (e.g. “eth1”).
  5. Click Execute.
    • The Response body field shows the drop_port_enabled configuration. If set to true, drop-port compression is enabled on the port. If set to false there is no compression.
Enable compression on a Usage interface
  1. Access the Admin API.
  2. Navigate to Flow > PUT /flow/interface/{interface_name}.
  3. Click Try it out.
  4. In the interface_name field, specify the Usage interface you are configuring (e.g. “eth1”).
  5. In the body field, specify: “drop_port_enabled”: true
  6. Click Execute.
    • The Response body field should contain “status”: 200.
Disable compression on a Usage interface
  1. Access the Admin API.
  2. Navigate to Flow > PUT /flow/interface/{interface_name}.
  3. Click Try it out.
  4. In the interface_name field, specify the Usage interface you are configuring (e.g. “eth1”).
  5. In the body field, specify: “drop_port_enabled”: false
  6. Click Execute.
    • The Response body field should contain “status”: 200.

Name Capture Interfaces

You can name the Usage monitoring packet capture interface on the v35 - VMware.

To name a capture interface:

  1. Navigate to > Manage Monitoring Points.
  2. For the Monitoring Point you are interested in, select > Name Capture Interfaces.
  3. In the Name field, enter the new capture interface name.
  4. Click Submit.
    • The interface name is changed.

Packet Capture Passphrase

The passphrase is used to encrypt your .pcap files generated by Packet Capture. While the passphrase is required to download capture files, it is not required to view packet capture analysis of capture files through APM. Remember the passphrase. If you lose it you can reset it, but you cannot download any captures encrypted with the old passphrase.

Determine if a passphrase is configured
Use Web Admin
  1. Log in to Web Admin.
  2. Navigate to Usage Monitoring Settings > Packet Capture.
    • If the DELETE PASSPHRASE button is enabled, a passphrase exists on the Monitoring Point. If it is disabled a passphrase does not exist.
Use Admin API
  1. Access the Admin API.
  2. Navigate to Capture Passphrase > GET /flow/passphrase/.
  3. Click Try it out.
  4. Click Execute.
    • The Server response section should show Code “200”.
    • Also look for "capture_passphrase_configured": true to show that the passphrase is configured. It will show "capture_passphrase_configured": false if it is not.
Set the passphrase

Setting the passphrase is required in order to perform packet captures.

Use Web Admin
  1. Log in to Web Admin.
  2. Navigate to Usage Monitoring Settings > Packet Capture.
  3. Enter a passphrase.
  4. Click Submit.
    • The passphrase is set for the Monitoring Point.
Use Admin API
  1. Access the Admin API.
  2. Navigate to Capture Passphrase > PUT /flow/passphrase/.
  3. Click Try it out.
  4. In the Parameters section, paste the following in the body field (where <passphrase> is your chosen passphrase):

    {
      "passphrase": "<passphrase>"
    }
    
  5. Click Execute.
    • The Server response section should show Code “200” to confirm that the passphrase was successfully set.
Clear the passphrase

This function is included in device setup and decommission, so you will likely never need to use it explicitly.

Use Web Admin
  1. Log in to Web Admin.
  2. Navigate to Usage Monitoring Settings > Packet Capture.
  3. Click DELETE PASSPHRASE.
  4. Click Continue.
    • The passphrase is deleted
Use Admin API
  1. Access the Admin API.
  2. Navigate to Capture Passphrase > DELETE /flow/passphrase/.
  3. Click Try it out.
  4. Click Execute.
    • The Server response section should show Code “200” to confirm that the passphrase was successfully cleared.

Other Services

The following can also be configured on the v35 - VMware.

Web Server SSL key/certificate

The web server running on the v35 - VMware provides administrative access via the Web Admin and Admin API interfaces, using HTTPS for secure communications on these interfaces. The default SSL certificate is self-signed, hence users accessing the v35 - VMware using these interfaces will receive security warnings complaining about an untrusted or invalid certificate, or that the hostname in the certificate does not match the v35 - VMware’s hostname. To eliminate these warnings, you can replace the self-signed certificate/key pair with your own trusted certificate/key pair and, if provided by the Certificate Authority, intermediate/chained CA certificates.

Determine if custom certificate/key file(s) are used
Use Web Admin
  1. Log in to Web Admin.
  2. Navigate to Monitoring Point Settings > Web Server.
    • If Default is selected, then default certificate/key file(s) are being used.
    • If Custom is selected, then custom certificate/key file(s) are being used.
Use Admin API
  1. Log in to Admin API
  2. Navigate to Web > GET /web/ssl/.
  3. Click Try it out.
  4. Click Execute.
    • The Server response section should show Code “200”.
    • If the Response body shows custom_key_certificate as “true”, then custom certificate/key file(s) are being used.
    • If the Response body shows custom_key_certificate as “false”, then custom certificate/key file(s) are not being used (the default Monitoring Point key and self-signed certificate are being used).
Use curl
  1. In APM, navigate to > Manage Monitoring Points.
  2. Find the hostname of your Monitoring Point in the Name column of the table.
  3. Determine if custom certificate/key file(s) are being used using:

    curl -k -u <username> -X GET -H 'Accept: application/json' 'https://<hostname>/api/v1/web/ssl/'
    
    • If the response shows custom_key_certificate as “true”, then custom certificate/key file(s) are being used.
    • If the response shows custom_key_certificate as “false”, then custom certificate/key file(s) are not being used (the default Monitoring Point key and self-signed certificate are being used).
Load custom certificate/key file(s)
Use Web Admin
  1. Log in to Web Admin.
  2. Navigate to Monitoring Point Settings > Web Server.
  3. Select Custom.
  4. Click Upload new certificates.
  5. In the Private Key/Certificate field, click .
    • Either drag or browse to the file containing the private key and trusted public key certificate (PEM format).
  6. If you have CA certificates, in the CA Certificates field, click .
    • Either drag or browse to the file containing the CA certificates (PEM format).
  7. Click Submit.
    • The file(s) are loaded.
  8. Click Confirm to restart the Web Admin interface.
    • You will lose access for up to 30 seconds. The connection will then be reestablished.
    • The custom certificate/key file(s) will be used once the web server is restarted.
Use Admin API
  1. Log in to Admin API
  2. Navigate to Web > POST /web/ssl/.
  3. Click Try it out.
  4. In the key_certificate_file field, browse to the file containing the private key and trusted public key certificate (PEM format).
  5. If you have CA certificates, in the certificate_authority_file field, browse to the file containing the CA certificates (PEM format).
  6. Click Execute.
    • The Server response section should show Code “200”.
    • You will lose access for up to 30 seconds. The connection will then be reestablished.
    • The custom certificate/key file(s) will be used once the web server is restarted.
Use curl
  1. In APM, navigate to > Manage Monitoring Points.
  2. Find the hostname of your Monitoring Point in the Name column of the table.
  3. Load the custom certificate/key file(s) using:

    curl -k -u <username> -X POST -H 'Expect:' -H 'Content-Type: multipart/form-data' -H 'Accept: application/json' -F key_certificate_file=@<full path to key/certificate file> -F certificate_authority_file=@<full path to CA certificate file>  https://<hostname>/api/v1/web/ssl/
    
    • The custom certificate/key file(s) will be used once the web server is restarted.
Use default certificate/key file(s)
Use Web Admin
  1. Log in to Web Admin.
  2. Navigate to Monitoring Point Settings > Web Server.
  3. Select Default.
  4. Click Submit.
  5. Click Confirm to restart the Web Admin interface.
    • You will lose access for up to 30 seconds. The connection will then be reestablished.
    • The default Monitoring Point key and self-signed certificate will be used once the web server is restarted.
Use Admin API
  1. Log in to Admin API
  2. Navigate to Web > DELETE /web/ssl/.
  3. Click Try it out.
  4. Click Execute.
    • The Server response section should show Code “200”.
    • Custom certificate/key file(s) will be removed.
    • You will lose access for up to 30 seconds. The connection will then be reestablished.
    • The default Monitoring Point key and self-signed certificate will be used once the web server is restarted.
Use curl
  1. In APM, navigate to > Manage Monitoring Points.
  2. Find the hostname of your Monitoring Point in the Name column of the table.
  3. Delete the certificate/key file(s) using:

    curl -k -u <username> -X DELETE "Content-Type: application/json" https://<hostname>/api/v1/web/ssl/
    
    • The file(s) are removed and the web server is restarted.
    • The default Monitoring Point key and self-signed certificate will be used once the web server is restarted.

SNMP

The v35 - VMware’s read-only SNMP community string is provided when the v35 - VMware is queried by an NMS. By default, the string is either ‘AppNeta’ (for software version 9.10.0 or higher) or ‘public’ (for all other software versions).

Note that SNMP v2 is supported. SNMP v3 is not supported.

You can change the community string as follows:

  1. Access the Admin API
  2. Retrieve the current community string setting:
    1. Navigate to Service > GET /service/{service_name}/settings/.
    2. Click Try it out.
    3. In the Parameters section, in the service_name field, enter ‘pathview-snmpd’.
    4. Click Execute. The Server response section should show Code “200”.
    5. Copy the contents of the Response body field.
  3. Update the community string:
    1. Navigate to Service > PUT /service/{service_name}/settings/.
    2. Click Try it out.
    3. In the Parameters section, in the service_name field, enter ‘pathview-snmpd’.
    4. In the body field, paste the content you copied in the previous step.
    5. Update the ‘rocommunity’ value as appropriate.
    6. Click Execute. The Server response section should show Code “200”. The snmpd service is restarted and the change is applied.
  4. Verify the new settings:
    1. Navigate to Service > GET /service/{service_name}/settings/.
    2. Click Try it out.
    3. In the Parameters section, in the service_name field, enter ‘pathview-snmpd’.
    4. Click Execute. The Server response section should show Code “200”.
    5. Verify the value of ‘rocommunity’.

Manage

Restart

Restarting the v35 - VMware will disrupt its connection to APM but it does not affect its software or its configuration.

Restart using Web Admin

To restart the v35 - VMware:

  1. Log in to Web Admin.
  2. Click > Restart Monitoring Point.
  3. Click Confirm.
    • Access is lost while the v35 - VMware restarts.
Restart using Admin API

To restart the v35 - VMware:

  1. Access the Admin API.
  2. Navigate to Appliance > PUT /appliance/.
  3. Click Try it out.
  4. In the Parameters section, for the action parameter, select reboot.
  5. Click Execute.
    • The Server response section should show Code “202”.
    • Access is lost while the v35 - VMware restarts.

Restart networking

Restarting networking on the v35 - VMware will disrupt its connection to APM but it does not affect its software or its configuration.

Restart networking using Web Admin

To restart networking on the v35 - VMware:

  1. Log in to Web Admin.
  2. Click > Restart Networking.
  3. Click Confirm.
    • Access is lost while the networking system restarts.
Restart networking using Admin API

To restart networking on the v35 - VMware:

  1. Access the Admin API.
  2. Navigate to Service > PUT /service/{service_name}.
  3. Click Try it out.
  4. In the Parameters section:
    1. Set service_name to “networking”.
    2. Set action to “restart”.
  5. Click Execute.
    • The Server response section should show Code “202”.
    • Access is lost while the networking system restarts.
Restart networking using curl

To restart networking on the v35 - VMware:

  1. In APM, navigate to > Manage Monitoring Points to determine the device hostname.
  2. Restart networking.

    curl -k -u <username> -X PUT -H 'Content-Type: application/json' -d {} 'https://<hostname>/api/v1/service/networking/?action=restart' | python -m json.tool
    
    • Access is lost while the networking system restarts.

The variables above are defined as follows:

  • <username> - the user name on the Monitoring Point.
  • <hostname> - the hostname or IP address of the Monitoring Point.

Shutdown

The v35 - VMware should be shut down gracefully if possible.

To gracefully shut down the v35 - VMware, issue a graceful shutdown request from the hypervisor.

Delete

Deleting the v35 - VMware from an organization is typically done when you are moving it to another organization or freeing up its base license so it can be used by another Monitoring Point.

Deleting the v35 - VMware has the following effects:

  • All paths where the v35 - VMware is the source (and the monitoring history related to those paths) are deleted (though they can be moved to another Monitoring Point during the delete process).
  • All Usage monitoring data related to the v35 - VMware is deleted.
  • Tests, assessments, and packet captures are not deleted.
  • The base license and any add-on licenses that were assigned to the v35 - VMware become available again.
  • Access to the v35 - VMware from APM is lost.
  • The v35 - VMware is decommissioned. This resets the APM connection configuration on the v35 - VMware.
  • In order to use the v35 - VMware again you need to redo the setup procedure.

    To delete the v35 - VMware from your organization:

  1. Navigate to > Manage Monitoring Points.
  2. For the v35 - VMware you want to delete, select > Delete.
    • You will be prompted to confirm this action, and optionally to move all affected paths to another Monitoring Point.

Manage software

There are a number of procedures to help manage the software running on the v35 - VMware:

The effects of these procedures are summarized in the following table:

Procedure Software change? Network config change? APM access config change?
Upgrade software Y (latest software) N N
Reflash (local image) Y (local image) N N
Decommission N N Y (factory)(no APM access)
Reset to factory defaults (local image) Y (local image) Y (factory) Y (factory)(no APM access)

Upgrade software

AppNeta recommends keeping your v35 - VMware software up to date to take advantage of the latest features and bug fixes. You will see the Upgrade Available symbol () appear on the Monitoring Points page when the v35 - VMware is no longer running the latest software version.

You can configure APM to upgrade the v35 - VMware automatically or you can upgrade it manually from APM at any time.

Note that the upgrade process can result in a gap of up to 15 minutes of monitoring history. Also note that the v35 - VMware must be connected to APM in order for an upgrade to complete successfully.

Upgrade type

You can see which upgrade options are available on the Monitoring Points page.

To see the Upgrade Type currently assigned to your v35 - VMware:

  1. Within APM, navigate to > Manage Monitoring Points.
  2. The Upgrade Type column shows the upgrade type. These include:
    • Manual - Upgrades are to be performed manually (no automation).
    • Managed - Upgrades are to be performed automatically when new software is released. This enables you to have the latest software running at all times. The software upgrade schedule is listed on the AppNeta service status page: http://status.appneta.com/.
    • Scheduled - Upgrades are to be performed automatically on a regularly scheduled interval. This enables you to schedule upgrades during your regular network maintenance window. You also have the option of skipping the next upgrade.
Configure upgrade automation

To configure Monitoring Point upgrade automation:

  1. Within APM, navigate to > Manage Monitoring Points.
  2. To configure a single Monitoring Point, select > Upgrade Settings next to the Monitoring Point you want to configure.
  3. To configure multiple Monitoring Points:
    1. Use the check boxes on the left to select the Monitoring Points to configure.
    2. In the Action drop-down, select Upgrade Settings.
  4. From the Upgrade Type drop-down, select the type of upgrade automation you want to use.
    • If you select Scheduled you will need to specify the upgrade schedule (Note: The upgrade schedule is based on the Monitoring Point time zone).
    • Start Date - The first day of the upgrade schedule.
    • Start Time - The start of the upgrade window.
    • Duration - The length of the upgrade window. Upgrades can only occur during the upgrade window.
    • Repeat - The period between the start of each upgrade window.
    • Skip next upgrade - Skip the next upgrade.
  5. Click Confirm. The Monitoring Point upgrade automation is set.
Manual upgrade

The upgrade process can be performed manually at any time to the Monitoring Point model no matter which of the upgrade automation settings is selected.

To upgrade Monitoring Point software to the latest release:

  1. Within APM, navigate to > Manage Monitoring Points.
  2. For the Monitoring Point you want to upgrade, select > Upgrade Now.
  3. Click OK.
    • The Monitoring Point software is upgraded to the latest release.

The Upgrade Now option is also available in the Action drop-down. Use this feature to upgrade multiple Monitoring Points at the same time.

Failed upgrade?

If an upgrade attempt fails, try the following:

  1. Retry the upgrade.
  2. Restart the v35 - VMware then retry the upgrade.
  3. Physically power the v35 - VMware off for 10 seconds then back on and retry the upgrade.
  4. Reflash the v35 - VMware using the latest image.

If you are still unsuccessful, contact AppNeta Support.

Reflash - local image

Reflashing the v35 - VMware (local image) involves rewriting the v35 - VMware file system with a software image stored on the v35 - VMware. All configuration information is saved during a reflash. This procedure is typically only required when troubleshooting a problem on the v35 - VMware.

Reflash using the Admin API

To reflash the v35 - VMware with the local image using the Admin API:

  1. Access the Admin API.
  2. Navigate to Appliance > PUT /appliance/reflash/.
  3. Click Try it out.
  4. Click Execute.
    • The Server response section should show Code “200” to confirm that the reflash instruction was received by the v35 - VMware.
    • The v35 - VMware reflashes with the locally stored image. Connectivity to the v35 - VMware is lost during the reflash procedure.

Decommission

Decommissioning the v35 - VMware resets its APM access configurations but does not affect its network configuration (for example, its hostname, IP address, and any static routes) or the software it is running.

After decommissioning, the v35 - VMware is not accessible on the network. Its status will show as disconnected. Any paths and monitoring data are not removed from your organization until you delete it.

To use the v35 - VMware again, you should follow the Migrating Monitoring Between EMPs procedure if you are replacing a failed v35 - VMware or the Getting Started procedure to set up the v35 - VMware as a new device within APM.

Decommission using Web Admin
  1. Log in to Web Admin.
  2. Click > Decommission.
  3. Click Confirm. The v35 - VMware restarts with a factory APM access configuration.
Decommission using the Admin API
  1. Access the Admin API.
  2. Navigate to Appliance > PUT /appliance/.
  3. Click Try it out.
  4. In the Parameters section, for the action parameter, select decommission.
  5. Click Execute.
    • The Server response section should show Code “202”.
    • The v35 - VMware restarts with a factory APM access configuration.

Reset to factory defaults - local image

Resetting to factory defaults using a local image resets both the network and APM access configurations and reflashes the Monitoring Point using a software image stored locally on the device.

After resetting to factory defaults, the Monitoring Point is not accessible on the network. Its status will show as disconnected.

To use the Monitoring Point again, you should follow the Migrating Monitoring Between EMPs procedure if you are replacing a failed Monitoring Point or the Getting Started procedure to set up the Monitoring Point as a new device within APM.

Reset using Web Admin

To reset the v35 - VMware to factory defaults and the local image using Web Admin:

  1. Log in to Web Admin.
  2. Click > Reset to Factory Defaults.
  3. Click Confirm. The v35 - VMware restarts using the local system image and factory configurations. Access to the v35 - VMware is lost.
Reset using the Admin API

To reset the v35 - VMware to factory defaults and the local image using the Admin API:

  1. Access the Admin API.
  2. Navigate to Appliance > PUT /appliance/reflash/.
  3. Click Try it out.
  4. In the body field, change the “reset” property from “false” to “true”.
  5. Click Execute.
    • The Server response section should show Code “200”.
    • The v35 - VMware restarts using the local system image and factory configurations. Access to the v35 - VMware is lost.

Reset using the reset button

Unidentified Monitoring Point: v35-vmware

Migrate monitoring

See Migrate Monitoring between Monitoring Points.

Share

See Sharing a Monitoring Point.

Move between orgs

You can move the v35 - VMware from one organization to another but any paths and monitoring history associated with it are not moved. These can, however, be moved to another Monitoring Point in the old organization. You need to be an Organization Admin or Advanced user in the old and new organizations in order to move the v35 - VMware between them.

To move the v35 - VMware between organizations:

Step 1: Download the nis.config file for the new organization

The nis.config file is used to associate a Monitoring Point with an organization. It is normally configured as part of a Monitoring Point setup but it can be obtained independent of the setup procedure in order to associate a Monitoring Point with a different organization.

To download the nis.config file for the new organization:

  1. Change organization to the new organization.
  2. Navigate to > Manage Monitoring Points > Add Monitoring Points > AppNeta hardware > Direct Connect.
  3. Click Download File.
    • The nis.config file is downloaded to your computer.
Step 2: Update with the new nis.config settings
Update using Web Admin
  1. Change organization to the old organization.
  2. Log in to Web Admin on the v35 - VMware.
  3. Decommission the v35 - VMware.
    • The v35 - VMware will take a while to restart.
    • When the v35 - VMware is decommissioned you can no longer access it via APM. You need to use it’s hostname or IP address to access it.
  4. Log in to Web Admin on the v35 - VMware using its hostname or IP address.
  5. Navigate to Monitoring Point Settings > APM Connection.
  6. Open the downloaded “<org-name>_nis.config” file in a text editor.
  7. Update the settings on the Connect to APM page to match those in the nis.config file.
  8. Click Submit.
    • The nis.config settings on the v35 - VMware are updated and the v35 - VMware connects to APM under the new organization.
Update using Admin API
  1. Rename the downloaded file to “nis.config” (i.e., remove “<org-name>_” from the filename).
  2. In APM, Change organization to the old organization.
  3. Decommission the v35 - VMware.
    • The v35 - VMware will take a while to restart.
    • When the v35 - VMware is decommissioned you can no longer access it via APM. You need to use it’s hostname or IP address to access it.
  4. Log in to Web Admin on the v35 - VMware using its hostname or IP address.
  5. Access the Admin API on the v35 - VMware.
  6. Navigate to NIS confirguration > POST /nis/file/.
  7. Click Try it out.
  8. In the Parameters section, in the nis_config_file parameter, click Choose File and select the “nis.config” file.
  9. Click Execute.
    • The Server response section should show Code “200”.
    • The nis.config settings on the v35 - VMware are updated and the v35 - VMware connects to APM under the new organization.
Step 3: Finalize the move to the new organization

When a new Monitoring Point initially connects to an organization in APM it needs to be licensed and have its location specified. At that point it is available in the new organization and new paths can be created or existing paths can be moved to it.

To finalize the v35 - VMware’s move to a new organization:

  1. In APM, change organization to the new organization.
  2. If prompted, specify the v35 - VMware licensing. Otherwise, assign a base license and any add-on licenses required.
  3. If prompted, specify the v35 - VMware location. Otherwise, set the location directly.
Step 4: Clean up the old organization

Moving a Monitoring Point to a new organization does not remove it from the old organization. From the perspective of the old organization, the Monitoring Point is simply disconnected. All paths and monitoring history are still available in the old organization.

To clean up the v35 - VMware from the old organization:

  1. Change organization to the old organization.
  2. If you want to preserve the paths and the associated monitoring history:
    1. Migrate old paths to another Monitoring Point.
  3. Once there are no more paths associated with the v35 - VMware (or you don’t care if they are deleted), delete the Monitoring Point from the old organization.