Virtual Monitoring Point - KVM

The AppNeta v35 - KVM Enterprise Monitoring Point is software that can be downloaded and run as a virtual machine on a KVM 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 - KVM is used.

Port # Preconfigured? Required or Optional Supported speeds Port type Used for
eth0 Yes Required 1Gbps or 10Gbps Primary network connection port Connectivity to APM
Delivery monitoring
Experience monitoring
eth1 Yes Optional 1Gbps Primary Usage monitoring port
(Out-of-band)
Usage monitoring
eth2 Physical interface
can be added
Optional 1Gbps or 10Gbps Secondary network connection port Connectivity to APM
Delivery monitoring
Experience monitoring
eth3 Physical interface
can be added
Optional 1Gbps or 10Gbps Secondary network connection port Connectivity to APM
Delivery monitoring
Experience monitoring

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 KVM
CPU 2 cores
RAM 4 GB
Storage 16 GB
File system ext4
Network interfaces 1 virtio_net interface
Host kernel drivers virtio_net
virtio scsi
virtio balloon
kvm-clock

Setup

Monitoring Point setup

Use the following steps to install a v35 virtual Monitoring Point in your network. The Monitoring Point runs on a host machine that has the KVM hypervisor installed. KVM runs on one of the following Linux versions: CentOS-7.x, RHEL 7.x or Ubuntu 16.04.3 LTS.

Once KVM is available and the necessary software and configuration information has been downloaded to the KVM host, the VM can be created and configured to connect to APM. After making the physical connection between the KVM host and your network the v35 will connect back to APM and can be used for monitoring. Once the setup is completed, additional features can be set up as required.

Prerequisites

The following are the minimum requirements for the KVM host system:

  • Capable of running a guest virtual machine with at least the v35 requirements.
  • Runs CentOS-7.x, RHEL 7.x or Ubuntu 16.04.3 LTS.
  • Has the following virtualization management packages installed:
    • CentOS-7.x, RHEL 7.x - qemu-kvm qemu-img libvirt libvirt-python libvirt-client virt-install bridge-utils
    • Ubuntu 16.04.3 LTS - qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils virtinst
  • Has up to four Ethernet NICs installed on the KVM host.
  • For 1Gbps: A Linux bridge or an OVS bridge to bind the interface on the v35 to the physical interface on the host.
    • The OVS bridge is required only if you want to use a VLAN. If this is the case, Open vSwitch (OVS) software must be installed. Open a support ticket for any assistance.
  • For 10 Gbps: A 10Gbps NIC with SR-IOV support. Supported 10Gbps NICs include:
    • Intel X540
    • Intel X550
    • Intel 82599

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

Set up a KVM host

If you have not already done so, set up either a CentOS, a RHEL, or an Ubuntu KVM host.

Set up a CentOS or RHEL KVM host

To set up a CentOS-7.x or RHEL 7.x KVM host:

  1. Install CentOS-7.x or RHEL 7.x.
  2. Install the required packages:

    sudo yum -y install qemu-kvm qemu-img libvirt libvirt-python libvirt-client virt-install bridge-utils
    
  3. Reboot.
  4. Verify the installation to see that all is okay and no guests are running at this point:

    virsh list --all
    
Set up an Ubuntu KVM host

To set up an Ubuntu 16.04.3 LTS KVM host:

  1. Install Ubuntu 16.04.3 LTS.
  2. Install the required packages:

    sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils virtinst
    
  3. Verify the installation to see that all is okay and no guests are running at this point:

    virsh list --all
    

Load install scripts

There are two scripts used for v35 setup that must be downloaded and copied to the KVM host:

  • vk35tool.py - Script to create a v35 and configure its interfaces.
  • vk35hook.sh - Hook script to automatically connect a mirror port to an OVS bridge.

To download and copy the script files:

  1. Click this link to download the .tar file containing the scripts.
  2. Copy the .tar file to the KVM host.
    • Copy it to the directory you want to run the vk35tool.py script from.
  3. Unzip the .tar file:

    tar xvzf vk35-tools.tar.gz
    
  4. Make a directory for the vk35hook.sh script:

    mkdir -p /var/lib/appneta/
    
  5. Copy the vk35hook.sh script to the directory:

    cp vk35hook.sh /var/lib/appneta/
    

Load base and config images

