Installation Guide: Virtual Arbor Edge Defense

Virtual Arbor Edge Defense
Installation Guide
Version 6.3.1
Legal Notice
The information contained within this document is subject to change without notice. NETSCOUT SYSTEMS, INC.
makes no warranty of any kind with regard to this material, including, but not limited to, the implied warranties
of merchantability and fitness for a particular purpose. NETSCOUT SYSTEMS, INC. shall not be liable for errors
contained herein or for any direct or indirect, incidental, special, or consequential damages in connection with the
furnishings, performance, or use of this material.
Use of this product is subject to the End User License Agreement available at
http://www.NetScout.com/legal/terms-and-conditions or which accompanies the product at the time of
shipment or, if applicable, the legal agreement executed by and between NetScout Systems, Inc. or one of its
wholly-owned subsidiaries (“NETSCOUT”) and the purchaser of this product (“Agreement”).
Government Use and Notice of Restricted Rights: In U.S. government (“Government”) contracts or subcontracts,
Customer will provide that the Products and Documentation, including any technical data (collectively “Materials”),
sold or delivered pursuant to this Agreement for Government use are commercial as defined in Federal
Acquisition Regulation (“FAR”) 2.101and any supplement and further are provided with RESTRICTED RIGHTS. All
Materials were fully developed at private expense. Use, duplication, release, modification, transfer, or disclosure
(“Use”) of the Materials is restricted by the terms of this Agreement and further restricted in accordance with FAR
52.227-14 for civilian Government agency purposes and 252.227- 7015 of the Defense Federal Acquisition
Regulations Supplement (“DFARS”) for military Government agency purposes, or the similar acquisition
regulations of other applicable Government organizations, as applicable and amended. The Use of Materials is
restricted by the terms of this Agreement, and, in accordance with DFARS Section 227.7202 and FAR Section 12.212,
is further restricted in accordance with the terms of NETSCOUT’S commercial End User License Agreement. All
other Use is prohibited, except as described herein.
This Product may contain third-party technology. NETSCOUT may license such third-party technology and
documentation (“Third-Party Materials”) for use with the Product only. In the event the Product contains Third-
Party Materials, or in the event you have the option to use the Product in conjunction with Third-Party Materials
(as identified by NETSCOUT in the Documentation provided with this Product), then such third-party materials are
provided or accessible subject to the applicable third-party terms and conditions contained either in the “Read
Me” or “About” file located in the Software or on an Application CD provided with this Product, or in an appendix
located in the documentation provided with this Product. To the extent the Product includes Third-Party Materials
licensed to NETSCOUT by third parties, those third parties are third-party beneficiaries of, and may enforce, the
applicable provisions of such third-party terms and conditions.
Open-Source Software Acknowledgment: This product may incorporate open-source components that are
governed by the GNU General Public License (“GPL”) or licenses that are compatible with the GPL license (“GPL
Compatible License”). In accordance with the terms of the GNU GPL, NETSCOUT will make available a complete,
machine-readable copy of the source code components of this product covered by the GPL or applicable GPL
Compatible License, if any, upon receipt of a written request. Please identify the product and send a request to:
NetScout Systems, Inc.
GNU GPL Source Code Request
310 Littleton Road
Westford, MA 01886
Attn: Legal Department
No portion of this document may be copied, photocopied, reproduced, translated, or reduced to any electronic
medium or machine form without prior consent in writing from NETSCOUT. The information in this document is
subject to change without notice and does not represent a commitment on the part of NETSCOUT.
The products and specifications, configurations, and other technical information regarding the products described
or referenced in this document are subject to change without notice and NETSCOUT reserves the right, at its sole
discretion, to make changes at any time in its technical information, specifications, service, and support programs.
All statements, technical information, and recommendations contained in this document are believed to be
accurate and reliable but are presented “as is” without warranty of any kind, express or implied. You must take
full responsibility for their application of any products specified in this document. NETSCOUT makes no implied
warranties of merchantability or fitness for a purpose as a result of this document or the information described
or referenced within, and all other warranties, express or implied, are excluded.
Except where otherwise indicated, the information contained in this document represents the planned capabilities
and intended functionality offered by the product and version number identified on the front of this document.
Screen images depicted in this document are representative and intended to serve as example images only.
© 2019 NETSCOUT SYSTEMS, INC. All rights reserved. Proprietary and Confidential Information of NETSCOUT
SYSTEMS, INC.
Document Number: vAED-IG-631-2019/12
11 December, 2019
Contents
Preface
How to Use the Virtual Arbor Edge Defense Documentation 5
Contacting the Arbor Technical Assistance Center 6
Section 1: Introduction to vAED

About vAED 8
About the Layer 3 Deployment Mode 9
Configuring Static Routes for the Protection Interfaces on vAED 10
Accessing vAED 13
Section 2: Installing vAED on KVM

Preparing to Install vAED on KVM 16
Configuring Network Bridges on KVM 18
Installing vAED on KVM 20
Configuring vAED on KVM 22
Section 3: Installing vAED on VMware

Preparing to Install vAED on VMware 26
Configuration Requirements for the VMware Virtual Network 28
Installing vAED on VMware 30
Configuring vAED on VMware 32
Remapping VMware Virtual Networks 35
Section 4: Using Cloud-Init to Initialize vAED

Using Cloud-Init to Initialize vAED 38
Creating a User Data File for Cloud-Init 40
Configuring Cloud-Init modules in the User Data File 41
Creating a Password Hash for vAED 46
About the Default User Data File 47
Using Cloud-Init with an Orchestration Environment 48
Using Cloud-Init without an Orchestration Environment 49
Viewing the Cloud-Init Log 52
Section 5: Licensing vAED

About Cloud-Based Licensing for vAED 54
Configuring Cloud-Based Licenses for vAED 57
Viewing vAED License Information in the UI 60
Appendix A: vAED Performance Benchmarks

vAED Performance Benchmarks 64
Index 69
End User License Agreement 71
vAED Installation Guide, Version 6.3.1 3

vAED Installation Guide, Version 6.3.1
Preface
This guide explains how to configure and use NETSCOUT® Virtual Arbor Edge Defense
(vAED).
Audience
This guide is intended for enterprise security operators and engineers who are
responsible for securing the internet data center edge from threats against availability.
These operators and engineers should have fundamental knowledge of their network
security policies and network configuration.
In this section
This section contains the following topics:
How to Use the Virtual Arbor Edge Defense Documentation 5

Contacting the Arbor Technical Assistance Center 6
4 Proprietary and Confidential Information of NETSCOUT SYSTEMS, INC.

Preface
How to Use the Virtual Arbor Edge Defense

Documentation
Using this guide
This guide contains instructions and information about installing and configuring Virtual
Arbor Edge Defense (vAED).
Related publications
After you install vAED, see the following documentation for information about how to use
AED:
Reference documentation
Document Contents
AED Online Help Online help topics from the AED User Guide . The Help is context-
sensitive to the AED UI page from which it is accessed.
AED API Reference information plus a simple code sample that you can
Programmer Guide experiment with to learn the basics of the AED API quickly.
This guide is installed with AED. You can access it at the following
link:
https://IP_address/help/AED_PG_HTML5/AED_PG.htm
IP_address = the IP address of hostname for your AED
Online AED API Complete commented code for the AED API.
Documentation This guide is installed with AED. You can access it at the following
link:
https://IP_address/api/aed/doc/v1/endpoints.html
IP_address = the IP address or hostname for your AED
Proprietary and Confidential Information of NETSCOUT SYSTEMS, INC. 5

Contacting the Arbor Technical Assistance Center

The Arbor Technical Assistance Center is your primary point of contact for all service and
technical assistance issues that involve Arbor products.
Contact methods
You can contact the Arbor Technical Assistance Center as follows:
n Phone US toll free — +1 877 272 6721
n Phone worldwide — +1 781 362 4301

n Support portal — https://support.arbornetworks.com
Submitting documentation comments

If you have comments about the documentation, you can forward them to the Arbor
Technical Assistance Center. Please include the following information:
n Title of the guide
n Document number (listed on the reverse side of the title page)

n Page number
Example
vAED-IG-631-2019/12
vAED Installation Guide
Page 9

Section 1:
Introduction to vAED
This section describes vAED and its key features and licensing options. vAED is the version
of AED that runs on a hypervisor or in the cloud.
In this section
About vAED 8
About the Layer 3 Deployment Mode 9
Configuring Static Routes for the Protection Interfaces on vAED 10
Accessing vAED 13

About vAED
vAED is the virtual machine version of AED that runs on a hypervisor. vAED contains all of
the AED software packages and configurations, and provides you with a hardware-
independent resource. You only need to install the virtual machine and configure its
network settings.
Supported interfaces
vAED provides the following interfaces:
n 2 management interfaces: mgt0 and mgt1
n 2 protection interfaces: ext0 and int0
Unsupported features and functions

vAED does not support the following features and functions:
n NTP on VMware hypervisors
However, the vAED synchronizes its clock with the VMware hypervisor, which can have
NTP enabled.
Note
You can configure an NTP server for vAED on KVM hypervisors.
n Shell access
Licensing vAED
vAED uses cloud-based licenses, which you configure in the vAED UI. You need to
configure cloud-based licenses for each instance of vAED. See “About Cloud-Based
Licensing for vAED” on page 54.
If vAED does not have a valid license when it is set to layer 3 mode, then the system does
not pass traffic or process mitigations.
Accessing vAED
After the initial installation and configuration, you can access vAED through any supported
web browser.
For a list of the supported web browsers, see the Arbor Edge Defense Release Notes.

About the Layer 3 Deployment Mode

The deployment mode indicates how AED is installed on your network: inline or monitor.
On vAED, you also have the option to deploy in the layer 3 mode. In the layer 3 mode,
vAED forwards all of the traffic that meets the mitigation rules and has a route configured
for the destination network. See “Setting the Deployment Mode” in the AED User Guide .
In the UI, the inline deployment mode appears as Inline Bridged and the layer 3
deployment mode appears as Inline Routed.
Configuring routes
If you deploy vAED in the layer 3 mode, then you must configure routes for the protection
interfaces. See “Configuring Static Routes for the Protection Interfaces on vAED” on the
next page.
Changing the deployment mode from inline to layer 3

If you change the deployment mode from inline to layer 3, then vAED makes the following
changes:
n Removes any GRE tunneling settings, including routes, local IP addresses, remote IP
addresses, and the subnet mask length
n Disables link state propagation
Changing the deployment mode from layer 3 to inline

If you change the deployment mode from layer 3 to inline, then vAED makes the following
changes:
n Removes any routes that are configured for the protection interfaces
n Removes any IP addresses that are configured for the protection interfaces
n Removes any GRE tunneling settings, including local IP addresses, remote IP addresses,
and the subnet mask length
Backing up and restoring data while in the layer 3 deployment mode

If vAED is set to the layer 3 deployment mode, then the following data is not included in
any backup:
n Any GRE tunneling settings that are configured on the Interfaces page in the UI. See
“Configuring Interfaces and GRE Tunneling” in the AED User Guide .
n Any routes that are configured for the protection interfaces. These routes may include
mitigation routes that were configured from the CLI and routes that were configured in
the Routes section on the Interfaces page. See “About Configuring Routes” in the AED
User Guide .

