Arbor Networks Sightline 9.1.1 9.1 Release-Notes 2020-07-16

Sightline
Release Notes
Version 9.1.1
Version 9.1
Sightline Release Notes
Legal Notice
The information contained within this document is subject to change without notice. Arbor Networks, Inc.
makes no warranty of any kind with regard to this material, including, but not limited to, the implied
warranties of merchantability and fitness for a particular purpose. Arbor Networks, Inc. shall not be liable
for errors contained herein or for any direct or indirect, incidental, special, or consequential damages in
connection with the furnishings, performance, or use of this material.
© 2019-2020 Arbor Networks, Inc. All rights reserved. Proprietary and Confidential Information of Arbor
Networks, Inc.
Document Number: SP_ RN-911-2020/07

16 July 2020
2 Proprietary and Confidential Information of NETSCOUT Systems, Inc.

Contents
Revision History .......................................................................................................................................... 6

Introduction ................................................................................................................................................. 7
Sightline 9.1.1 Release Notes .................................................................................................................... 7
Sightline 9.1 Release Notes ....................................................................................................................... 7
New Features ......................................................................................................................................... 7
View multiple mitigation impacts from a single DoS Alert page ....................................................... 7
Inactive TMS mitigations .................................................................................................................. 8
Regular expression generation from packet capture (PCAP) files .................................................. 9
IPv6 support for flowspec mitigations .............................................................................................. 9
Webhook notifications for alerts and events .................................................................................... 9
More accurate traffic reports for customer managed objects outside the network boundary ........ 10
Automatically download managed objects that match OTT traffic in ATLAS ................................ 11
Configure user interface appliances for Cloud Signaling only ....................................................... 11
Flowspec support and Arista switches ........................................................................................... 11
Insight: New views added .............................................................................................................. 12
Insight: New facets added .............................................................................................................. 12
Enhancements ...................................................................................................................................... 14
Enhanced support for routers that are behind a proxy .................................................................. 14
Custom diversion prefixes for mitigations and mitigation templates .............................................. 14
Precise protection prefixes can be updated and applied to a running TMS auto-mitigation ......... 14
New “Apply to Graph” option on the Host Automatic Rate Calculation page ................................ 14
Improved accuracy and performance for flow matching in alert traffic .......................................... 15
Wizard reports with the Security Summary content type can be scoped ...................................... 15
FCAP expressions can be used to match traffic class of IPv6 traffic ............................................ 15
Traffic collection can be disabled for a managed object ................................................................ 15
Flow Specification Blacklist Offloading supports BGP communities ............................................. 15
Increase in number of concurrent TMS mitigations ....................................................................... 16
Increased maximum number of entries in IPv4 and IPv6 address filter lists ................................. 16
New filters added to the Explore Traffic page ................................................................................ 16
Inform-type messages now available for SNMP notifications ........................................................ 17
Mitigation Orchestration Event alert ............................................................................................... 17
Mitigation orchestration configuration options ............................................................................... 17
New “traffic marking” action added to manual flowspec mitigations .............................................. 18
Destination MAC Address and VLAN ID details added to the Alerts details page ........................ 18
Sightline ignores abnormally large and small packets for alerting purposes ................................. 18
Insight: Increased stability and performance ................................................................................. 19
Insight: Support for pasting multiple IP addresses in the value field ............................................. 19
Proprietary and Confidential Information of NETSCOUT Systems, Inc. 3

Insight: Support for excluding certain managed objects from Insight data .................................... 19
Changes in Behavior ............................................................................................................................ 20
Unsupported TMS devices removed from TMS and Sightline ....................................................... 20
Flood detection for TCP ACK and SYN/ACK now includes the TCP PUSH and URG flags ......... 20
New default port numbers used for RADIUS connections ............................................................. 21
New default action for flow specification mitigations ...................................................................... 21
New version of ArbOS required when running Sightline ................................................................ 21
Mitigation drop–down on alerts page no longer includes mitigation information ........................... 21
Trigger Rate selector removed from Alerts Traffic graph ............................................................... 21
Dropped Traffic graph replaces Dropped Traffic selector .............................................................. 21
Profiled Network graphs no longer show pre-alert traffic ............................................................... 21
TMS HD1000 Chassis–based Licenses ........................................................................................ 22
Updated MIB .................................................................................................................................. 22
Insight: “SP Matched Applications” facet was renamed ................................................................ 22
Insight: New default MTU setting in ArbOS ................................................................................... 22
Information about the REST API in Sightline ....................................................................................... 23
REST API enhancements .............................................................................................................. 23
REST API support added for all Sightline devices with the user interface role ............................. 23
Updated endpoints in the REST API .............................................................................................. 23
Upgrade Information for Insight ............................................................................................................ 26
New default MTU setting in ArbOS for Insight ............................................................................... 26
Using Insight in a Sightline deployment ......................................................................................... 26
Upgrade Information for Sightline ......................................................................................................... 26
Supported upgrade paths .............................................................................................................. 26
Multi-version compatibility .............................................................................................................. 26
Deployments that use flexible licensing require a new license file ................................................ 26
TMS HD1000 (4x100G + 8x10G) automatic configuration replaces user configuration ................ 27
TMS services must be stopped and started again if using GRE tunnels ....................................... 27
Upgrade process ............................................................................................................................ 28
Upgrading requires a current maintenance and support contract ................................................. 28
Device certificates .......................................................................................................................... 28
Support for DSA keys was deprecated .......................................................................................... 28
Support for TLS v1.1 was deprecated ........................................................................................... 28
Pre-upgrade raw flows are not viewable after upgrading to Sightline 9.1 ..................................... 28
System Requirements for Sightline ...................................................................................................... 29
Supported devices ......................................................................................................................... 29
Supported web browsers ............................................................................................................... 29
Router requirements ...................................................................................................................... 29
Communication ports ..................................................................................................................... 29

Fixed Issues in Sightline ....................................................................................................................... 32

Known Issues in Sightline ..................................................................................................................... 38
Other Things to Know about Sightline ................................................................................................... 39
Create a backup after converting to flexible licensing .......................................................................... 39
High CPU load averages ...................................................................................................................... 39
Dynamic subscriber interfaces ............................................................................................................. 39
Sightline interface handling ............................................................................................................ 39
Untracked interfaces ...................................................................................................................... 39
Additional Information .............................................................................................................................. 40
Downloading the software .................................................................................................................... 40
Contacting Arbor Technical Assistance Center .................................................................................... 40
Documentation...................................................................................................................................... 40
Appendix A: Changes to notifications in Sightline 9.1 ......................................................................... 41
SNMP notification example: dosHostDetectionAlert ...................................................................... 41
Appendix B: Verification of flowspec features of Arista switches ...................................................... 42
Hardware tested ................................................................................................................................... 42
Test 1: How quickly is traffic dropped when a flowspec mitigation starts?........................................... 42
Baseline ......................................................................................................................................... 42
Many existing flowspec announcements ....................................................................................... 44
Test 2: How accurate is the sFlow received from the Arista switch? ................................................... 45
Baseline ......................................................................................................................................... 45
More than 11,000 existing flowspec announcements .................................................................... 46
More than 24,000 existing flowspec announcements .................................................................... 47
Test 3: How fast are flowspec announcements ingested by the Arista switch? ................................... 48
Example 1 ...................................................................................................................................... 48
Example 2 ...................................................................................................................................... 48

Revision History
The following table lists the dates when these release notes were updated and a description of the
changes that were made:
Date Description of Changes
2020-07-21 • Added Sightline 9.1.1 release notes.
• Added “Sightline ignores abnormally large and small packets for alerting purposes” on page 18.
• Added “Updated MIB” on page 22.
• Added fixed issues for Sightline 9.1.1.
• Added Appendix A: Changes to notifications in Sightline 9.1 on page 41.
2019-11-15 • Added known issue 89099 and updated “Automatically download managed objects that match
OTT traffic in ATLAS” section with workaround.
• Added fixed issue 87185.
2019-08-13 • Updated the information about “Improved accuracy and performance for flow matching in alert
traffic” on page 15.
• Added fixed issue 83412.
2019-08-02 Updated the new feature description “IPv6 support for flowspec mitigations” on page 9 to include
information about IPv6 flowspec auto-mitigations.
2019-07-12 Initial release.

Introduction
This document includes release information about Sightline 9.1.x. For release information about Threat
Mitigation System (TMS) 9.1.x, see the separate Threat Mitigation System Release Notes.
Sightline 9.1 is scheduled for General Availability on July 16, 2019, and will reach End of Maintenance on
July 16, 2021.
Note: Beginning with 9.0, the SP product has been renamed “Sightline”.
Sightline 9.1.1 Release Notes

Sightline 9.1.1 is a maintenance release that provides critical software fixes for Sightline 9.1. For details
about fixed and known issues, see Fixed Issues in Sightline on page 32 and Known Issues in Sightline on
page 38.
Sightline 9.1 Release Notes
New Features
View multiple mitigation impacts from a single DoS Alert page

The DoS Alert page in Sightline 9.1 gives you more informative and efficient ways to view how flowspec,
blackhole, and TMS mitigations are impacting the traffic for an alert. You can now view statistics, graphs,
and data for traffic dropped by mitigations that affect an alert—all in one place.
Mitigations table for DoS alerts

A new Mitigations table on the Summary tab of a DoS alert page contains the following information for
each flowspec, blackhole, and TMS mitigation affecting traffic for that alert:
• The mitigation start date/time and duration.
• The average and maximum amounts of traffic dropped by the mitigation.
• (TMS mitigations only) The average and maximum amounts of traffic passed by the mitigation.
New dropped traffic graphs and more flowspec impact details for DoS alerts
If your deployment has the Smart Mitigation licensed capability, the alert pages for DoS alerts affected by
flowspec or blackhole mitigations include the following new information:
• On the Summary tab, Dropped Traffic graphs show the alert traffic dropped by the mitigations that
affected the DoS alert. The Dropped Traffic graphs only appear when mitigations influence an alert's
traffic. If the alert has flowspec mitigations impacting its traffic, you can use tabs on the Dropped
Traffic graph to select the following views:
▪ All Mitigation Types displays the alert traffic along with the traffic dropped by the mitigations
affecting the alert. The graph includes alert traffic not dropped, the alert traffic dropped by each
type of mitigation affecting the alert, and the total alert traffic.
Note: On the All Mitigation Types graph, the amount of dropped Flowspec traffic shown can
exceed the All Alert Traffic line. This is because Sightline assumes any dropped flowspec traffic
is dropped at the network boundary by Sightline flowspec mitigations. However, Sightline can
also see traffic being dropped by flowspecs running on routers outside the network boundary.
When this happens, Sightline might report more dropped Flowspec traffic than amount of traffic
that matches the alert.
▪ Flowspecs displays a graph of the alert traffic dropped by each flowspec mitigation impacting the
alert.

• On the Traffic Details tab, the Flowspec Mitigations section appears if you select the Router view
and flowspec mitigations are impacting the alert.
• The new Flowspec Details tab gives you several options for viewing information about traffic
dropped by flowspec mitigations affecting the alert. For example, you can:
▪ Change the timeframe and units for all dropped traffic graphs and statistics on the tab.
▪ Display the dropped traffic graph for individual flowspec mitigation filters by clicking the statistics
table for that filter, or by clicking View Graph below the table.
▪ Download all source IP addresses in traffic dropped by flowspec mitigations affecting the alert.
• The new Flowspec Routers tab displays a graph of traffic dropped by flowspec mitigations impacting
an alert for selected routers. You can display the dropped traffic for up to 10 routers. The table below
the graph lists the routers and their interfaces that are associated with the dropped traffic.
For more information about these features

