ACTE r4 Student Guide

ACTE Technical Training

Student Guide

Level 1 Document Version 4.1

2012

ACTE Training

Table of Contents

1. Introduction

2. Introducing In-Line Platforms

3. Introducing NetXplorer

4. Monitoring and Reporting

5. Condition Catalogs

6. Action Catalogs

7. Building the Enforcement Policy

8. Events and Alarms

9. Steering and Mirroring

10.Basic System Troubleshooting

Module 1

Introduction


Introduction 1-2

In this introductory module, we will begin with an overview of DART - the

technology that lies at the core of Allots solutions. We will then discuss the needs of different types of customers and will review the different use

cases Allot has to offer. We end this introductory module by introducing

some key terms together with Allots NetXplorer solution architecture.

Allot Communications is a leading provider of intelligent IP service

optimization and revenue generation solutions for fixed and mobile service

providers and high-end enterprises.

Without Allots intelligent solutions, networks are typically uncontrolled and

effectively invisible. Allot provides visibility into these networks at an

application, subscriber, and device level, and then acts on this visibility to

deliver quality of experience (QoE), contain costs and maximize revenue

as well as enabling operators to personalize their service offering.


Introduction 1-3


Introduction 1-4

Allots rich portfolio of solutions transforms broadband pipes into smart

networks that can rapidly and efficiently deploy value added Internet

services for both the network and the subscriber.

Allot's scalable, carrier-grade solutions provide the visibility, network

topology awareness, security, application control and subscriber

management that are vital to managing Internet service delivery,

enhancing user experience, containing operating costs, and maximizing

revenue in broadband networks.

In this particular example, intelligent application-aware pipes enable a

service provider to offer different grades of services. Alternatively,

subscriber-aware pipes enable the service provider to personalize its

offering.

There are many other ways to use Allots smart pipes to optimize network

bandwidth, generate revenues and personalize services, as we will see in

next few slides.


Introduction 1-5

At the core of Allots expertise is a technology called Dynamic Actionable Recognition Technology (DART). DART integrates Allots vast expertise in IP traffic identification and policy enforcement into a highly effective

technology toolkit for managing bandwidth consumption and service

performance in mobile and fixed broadband networks.

Dynamic refers to the ability of the system to constantly learn the network behavior, based on both behavioral and statistical techniques.

Recognition refers to Allots Deep Packet Inspection capabilities which provide enhanced network awareness at different levels: application,

subscriber, device and topology.

Actionable refers to the different types of action one can choose to applyto a traffic flow once it has been recognized. These actions will most

typically be to assign Quality of Service (QoS) or to steer traffic to a

network or subscriber service.


Introduction 1-6

DART employs multiple inspection and analytical methods to identify

specific applications. From straightforward Layer-7 monitoring of individual

traffic flows, to complex analysis of application behavior, this synergy of

inspection methods greatly improves recognition capabilities and reduces

unidentified traffic even at maximum speeds and peak loads. Through

proactive learning, DART is able to adapt to changing tactics as

applications attempt to evade detection through encryption or by altering

their connection behavior or flow patterns. Frequent and ongoing updates

to Allots extensive signature library are designed to keep pace with

developments and advances in Internet applications.

Lets consider the positioning of Allot devices among other categories of

devices in the industry. Switches and routers are essentially situated at L2

and L3. Typically, they look at the source and destination address of a

packet, plus other easily-accessible information such as the ToS field.

Such equipment answers the question where do I send this packet?.

However, if we sit at L4 and even higher at L7, as Allots DART driven

devices do, we first address the question what is actually being sent

here? And given the complexity of current P2P applications, and all the

tricky mechanisms they use to hide themselves, the real question that Allot

addresses is am I really sure this traffic is what it appears to be? And if

not, what is it in reality?. The purpose and the technical challenge of a

DART engine is to answer this question with the highest possible

accuracy.


Introduction 1-7

DART offers network providers the following solutions:

Reporting & Analytics: Accurate and meaningful network business intelligence for key decision-makers. Allot distills the real-time monitoring

data into a full complement of performance and activity metrics that allow

you to understand network usage and subscriber behavior at very granular

levels and to correlate that information with data from other network

systems. E.g: Operators can now make informed decisions to roll out new

service plans based on concrete data about subscriber usage patterns

Traffic Management: Operators can regulate bandwidth consumption and service delivery based on network conditions, subscriber profiles and

desired outcomes. Armed with the data retrieves from reports, operators

can pinpoint areas of capacity cost control and can implement dynamic

Quality of Service (QoS) policies.

Policy Control & Charging: Enable you to embrace more personalized service plans and charging models as you anticipate and satisfy the

requirements of your increasingly sophisticated subscribers.

Service Enablement: Operators can leverage Allots solutions to deploy value-added services that go above and beyond high-speed connections

to the Internet. For example, they may wish to direct relevant subscriber-

application traffic to media caching, video optimization and other services

(subscriber services) or to improve the overall efficiency of the network,

cut costs and reduce threats (network services). Services may be hosted

within the platform or deployed externally.


Introduction 1-8

Lets see now a selection of real network use cases that leverage the power and

innovation of Allots technology and products:

Cut Costs by deploying Network Services: Fair Use Management: ensures fair & consistent QoE for all subscribers.

Video Caching & Optimization: steer video traffic to a caching / optimization

device to reduce bandwidth costs at the peering point

DDoS Mitigation & Blacklist Avoidance: protection against attacks on network

elements and outgoing attacks launched from within the network which without

proper mitigation can lead to subscriber domains being blacklisted.

Generate Revenues by deploying Subscriber Services: Service Tiering: tailor different service plans for subscriber groups

Bill Shock Prevention: notify subscribers of data session costs in real time

Happy Hour: reduce network congestion and improve overall QoE by

encouraging usage and applying different QoS at different time of day

Volume Charging (Quota): offer a choice of different priced quota packages,

and meter the bandwidth consumed by each subscriber

Application-Based Charging: classification of traffic on the basis of application

type to allow personalized and tailored packages

Turbo Boost: allow subscribers to temporarily boost service plans

Each use case can be implemented to cut cost as well as generate revenues. For

example: Happy hour can reduce traffic load during peak hours, as well as

generate revenues from customers subscribing to the happy hour package. The

operator can choose how exactly they want to implement each use case.


Introduction 1-9

In this section, we will examine the needs of the customers in more detail

and review a few of the use cases which you can offer to your subscribers

using Allot technology.

Before being introduced to Allot solutions, typical service provider

customers have minimal visibility on their network. Subscribers complain

of poor quality of experience, as the network is constantly clogged up with

bandwidth-hungry peer to peer applications and streaming video. Every

time the network is expanded to free up more bandwidth, costs increase,

and the congestion is quick to return. With internet access fast becoming a

commodity, pricing is flat and access based, and revenue growth declines.

The solutions for service providers which you will encounter in this training

course give them insight at an application level, a subscriber level, a

device level and a topology level. Applications can be controlled to free up

bandwidth on the existing infrastructure and enhance quality of experience

for subscribers. Furthermore, providers can add unique, differentiated

service plans to their customer offering which increases revenues through

new tiered pricing systems.


Introduction 1-10

Before being introduced to Allot solutions, typical enterprise customers

also have minimal visibility on their network. The network is congested and

users are complaining of poor quality of experience. The IT manager has

few tools at his disposal to properly analyze the cause of this congestion

and to mitigate it. Each time more bandwidth is purchased, it is quickly

used up. The constant and growing threat of denial of service attacks only

adds to the IT managers headache.The solutions for enterprises which you will encounter in this training

course give the IT manager the visibility he or she needs to understand

the reasons for network congestion and to act accordingly. By intelligent

allocation of bandwidth, the IT manager can ensure that mission-critical

applications are protected and employee productivity is maintained.

Furthermore, rapid detection of abnormal network behavior enables a

quicker and more informed reaction to network attacks.


Introduction 1-11


Introduction 1-12

Throughout this ACTE training course, we will be encountering several key