The AppNeta software required for the v35 includes a base image (.qcow2) and a config image (.iso). These must be downloaded and then copied to the KVM host.

To download the base and config images and copy them to your host:

  1. Log in to APM.
  2. Make sure you are using the correct organization
  3. Navigate to > Manage Monitoring Points > Add Monitoring Points > KVM
  4. Click Download KVM Base Image.
    • The KVM base image (.qcow2) is downloaded to your computer.
  5. Click Continue.
  6. Follow the instructions provided to specify the v35 configuration.
    • Note the Hostname as it will be used later.
    • A .zip file containing the config image (.iso) is downloaded to your computer.
  7. Copy the KVM base image (.qcow2) and the config image (.iso) to /var/lib/libvirt/images/ on the host system.
    • It is good practice to rename these files to match the Hostanme but leave the .qcow2 and .iso extensions. This is especially important if you are setting up more than one v35 on the KVM host as the .qcow2 and .iso files cannot be shared by virtual machines.

Create a v35 virtual machine

Once the software and configuration files are available on the host, the v35 virtual machine that uses them can be created.

You can create a v35 that uses a 1Gbps NIC or a 10Gbps NIC for connectivity to APM as well as Delivery and Experience monitoring.

Create a v35 with 1Gbps

eth0 on the v35 is mapped to the Linux bridge interface on the KVM host you will be using for network connectivity as well as Delivery and Experience monitoring. By default, the v35 is created with 4096MB RAM and two virtual CPUs.

You’ll need the following information to complete the setup:

Parameter Description
<v35_name> v35 virtual machine name. For simplicity, use the Hostname noted in a previous step.
<base_image> Name of the downloaded base image (e.g., <Hostname>.qcow2).
<config_image> Name of the downloaded config image containing initial Monitoring Point configuration (e.g., <Hostname>.iso).
<interface_type> Interface type on the KVM host (determined below).
<interface_name> Interface on the KVM host (determined below).

To create the v35:

  1. Log on to the KVM host.
  2. Go to the directory you copied the install scripts (vk35tool.py and vk35hook.sh) to.
  3. Determine which interfaces are available to the v35.

    ./vk35tool.py scan
    
  4. Install the v35.

    ./vk35tool.py install <v35_name> \
    --image /var/lib/libvirt/images/<base_image> \
    --config /var/lib/libvirt/images/<config_image> \
    --eth0 type=<interface_type>,source=<interface_name>
    
  5. Verify that the v35 is “running”.

    virsh list --all
    
Connect to the network via 1Gbps

To physically connect the Monitoring Point to the network via 1Gbps:

  1. Verify that the switch you’ll be connecting to has its default port speed and duplex set to auto-negotiate.
  2. Using a standard Ethernet cable, connect the physical interface on the KVM host associated with the bridge port configured above to the switch.
Create a v35 with 10Gbps

Note: This procedure should be completed by a system administrator with good knowledge of hypervisor management and tuning. To configure the system for optimal performance, they should also understand the CPU architecture of the KVM host. Those without this expertise should contact AppNeta Support for help.

There are a few steps required in order to set up the v35 to use a 10Gbps interface.

Configure host for virtual functions support

To configure the KVM host for virtual functions support:

  1. Edit /etc/modprobe.d/ixgbe.conf on the KVM host.
  2. Add the following lines:

    options ixgbe max_vfs=8
    blacklist ixgbevf
    
Isolate CPU cores and configure host for SR-IOV support

You can improve performance by running the v35 on at least two dedicated CPU cores. The following points should be used to determine which CPU cores on the KVM host to isolate for use with the v35:

  • If you have a multi-socket (NUMA) system:
    • The isolated cores should be on the same node so they access the same local memory.
    • Use cores on the node that is connected to the PCI slot containing the 10Gbps NIC.
  • If you have a hyper-threaded system (where a single physical processor core can act like two logical cores), make sure the isolated cores are not logical cores on the same physical core.