See the following topics in the Sightline and Threat Mitigation System User Guide:
• About the Summary Tab on a DoS Alert Page
• About the Traffic Details Tab on a DoS Alert Page
• About the Flowspec Details Tab on a DoS Alert Page
• About the Flowspec Routers Tab on a DoS Alert Page
Inactive TMS mitigations

TMS mitigations can now execute in an inactive mode. Inactive mitigations function the same as active
mitigations, except they do not drop attack traffic. You can use inactive mitigations to preview the impact
of applying countermeasures to attack traffic.
Mitigation and countermeasure statistics and graphs are updated as inactive mitigations execute. You
can use these tools to visualize the impact of countermeasures.
All enabled countermeasures perform normally, with the following exceptions:
• the TCP SYN Authentication countermeasure is not executed
• the DNS Authentication countermeasure is not executed
The following countermeasures are executed but do not reset connections:
• TCP Connection Reset
• TCP Connection Limiting
Blacklist offloading is not supported in inactive mitigations. This results in higher dropped traffic statistics
in inactive mitigations that blacklist than in active mitigations that blacklist with blacklist offloading.
Note: Inactive mitigations are included in the count of ongoing TMS mitigations for each TMS device they
run on. See the Sightline and Threat Mitigation System Deployment and Appliance Limits document for
the maximum number of ongoing TMS mitigations permitted for each TMS device.
See “About TMS Mitigations” in the Sightline and Threat Mitigation System User Guide for additional
information on inactive mitigations.

Regular expression generation from packet capture (PCAP) files

You can now use the Sightline CLI to generate regular expressions for up to five top traffic patterns in a
PCAP file. If the PCAP file contains attack traffic, the regular expressions can then be used in the
Payload Regular Expression countermeasure to mitigate the attack.
See “Generating Regular Expressions from Packet Capture Files” in the Sightline and Threat Mitigation
System Advanced Configuration Guide for instructions on generating the regular expressions.
See “Configuring the Payload Regular Expression Countermeasure” in the Sightline and Threat Mitigation
System User Guide for instructions on using the Payload Regular Expression countermeasure.
IPv6 support for flowspec mitigations

Sightline can now advertise flowspec mitigations to flowspec-enabled IPv6 routers. The new IPv6 support
includes both user-initiated flowspec mitigations and flowspec auto-mitigations. For example, alerts for
customer managed objects with Match settings for IPv6 traffic can now trigger flowspec auto-mitigations
on IPv6 routers in your deployment.
In addition, if you have the new Smart Mitigation licensed capability, you can monitor the impacts of all
IPv4 and IPv6 flowspec mitigations on DoS alert traffic in real time. See “New dropped traffic graphs and
more flowspec impact details for DoS alerts” on page 7.
You configure IPv6 flowspec mitigations the same way you configure IPv4 flowspec mitigations with the
following exceptions:
• In the Announcement settings for an IPv6 flowspec mitigation, you select BGP-peered IPv6 routers.
• The IPv6 routers that you select must have the BGP capabilities Announce IPv6 Mitigation Routes
and IPv6 Flow Specification enabled in their router configuration settings (Administration >
Monitoring > Routers > Add/Edit Router > BGP).
• For user-initiated IPv6 flowspec mitigations, the Destination Prefix and Source Prefix settings in the
flowspec filter must be IPv6 prefixes.
• For flowspec auto-mitigations that are configured to use IPv6 routers, the Source Prefix – IPv6 in the
filter settings for each enabled Misuse Type filter must be an IPv6 prefix (if configured).
Note: For each enabled Misuse Type filter, Sightline automatically adds 20 bytes to the configured
Packet Length value when matching IPv6 traffic.
For more information about configuring IPv6 flowspec mitigations, see the following topics in the Sightline
and Threat Mitigation System User Guide:
• For user-initiated IPv6 flowspec mitigations, see “Mitigating Using Flow Specification ACLs.”
• For IPv6 flowspec auto-mitigations, see “Configuring Mitigation Settings for Customer Managed
Objects” and “Configuring Flow Specification Auto-Mitigation Settings.”
Webhook notifications for alerts and events

In addition to sending notifications as email, SNMP, and remote syslog messages, Sightline 9.1 can also
send notifications as webhooks. A webhook is a JSON document in an HTTP POST request. Sightline
can POST webhook notifications to a destination HTTP server’s URI. Third-party web applications
running on the destination HTTP server can use the Sightline notification data in the webhook POSTs.
In the Sightline 9.1 web UI, you specify the HTTP server’s URI for webhook notifications in the Webhook
settings for a notification group. These settings are on the Add/Edit Notification Group page
(Administration > Notification > Groups). If the destination HTTP server only accepts POSTs from
authenticated sources, you can specify the authentication method, basic or digest, as well as the login
credentials, in the Webhook settings.

Multiple notification groups can use the same webhook URI. Each alert or event notification generates a
unique POST for every configured notification group. The data sent in a webhook POST for an alert
notification is the same as the data you receive from the REST API when you GET that alert ID from the
/alerts/ endpoint.
If you want to send a test webhook notification to the HTTP server URI configured in the default
notification group default, or in a specific notification group group_name, use the following CLI
command: / services sp notification test webhooks {default | group_name}
If a webhook notification fails, Sightline continues to retry the POST indefinitely every 24 hours (86400
seconds) by default. You can change the maximum number of retries and the retry timeout as follows:
• If you want to change the maximum number of retries for webhooks, max_retries, enter the
following CLI commands:
/ services sp notification webhooks retry_count_limit enable
/ services sp notification webhooks retry_count_max max_retries
For unlimited retries, enter:
/ services sp notification webhooks retry_count_max set default
• If you want to change the maximum amount of time (in seconds) that Sightline continues to retry
POSTing a failed webhook notification, max_seconds, enter the following CLI commands:
/ services sp notification webhooks retry_seconds_limit enable
/ services sp notification webhooks retry_seconds_max max_seconds
For more information, see “Configuring Notification Groups” in the Sightline and Threat Mitigation System
User Guide.
Note: You can also configure webhooks in the /notification_groups/ endpoint for the Sightline V.6
REST API. For more information, see “/notification_groups/” on page 25.
More accurate traffic reports for customer managed objects outside the network boundary
Previously, Sightline would report double the amount of traffic to customer managed objects if their
managed object boundary was outside the network boundary. This is because traffic to the customer
managed object had to enter and exit the network boundary before entering the external managed object
boundary. This is normal for peer managed objects which are, by definition, outside the network
boundary. However, customer managed objects are typically inside the network boundary.
To prevent the double-counting traffic for external customer managed objects, Sightline 9.1 includes the
new CLI command: / services sp managed_objects edit managed_object_name
treat_external_as_internal
When you run this command for an external customer managed object, managed_object_name,
Sightline 9.1 treats the network boundary and the boundary for the external customer as if they were the
same for traffic counting and reporting. However, for alerting, Sightline 9.1 continues to treat these two
boundaries separately.

Automatically download managed objects that match OTT traffic in ATLAS
Note: Critical bug 89099 has been identified in Sightline 9.1.0.

This bug specifically impacts those using local flexible licensing with the new AIF for Sightline feature.
For AIF to work properly on these deployments, you must apply the sp-patch-89099-9.1-ui-JKNF
handpatch to your Sightline UI appliances. You can download the patch from the following Sightline
9.1.0 folder on the Arbor Software Download Site:
https://arbornetworks.flexnetoperations.com/control/arbr/download?element=11163667
If you have questions or require any assistance installing this patch, please contact the Arbor Technical
Assistance Center (ATAC) at https://support.arbornetworks.com/.
Sightline 9.1 includes a new ATLAS Intelligence Feed (AIF): the “AIF managed object feed”. This feed
automatically downloads preconfigured profile managed objects called “AIF managed objects”. The match
settings in AIF managed objects are the CIDR blocks used by providers of high-volume over-the-top
(OTT) services such as video streaming, gaming, and VOIP.
ASERT configures the match settings for AIF managed objects based on ATLAS traffic data for OTT
services. When ASERT changes the match settings or makes new AIF managed objects available, your
deployment automatically receives the latest AIF managed object configurations at the next update.
If your deployment has the new AIF for Sightline flexible-licensed capability, Sightline automatically
checks the AIF server every day for changes to the AIF managed object feed. If the feed content
changed, Sightline downloads all AIF managed objects in the feed.
For more information, see “About ATLAS Services” and “About the AIF Managed Object Feed for
Sightline” in the Sightline and Threat Mitigation System User Guide.
Configure user interface appliances for Cloud Signaling only

In Sightline 9.1, you can now limit any non-leader user interface appliance to performing the single task of
forwarding Cloud Signaling mitigation requests from AED or APS devices. Enabling Cloud Signaling Only
on a user interface appliance prevents access to the Sightline user interface and API through that
appliance. This allows you to extend mitigation services for AED and APS devices while maintaining the
security of your Sightline deployment.
Before you deploy user interface appliances for Cloud Signaling only:
• Configure Cloud Signaling on the AED or APS devices.
• Assign each AED or APS device to a Sightline manager appliance.
• Associate each AED or APS device with a managed object.
You can enable Cloud Signaling Only for a non-leader user interface appliance on the Add/Edit
Appliance page (Administration > Appliances > Add/Edit Appliance). For more information, see
“Configuring Appliance Settings for a Sightline Appliance” in the Sightline and Threat Mitigation System
User Guide.
Flowspec support and Arista switches

Arbor has tested and verified that flowspec features of Arista switches are compatible with Sightline. For
details, see Appendix B: Verification of flowspec features of Arista switches on page 42.

Insight: New views added

The following views are now available on the Insight page (Explore > Insight):
• Customer Tag
Displays traffic that crosses a customer-type managed object's boundary, matches the managed
object's match value, and matches a tag assigned to the managed object.
• Peer Tag
Displays traffic that crosses a peer-type managed object's boundary, matches the managed object's
match value, and matches a tag assigned to the managed object.
• Profile Tag
Displays traffic that crosses a profile-type managed object's boundary, matches the managed object's
match value, and matches a tag assigned to the managed object.
Insight: New facets added

The following facets are now available on the Insight page (Explore > Insight):
• Customer Tag
Displays traffic that matches tags assigned to customer-type managed objects.
• Peer Tag
Displays traffic that matches tags assigned to peer-type managed objects.
• Profile Tag
Displays traffic that matches tags assigned to profile-type managed objects.
• IPv4 Address
Displays traffic per IPv4 address, regardless of whether the address is the source or destination of
the flow record.
• IPv6 Address
Displays traffic per IPv6 address, regardless of whether the address is the source or destination of
the flow record.
• Remote Community
Displays traffic per remote BGP community. A remote community is any community associated with
the source or destination of the flow record. For traffic entering the View boundary, the remote
community is any community associated with the source of the flow record. For traffic exiting the
View boundary, the remote community is any community associated with the destination of the flow
record.
• Remote IPv4 Nexthop
Displays traffic per remote IPv4 nexthop. A remote IPv4 nexthop is an IPv4 nexthop associated with
the source or destination of the flow record. For traffic entering the View boundary, the remote
nexthop is the nexthop associated with the source of the flow record. For traffic exiting the View
boundary, the remote nexthop is the nexthop associated with the destination of the flow record.
• Remote Origin ASN
Displays traffic per remote origin ASN. A remote origin ASN is an origin ASN associated with the
source or destination of the flow record. For traffic entering the View boundary, the remote origin ASN
is the origin ASN associated with the source of the flow record. For traffic exiting the View boundary,
the remote origin ASN is the origin ASN associated with the destination of the flow record.
• Remote Peer ASN
Displays traffic per remote peer ASN. A remote peer ASN is a peer ASN associated with the source
or destination of the flow record. For traffic entering the View boundary, the remote peer ASN is the