terms. In this section, we define these key terms, so that their meaning will

be clear from the outset.


Introduction 1-13

In order to control the network traffic, we must first of all, classify it. Allots traffic management solutions are based on a clear classification hierarchy.

The first level of classification is the line. Multiple lines can be defined, and

each line is divided into several pipes. Each pipe is further divided into

virtual channels which we will refer to from now on as VCs.

The user can define any number of Lines, Pipes or VCs up to the

maximum allowed by his license, and all traffic is classified into a Line, a

Pipe and a VC. For each Line, Pipe and VC that you create, you may

define a rule.


Introduction 1-14

Here we see an example of how the structure of lines, pipes and VCs

serves the needs of a service provider. This particular service provider has

chosen to use three levels of hierarchy. Its aims are to guarantee a quality

of experience for each of its subscriber types, and to control the heavy

traffic generated by peer to peer applications.

At the line level it divides its traffic between domestic users and business

users. Each line is divided between two pipes, based on the importance of

the business subscriber or the location of the domestic subscriber. Virtual

Channels are then used to distinguish between different applications.


Introduction 1-15

Here we see a second example, this time from an enterprise customer

using 2 levels of hierarchy. In this case, the enterprise classifies traffic to

and from its different branch offices into pipes. VCs are used for the

different applications.


Introduction 1-16

A traffic policy is made up of a series of Rules.

In order to create rules, we use predefined conditions and actions that

have been stored in catalogs. Catalogs can therefore be seen as the

building blocks of rules. There are several different types of catalogs - host

or service catalogs for example, are used for conditions, while the quality

of service catalog is used as an action. The ToS catalog can be used to

define both conditions and actions.

A rule consists of one or more conditions plus one or more action.

The catalog entries that you define can be global. This means that the

same catalog entries can be used in the definition of different pipe or

virtual channel rules

We will examine how to create condition and action catalog entries in

module 5 and 6 respectively.

The different rules are created in the policy table in the NetXplorer User

Interface and are organized in a hierarchy. Together, these different rules

form what is know as a policy

In module 7, we will show how to build a traffic policy.


Introduction 1-17

Here we see an example that illustrates how to create a rule. The first step

is to define catalog entries. These catalog entries will serve as either

conditions or actions, and they are centrally defined so that they can be

used and re-used to create any number of different rules.

We then take the conditions and actions that have been defined, and put

them together to create rules.


Introduction 1-18

Here you can see the enforcement policy table in the NetXplorer with the

default line, pipe and VC rules.


Introduction 1-19

In this final section, we will introduce the basic architecture of the

NetXplorer managed solution


Introduction 1-20

This is the basic core architecture for Allot Solution. The architecture

consists of three layers:

The DART layer. There can be several NetEnforcers or Service Gatewaydevices that implement the network management policies and collect

network usage data, directly from the physical lines.

The Server Layer. This incorporates the actual NetXplorer application, including the databases. Managing and communicating with the different

clients that access the system, it facilitates NetEnforcer or Service

Gateway configuration, policy provisioning, alarms, monitoring and

reporting. The NetXplorer also includes an integrated data collector, that

streamlines the required collection of data from the managed in-line

platforms.

User Interface Layer. The user interface can be installed on any computer on the network that can connect to the NetXplorer server, and

allow NetXplorer users full access to NetXplorer functionalities.An additional element, the distributed short term collector, is an optional element (mandatory when using Service Gateways) that enables

more NetEnforcer devices to be supported by a single NetXplorer server.

This element is discussed in full in the advanced ACPP training course.


Introduction 1-21

In addition to the core functionally described in previous slide, Allot offers

subscriber aware solutions. Here is a basic representation of the

architecture required to make the solution subscriber aware:

Subscriber Management Platform (SMP) allows to dynamically map allocated IP addresses to the individual subscribers using them. This

information can then be used to create tiered subscriber service plans and

to provision different Quality of Service (QoS) policies per each

subscribers group. It is also possible to configure quota based service

plans that allow providers to meter and control individual use of

applications and services. The SMP can also serve as a PCEF (Policy and

Charging Enforcement Function) in 3GPP mobile networks.

This element is discussed in full in the advanced SMP training course.


Introduction 1-22

In addition to the core functionally described in previous slides, Allot offers

many value added services for both the network level and subscribers

level. Lets review some of them:

Service Protector is an attack detection and mitigation service that protects commercial networks against Denial of Service (DoS/DDoS)

attacks, zero day attacks, worms, zombies and spambot behavior. It

consists of the controller (SP-C) which is the management server, and the

sensor (SP-S) which is reading mirrored traffic from the physical line itself

and is normally embedded into the in-line platform itself.

This element is discussed in full in the advanced CSPA training course.

Media Swift (MSW) is an intelligent media caching and acceleration service that significantly enhances the user experience and dramatically

reduces operational costs associated with delivery of over-the-top video

applications, HTTP file downloads and P2P traffic.

This element is discussed in full in the advanced CMSA training course.


Introduction 1-23

Fill the gaps


Introduction 1-24

Match the architecture layer with the component parts

Module 2

Introducing In-Line

Platforms

In this module, we will introduce you to the Allot In-Line Platforms the

NetEnforcer and Service Gateway families. By the end of this module,

you will:

Be familiar with the main functions of the NetEnforcer and Service Gateway

Know how to differentiate between the different NetEnforcer and Service Gateway models and how to decide which model is suitable for

which case

Understand the factors to take into consideration when deciding where in a network to place the products.

Know how to connect the product to its bypass unit (where relevant) and to the network.

Be able to perform initial and advanced configuration

Introducing Allot In-Line Platforms 2-2


What is the NetEnforcer? The NetEnforcer is an in-line platform which

collects traffic statistics and can implement quality of service on a network

per application and per subscriber.

Traffic statistics are collected in order to provide both real-time and long-

term data about the network. Real-time monitoring information, enables

the customer to know exactly what is happening on the network at any

given moment. It provides the customer with a tool for troubleshooting the

network should any unexplained delays be experienced. The NetEnforcer

also provides long term data about the network. Customers can use this

data to generate long-term usage reports to gain a detailed insight into

usage patterns and trends. This data can also be exported to other

databases and billing applications, extending the benefits of the

information provided.

As well as collecting detailed information about the traffic passing through

it, the NetEnforcer can also shape that traffic, applying quality of service

parameters which have been pre-defined by the user. The methods of

implementing the quality of service are varied and include guaranteeing

and limiting throughput, as well as prioritizing between different types of

traffic. These and other methods will be discussed in detail later on.



What is the Service Gateway? Based on Allot's DART engine, the Service

Gateway platform is used for enhanced service optimization and service

deployment. In addition to the features of the NetEnforcer described

earlier, (the ability to collect network and subscriber statistics and shape

network and subscriber traffic), the Service Gateway is used by service

providers to deploy new services for the network as a whole and for

subscribers who have signed up to them. Application and subscriber

information within the Service Gateway are identified for each traffic flow

and the flows are subsequently dispatched to an array of additional

services and actions using a single process. The Service Gateway is a

powerful solution to optimize, monetize and personalize fixed/mobile

broadband services.



Here we can see the different performance levels offered by Allot in-line

platforms. Starting at 400Mbps, with the NetEnforcer AC-500 and reaching

up to 160Gbps with a fully populated SG-Sigma E14. We will examine

each series in detail.

Each in-line platform runs Allot Operating System (AOS) software

versions.



Before we start reviewing each series, lets review some basic

terminology.

Each physical link on the NetEnforcer or Service Gateway is represented

by two ports, one labeled internal and the other, external. You will see that

the different models of the in-line platforms support different number of

physical links.

The NetEnforcer or Service Gateway can view all of the traffic passing

through it as one entity, irrespective of the number of physical links on the

unit and irrespective of the specific port through which the network traffic

enters and leaves the unit.

If required, the in-line platform can classify traffic by one or more physical

interfaces. This is done by using the interface catalog, which we will

review in Module 05: Condition Catalogs.