Configuring Static Routes for the Protection Interfaces on

vAED
If you deploy vAED in the layer 3 mode, you can assign IP addresses to the protection
interfaces. Then you can create static routes to direct traffic through the vAED. These
routes, which are distinct from the routes for management traffic, define how vAED
handles passed traffic.
A route can be inbound or outbound. vAED routes traffic using the most specific valid
route that matches the destination address, through the protection interface that has the
same subnet as the nexthop.
You configure routes in the command line interface (CLI). See “Entering CLI Commands” in
the AED User Guide .
Note
You also can configure routes on the Interfaces page (Administration > Interfaces) in
the UI. See “Configuring Routes” in the AED User Guide .
Specifying an IP address for a protection interface on vAED

To specify an IP address for a protection interface:
1. Log in to the CLI with your administrator user name and password.
2. (Optional) To get a list of the protection interfaces on your appliance, enter /
services aed mitigation interface ?
3. Enter / services aed mitigation interface protectionInterface
network
protectionInterface = The protection interface to configure. For example: ext0 or
int0.
network = The IPv4 address and prefix length for the protection interface.
After you change the address for a protection interface, verify that any configured routes
are still valid. To verify the routes, enter / services aed mitigation route show. If
Unknown appears in the Interface column, you must reconfigure the route.
Important
If you configure GRE tunneling when vAED is set to the layer 3 mode, vAED uses the IP
address of the external interface as the GRE tunnel destination.
Adding a static route for a protection interface on vAED

Before you can add a route for a protection interface, you must set vAED to the layer 3
deployment mode.
For information about deployment modes, see “Setting the Deployment Mode” in the AED
User Guide .
When vAED is set to the layer 3 mode, you can configure routes on the protection
interfaces for inbound traffic and outbound traffic:
2. Enter / services aed mitigation route add network nexthop
network = The IPv4 address and prefix length for the destination network.

nexthop = The IPv4 address for the router through which the traffic is sent to the
destination network. For a nexthop to be valid, its IP address must match a subnet for
one of the protection interfaces.
3. Repeat the previous step for each route that you want to configure.
If you expect vAED to forward outbound traffic, you must configure routes for the
outbound traffic. we recommend that you configure a default route to 0.0.0.0/0 and a
nexthop to a gateway router on the subnet that is connected to the external interface. If
necessary, configure additional routes for the outbound traffic to other external nexthops.
If you do not configure routes for the outbound traffic, vAED will drop outbound traffic.
See “Configuring the Outbound Threat Filter” in the AED User Guide .
Deleting the IP address for a protection interface on vAED

To delete the IP address for a protection interface:
2. Enter / services aed mitigation interface protectionInterface delete
protectionInterface = The protection interface to delete. For example: ext0 or
int0.
If the IP address for the nexthop is not within any protection interface subnet, vAED
displays Unknown in the Interface column.
Important
If you delete the IP address for a protection interface, all routes that were configured to
go through that interface become invalid. However, vAED does not remove the invalid
routes. If vAED can reach a nexthop after you assign a new IP address and subnet to a
protection interface, then vAED reactivates the invalid route. This behavior is different
than the behavior for management routes.
Deleting the routes for protection interfaces on vAED

Caution
This command deletes the entire route, including the IP address for the nexthop.
To delete the routes for a protection interface:

2. Enter / services aed mitigation route delete network
network = (Optional) The IPv4 address and prefix length for the destination network.
If you do not specify a network, this command deletes all of the routes for all of the
protection interfaces.
Deleting all of the layer 3 interface settings on vAED

To delete all of the layer 3 interface settings for the protection interfaces, but leave any of
the routes that are configured:
2. Enter / services aed mitigation interface clear

Deleting all of the layer 3 interface settings and routes on vAED

To delete all of the layer 3 interface settings and all of the routes that are configured for the
protection interfaces:
2. Enter / services aed mitigation l3 clear
Caution
This command deletes all of the routes that are configured on vAED, including any
GRE routes that you may have configured in the UI. See “Configuring Routes” in the
AED User Guide .

Accessing vAED
After you install and configure vAED, you can access it through any supported web
browser.
For a list of the capabilities and limitations of vAED, see “About vAED” on page 8 .
Accessing the vAED

You can access vAED in the following ways:
n In a browser window, enter https://IP_address
n In a terminal window, enter ssh admin@IP_address

IP_address = the IP address of the management interface on vAED
For vAED installation instructions, see “Installing vAED on KVM” on page 20 and “Installing
vAED on VMware” on page 30.


Section 2:
Installing vAED on KVM
This section describes how to create and configure vAED on a Kernel-based Virtual
Machine (KVM).
In this section
Preparing to Install vAED on KVM 16

Configuring Network Bridges on KVM 18
Installing vAED on KVM 20
Configuring vAED on KVM 22

Preparing to Install vAED on KVM

Before you install vAED on a KVM hypervisor, the host server must meet the minimum
requirements for system resources. You also must install several software packages.
Minimum system resources

To run vAED, the host server must meet the following minimum requirements for system
resources:
n 2 or 4 physical cores
n 100 GB hard disk space

n 6 GB RAM
n 4 interfaces (4 x virtio)
With this minimum configuration, vAED can support up to 10 protection groups.
To increase the pps throughput rate and the number of supported protection groups,
install and configure vAED for a hypervisor with 4 CPUs and 12 GB RAM. With this
configuration, vAED can support up to 50 protection groups.
For information about changing these settings, see the KVM documentation.
Enabling hardware virtualization on your CPU

To run vAED on KVM, the host server on which you install the virtual machine must have a
processor that supports hardware virtualization. Intel and AMD have developed
extensions for their processors: Intel VT-x and AMD-V.
To determine if your processor supports one of these extensions, enter the following
command on your system command line:
egrep -c '(vmx|svm)' /proc/cpuinfo
If the command returns 0, your CPU does not support hardware virtualization. If the
command returns 1 or greater, your CPU supports hardware virtualization. In this case,
you must enable hardware virtualization in the host server’s BIOS.
Preparation process
Prepare to install and configure vAED on KVM as follows:
Preparing to install vAED

Step Action
1 Gather information to use when you configure vAED on KVM.

See “Configuration information to collect” on the facing page.
2 Ensure that the host server on which you install the virtual machine has a
processor that supports hardware virtualization. See “Enabling hardware
virtualization on your CPU” above.

Preparing to install vAED (continued)

Step Action
3 Install the following software, modules, and packages:

n a 64-bit Linux Kernel that supports KVM
(http://www.linux-kvm.org/page/Choose_the_right_kvm_%26_kernel_
version)
n qemu-kvm
n libvirt-bin
n virt-install command line tool
n bridge-utils
4 Ensure that the MTU on the hypervisor is configured properly. Consult your
hypervisor documentation for instructions.
5 Configure the network bridges on KVM.

See “Configuring Network Bridges on KVM” on the next page.
6 Download the vAED .qcow2 image file to a suitable location under the managed
storage pool on the host server. The default location is /var/lib/libvirt/images/.
7 (Optional) If you plan to use a data source to initialize vAED, create a user date
file. See “Creating a User Data File for Cloud-Init” on page 40.
Configuration information to collect

Collect the information that applies to your virtual network and document it on the
following worksheet. This information is required when you configure vAED.
Configuration information worksheet
Item Description Your setting

IP address and The IP address and netmask of the mgt0
netmask of the virtual management interface on the virtual machine.
machine We recommend that you allocate IP addresses
from the same subnet as the host.
Note
If you are using a DHCP server, the IP address for
mgt0 is assigned automatically.
Default router (or The IP address of the first router hop that sends
gateway) outbound network traffic. Typically, this is the
subnet switch or router.
Administrator user The credentials for administrative access to vAED. The default user name
name and password is admin and the default
password is arbor.

Configuring Network Bridges on KVM

To run vAED on KVM requires four network bridges. You use these network bridges to
map the interfaces on the host server to the virtual interfaces on KVM.
Configuring network bridges

This procedure provides an example of an interfaces file that you use to configure the
network bridges (vmbr0, vmbr1, vmbr2, vmbr3).
The network bridges use the eth0, eth1, eth2, and eth3 interfaces on the host server. You
map the network bridges to the vAED mgt0, mgt1, ext0, and int0 interfaces on KVM.
To configure an interface mapping file:

1. In a text editor on the Linux shell, edit the interfaces file as follows:
/etc/network/interfaces
# loopback
auto lo
iface lo inet loopback
# Specify 4 interfaces.
iface eth0 inet manual
# Configure bridge vmbr0, assign it a static address,

# and map it to interface eth0.
auto vmbr0
iface vmbr0 inet static
address Server_IP
netmask Netmask
bridge_ports eth0
bridge_stp off
bridge_fd 0
# Configure vmbr1 and map it to interface eth1.

auto vmbr1
iface vmbr1 inet manual
bridge_ports eth1
bridge_stp off
bridge_fd 0

auto vmbr2


bridge_ports eth2
bridge_stp off
bridge_fd 0
bridge_ageing 0

auto vmbr3
bridge_ports eth3
bridge_stp off
bridge_fd 0
bridge_ageing 0
2. To restart network services, enter one of the following commands:
l /etc/init.d/network restart
l sudo service network-manager restart
After you configure the network bridges, you can install vAED on KVM. See “Installing vAED
on KVM” on the next page.


After you have performed the pre-installation steps and verified that the minimum system
resource requirements are met, you can install vAED on KVM. To install vAED, you create a
virtual machine on a KVM hypervisor and then configure its settings.
You must perform the installation steps for each virtual machine that you want to create.
Note
To prepare to install vAED, see “Preparing to Install vAED on KVM” on page 16 .
After you complete the installation, you can configure vAED. See “Configuring vAED on
KVM” on page 22.

To install vAED on KVM, enter the following commands:
sudo virt-install --connect qemu:///system --name vmHostname --ram 6144
--cpu host --vcpus=2,sockets=1,cores=2,maxvcpus=2 --arch=x86_64 --
import --os-type linux --disk path=/var/lib/libvirt/images/Arbor-vAED-
#.#.#-xxxx.qcow2,device=disk,bus=virtio,size=100,format=qcow2 --network
bridge=vmbr0,model=virtio --network bridge=vmbr1,model=virtio --network
bridge=vmbr3,model=virtio --network bridge=vmbr4,model=virtio --vnc --
noautoconsole --channel unix,mode=bind,target_
type=virtio,name=org.qemu.guest_
agent.0,path=/var/lib/libvirt/qemu/channel/target/
vmHostname.org.qemu.guest_agent.0
#.#.# = the vAED version number
xxxx = the build number of the image file
Command Description
sudo virt-install --connect Starts the installer on the host server command line.
qemu:///system
--name vmHostname Specifies a hostname or a fully qualified domain

name (vmHostname). For example:
host.example.com.
--ram 6144 Allocates 6 GB of memory to the virtual machine.
--cpu host Exposes the host CPU configurations to the virtual

machine, to improve performance.
--vcpus=2,sockets=1,cores=2,maxvcpus=2 Indicates the number of virtual CPUs that are

allocated to the virtual machine.
--arch=x86_64 Indicates that the virtual machine uses a 64-bit

