TO_TMS_EN

Arbor Technical Overview

A Guide for Peakflow SP TMSDeployment

Arbor Networks, Inc. is a leading provider of network security and management solutions for enterprise andservice provider networks, including the vast majority of the worlds Internet service providers and many of thelargest enterprise networks in use today. Arbors provennetwork security and management solutions help growand protect customer networks, businesses and brands.Through its unparalleled, privileged relationships withworldwide service providers and global network operators,Arbor provides unequalled insight into and perspective onInternet security and traffic trends via the ATLAS ActiveThreat Level Analysis System. Representing a unique collaborative effort with 230+ network operators acrossthe globe, ATLAS enables the sharing of real-time security,traffic and routing information that informs numerousbusiness decisions.

About Arbor Networks

Peakflow SP Threat Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Physical Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Surgical Mitigation Power of TMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Deployment Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Off-/On-Ramping (Diversion/Reinjection) Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Multiple Off-/On-Ramp Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

TMS Gateway Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Single-Leg Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Using Generic Routing Encapsulation Tunnels for On-Ramp Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Using Redundant Generic Routing Encapsulation Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Network Deployment Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Large Network Peering Edge Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

In-Line Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Advantages of Deploying TMS in the In-Line Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Disadvantages of Deploying TMS in the In-Line Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Hybrid Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

TMS Deployment Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Mitigation Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Countermeasure Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

DDoS Attack Detection and Surgical Mitigation Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

A Comprehensive Threat Management Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1

Arbor Technical Overview: A Guide for Peakflow SP TMS Deployment

Table of Contents

2Arbor Technical Overview: A Guide for Peakflow SP TMS Deployment

List of Figures

Figure 1 Peakflow SP TMS Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Figure 2 TMS Data Path and Traffic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Figure 3a Gateway Architecture with Layer 2 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Figure 3b Gateway Architecture via Direct Connection to Off-/On-Ramp Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Figure 4 TMS Single-Leg Architecture with Generic Routing Encapsulation Tunnel On-Ramp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 5 Redundant Generic Routing Encapsulation On-Ramp Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Figure 6 TMS Deployed in Peering POPs with Generic Routing Encapsulation On-Ramp to Peering Edge . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 7 Distributed Attacking Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 8 Mitigation Prefix Announcement Next-Hop Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure 9 On-Ramp Traffic Through Generic Routing Encapsulation Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure 10 TMS In-Line Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Figure 11 TMS Hybrid Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 12 Peakflow SP Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21


Peakflow SP Threat Management System

(TMS) is an integrated mitigation product

for the Peakflow SP solution (Peakflow

SP). TMS provides attack mitigation

through a full suite of integrated, easily

configured counter-measures, reports

and alerts. With TMS, network operators

can also monitor critical applications and

network services such as HTTP and

DNS to ensure service availability and

provide an early warning in the event

of a malicious network event.

Physical PlatformTMS is built upon high-capacity, network processing unit(NPU)-based hardware designed to operate in todays networkcarrier and large-scale enterprise environment. The systemincorporates state-of-the-art packet-processing technologyin platforms that range from 1-rack unit (RU) to 6 RU. Theseadvanced platforms incorporate both network and application-processing technology to ensure up to 40 Gbps performance.As noted in the chart below, there are multiple TMS modelsto choose from, allowing you to optimize your deployment.

TMS provides a separate processing path for transmittingfast-path production traffic and management traffic to thesystem. As a result, TMS ensures that: 1) data-path trafficdoes not impact system accessibility; and 2) managementtraffic is not prioritized and does not collide with productiontraffic in any way. The management data path uses a singleprocessor for appliance management, external access andTMS communication. The data path utilizes up to sixapplication processors to ensure high-speed packetprocessing through hardware acceleration.

Peakflow SP Threat Management System

Performance

(Gbps)

DeploymentSmall Provider, DedicatedCustomer, Small POPs

40

30

20

10

9

8

7

6

5

4

3

2

1

0

Large Provider, RegionalScrubbing Center, Large POPs

311010 Gbps, 3U, 2 x 10 GigE ports + 10 x 1 GigE ports

4000

4 x APM (40 Gbps)3 x APM (30 Gbps)2 x APM (20 Gbps)

8 x 10 GigE ports, 6U, 1 x APM (10 Gbps)

25002.5 Gbps, 2U, 6 x 1 GigE ports, NEBS certified

12001.5 Gbps, 1U, 4 x 1 GigE ports

30505 Gbps (software upgrade to 10 Gbps), 3U,

2 x 10 GigE ports + 10 x 1 GigE ports

Figure 1 Peaklfow SP TMS deployment

Surgical Mitigation Power of TMSTMS has the unique advantage of being fully integratedwith the Peakflow SP solution. When Peakflow SP detectsan anomalous event within the network, it offers multiplemitigation methods to deal with this traffic. One of thesemethods is to redirect traffic flows through TMS for trafficvalidation and scrubbing. Behavioral traffic patterns, baselinedata and known malicious attack methods are used tosurgically scrub the attack traffic out of the data path whilepreserving all legitimate traffic. The cleaned traffic is thenforwarded to the final destination. All return-path traffic issent directly back to the source asynchronously. See theTMS Deployment Architecture section (next page) formore details.

Large numbers of network events or attacks lead to theeffective completion of a distributed denial of service (DDoS)attack. Traditional mitigation tools leverage the access controllist (ACL) or black-hole capabilities of the routing infrastructureto deal with threats. While effective, these tools typicallycomplete an attack or create very large listsas in thecase of ACLs that can threaten the ability of the router tosuccessfully process packets at line rate. TMS provides theunique ability to inspect traffic on demand. Through theseadvanced mitigation countermeasures, the final act of thesurgical mitigation preserves the availability of the destinationunder attack and cleans threatening traffic from the datastream. This protects the destination itself and reducesthe processing overhead associated with the rest of thedownstream network infrastructure.