To configure the KVM host to isolate CPU cores and for SR-IOV support:

  1. Edit /etc/default/grub.
  2. Locate the line containing GRUB_CMDLINE_LINUX.
  3. Specify isolated CPU cores by adding isolcpus=<cpus> and nohz_full=<cpus> to it.
    • For example, “GRUB_CMDLINE_LINUX … isolcpus=4-6,8-10 nohz_full=4-6,8-10 …” isolates cores 4, 5, 6, 8, 9, and 10.
  4. Configure for SR-IOV support by adding intel_iommu=on (or amd_iommu=on if the KVM host has an AMD processor) to it.
    • For example, “GRUB_CMDLINE_LINUX … intel_iommu=on …”.
  5. Regenerate the grub.cfg file and rebuild initramfs.
    • For CentOS or RHEL, use:

       sudo grub2-mkconfig -o /boot/grub2/grub.cfg
       sudo dracut --regenerate-all -f
      
    • For Ubuntu, use:

       sudo update-grub
       sudo update-initramfs -k all -u
      
Apply changes and verify them

To apply the changes made in the previous steps and verify them:

  1. Reboot the KVM host to apply the changes.
  2. Verify that virtual functions (vf) have been created.

    ip link show
    
  3. Verify that CPU cores are isolated and that SR-IOV support is configured.

    cat /proc/cmdline
    
    • Look for isolcpus=<cpus> and nohz_full=<cpus>.
    • Look for intel_iommu=on (or amd_iommu=on).
Create a virtual function network

Once the KVM host is configured with virtual function (vf) support and SR-IOV you can create a virtual function network for the v35 to use. In this example we create enp5s0f1-vf based on interface enp5s0f1.

To create a virtual function network:

  1. Create an .xml network definition file. For example:

    $ cat enp5s0f1-vf.xml
    <network>
      <name>enp5s0f1-vf</name>
      <forward mode='hostdev' managed='yes'>
        <pf dev='enp5s0f1'/>
      </forward>
    </network>
    
  2. Define the network.

     virsh net-define enp5s0f1-vf.xml
    
  3. Start the network.

     virsh net-start enp5s0f1-vf
    
  4. Configure the network to start each time the system is started.

     virsh net-autostart enp5s0f1-vf
    
Create v35 using 10Gbps interface

eth0 on the v35 is mapped to the 10Gbps interface on the KVM host you will be using for network connectivity as well as Delivery and Experience monitoring. By default, the v35 is created with 4096MB RAM and two virtual CPUs.

This procedure assumes that a 10Gbps NIC is already installed in the KVM host and that the previous steps have been completed.

You’ll need the following information to complete the setup:

Parameter Description
<v35_name> v35 virtual machine name.
<base_image> Name of the downloaded base image (e.g., <Hostname>.qcow2).
<config_image> Name of the downloaded config image containing initial Monitoring Point configuration (e.g., <Hostname>.iso).
<10g_interface_name> The name of a 10Gbps Virtual Function (-vf) network on the KVM host (e.g., enp5s0f1-vf).
<cpus> The list of isolated CPU cores (e.g., 4-6,8-10).

To create the v35:

  1. Log on to the KVM host.
  2. Go to the directory you copied the install scripts (vk35tool.py and vk35hook.sh) to.
  3. Find the name of the 10Gbps interface you want to use (e.g., enp5s0f1-vf).

    ./vk35tool.py scan
    
  4. Install the v35.

    ./vk35tool.py install <v35_name> \
    --image /var/lib/libvirt/images/<base_image> \
    --config /var/lib/libvirt/images/<config_image> \
    --eth0 type=network,source=<10g_interface_name> \
    --cpuset <cpus>
    
  5. Verify that the v35 is “running”.

    virsh list --all
    
Connect to the network via 10Gbps

To physically connect the Monitoring Point to the network via 10Gbps:

  1. Verify that the switch you’ll be connecting to is 10Gbps capable has its default port speed and duplex set to auto-negotiate.
  2. Using the appropriate cable, connect the 10Gbps port to the switch.

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 - KVM 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 - KVM to show up in the list (you may need to refresh your screen).
    • The v35 - KVM’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 - KVM.
  5. In the Organization drop-down, select the child organization containing the v35 - KVM.
  6. Click the APM Monitoring Points tab in the bottom table.
  7. For the v35 - KVM 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 - KVM 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 - KVM. 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 - KVM:

  1. Navigate to > Manage Licenses.
  2. In the Parent Organization drop-down, select the parent organization containing the v35 - KVM.
  3. In the Organization drop-down, select the child organization containing the v35 - KVM.
  4. Click the APM Monitoring Points tab in the bottom table.
  5. For the v35 - KVM 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 - KVM to APM, you need to specify its location. This setting provides essential geographical context for the data that the v35 - KVM 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 - KVM you want to edit, select > Edit Location.
  3. Specify the location of the v35 - KVM.
  4. Click OK.
    • The location is set.