architecture.
--os-type linux Indicates the operating system type.
--import Indicates that you are using a disk image.

Command Description
--disk path=filepath/filename.qcow2, Specifies the path to and file name of the disk image
device=disk,bus=virtio,size=100,format and the size and bus type of the image.
=qcow2
--network bridge=vmbr0,model=virtio Assign the virtual bridges to the virtual machine and
--network bridge=vmbr1,model=virtio assign the virtual network.
--network bridge=vmbr2,model=virtio
--network bridge=vmbr3,model=virtio
--vnc --noautoconsole Allows virtual network computing (VNC) access to

the KVM console.
--channel unix,mode=bind,target_ (Optional) Connects the hypervisor to the QEMU

type=virtio,name=org.qemu.guest_ guest agent. The QEMU guest agent allows the
agent.0,path=/var/lib/libvirt/qemu/cha hypervisor to use a virtio serial console to
nnel/target/vmHostname.org.qemu.guest_ communicate with and issue commands to vAED.
agent.0 For examples of how to use the QEMU guest agent,
see the QEMU documentation at
https://wiki.qemu.org/index.php/Features/GuestA
gent#Example_usage
After the commands finish executing, you should see the following output, which indicates
that the virtual machine is running:
Domain creation completed. You can restart your domain by running:
virsh --connect qemu:///system start systemName

Configuring vAED on KVM

After you install vAED on a KVM hypervisor, you can configure the system settings.
For vAED installation instructions, see “Installing vAED on KVM” on page 20 .
Accessing the vAED command line interface

You configure vAED on the command line interface (CLI). You can access the CLI in one of
the following ways:
Access method Steps

SSH 1. SSH to the IP address that was assigned to mgt0 by your
DHCP server.
2. At the login prompt on the CLI, enter the default user name
of admin
3. At the Password prompt, enter the default password of
arbor
KVM virtual machine 1. To open the KVM console, enter the following command on
console the host server command line:
~# virsh - c qemu:///session
Note
For help with terminal commands, enter help. To close the
console, enter quit.
2. To connect to the vAED CLI, enter the following command:
virsh # consolehostname
hostname = the name of the vAED
Configuring vAED
To configure vAED, access the CLI on vAED. See “Accessing the vAED command line
interface” above.
In the CLI, enter the following commands. Press ENTER after each command.
Command Description
/ system name set hostname Enter the host name for the vAED as a simple host name
or a fully qualified domain name. For example:
host.example.com
/ service dns server add IP_address Enter the IP address for the DNS server.
/ ip interfaces ifconfig mgt1 IP_ (Optional) Enter an IP address and prefix for
address/prefix up management port mgt1. For example: 198.51.100.0/24 or
2001:DB8::/32

Command Description
/ services aaa local password admin To start the AED services, you must change the default
interactive administrator password. Enter this command to change
the password and then follow these steps:
1. Enter the new password.
2. Re-enter the new password.
/ services aed mode set deployment_ (Optional) To change the deployment mode of vAED
mode from the default mode (monitor), enter inline or L3.
For a description of the deployment modes, see “About
the Deployment Modes” in the AED User Guide .
/ ip access add service mgt0 IP_ (Optional) Enter this command to create an IP access
address/prefix rule for a service. Specify the name of a valid service and
the IP address and prefix for the hosts that are allowed
to communicate with the service. For example:
/ ip access add snmp mgt0 198.51.100.0/24
Valid services are as follows:
n http
n https
n ping
n ssh
n cloudsignal
n snmp
For information about the preconfigured IP access rules

for services, see “Modifying the preconfigured IP access
rules” on the next page.
/ ip access delete service all IP_ (Optional) Enter this command to delete an IP access
address/prefix rule for a service. Specify the name of the service and the
IP address and prefix of the hosts that were allowed to
communicate with the service.
For example, the following command deletes the default
IP access rule for the http service on all management
interfaces: / ip access delete http all
0.0.0.0/0
/ services ssh key generate Configure the SSH host keys in one of the following ways:
/ services ssh key host set n To have AED generate the SSH host key files, enter /
disk:fileName services ssh key generate
n To import a file that contains the SSH host keys, enter
/ services ssh key host set disk:fileName
fileName = the name of the file that contains the
SSH host keys
/ ip access commit Commit the IP access rule settings.
/ config write Save the configuration changes.
/ exit Log out of the CLI, and then close the hypervisor,
console, or SSH window.

After you complete the installation and configuration, you can access vAED at any time. See
“Accessing vAED” on page 13.
Modifying the preconfigured IP access rules

When you install vAED, IP access rules are configured for the following services:
n http
n https
n ping
n ssh
These IP access rules do not restrict access to the services (that is, they are configured for
0.0.0.0/0). To restrict access, first add a new IP access rule that specifies an IP address
range for the service, and then delete the existing access rule.

Section 3:
Installing vAED on VMware
This section describes how to create and configure vAED on VMware.
In this section
Preparing to Install vAED on VMware 26

Configuration Requirements for the VMware Virtual Network 28
Installing vAED on VMware 30
Configuring vAED on VMware 32
Remapping VMware Virtual Networks 35

Preparing to Install vAED on VMware

Before you install vAED on a VMware hypervisor, the host server must meet the minimum
requirements for system resources. You also must install several software packages.
Minimum system resources

To run vAED, the host server must meet the following minimum requirements for system
resources:
n 2 or 4 physical cores
n 100 GB hard disk space

n 6 GB RAM
With this minimum configuration, vAED can support up to 10 protection groups.
To increase the pps throughput rate and the number of supported protection groups,
install and configure vAED for a hypervisor with 4 CPUs and 12 GB RAM. With this
configuration, vAED can support up to 50 protection groups.
Note
By default, the vAED OVA for VMware is configured for a hypervisor with 2 CPUs and 6 GB
RAM. You can change the configuration as follows:
1. Deploy the OVA file that Arbor provides.
2. Change the CPU and RAM settings. For information about changing these settings, see
the VMware documentation.
3. Save the modified OVA file with a different file name.
Preparation process
Prepare to install and configure vAED on VMware as follows:
Preparing to install vAED

Step Action
1 Gather the information to use when you configure vAED.

See “Configuration information to collect” on the facing page.
2 Install VMware vSphere Hypervisor software, version 5.5. or later, on a

supported server, which is referred to as the VMware server. For more
information, see http://www.vmware.com/products/vsphere-hypervisor.
3 Ensure that the MTU on the hypervisor is configured properly. Consult your
hypervisor documentation for instructions.
4 Install the VMware vSphere Client software, version 5.5. or later, on a client
computer. For more information, see
http://www.vmware.com/products/vsphere-hypervisor.
Important
This client software runs on Windows computers only.

Preparing to install vAED (continued)

Step Action
5 Download the vAED OVA file.

We recommend that you save the file to the computer on which the VMware
client is installed.
6 On the VMware server, configure a virtual network for vAED.

See “Configuration Requirements for the VMware Virtual Network” on the
next page.
Configuration information to collect

Collect the information that applies to your virtual network and document it on the
following worksheet. This information is required when you configure vAED.
Configuration information worksheet
Item Description Your setting

IP address and The IP address and netmask of the mgt0 management
netmask of the virtual interface on the virtual machine.
machine We recommend that you allocate IP addresses from
the same subnet as the host.
Note
If you are using a DHCP server, the IP address for
mgt0 is assigned automatically.
Default router (or The IP address of the first router hop that sends
gateway) outbound network traffic. Typically, this is the subnet
switch or router.
Administrator user The credentials for administrative access to vAED. The default user
name and password name is admin and
the default password
is arbor.
Network mappings The associations between the virtual networks that you mgt0:
create and the vAED interfaces. mgt1:
When you create the virtual networks for the interfaces ext0:
as described in “Configuration Requirements for the int0:
VMware Virtual Network” on the next page, record the
network names here.
The use of management interface mgt1 is optional.

Configuration Requirements for the VMware Virtual

Network
You must configure the appropriate virtual networks before you can install vAED on
VMware.
Important
If you are an experienced VMware user, you may choose to configure your networks
differently. If you do, then you must account for those differences during the vAED
installation.
This document assumes that you have some knowledge of virtual network configuration
or you have access to someone who has this knowledge.
Virtual network overview

In the VMware vSphere Hypervisor, you add or configure virtual networks (also called
Ports or Port Groups) for vAED.
When you create vAED, you map the source networks in the virtual image to the virtual
networks (destination networks) that you configured. The source network names are the
same as the vAED interface names (that is, mgt0, mgt1, ext0, and int0).
Configuration for the management interfaces

When you create vAED, the management interfaces are mapped to the same virtual
network. Optionally, if you want to use separate networks for these interfaces, you can edit
the mapping after you complete the installation. See “Remapping VMware Virtual
Networks” on page 35.
Configuration for the ext0 and int0 interfaces

To allow the ext0 and int0 interfaces to receive and send traffic, configure the networks
that these interfaces are connected to as follows:
n Configure the network to allow promiscuous mode connections.
See “Configuring promiscuous mode in VMware” on the facing page.

n Connect the network tap or other device that provides traffic for vAED to the same
physical adapter that you assign to the network.
By default, vAED is installed in monitor mode. If you plan to keep the system in monitor
mode, then you can map all of the source networks to the same virtual network.
If you map these interfaces to the same virtual network during the initial installation, you
can remap them at any time. See “Remapping VMware Virtual Networks” on page 35.
Note
In inline mode, NETSCOUT tested the ext0 and int0 interfaces as physical interfaces
dedicated to separate virtual ports. However, other configurations should work, including
the use of VLANs to share a single physical interface, as long as the platform and
hypervisor support the configuration. Because vAED performance varies by platform and
configuration, confirm that the performance is acceptable for your situation.

Alternate interface configuration in VMware

In VMware, it is possible to configure the external and internal interfaces to share a
physical interface. However, if different VNIC interfaces are bound to the same physical
interface configured with different VLAN tags, the vswitch may drop packets. In this case,
the vswitch drops the packets because the source MAC addresses do not match the VNIC
address.
To avoid dropped packets in this configuration, set the Forged Transmits option for the
virtual network to Accept . When Forged Transmits is set to Accept , the vswitch does
not compare the source MAC addresses to the VNIC address.
For instructions on how to set the Forged Transmits option, refer to your VMware
documentation.
Important
Because vAED performance varies by platform and configuration, we recommend that
you confirm that the performance of vAED in this configuration is acceptable for your
situation.
Configuring promiscuous mode in VMware

To configure a network to allow promiscuous mode connections:
1. Open the VMware vSphere Client and log in, using the credentials for the VMware
server.
2. In the vSphere Client navigation tree, select the host under which you will install vAED.
3. In the right pane, select the Configuration tab.
4. On the left side of the tab, under Hardware , select Networking.
5. On the right side of the tab, find the vSwitch that has the network on which you want
to allow promiscuous mode, and then click its Properties link.
6. In the switch’s Properties window, on the Ports tab, select the network that you
created for the ext0 interface, and then click Edit .
7. In the Network’s Properties window, configure the network as follows:
a. Select the Security tab.
b. Select the Promiscuous Mode check box, and then select Accept in the list to the
right of the check box.
c. Click OK .
8. Repeat step 6 through step 7 for the network that you created for the int0 interface.
9. In the switch’s Properties window, click Close.


