II. Arbor Networks SP System Administrator Training Book

System Administrator Training System Monitoring
1-1 Arbor Networks SP


The essential components of the Arbor Networks SP solution are the Traffic Routing and Analysis (TRA) and
the TMS platforms. The TRAs collect flow data, SNMP and BGP to create network wide visibility, reporting
and alerts. The Threat Management System (TMS) is a family of platforms that provide application level
visibility and DDOS mitigation. The TMS family scales from 1.5Gbps mitigation capacity (suitable for smaller
hosting providers, enterprises) to 40Gbps for large ISP scrubbing centers. The combined deployment provides
a centrally managed, integrated network and application visibility, reporting and threat detection/mitigation.
The Flow Sensor (FS) is similar to the TRA platform but tailored for the customer and hosting edge of the
network, and is only used in a deployment that uses appliance-based licensing. An FS collects flow and SNMP
data and reports information to a managing TRA.
The Data Storage (DS) appliance is a management platform that provides redundancy (multi-homing) for
managed objects and therefore frees storage and processing resources on collectors that would otherwise store
the traffic details.
The User Interface (UI) appliance provides a central reporting and management platform for managed
services. It enables each managed services customer tailored access to network reporting and DDOS
prevention services.


Arbor Networks
Arbor Networks SP/TMS
SP Essentials Training 8.0 System Monitoring

Arbor Networks

Arbor Networks
The Deployment Status page presents deployment status graphs and table along with ongoing System alerts
(most current 30).
The Deployment Status graph tabs allow you to view flows per second, TMS bandwidth, and active users for
your deployment for a selected time frame.
The graphs include the following:
• A green trend line showing average usage when the selected time frame is a week or longer.
• A horizontal black line for the maximum licensed capacity when usage is approaching this maximum
capacity. This line does not appear for the Flows per Second graph with appliance-based licensing.
• A vertical red line indicating the most recent midnight if the selected time frame is a week or shorter.
On the leader appliance, a Upload Flexible License button appears in the upper-right corner of the
Deployment Status page. When you are ready to convert to flexible licensing, you can click this button to
start the flexible licensing conversion wizard.

Arbor Networks
The Deployment Status table displays the status of resources in your SP/TMS deployment. With Flexible
Licensing, an asterisk (*) is appended to items whose capacities are governed by a license. The status of the
AIF license appears below the table near the bottom of the page.
The Current column includes a bar graph which displays the current usage over the maximum capacity. The
usage appears as a dark gray bar when usage is well below the maximum capacity. When usage starts to
approach the maximum capacity, the bar changes to orange. When usage reaches or exceeds the maximum
capacity, the bar changes to red.
When the usage bar is orange or red, you can hover your mouse cursor over the item to view a message
describing the item status. When the bar is orange, the message indicates that the usage is nearing capacity.
When the bar is red, the message describes the impact that reaching or exceeding the maximum capacity has
on your SP/TMS deployment. The % Total for the item is also highlighted with a red background when you
reach or exceed the maximum capacity.
Note: With flexible licensing, SP displays entries for flows per second for core and edge routers. It also
displays separate entries for core and edge routers.

Arbor Networks
With flexible-licensing, the Time-Based Licenses table appears if you have any time-based licenses in your
SP deployment. Time-based licenses include trial licenses for any of the licensed capacities and AIF licenses.
The table lists the licenses with the time remaining on the license and the expiration date of the license. For
AIF licenses, it lists only the license that has the closest expiration date.

Arbor Networks
You can use the Flow Monitoring tab to view the rate at which an appliance receives flow, the number of
items that an appliance is tracking, and how the appliance is performing.
Items Tracked are the unique traffic entities for which SP stores data. For example TCP port 80 for a single
customer managed object is one item tracked.

Arbor Networks
You can use the Users tab to view how many users are logged on to your Web UI appliances, the level of their
activity, and the basic performance of the appliance. You can click the name link for an appliance to navigate
to the UI Statistics tab on the Appliance Status page.

Arbor Networks
The TMS tab displays statistics for each TMS appliance in your deployment. You can click the TMS
appliance name link to navigate to the TMS Statistics tab on the Appliance Status page.

Arbor Networks

Arbor Networks
The General tab on the Appliance Status page provides real-time status information for each individual
SP/TMS appliance. The system presents this information as a graph that you can customize and a Appliance
information table that provides the operational status for all configured devices at a single glance. You can use
the data from this page to monitor general system health, load, and performance over time.
When operating normally, each Appliance sends periodic heartbeat messages to the Leader. These messages
contain current status information and serve to notify the Leader that the Appliance is still up and running. If
the Leader does not receive heartbeats from the Appliance for a predetermined period of time, the system
displays a note in the Appliance information table. This might indicate that the Appliance is down or non-
operational, or there is some type of network connectivity issue between the Leader and the Appliance. Since
traffic and routing data is distributed across the system, all data monitored by an unreachable Appliance is not
included in the traffic and routing reports generated by the system until the Leader is again able to reach the
Appliance.

Arbor Networks
When you click the plus sign icon (+) next to an appliance name on the Appliance Status page, one or more of
the following tables appear that display detailed information about the appliance:
• System Details displays the version of SP that is installed on the appliance.
• Installed Packages displays the packages that are installed on the appliance, including the version
numbers.
• Ongoing System Alerts displays any ongoing system alerts for the appliance. This section appears only
when there are ongoing alerts for an appliance.

Arbor Networks
The UI Statistics tab allows you to monitor the diagnostics for appliances with the UI role (UI or TRA
devices) over a designated period of time and displays the following information for each Web UI appliance:
Name – The configured hostname of each Web UI Appliance listed.
Active Users – The number of users currently logged into the Web UI Appliance.
SOAP Queries – The number of SOAP queries made.
Query Duration (ms) – The duration of the queries in milliseconds.
Reports – The number of reports that users have viewed.
Page Loads – The number of times the users have loaded the page.
Bandwidth (PPS) – The bandwidth UI Appliance and bandwidth per interface in bits per second (bps).
Bandwidth (BPS) – The bandwidth UI Appliance and bandwidth per interface in packets per second (pps).
User Login – The number of users logged into the Appliance during this time period.
User Logout – The number of users who logged out of the Appliance during this time period.
The table entries show the current data from the last five minutes.

Arbor Networks
The TMS Statistics tab allows you to monitor the your TMS appliances for capacity planning and appliance
utilization by displaying a graph and a table that contains information about each TMS.
• When you initiate a TMS mitigation, you must select an SP TMS Appliance. In order for you to select a
TMS with capacity for another mitigation, this tab (which includes the number of mitigations and in bps
traffic per TMS) is critical.
• Without the ability to see the status in terms of bps in and out traffic, the user cannot know if a mitigation
through a TMS Appliance will work or if traffic will overload the ingress interfaces, causing normal traffic
to be dropped.
(Continue on next page)

Arbor Networks
Continue
The TMS Statistics table shows the following information for each Appliance:
Name – The configured hostname of each Appliance listed. Click the link in the Name column to view the
Appliance configuration page.
Type – The type of SP TMS Appliance.
Appliance Status – A brief description of each Appliance status.
BGP – The up or down status for configured BGP peers. For each column, X/Y is displayed, where X
represents the number of configured peers that are currently active for that input, and Y represents the total
number of peers that have that input configured.
GRE – The up or down status for the configured GRE destination IP addresses for all tunnels. For each
column, X/Y is displayed, where X represents the number of running, unique destination IP addresses, and Y
represents the total number of unique destination IP addresses.
Mitigations – The number of mitigations that were ongoing during the last heartbeat. The column also shows
the maximum number of mitigations you are allowed for each SP TMS Appliance. The column is red when
the mitigations go above the device’s mitigation limit, the column is orange when the device’s mitigations
reach between 80 and 100 percent of the limit, and the column is green when the device’s mitigations are
below 80 percent of the limit.
In – The amount of incoming traffic to the Appliance. The column also shows the maximum amount of in
traffic you are allowed for each SP TMS Appliance. A red column signifies that the incoming traffic is above
80 percent of the Appliance capacity. A green column signifies that the incoming traffic is 80 percent or below
the device’s capacity.
Out – The amount of outgoing traffic from the Appliance.
% Passed - The percentage of traffic that the SP TMS Appliance did not filter.
Memory – The percentage of physical memory currently being used by the SP TMS Appliance.
Load – The average number of processes in the system run queue. Note: This is the standard UNIX CPU load
measurement.
Disk – The percentage of available disk space being used to store traffic and routing data.
Uptime – The amount of time that has elapsed since the SP TMS Appliance was last restarted.
Alerts – The number of alerts seen by the Appliance. Expansion column (+/-) The five most recent alerts seen
by the Appliance including the ID number, start and stop times, the Appliance that reported the alert, alert
type, and what triggered the alert.
The table entries show the current data from the last five minutes.