In every model, a single management link serves for the management of

all of the traffic flowing through the in-line platform



The Bypass module is a mission-critical subsystem designed to ensure

network connectivity at all times. The Bypass mechanism provides

"connectivity insurance" in the event of a NetEnforcer or Service Gateway

subsystem failure.

While the NetEnforcers in the AC-500 series come with built-in bypass

support, all other products require an external bypass unit and it is a

compulsory part of the product installation. For Service Gateway it is

possible to have the Bypass module as an internal blade or as an external

unit.

The Bypass module is connected to the in-line platform by a series of

leads and cables.

When the in-line platform is powered on it validates that it is connected to

a bypass. If you attempt to power on an in-line platform that is not

connected to a Bypass, boot will fail.

The SYSTEM LED on the NetEnforcer will light up when the NetEnforcer

is in active mode, and will be extinguished when the NetEnforcer goes into

bypass mode. For Service Gateway, each blade has an Out of Service

LED to indicate when the blade is in bypass mode.



Here we see examples of the multiport copper and fiber bypass units.

Each bypass unit has 4 pairs of connectors (internal and external) which

are connected to the network.

For each pair of connectors to the network, there is also a pair of

connectors labeled To NetEnforcer, which are connected to the NetEnforcer (or Service Gateway)

In addition, each bypass unit has a primary connector for connection to the NetEnforcer backup port, and a secondary connector which is used in some of the redundant configurations discussed in later in this

module.

Allot bypass works as a passive bypass. This means it does not consume

power on its own, and will allow traffic to pass through in cases of power

outage for the in-line platform.



We will now focus on the NetEnforcer platform. Lets examine its

features, models and functionality.



The Allot NetEnforcer Series comes with speed ranges between 10Mbps

(the entry level of bandwidth control for an AC-500) up to 8Gbps (the

maximum bandwidth control of an AC-3040). There are three different

NetEnforcer product series:

The AC-500 series of entry level management devices are especially suitable for small to medium enterprises. Different levels of bandwidth

control can be ordered up to a maximum of 400 Mbps. Each product in the

series can support up to 256,000 connections, 256 lines, 4,096 Pipes and

32,768 VCs.

The AC-1400 series of bandwidth management devices are particularly suited to medium and large enterprises. The maximum bandwidth control

that can be ordered is 2Gbps.

The AC-3000 series of bandwidth management devices are suited to medium and large enterprises and small broadband service providers. The

maximum bandwidth control is 8 Gbps. Both the AC-1400 and AC-3000

series products support up to 2 million connections. The products come by

default with support for a full policy of up to 256 lines, 40,000 Pipes and

80,000 VCs.



The AC-500 offers high-end bandwidth management on a small scale

platform. It is targeted at enterprise networks, universities, satellite

environments and small service providers.

The AC-500 series consists of the AC-502 which has a single physical link

to the network and the AC-504 with two physical links.

Different levels of bandwidth control can be ordered on both units up to a

maximum of 200 Mbps full duplex (400 Mbps in total).

AC-500 is a 1U 19 rack mountable product

Unlike the other NetEnforcers, the AC-500 series products are available

only with copper interfaces. The network interfaces are

10/100/1000BaseT. AC-500 supports only copper cables.

Additional ports are available for active redundancy. This configuration is

covered at the last section of this module.

Note also that the AC-500 series products can only be ordered with an AC

power supply. Their other main distinguishing feature is a built-in bypass

unit. This will be discussed later.



Here we see the front view of the AC-502. Lets examine the front panel

from left to right.

On the left side, we see two LEDs system and PS. The system LED

shows the current status of the system (steady green functioning

normally; steady red error; off bypass mode), while the PS LEDs show

the status of the two power supplies (steady green functioning normally;

steady red not providing power; off malfunction)

Next to the LEDs is the console port and the 10/100/1000BaseT

management port. Next to that are the 2 copper interfaces of the

redundancy ports, followed by the 2 network ports (one for internal and

one for external). The bypass D-type connector on the far right side of the

front panel is not in use.

AC-504 has 2 additional redundancy ports and 2 more network links.

Otherwise its front panel is identical to the AC-502 we see here.



The AC-1440 and AC-3040 are similar products both have 8 network

ports for support of up to 4 physical links to the network. They also both

include an additional 4 copper ports which may be used when steering

traffic to external services or when connecting to an additional NetEnforcer

in a redundant configuration.

The main feature that distinguishes between the two products is the

different maximum throughput and the levels of QoS enforcement that are

supported. The AC-1440 supports up to 2Gbps, meaning 1Gbps full

duplex, with QoS enforcement steps of 45Mbps, 100Mbps, 200Mbps,

400Mbps and 1Gbps. The AC-3000 supports up to 8Gbps, meaning

4Gbps full duplex with QoS enforcement steps of 1, 2 or 4Gbps.

Both of the products in the series can support up to 2,000,000 connections

(4,000,000 flows) and a total of 256 lines, 40,000 Pipes and 80,000 VCs.

The 8 network interfaces can be 10/100/1000Base-T Copper (auto-

negotiation) or 1000Base-SX/LX/ZX

The 4 extra service interfaces are 10/100/1000Base-T copper only.



Here we see the front view of the AC-3040, which is virtually identical to

the front view of the AC-1440. Lets examine the front panel from left to

right.

On the left side, we see three LEDs system, PS-1 and PS-2. The

system LED shows the current status of the system (steady green

functioning normally; steady red error; off bypass mode), while the PS

LEDs show the status of the two power supplies (steady green

functioning normally; steady red not providing power; off malfunction)

Next to the LEDs is the console port and the 10/100/1000BaseT

management port. Next to that are the 4 copper interfaces of the service

ports, followed by the 8 network interfaces. The bypass D-type connector

on the far right side of the front panel is used to connect the NetEnforcer

to its bypass unit.



The Service Gateway is a separate Allot product line lets now

examine the Service Gateway, its features and functionality.



The Allot Service Gateway Series is a carrier-grade, highly scalable

platform for enhanced broadband service optimization based on Allots

DART technology.

Using the Advanced TCA (ATCA) standard 14 slot chassis, the SG-Sigma

series offers a throughput of up to 60 Gbps. It can support up to 20 million

connections and a policy with up to 512 lines, 500,000 pipes and

1,000,000 VCs, when fully populated with 4 CC-200 blades.

The SG-Sigma E offers extreme performance values and comes in two

models:

SG-Sigma E6, using an ATCA standard 6 slots chassis, offers up to 64

Gbps, up to 20 million connections and a policy with up to 512 lines,

400,000 pipes and 800,000 VCs, when fully populated with 4 CC-300

blades.

SG-Sigma E14, using an ATCA 14 slot chassis, offers up to 160Gbps, up

to 50 million connections and a policy with up to 512 lines, 1,000,000

pipes and 2,000,000 VCs, when fully populated with 10 CC-300 blades.

These maximum values supported depend on the number of Core

Controller blades deployed in each platform. The CC-200, used in the SG-

Sigma, supports 15Gbps. The CC-300, used in the SG-Sigma E supports

16Gbps. Both types of blade support 5 million connections and a policy

with 512 lines, 125,000 pipes and 250,000 VCs.



Here we see a close-up view of the SG-Sigma chassis. The particular

chassis on view is a fully populated 60Gbps SG-Sigma. The standard

ATCA chassis has 14 slots numbered from left to right.

Each of the blades can be seen here: the SGSV-100 (the server blade),

the CC-200 (Core controller blades), the SFC-200 (Switch Fabric

Controller blades) and the FB-200 (Flow Balancer blades). We can also

see the BP-204 (internal bypass blade), although it is possible to order the

unit with an external bypass unit instead.

The Shelf Management Controller (SMC) is in the bottom left side of the

chassis, while the Shelf Alarm Display (SAD) and Shelf Alarm Panel (SAP)

are at the top. Now lets examine the role of each of the blades in turn.



Here are the different blades used in the SG-Sigma and their main functionalities.