Optional - Cable for Usage monitoring

In order to use Usage monitoring, the v35 - KVM must be cabled for it.

Cabling for Usage monitoring - out-of-band

Out-of-band Usage monitoring requires that your switch is capable of port mirroring and that a mirror source and a mirror destination (also known as Switched Port Analyzer (SPAN) ports) have been configured. The switch’s mirror source port is the one being monitored (typically the aggregation point). The switch’s mirror destination port is connected to a Usage monitoring port (Out-of-band) on the Monitoring Point.

  • On the v35 - KVM, the Usage monitoring port (Out-of-band) is Port eth1.

Diagram showing an AppNeta Monitoring Point connected to the Mirror destination port of a switch via the Usage Monitoring port (Out-of-band).

Change default password

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

Set up monitoring

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

Configure additional features if required

Once the basic v35 is set up and is connecting back to APM, you can install additional features as required.

Set up v35 with additional interfaces

In addition to eth0, you can configure up to two additional interfaces for Delivery and Experience monitoring (eth2 and/or eth3). This procedure assumes that the v35 is already set up and running.

You’ll need the following information to complete the setup:

Parameter Description
<v35_name> v35 virtual machine name.
<v35_interface> v35 interface to use (either eth2 or eth3).
<interface_type> Interface type on the KVM host (determined below).
<interface_name> Interface on the KVM host (determined below).

To update the v35 to use an additional interface:

  1. Determine which interfaces are available to the v35.

    ./vk35tool.py scan
    
  2. Shutdown the v35.

    virsh shutdown <v35_name>
    
  3. Update the v35 configuration to use an additional interface.

    ./vk35tool.py update <v35_name> \
    --<v35_interface> type=<interface_type>,source=<interface_name>
    
  4. Start the v35.

    virsh start <v35_name>
    
  5. Verify that the v35 is “running”.

    virsh list --all
    
  6. To verify that the v35 is connected to APM, in APM, navigate to > Manage Monitoring Points.
  7. Wait a couple minutes for the new Monitoring Point to show up in the list (you may need to refresh your screen).
    • The Monitoring Point status should show “Connection Established” (Green circle with white check mark). At this point it is ready to monitor traffic.
    • If it doesn’t appear after a few minutes, you’ll need to troubleshoot the problem.
Set up v35 for Usage monitoring

This procedure assumes that the v35 is already set up and running and that Open vSwitch (OVS) software is installed on your KVM host and an OVS bridge has been created. You’ll need the following information to complete the setup:

Parameter Description
<v35_name> v35 virtual machine name.
<ovs_net_span> Virtual network based on the OVS bridge configured for mirroring traffic
<hostport> Port on host to be mirrored

There are a few steps required in order to set up the v35 for Usage monitoring.

Configure the v35 for Usage monitoring

To update the v35 configuration for Usage monitoring:

  1. Shutdown the v35.

    virsh shutdown <v35_name>
    
  2. Update the v35 configuration for Usage monitoring. Map eth1 to the OVS port configured for capturing mirrored traffic. Mirror traffic from the specified host port.

    ./vk35tool.py update <v35_name> \
    --eth1 type=network,source=<ovs_net_span>, \
    portgroup=<hostport>
    
  3. Start the v35.

    virsh start <v35_name>
    
  4. Verify that the v35 is “running”.

    virsh list --all
    
  5. To verify that the v35 is connected to APM, in APM, navigate to > Manage Monitoring Points.
  6. Wait for the new Monitoring Point to show up in the list (you may need to refresh your screen).
    • The Monitoring Point 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.
Connect to a mirror port

If you have not already done so, see Deployment Best Practices for information on where to deploy your Monitoring Point in you network for Usage monitoring.

To connect the v35 to a mirror port:

  1. Using a standard Ethernet cable, connect the OVS source port on the KVM host configured for capturing mirrored traffic to the port on your switch configured to mirror uplink traffic.
Set up the vk35hook.sh script

