Professional Documents
Culture Documents
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
Introduction
1-3
Introduction
1-4
Introduction
1-5
Introduction
1-6
Introduction
1-7
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-8
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.
Introduction
1-9
Introduction
1-10
Introduction
1-11
Introduction
1-12
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-13
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-14
Introduction
1-15
Introduction
1-16
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-17
Here you can see the enforcement policy table in the NetXplorer with the
default line, pipe and VC rules.
Introduction
1-18
Introduction
1-19
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 Gateway
devices 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-20
Introduction
1-21
Introduction
1-22
Introduction
1-23
Introduction
1-24
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
2-2
2-3
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.
2-4
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.
2-5
2-6
2-7
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.
2-8
2-9
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.
2-10
2-11
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.
2-12
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 (autonegotiation) or 1000Base-SX/LX/ZX
The 4 extra service interfaces are 10/100/1000Base-T copper only.
2-13
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.
2-14
2-15
2-16
2-17
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.
2-18
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.
2-19
2-20
2-21
Here we see a close-up view of the SG-Sigma E6 chassis rear. The RBS300 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.
2-22
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 FlowBalancer Blade) and the CC-300 (Core Controller blades)
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.
2-23
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).
2-24
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.
2-25
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.
2-26
2-27
2-28
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.
2-29
2-30
2-31
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.
2-32
2-33
2-34
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.
2-35
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
2-36
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 Inline 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.
2-37
2-38
2-39
Lets now see three examples of connecting the Service Gateway to the
Network. In the first example, 4 x 10Gbps links are connected to SGSigma 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.
2-40
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.
2-41
2-42
2-43
2-44
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
6. Verify traffic flow
7. Add other links in a similar way
2-45
2-46
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.
2-47
Now that we have physically connected our in-line platform to the network,
we will see how to perform initial configuration.
2-48
2-49
2-50
2-51
2-52
The admin user initially logs in with username sysadmin and password
sysadmin. IP configuration is performed by entering the go config ips
command. 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
-d
Domain
-g
<type:ip>
-dns
<dns1:dns2>|none
-ts
<ntp1:ntp2:ntp3>|none
-ip
<type:ip:mask>
2-53
2-54
Amongst the information that can be viewed in the extended output is the
current status of the device (active or bypass)
2-55
2-56
2-57
2-58
2-59
2-60
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.
2-61
Click the VLans Settings button to edit the VLAN configuration. The VLan
Settings 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.
2-62
Finally, lets examine how active redundancy works and the in-line
platforms on which it is supported
2-63
2-64
2-65
2-66
2-67
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.
2-68
Asymmetric traffic handling and active redundancy both offer a solution for
handling parallel links in your network running through more than one inline 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.
2-69
2-70
2-71
How many VLAN IDs need to be defined in the NetXplorer GUI for an
asymmetric group which includes 3 SG/NEs?
2-72
Which of the ports on the SFB-300 inserted in slot 7 are used for the 3
purposes listed here?
2-73
2-74
Module 3
Introducing
NetXplorer
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?
Introducing NetXplorer
3-2
Introducing NetXplorer
3-3
Introducing NetXplorer
3-4
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.
Introducing NetXplorer
3-5
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 AC1400 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.
Introducing NetXplorer
3-6
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.
Introducing NetXplorer
3-7
Introducing NetXplorer
3-8
Introducing NetXplorer
3-9
Introducing NetXplorer
3-10
Here you see some of the errors that you might encounter if you do not
follow the steps outlined in the previous slides.
On a Linux server, in case the package xorg-x11-server-Xvbf was not
installed with the operating system, the installation will fail with an error:
Error: X Virtual Frame Buffer is Not Detected. Install the package from the
operating system installation CD, and run the installation once more.
On a Windows server, if one of the ports required is being used by another
application, then the installation will be aborted.
If there is less than 4G of virtual memory available, you will encounter a
warning message at the beginning of the download. Note that the virtual
memory value can be changed by choosing system from the control
panel on the server. Open the Advanced tab and click the Performance
Settings button. Then open the Advanced tab and click the Change button
under Virtual Memory to select a new value.
Note: additional troubleshooting scenarios are covered in more detail in
the ACPP Training Course.
Introducing NetXplorer
3-11
Introducing NetXplorer
3-12
Introducing NetXplorer
3-13
NX-HAP comes pre-installed with CentOS operating system and the NetXplorer
software, but the 3 units need to be correctly connected together. The
connections are as follows:
1. A crossed copper cable is used to connect between Port 3 on one NX server
and Port 3 on the second NX server. (illustrated in green above)
2. A null modem serial cable (RS 232) is used to connect between the Serial
COM port on one NX server and the Serial COM port on the second NX
server. (illustrated in red above)
3. Two Serial SCSI (SAS) cables connect between the first controller on the
RAID storage device and the SAS HBA connection in the first PCIe low
profile slot of each NX server (illustrated in orange above)
4. Two further Serial SCSI (SAS) cables connect between the second controller
on the RAID storage device and the SAS HBA connection in the second PCIe
low profile slot of each NX server (illustrated in orange above)
5. Each NX server is connected to the management network via Port 1
(illustrated in blue above) with an additional link via Port 2, as required.
6. Each controller on the storage device is connected to the management
network by a copper Ethernet link (illustrated in blue above) for storage
management and traps
7. The IMM interface on each NetXplorer server is connected to an external
switch by an additional ethernet management cable (illustrated in blue above)
For a full explanation on how to configure the initial IP settings of the NX-HAP
see the NetXplorer Installation and Administration Guide.
Introducing NetXplorer
3-14
Introducing NetXplorer
3-15
Now that the NetXplorer server has been successfully installed and
connected, lets see how to install the NetXplorer GUI.
Introducing NetXplorer
3-16
Introducing NetXplorer
3-17
Introducing NetXplorer
3-18
Click the appropriate link and follow the installation wizard instructions to
install JRE 7.0 on your computer. You can either run the installation files or
download them and then run the installation locally.
Introducing NetXplorer
3-19
Introducing NetXplorer
3-20
In the event that the NetXplorer GUI fails to load, consider the following
actions:
1. Disable pop-up blocking for NetXplorer.
2. For Internet Explorer users, disable 'Empty Temporary Internet Files
folder when browser closed'
a) From the Tools menu, select Internet Options.
b) Select the Advanced Tab and Scroll down to Security
c) Clear the Empty Temporary Internet Files folder when browser
closed checkbox.
d) Click OK, and attempt to access the NX through the browser.
3. Make sure the browser cache file is not saturated:
a) From the Internet Explorer tools menu, select Internet Options.
b) On the General tab, click Delete Files.
c) Select the Delete all offline content checkbox and click OK.
4. If there is a firewall between the GUI Client and the NetXplorer Server,
check that all required ports are opened. A detailed list is available in
the Allot NetXplorer Installation & Admin Guide.
5. If the problem persists, try to access the NetXplorer via the Java Web
Start Application Manager. Note that a full treatment of how to
troubleshoot problems loading the NX GUI is included in the ACPP
Advanced Course Module on Troubleshooting the NX.
Introducing NetXplorer
3-21
Introducing NetXplorer
3-22
Introducing NetXplorer
3-23
When performing any task in the NetXplorer, you will normally work in the
following order of steps:
1. From the lower part of the navigation pane, select the area of the
product you wish to work with e.g: Network, Catalogs,
Events/Alarms etc. The upper part of the navigation pane will change
accordingly.
2. Click the entity you wish to work with from the upper part of the
navigation pane. You can now select an action to perform on the
selected entity.
3. The details area changes to reflect the selected entity and the action
performed on it.
A tab is displayed at the bottom of the pane for each open application. You
can easily navigate between the open applications by clicking the tabs.
Introducing NetXplorer
3-24
Introducing NetXplorer
3-25
Introducing NetXplorer
3-26
Note that the appearance of tables in the NetXplorer can be modified. This
is particularly useful for the policy table (discussed fully in Module 7).
To resize a columns width, click the right border of the column and drag.
To change which columns in the policy table are visible and which are
hidden, right-click the table header, and select Table Column Configuration
from the shortcut menu. The Policy Columns Visibility dialog is displayed.
Now select the columns that you want to display in the table and click
Save.
Introducing NetXplorer
3-27
Introducing NetXplorer
3-28
In order to use the NetXplorer you must enable the NetXplorer Server by
entering the appropriate key.
To enable the NetXplorer Server, select Tools > NetXplorer Application
Server Registration from the NetXplorer Menu bar. The NetXplorer
Application Server Registration dialog box appears. Enter the Server
Registration Key and Serial Number provided by Allot to enable the
NetXplorer Server functionality.
An Expiration Date will be generated automatically after clicking Save.
Note that an expiry date will appear even when you have purchased a
permanent key. This reflects the expiry of the service contract and is
relevant for the APU feature only, which will cease to work once the
service contract has expired.
Click Save to enter the key and close the dialog box.
Introducing NetXplorer
3-29
You will see that there are two root trees in the network pane the
network tree and the servers tree. Under the network tree we add the
Service Gateway and/or NetEnforcers that are to be managed by the
NetXplorer. Under the Servers tree we can add Distributed Collectors and
SMP servers. Both of these topics are covered in the Allot advanced
courses: SMP & ACPP.
To add a NetEnforcer or Service Gateway to the Network tree, we will first
of all need its IP address.
1. In the Navigation pane, right-click the Network in the Navigation tree
and select New NetEnforcer from the popup menu. The NetEnforcer
Properties dialog is displayed.
2. Enter a name for the in-line platform. This is the name that will appear
in the Network tree. Now enter the admin user password of the in-line
platform (The default password for the admin user is allot. It is possible
to change this default password using a script on the NE/SG) and the
IP address of the in-line platform in the designated fields and click OK.
The NE/SG is added to the Navigation tree. The New NetEnforcer
operation can take up to a couple of minutes to fully complete.
Note that in certain earlier software versions, a NetEnforcer that was
added would be rebooted.
Introducing NetXplorer
3-30
Once you have added an in-line platform, you can view and modify its
configuration parameters remotely via the NX. To view configuration and
configure a NetEnforcer or Service Gateway:
1. In the Navigation pane, select and right-click the NetEnforcer in the
network tree and select Configuration from the popup menu. The
Configuration window for the selected entity is displayed.
2. After modifying configuration parameters, you must select Save in
order for the changes to take effect. The save process prompts a
reset of the device. Resetting is required to ensure that the saved
parameter values are committed and activated on the NE/SG.
3. When the NetEnforcer Configuration dialog is selected, Restart and
Shutdown buttons become active, on the top right of the screen. Use
these buttons to Restart or Shutdown the selected NE/SG.
The General tab includes parameters that provide system status
information. Status indicates whether or not the NE/SG is operating in
Active or in Bypass mode. Bypass Setting indicates whether the bypass
is set to standalone or active (where relevant), or if it is not connected at
all. Remote Bypass. This was relevant for a type of redundancy (parallel
redundancy) which is not longer supported on AOS platforms. Power
Supply indicates the status of the power supply on the in-line platform
(OK, Unknown or Problem). Finally, Fans shows the status of the fans on
the in-line platform (OK, Unknown, or Problem).
Introducing NetXplorer
3-31
The Identification & Key tab includes parameters that provide system
information and activate optional NE/SG modules. Scroll down here to
show all of the configured license fields. Note that there is no need to
reboot the NE/SG when you add a new key.
Introducing NetXplorer
3-32
The NIC tab includes parameters that enable you to configure the NE/SGs
ports to either automatically sense the direction and speed of traffic, or
use a predetermined duplex type and speed.
This tab also allows you to see the actual settings of the NE/SG
interfaces, and it allows you to decide what action to take immediately if
any of the NICs should fail.
The action on failure is set to Fail Paired Port by default. This ensures
that traffic will not be blocked if a single port goes down, and helps for a
trouble-free installation.
The port usage field, is particularly useful when defining the usage of
different ports on the SFC-200 or SFB-300 blades.
Introducing NetXplorer
3-33
The networking tab includes parameters that help you configure the
network topology.
When using AC-1400 or AC-3000 in active redundancy configuration, you
need to disable the Bypass unit. This tab is also the place to set the
redundancy mode in which you are working. These issues were explained
fully in Module 02 Introducing In-Line Platforms.
The networking tab is also the place to enable HTTP User Defined
Signatures and Tethering condition catalogs which are covered in more
detail in Module 5.
Introducing NetXplorer
3-34
The IP Properties tab enables you to modify the IP and host name
configuration of your network interfaces, as well as the DNS and
connection control parameters.
Introducing NetXplorer
3-35
The Date/Time tab includes the date, time and NTP (Network Time
Protocol) server settings for the NetEnforcer or Service Gateway. When
adding a device the primary NTP is set as the NetXplorer Server IP. The
user may change the NTP server only using CLI commands on the
NE/SG.
Introducing NetXplorer
3-36
The slots and boards tab will only appear in the configuration of certain inline platforms (e.g: SG-Sigma or SG-Sigma E). On these multi-blade
devices, you can choose a blade from the graphical representation on the
left side of the screen. Below the graphic you will see each sensor and its
current reading. On the right side of the screen are common chassis
sensors and telco alarms.
Introducing NetXplorer
3-37
Introducing NetXplorer
3-38
Introducing NetXplorer
3-39
Introducing NetXplorer
3-40
Which of the tasks listed on the right can be performed by which user
types?
Introducing NetXplorer
3-41
Introducing NetXplorer
3-42
Introducing NetXplorer
3-43
Introducing NetXplorer
3-44
Here we see a flow chart which represents a full provisioning process from
start to finish. The first step is to analyze business objectives. Only once
we have established what our business goals are, can we actually decide
how to classify our network traffic and what traffic policy to build. In a full
provisioning methodology, the next step will be what we call out of the
box monitoring. The NetXplorer comes with a predefined default traffic
policy which does no shaping, but classifies traffic into virtual channels
according to well known groups of services. Once our NE or SG is
connected to the network, we can use this default policy to monitor traffic
patterns and this can help us to decide which policies are needed.
Monitoring will be discussed in full in module 4 of this course.
Once we know what policies we wish to define, we define our condition
catalogs (discussed in module 5) and our action catalogs (discussed in
modules 6 and 9). We then put these building blocks together to build our
traffic policies (module 7).
At this stage, many customers go back to monitoring. Monitoring tools can
be used here to analyze which traffic is and is not classified according in
the lines, pipes and VCs we have created. The traffic policy can then be
fine-tuned accordingly.
Finally, at this stage, we will typically also define alarms and events
(discussed fully in Module 8). We may also choose to define set reports
and even schedule them to run on a regular basis (Module 4).
Introducing NetXplorer
3-45
Module 4
Monitoring and
Reporting
4-2
In this module, we will see how to use the NetXplorer to gain full Network
visibility. After a brief overview of the real time monitoring and long term
reporting capabilities, we will examine every type of graph in turn, giving
examples of typical uses. We will then look at several advanced features
including the drill-down capabilities, before moving on to see how you can
schedule pre-defined reports to run on pre-defined groups of entities.
4-3
4-4
4-5
4-6
All of these charts can be displayed in a table view, which displays all of
the readings and the exact values on which the chart is based.
4-7
4-8
To view a NetXplorer graph, you will first need to select the object on
which you wish to run the graph from the network tree.
There are then 3 different ways to access the graphs.
1) By clicking on the Real-Time Monitoring or Long Term Reporting shortcut buttons and then choosing the object on which you wish to run the
graph. (NOTE: there is a separate short cut button for mobile analytics)
2) By right-clicking on the network element, selecting real-time monitoring
or long-term reporting and then choosing the object on which you wish to
run the graph.
3) By selecting real time monitoring or long term reporting from the view
item on the menu bar, and then choosing the object on which you wish to
run the graph.
NOTE: the menus are context sensitive. This means that the reports
available depend on the entity selected in the network tree. For example, if
the selected entity is a pipe, you will be able to see graphs for the
distribution of objects that are inside it: VCs, protocols and hosts. If the
object selected was the top node of the network tree then NetEnforcer,
Line and Pipe distribution graphs would also be available.
Note: up to 15 graphs can be opened at the same time. When attempting
to open the 16th graph, an alert message will pop up asking you to close
one graph.
4-9
4-10
4-11
In the Time tab, you can determine the chosen time period for the graph.
This can be either for the last given time, or for a time period spanning
between two specified times and dates. As well as determining the length
of time for which the report will be run, you can also decide (for long-term
reporting or real time monitoring with a resolution of 1hr or more) if you
want the reporting period to span back from the time the report is run, or to
span back from a defined moment N days in the past. You can also
determine the data resolution. The options here differ, depending on
whether you are defining a real-time monitoring or a long-term reporting
graph.
Finally, if you are configuring a typical time graph, an additional
configurable section will appear at the bottom of this dialog. A full
explanation on this will be provided when we come to discuss typical time
graphs.
4-12
In the Objects tab, the radio buttons at the top allow you to choose
whether to run a top graph or a distribution graph.
To choose a top graph such as most active protocols, simply choose
the number of objects you wish to view in the report, and then the criteria
on which the most active statistics will be based. This determines the
vertical axis in the bar chart that will be initially displayed.
To choose a distribution graph, choose the specific objects radio button,
select the specific objects that you wish to see, and move them to the right
hand window. In this case, the selected objects are protocols, but they can
just as easily be NetEnforcers or Service Gateways, lines, pipes, VCs or
hosts.
Note that while the vertical axis of top graphs is set on the objects tab, the
vertical axis of a distribution report is set on the display tab.
When opening protocols graph, Service Groups will appear on top of the
list, and there is a text filter function to help you easily find the objects you
are looking for.
4-13
In the Limits tab, you can choose to limit the scope of your report to a
specified object or objects. The objects available here depend on the
graph which you have chosen to run.
You may for example, wish to view the most popular protocols from within
a particular service group (e.g: P2P protocols). Or, you may wish to view
the most active hosts on specified VCs only. We will discuss this further in
the advanced features section of this module.
4-14
4-15
Once a graph has been opened, there are several options available by
right clicking on it. Using these options, you can do the following:
Use the show data by option to change the vertical axis without
redefining the graph properties. The chart style option is used to switch
between different chart styles (e.g: bar to pie chart). Display changes the
way in which data is displayed on the graph. You can change the units of
measurement from kbps to Mbps or change the order in which bars on a
most active graph are displayed between value, alphabet, percentage and
more. You can also show the exact values on the graph or on the legend.
Switching to a table view gives an exact list of the values displayed in the
graph. In case of errors displaying graphs, the errors log button provides
information that can help troubleshoot the problem. For a real-time
monitoring graph, you can start the automatic update so the graph will
refresh itself, or you can scroll backward and forward through time
ranges. You can also drill down from a graph to other graphs for quick,
intuitive, context-based analysis. When working with a distribution graph,
you can choose to hide specific instances. Graphs can be exported for
viewing or editing by other applications. You may export graphs to any of
the following file formats: CSV, PNG, PDF, JPG or HTML. Note that if you
export to CSV, you can overcome the limitation of 50 items which are
available on a graph.
Finally, the properties menu item (which is also accessed by a shortcut
button) returns you to the graph parameters dialog and enables you to
refine your graph definitions as required.
4-16
There are several other useful tips that can help you get the most out of
the graphs that you are displaying.
When a graph opens, double clicking on it will maximize its size
You will notice that the graph will be opened up in a tab according to
whether it is real-time monitoring graph, a long-term reporting graph, or
part of the favorites view.
A left click on any area on the graph reveals a tooltip detailing the specific
data reading for that point on the graph.
You can expand and collapse the legend, and you can expand or reduce
the size of the legend box to fit your requirements
Note that you can switch between the different graphs open on a given tab
by choosing the graphs list shortcut button.
Note also that the open graphs in the tab can be tiled or cascaded on the
screen.
4-17
4-18
Your favorite view can be easily accessed from the view menu.
4-19
In this next section, we will see examples of each of the different types of
graphs and how they are used.
4-20
4-21
The statistics graph can help you answer questions such as:
How much traffic is passing through my network right now?
When were the peaks/troughs in my network traffic?
How much of my network traffic was inbound or outbound?
When were the most new connections reported?
4-22
The statistics graph shows the total inbound and outbound traffic passing
through the whole network or any entity on it over a defined period of time.
By default the graph shows inbound bandwidth, outbound bandwidth and
total bandwidth, but it can be modified to display live or new connections,
inbound or outbound packets.
We can now see the following examples:
Example#1: How much traffic has been passing through my network?
Select network on the navigation tree, and choose to run a Real-Time
monitoring statistics graph. Keep the default settings and choose OK.
Right click on the graph and choose Display Bandwidth Units - Mbps
Example#2: When were the most new connections reported? Choose a
NetEnforcer on the navigation tree, and run a Long Term statistics graph;
On the time tab, choose to view data for the last day at 1hour intervals; On
the display tab, under default data choose to open the graph on the new
connections. Under data mode, choose show data by volume
4-23
4-24
For NetEnforcers, Lines, Pipes or VCs, we can run either a most active
objects graph or an object distribution graph.
The distribution graphs display by default the total bandwidth passing
through the NetEnforcer, Line, Pipe or VC over the defined time period.
Aside from the default of total bandwidth, they can be based on inbound
bandwidth, outbound bandwidth, live, new or dropped connections,
inbound packets or outbound packets.
The top graphs display the NetEnforcers, Lines, Pipes or VCs through
which the most bandwidth has passed over the defined time period. The
graph can display up to 50 objects, and as with the distribution graphs, the
vertical access can be modified to display a number of other criteria.
The type of objects graphs which are available depend on the network
entity which you are investigating, as shown in the table on the slide.
Now, lets see some examples:
Example: How much traffic is passing through each NetEnforcer or
Service Gateway on the network? Select the network at the top of the
network tree and choose to run a real-time monitoring graph on
NetEnforcers. On the objects tab, choose the Specific NetEnforcers
radio button, select all of the NetEnforcers you wish to analyze and click
on OK. Click on table view to see the exact total bandwidth figures for
each NetEnforcer over the last 30 second period.
4-25
4-26
The protocols graphs can help you answer questions such as:
How much bandwidth has been taken up by specific protocols?
Which protocols have been taking up most bandwidth on your network?
Which protocols have not been classified in the VCs you have created?
Is there any suspicious network activity that could indicate a DoS
attack?
4-27
4-28
When you open most active protocol you can choose to see top X
protocols (up to 50).
The display can be set to data for the period as a whole. This will result
in a bar graph, showing you the total bandwidth consumption of the top
used protocols for the selected time period.
Alternatively, you can choose to display data over time. This will result
with a stack area graph, showing you protocols distribution, over the
selected period of time. You can then scroll back to a previous time slot,
which may change the result you see.
4-29
When you open distribution graph you can choose to see specific
protocols or protocols groups from the list.
The display can be set to data for the period as a whole. This will result
in a pie chart, showing you 100% of the services or service groups
selected. You can also choose to display all others which will group all
the non-selected services for you.
Alternatively, you can choose to display data over time. This will
generate a stack area graph, showing you how specific protocols are
distributed over the selected period of time. You can then scroll back to a
previous time slot, which may change the result you see.
4-30
The next group of objects on which you can run graphs is hosts. Before
discussing this group in more detail, it is important to clarify what we mean
by internal and external hosts.
Internal hosts are defined as those originating from the side of the network
that is connected to the internal interface on the bypass unit or blade of
the NetEnforcer or Service Gateway. External hosts originate from the
side of the network that is connected to the external interface. NOTE: In
the case of the AC-500 where the bypass function is internal, hosts are
defined as internal or external on the basis of which network interface they
are connected to.
4-31
Running a graph on hosts can help you answer questions such as:
Which IP addresses are taking up the most bandwidth?
Who should be targeted for special service package offers?
Which IPs are using particular protocols?
NOTE: Service providers typically operate in a dynamic IP environment
where IP addresses are dynamically allocated to subscribers from an
available pool. In order to monitor subscriber usage patterns in a dynamic
IP environment, you will need to deploy Allots Subscriber Management
Platform (SMP) which integrates with the IP allocation system to ensure
real-time mapping between subscriber, allocated IP and purchased service
plan. Dedicated graphs are used when working with SMP and these are
discussed in the SMP training course.
4-32
4-33
Additional Graphs enable you to focus on specific details that are relevant
in your network. In the following section you will find detailed explanations
about each graph type. Note: subscriber graphs, service plan graphs and
mobile analytics are covered in the SMP course.
4-34
The utilization graph can help you answer questions such as:
Is my network approaching full capacity?
Are the limits I have defined for different applications or users realistic?
Are my network resources being over or under-used?
4-35
4-36
Running a Percentile graph can help you answer questions such as how
much bandwidth is being used on average by the top 5% of subscribers
(Bandwidth Usage Percentile Report), or what is the web usage profile of
the most active 10% of subscribers (Percentile Protocols graph).
Alternatively, a carrier might use the 95th percentile report to determine
how much to bill a service provider for wholesale bandwidth consumed
over a month.
4-37
4-38
Lets now briefly examine how the bandwidth usage percentiles graph is
calculated.
1. Lets suppose that for the chosen period of time, there are 2564
different hosts on the network.
2. The NetXplorer extracts the bandwidth each host is generating.
3. The NetXplorer takes these 2564 hosts and arranges them in a table
from the heaviest user to the lightest user.
4. Once the users are arranged in this way, different percentiles can be
identified. First we need to know what is one percentile. We will take
the total number of users, and divide it by 100. In this example, it will
be 26 users (25.64, rounded up).
Percentile 1 will represent the bottom 26 users. It will be calculated as the
average bandwidth used by the 26 hosts with the lowest bandwidth (or
numbers 2539 2564 on our list).
Percentile 100 will represent the top 26 users. It will be calculated as the
average bandwidth used by the 26 hosts with the highest bandwidth (or
numbers 1 26 on our list).
All other percentiles will be calculated the same.
4-39
4-40
Just like the bandwidth usage percentile graph, the Percentile Protocols
graph is available both as a long term reporting and a real-time monitoring
graph. It can be run on NetEnforcers, Lines, Pipes or VCs. It cannot be
run on a network level. It can also be accessed by drilling down from a bar
in the Bandwidth Usage Percentiles graph.
When generating the graph, you must specify in the Objects tab, which
percentile group you wish to analyze. You are then presented with a graph
showing the average bandwidth used for each of the top protocols (10 by
default) within that percentile group. The number of hosts (or subscribers,
depending on the graph definition) that use each protocol is recorded on
the legend in parentheses.
Now lets see an example:
Example #1: How much bandwidth is being used on average by the top
5% of subscribers ? Select the NetEnforcer or Service Gateway on the
network tree through which runs the traffic that needs to be analyzed.
Choose to run a real-time monitoring graph on Bandwidth Usage
Percentiles. Click on OK.
4-41
The 95th Percentile graph is used for billing purposes by Operators and
Carriers who are charging for internet access based on bandwidth usage.
This may be a carrier who is renting wholesale bandwidth to a Service
Provider, or it may be a Service Provider renting bandwidth to an
Enterprise.
It uses the de-facto industry standard for calculating bandwidth usage,
where the top 5% of samples are discarded, and an average is taken of
the remaining 95%. The 95th percentile allows a customer to have a short
(e.g: less than 36 hours, given a monthly billing period) burst in traffic
without overage charges. The 95th percentile says that 95% of the time,
the usage is at or below this amount. Conversely, 5% of the samples may
be bursting above this rate.
The graph is available for monthly periods of time as a long term reporting
and hourly periods as a real-time monitoring graph. It can only be run on
Lines, Pipes or VCs. It cannot be run on a network or a NetEnforcer level
4-42
4-43
Popularity graphs differ from other graphs in that they measure not the
amount of bandwidth, but rather the number of subscribers using
particular protocols, pipes or VCs.
Three different popularity graphs are available as long term reports only:
Average Protocol Popularity (which can be run at the Network or
NetEnforcer level only), Pipe Popularity (which can be run at the Network,
NetEnforcer or Line level) and VC popularity (which can be run on all
network entities except for the VC itself)
As with the other object reports, the user can choose to view either most
popular graphs, showing the protocols, pipes or VCs used by the most
number of IPs, or popularity distribution graphs, which show the
distribution of protocols, pipes or VCs by number of IPs over a defined
period of time.
NOTE: This graph uses a large amount of system resources and is
disabled by default. To enable this graph, please contact
support@allot.com
4-44
The key difference between the most active protocols graph and the
average protocol popularity graph is illustrated by the juxtaposition of the
two pie charts above, which were generated on the same network entity
over exactly the same period of time.
The chart on the left (most active protocols) displays the 6 protocols which
consumed the most bandwidth on the network. The chart on the right
(average protocol popularity) displays the 6 protocols which were used by
the largest number of subscribers on the network. The differences are
striking.
It is clear that the protocols which were responsible for the most amount of
bandwidth on the network (eDonkey, Gnutella, KaZaA in the most active
protocols graph on the left) were being generated by a very small
percentage of the subscribers (as shown in the average protocols
popularity graph on the right). In fact, the overwhelming majority of
subscribers was generating HTTP traffic which accounted for a relatively
small share of the bandwidth load on the network.
Lets see an example:
Example #1: How many subscribers have been generating the protocols
which consume the most bandwidth on my network? Select the network at
the top of the network tree and choose to run a long-term reporting graph
for Average Protocol Popularity. On the objects tab, choose the 10 most
popular protocols and click on OK.
4-45
The typical time graph can help you answer questions such as:
What are the most popular protocols over a typical weekend?
What is the distribution of different types of protocols over the course of
a typical day?
What are the typical usage patterns of subscribers during evening peak
surfing hours?
4-46
Typical time graphs are very useful to give indicators of typical network
and subscriber behavior in a typical day or week over a defined period of
time.
They can be used to create top graphs but they are most relevant in the
context of distribution graphs. In this case you can choose to see the
distribution of objects you select over the course either of a typical day or
a typical week for a defined period of time. Note, that the time resolution
field does not appear in a typical day or week report. The resolution for a
typical day and typical week report will always be 1 hour.
For a most active report, the button to choose between typical day and
week is grayed out as it has no relevance. A typical time most active
report where all the hours in the week have been chosen is in fact the
same as a regular most active report with a resolution of 1hr. In both
cases the graph displays the traffic that existed in the indicated timeperiod, divided by the time length (hence displaying in fact 'rate'). There is
one difference between a typical time most active report and a regular
most active report. This is the ability to choose specific days and hours
during the week to run the report on. This means that for the same period
of time say the last month, you could run a typical day report to see the
top 10 protocols inside work hours, and a different graph for the top 10
protocols outside work hours.
4-47
As we see here, for a typical day distribution graph, the hours of the
typical day appear on the horizontal axis. Total bandwidth, or whatever
other parameter has been defined, appears on the vertical axis. This
particular graph shows the distribution of selected groups of protocols over
the course of a typical day from midnight to midnight.
If the period defined for this graph was the last month, then NetXplorer
creates this graph by computing an average total bandwidth for each
protocol group at every hour. The average is calculated from the total
bandwidth figures on that protocol group at that particular hour, every day
over the course of the last month.
Now lets see an example:
Example #1: What is the distribution of different types of protocols over the
course of a typical day? Select a pipe from the network tree containing
VCs which classify traffic by groups of services. Choose long-term
reporting, typical time, and virtual channels. On the time tab, choose to
show data for the last month. On the objects tab, choose the Select
Specific Virtual Channels radio button, select all of the VCs in the pipe
and click on OK.
4-48
The different service graphs can help you answer questions such as:
How much subscriber traffic was being steered to a newly deployed
service?
How steered traffic is balanced between the different content servers
deployed?
Which websites were most accessed by my subscribers? (Most Active
Domains Graph)
How many illegal URLs were accessed by my subscribers? (WebSafe
Graph)
4-49
This report shows the traffic which is steered to the various Integrated
Services deployed. The report is available on a NE or SG level (as long as
Integrated Services are enabled) as a Long-Term or Real Time graph.
Most Active Integrated Services, Most Active Integrated Services by
Server, Integrated Services Distribution and Integrated Services Server
Distribution graphs are available, showing Total Bandwidth, In Bandwidth,
Out Bandwidth and Live Connections.
4-50
To run the Most Active Domains you must first enable the service (The
service can be set to Always Enabled, Always Disabled or Policy Based
from the Integrated Service tab in the Network Configuration window). The
report shows the most active domain names for all the network traffic (if in
always enabled mode) or for the policy entities on which HTTP
Monitoring is selected as an action (if in policy based mode). The report
is available at the in-line platform level as a Long-Term or Real Time Most
Active graph, showing In Bandwidth, Out Bandwidth, Total Bandwidth,
Live Connections, New Connections, Packets In, Packets Out and
Number of Subscribers.
4-51
The WebSafe traffic report shows the HTTP traffic being checked and
filtered by WebSafe (if WebSafe is enabled). This report is available on an
in-line platform level or network level as a Long Term or Real Time
Report, showing Inspected Requests or Illegal URLs per second
Now lets see an example:
Example #1: How many illegal URLs were accessed by my subscribers
over the last 24 hours? Select the network level from the network tree.
Choose long-term reporting and websafe. On the time tab, choose to
show data for the day. On the display tab, choose to display data by
illegal URLs and click on OK.
4-52
This report shows the traffic being used between the selected in-line
platform and each Asymmetry Group member. This report is available on a
device level (as long as the in-line platform has Asymmetry enabled) as a
Long-Term or Real Time Distribution graph, showing Asymmetry In
Bandwidth, Asymmetry Out Bandwidth and Number of Asymmetry
Sessions. The meaning and usage of this report was discussed fully in
Module 02 of this course: Introducing In-line platforms.
4-53
The VOIP minutes of use can help you answer questions such as:
How many minutes of use were consumed by OTT VOIP applications?
How much potential revenue was lost due to VOIP delivered to
subscribers over the top of your network?
4-54
4-55
This report shows the total minutes of use for specific VOIP protocols. It is
available as a Long-Term or Real Time graph. For Real Time it is only
available at 5 minutes or 1 hour data resolutions.
Available filters for graph limitations are:
Service Plans. Service Plans are discussed more fully in the SMP
training course.
4-56
4-57
4-58
4-59
From the display tab on the graph properties dialog, you can choose to
stack any of the top graphs by various parameters. Depending on the
graph selected, you may be able to stack your graph by NetEnforcer, Line,
Pipe, VC, Protocol or Host.
Using the stacking function creates a third dimension to your top graphs.
You can choose the number of instances your graph will be stacked by, up
to 50 instances. The default value is to stack by 4 instances.
Lets see an example of what we mean.
4-60
4-61
Lets see some examples of questions that can be answered using a single
multi-dimensional NetXplorer graph.
Example #1: Which protocols made up the most active VCs on my
network? Solution: Most Active VCs, Stacked by Protocol
Example #2: Who have been the heaviest bandwidth consumers on my
network and what protocols have they been using? Solution: Most Active
Internal Hosts, Stacked by Protocol
Example #3: Which protocols have been taking up the most bandwidth
and how have they been split between the NetEnforcers or Service
Gateways on my network? Solution: Most Active Protocols stacked by NE
4-62
From the Limits tab on the graph properties dialog, you can choose
additional filters to limit the scope of your chosen graph. The graphs can
be limited by parameters such as NetEnforcer, Line, Pipe, VC, Host or
Protocol depending on the chosen graph. This enables you to home in
on the specific objects which you are interested in.
Note that when you use the limiting functionality, the display separately
for each option becomes active on the Display tab. We will see an
example of this shortly.
4-63
4-64
4-65
Lets see some examples of questions that can be answered with the help
of the limiting filter on a NetXplorer graph
Example #1: Who are the heaviest BitTorrent users on my network?
Solution: Create a most active internal hosts graph, limited to the
BitTorrent protocol.
Example #2: Which of all the gaming and streaming protocols are taking
up the most bandwidth on my network? Solution: Create a most active
protocols graph, limited to the gaming and the streaming applications
service groups.
Example #3: Is subscriber 10.10.10.10 the source of malicious traffic?
Solution: Create a statistics graph, measuring new connections and limited
to the particular internal host 10.10.10.10
Example #4: How has subscriber 10.10.10.11 been using the BitTorrent
protocol over the course of a typical day? Solution: Run a typical day
protocol distribution graph, selecting BitTorrent as the object for analysis.
Limit the graph by internal host, to 10.10.10.11.
4-66
In this next section, we will examine the reports and groups functions of
the NetXplorer
4-67
4-68
4-69
The simplest way to save graph definitions as a report is if you are already
viewing the particular graph. If you are currently displaying a real-time
monitoring graph or a long-term reporting graph, you can easily save its
definitions.
To save the graph you are viewing as a report, either
Right-click the graph, and from the shortcut menu, select Add to
Reports.
Or simply click on the Add to Reports shortcut button
A new report is defined and can be accessed, edited and scheduled
from the reports tab.
4-70
Alternatively, you can define a new report using the report wizard.
1. In the left pane, select the Reports tab.
2. Right-click, and from the shortcut menu, select New Report. The
Report Definition wizard is displayed.
3. Set the report name and description as relevant.
4. Click Next to continue defining the report.
4-71
Here you decide on which entity to run the report. This can be a single
entity or a pre-defined group. We will see later how to create a group of
entities.
4-72
Now you choose the report subject and term. Note that if you wish to
create a typical time report, this is indicated in the report term section.
4-73
4-74
You then select the date and time range and data resolution. For long term
reports and reports with a resolution of 1 hour and up, there is also the
ability to determine when the reporting period should work back from (e.g:
show data for the last day starting from the time the report is run, or from
midnight x days ago)
4-75
Here you can decide if you wish to limit the scope of the report
4-76
4-77
4-78
4-79
4-80
You can organize the reports that you define into folders for your
convenience. The folders allow the user to categorize the reports by time
period, policy, devices, etc.
To create a new folder, simply right click on the folder under which you
wish to create a new one, choose New and then Report folder.
You will be asked to enter the folder name and then to Save it.
Reports can be copied and pasted between the different folders.
4-81
Using compound reports you can combine several reports together into a
single PDF file. The compound pdf can be generated periodically and sent
by email to the customer.
You can only choose to combine together in this way reports in the userdefined folder whose output is already in PDF.
Right click on the folder in which you wish to create the compound report
and choose New. Now choose Compound Report.
The Compound Report Properties dialog opens. Here you can give a
name to the new compound report. You will see a list of the existing
reports that you have in PDF format. You can choose which of them to
include in the report, and then if and when to schedule the report and who
to send it to.
4-82
4-83
4-84
In this example, a new group called Global P2P has been set up,
grouping together the Peer to Peer VCs on each of the in-line
platforms in the Network. To view a graph on this group:
1. On the Groups tab, right-click the relevant group.
2. From the shortcut menu, select the required graph type.
4-85
4-86
Which graph can help you answer each of the following questions?
4-87
4-88
Module 5
Condition Catalogs
Catalog entries are the building blocks that we use to make the rules that
comprise our traffic policy. Catalog entries may be conditions or actions. In
this module, we will learn about the catalogs you can use to define
conditions for traffic classification.
Condition Catalogs
5-2
Condition Catalogs
5-3
Condition Catalogs
5-4
The need for classifying traffic may be clear, but what methods should we
use? To take the example of street traffic, we can see that there are many
different categories by which we can classify cars. The car manufacturer,
its color and its maximum speed are just a few possibilities. Which one is
the best?
How we classify depends on what we want to achieve. Classifying by car
color for example may be suitable if you manufacture paint for cars, but
this type of classification is of little use if your aim is to manage the road
system.
Condition Catalogs
5-5
Condition Catalogs
5-6
Condition Catalogs
5-7
Condition Catalogs
5-8
Condition Catalogs
5-9
Condition Catalogs
5-10
Condition Catalogs
5-11
By default, host lists which you define are global. This means that they are
sent to each NetEnforcer and Service Gateway in the network and can be
used by them. If you are working with large numbers of long and detailed
host lists though, this might unnecessarily compromise the performance of
your in-line platform. If you know therefore that the catalogs you have
defined are only relevant to a specific in-line platform on the network, it
may be worth while limiting the scope of the catalog to the relevant
NetEnforcer or Service Gateway.
To set the scope of the entry to a specific device:
1. Click the Scope browse button. The Entry Scope Properties dialog box
is displayed.
2. To make the entry available to a selected device only, select Specific
Device and then select the device from the drop-down list.
3. Click OK. The Host List Entry Properties dialog box is displayed.
4. Click Save.
Condition Catalogs
5-12
Condition Catalogs
5-13
It is also possible to import large groups of hosts from an external text file.
The user updates this text file and the NetXplorer checks for changes
every 10 minutes. As long as the text file is not updated, no NX resources
are used. Note the default value of 10 minutes can be changed. Contact
customer support to enable this change.
Make sure you have the file on the NX at all times (if you delete it, the host
entry based on this file will have no data in it).
There are 3 different methods for importing external text files. The user
can create:
- A new external text file host list
- A new external text file host group
- A new dynamic external text file host group
Condition Catalogs
5-14
What is the difference between the regular External Text File Host Group
(or List) and the DYNAMIC External Text File Host Group?
The dynamic external text file host group functionality was developed to
help customers who wish regularly to use particularly large text files
containing tens of thousands of entries.
With the regular external text file host group we can only support a few
thousand hosts, but the Dynamic version enables us to support many
more 20,000 for the AC-500; 160,000 for the AC-1400/3000 devices;
2,000,000 for a fully populated SG-Sigma or SG-Sigma E6, 5,000,000 for
a fully populated SG-Sigma E14 (500,000 per CC).
There are however, several limitations when using the dynamic
mechanism:
1) It can only be used to support internal hosts.
2) It only supports individual IPs (ranges and subnets will be ignored)
Note that another side effect of the dynamic system is that the IPs
updated with the Dynamic text file are deleted when the NE/SG reboots.
The NetXplorer server will update the IPs again after approximately 10
minutes, but until then there will be no rule matching to the pipes and VCs
in the policy that use those text files in their conditions.
Condition Catalogs
5-15
For example, lets see how to create a new external text file host group.
From the Hosts item in the catalogs pane, choose New External Text File
Host Group. Now, enter a file path to the text file.
Condition Catalogs
5-16
Using this feature, you can import long lists of hosts from an external text
file into a Host Group or Host List Catalog on the NetXplorer.
There are three types of hosts that can be imported: IP address, IP range
and IP subnet. When using the dynamic method, IP address is the only
type of field that can be imported.
Create a text file according to the guidelines defined below, making sure
that you enter each host entry on a separate line. The text file format for
each of the three types of hosts is as follows:
IP address: Name;IP
IP subnet:
Name;IP/Mask
IP range:
Name;IP-IP
Condition Catalogs
5-17
Here we see an example. A text file is created which includes two host
names: IP1 and IP2. IP1 contains two IP addresses and one IP subnet,
and IP2 contains one IP and one IP range.
The External Text File Host Entry Properties dialog is opened and the path
of the text file is entered. In this case the text file has been placed directly
onto the servers C drive. However the file can be located on any machine
that the NetXplorer Server can access.
Here we see the imported host group, consisting of 2 host entries.
Clicking each host entry will show us what it contains.
We can also see an imported host list, which simply extract all instances
of the file to be host items in this host list.
This difference has important implications later when we come to work
with templates (in Module 7).
Condition Catalogs
5-18
Condition Catalogs
5-19
To enable the country classification feature you need a special key for the
NetXplorer Server.
Condition Catalogs
5-20
Condition Catalogs
5-21
When you are working with long lists of hosts, you might lose track of
individual host entries. The host search is used to find a host definition
from within a host list.
1. Select Catalogs and right-click Hosts in the Navigation pane and select
Host Search from the popup menu.
OR
In the Application Details pane, right-click an entry in the Host Catalog and
select Host Search from the popup menu.
The Host Search Properties dialog is displayed.
2. A Host Entry can be searched for by Host Name, IP or MAC address.
Enter the details of the host which you are looking for.
3. Click Search. Results are shown in the Search Results list.
4. Click Close to close the dialog.
Note that the search does not search within host groups.
Condition Catalogs
5-22
Knowing your business objectives, you can use the host catalog to group
different users groups. For example: per geographical location, per
importance to the organization, per packages purchased, per country, etc.
On the other hand you can use host catalog to identify crucial network
elements. Later, you can build your policy to ensure that enough
bandwidth is allocated to each of these network elements.
Can you think of other uses for host catalogs? Share your thoughts with
your trainer and the training class.
Condition Catalogs
5-23
Condition Catalogs
5-24
Condition Catalogs
5-25
Condition Catalogs
5-26
Condition Catalogs
5-27
Condition Catalogs
5-28
Condition Catalogs
5-29
To better understand services and service groups, lets look at the Web
Applications Service group.
This group includes several services: HTTP, HTTP Proxy, HTTPS and
more. Each service is defined by its application signature and by its port
numbers.
HTTP is based on the HTTP application signature, and it includes both a
signature and a port number (80).
HTTPS is based on the Other TCP application and it includes a port only
(443).
We will now review the steps to create a new service, and explain all the
different options available.
Condition Catalogs
5-30
2.
Condition Catalogs
5-31
Condition Catalogs
5-32
For every new service we need to define the entry identification method.
We can also take a recognized application, and re-define the way in which
the NetXplorer tries to recognize it. From the Application Type drop-down
list, select the basic application type, and choose ADD. You can now
manually configure the identification method to either default, signature or
port based. Lets now see what each of these means.
Default: First check all other signatures. If no signature is matched, then
traffic will be identified according to the port specified in the ports
section of this dialog.
Signature: Identifies the traffic according to the signature of origin,
regardless of the port. You can choose to check for this signature on
particular ports or on all ports. By using this method, you can distinguish
between applications which use the same signature on different ports. The
trade off is that before traffic can be identified, the 3 way handshake must
take place at the very least. This means that in some cases, tens of data
packets may pass before the traffic is positively identified.
Port-based: This method is also sometimes called parse by port. If you
choose this method, traffic on this destination port will be identified as the
service you have defined. The application signature on this port will not be
checked. Consequently, the traffic is identified as soon as the first packet
enters the classification engine. This makes it very useful for syn attacks
and other malicious traffic.
Condition Catalogs
5-33
Condition Catalogs
5-34
You can define your own service groups by combining several services
into a single group. Similar services can be grouped if you want to apply
the same QoS policy to them. An example of this is seen on the screen,
where a service group called: Business Applicaitons is created,
consisting of Oracle, SAP and Vonage, with a view to giving this group a
guaranteed quality of service.
Groups are defined for classification purposes, and the NetXplorer
enables you to produce monitoring graphs on service groups, as seen in
Module 4.
Groups combine port recognition and Layer 7 analysis. Within a group, the
identification of one service might be based on Layer 7 analysis, while
another might be identified by port number alone.
Condition Catalogs
5-35
Condition Catalogs
5-36
Condition Catalogs
5-37
These days HTTP is used for a lot more than traditional browsing. HTTP is
commonly used for file sharing application such as MegaUpload,
Rapidshare and more. It is used to view streaming videos via dedicated
web sites such as YouTube and Zulu. It is used for instant messaging
applications, voice over IP, on line gaming, P2P and a lot more. In order to
be able to identify what traffic is flowing over a specific HTTP session, a
more granular classification is required.
Condition Catalogs
5-38
Lets see how Allots in-line platform classifies HTTP traffic. When there is
a matching application, traffic will be classified as the specific application.
For example: Youtube, Rapidshare, etc.
When there is no matched application, traffic will be classified by behavior
to one of the HTTP categories, such as HTTP File Transfer.
When there is no matched application or behavior, traffic will be classified
as generic HTTP.
In case you want to use a more granular HTTP classification, define a
User Defined Signature, based on HTTP header fields. A UDS match is
stronger than all signatures and HTTP categories.
Lets see now what HTTP Header fields can you use to define an HTTP
User Defined Signature.
Condition Catalogs
5-39
Here we see the 5 different request headers that can be defined in the
HTTP UDS with examples for each one.
Host is used for the domain name of the server requested. For example
you can use it to identify all traffic going to www.cnn.com, or all traffic
going to your own home web site. This is a free text field.
Method is used for the desired action to be performed on the resource
identified by the requester. This is a multiple choice field where you can
choose: GET, CONNECT or POST.
Referer is used for the address of the previous web page from which a
link to the currently requested page was followed. For example, when
opening cnn.com from a google search the Referer will show:
http://www.google.com/search?hl=en&q=cnn.com&rlz=1I7RNTN_en <CR>
<LF>. This is a free text field.
URL (URI) is string of characters which identify and locate resources on
the Internet. For example, when opening the Tolly Report from
http://www.allot.com then the URI is: /Tolly_Report.html. This is a free
text field.
User-Agent is used to obtain information about the web-browser or the
type of mobile handset originating the request. For example: Browser e.g:
Mozilla/5.0, Mobile handset e.g: Nokia. This is a free text field.
NOTE: Each field in a UDS may contain a maximum of 69 characters.
Condition Catalogs
5-40
Here we see the 4 different response headers that can be defined in the
HTTP UDS with examples for each one.
Content-Encoding is used for the type of encoding used on the data. For
example: gzip. This is a free text field.
Content-Length is used for the length of the response body in octets (8bit bytes). This field can be set to greater than or lower than.
Content-Type is used for the MIME type of this content (Multipurpose
Internet Mail Extensions). For example: text/html, image/gif, image/jpeg.
This field has predefined values to select.
Location is used for an alternate location for the returned data. For
example: http://edition.cnn.com, http://www.bbc.co.uk/. This is a free text
field.
Condition Catalogs
5-41
HTTP User Defined Signatures (hereinafter UDS), can be used on all AOS
driven products.
HTTP UDS must first of all be activated from the Networking tab which is
accessed by choosing configuration from the NetEnforcer or Service
Gateway. After activating the UDS, create a new HTTP UDS from the Host
Catalog category. You can now add HTTP header fields (up to a maximum
of 16) and define the parameters required for each one. The relationship
between each header is AND, so a match will be made with this UDS if
the flow matches all of the header filters created.
Note: when you create a new UDS, you are actually adding a new service
to the service catalog. Therefore any connection with a matching service
to this new UDS will not match any other service even when there is no
rule for this UDS in the policy. This means that if a UDS is defined but not
added to the policy matching traffic might be classified to the Fallback VC.
UDS cannot be used in an asymmetric environment.
Condition Catalogs
5-42
Here we see a defined UDS to identify all traffic going towards bbc.com or
foxnews.com or cnn.com and the request is for a sport page.
NOTE: UDS is stronger than any other service in your service catalog.
When a session matches both a UDS and an additional service, such as
HTTP Browsing, the session will be identified as the matching UDS.
Condition Catalogs
5-43
Condition Catalogs
5-44
Knowing your business objectives, you can use service catalogs to identify
services and application and control them. For example:
Identify your critical business applications to ensure high quality of
experience for them at all times.
Identify video traffic in your network and optimize your resources using
a video caching service such as Allot MediaSwift.
Identify your own home web site traffic to ensure high priority so you will
always be available.
Identify high bandwidth consuming applications, such as P2P and limit
the available bandwidth for them during peak hours.
We will learn more about how to configure such policies in modules 6 & 7
of this training course.
Can you think of other uses for service catalogs? Share your thoughts with
your trainer and the training class.
Condition Catalogs
5-45
Condition Catalogs
5-46
The Time Catalog contains entries that are used to define the period of
time during which a particular rule is active.
Time Catalog entries are useful when you want to apply conditions to
traffic only on specific days or at specific times. For example, you might
differentiate between work and non-work hours, or give priority to
maintenance jobs run at scheduled times. NOTE: You can use time
catalogs to divide time up as you wish, for example by defining as many
time cycles as you want within a 24 hour period.
If a time catalog has been assigned to a Line, Pipe or Virtual Channel,
what happens when the expiration time is reached?
Both new and existing connections will be reclassified into other Lines,
Pipes or Virtual Channels.
Condition Catalogs
5-47
Condition Catalogs
5-48
Condition Catalogs
5-49
Knowing your business objectives, you can use time catalogs to define
different time slots and control them. For example:
Define peak hours in your network to avoid congestion and allow fair
usage to all subscribers all day long.
Create unique Happy Hour offerings for your subscribers allowing them
to enjoy special bandwidth rates at specific hours of the day.
Define your organization working hours to ensure high quality of
experience for your business applications.
We will see more about how to configure such policies in modules 6 & 7 of
this training course.
Can you think of other uses for time catalogs? Share your thoughts with
your trainer and the training class.
Condition Catalogs
5-50
In this section, we examine the ToS catalog. ToS can serve as a condition
or as an action in your policy table.
Lets begin with a few words of explanation about the Type of Service Byte
in the IP header, and how it can be used.
Condition Catalogs
5-51
The Type of Service, or TOS field, is one of the fields of IPv4 header. It
can be used to differentiate traffic flows one from another. It was originally
designed to support classification of different services by the designers of
the IP protocol. It is an 8 bit field. We will see now common usages of the
TOS field.
Condition Catalogs
5-52
Condition Catalogs
5-53
In the TOS Catalog, you can view the properties of predefined entries and
can create entries that classify the TOS byte using any or all of the 8 bits.
To define a TOS using free format:
1. In the Navigation pane, right-click ToS and select New ToS from the
shortcut menu. The ToS Entry Properties dialog box is displayed.
2. In the Name field, edit the name of the entry and add a description if
required.
3. Define the TOS value by inserting bit values in one of the following
ways:
Click the bit value field boxes (grey indicates 0, black indicates 1).
The decimal equivalent is displayed in the Selected TOS Byte Bit
Settings area.
Enter the decimal or hexadecimal representation of the bit in the
Decimal or Hex fields, respectively.
4.Click Save. The new entry is saved in the TOS Catalog.
Condition Catalogs
5-54
Condition Catalogs
5-55
Condition Catalogs
5-56
The VLAN Catalog contains Virtual LAN entities defined according to the
802.1q standard.
Allots In-Line platforms support VLAN traffic classification according to
VLAN Identifier (VLAN ID) tags, consisting of 12 bits, and according to
tagging priority bits, consisting of three bits.
VLAN catalogs can be used in the policy to assign each VLAN tag its own
priority and QoS definition according to the policies you define.
In order to define a new VLAN catalog, go to the navigation pane, rightclick Encapsulation and select New VLAN from the shortcut menu. The
VLAN Entry Properties dialog box is displayed.
The VLAN ID is computed from the values chosen for Bits 1-12
Bit 13 is the reserved bit
The User Priority value is computed from the values chosen in Bits 14-16
and can be used to specify user priority (where 7 is considered highest
priority, and 1 is considered lowest priority).
Note also that the In-Line platform is transparent to Cisco ISL tagging
(Cisco uses his own proprietary VLAN IDs). In other words, the in-line
platform detects that there is an ISL tag and while it cannot classify traffic
based on that tag ID, the NE/SG can go deeper into the frame to check
regular criteria such as hosts and applications (just as it does with GRE
and MPLS encapsulation).
Condition Catalogs
5-57
Condition Catalogs
5-58
After defining the different encapsulation catalogs you can define a new
encapsulation group with one or more VLAN or GRE catalogs.
To create an Encapsulation Group Catalog entry:
1. Select and right-click Encapsulation in the Navigation pane and select
New Encapsulation Group from the popup menu. Define if you wish to
create a New VLAN Group or a New GRE Group.
2. Complete the Name and Description fields, if required.
3. Select GREs or VLANS in the Available list and use the arrow keys to
move them into the Selected list.
4. Click Save. The new Group entry is saved in the Encapsulation
Catalog.
Condition Catalogs
5-59
Condition Catalogs
5-60
Condition Catalogs
5-61
The final condition catalog which we will examine is the tethering catalog.
Condition Catalogs
5-62
Condition Catalogs
5-63
In order to be able to use tethering, you need a special key for the
NetEnforcer/ Service Gateway.
Once you have tethering enabled, go to the Configuration window,
Networking tab. Make sure Enable Tethering Detection is checked.
Condition Catalogs
5-64
In order to use tethering in the policy, first you have to add the tethering
column to the policy table. Right-click title and select Table Column
Configuration. Make sure Tethering is checked and click save.
Now you can double click the tethering column on any policy rule and
choose one of three options:
Ignore: This condition is not activated. Traffic is matched to the rule based
on the other conditions and irrespective of whether traffic is tethered or
not. This is the default choice for policy rules.
Yes: Match only if traffic was identified as tethered
No: Match only if traffic was identified as not tethered
NOTE: The Fallback Line, Fallback Pipe and Fallback VC cannot be set to
use tethering.
Condition Catalogs
5-65
Condition Catalogs
5-66
Condition Catalogs
5-67
Condition Catalogs
5-68
In order to access Web updates you need a valid support contract as well
as an appropriate key for both the NetXplorer server and all the in-line
platforms which it manages. You obtain these keys by renewing your
support contract.
To check that APU is included in your NetXplorer key (and to enter a new
one if it is not), from the Tools menu select NetXplorer Application
server registration
To perform the same check for the NE or SG, from the Network tree select
the NE / SG and choose Configuration. Go to the Identification & Key
tab. Here you can see if APU is enabled and you can identify the currently
installed protocol pack.
Condition Catalogs
5-69
Condition Catalogs
5-70
If your NetXplorer server can access the Allot WebSite on the internet, the
simplest way to perform manual updates is by using the protocol updates
wizard.
The wizard is accessed from the protocol updates item on the Tools menu.
Choose From Allot Web Site
Condition Catalogs
5-71
Condition Catalogs
5-72
The 3rd and final stage of the process is to update the NetEnforcers or
Service Gateways.
Select the NetEnforcers or Service Gateways that you wish to update. In
the example above there is only one NetEnforcer available. For each NE /
SG you can see the services to be changed by clicking the Advanced
button.
Clicking Next one more time brings you to the end of the process.
Condition Catalogs
5-73
Condition Catalogs
5-74
We have seen how the upgrade package is downloaded using the wizard
and how this process can be configured to run automatically.
There are additional ways to download the update package to the
NetXplorer server which can be particularly useful when the NetXplorer
has no direct access to the internet.
In this case, the package can be downloaded from Allot Support Area and
copied to another server or a CD.
After you have it, go to Tools menu in the NetXplorer GUI, and choose
Protocol Updates from local package to update the NetXplorer. Choose
Install to Device to update the in-line platforms.
Follow the full procedure in the Protocol Pack Release Notes.
Condition Catalogs
5-75
Condition Catalogs
5-76
Look at the entry identification definitions for the service displayed here.
How will the in-line platform identify this service?
Condition Catalogs
5-77
Condition Catalogs
5-78
Module 6
Action Catalogs
As we have seen, catalog entries are the building blocks that we use to
make the rules that comprise our traffic policy. Catalog entries may be
conditions or actions. In this module, we will learn about the catalogs you
can use to define actions which enforce your traffic policies.
Action Catalogs
6-2
Once traffic has been classified into Lines, Pipes and Virtual Channels, we
can take actions on that specific traffic. This represents the A in Allots
Dynamic Actionable Recognition (DART) Technology.
In this module we will look at the different actions which can be taken on
specific traffic flows. We begin by looking at the access control
mechanism, which consists of three pre-defined values, before examining
the Quality of Service engine which is used to shape traffic running
through the NetEnforcer or Service Gateway. We will then explore some of
the service activation options we can use. This action is used to steer
traffic to different services, and also to define WebSafe, HTTP Monitoring
and Captive portal Redirection. Other service activation options will be
covered in the Steering module in more detail. Later we will see how we
can use ToS catalog as an action. We will finish by exploring Denial of
Service and its usage. We begin by looking at the Access Control
mechanism
Action Catalogs
6-3
Action Catalogs
6-4
Action Catalogs
6-5
In case you wish some of the traffic to bypass the NE/SG without a
defined a rule in the policy, you can use the Selective Bypass feature.
Traffic matching a predefined group of VLAN tags bypasses the DART
engine of the system. This, of course requires that all traffic you wish to
bypass should arrive to the NetEnforcer/ Service Gateway with the VLAN
tag you configured.
The bypassed traffic will not be counted in policy rules, connection
establishment rate limitations and total number of connections. It will be
counted towards bandwidth limitations.
To configure selective bypass you first have to define a VLAN Group. This
is explained in details in Module 5: Condition Catalogs. Then go to the
configuration window of the NetEnforcer/Service Gateway, Networking
Tab. Mark the checkbox for Enable Selective Bypass, and choose the
VLAN group for the traffic you wish to bypass. Click save to save this new
configuration.
Action Catalogs
6-6
Lets now review how we can use access control, together with condition
catalogs to serve our business requirements:
Large enterprises can drop all P2P traffic during working hours to free
up bandwidth for business applications
Operators can set their management VLAN to Selective in order to
ensure that important management traffic is not run through the QoS
engine
Can you think of other uses for access control? Share your ideas with your
trainer and the training class.
Action Catalogs
6-7
Lets now focus on the Allot Quality of Service engine and catalogs.
Before we see how to define QoS catalogs, lets first look at why we need
to enforce quality of service at all.
Action Catalogs
6-8
Action Catalogs
6-9
Action Catalogs
6-10
At the heart of Allots quality of Service mechanism lies the QoS Engine.
Based on user definitions, the QoS engine makes a decision for each
frame whether to transmit that frame to the network, to store it in the buffer
or to drop it.
Action Catalogs
6-11
Action Catalogs
6-12
Allots enhanced QoS engine provides support for RFC 2597 (Assured
Forwarding) by offering 4 levels of priority and 3 levels of drop precedence
(supported at the VC level only). When viewed together, this gives us the
12 levels of service stipulated in the assured forwarding RFC.
When traffic exceeds the maximum rate set, the decision on whether to
buffer or drop packets will be taken according to the drop precedence
value assigned to each packet. Packets with a high drop precedence will
be dropped before packets with a low drop precedence.
Action Catalogs
6-13
The four different priority level will be activated in the following way:
Once a minimum was assigned to all objects, the spare bandwidth
allocation will be distributed between the different rules based on priority.
Bandwidth will be allocated by priority weighting only, irrespective of
ingress. This means that the system will ignore how much bandwidth each
rule is asking for, and will divide bandwidth accurately based on the
priority. The calculation of how much bandwidth to assign to each policy
level is proportional to other elements at the same level.
Policy elements with a higher weight will be allocated a bigger share of
bandwidth.
Lets now see an example. Imagine we have 200Mbps of HTTP traffic and
100Mpbs of FTP traffic which must be shaped into a pipe with a maximum
rate of 100Mbps. If the NetXplorer operator assigns a priority of 1 to the
HTTP VC and a priority of 4 to the FTP VC, the HTTP VC will be assigned
20Mbps and the FTP VC will be assigned 80Mbps.
The allocation of bandwidth is performed irrespective of the ingress rates.
The bandwidth allocated to each element is determined by dividing the
element weight (e.g: 1 for the HTTP VC or 4 for the FTP VC) by the total
weight, which in this example is 5 (1+4) and multiplying by the total
available bandwidth (in this case 100Mbps as determined by the pipe
maximum).
Action Catalogs
6-14
Quality of Service can be assigned per Line, Pipe and Virtual Channel.
These assignments can be combined to provide a more granular quality of
service.
The NetXplorer QoS catalog offers 6 options. The Line, Pipe and QoS
catalogs are for use with all non-AOS products (e.g: AC-400). The
enhanced QoS catalogs are for use with all AOS driven products (e.g: SGSigma, SG-Sigma E, AC-1400, AC-3000, AC-500)
Action Catalogs
6-15
Action Catalogs
6-16
Action Catalogs
6-17
When setting some elements to have priority, and some to best effort at
the same policy level this could cause a situation known as bandwidth
starvation. When the traffic assigned by each rule competes for the spare
bandwidth, the rules set to best effort will be given an element weight of
zero.
Looking at the equation we use when we calculate the allocated
bandwidth for each rule, we can see that for element weight zero, the
allocated bandwidth will also be zero. This means that no bandwidth will
be allocated to this rule at all.
In case you try to save such a policy, where at the same policy level you
are combining priorities and best effort QoS, the NetXplorer will alert you
to this. Click Yes to save the policy as it is, or No to adjust the policy.
Important Note: Default QoS values (Normal Line QoS, Normal Pipe QoS
and Normal Virtual Channel QoS) are all set to Best Effort. Make sure not
to mix them with priority QoS on the same level.
Action Catalogs
6-18
Action Catalogs
6-19
Action Catalogs
6-20
Here we see the Enhanced Pipe QoS entry properties dialog. Note the If
Minimum Pipe Bandwidth is not Allocated field. This feature is available
for Enhanced Lines, Pipes and VCs and will be discussed now.
Action Catalogs
6-21
Action Catalogs
6-22
Action Catalogs
6-23
Here we see the Enhanced VC QoS entry properties dialog. Note the
Expedited Forwarding option and the Drop Precedence field. These
features are available for Enhanced VC QoS catalogs only and will be
discussed now.
Action Catalogs
6-24
Expedited forwarding enables first-class service level for real time traffic
which is loss-sensitive, delay-sensitive and jitter-sensitive and can also
handle traffic bursts efficiently. With this feature users can ensure QoE for
real-time applications such as VoIP and Videoconferencing services.
Allots implementation of this feature is in accordance with RFC2598.
How does the feature work? Expedited forwarding traffic (unlike traffic for
which a regular maximum is defined) is not smoothed. Unlike traffic for
which a regular maximum is defined, the Expedited forwarding defined
rate can be allocated entirely in the first millisecond (burst). When starting
to transmit in the middle of the second the traffic is allowed to breach the
maximum of the hierarchy object above. In order to provide the specified
rate to be Expedited, the QoS engine provides this rate at the expense of
other VCs in the subsequent second.
Action Catalogs
6-25
Action Catalogs
6-26
Action Catalogs
6-27
Action Catalogs
6-28
On occasion, traffic that does not require any shaping must pass through
the NetEnforcer or Service Gateway. Lets see an example of this from the
enterprise field. A customer may have a DMZ connected to its firewall. A
DMZ is the semi-protected area where equipment that needs to be
accessed from both inside and outside the firewall is placed. In this
example, traffic flows from the LAN to the WAN and from the LAN to the
DMZ. If the NetEnforcer is configured to limit internal bandwidth to
10Mbps and external bandwidth to 2Mbps, the NetEnforcer assumes the
traffic flowing to the DMZ is actually going out to the WAN, and therefore
limits the output to a total of 2 Mbps instead of 10Mbps.
To overcome this problem, You can use the predefined "Ignore QoS" entry
in the QoS catalog. The traffic will go through the NetEnforcer at wire
speed and will not be calculated as part of the allowed bandwidth in the
NetEnforcer.
It is recommended to create a pipe or VC and set the QoS level to Ignore
QoS for traffic going from the LAN to the DMZ and vice versa, or for other
LAN traffic passing through the NetEnforcer that does not require shaping.
"Ignore QoS" can also be used in a service provider environment, for
example, some providers choose to set up a pipe or VC for BGP traffic
and set it to ignore QoS.
Note: The Allot default policy applies ignore QoS on the network
operation VC.
Action Catalogs
6-29
The QoS catalog is the heart of all Action Catalogs. This is the catalog
which allows you to apply all the different principles we have reviewed
throughout this module. With the various options of this catalog you can
tailor your bandwidth to maximize every single bit of traffic.
For example:
Set a minimum bandwidth level in order to ensure available bandwidth
for important traffic
Set maximum Bandwidth in order to limit P2P traffic
Set expedited forwarding to ensure VoIP quality
Set priority to ensure desired precedence in times of congestion
Can you think of other uses for QoS control? Share your ideas with your
trainer and the training class.
Action Catalogs
6-30
To summarize this section of the module, have a look at this Policy table,
which implements the example from the previous slide.
Action Catalogs
6-31
We will now examine different services which can be activated using the
service activation catalog. This includes steering both to external
services and to integrated services such as WebSafe and HTTP
Monitoring. We will begin by taking a brief look at how to steer traffic to
services using the local service and integrated services catalogs. This will
be examined only at a conceptual level here. A separate training module
covers steering in more detail.
Action Catalogs
6-32
Action Catalogs
6-33
Action Catalogs
6-34
Action Catalogs
6-35
Action Catalogs
6-36
We will now look at Websafe and HTTP monitoring, both of which are Allot
services, integrated into the AOS software. We will then see how to define
a captive portal for redirection.
Action Catalogs
6-37
WebSafe and HTTP Monitoring are additional services available with Allot
in-line platforms. HTTP Monitoring allows you to see the Most Active
Domains graph. It holds up to 1000 most active domains. The service
must be enabled and does not require a special key.
Action Catalogs
6-38
Action Catalogs
6-39
Right click on Network to open the Configuration dialog and select the
Integrated Service Tab
At the bottom of the tab you can choose the default policy action for
WebSafe and HTTP Monitoring.
If always disabled is chosen, the service will not be activated
If always enabled is chosen, the service will be activated on all traffic
running through the Service Gateway or NetEnforcer. This means, for
WebSafe, that HTTP traffic from all subscribers will be inspected,
irrespective of their Service plans.
For HTTP Monitoring, this means that the graph that will be generated
will sum up the Most Active URLs for all traffic running through the system.
If policy based is chosen, the service will be activated only on traffic that
is classified into those policy entities (lines, pipes or VCs) for which the
action catalog is chosen in the policy.
This means, for WebSafe, that HTTP traffic from only those subscribers
whose service plans include this action will be inspected. For HTTP
Monitoring, this means that the graph that will be generated will sum up
the Most Active URLs for all of the lines, pipes and VCs with which this
action is associated.
Action Catalogs
6-40
If working in policy based mode, you will be able to use the predefined
HTTP Monitoring and WebSafe catalog entries that can be found in the
Service Activation catalog type. These entries cannot be altered they
should simply be added to the appropriate line, pipe or VC as required.
Here we can see an example based on the policy table we saw earlier at
the end of QoS section of this module, with the addition of WebSafe &
HTTP Monitoring service activation catalogs.
HTTP Monitoring enables the Most Active Domains graph which was
introduced on Module 04 Monitoring and Reporting.
We will now see how to configure the different options for WebSafe.
Action Catalogs
6-41
Action Catalogs
6-42
From the integrated services tab, the operator can define different options for the
WebSafe Service. (The Integrated Service Tab is accessed by right clicking on
the network and choosing configuration)
The Blacklist Source definition enables the operator to define an external
blacklist source. You can then determine how often to download the list, how to
track the server availability, and enable event notification of Allot server
reachability. All of this functionality equires an additional NetXplorer license.
User Defined Files refer to the blacklist, whitelist and the warning page (which
we will explain later). The default location of these files on a Linux server is:
/opt/allot/NetXplorer/jboss-5.1.0.GA/server/allot/websafe. On a Windows server
the path is: \Allot\netxplorer\jboss-5.1.0.GA\server\allot\webSafe. You can
change the location from the dialog here.
Using the Action on match field you can define what you want to do to a
connection which matches one of the blacklist URLs. The options are:
Monitor. The connection will be allowed, and the operator will be able to see it in
the NetXplorer WebSafe Graphs.
Block. In this case the connection will not be established.
Block and send subscriber to a warning page. In this case, the subscriber will
see a warning page configured by the operator. We will see how to create this
page shortly.
Block and redirect subscriber to a Captive Portal. In this case, the subscriber will
be redirected to a specific URL
Action Catalogs
6-43
Here we see a list of the acceptable formats for the black or whitelist text
files. Each NE/SG holds one blacklist file and one whitelist file. Any legal
URLs are acceptable (there should be no white spaces within paths).
WebSafe considers www.badsite.com and badsite.com to be different
sites. The URL entered may be with or without the http:// prefix. URL paths
(after domain name) may include anything. NOTE: HTTPS and FTP sites
are not currently supported.
Action Catalogs
6-44
The option to block and send warning page refers to the warning.html
file located on the NetXplorer server.
The default warning page is shown here. The warning.html file is
customizable, but must be less than 900 bytes. Any HTML syntax may be
used (e.g: reference to scripts, images). NOTE: if you add a new
warning.html to the NetXplorer at C:\Allot\netxplorer\jboss5.1.0.GA\server\allot\webSafe , this will replace the default Allot warning
file with no option to revert to the default warning page
Action Catalogs
6-45
Action Catalogs
6-46
Action Catalogs
6-47
To define a new captive portal from the Service Activation catalog, choose
New Captive Portal, enter the name and description, the URL to redirect to and an action in case HTTP redirect fails. You can choose HTTP
or HTTPS as the redirection protocol.
When working in mobile environments, you can send the customers
original URI and/or MSISDN to the portal. To do this you will need to set
the Captive Portal URI as follows: www.captive.com/landpage?ms=
<Fill in> Fill in {ORIG_URI} or {MSISDN} or {MSISDN}{ORIG_URI}. You
can add up to 16 characters here. The customer will need to configure his
portal to parse these fields to extract the MSISDN or ORIG_URI.
In the Http Redirection Fail Action field, configure what will be done with
non-HTTP traffic passing through this particular pipe or VC (i.e: VoIP
traffic). If you select Pass As Is then it will be allowed to pass and reach
its destination (i.e: allow VoIP sessions, but redirect HTTP traffic to the
active portal). If you select Drop then non-HTTP traffic will be blocked.
In the NE/SG configuration window it is possible to define the redirection
technique. Choose one of 3 options: On Request: The session is
redirected to the predefined portal when the NE/SG sees the HTTP
request. On Reply: The NE/SG tries to learn potentially asymmetric
encapsulation environment in order to figure out the Reply encapsulation
which needs to be used for the packet sent to the client. Example: MPLS,
where the MPLS tag is different between the Request and Answer of the
same connection Default: Chooses the appropriate method per session.
Action Catalogs
6-48
Both WebSafe and HTTP Monitoring help the operator generate more
revenues and better meet subscriber or regulatory requirements. For
example:
HTTP Monitoring can be set by the policy to monitor all HTTP traffic.
The marketing department will then check what are the most popular
sites, and create unique packages for them, approach particular sites
with a view to revenue sharing agreements or publish advertisements in
those sites.
Websafe can be used to offer a parental control package to the
subscriber or to meet regulatory requirements for blocking illegal
content.
Can you think of other uses for these services? Share your thoughts with
your trainer and the rest of the training class.
Action Catalogs
6-49
Now we will see how to use the ToS catalog, which we have seen as a
Condition Catalog in Module 5, as an action catalog as well.
Action Catalogs
6-50
The ToS Marking action catalog is defined in exactly the same way as the
ToS condition catalog. ToS marking might be used for example to let an
MPLS network know which applications to prioritize.
Action Catalogs
6-51
Action Catalogs
6-52
The DoS (Denial of Service) Catalog enables you to control the number of
connections and the rate of connections established per policy. For
example, if the user wants to limit the number of Voice over IP
connections, a maximum can be placed on the number of connections
allowed in the Voice over IP Virtual Channel. Connections above the limit
can simply be dropped.
Action Catalogs
6-53
Action Catalogs
6-54
From the DoS entry properties dialog, you can limit the total number of
connections and the number of connections that can be established per
second. You can also specify the action to be taken when these limits are
exceeded: Drop or Reject (Reject is available only in the Allot Legacy
product, the AC-400, which is no longer sold).
This DoS catalog can then be assigned to a Line, Pipe or Virtual Channel.
You can, for example, limit the number of simultaneous connections for
specific users by creating a catalog entry and applying the policy to those
users.
The In-line platforms also have a CLI command (go config cer) which can
set a maximum Connection Establishment Rate limit for the in-line
platform. When this value is reached it is possible to select one of two
actions to take place:
Drop: Every session over the CER limit will be dropped.
Bypass: Every session above the CER limit will be bypassed and will
not go through any of the DPI mechanisms.
NOTE: The maximum value entered in the CLI command cannot be
greater than 10,000 for an AC-500, 50,000 for an AC-1400 or AC-3000
and 150,000 per Core Controller on a Service Gateway.
Action Catalogs
6-55
Action Catalogs
6-56
Connect the access control values on the left with their definitions on the
right
Action Catalogs
6-57
For each of the 4 different enhanced QoS settings, what bandwidth would
you expect to be allocated to the HTTP VC and the VoIP VC in the AC1400 in the picture? Bear in mind that the Pipe in which these VCs reside
is set to a maximum of 10Mbps, HTTP traffic is being received at 20Mbps
and VoIP at 10Mbps.
Action Catalogs
6-58
Module 7
Building the
Enforcement Policy
The catalog entries are the building blocks of your policy. Once the
required catalog entries have been created, you can now put them
together to define your policy.
7-2
In this module, we will see how to create traffic policies for different
customer scenarios. By the end of this module you will know how to create
the rules that make up your policy, how to position them correctly in the
policy hierarchy, how to use pipe and VC templates, and how to distribute
an existing traffic policy to additional NetEnforcers or Service Gateways.
After explaining the principles, we will explore different implementation
concepts and see how to take it from training class to real live networks.
First, lets understand the hierarchical structure of the traffic policy.
7-3
NetXplorer monitors and controls a network that may include one or many
NetEnforcers or Service Gateways.
Traffic flowing through these in-line platforms falls into different pre-defined
lines. Each line is further divided into Pipes that break down into Virtual
Channels. Each Line, Pipe or Virtual Channel has a set of conditions that
can be defined for it.
When traffic flows through a NetEnforcer or Service Gateway, it is
compared to the conditions of the first Line. If the conditions apply, the
traffic is then tested against the conditions of the pipes within that line. If
the condition of the first line does not apply, the traffic is not classified into
the first line; the condition of the second Line is tested.
The policy table always consists of at least one line, the Fallback line.
This line is the last one listed in the Policy table, and its conditions are set
to accept all traffic. Traffic that does not meet the conditions of any other
Line is classified into the Fallback Line, and then into one of that Lines
Pipes. The same classification takes place for pipes within the line and
virtual channels within the pipe. In each case, if no match is found, traffic
falls into the fallback line, pipe or VC. In this way, every traffic flow finds its
home in a Line, a Pipe and a Virtual Channel. The fallback rule is like the
palm of a hand, catching all unmatched traffic from higher rules. It is
marked with a palm icon.
Each line, pipe or Virtual Channel has a set of actions that can be
performed on the traffic that is classified into it.
7-4
7-5
Because of the way in which traffic is classified from the top of the policy
table to the bottom, the order in which you place Lines, Pipes and Virtual
Channels in the Policy table is of the utmost importance.
Lets take a small service provider example. The North line represents all
users from the northern area, using a designated IP range.
A pipe can be defined for the business user with the specific sub-range of
only the business users, or by a ToS for example. This pipe is placed at
the top of the pipes table to ensure that all business users are classified
here regardless of the applications which they are using. All other northern
users, not part of the business users group, will be classified to the pipes
below Business pipe.
Another example is a Flickr pipe, which classifies Flickr traffic. The Flickr
service is included in the Web Applications Service Group. If the web
applications pipe was placed above the Flickr pipe, all of the Flickr traffic
would be classified in the web applications pipe and the flickr pipe would
remain empty. Hence the importance of placing more specific conditions
higher in the hierarchy table than more general conditions.
The exception to this rule is a condition based on User Defined
Signatures. As soon as a UDS is defined, it is excluded from the web
applications (even if it is not added as a condition to a rule). If a rule is
created classifying UDS traffic therefore, it is of no consequence where in
the hierarchy that rule sits.
7-6
Now lets see how to create the rules which make up our policy table.
7-7
The Enforcement Policy table displays the Lines, Pipes and Virtual
Channels defined for each NetEnforcer or Service Gateway. By default,
the Fallback Line and fallback Pipe are defined. Within the fallback pipe
are a number of virtual channels which classify traffic according to popular
service groups. A fallback Virtual Channel catches all other traffic.
For each entity in the Policy tree, the classification conditions and actions
are displayed as columns. The conditions and actions that can be selected
here are those which have been defined in the catalogs section of
NetXplorer.
Note that the following catalogs: Quota, Service Plan, Charging
Application, Charging Plan and Mobile Device are used only in conjunction
with the Subscriber Management Platform (SMP). This is covered in detail
in the SMP training course.
7-8
To add new lines, pipes or VCs, from the network view, select an entity
and choose Enforcement policy editor.
To add a Line, select an existing line and choose the insert line icon.
Alternatively, you can simply right click on the existing line and choose add
line. A new line will be added directly above the line you selected.
To add a Pipe, select an existing pipe and choose the insert pipe icon.
Alternatively, you can simply right-click on the existing pipe and choose
add pipe. A new pipe will be added directly above the pipe you selected.
Finally, to add a VC, select an existing VC and choose the insert VC icon.
Alternatively, you can simply right-click on the existing VC and choose add
VC. A new VC will be added directly above the VC you selected.
7-9
After choosing to add a Line, Pipe or VC, its properties dialog opens, with
a default rule that accepts all IP based traffic irrespective of host, service
and time, and passes it through the NE or SG without applying QoS.
The top part of the dialog displays the conditions. The conditions are
edited by clicking on the edit button. A conditions properties dialog opens
with drop down lists for each type of condition. Here you can choose from
the different condition catalog entries available. Alternatively, you can
double click on one of the conditions in the pipe properties dialog, to
choose a different condition.
The direction field has 3 options: bidirectional, int to ext and ext to int.
Whichever option you choose here, the rule will contain both directions of
traffic (inbound and outbound). The direction field is a criteria of
classification on connection establishment, not the direction of the traffic
flow. Internal to External means that the internal host is the client. It sends
the TCP SYN while the external host is the server. If the direction is
External to Internal, the external host is the client, and it will send the TCP
SYN, while the internal host is the server. When bidirectional is chosen,
the policy doesnt care what side has established the connection.
The bottom part of the dialog displays the actions. Different actions can be
chosen from the drop down lists for the access control and each type of
action catalog. Note that if you are defining actions for a pipe, then only
pipe QoS catalogs will be displayed in the Quality of Service drop down
list. The same is true of course, for lines and VCs.
7-10
Here we see an example of a rule that has been created, called Gold 2.5.
Lets follow the logical relationship between the different conditions and
actions in this rule. The rule states that IF the internal host matches with
the gold users catalog, AND the service is one of the services contained in
the P2P Applications service group AND the time is over the weekend, as
defined in the time catalog, THEN the traffic will be accepted and shaped
according to the chosen QoS catalog, to a maximum of 2.5Mbps.
7-11
We can also add an additional set of conditions to the same rule. This is
done by clicking on the add button.
7-12
After selecting the extra set of conditions for our rule, we now see a
second line in the conditions section of the dialog. The logical relationship
between these conditions is as follows IF all of the conditions in the first
line are met OR all of the conditions in the second line are met, THEN the
common set of actions should be applied.
7-13
When the rule is saved it appears in the policy table as follows. Note how
the actions are common for both sets of conditions and the pipe name is
also carried over from one line to the next.
The rule will appear in blue until it is saved on the NetXplorer and
accepted on the NetEnforcer or Service Gateway
Its position in the policy table can be moved up and down by the arrow
icons.
7-14
If you create a policy rule where both the Internal and External hosts are
based on country classification host catalogs, this generates a large
number of internal rules that may slow down the NetEnforcer/Service
Gateway or cause it to exceed its inbuilt number of internal rules.
For better performance it is recommended to create a rule for which the
Internal host is Any and the External host is a selected country or the
other way around.
Consequently, traffic that passes through the NetEnforcer or Service
Gateway and is targeted to a country that appears in the host entry of the
configured policy will be automatically assigned to this policy.
7-15
Lets now see how you can create pipe templates and VC templates, and
in what circumstances this can help you.
7-16
A Pipe or Virtual Channel template enables the fast creation of Pipes and
VCs which are differentiated by source or destination. This means that you
do not need to define similar Pipes and Virtual Channels when the only
difference between them is the IP address in the source or destination.
All that is required is to create a single master pipe or VC called a
template. You then simply define a set of hosts which will expand the
template. Whenever traffic is generated to or from one of the specified
hosts, the template creates a new pipe or VC. When the conversation
finishes, the pipe or VC is deleted.
7-17
Lets now look at two examples which contrast the two methods for
creating a Pipe. In the first example, we create a set of Pipes into which
traffic is classified. In the second example, we create Pipe templates that
expand into Pipes based on current traffic.
A company that only has three branches can define a Pipe for each
branch, to apply different QoS for each branch. NetXplorer analyzes the
network traffic and classifies it into a Pipe representing the branch from
which the traffic originated.
A retail chain with hundreds of branches that wants to apply the same
QoS to each branch need not define each branch as a Pipe. In this case,
a Pipe template can be defined for all branches. When a subscriber
connects, NetXplorer applies the appropriate Pipe template and creates a
new Pipe for that branch.
Pipe templates can cut the time involved in defining individual Pipes. They
also make it easy to apply changes. Lets suppose that in our template
example, each branch was allocated a maximum bandwidth of 1.5 Mbps.
The network has now been improved and each branch can be given
2Mbps. You need only change the Pipe template to apply the changes to
all Pipes within the template.
7-18
The Pipe Template properties dialog is the same as the Pipe Properties
Dialog, with one difference. You will see in the template settings area, you
have the choice to set the template instances to expand by internal or
external hosts.
Select Internal if you wish a new instance to be generated for each new
Internal connection (default).
Select External if you wish a new instance to be generated for each new
External connection.
Note that there may be some cases where you wish to expand a pipe or
VC template by Any internal or external hosts. If for example you want to
protect your email server (internal) from spam (external). You can create a
pipe based on the email server, with a VC template underneath it. The VC
template will be set to expand on any external hosts and you limit the VC
to 5 or 10 live connections.
7-19
Here we see the VC template properties dialog, which is much the same
as the Pipe template properties dialog. Note however that you cannot
insert a VC template inside a pipe template.
7-20
Host lists and host groups are treated differently when used to expand a
template.
When a Pipe template is expanded by a host list, a separate Pipe is
created for each individual host on the host list. This option can be useful,
for example, when a host list includes a list of addresses used by home
subscribers, in which each subscriber needs to be allocated a Pipe with a
QoS definition based on the subscribers SLA.
When a Pipe template is expanded by a host group, one Pipe is created
for each host list in the group. For example, a host group Large
Branches can includes 50 host lists. Each host list represents a branch,
and can include many individual hosts. This would be used for example, in
cases where a Pipe needs to be created to manage the traffic for each
branch, not for each host within a branch.
7-21
7-22
Once your policy has been defined, it can be easily distributed to other
NetEnforcers or Service Gateways on the network. Lets now briefly see
how this is done.
7-23
7-24
From the Network view, right click on the NE or SG whose policy you wish
to distribute and choose policy distribution.
The policy distribution dialog opens. The dialog will be populated only with
those NEs that are of the same series and have the same version
installed.
By selecting the checkboxes, you can choose to which NEs or SGs to
distribute the policy. You can also choose to abort the distribution on the
first error, should one occur.
Click on distribute to distribute the policy.
7-25
7-26
The first step of building the policy is planning what you want to achieve.
You should first ask a few guideline questions. Answering these questions
will give you the baselines for building your policy.
What do you want to achieve? Put differently, what are your business
objectives? Lets take a small service provider as an example. This
service provider wishes to offer different quality of service guarantees
for two subscriber groups: domestic and business.
How many policy levels will you need? 2 levels will be enough here: one
for the subscriber groups. As we will want to control bandwidth per
subscriber, templates must be used. The second level will be for
internet activities. So you will choose Pipes & VCs. Alternatively, you
can and use Lines & Pipes, which will allow you to have another level
for further classification.
How will you classify traffic? In this example, we will use IP subnet
classification for subscriber groups and application-based classification
for internet activities. This answer will guide you in creating your
condition catalogs.
What actions will you apply? QoS will be used for different packages
and applications inside the packages. Access Control will be used for
dropping some traffic. This answer will guide you in creating your action
catalogs.
Lets see now how to implement this.
7-27
How would you build your policy? Share ideas with your trainer and the
training class.
Refer to the different catalogs you will have to define, the structure of the
policy (which rules will be on top?) and the policy rules themselves.
7-28
Have a look at this Policy table, which implements the example from
previous slides.
The following catalogs were used to build this policy:
Host Catalogs are used at the pipe level, with three catalogs defined
(Business, VIP and Home). Each catalog includes the IP subnet allocated
to the subscribers. In addition, pre-defined service catalogs are used to
classify traffic at the VC level.
7-29
The instructor will now split you up into groups. On the next 3 pages of
your Student Guide you will see 3 different policy structures.
Each one uses templates to achieve different goals.
Examine each policy structure in your group and discuss for each one,
what it enables the Service Provider to control and what the Service
Provider cannot control. Write down any further advantages or
disadvantages that you see with each policy.
When you have finished, you will be asked to present your findings to the
class.
7-30
7-31
7-32
7-33
Based on the policy below, into which pipe and VC will a bronze
subscriber using a peer to peer application on a week day fall?
7-34
Fill in the correct words (AND, THEN, IF, OR) to describe the rule that you
see in the screenshot.
7-35
7-36
Module 8
Events and Alarms
Now that we have defined our basic traffic policy, we can also decide
when and how we would like to be informed about abnormal network
activity or particular scenarios that require our intervention.
8-2
8-3
In this module, we will explain the process for defining alarms, defining
alarm actions and then assigning them to the relevant entity on your
network. We also show how to configure events, and how to view both
events and alarms from the NetXplorer GUI.
8-4
8-5
8-6
8-7
8-8
Here we see examples of the types of alarms that you can define.
This particular user has defined the following:
A minor alarm to notify when total bandwidth on the entity chosen rises
above 950Mbps
A critical alarm to notify when disk usage on the in-line platform rises
above 85%
A major alarm to notify when more than 90% of the in-line platforms
memory is being used
A major alarm to notify when more than 35,000 VCs are active
A warning alarm to notify when more than 100 new connections are
established per second
8-9
In addition to having the alarm displayed in the Alarms and Events log,
you can define an alarm action. The alarm action can be an email
notification that is sent when the alarm is triggered, or a script that is run.
For an email notification, you can define the email address to which the
email notification is sent.
In order to send email notifications, an SMTP server to be used for
sending the email must first be configured.
8-10
8-11
For a script action, you should define the alarm script path and the cancel
alarm script path. Scripts can be used to notify other systems or people,
trigger activities on other network elements, use Allots Server CLI to
change policy configuration or any other action you choose to take.
The New Alarm Action dialog opens. Set a name for the action, and enter
a path to the script in the Alarm Script Path field (and a script for ending
the action if applicable, in the Cancel Alarm Script Path field) Click Save
to set the action
The NetXplorer sends device ID, line ID, pipe ID, VC ID and Mediator
Device (SMP/STC) ID for use in the script. The parameters are sent in the
order and format shown below:
DEV_ID:<id> LINE_ID:<id> PIPE_ID:<id> VC_ID:<id>
MD_ID:<id>
In case a particular parameter is not defined, a value of none will be
returned. So an example of the parameters sent might be: DEV_ID:16
LINE_ID:1 PIPE_ID:6 VC_ID:0 MD_ID:none
8-12
Once alarm entries and actions have been defined, you can assign them
to different network entities. There are separate procedures for assigning
alarms to a NetEnforcer or Service Gateway, and for assigning alarms to
Lines, Pipes and VCs within that NetEnforcer or Service Gateway.
To assign an alarm to a NetEnforcer or Service Gateway:
1. From the Network view on the Navigation pane, right-click the
relevant NetEnforcer in the Network tree and select Alarm Definition
Assignment. The Alarm Entries Assignment Editor dialog box is
displayed.
2. From the Alarm drop-down list, select the required alarm. This list
only includes alarm entries that can be assigned to an in-line
platform.
3. Set the action to occur when the alarm is generated by selecting the
Alarm Action or No Alarm Action option, as relevant. If you select
Alarm Action, select the type of action from the drop-down list.
4. Click Save.
8-13
The alarm which we have created is added to the Alarm Assignment list
for the selected NetEnforcer or Service Gateway.
To view alarms currently assigned to the NetEnforcer or Service Gateway,
right click the relevant NetEnforcer from the Network tree in the Network
navigation pane. Once again, choose Alarm Definition Assignment but this
time choose to view the Alarm Definition Assignment List.
8-14
You can pair together alarms and alarm actions and add them to
each network entity.
You can only choose alarms that are applicable for that network
entity.
8-15
The Alarms column of the policy editor indicates which Line, Pipe or Virtual
Channel has an alarm assigned to it.
Note that a quick way of assigning a new alarm to a Line, Pipe or VC is
simply to click on the relevant alarm icon.
8-16
Now lets see what events are and how we can configure them
8-17
All Allot elements in the network send events to the NetXplorer server
which are recorded in the NX events log. A subsection of these events
not all of them - can be configured by the NetXplorer Operator from the
NX GUI. For particular events, the operator can decide to record alarms,
and set their severity. Alternatively, the operator may write a script which is
triggered when the event occurs. Finally, the operator can determine that
certain events are forwarded by the NX to an external trap receiver. This is
particularly useful for some service providers who prefer that SNMP traps
are sent from a single point of integration to the Network Management
System. This may prove a more efficient or cost-effective alternative to
opening SNMP interfaces opposite every Service Gateway, Distributed
Collector and SMP server in the network.
NOTE: Some of the events are forwarded automatically, while for others,
the system administrator can configure whether or not to forward the trap
to the trap server. For a full list of User Defined and Automatic Traps that
can be forwarded from the NX, see the SNMP Integration Guide
8-18
Events are specific occurrences that are recorded for network elements.
NetXplorer comes with a set of predefined events that are automatically
logged by the system and can be viewed in the Events log. Events are
assigned predefined types, and can be configured to trigger alarms. To do
this, go to Events/Alarm pane in the NetXplorer GUI, and open Event
Types Configuration screen. There you can double click the Alarmable
column.
The severity of the alarm can also be configured, by double clicking the
Severity column in the same screen. Alarms triggered by events are
displayed in the Alarms log.
All events created by the in-line platforms, STC and SMP are
automatically sent to the Allot NetXplorer Server, and appear in the server
events log. If an external trap server has been defined, some of these
events are automatically sent to it. For other events, the administrator can
decide whether to send traps or not. This is done by clicking the External
Trap checkboxes.
8-19
Select the Action checkbox for any event you wish to trigger a script
action for. Configure the script action by right clicking the event and
selecting New Alarm Action Definition from the drop down menu. The
New Action Alarm dialog opens. Set a name for the action, and enter a
path to the script in the Event Script Path field (and a script for ending the
action if applicable, in the Cancel Event Script Path field) Click Save to
set the action. Once assigned, the action will appear in the Action on
Alarm field at the bottom of the Event Type Configuration window when
the relevant event is selected. An action can be deleted, edited and
copy/pasted to another event.
NOTE: The NetXplorer sends device ID, line ID, pipe ID, VC ID and
Mediator Device (SMP/STC) ID for use in the script. The parameters are
sent in the order and format shown below:
DEV_ID:<id> LINE_ID:<id> PIPE_ID:<id> VC_ID:<id>
MD_ID:<id>
In case a particular parameter is not defined, a value of none will be
returned. So an example of the parameters sent might be:
DEV_ID:16 LINE_ID:1 PIPE_ID:6 VC_ID:0 MD_ID:none
8-20
To configure the external server to which traps from the NetXplorer should
be forwarded, follow the procedure below. From the network pane in the
NetXplorer GUI, choose Network. Right click and select Configuration.
Select the SNMP Tab. Set the appropriate community for the external trap
server by filling in the Community field in the NX Agent window. The
default community is public. Click on Add and enter the target IP address
of the external trap server and the target port. The default target port is
162. Choose OK. The chosen external trap server will appear in the Trap
Target dialog.
8-21
8-22
The Alarms log tab is displayed in the NetXplorer window and provides a
list of all open alarms generated by the system (both user-defined and
event-based). An alarm remains open until the condition that generated it
is no longer valid, or it is manually removed by an operator.
In the Network tree, you can see an indication of the highest state of alarm
or event for each entity.
To view events and alarms for a specific entity on the Network tree, use
the Events log. The Events log displays events and alarms only for the
selected entity, excluding its child entities. For example, when you view
network events, events on NetEnforcers are not displayed.
8-23
Each entity on the Network tree can have two alarm indications:
1. An alarm indication about itself. This is represented by a colored ball in
the lower right. The color of the ball represents the highest state of
alarm for this entity. Here we can see that NetEnforcer HQ 1 has a
major alarm, and that the Fallback Pipe has a critical alarm.
2. An alarm indication about the state of the entities below it. This is
represented by an exclamation mark to the left of the entity. In the
example, we can see the critical alarm on the Fallback Pipe is reflected
in the network, NetEnforcer HQ1 and its Fallback Line. Below the
network there is both a major alarm (on NetEnforcer HQ1) and a
critical alarm (on the Fallback Pipe). The color of the exclamation mark
is red, since it is the higher state of the two alarms.
8-24
Lets see in more detail how to view events. You can view the Events
log entries for any specific network component.
To view event log entries:
1. In the navigation pane, click to select a network component in the
navigation tree.
2. Right-click and select Events from the shortcut menu. The Events Date
Coverage dialog box is displayed.
3. To view events from a specific point in time and forward, select the
Show Events for Last option. Then enter the relevant quantity of time
and select the unit of time (weeks, days, hours, minutes, or seconds) in
the designated fields.
OR
To set a definite starting and end point for events, select the Show
Events in Range option. Then enter the relevant dates and times in the
From Date/Time and To Date/Time areas.
4. Click OK. The events for the designated time period are displayed in
the Application Details pane.
8-25
The Events log displays only events for the selected entity. For example,
when you view network events, events on in-line platforms are not
displayed. Furthermore, you cannot view events on several in-line
platforms at the same time.
You can sort the events in the events log by clicking the header according
to which you want to sort them.
Notice that many events and alarms have a matching canceling event.
Before you start to investigate an event, check that it has not been
cleared.
To view additional information about an event, double-click it. The Event
Properties dialog box is displayed.
8-26
Lets now see some tips about viewing alarms in the alarm log at the
bottom of the NX GUI screen.
When you select an alarm in the Alarms log and right-click, a shortcut
menu with several options is displayed:
Acknowledge Select to indicate that you have seen the alarm. This
option does not indicate that any action has been taken in response
to the alarm. Selecting Acknowledge does not remove the alarm from
the alarms log.
Remove Select to remove an alarm from the active alarms log.
Show <entity> in Network Tree Select to quickly locate the
NetEnforcer, Line, Pipe or Virtual Channel for which the alarm was
activated, for further investigation and action.
Note: These options are available only for the Alarms log, not the Events
log.
8-27
You can apply a filter to the Alarms Log so that only alarms matching the
filter are displayed. This is particularly useful because the Alarms Log may
include up to 5,000 alarms.
Right click in the alarms log and select filter. Alternatively, you can choose
the filter shortcut button at the top of the screen.
The Alarm Log Filter Definitions Dialog is displayed.
From each of the different tabs you can choose to filter an alarm by any of
the following factors:
Its severity (critical, major, minor, warning or info)
Whether or not it has been acknowledged
The alarm type (threshold crossing or not)
When the alarm was triggered
The name and description of the alarm
When you click OK, the filter is applied. Only the alarms that match the
filter parameters are displayed in the Alarms Log. Note: If two or more filter
parameters are selected, the results will include all alarms that answer at
least one of the parameters.
You will see also that the word Filtered is displayed in the status bar. To
clear filters, reenter the Filters dialog box and select the Show All Alarms
(No Filter) radio button, then click OK. The log then refreshes without any
filter.
8-28
Here are a few examples of how you can use events and alarms in your
network:
Assuming your physical line is of 1Gbps, you can define an alarm to notify
you when BW is almost 1Gbps, so you will know you are almost at your
network limits. This may indicate you should re-define your policy, or
expand your physical line.
In addition, you can set an alarm action to reduce the max bandwidth
allocated to Peer to Peer applications for example, so your web users will
have more available bandwidth, and will not feel the congestion on your
network.
All events can be configured to be sent to an external SNMP server, which
will be monitored by your NOC team at all times.
What other uses can you think of?
Lets see now these examples.
8-29
8-30
8-31
Once defined, which of the alarms below can be associated with a virtual
channel?
8-32
8-33
Module 9
Steering and
Mirroring
9-2
Allot in-line platforms offer the ability to steer or mirror traffic to additional
services. We will review now the steering functionalities supported by each
platform.
The AC-1400 and AC-3000 can steer or mirror traffic to an external server.
The maximum throughput of an AC-3000 is 8Gbps. Both the network
traffic and the steered traffic throughput count towards this capacity limit.
This means that the maximum amount of traffic that can be steered is
4Gbps (4Gbps network traffic and 4Gbps steered traffic).
Steering is performed either through the 4 available copper service ports
or from the network ports (which may be copper or fiber depending on the
NetEnforcer model ordered). When using service ports, you maintain the
ability to manage up to 4x1GE network links.
These platforms can be directly connected to an external server, or
indirectly connected via a switch.
Note: AC-500 does not support steering.
9-3
9-4
The Service Gateway and NetEnforcer can balance the traffic load
between all of the deployed service servers to which it is connected. Load
balancing is performed per session, and there are three load balancing
options:
Session Based Cyclic Load Balancing: Each new steered session is
dispatched to the next server in a cyclic or round robin manner.
Subscriber Stickiness Load Balancing: Each session will be steered
based on its internal IP. All connections coming from the same IP will be
steered to the same server.
Server Stickiness Load Balancing: All sessions will be steered based
on the external IP. All connections going to the same destination will be
steered to the same server.
We will see later on how to configure load balancing for each service.
9-5
9-6
9-7
9-8
9-9
9-10
Lets now review the four central service scenarios for steering and
mirroring.
9-11
9-12
9-13
9-14
9-15
As the service to which traffic is being steered works as a proxy, the in-line
platform will occasionally need to make routing decisions. The NE/SG
must therefore be configured to work as a next hop router (gateway).
It will have 2 sets of configured default gateway IPs for this purpose:
A default gateway for the NE/SG (in both directions) is configured by
using the go config next_hop_router CLI command. This is
configured per in-line platform (Labeled here MAC/VLAN)
A default gateway for the service running back into the NE/SG and
then out to the network (labeled here: Local IP Address). This is
configured via the NetXplorer GUI (in the local ip address fields) as we
will see later on.
In order to execute the go config next_hop_router command, the following
should be specified:
Direction. Acceptable values are internal or external
Switch id. This is the SFC/SFB slot ID to which the NHR is connected.
This can be between 0-1 for the SG-Sigma or 0-3 for the SG-Sigma E.
Port. This is the SFC port to which the NHR is connected, between 18.
Vlan. This is the VLAN ID used to carry control packets to the NHR,
between 14094.
Mac. This is the MAC address of the next hop router.
For example when the SFC ID is 0, the SFC port connected to the next
hop router is 7, and its MAC address is AA:AA:AA:AA:AA:11, the correct
command will be: go config next_hop_router internal -switch_id 0 port 7 -mac AA:AA:AA:AA:AA:11
9-16
9-17
With Media Swift, connection flow is similar to the first method: generic
transparent redirection. The original connection is steered to the internal
cache engine blade or external MediaSwift cache engine, where a
decision is made about whether to access the file from the cache or from
the internet. The connection is then sent back to the in-line platform. A
connection with the remote media server is kept alive even when the
media file is being downloaded from the local cache.
9-18
We will now see what are the different steps to configure steering or
mirroring.
9-19
9-20
9-21
The first step of configuration is to set the relevant port or ports on the inline platform to the correct steering mode. There are two methods for port
usage configuration:
1. External Switched Redirection
With this mode the NE/SG will be connected to the 3rd party server or
servers via a switch. In order to route the connection to the correct server
a VLAN tag will be used to tag the connection. Another VLAN tag will be
used to tag the connection flowing back to the NE/SG.
2. External Direct Redirection
With this mode the NE/SG is connected directly to the server. There is no
need to connect a switch in between. There is also no need to tag the
connection with VLAN tags.
Direct connection can be used for the AC-3000/1400 when connecting the
copper service ports, and for the SG-Sigma E when using the 1GE-300
blade in slots 1-2.
9-22
9-23
9-24
The next step is to create the Local Service catalog. To define a new Local
Service:
In the Navigation pane, click Catalogs and right-click Service Activation.
Select New Local Service from the shortcut menu. The Local Service
Entry Properties dialog box is displayed.
Enter a name and description as appropriate. Choose the device name
from the drop down menu. NOTE: Each local service must be associated
to a specific in-line platform. Later on, when configuring the 3rd party
server, we will specify the NE/SG ports to be used for this local service.
The Service Type field will determine the steering method used by this
local service. You can choose one of the four options explained before:
Generic Transparent Redirection, Generic Proxy Redirection, Generic
Mirroring or MediaSwift. There is also a fifth option: Service Protector to
support the NSS-SP blade, which is now EOS. Once you choose a service
type, this will affect some of the other field options.
The other fields in this dialog are used to set Load Balancing & Health
Monitoring parameters. These parameters will determine whether the
service is considered up and how the connections should be steered
between multiple 3rd party servers.
The bottom part of this window is where we will define the 3rd party
steering servers configuration, which is the next configuration step. Each
service can be configured to contain up to 256 logical non-proxy servers,
or up to 128 logical proxy servers. We will now review the different
parameters for load balancing and health monitoring.
9-25
Here we see the different parameters for configuring the server load
balancing and health monitoring.
The first parameter is Service Admin Status. This can be set to Active
(default) or Inactive, which is used for maintenance. Next is the Load
Balancing Method. This determines which method will be used to steer
connections to the different steering servers. Here you can choose:
Cyclic (round robin) for session based cyclic load balancing
Hash by Internal IP for subscriber stickiness load balancing
Hash by External IP for server stickiness load balancing
Server Failure Action defines what to do when a particular server is
down. The options are as follows - Bypass: traffic flow will be returned to
the NE/SG. Re-dispatch: traffic flow will be returned to the load balancing
mechanism and re-dispatched to another server. Block: traffic will be
dropped.
Service Unavailability Action defines what to do if all servers of a
specific local service are not available. The options are Bypass or Block
(behaves the same as explained for Server Failure Action).
9-26
9-27
9-28
The fourth steering configuration step is adding the server to the local
service. With this step we define the actual servers which will be used by
the local service.
In order to add a new server, click the Add button at the bottom of the
local service window. The Add Server dialog box will appear.
The following parameters should be set:
General
Name should be a meaningful name, so this server is easily identified in
the servers list.
Admin Status can be set to either Active or In-active.
Deployment can be set to External Switched, or External Direct as per
port configuration, or Internal when working with a service blade. Each
service blade must be configured as a server.
When working with an Internal deployment, the Server Slot should be
configured as well.
9-29
Network Configuration parameters are used for load balancing and health
monitoring this server.
The MAC address will allow the NE/SG to identify traffic flowing back from
the server. When the tracking server method is set to Ping (in band) or
HTTP Request, the MAC is also used to identify if the server is up.
The IP addresses will be used for monitoring this server.
NOTE the following:
When the service type is set to Generic Proxy Redirection, there is no
need to configure a MAC address as the NE/SG will send an ARP to
retrieve it.
When BFD is used as a tracking method for the local service, there is
no need to define an IP here.
When deployment is set to Internal, only MAC address should be
configured.
Interface Connectivity parameters will define the port used to reach this
server, and the VLAN tagging to be used.
You can configure either an IPV4 or an IPV6 address.
SFC Port Id/Line is a drop down list allowing you to choose from all the
ports configured as External Switched Redirection or External Direct
Redirection.
In the VLAN Tag field, specify the chosen VLAN tags for this server.
Remember: these VLAN tags must also be configured on the switch.
Alternative Connectivity parameters are used to define the SFC ports for
IPMP Resiliency.
9-30
9-31
Enter a Name for your integrated service. You can also write a short
Description for it.
Choose the Service Type from the drop down list. This is the same list as
we have seen before:
Local services matching the selected service type will be shown under
Available. Select the relevant ones from the desired devices to create a
general Service. For example, when the service type is Media Swift,
choose local services SG1- Media Swift (External) and SG2- Media
Swift (Internal) to create one MediaSwift service in your NetXplorer.
Save the new Integrated Service
9-32
9-33
9-34
9-35
In case you are working with a video optimization service, you may want
to configure PDPI on specific services, in order to allow steering video
traffic from the first packet.
In order to enable PDPI, open the NE/SG configuration window, and go to
the Networking tab.
9-36
9-37
9-38
Module 10
Basic System
Troubleshooting
In this module, we will introduce you to the basic troubleshooting steps for
Allot systems. We will start with the first questions that you should ask
yourself before beginning any troubleshooting process. Next we will see
how to verify that all the system elements are functioning and
communicating as they should. We will then see how to check if
connections are being correctly classified and bandwidth is being allocated
according to the configuration and our expectations. We will review some
common tasks such as verifying the key, checking software version and
more. At the end of this module we will present how to proceed with the
next step: how to create a snapshot file, search the online knowledgebase
and open a support case.
10-2
10-3
We will now review several key steps which can be taken to ensure that
the system is functioning correctly.
10-4
10-5
All Allot solution elements must be synchronized to the same time. Time
zones may differ between one element and another, yet absolute time
must be the same.
When a NetEnforcer or Service Gateway is added to the NetXplorer it is
configured to use the NetXplorer server as its NTP server (with stratum
level 13)
It is recommended however to synchronize the NetEnforcer or Service
Gateway, the NetXplorer server, distributed collector and any other Allot
solution element with two servers an external NTP server and the NX
server (in case connectivity with the internet is lost). The server with the
lowest stratum will always take precedence.
When there is no synchronization between the different elements it may
lead to unexpected graph behavior, or to problems in saving policy
changes. NTP related issued are discussed in much greater detail in the
ACPP Allot advanced training course.
10-6
10-7
Next, you will need to configure each NE/SG synchronize with the external
NTP Server.
To do so use the go config ips command with the ts parameter:
go config ips ts <ntp1:ntp2:ntp3>
ntp1, ntp2, and ntp3 represent IPs of different NTP servers that the NE/SG
can synchronize with. The NetEnforcer or Service Gateway will
automatically synchronize with the NTP server that has the lowest stratum
value (stratum levels define the accuracy of the NTP server).
For example, if you have two external NTP servers with IP addresses of
10.31.68.48 and 10.0.120.1, the command would be: go config ips ts
10.31.68.48:10.0.120.1
Remember, the NX server is not a reliable NTP server, and it is strongly
recommended to use external NTP servers if they are available.
Note: in case the time difference between the NE/SG and the new
configured NTP server is more than 30 seconds backwards, the NE/SG
may reboot in order to synchronize.
10-8
In order to verify that the NE/SG is up and running, open its configuration
window. In the Navigation pane, select and right-click the NE/SG in the
network tree and select Configuration from the popup menu. The
Configuration window for the selected entity is displayed.
On the General tab, the Status field will show you if the system is active
or in bypass. For the Service Gateway you can also check the status of
each blade via the Slots&Boards tab. Choose a blade from the graphical
representation of the screen. Below the graphic you will see each sensor
and its current reading as well as the overall board status for that blade.
10-9
Alternatively, you can check system and blades status using a CLI
command. The go config view network command can be run on any
NE/SG. In the system status field, you will see if the system is active or
in bypass mode. In the SG output you will see a column called card
status which indicates the status of each blade in the system.
NOTE: Instructions for connecting to the in-line platform and logging into
the CLI are provided in Module 2: Introducing In-Line Platforms.
10-10
Now that we know the system is up and running, we will check what is
happening to the connections flowing through it. How are they classified?
What is the allocated bandwidth?
10-11
10-12
To check connection classification via CLI, use the acstat command. The
acstat CLI command is a tool for troubleshooting classification of traffic by
the NetEnforcer or Service Gateway. The information can be viewed either
as a total number of connections, in an extended and detailed form, or in a
specific, filtered format. Full details of acstat usage are discussed in the
advanced ACPP Allot training course.
In order to view the total number of connections on an NE/SG, type the
CLI command acstat. This will show you the current total number of
connections, and will also break them down into protocol type categories:
TCP, UDP, any IP and non IP.
The output will be displayed per XLR, which is the processor of the NE/CC
on the SG.
Running acstat on a multi blade devices will display the total number of
connections per Core Controller, and per each XLR on each Core
Controller. (The CC-200 of the SG-Sigma has one XLR and the CC-300 of
the SG-Sigma E has 2 XLRs).
10-13
10-14
10-15
When you want to check if bandwidth was allocated correctly as per the
enforcement policy you have configured, NetXplorer monitoring is the
place to start. Open an NE/Line/Pipe/VC graph to check the rate of traffic
which is flowing through each of the policy entities. Open a utilization
graph for the rules configured with a maximum bandwidth QoS, to check
the rule behavior. You can then drill down or limit the graph to see
additional details.
10-16
To check current bandwidth allocation via CLI, use the acmon command.
This command is a central tool for troubleshooting quality of service
issues.
Running this command will display the inbound/outbound traffic per
physical interface.
You can use this command to verify that all links see traffic.
This command will run continuously until stopped. You can stop it using
the keyboard Ctrl button together with the c button.
As with the acstat command, acmon has different filter and display
options. We will review one of them now.
10-17
10-18
Now we will see few common tasks which should be performed before
contacting Allot Support.
10-19
The first thing to verify is the existence of a valid license key. The NE/SG
license key can be checked by selecting the NE/SG from the network tree,
right clicking and choosing configuration. The details of the license and
its expiration date are listed in the Identification and Key tab. Here you
can see the key expiration date. Verify that the key expiration date is valid,
and that all features you purchased are enabled.
Note: The NE/SG license expiration date is synchronized with the NE/SG
support contract expiration date. If a support contract has expired for a
particular in-line platform then APU will be disabled for it. Protocol Pack
updates can only be pushed from the NetXplorer to in-line platforms for
which APU is enabled.
10-20
Alternatively, the in-line platform license can be checked via CLI. The go
config view key command can be entered on any Service Gateway or
NetEnforcer. The output displays the activation key, followed by a list of
features. For each feature you will see whether or not they are enabled or
disabled. If the feature you require is listed as disabled, this is because the
key entered does not enable it.
To get a new license for an additional feature, you will be asked to provide
your box key. This is done by entering the boxkey command, as seen on
the screen.
10-21
10-22
Next check what software version is running on your NE/SG. Via the GUI
open the configuration window of the NE/SG, and go to the Identification &
Key tab. At the bottom of this dialog box, you can see the software version
and protocol pack currently used by the NE/SG. Alternately, you can check
the software version using the CLI command actype.
10-23
10-24
10-25
A snapshot is a zip file that can be produced for both the NE/SG and the
NetXplorer.
The snapshot contains log files, Virtual Channel definitions, system
settings and much more.
The snapshot gives us a precise picture of what was happening inside
NE/SG and/or NetXplorer when a particular event occurred and as such, it
is an essential troubleshooting tool for customer support.
10-26
10-27
10-28
In order to use the Allot Online Knowledge base, first you have to login to
Allot Support Area. In order to do so, open Allot support page:
http://www.allot.com/support.html. Type in your user (email address) and
password.
In case you dont have user and password yet, register at the bottom of
the screen and you will receive your login details by email once you have
been verified as an Allot partner or customer.
10-29
Here you can see the Support Area home page. Other than the knowledge
base, you can find in the support area information about your in-line
platforms, register new products, generate new keys for your products and
more. We will focus on the Knowledgebase and Support Cases.
In order to open the Knowledgebase, choose the knowledgebase tab.
10-30
10-31
You can also use the Allot Support Area to generate new keys for your
Allot products. You will normally want to generate new keys when you
upgrade to a newer version which requires a new key, or in order to test a
new feature.
From the registration page, you can click one of 4 buttons:
NetEnforcer Key which will lead you to a page displaying a new
permanent key for your in-line platform. The key will have the same
add-ons as per the original purchase.
NetEnforcer Temp Key which will lead you to a key generation page
for your in-line platform. Here you will be able to change some
configuration parameters of the key. The key generated via this page
will be temporary.
NetXplorer Key which will lead you to a page displaying a new
permanent key for your NetXplorer. The key will have the same add-ons
as per the original purchase.
NetXplorer Temp Key which will lead you to a key generation page
for your NetXplorer. Here you will be able to change some configuration
parameters of the key. The key generated via this page will be
temporary.
NOTE: In order to be able to generate a key your product must have a
valid support contract.
10-32
Here we see the permanent key generation page. You see the key string
itself, which can be copied from here to the in-line platform or the
NetXplorer. You can also see the S/W version of the generated key. In
case you want to update the software version, make sure to do so from
the registration page, before you click the New Key button.
In addition, the support contact end date is displayed here. Note: The Allot
Protocol Update (APU) expiration date will be set to the end date of the
support contract.
10-33
10-34
Finally we will see how to open a new case with Allot Customer Support.
Go to the Cases tab and click the New Case button. This page will be
displayed.
Fill in the serial number or boxkey of the NE/SG or NetXplorer you want
report in Registration. Specify the issue in the Subject filed. Supply full
details of the issue in the Description field. Share all the troubleshooting
steps you have performed so far. Supply additional information in the
Case Details section.
It is important to attach snapshot in order to allow Allot Support teams to
fully investigate the issue. Click Submit.
The case will now be seen by one of Allot Support teams around the
world.
10-35
10-36