Peakflow SP is the most comprehensive solution on themarket today for dealing with network events. By combiningpervasive visibility with surgical mitigation, TMS enablesproviders to assess network threats, choose from multiplemitigation methods and influence network traffic patternsto efficiently deal with tomorrows most complex networksecurity risks.

4



These methods include:

Off-/On-Ramping (Diversion/Reinjection) Deployment

In-Line Deployment

Hybrid Deployment

Standalone Deployment

Off-/On-Ramping (Diversion/Reinjection)Deployment

For proper off-ramping and on-ramping deployment, TMSmust be deployed in network locations with good connectivityand visibility into the Border Gateway Protocol (BGP) controlplane. This provides the control needed to off-rampsource-to-destination traffic from the current data path intoTMS for mitigation. Off-/on-ramping is also referred to asdiversion/reinjection.

Once TMS is deployed in the network, some basic concepts oftraffic diversion are critical to ensure loop-free routing. Refer toFigure 2 for the definition of traffic concepts used throughoutthis document.

Network traffic that follows the current, unaltered routing pathis referred to as the native traffic path. The native traffic pathis a result of the routing protocols best path selection processand results in traffic following unaltered paths in the routersforwarding tables. When TMS diverts traffic from the nativetraffic path, the newly created path is referred to as theoff-ramp traffic path. Traffic is then sent through TMS andcountermeasures are applied. Traffic that is blocked by TMScountermeasures is referred to as dropped traffic withinmitigation reports. Post-countermeasure processed trafficpassed to the outbound interface of TMS is called scrubbedtraffic. The path from the TMS egress interface to the originaldestination of the traffic is called the on-ramp traffic path.On-ramp traffic always follows the on-ramp traffic path toensure loop-free routing to the final destination of the traffic.

Deployment Architecture

This document covers the methods of Peakflow SP TMS deployment.

Figure 2 TMS data path and traffic concepts

Peakflow SP CP

Peakflow SP TMS

Diverted Traffic Path

Flow Data

Native Traffic Path

SourcesDestination

On-Ramp PathOff-Ramp Path

In most deployments, traffic is diverted from the nativetraffic path to the off-ramp traffic path through a BGProute announcement. This announcement changes the pathby advertising TMS as the BGP next hop for the mitigateddestination. The TMS appliance or the Peakflow SP solutioncan originate the route change by announcing a morespecific route to the network. This route-change next hopis the off-ramp interface of TMS. This ensures that trafficcoming from the attacking source(s) is passed through TMSfor mitigation.

On-ramp traffic into the network is handled through a nativeIP packet placed on the TMS egress interface or through ageneric routing encapsulation (GRE) tunnel. The TMS applianceis capable of injecting non-encapsulated IP traffic directly intothe on-ramp traffic path. Putting traffic back on the networkwith no encapsulation requires an assurance of loop-freeforwarding on the on-ramp. If a loop-free path cannot beensured, then some form of encapsulation is required. GREtunnels can also be built into the on-ramp traffic path toensure that traffic to the destination is tunneled to the provideredge (PE) router closest to that destination. Encapsulatingdiverted traffic through the on-ramp traffic path ensures thattraffic is not reforwarded into TMS through a preferred route,thereby creating an endless traffic loop. The Using GenericRouting Encapsulation Tunnels for On-Ramp Traffic section(page 8) discusses the use of GRE tunnels to ensureloop-free traffic forwarding.

Once traffic has passed through the off-ramp and on-ramptraffic path, data is delivered to the destination. All return traffic(e.g., traffic sent from the destination back to the originalsource) is routed along the original native traffic path. TMSoperates in this asynchronous traffic model throughout theduration of the mitigation.

A secure communication channel is maintained between thePeakflow SP controller and the TMS appliance throughout themitigation. Control traffic between the Peakflow SP controllerand the TMS appliance utilizes a secure communication channel.This control traffic communication enables mitigations, mitigationand countermeasure filter configurations, and traffic statistics.

TMS can also be deployed in standalone mode (without aPeakflow SP controller). Off-ramp/on-ramp deployment issupported in standalone mode.

6


While a number of deployment scenarios are described in thisdocument, this is not an exhaustive deployment guide. Consultyour Arbor Networks sales representative for additional detailsand options available to the network operator.

Both of the deployment scenarios described in this sectioncan be used in many different network topologies. Thegateway architecture or the single-leg architecture can bedeployed in hosting centers, large enterprise networks or largeservice-provider environments. By leveraging the integratedanomaly detection, alerting and reporting of Peakflow SPalong with the surgical mitigation of TMS, a network operatorcan access the largest set of tools through a single interfaceto efficiently deal with todays and tomorrows most complexnetwork security risks.

TMS Gateway ArchitectureA standard deployment for TMS is outlined below. Thisdeployment includes connectivity to a router for off-ramptraffic. The connectivity between the off-ramp router andthe TMS appliance can be done through a Layer 2 switch(Figure 3a) or direct connection (Figure 3b). In this gatewayarchitecture, TMS uses a separate physical interface foron-ramp traffic into the network. This interface providesconnectivity to the next-hop router, thereby creating theon-ramp data path.

Using the gateway architecture, TMS can be deployed tospan across hops in the network or in redundant scenarios toensure that the appliance is available in the event of localizedoutage. In some scenarios, TMS can directly connect twodifferent locationsensuring the directly routed delivery of thescrubbed traffic to the protected destination. See the UsingGeneric Routing Encapsulation Tunnels for On-Ramp Trafficsection (page 8) for redundant on-ramp GRE tunnel examples.

7


TMS can be physically deployed in a number of ways to meet the requirements of todays

advanced network architectures. Each deployment method enables TMS to efficiently solve

unique problems and often serve a multipurpose role in the network.