The vk35hook.sh script maps the physical port that is capturing mirrored traffic to the OVS bridge (which is mapped to eth1 on the v35). On some systems, whenever the v35 is shut down this mapping is removed, so the vk35hook.sh script needs to be run whenever the v35 is started to reset this mapping.

To have the vk35hook.sh script run automatically when the v35 is started:

  1. With the v35 running, run vk35tool.py (as superuser) using the “genhook” parameter:

    sudo ./vk35tool.py genhook <v35_name>
    
Set up v35 with VLAN

This procedure assumes that the v35 is already set up and running and that Open vSwitch (OVS) software is installed on your KVM host and an OVS bridge has been created. You’ll need the following information to complete the setup:

Parameter Description
<v35_name> v35 virtual machine name.
<v35_interface> v35 interface to use (either eth0, eth2, or eth3).
<ovs_net_lan> Virtual network based on the OVS bridge configured to forward VLAN traffic.
<vlan_portgroup> Port group that defines a set of tagged and untagged VLANs the traffic is received from.

To update the v35 to use VLAN:

  1. Shutdown the v35.

    virsh shutdown <v35_name>
    
  2. Update the v35 configuration to use VLAN.

    ./vk35tool.py update <v35_name> \
    --<v35_interface> type=network,source=<ovs_net_lan>, \
    portgroup=<vlan_portgroup>
    
  3. Start the v35.

    virsh start <v35_name>
    
  4. Verify that the v35 is “running”.

    virsh list --all
    
  5. To verify that the v35 is connected to APM, in APM, navigate to > Manage Monitoring Points.
  6. Wait a couple minutes for the new Monitoring Point to show up in the list (you may need to refresh your screen).
    • The Monitoring Point status should show “Connection Established” (Green circle with white check mark). At this point it is ready to monitor VLAN traffic.
    • If it doesn’t appear after a few minutes, you’ll need to troubleshoot the problem.
Set up v35 with additional 10Gbps

10Gbps support is only available for network connectivity (access to APM), Delivery monitoring, and Experience monitoring. It is not available for Usage monitoring. This procedure assumes that a v35 is already set up and running and that it has been configured for 10Gbps network connectivity. It also assumes that you are planning to add a second 10Gbps port for Delivery or Experience monitoring and that the 10Gbps NIC for this is already installed.

There are a few steps required in order to set up an additional 10Gbps interface.

Create an additional virtual function network

This procedure assumes that virtual functions support and SR-IOV support have been configured on the KVM host. This allows you to create a virtual function network for the v35 to use. In this example we create enp5s0f2-vf based on interface enp5s0f2.

To create a virtual function network:

  1. Create an .xml network definition file. For example:

    $ cat enp5s0f2-vf.xml
    <network>
      <name>enp5s0f2-vf</name>
      <forward mode='hostdev' managed='yes'>
        <pf dev='enp5s0f2'/>
      </forward>
    </network>
    
  2. Define the network.

     virsh net-define enp5s0f2-vf.xml
    
  3. Start the network.

     virsh net-start enp5s0f2-vf
    
  4. Configure the network to start each time the system is started.

     virsh net-autostart enp5s0f2-vf
    
Configure v35 to use 10Gbps interface

You’ll need the following information to complete the setup:

Parameter Description
<v35_name> v35 virtual machine name.
<v35_interface> v35 interface to use (either eth2 or eth3).
<10g_interface_name> The name of a 10Gbps Virtual Function (-vf) network on the KVM host (e.g., enp5s0f2-vf).

To update the v35 configuration for 10Gbps:

  1. Find the name of the 10Gbps interface you want to use (e.g., enp5s0f2-vf).

    ./vk35tool.py scan
    
  2. Shutdown the v35.

    virsh shutdown <v35_name>
    
  3. Update the v35 configuration for 10Gbps support. Map an interface on the v35 to the 10Gbps interface on the KVM host.

    ./vk35tool.py update <v35_name> \
    --<v35_interface> type=network,source=<10g_interface_name>
    
  4. Start the v35.

    virsh start <v35_name>
    
  5. Verify that the v35 is “running”.

    virsh list --all
    
Connect to the network via additional 10Gbps port

To physically connect the Monitoring Point to the network via 10Gbps:

  1. Verify that the switch you’ll be connecting to is 10Gbps capable has its default port speed and duplex set to auto-negotiate.
  2. Using the appropriate cable, connect the 10Gbps port to the switch.
  3. To verify that the v35 is connected to APM, in APM, navigate to > Manage Monitoring Points.
  4. Wait for the Monitoring Point to show up in the list (you may need to refresh your screen).
    • The Monitoring Point 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.