After you have performed the pre-installation steps and verified that the minimum system
resource requirements are met, you can install vAED on VMware. To install vAED on
VMware, you create a virtual machine on a VMware hypervisor and then configure its
settings.
Note
Before you install vAED, see “Preparing to Install vAED on VMware” on page 26 .
When you create the virtual machine, you map the source networks in the virtual image to
the virtual networks (destination networks) that you configured. For more information
about configuring the networks, see “Configuration Requirements for the VMware Virtual
Network” on page 28.
After you complete the installation, you can configure vAED. See “Configuring vAED on
VMware” on page 32.

To install vAED, you deploy the virtual template (OVA). The virtual machine is a copy of the
virtual hardware, software, and properties that are configured for the template.
To install vAED on VMware:

1. Open the VMware vSphere™ Client and log in, using the credentials for the VMware
server.
2. Select File > Deploy OVF Template.
3. In the Source window of the Deploy OVF Wizard, select the OVA file that you
downloaded, and then click Next .
We recommend that you deploy the OVA file from the computer on which the
VMware client is installed. If you deploy an OVA file from a remote location, the
VMware client may time out.
4. In the OVF Template Details window, click Next.
5. In the Name and Location window, enter a unique name for this virtual machine or
accept the default name, and then click Next .
6. In the Disk Format window, click Next to accept the default format of Thick
Provision Lazy Zeroed.
7. In the Network Mapping window, map the source networks in the virtual image to the
virtual networks (destination networks) that you configured.
By default, all of the source networks are mapped to the first virtual network name
that appears in VMware. A warning indicates that multiple source networks are
currently mapped to the same destination network.

To change a network mapping, click (drop-down list) next to the destination

network to change, and then select a different network from the list. Refer to the
network names that you recorded in the “Configuration information to collect” on
page 27, and map the networks as follows:
Source network Destination network

mgt0, mgt1 Select the network that you configured for the mgt0 and mgt1
interface.
Initially, you must map the mgt0 interface and the mgt1
interface to the same network. Optionally, if you want to use
separate networks for these interfaces, then you can edit the
mapping after you complete the installation.
ext0 Select the network that you configured for the ext0 interface.
int0 Select the network that you configured for the int0 interface.
8. Click Next in the Network Mapping window.

9. In the Ready to Complete window, review the settings and then click Finish .
Note
Do not select Power on after deployment .
The deployment process might take several minutes.
10. When the completion window appears, click Close.
Configuring the hyperthreading and latency settings for vAED in vSphere

If you notice reduced performance on vAED when other virtual machines are running on
the host, you should consider enabling hyperthreading and configuring latency settings in
vSphere. For instructions, refer to your vSphere documentation.

Configuring vAED on VMware

After you install vAED on a VMware hypervisor, you can configure the system settings.
For vAED installation instructions, see “Installing vAED on VMware” on page 30 .
Accessing the vAED command line interface

You configure vAED on the command line interface (CLI). You can access the CLI in one of
the following ways:
Access method Steps

SSH 1. SSH to the IP address that was assigned to mgt0 by your DHCP
server.
2. At the login prompt on the CLI, enter the default user name of
admin
3. At the Password prompt, enter the default password of arbor
VMware vSphere 1. On the vSphere Hypervisor, display the Inventory View .

Hypervisor 2. If the virtual machine is not powered on, click the Power On
icon.
3. In the inventory list in the left pane, right-click vAED, and then
select Open Console from the context menu.
A new window opens.
4. If the GRUB menu appears, select disk (VGA) and press ENTER,
or wait and allow the system to boot automatically.
Configuring vAED
To configure vAED, access the CLI on vAED. See “Accessing the vAED command line
interface” above.
In the CLI, enter the following commands. Press ENTER after each command.
Command Description
/ system name set hostname Enter the host name for the vAED as a simple host name
or a fully qualified domain name. For example:
host.example.com
/ service dns server add IP_address Enter the IP address for the DNS server.
/ ip interfaces ifconfig mgt1 IP_ (Optional) Enter an IP address and prefix for
address/prefix up management port mgt1. For example: 198.51.100.0/24 or
2001:DB8::/32
/ services aaa local password admin To start the AED services, you must change the default
interactive administrator password. Enter this command to change
the password and then follow these steps:
1. Enter the new password.
2. Re-enter the new password.

Command Description
/ services aed mode set deployment_ (Optional) To change the deployment mode of vAED
mode from the default mode (monitor), enter inline or L3.
For a description of the deployment modes, see “About
the Deployment Modes” in the AED User Guide .
/ ip access add service mgt0 IP_ (Optional) Enter this command to create an IP access
address/prefix rule for a service. Specify the name of a valid service and
the IP address and prefix for the hosts that are allowed
to communicate with the service. For example:
/ ip access add snmp mgt0 198.51.100.0/24
Valid services are as follows:
n http
n https
n ping
n ssh
n cloudsignal
n snmp
For information about the preconfigured IP access rules

for services, see “Modifying the preconfigured IP access
rules” on the next page.
/ ip access delete service all IP_ (Optional) Enter this command to delete an IP access
address/prefix rule for a service. Specify the name of the service and the
IP address and prefix of the hosts that were allowed to
communicate with the service.
For example, the following command deletes the default
IP access rule for the http service on all management
interfaces: / ip access delete http all
0.0.0.0/0
/ services ssh key generate Configure the SSH host keys in one of the following ways:
/ services ssh key host set n To have AED generate the SSH host key files, enter /
disk:fileName services ssh key generate
n To import a file that contains the SSH host keys, enter
/ services ssh key host set disk:fileName
fileName = the name of the file that contains the
SSH host keys
/ ip access commit Commit the IP access rule settings.
/ config write Save the configuration changes.
/ exit Log out of the CLI, and then close the hypervisor,
console, or SSH window.
After you complete the installation and configuration, you can access vAED at any time. See
“Accessing vAED” on page 13.

Modifying the preconfigured IP access rules

When you install vAED, IP access rules are configured for the following services:
n http
n https
n ping
n ssh
These IP access rules do not restrict access to the services (that is, they are configured for
0.0.0.0/0). To restrict access, first add a new IP access rule that specifies an IP address
range for the service, and then delete the existing access rule.

Remapping VMware Virtual Networks

When you create the AED virtual machine, you map the source networks in the virtual
image to the virtual networks (destination networks) that you configured. You can remap
the networks at any time after the installation.
You might want to remap networks in the following situations:

n To map the source networks for the management interfaces (mgt0 and mgt1) to
separate virtual networks.
See “Configuration for the management interfaces” on page 28.
n To map the source networks for the ext0 and int0 interfaces to separate virtual
networks so that you can run vAED in inline mode.
See “Configuration for the ext0 and int0 interfaces” on page 28.
When you map a virtual network, you connect it to a network adapter that is associated
with a vAED interface. The associations between the network adapters and the interfaces
are predefined in vAED, as shown in the following table.
Associations between network adapters and interfaces

Network adapter Associated interface
Network adapter 1 mgt0
Network adapter 2 mgt1
Network adapter 3 ext0
Network adapter 4 int0
Remapping a source network to a different destination network

To remap a source network:
1. Open VMware vSphere Client and log in, using your credentials for the VMware server.
2. In the vSphere Client navigation tree, right-click the virtual machine and select Edit
Settings.
3. In the Virtual Machine Properties window, on the Hardware tab, select a network
adapter.
See “Associations between network adapters and interfaces” above to determine
which network adapter to select, based on the interface whose virtual network you
want to remap.
4. In the Network Connection section, in the Network label list, select the virtual
network to which you want to map the source network.
5. In the Virtual Machine Properties window, click OK .


Section 4:
Using Cloud-Init to Initialize vAED
This section describes how to use Cloud-Init to initialize a virtual AED (vAED) on supported
hypervisors the first time you start the system.
In this section
Using Cloud-Init to Initialize vAED 38

Creating a User Data File for Cloud-Init 40
Configuring Cloud-Init modules in the User Data File 41
Creating a Password Hash for vAED 46
About the Default User Data File 47
Using Cloud-Init with an Orchestration Environment 48
Using Cloud-Init without an Orchestration Environment 49
Viewing the Cloud-Init Log 52

Using Cloud-Init to Initialize vAED

The images for the AED virtual machine (vAED) from NETSCOUT include the Cloud-Init
platform. Cloud-Init provides a quick way to initialize vAED the first time you start the
system. Cloud-Init does this by passing vAED the configuration settings that you add to a
user data file.
After you create a user data file, you create a data source that vAED supports. Cloud-Init
uses a data source to pass the configuration settings in the user data file to vAED.
Note
You can use an orchestration environment such as OpenStack to create the data source.
You also can use the NoCloud data source, which does not require an orchestration
environment. See “Using Cloud-Init with an Orchestration Environment” on page 48
and “Using Cloud-Init without an Orchestration Environment” on page 49 .
Requirements
To use Cloud-Init to initialize vAED, ensure that you meet the requirements for installing
and running vAED on a supported hypervisor. See “Preparing to Install vAED on VMware”
on page 26 and “Preparing to Install vAED on KVM” on page 16
About the user data file

The user data file is a YAML file to which you add the vAED configuration settings. Cloud-
Init locates this file through a supported data source.
For information about the YAML format, see http://www.yaml.org/.
For information about data sources, see “Supported Cloud-Init data sources” below.
In the user data file, you include commands to perform some or all of the following
actions:
n Add a password for the system administrator
n Add user accounts and passwords

n Add SSH keys
n Create API tokens
n Set the IP access rules
n Set the deployment mode
n Assign IP addresses to the protection interfaces and configure routes
n Configure the protection ports
n Start AED services
See “Creating a User Data File for Cloud-Init” on page 40.
Supported Cloud-Init data sources

To locate a user data file, Cloud-Init searches for each of the data sources that vAED
supports. If Cloud-Init finds a supported data source, then it applies the configuration
settings that are in the associated user data file to vAED.

The data sources that vAED supports, in the order in which Cloud-Init searches for them,
are as follows:
Supported data sources

Data source Description
OpenStack Provides user data through the OpenStack Metadata Service.

Cloud-Init initializes vAED by using the configuration settings in the
metadata service. You configure the Open-Stack Metadata Service
in the OpenStack orchestration environment.
For instructions on how to configure the metadata service, refer to
the OpenStack documentation: http://docs.openstack.org/
ConfigDrive Mounts a file system when you start vAED. Cloud-Init finds the
mounted drive and initializes vAED by using the configuration
settings on the drive. You configure the ConfigDrive data source in
the OpenStack orchestration environment.
For instructions on how to create the drive and attach it to vAED,
refer to the OpenStack documentation:
http://docs.openstack.org/
NoCloud Provides a way to initialize vAED with Cloud-Init when you do not
have an orchestration environment. See “Using Cloud-Init without
an Orchestration Environment” on page 49.
None/Fallback Provides default configuration settings for vAED if Cloud-Init

cannot find a data source that vAED supports. NETSCOUT provides
this read-only data source.
For a description of the default settings in the user data file for the
None/Fallback data source, see “About the Default User Data File”
on page 47.

Creating a User Data File for Cloud-Init