Arbor Networks

Arbor Networks
Example URL:
https://sp-ui/page?id=appliance_monitoring&m1=48&t=w&a=115#MetricComparison_tab
• SP UI Page: id=appliance_monitoring
• Metric identifier: &m1=48 (BGP routes)
• Time Period: &t=w (week)
• Device GID: &a=115 (cse-sp-2)
• Page Tab: #MetricComparison_tab
Note that settings not relevant to the tab are preserved. The URL preserves context for the entire Appliance
Monitoring page, including tabs that are not selected

Arbor Networks

Arbor Networks

Arbor Networks

Arbor Networks
Changed names and names of new metrics are both listed in the Release Notes. Be sure to check them for any
changes.

Arbor Networks
To configure a limit for an appliance metric:

Log in to the SP leader appliance’s CLI using the administrator user name and password.
To configure the limit, enter / services sp device edit appliance_name metrics metric_label limit set
limit appliance_name = the name of the appliance whose metric limit you want to configure metric_label
= the label for the metric whose limit you want to configure limit = the number at which you want to set the
limit for the metric For a list of the metric labels, see Arbor Networks SP and TMS Advanced Configuration
Guide.
To display the configured limit, enter / services sp device edit appliance_name metrics metric_label show
Enter config write

Arbor Networks

Arbor Networks

Arbor Networks

Arbor Networks

Arbor Networks

Arbor Networks
You can verify that your SP appliances are communicating ArborFlow properly on the ArborFlow Sent and
ArborFlow Received page. ArborFlow is used:
• FS -> TRA and FS -> DS (appliance-based licensing)
• TRA->DS
• TMS -> managing TRA
It should be noted that virtual TMS appliances cannot generate ArborFlow.

Arbor Networks
You can monitor who accesses your SP appliances and the amount of time that they spend logged on to the
system on the Account Login History page.

Arbor Networks



Arbor Networks System Overview Training General System Configuration
2-1 Arbor Networks SP/TMS


Management interfaces must be configured as /30 or larger subnet (conforms to RFC 3021).



The following information will be configured for each Appliance:

Name – the configured Appliance hostname.
Description – the user-entered Appliance description.
Type – the type of SP appliance:
• Data Storage
• Traffic and Routing Analysis
• Flow Sensor – shown only for Appliance-based Licensing
• User Interface
• TMS model
IP Address – the device’s IP address.
Type the model number and license key for the Appliance in the License Key boxes (required). You must
type in the full license key number, which includes the model number (for example, CP-5500) and the
license key. If your license key has an expiration, type it as part of the model number (for example, CP-
5500-5-ex1454998000). Retrieve the license key for the Appliance from the Arbor TAC.



SSL Certificates – SSL Web server certificates keep information private while it transits between your
Web server and Web browsers. You can install SSL Web server certificates from external authorities
(such as RSA or Verisign) on the Certificates tab of the Appliance Edit page. This tab only appears if the
appliance you are configuring is a PI appliance and if you are logged on to the PI leader’s Web UI.
High Availability – Allows you to configure high-availability and failover settings.
Note that High Availability is not an option for virtual appliances as of the time of this writing.

To implement a high availability system, your Arbor Networks SP deployment must include at least two
Arbor Networks SP User Interface devices, one that is configured as the leader and the other configured as
the backup leader. Data is synchronized automatically in real-time between the Arbor Networks SP leader
device and all other Arbor Networks SP User Interface devices in the deployment. This means that when
the system fails, the device that is configured as the backup leader will assume leadership of the
deployment immediately, with minimal data loss. Up to a failover-timeout amount of data can be lost
during the time it takes for the backup leader to assume the leader role.
The system automatically synchronizes the following information between the leader and the backup
leader (and any other User Interface devices in your deployment):
• alert data
• mitigation data
• configuration and configuration history
• interface classification and interface history
• custom menus (“skins”)
• custom XML report templates
(Continued on next page)

Continue
To implement a high availability failover system, your deployment should meet the following
criteria:
• The leader should have a reasonable automatic DoS alert deletion policy configured. This limits the
amount of data that the system must back up.
• The data connection between the leader and the backup leader should be at least 100 Mbps.
Failover process
When you configure a high availability system, the backup leader receives frequent heartbeats from the
leader. If the backup leader does not receive a heartbeat from the leader for an amount of time equal to or
greater than the failover timeout, it automatically initiates the failover process. Alternatively, you can
manually initiate a failover.
When a failover occurs, the backup leader performs the following steps:
1. It removes the failed leader from the system configuration. This occurs in order to prevent the failed
leader from recovering and attempting to operate in conflict with the new leader.
2. It automatically reconfigures itself as the leader of the deployment and reconfigures all other devices to
recognize it as the new leader.
3. It restarts Arbor Networks SP services on itself and assumes operation as the leader, with all of the
previously synchronized data from the failed leader.
Note: This does not require a system reboot.
To configure high availability failover, perform the following procedures:
1. Install the appropriate User Interface devices.
You must install the following devices and add them to your deployment:
• a leader User Interface device
• a non-leader User Interface device (to serve as the backup leader)
Failover Timer
Type the failover period in minutes in the Automated Failover Timeout box. This is the amount of time the
backup leader will wait after losing contact with the leader to become the leader. Type a number that is
high enough that temporary network issues will not cause a failover.
If you leave it blank, automatic failover is disabled and you must failover manually using the services
sp backup failover activate CLI command on the backup leader.

You can configure HTTPS access rules for a User Interface appliance on the appliance itself or on its CP
leader. To configure HTTPS access rules on a PI appliance, click the HTTPS Access Rules tab and do
one of the following:
Type the CIDR blocks from which you want to allow HTTPS access.
Click Edit CIDRs, and then use the CIDR Wizard to enter the CIDR blocks from which you want
to allow HTTPS access.
(Optional) Click Load Local Rules if you want to upload the local HTTPS access rules that are currently
configured for the appliance.
Note: You can load local rules once. Arbor Networks SP removes this button after you save and
commit the local rules.
You can configure other types of access rules locally on each individual appliance.


• Name - the name of your network.

• Backbone ASNs - all the ASNs that make up the network being monitored. ASNs might consist of
public ASNs, private ASNs, and/or confederated ASNs. Separate multiple numbers with spaces or
commas.
The local address space is used for two things:
1) When using the auto-configuration hueristics, it is used to supplement the BGP routing table to help
identify mixed and backbone interfaces in cases where the BGP information is inconsistent (e.g. due to
asymmetric routing) or incomplete.
2) It is used for BGP hijack alert detection, to help identify routes that should belong to the monitored
network but are seen as announced from other networks.

• Local Address Space Prefixes – a list of the local aggregates that are advertised for the ASNs noted
above. All prefixes should be entered in CIDR notation (i.e., 1.1.1.0/24) with one prefix per line
• Local Address Space Holes - local hole prefixes in CIDR notation, one CIDR block per line. Address
space holes describe parts of your local aggregates that might still be seen advertised from BGP
external peers, for example if you have multi-homed customers. This will prevent Arbor Networks SP
from triggering router hijacking alerts when it sees those prefix announcements through BGP.
The network address space can be automatically learned via an Internet Routing Registry (IRR) query for
the configured network AS, but only through the CLI command / services sp model
address_space auto. The IRR server address is set by default, but can be overridden by the
following command: / services sp auto_config irr

Multicast traffic is sent from one source address a shared destination address, called a multicast address.
The multicast address is an identifier for a group of hosts called a multicast group. In IPv4, these
addresses range from 224.0.0.0 to 239.255.255.255 (224.0.0.0/4). Multicast traffic can be beneficial
because uses less bandwidth than multiple unicast streams when identical traffic is sent to many hosts.
If you use multicast traffic, you can enable Arbor Networks SP to count incoming multicast traffic through
an internal object (router, interface, managed object). By default, this feature is disabled in Arbor
Networks SP and treated as dropped traffic.

You can allocate a portion of your unused IP space to Dark IP space. Arbor Networks SP considers any
traffic that it sees as destined toward this space as malicious traffic. This includes hosts that might perform
host and port scans that are directed toward this Dark IP space. A significant increase in Dark IP traffic
could indicate new malware, worm, or other threats propagating across the network. In order for Arbor
Networks SP to detect the Dark IP address space that is being used, you must enable Dark IP detection and
configure the destination filter (the source filter is optional).