peer ASN associated with the destination of the flow record. For traffic exiting the View boundary, the
remote peer ASN is the peer ASN associated with the source of the flow record.

Enhancements
Enhanced support for routers that are behind a proxy

Sightline can receive flow from a proxy and associate the received flow with a router that is behind the
proxy. (Previously, Sightline associated the received flow with the proxy.) For more information, see
“Configuring Proxies for Routers” in the Sightline and Threat Mitigation System Advanced Configuration
Guide.
Custom diversion prefixes for mitigations and mitigation templates

In TMS mitigations and mitigation templates, the new Custom option for the Diversion Prefixes setting
allows routers to divert traffic that was sent to any prefixes you specify. Unlike the Default and Less
Specific options for Diversion Prefixes, custom diversion prefixes need not match or include any
prefixes that the mitigation protects (but they can).
To configure custom diversion prefixes in a TMS mitigation or template:
1. On the Add/Edit page for the TMS mitigation or template, select the Protect tab.
2. For Diversion Prefixes, select the Custom option.
3. Enter the list of custom prefixes to divert to the TMS in CIDR notation. Match the prefix format to the
IP version for the mitigation (IPv4 or IPv6).
4. (Optional for templates only) Select or clear the Lock check box for the Diversion Prefixes setting.
5. Save and commit.
For more information, see “Configuring Protect Settings for TMS Mitigations and Templates” in the
Sightline and Threat Mitigation System User Guide.
Precise protection prefixes can be updated and applied to a running TMS auto-mitigation
The prefixes identified as precise protection prefixes can now change over time as traffic changes. If the
prefixes that Sightline has identified change significantly over time, Sightline can now reuse existing TMS
auto-mitigations by updating the prefixes that are protected. Note that although this capability involves the
reuse of auto-mitigations for profiled router alerts, it does not require that the Reuse TMS Auto-
Mitigations for Multiple Alerts setting be enabled.
You can configure precise protection prefixes on the Mitigation tab when editing a customer-type
managed object displayed on the Configure Managed Objects page (Administration > Monitoring >
Managed Objects).
Note: The precise protection prefixes identifies only prefixes that are the destination of inbound traffic that
crosses the managed object’s boundary. Although it relies on profiled router detection, it will not identify
prefixes when traffic crosses the router boundary only.
For more information, see “Configuring Mitigation Settings for Customer Managed Objects” in the
Sightline and Threat Mitigation System User Guide.
New “Apply to Graph” option on the Host Automatic Rate Calculation page
When displaying results on the Host Automatic Rate Calculation page (Administration > Detection >
Host Automatic Rate Calculation), you can now view the Current Thresholds and Suggested
Thresholds easily by clicking Apply to Graph under the desired set of thresholds.
For more information, see “About Host Automatic Rate Calculation” in the Sightline and Threat Mitigation
System User Guide.

Improved accuracy and performance for flow matching in alert traffic

Sightline 9.1 includes accuracy and performance improvements when matching flows in alert traffic.
On the Summary tab of a DoS Alert page, traffic spikes are properly displayed in the Alert Traffic graph
when adjusting the period of the displayed traffic. Previously, in some cases, traffic spikes would not be
displayed depending on the displayed period.
Wizard reports with the Security Summary content type can be scoped
When configuring the Security Summary content of a wizard report, you can now select which managed
objects are included in the report. If you specify no managed objects, the report contains information for
the entire deployment.
You can configure the Security Summary content when editing a wizard report displayed on the Configure
Reports page (Administration > Reports).
For more information, see “Configuring Wizard Reports” in the Sightline and Threat Mitigation System
User Guide.
FCAP expressions can be used to match traffic class of IPv6 traffic

You can now use FCAP expressions to configure the TMS to match IPv6 traffic based on the traffic class
associated with the traffic. For details, see "Description of FCAP Expression Language" in the Sightline
and TMS User Guide.
Traffic collection can be disabled for a managed object

You can now disable traffic collection for any individual managed object. To disable traffic collection for a
managed object, navigate to the Description tab of the desired managed object, and set Traffic
Collection to Disabled.
Important: If flow is not collected for a managed object, Sightline will not detect attacks and trigger alerts
for the managed object. In addition, traffic reports for the managed object will show no traffic for the
period during which no flow was collected.
DNS scoping and HTTP scoping are available for TMS mitigation templates
You can now set DNS scoping and HTTP scoping settings for TMS mitigation templates. Previously,
these settings were available only for individual TMS mitigations.
This enhancement was made in response to bug 53146.
Flow Specification Blacklist Offloading supports BGP communities

Flow specification blacklist offloading routes can now be announced with BGP communities.
You can configure BGP communities for flow specification blacklist offloading on the Blacklist Offloading
tab when you add or edit a TMS device (Administration > Appliances).
For more information on flow specification blacklist offloading, see “About Blacklist Offloading for TMS
Models” and “Configuring Flow Specification Blacklist Offloading for a TMS Model” in the Sightline and
Threat Mitigation System User Guide.

Increase in number of concurrent TMS mitigations