To use Cloud-Init, you create a user data file that includes configuration settings for vAED.
The user data file can include several Cloud-Init modules.
You must create the user data file in the YAML format, and save the file with a .yaml
extension. For information about the YAML format, see http://www.yaml.org/.
After you create a user data file, Cloud-Init uses a data source to pass the configuration
settings in the file to vAED. See “Supported Cloud-Init data sources” on page 38.
Example of a user data file

The following code provides an example of a user data file that contains the Cloud-Init
modules that vAED supports.
#cloud-config
users:
- name: user_1
priv: system_admin
passwd: passwordHash
lock_passwd: False
ssh-authorized-keys:
- ssh-rsa publicKey user@host
comsh:
- ip access add http all 192.0.2.0/24
- ip access add https all 192.0.2.0/24
- ip access add ping all 192.0.2.0/24
- ip access add ssh all 192.0.2.0/24
- ip access commit
- services aaa local password admin encrypted 'passwordHash'
- services aaa local add user_2 ddos_admin encrypted 'passwordHash'
- services aaa local apitoken generate api token for user_2
- services ssh key generate
- services ssh start
- services aed start
- config write
final_message:
“Finished initializing vAED with Cloud-Init.”
For a description of the Cloud-Init modules that vAED supports, see “About the users
module” on the facing page, “About the comsh module” on page 42, and “About the
final_message module” on page 45.

Configuring Cloud-Init modules in the User Data File

vAED supports the following Cloud-Init modules, which can be configured in the user data
file:
Supported Cloud-Init modules

Module Purpose
users: To add Cloud-Init parameters for creating user accounts on
vAED.
comsh: To add CLI commands.
final_message: To add a message that appears in the orchestration

environment console and in the Cloud-Init log after the Cloud-
Init process is complete.
These modules are optional, and you can add them to the YAML file in any order.
Important
These modules are the only Cloud-Init modules that NETSCOUT supports in a user data
file.
About the users module

Add the users module to configure vAED user accounts. The parameters that you can add
to this module are as follows:
Supported parameters for the users module

Parameter Description
name: Enter the name of the user account.
passwd: Enter a password hash for the user account. See “Creating
a password hash” on page 46.
priv: Enter the user's level of privileges (user group) on vAED.

Valid user groups are as follows:
n system_admin
n ddos_admin
n system_user
n system_none
lock_password: Enter False for this command to allow the user to access
vAED. If you want to lock access to the account, enter True
for this command.
ssh-authorized-keys: Add this section to define public SSH key pairs for the user.
You can enter key pairs in the following forms:
ssh-rsa publicKey
ssh-dsa publicKey

The following code provides an example of the Cloud-Init parameters that you can add to
a user data file:
#cloud-config
users:
- name: user_1
priv: system_admin
passwd: passwordHash
lock_passwd: False
ssh-authorized-keys:
- ssh-rsa publicKey user@host
About the comsh module

Add the comsh module to include AED CLI commands for initializing vAED. The CLI
commands that this module supports are as follows:
Supported ip commands for the comsh module

Command Description
ip access add {mgt0|mgt1|all}service Add IP access rules for the services that are
ipAddress_Range allowed to access one management port (mgt0
or mgt1) or both management ports (all).
The valid services are as follows:
n http
n https
n ssh
n ping
For example, ip access add http all

198.51.100.0/24
Important
If you do not specify any IP access rules in the
user data file, no IP access rules are set on
vAED.
ip access commit If you add IP access rules, use this command to

save the changes.
services aed mode set {inline | l3 | Set the deployment mode. For example,
monitor} services aed mode set inline
For descriptions of the deployment modes, see
“About the Deployment Modes” in the AED User
Guide .
Important
If you do not specify a deployment mode, vAED
is set to the monitor mode by default.
services aed mitigation interface If vAED is set to the layer 3 (l3) deployment
protectionInterface network mode, assign an IPv4 address and prefix length
to a protection interface (for example, ext0 or
int0).

Supported ip commands for the comsh module (continued)

Command Description
services aed mitigation route add network If vAED is set to the layer 3 (l3) deployment
nexthop mode, add a route for the layer 3 traffic. Enter an
IPv4 address and prefix length for the
destination network.
Also enter an IPv4 address for the router
(nexthop) through which the traffic is sent to the
network. The IP address for the router must
match a subnet for one of the protection
interfaces.
services aaa local password admin Assign an encrypted password for an

encrypted 'passwordHash' administrator. Enter the password as a password
hash. See “Creating a password hash” on
page 46.
services aaa local add userName userGroup Creates a new user account. Enter a user name,
encrypted 'passwordHash' the user’s level of privileges (user group), and a
password hash. Valid user groups are as follows:
n system_admin
n ddos_admin
n system_user
n system_none
See “Creating a password hash” on page 46.
services aaa local apitoken generate Generate an API token for a user, to allow access
userName tokenDescription to the AED API. Enter the name of the user who
can use the token and a description for the
token.
To view the token that is generated, see “Viewing
the Cloud-Init Log” on page 52.
services ssh key generate Generate the SSH host key files.
services ssh start Start the SSH server, to allow SSH connections.
Important
Before you can start the SSH server, you must
generate the host key files.
services aed start Start AED services.

Important
Before you can start AED services on vAED, you
must change the default password.

Supported ip commands for the comsh module (continued)

Command Description
license --license-server-id idNum --mbps Configure a cloud-based license for vAED by

rate --aif-level {None | Standard | Advanced} specifying the license server ID and the
--proxy-enable {on | off} --proxy-host mitigation capacity of the license in megabits per
ipAddress --proxy-port portNum second. You also can specify the level for an
--proxy-auth-type {anyauth | basic | digest | ATLAS Intelligence Feed license.
negotiate | ntlm} --proxy-username name To configure an optional proxy server, you need
--proxy-password pw to provide the following information:
n IP address or fully-qualified domain name
n port number
n authentication method
You also may need to provide a username
and password, if the authentication method
requires them.
Important
The double hyphens in front of the options are
required for this command.
config write Important

Save the configuration settings on vAED.
Important
When you use Cloud-Init to initialize vAED, DHCP is enabled by default for management
port mgt0 only.
The following code provides an example of how to use the CLI commands in the comsh
module:
#cloud-config
comsh:
- ip access commit
- services aaa local password admin encrypted 'passwordHash'
- services aaa local add user_2 ddos_admin encrypted 'passwordHash'
- services aaa local apitoken generate api token for user_2
- services ssh key generate
- services aed start
- license --license-server-id 12345678901 --mbps 1000 --aif-level Advanced
- config write

About the final_message module

Add the final_message module to display a message that appears after the Cloud-Init
process is complete. This message appears in the orchestration environment console and
in the Cloud-Init log. See “Viewing the Cloud-Init Log” on page 52.
The format for the message is as follows:

n final_message: “messageText“
messageText = The message that you want to display. You must surround the message
text with quotation marks.
For example: final_message: “Finished initializing vAED with Cloud-Init.”

Creating a Password Hash for vAED

Before you can start AED services on vAED, you must change the default password. To
change the vAED password with Cloud-Init, you must enter the password as a password
hash in the user data file.

Although the password hash does not have to adhere to the AED password requirements,
we recommend that you create a strong password as follows:
n use from 7 to 72 characters, which can include special characters, spaces, and
quotation marks
n do not use all digits
n do not use all lowercase letters or all uppercase letters
n do not use only letters followed by only digits (for example, abcd123)
n do not use only digits followed by only letters (for example, 123abcd)
Creating a password hash

To create password hashes for vAED:
1. Copy the following python script to a suitable location, and then modify the code to
create your script:
#!/usr/bin/env python
import sys
# Using py-bcrypt
# https://pypi.python.org/pypi/py-bcrypt
from bcrypt import gensalt
from bcrypt import hashpw
# Generate a hash for each argument passed in.

for pw in sys.argv[1:]:
# Explicitly using 12 rounds.
salt = gensalt(12)
print '{0}:\t{1}'.format(pw, hashpw(pw, salt))
2. Run your script.
3. To view the password hashes that the script generates, pass in plain text passwords as
a list of arguments, as shown below. This example assumes that the name of the
script is "passwordHashes.py".
./passwordHashes.py password1 password2 password3
An example of the output is as follows:
password1:
$2a$12$D2hAeuKZahxtUAV7PDnEOe1w8ZozjcvxPcG6Vs0dsF7nVOWyH9XL2
password2:
$2a$12$yDmDzpBLefk11hOBikbO2O3qZ3WcIBQU9vGgtlSMfHstyUYucSFPe
password3:
$2a$12$JVVae6BEQjXmoAkycxLkyebbUA2BO95.A3O/LqGf.W.mmPXQIg18y

About the Default User Data File

If Cloud-Init does not find a data source that vAED supports, Cloud-Init uses the
None/Fallback data source automatically. This data source passes a user data file that
contains default configuration settings to vAED. NETSCOUT provides this read-only data
source and its associated user data file on the vAED image.
For information about the user data file, see “Creating a User Data File for Cloud-Init” on
page 40.
Configuration settings in the default user data file

The None/Fallback data source uses the following user data file to initialize vAED:
#cloud-config
comsh:
- ip access commit
- services aed mode set l3
- config write
final_message: "Finished cloud-init. Note that access to http, https,
ssh and ping are now all unrestricted. You should configure IP access
rules to allow access for authorized users only."
This user data file initializes vAED as follows:

n Provides unrestricted IP access to both management interfaces (mgt0 and mgt1) for
HTTP, HTTPS, PING, and SSH traffic
n Sets the deployment mode to layer 3 (Inline Routed)
n Starts the SSH server to allow SSH connections
Important
The user data file that the None/Fallback data source uses does not start AED services.
You must change the default password on vAED before you can start AED services.

Using Cloud-Init with an Orchestration Environment

After you create a user data file and configure a data source that vAED supports, you can
use Cloud-Init to initialize vAED on supported hypervisors. You can initialize vAED using a
data source with an orchestration environment, such as OpenStack.
For information about creating a user data file and data sources, see “Creating a User
Data File for Cloud-Init” on page 40 and “Supported Cloud-Init data sources” on page 38.
For information on the hypervisors that vAED supports, see the Arbor Edge Defense
Release Notes.
Note
You also can use Cloud-Init without an orchestration environment. See “Using Cloud-Init
without an Orchestration Environment” on the facing page.
After you use Cloud-Init to initialize vAED, you can view the Cloud-Init log on vAED. See
“Viewing the Cloud-Init Log” on page 52.
Using an orchestration environment to initialize vAED

Note
For instructions that are specific to your orchestration environment, refer to the
orchestration environment documentation.
To use an orchestration environment to initialize vAED:

1. Open the orchestration environment.
2. Upload a copy of the vAED image file from NETSCOUT. See “Preparing to Install vAED
on KVM” on page 16 and “Preparing to Install vAED on VMware” on page 26.
3. Configure the appropriate settings to create a vAED instance.
4. Upload a user data file or enter the configuration settings in the appropriate fields in
the orchestration environment.
5. Create the vAED instance.
6. Access vAED in one of the following ways:
l Open it from your orchestration environment
l SSH to the vAED command line interface
l Open vAED in a web browser.