The Configure Routers page displays any configured routers or devices that have been added to the
system configuration. After you’ve added a router and saved it’s configuration, it will appear on this page
in a summary table and also on the associated Name row on the Router Status page.
Name – displays the configured name and description for that router.
Appliance – displays the name of the device to which the router is sending flow data, or unassigned if a
device has not been associated with the router.
SNMP IP – displays the SNMP Export IP if SNMP is configured, otherwise it displays "Not Configured."
BGP – displays the BGP Session IP if BGP is configured, otherwise it displays "Not Configured."
Flow Export IP – displays the NetFlow/cflowd Export IP only if this router’s device type is Flow and the
Export IP is configured, otherwise it displays "Not Configured."
Flow Sampling – displays the configured flow sampling rate for the router.
Note: Router must be configured for same flow sampling rate.
The Appliance list allows you to filter by the managing appliance. You can select All or a specific
appliance.
The following information will be configured for each router:

Name – the configured router’s hostname (recommended).
Description – the user-entered router description.
Tag – (optional) Multiple tags can be assigned to a router. They can help you categorize and search for
routers in your deployment.
Managing Appliance – the SP device that is managing this router.

On the Configure Routers page and the Router Status page, the search functionality was enhanced in
Arbor Networks SP 6.0. To search on the either page, you can use any of the following:
• the Search box
• the Appliance list
• the Core, Edge, or Unset router type filters (flexible licensing only)

Router Type – (Flexible licensing only) Click Core or Edge to assign the router type. If you are not ready
to assign the router type, click Unset. For example, you might click Unset when you are pre-staging the
router.

Poll low capacity routers – Select if your router does not support sending high capacity interface
counters using SNMP version 1. Low capacity counters can wrap quickly on high-speed interfaces with
significant traffic. This can cause Arbor Networks SP to incorrectly display data on the System Tuning
page.
Use SNMP GETNEXT (instead of GETBULK) – Select if your router does not correctly support the
SNMP GETBULK operation for efficiently retrieving large amounts of data using SNMP version 2c or 3.

The Secondary BGP session capability was added at Arbor Networks SP 5.6.

Additional SP/TMS BGP Session Information:

• Offramp announcements of IPv6 and/or IPv4 prefixes can be performed over the Primary or Secondary
sessions (if necessary to use the Secondary).
• There is no requirement to split IPv4 and IPv6 route announcements over 2 different sessions (Primary
to an IPv4 neighbor and Secondary to an IPv6 neighbor) if they are announced to the same target router.
- Only use case would be mitigation fate sharing separation for IPv4 and IPv6 BGP sessions.
• If advertising the offramp from the TMS using the Secondary session profile, click the “Inhibit SP
Peering” checkbox so that only the TMS establishes a BGP session with the target router for offramp
announcements.

Arbor recommends that you configure each CP appliance as an iBGP route reflector client with each BGP
router. If Arbor Networks SP is not configured as a route reflector client, then it loses some of the internal
routing information and might have difficulty classifying some interfaces.
To configure router BGP settings:
Select the BGP tab.
If you do not want to peer with this router, select a different router on the same SP appliance with which
you want to share a BGP routing table by selecting the Shared option, and then pick from the list of
routers. This allows the other router’s routing table to match flows from the router that you are
configuring.
Type the remote IP address that you want SP to use to create a BGP peering session with this router in the
BGP Session IP box.
Type the ASN of the router in the Remote BGP AS Number box.
Type the ASN that you want SP to use to establish a peering session with the router in the Local AS
Number box.
Note: By default, SP uses the backbone ASN as the local ASN. Arbor recommends that you use the
router’s ASN here so that SP is the iBGP peer.

Continue
Type the secret that SP uses for BGP peering between the SP appliance and the BGP routers in the MD5
Secret box. You can type up to 80 alpha-numeric characters, except for a slash (/).
Note: Use the default router option if you deploy SP to monitor multiple routers that have the same or
similar routing table or if you want to use a central route reflector deployment model. This option allows
multiple routers to share a single routing table. The default router option points to the router that has the
BGP session configured. The router set as the default router must also be monitored from the same SP
appliance. BGP routes are not shared between appliances.

To configure a router’s capabilities, select appropriate check boxes:

Monitor Routes – monitor IPv4 routes through BGP.
4 byte ASN – the router supports 4 byte ASNs.
BGP-VPN – monitor VPNs through BGP information.
Flow Specification – enable traffic mitigation through FlowSpec.
IPv6 –the router supports IPv6 BGP routes.
Announce IPv4 Mitigation Routes – enable IPv4 traffic mitigation through BGP offramping or
blackhole routes.
Announce IPv6 Mitigation Routes – enable IPv6 traffic mitigation through BGP offramping or
blackhole routes.

Router ID box: (Secondary BGP only) Type an IP address that will be used by SP in the secondary BGP
session to differentiate it from the primary BGP session.
Note: This setting is usually not required. It is only required if the secondary BGP session
needs to use the same IP address that is used for the primary BGP session.
Inhibit SP Peering check box: (Secondary BGP only) Select if you want to prevent SP from peering with
this router. The router will still be used in TMS mitigations when a TMS appliance peers with this
router.

Netflow information can be exported unsampled (1:1) or sampled (1:x)

Arbor Networks SP reports statistical data over time so sampling does not affect accuracy
Use Embedded Sampling Rate – This removes the need to assign the sample rate for some routers
manually in the SP configuration. It does NOT work with NetFlow v9. Traffic will be stored and reported
on correctly, even if the router adjusts the flow sample rates automatically.

Select an algorithm from the Fallback Algorithm list to classify interfaces during auto-configuration that
either report no traffic or have no associated BGP information.
You can select one of the following fallback algorithms:
• Internal (the default) to classify interfaces as internal.
• External to classify interfaces as external.
• Use_bgp_and_local to classify each observed flow, based on learned BGP information and the
configured IP address space.
Select the Reflected Routers May Be External check box if you use the default router option and if you
want the system to auto-classify the interfaces on this router as external.
Important: Users usually configure these settings for lab trials or deployment within the backbone
core or aggregation edge. The auto-configuration rules for this router allow Arbor Networks SP to
treat an internal router as a BGP backbone edge router.

Select the SNMP Scaling check box to allow the system to adjust the reported traffic differences that it
sees between traffic flow information and SNMP reported traffic levels.
Select the TCP Flags Missing check box if you do not want the system to use TCP flag information from
flows coming from this router.
Note: Select this check box if you use Cisco Catalyst 6500 and 7600 series routers. Otherwise, Arbor
Networks SP may generate false TCP flag-based alerts due to the missing TCP flags.
Enable Dynamic Subscriber Interface Handling - New to SP 7.0, this setting can reduce the number of
interfaces that Arbor Networks SP tracks and for which it polls SNMP counters from the router.
Consequently, it can improve Arbor Networks SP scale because the untracked interfaces do not count
against the monitored interface limit of the appliance. It can also avoid possible performance problems on
the router that would be caused by frequent polling of large numbers of interfaces. This is particularly
useful on large customer aggregation routers. This can be effectively combined with the Track by SNMP
Description interface classification Action setting (covered later)







Q: Can router reassignment work in appliance mode or just with flex license? A: It will work with either


Some commonly asked questions (answers in italics):

1. Is there a way to cancel router reassignment? No you would need to convert back.
2. What if the destination appliance is not available? The reassignment process will fail. If the appliance
comes up later, retry the reassignment then. If the destination node never returns, the reassignment will
fail and a reversion would need to be done in the CLI. ATAC can help with this.
3. I did one router move in a previous version then upgraded. Will it take into account the previous router
move? Yes and original move will still be remembered.




Option 1 – Arbor SP configured as an iBGP route reflector client of each router being monitored
Arbor Networks SP receives routes for a monitored router via iBGP peering with route reflection directly
from the monitored router. For data accuracy, this method is always preferred since it will supply Arbor
Networks SP with both the best external routes directly learned by the router and also best routes learned
indirectly from other network routers. The monitored router will supply Arbor Networks SP with all BGP-
visible routes that the router has selected as best routes for its own forwarding table. This approach will
require one BGP session between each router being monitored and the Arbor Networks device that is
monitoring that router.
Option 2 – Arbor SP configured as an iBGP route reflector client of one or more routers and sharing
this information between monitored routers
Arbor Networks SP receives routes for a monitored router via standard iBGP peering directly from the
monitored router. The monitored router is not doing route reflection. Standard non-reflected iBGP
specifies that only routes learned externally by the peering router are advertised by that router.
Arbor Networks SP thereby learns only those routes that the monitored router learns from external
peering. Although Reflected iBGP (Method 1) is more accurate, this method may be nearly as good when
the monitored router uses only externally learned BGP routes for its forwarding table.