The maximum number of mitigations that can run concurrently has been increased for the following TMS
appliances:
Appliance Maximum number of mitigations
TMS 2600 250
TMS 2800 250
TMS 5000* 250
TMS HD1000 (16x10G) 300
TMS HD1000 (4x100G + 8x10G) 300
*The following log messages may occur when running more than 100 mitigations on a TMS-5000. These
are harmless and should be ignored:
• blinky[#]: [S] #MODULE-SKIP check-hwdevice (already running)
• blinky[#]: [W] #BLINKY apm-X-ipmc -4 seconds out of sync
• SA_ERR_HPI_NO_RESPONSE
For additional information, see “Configuring Advanced Settings for a TMS Model” in the Sightline and
Threat Mitigation System User Guide.
Increased maximum number of entries in IPv4 and IPv6 address filter lists
The maximum number of entries that can be in an IPv4 or IPv6 address filter list has been increased. The
limit is now enforced per TMS device rather than per TMS mitigation.
All TMS devices now support the following:
• a maximum of 2,000,000 IPv4 filter list entries
• a maximum of 1,272,800 IPv6 filter list entries
See the following for additional information:
• Sightline and Threat Mitigation System Deployment and Appliance Limits
• “About Filter Lists for TMS Mitigations and Templates” in the Sightline and Threat Mitigation System
User Guide
• “About IPv4 and IPv6 Address Filter List Sizes” in the Sightline and Threat Mitigation System User
Guide
New filters added to the Explore Traffic page

The following filters were added to the Explore Traffic page (Explore > Traffic):
• r_as: Shows traffic by remote AS.
• r_as_origin: Shows traffic by remote AS origin.
• r_as_peer: Shows traffic by remote AS peer.
• r_community: Shows traffic by remote BGP community.
• r_nexthop: Shows traffic by remote nexthop.

Inform-type messages now available for SNMP notifications

When using SNMP version 2c or 3 to send notifications, you can now select Inform as the message type
using the new Message Type option. Previously, only Trap-type messages were supported. This setting
is available when editing a notification group listed on the Notification Group page (Administration >
Notification > Groups).
Mitigation Orchestration Event alert

A new Mitigation Orchestration Event alert is generated when mitigation orchestration does either of the
following:
• moves a mitigation off an overloaded TMS group
• returns a mitigation to its original TMS group
A notification for the alert is sent to the default notification group (if configured). If a default notification
group is not configured, the notification is sent to the email address configured in the SMTP server
settings.
For more information on mitigation orchestration, alerts, and notifications, see the follow topics in the
Sightline and Threat Mitigation System User Guide:
• “About TMS Mitigation Orchestration”
• “About Alert Classes and Alert Types”
• “About Notifications”
Mitigation orchestration configuration options

Three new global configuration options give you additional control over the movement of mitigations by
mitigation orchestration.
To configure the options, navigate to the Configure Global TMS Mitigation Settings page (Administration
> Mitigation > Global Settings). The options apply to all TMS groups that have mitigation orchestration
enabled.
For additional information on mitigation orchestration and global TMS settings, see the following topics in
the Sightline and Threat Mitigation System User Guide:
• “About TMS Mitigation Orchestration”
• “Configuring Global TMS Mitigation Settings”
Minimum Over Bandwidth Duration

You can use the Minimum Over Bandwidth Duration setting (default 20 seconds) to control the
minimum amount of time a TMS must be over the bandwidth threshold of its TMS group before mitigation
orchestration attempts to move mitigations off of it. Mitigation orchestration does not move mitigations
until the TMS has been over the bandwidth threshold for this length of time.

Mitigation Movement Pause Duration

You can use the Mitigation Movement Pause Duration setting (default 5 minutes) to control how long
mitigation orchestration pauses after mitigations are moved or new mitigations are started. Mitigation
orchestration does not move mitigations on the affected TMS groups until the pause duration has
elapsed.
The mitigation movement pause provides time for the following:
• BGP announcements to be withdrawn and re–announced for moved mitigations
• new mitigations to begin mitigating attack traffic without mitigation orchestration moving them
Mitigation Return Interval

You can use the Mitigation Return Interval setting (default 6 hours) to control how frequently mitigation
orchestration attempts to return moved mitigations to their original TMS groups. Mitigations are only
returned if their original TMS group has enough capacity to accommodate them. If the original TMS group
does not have enough capacity, mitigation orchestration tries to move the mitigation again after the next
mitigation return interval elapses.
You can disable this option if you do not want mitigations returned to their original TMS group.
New “traffic marking” action added to manual flowspec mitigations

A traffic marking action was added to manual flowspec mitigations. This action allows you to use a
manually-created flowspec mitigation to mark traffic that matches the mitigation’s filter with a DCSP value.
This setting is available when editing a flowspec mitigation listed on the Flow Specifications page
(Mitigation > Flow Specification).
Destination MAC Address and VLAN ID details added to the Alerts details page
When displaying the details of a host alert, Sightline can now display the MAC address of the destination
host and the corresponding VLAN ID. Sightline can display this information only if the router sends the
information to Sightline.
Sightline ignores abnormally large and small packets for alerting purposes
To prevent alerts from being generated for traffic with bad flow records, Sightline ignores traffic with
packets that are abnormally large (more than 100,000 bpp) and small (less than 1 bpp) for the purposes
of alerting.

Insight: Increased stability and performance

Numerous improvements have been made to the Insight software that result in increased stability and
performance.
Insight: Support for pasting multiple IP addresses in the value field

When using the Insight page (Explore > Insight) to filter a facet that is expressed by IP addresses, such
as Destination IPv4 Address or IPv6 External Top Talker, you can specify IP addresses or CIDR
blocks. When specifying individual IP addresses, you can paste a comma-separated, line-separated, or
space-separated list of addresses. Arbor has verified this functionality when pasting up to 300 addresses.
Note: Pasting line-separated lists is not supported in Internet Explorer 11.
Insight: Support for excluding certain managed objects from Insight data
You can specify certain managed objects to not be included in Insight data. This prevents the specified
managed objects from being subject to or appearing in Insight queries. This enhancement is available
only by using the REST API. See the information about the managed_objects endpoint on page 24.
Note: This feature does not affect data already stored in your Insight cluster; it only affects flow ingested
by Insight after the feature is enabled. Any flow stored by Insight before using this feature will continue to
be associated with the managed object in Insight.

Changes in Behavior
Unsupported TMS devices removed from TMS and Sightline

The following unsupported TMS devices have been removed from Sightline and TMS:
• TMS–CGSE
• TMS–ISA
• TMS–ISA clusters
• TMS–CGSE clusters
The following Sightline API endpoints have been changed due to the removal of TMS clusters:
Endpoint Change
/tms_groups/ The members_cluster attribute has been removed.
/tms_groups/ The type attribute no longer returns the value cluster
/devices/ The deployment_type attribute no longer returns the value clusterable
In the Sightline UI, the following items have been removed:

• the Administration > Mitigation > TMS-CGSE Clusters menu item
• the Administration > Mitigation > TMS-ISA Clusters menu item
• the Type drop-down on the Description tab of the Add TMS Group page
• the TMS Clusters tab of the Add/Edit TMS Group page
If your deployment contained any of the removed TMS devices, they will now appear as TMS 1200s on
the System > Status > Appliance Status and System > Status > Appliance Monitoring pages.
If your deployment had a TMS group that was a Cluster type, it will now appear as a group with no
members in it.
Flood detection for TCP ACK and SYN/ACK now includes the TCP PUSH and URG flags
The host detection misuse types TCP ACK and TCP SYN/ACK Amplification now match flows in attack
traffic that contain the TCP flags PUSH and URG (urgent pointer). This allows Sightline 9.1 to alert on
new, increasingly frequent variants of ACK and SYN/ACK flood attacks that include the PUSH and URG
flags.
The table below shows the TCP flags matched:
TCP Flags matched in TCP flood traffic flows
Host Detection Misuse Type Sightline 9.0.1 and lower Sightline 9.1
TCP ACK • ACK • ACK
• ACK + PUSH • ACK + PUSH
• ACK + URG
• ACK + PUSH + URG
TCP SYN/ACK Amplification • SYN + ACK • SYN + ACK
• SYN + ACK + PUSH
• SYN + ACK + URG
• SYN + ACK + PUSH + URG

New default port numbers used for RADIUS connections

The default port numbers used for RADIUS connections were changed to match the registered port
numbers assigned by the Internet Assigned Numbers Authority (IANA). The default port number for
accounting was changed from 1646 to 1813, and the default port number for authentication was changed
from 1645 to 1812.
If you configured RADIUS using the Sightline CLI and did not specify port numbers for accounting or
authentication, the port numbers used by Sightline will change as described above when you upgrade to
Sightline 9.1.
This change does not affect your deployment if:
• You used the Sightline CLI to configure RADIUS settings and you specified the port numbers.
• You configured RADIUS using the Sightline web UI.
New default action for flow specification mitigations

The default action when using the Sightline web UI to create a flow specification mitigation is now
discard. In previous versions of Sightline, the default action was accept.
New version of ArbOS required when running Sightline

ArbOS 7.0 is required when running Sightline 9.1.
Mitigation drop–down on alerts page no longer includes mitigation information

On the DoS alert page, the Mitigate Alert drop–down no longer includes the number of mitigations
applied to each alert. The number of mitigations, along with the traffic dropped by them, is now included
in the new Mitigations table and Dropped Traffic graphs on the alert page.
Trigger Rate selector removed from Alerts Traffic graph

On the Summary tab of a DoS Alert page, in the Alert Traffic graph, the <Misuse Type> Trigger Rate
selector that showed the threshold for a single misuse type no longer appears. Previously, when you
selected Router from the View list, this selector would appear when the alert traffic for a single misuse
type was displayed.
Dropped Traffic graph replaces Dropped Traffic selector

On the Summary tab of a DoS Alert page, in the Alert Traffic graph, the Dropped Traffic selector no
longer appears. Rather, dropped alert traffic now appears in a new, separate Dropped Traffic graph on
the Summary tab.
Profiled Network graphs no longer show pre-alert traffic

On the Summary tab of a DoS Profiled Network Alert page, the Alert Traffic graph no longer shows pre-
alert traffic.

TMS HD1000 Chassis–based Licenses

Appliance licenses for new TMS HD1000 appliances are now based on the appliance’s chassis serial
number. Licenses were previously based on the serial number of the Management Module (MM). Using
the chassis serial number for the license permits MM’s to be replaced without licensing complications.
The chassis and the MM serial numbers are now both displayed in the Sightline UI on the following
pages:
• Appliance Status (System > Status > Appliance Status)
• System Details (System > Status > Appliance Monitoring > View Appliance Details)
Important: Upgrading a TMS HD1000 to TMS 9.1.0 does not change the serial number used for licenses.
Existing customers can upgrade to TMS 9.1.0 with no impact on their licenses. Licenses based on MM
serial numbers continue to be supported.
Contact the Arbor Technical Assistance Center (https://support.arbornetworks.com) for assistance with
licensing issues.
Updated MIB
SNMP traps now report correct information when the maximum impact of the alert traffic is 4.3 Gbps or
more. To implement this change, download the updated Sightline MIB. For details about the updated MIB,
see Appendix A: Changes to notifications in Sightline 9.1 on page 41.
You can download the updated MIB on the SNMP tab of the Configure Network Services page
(Administration > System Maintenance > Network Services).
This change was made in response to bug 86101.
Insight: “SP Matched Applications” facet was renamed

The name of the “SP Matched Applications” facet was changed to “Applications”. After upgrading to
Sightline 9.1 and Insight 7, you must replace the “SP Matched Applications” facet with the “Applications”
facet in any saved Insight queries that include “SP Matched Applications”.
To replace the “SP Matched Applications” facet with “Applications” in a saved query:
1. Navigate to the Insight page (Explore > Insight) and click the Saved Queries tab.
2. Click Update next to the desired saved query to load the query into the control bar.
3. In the Filter box, note any values specified for the “SP Matched Applications” facet and then delete
the facet.
4. Add the “Applications” facet to the Filter box and specify values as needed.
5. Click Update in the control bar.
6. Click to save the content of the control bar as a saved query.
7. Click the Saved Queries tab and then click Delete next to the old saved query that contains the “SP
Matched Applications” facet.
Insight: New default MTU setting in ArbOS

When using Arbor hardware to run Insight, we now recommend that the network used for intra-cluster
communication supports an MTU (maximum transmission unit) of 9000. As a result of this
recommendation, the default MTU setting for 10 GbE interfaces (eth2 to eth5, which are typically used for
intra-cluster communication) was changed to 9000 beginning with the version of ArbOS that was released
with Insight 7.

Information about the REST API in Sightline
REST API enhancements

The Sightline REST API was upgraded to version 6 in Sightline 9.1.
For descriptions of breaking changes from version 5 to version 6, see Administration > REST API
Documentation > Breaking Changes > V.6 Breaking Changes in the Sightline web UI.
REST API support added for all Sightline devices with the user interface role
Previously, the REST API was only supported for Sightline leaders. Arbor now supports REST API
requests to any Sightline device with the user interface role.
Updated endpoints in the REST API

The following endpoints were updated in the Sightline REST API in version 6:
/alerts/
• The REST API can now return the MAC address of the destination host and the corresponding VLAN
ID of DoS host alert traffic. This information is returned as values for the destination_mac_address
and the dot1q_vlan_id attributes of an alert. These are the REST API equivalents of the new Dest
MAC Address and VLAN ID details that appear on the alert details page. See "Destination MAC
Address and VLAN ID details added to the Alerts details page 18.
• You can now use the alerts endpoint to view traffic dropped by flowspec and blackhole mitigations.
Set the query_view attribute to flowspec or blackhole to return traffic dropped by flowspec of
blackhole mitigations, respectively. This is the REST API equivalent of the capabilities added to the
DoS Alert details page in the Sightline web UI. See "View multiple mitigation impacts from a single
DoS Alert page" on page 7.
/devices/
The cloud_signaling_only attribute was added. When this attribute is set to true, the corresponding
user interface device can only receive and forward Cloud Signaling mitigation requests from AED or APS
devices. No other UI appliance functions are available. This is the REST API equivalent of the new Cloud
Signaling Only setting available for non-leader user interface appliances on the Add/Edit Appliance page
(Administration > Appliances > Add/Edit Appliance). See “Configure user interface appliances for
Cloud Signaling only” on page 11.
/insight/
• The following facets were added: Customer_Tag, Peer_Tag, Profile_Tag, IPv4_Address,
IPv6_Address, Remote_AS, Remote_Community, Remote_IPv4_BGP_Nexthop, Remote_Origin_ASN,
Remote_Peer_ASN. These are the REST API equivalents of the new facets added to the Insight page
(Explore > Traffic) in the Sightline web UI. See Insight: New facets added on page 12.
• The following views were added: Customer_Tag, Peer_Tag, Profile_Tag. These are the REST API
equivalents of the new views added to the Insight page (Explore > Traffic) in the Sightline web UI.
See Insight: New views added on page 12.
• The name of the SP_Matched_Applications facet was changed to Applications. This is the REST
API equivalent of the change that was made to the Insight page (Explore > Traffic) in the Sightline
web UI. See Insight: “SP Matched Applications” facet was renamed on page 22.
• Existing crumbs that use the SP Matched Applications facet no longer work. You can use the
/insight/crumbs endpoint to PATCH these crumbs and replace SP_Matched_Applications with
Applications.

/managed_objects/
• The atlas_feed_id attribute was added.
• The scrub_insight_mo_match attribute was added. It allows you to specify certain managed objects
to not be included in Insight data. This prevents the specified managed objects from being subject to
or appearing in Insight queries.
Note: This feature does not affect data already stored in your Insight cluster; it only affects flow
ingested by Insight after the feature is enabled. Any flow stored by Insight before using this feature
will continue to be associated with the managed object in Insight.
• The match_enabled attribute was added. When this attribute is set to true, Sightline will record flow
for the corresponding managed object. Sightline will not record flow for the managed object if you set
this attribute to false. This is the REST API equivalent of the new Traffic Collection setting added
to the Edit Managed Object page in the Sightline web UI. See “Traffic collection can be disabled for a
managed object” on page 15.
/mitigations/
• The ip_version attribute is now available for flowspec mitigations.
• The type sub-attribute of the action attribute now accepts traffic-marking as its value. When you
set type to traffic-marking, you must also specify a value for the dscp sub-attribute. These
changes allow you to use a flowspec mitigation to mark traffic that matches the mitigation’s filter with
a DCSP value. This is the REST API equivalent of the new traffic marking action available when
editing a flowspec mitigation listed on the Flow Specifications page (Mitigation > Flow
Specification). See New “traffic marking” action added to manual flowspec mitigations on page 18.
• The diversion_prefix_enabled attribute was removed and replaced with the
diversion_prefix_mode attribute. The diversion_prefix_mode attribute can be set to one of the
following values:
▪ custom: Allows you to use the diversion_prefixes attribute to specify the address ranges to
be diverted to the TMS.
▪ default: Allows you to divert the same prefixes to the TMS as the prefixes that the mitigation
protects.
▪ mask_length: Allows you to use the diversion_prefix_max_mask_len attribute to specify the
length of the less specific mask to be used for routing announcements.
This is the REST API equivalent of the new custom diversion prefixes feature. See “Custom diversion
prefixes for mitigations and mitigation templates” on page 14.
/mitigation_templates/
The dns_scoping and http_scoping attributes were added for TMS mitigation templates. Previously,
these attributes were available only for individual TMS mitigations. This is the REST API equivalent of the
new DNS scoping and HTTP scoping settings added to the Edit Mitigation Template page in the
Sightline web UI. See “DNS scoping and HTTP scoping are available for TMS mitigation templates” on
page 15.

/notification_groups/
• The snmp_message_type attribute was added. This attribute is available when snmp_version is 2 or
3. The available values are trap and inform. This is the REST API equivalent of the new Message
Type option on the Notification Group page (Administration > Notification > Groups). See “Inform-
type messages now available for SNMP notifications” on page 17.
• The new webhooks_uri attribute to specifies the HTTP server URI for a notification group. The
notification group posts webhoosk notifications to the HTTP server at webhooks_uri. If the HTTP
server requires authentication for POST requests, use the webhooks_authtype attribute to specify
the authentication method, basic or digest. Then, use the attributes webhooks_username and
webhooks_password to specify the login credentials.
These REST API attributes correspond to the new Webhook notification settings on the Notification
Group page (Administration > Notification > Groups). See “Webhook notifications for alerts and
events” on page 9.
/routers/
• The key is_proxy was added. This key allows Sightline to treat the corresponding router as a proxy
for other routers, in which case Sightline associates flow with routers that are behind the proxy
according to the IPv4 address found in the ExporterIPv4Address field of the flow received from the
proxy.
• The key poll_alcatel_ifmib was added.
/tms_groups/
• In Sightline 9.1, you cannot configure TMS clusters or mitigate traffic with TMS clusters. Likewise, you
cannot add TMS clusters to TMS groups. As a result, the members_cluster attribute always returns
an empty string.
• The dns_auth_active_secondary_servers attribute was changed and now accepts and returns an
array of strings. In previous versions of the REST API, it accepted and returned a boolean.

Upgrade Information for Insight
New default MTU setting in ArbOS for Insight
When using Arbor hardware to run Insight, we now recommend that the network used for intra-
cluster communication supports an MTU (maximum transmission unit) of 9000. As a result of
this recommendation, the default MTU setting for 10 GbE interfaces (eth2 to eth5, which are
typically used for intra-cluster communication) was changed to 9000 beginning with the version
of ArbOS that was released with Insight 7.
Discrepancies between the MTU setting used by ArbOS for Insight and your network’s MTU can
cause errors during Insight installation and will cause issues with communication between
Insight nodes.
Using Insight in a Sightline deployment

If you use Insight and you upgrade to Sightline 9.1 you must upgrade all Sightline devices to Sightline 9.1
and upgrade your Insight nodes to Insight 7. To receive the appropriate version of the Insight installation
files, contact the Arbor Technical Assistance Center (https://support.arbornetworks.com).
Upgrade Information for Sightline
Supported upgrade paths

For information about the supported upgrade paths to Sightline 9.1, see “Supported Upgrade Paths” in
the Sightline and Threat Mitigation System Compatibility Guide, available from the Arbor Technical
Assistance Center (https://support.arbornetworks.com).
Multi-version compatibility
Sightline 9.1 is compatible with previous versions of SP and TMS. This allows you to upgrade the devices
in your deployment in stages. For details about multi-version compatibility, refer to the
Sightline and Threat Mitigation System Compatibility Guide, available from the Arbor Technical
Deployments that use flexible licensing require a new license file
For deployments that use flexible licensing

Before upgrading from SP 8.3.x or lower to Sightline 9.1, you must first contact the Arbor
Technical Assistance Center (ATAC) at https://support.arbornetworks.com/ to obtain a new flexible
license file. If you continue to use your old license file, you may experience a reduction in the
number of managed objects that can be used in the deployment or the number of users
accounts that can access the web UI.
Follow the procedures below to ensure no reduction in deployment capabilities.
For deployments that use locally-managed flexible licensing

1. Contact the Arbor Technical Assistance Center (ATAC) at https://support.arbornetworks.com/ and
obtain a new flexible license file.
2. Install the new flexible license file.
For more information, see the Sightline and Threat Mitigation System Licensing Guide at
https://support.arbornetworks.com/

3. Proceed with the upgrade procedure and install the new version of Sightline on the leader. For more
information, see “Upgrading the Software and Installing Maintenance Releases on a Sightline
Appliance” in the Sightline and Threat Mitigation System Advanced Configuration Guide at
For deployments that use cloud-based flexible licensing

1. Contact the Arbor Technical Assistance Center at https://support.arbornetworks.com/
Your new license file will be made available on the cloud license server.
2. Before beginning the upgrade procedure, disable cloud-based flexible licensing.
a. Enter / services sp license flexible server cloud_licensing disable
b. Enter config write
3. Proceed with the upgrade procedure and install the new version of Sightline on the leader.
For more information, see “Upgrading the Software and Installing Maintenance Releases on a
Sightline Appliance” in the Sightline and Threat Mitigation System Advanced Configuration Guide at
4. After installing the new version of Sightline on the leader, enable cloud-based flexible licensing and
start Sightline services.
a. Enter / services sp license flexible server cloud_licensing enable
b. Enter config write
c. Enter / services sp start
d. Enter config write
TMS HD1000 (4x100G + 8x10G) automatic configuration replaces user configuration
The new TMS HD1000 (4x100G + 8x10G) automatic configuration replaces your previous
configuration with the PPM configuration sent from the appliance. See “TMS HD1000 (4x100G +
8x10G) automatic configuration” in the Threat Mitigation System Release Notes for more
information.
TMS services must be stopped and started again if using GRE tunnels
To maintain proper functionality, follow the procedure below if you have TMSes in your deployment that
use GRE tunnels.
1. Upgrade the Sightline leader to Sightline 9.1.
2. Confirm that the Appliance Status page in the Sightline leader’s web UI (System > Status >
Appliance Status) lists each TMS status as “RUNNING”.
3. Log in to the CLI of the TMS and run the following commands:
▪ / services tms stop
▪ / services tms start
4. Repeat the previous step for each TMS in the deployment.

Upgrade process
When upgrading your Sightline deployment, you must upgrade your Sightline devices in a specific order.
For more information, see “Multi-Version Deployment Upgrade Process” in the Sightline and Threat
Mitigation System Compatibility Guide. Be aware of the following when upgrading:
• You must upgrade the leader device before upgrading any other user interface devices in your
deployment.
• 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.
• When upgrading from SP 8.2 or higher, a database sync for non-leader user interface devices may
be 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.
Upgrading requires a current maintenance and support contract

Before upgrading Sightline, make sure that your deployment’s maintenance and support contract with
Arbor is current.
Important: If your contract is not current when you upgrade Sightline, router capabilities will be blocked,
and Sightline will not be able to process flow. To revert to a previous version, you will need a backup that
was made before you upgraded.
Device certificates
Contact the Arbor Technical Assistance Center (https://support.arbornetworks.com) and obtain a
certificate for your device if you plan to use the device for one of the following:
• Remote services
• Web UI secure login
Support for DSA keys was deprecated

Sightline 9.0 and higher versions do not support DSA keys. Sightline will not advertise a DSA host key
and will not accept DSA public keys for SSH public key authentication.
Important: If you use SSH public key authorization, ensure that you are using one of the following key
types before you upgrade to Sightline 9.0 or higher: RSA, ECDSA, and Ed25519. By default, OpenSSH
generates RSA keys.
Support for TLS v1.1 was deprecated

To prevent potential security issues, TLS v1.1 was deprecated. This change was made in response to
bug 82733.
Pre-upgrade raw flows are not viewable after upgrading to Sightline 9.1
Previously logged raw flows are lost when upgrading to Sightline 9.1. Sightline will begin collecting raw
flows again after the upgrade.

System Requirements for Sightline

For information about enforced limits and appliance limits in Sightline deployments, see Sightline and
Threat Mitigation System Deployment and Appliance Limits, available from the Arbor Technical
Assistance Center (https://support.arbornetworks.com/).
Supported devices
For information about Sightline appliances and TMS devices that are supported by Sightline, see the
For more information about running Sightline in a virtual machine, see the Sightline Virtual Machine
Installation Guide, available from the Arbor Technical Assistance Center
(https://support.arbornetworks.com/).
Supported web browsers

At the time of release, Sightline 9.1 officially supports the latest versions of Microsoft Internet Explorer,
Mozilla Firefox, and Google Chrome. For more information, see “Supported Web Browsers” in the
Assistance Center (https://support.arbornetworks.com/).
Router requirements
Sightline is compatible with any router that exports RFC-compliant netflow and includes all the RFC-
required fields. Sightline supports netflow v5, v9, IPFIX, and sFlow.
Communication ports
Required ports
The following table lists the ports that Sightline uses and that are required for a deployment to operate
correctly. When the following terms appear in this table, they refer to appliance roles with flexible
licensing and to appliance types with appliance‑based licensing:
• data storage
• traffic and routing analysis
• user interface
References in this table to the FS appliance (Flow Sensor) only apply to appliance-based licensing.
Service Ports Required Protocol Direction
ArborFlow 31373 UDP • FS appliance to traffic and routing analysis
• FS appliance to data storage traffic and routing
analysis to data storage
• traffic and routing analysis to data storage
ArborFlow (if ArborFlow 5000 (default) UDP TMS appliance to traffic and routing analysis
from TMS is enabled)
BGP 179 TCP • traffic and routing analysis to router
• FS appliance to router
• Router to traffic and routing analysis
• Router to FS appliance
• Router to TMS appliance

Service Ports Required Protocol Direction

DNS 53 UDP • Sightline appliance to DNS server
• Return on same port
Flow 2055 UDP • Router to traffic and routing analysis
(netflow) (configurable) • Router to FS appliance
By default, traffic and routing analysis or FS
appliances watch all UDP ports for netflow packets
from configured routers.
HTTPS 443 TCP • Sightline non-leader appliance(s) to Sightline
leader appliance
• Sightline leader appliance to Sightline non-leader
appliance(s)
• TMS appliance to managing appliance
• Managing appliance to TMS appliance
SNMP polling of routers 161 UDP • Traffic and routing analysis to router
• FS appliance to router
• Return on same port
Sightline user interface 443 TCP User workstation to Sightline leader or user interface
(HTTPS)
Sightline user interface 443 TCP Web proxy to Sightline leader or user interface
with single-sign-on
(HTTPS)
SSL 40000-40030 TCP Any appliance to any appliance (excluding TMS)
(configurable)
Note: Some of the 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:
Service Ports Protocol Direction
Cloud-based 443 TCP • Leader to cloud license server
licensing • Cloud license server response to leader
Cloud signaling 443 TCP • APS to leader appliance
handshake • Leader appliance response to APS
(HTTPS)
Cloud signaling 7550 UDP • APS to leader appliance
heartbeat • Leader appliance response to APS
FTP 20-21 TCP • Sightline appliance query to FTP server
• FTP server response to Sightline appliance
HTTP 80 TCP • Sightline appliance to HTTP server
• HTTP server response to Sightline appliance
NTP 123 UDP • Sightline appliance request to NTP server
• NTP server response to Sightline appliance
ping echorequest, ICMP • Sightline appliance request to remote device
echoreply • Remote device response to Sightline appliance
RADIUS 1812 UDP • Sightline appliance query to RADIUS server
Authentication • RADIUS server response to Sightline appliance

Service Ports Protocol Direction

RADIUS 1813 UDP • Sightline appliance query to RADIUS server
Accounting • RADIUS server response to Sightline appliance
SMTP 25 TCP • Leader appliance delivery to SMTP server
• SMTP server response to leader appliance
SNMP polling of 161 UDP • User polling equipment query to Sightline appliance
appliances • Sightline appliance response to user polling
equipment
SNMP trap, inform 162 UDP • Leader appliance message to SNMP trap or inform
manager
SSH 22 TCP • Workstation to Sightline appliance
• Sightline appliance response to workstation
Note: Backup uses SSH
Syslog 514 UDP • Sightline appliance message to Syslog server
TACACS+ 49 TCP • Sightline appliance query to TACACS+ server
• TACACS+ response to Sightline appliance
Whois 43 TCP • Leader appliance, user interface, and backup user
interface query to Whois server
• Whois server response to appliance
ATLAS services ports

All ATLAS services require you to open access to hosts outside your network. These host live across the
internet and leverage modern content delivery networks and web services.
Important: Because each of these services uses DNS to find the IP address of the ATLAS service, the IP
addresses of the services may change. If an ATLAS service cannot connect to the service IP address,
you may need to check the current DNS results for the addresses listed in the following table and update
your firewall rules. Use of a proxy server for outbound connections is an excellent method for accessing
these services. Contact the Arbor Technical Assistance Center (https://support.arbornetworks.com) if you
have any questions or have special requirements.
The following table lists the ATLAS services:
Service Address (DNS) Port Protocol Direction
AIF aif.arbor.net 443 HTTPS/TCP Leader to feed server(s)
ATLAS Visibility atlas-visibility.arbor.net 443 HTTPS/TCP Leader and all UI appliances to

(formerly ATLAS servers
Internet Trends)
HTTP proxy (If Your HTTP proxy server 1080 TCP Leader to the proxy server
you configure a (configurable)
proxy to reach
out to ATLAS
services or the
Internet)

Fixed Issues in Sightline

Bug Number Ticket Number Fixed In Sightline Fixed Issues Description
90656 200616-000069 9.1.1 After rebooting a non-leader user interface device, Sightline
became partially unusable and generated many
REGISTRY-NOT-LOADED: sleeping syslog messages.
89791 191213-000024 9.1.1 Sightline dropped flow in some cases.
89642 191122-000031 9.1.1 In some cases, Sightline logged the error Too many open
191101-000031 files in syslog, or reported that SNMP was down.
191120-000018
191105-000036
190821-000010
191001-000051
191213-000017
191223-000028
200120-000008
200519-000057
89611 9.1.1 After changing the Cloud Signaling Only setting, the new
configuration was not applied until you restarted the
Sightline device.
89547 191010-000089 9.1.1 In some cases Sightline’s traffic binning process crashed.
191210-000033
89333 190930-000010 9.1.1 If you used the Custom Text widget in a custom wizard
191119-000054 report, you could not download the report results.
191127-000096
89299 190921-000041 9.1.1 Sightline ended fast flood alerts even thought the attack
190927-000068 traffic had not stopped.
89282 190924-000078 9.1.1 In some cases Sightline did not start auto-mitigations after
200424-000050 an upgrade.
89274 9.1.1 If you deleted a router and then created a new router with
89269 the same IP address, or if you changed the username
and/or authentication protocol, an error could occur that
stopped all router polling. To resume polling, you had to
restart Sightline services on the router’s managing
appliance.
89176 190906-000018 9.1.1 Sightline dropped flow records due to incorrect prefix
191008-000040 comparisons.
191213-000024
89050 190821-000036 9.1.1 Stopping a manual mitigation for a Cloud Signaling alert
180713-000020 started a new auto-mitigation for that same alert with the
same mitigation name.
89040 190819-000037 9.1.1 If you configured managed objects to match more than
190822-000024 200,000 AS path regular expressions, Sightline’s
190912-000011 performance degraded.
190929-000022
190930-000060
191017-000007
191021-000022
191103-000025
191106-000052
191107-000080
191122-000039
191115-000035
191127-000094


88861 191025-000013 9.1.1 Sightline user interface appliances failed to load the registry
191010-000164 after certain types of configuration updates.
88637 190626-000086 9.1.1 When editing the configuration for an HD1000 (16x10G)
191010-000164 appliance, the number of Maximum Ongoing Mitigations
191120-000005 setting on the Advanced tab of the Edit Appliance page
200123-000056 (Administration > Appliances) implied that the maximum
number was 100, instead of 200.
88623 190626-000058 9.1.1 In some cases, internal processes caused memory to
become full, leading to backup failures being displayed.
88517 190528-000015 9.1.1 The SOAP API did not return all of the mitigation rates and
statistics for some countermeasures.
88037 190422-000027 9.1.1 Sightline generated unnecessary Cloud Signaling
190819-000055 Fault errors.
86263 190509-000035 9.1.1 Cloud Signaling did not work in Sightline deployments that
191008-000053 use interface redundancy.
85560 190101-000012 9.1.1 Changing the configuration of the SNMP polling process
190123-000046 that gathers router information could stop the process.
190711-000042 While stopped, it could not report router configuration
changes. You had to restart services to restart the SNMP
polling process.
85267 190327-000067 9.1.1 A Cloud Signaling process would, in many cases,
unnecessarily restart each time a new configuration was
activated. Now this process only restarts when you activate
a new Cloud Signaling timeout period or a new user
interface appliance.
84248 180307-000004 9.1.1 In PDFs downloaded from the Flow Tuning page, the data
180712-000037 table format was incorrect.
181004-000012
190321-000022
190912-000025
73267 160127-000032 9.1.1 Sightline displayed excessive CPU load errors for TMS
160817-000028 devices on the Appliance Status page.
170420-000012
170815-000033
170912-000012
88212 190510-000039 9.1 TCP Null alerts now appear when the “TCP Flags Missing”
flag is set on the router.
88070 190425-000022 9.1 Mitigation templates did not reset when the 2nd match
criteria on the Match tab in managed objects was modified.
88065 190425-000028 9.1 Sightline no longer fails to sync AIF templates to non-leader
UI devices.
88064 190425-000028 9.1 Data syncing issues between the leader and backup leader
190530-000063 were corrected.
87841 190328-000053 9.1 Sightline now cleans up legacy memory management files
during upgrade to avoid a situation where things can crash.
87807 190323-000012 9.1 Fixed an issue that caused Sightline to be unable to initiate
BGP peering in mitigations to a TMS device.
87616 190228-000060 9.1 Fixed an issue that caused notification groups to be
recycled after they were deleted.
87608 190217-000006 9.1 Reported active routes would erroneously increase on
secondary BGP session.


87358 190404-000051 9.1 Database syncing issues between the leader and TRA have
190206-000047 been resolved.
190321-000023
190401-000122
87185 190109-000046 9.1 Sightline adds an annotation to an alert when the alert
190108-000065 reuses a mitigation.
87183 190109-000046 9.1 Alerts now correctly link to mitigations that are being
190108-000065 handled in both the UI and REST API.
87112 190314-000075 9.1 The dropdown selector in the Merge AIF Template popup
now works as expected.
87070 190107-000028 9.1 Alert managed object matches work on systems with larger
numbers of results.
87031 181226-000002 9.1 Fixed an issue that caused part of the flow storage system
to crash.
87002 181205-000037 9.1 Leader / backup leader combinations with large number of
IP access rules now sync correctly.
86985 181219-000052 9.1 After using the date selector once on the Explore Forensics
page and updating the page, the date selector tool now
remains available.
86983 181217-000015 9.1 Fixed compatibility issues so Sightline and APS can now
handle a space-separated list.
86946 181213-000073 9.1 Sightline now deletes IP addresses properly when they are
deleted from a router interface.
86935 181210-000042 9.1 The suggested values for some Insight facets could return
“warning: not found in flow data” even though the value was
present for the facet.
86904 181210-000028 9.1 Remote facets were added to Insight for parity with Explore
181210-000029 Traffic.
190409-000055
86856 181203-000038 9.1 Fixed an issue that caused config files and passwords that
181211-000044 include “#” to break.
86854 181015-000024 9.1 A tool was added to clean up unused router interfaces from
the Sightline configuration data file.
86830 181129-000041 9.1 The incorrect mitigation template is no longer selected in
190529-000072 when editing a managed object's mitigation.
86794 181127-000031 9.1 Using the REST API to query mitigation rates now returns
190426-000044 correct rates when the mitigation id is tms-<mitigation id> in
190528-000015 the end query presented to Sightline.
86616 181105-000030 9.1 An alert information query process no longer crashes.
86580 181101-000019 9.1 The” expand” icons now display as expected in the sample
181102-000020 packets dialog.
190201-000006
190227-000041
86513 190128-000034 9.1 Changing the name of a router no longer stops TMS
Blacklist Offloading when that router is targeted.
86503 190404-000051 9.1 After a failover, the Configure Appliances page
181022-000036 (Administration > Appliances) correctly indicates that the
190211-000060 former backup leader is now the leader.
86502 181015-000106 9.1 Documented the maximum number of CIDR blocks that can
181121-000022 be specified in a managed object's “Match Type” field.


86484 181012-000061 9.1 Failures no longer occur in syslog when adding and
removing prefixes from a mitigation set to reuse.
86481 181022-000017 9.1 Sightline no longer incorrectly attempts to start a duplicate
181122-000032 blackhole auto-mitigation.
86432 181017-000028 9.1 In the event of a failover, Sightline services would not start
181109-000028 on the backup leader.
190321-000023
190523-000036
86336 181011-000004 9.1 Fixed an issue that caused a “Configuration out of date”
error message when stopping and restarting SP services.
86270 181002-000010 9.1 Resolved an issue where an improperly terminated user
181115-000000 SSH session would sometimes produce a hung process and
180910-000014 resulted in an increased CPU load on the system.
86266 181003-000019 9.1 Fixed an issue that caused some filter lists to fail in non-
181004-000021 leader user interface devices or backup leaders that have
failed over.
86254 180905-000021 9.1 The standard fan setting was changed to 10k RPM to
reduce the likelihood of overheating.
86208 180913-000022 9.1 The email notification “New ATLAS Intelligence Feed
180724-000054 template content available” is no longer sent when there is
181030-000031 no new content available.
86120 180917-000023 9.1 Added support for Inform-type notifications to fix an issue
that caused modern traps to not return correctly.
86101 180912-000010 9.1 SNMP traps reported incorrect information when the
181022-000011 maximum impact of the alert traffic was 4.3 Gbps or more.
190430-000004 This issue was resolved by updating the Sightline MIB. See
Updated MIB on page 22.
86024 180912-000011 9.1 Time zones for timestamps in annotations now match the
190524-000026 system and alert time zone.
190524-000008
85877 180807-000013 9.1 Committing a configuration through the CLI no longer
190513-000030 causes API calls and Cloud Signaling requests to fail.
180828-000007
180807-000030
180820-000059
180821-000023
190224-000032
190103-000014
190329-000046
190422-000005
85645 180801-000033 9.1 Fixed issues that caused queries on the Explore BGP
181004-000048 Routing Table page to timeout.
190610-000009
85622 190307-000036 9.1 Manually started mitigations are now correctly represented
in the REST API.
85233 180615-000042 9.1 Fixed an issue where an interface could not be added to a
190117-000008 managed object boundary.
85219 180614-000036 9.1 Removed text from the Release Notes that incorrectly
implied a Sightline device with the user interface role needs
to communicate with routers over port 179 for BGP service.
85213 180604-000041 9.1 Fixed an issue that caused the web UI to be unresponsive.


85039 180525-000004 9.1 Appliance-based TMS Bandwidth is now reported correctly
190320-000034 on the Deployment Status page when a TMS 2800 or TMS
190516-000061 2600 is in the deployment.
190615-000026
84453 180319-000006 9.1 Fixed an issue that caused Sightline devices with the data
storage role to not support IPv6.
84407 180305-000012 9.1 Learning mitigations of child managed objects will now be
properly deleted.
84022 180209-000004 9.1 Sightline now returns an error if the user enters an invalid
value for the number of open connections for the TCP
Connection Limiting Countermeasure.
83592 170912-000016 9.1 Blackhole auto-mitigations are reused for new alerts if the
mitigation is still ongoing when the original alert ends.
83412 171129-000008 9.1 Due to a rare race condition, an internal process could have
171110-000037 crashed, logged a message in the system syslog similar to
180921-000060 "[F] #TBD-MISSING-FLOWS -2", and automatically
181025-000018 restarted.
190321-000014
190321-000014
190329-000020
190524-000001
190711-000000
83149 171102-000026 9.1 Fixed an issue that caused mini graphs to not be displayed
180416-000032 in emailed reports.
190225-000043
190425-000027
82733 180803-000010 9.1 To prevent potential security issues, TLS v1.1 was
deprecated.
82130 170830-000044 9.1 Fixed an issue that caused the TMS appliance capacity
180110-000023 represented in the table and graph in the deployment status
180124-000011 to not be displayed properly.
190320-000034
81843 180320-000023 9.1 When using the Sightline REST API to edit the Payload
Regular Expression countermeasure, host blacklisting
changes are no longer incorrectly applied to the “Blacklist
on Blocked” setting in the AIF and HTTP/URL Regular
Expression countermeasure.
81376 170331-000000 9.1 Fixed an issue that caused Sightline to improperly report
180108-000032 dropped flow in certain conditions.
180404-000045
181102-000021
180927-000037
80800 170419-000007 9.1 Fixed an issue where Sightline did not display an error
170606-000003 message when a user attempted to log in to the web UI and
171129-000038 exceeded the number of maximum concurrent logins.
180420-000019
180909-000005
80776 170518-000032 9.1 Users can now set a custom page size through the
190110-000034 database, which results in reduced disk usage.
70303 170706-000040 9.1 Manually setting an interface name via the UI or CLI no
longer causes the interface to be constantly rediscovered
and given a new internal ID.


53146 190325-000051 9.1 Mitigations templates now have settings for DNS and HTTP
scoping.

Known Issues in Sightline

Bug Number Ticket Number Found In Sightline Known Issues Description
91162 9.1 When you select a misuse type on the Host Automatic Rate
Calculation page and click Show Results, in some cases
Sightline displays the message No data available even
though there is traffic associated with the specified misuse type.
89099 190828-000154 9.1 Some users with local (non-cloud-based) flexible licenses and
191009-000259 the AIF for Sightline licensed capability were not receiving the
191023-000030 AIF managed object feed.
191105-000045 For more information, see
191113-000056 Automatically download managed objects that match OTT traffic
in ATLAS on page 11.
88791 9.1 In some cases, Smart Mitigation graphs do not show
“Not Dropped” traffic even though traffic is passing.
87191 9.1 When you delete a router, Sightline does not remove it as the
target for TMS flowspec blacklist offloading.
86214 9.0 If you POST an invalid calculation attribute value to the
/smart_alert_settings/ endpoint in the REST API, the smart
alert that you create will not work. The only valid calculation
values are Last, Avg, Max, and Pct95. (These valid values are
the same as the Calculation options on the Explore > Insight
page in the web UI.)
86192 9.0 If you POST an invalid filter or view attribute value to the
/smart_alert_settings/ endpoint in the REST API, the
returned error data contains a correct error description in the
detail attribute but an incorrect error path in the pointer
attribute.
86087 9.0 The REST API returned an error with the ambiguous message
`Detailed error information unavailable` during a
misuse-triggered flowspec auto-mitigation using a Juniper
router.
86081 9.0 Error messages appear in syslog when you commit a
configuration that has no user-defined misuse types.
86080 9.0 On the Host Automatic Rate Calculation page (Administration
> Detection > Host Automatic Rate Calculation), the
Managed Object list might not include all of the managed
objects that you can select.
Workaround:
Type the name (or a portion of the name) of the managed object
to select in the Managed Object list box.
86014 9.0 Although the product has been renamed “Sightline”, some
places in the product refer to the previous product names
(“Peakflow” or “SP”).

Other Things to Know about Sightline
Create a backup after converting to flexible licensing

Important: If you are converting from legacy appliance-based licensing to flexible licensing, be sure to
create a backup as soon as possible after the conversion. It is not recommended/supported to restore a
backup made before the conversion onto an appliance that was converted to flexible licensing.
High CPU load averages

On large multi-appliance deployments, high load averages will be seen when arbor_stats runs. This
does not materially impact interactive performance of the Sightline appliance.
Dynamic subscriber interfaces
Sightline interface handling

Sightline provides three levels of granularity when gathering data on a per-interface basis, depending on
the interface classification and discovery method:
Interface classification Discovery method Data granularity
External or configured to Via flow • Highest level of data granularity
collect “detailed” statistics • Available in all interface pages and reports
Other than external Via flow • Much lower level of data granularity
• Available in all interface pages and reports
• Included in the UI
Never sends flow data SNMP • Tracked individually
• Not available in all interface pages and reports
• Impacts the overall interface scaling properties of the
deployment, but not as much as the other types of
interfaces
Untracked interfaces
In addition to the data gathered on a per-interface basis, there can be untracked interfaces, which have
the following properties:
• They are on a router that was configured with the “Enable Dynamic Subscriber Interface Handling”
option.
• Their SNMP interface names/descriptions do not match a configured Interface Classification rule OR
the interfaces are not represented in the SNMP data obtained from the involved router.
Note: Only 400,000 interfaces with SNMP information can be processed, even if they are untracked
interfaces. The 700,000-interface limit can only be reached if a very large number of the interfaces
have no SNMP presence whatsoever.
• They do not appear in any interface page or report in the product.
• They do not impact any interface scaling limitation on the deployment. Therefore, there can be an
unlimited number of these kinds of interfaces on a particular collector or on the deployment in
general.
• They can have flow sent for them by the router and it will be tracked on a per-router basis in a single
aggregate interface. This appears in normal interface pages and reports.
• The flow sent for these interfaces is constrained by the normal stated flow processing limits on a per-
appliance basis, as well as the normal licensed limits on a per-deployment basis for flex licensing
deployments.

Additional Information
Downloading the software

You can download the software releases and user documentation from the Arbor Technical Assistance
Center at https://support.arbornetworks.com using the Software Downloads link.
Contacting Arbor Technical Assistance Center

You can download the software release and user documentation from the Arbor Technical Assistance
Center website. You will need a username and password to access the site.
If you do not already have a customer account, contact Arbor Technical Assistance Center at:
• 1 877 272 6721 [U.S. toll free]
• +1 781 768 4301 [Worldwide]
• https://support.arbornetworks.com/
Documentation
User documentation is available from the Arbor Technical Assistance Center at
https://support.arbornetworks.com using the Software Downloads link.
The user documentation for Sightline includes the following documents:
Document Description
Sightline and Threat Mitigation Information about how to install, connect, and configure Sightline
System Quick Start Cards appliances.
Online Help Information about the feature on the current page is displayed, with links to
supporting information and a table of contents to the complete Sightline
and Threat Mitigation System User Guide and Sightline and Threat
Mitigation System Advanced Configuration Guide.
Sightline and Threat Mitigation Information about how to use Sightline.
System User Guide
Sightline and Threat Mitigation Information about configuring advanced settings in Sightline, including
System Advanced Configuration those that can only be configured using the command line interface (CLI).
Guide
Sightline and Threat Mitigation Information about cloud-based and locally-managed flexible licensing,
System Licensing Guide appliance-based licensing, and volumetric licensing for TMS appliances.
Managed Services Customer Guide Information about deploying and using Sightline managed services.
Sightline Virtual Machine Installation Information about running Sightline in a virtual machine.
Guide
Software Threat Mitigation System Information about running Software TMS in a virtual machine.
Virtual Machine Installation Guide
Software Threat Mitigation System Information about installing Software TMS on hardware.
Installation on Hardware
Sightline and Threat Mitigation Information about the enforced and guideline limits for an Arbor Networks
System Deployment and Appliance deployment and for Arbor Networks appliances.
Limits
REST API Documentation Online information about the REST API endpoints.
Sightline API Guide Instructions for remotely accessing Sightline using the REST, SOAP, and
Arbor Web Services APIs.

Appendix A: Changes to notifications in Sightline 9.1

As part of the change in behavior noted in Updated MIB on page 22, new 64-bit objects were added to
the following SNMP notification types in Sightline 9.1.
Notification type New 64-bit object 32-bit object equivalent
managedObjectUsage spThresholdHC spThreshold
fingerprintUsage spUsageHC spUsage
serviceUsage
dosNetworkProfiledAlert spImpactBpsHC spImpactBps

dosNetworkProfiledAlertDone spImpactPpsHC spImpactPps
dosHostDetectionAlert
dosHostDetectionAlertDone
SNMP notification example: dosHostDetectionAlert

2019-04-17 21:36:48 example.com [UDP: [172.18.2.243]:19923-
>[172.18.2.190]:162]: DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks:
(17941868) 2 days, 1:50:18.68 SNMPv2-MIB::snmpTrapOID.0 = OID: PEAKFLOW-SP-
MIB::dosHostDetectionAlert PEAKFLOW-SP-MIB::spAlertID = Gauge32: 41
PEAKFLOW-SP-MIB::spAlertDetectionSignatures = STRING: Total Traffic
PEAKFLOW-DOS-MIB::pdosAnomalyDirection = STRING: incoming PEAKFLOW-DOS-
MIB::pdosAnomalyStart = STRING: 2019-04-17 21:36:45 UTC PEAKFLOW-DOS-
MIB::pdosAnomalyDuration = Timeticks: (300) 0:00:03.00 PEAKFLOW-DOS-
MIB::pdosUrl = STRING: https://example.com/page?id=host_alert&alert_id=41
PEAKFLOW-SP-MIB::spInetAddress = STRING: "10.11.12.13" PEAKFLOW-SP-
MIB::spInetAddressType = INTEGER: ipv4(1) PEAKFLOW-SP-MIB::spImpactBps =
Gauge32: 1511849984 PEAKFLOW-SP-MIB::spImpactPps = Gauge32: 90254096
PEAKFLOW-SP-MIB::spImpactBpsHC = Counter64: 641461977088 PEAKFLOW-SP-
MIB::spImpactPpsHC = Counter64: 90254096 PEAKFLOW-DOS-
MIB::pdosAnomalyClassification = STRING: high

Appendix B: Verification of flowspec features of Arista switches

Arbor has tested and verified that flowspec features of Arista switches are compatible with Sightline. This
section described the testing conditions and results.
Hardware tested
• Arista 7280CR2A-60
• 60 QSFP100 ports, 2U, 1760W
• 12 Tbps, 5.02 Bpps, L2/3 throughput
• Hardware version 21.01
• Software image version 4.22.0F (internal build version 4.22.0F-12170486.4220F)
Test 1: How quickly is traffic dropped when a flowspec mitigation starts?

In this test, a flowspec mitigation that matched on a specific destination IP address (192.0.2.1), a specific
source port (5019), and a specific destination port (60516) was toggled between the “stopped” and
“running” states via the Sightline web UI (Mitigation > Flow Specification). An Ixia was configured to
send a Tolly-distribution (55@64 bytes, 5@78 bytes, 17@576 bytes and 23@1518 bytes) of UDP
packets from port 5019 to port 60516 from a random set of source IP addresses to a destination IP of
192.0.2.1, and set to send the traffic at 100% over a 40 Gbps interface. When toggling the flowspec
mitigation between stopped and running, the traffic should be 100% blocked or 100% passed. The
packets per second rate was measured every 5 seconds using the "5 second input rate” statistic at the
switch of the TMS.
Baseline
In the baseline test case, there were no existing flowspec mitigations on the Arista switch. The results
show that after Sightline announces the flowspec, the traffic is affected very quickly, and within 10
seconds the 5-second input rate on the TMS reflects the stopped/running state.

bits second (ingress interface of TMS connected to Arista switch)
20,000,000,000
0,000,000,000
0,000,000,000
10,000,000,000
0
0
5s
10s
15s
20s
25s
0s
5s
0s
5s
50s
55s
1m
1m s
1m 11s
1m 1 s
1m 21s
1m 2 s
1m 1s
1m s
1m 1s
1m s
1m 51s
1m 5 s
2m 1s
2m s
2m 11s
2m 1 s
2m 21s
Proprietary and Confidential Information of NETSCOUT Systems, Inc.

2m 2 s
2m 1s
2m s
2m 1s
2m s
2m 51s
2m 5 s
m 1s
m s
m 11s
m1 s
m 21s
m2 s
m 1s
m s
0
1
2
Number of active Flowspecs on Arista switch

bits second
Number of Flowspecs
43
Many existing flowspec announcements

In this test case, there were 10,495 existing flowspec mitigations on the Arista switch. The purpose of this
test was to see if having a large number of existing flowspec announcements changed the speed at which
new flowspec mitigations affect traffic.
The results show that after Sightline announces (or removes) the 10,496th flowspec mitigation, the traffic
is still affected very quickly, and within 10 seconds the 5-second input rate on the TMS reflects the
stopped/running state.
0,000,000,000 10 97
bits second (ingress interface of TMS connected to Arista switch)
0,000,000,000
Number of active Flowspecs on Arista switch

10 9
20,000,000,000
10 95
10,000,000,000
bits sec
Number of Flowspecs
0 10 9
0
5s
1m
2m
m
10s
15s
20s
25s
0s
5s
0s
5s
50s
55s
1m 5s
2m 5s
m 5s
1m 10s
1m 15s
1m 20s
1m 25s
1m 0s
1m 5s
1m 0s
1m 5s
1m 50s
1m 55s
2m 10s
2m 15s
2m 20s
2m 25s
2m 0s
2m 5s
2m 0s
2m 5s
2m 50s
2m 55s
m 10s
m 15s
m 20s
m 25s

Test 2: How accurate is the sFlow received from the Arista switch?
The purpose of this test was to see if a large number of flowspec announcements from Sightline affected
the accuracy of sFlow from the Arista switch.
In these tests, memcached attack traffic (again, using the Tolly distribution) was generated from the Ixia
targeting a /29 of an MO with a protected /24. 40 Gbps of attack traffic was started, and 8 DoS host alerts
were detected by Sightline corresponding to the /29 being targeted, which then triggered eight auto
flowspec mitigations. The attack was left running for one hour, and then the flow data from each of the 8
alerts was retrieved from the dos_alerts/refine_data SQLite database.
The results show the accuracy of the sampled flow over the one-hour attack. The “Ideal” line represents
perfect sampling.
Baseline
In this test, there were no existing flowspec announcements on the Arista switch, so when Sightline
detected the attack, it announced 8 flowspecs, bringing the total to 8.
Flow data from 8 alerts, 8 flowspecs

0 Gbps of attack traffic, 1 minute bins, 1 hour
75,000,000
7 ,500,000
Frames per minute per alert
Ideal
7 ,000,000
7 ,500,000
7 ,000,000
0
58
10
12
18
20
22
28
50
52
0
1
Minute

More than 11,000 existing flowspec announcements

In this test, there were 11,272 existing flowspec announcements on the Arista switch. After the attack was
detected, there were 11,280 flowspec announcements from Sightline. There is an overall slight downward
reduction in the overall sampling rate, but well within the realm of acceptability considering it is sampled
data.
Flow data from 8 alerts, 11280 flowspecs

0 Gbps of attack traffic, 1 minute bins, 1 hour
75,000,000
7 ,500,000
Ideal
7 ,000,000
7 ,500,000
7 ,000,000
0
58
10
12
18
20
22
28
50
52
0
1
5
Minute

More than 24,000 existing flowspec announcements

In this test, there were 24,568 existing flowspec announcements on the Arista switch. The Ixia was
configured to send 80 Gbps of “good” traffic and 20 Gbps of memcached attack traffic through the Arista
switch during the test, so the scale on the graph is half of the previous graphs. After the attack was
detected, there were 24,576 flowspecs being announced from Sightline.
Flow data from 8 alerts, 2 57 flowspecs

100 Gbps total traffic, 20 Gbps of attack traffic, 1 minute bins, 1 hour
8,000,000
7,500,000
1
Ideal
7,000,000
,500,000
,000,000
0
58
10
12
18
20
22
28
50
52
0
1
5
Minute
For reference, running show int e60/1 (the ingress interface from the Ixia) during the above test
showed the following:
5 minutes input rate 95.9 Gbps (99.9% with framing overhead), 24666350 packets/sec
Running show int e3/1 (the egress interface to the TMS) showed the following:
5 minutes output rate 76.7 Gbps (79.9% with framing overhead), 19727385 packets/sec
Running tmsdump on the TMS confirmed that there was no memcached traffic reaching the TMS.

Test 3: How fast are flowspec announcements ingested by the Arista switch?
Overall, the Arista accepted flowspec announcements as fast as Sightline could announce them.
Every 15 seconds, we counted the number of flowspec rules that were on the Arista switch by running the
following (there are 5 header lines in the output, so the command subtracts 5 to indicate the number of
rules):
while true; do (sleep 15&; echo -n "`date`: "; echo $((`ssh hostname show bgp flow-
spec ipv4 | wc -l` - 5)); wait); done
Timing examples of going from 0 Flowspec rules to 8,192 rules as announced by Sightline:
Example 1
13:17:05 GMT 2019: 0
13:17:20 GMT 2019: 51
13:17:35 GMT 2019: 51
13:17:50 GMT 2019: 51
13:18:05 GMT 2019: 51
13:18:20 GMT 2019: 2352
13:18:35 GMT 2019: 2352
13:18:50 GMT 2019: 2352
13:19:05 GMT 2019: 2352
13:19:20 GMT 2019: 4598
13:19:35 GMT 2019: 4598
13:19:50 GMT 2019: 4598
13:20:05 GMT 2019: 4598
13:20:20 GMT 2019: 6790
13:20:35 GMT 2019: 6790
13:20:50 GMT 2019: 6790
13:21:05 GMT 2019: 6790
13:21:20 GMT 2019: 8192
Example 2
19:09:12 GMT 2019: 0
19:09:27 GMT 2019: 1299
19:09:42 GMT 2019: 1299
19:09:57 GMT 2019: 1299
19:10:12 GMT 2019: 1299
19:10:27 GMT 2019: 3348
19:10:42 GMT 2019: 3348
19:10:57 GMT 2019: 3348
19:11:12 GMT 2019: 3348
19:11:27 GMT 2019: 5358
19:11:42 GMT 2019: 5358
19:11:57 GMT 2019: 5358
19:12:12 GMT 2019: 5358
19:12:27 GMT 2019: 7338
19:12:42 GMT 2019: 7338
19:12:57 GMT 2019: 7338
19:13:12 GMT 2019: 7338
19:13:27 GMT 2019: 8192

Arbor Networks Sightline 9.1.1 9.1 Release-Notes 2020-07-16

Uploaded by

Copyright:

Available Formats

You might also like

Arbor Networks Sightline 9.1.1 9.1 Release-Notes 2020-07-16

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Arbor Networks Sightline 9.1.1 9.1 Release-Notes 2020-07-16

Uploaded by

Copyright:

Available Formats

Sightline

Document Number: SP_ RN-911-2020/07

2 Proprietary and Confidential Information of NETSCOUT Systems, Inc.

Revision History .......................................................................................................................................... 6

Proprietary and Confidential Information of NETSCOUT Systems, Inc. 3

4 Proprietary and Confidential Information of NETSCOUT Systems, Inc.

Fixed Issues in Sightline ....................................................................................................................... 32

Proprietary and Confidential Information of NETSCOUT Systems, Inc. 5

6 Proprietary and Confidential Information of NETSCOUT Systems, Inc.

Sightline 9.1.1 Release Notes

Sightline 9.1 Release Notes

View multiple mitigation impacts from a single DoS Alert page

Mitigations table for DoS alerts

Proprietary and Confidential Information of NETSCOUT Systems, Inc. 7

For more information about these features

Inactive TMS mitigations

8 Proprietary and Confidential Information of NETSCOUT Systems, Inc.

Regular expression generation from packet capture (PCAP) files

IPv6 support for flowspec mitigations

Webhook notifications for alerts and events

Proprietary and Confidential Information of NETSCOUT Systems, Inc. 9

10 Proprietary and Confidential Information of NETSCOUT Systems, Inc.

Automatically download managed objects that match OTT traffic in ATLAS

Note: Critical bug 89099 has been identified in Sightline 9.1.0.

Configure user interface appliances for Cloud Signaling only

Flowspec support and Arista switches

Proprietary and Confidential Information of NETSCOUT Systems, Inc. 11

Insight: New views added

Insight: New facets added

12 Proprietary and Confidential Information of NETSCOUT Systems, Inc.

Proprietary and Confidential Information of NETSCOUT Systems, Inc. 13

Enhanced support for routers that are behind a proxy

Custom diversion prefixes for mitigations and mitigation templates

14 Proprietary and Confidential Information of NETSCOUT Systems, Inc.

Improved accuracy and performance for flow matching in alert traffic

FCAP expressions can be used to match traffic class of IPv6 traffic

Traffic collection can be disabled for a managed object

Flow Specification Blacklist Offloading supports BGP communities

Proprietary and Confidential Information of NETSCOUT Systems, Inc. 15

Increase in number of concurrent TMS mitigations

New filters added to the Explore Traffic page

16 Proprietary and Confidential Information of NETSCOUT Systems, Inc.

Inform-type messages now available for SNMP notifications

Mitigation Orchestration Event alert

Mitigation orchestration configuration options

Minimum Over Bandwidth Duration

Proprietary and Confidential Information of NETSCOUT Systems, Inc. 17

Mitigation Movement Pause Duration

Mitigation Return Interval

New “traffic marking” action added to manual flowspec mitigations

18 Proprietary and Confidential Information of NETSCOUT Systems, Inc.

Insight: Increased stability and performance

Insight: Support for pasting multiple IP addresses in the value field

Proprietary and Confidential Information of NETSCOUT Systems, Inc. 19

Unsupported TMS devices removed from TMS and Sightline

In the Sightline UI, the following items have been removed:

20 Proprietary and Confidential Information of NETSCOUT Systems, Inc.

New default port numbers used for RADIUS connections