Using Cloud-Init without an Orchestration Environment

If you do not have access to an orchestration environment, you can create a disk image to
use as a NoCloud data source.
For an overview of data sources, see “Supported Cloud-Init data sources” on page 38 .
About the NoCloud data source

To use the NoCloud data source, you must create a disk image that contains a metadata
file and a user data file. Create these files in the YAML format and save them with a .yaml
extension.
The metadata file can be empty, but the disk image requires a metadata file. For
information about the metadata file, see
http://cloudinit.readthedocs.io/en/latest/topics/datasources.html?highlight=meta%20d
ata%20file#no-cloud
Creating a disk image for the NoCloud data source

To create a disk image for the NoCloud data source:
1. Create the user data file, and name the file “user-data”.
2. Create the metadata file, and name the file “meta-data”. This file can be empty but you
must include a metadata file in the disk image.
3. Save the user-data file and the meta-data file in the same folder.
4. At the same level as the folder in which you saved the files, enter $ genisoimage -
output seed.iso -volid cidata -joliet -rock user-data meta-data
This command creates a disk image for an ISO 9660 file system or a vfat file system
with the system label “cidata”.
Note
This command is for use with a Linux operating system. If you use a different
operating system, refer to the operating system documentation for the correct
command.
Using a NoCloud disk image to initialize vAED on KVM

After you create a disk image, you can use the NoCloud data source to initialize vAED.
To initialize a new vAED instance on KVM:

1. To start the installer, on the host server command line, enter sudo virt-install -
-connect qemu:///system \
2. Enter the following commands to install and configure vAED on KVM. Press ENTER after
each command.

Command Description
-n VM_hostname\ Indicates the hostname for the virtual

machine. Enter a simple hostname or a fully
qualified domain name.
For example: host.example.com
-r 6144 \ Allocates 6 GB of memory to the virtual

machine.
--vcpus=2,sockets=1,cores=2,maxvcpus=2 \ Specifies the number of virtual CPUs that are
allocated to the virtual machine.
--arch=x86_64 \ Indicates that the virtual machine uses a 64-
bit architecture.
--os-type linux \ Specifies the operating system type.
--import \ Indicates the use of a disk image.
--disk path=filepath/filename qcow2, Specifies the path and file name of the vAED
device=disk,bus=virtio,size=100,format=qcow2 disk image and the size and bus type of the
image.
--disk path=filepath/filename.iso, Specifies the path and file name of the

device=cd-rom,perfs=ro NoCloud disk image that contains the user
data file and the metadata file.
See “Creating a disk image for the NoCloud
data source” on the previous page.
--network bridge=vmbr0,model=virtio \ Assigns virtual bridges to the virtual machine

--network bridge=vmbr1,model=virtio \ and assigns the virtual network.
--network bridge=vmbr2,model=virtio \
--network bridge=vmbr3,model=virtio \
--vnc --noautoconsole Allows virtual network computing (VNC)

access to the KVM console.
After Cloud-Init finishes executing the commands, you should see the following output,
which indicates that the virtual machine is running:
# virt-install --connect qemu:///system --name <vm-hostname> -r 6144 --
vcpus=2,sockets=1,cores=2,maxvcpus=2 --arch=x86_64 --import --os-type
linux --disk path=/var/lib/libvirt/images/Arbor-vaed-#.#.#-
xxxx.qcow2,bus=virtio,size=100,format=qcow2 --disk
path=/var/lib/libvirt/images/filename.iso,device=cdrom,perms=ro --
network bridge=vmbr0,model=virtio --network bridge=vmbr1,model=virtio -
-network bridge=vmbr3,model=virtio --network bridge=vmbr4,model=virtio
--vnc --noautoconsole
Using the NoCloud disk image to initialize vAED on VMware

Important
Use these instructions immediately after you deploy vAED on VMware, but before you
start vAED. When you deploy the OVA, do not select Power On After Deployment .

To initialize vAED on VMware:

1. Deploy the virtual template file (OVA) for VMware. See “Installing vAED on VMware”
on page 30.
2. Open the VMware vSphere Client and, in the left navigation bar, select the host server
on which the vAED resides.
3. In the right pane, click the Configuration tab, and then select Datastores as the
View .
4. From the list of datastores, right-click the datastore in which you want to store the
NoCloud disk image, and then select Browse Datastore .
5. In the left navigation pane of the Datastore Browser window, select the folder in which
you stored your NoCloud disk image.
6. From the toolbar, click (upload), and then select Upload File.
7. In the Upload Items window, select the disk image file (.iso), and then click Open . If an
upload warning message appears, click Yes to continue.
8. In the left navigation pane, expand the host server section in which the vAED resides.
9. Under the host server name, right-click the vAED name, and then click Edit Settings.
10. In the Virtual Machine Properties window, select the Hardware tab, and then click
Add.
11. In the Add Hardware wizard, on the Device Type page, select CD/DVD Drive, and
then click Next .
12. On the CD/DVD Media Type page, select the Use ISO Image option, and then click
Next .
13. On the Select ISO Image page, click Browse, and then select your NoCloud disk
image.
14. Select the Connect at power on option, and then click Next.
15. In the Virtual Device Node box, select IDE (1:0), and then click Next.
16. On the Ready to Complete page, click Finish
17. To save your settings and close the Virtual Machine Properties window, click OK .

Viewing the Cloud-Init Log

After you use Cloud-Init to initialize vAED, you can view the Cloud-Init log on vAED. The log
shows all of the Cloud-Init commands, as well as information that is specific to the vAED
instance.
Viewing the Cloud-Init Log

To view the Cloud-Init log on vAED:
2. Use one of the following commands to view the Cloud-Init log:
l To view the entire log, enter / services log view cloud-init-output.log
l To view only vAED information in the log, enter / services log view cloud-
init-output.log tail #
# = (Optional) The number of lines of text that you want to view. If you do not
specify a number, this command displays a maximum of 10 lines.
An example of the information that may appear in the Cloud-Init log is as follows:
##################################################################
Local users:
admin system_admin Password set
user1 system_admin Password set
user2 system_user Password set
Apitokens:
user1:
IWjqFmIE_o9qCMgs**bwVQL8**Z54QzMPt3**Vpf apitoken for user1
user2:
nWxtMteU**F41lM2Bj**CTlv6inHMF7XmC_YM**k apitoken for user2
Management IP:
Inet: 198.51.100.8
Inet6: 2001:DB8::2
System name:
vaed_1
##################################################################

Section 5:
Licensing vAED
This section describes how to license vAED.
In this section
About Cloud-Based Licensing for vAED 54

Configuring Cloud-Based Licenses for vAED 57
Viewing vAED License Information in the UI 60

About Cloud-Based Licensing for vAED

vAED uses cloud-based licenses that allow you to configure the licensed capabilities for the
system. You can license the following capabilities:
n The throughput limit for vAED
The throughput limit is enforced on the clean traffic that vAED forwards. Clean traffic
refers to traffic that is not dropped by a protection setting.
n The ATLAS Intelligence Feed (AIF)
Overview of cloud-based licensing

With cloud-based licensing, vAED accesses a cloud-based license server and the server
downloads local copies of the cloud-based licenses. After you download local copies of
the cloud-based licenses, vAED requires contact with the cloud-based license server to
function correctly.
vAED communicates with the cloud-based license server on the standard HTTPS port, 443.
If vAED is behind a firewall, we recommend that you configure a proxy server through
which vAED accesses the license server.
If vAED cannot communicate with the license server, the local licenses expire 10 days after
they were last refreshed. See “Refreshing local copies of the cloud-based licenses” on
page 59.
If the local licenses expire, your ability to use vAED is severely limited. See “About license
expiration” on the facing page.
If you decommission vAED, then release the local licenses on vAED first. If you do not
release the licenses first, then the capacity that is assigned to them is unavailable to other
systems until the local licenses expire. The licenses expire 10 days after you decommission
vAED. See “Releasing Local Licenses on vAED” on page 59.
Configuring access to the cloud-based license server

If you are a system administrator, you configure access to the cloud-based license server
on the Licenses page (Administration > Licenses). See “Configuring Cloud-Based
Licenses for vAED” on page 57.
How to obtain cloud-based licenses

You purchase cloud-based licenses for vAED from your NETSCOUT sales representative.
After you purchase a license, you receive an email that contains your cloud-based license
server ID. Use this ID to configure access to the cloud-based license server.
See “Configuring access to the cloud-based license server” on page 57.
About throughput licensing

After you configure access to a cloud-based license server, you request a throughput limit
for vAED. You can combine the value of one or more of your vAED licenses to attain this
throughput limit. See “Requesting a throughput limit for vAED” on page 58.

Regardless of the throughput limit that you license on vAED, the limit is not absolute; it
allows for a buffer that accommodates occasional traffic spikes.
If the amount of traffic that vAED forwards exceeds 90 percent of its licensed limit, an alert
appears on the Summary page and System Alerts page. You can configure notifications to
send messages when a license alert occurs.
License alerts are included when you configure bandwidth notifications. See “Configuring
Notifications” in the Arbor Edge Defense User Guide .
About AIF licensing

An advanced AIF license subscription is required. When you request a throughput limit,
vAED automatically requests an advanced AIF license from the server.
Viewing the licensed capabilities on vAED

You can view information about the licensed capabilities for vAED on the Licenses page in
the UI and in the command line interface (CLI). See “Viewing vAED License Information in
the UI” on page 60.
About license expiration

On the Licenses page, the Expiration fields display the dates on which the licenses expire
on the cloud-based license server. If the license server contains multiple licenses for a
capability, the Expiration field reflects the first date on which a licensed capability expires.
After a license expires, the Expiration field reflects the next date on which a license for that
capability expires.
If no licenses for a capability are available on the license server, vAED clears the Expiration
field. Without a throughput license, vAED passes traffic without inspecting it. Without an
AIF license, vAED cannot detect and block traffic that matches AIF HTTP header signatures
or AIF threat policies that are enabled.

Status of cloud-based licenses

vAED informs you about the status of your cloud-based licensing in the following ways:
Cloud-based licensing status information

Method Description
Expiration messages for local If local licenses expire in 9 or fewer days, a message
licenses appears on the Licenses page, in the Cloud-Based
License Server section. This message provides the
following information:
n the date and time of the last successful refresh
n the date and time when the local licenses expire or
expired
If your local licenses expired, contact the Arbor

Technical Assistance Center (ATAC) at
https://support.arbornetworks.com/.
Expiration messages for Cloud- If cloud-based licenses expire in 30 or fewer days, a

based licenses message appears on the Licenses page, in the
Licensed Capabilities section. This message displays
one of the following warnings:
n the date and time when the throughput license
expires or expired, and the throughput limit that is
available after the expiration date
n the date and time when the current AIF license
expires or expired
If your cloud-based licenses are expired, contact

ATAC at https://support.arbornetworks.com/.
System alerts If issues occur with your cloud-based licenses or local

licenses, vAED generates alerts on the Summary page
and System Alerts page. See “Viewing Alerts” in the
AED User Guide .
Status message Status messages indicate the result of an event:

success, failure, or already in progress. Any messages
about problems that need further action remain until
the problem is resolved.
Status messages appear in the following locations on
the Licenses page:
n messages that indicate the result of an event, such
as a request for a different throughput amount,
appear at the top of the Licenses page
n throughput issues and AIF issues appear in the
Licensed Capabilities section
n server connection issues appear in the Cloud-
Based License Server section

Configuring Cloud-Based Licenses for vAED

On the Licenses page, system administrators can configure the throughput limit for vAED.
The current status of the AIF license also is shown on this page.
The licenses are available through a cloud-based license server. See “About Cloud-Based
Licensing for vAED” on page 54.
License configuration process

The process to license vAED consists of the following steps:
Steps to configure vAED licenses

Step Action
1 Configure access to the cloud-based license server. See “Configuring access to

the cloud-based license server” below.
2 Request a local license for a throughput limit. This limit is the amount of clean
traffic that vAED is licensed to forward. Clean traffic refers to traffic that is not
dropped by a protection setting.
See “Requesting a throughput limit for vAED” on the next page.
Note
When you request a throughput limit, vAED automatically requests an
advanced AIF license from the server.
4 (Optional) Refresh local copies of the licenses. See “Refreshing local copies of
the cloud-based licenses” on page 59.
Configuring access to the cloud-based license server

After you purchase a vAED license, you receive an email that contains the cloud-based
license server ID. Use this ID to configure access to the license server.
To configure access to the license server:

1. Select Administration > Licenses.
2. On the Licenses page, in the Cloud-Based License Server section, specify the server
settings. See “vAED license server settings” on the next page.
To change any of the license server settings that you previously configured, click Edit .
3. Click Save.

vAED license server settings

The Cloud-Based License Server section contains the following settings:
vAED license server settings

Setting Description
Cloud-Based License Type the license server ID that you received from NETSCOUT
Server ID box after you purchased a cloud-based license.
Use Proxy Server Select this check box to connect to the vAED license server
check box through a proxy server.
Proxy Server box Type the IP address or the hostname for the proxy server.
Port box Type the port number for the proxy server.
Proxy Username If necessary, type the user name that is required to access the
box proxy server.
Proxy Password box If necessary, type the password that is required to access the
Verify box proxy server, and then re-type the password to confirm it. To
delete an existing password and leave the password empty,
click (Clear Password).
Proxy If necessary, select the authentication method that the proxy

Authentication server uses:
Method options n Automatic
n Basic
n Digest
n NTLM
Automatic is the default setting. If you select Automatic,

then vAED automatically identifies the authentication method
that the proxy server uses. If vAED cannot identify the correct
authentication method automatically, then select another
authentication method.
Requesting a throughput limit for vAED

After you configure access to the license server, you can request a throughput limit for
vAED. vAED can obtain the requested throughput limit from one throughput license or
from multiple throughput licenses on the configured cloud-based license server.
To request a throughput limit:

2. On the Licenses page, in the Requested Throughput Limit box, specify the amount
of throughput to license on this vAED.
You can request from 20 Mbps up to 1 Gbps. The amount of clean traffic that vAED
can forward depends on the throughput limit that has been purchased.
3. Click a throughput rate: Mbps or Gbps.

4. Click Save.
If the cloud-based license server is processing a request from another user, a
message notifies you that your request cannot be saved. When this message
disappears, click Save again.
The Throughput Limit for Clean Traffic field displays the throughput limit that vAED
acquired. If the throughput limit that you request is not available, then a message displays
the throughput limit that vAED could acquire.
In this case, your original throughput request remains in the Requested Throughput
Limit box. If more throughput becomes available, vAED increases the throughput, up to
the requested amount.
To increase the throughput limit for a vAED, you can purchase additional throughput
licenses. You also can reduce the throughput limit on other vAED systems that are
connected to the same license server.
Refreshing local copies of the cloud-based licenses

vAED communicates with the cloud-based license server on a regular basis throughout
each day, to refresh the local copies of the licenses. However, you may want to refresh the
local licenses in the following situations:
n after a network change occurs, to ensure that vAED still can contact the license server
n after you add more throughput capacity to the server, so that vAED can access it
immediately
n after you resolve any issues that may have caused a license refresh to fail
To refresh the local copies of the cloud-based licenses on vAED:

2. On the Licenses page, in the Cloud-Based License Server section, click Refresh Local
Copy of License.
If a license request from another user is pending, then a message notifies you that
you cannot refresh your licenses at this time. You must wait until the message
disappears before you try to refresh again.
A refresh may take several minutes. If vAED can communicate with the cloud-based license
server, then the Last Successful Refresh section displays the new date and time. If vAED
cannot communicate with the license server, then a message notifies you that the refresh
was unsuccessful. In that situation, contact the Arbor Technical Assistance Center (ATAC) at
https://support.arbornetworks.com/.
Releasing Local Licenses on vAED

If you no longer need a local license, you can release it so that its throughput amount is
available for other vAED systems. You also should release the local licenses before you
decommission vAED. If you do not release the licenses first, then the capacity that is
assigned to them is unavailable to other vAED systems until the local licenses expire. The
licenses expire 10 days after you decommission a vAED.
To release a throughput license:

2. On the Licenses page, in the Requested Throughput Limit box, enter 0.
3. Click Save.

Viewing vAED License Information in the UI

If you are a system administrator, then you can view information about the cloud-based
license server and the licensed capabilities for vAED on the Licenses page. The licensed
capabilities are the throughput limit for vAED and the ATLAS Intelligence Feed (AIF).
For information about how to configure the licensed capabilities on vAED, see
“Configuring Cloud-Based Licenses for vAED” on page 57.
Navigating to the Licenses page

To view information about the licensed capabilities for vAED:
n Select Administration > Licenses.
Viewing information about the throughput license capability

On the Licenses page, you can view the following information about the throughput
license:
Throughput license information

Information Description
Throughput Limit The amount of clean traffic that vAED is licensed to forward. Clean
for Clean Traffic traffic refers to traffic that is not dropped by a protection setting.
This throughput limit is not absolute; it allows for a buffer that
accommodates occasional traffic spikes.
vAED continues to forward clean traffic until the traffic exceeds the
buffer. At that point, vAED may start dropping clean traffic.
Requested The amount of license throughput that you requested. If the

Throughput Limit requested amount is not available, this value differs from the
Throughput Limit for Clean Traffic.
See “Requesting a throughput limit for vAED” on page 58.
Expiration The first date on which a throughput license will expire on the
cloud-based license server. If no throughput license was requested
or if no throughput license is available, then this field is empty. If
the throughput license on the license server does not have an
expiration date, then this field shows No Expiration.
About the throughput information on the Licenses page

The Throughput for Clean Traffic graph represents the amount of clean traffic that vAED
forwarded over the previous week. Use this information to monitor vAED and determine
when it is near or above the licensed capacity. You also can use this information to verify
the success of an upgrade to a license that has a higher throughput limit.
Below the graph, the Throughput Limit for Clean Traffic section indicates the amount of
throughput for which vAED is licensed. A black horizontal line identifies this limit on the
graph. This throughput limit is not absolute; it allows for a buffer that accommodates
occasional traffic spikes.

Note
If you restart your system, the horizontal line may drop to zero. After the restart is
complete, the correct limit is restored.
vAED continues to forward clean traffic until the traffic exceeds the buffer. At that point,
vAED may start to drop clean traffic.
The traffic segments in blue represent the clean traffic that AED forwarded. The traffic
segments in red represent the clean traffic that AED dropped after the buffer was
exceeded.
Viewing information about the AIF license capability

On the Licenses page, you can view the following information about the AIF license:
AIF license information

Current AIF Level The AIF level that is configured for your system (None or
Advanced).
Expiration The first date on which an AIF license will expire on the cloud-
based license server. If no AIF license is available, then this field is
empty. If the AIF license on the license server does not have an
expiration date, then this field shows No Expiration.
Viewing information about the cloud-based license server

On the Licenses page, you can view the following information about the cloud-based
license server:
Cloud-based license server information

Last Successful The last date on which vAED was able to connect to the cloud-
Refresh based license server, to refresh the local copies of the licenses.
If vAED cannot connect to the license server, a message displays
the amount of time, in days and hours, until the local licenses
expire.
Refresh Local Copy Click this button to refresh the connection to the cloud-based
of License license server. You may want to refresh the connection in the
following situations:
n after a network change occurs, to ensure that vAED still can
contact the license server
n after you add more throughput capacity to the server, so that
vAED can access it immediately
n after you resolve any issues that may have caused a license
refresh to fail
See “Refreshing local copies of the cloud-based licenses” on

page 59.

Cloud-based license server information (continued)

Cloud-Based License The ID of the cloud-based license server on which the vAED
Server ID licenses reside.
Proxy Server, Port, If you configure a proxy server for the cloud-based license
Proxy Authentication server, these fields show the IP address or hostname, port
Method number, and authentication method for the server.

Appendix A:
vAED Performance Benchmarks
This section provides information about the vAED performance benchmark tests.
In this section
vAED Performance Benchmarks 64

vAED Performance Benchmarks

To obtain information about the performance of AED virtual machines (vAED), Arbor ran
benchmark tests on several vendor platforms. Arbor tested vAED in the following
virtualization environments:
n KVM
For information about the KVM installation, see “Installing vAED on KVM” on page 20 .
n VMware
For information about the VMware installation, see “Installing vAED on VMware” on
page 30.
For information about vAED, see “About vAED” on page 8 .
2 CPU vendor platforms and host server configuration

Arbor performed the 2 CPU tests on the following platforms:
Vendor platforms for 2 CPU tests

Vendor and Model CPU Cores RAM Storage
Dell™ PowerEdge™ 2x Intel® Xeon® CPU E5-2699 v3 72 512 GB 6 x 1.2 TB 10K SAS
R730xd @ 2.30GHz
HP® o ProLiant DL380 2x Intel® Xeon® CPU E5-2690 v3 48 256 GB 4 x 1.2 TB 10K SAS
Gen9 @ 2.60GHz
Important
For the 2 CPU tests, Arbor ran the VMware tests on the Dell platform and the KVM tests
on the HP platform. Arbor extrapolated the 2 CPU results on the other platforms from
the results on these platforms.
Arbor configured the host server for the 2 CPU vAED benchmark tests as follows:
2 CPU configuration
Component Configuration
CPUs 2
Hard disk space 100 GB
RAM 6 GB
Interfaces VMware: 4 x E1000

KVM: 4 x Virtio

4 CPU vendor platforms and host server configuration

Arbor performed the 4 CPU tests on the following platforms:
Vendor platforms for 4 CPU tests

Vendor and Model CPU Cores RAM Storage
Cisco® UCS B200 M4 2x E5-2640 v3 @ 2.60 GHz 16 64 GB 2 TB SAS
Dell™ PowerEdge™ R420 2x E5-2470 v2 @ 2.40 GHz 10 256 GB 2 TB non-SSD
HP® ProLiant DL380 G2 2x E5-2690 v3 @ 2.60GHz 12 256 GB 2 TB non-SSD
Arbor configured the host server for the 4 CPU vAED benchmark tests as follows:
4 CPU configuration
Component Configuration
CPUs 4
Hard disk space 100 GB
RAM 12 GB
Interfaces VMware: 4 x E1000

KVM: 4 x Virtio
Performance benchmark test metrics