Continue
A monitored router is typically suitable for this method when it receives an entire Internet routing table
from external peering, which it will then normally prefer for packet forwarding. Also suitable are routers
in network architectures that ensure a router only receives traffic when it has routes to directly forward
that traffic externally. This is NOT a good method when a router receives only a partial external Internet
routing table and also receives significant traffic that is forwarded according to iBGP learned routes, since
it doesn’t share those routes with Arbor Networks SP. Arbor Networks SP will thus fail to properly
analyze and categorize traffic that is exchanged with external networks on other routers.
This method also requires one BGP session between each router being monitored and the Arbor Networks
device that is monitoring it.
Arbor Networks SP receives routes for two or more monitored routers via peering with an iBGP route
reflector that has routing information from the monitored routers. If the monitored routers are in the same
iBGP domain, the Arbor Networks SP device can be configured with the route reflector as a “default
router” for the monitored routers. BGP peering from the Arbor Networks SP device is set up for one of the
routers being monitored and the other routers monitored on that device can share this data. Routing data is
not shared between Arbor Networks SP devices so each Arbor Networks SP device in the network will
require at least one peering session with a route reflector.
For large networks where there are a significant number of routers being monitored, this method is often
preferential as it reduces the overall number of BGP sessions required.
Although the data accuracy using this method is less optimal than using individual reflected peering
(method 1), it can be very accurate when the number of peer ASNs contributing to the routing table is
relatively low. This method is very tolerant of routes that exist only on one or some monitored routers in
an iBGP mesh, and thus is usually superior in both data accuracy and reliability over standard iBGP
(method 2).
When two or more routes exist to the same destination prefix, route reflectors do route selection between
those routes. When this happens, Arbor Networks SP will bin data incorrectly for traffic that goes down
the path that was not chosen. Nonetheless, accuracy is quite good when all of the monitored routers using
a reflector are topologically close enough that redundant routes have nearly identical attributes, when
there is a low number of peer ASNs represented, or when network design eliminates most redundancies.
Configuration of the Arbor Networks system to use a route reflector can be confusing. If a default router is
not a monitored router itself, the peering session might be configured in Arbor Networks SP as if it was a
session with one of the monitored routers. In this case, the router will be configured as getting Netflow
from one IP address (the router itself) and it will be configured as BGP peering with another IP address
(the route reflector). When this is done, the Netflow being received from one router will be compared
against the BGP received from the route reflector. The configuration is done this way to reduce the
number of configured routers on the system but does not change any performance considerations.

Configuring a router so that a Arbor Networks SP appliance peers with it as a route reflection client does
not require that route reflection be enabled for any other peering session on that router. Existing BGP
peering with other routers can remain unaffected. All significant routing vendors support route reflection
configuration on a per-peer basis by default.
• Configuring Arbor Networks SP as a route reflection client of any router does not require any
configuration of routing loop prevention mechanisms. Arbor Networks SP never redistributes received
BGP routes, so it never causes a route reflection loop. Network engineers are welcome to configure a
reflector cluster identifier if they so choose, as it won’t affect Arbor Networks SP. If the network has
defined a common “never re-reflect” cluster-id, that is an appropriate choice. Some network engineers
use the Arbor Networks SP leader IP address as a self-documenting cluster-id.
• Configuring Arbor Networks SP as a route reflection client of a router will not increase the routing table
memory needed by that router, nor will it contribute more than trivially to routing update CPU load.
Concerns about both of these originate in older router behaviors in clusters of route reflectors with
dozens or hundreds of reflector clients. A Arbor Networks SP appliance does not reflect or redistribute
any routes, so peering with it as a route reflector client does not impact route memory usage at all
compared to non-reflector peering. Also, the CPU impact is the same for routes downloaded via reflector
and non-reflector peering except that the greater number of routes exported from a reflector will
maintain the routing update CPU load for slightly longer periods of time.


You can connect Arbor Networks SP to your NTP servers so that Arbor Networks SP synchronizes its time
to your NTP servers. This is important for data consistency. Prior to Arbor Networks SP 5.8, only a
primary and secondary could be configured. Now more than 2 NTP servers can be configured for
redundancy.
Arbor Networks SP requires DNS servers so that it can look up host names for individual host addresses
that appear in DoS alerts or in flow queries. Also, there are additional uses for DNS servers. For example,
if a DNS server is configured, Arbor Networks SP can replace any IP address from a system file’s copy
command with a host name.
DNS and NTP servers configured on this page are global settings. That is, they apply to all appliances in
the deployment. It is also possible to configure local DNS and NTP server to individual appliance but that
must be done directly through the appliance’s CLI. Local configuration is only needed if individual
appliances must use different DNS or NTP servers.

To configure SMTP servers, type the IP address of the SMTP server used to email notifications in the
SMTP Server box. Type the user name that Arbor Networks SP uses to authenticate to the SMTP server
in the SMTP Server Username box. If required, type the password that Arbor Networks SP uses to
authenticate with the SMTP server in the SMTP Server Password boxand SMTP Server Confirm
Password box. Enter the address that appears in the From field in the email notifications in the SMTP
From Address box.
Type the URL of the support link to include with notifications in the Alert URL box. then type the text
that you want to include in the footer of each email notification in the Email Footer box (for example,
instructions, contact information, and marketing messages).

To configure HTTP Proxy, select the Enable HTTP Proxy check box and type the IP address of the
internal proxy in the Proxy Server box. Optionally type the port on which the proxy listens in the Proxy
Port box. If you leave this box blank, the default setting of port 1080 is used. Select the Authentication
Method that you want to use. If you select Basic Authentication or Digest Authentication, then you
must also specify the Proxy Username and Proxy Password that are required to access the proxy server.
Select Use configured IP address of egress interface as source of packet instead of appliance’s address.
By default, the source IP address is the configured IP address of the appliance. For example, this option is
useful in the following case:
• An appliance’s configured IP address is from a non-routed private space.
• Access to external Arbor services is through a second interface that has a publicly routed IP address.

You can create groups to which Arbor Networks SP sends system notifications. Arbor Networks SP can
send notifications by email and SNMP traps or by syslog events to remote servers. These notifications
include DoS alert, BGP trap, mitigation event, system event (such as a disk failure), and report
information.
You can create a default notification group to receive all system notifications, and you can define unique
groups to receive specific DoS alerts and reports, but not mitigation information. (Mitigation notifications
are only sent to the default notification group).
After you create a group, you can designate it as the default group, create rules for DoS alerts, or assign
that group to receive emailed reports from Arbor Networks SP.

The Global Notification Settings page (Administration > Notification > Global Settings) allows you to
configure the Default Notification Groups and Flow Down Timeout vavueSNMP information that Arbor
Networks SP uses to send alert notifications.
About the SMTP settings
You must configure the SMTP settings so the system can send you alert notifications by email. Arbor
Networks SP supports password authenticated SMTP servers. You can optionally enter a user name and
password to authenticate with a password-protected SMTP server.
About setting the alert URL
When you set the Alert URL to contact your support system, Arbor Networks SP defines two variables for
reference with your help system. The system replaces %name with the customer's name and replaces
%id with the ID number of the originating alert.



You can configure notification rules for specific resources and managed objects. Arbor Networks SP sends
alerts using notification groups that contain sets of email addresses (for XML and email alerts) or IP
addresses (for SNMP and syslog alerts).
Users can create a notification rule for a Managed Services DDoS customer. DDoS alerts for that
customer can then be directed to a pager, SNMP trap receiver, or syslog server to be processed in a timely
manner, giving the MS customer prioritized service.
For example, if Arbor Networks SP detects a DoS alert applied to 10.0.0.1/32, and you create a rule with
the resource CIDR block 10.0.0.0/16, then Arbor Networks SP sends a notification message using the
mechanism and destination addresses specified within the rule (if it also matches the specified importance
level).
Importance – limits the alerts that will be sent to the configured level or higher

You can configure Arbor Networks SP to alert you when one or more non-TMS appliances experience
operational issues. These alerts help you to identify issues and their causes as issues occur so you can
address them more quickly and efficiently. To prevent spam, after Arbor Networks SP ends an alert type, it
does not trigger another alert until 30 minutes after the last alert of that type ended.
System alerts are enabled by default so that you can view them in the Web UI. However, system alert
notifications are disabled by default. If you want to receive system alert notifications, you can enable
them in the CLI:
1. In the CLI, type / services sp alerts system_errors ?, and then press enter to see the alert types for
which you can enable notifications.
2. Type show, and then press enter to see the current configuration for each type of alert notification.
3. Type / services sp alerts system errors alert_type notifications enable, and then press enter.
alert_type = the system alert type that you want to enable
4. Type config write, and then press enter.
5. Configure the thresholds for system alerts and the default notification group in the Web UI.
You can also disable notifications if you find that you are receiving too many for a specific alert type.