Multiple Off/On-Ramp Deployment

On-Ramp PathInf 2 10.2.2.2/24

Peakflow SP TMS

Off-Ramp PathInf 1 10.1.1.1/24

Internet

Destination192.168.1.1/24

On-Ramp Router10.2.2.254/24

Layer 2 Switch

Off-Ramp Router10.1.1.254/24

Figure 3a Gateway architecture with Layer 2 switch

Figure 3b Gateway architecture via direct connection to off-/on-ramp routers

Internet


On-Ramp Router10.2.2.254/24


Peakflow SP TMS


Off-Ramp Router10.1.1.254/24


Single-Leg ArchitectureThe single-leg architecture uses a single interface to connectthe TMS appliance to the production network. This reduces thephysical footprint requirement of TMS and enables the applianceto connect directly to a router or switch interface.

Figure 4 shows the directly connected deployment of TMSto a router. In this example, TMS provides mitigation on thedirectly connected link to the routerwhich off-ramps trafficto TMS. The use of a single interface ensures the propagationof the TMS off-ramp interface IP address through the InteriorGateway Protocol (IGP), along with the router-connectedinterface route statement. In this case, on-ramp traffic requireseither: 1) a policy-based routing (PBR) configuration on thedirectly connected router to ensure loop-free traffic forwardingor; 2) a GRE tunnel from the TMS interface to the GREdestination in order to bypass the routing table of the directlyconnected router.

Using Generic Routing Encapsulation Tunnelsfor On-Ramp TrafficGRE tunnels are used to on-ramp traffic and bypass areasof the network that can cause a routing loop. Routing loopsoccur in areas where the destination route points to the TMSoff-ramp interface as a BGP next hop. When a BGP route isadvertised into the network to divert traffic, that route may bepropagated throughout the network. The use of interior BorderGateway Protocol (iBGP) peering sessions with edge routers,prefix advertisements tagged with communities such asNO_ADVERTISE and NO_EXPORT, and route maps ensurethat routes are only propagated in desired areas of the network.

In some cases, a loop-free routing environment cannot beensured. To bypass this problem, GRE tunnels are employed toenable on-ramp traffic to reach the desired destination. A GREtunnel must be used when:

A route is advertised without NO_ADVERTISE andNO_EXPORT community tags

A route is advertised to an iBGP-peered route reflector server

TMS is deployed in a single-leg architecture

The GRE tunnel originates from the on-ramp interface ofTMS and terminates on a downstream router within thenetwork closest to the final destination. In some cases, thismay be the provider edge (PE) router or the customer edgerouter to which the destination network is directly connected.

The GRE tunnel source is the IP address of the TMSinterface; the tunnel destination is the Loopback0 IP addressof the termination router. The tunnel has an entrance IP anddestination IP address. In Figure 4, these values would beconfigured as:

TMS

Source IP Address TMS Inf 1: 10.1.1.1/24

Destination Prefix: 192.168.1.1/24

Primary Destination IP Router B Loopback0: 10.2.2.254/24

Tunnel IP Address: 10.3.3.1/24

Router B

Tunnel Source IP Loopback0: 10.2.2.254/24

Tunnel Destination IP TMS Inf 1: 10.1.1.1/24


On-Ramp Path

Peakflow SP TMS

Off-Ramp Path

Internet


Router B Tunnel IP10.3.3.254/24

Router A10.1.1.254/24

Peakflow SP TMSInf 1: 10.1.1.1/24 GRE Tunnel IP: 10.3.3.254/24

Figure 4 TMS single-leg architecture with generic routingencapsulation tunnel on-ramp


Configuring GRE tunnels is done from the Peakflow SP userinterface (UI). Go to Administration > Monitoring > PeakflowDevices, then select the TMS system and go to the On-Ramptab. Enter the specific IP addresses for the TMS interface source,the router destination address and the TMS GRE address. AGRE tunnel can be mapped to any prefix. As TMS is configuredand deployed within the network, or as more locations areidentified as requiring TMS protection, a new GRE-to-routermapping can be created for each prefix to be protected.

Using Redundant Generic RoutingEncapsulation TunnelsRedundant GRE tunnels can be used to ensure that on-ramptraffic reaches the protected destination. Each GRE tunnelis configured to separate routers, each with disparate pathsto the destination. Keep-alives are used to ensure that eachtunnel path is available from both the TMS appliance andthe destination router. Figure 5 illustrates the deploymentarchitecture of a redundant GRE on-ramp.

To configure a redundant GRE tunnel from the Peakflow SPUI, go to Administration > Monitoring > Peakflow Devices,then select the TMS system and go to the On-Ramp tab.Click the Add Mapping button to add a GRE tunnel mapping.Check the Enable Redundancy box and complete themapping information. Based on the example in Figure 5,the configurations are:

TMS

Source IP Address: 10.3.3.1

Destination Prefix: 192.168.1.1/24

Primary Destination IP: 10.2.2.254

Secondary Destination IP: 10.5.5.254

Router B




Router C




GRE keep-alives are used to ensure that: 1) the tunnel isavailable to TMS; and 2) packets are on-ramped using theavailable tunnel in order of priority. Setting the keep-aliveinterval and the number of retries starts the keep-alive process.

Figure 5 Redundant generic routing encapsulation on-ramp tunnels

On-Ramp Path

Peakflow SP TMS

Off-Ramp Path

Internet


Router BLoopbackO IP 10.2.2.254/24GRE Tunnel IP 10.3.3.253/24

Router CLoopbackO IP 10.5.5.254/24GRE Tunnel IP 10.3.3.254/24

Peakflow SP TMSInf 1: 10.1.1.1/24Destination Prefix: 192.168.1.1/24Primary Destination IP: 10.2.2.254/24Secondary Destination IP: 10.5.5.254/24GRE Tunnel IP: 10.3.3.1/24