Set up v35 with 10Gbps and VLAN

This procedure assumes that the v35 is already set up and running and that it has been configured for 10Gbps.

You’ll need the following information to complete the setup:

Parameter Description
<v35_name> v35 virtual machine name.
<v35_interface> v35 interface to use (either eth0, eth2, or eth3).
<10g_interface_name> The name of a 10Gbps Virtual Function (-vf) interface on the KVM host (e.g., enp5s0f1-vf).
<vlan_id> VLAN ID to use.

To update the v35 configuration to use VLAN:

  1. Shutdown the v35.

    virsh shutdown <v35_name>
    
  2. Update the v35 configuration to specify the VLAN to use on the 10Gbps interface.

    ./vk35tool.py update <v35_name> \
    --<v35_interface> type=network,source=<10g_interface_name>,vlan=<vlan_id>
    
  3. Start the v35.

    virsh start <v35_name>
    
  4. Verify that the v35 is “running”.

    virsh list --all
    
  5. To verify that the v35 is connected to APM, in APM, navigate to > Manage Monitoring Points.
  6. Wait for the new Monitoring Point to show up in the list (you may need to refresh your screen).
    • The Monitoring Point status should show “Connection Established” (Green circle with white check mark). At this point it is ready to monitor VLAN traffic on the 10Gbps interface.
    • If it doesn’t appear after a few minutes, you’ll need to troubleshoot the problem.

Helpful commands

The following commands can be used on the host to manage your KVM virtual machines.

Command Description
virsh list –all List all virtual machines on your host.
virsh start <v35_name> Start a v35 instance that has been shut down.
virsh shutdown <v35_name> Shutdown a v35 instance (graceful).
virsh destroy <v35_name> Shutdown a v35 instance (force).
virsh undefine <v35_name> Delete a v35 instance.
virsh -h virsh help.

The following commands can be used to create and manage v35 virtual machines.

Command Description
vk35tool.py install <v35_name> Create a v35 VM.
vk35tool.py update <v35_name> Update a v35 VM configuration.
vk35tool.py show <v35_name> Show network interface on a v35 VM.
vk35tool.py scan List Linux interfaces available to a v35 VM.
vk35tool.py -h vk35tool help.

Troubleshooting connectivity to AppNeta

Your v35 - KVM 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 - KVM must be running. Check that the virtual machine is running.
The v35 - KVM 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 - KVM 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 - KVM 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 - KVM must be configured to connect through it. Check the proxy configuration on the v35 - KVM (via Web Admin).
  Verify that the proxy is reachable from the network the v35 - KVM 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 - KVM 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 - KVM 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 - KVM 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 - KVM across the internet.
    • the Host Networking Details section contains the active v35 - KVM interfaces and the local IP address of each. Use this if you are connecting to the v35 - KVM locally.

Access credentials

The v35 - KVM 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 - KVM credentials to log into Web Admin or use the Admin API.

The default credentials for the v35 - KVM are:

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

Changing Monitoring Point password

To secure Web Admin and Admin API access your v35 - KVM, 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 - KVM password you can reset it.

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

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 - KVM.
    • 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 - KVM 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 - KVM.
    • 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 - KVM.
    • If you are unable to login, see Can’t log in.

Can’t log in?

  1. Try using the default v35 - KVM 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 - KVM off then on.
  9. If you are still unable to login, open a support ticket.

Access via Admin API

The v35 - KVM 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 - KVM 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 - KVM.
    • <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 - KVM:

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 - KVM. Use it to manage and configure the v35 - KVM. For example, restart networking, add static IPs, and VLAN tags.
Admin API This is a web-based API interface hosted on the v35 - KVM. Use it to manage and configure the v35 - KVM.
curl The Admin API interface can generate custom curl commands that can be used to manage and configure the v35 - KVM from a command line.

Basic settings

There are a few settings that should be configured on the v35 - KVM 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 - KVM is initially configured and it can be seen in APM by navigating to > Manage Monitoring Points.

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

  • In conjunction with the v35 - KVM’s system time, it is required in order for the v35 - KVM 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 - KVM is located in.
  4. Click Submit.
    • The v35 - KVM’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 - KVM’s time zone is set accordingly.