The Support Email that appears as the contact link at the bottom of all Web user interface pages.
The Login Timeout Period which, when it expires, will make users log on again to access the Web user
interface.
The Status Page Update Period that determines the frequency with which the status pages are
automatically re-loaded.
• If you are on any page that auto-refreshes, you will not be logged out since the refresh counts as a page
load for the user and resets the idle timer.
The Ticketing System URL that will be used to integrate with your Web-based trouble ticket system.


Account groups specify users access to specific managed objects’ traffic data and the ability to use
specific Arbor Networks SP features. Each account group is associated with a set of capabilities that are
inherited by the users assigned to that group. You can use pre-configured account groups or create custom
account groups. You can view all configured account groups and create custom account groups on the
Configure Account Groups page.
Capability groups allow you to flexibly control users’ access to Arbor Networks SP features. You must
assign a capability group to any account group that you create. All users in the account group then inherit
the capabilities assigned to the account group.
Configuring authentication consists of a number of steps. First, you must specify the authentication
method. If you do not set a method, the system defaults to local authentication. Local authentication does
not require additional settings. You can also set more than one method. If you specify more than one, enter
them in a list separated with spaces. Arbor Networks SP will try them in the order you list them when
authenticating users.
For example: If you wanted the system to try TACACS+, then Radius before trying local authentication,
you would enter: tacacs, radius, local.

Continue
Next, you can specify if you want to enable Exclusive Login. This feature specifies that you want only
the first working method tried, and that if the method is working (i.e., the RADIUS server responds), but
the user cannot authenticate to it, then the user login is denied without trying any other method in the
list. If this feature is not enabled, then a user login attempt that fails one authentication method will be
submitted to the next method in the list, and the login attempt will be denied only if the user is unable to
authenticate via any listed method.
For TACACS+ users, you can configure Arbor Networks SP to display a message to notify users that
their passwords will soon expire. Arbor Networks SP allows for an integrated TACACS+ password
change, and TACACS+ users can change their password in the My Account window. Use the My
Account button in the upper-right corner of the screen to open the My Account window.

Capability groups allow you to control users’ access to Arbor Networks SP features. You must assign a capability
group to any account group that you create. All users in the account group then inherit the capabilities assigned to
the account group.
System-defined capability groups:
admin – This group is for administrators of the system who have full read and write privileges to all pages.
none – Users assigned to this group have no privileges. A user in this group is effectively disabled.
operator – Users assigned to this group can configure most settings in the Web UI. However, they cannot edit
account information in the CLI or Web UI or configure basic system-level configuration in the CLI (such as ArbOS
network interfaces, IP access rules, ARP configuration, routing configuration, and system time).
user – Users assigned to this group have basic privileges and can view all reports. They cannot make configuration
changes, except to their own account information. Copy this group to create new user groups.
Managed Services User and Admin – ms_admin – ms_user
Managed Services VPN User and Admin – ms_vpn_admin – ms_vpn_user
TMS read only ms_user – tms_read_only_ms_user – Non-administrative capability group for managed services
accounts. Can view TMS mitigations but cannot modify them.
TMS read only user – tms_read_only_user – User capability group. Can view data but can't change configuration
settings. Can view TMS mitigations but cannot modify them. Copy this group to create new user groups.



The organization of capabilities into categories was introduced in Arbor Networks SP release 5.6.



Managed Services Group - If you indicate that an account group is for managed services users, then Arbor
Networks SP also limits users’ access to certain data in the UI, such as router and interface details for
DoS alerts as well as routing data and other information about the network’s routers and interfaces.
A managed services user is a user who is a customer of the network provider and who should only have
access to data and configuration about their managed object and it's children. Managed services users
degrades the capabilities of a system_ms_admin or system_ms_user capability group, or a custom group
that contains certain capability tokens from those groups (i.e. to remove sp_intelligent_filt). Managed
services users also have the managed services checkbox checked in their account group, which limits their
access. Managed services users get a different default menu in the UI, as well as a different level of
access to various system reports. All of this is triggered off of the "Managed Services" checkbox.
Device - Select Global for all appliances. Select an individual appliance to limit groups access to a
specific PI Appliance



New User Configuration:

Username – A unique name; must be a minimum of 1 and a maximum of 31 letters/numbers combination.
Real Name – The given name of this user.
Email Address – The e-mail address for this user.
New Password – Passwords must meet the following criteria:
Contain at least 7 characters and not exceed the maximum length, if an administrator has configured a maximum
length.
• Can include special characters, spaces, and quotation marks
• Cannot be all digits
• Cannot be all uppercase letters
• Cannot be all lowercase letters
• Cannot be only letters followed by only digits (for example, abcd123)
• Cannot be only digits followed by only letters (for example, 123abcd)
• Cannot consist of alternating letter-digit combinations (for example, 1a3A4c1 or a2B4c1d)
Administrators can configure the minimum and maximum password length to enforce more stringent password
requirements for user accounts.

Continue
Appliance – If you assign a user name to a specific appliance (local) and assign another user with the
same user name to all appliances (global), then the appliance-specific, local user has access to that
appliance and the global user does not. Global users only have access to an appliance when there is no
matching local user name for that appliance.
Account Group (drop-down menu) – The account group for this user.
Timezone (drop-down menu) – The time zone for this user.
UI Menu (drop-down menu) (optional) – A customized set of menus for this user’s Web UI.


At Arbor Networks SP 7.0, AIF Standard Feed replaced a similar service called the Arbor Threat Feed
(ATF).

When you enable BGP Routeviews reporting, you can directly query BGP routing tables from various
large, global ISPs.
Having a view into the routing tables of other large providers allows you to see how your network is
viewed from a global perspective. This enables you to investigate routing issues that affect network
traffic.
Note: You do not need to share your network’s routing information in order to see this information.
However, if you are interested in sharing your anonymized data with Arbor for use in this feature,
contact your Arbor Networks CE

Arbor Networks SP gathers and stores a rich set of attack and traffic statistics in each network on which it
is deployed. It is valuable to gather statistics about Internet trends from different worldwide deployments
so that you can analyze global threats and traffic patterns. Arbor Networks SP allows you to share these
statistics while protecting your and others’ privacy, using algorithms that anonymizes your data.
When you enable Internet Trends sharing, the following types of data are shared with Arbor and other
participating Arbor Networks SP customers:
• a breakdown of the Arbor Networks SP deployment size
• a list of all medium and high severity DDoS alerts during the last 24 hours
Note: Arbor Networks SP replaces the first two octets of specific customer IP addresses, anonymizes
the destination of incoming attacks, and anonymizes the source of outgoing attacks.
• top TCP, UDP, protocol, and packet lengths
• overall network incoming and outgoing traffic
• TMS mitigation statistics



System Administrator Training Interface Classification


Arbor Networks SP Essentials Training Interface Classification

The main interface classification types are:

External - interface is connected to a peer external to your network.
Internal - the interface only connects to local hosts within your network. In other words, after a packet
is output on this interface, it can never leave your network. Likewise, packets input on this interface
should only have sources within your network.
Backbone - the interface carries a mix of internal and external traffic. Packets passing through this
interface might ultimately be destined for internal interfaces (and hosts local to your network), or they
might ultimately be destined for hosts external to your network, in which case they will use this
interface to reach an external peering interface for their destination. Backbone interfaces cannot be
externally facing.
While currently there is no distinction in functionality between Internal and Backbone, they are
intended to represent different interface characteristics. A backbone interface connects to the network
backbone, meaning that traffic passed over a backbone interface could still leave the network via
another interface. Internal interfaces indicate where traffic is leaving the network backbone -- i.e.
traffic passed over an internal interface will never leave the network after that point.

There is also a mixed classification where the interface directly connects to an external peer and also
passes traffic to/from hosts internal to your network. A mixed interface might be internal or external
facing. This is a very rare case, as, for example, if you have an external peering interface at an
exchange that includes both external BGP peers (upstream/transit connections) and multi-homed
networks that are also your customers.
Interfaces can also be classified as ignore where traffic on the interface is ignored.
Both mixed and ignore must be configured; the system will not auto-classify them.

The current network boundary (all interfaces classified as external) is shown in the Boundary tab of the
Configure Network page.


SP combines real-time BGP, NetFlow, and SNMP data to provide detailed information about the traffic
traversing your network. To properly track and classify traffic, SP initially uses a feature called auto-
classification. Auto-classification builds a real-time, detailed model of per-router and interface
behavior based upon the In/Out traffic it observes. You can refine this model to build an accurate,
useful, and complete representation of your network.
The SP system uses these models to accurately classify flows and distinguish between different types
of traffic (such as backbone, in, and out). These models further allow SP to aggregate and correlate
information across potentially hundreds of routers and tens of thousands of interfaces.
Auto-classification combines user-configured information with real-time iBGP, SNMP, and flow
information to infer each monitored router's forwarding behavior on a per-interface basis. During auto-
classification, the SP device applies a range of heuristics to each flow. These heuristics classify the
interface and set associated peer ASNs (if any).

