Professional Documents
Culture Documents
Preface
How to Use SP and TMS Documentation 8
Conventions Used in this Guide 9
Contacting the Arbor Technical Assistance Center 11
Appendixes
Appendix A: Configuring Flowspec Routers for Traffic Mitigation 261
Configuring a Juniper Router to Mitigate Traffic 262
Testing Flow Specification Mitigation 264
Appendix B: Configuring Flow and SNMP on Routers 267
About Configuring Flow Sources 268
Configuring Cisco IOS Routers to Send NetFlow to SP 269
Configuring Juniper Routers to Send Flow Monitoring to SP 273
Configuring Foundry, Alaxala, and Force10 Devices to Send sFlow to SP 279
Configuring Alcatel 7750 Routers to Send cFlowd Data to SP 285
Configuring SNMP on the Alcatel 7750 Router 288
Supported SNMP Polling with Alcatel 7750 Router 289
Configuring Routers to Send SNMP Information to SP 290
Glossary 295
Index 305
Introduction
The Arbor Networks® SP and TMS Advanced Configuration Guide includes instructions for
re-installation, upgrading, and additional optional configurations for your SP and TMS
appliances. The commands documented in the Advanced Configuration Guide do not
apply to TMS-ISAs or TMS-CGSEs. This guide supports the 8.4 release for all SP and TMS
appliances.
Audience
This information is intended for network security system administrators (or network
operators) who are responsible for configuring and managing SP on their networks.
Administrators should have fundamental knowledge of their network security policies and
network configuration.
In this section
This section contains the following topics:
Additional documentation
SP and TMS User Guide Instructions and information that explain how to
configure and use SP and TMS appliances and
software using the SP web user interface (UI).
SP and TMS Help Online help topics from the User Guide and
Advanced Configuration Guide. The Help is context-
sensitive to the SP web UI page from which it is
accessed.
SP and TMS API Guide Instructions for remotely accessing SP and TMS
using the REST, SOAP, and Arbor Web Services APIs.
SP REST API Documentation Online help topics about the SP REST API endpoints.
To open the help, select Administration >
REST API Documentation.
Monospaced A file name, folder name, path Type the server's IP address or
italics name, or other information hostname.
that you must supply.
Convention Description
Monospaced bold Information that you must type exactly as shown.
[ ] (square brackets) A set of choices for options or variables, any of which is optional.
For example: [variable1 | variable2].
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
Example
SP_TMS-ACG-84-2018/04
Page 9
Introduction
This section provides instructions for connecting to and using the Command Line
Interface (CLI). You can use the CLI to manually reinstall a appliance or to configure
advanced settings.
In this section
This section contains the following topics:
Note
On all MCM models, the Management Serial Port uses Cisco pinouts.
Note
Chassis-based TMS appliances include the TMS 4000 and the TMS 5000.
l For all other appliances: Plug one end of the serial cable into the serial port on
the back of the appliance.
2. Plug the other end of the serial cable into the serial port on your computer or laptop.
3. Connect the power cables for your appliance.
4. Turn on the appliance, and then start your computer.
Logging in
To log in to the appliance:
1. Turn on the appliance.
2. Start your terminal emulator.
3. At the login prompt, enter your user_name
4. Enter your password
Command
Mode Description Prompt
Edit Allows all configuration changes. The system starts in Hash mark (#)
edit mode automatically when an administrator logs in
to SP; they do not need to access a password to access
Edit mode.
Disabled Allows read-only access and minimal configuration Greater than sign
changes. Users without administrative privileges must (>)
enter edit mode to make configuration changes.
Command types
The following are the types of commands:
Using Help
The following are the types of Help commands:
Command Description
help Shows a list of the available choices within a directory.
Note
You can view the configuration from anywhere in the CLI.
Note
You can view the system status from most directories within the CLI. The results you see
represent the state of what the current directory is used to configure.
configuration ensures that the current changes take effect immediately and preserves the
configuration if the system is rebooted.
Introduction
This section describes how to configure your SP deployment.
In this section
This section contains the following topics:
Ports Used by SP 24
Auto-discovering Your Local Address Space 28
Adding a Whois Resolution Server 30
Configuring DNS Servers 31
Configuring NTP Servers 34
Setting the AIF Server Address 37
Importing AIF Signatures 38
Automatically Configuring a TMS Model for the Management Network 39
Add New TMS Models to the Appliance List without Upgrading SP 44
Replacing an SP Appliance with an RMA Replacement 46
Replacing a TMS Appliance with an RMA Replacement 49
Ports Used by SP
Introduction
SP uses specific ports for each of the services it utilizes.
References in this table to the FS appliance (Flow Sensor) only apply to appliance-based
licensing.
ArborFlow (if 5000 (default) UDP n TMS appliance to traffic and routing analysis
ArborFlow from
TMS is enabled)
SNMP polling of 161 UDP n Traffic and routing analysis query to router
routers n FS appliance query to router
n Router response to appliance
Note
Some of these ports may not be applicable to your deployment.
Optional ports
The following ports are optional and only need to be enabled if you are using the
corresponding service:
SNMP trap 162 UDP n Leader appliance message to SNMP trap collector
A web proxy server helps keep SP from making direct calls out to the internet yet lets SP
communicate with ATLAS services where needed. Direct connectivity from an SP device
to the ATLAS services is also supported.
n You should allow your proxy server to talk to the internet only on port 443 for calls from
the SP device.
n You should rely upon DNS to provide service resolution of name to IP address to
ensure availability for requests.
If an ATLAS service cannot connect to the service address, you may need to check the
current DNS results for the addresses listed in the following table and update your
firewall rules.
n You should make sure your Arbor SP client certificate is not expired as it is required to
protect the internet communication between the SP device and the ATLAS services.
Note
If you are faced with security constraints that limit your ability to follow the preceding
recommendations, please open a case with the Arbor Technical Assistance Center (ATAC)
for further review:
n Web: https://support.arbornetworks.com via the ATAC Customer Support Portal
HTTP proxy (If you your HTTP proxy server 1080 TCP Leader to the
configure a proxy to (configurable) proxy server
reach out to ATLAS
services or the internet)
For information on customizing the IRR server used to autodiscover your address space,
see “Changing the Internet Routing Registry server” below.
Note
SP only supports querying servers that respond to RIPE argument syntax as described at
http://www.radb.net/tutorials/query2.php.
To change the IRR server:
1. Log in to the SP leader appliance’s CLI using the administrator user name and
password.
2. Enter / services sp auto-config irr ip_address setIP_address
3. Enter config write
For more information about peering evaluation, see “Using the Peering Evaluation Tool” in
the SP and TMS User Guide .
Example
The following example shows how to add a Whois server with the IP address 10.1.2.3:
admin@mariner1:/# services sp preferences whois
admin@mariner1:/services/sp/preferences/whois/# show
Whois servers:
User configured:
Default: whois.arin.net whois.ripe.net whois.apnic.net
admin@mariner1:/services/sp/preferences/whois/# add 10.1.2.3
admin@mariner1:/services/sp/preferences/whois/# config write
You can also add DNS servers to a global configuration on the Configure Network Services
page (Administration > System Maintenance > Network Services ) of your SP
leader appliance.
For information about configuring global DNS servers on the Configure Network Services
page, see “Configuring Network Services” in the SP and TMS User Guide .
n If you want individual appliances to use different DNS servers, use a local configuration.
The following are some additional guidelines for adding a DNS server to a local or global
configuration:
n If you add a DNS server to a local configuration, you can then add the DNS server to a
global configuration on that appliance without first deleting the local configuration. If
you then delete the DNS server from the global configuration, the local configuration is
restored.
n If a DNS server has been added to a global configuration, then you cannot add the DNS
server to a local configuration.
Note
When you add a DNS server to a global configuration or delete a DNS server from a
global configuration, the global servers do not get added or deleted until you commit the
configuration changes. However, when you add a DNS server to a local configuration or
delete a DNS server from a local configuration, the change takes place immediately.
You can also add NTP servers to a global configuration on the Configure Network Services
page (Administration > System Maintenance > Network Services ) of your SP
leader appliance.
For information about configuring global NTP servers on the Configure Network Services
page, see “Configuring Network Services” in the SP and TMS User Guide .
n If you want individual appliances to use different NTP servers, use a local configuration.
The following are some additional guidelines for adding an NTP server to a local or global
configuration:
n If you add an NTP server to a local configuration, you can then add the NTP server to a
global configuration on that appliance without first deleting the local configuration. If
you then delete the NTP server from the global configuration, the local configuration is
restored.
n If an NTP server has been added to a global configuration, then you cannot add the
NTP server to a local configuration.
Note
When you add an NTP server to a global configuration or delete an NTP server from a
global configuration, the global servers do not get added or deleted until you commit the
configuration changes. However, when you add an NTP server to a local configuration or
delete an NTP server from a local configuration, the change takes place immediately.
You can configure all of the other AIF standard feed settings in the web UI on the ATLAS
Intelligence Feed tab of the Configure ATLAS Services page (Administration > ATLAS).
After ZTP automatically configures the TMS model, the system boots up on the
management network. You can then remotely log in to the SP web UI or the TMS model’s
command line interface (CLI) and add the TMS model to your SP/TMS deployment.
ZTP can configure a TMS model for an IPv4 or IPv6 management network. However, to use
ZTP, the TMS model must be connected to a management network that supports IPv4.
Note
For information about manual initial configuration, and for information about adding a
TMS model to your deployment, see Adding, Editing, and Deleting a TMS Model.
See “Prerequisites for Zero Touch Provisioning on a TMS model” on the next page.
Unlike manual initial configuration, with ZTP, you create a startup configuration file for the
TMS model in a text editor. You store that file on a network file server. Next, you configure
the file’s location on a DHCP server. Then, if the TMS model boots up with no initial
configuration, ZTP queries the DHCP server to locate the predefined configuration file for
that model. ZTP then downloads, applies, and saves that configuration file.
See “How ZTP automatically configures a TMS model for the management network”
below.
When the TMS model boots up, it runs the commands in the startup configuration file.
These commands configure the TMS model for the management network.
How ZTP automatically configures a TMS model for the management network
When you boot a TMS model that has no startup configuration file, ZTP automatically
performs the following tasks:
1. Asks the DHCP server to provide the “bootfile-name” parameter (DHCP option 67) for
the TMS model. The bootfile-name specifies the URL for the ZTP configuration file that
was created for the TMS model.
See “Creating a ZTP configuration file” on page 41.
2. Receives the URL for the ZTP configuration file in the bootfile-name parameter sent
from the DHCP server.
3. Downloads the ZTP configuration file from the file server at the specified URL using
HTTP, FTP, or TFTP.
4. Saves the downloaded ZTP configuration file to disk as the new startup configuration
file.
5. Runs the commands in the new startup configuration file to configure
communications with the management network.
6. Finishes booting up.
Since TMS models ship without a startup configuration file, ZTP runs on the first boot after
a new or replacement TMS model is installed. ZTP also runs the first time you boot a TMS
model after its startup configuration was manually cleared.
ZTP will not run on boot if a startup configuration exists on the TMS model. If no startup
configuration exists on a TMS model, but you do not want ZTP to run on boot, see
“Disabling ZTP on a TMS model” on page 42.
If the management network configuration changes, you might need to update the startup
configuration file on the TMS model. See “Updating the startup configuration file on a
TMS model using ZTP ” on page 42.
n fixed-address: The temporary IP address for the TMS model. ZTP uses this address
communicate with the DHCP server, and to download the ZTP configuration file from
the URL that the DHCP server provides. Once the TMS applies the ZTP configuration file,
it stops using this temporary IP address and uses the network settings in the ZTP
configuration file instead.
n option bootfile-name: The URL of the ZTP configuration file to download. The URL
can use HTTP, FTP, or TFTP.
The following is an example of a Linux DHCP server configuration file that supports ZTP on
a TMS model with the host name TMS-01. The ZTP configuration file name is
TMS-01.config.
subnet 198.51.100.0 netmask 255.255.255.0 {
# Standard gateway / mask setup.
option routers 198.51.100.1;
option subnet-mask 255.255.255.0;
host TMS-01 {
hardware ethernet 00-00-5E-FE-CB-00-71-FF;
fixed-address 198.51.100.25;
option bootfile-name "http://198.51.100.32/TMS-01.config";
For example, you can modify the IP addresses or host names in the commands in a
ZTP configuration file. However, you should only add commands which can be
exported from a valid TMS startup configuration file. There is one exception: You can
add the TMS bootstrap command, which is not an exported command.
See “Connecting to the SP leader on boot-up” below.
Caution
Except for the TMS bootstrap command, Arbor only supports exportable
configuration commands in ZTP configuration files. Adding commands that are not
exportable can cause boot errors or boot failure.
If you want the TMS model to connect to its SP leader on boot up, add the following TMS
bootstrap command the end of the ZTP configuration file, just before the
/ services tms start command:
/ services tms bootstrap leader_ipzone_secret
For example:
/ services tms bootstrap 198.51.100.5 f006arV31tas
/ services tms start
2. (If required) Update the ZTP configuration file to reflect the changes in the
management network.
See “Creating a ZTP configuration file” on page 41.
3. Log in to the CLI for the TMS model.
4. Enter the command / config clear
This clears the startup configuration for the TMS model so that ZTP will run the next
time that the TMS boots up.
5. Reboot the TMS model to locate, download, and save the updated ZTP configuration
file as the new startup configuration file.
6. To view the new TMS models on the updated Appliance list, do the following:
a. Log in to the SP web UI on the target SP appliance and navigate to the Configure
Appliances page (Administration > Appliances).
b. Click Add Appliance.
c. On the Appliance tab, click the Appliance list. Scroll down the list to view the new
TMS models.
7. (Optional) To configure a new TMS model for your deployment, see “Adding, Editing,
and Deleting a TMS Model” in the Arbor Networks SP and TMS User Guide .
Note
You can create an incremental backup if you already have a full backup. An
incremental backup includes only the changes that have occurred since the last full
backup.
3. If SP is not installed on the new appliance, install the same version of the software that
was installed on the old appliance along with any patches that were installed on the
old appliance. See “Reinstalling SP Appliance Software” on page 146.
The patches must include any hand patches that were installed on the old appliance.
Note
The RMA replacement appliance should come with the correct version of SP
installed.
4. Perform the initial configuration of the SP software using the instructions in the
appliance’s Quick Start Card. You can access the Quick Start Card at
https://support.arbornetworks.com.
Important
Make sure all of these initial configuration settings on the new appliance are the
same as those on the old appliance. This includes performing a bootstrap if you
want to restore the appliance using the web UI.
5. Disconnect the old appliance from the network and connect the new appliance.
6. On the new appliance, do one of the following to import and restore the backup from
the remote server:
l In the web UI of the new appliance, on the Managed Backups page
(Administration > System Maintenance > Backups ), perform tasks to import
and restore the backup. See “Managing System Backups” in the SP and TMS User
Guide .
Important
If you restore the full backup, the IP interface, IP access, and IP route settings will
no longer be correct. Make sure to configure these settings on the new appliance
so that they are the same as those on the old appliance. For information about
how to configure these settings, see the appliance's Quick Start Card at
https://support.arbornetworks.com.
l In the CLI of the new appliance, use the following CLI commands to import and
restore the backup (the first command imports a full backup and the second
command imports an incremental backup):
/ services sp backup import full scp://user@host/path/ password
/ services sp backup import incremental scp://user@host/path/
password
/ service sp backup restore skip_arbos
user = the user name that is required to access the remote server
host = the IP address of the remote server
path = the directory path to where you want to export the backup on the
remote server
password = the password that is required to access the remote server
7. If the old appliance had appliance-based licensing, log in to the web UI of the leader
appliance and apply the new appliance’s license.
Note
Contact ATAC if you need help with this RMA replacement procedure. See “Contacting
the Arbor Technical Assistance Center” on page 11.
2 Export and copy the old appliance’s TMS See “Exporting and copying the
configuration settings to the backup server. old TMS configuration settings”
on the next page.
3 Back up the TMS data on the old appliance See “Backing up the TMS data
to the backup server. stored on the old appliance” on
the next page.
4 Connect the new appliance and perform an See “Connecting and configuring
initial configuration on the new appliance. the new appliance” on page 52.
5 Restore the old appliance’s TMS data from See “Restoring the old TMS data
the backup server to the new appliance. from backup to the new
appliance” on page 53.
6 Copy and import the old appliance’s TMS See “Copying and importing the
configuration settings to the new appliance, old configuration settings to the
and then reboot the new appliance. new appliance” on page 53.
7 Restart and bootstrap the new appliance, See “Restarting and configuring
and then configure administrative settings the new appliance on the SP
for the new appliance on the SP leader. leader” on page 54.
For help accessing the TMS CLI and entering CLI commands, see “Using the Command
Line Interface (CLI)” on page 13.
Note
Contact ATAC if you need help determining which hand patches are installed on the
old appliance. See “Contacting the Arbor Technical Assistance Center” on page 11.
3. Set the URL for the storage path that you created on the backup server.
Enter / services backup server set {backupURL|interactive|local}
backupURL = the URL for the storage path on the backup server. Use the following
syntax to specify the backupURL:
transport://[user:password@]server[:port]//storagepath
transport = the transport protocol: scp, sftp, ssh, or ftp
user:password = the username and password for the backup server
server = the backup server’s hostname, IPv4 address (A.B.C.D), or IPv6
address (aaaa:bbbb::cccc)
port = the port number for the backup server
storagepath = the relative or absolute storage path that you created on the
backup server. Use two forward slashes (//) before storagepath as shown if
the path is absolute. Use a single forward slash ( / ) before storagepath. if
the backup path is relative to a working directory such as /home.
(Optional) Enter interactive instead of the backupURL to have the CLI prompt
you for the URL components:
Backup server address = the server IP address in IPv4 or IPv6 format
Backup transport (scp, sftp, ssh, or ftp) = the transport protocol
Backup storage path on server = the relative or absolute storage path
on the backup server
Backup server username = the username for the backup server
Backup server password = the password for the backup server
After you enter the password, enter y to save your entries and to set the backup
URL, or press ENTER to exit without saving and setting the backup URL.
Caution
Enter either the backupURL or the interactive option only. Do not enter the
local option. If you use the local option, the TMS data will be backed up to the
disk in the old appliance instead of the backup server.
4. (Optional; recommended) Show the backup URL and verify that the storage path was
created correctly.
Enter / services backup show
In the output, under Backup Configuration, the Server should match the backup
URL that you set in the previous step.
5. Back up the TMS data stored on the old appliance to the backup URL.
Enter / services backup create [full | incremental]
If this is the first backup of the old appliance to the backup URL that you set in Step 3,
create a full backup. If you backed up the old appliance to this URL previously, you can
create an incremental backup to save time.
6. (Optional; recommended) Show the status of the backup.
Enter / services backup show
When the backup completes, the Backup Status in the output should show backup
succeeded.
To connect the new appliance to the network, and then perform an initial configuration of
the TMS software on the new appliance:
1. Log in to the CLI of the new appliance with the username admin and the password
arbor.
2. Verify that the new appliance has the same software versions installed as the old
appliance.
Enter / system files show.
Compare the version numbers for all installed software packages to those for the old
appliance that you noted in Step 2 under “Backing up the TMS data stored on the old
appliance” on page 50.
3. If the software installed on the new appliance does not match the software installed
on the old appliance, you must install the matching software versions on the new
appliance. For instructions, see “Reinstalling TMS Software on a Chassis-based TMS
Appliance” on page 155 .
Important
The software installation for the new appliance must include all of the hand patches
that were installed on the old appliance.
4. If the new appliance contains the same software versions as the old appliance,
connect the new appliance to the network. For connection instructions, see the Quick
Start Card for the new appliance.
Important
You must, at minimum, connect the management interface port on the new
appliance.
5. Perform the initial configuration of the TMS software on the new appliance. For initial
configuration instructions, see the Quick Start Card for the new appliance.
Important
Do not configure the administrative settings for the new appliance on the SP leader
yet. You will do this later in “Restarting and configuring the new appliance on the SP
leader” on the next page.
Restoring the old TMS data from backup to the new appliance
Important
You must connect and initially configure the new appliance before you perform this
restore procedure. See “Connecting and configuring the new appliance” on the previous
page.
To restore the old appliance TMS data files on the backup server to the new appliance:
1. Log in to the CLI of the new appliance.
2. Specify the storage path on the backup server to restore from:
Enter / services backup server set {backupURL|interactive|local}
Specify the same backupURL value that you entered in Step 3 under “Backing up the
TMS data stored on the old appliance” on page 50 .
3. (Optional) Verify that the backup URL was specified correctly.
Enter / services backup show
In the output, under Backup Configuration, the Server should match the backup
URL that you set in Step 2.
4. (Optional) Verify that the backup that you want restore exists.
Enter / services backup list
The list of Available Backups in the output should show the information for the
backup that you want to restore from. The list should also show the timestamp
indicating when the backup was created.
5. Restore the old appliance backup data files to the new appliance:
Enter / services backup restore [timestamp]
timestamp = the timestamp of the backup to restore from. Omit the timestamp to
restore from the most recent backup.
6. (Optional) Check the status of the restore process.
Enter / services backup show
When the restore process completes, the Backup Status in the output should show
restore succeeded.
Copying and importing the old configuration settings to the new appliance
To copy oldTMS.conf from the backup server to the disk on the new appliance, and then
import the configuration settings in oldTMS.conf to working memory on the new
appliance:
1. Log in to the CLI of the new appliance.
2. Copy the oldTMS.conf file from the backup server to the disk on the new appliance:
Enter / system files copy backupURL/oldTMS.conf disk:[oldTMS.conf]
Specify the same backupURL value that you entered in Step 3 under “Exporting and
copying the old TMS configuration settings” on page 50.
3. Import the old TMS configuration settings in the disk file oldTMS.conf to working
Introduction
This section describes how to secure your SP appliances.
In this section
This section contains the following topics:
The following are some basic tactics for securing your Arbor Networks appliances:
n Set IP access rules appropriately to ensure that only the IP networks used by system
users can access the system.
l Prevent system intrusion via compromised user credentials by denying a login
prompt to potential attackers.
l Use more restrictive rules for services such as SSH or SNMP that might need access
from fewer networks than the HTTPS user interface.
l Do not permit access from 0.0.0.0/0 unless absolutely necessary.
n Use centralized authentication services for your organization instead of local user
accounts whenever possible, using TACACS+ or RADIUS protocols for integration.
l Implementing centralized authentication services can reduce the forgotten
passwords and password resets for users who infrequently access an Arbor
appliance, because passwords for general users are the same as those used daily
elsewhere in the organization.
l Arbor recommends maintaining a least one local user account, which can be used to
access the system in the event that RADIUS or TACACS+ servers become inaccessible
via the network.
n Use long and complex passwords whenever local user accounts are necessary on an
Arbor appliance.
l Generally, longer passwords are more secure. Arbor appliances support passwords
up to 72 characters long.
l Mix different classes of characters in a password. Use uppercase and lowercase
letters, numbers, and special characters.
n Physically secure your Arbor appliances to prevent them from being disabled or
otherwise compromised.
Open ports only to For example, if 5.5.5.5/32 and 10.10.10.0/24 are known CIDR
known CIDR blocks blocks and are considered safe, you can open IP access to these
and only to specific, hosts, as follows:
trusted networks / ip access add ssh eth0 5.5.5.5/32
or hosts. / ip access add ssh eth0 10.10.10.0/24
/ ip access add https eth0 5.5.5.5/32
/ ip access add https eth0 10.10.10.0/24
/ ip access add ping eth0 5.5.5.5/32
/ ip access add ping eth0 10.10.10.0/24
/ ip access commit
/ config write
Important
Do not open traffic to 0.0.0.0/0, and if you must open traffic to
0.0.0.0/0 never open SSH or HTTP(S) for 0.0.0.0/0.
Use TACACS+ or You can configure the TACACS+ and RADIUS account settings in
RADIUS to control the web UI on the Configuring Accounting page (Administration
logins. > Accounts/Accounting > TACACS+/RADIUS Accounting ).
You configure SP to integrate with your existing TACACS+ and
RADIUS servers to authenticate users on the Configure
Authentication page (Administration > Accounts/Accounting
> TACACS+/RADIUS Authentication). See “Configuring
Accounting” and “Configuring Authentication” in the SP and TMS
User Guide .
Note
You can configure BIOS settings by pressing F2 during the boot sequence.
Example
The following example shows how to add the question, “Do you agree to be bound by the
access terms specified?” and allow access to users who reply “yes.”
admin@mariner1:/# system banner acknowledge ?
set Set system banner acknowledgment question
clear Clear system banner acknowledgment question
enable Enable system banner acknowledgment
disable Disable system banner acknowledgment
admin@mariner1:/system/banner/acknowledge# banner acknowledge set “Do
you agree to be bound by the access terms specified” yes no
admin@mariner1:/# / system banner acknowledge enable
admin@mariner1:/#
Administrators can also enable password hardening to add additional login security.
When you enable password hardening, passwords must meet the following criteria:
n contain at least one number and one letter
n cannot contain the user name in any form (upper case or lower case)
After you configure these password settings, if a user tries to add a password that does
not meet the criteria, an error appears and the password is not set.
Note
After you configure these password settings, they apply to the creation of new
passwords. They do not apply to passwords that have already been created.
Example
The following example shows how to reset an SP password:
boot> cdrom
Booting from CD-ROM-
ArbOS/6.2 (arbos)
login: admin
Password: **********
ArbOS 6.2 (build xxxx)
Copyright (c) 2000-2013 Arbor Networks, Inc. All Rights Reserved.
Welcome to Peakflow
SP/8.4 (mariner)
login: admin
Password: **********
Last login: CLI on Wed Oct 26 21:17:01 2013 from console
SP v8.4
Copyright (c) 2000-2013 Arbor Networks, Inc. All Rights Reserved.
Welcome to Peakflow
Introduction
This section describes how to use the CLI commands to configure advanced SP appliance
settings.
In this section
This section contains the following topics:
Note
Cloud-based flexible licensing requires regular contact with our license server to function
correctly. It uses the standard HTTPS port 443. If you are behind a firewall, Arbor
recommends that you use a proxy server. If a proxy server is not available, you can make
an ACL change to allow the leader to connect to port 443. For information about
configuring HTTP proxy settings, see "Configuring Network Services" in the SP and TMS
User Guide .
For information about using CLI commands, see “Using CLI Commands” on page 16 .
After one to three minutes, you can also view the status of the license in the Cloud-based
License section on the Deployment Status page (System > Status > Deployment
Status) in the SP web UI.
If you are unable to resolve the problems that are preventing SP from communicating with
the license server, contact the Arbor Technical Assistance Center (ATAC) for assistance. For
information about contacting ATAC, see “Contacting the Arbor Technical Assistance
Center” on page 11.
The following are examples of when you might want to override the default FPS limit for
flow:
n To lower the limit to resolve performance issues that are caused by too much flow
being received by an SP appliance
n To increase the limit to avoid or decrease the sub-sampling of flow that is occurring on
an SP appliance
Warning
If the FPS limit is raised above the default value, it could result in an appliance overload
and the loss of data.
To override the default FPS limit for flow, see “Overriding the FPS limit for flow on an SP
appliance” on the next page.
The following table lists the default FPS limits for flow for each type of appliance:
Teeing NetFlow
Introduction
You can use the tee feature to duplicate the NetFlow™ records that your SP appliance
receives and then forward the duplicated records to another IP address.
Example
The following example shows how to tee NetFlow from port 111 on 192.168.1.1 and send
it to port 222 on 198.168.1.2. It then shows how to start the tee and test it.
admin@mariner1:/# / ip tee ?
Subcommands:
add Add a NetFlow tee rule
counter Show or reset NetFlow tee counters
delete Delete a NetFlow tee rule
show Show NetFlow tee configuration
start Start the NetFlow tee
stop Stop the NetFlow tee
admin@mariner1:/ip/tee# add ?
[A.B.C.D]:[1-65535] Source address:Destination port
admin@mariner1:/ip/tee# add 192.168.1.1:111 198.168.1.2:222
admin@mariner1:/ip/tee# start
admin@mariner1:/ip/tee# counter ?
status
reset
[cr]
admin@mariner1:/ip/tee# counter
Rule evaluations failed: 9109
Interface output failures: 0
tee 192.168.1.1:111 to 168.1.2:222 - passed: 9259
admin@mariner1:/ip/tee# config write
admin@mariner1:/ip/tee#
Warning
You cannot re-enable access after you disable it. You should consult with your Arbor
Networks Consulting Engineer or contact ATAC (Arbor Technical Assistance Center)
before you complete this procedure. See “Contacting the Arbor Technical Assistance
Center” on page 11.
Example
The following example shows how to disable access to the shell:
admin@mariner1:/# / system attribute set appliance.enabled = 1
admin@mariner1:/# / sys appliance
enable Enable appliance mode
<cr>
admin@mariner1:/# / sys appliance
Appliance mode: disabled
admin@mariner1:/# / sys appliance enable
By enabling appliance mode, you will permanently remove the shell
capability.
Are you sure you want to permanently remove the shell capability? [no] yes
Answer again to proceed [no] yes
Appliance mode enabled
admin@mariner1:/# / shell
121: Shell access is prohibited with appliance mode enable
admin@mariner1:/# / sys appliance
Appliance mode: enabled
For information about generating or viewing a raw flows report for a DoS alert, see “About
the Summary Tab” on a DoS Alert Page in the SP and TMS User Guide .
You can use CLI commands to configure settings that determine the rate at which raw
flows are captured and the amount of hard disk space that captured raw flows can use.
These settings are configured on a per appliance basis and can be configured on any of
the collector appliances in your SP deployment.
Use cases for modifying the settings for capturing raw flows
The following use cases are examples of when you might want to modify the default
settings for capturing raw flows:
n More detailed raw flows data is needed
You are under a long-running attack, and you want more detailed data about the
attack. You then change the sampling rate from the default rate of 100 to a rate that
captures more raw flows. For example, you can change the rate to 50, which captures 1
flow record for every 50 raw flows.
n Raw flows data is not relevant
The raw flows data is not relevant to you, and you want to reduce the amount of hard
disk space that can be used for writing the captured raw flows to the disk. You then
reduce the disk suspend setting and the maximum disk usage setting.
50 K 100 62 MB 1.5 GB 10 GB
200 K 50 430 MB 10 GB 70 GB
Command Setting
raw_flows disk max show maximum disk usage
3. To clear all of the settings for capturing raw flows and revert to the default values,
enter / services sp device edit collector_name raw_flows clear
collector_name = the name of the collector appliance
You can also use the following command arguments in place of raw_flows clear to
clear specific settings for capturing raw flows:
Command Setting
raw_flows disk max clear maximum disk usage
Caution
You should perform this procedure only if instructed to do so by your SE or an Arbor
Technical Assistance Center representative. Resetting the alert database permanently
removes all alerts, mitigations, and associated data from your SP system.
The maximum size that you should set for the BGP shared memory is 2048 megabytes
(MB), which supports the guideline limit of 25 million steady-state BGP routes. The
minimum size that you should set for the BGP shared memory is 500 megabytes (MB). If
you set the size too small, the system might become unstable.
Introduction
This section describes how to use the CLI commands to configure advanced TMS Model
settings.
In this section
This section contains the following topics:
Important
You can only put a physical interface into promiscuous mode on a TMS appliance that is
in the diversion mode.
When triggered, the Performance Alert displays a message like the following example:
System oversubscribed: offered rate exceeded processed rate by 5%;
offered rate = 6.48 Gbps / 764.84 Kpps
Important
Enabling or disabling the Performance Alert also enables or disables the TMS Fault - Rate
Limit alert. Therefore, like Performance Alert, the Rate Limit alert is disabled by default.
See "Rate Limit 'Licensed Limit' is 'Over Limit'" in the SP and TMS User Guide.
For a longer-term correction, you can purchase license upgrades for appliance-licensed
TMS model rate limits or flexible-licensed Software TMS bandwidth capacity. You can also
purchase additional TMS models.
Note
You can also use the tms-traceroute command to troubleshoot network connectivity
in your SP/TMS diversion deployment. See “Running a Traceroute Command from a TMS
Port” on page 93.
About tms-ping
With tms-ping, you can ping a nexthop for a physical or logical TMS interface or
subinterface. The nexthop is the destination in the echo request sent by tms-ping. You
specify the destination to ping using the nexthop’s DNS hostname or its IPv4 or IPv6
address.
You can optionally specify a TMS interface or subinterface as the source interface. This
interface is the source of the echo request sent by tms-ping (...the interface that you “ping
from”). In the tms-ping command, you specify the source interface by name. For
example, the source name can be the name of an output port that is configured for a TMS
interface or subinterface.
If you ping a nexthop’s DNS hostname, you can tell the tms-ping command to ping either
the IPv4 address or the IPv6 address for that hostname. This is useful when the host’s DNS
resource record contains both an IPv4 host address and an IPv6 address.
See Configuring Deployment Settings for a TMS Appliance, Software TMS, TMS-ISA, or
Cisco ASR 9000 vDDoS Protection Model.
The standard ping command cannot ping from a TMS mitigation interface while TMS
services are running, but tms-ping can. However, tms-ping cannot ping from any TMS
management interface. Instead, use the standard ping command to ping from a
management interface.
include ipv4 to ping the IPv4 address for a DNS host. If you omit this keyword,
the command pings the IPv6 address of the DNS host by default.
Note
If you ping a DNS host named “ipv4” or “ipv6”, include this
keyword to ping the intended IPv4 or IPv6 address.
hostname|v4addr|v6addr = the nexthop to ping. You can specify the nexthop
to ping by its DNS hostname, its IPv4 address (A.B.C.D). or its IPv6 address
(aaaa:bbbb:...).
source_intf = the name of the TMS mitigation interface to ping from. This can
be the name of a physical or logical mitigation interface or subinterface. For
example, source_intf can be an interface name such as tms2, tms0.4, or
logical0. Or, it can be a subinterface name such as tms2.3, tms0.4.1, or
logical0.1. If you do not specify an interface or subinterface name, the TMS
automatically selects an interface to ping from.
Note
A subinterface name is the parent interface name with a “.n”
suffix. The “n” is the VLAN ID number (or “VLAN tag”) for the
subinterface. See Configuring Subinterfaces for a TMS
Appliance or Cisco ASR 9000 vDDoS Protection Model.
number = the number of ping attempts.
See Configuring Patch Panel Settings for a TMS Appliance, Software TMS, or Cisco ASR
9000 vDDoS Protection Model.
If several interfaces have the same nexthop address, use source_intf in the tms-ping
command to specify the name of the interface or subinterface to ping from. You can also
use source_intf to ping the nexthop from the Output Port that is configured for a TMS
interface or subinterface.
For example, on a TMS HD1000 appliance, suppose the interface tms0.0 is configured with
the IPv4 Nexthop address 192.0.2.100 and the Output Port is assigned to
subinterface tms0.1.100. To ping the IPv4 nexthop for tms0.0 from the output port
tms0.1.100, enter the following command:
/ services tms tms-ping 192.0.2.100 tms0.1.100
See About layer 3 forwarding and Configuring IP Forwarding Settings for a TMS
Appliance.
For example, to ping the Nexthop address 192.0.2.101 on the IPv4 Forwarding tab
from the TMS interface tms2, enter the following command:
Note
You can also use the tms-ping command to troubleshoot network connectivity in your
SP/TMS diversion deployment. See “Pinging a Nexthop from a TMS Appliance” on
page 90.
About tms-traceroute
With tms-traceroute, you can trace a route to a destination host from a physical or
logical TMS interface or subinterface. You specify the destination host using its DNS
hostname or its IPv4 or IPv6 address.
You can optionally specify a physical or logical TMS interface or subinterface as the source
interface for the trace. The route trace starts at the source interface. In the
tms-traceroute command, you specify the source interface by name. For example, the
source interface name can be the name of an output port that is configured for a TMS
interface or subinterface.
If you trace a route to a DNS host, you can tell the tms-traceroute command to use
either the IPv4 address or the IPv6 address for that DNS host. This is useful when the
host’s DNS resource record contains both an IPv4 host address and an IPv6 address.
See “To trace a route from a TMS port using tms-traceroute” on the next page.
See Configuring Deployment Settings for a TMS Appliance, Software TMS, TMS-ISA, or
Cisco ASR 9000 vDDoS Protection Model.
In Layer 3 forwarding mode, tms-traceroute can trace routes with multiple hops to
destinations in different subnetworks. However, in Patch Panel forwarding mode,
tms-traceroute can only trace single-hop routes to destinations in the same
subnetwork as the source interface. Therefore, tms-traceroute provides the same
information as the tms-ping command in Patch Panel forwarding mode. Specifically, it
shows the elapsed time for packets to reach a single destination.
See “Example: Using tms-ping in Patch Panel forwarding mode” on page 91.
The standard traceroute command cannot trace a route from a TMS mitigation interface
while TMS services are running, but tms-traceroute can. However, tms-traceroute
cannot trace a route from any TMS management interface. Instead, use the standard
traceroute command to trace a route from a management interface.
Note
If you trace a route to a DNS host named “ipv4” or “ipv6”,
include this keyword to trace a route to the intended IPv4 or
IPv6 address.
hostname|v4addr|v6addr = the destination of the route to trace. You can
specify the destination by its hostname, its IPv4 address (A.B.C.D). or its IPv6
address (aaaa:bbbb:...).
source_intf = the name of the TMS mitigation interface from which the route
trace starts. This can be the name of a physical or logical mitigation interface or
subinterface. For example, source_intf can be an interface name such as tms2,
tms0.4, or logical0. Or, it can be a subinterface name such as tms2.3,
tms0.4.1, or logical0.1. If you do not specify an interface or subinterface
name, the TMS automatically selects the interface where the route starts.
Note
A subinterface name is the parent interface name with a “.n”
suffix. The “n” is the VLAN ID number (or “VLAN tag”) for the
subinterface. See Configuring Subinterfaces for a TMS
Appliance or Cisco ASR 9000 vDDoS Protection Model.
In Patch Panel forwarding mode, you can trace a route to any destination that is in the
same subnetwork as the source interface. For example, you can trace a route to an IPv4
Nexthop or IPv6 Nexthop from any configured TMS interface or subinterface on the
Patch Panel tab.
See Configuring Patch Panel Settings for a TMS Appliance, Software TMS, or Cisco ASR
9000 vDDoS Protection Model.
You can optionally use source_intf in the tms-traceroute command to specify the
name of the interface or subinterface where the route trace starts. You can also use
source_intf to start a route trace from the Output Port that is configured for a TMS
interface or subinterface.
For example, on a TMS HD1000 appliance, suppose the interface tms0.0 is configured with
the IPv4 Nexthop address 192.0.2.100 and the Output Port is assigned to
subinterface tms0.1.100. To trace a route to the IPv4 nexthop for tms0.0 from the output
port tms0.1.100, enter the following command:
/ services tms tms-traceroute 192.0.2.100 tms0.1.100
the last “n” number / services tms deployment bgp show number
of BGP number = the number of most recent BGP announcements
announcements that you want to view (The default is 20.)
Note
Chassis-based TMS appliances include the TMS 4000 and the TMS 5000.
On the TMS 4000 and 5000 appliances, the valid APM slot numbers are 3, 4, 5, and 6.
Important
Consult with your SE or Arbor Technical Assistance Center before using the commands
listed in this topic. See “Contacting the Arbor Technical Assistance Center” on page 11.
Commands
You can log in to the CLI for a chassis-based TMS appliance and use the following
commands to view and change the slot activation status:
Action Command
View the activation status of all populated APM slots / system hardware slot
in the appliance.
(TMS 4000 appliances only) Reboots all APMs in the / system hardware slot
appliance and then shows the activation status of rescan
all populated APM slots.
Show the activation status of the specified slot. / system hardware slot
slot-number
(TMS 4000 appliances only) Reboots the APM in the / system hardware slot
specified slot and then shows the activation status slot-number rescan
of the specified slot.
Examples
The following are examples of the CLI commands for viewing or changing the APM slot
activation status for the chassis-based TMS appliances.
n To show the activation status for all populated APM slots in a TMS 4000 appliance:
For CLI instructions, see “Using the Command Line Interface (CLI)” on page 13 .
To clear the counters for all interfaces, you can use a CLI command or you can reboot the
TMS appliance. However, to clear the counters for only one interface, you must use a CLI
command.
Note
Restarting the TMS service (using the CLI commands / services tms stop and then
/ services tms start) clears all mitigation interface counters but does not clear
management interfaces.
See “Viewing SFP module information for a TMS 2300-series appliance” below.
For CLI instructions, see “Using the Command Line Interface (CLI)” on page 13 .
You configure SFP and SFP+ modules as mitigation ports on a TMS 2300 series appliance.
SFP+ modules provide about ten times the throughput of SFP modules. Each 1-Gigabit
Ethernet (1GE) SFP module provides up to 1 Gbps of mitigation capacity. Each 10GE SFP+
module provides up to 10 Gbps of mitigation capacity.
Important
The total mitigation capacity for a TMS 2300-series appliance might be less than the sum
of the capacities of its individual SFP or SFP+ modules. This is because the total mitigation
capacity of an appliance depends on its hardware and license configuration as well as the
number and type of SFP or SFP+ modules installed.
Note
SFP and SFP+ modules are purchased separately from Arbor, or they are user-supplied.
Module A description of the Ten Gigabit Fiber (10GE SFP+ fiber optic
type module type in terms of module)
its configured connection Gigabit Fiber (1GE SFP fiber optic module)
speed and interface type Gigabit Ethernet (1GE SFP electrical
(optical or electrical). “copper” module)
MTU size The size of the maximum mtu 1500 (for a 1500-byte MTU)
transmission unit (MTU)
in bytes.
Status The negotiated speed at tatus: 10000Mb/s Full (link has been
S
which the module established at 10 Gbps)
currently runs. Status: 1000Mb/s Full (link has been
established at 1 Gbps)
Status: No carrier (link has not been
established)
Output Link statistics for data Output: 3 pkts, 258 bytes, 0 errors,
transmitted by the 0 collisions
module.
Note
For 10GE SFP+ modules, there are no limitations on the display of model information.
Note
Interface information for management ports mgt0-3 will also appear when you run this
command, however it was omitted from this example for brevity. The format of the
management port interface information is similar to the information shown for
mitigation ports tmsx0-6. On TMS 2300-series appliances, management ports are 1GE
copper interfaces on the motherboard, not SFP modules on NICs.
admin@tms-2310:/# / ip interfaces show
tmsx0 Ten Gigabit Fiber, Interface is UP, mtu 1500
Hardware: 00:E0:ED:26:E8:E4
Media: Fiber
Status: No carrier
Input: 0 pkts, 0 bytes, 0 errors
Output: 0 pkts, 0 bytes, 0 errors, 0 collisions
Interrupts: 13468288
SFP: FINISAR CORP. FTLX8571D3BCL
Introduction
This section describes how to configure settings for routers and interfaces.
In this section
This section contains the following topics:
Example
The following example shows how to configure BGP for router monitoring:
admin@mariner1:/services sp router edit
ar1.chi/ Router name
ar1.lax/ Router name
ar1.nyc/ Router name
br1.chi/ Router name
br1.lax/ Router name
br1.nyc/ Router name
cr1.chi/ Router name
cr1.lax/ Router name
cr1.nyc/ Router name
mpls1.chi/ Router name
r4/ Router name
vr1.lax/ Router name
vr1.nyc/ Router name
admin@mariner1:/services/sp/router/edit crl.lax
admin@mariner1:/services/sp/router/edit/london2 bgp
admin@mariner1:/services/sp/router/edit/london2/bgp ip_address set
10.0.1.1
admin@mariner1:/services/sp/router/edit/london2/bgp remote_as set 555
Procedure
To configure the BGP router ID on an SP appliance:
1. Log in to the leader appliance by using the administrator user name and password.
2. Enter / services sp device edit name bgp router_id IP_address
name = the name of the SP appliance
IP_address = the IPv4 IP address to which you want to set the local BGP router
ID. If you do not set the local BGP router ID, then SP uses the IP address of the
interface over which the BGP session to a router is established.
3. Enter config write
SP restarts all BGP sessions.
Procedure
To enable the detection of traffic on a router based on SNMP polling:
1. Log in to the SP leader appliance’s CLI using the administrator user name and
password.
2. To view your routers, enter / services sp router edit ?
3. Enter the router_name
4. Enter advanced flow_seen {flow | all}
flow = the detection of traffic using only flow
all = the detection of traffic using flow and SNMP polling
5. To save the configuration, enter config write
Example
The following example shows how to disable SNMP polling for a router:
admin@mariner1:/# services sp router edit
ar1.chi/ Router name
ar1.lax/ Router name
ar1.nyc/ Router name
br1.chi/ Router name
br1.lax/ Router name
br1.nyc/ Router name
cr1.chi/ Router name
cr1.lax/ Router name
cr1.nyc/ Router name
mpls1.chi/ Router name
r4/ Router name
vr1.lax/ Router name
vr1.nyc/ Router name
admin@mariner1:/services/sp/router/edit brl.chi
admin@mariner1:/services/sp/router/edit/madrid2 snmp
admin@mariner1:/services/sp/router/edit/madrid2/snmp/ hardware_polling
disable
Procedure
To set an alias IPv4 address and netmask for a network interface:
1. Log in to the SP appliance’s CLI using your administrator user name and password.
2. Enter / ip interfaces ifconfig network interface_name IPv4_address
netmask alias
Example
The following example shows how to add an IPv4 alias:
admin@mariner1:/# / ip interfaces ifconfig fxp0 10.0.1.13 255.255.255.0
alias
admin@mariner1:/ip/interfaces#
Example
The following example shows how to disable sampling for the router “chicago1” on the
indexes 1 and 3:
admin@mariner1:/# system attribute set
collector.mariner1.router.chicago1.sampling_disabled_indices = “1,3”
admin@mariner1:/system# / services sp stop
Stopping SP services..............done.
admin@mariner1:/system# / services sp start
Starting SP services......done.
Example
The following example shows how to manually run router Auto-Configuration.
admin@mariner1:/# / services sp auto-config run
admin@mariner1:/#
Important
The primary and secondary failover interfaces for a loopback interface configuration
must be on separate broadcast domains or subnets.
9. If your router is already configured as a BGP peer with the SP appliance, then remove
the existing physical interface IP address from the router’s BGP configuration.
10. Repeat Step 7 through Step 9 for each router that you want to establish a BGP session
with SP using the loopback interface.
11. If you want SNMP queries from the SP appliance to the router to be sourced from the
loopback interface, then enter / services sp router edit name snmp local_
ip_address set IP_address
name = the name of the router that you are configuring
IP_address = the IP address of the SP loopback interface from which SNMP
queries should be sourced
12. To have the SP appliance set the BGP router ID of the appliance to the loopback
interface IP address, then enter / services sp device edit name bgp router_
id set IP_address
name = the name of the appliance that you are configuring
IP_address = the IP address of the SP loopback interface for the appliance that
you are configuring
13. If you changed the IP address on a leader appliance, then do the following to
re-bootstrap your appliances:
l On the leader appliance, enter / services sp bootstrap leader IP_address
zone_secret role nodeldb
IP_address = the IP address of the loopback interface
zone_secret = the zone secret for the deployment
role = the role to assign to the appliance
Enter bi for the data storage role, cp for the traffic and routing analysis role, fs
for the Flow Sensor appliance, and pi for the user interface role. The Flow
Sensor appliance is only applicable with appliance-based licensing.
Note
With appliance-based licensing, the different types of SP appliances have fixed
roles. For information on the relationships between appliance types and
appliance roles, see "Introduction to SP Appliances" in the SP and TMS User
Guide .
l On the non-leader appliances, enter the following commands:
l If the appliance has the user interface role (pi), enter / services sp stop
l / services sp bootstrap nonleader IP_address zone_secret role
IP_address = the IP address of the loopback interface
zone_secret = the zone secret for the deployment
role = the role to assign to the appliance
Enter bi for the data storage role, cp for the traffic and routing analysis
role, fs for the Flow Sensor appliance, and pi for the user interface role.
The Flow Sensor appliance is only applicable with appliance-based
licensing.
Note
With appliance-based licensing, the different types of SP appliances have
fixed roles. For information on the relationships between appliance types
and appliance roles, see "Introduction to SP Appliances" in the SP and
TMS User Guide .
l If the appliance has the user interface role (pi), enter / services sp start
A non-leader user interface device will take additional time to start, because it will
be resynchronizing the database. Resynchronizing should take less than 10
minutes; however, large databases on slow connections could take longer.
14. If you configured a loopback interface on a non-leader appliance, then log in to the
web UI of the leader and update the IP address of the non-leader appliance.
See “Configuring SP Appliances” in the SP and TMS User Guide .
The TMS will use any available management interface for the BGP interface when one of
the following are true:
n The BGP interface is assigned to a misconfigured management interface. For example,
if the management interface is configured as mgt1 on the TMS appliance and mgt0 on
the router.
n The BGP interface is not assigned to a management interface.
Note
You cannot configure multiple VLAN subinterfaces on mgt1 for the MCM-2 platform.
Warning
Before you delete the default route entry, make sure you have physical access to the
appliance or that you understand how your system is connected to the appliance so that
you do not lock yourself out.
File format
The file contains the following information:
Time|BGP|QUERY START|Peering Router|Prefix|AS Path|Origin|Nexthop|
Local Preference|MED|Community|Atomic Aggregate|Aggregator|
Originator|Cluster List|Extended Communities
Introduction
This section describes how to upgrade your SP and TMS software.
In this section
This section contains the following topics:
Important
With a cloud-based flexible license deployment, if you are upgrading the leader from SP
7.x, then do not use the procedures in this topic. Instead, see "Upgrading a Leader VM
from 7.x to SP 8.x" in the Running SP 8.4 in a Virtual Machine guide. Upgrading a leader
from SP 7.x requires additional steps that are not included in these procedures.
On a leader appliance that has a user interface role, you can use the CLI to copy software
updates to the appliances in your deployment. See “Adding Software Updates to the
Appliances in Your Deployment” on page 141.
Because SP has multi-version support, you do not have to upgrade all of the SP appliances
in your deployment at the same time. See "Multi-Version Support in SP and TMS Software"
in the Arbor Networks SP and TMS Compatibility Guide .
Important
You must upgrade your SP devices in a specific order. For more information, see "Multi-
Version Deployment Upgrade Process" in the Arbor Networks SP and TMS Compatibility
Guide . Be aware of the following when upgrading:
n You must upgrade the leader SP device before upgrading any other user interface
devices in your deployment.
n When upgrading from SP 8.2 or higher, Arbor recommends stopping all user interface
devices prior to upgrading. Stopping user interface devices avoids failover and cross-
version compatibility issues.
n The upgraded leader must be running when you upgrade the other user interface
devices. If the leader is not upgraded or not running, you will need to manually resync
the database when it is.
n When upgrading from a version lower than SP 8.2, non-leader user interface devices
take additional time to upgrade because they are syncing the database. Syncing the
database should take less than 10 minutes; however, large databases on slow
connections could take longer.
n When upgrading from SP 8.2 or higher, a database sync for non-leader user interface
devices is not normally needed. A database sync is only needed if the devices have been
down for an extended time period, usually on the order of hours. Syncing the database
should take less than 10 minutes; however, large databases on slow connections could
take longer.
Important
If you have an uncommitted configuration when you perform an upgrade, your
uncommitted changes will be lost. Verify that you have committed all necessary
configurations before you begin this procedure.
18. To install the new SP software, enter / system files install disk:Peafklow-
SP-8.4-build
build = the build number in the file name, including -B
19. Enter / services sp start
20. Enter config write
21. To verify that you successfully upgraded the software, enter system files show
login: admin
Password: **********
SP v6.0
Copyright (c) 2000-2013 Arbor Networks, Inc. All Rights Reserved.
Welcome to Peakflow
admin@reds:/# reload
You are about to reboot the system. Do you wish to proceed? [n] y
094: Rebooting the system..
Broadcast messagSending all processes the TERM signal...
Sending all processes the KILL signal...
Syncing hardware clock to system time
Unmounting loopback filesystems:
Unmounting file systems:
Please stand by while rebooting the system...
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/kernel-arbux-smp console=ttyS0,9600n8 root=/dev/ram0
ramdisk=24480
vdso=0 acpi=no rw init=/linuxrc-disk
[Linux-bzImage, setup=0x1400, size=0x4d6ad0]
initrd /boot/initrd.gz
[Linux-initrd @ 0x37a19000, 0x5d6778 bytes]
....................................................................
.....�..............................................................
....................................................................
....................................................................
....................................................................
..................****................................**************
boot:
clean, 63/124928 files, 141851/497980 bloc.ks
INIT: version 2.86 booting
002: Scanning for filesystems
003: Using system disk
reds login:
ArbOS v6.2
Copyright (c) 2000-2014 Arbor Networks, Inc. All Rights Reserved.
Welcome to Peakflow
admin@reds:/# / system files install disk:Peakflow-SP-7.0.1-xxxx
Extracting package...done.
Writing SNMP system description...done.
Upgrading to 7.0.1-xxxx...
Adding CDN Proxy mitigation storage...done
Adding Flowspec TMS offramp mitigation storage...done
Adding profiled interface alert storage...done
Adding router_name and interface_name to the attack table...
...done
Checking database schema
....................................................................
....................................................................
....................................................................
.................done
Database upgrade done
Updating managed object scoping configuration...done
Removing redundant tag indices.done
Setting offramp_method to BGP for all TMS devices and clusters...done
Saving ArbOS configuration...
Saving SP configuration...
Updating saved command cache this may take a while)...000: SP
services are not running
done
Upgrade successful. Welcome to 7.1-xxxx.
admin@reds:/# / services sp start
Starting SP services......done.
For 64-bit upgrades and installations only: verify that the ArbOS and TMS software
packages have the same architecture suffix. For example, if you are upgrading to a TMS
5000 appliance, the 64-bit ArbOS and TMS software packages should have the architecture
suffix x86_64.
Multi-version support
Because SP has multi-version support, you may not have to upgrade your TMS appliances
when you upgrade the leader appliance.
See "Multi-Version Support in SP and TMS Software" in the Arbor Networks SP and TMS
Compatibility Guide .
To find the serial number that is needed to obtain a valid license key from Arbor Technical
Assistance Center, see “Obtaining a valid license key for your TMS appliance” on the
facing page.
Example output for obtaining a serial number for a chassis-based TMS appliance
The following example shows the Chassis Serial Number for a TMS 4000 appliance:
admin@tms4000:/# system hardware
Boot time: Wed Nov 28 22:59:51 2013, 16:25 ago
Load averages: 0.08, 0.09, 0.08
BIOS Version: 4.6.3 System Board
Model: Tionesta
Processor: Intel(R) Xeon(R) CPU L5408 @ 2.13GH
Processor: Intel(R) Xeon(R) CPU L5408 @ 2.13GH
Memory Device: No Module Installed A1_BANK DIMM9B2
Memory Device: No Module Installed A1_BANK DIMM9B1
Memory Device: No Module Installed A1_BANK DIMM8B2
Memory Device: No Module Installed A1_BANK DIMM8B1
Chassis Serial Number: 1044219-010 (CDA-1200Z)
Slot 0: Type: shelf
Slot 0: Firmware : 2.7.4
Slot 1: Type: mcm2
Slot 1: Model: 0-12489-04
Slot 1: Serial Number: CX8-01347
Slot 1: Firmware 0: xe50-ipmc-v1.3.2b01
Slot 2: Type: psm40
Slot 2: Model: 0-12380-E03
Slot 2: Serial Number: CZ9-09858
Slot 2: Firmware 0: fm40-ipmc-v2.3.1r00
Slot 2: Firmware 1: fm40-ppc-v2.3.5r00
Slot 2: Firmware 2: fm40-ppc-v2.3.5r00
Slot 3: Type: apm-e
Slot 3: Model: 0-15286-03
Slot 3: Serial Number: CJC-3602N
Slot 3: Firmware 0: 20132103000
Slot 3: Firmware 1: cnode-fw-pp81-v1.1.0r02
Warning
For chassis-based TMS appliances, the upgrade process can take up to 70 minutes. After
you start the upgrade, let it run uninterrupted until it completes. DO NOT pause or stop
the upgrade while it is in progress.
Important
Before completing the procedures in this topic, you should review the information in
“About Upgrading Software and Installing Maintenance Releases on TMS Appliances”
on page 132 .
8. Choose your next steps based on the method that you use to upgrade:
Method Procedure
downloaded file See “Installing the software from a downloaded file” on the
next page.
USB thumb drive See “Installing the software from a USB thumb drive” on
page 137.
Note
In the ArbOS and TMS software package file names in this procedure, -build is the build
number and x.y is the ArbOS version number. For 64-bit ArbOS and TMS software
packages only, -arch is the architecture suffix. For example, the 64-bit ArbOS and TMS
software packages for a TMS 5000 appliance have the architecture suffix x86_64.
1. Download the necessary software packages from the Arbor Networks Update Server
to a location that is accessible by the TMS appliance.
The update server is located at https://update.arbor.net
2. To copy the ArbOS file from the location where you downloaded it, enter one of the
following commands:
copy ftp://[user:password@]A.B.C.D[:port]/arbos-x.y-build[-arch]
disk:
copy http://A.B.C.D[:port]/arbos-x.y-build[-arch] disk:
copy scp://[user@]A.B.C.D[:port]/arbos-x.y-build[-arch] disk:
3. To view the directory listing, enter directory disk:
4. Enter install disk:arbos-x.y-build[-arch]
5. Enter reload
6. To confirm your choice, enter y
The appliance restarts with the new ArbOS version.
7. Log in to the appliance using the administrator user name and password.
8. Enter system files
9. Repeat Step 2 through Step 4 for the TMS 8.4 file.
10. To view the directory listing, enter directory disk:
11. To install the new TMS software version, enter install
disk:Arbor-TMS-8.4-build[-arch]
12. To start TMS services, enter / services tms start
13. To save your configuration changes, enter config write
Note
In the ArbOS and TMS software package file names in this procedure, -build is the build
number and x.y is the ArbOS version number. For 64-bit ArbOS and TMS software
packages only, -arch is the architecture suffix. For example, the 64-bit ArbOS and TMS
software packages for a TMS 5000 appliance have the architecture suffix x86_64.
1. Enter cdrom unlock
2. Remove the old CD and insert the new CD in the CD drive.
3. Enter cdrom lock
4. To view the directory listing, enter directory cd:
The file names in the directory listing include the build number that you need to install
the upgrade.
5. Enter install cd:arbos-x.y-build[-arch]
6. Enter reload
7. To confirm your choice, enter y
The appliance restarts with the new ArbOS version.
8. Log in to the appliance using the administrator user name and password.
9. To view the directory listing, enter system files directory cd:
10. To install the new TMS software version, enter install
disk:Arbor-TMS-8.4-build[-arch]
11. To start TMS services, enter / services tms start
12. To save your configuration changes, enter config write
Note
In the ArbOS and TMS software package file names in this procedure, -build is the build
number and x.y is the ArbOS version number. For 64-bit ArbOS and TMS software
packages only, -arch is the architecture suffix. For example, the 64-bit ArbOS and TMS
software packages for a TMS 5000 appliance have the architecture suffix x86_64.
1. Insert the thumb drive into the USB port.
Important
Verify that the necessary software packages reside in the root directory on the USB
thumb drive.
2. To view the directory listing, enter directory usb:
The file names in the directory listing include the build number that you need to install
the upgrade.
3. Enter install usb:arbos-x.y-build[-arch]
4. Enter reload
5. To confirm your choice, enter y
The appliance restarts with the new ArbOS version.
6. Log in to the appliance using the administrator user name and password.
admin@mariner:/system/files# /
admin@mariner:/# services tms start
Starting Arbor Networks TMS services...done.
admin@mariner:/# config write
admin@mariner:/#
Note
Chassis-based TMS appliances include the TMS 4000 and the TMS 5000.
The following table lists the slot numbers for the blades that support firmware upgrades in
each chassis-based TMS appliance:
APM-10 or APM-E 3, 4, 5, or 6
APM-E 3, 4, 5, or 6
After you enable software updates in the web UI (Administration > System
Maintenance > Software Updates), you can use the CLI to copy the software updates
to the appliances in your deployment.
For details about enabling software updates, see “Enabling Software Updates” in the
SP and TMS User Guide .
For installation instructions, see “Upgrading the Software and Installing Maintenance
Releases on an SP Appliance” on page 124 .
Example
The following example shows how to add a software release update to an appliance in
your deployment:
admin@mariner1:/# services sp software ?
copy Copy software from staging area to disk
disable Disable software update checking
enable Enable software update checking
list Show list of options
proxy/ Configure a proxy for downloading updates
pull Pull software from update server
push Push software to other appliances
server Configure software update server
show Show the current software update checking status
status/ Show status of devices
admin@mariner1:/# / services sp software pull?
SP-8.4 Package to pull from update server
SP-TMS-8.4 Package to pull from update server
admin@mariner1:/# / services sp software pull SP-8.4
Downloading Peakflow-SP-8.4-xxxx
#####################################################################
Download complete Peakflow-SP-8.4-xxxx
Downloading arbos-6.2-xxxx
#####################################################################
Download complete arbos-6.2-xxxx
All downloads completed
Introduction
This section describes how to reinstall the operating system and other necessary software
for SP and TMS appliances in the case of an emergency situation.
In this section
This section contains the following topics:
Caution
Reinstalling an appliance erases all data from the system and returns it to its factory state.
This should only be done in an emergency situation and under the direction of Arbor
Technical Assistance Center.
Configuring interfaces
To configure interfaces:
1. Determine if you are using the listed interface.
l If yes, enter an IP_address for the listed interface.
l If no, press ENTER, and go to the procedure on enabling access to services.
See “Enabling access to services” below.
2. Enter a netmask for the interface.
3. Enter the IP_address of the default route gateway.
11. If prompted, press ENTER to deny all SPCOMM access to the appliance.
Note
Configurations that you perform later (bootstrap command for non-leaders and
leader configuration for SP UI) will automatically add SPCOMM access as needed.
12. If prompted, press ENTER at the TFTP access prompt.
13. If prompted, press ENTER to skip configuring VRRP access.
SP does not support VRRP.
14. Enter the CIDR_block of the network from which you want to enable SSH access.
15. Repeat Step 14 for each network from which you want to enable SSH access.
16. Enter the IP_address of the DNS server that you want the appliance to use.
See “About adding a DNS server” below.
17. Repeat Step 16 for each DNS server.
18. When prompted to set the time and date, do one of the following:
l Enter the date in the format mmddHHMMyyyy.SS (month, day, hour, minute, year,
second).
l Enter the IP_address or FQDN hostname of the NTP server that you want the
appliance to use.
See “About adding an NTP server” below.
Note
Using a certificate to reinstall an appliance is optional.
disk:license_file
license_file = the name of the license file
+--------------------------------------------------------------+
| usb (serial console) |
| disk (serial console) |
| second disk (serial console) |
| (re)install from usb (serial console) |
| usb (VGA) |
| disk (VGA) |
| second disk (VGA) |
| (re)install from usb (VGA) |
| |
| |
| |
| |
| |
| |
+--------------------------------------------------------------+
Use the ^ and v keys to select which entry is highlighted.
Press enter to boot the selected OS, 'e' to edit the
commands before booting, 'a' to modify the kernel arguments
before booting, or 'c' for a command-line.
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/kernel-arbux-smp console=ttyS0,9600n8 root=/dev/ram0
ramdisk=24480
vdso=0 acpi=no rw init=/linuxrc-flash-install
[Linux-bzImage, setup=0x1400, size=0x4dd670]
initrd /boot/initrd.gz
[Linux-initrd @ 0x37a1a000, 0x5d58f1 bytes]
...............****............................................
..............................**************boot: clean, 68/.124928
files, 14...2305/497980 blocks
INIT: version 2.86 booting
010: Using flash disk
018: No system configuration found
Note
Chassis-based TMS appliances include the TMS 4000 and the TMS 5000.
Caution
Reinstalling the TMS software on an appliance erases all data from the system and
returns it to its factory state. This should only be done in an emergency situation and
under the direction of the Arbor Technical Assistance Center.
Note
For instructions on restoring the TMS software from flash, see “Restoring TMS Software
from Flash on a Chassis-based TMS Appliance” on page 161 .
Initial steps
Complete the following initial steps to begin reinstalling the TMS software on a
chassis-based TMS appliance:
1. Depending on the method you are using to reinstall the appliance, insert the USB
device or CD-ROM into the appliance.
2. To initiate recovery, connect a serial cable from the serial console to the appliance.
3. Restart the appliance.
You can manually turn the power off and on if the appliance is non-responsive.
4. To start the boot menu, press any key when you see the message, “Press any key to
continue.”
5. At the boot menu, select [Serial Console] (re)install from usb disk.
6. To confirm that you want to reinstall when the warning message appears, enter y
The ArbOS and TMS software packages are installed, and the databases are built.
Configuration steps
After the reinstall, complete the following steps at the configuration prompts:
1. Enter the system_hostname
2. When prompted to change the password for the admin user, type y and then follow
the prompts to change the password, otherwise type n.
3. Enter the IP_address for the mgt0 management interface.
If you enter an IPv6 address, then you must also include the prefix length.
4. Enter the netmask for the mgt0 management interface.
If you entered an IPv6 address in Step 3, then this prompt does not appear.
5. Press ENTER to accept the auto selected media speed for this interface.
You can use the CLI to reconfigure the media speed at a later time.
See “Setting the management interface media speed (optional)” on page 157.
6. Repeat Step 3 through Step 5 for the remaining interfaces.
You can press ENTER at the prompt if you want to skip configuring an interface.
The appliance reboots from disk, which has the installed ArbOS and TMS software
packages.
Follow the procedures below to complete the reinstallation using the CLI.
Setting the default SSH host key and starting SSH services
To set the default SSH host key:
1. Enter / services ssh key host set default
2. To generate a default SSH host key, enter y
3. Enter / services SSH start
Note
If you set the interface media speed to 1000, you can only set the duplex mode to full.
(TMS 5000 appliance only) Show or set the speed for all mitigation interfaces (optional)
If you want to show or set the speed for all mitigation interfaces on a TMS 5000 appliance:
Building
databases.......................................................
..................................done.
File: boot Type: Directory
Restarting system.
Note
Chassis-based TMS appliances include the TMS 4000 and the TMS 5000.
Caution
You should only restore the TMS software from flash in an emergency situation under
the direction of the Arbor Technical Assistance Center.
MCM-1 A
TMS 4000
MCM-2 or MCM-C B
Procedure (B): Flash recovery for a TMS appliance with an MCM-2 or MCM-C
To recover from flash on a chassis-based TMS appliance with an MCM-2 or MCM-C
installed:
1. Connect to the appliance using serial console, and then reboot the appliance.
2. When the grub menu appears, select [Serial Console] (re) install from on-board
flash.
3. Proceed with instructions for a regular installation.
See “Reinstalling TMS Software on a Chassis-based TMS Appliance” on page 155 or
see the Arbor Networks TMS 4000 Quick Start Card or Arbor Networks TMS 5000 Quick
Start Card.
Introduction
This section describes CLI commands that you can use to configure the user interface.
In this section
This section contains the following topics:
Requirements
Every menu XML definition must contain:
n at least one menu_definition element with an id attribute
n one menu element with the id attribute sp_menu_main (e.g. <menu id="sp_menu_
main">)
Note
This XML node describes the top-level menus.
The menu XML file may contain an arbitrary number of sub-menu menu elements. Each
sub-menu definition must have a unique id attribute.
<pagematch>/page?id=managed_object_list</pagematch>
</item>
</menu>
</menu_definition>
</peakflow>
Example
The following is an example of enabling the Subscriber feature:
admin@mariner1:/# / services sp model subscribers enable
admin@mariner1:/# config write
See “Customizing the Login Page” in the SP and TMS User Guide .
Example
The following is an example of restoring the default login page:
admin@mariner:/# / services sp portal login_page clear
Are you sure you want to remove your login page customization?
(this cannot be undone)? [n] y
Procedure
To change the number of the configuration changes shown on the Interface Configuration
History page:
1. Log in to the leader appliance’s CLI using the administrator user name and password.
2. Enter / services sp auto-config interface revisions set number
number = the maximum number of configuration changes you want to display on
the Interface Configuration History page
Example
The following example shows how to set the configuration changes to display to 2000:
admin@mariner1:/# / services sp auto-config interface ?
revisions Set the max configuration history versions to
display
rules/ Interface classification regular expression rules
run Start interface classification
admin@mariner1:/# / services sp auto-config interface revisions set 2000
admin@mariner1:/#
For additional information about severity level, maximum severity percent, and maximum
impact of alert traffic, see "About key alert information on the Summary tab" and "Why
maximum severity percent, maximum impact of alert traffic, and maximum observed
values might not match" in the SP and TMS User Guide .
The default settings are 10 alerts per page and 100 maximum returned results.
number = the number of search results you want shown per page
4. Enter config write
Important
If you disable prefix aggregation of IP addresses, SP can only display the top 200
individual source and destination IP addresses on the Traffic Details tab of a DoS alert.
SP can also display only top traffic patterns for individual IP addresses.
You use the CLI to disable the aggregation of IP addresses. If you have disabled prefix
aggregation of IP addresses, you can then use the CLI to enable prefix aggregation. You
can also use the CLI to clear the prefix aggregation settings. When you clear the prefix
aggregation settings, the default settings are restored, which currently means that prefix
aggregation is enabled.
n Top Traffic Patterns table on the Summary tab and the Traffic Details tab
n Source and destination address tables on the Traffic Details tab
Introduction
This section describes CLI commands that you can use to configure user account and user
group settings.
In this section
This section contains the following topics:
Hiding Non-Local User Data on the User Account Login Records Page 180
How SP Header-Based Single Sign-On Works 181
Configuring Header-Based Single Sign-On 183
Changing the Default RADIUS/TACACS+ User Group 185
Supported products
SP uses both IBM's WebSeal and Tivoli Policy Director products to provide a web proxy
and single sign-on authentication mechanism. For HTTP header authentication, the web
proxy sets the HTTP header to the login ID for the authenticated user, which maps directly
to the SP login ID.
Important
You must have an SP user account (login ID) to use single sign-on. For instructions about
how to create a user account, see “Configuring User Accounts” in the SP and TMS User
Guide .
If the authentication expires (times out), SP redirects you to the configured logout page, so
you can re-enter your user information, and then automatically logs you in to the SP web
user interface.
Task overview
To configure single sign-on HTTP header authentication, you must complete the following
tasks:
Task Description
1 Enable HTTP header authentication.
3 Configure a URL to which you want to direct users who fail to authenticate.
4 Configure a URL to connect users who log out from SP so that they can log out
from the single sign-on system.
6 Add remote access rules for the web proxy servers to limit the IP addresses
that can connect to SP through single sign-on.
enableIP addresses
IP addresses = the web proxy servers that you want to allow to communicate
with SP for single sign-on
Tip
You can enter IP addresses or CIDR blocks, and enter multiple addresses as a
comma-separated list.
8. To save the settings, enter config write
Example
The following example shows how to configure single sign-on HTTP header
authentication:
host: ssh leader.sample.net
username: admin
password; *******
Last Login: UI on Tue Mar 6 21:36:08 2013 from 10.0.0.1
SP v5.8
Copyright (c) 2000-2013 Arbor Networks, Inc. All Rights Reserved.
Welcome to Peakflow
For more information about user groups, see “About Account Groups” in the SP and TMS
User Guide .
For more information about creating custom user groups, see “Configuring Account
Groups” in the SP and TMS User Guide .
Example
The following example shows how to set the system_none group (with no privileges) as
the default for any RADIUS/TACACS+ user that does not have a specified group.
admin@mariner1:/# services aaa groups default set system_none
admin@mariner1:/services/aaa/groups# config write
Introduction
This section describes CLI commands that you can use to configure DoS detection
settings.
In this section
This section contains the following topics:
How Sets of Shared Host Detection Settings Are Assigned During an Upgrade 188
Combining Duplicate Sets of Shared Host Detection Settings 191
Converting Managed Objects and Services to Use Custom Sets of Host Detection
Settings 194
Disabling and Enabling Host Detection Misuse Types 195
Resetting DoS Evaluation Baselines 197
Disabling and Enabling Auto-detection of VPN Sites 199
How these sets of shared host detection settings are assigned is somewhat different when
you upgrade from SP 6.0 (all patch levels) or earlier than when you upgrade from SP 7.0 or
7.0.1. Consequently, each of these types of upgrades is described separately.
Note
When you upgrade from SP 7.0.2 or 7.0.3, to SP 7.5 or higher, no changes are made to
the host detection settings.
How sets of shared host detection settings are assigned when upgrading from SP 6.0 or
earlier
When you upgrade from SP 6.0 (all patch levels) or earlier to SP 7.0.2 or higher, a set of
shared host detection settings is assigned to host global detection and to each of your
managed objects and services. The set of shared host detection settings that is assigned
depends on how the corresponding setting was configured before the upgrade.
How shared host detection settings are assigned when upgrading from 6.0 or earlier
Settings Before
Upgrade How Shared Host Detection Settings Are Assigned
Misuse or host A set of shared host detection settings is created for each managed
detection settings object or service and is assigned to the managed object or service.
are configured. Each set of shared host detection settings that is created is given a
name that begins with “copied from” followed by the name of the
managed object or service.
Note
Because SP creates a set of shared host detection settings for
each managed object that has configured misuse or host
detection settings, duplicate sets of shared host detection settings
might be created. You can use the CLI to identify and combine
duplicate sets of shared host detection settings. See “Combining
Duplicate Sets of Shared Host Detection Settings” on page 191.
Misuse detection The Default set of shared host detection settings is assigned to that
is set to Default. managed object or service.
The Default set of host detection settings is created from the
misuse default settings that were configured on the Configure
Global Detection Settings page (Administration > Detection >
DDoS) in Arbor Networks SP 6.0 (all patch levels) or earlier.
How shared host detection settings are assigned when upgrading from 6.0 or earlier
(Continued)
Settings Before
Upgrade How Shared Host Detection Settings Are Assigned
Host detection is The “default_host” set of shared host detection settings is assigned
set to Default. to that managed object or service.
The “default_host” set of host detection settings is created from the
host default settings that were configured on the Configure Global
Detection Settings page (Administration > Detection > DDoS)
in Arbor Networks SP 6.0 (all patch levels) or earlier.
Misuse or host The Disabled set of shared host detection setting is assigned to
detection is that managed object or service.
disabled. If host detection settings were configured and saved before host
detection was disabled, then a set of shared host detection settings
is created with those settings and with host detection disabled.
Misuse "other" is The “global” set of shared host detection settings is assigned to
enabled for global host global detection. If misuse “other” detection was disabled,
misuse detection. then the “Disabled” set of shared host detection settings is
assigned to host global detection. See “About host global
detection” in the SP and TMS User Guide .
The “global” set of shared host detection settings is created only if
misuse “other” detection was enabled. The “global” set of shared
host detection settings is created from the misuse “other” default
settings that were configured on the Configure Global Detection
Settings page (Administration > Detection > DDoS) in Arbor
Networks SP 6.0 (all patch levels) or earlier.
Note
If a managed object or service had both misuse detection and host detection enabled,
then the settings are merged with any configured misuse settings overriding the
corresponding host detection settings. Further, if misuse detection was disabled but host
detection enabled, then host detection is set to disabled because the misuse detection
setting overrides the host detection setting.
How sets of shared host detection settings are assigned when upgrading from SP 7.0 or
7.0.1
When you upgrade from SP 7.0 or 7.0.1 to SP 7.0.2 or higher, a set of shared host detection
settings is assigned to host global detection and to each of your managed objects and
services. The set of shared host detection settings that is assigned depends on how the
corresponding setting was configured before the upgrade.
How shared host detection settings are assigned when upgrading from 7.0.1 or 7.0.2
Settings Before
Upgrade How Shared Host Detection Settings Are Assigned
Host detection A set of shared host detection settings is created for each managed
settings are object or service and is assigned to the managed object or service.
configured. Each set of shared host detection settings that is created is given a
name that begins with “copied from” followed by the name of the
managed object or service.
Note
Because SP creates a set of shared host detection settings for each
managed object that has configured misuse or host detection
settings, duplicate sets of shared host detection settings might be
created. You can use the CLI to identify and combine duplicate
sets of shared host detection settings. See “Combining Duplicate
Sets of Shared Host Detection Settings” on the facing page.
Host detection is The Default set of shared host detection settings is assigned to that
set to Default. managed object or service.
The Default set of shared host detection settings is created from the
default host settings that were configured on the Configure Global
Detection Settings page (Administration > Detection > DDoS)
in SP 7.0 and 7.0.1.
Host detection is The Disabled set of shared host detection setting is assigned to that
disabled. managed object or service.
If host detection settings were configured and saved before host
detection was disabled, then a set of shared host detection settings
is created with those settings and with host detection disabled.
Host global The Default set of shared host detection settings is assigned to host
detection is global detection. If host global detection was disabled, then the
enabled. “Disabled” set of shared host detection settings is assigned to host
global detection. See “About host global detection” in the SP and
TMS User Guide .
The Default set of shared host detection settings is created from the
default host settings that were configured on the Configure Global
Detection Settings page (Administration > Detection > DDoS)
in SP 7.0 and 7.0.1.
For additional information about how SP assigns sets of host detection settings when you
upgrade from a version of SP prior to 7.0.2, see “How Sets of Shared Host Detection
Settings Are Assigned During an Upgrade” on page 188 .
Displaying every set of shared host detection settings with duplicate sets grouped
together
You can use this procedure to display every set of shared host detection settings with the
sets arranged so that duplicate sets are grouped together. You can then look at the
duplicate sets and determine if you want to combine any or all of them into a single set.
To display every set of shared host detection settings with duplicate sets grouped together:
1. Log in to the SP leader appliance’s CLI using the administrator user name and
password.
2. Enter / services sp detection host shared duplicate show
Displaying sets of shared host detection settings that are duplicates of a specific set
You can use this procedure to display the sets of shared host detection settings that are
duplicates of a set that you specify. You can then look at the duplicate sets and determine
if you want to combine any or all of them into a single set.
To display sets of shared host detection settings that are duplicates a specific set:
1. Log in to the SP leader appliance’s CLI using the administrator user name and
password.
2. Enter / services sp detection host shared duplicate show name
name = the name of the set of shared host detection settings that you want use to
identify the other sets with the same settings
Note
If the name contains spaces, then enclose the name in double quotation marks.
Combining every set of shared host detection settings that are duplicates of a specific set
You can use this procedure to combine every set of shared host detection settings whose
settings are duplicates of a set that you specify. After the sets of settings are combined,
each duplicate set is deleted, unless the duplicate set is the Default set or the Disabled set.
The combined set of settings is then assigned to each managed object or service to which
the duplicate sets were formerly assigned. If you want to combine only some of the sets
that are duplicates of a given set of settings, see “Combining selected sets of shared host
detection settings that are duplicates of a specific set” below.
To combine every set of host detections settings that are duplicates of a specific set:
1. Log in to the SP leader appliance’s CLI using the administrator user name and
password.
2. Enter / services sp detection host shared duplicate combine all name
name = the name of the set of host detection settings to which you want to
combine all of its duplicates
Note
If the name contains spaces, then enclose the name in double quotation marks.
Combining selected sets of shared host detection settings that are duplicates of a
specific set
You can use this procedure to combine selected sets of shared host detection settings
whose settings are duplicates of a set that you specify. After the sets of settings are
combined, each duplicate set is deleted, unless the duplicate set is the Default set or the
Disabled set. The combined set of settings is then assigned to each managed object or
service to which the duplicate sets were formerly assigned. If you want to combine all of
the sets that are duplicates of a given set of settings, see “Combining every set of shared
host detection settings that are duplicates of a specific set” above.
To combine selected sets of shared host detection settings that are duplicates of a specific
set:
1. Log in to the SP leader appliance’s CLI using the administrator user name and
password.
2. Enter / services sp detection host shared duplicate combine selected
name_1 {name_2,name_3,..,name_n}
name_1 = the name of the set of shared host detection settings to which you want
to combine all of its duplicate sets that you specify
name_2,name_3,..,name_n = the names of each of the duplicate sets of shared host
detection settings that you want to combine with the name_1 set
Note
You must enclose name_2,name_3,..,name_n in braces and separate each name with
a comma and no space. If a name contains spaces or commas, then enclose the
name in double quotation marks (for example, “copied from XYZ”).
Note
If any set of shared host detection settings specified by name_2,name_3,..,name_n is
not a duplicate of the name_1 set, then its settings are ignored and are not combined
with the name_1 set.
For additional information about how to configure sets of host detection settings, see
"Configuring Host Detection for Managed Objects" in the SP and TMS User Guide . For
information about using CLI commands, see “Using CLI Commands” on page 16 .
By default, every host detection misuse type in a set of host detection settings is enabled
except for the Total Traffic misuse type. If you experience an inordinate number of alerts
because a misuse type is enabled, you can quickly disable that misuse type in every set of
host detection settings. After you disable a misuse type, you can use the SP web UI to
modify its settings in individual sets of host detection settings so that when they are
enabled they do not trigger false alerts.
After you modify the settings of a misuse type in individual sets of host detection settings,
you can then manually enable the misuse type in those sets of host detection settings, or
you can use the CLI to enable that misuse type for every set of host detection settings.
DNS dns
ICMP icmp
IP Fragment ipfrag
IP Private ippriv
UDP udp
After you start the evaluation baseline period, SP will monitor traffic for the specified
duration. At the end of that time, the monitored traffic is used to create the evaluation
baseline, which is then used for profiled DoS detection. Because of this, you should make
sure that the traffic used to generate the baseline is already running before you enable
evaluation baseline mode.
Note
Unlike normal baseline monitoring, the evaluation baseline is not updated again until
you run the reset baseline command.
Important
Arbor recommends that you do not perform this procedure in your normal day-to-day
operation.
Example
The following example shows how to log in to an SP leader and reset the DoS evaluation
baseline to 20 minutes:
admin@mariner1:/# / services sp detection profiled eval_baseline
enable 1200
admin@mariner1:/# config write
admin@mariner1:/# / services sp stop
Stopping SP services..............done.
admin@mariner1:/# / services sp data database reset baseline
Reset baseline database? (This operation cannot be undone) [n] y
Deleting baseline data. This could take a while...done.
admin@mariner1:/# / services sp start
Starting SP services......done.
If you disable auto-detection of VPN sites after VPN sites have been auto-detected for a
VPN managed object, then the auto-detected VPN sites will continue to be associated with
the VPN managed object. If you later decide to enable auto-detection of VPN sites, you can
then use a CLI command to enable auto-detection. You can also use a CLI command to
reset the auto-detection settings to the default setting of enabled.
For additional information, see the following topics in the SP and TMS User Guide :
n Configuring Match Settings for Managed Objects
Resetting the VPN site auto-detection settings to the default setting of enabled
By default, the VPN site auto-detection settings are enabled. If you disable the auto-
detection settings, you can use a CLI command to reset the settings to the default setting
of enabled.
Introduction
This section describes CLI commands that you can use to configure mitigation settings.
In this section
This section contains the following topics:
For more information, see “About Sample Packets” in the SP and TMS User Guide .
Setting the host and port number for the log file location
You need to set the host IP address where the logs will be written. You can also set the
host port number that will be used to write the logs. If you do not set a host port number,
port number 514 will be used by default.
To set the host and the host port number where the logs will be written:
1. Log in to the TMS appliance’s CLI using the administrator user name and password.
2. Enter / services tms registry main set logger default_syslog_host =
host_IP_address
3. (Optional) Enter / services tms registry main set logger default_
syslog_port = host_port_number
Example
The following example shows how to set a log file location and enable blocked-host
logging on a TMS appliance:
admin@tms:# services tms
admin@tms:/services/tms# registry main set logger default_syslog_host
= 192.0.2.1
admin@tms:/services/tms# registry main set logger default_syslog_port =
514
admin@tms:/services/tms# registry main set logger default_local_
logging_enabled = 1
n a rate limit suggestion based on a target output rate (matching the original input rate)
after the addition of the GRE tunnel
n 4 @ 570 bytes
n 1 @ 1518 bytes
Note
The average packet size is 380 bytes.
Layer 2 chart
The following Layer 2 conversion chart provides GRE encapsulation overhead based on
input rate with IMIX packet distribution:
Layer 2 conversions
Note
Layer 2 header calculated using Ethernet encapsulation.
n 4 @ 546 bytes
n 1 @ 1494 bytes
Note
The average packet size is 356 bytes.
Layer 3 chart
The following Layer 3 conversion chart provides GRE encapsulation overhead based on
input rate with IMIX packet distribution:
Layer 3 conversions
Important
To divert and mitigate traffic using 6PE, the TMS appliance must be running TMS 8.1 or
higher.
n The TMS All group should not be used when using 6PE to mitigate IPv6 traffic because
SP is not able to validate the mitigation with the All group.
n A TMS group can have TMS appliances that are enabled to pop MPLS labels and other
TMS appliances that are not enabled to pop MPLS labels.
n TMS ports that are enabled to process MPLS labels, can also be used to mitigate IPv4
traffic and IPv6 traffic that does not have MPLS labels.
n A TMS appliance pops all of the MPLS labels. It does not pop just the label that was
added to divert the traffic for mitigation.
For more information about the settings on the Deployment and Patch Panel tabs, see
"Configuring Deployment Settings for a TMS Appliance, TMS-ISA, or Cisco ASR 9000 vDDoS
Protection" and "Configuring Patch Panel Settings for a TMS Appliance or Cisco ASR 9000
vDDoS Protection" in the SP and TMS User Guide .
Important
When you add custom templates in bulk, any custom templates already stored in the
system will be deleted and replaced with the content of the disk file.
Introduction
This section describes CLI commands that you can use to configure report settings.
In this section
This section contains the following topics:
Disabling and Enabling Transit Traffic and Transit Research Reporting 216
Overriding the Default Number of Items Listed in a Report Data Table 218
Note
These reports are enabled by default. You can disable and enable them with the CLI only
on the leader appliance.
References:
n For more information about transit traffic reports, see “Additional information about
the BGP Attributes (Transit) filter” in the SP and TMS User Guide .
n For more information about transit research tools, see “About the Transit Research
Tools” in the SP and TMS User Guide .
n For more information about the Peering Traffic Exchange tools, see “About the Peering
Traffic Exchange Tools” in the SP and TMS User Guide .
n For more information about the Traffic Engineering tools, see “About the Traffic
Engineering Tools” in the SP and TMS User Guide .
The BGP transit reports report on BGP attributes associated with the “other” side of the
traffic not included in the standard BGP attribute reports. More specifically, these reports
provide details about the BGP attributes for the destination route when traffic is entering
your network and for the source route when traffic is leaving your network.
Tip
You can use the show command to view the current setting.
Tip
You can use the show command to view the current setting.
Tip
You can use the show command to view the current setting.
Tip
You can use the show command to view the current setting.
Note
This setting is not applied if you explicitly set the limit in the XML of an edited or custom
report.
n IPv6 reports (except IPv6 Applications Compare Report and IPv6 Customer or Peer TCP
or UDP reports)
n Dashboard reports
n Top Talkers reports
n Raw Flows reports
n Peering tools reports
n Customer traffic engineering tools reports (source or destination analysis)
n Profile Transit Research reports
n TMS DNS reports (FQDN and RDN)
n Services HTTP reports
Note
You must log out and log back into the web UI to see the updated value in your reports.
Note
You must log out and log back in to the web UI to see the updated value in your reports.
Introduction
This section describes CLI commands and other information for monitoring the state of
your SP and TMS deployment.
In this section
This section contains the following topics:
For information on the SNMP OIDs used by SP to poll routers, see “SNMP public OIDs
that SP uses to poll routers” on page 290 .
Note
You can download up-to-date MIBs from the SP web UI on the SNMP tab of the
Configure Network Services page (Administration > System Maintenance >
Network Services).
For information on downloading a MIB file, see "Configuring Network Services" in the
SP and TMS User Guide .
.1.3.6.1.2.1.1.2.0 sysObjectID
.1.3.6.1.2.1.1.3.0 sysUptime
.1.3.6.1.2.1.1.4.0 sysContact
.1.3.6.1.2.1.1.5.0 sysName
.1.3.6.1.2.1.1.6.0 sysLocation
.1.3.6.1.2.1.1.7.0 sysServices
.1.3.6.1.4.1.9694.1.4.2.1.1.0 deviceCpuLoadAvg1min
.1.3.6.1.4.1.9694.1.4.2.1.2.0 deviceCpuLoadAvg5min
.1.3.6.1.4.1.9694.1.4.2.1.3.0 deviceCpuLoadAvg15min
.1.3.6.1.4.1.9694.1.4.2.1.4.0 deviceDiskUsage
.1.3.6.1.4.1.9694.1.4.2.1.5.0 devicePhysicalMemory
.1.3.6.1.4.1.9694.1.4.2.1.6.0 devicePhysicalMemoryInUse
.1.3.6.1.4.1.9694.1.4.2.1.7.0 devicePhysicalMemoryUsage
.1.3.6.1.4.1.9694.1.4.2.1.8.0 deviceSwapSpace
.1.3.6.1.4.1.9694.1.4.2.1.9.0 deviceSwapSpaceInUse
.1.3.6.1.4.1.9694.1.4.2.1.10.0 deviceSwapSpaceUsage
.1.3.6.1.4.1.9694.1.4.2.1.12.0 deviceTotalFlowsHC
Note
SP also exposes IF-MIB, which provides network interface traffic information. IF-MIB is
defined in RFC-2863. In addition to OIDs in the previous table and IF-MIB, other OIDs
might be exposed by SP; however, they are not officially supported.
.1.3.6.1.4.1.9694.1.5.2.2.0 tmsHostUpTime
.1.3.6.1.4.1.9694.1.5.2.3.0 deviceCpuLoadAvg1min
.1.3.6.1.4.1.9694.1.5.2.4.0 deviceCpuLoadAvg5min
.1.3.6.1.4.1.9694.1.5.2.5.0 deviceCpuLoadAvg15min
.1.3.6.1.4.1.9694.1.5.2.6.0 deviceDiskUsage
.1.3.6.1.4.1.9694.1.5.2.7.0 devicePhysicalMemoryUsage
.1.3.6.1.4.1.9694.1.5.2.8.0 deviceSwapSpaceUsage
.1.3.6.1.4.1.9694.1.5.2.9.0 tmsTrapString
.1.3.6.1.4.1.9694.1.5.2.10.0 tmsTrapDetail
.1.3.6.1.4.1.9694.1.5.2.11.0 tmsTrapSubhostName
.1.3.6.1.4.1.9694.1.5.2.12.0 tmsTrapComponentName
.1.3.6.1.4.1.9694.1.5.2.13.0 tmsTrapBgpPeer
.1.3.6.1.4.1.9694.1.5.2.14.0 tmsTrapGreSource
.1.3.6.1.4.1.9694.1.5.2.15.0 tmsTrapGreDestination
.1.3.6.1.4.1.9694.1.5.2.16.0 tmsTrapNexthop
.1.3.6.1.4.1.9694.1.5.5.1.1.0 tmsVersion
.1.3.6.1.4.1.9694.1.5.5.1.2.0 tmsLastUpdate
.1.3.6.1.4.1.9694.1.5.5.2.1.0 tmsMitigationLastUpdate
.1.3.6.1.4.1.9694.1.5.5.2.3.0 tmsMitigationTable
.1.3.6.1.4.1.9694.1.5.5.2.3.1.1.0 tmsMitigationIndex
This is an entry of the tmsMitigationTable.
.1.3.6.1.4.1.9694.1.5.5.2.3.1.2.0 tmsMitigationId
This is an entry of the tmsMitigationTable.
.1.3.6.1.4.1.9694.1.5.5.2.3.1.3.0 tmsDestinationPrefix
This is an entry of the tmsMitigationTable.
.1.3.6.1.4.1.9694.1.5.5.2.3.1.4.0 tmsDestinationPrefixMask
This is an entry of the tmsMitigationTable.
.1.3.6.1.4.1.9694.1.5.5.2.3.1.5.0 tmsMitigationName
This is an entry of the tmsMitigationTable.
Note
SP also exposes IF-MIB, which provides network interface traffic information. IF-MIB is
defined in RFC-2863. In addition to OIDs in the preceding table and IF-MIB, other OIDs
might be exposed by SP; however, they are not officially supported.
.1.3.6.1.4.1.9694.1.5.3.0.2.0 greTunnelDown
.1.3.6.1.4.1.9694.1.5.3.0.3.0 greTunnelUp
.1.3.6.1.4.1.9694.1.5.3.0.4.0 tmsLinkUp
This is obsolete. TMS now sends IF-MIB::linkUp
instead.
.1.3.6.1.4.1.9694.1.5.3.0.5.0 tmsLinkDown
This is obsolete. TMS now sends IF-MIB::linkDown
instead.
.1.3.6.1.4.1.9694.1.5.3.0.6.0 subHostUp
.1.3.6.1.4.1.9694.1.5.3.0.7.0 subHostDown
.1.3.6.1.4.1.9694.1.5.3.0.8.0 tmsBgpNeighborDown
.1.3.6.1.4.1.9694.1.5.3.0.10.0 tmsNexthopDown
.1.3.6.1.4.1.9694.1.5.3.0.11.0 tmsNexthopUp
.1.3.6.1.4.1.9694.1.5.3.0.12.0 tmsMitigationError
.1.3.6.1.4.1.9694.1.5.3.0.13.0 tmsMitigationSuspended
.1.3.6.1.4.1.9694.1.5.3.0.14.0 tmsMitigationRunning
.1.3.6.1.4.1.9694.1.5.3.0.15.0 tmsConfigMissing
.1.3.6.1.4.1.9694.1.5.3.0.16.0 tmsConfigError
.1.3.6.1.4.1.9694.1.5.3.0.17.0 tmsConfigOk
.1.3.6.1.4.1.9694.1.5.3.0.18.0 tmsHwDeviceDown
.1.3.6.1.4.1.9694.1.5.3.0.19.0 tmsHwDeviceUp
.1.3.6.1.4.1.9694.1.5.3.0.20.0 tmsHwSensorCritical
.1.3.6.1.4.1.9694.1.5.3.0.21.0 tmsHwSensorOk
.1.3.6.1.4.1.9694.1.5.3.0.22.0 tmsSwComponentDown
.1.3.6.1.4.1.9694.1.5.3.0.23.0 tmsSwComponentUp
.1.3.6.1.4.1.9694.1.5.3.0.24.0 tmsSystemStatusCritical
.1.3.6.1.4.1.9694.1.5.3.0.25.0 tmsSystemStatusDegraded
.1.3.6.1.4.1.9694.1.5.3.0.26.0 tmsSystemStatusNominal
System alerts
You can enable notifications for the following types of system alerts:
n clock skew
n 15-minute CPU load
n high disk usage
n dropped flows
n high memory usage
n process error
n short-term terrd runtime
References:
n For information about configuring the thresholds for system alerts, see “Configuring SP
System Monitoring Alerts” in the SP and TMS User Guide .
n For information about setting the default notification group to receive the system alert
notifications, see “Configuring Global Notification Settings for Alerts” in the SP and TMS
User Guide .
Note
In the DoS alert formats described below, the third section is specific to DoS Profiled
Router, the fourth section is specific to DoS Host, and the fifth section is specific to DoS
Profiled Network.
Output format
I. Conventions
The syslog format is described in pseudo BNF.
/* This is a comment */
INTEGER = whole number eg 10
FLOAT = decimal number eg 10.25
DATE = YYYY-mm-dd HH:MM:SS +-ZZZZ /* ISO 8601: 1970-01-01 00:00:00 +0000 */
LOCAL_DATE = YYYY-mm-dd HH:MM:SS LOCAL_TZ
SECONDS = count of seconds
IP = IP address eg 10.0.1.1
CIDR = prefix in cidr notation eg 10.0.1.0/24
TEXT = non whitespace characters
MESSAGE = TEXT + possible whitespace
NAME = TEXT + possible whitespace
USERNAME = TEXT
APPLICATION_NAME = TEXT + possible whitespace
FAMILY = customer | profile | peer | vpn | vpnsite | worm
SERVICE_ELEMENT = jitter | loss | bps | pps
UNIT_KMG = bps | pps | Kbps | Kpps | Mbps | Mpps | Gbps | Gpps
USAGE_TYPE = high | low
ROUTER_TYPE = Edge | Core
LICENSE_ROUTER = ROUTER_TYPE routers
LICENSE_RESOURCE = LICENSE_ROUTER
DIRECTION = incoming | outgoing
II. Common Syslog Message format
/*
* Top-level definition
*/
syslog_msg = msg_header msg_body
/*
* msg_header description
*/
msg_header = <priority>date tag:
/* msg_header fields */
priority = INTEGER /* logical OR of facility and severity */
date = mmm dd HH:MM:SS /* Jan 01 00:00:00 - no year */
tag = [pfsp] /* process description - no PID */
The remainder of this document describes the message bodies for different
syslog message types.
III. Description of DoS Profiled Router Alert syslog msg_body
/*
* dos profiled router msg_body description
*/
msg_body = anomaly anomaly_type id INTEGER status status_type
severity INTEGER classification classification_type
impact “FLOAT UNIT_KMG/FLOAT UNIT_KMG” detail_body
/* anomaly_body fields */
anomaly_type = NONE | AH | Bandwidth | ESP | GRE | ICMP | ICMPv6 |
Multi Protocol | TCP | UDP
status_type = ongoing | done
classification_type = low | medium | high /* 1=low, 3=medium, 5=high */
impact “FLOAT UNIT_KMG/FLOAT UNIT_KMG” /* 10.34 Mbps/10.34 Kpps */
/* detail_body description */
detail_body = resource_body | router_body*
/*
* For DoS profiled router syslog messages, there will be one message
* containing a resource body, followed by a message containing a router body
* for each input and output interface in the alert.
*
* A source or destination CIDR of 0.0.0.0/0 means N/A. Only a source or a
* destination is valid, not both.
*/
/* resource_body description */
resource_body = ipVer ip_version src CIDR TEXT dst CIDR TEXT start DATE
duration SECONDS percent FLOAT rate FLOAT rateUnit rateUnit_type
protocol protocol_type flags flags_type url TEXT,
(managed object "managed_object_name"),
(parent managed object "parent_name"), (Router "router_name"),
(Interface "interface_name")
/* resource_body fields */
ip_version = 4 | 6
rateUnit_type = bps | pps /* eg Mbps, Kpps */
protocol_type = proto | multi-protocol | nil
proto = tcp | udp | gre | esp | ... /* IP protocol name */
flags_type = [SAFRPUEW] | nil /* tcp flags */
/* Flow Down */
msg_body = Flow down for router NAME, leader NAME since LOCAL_DATE
/* Flow Restored */
msg_body = Flow restored for router NAME, leader NAME at LOCAL_DATE
/* Hardware Failure Alert start */
msg_body = Hardware failure on NAME since LOCAL_DATE: TEXT
/* Hardware Failure Alert Done */
msg_body = Hardware failure on NAME done at LOCAL_DATE: TEXT
/* Interface Usage Alert start */
msg_body = USAGE_TYPE interface usage alert #INTEGER started at LOCAL_
DATE for router NAME interface "NAME" speed FLOAT Mbps threshold INT%
observed FLOAT Mbps pct FLOAT%
/* Interface Usage Alert Done */
msg_body = USAGE_TYPE interface usage alert #INTERGER ended at LOCAL_
DATE for router NAME interface "NAME"
/* License Alert Start */
msg_body = License Alert: LICENSE_RESOURCE (INTEGER) exceeds the
licensed limit of INTEGER, alert id: INTEGER
/* License Alert Done */
msg_body = License alert ended at LOCAL_DATE: LICENSE_RESOURCE
(INTEGER) exceeds the licensed limit of INTEGER, alert id: INTEGER
/* Managed Object Threshold */
msg_body = USAGE_TYPE usage alert #INTEGER for FAMILY NAME threshold
INTEGER UNIT_KMG observed FLOAT UNIT_KMG, (parent managed object "NAME")
/* Managed Object Threshold Done */
msg_body = USAGE_TYPE usage alert #INTEGER for FAMILY NAME done,
(parent managed object "NAME")
/* SNMP Down */
msg_body = SNMP down for router NAME, leader NAME since LOCAL_DATE
/* SNMP Up */
msg_body = SNMP restored for router NAME, leader NAME at LOCAL_DATE
/* BGP Hijack */
msg_body = BGP Hijack local_prefix CIDR router NAME bgp_prefix CIDR
bgp_attributes BGP_ATTR started: LOCAL_DATE
/* BGP Hijack Done */
msg_body = BGP Hijack for prefix CIDR router NAME done at LOCAL_DATE
/* Fingerprint Threshold */
msg_body = USAGE_TYPE usage alert #INTEGER for fingerprint NAME
threshold INTEGER UNIT_KMG observed INTEGER UNIT_KMG
/* Fingerprint Threshold Done */
msg_body = USAGE_TYPE usage alert #INTEGER for fingerprint NAME done
/* GRE Down */
msg_body = GRE tunnel NAME (IP > IP) down for destination IP, leader
NAME since LOCAL_DATE
To configure these settings on a TMS appliance, see “Configuring Syslog to Send the TMS
Appliance Log Messages to a Remote Host” on page 239 .
The configured limit appears as a dashed line on the graph of the metric for that
appliance. This dashed line represents what is considered to be the maximum amount of
usage that should be seen for that appliance for that metric. This line makes it easy to see
when a metric is approaching its limit.
The System-Wide and Appliance Limits document lists the enforced and guideline limits
for Arbor Networks appliances. In this document, only the limits that are followed by an
asterisk are appliance metrics that appear on the Appliance Monitoring page. Before
configuring a limit for an appliance metric, consult this document to see if it includes limits
for that metric. You can access this document at https://support.arbornetworks.com/.
metric_label = the label for the metric whose limit you want to clear
For a list of the metric labels, see “Appliance metric labels” below.
3. To commit the clearing of the limit of an appliance metric, enter config write
Introduction
This section describes CLI commands and other information for maintaining your SP
deployment.
In this section
This section contains the following topics:
n data
n system
The data partitions can reach capacity, depending on your system’s logging and traffic
monitoring parameters. If your system is close to capacity, contact your Arbor Networks
Consulting Engineer.
Example
The following example shows how to view the disk space on the mariner1 appliance.
admin@mariner1:/# / system disks show
Filesystem status:
Filesystem Size/Used Inodes/Used
boot 1011M/438M (43%) 132059/35 (0%)
data 264G/794M (0%) 71235850/30452 (0%)
system 3.9G/687M (17%) 515941/19865 (4%)
RAID volume 0,0 status:
Controller status:
Controller Memory: 64 Mbytes
Battery State: Ok
Controller Software: 5.2-0 (Build #xxxx)
Volume status:
Type: Mirror, Size: 279GB, Task: None
Disk Vendor Model Firmware
0:00:0 SEAGATE ST3300007LC 0005
0:01:0 SEAGATE ST3300007LC 0005
admin@mariner1:/system/disks#
When you configure high availability, SP automatically synchronizes data (in real-time)
between the leader appliance and all SP appliances in the deployment that have the user
interface role. You can configure the backup leader to take over automatically if the leader
has been out of contact for a specified time period with minimal data loss. Alternatively,
you can manually initiate the failover to the backup leader.
Note
With flexible licensing on a physical appliance, you must upload the flexible license to
both the leader appliance and the backup leader appliance. You can upload the flexible
license to the leader appliance on the Deployment Status page (System > Status >
Deployment Status). To upload the flexible license to the backup leader, you must use
the CLI. See "Uploading a Flexible License" in the SP and TMS User Guide.
Note
With cloud-based flexible licensing, you configure the leader so that it has access to the
license server and the backup leader automatically receives the URL configuration that it
needs to access the license server. See SP and TMS Licensing Guide at
https://support.arbornetworks.com.
Synchronization
The system automatically synchronizes the following information between the leader and
the backup leader (and any other appliances that have the user interface role in your
deployment):
n alert data
n mitigation data
n configuration and configuration history
n interface classification and interface history
Tip
To see this in the web UI, navigate to the Interface Configuration History page
(Administration > Monitoring > Interface Configuration History ).
n custom menus (“skins”)
n custom XML report templates
Important
If you convert the leader appliance to flexible license mode, you must also convert the
backup leader to flexible license mode. For information about uploading a flexible
license to your deployment, see "Uploading a Flexible License" in the SP and TMS User
Guide.
on the appliance on which it was run. When a failover occurs, scheduled reports appear
on the backup appliance, but any manual reports run on the original leader do not. Also,
the results of scheduled reports that are created before a backup appliance is added to
your deployment do not appear on the backup appliance. To avoid losing report data, you
can back up your reports using the standard backup process.
You can only perform manual backups on the leader appliance that has the user interface
role.
For instructions about the standard backup process, see “Managing System Backups” in
the SP and TMS User Guide .
Deployment requirements
To implement a high availability failover system, your deployment should meet the
following criteria:
n The leader should have a reasonable automatic DoS alert deletion policy configured.
This limits the amount of data that the system must back up.
n The data connection between the leader and the backup leader should be at least 100
Mbps.
When a failover occurs, the backup leader performs the following steps:
1. It removes the failed leader from the system configuration. It does this to prevent the
failed leader from recovering and attempting to operate in conflict with the new
leader.
2. It automatically reconfigures itself as the leader of the deployment and reconfigures
all other appliances to recognize it as the new leader.
3. It restarts SP services on itself and assumes operation as the leader, with all of the
previously synchronized data from the failed leader.
This does not require a system reboot.
Configuring high availability on an appliance that has the user interface role
You configure the high availability settings on the High Availability tab of an appliance
that has the user interface role. You designate the appliance as a backup leader. You then
specify the number of minutes that you want the backup leader to wait after losing contact
with the leader before it takes over as the leader. If you don’t specify the number of
minutes, the automated failover is disabled.
See “Configuring High Availability Settings” in the SP and TMS User Guide .
Identifying a failover
The way to identify that a failover occurred depends on how you are using the system at
the time of failover as follows:
Failover indications
Backup leader The backup leader stops SP services briefly to reconfigure itself as
the leader. For a few minutes, you cannot log in to its web UI.
Other appliances Pages either time out or are slow to load when the leader fails and
that have the user the backup leader takes over as the leader. The time frame for this
interface role is a few minutes for the actual failover plus the amount of time that
you set for an automatic failover timeout. The original leader is
automatically removed from your deployment, so it does not
appear in the Appliances list in the web UI.
Appliances that do The backup leader sends you an email that informs you that the
not have the user configuration has changed due to a failover.
interface role You only receive an email if you are part of the default notification
group.
You can view the status of backups on the Manage Backups page (Administration >
System Maintenance > Backups > Backup Status tab) in the web UI.
Incremental Backups:
Export URL: scp://user@server/path/
Backup Time: 2:33
Schedule Interval: Weekly
Scheduled Days of the Week: 0
Note
You should manually switch to the backup leader only when the leader is offline. If the
leader is online when you manually switch to the backup leader, a warning message
appears.
Example
The following example shows how to manually switch to a backup leader:
admin@mariner1:/# / services sp backup failover activate
Are you sure? [n] y
For additional information about configuring high availability with a VM leader and VM
backup leader, see Running SP 8.4 in a Virtual Machine at
https://support.arbornetworks.com/.
Wait until the appliance status message in the web UI no longer indicates that the
backup leader (the failed leader) is unsynchronized with the new leader.
2. Follow the instructions in “Manually Switching to the Backup Leader Appliance” on
page 252 to initiate failover to the backup leader (the failed leader in Step 1).
The leader fails, and the backup leader (the original failed leader) becomes the new
leader.
3. Follow the instructions in “Recovering after a failover” on the previous page to
configure the manually failed leader to become the new backup leader.
To perform all other backup tasks, navigate to the Manage Backups page in the web UI
(Administration > System Maintenance > Backups ).
Format
Element String Description
Day
Week
Month
Format
Element String Description
%m Two-digit representation of the month.
Year
Time
%R Same as "%H:%M."
%T Same as "%H:%M:%S."
Format
Element String Description
%F Same as "%Y-%m-%d" (commonly used in
database datestamps).
Examples
The following are examples of common timestamp formats:
Example 1
Example 1 shows the following format: %d for the two-digit day of the month, hyphen, %m
for the two-digit month, hyphen, and %Y for the four-digit year.
admin@mariner1:/# services sp backup remote filename set %d-%m-%Y
Date format set. Example: mariner1-backup-16-04-2009-level0.tar
Example 2
Example 2 shows the following format: %Y for the four-digit year, hyphen, %m for the two-
digit month, hyphen, %d for the two-digit day, hyphen, %H for the hour in 24-hour format,
colon, %M for the minutes, colon, and %S for the seconds.
admin@mariner1:/# services sp backup remote filename set
%Y-%m-%d-%H:%M:%S
Date format set. Example: mariner1-backup-2009-04-16-14:10:34-level0.tar
Example 3
Example 3 shows the following format: %b for the three-character month, %d for the two-
digit day, underscore, and %Y for the four-digit year.
admin@mariner1:/# services sp backup remote filename set %b%d_%Y
Date format set. Example: mariner1-backup-Apr16_2009-level0.tar
Example 4
Example 4 shows the following format: % m for the two-digit month, %d for the two-digit
day, and %Y for the four-digit year (2009)
admin@mariner1:/# services sp backup remote filename set %m%d%Y
Date format set. Example: mariner1-backup-04162009-level0.tar
Introduction
Flowspec is a BGP-based IETF standard for exchanging flexible firewall and ACL rules. You
can use routers and switches that support flowspec to integrate with SP and mitigate DoS
and DDoS attacks and other anomalous traffic on your network.
The procedures in this section describe Juniper routers; however, the procedures to
configure other brands of routers are similar. For more information about configuring
other flowspec routers, please see the documentation for your router.
In this section
This section contains the following topics:
Note
Verify that the router you are configuring is flowspec capable. If you are configuring a
Juniper router, it must utilize JunOS version 7.3 or later.
Note
To implement Flowspec ACLs, the Flow Specification capability must be enabled for a
router on the BGP tab of the Add/Edit Router page in the web UI. See "Configuring Router
BGP Settings" in the SP and TMS User Guide .
For more information on enabling a flow specification mitigation in the SP web UI, see
“Mitigating Using Flow Specification: A Use Case” in the SP and TMS User Guide .
Example
The following example shows how to configure the Juniper router with the flowspec group
name set to arborsp, a policy name set to arbor_policy, and the IP address of the SP
appliance monitoring this router set to 1.2.3.4:
mx240> set protocols bgp group arborsp neighbor 1.2.3.4 family inet
flow
mx240> set policy-options policy-statement arbor_policy from neighbor
1.2.3.4
Introduction
This section contains the instructions for configuring your routers and switches to
generate and forward flow and send SNMP information to your SP appliances.
In this section
This section contains the following topics:
To view current values for supported router interfaces and flow sources, see the SP
Release Notes.
For more information about supported NetFlow versions, see the SP Release Notes.
GSR-1>enable
Password:
GSR-1#configure
Configuring from terminal, memory, or network [terminal]?
enter configuration commands, one per line. End with CNTL/Z.
GSR-1(config)#ip flow-export version 5
GSR-1(config)#ip flow-sampling-mode packet-interval 1000
GSR-1(config)#
For these instructions, see the topic "Configuring Appliance Settings for an SP Appliance"
in the SP and TMS User Guide .
The Juniper architecture exports flow monitoring records that summarize the traffic that
matches a configured sampling filter, or all traffic if sampling is configured directly for an
interface instead of as a filter. The matching traffic is sampled at the configured sampling
rate. Properly configuring flow monitoring is critical for optimal SP performance, so use
the information in this topic to familiarize yourself with how these systems integrate.
See your router documentation to determine whether your router supports this feature.
Supported versions
Juniper supports Netflow-compatible flow monitoring functionality on all M series, T series,
TX matrix, J series, and MX series routers, as well as on SRX-series gateways. The JUNOS
software version needed to support flow monitoring will depend on the specific Juniper
hardware and desired flow monitoring features. When router hardware is released, flow
monitoring support should be available, but it sometimes is not available until several
JUNOS software releases later. It is always best to consult the Juniper release notes for
more information on your specific requirements. EX-series switches support flow
monitoring as of sFlow version 5, and this version is also interoperable with SP.
As a general rule, all modern M and T series routers have native RE-based support for flow
version 5. M series and T series routers additionally support optional services PIC modules
that offer better flow monitoring performance, monitoring of MPLS and IPv6 traffic, and
flow version 9. Flow monitoring of MPLS traffic requires JUNOS version 8.3 or later. Flow
monitoring of IPv6 traffic requires JUNOS version 9.3 or later. Arbor recommends JUNOS
version 9.3 or later for all flow version 9 applications due to functionality improvements.
JUNOS version 8.5 is required for flow monitoring on an MX series router using a
Multiservices DPC module. JUNOS version 10.2 is required for inline flow monitoring
without a MS-DPC module. However, because JUNOS version 10.2 without a MS-DPC
module can monitor only a single protocol, an MS-DPC module is required for
multiprotocol monitoring.
J series routers and SRX services gateways support RE-based flow version 5 in JUNOS
versions 7.0 through 10.4. Inline flow monitoring of IPv4 is supported in JUNOS version
10.4 and later for either flow version 5 or flow version 9, although only monitoring of IPv4
is supported.
Juniper does not recommend sampling at a rate more frequently than 1/1,000; however,
Arbor has successfully used sampling rates less than 1,000.
Some Juniper routers enforce the active flow timeout parameter. For example, a Juniper
router that is equipped with a Multiservices PIC (MS-PIC) enforces this parameter. For
these routers, Arbor recommends that you set the active flow timeout to one minute,
which should not affect router performance.
For Juniper routers that do not enforce the active flow timeout parameter, it is not
necessary to set active and inactive flow timeouts in JunOS. The sampled packets are
aggregated in one-minute “bins” and flows are always expired at this one-minute interval.
They do not time out or expire based on information in the packet (such as TCP flags).
Because of this, settings like active timeout and inactive timeout do not apply; both are
always one minute.
Command Description
set forwarding-options Sets a limit on the number of packet headers that
sampling input family inet are sampled per second.
max-packets-per-second Although the maximum allowed value is 65535, the
number system might have a defined hard limit that is lower
than this value. The system-defined hard limit
depends on the type of hardware and software you
use.
Command Description
set forwarding-options Sets the IP address of the SP appliance that receives
sampling output cflowd IP_ the cFlowd output packets.
address
set forwarding-options Sets the UDP destination port to the port number
sampling output cflowd IP for the SP appliance that receives the cFlowd output
address port portnumber packets.
Recommended values are between 2000 and
65535.
Enabling interfaces
You should apply the cFlowd filter to each interface on the router that sees inbound traffic
for your customers.
The following example shows how to enable sampled cFlowd on interface e3/4/1:
admin@m5# set forwarding-options sampling output cflowd 192.168.10.11
version 5
admin@m5# set interfaces e3/4/1 unit 0 family inet sampling
For these instructions, see “Configuring Routers” in the SP and TMS User Guide .
output {
cflowd 100.10.100.10 {
port 2055;
source-address 100.10.100.15;
version9 {
template {
mpls;
}
}
autonomous-system-type origin;
}
interface sp-0/0/0 {
source-address 100.10.100.15;
}
}
}
}
routing-options {
route-record;
}
protocols {
bgp {
local-as 65400;
group Arbor {
type internal;
local-address 100.10.100.15;
family inet-vpn {
unicast;
}
authentication-key t3lu5labs;
peer-as 65400;
cluster 1.1.1.1;
neighbor 100.10.100.10 {
description ArborFS1-TOROLABFS1;
}
}
}
services {
flow-monitoring {
version9 {
template mpls {
mpls-template {
label-position [ 1 2 3 ];
}
}
}
}
}
snmp {
name TOROLABPE4;
community t3lu5labs {
authorization read-only;
clients {
0.0.0.0/0 restrict;
100.10.100.10/12;
}
}
}
To configure your sFlow devices to send flow records to SP, you must configure the agent
to forward the flows to an SP appliance and then configure the SP appliance to receive
them. Configuration instructions vary depending on the type of sFlow agent that you
configure.
sFlow devices
sFlow is a sampled protocol that performs a sampling of flow data and does not forward
every flow across a switch or router to your SP appliance. Because of this, SP might not be
able to detect or identify security events that require observing every flow.
This topic provides specific configuration instructions for the following router types:
n Foundry
n Alaxala
n Force10
For more information about sFlow devices, see the sFlow organization website at
http://sflow.org.
For more information on a particular type of switch or router, see that router’s product
documentation.
Tip
You can find the IP address on the Configure Appliances page (Administration >
Appliances) in the SP web UI.
6. To enter the configuration mode, enter interface name
name = the name of the interface that you want the switch to use to forward data
to the SP appliance
7. To set forwarding for that interface, in the interface menu, enter sflow forwarding
After you configure a Foundry device to send sFlow packets to the SP appliance, it
continues forwarding packets until you disable the function.
8. Enter sflow sampling rate
rate = the appropriate sampling rate for the traffic load of your interface
For example, enter 100 if you want the sampling rate of 1 out of every 100 packets.
9. To return to the configuration menu, enter exit
For more information about configuring sFlow on Alaxala routers, see the Alaxala router
documentation.
Password
alaxala# config
alaxala(config)# sflow yes
alaxala(config)# sflow
[sflow]
alaxala(config)# set destination 10.0.0.1
[sflow]
alaxala(config)# sample 3
[sflow]
alaxala(config)# version 4
alaxala(config)exit
alaxala(config)# show sflow
sFlow service status: enable
sFlow service version: 4
Progress time from sFlow statistics cleared: 2 day
Received sFlow samples:12444692 Dropped sFlow samples:132300
Collector exported sFlow samples:12444689 Couldn’t exported sFlow
samples:0
Collector IP address: 10.0.2.140 UDP:6343 Source IP address: 10.0.2.3
Send FlowSample UDP packets:2527966 Send failed:0
Send CounterSample UDP packets:1204 Send failed:0
Collector IP address: 10.0.2.153 UDP:6343 Source IP address: 10.0.2.3
Send FlowSample UDP packets:2527966 Send failed:0
Send CounterSample UDP packets:1204 Send failed:0
Collector IP address: 10.0.2.208 UDP:6343 Source IP address: 10.0.2.3
Send FlowSample UDP packets:2527966 Send failed:0
Send CounterSample UDP packets:1204 Send failed:0
Collector IP address: 10.0.2.236 UDP:6343 Source IP address: 10.0.2.3
Send FlowSample UDP packets:2527966 Send failed:0
Send CounterSample UDP packets:1204 Send failed:0
CounterSample interval rate:300
Default configured rate:32 Default actual rate:32
Configured sFlow port: 0/0 - 0/1
For more information about configuring sFlow on Force10 routers, see the Force10 router
documentation.
sFlow contains an agent address in the payload, which can be an IPv4 or IPv6 address.
Typically, you can set this on the sFlow appliance; however some Foundry switches do not
allow you to set the source IP address of sFlow packets. sFlow looks at the agent address
instead of the source IP address of the sFlow packet when deciding whether or not the
packet came from a configured router. To correct this issue, you can allow many-to-one
mappings of export IP addresses to routers using the SP web UI.
For detailed information about these configurations, cFlowd, and your router, see the
Alcatel product documentation.
About cFlowd
The Alcatel 7750 router supports cFlowd versions 5 and 8. When the flow cache of the
router exports a flow, the router sends the collected data to an SP appliance. The SP
appliance retains the historical data flows so that network operators can use the flows to
analyze traffic patterns.
Command Description
configure cflowd Configures the number of minutes that you want the router
active-timeout to retain the current flow before the cache deletes it and a
new flow is created.
configure cflowd Identifies the SP appliance used to collect cFlowd data. You
collector must configure the IP address of the flow collector, and you
can optionally configure the UDP port number.
configure cflowd Specifies the number of seconds that must pass without a
inactive-timeout packet matching a flow in order for the flow to be considered
inactive.
configure cflowd Specifies the rate at which the router samples traffic and
rate sends it for flow analysis. If you configure the sampling rate as
1, then all packets are sent to the cache. If you configure the
sampling rate as 100, then one in every 100 (1/100) packets is
sent to the cache.
Enabling cFlowd
To enable cFlowd:
1. Log in to the router (through Telnet or SSH) using your user name and password.
2. Enter configure
3. Enter cflowd no shutdown
exit
For these instructions, see “Configuring Routers” in the SP and TMS User Guide .
For more information about configuring SNMP on your Alcatel router, see the 7750 SR OS
System Management Guide .
Enabling SNMP in SP
After you configure your Alcatel routers with SNMP, you must configure SNMP in SP. For
these instructions, see “Configuring Routers” in the SP and TMS User Guide .
For information on the level of SNMP polling that is supported in SP for the Alcatel 7750
router, see “Supported SNMP Polling with Alcatel 7750 Router ” on the facing page.
Line Card
OS Version Type Chassis Mode Supported Operation
is 8 or less Any Any Poll standard MIB.
Only the interfaces in virtual
router 1 will have SNMP values.
You may need to change firewall and ACL rules to allow SP to poll these OIDs or
reconfigure routers to reply to this information.
.1.3.6.1.2.1.1.2 system.sysObjectID
.1.3.6.1.2.1.2.2.1.2 interfaces.ifTable.ifEntry.ifDescr
.1.3.6.1.2.1.2.2.1.5 interfaces.ifTable.ifEntry.ifSpeed
.1.3.6.1.2.1.2.2.1.8 interfaces.ifTable.ifEntry.ifOperStatus
.1.3.6.1.2.1.31.1.1.1.1 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName
.1.3.6.1.2.1.31.1.1.1.18 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifAlias
.1.3.6.1.2.1.31.1.1.1.15 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHighSpeed
.1.3.6.1.2.1.31.1.1.1.6 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCInOctets
.1.3.6.1.2.1.31.1.1.1.7 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCInUcastPkts
.1.3.6.1.2.1.31.1.1.1.8 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCInMulticastPkts
.1.3.6.1.2.1.31.1.1.1.9 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCInBroadcastPkts
.1.3.6.1.2.1.31.1.1.1.10 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCOutOctets
.1.3.6.1.2.1.31.1.1.1.11 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCOutUcastPkts
.1.3.6.1.2.1.31.1.1.1.12 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCOutMulticastPkts
.1.3.6.1.2.1.31.1.1.1.13 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCOutBroadcastPkts
.1.3.6.1.2.1.4.20.1.2 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex
For information on SNMP OIDs that management systems use to poll SP appliances, see
“Configuring Alert Management Software” on page 222 .
.1.3.6.1.2.1.2.2.1.10 interfaces.ifTable.ifEntry.ifInOctets
.1.3.6.1.2.1.2.2.1.11 interfaces.ifTable.ifEntry.ifInUcastPkts
.1.3.6.1.2.1.2.2.1.16 interfaces.ifTable.ifEntry.ifOutOctets
.1.3.6.1.2.1.2.2.1.17 interfaces.ifTable.ifEntry.ifOutUcastPkts
.1.3.6.1.2.1.31.1.1.1.3 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifInBroadcastPkts
.1.3.6.1.2.1.31.1.1.1.4 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifOutMulticastPkts
.1.3.6.1.2.1.31.1.1.1.5 ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifOutBroadcastPkts
When available, the CPU and memory values displayed for each router are shown only for
the primary route processor.
A
AAA (Authentication, Authorization, & Accounting) — This is an acronym used to describe the
process of authorizing access to a system, authenticating the identity of users, and logging their
behaviors.
ACL (Access Control List) — A list composed of rules and filters stored in a router to allow, deny, or
otherwise regulate network traffic based on network parameters such as IP addresses, protocol
types, and port numbers.
AES (Advanced Encryption Standard) — A commonly used encryption block cipher adopted as the
standard of the U.S. government.
AIF (ATLAS Intelligence Feed) — Real-time threat information that is an Arbor-maintained feed
consisting of a database of security threats and signatures that automatically updates each minute
and DDoS regular expressions that are used by TMS to mitigate attacks. SP regularly downloads
this information and uses it to detect and block emerging botnet attacks and application-layer
attacks.
anomaly — An event or condition in the network that is identified as an abnormality when compared to a
predefined illegal traffic pattern.
anonymous statistic sharing — A service whereby service providers and enterprise businesses share
anonymized statistics on ongoing attacks in order to provide an internet-wide view of ongoing
attacks.
API (Application Programming Interface) — A well-defined set of function calls providing high-level
controls for underlying services.
appliance — An Arbor Networks server that gathers network statistics from adjacent routers via either
packet capture or flow and performs first-order traffic analysis. Anomalous activities are
compressed into alert messages that are periodically sent to the listening leader.
ARP (Address Resolution Protocol) — A protocol for mapping an IP address to a physical machine
address.
AS (Autonomous System) — A collection of IP networks and routers under the control of one entity
and assigned a single ASN for purposes of BGP routing.
ASCII (American Standard Code for Information Interchange) — A coded representation for
standard alphabetic, numeric, and punctuation characters, also referred to as “plain text.”
ASN (Autonomous System Number) — A unique number assigned to an autonomous system for
purposes of BGP routing.
AS Path (Autonomous System Path) — The ASNs that comprise a packet's path through the internet
using BGP.
ATLAS (Active Threat Level Analysis System) — A globally scoped threat analysis network that
analyzes data from darknets and the internet’s core backbone to provide information to
participating customers about malware, exploits, phishing, and botnets.
B
backbone router — An OSPF router with all operational interfaces within 0.0.0.0.
baseline — A description of typical traffic patterns over a period of time. Baselines are generated by
reducing collections of fine-grained profiles into a more monolithic data representation that
includes a chronological component.
BGP (Border Gateway Protocol) — The core routing protocol of the internet.
binning — Grouping data into chunks or "bins" usually defined by time periods, for example, traffic for
the last 24 hours.
blackhole routing — A technique to route traffic to null interfaces that can never forward the traffic.
C
CA (Certificate Authority) — A third party which issues digital certificates for use by other parties. CAs
are characteristic of many public key infrastructure (PKI) schemes.
CAR (Committed Access Rate) — A tool for managing bandwidth that provides the same control as
ACL with the additional property that traffic can be regulated based on bandwidth usage rates in
bits per second.
CIDR (Classless Inter-Domain Routing) — Method for classifying and grouping internet addresses.
CIDR Group — CIDR addresses grouped together to share a common managed object configuration. The
equivalent of DoS "detection groups."
cflowd — Developed to collect and analyze the information available from NetFlow. It allows the user to
store the information and enables several views of the data. It produces port matrices, AS matrices,
network matrices, and pure flow structures.
challenge packets — Information sent by a TMS model to an unknown host in response to a request
from the unknown host. The unknown host must provide a valid response to the challenge
packets. If it does not, the TMS model refuses the request and adds the unknown host to the
blacklist. Several TMS countermeasures use challenge packets to authenticate unknown hosts.
chargen — The character generator protocol that was used for testing the TCP/IP protocol.
CLI (Command Line Interface) — A user interface that uses a command line, such as a terminal or
console (as opposed to a graphical user interface).
client — The component of client/server computing that uses a service offered by a server.
Collector — An appliance that gathers network information from adjacent routers through flow and
performs first-order traffic analysis. Anomalous events are compressed into event messages that
are then sent to the listening leader.
commit — The process of saving a configuration change so that the changes take effect on the SP system.
customer — A managed object that defines traffic for a business or organization who purchases internet
service from an internet service provider. Note, this type of managed object should be used to
define most managed services clients.
customer edge router — A router within a customer's network connected to an ISP's customer peering
edge.
D
Dark IP — Regions of the IP address space that are reserved or known to be unused.
designated router — The router designated by other routers (via the OSPF protocol) as the sender of
link state advertisements.
DHCP (Dynamic Host Configuration Protocol) — A protocol used to distribute IP addresses to host
machines, which has a list of available addresses.
DNS (Domain Name System) — A system that translates numeric IP addresses into meaningful,
human-consumable names and vice-versa.
DoS (Denial of Service) — An interruption of network availability typically caused by malicious sources.
DoS alert — A notification indicating an event or condition in the network that is identified as a statistical
abnormality when compared to typical traffic patterns gleaned from previously collected profiles
and baselines or that matches a predefined illegal traffic pattern.
E
encryption — The process by which plain text is scrambled in such a way as to hide its content.
ESP (Encapsulating Security Payload) — An IPSec protocol for establishing secure tunnels.
exploit — Tools intended to take advantage of security holes or inherent flaws in the design of network
applications, devices, or infrastructures.
F
failover — Configuring two appliances so that if one appliance fails, the second appliance takes over the
duties of the first, ensuring continued service.
fate sharing — Putting a mitigation out of service when a part of the mitigation’s deployment fails or
becomes unreachable. Fate sharing can occur when a dependent interface loses link, a nexthop
becomes unreachable, a BGP peer is down, a GRE tunnel is down, one or more TMS appliances or
TMS clusters are out of service, or the leader appliance becomes unreachable. For example, if
nexthop fate sharing is configured for a TMS appliance and the nexthop used by a mitigation
becomes unreachable, then the mitigation is put out of service.
FCAP — A fingerprint expression language that describes and matches traffic information.
Fibre Channel — Gigabit-speed network technology primarily used for storage networking.
firewall — A security measure that monitors and controls the types of packets allowed in and out of a
network, based on a set of configured rules and filters.
flow — Flow is a characterization of the network traffic. It defines the traffic that is seen. It provides SP with
information from layers 1, 3, and 4 for the traffic that traverses a network.
flowspec — A BGP-based IETF standard for exchanging flexible firewall and ACL rules implemented by
Juniper routers utilizing JunOS 7.3 or later.
FQDN (Fully Qualified Domain Name) — A complete domain name, including both the registered
domain name and any preceding node information.
G
GMT (Greenwich Mean Time) — A deprecated world time standard, replaced by UTC.
GRE (Generic Routing Encapsulation) — A tunneling protocol commonly used to build VPNs.
H
host — A networked computer (client or server); in contrast to a router or switch.
HTTP (HyperText Transfer Protocol) — A protocol used to transfer or convey information on the
World Wide Web. Its original purpose was to provide a way to publish and retrieve HTML pages.
HTTPS (HyperText Transfer Protocol over SSL) — The combination of a normal HTTP interaction
over an encrypted Secure Sockets Layer (SSL) or Transport Layer Security (TLS) transport
mechanism.
I
IANA (Internet Assigned Numbers Authority) — An entity that oversees global IP address allocation,
DNS root zone management, and other internet protocol assignments. It is operated by ICANN.
ICMP (Internet Control Message Protocol) — An IP protocol that delivers error and control messages
between TCP/IP enabled network devices, for example, ping packets.
IETF (Internet Engineering Task Force) — An internet standards organization that develops draft
documents and RFC documents defining protocols for the internet.
IGMP (Internet Group Management Protocol) — A communications protocol used to manage the
membership of Internet Protocol multicast groups.
intelligent filtering — A feature that adds the ability to work with an integrated filtering device to
automatically filter traffic.
IMAP (Internet Message Access Protocol) — An application layer internet protocol that allows a local
client to access email on a remote server. (Also known as Internet Mail Access Protocol, Interactive
Mail Access Protocol, and Interim Mail Access Protocol.)
IP (Internet Protocol) — A connectionless network layer protocol used for packet delivery between
hosts and devices on a TCP/IP network.
IPS (Intrusion Prevention System) — A computer security device that exercises access control to
protect computers from exploitation.
IPSec (Internet Protocol Security) — A suite of protocols for securing Internet Protocol (IP)
communications by authenticating and/or encrypting each IP packet in a data stream.
ISP (Internet Service Provider) — A business or organization that provides to consumers access to the
internet and related services.
L
LAN (Local Area Network) — A typically small network that is confined to a small geographic space.
leader — A designated SP appliance that accepts alert messages from one or more normal devices and
performs second-order traffic analysis in order to identify and visualize potential attacks. (These
were referred to as "Controllers" in previous Arbor Networks products.)
M
MAC (Media Access Control) Address — A unique hardware number associated with a networking
device.
managed object — User-defined network objects used to classify logical portions of your network or
network traffic. Managed objects can be customers, peers, profiles, VPNs, or VPN sites.
MDI (Media Dependent Interface) — An Ethernet port connection that allows network hubs or
switches to connect to other hubs or switches without a null-modem or Ethernet crossover cable.
MIB (Management Information Base) — A database used by the SNMP protocol to manage devices
in a network. Your SNMP polling device uses this to understand SP SNMP traps.
MPLS label — An identifying string for packets using the MPLS protocol.
mitigation — The process of using recommendations from SP to apply policies to your network to
reduce the effects of a worm or DoS attack.
mitigation device — A device that filters network traffic passing through it based upon a ruleset
provided by SP. This can be either a dedicated network device (TMS appliance or Flowspec capable
router) or an SP appliance with software mitigation enabled.
MS (Managed Services) — an SP appliance that has the ability to provide a web UI to allow customers a
special, restricted access to the SP system.
MTU (Maximum Transmission Unit) — The size (in bytes) of the largest packet that a given layer of a
communications protocol can efficiently forward.
multicast — Protocols that address multiple IP addresses with a single packet (as opposed to unicast
and broadcast protocols).
N
NAT (Network Address Translation) — Rewriting the source and destination addresses of IP packets
as they pass through a router or firewall.
NetFlow — A technology developed by Cisco Systems, Inc. that allows routers and other network devices
to periodically export information about current network conditions and traffic volumes.
netmask — A dotted quad notation number used by routers determine which part of the address is the
network address and which part is the host address.
network object — Network objects are portions of your network or network traffic and include both
managed objects (customers, peers, profiles, VPNs, or VPN sites) and physical network objects
(routers and interfaces).
NIC (Network Interface Card) — A hardware component that maintains a network interface
connection.
NTP (Network Time Protocol) — A protocol that is used to synchronize clock times in a network of
computers.
O
OC-3 — A fiber optic network line with transmission speeds of up to 155.52 Mbit/s.
OC-12 — A fiber optic network line with transmission speeds of up to 622.08 Mbit/s.
offnet — Traffic that leaves the network through a BGP boundary and is not destined for a configured
customer entity.
P
packet — A unit of data transmitted across the network that includes control information along with
actual content.
PCC (Packet Capture Collector) — Packet capture is a method of passively monitoring network traffic
to create flow information. The packet capture mode on an Arbor Networks appliance can be used
in cases where flow from routers is unavailable or unwanted.
PE (Provider Edge) Router — A router in a service provider's network that is connected to a customer
edge router.
peer — A managed object that describes other networks that are peering with yours.
peer to peer — (Sometimes abbreviated P2P) a computer network that relies primarily on the computing
power of the clients in the network rather than concentrating it in a relatively low number of
servers. P2P networks are typically used for connecting nodes via largely ad hoc connections.
POP (Post Office Protocol) — A TCP/IP email protocol for retrieving messages from a remote server.
port — A field in TCP and UDP protocol, packet headers that corresponds to an application level service
(for example TCP port 80 corresponds to HTTP).
profile — A managed object that defines an arbitrary subset of network traffic that does not fit any of the
other managed object types.
protocol — A well-defined language used by networking entities to communicate with one another.
Q
QoS (Quality of Service) — A method of providing different priority to different traffic, or guaranteeing
a certain level of performance to a data flow for a particular traffic type.
R
RADIUS (Remote Authentication Dial In User Service) — A client/server protocol that enables
remote access servers to communicate with a central server to authenticate dial-in users and
authorize their access to the requested system or service.
RDN (Registered Domain Name) — A domain name as registered, without any preceding node
information (for example, “arbor.net” instead of www.arbor.net).
refinement — The process of continually gathering information about anomalous activity seen.
remediation — The process of minimizing attack damage by taking the recommendations from SP and
applying reasonable changes to the network.
remote BGP routeviews — External route servers maintained by Arbor Networks which provide
information on route availability with remote ASNs.
RFC (Request For Comments) — An IETF document that defines a protocol or other standard for
internet communications.
route distinguisher — An address qualifier that is prepended to an IPv4 address to create a unique
VPN-IPv4 address.
route target — A VPN identifier. A VPN might require more than one route target.
router — A device that connects one network to another. Packets are forwarded from one router to
another until they reach their ultimate destination.
S
scoping — The container managed object within which a managed services customer's traffic view is
restricted.
secret key — A secret shared only between a sender and receiver of data.
SFlow — A standard similar to NetFlow which describes a mechanism to capture traffic data in switched
or routed networks.
site-of-origin — A BGP extended community attribute that identifies the VPN site from which a route
originates.
SMTP - (Simple Mail Transfer Protocol) — The de facto standard protocol for email transmissions
across the internet.
smurf attack — A DDoS attack that exploits misconfigured network devices to broadcast large numbers
of ICMP packets to all the computer hosts on a network.
SNMP (Simple Network Management Protocol) — A standard protocol that allows routers and
other network devices to export information about their routing tables and other state
information.
SSDP (Simple Service Discovery Protocol) — A network protocol that is used to advertise and
discover network services and devices.
SSH (Secure Shell) — A command line interface and protocol for securely getting access to a remote
computer. SSH is also known as Secure Socket Shell.
SSL (Secure Sockets Layer) — A protocol for secure communications on the internet for such things as
web browsing, email, instant messaging, and other data transfers.
T
TACACS+ (Terminal Access Controller Access Control System +) — An authentication protocol
common to UNIX networks that allows a remote access server to forward a user’s login password
to an authentication server to determine whether that user is allowed to access a given system.
target — A victim host or network of a worm or other malicious denial of service (DoS) attacks.
TCP (Transmission Control Protocol) — A connection-based, transport protocol that provides reliable
delivery of packets across the internet.
TCP/IP — A suite of protocols that controls the delivery of messages across the internet.
Telnet — A TCP protocol used primarily for unencrypted CLI communications (usually deprecated and
replaced by SSH).
TMS — an SP appliance designed for intelligent traffic filtering and DNS monitoring in conjunction with an
SP deployment.
U
UDP (User Datagram Protocol) — An unreliable, connectionless, communication protocol.
UNC (Universal Naming Convention) — A standard which originated from UNIX for identifying
servers, printers, and other resources in a network.
uptime — The time elapsed since a given host or server was last rebooted.
URI (Uniform Resource Identifier) — A protocol, login, host, port, path, etc. in a standard format used
to reference a network resource, (for example http://arbor.net/).
UTC (Universal Time Coordinated) — The time zone at zero degrees longitude which replaced GMT as
the world time standard.
V
VLAN (Virtual Local Area Network) — Hosts connected in an infrastructure that simulates a local area
network, when the hosts are remotely located, or to segment a physical local network into smaller,
virtual pieces.
VoIP (Voice over Internet Protocol) — Routing voice communications (such as phone calls) through
an IP network.
VPN (Virtual Private Network) — A private communications network often used within a company, or
by several companies or organizations, to communicate confidentially over a public network using
encrypted tunnels.
W
WAN (Wide Area Network) — A computer network that covers a broad area. (Also, Wireless Area
Network meaning a wireless network.)
WEP (Wired Equivalent Privacy) — A security scheme for wireless networks intended to provide
comparable confidentiality to a traditional wired network (in particular it does not protect users of
the network from each other).
worm — A self propagating program, usually used to spread a malicious payload across networked
computers.
X
XML (eXtensible Markup Language) — A metalanguage written in Standard Generalized Markup
Language (SGML) that allows one to design a markup language for easy interchange of documents
on the World Wide Web.
ATAC, contacting 11
6 ATLAS services
ports 26
6PE
Auto-Configuration
diversion 208
running manually 113
using to mitigate IPv6 traffic 208
auto-mitigation settings, traffic triggered
6PE mitigations
changing 202
configuring 208
autodiscovering
important things to know 208
local address space 28
important TMS appliance settings 210
A B
backup, TMS 49
access rules
backups, scheduled
adding to a VLAN subinterface of a TMS
configuring 250
appliance 119
BGP
acknowledgement question
monitoring routers with 106
adding 61
shared memory 83
editing 61
status, viewing for a TMS appliance 96
add TMS models 44
BGP interface
using ZTP 39
configuring on TMS appliance 117
administrator password
BGP session
resetting 63
labeled unicast BGP capabilities 209
AIF server address
blackhole nexthops
setting 37
custom templates 212
AIF signatures
importing 38
Alcatel 7740 router C
configuring to send cFlowd data 285 CLI
Alcatel 7750 router 289 command hierarchy 17
configuring SNMP 288 command types 18
alert database commands, using 16
resetting 82 compound commands 18
alert management software entering commands 18
configuring 222 help, using 18
alert notifications logging in 15
configuring 226 saving configuration 19
alert pages viewing current configuration 19
changing search result settings 175 viewing current directory status 19
alerts 173 cloud-based licensing
appliance CLI 70
configuring scheduled backups 250 installing 70
replacing with an RMA replacement 46 refreshing manually 70
securing 56 console
appliance, TMS connecting 14
replacing with an RMA replacement 49 conventions, typographic
Arbor Technical Assistance Center, contacting 11 in commands and expressions 10
P S
password sample packet
configuring maximum length 62 configuring recording settings 203
configuring minimum length 62 sampling
default 15 disabling on a router interface 112
enabling hardening 62
serial cable
connecting for CLI setup 14 T
type 14
TACACS+
sFlow
changing default user group 185
about enabling 283
teeing NetFlow 75
configuring Alaxala routers 281
terminal emulation
configuring Force10 routers 283
about 14
configuring Foundry routers 279
Hyperterminal 14
sending to SP 279
timestamp suffix
Shared memory for BGP 83
setting 255
shell
TMS 5000
disabling access 77
reinstalling software 155
single sign-on
TMS appliance
about header-based 181
about installing patches 132
configuring header-based 183
adding a default route for a VLAN subinterface 118
slot status
adding access rules for a VLAN subinterface 119
viewing 97, 100
adding VLAN subinterfaces 118
SNMP
changing the leader 89
configuring routers 290
configuring BGP interface 117
disabling polling for a router 110
configuring VLAN subinterfaces 118
OID traps used by management systems 224
enablimg promiscuous mode 86
OIDs used to poll routers 290
enabling local blocked host logging 205
OIDs used to poll SP devices 222
obtaining valid license key 133
OIDs used to poll TMS devices 223
pinging nexthop 90
sending information to SP 290
removing VLAN subinterface 120
vendor-specific OIDs 291
replacing 49
SNMP polling 289
restoring from flash 161
using to detect flow 109
running a traceroute 93
software updates
securing 56
adding to appliances 141
viewing and clearing interface counters 99
sorting alerts 173
viewing SFP and SFP+ information 100
SP
viewing slot status 97
connecting appliance to console 14
viewing the BGP status 96
installing maintenance releases 124
TMS backup 49
physical security 60
TMS physical interface
reinstalling 146
enabling promiscuous mode 86
syslog output 229
TMS port
SP appliance
enabling to use MPLS labels 210
configuring local BGP router ID 108
TMS restore from backup 49
securing 56
traceroute command
SP appliances
running 93
enabling NetFlow 271
traffic-triggered auto-mitigation settings
SSH
changing 202
configuring settings 66
Traffic Engineering tools
installing public keys 66
enabling 216
setting version 66
traffic mitigation
SSL Negotiation countermeasure
configuring Juniper routers 262
disabling whitelisting 204
FlowSpec routers 261
subscriber group 170
transit research reporting
support, contacting 11
enabling 216
syslog
transit traffic reporting
sending messages to a remote host 237, 239
enabling 216
system configuration
viewing current 19
typographic conventions
commands and expressions 10
procedures 9
U
upgrading
BI 124
CP 124
FS 124
PI 124
TMS 4000 135
TMS firmware manually 140
user account 180
user name
default 15
V
VLAN subinterface
removing from a TMS appliance 120
VLAN subinterfaces
adding on a TMS appliance 118
configuring on a TMS appliance 118
VPN site auto-detection
disabling and enabling 199
W
whitelisting
disabling for SSL Negotiation countermeasure 204
Whois resolution server
adding 30
X
XML menu schema 166
Z
Zero Touch Provisioning 39
ZTP 39