Router A10.1.1.254/24

10


Large Network Peering Edge DeploymentDeploying TMS in multiple locations on a large networkprovides granular control of mitigation traffic flows throughthe single Peakflow SP management console. Large networkdeployments have the advantage of tracing DoS attacksback to multiple points-of-entry into the network. Using TMSappliances deployed in close proximity to the peering edgeallows for efficient off-ramping to the closest appliance formitigation. The use of large network BGP control techniques(e.g., Anycast destination prefix announcement) can improvecontrol over the load on the mitigation appliances as an attackenters the network or increases in volume.

In this example, the use of an Anycast destination prefix:1) leverages the TMS capability to announce multiple BGPnext-hop addresses; 2) improves granular control of traffic flowsthrough the mitigation products; and 3) distributes the load ofthe attack across multiple processing centers. Deploying TMSappliances in each Internet peering location provides mitigationcapability at the network edge. Connections to each peeringrouter, as well as to the GRE on-ramp tunnels created betweeneach TMS appliance and the peering edge router, are configuredto ensure protection to the destination services.

Figure 6 illustrates one possible large-scale deploymentscenario. In this deployment, a BGP peering session ismaintained directly between TMS and the peering router.This peering session is maintained over the TMS managementinterface and the peering routers loopback interface.

Peering directly from TMS provides valuable control over thedetails of the routes announced into the network for mitigationoff-ramping. For example, it ensures that a unique route isannounced from each individual TMS appliance. While theannouncement of multiple routes into the network effectivelycreates an Anycast prefix, each peering router will select theclosest next hop based on the administrative distance of theroute. In this example, using a directly connected interfaceaddress of TMS provides a highly preferred route to the peeringedge routers for the destination next hop.

Figure 6 TMS deployed in peering POPs with GRE on-ramp to peering edge

Peakflow SP TMS BInterface IP 10.2.2.2/24GRE IP 172.16.2.1/30

Peakflow SP TMS Peakflow SP TMS

Internet


PE RouterLoopbackO IP 10.4.4.4/24

GRE Tunnel A 172.16.1.2/30GRE Tunnel B 172.16.2.2/30GRE Tunnel A 172.16.3.2/30

Peer A Core

Peer C

Peer B

Internet

Internet

Peakflow SP TMS AInterface IP 10.1.1.1/24GRE IP 172.16.1.1/30

Peakflow SP TMS CInterface IP 10.3.3.3/24GRE IP 172.16.3.1/30

Peakflow SP TMS

Network Deployment Example

Deploying TMS in very large networks provides some unique advantages for protecting

against denial of service (DoS) attacks. The goal should be to focus on limiting the impact

of the attack on as many infrastructure elements as possible from the edge of the network.

This section outlines an example of how to implement TMS in the aggregation POP and

on the network peering edge, and how to deploy TMS to protect network services.

11


As a network attack is launched, the core and peering edgerouters are put under significant load. The path to the destinationunder attack becomes saturated. The load of the attack threatensboth the availability of the destination server as well as thepacket processing of the core and peering edge router. The mostlikely choke point of the attack is the link between the destinationand the peering edge router, as this is most often a dedicatedlink with throughput speeds of under one gigabit per second.As the number of sources grows in the attack, the link becomessaturated with malicious traffic as seen in Figure 7. Some ofthe attack may be dropped at the external peering interfacethrough ACL matching via the decision-support capabilities ofPeakflow SP. The most efficient way of dealing with this typeof saturating event is to distribute the traffic through a numberof diversely deployed TMS appliances at the network edge.

Traffic flooding the destination triggers an alert in Peakflow SP.Network operators can configure the proper mitigation byadding each of the TMS appliances to the TMS mitigation option.

As the mitigation starts, a BGP route for a more specificclassless inter-domain route (CIDR) is announced into thenetwork from each TMS appliance. Each CIDR announcementfor 192.168.1.1/32 has a unique next hop of each TMS interface.This provides three next-hop addresses for the 192.168.1.1/32prefix. If each TMS appliance is iBGP-peered to the local peeringrouter, as each router in the network receives these BGPannouncements, the peering router will select the new nexthop of the local TMS.

If the route announcements are made through route-reflectorservers, the route-selection process within each route-reflectorserver will choose the next hop closest to itself based on thelocal shortest path algorithm. Each peering router will receivea unique route for the prefix 192.168.1.1/32 and install theclosest next-hop address of the local TMS appliance as seenin Figure 8 (page 12).

Attack traffic is redirected into the local TMS appliance fromeach peering location. All redirected traffic is scrubbed by theappliance in each location. Clean traffic is then forwarded onto the final destination through GRE on-ramp traffic pathsconfigured between the TMS locations and the peering edgerouter (Figure 9, page 12).

Each TMS appliance continues to communicate with thePeakflow SP Collector Platform (Peakflow SP CP) throughoutthe mitigation as illustrated in Figure 9 (page 12). Thiscommunication is maintained over a secure socket layer(SSL)-encrypted session for privacy. Information is passedbetween TMS and Peakflow SP CPproviding details aboutmitigation, countermeasure updates and traffic statistics. Thestatistics gathered from TMS provide ongoing and after-actionreports about the event, including dropped, passed and percountermeasure statistics.

Stopping the mitigation removes the more specific routeannouncement for destination 192.168.1.1/32 from the network.All traffic returns to the native path upon the withdrawal of theroutes from the peering sessions to the peering routers.

TMS B10.2.2.2/24

Internet

Peakflow SP TMS


Internet

Destination192.168.1.1/32192.168.1.0/24

PEPeer A Core

TMS A10.1.1.1/24

TMS C10.3.3.3/24Peer C

Internet

Peer B

Figure 7 Distributed attacking sources

12


Figure 8 Mitigation prefix announcement next-hop updates