Continue
You can always view the current network model by examining the Interface configuration version now
page (Administration > Monitoring > Auto-Configuration > Current). For each classified interface, this
page lists both the rule that was used to classify it along with any ASN(s) for external interfaces.
The heuristics used by auto-classification to classify interfaces specify what the resulting interface type
should be for each flow, based on learned BGP and local address space information. Based on the
totality of flows observed across an interface during auto-classification, the system will determine the
final classification type of the interface.
The system will not auto-classify interfaces as mixed or none; they must be manually configured
(under Administration > Monitoring > Interfaces).

Auto-configuration runs every 4 hours at 2:50 offset to make sure that interfaces remain classified
according to current traffic. However these 4-hour classifications have timestamps on a 3:00 offset, not
2:50. The auto-classification run does happen with a 2:50 offset, and then the database update from
that run happens at the next :15 transition in an attempt to align classification changes with traffic data
collection periods (to some extent).
An additional process that runs every 15 minutes that checks for new interfaces. If any are discovered,
auto-configuration is run out of schedule. This is intended to minimize lost data when active links are
moved between interfaces.

As of SP 5.8, each SP 5500 appliance can discover 20,000 router interfaces but only monitor 10,000.
These limits are 40,000 and 20,000 respectively if the appliance serial number begins with AZLH. FS
appliances are limited to 10,000 monitored interfaces.
At SP release 6.0 and later, the interface limits remain the same for an SP 5500 appliance. The newer
SP 6000 appliance limits are 40,000 interfaces total and 20,000 monitored.

A full routing table from each router is needed if the system-defined auto-classification heuristics are
used (not recommended by Arbor). Otherwise you may get incorrect results because SP will have only
a partial routing table. The typical way to do this is to set up the SP device as a route reflector client of
the router.

With this menu, you can see why Peer traffic changes, why SP reports traffic for a given peer or
external customer, and you can verify which interfaces are identified as peering with a particular peer
AS, currently or in the past.



The Auto-configuration Rules page (Administration > Monitoring > Auto-Configuration Rules)
allows you to create, edit, and delete custom classification rules for router interfaces on your network.
SP normally classifies each interface according to a preset list of rules. By adding your own custom
rules you can classify interfaces whose descriptions match a specified regular expression. Optionally,
for mixed and external interfaces, one or more peer ASNs can also be assigned to the interface. If an
interface has a description that matches the regular expression then it is assigned the specified
classification (internal, external, backbone, etc.) when auto-classification runs

Routers - To select interfaces on all routers, leave the field blank. To select interfaces only on specific
routers, click Select Routers, and use the Router Selection Wizard to choose which routers to match
interfaces.
Interface Subnet Mask – This setting restricts the rule to matching SNMPfields only on interfaces
that have an IP address which falls the specified subnet.
SNMP Field for Interface Match - Select the SNMP field(s) to use for the interface match. SP can
match against the following SNMP fields:
• Description - the interface description (SNMP OID ifAlias)
• Name - the interface name (SNMP OID ifDescr)
• Description or Name - the interface description (SNMP OID ifAlias) or the interface name (SNMP
OID ifDescr)
Regular Expression for Interface Match - Enter a regular expression to use to match against the
selected SNMP field(s). When the regular expression matches the selected SNMP field(s) of an
interface, SP auto-configures the interface. If you do not enter a regular expression, SP matches and
auto-configures all the interfaces of the selected router(s).

Use System Auto-Configuration Heuristics - Select the check box to enable the system to run the
built-in system defined heuristics on traffic that is seen on an interface. System heuristics are disabled
by default; you can't modify them, you can only enable or disable whether they are used by the rule. If
you select this check box, then this disables the Set Type and Set ASNs check boxes. If used, only one
rule should have it enabled and it should be the last rule in the sequence (largest Rule Precedence
value).
Set Type – Check the box to enable type. Then, select a type: external, internal, backbone, mixed, or
ignore. If the Set Type action is enabled and is set to Backbone, Internal, or Ignore, then SP clears
the ASNs setting for the interface and ignores the Set ASNs action. Using this field and the Set ASNs
field allows you to manually override the system defined heuristics.
Set ASNs – Check the box to enable specifying ASNs. Enter the ASNs you want to associate with this
rule. If selected but no ASNs are specified, then the ASN setting for the interface is cleared. Using this
field and the Set type field allows you to manually override the system defined heuristics.

SNMP Field for Interface Tracking – Select whether to track interfaces by their name or description.
Name is selected by default. Select Description to track dynamic interfaces by their SNMP description
instead of their SNMP name. If the SNMP index or SNMP name of the interfaces might change over
time in your environment, then track the interfaces by their SNMP description. The IDs that are used to
track the interfaces will then change only if the SNMP description changes. This setting was added in
PS 7.0.
You should select Description when the routers associated with the rule are Broadband Network
Gateway (BNG) routers. If you also select Enable Dynamic Subscriber Interface Handling when
you configure the BNG router, then SP discovers and tracks only the interfaces that match an
auto-configuration rule. For example, you can configure SP so that it discovers business interfaces, but
does not discover consumer interfaces. This prevents interfaces that are not of interest to you to be
counted against your total interfaces licensing limit.



A manually classified interface configuration is tied to the configured index value. Some routers
reassign interface indexes dynamically, such as on a reload, which is why manually configuring
interfaces is not recommended.



System Administrator Training Managed Object Configuration



Managed object children

Managed object children allow you to group managed objects hierarchically and create scoped managed
objects. Internet Service Providers (ISPs) can use child managed objects to increase revenue and offer traffic
visibility, detection, and mitigation services to their customers.


Managed objects can be defined by many methods ranging from static CIDR blocks to dynamic
BGP expressions.


A more detailed discussion of managed object match types is found in a subsequent courses of the SP/TMS
curriculum, but some example uses for the above list include:
AS Path Reg. Ex: track a specific AS number or series of numbers in an AS-Path
CIDR Blocks: perhaps the most commonly used match criteria; looks for traffic matching a subset of IPv4 or
IPv6 addresses
Communities: track traffic belonging to a specific BGP Community string using a regular expression (ie,
245:30 looks for ASN 245 with a local significance of 30)
Flow Filter: use an FCAP expression to define a specific source or destination address or port or protocol (or
all of the above)
Peer ASNs: specify one or more peer AS numbers of traffic on which to report

Advanced Boolean Matching - A matching expression including the other match types and the operators:
and, or, not. Note that advanced boolean matches cannot include SubASNs and CIDR blocks entries cannot be
parented by a clause that contains either the AND or NOT operator. For more information on the FCAP
language used for advanced boolean matches, see the "The FCAP Language" appendix in the User Guide.
ASPath Regular Expression - A Cisco style, string based AS regular expression
CIDR Blocks - One or more CIDR block prefixes of the form A.B.C.D/N. Use spaces to separate multiple
prefixes. All CIDRs listed will be treated in aggregate for traffic reporting and DoS alert detection.
CIDR Groups - One or more CIDR block prefixes (of the form A.B.C.D/N) followed by the name you would
like to assign to this group and a semicolon. Use spaces (no commas) to separate multiple prefixes. Each line
should contain one or more prefixes and one group name. (This match type is not available to scoped view
users.) Each CIDR listed will be treated individually for DoS alert detection but all CIDRs will be treated in
aggregate for traffic reporting.
Communities – A regular expression including one or more BGP communities in the form of X:Y, where X
represents the AS number and Y represents a number of local significance to AS X. Use commas (no spaces)
to separate multiple communities. The range of each X and Y must be within 0-65535.

Interfaces – Arbor Networks SP bases this match on the defined interface boundary of the managed object.
Peer ASNs – One or more AS numbers of a peering network. These must be within the range of 1-65535 and
must be unique across all customers.
Local ASN/SubAS - The AS number of a sub or local AS on your network. These must be within the range of
1-65535 and must be unique across all customers.
Application ID - The ID number of an application. Arbor Networks SP maps application ID numbers to
names, descriptions, and ports that is in sync with the mapping on the TMS devices.
TMS Ports – The TMS port (in, out, auto). Arbor Networks SP maps the selected port to the managed object,
so traffic is into or out of the managed object. TMS ports represent a network boundary around a managed
object.
TMS VLANS - The VLANs associated with a TMS device. TMS VLANs require inline or span port TMS
deployment, not off-ramp TMS deployment.
Flow Filter - A fingerprint expression used to define which flows to match on.