The SGSV-100 is the server blade, responsible for application management of the chassis. Statistics from each of the CC-200 blades are aggregated on the

SGSV-100 blade, and it is on this blade that administration of the chassis is

performed.

The CC-200, a double-slot blade is the core controller. It is here that DART processes are implemented on the traffic passing through the network. When the

SG-Sigma is deployed together with the ServiceProtector, CC-200 can also

serve as SP-Sensor, which is monitoring traffic from the physical line itself

searching for network or subscriber anomalies. In addition, it stores dynamic

signatures used for attack mitigation.

The SFC-200 is the Switch Fabric Controller and serves as a backplane switch for network & management traffic. The network traffic enters the system from the

bypass via this blade, and redirected traffic is also connected here. The ETH

management connections are also located on the SFC, which serves as an

interface to external servers (NX/SMP/STC)

The FB-200 is the Flow Balancer. This serves as the traffic dispatcher and decides to which core controller to dispatch each traffic flow.

The NSS blades are used for Network and Subscriber Services. For example, the NSS-MS is the MediaSwift caching engine used for caching HTTP streaming video and/or PeertoPeer traffic.

Finally the BP-204 blade is an internal bypass blade which bypasses network traffic on failure.



How many blades are required and in which slots? The answer depends on the

customer requirements, but the guidelines below help explain the logic behind

the different SG-Sigma configurations.

SGSV-100 Blades: Only one SGSV-100 blade is used in all configurations, installed in slot number 1.

SFC-200 Blades: The minimum officially supported configuration requires two SFC-200 blades which must be installed in slots 7 and 8.

NOTE: SFC-200 is also available with 8 x 1G ports (instead of 4 x 10G ports)

CC-200 Blades: Each CC-200 blade requires two slots in the chassis. Up to four CC-200 blades can be installed (in slots 2/3, 4/5, 10/11 and 12/13) supporting up

to a maximum of 60Gbps. The throughput growth path is from left to right, with

each CC blade supporting 15Gbps (meaning 7.5Gbps full duplex). To deploy an

SG-Sigma with 30Gbps throughput for example, 2 x CC-200 blades must be

installed in slots 2/3 and 4/5.

FB-200 Blades: Each FB-200 blade supports up to two 10Gbps network links. If a single FB-200 blade is required, it must be installed in slot 6. If support is

required for 3 or 4 links an additional FB-200 is required. These two FB-200

blades must be installed in slots 6 and 9. The FB-200 in slot 6 supports the

network links in port 5 & 6 of each SFC-200. The FB-200 in slot 9 supports the

network/HA link in port 7 and 8 of each SFC-200.

BP-204 Blades: For 10GE configurations, the BP-204 blade is deployed in slot 14. For 1GE fiber configurations, it is possible to deploy two BP-204 blades, in

slot 13 and slot 14.



The SG-Sigma is a modular platform which enables the customer to start

small and grow organically without losing any functionality. As the needs

grow, you can add additional capacity, interfaces and services. Here we

see 4 sample configurations of the SG-Sigma, and the different blades

required for each one.



Here we see a close-up view of the SG-Sigma E6 chassis. The particular

configuration on view is a fully populated SG-Sigma E6 supporting up to 8

x 10GE ports and a throughput of up to 64Gbps.

The standard ATCA chassis has 6 slots numbered from bottom to top.

Two types of blades can be seen here: the SFB-300 (Switch Flow-

Balancer Blade) and the CC-300 (Core controller blades)


chassis, and there are two fan trays on the left and right of the front panel

which are designed for full redundancy to meet the cooling requirements

of a full shelf in the most demanding situations.



Here we see a close-up view of the SG-Sigma E6 chassis rear. The RBS-

300 is a rear transition module blade, connecting on the rear part of the

chassis. The two RBS-300s are connected in slots 1 and 2. These blades

must be inserted BEFORE inserting the SFB-300s to the chassis. At the

bottom of the rear panel we see the 3 AC power inlets.

Now we will examine each of the blades in turn.



Here we see a close-up view of the SG-Sigma E14 chassis. The particular

configuration on view is a fully populated SG-Sigma E14 supporting up to

16 x 10GE ports and a throughput of up to 160Gbps.

The standard ATCA chassis has 14 slots numbered from left to right.

Two types of blades can be seen here: the SFB-300 (Switch Flow-

Balancer Blade) and the CC-300 (Core Controller blades)


chassis, while the Shelf Alarm Display (SAD) and Shelf Alarm Panel (SAP)

are at the top.



Here we see a close-up view of the SG-Sigma E14 chassis rear. Two

types of rear transition module blades, the RBS-300 and RBL-300 blade

connect on the rear part of the chassis. The two RBS-300s are connected

in slots 7 and 8, while the two RBL-300s (required only when there are 4 x

SFBs inserted in the front) are connected in slots 6 and 9. These blades

must be inserted BEFORE inserting the SFB-300s to the chassis. At the

top of the rear we see the 3 fan trays and at the bottom, the two Power

Entry Modules (PEMs).



Here are the different blades used in the SG-Sigma E and their main

functionalities.

The CC-300 is the core controller blade. It is a single slot blade. It is here that DART processes are implemented on the traffic passing through the network.

When the SG is deployed together with the ServiceProtector, CC-300 can also

serve as an SP-Sensor, which is monitoring traffic from the physical line itself

searching for network or subscriber anomalies. In addition, it stores dynamic

signatures used for attack mitigation.

The SFB-300 is a blade combining the functionalities of the FB-200 and the SFC-200 on the SG-Sigma. It dispatches traffic to the different core controllers

and serves as a network switch. In slot 7 the SFC-300 also serves as the host

blade, responsible for chassis application management.

RBS-300 is a rear base blade, serving as the management switch in conjunction with the SFC-300 blade in slots 7 & 8.

RBL-300 is a rear base blade, with no switch functionality. It is required for the proper operation of the SFC-300 in slots 6 & 9.

The NSS blades are used for Network and Subscriber Services. For example, the NSS-MS is the MediaSwift caching engine used for streaming video and/or Peer to Peer caching.

The 1GE-300 blades are an interface blade enabling additional 1GE ports which can be used for network connectivity and/or external direct redirection.

Finally the BP-204 blade is an internal bypass blade which bypasses network traffic on failure.



How many blades are required and in which slots? The answer depends on the

customer requirements, but the guidelines below help explain the logic behind

the different SG-Sigma E6 configurations.