Figure 9 On-ramp traffic through GRE tunnels

TMS B10.2.2.2/24

Internet

Peakflow SP TMS


Internet

Destination192.168.1.1/32192.168.1.0/24

PECore

TMS A10.1.1.1/24


Internet

Peer B

Peer A

192.168.1.1/32Next hop 10.1.1.1 192.168.1.1/32

Next hop 10.3.3.3

192.168.1.1/32Next hop 10.2.2.2

TMS B10.2.2.2/24

Internet

Peakflow SP TMS


Internet

Destination192.168.1.1/32192.168.1.0/24

PECore

TMS A10.1.1.1/24


Internet

Peer B

Peer A

192.168.1.1/32Next hop 10.2.2.2

192.168.1.1/32Next hop 10.3.3.3

192.168.1.1/32Next hop 10.1.1.1

13


TMS can also be deployed in-line. From

a software perspective, configuring a TMS

appliance for in-line deployment is as simple

as selecting the In-Line option from a

configuration menu within the management

UI. This essentially turns TMS into a pure

Layer 1 appliance, providing transparent

mitigation as an intelligent wire. No IP

addressing or network configuration is

needed, and only a mapping of ingress

to egress ports is required to enable this

deployment type.

Advantages of Deploying TMS in theIn-Line Mode

Though a majority of TMS deployments are done in-cloudutilizing the off-/on-ramping mode, there are scenarios wheredeploying TMS in-line makes more sense. The following areadvantages of deploying TMS in the in-line mode:

This is the simplest deployment method, requiring the leastamount of TMS configuration and integration with thenetwork environment. The in-line deployment requires nonetworking or readdressing of the network. Only physicalconnections in the protected path are required.

The value of TMS can be maximized as it simultaneouslyconducts surgical mitigation of attack traffic while providingapplication-layer visibility and performance analysis.

Application performance statistics (i.e., jitter, delay, packetloss, etc.) are reported most accurately in this mode as TMSmeasures both inbound and outbound traffic directly throughthe network link.

TMS can be used to generate flow information in anenvironment where the routers are not capable of producingflow. For example, if a TMS appliance is deployed in frontof a server data center, the router upstream of the TMSappliance might not be BGP capable, or might beadministered by a different unit or company.

There may be instances where a customer is not able tobe mitigated through the cloud because the border andcustomer aggregation edges have collapsed to a single layer.This is true in many transit networks where, due to IGP/EGPadmin distances, the local router will not off-ramp into ascrubbing center. The in-line mode may serve as a means todedicate a system to the customer link where before therewas no option.

In-Line Deployment

14


Disadvantages of Deploying TMS in theIn-Line Mode

The disadvantages of deploying TMS in the in-line mode are:

Even though TMS has fault-tolerant features such ashardware bypass ports, as with any in-line device, it hasthe potential to become a point of failure in the networksdata path.

Note: A network tap can be used to avoid a data pathfailure through TMS. When a TMS appliance is connectedto the network via a tap, TMS can only provide trafficvisibility as the system is purely out of the data plane forproduction traffic. To mitigate, TMS must have ports in thedata plane where it can actively test traffic through its setof countermeasures. Some of these countermeasuresinteract with trafficensuring that the traffic is legitimate,not spoofed and manage advanced inspections.

Placing in-line systems to thwart DDoS attacks has limitations,specifically in scaling to the size of the attack. If the attackis greater than the link bandwidth, the in-line TMS protectingthat link may become saturated before TMS can clean thetraffic properly. If this is the case, the overall effect of TMSmay be limited and likely should be augmented with acloud-based solution to scale to very large attacks througha hybrid approach described later in this document.

Sizing the TMS deployment is important to ensure that thedemands of the environment are met by the multiple valuesthat in-line TMS provides. Under-sizing the TMS system forthe protected link could impact traffic flow through the TMSappliance as well the performance of the product while itconducts mitigation, Arborflow generation and Layer 7traffic analysis.

Peakflow SP TMS

Internet


Router B10.2.2.254/24

Router A10.1.1.254/24

Figure 10 TMS in-line deployment. As an in-line system, TMS acts as aphysical connection between two end points. The appliance can providevisibility and mitigation as well as physical link protection through onboardlink bypass capabilities

15


TMS deployments can also combine both

off-/on-ramp and in-line configurations.

For example, in environments where

services are being constantly attacked,

TMS technology has been deployed in

a layered approach.

This splits the mitigations into two functional systems: first, acloud-based deployment providing protection from brute forceand bulk attacks in the cloud; and second, a dedicated TMSnear to or in the customer premises to provide instrumentationand Layer 7 protection for the service itself. This can providea very strong layered approach to mission-critical serviceprotection and work in conjunction with each of the TMSsystems deployed. Using TMS groups allows the carrier tomanage each layer of the protection solution independentlyand without countermeasure overlap and conflict.

TMS can also be placed in-line through policy-based routing(PBR) techniques. In this case, TMS can be in-line on theingress path but simulating the BGP off-ramp method. This isthe choice of a number of active deployments. It can be lessadvantageous as it forces asymmetric routing, requires operatorintervention to change traffic paths (non-dynamic) and cannotbe used to create all the accurate performance instrumentationon the system through the single half-duplex traffic stream.However, this is advantageous for customers who prefer theoff-ramp method versus the in-line method and are willing tomake the operational trade-off of a non-dynamic deployment.

Hybrid Deployments

Peakflow SP TMS

Internet


Router B10.2.2.254/24


Peakflow SP TMS


Router A10.1.1.254/24

Figure 11 TMS hybrid deployment

16


TMS can be deployed as a mitigation-only

solution or as a component of a Peakflow

SP solution that provides network monitoring,

alerting, traffic engineering reports

and mitigation.

The deployment options are summarized as follows:

TMS Integrated with Peakflow SP

A comprehensive network monitoring, traffic engineeringand DDoS protection solution consisting of (at a minimum)a Peakflow SP Collector Platform-2 (CP-2 TMS) applianceand a TMS appliance.

Peakflow CP-0 TMS

A DDoS mitigation solution consisting of a licensedPeakflow SP Collector Platform-0 (CP-0 TMS) applianceand TMS appliance.

Standalone TMS (SA TMS)

A DDoS mitigation solution consisting of a TMS appliance.

The functional differences between these deployment optionsare summarized in the following table.

TMS Deployment Options

continued on page 17

SA TMS CP-2/5 TMS CP-0 TMS

Supported Appliances 1200, 2500 All TMS Models All TMS Models

Management On Box Multi-appliance centralmanagement from thePeakflow SP Collector Platform(Peakflow SP CP) or thePeakflow SP Portal Interface(Peakflow SP PI) appliance

Single appliance managementfrom CP-0 TMS

Deployment Modes In-line, Diversion/Reinjection In-line, Diversion/Reinjection,Span Port

In-line, Diversion/Reinjection

Flow Collection (xflow, SNMP, BGP) No Yes (Peakflow SP CP) No (CP-0 TMS does not collect)

Attack Alerts No Yes No

Historical Reports No Yes No

Packet Capture Yes Yes Yes

Application Performance Reporting No Yes No

17


Countermeasures SA TMS CP-2/5 TMS CP-0 TMS

Filter List Yes Yes Yes

Filter List Management No Yes Yes

Zombie Detection Yes Yes Yes

TCP SYN Authentication Yes Yes Yes

TCP SYN Authentication,Out-of-Sequence ACK

No Yes Yes

TCP Connection Reset Yes Yes Yes

Payload Regular Expression Yes Yes Yes

DNS Authentication (Passive& Active UDP Mode)

Yes Yes Yes

DNS Authentication, ActiveTCP Mode

No Yes Yes

DNS Malformed Packet Yes Yes Yes

DNS NXDomain Rate Limiting Yes Yes Yes

DNS Regular Expression Yes Yes Yes

HTTP Malformed Traffic Yes Yes Yes

HTTP Rate Limiting Yes Yes Yes

HTTP Header Regular Expression Yes Yes Yes

SIP Malformed Yes Yes Yes

SIP Request Limiting Yes Yes Yes

Traffic Shaping Yes Yes Yes

Proxy List Threshold Exceptions No Yes Yes

ATF No Yes Yes

Fingerprints No Yes Yes

GeoIP-Based Mitigation No Yes Yes

GeoIP-Based Rate Shaping No Yes Yes

Mitigation Templates No No Yes

Learning Mitigations No Yes Yes

Traffic-Triggered Mitigations No Yes Yes

Read-Only Access to Mitigations No Yes Yes

DNS and HTTP Scoping No Yes Yes

Active TCP DNSAuthentication No Yes Yes

18


Mitigation is configured directly through

the workflow in the Peakflow SP console

UI. Mitigations can be created ad hoc or

using the UI workflow from an alert within

the Peakflow SP solution. Each mitigation

requires the configuration of a mitigation

name, a destination prefix for protection

and the identification of the TMS appli-

ance(s) selected to apply the mitigation.

Mitigation can then be started with or without specificcountermeasures configured. Once a mitigation is started,its details are sent to the TMS appliance(s) selected in themitigation from the Peakflow SP CP appliance(s). StandaloneTMS (SA TMS) mitigation is configured through the TMSWeb UI. Note that SA TMS only has system alerts; you cannotcreate a mitigation from an alert.

Countermeasure Overview

Countermeasures are applied to traffic when a mitigation isstarted. Countermeasures can be classified as either raw orevent-driven. Raw countermeasures are applied to all trafficpassing through TMS. Event-driven countermeasures areapplied only to traffic with an application ID matching thecountermeasure in which TMS identifies the traffic stream andapplies the countermeasure to that stream. This may involveinspection and reassembly of multiple packets. Event-drivencountermeasures are typically countermeasures designed toprotect specific applications (e.g., DNS, SIP or HTTP) orspecific resources (e.g., TCP session tables).

TMS has black- and white-list functionality that enhances theefficiency and security of mitigation processing. The functionof a black list is to block known bad sources or known badtraffic, thus avoiding the need to apply more complexcountermeasures to that traffic. The function of a white listis to exclude known valid sources and important sourcesfrom being potentially blocked by a countermeasure. Thissafeguards against the possibility of blocking critical sourcessuch as external DNS, important customers, remote supportpersonnel, etc. It also improves the overall mitigation efficiencyof the system.

TMS white and black lists are collectively referred to as filterlists. Filter lists can be configured as global lists or configuredspecifically for a mitigation. A global list is available for usewithin any mitigation. Global lists can be very large listsimported and maintained from third-party sourcessuch aslists of known infected hosts.

The following table (page 19) lists the TMS countermeasuresin the order in which they are applied during a mitigation.

Mitigation Overview

19


Countermeasures Description Usage

Black White List FCAP expression to explicitly drop or pass traffic.Global list.

Pass traffic from critical services, Google crawler;drop spoofed sources, drop invalid ports/protocols.

IP Address Filter Lists IP hosts or CIDR addresses. Global list. Pass known partner networks, secure clients, supportworkers. Block infected subscriber lists, known BOTC&C servers.

Black White List(formerly global exceptionlist in V5.1 and below)

FCAP expression to explicitly drop or pass traffic.Global list.

Pass traffic from critical services, Google crawler;drop spoofed sources, drop invalid ports/protocols.

URL Filter List Lists of regular expressions that match on the URIfields in HTTP requests. Global list.

Efficient way to block/allow HTTP requests.