Arbor Networks SP uses global network boundary to define all of the entry and exit points to the network that
it monitors. It uses a number of algorithms to determine which monitored interfaces connect to external BGP
ASNs, and it labels these interfaces as “external.” Arbor Networks SP considers in and out traffic on these
external interfaces for managed objects that use the network boundary.
Arbor Networks SP uses boundary-based counting to ensure accuracy while eliminating the double-counting
of flows. It aggregates information across multiple boundary interfaces and routers to track traffic in and out
of the network, each router, or user configured managed objects. Every object the system tracks has a
boundary on which the system counts data.
The network boundary includes all of the interfaces that connect the network to external BGP peers. This is a
system default boundary.

Customer managed objects count traffic in the same way. You can define boundary interfaces for customer
managed objects. Boundary interfaces connect the customer to the network. If you define a managed object
with a set of boundary interfaces, Arbor Networks SP counts traffic for that object across the boundary
interfaces.
If you do not define a boundary interface, the system considers the object to be a global managed object.
Therefore, it counts traffic across the network BGP border, which is defined by the interfaces that you classify
as external.
The local boundary includes all of the interfaces that connect an object to the network. You must configure
managed object boundaries.
When customers are defined with local boundary interfaces, it is possible to measure how much traffic each
customer is sending to other customers by counting along these interfaces. This provides useful information
when making backbone capacity planning decisions.

The current managed object Boundary selection mechanism was introduced in Arbor Networks 7.0.3.
Network Boundary – Uses the network boundary. No interfaces can be configured for the router boundary
nor the TMS boundary.
Interfaces can be selected in a variety of ways:
None – Uses the network boundary.
Global Customer, Ignore Rules – Uses the network boundary but can configure the Locality of the managed
object as either internal or external to the network.
Rules Only – Uses dynamic auto-configuration rules only to determine all boundary interfaces.
Interfaces & Rules – Uses dynamic auto-configuration rules and your static configurations to determine
boundary interfaces.
Note: The rules here mirror the rules configured on the master Auto-Configuration Rules page
(Administration > Monitoring > Auto-Configuration Rules). You can edit rules in either location. Only
rules that apply to this managed object are listed.

Continue
Traffic for MOs defined as Match Type ‘TMS Ports’ is counted in a similar way to “regular” MOs with
‘Manual, Advanced Boundary Interfaces”’, with the difference that since no IP addresses are specified, the
IN/OUT direction is only determined by the direction of the traffic on the interfaces.
Rule:
Traffic entering a “TMS In” port is counted as IN to the MO;
Traffic entering a “TMS Out” port is counted as OUT from the MO;
if “TMS Auto” is selected, traffic will be counted as “IN” by default.
select the TMS in ports, click TMS In Ports and the TMS Ports Selection Wizard opens. Select your filter
criteria and click Filter. Highlight the ports you want to add from the Available Choices box, and click the
down arrow. The ports appear in the Selected box. Click Select and the in ports appear in the Match Values
box.
To select the TMS out ports, click TMS Out Ports. Select your filter criteria and click Filter. Highlight the
ports you want to add from the Available Choices box, and click the down arrow. The ports appear in the
Selected box. Click Select and the out ports appear in the Match Values box.
To select the TMS auto ports, click TMS Auto Ports. Select your filter criteria and click Filter. Highlight
the ports you want to add from the Available Choices box, and click the down arrow. The auto ports appear
in the Selected box. Click Select and the auto ports appear in the Match Values box.




When using ‘Interfaces & Rules’ for a boundary, Arbor Networks SP uses dynamic auto-configuration rules
and your static configurations to determine boundary interfaces.
• Use simple when MO lives on one side of boundary and flow to/from MO likely to cross boundary only
once. The MO is simple relative to the perspective of the monitored network.
• Use advanced when MO match doesn‘t include source or destination IP, lives on both sides of boundary,
or flow to/from MO likely to cross boundary twice. The MO has a complex/advanced relationship to the
monitored network.
• Traffic for MOs defined as Match Type “Flow Filter” are required to be configured as “Manual, Advanced
Boundary Interfaces”, but any MO can be configured to use them.
Rule:
• Traffic entering Object-facing interfaces and matching the filter is counted as OUT of the MO. Traffic
leaving the interface and matching the filter is counted as IN to the MO.
• Traffic entering Backbone-facing interfaces and matching the filter is counted as IN to the MO. Traffic
leaving the interface and matching the filter is counted as OUT the MO.










While we would commonly use a match type of Peer ASN for Customer B, there are other match types that
could be used:
ASpath regex, Community, Boolean expression
• Used to monitor BGP resources that are dynamic
- Automatically adjusts matching criteria over time
- BGP customers, market segments, network regions, groups of customers, strategic ASNs, groups of
providers
- Preferred method for monitoring BGP customers when not directly monitoring customer-facing routers







You can configure high and low thresholds for either bps or pps. Every minute, Arbor Networks SP looks at
the in and out traffic for each managed object and compares it with the thresholds configured for that
managed object.
If the in or out traffic is over the configured high threshold, then the system generates a high threshold alert. If
both the in and out traffic is below the configured low threshold, then the system generates a low threshold
alert. Arbor Networks SP evaluates each threshold is independently for bps and pps.
There is no system default for generating alerts on a given managed object threshold, so you must configure
each managed object.

Managed Object Threshold-based Alerting is enabled globally by default.





VPNs (Virtual Private Networks) are network entities (subsets of your network) that you can define for use in
both traffic reporting as well as anomaly detection. Managed objects that you have designated as VPNs
appear in the Reports > VPNs menus.
• The VPN reports provide VPN-specific information. This includes a summary of all VPN traffic and a
breakdown of that traffic into useful reports that can be used in accounting, acceptable use policies, route
policy management, and market analysis. VPN type managed objects are used to track the use of VPNs in
your network space.
• VPNs are defined by a name, a match pattern, and a list of VPN sites. All traffic matching the supplied
match pattern will be analyzed and tracked as an independent network object by Arbor Networks SP. A
common use of this feature is to monitor traffic sent to or from individual VPN sites within a network.
Note: Routers must be configured with Netflow v9


VPN Routing and Forwarding (VRF) is a route table instance for connecting a set of sites to a VPN service. A
VRF contains a template of VPN Routing/Forwarding table in a PE router.
The overlapping addresses, usually resulting from usage of private IP addresses in customer networks, are one
of the major obstacles to successful deployment of peer-to-peer VPN implementation. The MPLS/VPN
technology provides an elegant solution to dilemma.
Each VPN has its own routing and forwarding table in the router, so any customer or site that belongs to a
VPN is provided access only to the set of routes contained within that table. Any PE router in the MPLS/VPN
network therefore contains a number of per-VPN routing tables and a global routing table, that is used to
reach other routers in the provider network. Effectively, a number of virtual routers are created in a single
physical router.
Route Distinguisher - the route distinguisher for this VPN in the form of the ASN, a colon, and the
distinguisher or the IP address, a colon, and the distinguisher.
Customer Sub-Interfaces - use the interface selection wizard to select the boundary interfaces for this VPN.



The Edit Boundary Interface List pop-up window allows you to enter sets of interfaces that are located at your
VPN's boundary; they are the ones on which your Arbor Networks devices will see traffic.
Another option you have is to add multiple interfaces at once by using a Cisco style, string based regular
expression that matches the interface names you want to add. For example, if you have entered "fxp*" in as
the description and click the Populate button, the system will add all interfaces whose names begin with fxp.
This is a quick way to add interfaces that is exclusive to the Web user interface.

As of Arbor Networks SP 7.5, VPN sites are automatically detected if the VPN managed object match criteria
is a route target and the sites match the configured route target setting. These auto-detected VPN sites appear
on the VPN Sites tab when you edit a VPN managed object and as child managed objects on the Configure
Managed Objects page. VPN sites that are auto-detected cannot be deleted but do not count against the
licensed MO limit. The name given to an auto-detected VPN site is by default the BGP site-of-origin (SoO)
extended community, but it can be edited.
VPN sites are manually configured by with these settings:
Name - a unique name for this site.
Description - a description of this site.
Match is either:
• CIDR Blocks - one or more CIDR block prefixes of the form A.B.C.D/N. Enter multiple CIDR blocks, as a
comma-separated list. These are the CIDR blocks in use at this VPN site.
• Extended Communities – These are the extended communities contained in BGP route advertisements
from this site.


Internet Service Providers (ISPs) can use child managed objects to increase revenue by offering more
focused traffic visibility, detection, and mitigation services to their customers.