Between 1 (minimum) and 4 (maximum) CC-300 blades are supported, and these should be placed in the chassis from bottom to top (1st CC in slot #3, 2nd

CC in slot #4 etc.). All slots can be used for the core controllers except 1 and 2.

As each Core Controller supports 16Gbps, a fully populated SG-Sigma E6 with 4

Core Controller blades will support 64Gbps throughput.

Either 1 (min) or 2 (max) SFB-300 blades can be installed. A minimum configuration of 1 x SFB-300 will enable support for 2 x 10GE links using ports

L3-L6 on each SFB. This blade must be installed in slot 1. The maximum

configuration has 2 x SFB blades installed in slots 1 and 2 and gives support for

8x10GE ports using L3-L6. Up to two RBS-300 blades will be installed in the rear of the chassis, in accordance with the number of SFB-300 blades installed.

Between 0 (when not required) and 2 1GE-300 blades can be installed. When used in slots 3,4, the 1GE-300 blades can be used for network ports. When used

in slots 5,6 the 1GE-300 blades can be used for external direct redirection only.

Note the impact on SFB port usage! When you use the 1GE-300 in slots 3 and 5,

ports 3 and 4 of the SFB in slot 1, can only be used as 1G. When you use the

1GE-300 in slot 4 and 6, ports 5 and 6 of the SFB in slot 1 can only be used as

1G.

A single BP-204 blade is deployed in slot 6 for up to 4X10G links.For more guidelines, please refer to Allot SG-Sigma E6 Hardware Guide.



Here are the guidelines for different SG-Sigma E14 configurations.

Between 2 (minimum) and 10 (maximum) CC-300 blades are supported, and these should be placed in the chassis from left to right (1st CC in slot #1, 2nd CC

in slot #2 etc.). All slots can be used for the core controllers except 6-9. As each

Core Controller supports 16Gbps, a fully populated SG-Sigma E14 with 10 Core

Controller blades will support 160Gbps throughput (full duplex).

Between 2 (minimum) and 4 (maximum) SFB-300 blades can be installed. A minimum configuration of 2 x SFB-300s will enable support for 8 x 10GE ports

using L3-L6 on each SFB. These blades must be installed in slots 7 and 8. An

additional possibility is to use 3 x SFB-300s installed in slots 6,7 and 8 to ensure

support for 12 x 10GE ports using L3-L6. Finally, the maximum configuration has

4 x SFB blades installed in slots 6,7,8 and 9 and gives support for 16 x10GE

ports using L3-L6.

Between 0 (when not required) and 4 (maximum) 1GE-300 blades can be installed. When used in slots 6,9, the 1GE-300 blades cab be used for network

ports. When used in slots 1,2 the 1GE-300 blades can be used for external direct

redirection only.

Note the impact on SFB port usage! When you use the 1GE-300 in slot 6&9,

ports 3&4 of the SFB in slot 7&8 can only be used as 1G. When you use the

1GE-300 in slot 1&2, ports 5&6 of the SFB in slot 7&8 can only be used as 1G.

For all configurations with up to four links, a BP-204 blade is deployed in slot 14. For more than 4 links, you can deploy two BP-204 blades, in slots 13&14.

For more guidelines, please refer to Allot SG-Sigma E14 Hardware Guide.



The SG-Sigma E is a modular platform which enables the customer to

start small and grow organically without losing any functionality. As the

needs grow, you can add additional capacity, interfaces and services.

Here we see 4 sample configurations of the SG-Sigma E, and the different

blades required for each one.



Lets briefly discuss the different types of fiber cables which can be used

with the in-line platforms. Multi mode fiber contains several rays of light

and travels for lesser distances. Single mode fiber contains one ray of light

and can travel longer distances. Allot products supporting 1GE fiber can

be ordered with standard SX, LX or ZX fiber.

The 1000Base-SX runs over multimode fiber. The wavelength of the central wave transmitted/received is 850nm. SX is used for distances up

to 550m, depending on the fiber core diameter and loss/Km.

The 1000Base-LX runs over single mode fiber with a wavelength of 1310nm. The standard comes in two flavors - LX5 & LX20, used for

distances of up to 5km & 20km respectively.

The 1000Base-ZX runs over single mode fiber with a wavelength of 1550nm. It is mainly used for long distances (up to 80km) therefore the

laser beam is very powerful. If ZX is used for short distances (20 km and

less), the powerful laser beam can damage the equipment.

Allot products supporting 10GE fiber can be ordered with standard SR(multimode) or LR (single mode) fiber. The Service Gateway also supports ER fiber.All 1GE cables use the SFP transceiver. All 10GE cables use the SFP+

transceiver.

Make sure both endpoint use the same interface, and bypass unit also

uses the same interface.



In this section, we understand the factors to take into consideration

when deciding where in a network to place the products



If the NetEnforcer or Service Gateway is to monitor and reshape traffic,

then the traffic that you would like to reshape must first be identified. The

in-line platform must be placed on the network where all relevant traffic

can flow through it.

The ideal location will vary depending on the network configuration and on

the customers requirements.The first question to ask therefore is - what are we trying to achieve?

For a service provider are we trying to control traffic per application, to deploy services on a network level or to tailor packages with value added

services per subscriber ?

For an enterprise are we trying to optimize the Internet link or the WAN links to remote sites?

In both cases, understanding what the customer is trying to achieve is the

first step to deciding where to place the in-line platform on the network.

Lets look at the case of the service provider and the enterprise now in

turn.



For the Service Provider, the guiding principle is that the in-line platform

should be placed in a position on the network where as much of the traffic

as possible flows through it. Only traffic that flows through the SG or NE

can be monitored and shaped. Typically there are two placement options

in a service provider network at the access point or at the peering point. By access point we mean deploying the in-line platform straight after the

BRAS or CMTS.

While a deployment at the Peering Point, usually requires a relatively

small number of devices, an in-line platform at the peering point will only

be able to see and control the traffic that goes outside of the SPs domain. On the other hand, a deployment at the Access Point may require more

NEs or SGs, but the devices deployed can see and control all of the traffic,

including that which is terminated inside the providers network.



Here we see the typical placement of an Allot Service Gateway in a 3G

mobile network. If required, Allot Service Gateways or NetEnforcers

(working together with the SMP) can serve the purpose of a PCEF (Policy

and Charging Enforcement Function) integrated with a PCRF (Policy and

Charging Rules Function) and online or offline charging systems.

Communication takes place using protocols from the standard Diameter

stack. This topology is fully described in the SMP training course when we

discuss Allots Subscriber Management Platform (SMP).



In an Enterprise network, the in-line platform deployed will typically be a

NetEnforcer. The NetEnforcer should be placed at (or as close to) the

exact location of the bottleneck.

On the Internet link, the NetEnforcer is therefore placed directly before the

Internet router. Placement of the NetEnforcer in relation to a firewall will be

discussed in the next slide.

On the WAN link in a branch environment, the NetEnforcer should be

placed next to the outgoing router that links the local area network with the

remote branches. Firewalls are not usually an issue here, since the WAN

links are connected only to the branches and are therefore private. This

means that the NetEnforcer can be connected directly between the WAN

router and the LAN.



Where should you position the NetEnforcer with relation to the enterprise firewall? Where the firewall performs network address translation (NAT), it may make sense to place the NetEnforcer before the firewall. Placing the NetEnforcer after a firewall which performs NAT means that the NetEnforcer will not be able to filter traffic by internal host.

Placing the NetEnforcer before the firewall may not always be an immediate choice however particularly in cases where the customer has a DMZ connected to its firewall. A DMZ is the semi-protected area where equipment that needs to be accessed from both outside and inside the firewall is placed. In such a case, traffic flows from the LAN to the WAN, and from the LAN to the DMZ.

The first possible disadvantage is that a NetEnforcer placed inside the firewall will not be able to monitor traffic which flows from the WAN to the DMZ without entering the LAN.

A second disadvantage relates to traffic flowing from the LAN to the DMZ which normally flows at LAN speed, but may be unnecessarily limited. If the NetEnforcer is set to control 10Mbps on the internal link and 2Mbps on the external link, the NetEnforcer assumes the traffic flowing to the DMZ is actually going out to the WAN; it therefore limits the output to a total of 2 Mbps. This can have a big impact on bandwidth management.

To overcome this problem, it is possible to define a policy (VC or Pipe) for such traffic. The NetEnforcer can be configured to ignore it, as it is LAN traffic and does not need to be managed. NetEnforcer comes with a predefined ignore QoS quality of service entry.



In this section, we will learn the procedure for physically connecting the

NetEnforcer or Service Gateway to its bypass unit where appropriate and

to the network



We will begin by seeing how to connect the In-line platform. To make sure

installation of the In-line platform and its bypass does not disturb the traffic

flow, install one step at a time and validate traffic flow after each step. You

can validate traffic flow by using ping, checking if the devices are

reachable and the time it takes to reach them.

Install in the following order

1. Before installation make sure there is traffic flow in the location where

you are about to install the In-line platform

2. Connect the bypass only

3. Connect the In-line platform to the bypass with ethernet cables and

the bypass cable. Keep the In-line platform turned off. When the In-

line platform is powered on it validates that it is connected to a

bypass. If you attempt to power on an In-line platform that is not

connected to a Bypass, boot will fail. Make sure cables are secure.

4. Power up the In-line platform. Verify traffic flow.



The exact layout of the interface status indicators depends on the

particular NetEnforcer/ or Service Gateway hardware, but the significance

of the LEDs is the same for all:

A lit LINK LED (green) indicates that a link is detected.

A blinking ACTIVITY LED (amber) indicates that traffic is detected on the

interface.



Here we see an example of how to connect a Copper AC-3040, which

has four physical links to the network.

1. Connect the External cable from the External port (Link 1) on the

Bypass Unit to a router (100Base-T) connector.

2. Connect the Internal cable from the Internal port (Link 1) on the Bypass

Unit, to a switch connector.

3. Repeats Steps 1 and 2 for Links 2 to 4.

4. Connect the External cable from the To NetEnforcer External port (Link 1) on the Bypass Unit to the External port on the NetEnforcer

(Link 1).

5. Connect the Internal cable from the To NetEnforcer Internal port (Link 1) on the Bypass Unit to the Internal port on the NetEnforcer

(Link 1).

6. Repeats Steps 4 and 5 for Links 2 to 4.

7. Connect the D-type High Density connector from the Primary port on

the Bypass Unit to the Backup port on the NetEnforcer.



Lets now see three examples of connecting the Service Gateway to the

Network. In the first example, 4 x 10Gbps links are connected to SG-

Sigma via an internal bypass blade. In the second example, 2 x 10Gbps

links are connected to SG-Sigma E6 via an external bypass unit. In the

third example, 4 10Gbps links are connected to SG-Sigma E 14 via an

external bypass unit.



WARNING: Make sure you follow all safety instructions mentioned in the SG-Sigma Hardware Guide. FAILURE TO COMPLY CAN RESULT IN

PERSONAL INJURY!

At the rear of the Service Gateway chassis you will find two Power Entry

Modules (PEM).

First of all connect the protective ground before connecting any external

power.

Then connect the 4 domain power cables (red) and the 4 return power

cables (black) as per instructions in the hardware guide.

NOTE: Full specifications for input and output power cables can be found

in the SG-Sigma Hardware Guide.



Here we see how to connect an SG-Sigma with 4 x 10GE links to the

network via an internal bypass unit. Install in the following order:

1. Connect Network links to BP-204 unit: from Internal & External port

(Link 1) of the bypass unit, to the network. Do the same for Link2-4.

2. Verify traffic flow

3. Connect FB-200 to SFC-200 using 10GE fiber cables as follows:

Connect the L1 port on the SFC-200 in Slot 7 to the 10G 1 port on the

FB-200 in slot 6

Connect the L1 port on the SFC-200 in Slot 8 to the 10G 2 port on the

FB-200 in slot 6

Connect the L2 port on the SFC-200 in slot 7 to the 10G 1 port on the

FB-200 in slot 9

Connect the L2 port on the SFC-200 in slot 8 to the 10G 2 port on the

FB-200 in slot 9

4. Connect the spider connectors on the BP-204 blade to L5-L6 and L7-

L8 on each of the SFC-200 blades

5. Power up chassis




Here we see a schematic which summarizes port usage of the 8 SFC-200

ports for the SG-Sigma. For an SG-Sigma with 10GE links, L1 and L2 will be used to connect the SFC-200 with fiber cables to the FB-200 blade. L1

connects to the left hand flow balancer (installed in slot 6), while L2

connect to the right hand flow balancer (installed in slot 9).

L3 & L4 will be used for Asymmetric Control Traffic or Media Swift Storage.

L3 on the left hand SFC (installed in slot 7) is used for asymmetric control

traffic in asymmetric configurations. Note that asymmetric traffic comprises

approximately 5% of the total network traffic. In such configurations, using

L3 will consume some of the resources of L5. (Similarly, using L4

consumes some of the resources of L6).

L5 & L6 will be used for either network traffic, external VAS or internal VAS resource use.

NOTE: L3 & L4 can be set to be network ports together with L4 & L5,

when only 2 ports can be active at the same time. This can be used for

specific deployments in networks with redundant links.

L7 & L8 will be used for either network traffic, external VAS or internal VAS resource use.

Consult the SG-Sigma Hardware Guide for more guidelines.



Here we see how to connect an SG-Sigma E6 with 2 x 10GE ports to the

network via an external bypass unit. Install in the following order:

1. Connect Network links to bypass unit


3. Connect SFB-300 fiber ports to Bypass unit (Internal or External)

4. Connect bypass PRIMARY port to the SFB-300 (slot 1) bypass port

with bypass cable

5. Power up chassis


7. Add other links in a similar way



Here we see how to connect an SG-Sigma E14 with 4 x 10GE links to the

network via an external bypass unit. Install in the following order:

1. Connect Network links to the bypass unit

2. Verify the traffic flow

3. Connect SFB-300 fiber ports to the Bypass unit (Internal or External)

4. Connect the bypass PRIMARY port to the SFB-300 (slot 7) bypass port

with the bypass cable

5. Power up the chassis


7. Add other links in a similar way



Here we see a schematic which summarizes port usage of the 8 SFB-300

ports for the SG-Sigma E. L1 and L2 will be used for Asymmetric Control Traffic or Media Swift Storage.

L3,L4,L5 & L6 will be used for network links and, if required, External Switched Redirection.

NOTE: L1 & L2 can be configured as network ports together with L3 & L4,

when only 2 ports can be active at the same time. This can be used in

specific deployments for networks with redundant links.

Consult the SG-Sigma E Hardware Guides for more guidelines.



The port usage of each SFC-200 and SFB-300 on the Service Gateway

can be defined from the NetXplorer GUI by choosing a NetEnforcer or

Service Gateway from the network tree and selecting configuration. On

the NIC tab, you can click any of the boards in the picture and then double

click the relevant port below to set its usage as shown in the example on

the screen.



Now that we have physically connected our in-line platform to the network,

we will see how to perform initial configuration.



Before the in-line platform can be used in a live network environment, the network settings must be configured. For all in-line platforms:

1. A dedicated PC can be connected via a serial cable to the console port for initial IP settings

2. The management port is an Ethernet port intended solely for managing the in-line platform. Once the IP settings have been configured via the console port, a management port can be connected to the network, and any PC on that network can manage the NE or SG via Telnet or SSH as if he or she were directly connected via the console port.

3. Once all NetXplorer components have been installed, you can edit the NetEnforcer or Service Gateway configuration settings via the NetXplorer user interface.



Initial configuration of the SG-Sigma is achieved by connecting a local

serial connection to the console port on the SGSV-100 blade (in slot 1).

Subsequent management is then achieved via the M1 (and M2 if

redundancy is required) ports on the SFC-200 blade located in slot 7.



Before the Service Gateway Sigma E6 can be used in a live network environment, the network settings must be configured:

1. A dedicated PC can be connected via a serial cable to the console port of the SFB-300 in slot 1 for initial IP settings

2. The Mgmnt1 port is an Ethernet port on the SFB-300 blade in slot 1, intended solely for managing the SG-Sigma E6. Once the IP settings have been configured via the console port, a management port can be connected to the network, and any PC on that network can manage the SG via Telnet or SSH as if it was directly connected via the console port.

3. Once all NetXplorer components have been installed, you can edit the Service Gateway configuration settings via the NetXplorer user interface.



Likewise, before the SG-Sigma E14 can be used in a live network environment, the network settings must be configured:

1. A dedicated PC can be connected via a serial cable to the console port on the SFB-300 in slot 7 for initial IP settings

2. The Mgmnt1 port is an Ethernet port on the SFB-300 blade intended solely for managing the SG. Once the IP settings have been configured via the console port, a management port can be connected to the network, and any PC on that network can manage the SG via Telnet or SSH as if he or she were directly connected via the console port.For the SFB-300 the two management ports in the front are physically connected via the rear RBS Base management switch. The two ports connected will work as Active-Standby Lag sharing the same MAC and IP addresses. Once one of the ports goes down the other port will become active and will notify the network about the new management path

3. Once all NetXplorer components have been installed, you can edit the Service Gateway configuration settings via the NetXplorer user interface.



The admin user initially logs in with username sysadmin and password

sysadmin. IP configuration is performed by entering the go config ipscommand. Various syntax options are possible here. For example, to

configure an IP address of 10.50.1.7 with a network mask of 255.0.0.0,

you can enter: go config ips -ip 10.50.1.7:255.0.0.0.

Additional parameters you can define are as follows:

-h Hostname set host name of NE

-d Domain set domain name of NE

-g set gateway IP address

-dns |none set DNS IP addresses

-ts |none set NTP server IP addresses

-ip set IP/netmask of interface

A full list of sysadmin CLI commands is available in the Command Line

Interface chapter of the relevant NetEnforcer or Service Gateway

Hardware Guides.



By entering go config view, you can see a summary of the current configuration settings.



Amongst the information that can be viewed in the extended output is the

current status of the device (active or bypass)



We will now focus on some more advanced configurations, specifically

configurations for handling asymmetric traffic and redundancy.



In some network topologies the traffic flows of a single connection can

take different paths in the upstream and the downstream directions. This

can lead to a situation where one in-line platform on the network sees one

flow of the connection while another in-line platform that is located

remotely sees the complementary flow of the same connection. Since

Allots DART engine needs to inspect both flows of the connection for

maximum DPI accuracy, this leads to a poor identification of the

applications running in the network.

Asymmetric Traffic support is designed to significantly increase DPI

accuracy by allowing Service Gateway or NetEnforcer platforms to share

information concerning connections. This will ensure that two different

flows may be identified as part of the same connection, even when their

traffic is handled by different in-line platforms. Ideally, using Asymmetric

Traffic should provide the same percentage of DPI accuracy with remotely

located platforms as is found when a single in-line platform sees both

sides of the connection.

Asymmetric traffic handling is not supported on the AC-500.



Asymmetric Traffic information is synched between all devices that belong

to the same Asymmetric Device Group (ADG) which is configured via

NetXplorer. All devices in an ADG must be assigned to the same

NetXplorer and each NetXplorer may support up to eight ADGs. An ADG

can include co-located and remotely located devices. Co-located devices

are connected with an intra-site asymmetric control link. This link passes

control information between the co-located devices to sync the DPI

information. Remotely located devices are connected over an L2/L3

network.

Each ADG may be configured with up to eight devices and has a group ID

of 0 through 7. Each in-line platform configured to an ADG has a local ID

of 0 through 7. In this example we see an asymmetric group with 2 x

Service Gateways. Different VLAN tags identify the direction of the

asymmetric control traffic flowing between the Service Gateways or

NetEnforcers in the group. If traffic is recognized as being asymmetric,

asymmetric control traffic is sent between the devices in the asymmetric

group to ensure that protocols can be correctly identified.



Here we see an example where a single ADG (Group ID = 0) contains

three SG-Sigma E platforms (Group IDs = 0, 1 and 2). You can see from

the diagram that asymmetric control traffic interconnects between each of

the platforms, and different VLAN tags are defined for each direction of

control traffic between each Service Gateway.

An asymmetric control traffic switch is needed when 3 or more in-line

platforms are included in the configuration. This switch will also need to be

configured, as will be shown shortly.



In order to setup an asymmetric configuration, steps will need to be

performed in the NetXplorer GUI, and (in cases when more than 2

NE/SGs are included in the asymmetric device group) the switch or router

will also need to be configured.

In the NetXplorer, we need to create an asymmetric group, configure the

devices to be included in it, and then configure the VLAN IDs which tag

the asymmetric control traffic in each direction between each of the in-line

platforms in the asymmetric group.

If a switch or router is required, the SG-Sigma/NetEnforcer asymmetric

control access port in the 3rd party Switch should be configured to receive

asymmetric messages with their respective VLANs.

For details on the correct ports to connect on each SG or NE, see the

port usage section of this training module.

We will now examine these configuration steps in more detail.



Right click on the Network in the Navigation pane and select Asymmetry

Configuration OR Highlight the Network in the Navigation pane and select

Asymmetry Configuration from the View menu. The Asymmetry

Configuration dialog appears. Click add to add a new ADG. The

Asymmetry Group New dialog appears. Enter a Group Name and Description in the appropriate fields.Select the Enable Health Check checkbox if you wish NetXplorer to automatically confirm the health of all devices in the ADG.

Select the in-line platforms to add to the group from the drop down menus.

An ADG may include up to eight in-line platforms. The Device ID will be

established based on the order you place them in inside the ADG. For

example, if Sigma-1 is assigned with Number in Group = 0, then it will

have a Device ID of 0 for the purposes of Asymmetry.

Select the Asymmetry Enabled checkbox for each device.



Click the VLans Settings button to edit the VLAN configuration. The VLanSettings dialog appears. A VLAN must be set for each connection between

any two in-line platforms in the group. Each direction must have a VLAN to

be used for Asymmetric control messages (however the same number can

be used for both directions). Double click in a field to enter a new VLAN

number. Click Save to save the information and return to the Asymmetry Group New dialog. Click Save to save the new ADG.NOTE: if you wish to verify that your asymmetric group has been setup

correctly, two CLI commands are available from the NetEnforcer or

Service Gateway that will show you the current asymmetry configuration:

go config view asymmetry

go config view asymmetry_remote_device

Last, open your NetEnforcer / Service Gateway NIC setting (right click

device icon and go to configuration, NIC tab). Set the appropriate port to

have Asymmetry port usage.



Finally, lets examine how active redundancy works and the in-line

platforms on which it is supported



Active redundancy is recommended for network topologies where at least

two network links are active in load-balancing mode. It requires two

NetEnforcers and typically, no bypass units.

In the Active Redundancy configuration, each NetEnforcer manages a

single link while duplicating that links traffic to the other NetEnforcer. Both

NetEnforcers are active. Each unit shapes the traffic of one link only, but

the shaping algorithm considers traffic of both links.

In the event that one of the links fails due to router, switch or line

malfunction, the network redundancy mechanism (for example, spanning

tree) will ensure that traffic is routed or switched via the other link and

managed by the second NetEnforcer. Since both NetEnforcers maintain a

constant view of the two links, there will be no loss of flow state and other

information required for correct shaping and application classification.

In the Active Redundancy configuration, the two NetEnforcers should

share the same policy configuration.

NOTE Users should be aware that a NetEnforcer working in Active Redundancy mode duplicates all traffic passing through it. Therefore, the

overall throughput of each NetEnforcer in Active Redundancy will be half

of the throughput enabled by the current license key.

Supported Platforms for active redundancy are: AC-500, AC-1400 and AC-

3000.



Here we see how to connect two AC-500 NetEnforcers in Active

Redundancy mode:

Internal 1&2, External 1&2 are used to pass actual traffic these interfaces will be used to connect the NetEnforcers to the corresponding

switches or routers.

Redundancy ports: Internal 3&4, External 3&4 are used to duplicate traffic and pass it to the second NetEnforcer. Traffic that is passed

between NetEnforcers is not sent to adjacent network devices it is only

used for monitoring and classification purposes.

Both NetEnforcers should be running with the same software version and

the same policy.

NOTE: If the NetEnforcer Active Redundancy mechanism is implemented the internal bypass module should be disabled. This ensures that the

network is made aware of any failure and is able to smoothly transfer

traffic to the secondary link.



Here we see how to connect two AC-1400/AC-3000 NetEnforcers in Active

Redundancy mode:

Link 1 and 3 are used to pass actual traffic these interfaces will be used to connect the NetEnforcers to the corresponding switches or routers.

Link 2 and 4 are used to duplicate traffic and pass it to the second NetEnforcer. Traffic that is passed between NetEnforcers is not sent to

adjacent network devices it is only used for monitoring and classification

purposes.

Both NetEnforcers should be running with the same software version and

the same policy.

NOTE: If the NetEnforcer Active Redundancy mechanism is implemented a bypass unit should not be used. This ensures that the network is made

aware of any failure and is able to smoothly transfer traffic to the

secondary link.



Active redundancy can be configured on the NetEnforcers using the

NetXplorer GUI. Select a NetEnforcer and choose configuration. From the

Networking tab, you can now configure the NetEnforcers network settings as seen in the screenshot:

Confirm the Enable Bypass Unit checkbox is not checked and set Redundancy Mode to Active.



Open the NIC tab and in the Action on Failure field, set INTERNAL0, EXTERNAL0, INTERNAL2 and EXTERNAL2 to fail paired port. Set INTERNAL1, EXTERNAL1, INTERNAL3 and EXTERNAL3 to No Action in the Action on Failure field. Save the configuration. NetEnforcer will reboot.

This will automatically change the Port Usage of Ports 1 and 3 (2 and 4 on

the physical device) to Cloned.



Asymmetric traffic handling and active redundancy both offer a solution for

handling parallel links in your network running through more than one in-

line platform. Lets review and compare these features:

In both deployments each in-line platform sees full connection information.

Traffic is fully identified and classified, even if part of it flows through one

platform and part through the other (asymmetric environment).

In case one network link fails, the providers switches can ensure that the

traffic is switched from one link to the other. When working with active

redundancy, classification of open connections is maintained. In an

asymmetric setup, the current connection classification will not be

maintained, but new connections will be correctly classified.

With active redundancy QoS definitions for a specific IP will take into

account the traffic running through both platforms. With an Asymmetric

traffic solution, the QoS definition applies to each platform separately.

The impact on bandwidth for Active Redundancy is 50%, as both

NetEnforcers see and handle the exact same traffic. With the Asymmetric

traffic solution, only 5% of bandwidth is used for information transfer

between the in-line platforms.

The total number of NEs that can be used with Active Redundancy is 2.

You can include up to 8 NEs in the same Asymmetric group.



What is the specification for each of the two listed Platforms?



Here you see 3 steps in a typical installation procedure for connecting an

in-line platform with an external bypass to the network. What is the

recommended order of carrying out these steps?



How many VLAN IDs need to be defined in the NetXplorer GUI for an

asymmetric group which includes 3 SG/NEs?



Which of the ports on the SFB-300 inserted in slot 7 are used for the 3

purposes listed here?



Module 3

Introducing

NetXplorer


Introducing NetXplorer 3-2

In this module, we introduce the NetXplorer. By the end of the module, you

will know how to install the NetXplorer server on both Windows and Linux

platforms, how to install and get started with the GUI and how to perform

the initial configuration. We finish with some examples of a typical

NetXplorer workflow. We begin by asking what is NetXplorer?



NetXplorer is a scalable central management umbrella for Allot in-line

platforms and services.

Using the NetXplorer, you can configure Allots NE, SG and SMP products,

and build traffic policies for them to enforce. You can perform real time

monitoring of your network for troubleshooting and problem analysis, and

long-term reporting to help with capacity planning and understanding

longer term usage trends. NetXplorer enables you to define and manage

traffic and system alerts to assure a proactive approach to network

management. You can also use it to collect accounting information which

can then be exported for billing purposes. Finally, with NetXplorer you can

view analytics of mobile internet session. Note that the NetXplorers accounting interface and mobile analytics are not within the scope of this

course.

NetXplorer is shipped in 3 different ways.

When purchased as a software only license (forWindows or Linux), the customer provides his own hardware according to Allot recommended

specifications. The software license can be purchased to enable the

NetXplorer to manage up to 3 NE/SGs, up to 15 NE/SGs or an unlimited

amount.

Alternatively, NetXplorer can be purchased as a standalone server package (SNX-SRV), consisting of the NetXplorer software preinstalled on

an IBM server.

The third and final option (SNX-SRV-HAP) is the NetXplorer high availability package, which consists of the NetXplorer software installed on 2 separate IBM servers, both of which are connected to a RAID

storage device. High Availability is ensured by the Linux heartbeat

process.

In addition, add-ons can be purchased to enable NetAccountant (covered in the ACPP training course), NetPolicy Provisioner (available as an appendix module), Country Classification (covered in Module 5 of this course) and WebSafe (covered in Module 6 of this course).NOTE: The NetXplorer reporter which enables real-time monitoring

functionality on AOS driven products, is purchased as an add-on to the

NetEnforcer or Service Gateway (not the NetXplorer).





Before looking at the installation process, we will review the hardware and

software requirements, as well as installation guidelines of NetXplorer on a

Linux server and NetXplorer on a Windows Server.



If the software only option is chosen, the customer will need to provide

the server hardware and operating system according to Allots minimum

specifications. Allot proposes two minimum configurations. In this

minimum configuration (which may be suitable for enterprise customers),

a single NetXplorer Server supports 1 or 2 AC-500 devices, 1 or 2 AC-

1400 devices or 1 or 2 AC-3000 devices.

NOTE: Allot supports CentOS Linux 5.5 and RedHat Enterprise Linux

Server 5.5 (32 or 64 bit). Other types of Linux are not supported. In

addition, it should be noted that Allot does not recommend installing the

NetXplorer on a virtualized machine such architectures are not officially

supported.

Regional settings must be configured as English Only.



In this minimum configuration (which may be suitable for service provider

customers), a single NetXplorer Server supports 1 Service Gateway,

Alternatively it can support more than 2 AC-1400, AC-3000 or AC-500

devices.

In order to know what is the required disk size use the following

assumptions:

100GB per Service Gateway

20 GB per AC-3000/AC-1400

10 GB per AC-500

NOTE: Allot supports CentOS Linux 5.5 and RedHat Enterprise Linux

Server 5.5 (32 or 64 bit). Other types of Linux are not supported. In

addition, it should be noted that Allot does not support installing the

NetXplorer on a virtualized machine. Regional settings must be configured

as English Only.

Software requirements from the NetXplorer server are as follows:

NetXplorer Server should be installed on a dedicated server behind a

Firewall for optimal performance and security.

Any Real-Time Virus Protection programs or automatic

Defragmentation/Backup software must be disabled on the NetXplorer

server or the Allot folder needs to be excluded from

protection/defragmentation

Java JDK 7 should be installed on the Server machine. If the machine

on which you are installing NX Server is running a 64 bit OS, the Java

installation must also be 64 bit. If the server is running a 32 bit OS,

then the Java version must be 32 bit. Both JDK versions can be

downloaded from Allot FTP server.

No other database applications (for example, SQL database) should

be installed on the NetXplorer server machine

No application should be listening to port 80 at the time of the

installation.

When there is firewall between different Allot components, verify all

required ports are opened

A full procedure can be found in Allot NetXplorer Installation &

Administration Guide.



For a successful NetXplorer installation on Linux, make sure to verify the

following:

If the CentOS/Red Hat operating system has not been installed yet,

configure the server so that the CD is the first boot device, insert

Installation CD #1 and reboot the host. Follow the on-screen

instructions for a customized installation. Make sure that the following 2

extra packages are installed: net-snmp-utils from theSystem Tools group, and xorg-x11-server-Xvbf from the X Window system group

Hostname: give fully qualified host name (e.g., NXlinux.allot.local)

Firewall: disabled (during configuration after reboot)

SELinux: disabled (during configuration after reboot)

Time: configure correct time according to time zone chosen

NTP server: may be configured during configuration after the IP

address is configured (select synchronization checkbox before starting)

MGMT Interface: Must be set to Eth0.

Once verified, you can start the installation by downloading installationfiles, or copy them from the installation CD and run the command : rpm -ivh where file name is the NetXplorer installation file name. For example: rpm -ivh netxplorer-12.3.0-10.i386.rpm. Reboot the server, and verify you have the most recent Protocol Pack

installed



For a successful NetXplorer installation on Windows, make sure to verify

the following:

That there is at least 4 GB of available Virtual Memory.

On Windows Server 2008, IPv6 should be disabled by going to Control

Panel > Network and Sharing Center > Manage Network Connections >

Local Area Connection Properties. Uncheck the Internet Protocol

Version 6 checkbox to disable the service.

Once verified, download installation files, or copy them from the

installation CD, and start the installation by running the setup.exe file.

You can choose to run a typical

Documents

ACTE r4 Student Guide