DNS Filter List Lists of regular expressions that match DNS domainsin DNS requests. Global list.

Efficient way to block/allow DNS requests.

GeoIP Filter List GeoIP country lists are an extension of IP addresslists. Global list.

Efficient way to drop or pass traffic from specifiedcountries during a mitigation.

GeoIP Policing Per mitigation list of GeoIP filters (countries) thatare passed, dropped or rate-limited.

Effective in blocking/limiting sources that have nolegitimate reason to be sending traffic (e.g., trafficfrom a country to an ecommerce site that does notdo business there).

Zombie Removal Removes sources that exceed defined pps orbps thresholds.

Effective against flood, TCP SYN and protocol attacks.Black lists offending hosts until their behavior fallsbelow thresholds.

TCP SYN Authentication Event-driven countermeasure designed to block TCPrequests from spoofed sources and traffic generators.

Protects servers, firewalls and load balancers fromTCP session table exhaustion.

TCP Connection Reset Event-driven countermeasure that protects serversfrom excessive idle sessions.

TMS clears idle TCP sessions from back-endservers. Added features ensure graceful recoveryfor legitimate users.

Payload Regex Regex countermeasures reassemble incomingpacket streams and match on payload data. Eventdriven countermeasure.

Effective in removing attack traffic with known patternin the payload.

Baseline Enforcement Bandwidth and protocol enforcement. Monitors topsubnets and protocols and identifies high spikes intraffic from normally low-volume sources or protocols.

Blocks sources and protocols that exceed the norms.Effective in mitigating attacks that use legitimatesources sending legitimate traffic.

DNS Countermeasures Combination of raw and event-driven countermeasuresdesigned to ensure that only valid DNS requests fromvalid sources are allowed.

Protects against DNS amplification, cache poisoningand resource exhaustion. Protects recursive and authori-tative DNS. Scoping features focus countermeasuresfor virtualized, shared and NATd environments.

HTTP Countermeasures Combination of raw and event-driven countermeasuresdesigned to ensure that only valid HTTP requests fromvalid sources are allowed.

Protects Web servers from spoofed sources, trafficgenerators and bot sources. Scoping features efficientlyfocus countermeasures for virtualized, shared andNATd environments.

SIP Countermeasures Combination of raw and event-driven countermeasuresdesigned to ensure that only valid HTTP requests fromvalid sources are allowed.

Protects SIP servers from attack. Rate limiting andmalformed detection.

Traffic Shaping/RateLimiting

Limits traffic to a level that allows protected hoststo continue to function.

Effective in managing flash crowd events and helpingcontrol operations gracefully if other countermeasuresare not fully mitigating an attack.

20


Peakflow SP is a comprehensive

threat detection and mitigation solution.

By utilizing a number of attack detection

and surgical mitigation countermeasures,

the combination of Peakflow SP and TMS

allows ISPs to protect critical IP services

from all types of DDoS attacks, which

come in a variety of forms.

For example:

As large quantities of raw traffic designed to overwhelma resource or infrastructure.

As application-specific traffic, sometimes stealthy in nature,designed to overwhelm a particular service.

As traffic formatted in such a way to disrupt a host fromnormal processing

As traffic reflected and/or amplified through legitimate hosts

As traffic from compromised sources or from spoofedIP addresses

Below is a table briefly describing the different types of DDoSattacks that the integrated Peakflow SP and TMS solution candetect and stop by using multiple types of countermeasures.

DDoS Attack Detection and Surgical Mitigation Capabilities

These attacks flood a certain aspect of theTCP connection process to keep the hostfrom being able to respond to legitimateconnections. At times these attacks maybe spoofed or non-spoofed.

TCP SYN, TCP FIN, TCPRST, TCP Flags attacks.

Misuse, TCP SYN, TCP RST,or Total Traffic detection.

TCP SYN authentication, zombiedetection, filter, (white/black) list.

These attacks flood traffic for oneor more protocols or ports. They aredesigned to look like normal traffic,may be spoofed or non-spoofed andutilize reflection techniques.

Ping Attack, Smurf attack,reflection attacks, UDPflood, Stream, dc++,blackenergy.

Misuse UDP, ICMP, Total Trafficdetection, or Profiled Anomalydetection for managed object.

White/black list, zombie detection,baseline enforcement, rate limiting,payload filtering. (Note: Baselineenforcement not available on SA TMS.)

These attacks send a flood of TCP orUDP fragments to a victim, overwhelmingthe victims ability to re-assemble thestreams and severely reducingperformance. Fragments may also bemalformed in some way or may be aresult of a network misconfiguration.

Teardrop, Targa3, Jolt2,Nestea.

Misuse IP fragment detection. White/blacklist, zombie detection.

Attack Type Common Names Peakflow SP DetectionPeakflow SP TMSCountermeasures

TCP Stack Flood Attacks

Generic Flood Attacks

Fragmentation Attacks

continued on page 21

21


These attacks are designed to overwhelmcomponents of specific applications.Common attacks are against HTTP, DNSand SIP services. These attacks may bestealthy in nature by mixing with a muchhigher traffic volume on the sameprotocol/port.

HTTP GET floods,SIP Invite floods, DNSamplification attacks.

Requires Peakflow SP TMS systemsdeployed in span modeor seeingboth sides of the conversation,conducting deep packet inspection(DPI) for application identificationand feeding Peakflow SP solutionswith defined application levelmanaged objects.

Packet RegEx filtering; HTTP malformed,HTTP rate limiting, HTTP payload RegExfiltering; SIP malformed, SIP requestrate limiting; and DNS authentication,DNS malformed, DNS NXDomain ratelimiting, DNS query rate limiting, DNSpayload RegEx filtering.

These attacks maintain a large numberof either half-open TCP connections orfully-open idle connections with the victim,impeding new connections from forming.