Location

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

The v35 - KVM’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 - KVM’s APM name:

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

When you change the v35 - KVM’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 - KVM’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 - KVM.
    • The hostname and the APM name are changed.

Restricting Access

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

Access Control Lists (ACLs)

By default, all inbound access to a v35 - KVM is denied, with a few exceptions. These exceptions are in the form of Access Control Lists (ACLs). ACLs permit access to the v35 - KVM 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 - KVM 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 - KVM. The benefits include:

  • More convenient for administrators - Administrators login the v35 - KVM using their own desktop credentials. No new credentials to remember.
  • More secure - Administrators never need to be given local admin credentials to the v35 - KVM. No sharing of credentials.
  • Easy to control access - The network administrator can centrally control who can login to the v35 - KVM simply by adding them to (or removing them from) an authorization group.
  • Centralized password policy - Password policy (eg: password strength, rollover, lockout) for v35 - KVM access remains under the control of the network administrator and follows central corporate policy.
  • Better security forensics - The audit trail for v35 - KVM 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 - KVM (using local v35 - KVM admin credentials). Retains control over local admin credentials for the v35 - KVM.
  • Monitoring Point administrator - Logs into the v35 - KVM (using their own desktop credentials) and assumes administrator privileges to perform v35 - KVM administration.
  • Authorization group - Created by the network administrator. Only members of this group can log in to the v35 - KVM to perform administration tasks.
  • LDAP configuration - Settings supplied by the network administrator that tell the v35 - KVM to authenticate via LDAP, and where to find the server and authorization group.
How it works

For the v35 - KVM to make use of LDAP you need an LDAPv3 compliant server (directory server) that is accessible by the v35 - KVM and an authorization group on the server containing v35 - KVM administrators. The v35 - KVM 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 - KVM 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 - KVM 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 - KVM 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 - KVM.
  • 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 - KVM.

Note: LDAP setup on the v35 - KVM 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 - KVM using the Admin API.

LDAP configuration steps

Configuring the v35 - KVM 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 - KVM.
  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 - KVM should authenticate responses from the LDAP server, the server’s CA certificate must be available on the v35 - KVM. 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 - KVM.
  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 - KVM.
Configure LDAP