Arbor used the following metrics for its vAED benchmark tests.
Test Setup
The test components consisted of an Ixia appliance and the device under test (DUT). The
DUT was vAED on VMware or KVM. The Ixia chassis was connected directly to the DUT with
no physical switch between the two devices. The physical cabling varied, based on the DUT
and the test that was being run.
Each vAED interface used its own virtual switch or Linux bridge, which was bound to a
physical interface on the host server. The virtual switches were not shared among vAED
virtual machines.
Throughput testing
The purpose of the inspection throughput metric is to establish and illustrate the
maximum traffic throughput that the vAED can inspect.
Note
This test differs from a pure network throughput test, in which the raw packet handling
capacity is determined without inspection.

Arbor performed the following throughput tests:

n 64-byte fixed packet size
This test determines the maximum frames per second (fps) that vAED can handle while
it inspects packets. The fps values in the following tables are the results from this test.
n random packet size
For this test, Arbor used IMIX traffic to determine the maximum bps that vAED can
handle while it inspects packets. The bps values in the following tables are the results
from this test.
The IMIX traffic uses the ratio [64:7, 570:4, 1518:1]. For example, in this case, 12 (7+4+1)
is the total of the weights. Frames are randomly generated:
l 64-byte frames are 7/12 of the total
Latency testing
Traffic delays can trigger timeout conditions, which may cause critical applications to fail. In
some cases, time-to-live values may cause traffic to be re-sent, which can make traffic
problems worse. For these reasons, latency is an important consideration for an inline
network security device.
Note
Latency can vary due to the hardware configuration of the virtual machine’s host server
and the number of virtual machines that the server is hosting.
Arbor performed the following latency tests:

n 64-byte fixed packet size
This test determines the average latency and minimum latency on vAED while it inspects
64-byte packets.
n random packet size
This test determines the average latency and minimum latency on vAED while it inspects
IMIX traffic.
Note
Arbor incorporated latency improvement measures during the installation process.
VMware performance benchmarks

To obtain the VMware results, Arbor used VMware 5.5. The numbers may vary slightly if
you use a different VMware version.

The 1 Gb performance benchmark results for VMware on a host server with 2 CPUs are as
follows:
2 CPU results on VMware
Throughput Latency (ms)
64-byte fixed packet size Random packet size
Platform Mfps Mbps Average Minimum Average Minimum

UCS 0.447 (30.16%) 946.5 (100%) 0.2 0.11 0.52 0.25
HP 0.447 (30.16%) 946.5 (100%) 0.3 0.04 1.56 0.12
Dell 0.581 (39.2%) 946.5 (100%) 0.54 0.435 0.75 0.109
Note
Arbor extrapolated the 2 CPU results for the UCS and HP platforms from the results on
the Dell platform.
The 1 Gb performance benchmark results for VMware on a host server with 4 CPUs are as
follows:
4 CPU results on VMware

UCS 0.562 (37.78%) 946.5 (100%) 0.245 0.088 0.229 0.115
HP 0.561 (37.70%) 946.500 (100%) 0.337 0.03 0.697 0.055
Dell 0.91 (61.40%) 946.500 (100%) 0.729 0.35 0.333 0.05
KVM performance benchmarks

The 1 Gb performance benchmark results for KVM on a host server with 2 CPUs are as
follows:
2 CPU results on KVM

UCS 0.339 (22.87%) 888 (93.81%) 0.38 0.06 0.13 0.02
HP 0.314 (21.18%) 870.706 (92%) 0.16 0.033 0.298 0.039
Dell 0.395 (25.65%) 888.12 (93.83%) 0.2 0.03 0.32 0.03

Note
Arbor extrapolated the 2 CPU results for the UCS and Dell platforms from the results on
the HP platform.
The 1 Gb performance benchmark results for KVM on a host server with 4 CPUs are as
follows:
4 CPU results on KVM

UCS 0.416 (27.96%) 943.265 (99.65%) 0.395 0.046 0.14 0.018
HP 0.385 (26.00%) 924.316 (97.65%) 0.168 0.026 0.332 0.042
Dell 0.485 (32.62%) 946.500 (100%) 0.200 0.019 0.355 0.033

Index
A I
AIF (ATLAS Intelligence Feed) inspected throughput
cloud-based licenses 55 vAED 54
license on vAED 55 installation
license, viewing on vAED 61 vAED on KVM virtual machine 16, 20
API Guide online 5 vAED on VMware 26, 30
Arbor Technical Assistance Center, contacting 6 interfaces
ATAC, contacting 6 vAED 8
ATLAS Intelligence Feed (AIF) IP access rules
cloud-based licenses 55 adding 23, 33
license on vAED 55 deleting 23, 33
C K
cloud-based license server, configuring for vAED 57 KVM
cloud-based licenses, vAED using QEMU guest agent with 21
about 54 KVM virtual machine
AIF 55, 61 configuring network bridges 18
configuring 57 installing vAED on 16, 20
expiration 55 performance benchmarks 67
refreshing local copies 59
releasing 59 L
status 56
l3
throughput, viewing 60
see layer 3 mode 10
viewing information about 60
layer 3 mode
Cloud-Init
about 9
about 38, 48-49, 52
configuring routes 10
password hash for user data file 46
license information
supported data sources 38
vAED 60
user data file 38, 40, 47
license server, vAED
Cloud-Init modules
configuring 57
supported 41
viewing information 61
configuration, vAED 22, 32
Licenses page 60
customer support, contacting 6
licenses, releasing on vAED 59
D M
data sources for Cloud-Init 38
mitigation interfaces
deployment mode
configuring 10
layer 3 9-10
E N
network bridges
expiration
configuring for KVM virtual machine 18
cloud-based licenses 55
vAED licenses 55

Index: overview of vAED – vSphere
configuring license server 57

O configuring routes 10
configuring VMware virtual network 28
overview of vAED 8
initializing with Cloud-Init 38
inspected throughput 54
P installation on KVM virtual machine 16, 20
password installation on VMware 26, 30
changing on CLI 23, 32 layer 3 mode 10
password hash for Cloud-Init 46 performance benchmarks 64
performance benchmarks 64 reinitializing 59
KVM virtual machine 67 supported interfaces 8
VMware virtual machine 66 VMware virtual network configuration 35
protection interfaces vAED license server
configuring 10 proxy server 58
proxy server viewing information 61
vAED license server 58 vAED licenses
about 54
Q AIF 55, 61
QEMU guest agent, using with KVM 21 configuring 57
configuring throughput limit 58
expiration 55
R overview 54
routes refresh manually 61
configuring on vAED 10 refreshing local licenses 59
deleting 10 releasing 59
status 56
S throughput 54, 60
services viewing information about 60
adding IP access rules 23, 33 virtual machine (vAED)
deleting IP access rules 23, 33 about 8
status Also see vAED 8
vAED licenses 56 installing on KVM 16
support, contacting 6 installing on VMware 26, 30
VMware
T configuring CPU settings for vAED 31
installing vAED on 26, 30
throughput performance benchmarks 66
enforcement on vAED 54 remapping virtual networks 35
limit, configuring for vAED 58 requirements for virtual network 28
viewing on vAED 60 vSphere
configuring CPU settings for vAED 31
U
user data file
creating for Cloud-Init 40, 47
password hash 46
supported Cloud-Init modules 41
user data file for Cloud-Init 38
V
vAED
about 8
accessing 13
configuring CPU settings in vSphere 31

End User License Agreement
The end user license agreement (EULA) contains updated terms and conditions with respect to
your license of NETSCOUT product and services and is deemed to replace any previous license
terms provided with respect thereto; provided, however, if you and NETSCOUT have executed a
direct agreement, such direct agreement shall govern your license of NETSCOUT product and
services.
To read the complete end user license agreement online, click one of the following links:
Links to the EULA

Products EULA link
Arbor APS, Arbor https://www.netscout.com/cloud-and-managed-services-eula
Sightline, and Arbor
Threat Mitigation
System
Arbor Edge Defense https://www.netscout.com/sites/default/files/2018-06/NetScout-

and Edge Defense Systems-End-User-Product-License-Agreement.pdf
Manager

Installation Guide: Virtual Arbor Edge Defense

Uploaded by

Copyright:

Available Formats

You might also like

Installation Guide: Virtual Arbor Edge Defense

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Installation Guide: Virtual Arbor Edge Defense

Uploaded by

Copyright:

Available Formats

Virtual Arbor Edge Defense

Section 1: Introduction to vAED

Section 2: Installing vAED on KVM

Section 3: Installing vAED on VMware

Section 4: Using Cloud-Init to Initialize vAED

Section 5: Licensing vAED

Appendix A: vAED Performance Benchmarks

End User License Agreement 71

vAED Installation Guide, Version 6.3.1 3

How to Use the Virtual Arbor Edge Defense Documentation 5

4 Proprietary and Confidential Information of NETSCOUT SYSTEMS, INC.

How to Use the Virtual Arbor Edge Defense

Proprietary and Confidential Information of NETSCOUT SYSTEMS, INC. 5

Contacting the Arbor Technical Assistance Center

n Phone worldwide — +1 781 362 4301

Submitting documentation comments

n Document number (listed on the reverse side of the title page)

vAED Installation Guide

6 Proprietary and Confidential Information of NETSCOUT SYSTEMS, INC.

vAED Installation Guide, Version 6.3.1 7

Unsupported features and functions

8 Proprietary and Confidential Information of NETSCOUT SYSTEMS, INC.

About the Layer 3 Deployment Mode

Changing the deployment mode from inline to layer 3

Changing the deployment mode from layer 3 to inline

Backing up and restoring data while in the layer 3 deployment mode

Proprietary and Confidential Information of NETSCOUT SYSTEMS, INC. 9

Configuring Static Routes for the Protection Interfaces on

Specifying an IP address for a protection interface on vAED

Adding a static route for a protection interface on vAED

10 Proprietary and Confidential Information of NETSCOUT SYSTEMS, INC.

Deleting the IP address for a protection interface on vAED

Deleting the routes for protection interfaces on vAED

To delete the routes for a protection interface:

Deleting all of the layer 3 interface settings on vAED

Proprietary and Confidential Information of NETSCOUT SYSTEMS, INC. 11

Deleting all of the layer 3 interface settings and routes on vAED

12 Proprietary and Confidential Information of NETSCOUT SYSTEMS, INC.

Accessing the vAED

n In a terminal window, enter ssh admin@IP_address

Proprietary and Confidential Information of NETSCOUT SYSTEMS, INC. 13

14 Proprietary and Confidential Information of NETSCOUT SYSTEMS, INC.

Preparing to Install vAED on KVM 16

vAED Installation Guide, Version 6.3.1 15

Preparing to Install vAED on KVM

Minimum system resources

n 100 GB hard disk space

With this minimum configuration, vAED can support up to 10 protection groups.

Enabling hardware virtualization on your CPU

Preparing to install vAED

1 Gather information to use when you configure vAED on KVM.

16 Proprietary and Confidential Information of NETSCOUT SYSTEMS, INC.

Preparing to install vAED (continued)

3 Install the following software, modules, and packages:

5 Configure the network bridges on KVM.

Configuration information to collect

Configuration information worksheet

Item Description Your setting