Click the Edit Child Managed Object List button in the Children tab of the parent managed object to open
the selection wizard.
The top box labeled Available Choices is a list of all of the managed objects created in your deployment.
Choose one or more of them (using the Ctrl or Shift buttons to select multiple) and then click the downward
pointing arrow to add the managed object to the Selected box. All of the MOs listed in the Selected box are
those that will become child managed objects of the parent.
Click the Select button in the Selection Wizard screen to confirm your selection(s).


Managed object matching first matches flows to independent and parent MOs. If a flow matches a parent MO,
the flow is then compared to the match statement of each MO that is a child of that parent.
If a flow is counted for a child MO, then the flow must match both the parent MO match statement and the
child MO match statement, at the parent MO boundary interfaces.
Any flow that is counted for a child MO is also counted for the parent MO.
The match statement of a parent is used both to match flows to the parent, and also as a scoping match for all
children of that parent.




System Administrator Training Maintenance and Troubleshooting
5-1 Arbor Networks SP 7.5.1





As of Peakflow 5.8, it is possible to set a ceiling to the amount of scaling applied if the SNMP
Scaling feature is enabled and SNMP counters differ from the amount of flow being received. This
may prevent aberrant SNMP counter spikes from skewing flow counters too greatly.
To set the scaling ceiling:
/ services sp router edit router adaptive_flow snmp_scaling_max set
value
To clear the scaling ceiling:
/ services sp router edit router adaptive_flow snmp_scaling_max
clear


The System Maintenance menu provides functions to:

• restore your system from a backup
• manage deletion of alerts and reports
• maintain configurations
• configure network services

You can export, import, commit changes to, and view the history of your Arbor Networks SP
configuration from the Configuration Version page (Administration > System Maintenance > Config
Version).
You can commit the configuration changes that you have made since your last commit on the
Configuration Commit page (Administration > System Maintenance > Config Version > Commit). To
commit your changes, type a message in the Log message box, if desired. and click Commit.
You can revert changes that you have not committed on the Configuration Revert page
(Administration > System Maintenance > Config Version > Revert). When you revert changes, the
system applies the last committed configuration.
You can view and export the system configuration file on the Configuration Export page
(Administration > System Maintenance > Config Version > Export).

You can view and “rollback” to previously saved system configurations on the Configuration
History/Rollback page (Administration > System Maintenance > Config Version > History).


These settings are automatically constrained for the system-wide configuration for managed services
users. Arbor Networks SP might delete alerts that are more recent than what is specified in the Web
UI if the system-wide configuration indicates a deletion time that is less than what you specify here.
Settings followed by an asterisk (*) are overridden by the current system-wide configuration.
Note: A maximum of 2000 alerts can be deleted per hour.

You can schedule the automatic deletion of custom traffic report runs on the Schedule Auto-Deletion
of Reports page.
Note: You can also manually delete traffic reports on the View Reports page.

Each appliance can store one full backup and one incremental backup. Each time you perform a
backup, Arbor Networks SP replaces the previous backup. If you want to save multiple backups, you
can export them to a remote server.
Note: Arbor Networks SP can only restore system backups created in the same SP version that is
currently running

You can perform either a full backup or an incremental backup. When you perform a full backup,
Arbor Networks SP backs up all of the database files, configuration files, and other files necessary to
restore an SP appliance to that point in time. When you perform an incremental backup, SP backs up
only the changes that have occurred since you ran the last full backup. The advantage of an
incremental backup is that it takes less time. Both types of backups are stored in a single file, which
is a gzip compressed tarball.
Note: You must create a full backup before you can create an incremental backup.
Restore loads the latest full backup plus last incremental backup.

Backup storage
Each appliance can locally store one full backup and one incremental backup. Each time you perform
a backup, SP replaces the previous backup. If you want to save multiple backups, you can export
them to a remote server.
SP can only restore system backups created in the same SP version that is currently running.
When you export or import a backup image, the file transfer uses SCP on port 22




At Arbor Networks SP 6.0, the SP application file name format was changed from ‘Peakflow-SP-
<appliance>-X.X-YYYY-B’ to ‘Peakflow-SP-X.X-YYYY-B’.

We advise that you do not execute config write during your uninstall until the very end, as
shown above. If you do issue a config write during the uninstall, you should confirm that the process
“activate_config” is no longer running. (This can definitely be a concern in an SP system with a large
configuration, particularly one with many configured users.)
Use the / shell command to obtain a shell prompt, then use the ps command, for example ps
ax | grep activate, to determine whether any instances of activate config are still
running. If you see any running, give them some time to finish running and then check again to see if
any are running. Do not proceed with uninstalling until there are no more instances of
activate_config running.
With Peakflow 7.0, the upgrade process has been simplified such that there are no longer individual
patch files. Instead, each release is an entire dotted minor release, such as 7.0.1  7.0.2. Just
uninstall the previous revision and install the new one.

Multi-version support was implemented in Arbor Networks SP 5.5 for upgrades to newer releases.
The upgrade procedure supports a single rolling upgrade across the deployment until the migration is
complete. A deployment with Peakflow 8.0 installed supports other appliances that are running 7.0.2
or later. As with previous versions, SP/TMS only supports up to two versions installed
simultaneously in the deployment.
As of release 5.7.1, support for multi-version changed from a being a transitional migration
methodology to potentially a permanent state. You do not need to upgrade all devices to the same
version number. Depending on your circumstances, you can choose to run (a maximum of 2)
different, but multi-version compatible, versions of SP and TMS in your deployment.

Leaders, UIs, and DSs must be updated to the new version. TMS must be at the same major version
as its TRA manager.































Corporate Headquarters
76 Blanchard Road
Burlington, Massachusetts 01803
Toll Free +1 855 773 9200
T +1 781 362 4300
F +1 781 365 1749
Europe Headquarters
T +44 207 127 8147
Asia Pacific Headquarters Revised: 26 FEB 2017

T +65 68096226
www.arbornetworks.com Information presented in this document is subject to change without

notice. The contents of this publication may not be reproduced (in any
Copyright © 1999-2016 part or as a whole) without the permission of the publisher. Peakflow X
Arbor Networks, Inc. is a trademark of Arbor Networks. All other trademarks are the property
All rights reserved. of their respective owners.

II. Arbor Networks SP System Administrator Training Book

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

II. Arbor Networks SP System Administrator Training Book

Hochgeladen von

Copyright:

Verfügbare Formate

System Administrator Training System Monitoring

1-1 Arbor Networks SP

1-2 Arbor Networks SP

1-3 Arbor Networks SP

1-4 Arbor Networks SP

2-5 Arbor Networks SP

2-6 Arbor Networks SP

2-7 Arbor Networks SP

2-8 Arbor Networks SP

2-9 Arbor Networks SP

2-10 Arbor Networks SP

2-11 Arbor Networks SP

2-12 Arbor Networks SP

2-13 Arbor Networks SP

2-14 Arbor Networks SP

2-15 Arbor Networks SP

2-16 Arbor Networks SP

(Continue on next page)

2-17 Arbor Networks SP

2-18 Arbor Networks SP

2-19 Arbor Networks SP

2-20 Arbor Networks SP

2-21 Arbor Networks SP

2-22 Arbor Networks SP

2-23 Arbor Networks SP

2-24 Arbor Networks SP

To configure a limit for an appliance metric:

2-25 Arbor Networks SP

2-26 Arbor Networks SP

2-27 Arbor Networks SP

2-28 Arbor Networks SP

2-29 Arbor Networks SP

2-30 Arbor Networks SP

2-31 Arbor Networks SP

2-32 Arbor Networks SP

2-33 Arbor Networks SP

1-34 Arbor Networks SP

1-35 Arbor Networks SP

2-1 Arbor Networks SP/TMS

2-2 Arbor Networks SP/TMS

2-3 Arbor Networks SP/TMS

2-4 Arbor Networks SP/TMS

2-5 Arbor Networks SP/TMS

The following information will be configured for each Appliance:

2-6 Arbor Networks SP/TMS

2-7 Arbor Networks SP/TMS

2-8 Arbor Networks SP/TMS

2-9 Arbor Networks SP/TMS

2-10 Arbor Networks SP/TMS

2-11 Arbor Networks SP/TMS

2-12 Arbor Networks SP/TMS

2-13 Arbor Networks SP/TMS

• Name - the name of your network.

2-14 Arbor Networks SP/TMS

2-15 Arbor Networks SP/TMS

2-16 Arbor Networks SP/TMS

2-17 Arbor Networks SP/TMS

2-18 Arbor Networks SP/TMS

2-19 Arbor Networks SP/TMS

The following information will be configured for each router:

2-21 Arbor Networks SP/TMS

2-22 Arbor Networks SP/TMS

2-23 Arbor Networks SP/TMS

2-24 Arbor Networks SP/TMS