A convenient way to configure LDAP on the v35 - KVM 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 - KVM.
  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 - KVM’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 - KVM 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 - KVM (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 - KVM.
  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 - KVM’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 - KVM can be used.

  1. Access the Admin API on the v35 - KVM.
  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 - KVM’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 - KVM can be found using its Admin API.

  1. Access the Admin API on the v35 - KVM.
  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 - KVM but are unable to login as one of the administrative users defined on the LDAP server, check the following:

  • Make sure the v35 - KVM 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 - KVM 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 - KVM and the LDAP server is encrypted using TLS.
tls_reqcert
(Default value: “hard”)
Default config Authentication will fail if the v35 - KVM 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 - KVM admin credentials can be used for remote access. This setting restricts the local admin credentials for use only on the v35 - KVM 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 - KVM’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 - KVM’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 - KVM’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 - KVM’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 - KVM’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 - KVM’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 - KVM’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 - KVM 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 - KVM 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 - KVM.

Hostname

See APM Name and Hostname

Default interface

The default interface is the one the v35 - KVM 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 - KVM 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 - KVM 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 - KVM.
  • <hostname> - the hostname or IP address of the v35 - KVM.
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 - KVM 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 - KVM.
  • <hostname> - the hostname or IP address of the v35 - KVM.
  • <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 - KVM 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 - KVM 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 - KVM 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 - KVM 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 - KVM.
  • <hostname> - the hostname or IP address of the v35 - KVM.
  • <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 - KVM 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 - KVM 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 - KVM 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 - KVM.
  • <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 - KVM 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 - KVM.
  • <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 - KVM 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 - KVM.
  • <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 - KVM.
  • <interface_name> - the name of the interface you are configuring.
Legacy IPv6 support

If your v35 - KVM has software older than EMP 12.6.0, IPv6 is enabled and disabled globally on the v35 - KVM. 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 - KVM. IPv6 is enabled on the v35 - KVM.
Enable using curl
  1. Complete Monitoring Point setup setup.
  2. Discover your v35 - KVM 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 - KVM.
  • <hostname> - the hostname or IP address of the v35 - KVM.
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 - KVM. IPv6 is disabled on the v35 - KVM.
Disable using curl
  1. Discover your v35 - KVM 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 - KVM.
  • <hostname> - the hostname or IP address of the v35 - KVM.
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 - KVM 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 - KVM 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 - KVM interfaces.

When a network or web path is initiated from the v35 - KVM, 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 - KVM are used.

From the v35 - KVM’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 - KVM 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 - KVM 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 - KVM 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 KVM must be configured to connect to your proxy server so that it can communicate with APM.

The proxy settings on the v35 - KVM 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 - KVM.

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 - KVM’s Admin API.

View Usage interfaces

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

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

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

Web Server SSL key/certificate

The web server running on the v35 - KVM 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 - KVM 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 - KVM’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 - KVM’s read-only SNMP community string is provided when the v35 - KVM 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 - KVM will disrupt its connection to APM but it does not affect its software or its configuration.

Restart using Web Admin

To restart the v35 - KVM:

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

To restart the v35 - KVM:

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

Restart networking

Restarting networking on the v35 - KVM 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 - KVM:

  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 - KVM:

  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 - KVM:

  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 - KVM should be shut down gracefully if possible.

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

Delete

Deleting the v35 - KVM 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 - KVM has the following effects:

  • All paths where the v35 - KVM 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 - KVM is deleted.
  • Tests, assessments, and packet captures are not deleted.
  • The base license and any add-on licenses that were assigned to the v35 - KVM become available again.
  • Access to the v35 - KVM from APM is lost.
  • The v35 - KVM is decommissioned. This resets the APM connection configuration on the v35 - KVM.
  • In order to use the v35 - KVM again you need to redo the setup procedure.

    To delete the v35 - KVM from your organization:

  1. Navigate to > Manage Monitoring Points.
  2. For the v35 - KVM 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 - KVM:

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 - KVM 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 - KVM is no longer running the latest software version.

You can configure APM to upgrade the v35 - KVM 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 - KVM 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 - KVM:

  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 - KVM then retry the upgrade.
  3. Physically power the v35 - KVM off for 10 seconds then back on and retry the upgrade.
  4. Reflash the v35 - KVM using the latest image.

If you are still unsuccessful, contact AppNeta Support.

Reflash - local image

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

Reflash using the Admin API

To reflash the v35 - KVM 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 - KVM.
    • The v35 - KVM reflashes with the locally stored image. Connectivity to the v35 - KVM is lost during the reflash procedure.

Decommission

Decommissioning the v35 - KVM 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 - KVM 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 - KVM again, you should follow the Migrating Monitoring Between EMPs procedure if you are replacing a failed v35 - KVM or the Getting Started procedure to set up the v35 - KVM as a new device within APM.

Decommission using Web Admin
  1. Log in to Web Admin.
  2. Click > Decommission.
  3. Click Confirm. The v35 - KVM 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 - KVM 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 - KVM 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 - KVM restarts using the local system image and factory configurations. Access to the v35 - KVM is lost.
Reset using the Admin API

To reset the v35 - KVM 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 - KVM restarts using the local system image and factory configurations. Access to the v35 - KVM is lost.

Reset using the reset button

Unidentified Monitoring Point: v35-kvm

Migrate monitoring

See Migrate Monitoring between Monitoring Points.

Share

See Sharing a Monitoring Point.

Move between orgs

You can move the v35 - KVM 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 - KVM between them.

To move the v35 - KVM 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 - KVM.
  3. Decommission the v35 - KVM.
    • The v35 - KVM will take a while to restart.
    • When the v35 - KVM 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 - KVM 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 - KVM are updated and the v35 - KVM 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 - KVM.
    • The v35 - KVM will take a while to restart.
    • When the v35 - KVM 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 - KVM using its hostname or IP address.
  5. Access the Admin API on the v35 - KVM.
  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 - KVM are updated and the v35 - KVM 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 - KVM’s move to a new organization:

  1. In APM, change organization to the new organization.
  2. If prompted, specify the v35 - KVM licensing. Otherwise, assign a base license and any add-on licenses required.
  3. If prompted, specify the v35 - KVM 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 - KVM 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 - KVM (or you don’t care if they are deleted), delete the Monitoring Point from the old organization.