TCP Idle attack. Misuse TCP SYN Flood, TCP ACKFlood (seen in reflection), TCP RSTFlood, TCP Total Traffic detection.

TCP SYN authentication, TCPconnection reset.

These attacks are designed to exploitvulnerabilities in the victims operatingsystem. Some attacks use single packetsor send at very low rates. Many of theseare obsolete in modern operating systems.

Most Worms and Trojans,Land, Xmas Tree, Ping ofDeath, Targa3, Kiss ofDeath, Nuke.

ATF-based fingerprint detection. Malformed HTTP, SIP, DNS, whitelist/blacklist.

Attack Type Common Names Peakflow SP DetectionPeakflow SP TMSCountermeasures

Application Attacks

Connection Attacks

Vulnerability Exploit Attacks

Peering/Transit Edge

Customer/Hosting Edge

BackboneRegional Mitigation

Center

Managed Service Customers

Peakflow SPCollector Platform (CP) 5500

Peakflow SPCollector Platform (CP) 5500

Peakflow SPFlow Sensor (FS)

Peakflow SPBusiness Intelligence (BI)

Peakflow SPPortal Interface (PI)

Peakflow SP Threat ManagementSystem (TMS) 1200/2500

Peakflow SP Portal Interface (PI)

Peakflow SPThreat Management System (TMS)

1200/2500/3x00/4x00

Central Console for Visibility and Threat Management

Figure 12 Peakflow SP architecture. Consists of five types of appliances: 1) Peakflow SP Collector Platform (CP) appliancesin the peering edge or backbone; 2) Peakflow SP Flow Sensor (FS) appliances in the customer aggregation edge; 3) PeakflowSP Business Intelligence (BI) appliances to increase scalability and add redundancy for managing critical business objects;4) Peakflow SP Portal Interface (PI) appliances to increase the scale, redundancy and profitability of Arbor-based managedservices; and 5) Peakflow SP Threat Management System (TMS) appliances deployed in any part of the network to surgicallymitigate network threats.

The combination of the Peakflow SP

solution and TMS appliances provides the

ability to cost-effectively detect, surgically

mitigate and accurately report upon DDoS

and other threats to your business-critical

IP services. No other product offers such a

comprehensive threat management solution.

For more information regarding Peakflow SPand TMS solutions, please contact your localArbor Networks sales representative or visit ourWeb site at www.arbornetworks.com.

Arbor Peakflow SP TMS Appliance Specifications

Power RequirementsRedundant dual power sources

3050/3100/3110/4000AC: 100/240V, 50-60Hz,460W nominalDC: -48 to -68V; 460W nominal

2500AC: 100/240V, 8.5A (50-60 Hz)DC: -48 to -60V, 20.5A max

1200AC: 100/240V, 8.5A(50-60 Hz)DC: -48 to -60V, 12A max

Physical DimensionsStandard 19 in and 23 inrack mountable

4000Chassis: 6U rack heightWeight: 85.3 lbs (38.7 kg)Height: 10.5 in (26.7 cm)Width: 17.64 in (44.8 cm)Depth: 16.3 in (41.4 cm)

3050/3100/3110Chassis: 3U rack heightWeight: 33.5 lbs (15.2 kg)Height: 5.25 in (13.34 cm)Width: 19 in (44.8 cm)Depth: 16.28 in (41.33 cm)

2500Chassis: 2U rack heightWeight: 39 lbs (17.7 kg)Height: 3.45 in (8.76 cm)Width: 17.11 in (43.46 cm)Depth: 20 in (51 cm)

1200Chassis: 1U rack heightWeight: 25.41 lbs (11.52 kg)Height: 1.7 in (4.32 cm)Width: 16.93 in (43 cm)Depth: 20 in (51 cm)

Hard DrivesDual hard drives running RAID 1

NICs40008 x10 GigE (SFP+)

31002 x10 GigE (SFP+)

3050/31102 x10 GigE (SFP+)10 x1 GigE (SFP)

25006 x 10/100/1000 (fiber GigESX and LX available)

12004 x 10/100/1000 (fiber GigESX and LX available)

Environmental3050/3100/3110/4000Operating: 32 to 131F(0 to +55C)Relative Humidity (Operating):5 to 80% non-condensing

2500Operating: 32 to 104F(0 to 40C)Relative Humidity (Operating):10 to 90% non-condensing

1200Operating: 50 to 95F(10 to 35C)Relative Humidity (Operating):12 to 90% non-condensing

Operating System1200/2500/3050/3100/3110/4000ArbOS/ArbUX, our proprietary,embedded operating systems,are based on open source oper-ating system technology such asLinux and Open BSD.

Regulatory Compliance1200/2500

FCC Part 15 Class A, IEC609503rd ed., CD, VCC, BSMI, CISPR,ICES, CTick, MIC, CCC, (model2500 NEBS)

3050/3100/3110/4000UL 60950, IEC/EN 60950,FCC Part 15, Subpart B, ClassA, CE Mark, NEBS GR-63-CORE and GR-1089-CORELevel 3, RoHS 6/6 Compliant

22


A Comprehensive Threat Management Solution

Corporate Headquarters

76 Blanchard RoadBurlington, MA 01803 USA

Toll Free USA +1 866 212 7267T +1 781 362 4300

Europe

T +44 207 127 8147

Asia Pacific

T +65 6299 0695

www.arbornetworks.com

2012 Arbor Networks, Inc. All rights reserved. Arbor Networks, the Arbor Networks logo, Peakflow, ArbOS, How NetworksGrow, Pravail, Arbor Optima, Cloud Signaling, ATLAS and Arbor Networks. Smart. Available. Secure. are all trademarks ofArbor Networks, Inc. All other brands may be the trademarks of their respective owners.

TB/TMS/EN/0912

TO_TMS_EN

Documents

Transcript of TO_TMS_EN