NX Installation Admin Guide R7

NetXplorer Centralized, Proactive Management of all Network Traffic

Installation and Administration Guide

P/N D354005 R7

NetXplorer Installation and Administration Guide i

NetXplorer Installation and Administration Guide ii

Important Notice Allot Communications Ltd. ("Allot") is not a party to the purchase agreement under which NetEnforcer was purchased, and will not be liable for any damages of any kind whatsoever caused to the end users using this manual, regardless of the form of action, whether in contract, tort (including negligence), strict liability or otherwise.

SPECIFICATIONS AND INFORMATION CONTAINED IN THIS MANUAL ARE FURNISHED FOR INFORMATIONAL USE ONLY, AND ARE SUBJECT TO CHANGE AT ANY TIME WITHOUT NOTICE, AND

SHOULD NOT BE CONSTRUED AS A COMMITMENT BY ALLOT OR ANY OF ITS SUBSIDIARIES. ALLOT

ASSUMES NO RESPONSIBILITY OR LIABILITY FOR ANY ERRORS OR INACCURACIES THAT MAY APPEAR IN THIS MANUAL, INCLUDING THE PRODUCTS AND SOFTWARE DESCRIBED IN IT.

Please read the End User License Agreement and Warranty Certificate provided with this product before using the product.

Please note that using the products indicates that you accept the terms of the End User License Agreement and Warranty

Certificate.

WITHOUT DEROGATING IN ANY WAY FROM THE AFORESAID, ALLOT WILL NOT BE LIABLE FOR ANY SPECIAL, EXEMPLARY, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES OF ANY KIND,

REGARDLESS OF THE FORM OF ACTION WHETHER IN CONTRACT, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY OR OTHERWISE, INCLUDING, BUT NOT LIMITED TO, LOSS OF REVENUE OR

ANTICIPATED PROFITS, OR LOST BUSINESS, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Copyright Copyright © 1997-2010 Allot Communications. All rights reserved. No part of this document may

be reproduced, photocopied, stored on a retrieval system, transmitted, or translated into any other

language without a written permission and specific authorization from Allot Communications Ltd.

Trademarks Products and corporate names appearing in this manual may or may not be registered trademarks or

copyrights of their respective companies, and are used only for identification or explanation and to

the owners' benefit, without intent to infringe.

Allot and the Allot Communications logo are registered trademarks of Allot Communications Ltd.

NetXplorer Installation and Administration Guide iii

Version History

Each document has a version and a build number. You can tell the exact version and build

of this document by checking the table below.

Document updates are released in electronic form from time to time and the most up to date

version of this document will always be found on Allot‟s online Knowledge Base. To check

for more recent versions, login to the support area www.allot.com/support and from the

knowledgebase tab, enter the title of this document into the search field.

Doc

Revision

Internal

Build

Product

Version

Published Summary of Changes

4 v4b6 NX9.2.1 25.06.09 GA Version

5 v5b6 NX10.1.1 20.10.09 GA Version

6 v6b6 NX10.2.1 29.04.10 GA Version

6 v6b11 NX10.2.1 04.08.10 NX-HAP installation clarifications;

IBM DS Manager Installation added

7 v7b1 NX11.1.0 15.08.10 Internal Build

7 v7b2 NX11.1.0 01.09.10 NX-HAP installation clarifications

7 v7b3 NX11.1.0 13.09.10 Internal Build

7 v7b4 NX11.1.0 14.09.10 Updated Upgrade Procedure; Internal review copy

7 v7b5 NX11.1.0 20.09.10 LA Version

7 v7b6 NX11.1.0 26.09.10 Downgrade procedure added

7 v7b7 NX11.1.0 03.10.10 Edits to upgrade/downgrade and NX-HAP installation

7 v7b8 NX11.1.0 04.10.10 Password management added

7 v7b9 NX11.1.0 06.10.10 HTTP Proxy Configuration updated and edits made to

upgrade procedure

7 v7b10 NX11.1.0 12.10.10 Supported Operating Systems Added

7 v7b11 NX11.1.0 14.10.10 HTTP Proxy Configuration updated

7 v7b12 NX11.1.0 20.10.10 HTTP Proxy Configuration updates

http://www.allot.com/support

NetXplorer Installation and Administration Guide iv

7 v7b13 NX11.1.0 26.10.10 GA version

7 v7b14 NX11.1.0 10.11.10 NX IP Address Script added

7 v7b15 NX11.1.0 25.11.10 Installing SNX-SRV added

7 v7b16 NX11.1.0 26.12.10 Minor edits (Ch4)

NetXplorer Installation and Administration Guide v

Important Notice ........................................................................................................................... ii Version History ............................................................................................................................. iii

CHAPTER 1: GETTING STARTED .......................................................................... 1-1 Overview...................................................................................................................................... 1-1 Terms and Concepts ................................................................................................................... 1-1 NetXplorer Architecture ............................................................................................................ 1-5 Administration Role ................................................................................................................... 1-7

CHAPTER 2: INSTALLATION .................................................................................. 2-1 NetXplorer Server Installation .................................................................................................. 2-1

Windows Installation ................................................................................................................ 2-1 Linux Installation ...................................................................................................................... 2-8 NX-SRV Installation............................................................................................................... 2-12

NetXplorer Client Installation................................................................................................. 2-16 Java, WebStart and the NetXplorer Client .............................................................................. 2-16 Accessing NetXplorer ............................................................................................................. 2-19 Enabling NetXplorer Servers .................................................................................................. 2-20

NX Accounting Installation ..................................................................................................... 2-21 Windows Server ...................................................................................................................... 2-21 Linux Server ........................................................................................................................... 2-26

NPP Installation ........................................................................................................................ 2-28 Windows Server ...................................................................................................................... 2-28 Linux Server ........................................................................................................................... 2-32

NX High Availability Platform Installation ........................................................................... 2-36 Connecting NX-SRV-HAP ..................................................................................................... 2-36 Configuring NX-SRV-HAP .................................................................................................... 2-38

CHAPTER 3: CONFIGURATION .............................................................................. 3-1 Overview...................................................................................................................................... 3-1 Working with Devices ................................................................................................................ 3-1 Configuring NetXplorer Users .................................................................................................. 3-8

Password Management ........................................................................................................... 3-10

CHAPTER 4: MONITORING COLLECTORS ........................................................ 4-1 Overview...................................................................................................................................... 4-1

Data Collection Process ............................................................................................................ 4-2 Collector Redundancy ............................................................................................................... 4-3 NetXplorer Support................................................................................................................... 4-4

Installing Monitoring Collectors ............................................................................................... 4-5 Collector Groups ....................................................................................................................... 4-8

Configuring Monitoring Collectors .......................................................................................... 4-9 Troubleshooting the Collector ................................................................................................. 4-12

Command Line Interface ........................................................................................................ 4-12 Processes ................................................................................................................................. 4-12

NetXplorer Installation and Administration Guide vi

Logs and Snapshots ................................................................................................................ 4-12 Recreating Databases .............................................................................................................. 4-13 Changing IP Addresses ........................................................................................................... 4-13

CHAPTER 5: DATABASE MANAGEMENT ............................................................ 5-1 Backup Terms ........................................................................................................................... 5-1 Using Backups to Achieve NX Redundancy ............................................................................ 5-2

Database Management on Windows ......................................................................................... 5-2 Cold Backup ............................................................................................................................. 5-2 Hot Backup ............................................................................................................................... 5-4

Database Management on Linux ............................................................................................ 5-16 Cold Backup ........................................................................................................................... 5-16 Hot Backup ............................................................................................................................. 5-17

Data Collection and Storage Profiles ...................................................................................... 5-25 Bucket Types .......................................................................................................................... 5-25 Configuring Profiles ............................................................................................................... 5-26

CHAPTER 6: COMMAND LINE INTERFACE (CLI) ............................................ 6-1 Provisioning CLI ........................................................................................................................ 6-1

Topology CLI ........................................................................................................................... 6-2 Catalog CLI .............................................................................................................................. 6-3 Policy CLI ............................................................................................................................... 6-18 Web Updates CLI ................................................................................................................... 6-23

Monitoring CLI ........................................................................................................................ 6-24 Export to CLI .......................................................................................................................... 6-25

CHAPTER 7: TROUBLESHOOTING ....................................................................... 7-1 Troubleshooting Basics .............................................................................................................. 7-1

First Steps ................................................................................................................................. 7-1 Processes ................................................................................................................................... 7-1 Log Files ................................................................................................................................... 7-2 Snapshots .................................................................................................................................. 7-5 How to restore CFG (allot_cfg) database from the Snapshot-File ............................................ 7-6

Login Errors ............................................................................................................................... 7-6 Incorrect Java Version .............................................................................................................. 7-6 Lack of Connectivity ................................................................................................................ 7-7 Antivirus Conflict ..................................................................................................................... 7-8

Policy Saving Errors .................................................................................................................. 7-8 Data Display Errors ................................................................................................................. 7-10

Data Transmission .................................................................................................................. 7-10 Data Reception ........................................................................................................................ 7-11 Data Loss ................................................................................................................................ 7-12 Stress ....................................................................................................................................... 7-12

Add Device Errors .................................................................................................................... 7-13 NX-HAP Troubleshooting ....................................................................................................... 7-15

NetXplorer Installation and Administration Guide vii

Monitoring the Cluster Status ................................................................................................. 7-15 Viewing Available Resources ................................................................................................. 7-16 Stopping Heartbeat Service .................................................................................................... 7-17

CHAPTER 8: APPENDICES ....................................................................................... 8-1 Appendix A - Comprehensive Upgrade Procedure ................................................................. 8-1

Upgrade Master-plan ................................................................................................................ 8-1 Upgrade Stage 1: Backup All SMPs ......................................................................................... 8-2 Upgrade Stage 2: Backup NetXplorer ...................................................................................... 8-3 Upgrade Stage 3: Upgrade NetXplorer ..................................................................................... 8-4 Upgrade Stage 4: Stop NetXplorer Service .............................................................................. 8-6 Upgrade Stage 5: Upgrade All Collectors ................................................................................ 8-7 Upgrade Stage 6: Upgrade Additional Services ....................................................................... 8-8 Upgrade Stage 7: Upgrade All SMP Servers .......................................................................... 8-10 Upgrade Stage 8: Start NX Service ........................................................................................ 8-14 Upgrade Stage 9: Verify Normal Operation ........................................................................... 8-15

Appendix B - Upgrading NetXplorer from Versions Earlier than NX9.2.1 ........................ 8-18 Standard Upgrade Procedure .................................................................................................. 8-18 Manual Upgrade Procedure .................................................................................................... 8-18

Appendix C – Downgrade Procedures ................................................................................... 8-21 Downgrade Stage 1: Backup All SMPs .................................................................................. 8-22 Downgrade Stage 2: Backup NX ............................................................................................ 8-22 Downgrade Stage 3: Downgrading NetXplorer ...................................................................... 8-22 Downgrade Stage 4: Restore NX Configuration and Databases ............................................. 8-25 Downgrade Stage 5: Stop NetXplorer Service ....................................................................... 8-26 Downgrade Stage 6: Downgrade All Collectors ..................................................................... 8-26 Downgrade Stage 7: Downgrade Additional Services ............................................................ 8-27 Downgrade Stage 8: Downgrade All SMPs ............................................................................ 8-30 Downgrade Stage 9: Restore SMP Configuration .................................................................. 8-33 Downgrade Stage 10: Start NetXplorer Service ..................................................................... 8-34 Downgrade Stage 11: Verify Normal Operation .................................................................... 8-34

Appendix D – IBM DS Storage Manager ............................................................................... 8-35 Installing Storage Manager Client on NX Servers ................................................................. 8-35 Configuring Storage Manager to Send SNMP Traps from the Storage Device ..................... 8-39

Appendix E - Configuring NX to Work Behind an HTTP Proxy ........................................ 8-40 Appendix F - Events and Recommended Actions.................................................................. 8-42 Appendix G – NX IP Address for UI Script ........................................................................... 8-49

NetXplorer Installation and Administration Guide viii

FIGURES

Figure ‎1-1: NX-SRV-HAP ........................................................................................................... 1-2

Figure ‎1-2: System Architecture .................................................................................................. 1-6

Figure ‎2-1: Local Area Connection Properties ............................................................................. 2-2

Figure ‎2-2: Security Warning ....................................................................................................... 2-4

Figure ‎2-3: NetXplorer InstallShield Wizard Welcome Window ................................................ 2-5

Figure ‎2-4: Choose Setup Type .................................................................................................... 2-5

Figure ‎2-5: Choose Destination Location - Custom ..................................................................... 2-6

Figure ‎2-6: Choose NTP configuration option - Custom ............................................................. 2-6

Figure ‎2-7: Choose Destination Location - Typical ..................................................................... 2-7

Figure ‎2-8: Ready to Install the Program ..................................................................................... 2-7

Figure ‎2-9: Setup Initializing........................................................................................................ 2-7

Figure ‎2-10: NetXplorer InstallShield Wizard Complete ............................................................. 2-8

Figure ‎2-11: Redhat UI ............................................................................................................... 2-13

Figure ‎2-12: NetXplorer Java Installation Screen ...................................................................... 2-18

Figure ‎2-13: NetXplorer Log On Window ................................................................................. 2-18

Figure ‎2-14 – NetXplorer Log On Dialog Box .......................................................................... 2-19

Figure ‎2-15: NetXplorer Application Server Registration Dialog ............................................. 2-20

Figure ‎2-16: Local Area Connection Properties ......................................................................... 2-22

Figure ‎2-17: Security Warning ................................................................................................... 2-23

Figure ‎2-18: Accounting Manager InstallShield Welcome Window ......................................... 2-24

Figure ‎2-19: Choose Destination Location ................................................................................. 2-24

Figure ‎2-20: Ready to Install Window ....................................................................................... 2-25

Figure ‎2-21: NetXplorer InstallShield Wizard Complete ........................................................... 2-25

Figure ‎2-22: Local Area Connection Properties ......................................................................... 2-30

Figure ‎2-23: Security Warning ................................................................................................... 2-30

Figure ‎2-24: NetPolicy Provisioner InstallShield Welcome Window ........................................ 2-31

Figure ‎2-25: Choose Destination Location ................................................................................. 2-31

Figure ‎2-26: NetXplorer IP Address Window ............................................................................ 2-31

NetXplorer Installation and Administration Guide ix

Figure ‎2-27: Ready to Install Window ....................................................................................... 2-32

Figure ‎2-28: NPP InstallShield Wizard Complete ..................................................................... 2-32

Figure ‎2-29: Cable Connections for NX High Availability Platform......................................... 2-36

Figure ‎2-30: Cables for NX HAP Connectivity ......................................................................... 2-37

Figure ‎2-31: Updating /etc/hosts file .......................................................................................... 2-41

Figure ‎2-32: Updating /etc/ha.d/ha.cf file – Default Gateway ................................................... 2-42

Figure ‎2-33: Updating /etc/ha.d/ha.cf file – Enable SNMP Traps ............................................. 2-42

Figure ‎2-34: Updating cib.xml ................................................................................................... 2-44

Figure ‎2-35: Updating cib.xml ................................................................................................... 2-44

Figure ‎2-36: Specifying NX-HAP IP for Receipt of SNMP Traps ............................................ 2-46

Figure ‎3-1: NetEnforcer Properties – New Dialog ....................................................................... 3-2

Figure ‎3-2: NetEnforcer Properties – Import Dialog .................................................................... 3-3

Figure ‎3-3: Monitoring Collector Properties – New Dialog ......................................................... 3-4

Figure ‎3-4: Monitoring Collector Properties – New Dialog ......................................................... 3-4

Figure ‎3-5: Collector Group Properties – New Dialog ................................................................. 3-5

Figure ‎3-6: SMP Properties – New Dialog ................................................................................... 3-5

Figure ‎3-7: Device Properties Update dialog ............................................................................... 3-6

Figure ‎3-8: System Message ........................................................................................................ 3-6

Figure ‎3-9: NetEnforcer Configuration ........................................................................................ 3-7

Figure ‎3-10: Users Configuration Editor ...................................................................................... 3-9

Figure ‎3-11: User Editor ............................................................................................................... 3-9

Figure ‎3-12: Password Management dialog box ........................................................................ 3-11

Figure ‎4-1: Collector – Front View ............................................................................................. 4-1

Figure ‎4-2: Collector– Rear View ............................................................................................... 4-1

Figure ‎4-3 N+1 Collector Redundancy ....................................................................................... 4-3

Figure ‎4-4 1+1 Collector Redundancy ......................................................................................... 4-4

Figure ‎4-5: Connecting the Collector – Front View .................................................................... 4-5

Figure ‎4-6: Monitoring Collectors Properties dialog – General tab ............................................. 4-6

Figure ‎4-7: NetEnforcer Properties dialog ................................................................................... 4-7

NetXplorer Installation and Administration Guide x

Figure ‎4-8: Monitoring Collector Properties - Update ................................................................. 4-8

Figure ‎4-9: Collector Group Properties – New Dialog ................................................................. 4-8

Figure ‎4-10: Collector Configuration Window - General Tab ..................................................... 4-9

Figure ‎4-11: SNMP Tab ............................................................................................................... 4-9

Figure ‎4-12: Date/Time Tab ....................................................................................................... 4-10

Figure ‎4-13: IP Properties Tab ................................................................................................... 4-10

Figure ‎4-14: Securities Tab ........................................................................................................ 4-11

Figure ‎4-15: Monitoring Collector Properties – Update Dialog ................................................. 4-11

Figure ‎5-1: Changing the Reduction Profile on the NetEnforcer (Non-AOS) ........................... 5-28

Figure ‎5-2: Length of time for which data is stored under different profiles ............................. 5-30

Figure ‎7-1: Database Logs............................................................................................................ 7-2

Figure ‎7-2: Key Database Logs .................................................................................................... 7-3

Figure ‎7-3: Application Server Logs ............................................................................................ 7-3

Figure ‎7-4: NMS.log Example ..................................................................................................... 7-4

Figure ‎7-5: Install Log .................................................................................................................. 7-4

Figure ‎7-6: Snapshot File ............................................................................................................. 7-5

Figure ‎7-7: Restore Policy and Catalogs Dialog .......................................................................... 7-9

Figure ‎7-8: Events Log ............................................................................................................... 7-10

Figure ‎7-9: Bucket Manifest ....................................................................................................... 7-11

Figure ‎7-10: Data Logs ............................................................................................................... 7-12

Figure ‎8-1: SNMP Traps Sent from Storage Controllers ........................................................... 8-35

Figure ‎8-2: Storage Manager Installation Wizard ...................................................................... 8-36

Figure ‎8-3: Select Installation Type ........................................................................................... 8-37

Figure ‎8-4: Select Addition Method ........................................................................................... 8-37

Figure ‎8-5: Devices Hierarchy Tree ........................................................................................... 8-38

Figure ‎8-6: Devices Tab Menu ................................................................................................... 8-38

Figure ‎8-7: Configure Alerts ...................................................................................................... 8-39

NetXplorer Installation and Administration Guide 1-1

Chapter 1: Getting Started

Overview

NetXplorer is a highly scalable Network Business Intelligence system that enables

strategic decision-making based on comprehensive network application and subscriber

traffic analysis.

NetXplorer configures NetEnforcer or Service Gateway devices and a central catalog,

which enables global policy provisioning. Many network topologies can benefit from

more than one NetEnforcer or Service Gateway. In addition, NetXplorer provides a

centralized management system for all NetEnforcers or Service Gateways on the

network. It provides easy access to devices and configuration parameters via the device

tree.

By enabling real time monitoring of network troubleshooting and problem analysis,

NetXplorer provides long term reporting for capacity planning, tracking usage and trend

analysis; it allows for the proactive management of traffic and system-wide alarms; and

it allows for the collection and export of auditing data for billing and quota purposes.

Terms and Concepts This section introduces some of the basic terms and concepts used in NetXplorer.

NetXplorer

NetXplorer is a highly scalable Network Business Intelligence system that centrally

manages the NetEnforcer and Service Gateway product line. It enables strategic

decision-making based on comprehensive network application and subscriber traffic

analysis.

The NetXplorer can be purchased from Allot as an Appliance which is comprised of the

hardware and server software pre-installed. The available configurations are:

Standalone Server: Allot part number: NX-SRV

IBM System x3650 M2 Base with:

Intel Xeon Processor E5520 4C (2.26GHz 8MB L3 Cache 1066MHz

6 x 1GB DDR3-1333 1Rx8 LP RDIMM

4 x IBM 146GB 15K 6Gbps SAS 2.5inch SFF Slim-HS HDD

2 x 1Gb Ethernet Ports

2 x Redundant 675W Power supply

‎Chapter 1: Getting Started


Highly Available platform: Allot part number: NX-SRV-HAP

IBM System x3650 M2 Base with:

2 x Intel Xeon Processor E5520 4C (2.26GHz 8MB L3 Cache 1066MHz

9 x 1GB DDR3-1333 1Rx8 LP RDIMM

2 x IBM 146GB 15K 6Gbps SAS 2.5inch SFF Slim-HS HDD

4 x 1Gb Ethernet Ports

2 x Redundant 675W Power supply

DS3200 STORAGE DUAL CONTROLLER

9 x HDD 146GB 15K 3.5" SAS

Figure ‎1-1: NX-SRV-HAP

In addition customers can install the NetXplorer server software on applicable hardware

compatible with the Allot recommendations as described in the NetXplorer datasheet.

The NetXplorer server is certified to support the following operating systems:

Windows Server 2003 Enterprise Edition

Windows Server 2003 Standard Edition



Windows Server 2008 Enterprise Edition (32 bit and 64 bit)

Windows Server 2008 Standard Edition (32 bit and 64 bit)

Windows XP Professional Service Pack 3

Red Hat Enterprise Linux 5.3 - 32/64-bit x86

NetEnforcer

NetEnforcers are the traffic management devices that inspect and monitor network

traffic.

Service Gateway

The Service Gateway is a platform for enhancing service optimization and service

deployment. The Service Gateway provides an open, carrier-grade solution for

broadband service providers to manage multiple 10 or 1 Gigabit lines and deploy value

added services in one integrated platform. Application and subscriber information

within the Service gateway is identified for each traffic flow and subsequently the flow

is dispatched to an array of additional services and actions using a single DPI process.

Monitoring Collector

The Monitoring Collector is an Allot appliance that can be added between the

NetXplorer Servers and the NetEnforcers or Service Gateways in order to support large

numbers of NetEnforcers or Service Gateways or those installed in remote geographic

locations.

QoS

QoS (Quality of Service) is the ability to define a level of performance in a data

communications system. In NetXplorer, QoS is an action applied to a connection when

the conditions of a filter are satisfied.

The QoS specified can include the following:

Prioritized Bandwidth: Delivers levels of service based on class

levels. During peak traffic periods, the NetXplorer will slow down

lower priority applications, resulting in increased bandwidth delivery

to higher priority applications.

Guaranteed Bandwidth: Enables the assignment of fixed minimum

and maximum amounts of bandwidth to specific Pipes, Virtual

Channels and connections. By borrowing excess bandwidth when it

is available, connections are able to burst above guaranteed

minimum limits, up to the maximum guaranteed rate. Guaranteed

rates also assure predictable service quality by enabling time-critical

applications to receive constant levels of service during peak and

non-peak traffic periods.



Reserved Bandwidth on Demand: Enables the reservation of the

minimum bandwidth from the first packet of a connection until the

connection ends. This is useful when the bottleneck is not at the link

governed by the NetEnforcer or Service Gateway. By limiting other

connections (non-guaranteed), the NetEnforcer or Service Gateway

reserves enough bandwidth for the required Pipe or Virtual Channel.

TOS Marking: Enables the user to set the ToS bytes in the

transmitted frame according to the DiffServ standard or free format.

Access Control: Determines whether a connection is accepted,

dropped or rejected (Supported on AC-400 and AC-800 only). For

example, you can specify the following policy: accept 1000 ICMP

connections to Server1 and drop the rest. A NetEnforcer or Service

Gateway policy can also be to drop all P2P connections or accept

new connections with a lower priority

Admission Control: Determines the bandwidth granted to a flow

based on your demand (for example, allocated minimum of 10kbps)

and the available bandwidth on the line.

Catalog Editors

Catalog Editors enable you to define values to define your policy. The possible values

for each condition of a filter and for actions are defined in the Catalog entries in the

Catalog Editors. A Catalog Editor enables you to give a logical name to a

comprehensive set of parameters (a Catalog entry). This logical name then becomes a

possible value for a condition or action

Lines

A Line represents a physical or logical media in the system. A line provides a way of

classifying traffic that enables you to divide the total bandwidth and then manage every

Line as if it was an independent link. A Line consists of one or more sets of conditions

and a set of actions that apply when all of the conditions are met. A line is an address-

based or VLAN-based entity, and is not service-based.

A Line can aggregate several Pipes, acting like a container of Pipes from a QoS point of

view. The filter of the Fallback Line cannot be modified or deleted. A connection

coming into the NetEnforcer or Service Gateway is matched to a Line according to

whether the characteristics of the connection match all of the Conditions of the Line.

The connection is then further matched to the Conditions of a Pipe under the Line. The

actions defined for the Line influence all the Pipes under the Line. The actions defined

for a Pipe are enforced together with the actions of the Line.

Pipes

A Pipe provides a way of classifying traffic that enables you to divide the total

bandwidth and then manage every Pipe as if it was an independent link. Pipes cannot

stand alone and are always contained within a Line. A Pipe consists of one or more sets

of conditions and a set of actions that apply when all of the conditions are met. A Pipe



can aggregate several Virtual Channels, acting like a container of Virtual Channels from

a QoS point of view.

When you add a new Pipe, it always includes at least one Virtual Channel, the Fallback

Virtual Channel. The Fallback Virtual Channel filter cannot be modified or deleted. A

connection coming into a line is matched to a Pipe according to whether the

characteristics of the connection match all of the Conditions of the Pipe. The connection

is then further matched to the Conditions of a Virtual Channel under the Pipe. The

actions defined for the Pipe influence all the Virtual Channels under the Pipe. The

actions defined for a Virtual Channel are enforced together with the actions of the Pipe.

Virtual Channels

A Virtual Channel provides a way of classifying traffic and consists of one or more sets

of Conditions and a set of actions that apply when all of the Conditions are met. A

Virtual Channel is defined within a Pipe and cannot stand alone. A connection matched

to a Pipe is further matched to a Virtual Channel according to whether the

characteristics of the connection match all of the Conditions of the Virtual Channel.

Conditions

A Condition is defined at the Line level, Pipe level or Virtual Channel level. NetXplorer

matches connections to conditions, first at the Line level then at Pipe level and then

again at the Virtual Channel level within a Pipe.

Templates

Templates enable you to create a "master" Pipe or Virtual Channel that upon saving will

create multiple Pipes or Virtual Channels similar to one another. Templates work with

host group entries defined in the Host Catalog. For example, if a host group entry in the

Host Catalog called Gold Customers consists of Company X, Company Y and

Company Z, you could define a Pipe template to be expanded for Gold Customers. This

would result in Pipes being created for Company X, Company Y and Company Z when

the Policy Editor is saved.

A Pipe or Virtual Channel template enables the fast creation of Pipes and Virtual

Channels on source/destination differentiation. 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.

NetXplorer Architecture

This section introduces the NetXplorer concept and explains its components and

architecture.

NetXplorer uses a highly scalable architecture that enables the monitoring of all

NetEnforcer or Service Gateway devices from a single user interface. In addition,

NetXplorer can utilize distributed monitoring collectors, which increase the scalability

of your deployment. The collectors gather short-term network usage statistics from the

NetEnforcers or Service Gateways.



NetXplorer's server-based, distributed architecture consists of four tiers: multiple

NetEnforcer or Service Gateways and associated distributed collectors, a NetXplorer

server and GUI clients.

Figure ‎1-2: System Architecture

NetXplorer architecture consists of four layers:

1. NetEnforcer layer: NetEnforcers or Service Gateways are the traffic

management devices that inspect and monitor network traffic. There can be one

or more NetEnforcers or Service Gateways on a network. They manage network

policies and collect network usage data.

2. Monitoring Collectors: Monitoring collectors increase scalability by supporting

large numbers of NetEnforcers or Service Gateways or those installed in remote

geographic locations. Monitoring collectors are fully managed via the NetXplorer

GUI.

3. Server Layer: The NetXplorer server is the actual application, which includes

the databases and an integrated data collector. The NetXplorer server manages

and communicates with the different clients that access the system, and facilitates

NetEnforcer or Service Gateway configuration, policy provisioning, alarms,

monitoring and reporting. The integrated data collector included in the

NetXplorer streamlines the required collection of data from the managed

NetEnforcer or Service Gateway devices. The Server layer includes additional

servers such as SMP Servers, NPP Servers and stand along Accounting Servers.

4. User Interface Layer: The different clients connected to the NetXplorer Server

are the NetXplorer GUI application users. Any network computer capable of

connecting to the NetXplorer server can support the GUI interface.



The system offers simple integration with external systems using a wide range of

interfaces, including SNMP, CSV Files (for report data export), XML and CLI.

Administration Role NetXplorer uses a role-based security model. The role defined for each authorized user

indicates the scope of operations that can be performed by that user. The Administrator

role gives Admin users complete read/write privileges in the NetXplorer application

including read/write configuration privileges.

The main functions of the Administrator role include:

1. User Registration

2. Device and Network Management

3. Monitoring Collectors Management

4. Database Maintenance

This document defines the main concepts and describes the various activities related to

the installation and configuration of NetEnforcer or Service Gateways and the

NetXplorer, Monitoring Collectors, as well as the main tasks associated with Database

Maintenance, such as backup and restore, changing location and installing the

NetXplorer on a remote data base.


Chapter 2: Installation

NetXplorer Server Installation

Windows Installation

Installation Prerequisites

This section describes the minimum hardware and software requirements for installing

NetXplorer on a Windows Server.

Server Hardware Requirements

Minimum Specifications for Managing 1-2 NetEnforcer AC-

400/800/1000/2500/3000/1400 Devices

Intel Pentium 4 2.8 GHz and up

Intel Chipset based (925 or 955)

4 GB RAM DDR Dual channel

1 x 80 GB HDD, 8 MB Cache (SATA interface recommended)

Windows Server 2003 Standard or Enterprise Editions, Windows

Server 2008 SP2 Standard and Enterprise editions (32 bit and 64 bit)

or Windows XP Professional Service Pack 3 (English only)

Minimum Specifications for Managing an Allot Service gateway, AC-10000, AC-

5000 or more than 2 NetEnforcer AC-400/800/1000/2500/3000/1400 Devices

Dual Xeon 3.0 GHz and up


RAID (0 or 10) Controller with 256MB Battery Backed Write Cache

(BBWC)

5x36 GB HDD SCSI U320 15k RPM or larger (capacity depends on

overall storage needs, allowing for 100 GB per Service Gateway or

AC-10000/AC-5000, 20 GB per AC-2500/AC-1000 and 10 GB per

AC-800/AC-400)




NOTE NetXplorer Server should be installed on a dedicated server for optimum performance.

‎Chapter 2: Installation


Software Requirements

Any Real-Time Virus Protection programs or automatic

Defragmentation/Backup software must be disabled on the

NetXplorer server or the Allot folder needs to be excluded from

protection/defragmentation.

Java JDK 6 should be installed on the Server machine. For details on

how to install the Java JDK see Installing Java JDK 6 on page 2-3.

NOTE If the machine on which you are installing NX Server is running a 64 bit OS, the Java installation must also be 64 bit. If the server is running a 32 bit OS, then the Java version must be 32 bit. Only the 32 bit JDK is provided by Allot. The 64 bit JDK may be downloaded from http://www.oracle.com/technetwork/java/javase/system-configurations-135212.html.

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

be installed on the NetXplorer server machine.

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

installation.

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

Control Panel > Network and Sharing Center > Manage

Network Connections > Local Area Connection Properties.

Uncheck the Internet Protocol Version 6 checkbox to disable the

service.

Figure ‎2-1: Local Area Connection Properties

Pre-Installation Checklist

Before you begin the installation process, it is important that you perform the following

steps.



1. Verify that the minimum required space is available on the hard

disk.

2. Verify that there is at least 4 GB of available Virtual Memory.

NOTE: Set the Virtual Memory on your computer by selecting Start/Settings/Control Panel/System. Open the Advanced tab and click the Performance Settings button. Open the Advanced tab and click the Change button under Virtual Memory to select a new value.

3. Verify that Java JDK 6 is installed, including runtime

environment. If it is not installed, install it now, as described

below.

Installing Java JDK 6

The Java JDK 6, including the run time environment, must be installed before you can

install NetXplorer.

To install the Java JDK:

1. Browse to <target folder> and run the jdk-6u20-windows-i586-

p.exe file on the installation CD. The Security Warning is

displayed.


2. Click Run. The License Agreement is displayed.

3. Read the license agreement and select I accept the terms … to

indicate your agreement, and then click Next. The Custom Setup

dialog is displayed.

4. Click Next to accept the default installation location,

OR

Click Change to browse and select an alternate installation location, and then

click Next.

NOTE The necessary program features are selected by default. You do not need to change these default settings.



The Browser Registration dialog is displayed.

5. Verify that Microsoft Internet Explorer is selected and click

Install. The Installing Java JDK dialog is displayed. The progress

bar indicates the status of the installation process.

6. When the installation process is done, the Complete window is

displayed.

7. Click Finish.

Installation Instructions

After you have performed the pre-installation checks and have verified that the Java

JDK is installed, you are ready to install NetXplorer.

To install NetXplorer:

1. Run the setup.exe file on the installation CD or from a net-

mounted disk.

NOTE Do not attempt to run the setup file from a net long address, such as \\file_server\.

2. The following dialog is displayed.

Figure ‎2-2: Security Warning



3. Click Run. The following window is displayed.

Figure ‎2-3: NetXplorer InstallShield Wizard Welcome Window

Click Next to continue.

4. The NetXplorer License Agreement is displayed.

Click Next to continue

5. Read the license agreement and select I accept the term … to

indicate your agreement, and then click Next. The Choose Setup

Type dialog is displayed.

Figure ‎2-4: Choose Setup Type

6. To install all program components in a single location, select

Typical and click Next. Then skip ahead to step 10.

OR

To install each component in a different location, select Custom and click

Next.

NOTE Allot strongly recommends using the Custom installation option.



7. If you selected Custom in step 5, the following dialogs are

displayed.

Figure ‎2-5: Choose Destination Location - Custom

8. Accept the default destination locations or browse and select an

alternate location for one or more of the components, and then

click Next. The Choose NTP configuration option dialog is

displayed.

NOTE If alternate locations are chosen for one or more components, they must be in a subdirectory on one of the root directories (like C:\Allot or D:\Allot) and not on the root directory itself (C:\ or D:\).

NOTE It is recommended that the system files and the different monitoring files be installed on different physical drives in order to improve overall performance.

Figure ‎2-6: Choose NTP configuration option - Custom

9. Select either the Use local clock or the Use External NTP server

radio button. If you select an external NTP server, enter the

server‟s IP address in the field provided. Click Next.

NOTE Allot strongly recommends using an external NTP server.



10. If you selected Typical in step 5 the following dialog is displayed.

Figure ‎2-7: Choose Destination Location - Typical

11. Accept the default destination location or browse and select an

alternate location, and then click Next.

Figure ‎2-8: Ready to Install the Program

12. Click Install to begin the installation. The Setup Status dialog is

displayed.

After a few moments the following popup is displayed.

Figure ‎2-9: Setup Initializing

NOTE The installation may take up to 30 minutes to complete.



13. When the installation is complete the following dialog is

displayed.

Figure ‎2-10: NetXplorer InstallShield Wizard Complete

14. Select Yes, I want to restart my computer now and click

Finish. The installation process is complete.

Linux Installation



NetXplorer on a Linux Server.


Minimum Specifications for Managing 1-2 NetEnforcer AC-

400/800/1000/2500/3000/1400 Devices





Red Hat Enterprise Linux 5.3 - 32 /64-bit x86 (English only)

Minimum Specifications for Managing an Allot Service Gateway, AC-10000, AC-

5000 or more than 2 NetEnforcer AC-400/800/1000/2500/3000/1400 Devices

DUAL Xeon 2.8 GHz and up


RAID (0 or 10) Controller with 256MB Battery Backed Write Cache

(BBWC)



5x36 GB HDD SCSI U320 15k RPM or larger (capacity depends on

overall storage needs, allowing for 100 GB per Service Gateway or

AC-10000/AC-5000, 20 GB per AC-2500/AC-1000 and 10 GB per

AC-800/AC-400)

Red Hat Enterprise Linux 5.3 - 32 /64-bit x86 (English only)

NOTE NetXplorer Server should be installed on a dedicated server for optimum performance.


NetXplorer Server should be installed on a machine running Red Hat

Enterprise Linux Server 5 32 or 64 bit, English only. NetXplorer

Server does not run on any other Linux distro or in any other

language.


NetXplorer Client software should be installed on a machine running

Windows XP Professional and Microsoft Internet Explorer.








installation.

FQDN of the server should be defined (to check run „hostname -f‟).

Check that NTP service is installed. The Config ntp service should

be configured to start when the unit is rebooted by entering the

following command:

chkconfig --levels 35 ntpd on

NTP service should be configured to update the time from an

external NTP server and deliver the time service to Allot devices.

If the RedHat operating system has not yet been installed, configure the server so that

the CD is the first boot device, insert the RedHat5 Installation CD #1 and reboot the

host. Follow the on-screen instructions using the default installation options on all steps

except for the steps listed below

Choose “Customize Now” for software selection and add the

following two packages:

net-snmp-utils from the “System Tools” group



xorg-x11-server-Xvfb from the “X Window system” group

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

Firewall: disabled (during configuration after reboot)

SELinux: disabled (during configuration after reboot)

Time: configure correct time according to time zone chosen

NTP server: may be configured during configuration after the IP

address is configured (select the checkbox about synchronize before

starting)




To install the software:

1. Confirm all the hardware and software requirements.

2. Confirm that there is at least 20GB of free space on the /opt

directory.

3. Run rpm -ivh <filename>.rpm

Example:

rpm -ivh netxplorer-10.1.0-9.i386.rpm

NOTE You may discover the filename by using the following command: cd / find|grep -i netxplorer-

Package dependencies are checked, and error message issued if

additional are packages needed. The JDK 6 (Java development

kit) package is included in the installation set.

4. To install the packages, run rpm –ivh <JDK filename>.rpm

(version numbers may differ).

5. Configure the NTP service to start on system start by entering the

following command: chkconfig --levels 35 ntpd on

6. Manually edit the /etc/hosts files as follows: 127.0.0.1 localhost.localdomain localhost

10.50.18.1 NX1-lin.allot.local NX1-lin

7. Reboot the machine. Confirm that NTP and NetXplorer services

are running.

8. To start/stop/check the status of the services use commands such

as:

service ntpd start

service netxplorer stop

service netxplorer status

Uninstallation Instructions

1. Check what version of software is installed on the server by

running the following command: rpm -qa |grep netxplorer



2. To uninstall NetXplorer run the following command rpm -e <netxplorer version>

Example: [root@REDHATNX NX1021b12]# rpm -e netxplorer-12.2.1-12

NX-SRV Installation

NX-SRV is shipped to the customer as an Allot Appliance consisting of the hardware

with server software pre-installed.

After unpacking the hardware, installation consists of 3 steps:

1. Connect directly to the Server with a keyboard and monitor

2. Changing the IP address of the server via the RedHat UI

3. Run the set_nx_ip4ui.sh script to configure the new IP address in

the NetXplorer application server

Connecting to NX-SRV

Connect a keyboard and monitor to the front panel of the NX-SRV as shown in Figure

‎2-11 below.

Figure ‎2-11: Connecting Keyboard and Screen

Changing the IP Address (RedHat)

After connecting directly to the NX-SRV, you will see the RedHat User interface.

Follow the procedure below to change the IP address from the factory default

(11.11.11.1) to your required address.

To change the address

1. From the system menu, select Administration > Network as shown

in Figure ‎2-12 below



Figure ‎2-12: Redhat UI

2. From the Network window, shown in Figure ‎2-13 below, double

click on the appropriate network card



Figure ‎2-13: Ethernet Interfaces

3. The Ethernet Device Menu will open, as shown in Figure ‎2-14

below. From the Ethernet Device menu set the IP address, Subnet

mask and Default Gateway in the “Statically set IP addresses”

section.

4. Click on OK to save



Figure ‎2-14: Ethernet Device Menu

Changing the IP Address (NetXplorer)

In order to change the IP address on the NetXplorer application server, from the default

11.11.11.1, you will need to run the set_nx_ip4ui.sh script. For full instructions, refer

to Appendix G – NX IP Address for UI Script below.



NetXplorer Client Installation

Java, WebStart and the NetXplorer Client

NetXplorer works with a technology known as WebStart from Sun Microsystems.

WebStart enables you to run the NetXplorer Client software by simply double-clicking

an icon on your computer‟s desktop. This mode of operation is more convenient than

having to access the NetXplorer Client through an Internet browser.

Hardware Requirements

It is recommended that the NetXplorer Client be installed on a machine with the

following minimum specifications:

Pentium 4

512MB RAM

Windows XP/Microsoft Internet Explorer

NOTE: History logs will be kept on the client and can consume up to 150M






NetXplorer client or the Allot folder needs to be excluded from


Java JRE 6.0 should be installed on the client machine. For

details on how to install the Java JRE see Installing Java 6.0

JRE below.

NOTE If the machine on which you are installing NX Client is running a 64 bit OS (x64), the Java installation must also be 64 bit. If the machine is running a 32 bit OS (x86), then the Java version must be 32 bit.


installation.

Firewall Settings

In some networks, workstations running the NetXplorer GUI and NetEnforcers or

Service Gateway can be separated from the NetXplorer server by a firewall for security

reasons. In order to allow the client to communicate with the NetXplorer server the

following ports should be opened in the Firewall:

TCP/80 HTTP



TCP/443 SSL

TCP/1098 The RMI service bind address

TCP/1099 JNP server bind address

TCP/4446 RMI Object ports

TCP/4457 Alarms

TCP/50010 Alarms

To enable the communication between the NetXplorer and the NetEnforcer or Service

Gateways the following ports in the Firewall should be opened:

TCP/80 HTTP

TCP/443 SSL

UDP/161 SNMP

UDP/162 SNMP Trap

UDP/123 NTP

TCP/123 NTP

Installing Java 6.0 JRE

The Java 6.0 JRE must be installed on your computer as a prerequisite to working with

the NetXplorer User Interface.

To install Java 6.0 JRE:

1. Open your Internet browser, and access http://<<NX-addr>> The

following window is displayed.



Figure ‎2-15: NetXplorer Java Installation Screen

2. Click the Install Java JRE First link if you do not have Java 6.0

JRE installed on your computer.

Clicking the link will allow you to choose a version of the JRE for

Microsoft Windows users or a version for all other users. The

Microsoft Windows link is 32 bit only. If your installation of

Windows is 64 bit, use the All Other Users link and select the

appropriate Java install for Windows 64 bit architecture.

3. Click on the appropriate link and follow the on-screen instructions

to install the Java 6.0 JRE on your computer.

Initializing WebStart

1. With the Java 6.0 JRE installed, access http://<<NetXplorer-IP-

address> once again. The Application Starting window is

displayed.

When the loading process is complete for the first time, the Security Warning

is displayed, prompting you to confirm that you want to allow NetXplorer User

Interface software access to your computer.

2. The NetXplorer Log On window is displayed.

Figure ‎2-16: NetXplorer Log On Window

A shortcut icon to the NetXplorer installation is placed on your desktop and in your

system‟s Start menu.

Working Behind NAT

In certain deployments, the Network Address Translation (NAT) is in operation

between the NetXplorer Client and the NetXplorer Server. In order to enable GUI

access in such a case, the NetXplorer administrator must edit the swKeeper.ini file on

the NetXplorer server, replacing the server hostname with the fqdn hostname.



The swKeeper.ini file can be found in /opt/allot/conf/swKeeper.ini

Under tasks/java, look for the args option, and set it as shown below, inserting the fqdn

hostname in the relevant place.

-Djava .rmi.server.hostname=<fqdn hostname> -Dremoting.bind_by_host=true

Accessing NetXplorer

Once you have completed the initial setup, as described above, you can access the

NetXplorer via your Web browser. The first time that you connect to NetXplorer, you

may be prompted to install Java plug-in 6.0. Refer to Installing Java 6.0 JRE below, for

further information.

To connect to NetXplorer:

1. In Internet Explorer, browse to http:<<NetXplorer IP>> and

select Launch NetXplorer in the NetXplorer Control Panel.

OR

Double click the shortcut icon on the desktop or in the system‟s Start menu.

2. The Java Application Starting window is displayed.

3. The NetXplorer Log On dialog is displayed.

Figure ‎2-17 – NetXplorer Log On Dialog Box

4. In the User Name field, enter admin and in the Password field,

enter allot or the password that was established at set up. This is

the default user name and password. They may be different if you

changed them during the initial configuration.

5. Click Log On. The NetXplorer GUI is displayed.

NOTE It may take a few moments for the NetXplorer GUI to load.



Enabling NetXplorer Servers

In order to manage more than one NetEnforcer or Service Gateway as well as certain

features using NetXplorer, NetXplorer Server must be enabled by entering the

appropriate key. This key may be entered at installation or at any time following. For

more information concerning the NetXplorer Server contact Allot Customer Support at

[email protected].

To enable NetXplorer Server:

1. Select Tools > NetXplorer Application Server Registration

from the NetXplorer Menu bar.

The NetXplorer Application Server Registration dialog box

appears.

Figure ‎2-18: NetXplorer Application Server Registration Dialog

2. Enter the Activation Key and Serial Number provided by Allot to

enable the NetXplorer Server functionality.

3. A Key Version, Marketing Version and Expiration Date will be

generated automatically after clicking Save.

4. The number of devices supported by the key is indicated.

5. If Policy Provisioning is enabled by the key that has been entered,

it will be indicated (along with the maximum number of accounts)

after NPP. For more information, see the NPP User Guide.

mailto:[email protected]



6. If Classification of Hosts by Country is enabled by the key that

has been entered, it will be indicated after Country Classification

Subscription.

7. If Accounting information is enabled by the key that has been

entered, it will be indicated after Net Accounting.

8. If Service Catalog updates via the web are enabled by the key that

has been entered, it will be indicated after APU.

9. If Subscriber Management is enabled by the key that has been

entered, it will be indicated by at least one of the following

attributes being enabled: Tiered Services, Tiered Services Gx,

Quota Management or Volume Reporting. In addition, the

number of supported subscribers will be indicated if relevant. For

more information, see the SMP User Guide.

10. Click Save to enter the key and close the dialog box.

NX Accounting Installation

Windows Server



Minimum Specifications








Software Requirements Any Real-Time Virus Protection programs or automatic






Java JDK 6 should be installed on the Accounting Server. For details

on how to install the Java JDK see Installing Java JDK 6 on page 2-

3.



be installed on the NetXplorer Accounting machine.


installation.





service.



Before you begin the installation process, it is important that you perform the following steps.



1. Verify that a minimum of 20 GB is available on the disk.


NOTE Set the Virtual Memory on your computer by selecting Start/Settings/Control Panel/System. Open the Advanced tab and click the Performance Settings button. Open the Advanced tab and click the Change button under Virtual Memory to select a new value.


environment. If it is not installed, install it now, as described in

Installing Java JDK 6 on page 2-3.


NX Accounting may be installed on the same machine as NetXplorer Server, or on a

separate machine. In either case you need to identify the IP address of the NetXplorer

during the installation process.

NOTE Be sure that all the Ports are operable as detailed in the Firewall section in this Installation and User Guide, and that the Java JDK is installed.

On the NetXplorer CD (or in a folder supplied to the End-User) the installation files are

in a directory called ACCT.

To install the accounting manager:

1. Browse to the ACCT directory and run the setup.exe file on the

installation CD or from a net-mounted disk.

NOTE Do not attempt to run the setup file from a long address






Figure ‎2-21: Accounting Manager InstallShield Welcome Window

4. Click Next.

The NetXplorer License Agreement is displayed.


indicate your agreement, and then click Next. The Choose

Destination Location window is displayed.

Figure ‎2-22: Choose Destination Location


alternate location, and then click Next.

The Enter NetXplorer Server IP Address window is displayed.



7. Type in the IP address of the NetXplorer Server, and click Next.

Figure ‎2-23: Ready to Install Window

8. Click Install to begin the installation. The Setup Status window is

displayed.

When the installation is complete the following dialog is displayed.

Figure ‎2-24: NetXplorer InstallShield Wizard Complete

9. Select Yes, I want to restart my computer now and click Finish.

The installation process is complete.

10. The NX Accounting functionality must be enabled by entering the

appropriate key in the NetXplorer GUI. This key may be entered

at installation or at any time following. For information, see the

NetXplorer Operations Guide.

NOTE NetXplorer Accounting cannot be upgraded directly. The old version must be uninstalled and the new version of Accounting may then be installed.



Linux Server










Red Hat Enterprise Linux Server 5.2 or 5.3, 32 or 64 bit (English

only) installed



Enterprise Linux Server 5 32 or 64 bit, English only.










installation.




following command:




If the OS is not installed yet, configure the server so that the CD is the first boot device,

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

instructions using the default installation options on all steps except for the steps listed

below



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

Firewall: disabled (during configuration after reboot),

SELinux: disabled (during configuration after reboot),




starting)


To install the accounting manager server in Linux:

1. Confirm all the software and disc pre-installation requirements are

available.

2. Run the rpm -ivh <Accounting filename>.rpm Package.

Dependencies are checked and error message issued if additional

packages are needed. JDK 6 (Java development kit) is included in

the installation set.


3. To install the packages, run rpm -ivh <JDK filename>.rpm

(version numbers may differ). After the installation is finished,

you see the following:

rpm -ivh accounting-manager-11.1.0-6i386.rpm

Preparing...

########################################### [100%]

1: accounting-manager ########################################### [100%]

Installation finished.

Please set NetXplorer IP Address by running

accounting/bin/set_acct_nx_ip.sh.

Then, please reboot your device.



4. Manually edit the /etc/hosts files as follows:

127.0.0.1 localhost.localdomain localhost


5. To set the NetXplorer IP address, (so that the NetAccounting

Server can communicate with it) run the following:

/opt/allot/accounting/bin/set_acct_nx_ip.sh

6. Reboot the machine.

7. Check that NTP and NetXplorer services are running.


as:

service ntpd start

service nxacct stop

service nxacct status

9. The NX Accounting functionality must be enabled by entering the

appropriate key in the NetXplorer GUI. This key may be entered

at installation or at any time following. For information, see the

NetXplorer Operations Guide.


NPP Installation

Windows Server

By default, the NetPolicy Provisioner is installed on the same machine as NetXplorer

Server during the standard NetXplorer installation. NPP functionality is then enabled by

entering the appropriate License Key.

The following procedure is for installing NPP on another Windows Server, without

NetXplorer.













Software Requirements Any Real-Time Virus Protection programs or automatic




Java JDK 6 should be installed on the NPP Server. For details on

how to install the Java JDK see Installing Java JDK 6 on page 2-3.



be installed on the NPP machine.


installation.





service.





Before you begin the installation process, it is important that you perform the following steps.

1. Verify that a minimum of 20 GB is available on the disk.


NOTE Set the Virtual Memory on your computer by selecting Start/Settings/Control Panel/System. Open the Advanced tab and click the Performance Settings button. Open the Advanced tab and click the Change button under Virtual Memory to select a new value.


environment. If it is not installed, install it now, as described in

Installing Java JDK 6 on page 2-3.


NPP may be installed on the same machine as NetXplorer Server, or on a separate

machine. In either case you need to identify the IP address of the NetXplorer during the

installation process.

NOTE Be sure that all the Ports are operable as detailed in the Firewall section in this Installation and User Guide, and that the Java JDK is installed.

On the NetXplorer CD (or in a folder supplied to the End-User) the installation files are

in a directory called NPP.

To install NPP:

1. Browse to the NPP directory and run the setup.exe file on the

installation CD or from a net-mounted disk.

NOTE Do not attempt to run the setup file from a long address






Figure ‎2-27: NetPolicy Provisioner InstallShield Welcome Window

4. Click Next.

The NetXplorer License Agreement is displayed.


indicate your agreement, and then click Next. The Choose

Destination Location window is displayed.

Figure ‎2-28: Choose Destination Location


alternate location for one or more of the components, and then

click Next. The Enter NetXplorer Server IP Address window is

displayed.

Figure ‎2-29: NetXplorer IP Address Window



7. Type in the IP address of the NetXplorer Server, and click Next.

Figure ‎2-30: Ready to Install Window

8. Click Install to begin the installation. The Setup Status window is

displayed.

When the installation is complete the following dialog is displayed.

Figure ‎2-31: NPP InstallShield Wizard Complete

9. Select Yes, I want to restart my computer now and click Finish.

The installation process is complete.

10. NPP functionality must be enabled by entering the appropriate key

in the NetXplorer GUI. This key may be entered at installation or

at any time following. For information, see the NetXplorer

Operations Guide.

Linux Server

By default, the NetPolicy Provisioner is installed on the same machine as NetXplorer

Server during the standard NetXplorer installation. NPP functionality is then enabled by

entering the appropriate License Key.

The following procedure is for installing NPP on another Linux Server, without

NetXplorer.












Red Hat Enterprise Linux Server 5.2 or 5.3, 32 or 64 bit (English

only) installed



Enterprise Linux Server 5 32 or 64 bit, English only.










installation.




following command:




If the OS is not installed yet, configure the server so that the CD is the first boot device,

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

instructions using the default installation options on all steps except for the steps listed

below

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

Firewall: disabled (during configuration after reboot),



SELinux: disabled (during configuration after reboot),




starting)


To install the NPP on Linux:

1. Confirm all the software and disc pre-installation requirements are

available.

2. Run the rpm –ivh <NPP filename>.rpm Package. Dependencies

are checked, and error message issued if additional packages are

needed. JDK 6 (Java development kit) is included in the

installation set.


3. To install the packages, run rpm -ivh <JDK filename>.rpm

(version numbers may differ). After the installation is finished,

you see the following:

rpm -ivh netpolicy-provisioner-11.1.0-6.i386.rpm

Preparing...

########################################### [100%]

1:netpolicy-provisioner

########################################### [100%]



/opt/allot/npp/bin/set_npp_nx_ip.sh.





5. To set the NetXplorer IP address, run the following:





7. Check that NTP and NetXplorer services are running.


as:

service nxnpp start

service nxnpp stop

service nxnpp status

9. NPP functionality must be enabled by entering the appropriate key

in the NetXplorer GUI. This key may be entered at installation or

at any time following. For information, see the NetXplorer

Operations Guide.



NX High Availability Platform Installation

When a NetXplorer High Availability Platform is supplied, the customer will receive

the following hardware components with the necessary software pre-installed:

2 x NetXplorer Servers

1 x NetXplorer Shared Storage Device

The administrator responsible for installation needs to connect the devices and then

perform a basic network configuration as outlined below.

Connecting NX-SRV-HAP

In a High Availability Cluster configuration, the NX servers are connected by two

physical links. In addition, each NX server is connected to each of the controllers on the

RAID Storage device with dedicated SAS cables).

The diagram below shows the rear-views of the RAID storage server and the 2 x

NetXplorer servers that make up the NX-HAP solution. The physical connections are

shown below:

Figure ‎2-32: Cable Connections for NX High Availability Platform



Figure ‎2-33: Cables for NX HAP Connectivity

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. Optionally, each NetXplorer server can be directly managed from

the RSAII port by connecting this port to an external switch with

an additional ethernet management cable (illustrated in blue

above)

WARNING: Once the green Ethernet cable and the red serial cable in Figure ‎2-32 above have been connected DO NOT DISCONNECT BOTH OF THEM TOGETHER. The effect of disconnecting BOTH of these heartbeat cables is that both NetXplorer servers will mount the storage and this will lead to a corruption of the NetXplorer database.



Verifying Connectivity

After connecting all of the cables above, check that there is communication between

ETH 2 on each NX node. This connection is used by the heartbeat process to

communicate between the two nodes. Verify connectivity by following the steps below:

1. Login to NX-1 as a root user (the default password is bagabu)

2. Enter ifconfig eth2 to verify the IP address of ETH2.

If the IP address is 192.168.168.1, ping 192.168.168.2

If the IP address is 192.168.168.2, ping 192.168.168.1

If there is no ping, check the physical connectivity. Enter the

command: ethtool eth2 to verify if the status of the link.

3. Repeat steps 1-2 above for NX-2

Configuring NX-SRV-HAP

Overview

There are five stages to the NX-HAP configuration:

Bonding the management interfaces on each NX server to ensure

redundancy of the ethernet management link

Configuring the IP addresses for each NX and the virtual IP of the

NX-HAP

Adding the Virtual IP of the NX-HAP as a trap target for SNMP

communication from devices

Configuring NX-HAP to send Linux based SNMP traps to alert a

trap receiver in the event of failover from one node to the other

Enabling protocol updates on the NX-HAP

For each of the different configuration steps below you will be asked to login to each of

the NetXplorer nodes. For the sake of this procedure we will refer to the nodes as NX-1

and NX-2. Logging into each NetXplorer node is performed by using the root user

(default password: bagabu)

Stage 1: Bonding the NetXplorer Management Interfaces

For each NetXplorer server in the cluster, follow the step-by-step instructions below to

bond the eth0 and eth1 interfaces together. Eth0 and Eth1 are the interfaces which are

connected to the management switch and to the secondary management switch in Figure

‎2-32 above. On the NetXplorer server itself, they are labeled 3 and 4.

NOTE Allot strongly recommends that this procedure be carried out by or under the supervision of an Allot engineer.



1. Connect to the first NetXplorer server (NX-1) in one of two ways:

By opening an SSH session to the default IP address of the NX on

the eth2 interface (labeled port 2 on the NX server). The default IP

addresses of this interface are 192.168.168.1 for NX-1 and

192.168.168.2 for NX-2

By attaching a serial cable to the console port of the NetXplorer

2. Edit the ifcfg-eth0 file using vi. Make sure that the file reads as shown

in the output below except for the unique MAC address (HWADDR

field).

NOTE Do not change the MAC address in the HWADDR field from its default value!

[root@L3NETX02 tmp]# cat /etc/sysconfig/network-

scripts/ifcfg-eth0

# Broadcom Corporation NetXtreme II BCM5708 Gigabit

Ethernet

DEVICE=eth0

BOOTPROTO=none

HWADDR=00:21:5E:75:84:30

ONBOOT=yes

MASTER=bond0

SLAVE=yes

TYPE=Ethernet

USERCTL=no

3. Now edit the ifcfg-eth1 file using vi. Make sure that the file reads as

written below except for the unique mac address (HWADDR field).

NOTE Do not change the MAC address in the HWADDR field from its default value!


scripts/ifcfg-eth1


Ethernet

DEVICE=eth1

BOOTPROTO=none

HWADDR=00:21:5E:75:84:32

ONBOOT=yes



MASTER=bond0

SLAVE=yes

TYPE=Ethernet

USERCTL=no

4. Copy the ifcfg-bond0 file from the Allot HA installation directory by

entering the command below:

cp /home/install/Linux/HA/resources/ifcfg-bond0

/etc/sysconfig/network-scripts/

5. Edit the ifcfg-bond0 file using vi. The file should look as in the output

below. Update the IP, Gateway, Subnet, Broadcast and Network fields.

This is the physical IP address of the two bonded interfaces which

represents the NetXplorer node itself.


scripts/ifcfg-bond0


Ethernet

DEVICE=bond0

USERCTL=no

ONBOOT=yes

BROADCAST=10.10.132.255

NETWORK=10.10.132.0

NETMASK=255.255.255.0

GATEWAY=10.10.132.1

IPADDR=10.10.132.8

TYPE=Ethernet

6. Enter the command: service network stop You will receive a prompt for each interface telling you that the service is being brought down.

7. Enter the command: service network start

NOTE: If mistakes were made in the configuration, and connectivity is lost, you are advised to connect via the console port or via ETH2 (labeled port 2 on the NX server) with the default IP 192.168.168.1 for NX-1 or 192.168.168.2 for NX-2

8. Repeat steps 1-6 above for the second NetXplorer server (NX-2)



Stage 2: Configuring the NX-HAP IP Addresses

Follow the step-by-step instructions below to give an IP address to each NX in the

cluster and a virtual IP address to the High Availability Cluster itself. In this stage you

will need to edit 3 different files:

/etc/hosts

/etc/ha.d/ha.cf

/home/install/Linux/HA/resources/cib.xml

NOTE Editing of these files must be done with great care, and according to the exact instructions detailed below. Allot strongly recommends that this procedure be carried out by or under the supervision of an Allot engineer.

Editing the /etc/hosts file:

1. Login to NX-1 and edit the /etc/hosts file by entering vi /etc/hosts

2. Change the IP address and, if required, the FQDNs (host names)

of each NetXplorer from the default addresses:

Figure ‎2-34: Updating /etc/hosts file

NOTE The exact FQDN you have entered here (e.g: nx1 and nx2 in the example above) will be used later when configuring the ha.cf file

3. Verify the FQDN you have configured by using the Linux

command hostname –f

4. Verify that this NX can ping the second node by using the host

name. Enter ping nx2 (if you are connected to nx1) or ping nx1

(if you are connected to nx2)


Editing the ha.cf file:

# Do not remove the following line, or various programs

# that require network functionality will fail.


11.0.0.1 nx1.allot.com nx1

11.0.0.2 nx2.allot.com nx2



1. On NX-1 edit the /etc/ha.d/ha.cf file

2. Insert the default gateway address in the “ping 11.0.0.1” field,

instead of 11.0.0.1

Figure ‎2-35: Updating /etc/ha.d/ha.cf file – Default Gateway

3. Find the string beginning ucast eth2. You need to make sure that

the IP address listed here is that of eth2 for the other NetXplorer

node. In other words:

If you are currently logged into NX-1 (whose default eth2 address is

192.168.168.1) you should change the IP address in this field to that

of NX-2. i.e: ucast eth2 192.168.168.2.

If you are currently logged into NX-2 (whose default eth2 address is

192.168.168.2) the IP address in this field should remain the IP

address of NX-1. i.e: ucast eth2 192.168.168.1.

WARNING Inverting the UCAST values ensures that each NX Node pings the other one during the heartbeat process. If the IP addresses here are not inverted, each node will ping itself and both nodes will think that they are active. Consequently both nodes will mount the storage device simultaneously which will lead to a corruption of the database!

NOTE The default IP address of ETH2 for NX-1 is 192.168.168.1. The default IP address of ETH2 for NX-2 is 192.168.168.2. You can verify the IP address of ETH2 on each NX node by entering the command ifconfig eth2

4. Find the strings below:

node nx-1.allot.com

node nx-2.allot.com

and change the node names to the host names defined when you

edited the /etc/hosts file in Figure ‎2-34 above (in the example in

Figure ‎2-34, the host names were nx1.allot.com and

nx2.allot.com)

5. Ensure that the unmarked lines (in bold below) are indeed

unmarked to enable SNMP traps to be sent from the NX Cluster:

Figure ‎2-36: Updating /etc/ha.d/ha.cf file – Enable SNMP Traps

6. Repeat steps 1-5 on NX-2

#respawn hacluster /usr/lib/heartbeat/ipfail

respawn root /usr/lib64/heartbeat/pingd -m 100 -d 5s

respawn root /usr/lib64/heartbeat/hbagent

#

# Access control for client api

#

ping 11.0.0.1

#



Ensure that heartbeat service loads on next boot:

1. Login to NX-1 and enter: chkconfig –levels 35 heartbeat on

2. Repeat step 1 above for NX-2

3. In order to check that heartbeat will load when a reboot occurs,

enter: chkconfig --list | grep -i hearbeat

The expected output should be as below with init levels 3 and 5

recorded as “on”

heartbeat 0:off 1:off 2:off 3:on 4:off 5:on 6:off

Editing the cib.xml file:

1. Login to NX-1 and start the heartbeat service by entering service

heartbeat start

NOTE Although you will receive an “OK” message immediately after entering the command above, this does not necessarily mean that the heartbeat process is up. The heartbeat process may take up to 5 minutes to start each time. You are advised to wait 5 minutes before proceeding. You can check that heartbeat is running by entering: ps -ef | grep heartbeat | grep –v grep. If the heartbeat process is not yet up, the output of this command will be empty.

2. Enter crm_mon. In the crm_mon output, note and record the

HEX value listed for node NX-1 only in a separate text file.

NOTE When logged into this node, ignore any HEX values you see for the other NX node, and record only the HEX value for the node you are logged into.

3. Stop the heartbeat service on NX-1 by entering service heartbeat

stop

NOTE Although you will receive an “OK” message immediately after entering the command above, this does not necessarily mean that the heartbeat process has stopped. The heartbeat process may take up to 5 minutes to stop each time. You are advised to wait 5 minutes before proceeding. You can check that heartbeat is stopped by entering: ps -ef | grep heartbeat | grep –v grep. If the heartbeat process has stopped, the output of this command will be empty.

4. Repeat steps 1-3 above for NX-2, this time recording the HEX

value listed for the NX-2 node in a separate text file.

5. Login to NX-1, go to the directory called

/home/install/Linux/HA/resources and edit the cib.xml file

6. The HEX values for both NX-1 and NX-2 appear in two places in

the file – firstly under “node id” and secondly under “expression

attribute”. In both places, replace the HEX values with the new

values for NX-1 and NX-2 which you recorded from the crm_mon

output in steps 2 and 4 above



<nodes>

<node id="a4fb160c-30be-4744-8822-a9f1f790f675" uname="nx2.allot.com" type="normal"/>

<node id="37f206c8-a973-48db-bfbe-a7db915fefed" uname="nx1.allot.com" type="normal"/>

<expression attribute="#uname" id="a4fb160c-30be-4744-8822-a9f1f790f675"

operation="eq" value="nx2.allot.com"/>

<expression attribute="#uname" id="37f206c8-a973-48db-bfbe-a7db915fefed"

operation="eq" value="nx1.allot.com"/>

WARNING: Replace ONLY the Hex values that are contained

within the quotation marks. Take care not to replace

or change any other parts of the file.

Figure ‎2-37: Updating cib.xml

7. Now look for the line containing: name=”ip”

8. When you find this line, replace the IP that is contained in the

value=”x.x.x.x” field with the virtual IP value.

WARNING Replace ONLY the virtual IP value that is contained within the quotation marks. Take care not to replace or change any other parts of the file.

Figure ‎2-38: Updating cib.xml

9. Delete all files from the directory /var/lib/heartbeat/crm

10. Copy the newly edited cib.xml file to /var/lib/heartbeat/crm by

entering the command below:

cp /home/install/LINUX/HA/resources/cib.xml

/var/lib/heartbeat/crm/

11. Change the owner of the file by entering:

chown hacluster:haclient /var/lib/heartbeat/crm/*

12. Repeat steps 5-11 on NX-2

<nvpair id="39163b78-bf63-47dc-bb7a-7e1557d29a5b" name="ip" value="10.4.60.112"/>



Run set_nx_ip4ui.sh Script

In order to ensure that the NetXplorer Client bonds only with the Virtual IP address of

the NX-HAP cluster, you will need to run the set_nx_ip4ui.sh script on both NetXplorer

nodes. In each case you should enter the Virtual IP Address of the NX-HAP when

prompted to enter an IP address. For full instructions, refer to Appendix G – NX IP

Address for UI Script below.

To verify a successful configuration:

1. Start the heartbeat service on node NX-1 by logging into NX-1

and entering service heartbeat start

WARNING Although you will receive an “OK” message immediately after entering the command above, this does not necessarily mean that the heartbeat process is up. The heartbeat process may take up to 5 minutes to start each time. You are advised to wait 5 minutes before proceeding. You can check that heartbeat is running by entering: ps -ef | grep heartbeat | grep –v grep. If the heartbeat process is not yet up, the output of this command will be empty.

2. Now that the heartbeat process is running on NX-1 alone, verify

that the GUI can be accessed from the virtual IP

3. Stop the service on node NX-1 by entering service heartbeat stop

WARNING Although you will receive an “OK” message immediately after entering the command above, this does not necessarily mean that the heartbeat process is down. The heartbeat process may take up to 5 minutes to shut down each time. You are advised to wait 5 minutes before proceeding. You can check that heartbeat is down by entering: ps -ef | grep heartbeat | grep –v grep. Once the heartbeat process is down, the output of this command will be empty.

4. Start the heartbeat service on node NX-2 by entering service

heartbeat start

WARNING Although you will receive an “OK” message immediately after entering the command above, this does not necessarily mean that the heartbeat process is up. The heartbeat process may take up to 5 minutes to start each time. You are advised to wait 5 minutes before proceeding. You can check that heartbeat is running by entering: ps -ef | grep heartbeat | grep –v grep. If the heartbeat process is not yet up, the output of this command will be empty.

5. Now that just heartbeat is running on NX-2 alone, verify that the

NetXplorer GUI can be accessed from the virtual IP

6. Start the heartbeat service on node NX-1 again by entering service

heartbeat start



Stage 3: Add NX-HAP VIP as Target for Internal SNMP Traps

This stage is mandatory to ensure that SNMP communication is always possible

between devices such as the NE, SG or SMP and the virtual IP of the NX-HAP. This

ensures that such communication will continue in the event of a failover between the

active and passive NetXplorer nodes.

To add the NX-HAP virtual IP as the SNMP trap target, follow the steps below:

1. Open the NetXplorer GUI.

2. From Network in the Network Pane, right click and choose

Configuration

3. Select the SNMP Tab

4. In the “IP Target For Receipt Of SNMP Traps” section, choose

“Other IP Target” and enter the Virtual IP address of the NX-

HAP cluster to ensure that traps are sent here.

Figure ‎2-39: Specifying NX-HAP IP for Receipt of SNMP Traps

Stage 4: Configuring the NX-HAP to Send SNMP Traps

Follow the step-by-step instructions below to enable Linux based high availability traps

to be sent from the NX-HAP cluster. The traps are based on the LINUX-HA-MIB mib file.

When a passive NX node becomes active it will send a trap to the trap receiver which

you define below.

1. Open an SSH session to NX-1

2. Edit the /etc/snmp/snmpd.conf file with VI. Add the IP address

of the trap receiver to the trap2sink field as shown in the example

below:



/etc/snmp/snmpd.conf

trap2sink 192.168.1.229

[root@nx1 ~]#

3. Restart the snmpd process by entering the command: service

snmpd restart

4. Check snmpd service is running by entering the command: service snmpd status


High Availability Failover Traps

Once the NetXplorer nodes have been configured to send traps to an external server,

traps will begin to be sent. The traps are part of the LINUX-HA-MIB.mib and 6 traps

are available.

Name Description OID

LHANodeStatusUpdate A node status change event just happened

1.3.6.1.4.1.4682.900.1

LHAIFStatusUpdate A link status just changed 1.3.6.1.4.1.4682.900.3

LHAMembershipChange A node just changed it membership

1.3.6.1.4.1.4682.900.5

LHAHBAgentOnline The heartbeat agent for this node is online and ready to accept queries

1.3.6.1.4.1.4682.900.7

LHAHBAgentOffline The heartbeat agent for this node is offline

1.3.6.1.4.1.4682.900.9

LHAResourceStatusUpdate A resource status change event just happened

1.3.6.1.4.1.4682.900.11

Stage 5: Enabling Protocol Pack Updates

Follow the steps below to enable future protocol pack updates for the NX-HAP

1. Open an SSH session to the virtual IP of the NX-HAP

2. Enter the command below: mkdir /opt/sybase/data/nx

3. Enter the command below:

mkdir /opt/sybase/data/nx/webupdate


Chapter 3: Configuration

Overview

This chapter describes the processes used to configure, add and change NetEnforcers,

Service Gateways and other devices as well as how to register and maintain users.

The NetXplorer, once installed on the network, enables the central configuration of

managed NetEnforcers, Service Gateways and Monitoring Collectors. It has an easy

GUI interface that provides access to all the devices via a device tree. All available

configuration parameters can be accessed via the GUI.

Monitoring Collectors may be added between the NetXplorer Servers and the

NetEnforcers or Service Gateways, in order to support sparse and remote geographic

regions.

In order to manage more than one NetEnforcer or Service Gateway device using

NetXplorer, the NetXplorer Server must be enabled by entering the appropriate key.

This key may be entered at installation or at any time following.

Working with Devices

In order for NetXplorer to manage a Device (NetEnforcer or Service Gateway, SMP,

etc), it must be added to the NetXplorer's network and properly configured. The IP

address of the NetEnforcer or Service Gateway is required for this procedure.

NOTE Initial configuration of the NetEnforcer or Service Gateway should be performed on the NetEnforcer or Service Gateway (via the CLI interface) before it is added to the NetXplorer configuration. Refer to the hardware manual for the specific NetEnforcer or Service Gateway model for details.

To add a NetEnforcer or Service Gateway:

1. In the Navigation pane, right-click Network in the Network of the

Navigation tree and select New NetEnforcer from the popup

menu.

OR

Select Network in the Network pane of the Navigation tree and then select New

NetEnforcer from the Actions menu.

The NetEnforcer Properties - New dialog is displayed.

‎Chapter 3: Configuration


Figure ‎3-1: NetEnforcer Properties – New Dialog

2. Enter the name of the NetEnforcer or Service Gateway and its IP

address in the designated fields.

3. In the Password field, enter the admin password of the

NetEnforcer or Service Gateway

NOTE: The default admin password is „allot‟ in all NetEnforcer and Service Gateways

4. Choose a Monitoring Collector or Collector Group for the

NetEnforcer or Service Gateway from the drop down menus. The

new NetEnforcer or Service Gateway will transmit its monitoring

data to that Collector or Group only. The default option is

<system defined> which means that the NetEnforcer or Service

Gateway will transmit its monitoring data to the internal Short

Term Collector which is built into the NetXplorer server . If you

do not have any Monitoring Collectors on the Network and you do

not want to use the NetXplorer‟s internal monitoring collector,

select No Collector.

5. Click OK. The NetEnforcer or Service Gateway is added to the

Navigation tree. The Add NetEnforcer operation can take up to a

couple of minutes to complete.

To Import a NetEnforcer or Service Gateway:

1. A NetEnforcer or Service Gateway can be imported into

NetXplorer if it already exists on the network but has not

previously been part of this NetXplorer network or had

NetXplorer enabled. When a NetEnforcer or Service Gateway is

imported, its policy tables and catalogs remain intact and are

imported into the NetXplorer database.

2. Select Import NetEnforcer from the Tools menu.

The NetEnforcer Properties - Import dialog is displayed.



Figure ‎3-2: NetEnforcer Properties – Import Dialog

3. Enter the name of the NetEnforcer or Service Gateway and its IP

address in the designated fields.




5. Assign a Monitoring Collector or Collector Group to the

NetEnforcer or Service Gateway from the drop down menus. This

means that the new NetEnforcer or Service Gateway will transmit

its monitoring data to that Collector or Group only. If it does not

matter which Collector is used, select <system defined>. If you

do not have any Monitoring Collectors on the Network, select No

Collector.

6. Click OK. The NetEnforcer or Service Gateway is added to the

Navigation tree. The Import NetEnforcer operation can take up to

a couple of minutes to complete.

To add a Monitoring Collector

1. In the Navigation pane, right-click Servers in the Network pane

of the Navigation tree and select New Collector from the popup

menu.

OR

Select Servers in the Network pane of the Navigation tree and

then select New Collector from the Actions menu.

The Monitoring Collector Properties - New dialog is displayed.



Figure ‎3-3: Monitoring Collector Properties – New Dialog

2. On the General tab, enter the Name and IP address of the

Monitoring Collector.

3. In the Backup if Monitoring Collector Fails area, select one of the

two radio buttons, No Backup or On Failure, Transfer To…. If

On Failure, Transfer To… is selected, select the backup

Monitoring Collector from the drop down menu.

Figure ‎3-4: Monitoring Collector Properties – New Dialog

4. In the Associated NetEnforcers tab, a list of all NetEnforcer or

Service Gateways transmitting monitoring information to this

Collector appears. They are assigned by right clicking on a

NetEnforcer or Service Gateway in the Network pane and

selecting Properties.

5. Click Save. The Monitoring Collector is added to the Navigation

tree. The Add Monitoring Collector operation can take up to a

couple of minutes to complete.

NOTE For more information concerning Monitoring Collectors, see the NetXplorer Administration Guide.

To add a Collector Group

Collector Groups are made up of two Collectors, providing 1+1 redundancy.

1. In the Navigation pane, right-click Servers in the Network pane of

the Navigation tree and select New Collector Group from the

popup menu.

The Collector Group Properties - New dialog is displayed.



Figure ‎3-5: Collector Group Properties – New Dialog

2. In the Collector Group tab Select the two Collectors (already part

of the network) to be included in the group. Collector 2 will act as

the backup for Collector 1.

3. Those NetEnforcer or Service Gateways associated to the added

Collectors will be listed in the Associated NetEnforcers tab.

4. Click Save. The Collector Group is added to the Navigation tree.

The Add Collector Group operation can take up to a couple of

minutes to complete.

To add an SMP

NOTE This feature is only available with the appropriate license key, enabling Subscriber Management. Contact Allot Customer Support at [email protected] for more information concerning your license.


the Navigation tree and select New SMP from the popup menu.

OR

Select Servers in the Network pane of the Navigation tree and

then select New SMP from the Actions menu.

The SMP Properties - New dialog is displayed.

Figure ‎3-6: SMP Properties – New Dialog

2. Enter the Name and IP address of the SMP.

3. Select the SMP Type using the radio buttons. Select either

Subscriber Mapping, Subscriber Mapping Short Term Collector or

Subscriber Mapping Short Term Collector Quota Management.

4. Click Save. The SMP is added to the Navigation tree. The Add

SMP operation can take up to a couple of minutes to complete.

NOTE For more information concerning SMPs, see the Allot SMP User‟s Manual.

To change the IP of a NetEnforcer or Service Gateway:




1. Select the NetEnforcer or Service Gateway device in the

Navigation tree and then select Properties from the Actions menu.

The Device Properties-Update dialog is displayed.

Figure ‎3-7: Device Properties Update dialog

2. Enter the new IP address of the NetEnforcer or Service Gateway

in the designated field




4. Click Save

NOTE If you change the IP of the NetEnforcer or Service Gateway, you must also change the IP in the device configuration of the NetXplorer.

To Remove a NetEnforcer or Service Gateway from the network:

1. Right-click Network and select a NetEnforcer or Service Gateway

and select Delete.

The following Delete message is displayed.

Figure ‎3-8: System Message

2. Click Yes to delete the NetEnforcer or Service Gateway.

To configure a NetEnforcer or Service Gateway via the NetXplorer:



1. In the Navigation pane, select and right-click the NetEnforcer or

Service Gateway in the Navigation tree and select Configuration

from the popup menu.

OR

Select the NetEnforcer or Service Gateway in the Navigation tree and then

select Configuration from the View menu.

OR

Select the NetEnforcer or Service Gateway in the Navigation tree and then

click the Configuration icon on the toolbar.

The Configuration window for the selected NetEnforcer or Service Gateway is

displayed.

Figure ‎3-9: NetEnforcer Configuration

2. Configure the NetEnforcer or Service Gateway parameters, as

required.

3. Click or select Save from the File menu to save the changes

to the NetEnforcer or Service Gateway configuration.

NOTE For detailed descriptions of the parameters in each of the NetEnforcer Configuration tabs, refer to NetEnforcer Configuration Parameters in the NetXplorer Operations Manual.

The NetEnforcer Configuration parameters available in the NetEnforcer Configuration

window are grouped on the following tabs:

General – indicates the NetEnforcer or Service Gateway‟s bypass status.

Identification and Keys – includes parameters that provide system information

and activation keys



SNMP – enter the contact person, location, system name and description for

SNMP purposes

Security – includes security and authorization parameters

NIC – includes parameters to configure the system interfaces to either

automatically sense the direction and speed of traffic or use default parameters

as well as parameters to define ports

Networking – includes parameters that enable you to configure network

topology

IP Properties – enables you to modify the IP and host name configuration of

your network interfaces as well as the DNS and connection control parameters

Date/Time – includes the date, time and NTP server settings for the


Service Activation - includes IP and Port Redirection Parameters

Slots and Boards- includes device layout to provide schematic device

components layout (when applicable) and status information

After modifying configuration parameters you must select Save in order for the changes

to take effect. The save process prompts a rebooting of the NetEnforcer or Service

Gateway. Rebooting is required to ensure that some saved parameter values are

committed and activated on the NetEnforcer or Service Gateway.

Configuring NetXplorer Users

NetXplorer implements a role-based security model. The role defined for each

authorized user indicates the scope of operations that can be performed by the user.

There are three types of NetXplorer roles, as follows:

Regular: Read/write privileges in the NetXplorer application not

including User Configuration and System Report definitions.

Monitor: Read-only access (unavailable menu items will appear in

grey).

Administrator: Read/write privileges in the NetXplorer application,

which includes read/write privileges to define User Configurations

and System Reports.

This section describes the processes used to register and maintain users. It includes how

to add a new user, change a user‟s information and how to delete a user.

To add a new user:



1. Select Users Configuration from the Tools menu.

2. The Users Configuration Editor dialog is displayed, listing all

currently defined NetXplorer users.

Figure ‎3-10: Users Configuration Editor

3. Click Add.

The User Editor dialog is displayed.

Figure ‎3-11: User Editor

4. Enter the name of the user in the User Name field.

5. Enter a password for the user in the Password field and then again

in the Confirm PW field.

NOTE The user password must be at least six characters in length and include at least one numerical digit.

6. Set the permissions level of the user by selecting the radio button

for the required role (Administrator, Regular or Monitor).



7. (Optional) Enter the user's contact information in the Email and

phone fields. You can also enter a brief description in the

designated field.

8. (Optional) Click Advanced to manage password policy (see

below).

9. Click OK.

10. The new user has been added to the list of users in the Users

Configuration Editor dialog.

To edit user information:

1. In the Users Configuration Editor dialog (Figure 3-18), select the

user whose information you want to edit

2. Click Edit.

The User Editor dialog is displayed.

3. Edit the user parameters, as required

4. Click OK.

To delete a user:

1. In the Users Configuration Editor dialog, select the user(s) to be

deleted

2. Click Delete.

3. A confirmation message is displayed.

4. Click Yes to confirm the deletion.

The user is no longer able to access the NetXplorer.

WARNING There must be at least one Administrator user in the system.

Password Management

It is possible to manage password policy for all users from the User Configuration

panel.

To manage password policy:

1. Select Users Configuration from the Tools menu.

2. Click the Advanced button.

The Password Management dialog box opens.



Figure ‎3-12: Password Management dialog box

3. Select the Enable Password Management Policy checkbox in

order to set the number of days between mandatory password

changes and how many days before a password is disabled a

warning will be displayed.

4. Select Enforce Minimum Length for Password to require all

passwords to be at least five characters in length.

5. Select Enforce Password Character’s Type Limitation to

require all passwords to include at least one number, one

uppercase letter and one lowercase letter (case sensitive).

6. Click Save.

The new password policy will be applied to all passwords created from that

point.


Chapter 4: Monitoring Collectors

Overview

Figure ‎4-1: Collector – Front View

Figure ‎4-2: Collector– Rear View

Allot‟s NetXplorer utilizes Distributed Monitoring Collectors. The collectors gather

short-term network usage statistics from the NetEnforcer or Service Gateways.

Distributed monitoring collectors increase the scalability of your deployment. Each

collector can support several NetEnforcers or Service Gateways. By deploying

distributed collectors, you can increase the total number of NetEnforcers or Service

Gateways supported by a single NetXplorer server. This is possible because the

NetXplorer can split the storage of the real-time monitoring data between several short-

term databases.

‎Chapter 4: Monitoring Collectors


A second reason for using distributed monitoring collectors is to overcome connectivity

issues in distributed networks. In order to support data collection, the line speed

between the NetEnforcer or Service Gateway and the collector must be at least 10Mbps

mainly for the high throughput devices such as AC-10000 and SG-Sigma. If you are

working with a low throughput device, for example an AC-400 with 2 or 10 Mbps,

statistics can be collected over slower connections without the need for distributed

collectors.

Up until now, the collectors have always been situated on the NetXplorer server.

However, some cases the networks have topology that does not allow for a 10Mbps line

between the NetEnforcer or Service Gateway and the server. This can happen for

example when the network is spread out over remote geographical locations. In such

cases, the use of collectors is necessary. The line between the NetEnforcers or Service

Gateways and their collectors will be at least 10Mbps. The line between the collectors

and the NetXplorer server can be of lower capacity however, a collector is needed for

each network zone that cannot guarantee a 10Mbps connection to the server.

A third reason for deploying distributed monitoring collectors is redundancy. If a

collector is unavailable, data from the NetEnforcer or Service Gateways, which this

collector supports, can automatically be collected by a defined backup collector.

Data Collection Process

In addition to any external collectors which may be deployed, the NetXplorer server has

its own internal short-term collector.

NOTE This short-term collector cannot be deleted even if there are external collectors.

Traffic statistics are collected in buckets. There are 30-second buckets and 5-minute

buckets. The buckets are imported into the database by the collector per sample period.

In a NetXplorer implementation, which does not include external collectors, the buckets

are loaded into the short-term database, located on the NetXplorer, every 30 seconds or

5 minutes. Long-term buckets are created every hour on the NetXplorer and are then

loaded into the long-term database on the same machine.

Implementations with external monitoring Collectors also collect samples in 30-second

buckets and 5-minute buckets. The buckets are imported to the collector at every sample

period. The data contained in the buckets is stored in the short-term database of the

collector. The samples in the Database are aggregated into one-hour buckets, which are

then loaded into the long-term database on the NetXplorer once an hour. Therefore, a

NetXplorer implementation that includes external collectors will have additional traffic

sent once an hour, namely, the long-term bucket. The short-term data, however, arriving

every 30 seconds, will have a shorter distance to travel. This could be of great

importance when NetEnforcers or Service Gateways do not have constant connectivity

to the server. External monitoring collectors can significantly lower the burden on the

NetXplorer server.

The monitoring data is saved on the NetXplorer server, and can be displayed in the GUI



Collector Redundancy

In case a collector is unavailable, data from the NetEnforcers or Service Gateways that

this collector supports can automatically be collected by a defined backup collector.

There are two types of redundancy models possible:

One type of redundancy model is the N+1 model. In this case, several collectors are all

backed up by a single collector dedicated to this purpose. This solution takes into

account that the probability of more than one collector failing is very low. However, it

may be difficult to locate the backup collector in close proximity to all of the configured

collectors.

Figure ‎4-3 N+1 Collector Redundancy

Where high performance redundancy is of particular importance, or where the network

topology does not allow for the use of a single collector for backup, you will need to use

the 1 to 1 redundancy model. In this situation, each collector has a dedicated backup

collector as part of a Collector Group.



Figure ‎4-4 1+1 Collector Redundancy

NetXplorer Support

Each NetXplorer server can support up to five external short-term collectors in addition

to its one built-in internal collector.

Each collector can support a single Service Gateway (SG-Omega or SG-Sigma) or

NetEnforcer AC-10000, up to two (2) NetEnforcers of the AC-5000 series, up to five

(5) NetEnforcers of the AC-3000, AC-2500, AC-1400 or AC-10000 series, up to ten

(10) NetEnforcers of the AC-800 or up to fifteen (15) NetEnforcers of the AC-400

series.

You can also combine NetEnforcers of different models according to this formula. For

example, one collector can support three AC-1000s and six more AC-400s.

The NetXplorer‟s built in short-term collector can support additional NetEnforcers

according to the same ratios.

NOTE This is a simple calculation based on a series of conservative assumptions. It is important to consult with Allot HQ to verify the exact number of collectors required.



Installing Monitoring Collectors

Once the Collector has been physically installed, the following steps must be taken in

installing Monitoring Collectors:

Set the collector‟s initial parameters

Physically connect the Collector to the network

Add the Collector to the NetXplorer using the NetXplorer user interface

Associate NetEnforcers or Service Gateways to the Collector.

To set initial parameters of the Monitoring Collector:

1. Connect a monitor to the VGA connector and a keyboard and

mouse to the USB connectors on the front panel of the Monitoring

Collector as shown in Figure ‎4-5 below.

Figure ‎4-5: Connecting the Collector – Front View

2. When prompted, enter admin for the login and allot for the

password.

3. Enter the following command to set the IP address, network mask

and default gateway: go config ips –ip <IP ADDRESS>:<NETWORK MASK> -g <DEFAULT GATEWAY>

4. The Collector should be set to STC (short term collector) mode.

This can be checked by running the following command: dev_setup.sh –v command.

If the device mode is not set to STC use the following command



to set it as an STC appliance: dev_setup.sh –m stc

Change the password by entering the following command: passwd

5. When prompted, enter a new password, between 5 and 8

characters in length and press <enter>.

6. Enter the new password a second time when prompted to confirm

the change.

To add the new Monitoring Collector to the network:

1. Open NetXplorer.

2. In the Navigation pane, right-click Servers in the Network pane in

the Navigation tree and select New Collector from the popup

menu.

The Monitoring Collector Properties - New dialog is displayed.

Figure ‎4-6: Monitoring Collectors Properties dialog – General tab

3. On the General tab, enter the IP address of the Monitoring

Collector.

4. Enter a name for the Monitoring Collector.

5. In the Backup if Monitoring Collector Fails area, select one of the

two radio buttons, No Backup or On Failure, Transfer To

6. If you select On Failure, Transfer To, select the backup

Monitoring Collector from the drop down menu.

7. Click Save. The Monitoring Collector is added to the Navigation

tree. The New Collector operation can take up to a couple of


NOTE There are no NetEnforcers or Service Gateways associated with this collector yet, therefore the Associated NetEnforcers tab is disabled.



8. Repeat this process as often as required to add further Collectors

to the network.

To assign NetEnforcers to the new Monitoring Collector:

1. In the Navigation pane, right-click a NetEnforcer or Service

Gateway in the Navigation tree and select Properties from the

popup menu.

The NetEnforcer Properties - Update dialog is displayed.

Figure ‎4-7: NetEnforcer Properties dialog

2. Assign a Monitoring Collector to the NetEnforcer or Service

Gateway from the drop down menu. This means that the

NetEnforcer or Service Gateway will transmit its monitoring data

to that Collector only. If it does not matter which Collector is

used, select <system defined>.

3. If there is currently a collector associated with this NetEnforcer or

Service Gateway, its unique name is displayed. Select a new

monitoring collector from the drop down menu.

4. Click Save.

To verify that the new collector has been associated with the NetEnforcer or Service

Gateway, select the collector in the Navigator pane and click Properties. You should see

the NetEnforcer or Service Gateway in the Associated NetEnforcer tab.

NOTE: You cannot change the association from this dialog, only from the NetEnforcer properties dialog.

To view the NetEnforcers or Service Gateways associated with a Monitoring Collector

1. Right-click the selected collector and choose properties. The

Associated NetEnforcers tab is not disabled and you can view a

list of all NetEnforcer or Service Gateways transmitting

monitoring information to this Collector.



Figure ‎4-8: Monitoring Collector Properties - Update

Collector Groups

Collector Groups are made up of two Collectors, providing 1+1 redundancy for each

other.

To add a Collector Group


the Navigation tree and select New Collector Group from the

popup menu.

The Collector Group Properties - New dialog is displayed.

Figure ‎4-9: Collector Group Properties – New Dialog

2. In the Collector Group tab Select the two Collectors (already part

of the network) to be included in the group. Collector 2 will act as

the backup for Collector 1.

3. Those NetEnforcers or Service Gateway‟s associated to the added

Collectors will be listed in the Associated NetEnforcers tab.

4. Click Save. The Collector Group is added to the Navigation tree.

The Add Collector Group operation can take up to a couple of




Configuring Monitoring Collectors

To configure a Monitoring collector, you will use two dialogs. The first is the

Configuration dialog and the second is the Properties dialog.

To configure the Collector’s Settings - Configuration

1. In the Navigation pane, right-click the Collector and select

Configuration

The configuration window for that collector is displayed.

The dialog shows the following tabs:

General – View the collector‟s serial number, software version and model

Figure ‎4-10: Collector Configuration Window - General Tab

SNMP - Add a contact person, location and system name for SNMP purposes

NOTE The Collector, as well as the NetEnforcer or Service Gateway supports SNMP (Simple Network Management Protocol) that includes standard MIB II traps.

Figure ‎4-11: SNMP Tab

Date/Time – Configure the time zone according to the geographical location of the

collector

NOTE The NTP server cannot be changed



Figure ‎4-12: Date/Time Tab

IP Properties – Inset the IP Address, Network Mask, Default Gateway, Host Name,

Domain Name, Primary Server and the Secondary Server

NOTE If you change the Collector‟s IP address, you must make the NetXplorer server aware of this change by changing the IP in the Collector‟s Properties dialog.

Figure ‎4-13: IP Properties Tab

Security – Check the appropriate boxes to apply general security attributes. Select

the radio button to limit access to specific hosts

NOTE If you select Unrestricted Access Allowed, any host can access the system.



Figure ‎4-14: Securities Tab

To configure the Collector’s Settings - Properties

1. In the Navigation pane, right-click the Collector and select

Properties

2. The Monitoring Collectors Properties dialog is displayed.

Figure ‎4-15: Monitoring Collector Properties – Update Dialog

The dialog shows two tabs:

General – Set the name, IP and backup setting of the Collector

Associated NetEnforcers - View the NetEnforcer or Service Gateways

currently associated with this collector.

NOTE Collector Role shows the collectors as configured. It will show a collector as backup only if the configured collector is unavailable and the backup collector is operating instead.



Troubleshooting the Collector

Command Line Interface

To connect to the collector using an SSH connection

1. Login as user admin with the password allot.

2. Enter go config, with no additional parameters, to view all the

available configuration commands

3. Enter go config plus parameter to view the available commands

for that parameter

For example, enter go config ips to view the available CLI options for IPs

Processes

To check that all of the collector's processes are running, enter the command

keeperMgr –l

The processes that should be running include:

dbserv9

AllSnmpAgent

The following processes must be running to insure proper data collection

Converter.exe

Loader.exe

Poller.exe

Logs and Snapshots

Log files for the collector are located in the following directory: opt/allot/log.

To take a snapshot of a Collector, run the following script on the Collector: host:/opt/allot/bin$ create_snapshot_logs.sh

Snapshots can be found in the tmp folder located at: host:/opt/allot/tmp$



Recreating Databases

To recreate the default database of the collector, login to the collector as root user and

use the following command: ./recreate_db.sh stc

Output Example

NetXplorerCollector:/opt/allot/bin# ./recreate_db.sh stc

Create(initialization) database - allot_stc

Adaptive Server Anywhere Initialization Utility Version

9.0.2.3397

Creating system tables

Collation sequence: ISO1LATIN1

Creating system views

Setting permissions on system tables and views

Setting option values

Initializing UltraLite deployment option

Database "/opt/sybase/data/db/stc/allot_stc.db" created

successfully

Create user - nms

Create dbspaces

Create tables

Load default data into database

Get mediation device type for stc database

Mediation device type is 1

Configure parameters

Version name is 8.1.0b07

Create stored procedures and user defined functions

Add common STC/LTC stored procedures and user defined

functions

Create database events

Create database remote server/table

Configure database

Pre-allocate space for dbspaces

Fri Jan 23 18:44:13 GMT 2009

!!! This script will work up to 60-120 minutes !!!

Fri Jan 23 19:39:03 GMT 2009

NetXplorerCollector:/opt/allot/bin# reboot

Changing IP Addresses

To change the IP address of the NetEnforcer or Service Gateway and Collector:

1. Stop the NX Server process by opening Start on the Windows

Task Bar and selecting Settings > Control Panel.



2. Double-click Administrative Tools and open Services.

3. Right-click NetXplorer in the list of Services and select Stop

from the drop-down menu. Leave the Services window open.

4. Copy the original CFG folder on the server to another place for

backup. It is located in $Allot\data\db.

5. Start the NX Server process again by right-clicking NetXplorer in

Services and selecting Start from the drop-down menu.

6. Login and delete the NEs and Collector from the NX server (that

enables us not to affect the device policy on the NetEnforcer or

Service Gateways during the process). The NE's must be deleted

before the collector (right-click on each and choose delete).

7. Stop the NX Server process again.

8. Change the IP address and reboot the server.

9. Now logon to the collector as admin. Reboot it with the command

'reboot'.

10. Log back onto the Collector again and change the IP address and

gateway – to change the ip on the collector run the follow

command:

go config ips -ip oob:<CURRENT COLLECTOR

IP>:255.255.255.0 -g <NEW COLLECTOR IP>

11. Reboot the collector.

12. Log back onto the NX Server, stop the service, and copy the

backup CFG folder back to its original location.

13. Start the NX server process.

14. Check the allot_ltc.txt, allot_stc.txt log files located under Allot

Home Directory\Logs in order to verify that NetXplorer services

are running

15. Right click on the configuration of the collector and change it to

the new IP address.


Chapter 5: Database Management

The NetXplorer is a centralized management system, which enables the ongoing

collection and consolidation of data from multiple NetEnforcer or Service Gateway

devices that enable users to produce consolidated reports. The key to a centralized

system is the ability to consolidate information from all the managed groups that are

being monitored. Because NetXplorer allows for the ongoing collection and

consolidation of data from multiple NetEnforcer or Service Gateway devices, users are

able to produce consolidated reports based the information collected.

In order to manage the collected data, there are three databases:

CFG Tables - Configuration parameters

STC Database – Short term database

LTC Tables – Long term database

Backup Terms

Cold backup – A backup process performed with the NetXplorer server

offline.

Hot backup – A backup process performed without interrupting NetXplorer

operation

Full Backup – A backup process that copies all of the data to a location from

which we can create an entire database.

Incremental Backup – A process that preserves only the changes made since

the latest backup, either full or incremental, the latest of them.

Database Restore – A process to create a database using the backup copy.

Typically, the restore process consists of copying the latest full backup to the

restore directory, and then “applying” the incremental backups that were

performed after that last full backup.

Backup generation –Backups are kept cyclically as generations. Each

generation is a full set of backup files capable of restoring the database to the

point in time in which its last iteration was created. Each generation typically

consists of one full backup and several incremental backups.

Incremental Backup serial number – Within a certain generation, incremental

backups are performed one after another, each one being part of a certain serial

number.

‎Chapter 5: Database Management


Hot Backup Options Per Database Type

Configuration Tables (CFG) –Full backup and periodical

incremental backups, manually or scheduled. Full backup is

performed once a day while the incremental backup is performed

every hour. All values are configurable by the user and can be

changed according to requirements.

Short Term Collector Database (STC) –Full backups only,

manually or scheduled. STC full backup only backs up a set of

files that hold the values kept in key tables (such as param) but the

actual traffic data is NOT saved. The restore process, therefore,

recreates a new database from scratch, performs a delete and then

loads the key tables mentioned.

Long Term Collector table (LTC) – Full backups only. This is a

manual process only. This is due to the database‟s potential size.

Using Backups to Achieve NX Redundancy

The following scenario is one suggestion for using backups to achieve NetXplorer

redundancy:

1. Install two NetXplorer servers, one used exclusively as backup.

2. Schedule regular backups for the CFG and STC databases.

3. Perform a manual backup of the LTC database once per

day/week/months (depending on the requirements)

4. In the event that the main NetXplorer server fails, assign the same

IP to the backup NetXplorer server.

5. Restore the CFG, STC, and LTC database backups to the new

NetXplorer.

Database Management on Windows

Cold Backup

To perform a Cold backup:

1. Stop the NetXplorer Service.

Click Start on the Windows Task Bar and select Settings > Control

Panel.

Double-click Administrative Tools and open Services.



Right-click NetXplorer Server in the list of Services and select Stop

from the drop-down menu.

Check the allot_ltc.txt, allot_stc.txt log files located under Allot Home

Directory\Logs in order to verify that NetXplorer services are not

running:

The following lines should appear in both allot_ltc.txt, allot_stc.txt log

files:

"Disable all events"

"End of current events"

2. Copy Allot Home Directory\data\db folder to a backup directory

3. Restart the NetXplorer Service.


Panel.


Right-click NetXplorer Server in the list of Services and select Start


NOTE If a customer is upgrading from a previous NetXplorer version the backup directory will be located at Allot Home Directory\data\db.

To restore the Cold backup:



Panel.






running:


files:





2. Restore the database by copying the backup to the following

folder: /opt/sybase/data/backup/cfg OR d:\allot\data\backup.

If you get a "Confirm Folder Replace" pop-up window, then press

"Yes to All".



Panel.




Hot Backup

Backing up CFG Tables

NOTE The following commands should not be cut and pasted into the DOS window, but typed in. They may not function properly unless entered manually.

To perform an incremental hot backup manually:

1. Open a Microsoft DOS window on the NetXplorer Server.

2. Open the Allot\Bin directory (by default D:\Allot\bin).

3. At the prompt enter the following command:

db_maint –a backup –n cfg –t incremental

To perform a full hot backup manually:




db_maint –a backup –n cfg –t full

To check the hot backup parameters:






db_maint –a backup_status –n cfg –sa list

The backup parameters will indicate what scheduled backups are enabled, when they

are scheduled, and how many generations will be backed up.

To enable incremental scheduled hot backups:

NOTE Incremental scheduled hot backup is enabled by default.




db_maint –a backup_status –n cfg –t incremental –sa enable

To schedule an incremental hot backup for a specific time:




db_maint –a backup_status –n cfg –t incremental –sa change_sched –ns <TIME>



To set the amount of time between scheduled incremental hot backups:



3. Enter the following command:

db_maint –a backup_status –n cfg –t incremental –sa change_sched –ni <VALUE> –nt <UNIT OF TIME>

For example, to set a period of 2 hours between incremental backups, enter the

following command

db_maint –a backup_status –n cfg –t incremental –sa change_sched –ni 2 –nt hours

To schedule a full hot backup for a specific time:




db_maint –a backup_status –n cfg –t full –sa change_sched –ns <TIME>



To set the amount of time between scheduled full hot backups:




db_maint –a backup_status –n cfg –t full –sa change_sched –ni <VALUE> –nt <UNIT OF TIME>

For example, to set a period of 20 hours between full backups, enter the following

command

db_maint –a backup_status –n cfg –t full –sa change_sched –ni 20 –nt hours

To change the backup directory:




db_maint –a backup_status –n cfg –sa change_dir –nd <NEW LOCATION PATH>

For example, to change the database directory to cfg1, enter the following command

db_maint –a backup_status –n cfg –sa change_dir –nd D:\backup\cfg1



To change the number of generations:




db_maint –a backup_status –n cfg –sa change_gen –ng <VALUE>

Restoring CFG Tables





db_maint –a backup_status –n cfg –sa list

The backup parameters will indicate the generation numbers of the backups.

The increment number must be found in the correct folder under the backup folder (for

example: D:\Allot\backup\cfg\5\incremental).

To restore the database:



Panel.






running:


files:








db_maint –a restore –n cfg –s <D:\Allot\backup\cfg or LOCATION PATH> –g <GENERATION NUMBER> –i <INCREMENT NUMBER> –d <D:\Allot\data\db\cfg or LOCATION PATH> -b <TEMP LOCATION TO KEEP CURRENT CONFIGURATION>



Panel.






Backing up STC Databases





db_maint –a backup –n stc –t full





db_maint –a backup_status –n stc –sa list







db_maint –a backup_status –n stc –t full –sa change_sched –ns <TIME>







db_maint –a backup_status –n stc –t full –sa change_sched –ni <VALUE> –nt <UNIT OF TIME>


command

db_maint –a backup_status –n stc –t full –sa change_sched –ni 20 –nt hours

To change the hot backup directory:




db_maint –a backup_status –n stc –sa change_dir –nd <NEW LOCATION PATH>


db_maint –a backup_status –n cfg –sa change_dir –nd D:\backup\cfg1







db_maint –a backup_status –n stc –sa change_gen –ng <VALUE>

Restoring STC Databases





db_maint –a backup_status –n stc –sa list

The backup parameters will indicate the generation numbers of the backups




Panel.






running:


files:








db_maint –a restore –n stc –s <D:\Allot\backup\stc or LOCATION PATH> –g <GENERATION NUMBER> –i 0 –d <D:\Allot\data\db\stc or LOCATION PATH>



Panel.






Backing up LTC Tables





db_maint –a backup –n ltc –t full





db_maint –a backup_status –n ltc –sa list





db_maint –a backup_status –n ltc –sa change_dir –nd <NEW LOCATION PATH>


db_maint –a backup_status –n ltc –sa change_dir –nd D:\backup\cfg1




1. Access the NetXplorer via Telnet.



db_maint –a backup_status –n ltc –sa change_gen –ng <VALUE>

Restoring LTC Tables


1. Access the NetXplorer via Telnet.



db_maint –a backup_status –n ltc –sa list





Panel.






running:


files:








db_maint –a restore –n ltc –s <D:\Allot\backup\ltc or LOCATION PATH> –g <GENERATION NUMBER> –d <D:\Allot\data\db\ltc or LOCATION PATH>



Panel.




Database Management on Linux

Cold Backup

To perform a Cold backup:

1. Telnet to the NetXplorer Server


As root user run the following command: service netxplorer stop

Wait for the following message - Stopping NetXplorer Server (this may take a few minutes) [OK]

3. Copy the /opt/sybase/data/db directory to a backup directory

4. Restart the NetXplorer Service

As root user run the following command: service netxplorer start

To restore the Cold backup:







3. Copy the backup directory to /opt/sybase/data/db



Hot Backup

Backing up CFG Tables

NOTE The following commands should not cut and pasted into the telnet session, but typed in. They may not function properly unless entered manually.

To perform an incremental hot backup manually:

1. Telnet to the NetXplorer Server.

2. Open the /opt/allot/bin/ directory.

3. Enter the following command as the root user:

./db_maint_sudo.sh –a backup –n cfg –t incremental


1. Telnet to the NetXplorer Server as root user


3. Enter the command below (inserting the NX version number

instead of 11.1.0b5 if relevant:

/opt/allot/bin/treat_dir /opt/sybase/data/backup/cfg/1 1 full 10.2.1b12 /opt/sybase/data/db/cfg/


./db_maint_sudo.sh –a backup –n cfg –t full





./db_maint_sudo.sh –a backup_status –n cfg –sa list





To enable incremental scheduled hot backups:




./db_maint_sudo.sh –a backup_status –n cfg –t incremental –sa enable

To schedule an incremental hot backup for a specific time:




./db_maint_sudo.sh –a backup_status –n cfg –t incremental –sa change_sched –ns <TIME>

To set the amount of time between scheduled incremental hot backups:




./db_maint_sudo.sh –a backup_status –n cfg –t incremental –sa change_sched –ni <VALUE> –nt <UNIT OF TIME>

For example, to set a period of 2 hours between incremental backups, enter the

following command

./db_maint_sudo.sh –a backup_status –n cfg –t incremental –sa change_sched –ni 2 –nt hours





./db_maint_sudo.sh –a backup_status –n cfg –t full –sa change_sched –ns <TIME>







./db_maint_sudo.sh –a backup_status –n cfg –t full –sa change_sched –ni <VALUE> –nt <UNIT OF TIME>


command

./db_maint_sudo.sh –a backup_status –n cfg –t full –sa change_sched –ni 20 –nt hours

To change the backup directory:




./db_maint_sudo.sh –a backup_status –n cfg –sa change_dir –nd <NEW LOCATION PATH>





./db_maint_sudo.sh –a backup_status –n cfg –sa change_gen –ng <VALUE>

Restoring CFG Tables





./db_maint_sudo.sh –a backup_status –n cfg –sa list

The backup parameters will indicate the generation numbers of the backups.

The increment number must be found in the correct folder under the backup folder (for

example: /opt/sybase/data/db/cfg/5/incremental).










./db_maint_sudo.sh –a restore –n cfg –s <LOCATION PATH> –g <GENERATION NUMBER> –i <INCREMENT NUMBER> –d <LOCATION PATH> -b <TEMP LOCATION TO KEEP CURRENT CONFIGURATION>



Backing up STC Databases





./db_maint_sudo.sh –a backup –n stc –t full





./db_maint_sudo.sh –a backup_status –n stc –sa list









./db_maint_sudo.sh –a backup_status –n stc –t full –sa change_sched –ns <TIME>





./db_maint_sudo.sh –a backup_status –n stc –t full –sa change_sched –ni <VALUE> –nt <UNIT OF TIME>


command

./db_maint_sudo.sh –a backup_status –n stc –t full –sa change_sched –ni 20 –nt hours





./db_maint_sudo.sh –a backup_status –n stc –sa change_dir –nd <NEW LOCATION PATH>





./db_maint_sudo.sh –a backup_status –n stc –sa change_gen –ng <VALUE>

Restoring STC Databases







./db_maint_sudo.sh –a backup_status –n stc –sa list








./db_maint_sudo.sh –a restore –n stc –s <LOCATION PATH> –g <GENERATION NUMBER> –i 0 –d <LOCATION PATH>



Backing up LTC Tables





./db_maint_sudo.sh –a backup –n ltc –t full





./db_maint_sudo.sh –a backup_status –n ltc –sa list







./db_maint_sudo.sh –a backup_status –n ltc –sa change_dir –nd <NEW LOCATION PATH>







./db_maint_sudo.sh –a backup_status –n ltc –sa change_gen –ng <VALUE>

Restoring LTC Tables





./db_maint_sudo.sh –a backup_status –n ltc –sa list





As root user run the following command:




./db_maint_sudo.sh –a restore –n ltc –s <LOCATION PATH> –g <GENERATION NUMBER> –d <LOCATION PATH>


As root user run the following command:

service netxplorer start



Data Collection and Storage Profiles

Profiles can be defined both on the NetEnforcer/Service Gateway and on the

NetXplorer Server. Profiles define a series of parameters which control two things:

Reduction - The amount of data that is included in the buckets, or

stated differently – how much reduction is performed on the

statistics collected. The extent of reduction can be determined in

two places – on the NetEnforcer or Service Gateway when 30

second and 5 minute buckets are collected, and on the Short Term

Collector when 1hr buckets are reduced before being transferred

to the Long Term Collector.

Data Aging - The amount of time for which statistical data is

stored on the server. This can be determined both on the short

term and the long term collector.

Bucket Types

The NetEnforcer or Service Gateway generates up to five types of buckets:

VC buckets (sometimes referred to as Rule buckets) include data that can be

used for Statistics, Utilization, Line, Pipe and VC reports. They can also be

used for the Pipe and VC popularity reports too. As the amount of data in these

buckets is limited by policy definitions, their size is manageable and reduction

is not required. With no reduction performed on the buckets, the user will

always obtain exact information from the graphs which are opened based on

VC buckets.

Conversation buckets include data that can be used for Protocols, Hosts and

Conversation reports. The amount of data in these buckets is not limited by

policy definitions. The data here concerns activity on the network, as opposed

to classified traffic. These buckets collect data regarding each individual

connection on the network. The amount of data here is virtually unlimited and

can exceed millions of conversations. For this reason, reduction is performed on

this data.

NOTE: By default, data for external hosts within conversation buckets is not collected. Consequently, “external hosts” and “conversations” reports are not available by default. Including these records in the conversation buckets uses up statistic collection resources which may impact data collection performance! External hosts data collection can be enabled by using the go config data_collect command on the NetEnforcer or Service Gateway. You should consult with Allot Support before enabling this.

Service buckets are used for the average protocol popularity graphs. They

measure the average number of IPs (or subscribers) generating each type of

protocol. As only a single record is produced per protocol, no reduction is

required.



NOTE: Service Buckets are disabled by default. When enabled, they use up the statistic collection resources which may impact data collection performance! Service Buckets are enabled by using the go config data_collect command on the NetEnforcer or Service Gateway. You should consult with Allot Support before enabling these buckets.

Generic buckets include data that can be used for Integrated Service reports

(redirected traffic), Websafe reports (inspected and illegal sites) and

asymmetric reports (control traffic running between NEs or SGs which are set

up in an asymmetric configuration).

HTTP buckets include data that can be used for the Most Active Domains

report which is disabled by default (these buckets can be activated by enabling

the HTTP monitoring feature from the Integrated Service Tab as described in

the NetXplorer Operation Guide Ch3).

Configuring Profiles

There are 4 places where you need to configure the different profiles.

1. Configure the Reduction Profile on the NetEnforcer or Service

Gateway. This determines the extent of reduction carried out by

the NetEnforcer or Service Gateway.

2. Configure the Reduction Profile on the Short Term Collector

(which may be part of the NetXplorer or deployed externally as

described in ‎Chapter 4: above). This determines the extent of

reduction carried out when passing the aggregated 1hr buckets

between the short term collector and the long term collector.

3. Configure the Data Ageing profile on the Short Term Collector.

This determines how long data is kept in the STC.

4. Configure the Data Ageing profile on the Long Term Collector.

This determines how long data is kept in the LTC.

WARNING: Changing the default reduction and aging profiles can impact the performance of your solution. Different aging and reduction profiles have been designed to suit particular setups. You should not change any of these profiles from their default value without first consulting with Allot Customer Support.



Reduction Profile on NE/SG

For NE/SG Running AOS Software

For a NetEnforcer of Service Gateway running AOS software (AC-1400, AC-3000,

AC-5000, AC-10000 or SG-Sigma), there are 2 possible profiles:

Normal

Subscriber

The default profile is normal. In the “subscriber” profile there is no processing of 30

second buckets, in order to free up system resources for supporting VC statistics on up

to 400,000 VC‟s When working in a large deployment where many virtual channels are

expected to be opened (e.g: using SMP with templates for subscribers), Allot

recommends to work with the “subscriber” profile.

To change the reduction profile on the NE or SG (AOS):

To change the reduction profile on the NetEnforcer or Service Gateway:

1. Open an SSH connection to the NetEnforcer or CC-220 (on an

SG-Sigma or AC-10200)

2. Go to the configuration directory by typing the command: cd

$SWGC

3. You can see the available reduction profiles and the profile

currently configured to be used by using the command: ls -ltr

red*.

4. To change the active profile, use the command: go config

data_collect -st_reduction <profile>

5. When running ls -ltr red* you can see that reduction.conf now

points to the profile you chose.

For NE Not Running AOS Software

For a NetEnforcer running E, S or C software (AC-400, AC-800, AC-1000 or AC-

2500), there are 3 possible profiles:

Accuracy

Normal

History



The default profile is normal. In the Accuracy profile, more records can be included in

a bucket. If this profile is chosen, you must also choose an accuracy aging profile in the

STC and LTC which ensures that the bucket can be saved for less time. In the History

profiles, fewer records are included in the bucket. This means that the bucket can be

saved for longer. In this case you should choose a “history” aging profile in the STC

and LTC too.

To change the reduction profile on the NE (Non-AOS):

1. Open a telnet connection to the NetEnforcer and log in as user:

root with password: bagabu

2. Go to the configuration directory by typing the following

command:

cd $SWGC

Figure ‎5-1: Changing the Reduction Profile on the NetEnforcer (Non-AOS)

3. You can see the available reduction profiles and the profile

currently configured to be used by using the following command:

ls -ltr red*

4. To change the active profile, use the following command:

ln -sf <reduction profile name> reduction.conf

5. Running ls -ltr red* again you can see that reduction.conf now

points to a different profile.

6. After changing the configured profile you must restart the

statistics manger process.

To do so use the following command:

swgadmin -R StatisticMgr



If you run the command swgadmin -l before and after restart, you can see that

the number next to the StatisticMgr will have increased after restart.

Reduction Profile on STC

There are 6 different types of STC reduction profiles

ISP Accuracy

ISP Normal

ISP History

Enterprise Accuracy

Enterprise Normal

Enterprise History

The default NetXplorer profile is ISP Normal. The profiles determine the amount of

reduction which takes place on conversation records when 1hr buckets are imported

from the Short Term Collector to the Long Term Collector. In the History profiles, more

records are saved, while in the accuracy profiles, less buckets are saved.

To change the reduction profile on the STC:

1. Open a command prompt window

2. Go to <allot home directory>\bin (opt/allot/bin on a Linux server or a distributed

monitoring collector.)

3. Run the following command: reduction_profile_upd.bat This changes the configuration

for the reduction algorithm that runs on the STC server when transferring the 1hr

aggregated buckets from the short term collector to the long term collector.

• The available parameters to choose are:

• ent_accuracy

• ent_normal

• ent_history

• isp_accuracy

• isp_normal

• isp_history

• Note for reduction_profile_upd.bat there is no need for quotes around the profile name



4. After changing the profile you need to restart the NetXplorer Service. You can do so

from the services control panel (for Windows) or by entering service netxplorer start

(For Linux)

Aging Profile on STC and LTC

The aging profiles determine for how long data is maintained on the short term database

(whether it is on the NetXplorer or an external collector) and on the long term database.

There are 8 different types of aging profiles. The default NetXplorer profile is ISP

Normal. The table below shows the lengths of time for which different data resolutions

are stored for each profile, on both the STC and the LTC.

STC LTC

30 sec 5 min 1hr 1hr 1 day 1 mon

ISP

10k 15min 12 hours 12 hours 1 month 2 months 6 months

Accuracy 1 hour 24 hours 24 hours 1 month 2 months 6 months

Normal 2 hours 36 hours 36 hours 2 months 6 months 1 year

History 6 hours 48 hours 48 hours 4 months 1 year 1 year

Long Hours 0 48 hours 6 months 0 0 0

Enterp

rise

Accuracy 2 hours 24 hours 24 hours 2 months 6 months 1 year

Normal 4 hours 48 hours 48 hours 3 months 1 year 1 year

History 12 hours 96 hours 96 hours 6 months 2 years 2 years

Hours Months

Figure ‎5-2: Length of time for which data is stored under different profiles

WARNING: Changing the default reduction and aging profiles can impact the performance of your solution. Different aging and reduction profiles have been designed to suit particular setups. You should not change any of these profiles from their default value without first consulting with Allot Customer Support.

To change the again profile on the STC and LTC:

1. Open a command prompt window

2. Go to <allot home directory>\bin (opt/allot/bin on a Linux server

or a distributed monitoring collector.)



3. Run one of the following commands:

• stc_profile_upd.bat – changes data aging parameters in Short term

database

• ltc_profile_upd.bat – changes data aging parameters for the Long term

database.

4. For each one of the commands you should specify one of the

following parameters that describes the profile you wish to use:

• isp_10k

• isp_accuracy

• isp_normal

• isp_history

• isp_long_hours

• enterprise_accuracy

• enterprise_normal

• enterprise_history

NOTE For the commands stc_profile_upd.bat and ltc_profile_upd.bat the parameter should be in quotes („‟) while for reduction_profile_upd.bat there is no need for quotes.

5. After changing the profile you need to restart the NetXplorer

Service. You can do so from the services control panel.


Chapter 6: Command Line Interface (CLI)

The Server CLI described in this chapter enables you to modify the NetEnforcer,

Service Gateway or NetXplorer database from the command line rather than the GUI.

The CLI supplies a set of commands to add, change, rename and remove NetEnforcer or

Service Gateway entities, such as, Pipes, Virtual Channels or other Catalog entries and

change the configuration of the NetEnforcer or Service Gateway. You can also use the

CLI to set system parameters and device settings.

There are two types of NetXplorer Server CLI:

Provisioning CLI, which enables you to create traffic policies via

CLI without using the NetXplorer GUI

Monitoring CLI, which enables you to generate .csv based traffic

and subscriber network usage reports via CLI without using the NX

GUI

The Allot Command Line Interface is available in both Windows and Linux format.

When NetXplorer Server is installed on a Linux server, either format may be used.

However, if NetXplorer is installed on a server running Windows, only the Windows

CLI is available.

NOTE The computer used to send CLI commands to the NetXplorer or to NetEnforcer or Service Gateway devices must have Java installed and be included in the allowedHosts.properties.

Scripts

Scripts can contain CLI commands in order to automate the data entry process.

Provisioning CLI

To use the provisioning CLI in Windows:

1. Unzip the file \<VERSION NUMBER>\RnD\WSCli.zip on the

NetXplorer Software CD to a folder on the computer from which

you wish to access the statistics.

2. The newly created folder contains 4 batch files: topologyCLI.bat,

policyCLI.bat, catalogsCLI.bat and wuCLI.bat. Each of these

files needs to be edited. Open a .bat file using a text editor. Look

for the -Dserver parameter. It is set by default to the local host,

127.0.0.1. Change the value to the IP Address of the NetXplorer

Server you wish to work with.

3. The NetXplorer server must be configured to allow your computer

to use its web services. In the NetXplorer GUI go to the Servers

‎Chapter 6: Command Line Interface (CLI)


tab of the Network configuration screen and add the IP address of

computer you wish to use to access the CLI in the Allowed Hosts

list.

4. Open cmd and go to the folder to which you extracted the files,

run the batch files you require and enter CLI commands.

To use the provisioning CLI in Linux:

1. The NetXplorer server must be configured to allow your computer

to use its web services. In the NetXplorer GUI go to the Servers

tab of the Network configuration screen and add the IP address of

computer you wish to use to access the CLI in the Allowed Hosts

list.

2. Unzip the file \<VERSION NUMBER>\RnD\WSCli.zip on the

NetXplorer Server.

3. The newly created folder contains four .sh files: topologyCLI.sh,

policyCLI.sh, catalogsCLI.sh and wuCLI.sh.

4. From the NetXplorer client machine, telnet to the folder on the

server to which you extracted the files and enter CLI commands.

There are 4 types of provisioning CLI:

Topology CLI is used to add, import or remove NetEnforcer or Service

Gateway devices from the managed network.

Catalog CLI is used to create, delete or modify the catalogs used to build

traffic policies

Policy CLI is used to create lines, pipes and VCs (collectively known as

“tubes”) and to add and remove catalogs from them.

WU CLI is used to update the service catalog to the latest protocol pack and

roll-back if necessary.

Topology CLI

Topology CLI commands are used to add, import of remove NetEnforcers and Service

Gateways to the Network

The Topology CLI syntax on Windows is:

topologyCLI <action> <option> <value> [<value>] [<option> <value> [<value>]] …

The Topology CLI syntax on Linux is:

./topologyCLI.sh -<action> <option> -<value> [<value>] [<option> <value> [<value>]] …



The following actions are possible:

1. addDevice

2. importDevice

3. deleteDevice

4. help

Add Device

topologyCLI –addDevice

options:

o -uiName <value: name>

o -netAddress <value: ip>

o -password <value: password>

Import Device

topologyCLI –importDevice

options:

o -uiName <value: name>

o -netAddress <value: ip>

o -password <value: password>

Delete Device

topologyCLI –deleteDevice

options:

o -uiName <value: device name>

Catalog CLI

Catalog CLI is used to add, modify and delete catalogs

The Catalog CLI Syntax in Windows is:

catalogsCLI -<action> -<catalog> [<-option> <value>]

The Catalog CLI Syntax in Linux is:

./catalogsCLI.sh -<action> -<catalog> [<-option> <value>]

Catalogs

tos, dos, qos, vlan, alert, action, time, host, host group, service, service group,

service activation, VAS Chain, service plan

Actions

List All



catalogsCLI –list_all

No required arguments

Get catalog

catalogsCLI –get – catalog name

Required arguments:

o -name –existing name of the required catalog

Delete catalog

catalogsCLI –delete –catalog name

Required arguments:

o -name – existing name of the required catalog

Add catalog

catalogsCLI –add –catalog name

Required arguments:

o –name - existing name of the required catalog

Arguments:

o See Options for the specific catalog and global options.

Update catalog

catalogsCLI – update –catalog name

Required arguments:

o -name – existing catalog name

Arguments:

o See Options for the specific catalog and global options.

Options

Global

ARGUMENT NAME OPTION REMARKS

Name Catalog name

access_right Access right 0-read only

1-provisioned user

2-super user

3-super provisioned user




Admin Desirable source status 0-unknown

1-enabled

2-disabled

3–deleted

description Catalog description

DoS Catalog Arguments


max_connections Connections limitation

max_CER Connection establishment

rate limitation

violation_action Violation action 2 – drop

3 - reject

For example, to add a new DoS Catalog entry, use the following

command:

catalogsCLI -add -dos -name MY_DOS -max_cer 200 -violation_action DROP

Vlan Catalog Arguments


vlan_type Vlan type 0-Do not ignore

1-Ignore Vlan id

2-Ignore priority bits

3–Ignore Vlan id and

priority bits

vlan_tag Vlan value

For example, to list all VLAN catalogs, use the following command:

catalogsCLI -list_all –vlan

For example, to change the value of an existing VLAN catalog, use the following:

catalogsCLI -update –vlan –name vlan_name –tag 256

For example, to add a VLAN catalog called “vlan_name” with a VLAN tag of 128 and

set to ignore VLAN ID and priority bits, use the following command

catalogsCLI -add -vlan –name vlan_name – description “vlan description” –vlan_type 3 -tag 128



For example, to delete a VLAN catalog called vlan_name, use the

following command:

catalogsCLI -delete –vlan –name vlan_name

ToS Catalog Arguments


tos_type 0-Ignore Tos bytes

1-Differentiated services

2-Free format

tos_byte Tos value

For example, to delete a new ToS catalog entry, use the following

command:

catalogsCLI -add tos -name myTos -tos_type 1 -tos_byte 156

Alert Catalog Arguments


alert_type Event Name From

EVENT_DEF_CORE table

oid OID of the corresponding

MIB counter

From ALERT_COUNTER

table

is_alarm Alert is an alarm 0-not an alarm

1-is an alarm

mode Alert mode 0-regular

1-applies to every template

instance

severity 0-unknown

1-cleared

2-indeterminate

3-critical

4-major

5-minor

6-warning

relation 0-equal

1-greater

2-less

3-not equal

threshold Bad value

normal Normal value




register % time in the sample to

start the event (start barrier)

unregister % time in the sample to

stop the event(stop_barrier)

For example, to add a new Alert, use the following command:

catalogsCLI -add -alert -name "new-alert" –alert_type 1 -relation GREATER -is_alarm NOT_ALARM -mode REGULAR -normal 70 -register 90 -threshold 80 -unregister 50 -severity INDETERMINATE -oid "1.3.6.1.4.1.2603.5.5.5.0"

Qos Catalog Arguments


qos_type 1-ignore

2-each VC

3-both VC

4-each pipe

5-both pipe

6-half duplex pipe

7-each line

8-both line

9-half duplex line

10-PCMM

11-SDX

12 -ENH_EACH_VC

13 -ENH_BOTH_VC

14 -ENH_EACH_PIPE

15 - ENH_BOTH_PIPE

16 - ENH_EACH_LINE

17 - ENH_BOTH_LINE

18 - ENH_EACH_SLINE

19 - ENH_BOTH_SLINE

qos_action

direction 0-for both direction

1-for internal (outbound)

2-for external (inbound)

mode

is_reserved Minimum reserved

bandwidth on use

Only for pipe




min_bw

max_bw

min_bw_conn

max_bw_conn

mode 0-burst

1- CBR (constant bit rate)

delay if mode=CBR, then max

time in microsecond for

the package to be in the

system (box)

burst for all flows of this VC

bw_type bandwidth type measure 0-absolute value

1- percent from max

priority

For example, to add a new QoS entry, use the following command:

catalogsCLI -add -qos -name qosName -qos_type BOTH_LINE -qos_action ADMIT -qos_wire BOTH,4,0,0,false,0,0,0,BURST,false,0

For example, to add a new Enhanced QoS entry, use the following

command:

catalogsCLI -add -qos -name New_Enh_QoS1 -access_right 1 -admin 1 -qos_type ENH_BOTH_SLINE -qos_action ADMIT -exp_frw true -drop_prec 3 -qos_wire BOTH,4,0,0,false,0,0,0,BURST,false,0

Action Catalog Arguments


location Action source 0 –Application server

1-device

action_type action type 1-script

2-email

3-sms

4-stored procedure

actor Script, stored procedure

name ; e-mail address



For example, to add a new Action entry, use the following command:

catalogsCLI -add -action -name myAction -location 1 -action_type 2 -actor [email protected]

Host Catalog Arguments


host_type Host type 0 - regular (entries)

1 - data source (queries)

2 - NE for the compression

(entries)

device_id host device For common host – device

ID is null

add_entry New host-entries Syntax: TYPE:value[,…]

TYPE values are:

Name / ip_address / subnet

/ range /

Mac_address / all_address

remove_entry Entries to remove

For example, to change the value of an existing host catalog called testA, use the

following:

catalogsCLI -update –host –name testA -add_entry ip_address:1.1.1.1

For example, to add a new host catalog called testB, use the following:

catalogsCLI -add –host –name testB -add_entry ip_address:2.2.2.2

Host – Group Catalog Arguments


add_host Host list that will be added

to the host group

Syntax hostname[,…]

remove_host Host list that will be

removed from the host

group

File_path For External Data Source

For example, to remove existing hosts from a host group, use the

following:

catalogsCLI -update -host_group -name group1 -remove_host host1,host2 -add_host host3



Service Catalog Arguments


service_type Service type 0 - secondary service -

content definition

1-primary service - ports

characteristics

application An existing application

name

Null for all.

add_port Protocol:port_type:from-

port:[to-port] [,…]

Protocols

{TCP,UDP,IP,NON_IP}.

Port types:

{SIGNATURE,DEFAULT

,PORT_BASED}

remove_port

parent Parent service For service content only.

add_content_item For service content use.

Syntax:

content_key:content_value remove_content_item

For example, to add a port based citrix service, use the following

command:

catalogsCLI -add -service -service_type PRIMARY -name service1 -type 1 -application "Citrix ICA" -add_port TCP:PORT_BASED:1000:1000,UDP:DEFAULT:1100:1111

For example, to add a service content item for uploading 100BAO Peer to

peer traffic, use the following command:

catalogsCLI -add -service –service_type CONTENT -name "lilach by CLI" -description "added by CLI" -parent "100BAO" -add_item Direction:Upload

Service – Group Catalog Arguments


add_service service list that will be

added to the service group

Syntax service-name[,…]

Remove_service service list that will be

removed from the service

group

For example, to add a new Service Group, use the following command:



catalogsCLI -add -service_group -name mySG

Time Catalog Arguments


add_item Time items that will be

added time catalog

Syntax service-

TYPE:DAY[:TIME] [,…]

while Type is

{DAILY,WEEKLY,MON

THLY,ANUALLY}, DAY

is the day number in

week/month/year, Time

format: hh:mm-hh:mm

Remove_item Time items that will be

removed from the time

catatlog

For example to add a time catalog (called time_name), daily at 10-100am,

use the following command

catalogsCLI -add -time -name time_name -add_item DAILY:10:00-11:00,WEEKLY:2:10:00-11:00

Service Activation Catalog Arguments ARGUMENT

NAME OPTION REMARKS

service_act Catalog name Mandatory for all Service Activation

catalog items

service_type CAPTIVE_PORTAL,

INTEGRATED_SERVICE or

VAS

Mandatory for add/delete/update

actions

url Url Address Relevant for Service Type

CAPTIVE_PORTAL

noserver_act PASS, DROP Relevant for Service Type

CAPTIVE_PORTAL

rate_limit Rate limit Relevant for Service Type

INTEGRATED_SERVICE

tracking_interval Tracking interval Relevant for Service Type

INTEGRATED_SERVICE,

mandatory parameter on create

tracking_timeout Tracking timeout Relevant for Service Type

INTEGRATED_SERVICE,

mandatory parameter on create

num_redund_servers Number of redundant servers Relevant for Service Type

INTEGRATED_SERVICE



ARGUMENT NAME

OPTION REMARKS

add_servers For add servers on create item Relevant for Service Type

INTEGRATED_SERVICE and VAS

Server syntax for

INTEGRATED_SERVICE:

IP:3.3.3.3:VLAN_ID:1234

Delimiter between servers – “;”

Tracking interval and tracking

timeout are mandatory

parameters

Server syntax for VAS:

server name must be one word,

with no spaces

delimiters between server data -

"&"

delimiters between parameters -

","

The number of parameters is 21,

if a parameter is not defined use

"". The word “end” must always

appear at the end of the

parameters.

use "" also to set default system

value

It is recommended that servers

are added one-by-one after VAS

creation

delete_servers For delete servers on update

item

Relevant for Service Type

INTEGRATED_SERVICE and VAS.

Server syntax for VAS: delimeters

between server names - ";"

update_servers For update servers on update

item


INTEGRATED_SERVICE and VAS,

may be change only VLAN_ID not

the IP.



ARGUMENT NAME

OPTION REMARKS

load_bal_method HASH_BY_INTERNAL_IP,

HASH_BY_EXTERNAL_IP


INTEGRATED_SERVICE

tracking_interface MANAGEMENT,

IN_BAND


INTEGRATED_SERVICE

tracking_method NONE, PING, TCP_80,

HTTP_80


INTEGRATED_SERVICE and VAS

For VAS Service Type:

SERVICE_PROTECTOR

enable only NONE,

MEDIA_SWIFT enable all

except BFD

rate_limit NO_LIMIT,

BLOCK_SERVER


INTEGRATED_SERVICE

service_un_act DROP, BYPASS Relevant for Service Type

INTEGRATED_SERVICE

noserver_act BYPASS, DROP, REHASH Relevant for Service Type

INTEGRATED_SERVICE

description description Relevant for Service Type VAS

vas_service_type Service type Relevant for Service Type VAS,

Mandatory parameter – cannot be

changed on update

service_status Status of service Relevant for Service Type VAS

load_bal_method Load balancing method Relevant for Service Type VAS

noserver_act Server unavailable action Relevant for Service Type VAS

service_un_act Service unavailable action Relevant for Service Type VAS

tracking_retries Tracking retries Relevant for Service Type VAS

tracking_interval Tracking interval Relevant for Service Type VAS

srv_cap_reach_act Server capacity reached

action

Relevant for Service Type VAS

min_act_srvs Minimum active servers Relevant for Service Type VAS

flow_dir Flow direction Relevant for Service Type VAS

device_id Device name for private

scope


local_ip Local IP address Relevant for Service Type VAS



ARGUMENT NAME

OPTION REMARKS

vas_service_type GENERIC_REDIRECTION,

GENERIC_MIRRORING,

MEDIA_SWIFT,

SERVICE_PROTECTOR


service_status IN_ACTIVE, ACTIVE Relevant for Service Type VAS

load_bal_method HASH_BY_INTERNAL_IP,

HASH_BY_EXTERNAL_IP

, CYCLIC


noserver_act BYPASS, REDISPATCH,

BLOCK


service_un_act BYPASS, BLOCK Relevant for Service Type VAS

tracking_method NONE, BFD, PING,

SYN_80, HTTP_REQ


srv_cap_reach_act BYPASS, REDISPATCH,

BLOCK


flow_dir BOTH, CLIENT_SERVER,

SERVER_CLIENT


deployment INTERNAL,

EXTERNAL_SWITCHED,

EXTERNAL_DIRECT


For example, to add a new captive portal:

catalogsCLI -add -service_act -service_type CAPTIVE_PORTAL -name "CP1" -noserver_act PASS -url www.allot.com

For example, to delete a captive portal:

catalogsCLI -delete -service_act -service_type CAPTIVE_PORTAL -name "CP1"-update -service_act -service_type CAPTIVE_PORTAL -name "CP1" -noserver_action DROP -url allot1.com

For example, to add a new integrated service:

catalogsCLI -add -service_act -service_type INTEGRATED_SERVICE -name "IS123" -load_bal_method HASH_BY_INTERNAL_IP -service_un_act DROP -tracking_interface IN_BAND -tracking_method NONE -rate_limit 123 -noserver_act REHASH -tracking_interval 1 -tracking_timeout 10 -num_redund_servers 1 -add_servers IP:2.2.2.2:VLAN_ID:123;IP:3.3.3.3:VLAN_ID:1234

For example, to update server information on an integrated service:

http://www.allot.com/



-update -service_act -service_type INTEGRATED_SERVICE -name "IS2" -tracking_interval 1 -tracking_timeout 10 -update_servers IP:3.3.3.3:VLAN_ID:4321

For example, to add a new VAS (ServiceProtector):

catalogsCLI -add -service_act -service_type VAS -name VAS008 -description "vas test" -vas_service_type SERVICE_PROTECTOR -service_status ACTIVE -load_bal_method HASH_BY_INTERNAL_IP -noserver_act REDISPATCH -service_un_act BYPASS -tracking_method NONE -tracking_retries 3 -tracking_interval 1 -srv_cap_reach_act REDISPATCH -min_act_srvs 5 -flow_dir CLIENT_SERVER -local_ip 3.3.3.3 -device_id 72 -add_servers vas2-s2,ACTIVE,INTERNAL,,9,,,,,,,,0,0,0,0,2,4,5,0000000110000000,!&vas2-s1,ACTIVE,INTERNAL,,10,,,,,,22:22:22:22:22:22,11:22:22:22:44:43,0,0,0,0,3,6,7,0000000110000000,!

For example, to update a VAS entry:

catalogsCLI -update -service_act -service_type VAS -name VAS008 -description "vas test" -vas_service_type SERVICE_PROTECTOR -service_status ACTIVE -load_bal_method HASH_BY_INTERNAL_IP -noserver_act REDISPATCH -service_un_act BYPASS -tracking_method NONE -tracking_retries 3 -tracking_interval 1 -srv_cap_reach_act REDISPATCH -min_act_srvs 5 -flow_dir CLIENT_SERVER -update_servers vas2-s2,ACTIVE,INTERNAL,,12,,,,,,,,0,0,0,0,2,4,7,0000000110001000,!&vas2-s1,ACTIVE,INTERNAL,,13,,,,,,22:22:22:22:22:22,11:22:22:22:44:43,0,0,0,0,3,6,8,0010000110000000,!

VAS Chain Catalog Arguments


service_act_group Catalog name Mandatory for VAS Chain

catalog items

device_id Defines private device

scope

If defined, possible to add

only VAS members with

the same device private

scope.

add_members Add member – existing

VAS item by name

Syntax – delimiter between

items – “;”

reorder_members Sets order according to

order in command




delete_members Delete members item from

chain and not from catalog

For example, to add a new VAS chain:

catalogsCLI -add -service_act_group -name "VAS Chain" -description "first test" -device_id 72 -add_members VAS1;VAS2;VAS3

For example, to add a new member to an existing VAS chain:

catalogsCLI -update -service_act_group -name "VAS Chain Global2" -add_members VAS4



Service Plan Catalog Arguments


service_plan Catalog name Mandatory for Service

Plan catalog items

sp_type Service Plan Type TYPE_PIPE,TYPE_VC –

mandatory for new catalog

app_add, Syntax:

name:[],quota:[],next_sp:[],

cond:[],act:[]

Detailed:

name:[name],

quota:[quota1#quota2#…],

next_sp:[service plan],

cond:[Service]#[Service

Group]#[Time]#[TOS]#[VLAN],

act:[Access]#[Service

Activation]#[Service Activation

Group]#[DoS]#[QoS]#[ToS]

Relevant only for Pipe

Service Plan

Access values:

ACCEPT,DROP,REJECT

Name is mandatory

parameter.

Condition syntax Note:

only one [Service] or

[Service Group] may be

defined

Action syntax Note:

only one [Service

Activation] or [Service

Activation Group] may be

defined

Delimiter between

items into “quota”,

“cond” and “act”

parts is “#”

For names with

spaces use quotation

marks.

If some field is empty

– entry will be filled

with default value

defined be system.

app_del Syntax: name1,name2,… Relevant only for Pipe

Service Plan.

Existence of 1 application

is mandatory.




app_upd The same syntax as for

“app_add”

Relevant only for Pipe

Service Plan

If any field is empty on

update the previous value

will not be changed.

app_reord Syntax: name1,name2,… Relevant only for Pipe

Service Plan

data_add The same syntax as for

“app_add” but without name:

quota:[],next_sp:[],cond:[],act:[]

Relevant for Pipe and VC

Service Plan

data_upd The same syntax as for

“app_add” without name:

quota:[],next_sp:[],cond:[],act:[]

If any field is empty on

update the previous value

will not be changed

For example, to create a VC Service Plan with default parameters:

-add -service_plan -sp_type TYPE_VC -name TEST_SP_VC -description "first test"

For example, to create a Pipe Service Plan with one application:

-add -service_plan -sp_type TYPE_PIPE -name SP1 -description "first test" -data_add quota:"Test Quota Time"#"Test Quota Volume",next_sp:"TEST_SP_VC",cond:PService##PTime#PToS#PVLAN,act:DROP#VAS1##PDoS#PQoS#PToS -app_add name:123,quota:"Test Quota Time"#"Test Quota Volume",next_sp:"TEST_SP_VC",cond:PService##PTime#PToS#PVLAN,act:DROP#VAS1##PDoS#PQoS#PToS

For example, to add an application to an existing Service Plan:

-update -service_plan -name TEST_SP_PIPE -app_add name:123,quota:,next_sp:,cond:PService##PTime#PToS#PVLAN,act:DROP#VAS1##PDoS#PQoS#PToS

Policy CLI

Policy CLI commands are used to create or remove rules from the policy table. For the

purposes of Policy CLI, a line, pipe or VC rule is known as a “tube”. In addition, Policy

CLI is used to add pre-defined catalogs or alarms to these rules. For the purposes of

Policy CLI, a condition catalog is known as a “filter” and an action catalog is known as

an “action”



The Policy CLI Syntax on Windows is:

policyCLI <action> <option> <value> [<value>] [<option> <value> [<value>]] …

The Policy CLI Syntax on Linux is:

./policyCLI.sh -<action> <option> -<value> [<value>] [<option> <value> [<value>]] …

Actions

help, addTube, addFilter, addAlarm, listTube, listPolicy, deleteTube,

deleteFilter, deleteAlarm, updateTube

Options


tubeDeviceName Device Name Only active devices

tubeType Tube Type line, pipe, VC

tubeName Tube Name

tubeOffset Tube Offset (location) First filter is offset 0

tubeLineName Tube Line Name

tubePipeName Tube Pipe Name

tubeId Tube ID

tubeVcName Tube VC Name

tubePolicyId Policy ID Currently all options work with

active

filterId Filter ID

filterDirection Direction 0-Bi, 1-Int. to Ext.,2- Ext to Int

filterService Service ID

filterServiceGroup Service Group ID

filterExternalHost External Host ID




filterExternalHostGroup External Host Group ID

filterInternalHost Internal Host ID

filterInternalHostGroup Internal Host Group ID

filterTime Time Catalog ID

filterTos Filter Tos ID

filterVlan Vlan ID

actionQos Qos ID

actionDos Dos ID

actionTos Action Tos ID

actionAccess Action Access

actionId Action ID

Alarmed alarm ID

alarmActionId alarms‟ action ID

alarmAlertId Alarms‟ Alert ID

alarmParams Alarm Params

Add Tube

policyCLI – addTube

For example: To add a line called “newline” (12th in the list) to NetEnforcer 73, you

would use the following command:

policyCLI -addTube -tubeDeviceName 73 -tubeType line -tubeOffset 11 -tubeName newLine

Required Arguments:

o -tubeDeviceName Device Name



o -tubeType Tube Type (line, pipe, VC)

o -tubeName Tube Name (unique in its level)

o -tubeOffset Tube Offset (starting at 0)

o -tubeLineName required for pipe and VC only

o -tubePipeName required for VC only

Optional Arguments (if not specified, defaults apply):

o All filter options except filterId

o All action options except actionId

o All alarm options except alarmed

Add Filter

policyCLI - addFilter

Required Arguments:

o -tubeDeviceName

o -tubeType

o - tubeLineName

o - tubePipeName - Required for pipe and VC

o - tubeVcName – Required for VC only

Optional Arguments:

o All filter options except filterId

Add Alarm

policyCLI -addAlarm

Required Arguments:

o -tubeDeviceName

o -tubeType

o - tubeLineName



o - alarmActionId

o - alarmAlertId

Optional Arguments:

o alarmParams



List Tube

policyCLI -listTube

Required Arguments:

o -tubeDeviceName

o -tubeType

o - tubeLineName



List Policy

policyCLI -listPolicy

Required Arguments:

o -deviceId

Delete Tube/Filter/Alarm

PolicyCLI -deleteTube/-deleteFilter/-deleteAlarm

For example, to delete a VC called VV1 from the fallback pipe in the

fallback line of NE 73, you would use the following command:

policyCLI -deleteTube -tubeType vc -tubeDeviceName 73 -tubeLineName Fallback -tubePipeName Fallback -tubeVcName vv1

Required Arguments:

o -tubeDeviceName

o -tubeType

o - tubeLineName



o -filterId - For delete Filter only

o -alarmId - For delete Alarm only

Update Tube

policyCLI –updateTube

For example, to change the action catalog of the “newVc” VC on the

“newPipe” pipe on the “newline” line of NE 73 to a “Best Effort” ToS

catalog, enter the following



-updateTube -tubeDeviceName 73 -tubeType vc -tubeLineName newLine -tubePipeName newPipe -tubeVcName newVc -actionTos “Best Effort”

Required Arguments:

o -tubeDeviceName

o - tubeType

o - tubeLineName



o -filterId – If filter fields were modified

o -alarmId – if alarm fields were modified

Optional Arguments:

o tubeName

o All filter options

o All alarm options

All action options

Web Updates CLI

The Web Updates CLI Syntax in Windows is:

wuCLI <option> [<value>] [<option> <value> [<value>]] …

The Web Updates CLI Syntax in Linux is:

./wuCLI.sh -<option> [<value>] [-<option> <value> [<value>]] …

Device ID

wuCLI -deviceId

ID number of the device to be updated/rolled back

Update Server

wuCLI -updateServer

Updates the Service catalog of the NetXplorer Server

Update Device

wuCLI -updateDevice



Updates the Service Catalog of the selected device

Update Number

wuCLI -updateNumber

Selects the Protocol Pack to be used in the update.

For example, to update NE2 to protocol pack 2, use the following

wuCLI -updateDevice -deviceId 2 -updateNumber 2

Help

wuCLI -help

Provides usage and help information.

Rollback Server

wuCLI -rollbackServer

Rolls back the last update to the Services Catalog of the NetXplorer Server

Rollback Device

wuCLI -rollbackDevice

Rolls back the last update to the Services Catalog of the selected device

For example to rollback NE2 to the last update, use the following command:

wuCLI -rollbackDevice -deviceId 2

Monitoring CLI

The NetXplorer GUI may only display up to 50 items in a monitoring graph. Using

monitoring CLI, reports may be generated as CSV files that include hundreds or

thousands of items.

By using the Export to CLI function in the NetXplorer GUI, you can create a template

for the monitoring CLI command and then simply change the parameters later.

NOTE The computer used to send CLI commands to the NetXplorer or to NetEnforcer or Service Gateway devices must have Java installed and be included in the allowedHosts.properties.

To enable the monitoring CLI in Windows:

1. Unzip the file \<VERSION NUMBER>\RnD\monitorCLI.zip

on the NetXplorer Software CD to a folder on the computer from

which you wish to access the statistics.



2. In the newly created folder, open monitorCLI.bat with a text

editor and change the value of the parameter SERVER_URL to

the IP address or domain name of the NetXplorer server.

3. Open a DOS window, run monitorCli.bat and enter a command

requesting monitoring CLI command. The command is sent to the

NetXplorer server. Any monitoring data returned by the

NetXplorer server is stored in a .csv file.

The Monitoring CLI Syntax in Windows is:

monitorCLI <option> [<value>] [<option> <value> [<value>]] …

To enable the monitoring CLI in Linux:

1. Unzip the file \<VERSION NUMBER>\RnD\monitorCLI.zip

on the NetXplorer Server.

2. The newly created folder contains monitorCLI.sh.

3. From the NetXplorer client machine, telnet to the folder on the

server to which you extracted the file and enter CLI commands.

The Monitoring CLI Syntax in Linux is:

./monitorCLI.sh -<option> [<value>] [-<option> <value> [<value>]] …

Export to CLI

It is possible to create a monitoring CLI command by first creating the report definition

in the NetXplorer GUI and then generated a code string which may be edited and

entered into the CLI.

To export a graph definition to CLI:

1. Create a graph definition using the NetXplorer user interface

2. Right click on the graph and select Export to CLI from the drop

down menu.

3. The report definition is saved as a .txt file in whatever directory

you choose.

4. You may edit the file to alter the report definition.

For example if the graph shows the 10 most active Pipes, you can

edit the .text file so that the CLI command will generate a graph

showing the 100 most active Pipes simply by changing the value.

5. The file may now be used as input for the monitoring CLI



To run the file, open a Command Prompt and run the

monitoringCLI.

6. Use the –inputFile parameter to specify the path to the .txt file and

use the –outputFile parameter to specify the location and name of

the output (.CSV) file (as shown below).

NOTE This method is supported on servers running NX8.1.1 and later.



Monitoring Arguments


-dayDefinitionArray DayDefinitionList Day Definition List in UTC

used by Typical (50):

[Day(1-sun,2-mon,7-sat,0-

all),startHour0,endHour0,start

Hour1,endHour1,

,startHourn,endHourn]

[Day,startHour0,endHour0,star

tHour1,endHour1,startHourn,e

ndHourn]

-allSubjectsInScope Regular req All Subjects in

scope.

-inputFile <file> Input request file

-help Provides usage and help

information.

-longTermRequest Long Term Reporting.

-mostActive Most Active Request.

-relativeTimeUnit <relativeTimeId> Relative Time (default 1) :

[RelativeTimeUnit[Seconds=7],

RelativeTimeUnit[Minutes=6],

RelativeTimeUnit[Hours=1],

RelativeTimeUnit[Days=2],

RelativeTimeUnit[Weeks=3],

RelativeTimeUnit[Months=4],

RelativeTimeUnit[Years=5]]

-typicalType <TypicalTypeId> Request Typical Type :

[TypicalType [Day=1],

TypicalType[Week=2]]




-subject <subjectId> Request Subject (default 0) :

[SubjectType[Enterprise=0],

SubjectType[NetEnforcer=1],

SubjectType[Line=2],

SubjectType[Pipe=3],

SubjectType[Virtual

Channel=4],

SubjectType[Host=5],

SubjectType[Internal Host=6],

SubjectType[External

Host=7],

SubjectType[Protocol=8],

SubjectType[Conversation=9],

SubjectType[Subscriber=10]]

-time fromDate/Time

toDate/Time

Request Date & Time

{dd/MM/yyyy,HH:mm:ss}.

-relativeTimeCount relativeTimeCount Relative Time count (default 0)

: 1..50.

-allAsOne Regular req All as one.

-sortingCriteria <statisticId> Most Active req Sort Based On (default 1) :

[StatisticType[TotalBandwidth=1], StatisticType[BandwidthIn=2],

StatisticType[BandwidthOut=3], StatisticType[LiveConnections=4],

StatisticType[DroppedConnections=6],

StatisticType[NewConnections=5],

StatisticType[PacketsIn=7],

StatisticType[PacketsOut=8],

StatisticType[HostCount=9], StatisticType[BurstIn1=20],

StatisticType[BurstIn2=21],

StatisticType[BurstIn3=22], StatisticType[BurstIn4=23],

StatisticType[BurstIn5=24], StatisticType[BurstOut1=25],

StatisticType[BurstOut2=26],

StatisticType[BurstOut3=27], StatisticType[BurstOut4=28],

StatisticType[BurstOut5=29]]




-subjectCapacity <capacity> Most Active req Subject

capacity (default 5) : 1..50.

-distributor <distributorId> Most Active req Stack result by

element:

[DistributorType[NetEnforcer=

1], DistributorType[Line=2],

DistributorType[Pipe=3],

DistributorType[Virtual

Channel=4],

DistributorType[Host=5],

DistributorType[Protocol=6],

DistributorType[Subscriber=7]]

-outputFile <file> Output file result

-hostFilerArray <hostFilterList> Host Filter List(50): [hostIp or

hostName] ... [hostIp

or hostName]

-subjectArray <subjectDefinerList> Regular req Subject Definer

List Inluded in Graph(50) :

[NE,Line,Pipe,Vc]

[NE,Line,Pipe,Vc] or [hostIp or

hostName]

[hostIp or hostName] or

[serviceId]

[serviceId] or

[hostIpIn,hostIpOut]

[hostIpIn,hostIpOut]




-scopeLimiterType <ScopeLimiterId> Request Scope Limiter (Most

active default 0) :

[ScopeLimiterType[Enterprise

=0],

ScopeLimiterType[NetEnforce

r=1],

ScopeLimiterType[Line=2],

ScopeLimiterType[Pipe=3],

ScopeLimiterType[Virtual

Channel=4]]

-scopeLimiterArray

<ScopeLimiterList>

Scope Limiter List(50):

[NE,Line,Pipe,Vc] ...

[NE,Line,Pipe,Vc]

-isAllOthers Most Active req All Others

-splitter <splitterId> Most Active req Display

Separately for each element:

[SplitterType[Host=1],

SplitterType[Protocol=2],

SplitterType[Subscriber=7],

SplitterType[NetEnforcer=3],

SplitterType[Line=4],

SplitterType[Pipe=5],

SplitterType[Virtual Channel=6

]]

-resolution <resolutionId> Request Resolution (default 1) :

[AggregationResType[Level

0=1],

AggregationResType[Level

1=2],

AggregationResType[Hour=3],

AggregationResType[Day=4],

AggregationResType[Month=5

]]

-serviceFilerArray <serviceFilterList> Service Filter List(50):

[serviceId] [serviceId]




-adjustTime Adjust Time

Links Format

[NE,Line,Pipe,Vc] / [NE,Line,Pipe,Vc,Template] /

[NE,Line,Pipe,Vc,InstanceType,instanceValue]:

1) [NE,Line,Pipe,Vc] simple VC = 1,2,3,4 ; simple Line = 1,2,0,0

2) [NE,Line,Pipe,Vc,Template] VC Template = 1,2,3,4,T ; Pipe Template = 1,2,3,0,T

3) [NE,Line,Pipe,Vc,InstanceType,instanceValue] VC Instance = 1,2,3,4,2,9999 ; Pipe

Instance = 1,2,3,0,1,9999 [InstanceType[Pipe=1], InstanceType[Virtual Channel=2]]

Examples

5 Most Active NEs on Level0 resolution :

monitorCLI -mostActive -subject 1 -resolution 1 -time 22/11/2005,11:20:00

5 Most Active Hosts on Days resolution scope limited to NE #32 & #37 :

monitorCLI -mostActive -subject 5 -longTermRequest -resolution 4 –time 20/11/2005,00:00:00 23/11/2005,23:59:59 -scopeLimiterType 1 -scopeLimiterArray 32,0,0,0 37,0,0,0

10 Most Active VCs on Level0 resolution scope limited to NE #32 stack result by

Protocol

monitorCLI -subjectCapacity 10 -mostActive -subject 4 -resolution 1 -time 22/11/2005,11:20:00 22/11/2005,11:25:00 -scopeLimiterArray 32,0,0,0 -distributor 6

Statistics on NE #37, last 5Min on Level0 resolution :

monitorCLI -subject 1 -resolution 1 -time 22/11/2005,11:20:00 22/11/2005,11:25:00 -subjectArray 37,0,0,0

Pipes Distribution on Network, last 5Min on Level0 resolution :

monitorCLI -subject 3 -resolution 1 -time 22/11/2005,11:20:00 22/11/2005,11:25:00 -scopeLimiterType 0 -scopeLimiterArray 0,0,0,0

Statistics on VC Instance #37,1,1,1,2,42 last 5Min on Level0 resolution :

monitorCLI -subject 4 -resolution 1 -time 22/11/2005,11:20:00 -relativeTimeUnit 2 -subjectArray 37,1,1,1,2,42



Use regular monitor request file & create monitor result file (csv format) :

monitorCLI -inputFile c:\monitor_cli\monitor42060.req -outputFile c:\monitor_cli\monitor42060.csv

Use most active monitor request file & create monitor result file (csv format) :

monitorCLI -inputFile c:\monitor_cli\monitor42061.req -outputFile c:\monitor_cli\monitor42061.csv


Chapter 7: Troubleshooting

Troubleshooting Basics

First Steps

There are some basic checks to begin with when troubleshooting almost any type of

problem:

1. Validate that the NetXplorer server and relevant NetEnforcers or

Service Gateways are actually up and running.

2. NetXplorer components (GUI, Server and NetEnforcers/Service

Gateways) communicate with each other using the protocols and

ports listed on p 2-17. Validate that the communication is not

blocked by using the following command (on either the

NetXplorer or NetEnforcer/Service Gateway): netstat –an

3. Each one of the NetXplorer components has configured time

settings. It is crucial that the component times are synchronized.

Processes

NetXplorer

There are certain processes that should be running on the NetXplorer Server. These

processes can be identified using several different tools when using Windows:

1. Use Windows Services (Start > Control Panel > Administrative Tools >

Services) to check that NetXplorer Server is running

2. Use Windows Task Manager (CTRL+ALT+DEL and click Task Manager) to

check that the following processes are running:

• poller.exe, converter.exe and loader.exe

• ltc_poller.exe and ltc_loader.exe

• ltreducer (only appears periodically)

• manifest_manager.exe (only appears periodically)

• KeeperService.exe

• Dbsrv9.exe (3 instances)

• ntpd.exe

‎Chapter 7: Troubleshooting


When on a Linux based server, use the command ps –ef or ls to list running processes.


There are several processes that should always be running on the NetEnforcer or

Service Gateway. These processes can be identified using the following command: swgadmin

Each time a process is restarted, its value increases. If one of the values is significantly

higher than the others, it indicates that a process has been restarted. Restart may have

been initiated automatically or manually.

Log Files

Several key log files are stored on the NetXplorer Server. For the sake of convenience

we can divide these into three main categories.

Database Logs

Database log files are stored in C:\Allot\log (or /opt/allot/log on a Linux server). These

files log the performance of the NetXplorer‟s three main databases – cfg, stc and ltc as

well as the data collection processes.

Figure ‎7-1: Database Logs

The allot_cfg log can be consulted for problems related to general configuration (e.g:

saving policy, password). The allot_ltc log can be consulted for problems with long-

term reporting, and the allot_stc log for problems with real-time monitoring.

In addition, the logs which record the data collection processes are also useful,

specifically the Poller, Convertor and Loader logs. The keeper.log records the status

of the keeper process which makes sure that all other processes are up.



Figure ‎7-2: Key Database Logs

Application Server Logs

The application server log files are stored in C:\Allot\netxplorer\jboss-

5.1.0.GA\server\allot\log (or /opt/allot/netxplorer/jboss-5.1.0.GA/server/allot/log on

a Linux server). These files are responsible for logging all of the java-based activity

which takes place on the application server.

Figure ‎7-3: Application Server Logs

The events log records every event in the NetXplorer server. It can help you for

example to view alarms that have been cleared from the GUI.

The NMS.log records every activity carried out by the application server such as

records of alarms, GUI errors, web update checks, scheduled reports, and NetEnforcer

or Service Gateways which have been added or imported. As soon as this log reaches

5Mb, a new one is created, and a log history is maintained up to a total of 20 NMS logs.

The latest log is called simply NMS.log.



Figure ‎7-4: NMS.log Example

The NMS-Monitor.log records everything related to graphs and reports and the

UserOperations.log records of what has been done in the GUI by each user. This log

can reach a total of 10Mb and the NetXplorer will store 20 such historic logs in the

folder before over-writing the oldest one.

Installation Log

The install_log can be found in C:\Allot\conf (or /opt/allot/conf if you are working on

a Linux server). This simple log details the history of NX installations on the server.

You can see here for example if the current installation was an upgrade from a previous

version or a clean installation. This may be useful for detecting specific problems that

are related to upgraded NetXplorers only.

Figure ‎7-5: Install Log



Snapshots

Windows

This will prepare a zip-file that contains log and configuration files from all NetXplorer

components (Application Server, Collector, Databases) and the last backup of the CFG

(configuration allot_cfg) database.

Figure ‎7-6: Snapshot File

To create a snapshot in Windows:

1. Open MSDOS command window (cmd.exe). Run from command-

line - %ALLOT_HOME%\bin\ create_snapshot_logs.bat.

2. A message will appear in the command window indicating that the

snapshot was taken successfully and its location.

Zip-file - snapshot_<yyyy_mm_dd_hh_mi>.tar.gz will be located in

%ALLOT_HOME%\tmp directory.

Message Example –

Snapshot zip-file - D:\Allot\tmp\snapshot_2005_10_26_19_09.tar.gz is ready

To create a snapshot in Linux:

1. Open directory /opt/allot/bin/

2. Run the following command:

./create_snapshot_logs.sh



3. A message will appear in the command window indicating that the

snapshot was taken successfully and its location.

Message example -

Snapshot zip-file - /opt/allot/tmp/snapshot_2008_05_28_14_15.tar.gz is ready

How to restore CFG (allot_cfg) database from the Snapshot-File

1. Install the appropriate NetXplorer version from

<snapshot>\conf\install_log.txt file.

2. From the <snapshot>\conf\dynamic.ini file discover the CFG path.

3. After installation, reboot the computer and stop the NetXplorer

service.

4. Restore allot_cfg database using db_maint.exe from

%ALLOT_HOME%\bin directory using the following command

line operation:

db_maint -a restore -n cfg -t incremental -s <snapshot>\backup_cfg -g 1 -i

<max incr number(1-22)> -d %ALLOT_HOME%\data\db\cfg

5. <max incr number> - max number(1-22) in directory name from

<snapshot>\backup_cfg\1\incremental (example: 10)

6. Start the NetXplorer service

The NetXplorer server is now ready to work with snapshot allot_cfg database

Login Errors

Login errors can occur for several reasons:

Incorrect Java Version

An error messages stating that netxplorer.jnlp is an unrecognized file extension

typically indicates that the correct version of JRE has not been installed. Where JRE

1.5.6 or higher has not been installed, the java “.jnlp” extension is not registered to any

application.

• If the root cause of the issue is with Java, you can often solve it by clearing the

Java Cache on the machine that cannot access the NetXplorer, and then

reinstalling JRE.

• Go to control panel and choose Java.



• On the General tab, under Temporary Internet Files, click on delete and then

OK.

This action will clear the java cache files. It will also remove the NetXplorer

shortcut from the desktop.

• Open browser with NX server IP address (http://<NXServer-IP>) and choose the

first option “Install Java JRE First”. Now launch the application.

If the previous method does not solve the problem, run Java WebStart - javaws.exe from

the Java 1.5 environment.

This will typically be located at a location similar to: C:\Program

Files\Java\jre1.5.0_06\bin.

Delete anything shown on this screen (this will clear the cache).

Lack of Connectivity

A common cause of GUI initialization problems is a lack of communication between

the GUI and the NetXplorer, that is there is something on the network which may be

blocking the traffic (HTTP port 80).

• Below is a table of the TCP ports required for communication between the client

and server.

• Validate that there is nothing blocking communication on these ports and that all

the required NetXplorer services are running.

PORT # DESCRIPTION

TCP:80 HTTP

TCP:1098 RMI (Java J2EE protocol)

TCP:4446 RMI (Java J2EE protocol)

TCP:4457 Alarms

TCP:1099 JNP (Java J2EE protocol)

TCP:50010 Alarms

TCP:443 SSL



Antivirus Conflict

Antivirus or backup utilities could be interfering with the database, locking the file and

not permitting changes to it. Antivirus and backup utilities can also cause many other

types of problems for any operation involving a database modification.

It is highly recommended NOT to run antivirus or backup programs on folders where

the databases reside. The database folder is usually located in:

C:\Allot\data\dc\<DatabaseName>

Policy Saving Errors

Typically, inability to save a policy can result from a communication problem between

the GUI and the server, a communication problem between the NetEnforcer or Service

Gateway and the server or a synchronization problem between the NetEnforcer or

Service Gateway and the NetXplorer server.

To troubleshoot this problem, you must first understand how the provisioning data is

updated in the system.

The process consists of 3 stages.

First of all, the NetXplorer server sends an XML command to the NetEnforcer

or Service Gateway

The NetEnforcer or Service Gateway then performs the required changes and

updates the counters.

Finally, the NetEnforcer or Service Gateway sends a trap back to the server.

If the server has successfully sent the XML, the request should be received by the

DataSrv on the NetEnforcer or Service Gateway. The DataSrv should acknowledge

receipt, apply the change and confirm.

We can therefore check if the second stage has been passed, by examining the DataSrv

log file to see if the request has been received by looking at the following log file:

$SWGL/nedbg.DataSrv.log

Having confirmed this, we should look at allotProvision.xml. This is the actual policy

configuration file on the NetEnforcer or Service Gateway. By analyzing this file, we can

verify that the changes have actually been written.

If there is a synchronization problem between the NetXplorer and the NetEnforcer or

Service Gateway, perhaps caused by a temporary loss of communication between the

two, a tool that can help solve the problem is to perform a full policy export.

Using the Restore Policy and Catalog feature it is possible to restore the saved image

of the Policy Table and catalogs which is stored for each NetEnforcer or Service

Gateway and updated periodically. This feature should be used if a NetEnforcer or

Service Gateway becomes corrupted or its policies and catalogs become damaged,

requiring a roll back to a previous, working configuration.



To restore policies and catalogs:

1. Select Restore Policy and Catalogs from the Tools menu.

The Restore Policy and Catalogs dialog is displayed.

Figure ‎7-7: Restore Policy and Catalogs Dialog

2. The NetEnforcer Devices list will populate with all NetEnforcers

or Service Gateways on the network. Each relevant NetEnforcer

or Service Gateway is listed by name, with the time it received the

new policies and any system messages.

3. Click the Restore checkbox to include that NetEnforcer or

Service Gateway in the restoration or select a NetEnforcer or

Service Gateway and use the Check and Uncheck buttons.

4. Select a NetEnforcer or Service Gateway and click Up or Down

to change its location in the distribution order.

5. Select a NetEnforcer or Service Gateway and click Remove to

delete the NetEnforcer or Service Gateway from the list or Clear

Messages to delete any system messages.

6. Select the Abort on First Error checkbox to instruct NetXplorer

to cancel the entire Policy Distribution operation on the first error.

7. Click Restore to restore the saved Policy table and catalogs to

each device. The NetEnforcers or Service Gateways selected will

be restored in order, starting at the top of the list.

8. Click Abort at any time to stop the process or Print to print the

Results list.

NOTE Aborting the restoration will not roll back the Policy Tables or Catalogs of any NetEnforcers or Service Gateways already overwritten.

9. Click Close to close the Restore Policy and Catalogs dialog box.



Data Display Errors

When there is no data in a graph for a certain period of time, this typically indicates a

problem with data collection.

Data Transmission Check whether the NetEnforcer or Service Gateway is sending statistics

buckets to the NetXplorer server.

Data Reception It could be that buckets are being sent, but because of communication

problems, they are not reaching their destination.

Data Loss It could be that buckets are sent to the server and received, but are subsequently

dropped.

A common reason for this is a lack of synchronization. If the time of the bucket

is dramatically different from that of the NetXplorer server time, then buckets

will be discarded.

Stress Alternatively, the problem could be one of “stress”. If there is more data than

the NetXplorer server can handle, the server will only handle buckets that have

already been received and will discard any new buckets.

Data Transmission

As the first step of our troubleshooting we do not need to leave the NX GUI. Using the

GUI, we examine the event and alarms logs.

In most cases there will be an alert that shows us where the problem lies.

Figure ‎7-8: Events Log



For example, if we see the event: “Collector Reported Device Unreachable”, this

indicates that the data collector cannot access the NetEnforcer or Service Gateway for

short term data collection. In this case, you should check network connectivity, possible

firewall and ACL (access control list) rules.

If we see the event: “Invalid Bucket Time on Collector”, this indicates that the time on

the NetEnforcer or Service Gateway and on the NetXplorer Data Collector is not

synchronized. Make sure you synchronize the time for the NetEnforcer or Service

Gateway, Data Collector and NetXplorer. (See the “Time Synchronization Issues”

module for further information)

The event “Real Time Bucket Overload in Collector” indicates a problem of stress.

Data Reception

It could be that buckets are not being sent from the NetEnforcer or Service Gateway in

the first place.

This can be checked by consulting the manifest of a specific NetEnforcer or Service

Gateway.

The Manifest is the list of buckets that the NetEnforcer or Service Gateway has created

and that are waiting to be sent to the NetXplorer. This can be accessed using any web

browser.

Figure ‎7-9: Bucket Manifest

To see the 30 seconds buckets waiting to be sent, enter:

http://<NE_IP>/bucket/30/manifest

To see the 300 seconds buckets waiting to be sent, enter:

http://<NE_IP>/bucket/300/manifest

Refresh the browser window a few times to check that the NetEnforcer or Service

Gateway is continuously creating buckets.



Data Loss

To confirm that the data, once received, is not being dropped, check the log files that are

created by the data collection processes and are located on the NetXplorer server. Here

we can check if the NetXplorer and/or distributed collector has received the collected

data. The poller process is responsible for polling the buckets from the manifest file on

the NetEnforcer or Service Gateway. This process is logged in the poller log.

Figure ‎7-10: Data Logs

The convertor process then converts the buckets from binary into ASCII form – this is

logged in the convertor log.

Finally, the loader process, logged in the loader log is responsible for loading the

converted buckets into the short term database.

The Ltc_poller polls the 1hour buckets from the short term collector and the Ltc_loader

loads them into the long term collector.

You can look in the log files and see if there are any error indications.

Stress

What should you do if the events suggest a situation where buckets are being dropped

due to excess stress? Firstly, check the Collection Configuration to validate that the

NetEnforcer or Service Gateway is actually configured to collect the data you expect to

see.

One thing you can do to reduce stress is to disable real-time data collection. This will

lower the number of buckets dramatically.



Disabling Real-Time Collection stops the import of 30 sec buckets from the

NetEnforcer or Service Gateway to the NetXplorer. Therefore you will not be

able to see real-time monitoring graphs at 30 sec resolution. You will still be

able to see real-time monitoring graphs at other resolutions though, and long

term reporting which relies on the 300 sec buckets is not affected at all.

Disabling Long-Term Collection stops the import of 1 hr buckets from the

short term database on the NX to its Long Term database. By disabling this

option, you will not be able to view long-term reports at all.

Short Term Collection refers to the 300 seconds, or 5 minutes, buckets. What

happened when you disable Short Term collecting depends on whether Long

Term collecting is enabled or not. If Long Term Collection is also disabled, the

only graphs that you will be able to see are real-time graphs at 30 sec

resolution. If Long Term collection is enabled, short term data (300 sec

buckets) will be imported to the NX regardless of the state selected in the short

term collection dialog. This is because Long term data is aggregated from the

300 sec buckets.

Add Device Errors

In some situations, the attempt to add a device to the NetXplorer may fail. What might

be the reasons for this failure?

The more obvious reasons could be down to an incorrect IP address or an incompatible

software version.

There may be communication problems between NetXplorer and the NetEnforcer or

Service Gateway. These might arise due to problems with a firewall or with a router

access list for example. Alternatively, this problem can arise when management traffic

and user traffic are not fully separated.

By consulting with the NX server log (NMS.log), you can see at exactly which stage,

the “add device” process failed. There are eleven stages to adding a device.

You can see which stage has succeeded and which has failed by looking at the

NetXplorer‟s NMS.log.

There are thirteen stages to adding a NetEnforcer or Service Protector. To start tracking

the add device messages in the log file, look for the string: “CREATE (1/13)” or for the

string “create device”

In stages one and two of the add device process, NetXplorer prepares its database

tables for the new device topology. Normally you should not encounter problems

at these stages.

In stage three, the NetXplorer validates that the device has a software version that

matches that version on the NetXplorer Server. If there are error messages here

you might need to upgrade the device software version.



At stage four, the NetXplorer reads the NetEnforcer or Service Gateway‟s

configuration file: rc.conf. The file is sent via SNMP on port 161. Issues can

occur when there is a communication problem, or if the SNMP agent is not

running on the NetEnforcer or Service Gateway. If there is a problem at this

stage, check the following:

• Run netstat -an on the NetEnforcer or Service Gateway or Server and

check whether a connection on port 161 is established

• Run swgadmin and validate that allSNMPagent is running

• Check that nothing is blocking SNMP traffic along the way

• Check that the database is up and available

At stage five the catalogs are sent from the NetXplorer to the NetEnforcer or

Service Gateway. There are a few things that can go wrong at this stage:

• Communication issues – communication is carried out on HTTP port 80.

An error can occur if communication is blocked or if the NetEnforcer or

Service Gateway is not listening for requests on port 80. To validate that

NetEnforcer or Service Gateway is running the HTTP daemon, run ps –

awx and look for HTTPD

• Incorrect password – this happens when the password for the admin user

that was supplied in the “Add Device” dialog is not the right password. If

you have forgotten the password you can change the password by

logging into the NetEnforcer or Service Gateway as “root” and using the

menu>change password option.

During stage 6, the default policy is exported to the NetEnforcer or Service

Gateway by HTTP over port 80. The process could fail at this stage if there is a

timeout issue. This can be verified by looking at the nms.log. If this is the case,

you will need to contact Allot support for a fix.

At stage 7, the server performs several updates, one of which is updating NTP.

Issues can occur when the NetEnforcer or Service Gateway is set up in a way that

management traffic flows through the NetEnforcer or Service Gateway. This

happens when the management port is connected to the same part of the network

as the external connection is. In such cases, an NTP update can occur before the

NetEnforcer or Service Gateway update is complete. This interrupts the update

process.

A possible solution can be to switch the NetEnforcer into bypass mode until the

addition process is complete. In any case, it is recommended to connect the

management port to the internal section of the network.



During the stages 8-10, the NetXplorer updates its databases. A problem at this

stage could result from the unavailability of one of the databases. In this case, try

to stop and restart the NetXplorer service. This may kick-start the unavailable

database. If this does not work, you may have to recreate the database that is

unavailable.

During stage 11, dynamic hosts are added to the NetEnforcer or Service Gateway

In stage 12, WebSafe parameters, which were set up in the Integrated Services

Tab in the NetXplorer GUI are distributed.

In the final stage of the process, Stage 13, WebSafe blacklist files are updated in

the NetEnforcer or Service Gateway from their destination as defined in the

Integrated Services Tab in the NetXplorer GUI.

Adding a new collector has only 6 steps. These can be found in the server‟s NMS log by

looking for the string “CREATE (1/6)” or “create collector”.

The process of importing a device has 16 steps and the relevant messages can be found by

looking for “IMPORT (1/16)”

NX-HAP Troubleshooting

Monitoring the Cluster Status

cl_status is a linux command that retrieves information about the status of the

NetXplorer High Availability Cluster. For a full list of the cl_status commands, simply

enter cl_status.

We can check the node status by entering cl_status nodestatus <node name>.

NX-1.allot.com:~$ cl_status nodestatus NX-1.allot.com

cl_status: 2008/09/09_09:45:26 debug: optind: 1

argv[optindex+1]: NX-1.allot.com

active

NX-1.allot.com:~$ cl_status nodestatus NX-2.allot.com

cl_status: 2008/09/09_09:45:43 debug: optind: 1

argv[optindex+1]: NX-2.allot.com

active



In the example above, the nodes are named NX-1.allot.com and NX-2.allot.com. The

cl_status nodestatus command is run for each node in turn. An output of “active” (for

both nodes) indicates that the NX High Availability Cluster is alive.

The heartbeat program is at the core of the High Availability platform. It is responsible

for detecting the different nodes, communicating between them and managing the

cluster.

cl_status hbstatus tells us if heartbeat is running on the local system. The command

cl_status hblinkstatus <node name><link name> displays the status of a heartbeat

link. This indicates up if we are able to hear from that node across that link.

NX-1.allot.com:~$ cl_status hbstatus

Heartbeat is running on this machine.

NX-1.allot.com:~$ cl_status hblinkstatus NX-2.allot.com eth2

up

NOTE If the <node-name> is the current node, the status is not meaningful, since with few exceptions we don't receive messages from ourselves on any links. Make sure that you use this command to check the status of the peer node in the cluster.

NX-1.allot.com:~$ cl_status hblinkstatus NX-1.allot.com eth2

dead

WARNING: Be aware that database corruption is caused when both NX nodes are active at

the same time. In a normal situation one node should be active (connected to

storage with both heartbeat and netxplorer services running) while the second

node should be passive (connected to storage with the heartbeat service running,

and the netxplorer service stopped)

Viewing Available Resources

The crm_mon command can be used to analyze which node in the cluster is using

system resources. This tells the system administrator which node is currently active.

==============

Last updated: Mon Jun 1 19:24:44 2009

Current DC: NX-1.allot.com (l3425fesfth)

2 Nodes configured.



1 Resources configured.

Node: NX-1.allot.com (l3425fesfth): online

Node: NX-2.allot.com (fewf834271h): online

Resource Group: nx_ha

vip (ocf::heartbeat:IPaddr2): started NX-1.allot.com

db (ocf::heartbeat:Filesystem): started NX-1.allot.com

nx (lsb:netxplorer): started NX-1.allot.com

The output of this command shows us that there are two nodes in the cluster and that

both are on-line. The Resource Group, nx-ha consists of 3 sub-resources:

VIP: which is the virtual IP address of the cluster

db: which is the database

nx: which is the NetXplorer service

Adjacent to each of these sub-resources you will see on which node it is running. In this

case, we see clearly that NX-1.allot.com is the active node in the cluster.

In case problems are detected, the administrator may run crm –rf. This gives an

extended view of the cluster resources and includes fail messages for each of the nodes.

Stopping Heartbeat Service

To stop the heartbeat service on the currently active node, opening an SSH session to

this node and enter the command: service heartbeat stop

This will stop the cluster suite running on the currently active node and the second node

will take control of the resources.


Chapter 8: Appendices

Appendix A - Comprehensive Upgrade Procedure

Allot management solutions may comprise of many interlocking components which

need to be upgraded together (e.g: NX and SMP). Upgrading the Allot system may

require the administrator to upgrade several elements in turn.

Upgrade Master-plan

Allot recommends that all management upgrades follow the upgrade master-plan, in the

order detailed below. The table below outlines the master-plan for upgrading a

deployment which includes NX (standalone or HAP), one or more SMPs (standalone or

HAP), one or more STCs, plus other optional elements such as NetXplorer Accounting

and NetPolicy Provisioner.

STAGE AIM TYPICAL TIME

NOTES

1 Back Up All SMPs 15 mins

(per SMP)

If SMP is deployed

2 Back Up NetXplorer 15mins - 2

hours

Longer time is required for

backing up LT database. If

LT backup required, verify

enough disk space is

available

3 Upgrade NetXplorer 1hr – 2hrs Time depends on size of

databases and if upgrading

NX-HAP. Separate

procedure for NX and NX-

HAP

4 Stop NetXplorer Service 15 mins Necessary if additional

elements beside NX are to

be upgraded (e.g: SMP,

STC, NPP)

5 Upgrade All Collectors 30 mins

per

collector

If deployed. Can be

performed simultaneously to

save time.

6 Upgrade Additional Deployed

Services (e.g: Accounting / NPP)

30 mins

per

service

If deployed. Can be

performed simultaneously to

save time.

‎Chapter 8: Appendices


7 Upgrade All SMPs 30 mins –

1hr

If deployed. Time depends

on whether upgrading SMP-

HAP. Separate procedure for

SMP and SMP-HAP

8 Start NetXplorer Service 20 mins Necessary if NX service was

stopped in 4 above

9 Verify Normal Operation 30 mins –

1hr

Time required depends if

working with HAPs

NOTE: The approximate times shown in the table above give a very rough

guideline only. Actual upgrade times may be significantly different,

depending on the specific circumstances

A typical upgrade may not include all of the components detailed above. Consequently,

different tracks can be planned through this master-plan depending on the equipment

which needs to be upgraded. For example:

For upgrading NX only follow stages 23 9

For upgrading NX and STC only: Stages 234589

For upgrading NX and SMP only: Stages 1234789

Make sure you have all root user passwords before the upgrade process starts.

Upgrade Stage 1: Backup All SMPs

If SMP is deployed together with the NetXplorer installation, you will need to first

backup the SMP database to an external disk. To back up the SMP database, follow the

instructions below:

1. Open an SSH session as super-user to the SMP server (or to SMP-0 if working

with an SMP-HAP)

2. To backup the database for this machine, run the command

/opt/allot/bin/db_maint_sudo.sh –a backup –n smf –t full

SMP-22:~# /opt/allot/bin/db_maint_sudo.sh -a backup -n smf -

t full database name is allot_smf

full backup performed

generation number: 1

serial number: 0

backup completed successfully



NOTE: “generation number: 1” in the output above means that the smf database

has been copied into directory “1” at this location:

/opt/sybase/data/backup/smf/1/full/

3. Copy the two database files below to an external disk:

a. allot_smf.log

b. allot_smf.db

In addition, to back up the configuration, copy the following files to an external

folder:

/etc/rc.d/*

/opt/allot/conf/*

/opt/allot/radius/etc/raddb/* (if working with Radius mode)

/opt/allot/diameter/config/* ( if working with PCC mode)

/etc/hosts

/opt/allot/bin/active_standby_node_status.sh( if working with PCC mode)

4. Repeat steps 1-4 above for all deployed SMP servers

NOTE: When working with SMP-HAP, copy these files for each node, and store

the files for each node separately

Upgrade Stage 2: Backup NetXplorer

Allot strongly recommends to perform a backup of the NetXplorer databases before

proceeding.

When working with Windows or Linux based standalone NetXplorer

servers, Allot recommends performing a cold backup of the

NetXplorer databases.

When working with NX-HAP, Allot recommends performing a hot

backup of the NetXplorer databases

The procedure for performing a cold backup on a Windows based NetXplorer is

outlined in Database Management on Windows on page 5-2 above.

The procedure for performing a cold backup on a Linux based NetXplorer is outlined in

Database Management on Linux on page 5-16 above.

The procedure for performing a hot backup (for NX-HAP) is outlined in Database

Management on Linux on page 5-17 above.

NOTE: The files which you have backed up should not be stored in the /opt

directory. In case you need to uninstall the software, this directory will

be deleted.



Upgrade Stage 3: Upgrade NetXplorer

Once the new NetXplorer software version has been released for general availability

you can download it from the Allot FTP site.

The software for the Windows based NetXplorer server, and for the Linux based

NetXplorer server (including the high availability software if required) can be

downloaded from: ftp://ftp.allot.com/MNG_server/NX/GA

After completing the download of the files you can verify the files are complete and

intact by checking the MD5 checksum.

NetXplorer Standalone (Linux Based)

To upgrade a standalone Linux based NetXplorer server, follow the instructions below.

1. Stop the NetXplorer service by entering: service netxplorer stop

2. Upgrade the JDK to the most recent version with no dependencies

by entering the following command: rpm -U <JDK filename> -–

nodeps

NOTE There are two „-„ before the last parameter!

NOTE You must use the exact JDK name, including the correct update number e.g: rpm –U jdk-6u20-linux-i586.rpm --nodeps

3. When upgrading the NetXplorer software you must use the U

option to upgrade the software. Therefore, the proper command to

use when upgrading is as follows: rpm -Uvh <filename>.rpm

Example: rpm –Uvh netxplorer-11.1.0-6.i386.rpm

NOTE You may discover the name of the NetXplorer installation package by entering the following command: rpm -qa netxplorer

NetXplorer Standalone (Windows Based)

To upgrade a standalone Windows based NetXplorer server, follow the instructions

below.

NOTE The installation folder should be copied to a local drive on the NetXplorer server and not run from a remote location

1. Double click on the setup.exe file.


2. Follow the onscreen instructions in the Setup Wizard to upgrade

the NetXplorer Server.

ftp://ftp.allot.com/MNG_server/NX/GA




NetXplorer High Availability Platform (Linux Based)

Follow the procedure below to upgrade the NX High Availability Platform.

NOTE All of the operations outlined below must be performed by a root user.

1. Stop the HA monitoring on both NX nodes. This is done by using

command: service heartbeat stop

2. On NX-1 node, mount the common disk storage. This is done by

using the command: mount /dev/dm-1 /opt/sybase/data

3. Upgrade the NX-1 node as you would upgrade a regular

NetXplorer Server. The upgrade steps (for a Linux Server) are

outlined below:

a. Check that netxplorer server is stopped by entering: service netxplorer

status. In case netxplorer service is running stop the service by entering:


b. Update the JDK by entering the following: rpm -U <JDK

filename>.rpm --nodeps

NOTE There are two „-„ before the last parameter!

NOTE You must use the exact JDK name, including the correct update number e.g: rpm –U jdk-6u20-linux-i586.rpm --nodeps

c. Update the NetXplorer software by entering the following: rpm -U

<filename>.rpm

d. Do NOT reboot the server once the upgrade is completed.

4. Now upgrade the NX-2 node as in step 3 above. The local

databases will be updated here too, simply to ensure consistency

of the upgrade process.

5. Enter the following command on both NetXplorer nodes: chown

hacluster:haclient /var/lib/heartbeat/crm/*

6. Reboot NX-1 by logging into NX-1 and entering the command

reboot. Wait until you see that the NetXplorer service is up. You

can check whether the service is up by entering crm_mon

Resource Group: nx_ha

vip (ocf::heartbeat:IPaddr2): Started nx1.allot.com



db (ocf::heartbeat:Filesystem): Started nx1.allot.com

nx (lsb:netxplorer): Started nx1.allot.com

WARNING Do not reboot NX-2 until the NetXplorer service in NX-1 is up!

7. Reboot NX-2 by logging into NX-2 and entering the command

reboot

8. After rebooting check the status of each NX node. Use command

– crm_mon. This will reveal which node is active and will detail

the status of the common storage status

Upgrade Stage 4: Stop NetXplorer Service

To stop the NetXplorer service follow the instructions below, which differ depending on

whether you are working with a Windows based NetXplorer server or a Linux based

NetXplorer server and whether or not you are working with a NetXplorer High

Availability Platform.

NetXplorer Standalone (Windows Based) 1. Click Start on the Windows Task Bar and select Settings > Control Panel


3. Right-click NetXplorer in the list of Services and select Stop from the drop-

down menu

NetXplorer Standalone (Linux Based) 1. Start an SSH session to the NetXplorer server.

2. Enter: service netxplorer stop

NetXplorer High Availability Platform (Linux Based) 1. Start an SSH session to the passive NetXplorer server

2. Enter service heartbeat stop and wait for the command output to issue an ok

message

3. Now start an SSH session to the active NetXplorer server

4. Enter service heartbeat stop and wait for the command output to issue an ok

message.

WARNING: After entering the command, wait until you receive

an “OK” message. This may take several minutes.

Even after receiving the “OK”, this does not

necessarily mean that the heartbeat process has

stopped. The heartbeat process may take up to 15

minutes to stop each time. You are advised to wait

15 minutes before proceeding. You can check that

heartbeat is stopped by entering: ps -ef | grep



heartbeat | grep –v grep. If the heartbeat process

has stopped, the output of this command will be

empty. In case there are still NetXplorer processes

running, contact [email protected] and do not

continue with the upgrade.

Upgrade Stage 5: Upgrade All Collectors

Follow the procedure below to upgrade each Distributed Collector (DC).

1. Login to the DC using username admin, password allot

2. Create a folder on the DC in which the target software version will be stored.

For example: /opt/admin/MD11.1

3. Once the new distributed collector software version has been released for

general availability you can download it from the Allot FTP site:

ftp://ftp.allot.com/MNG_server/MD/GA/

4. Download the two files below for the target software version to the folder

created.

a. md-11.1.1-4.tgz

b. md-inst.sh

NOTE: The exact name of the tgz file will change per software version.

5. Change directory to the directory in which the installation files are stored – e.g:

/root/MD11.1

6. Change md-inst to executable by entering: chmod +x md-inst.sh

7. Perform the upgrade by entering: ./md-inst.sh

8. After the upgrade has been successfully completed, you will be requested to

reboot the system. Choose “y” to reboot.





Upgrade Stage 6: Upgrade Additional Services

Upgrading NetXplorer Accounting

NetXplorer Accounting cannot be upgraded directly. The old version must be

uninstalled and the new version of Accounting may then be installed.

On a Linux Accounting Server:

1. Download the NetXplorer software files as described on on page

8-4 above. The file you require is prefixed accounting-manager

2. When upgrading the NetXplorer Accounting software you must

use the U option to upgrade the software. Therefore, the proper

command to use when upgrading is as follows: rpm -Uvh <filename>.rpm

Example:

rpm –Uvh accounting-manager-11.1.0-6.i386.rpm

NOTE You may discover the name of the NetAccounting installation package by entering the following command: rpm -qa accounting-manager

3. After the upgrade finishes, inform the accounting server of the

NetXplorer IP address by running


On a Windows Accounting Server

NOTE NetXplorer Accounting cannot be upgraded directly on a Windows server. The old version must be uninstalled and the new version of Accounting may then be installed.

1. Uninstall the current NetXplorer Accounting installation.

2. Open the ACCT folder in the NetXplorer Upgrade package

3. Double click setup.exe in the ACCT folder.



NetXplorer Accounting.



Upgrading NPP

On a Linux NPP Server:

1. Download the NetXplorer software files as described on on page

8-4 above. The file you require is prefixed netpolicy-provisioner

2. When upgrading the NPP software you must use the U option to

upgrade the software. Therefore, the proper command to use when

upgrading is as follows: rpm -Uvh <filename>.rpm

Example:

rpm –Uvh netpolicy-provisioner-11.1.0-6.i386.rpm

NOTE You may discover the name of the NPP installation package by entering the following command: rpm -qa netpolicy-provisioner

On a Windows NPP Server

1. Open the NPP folder in the NetXplorer Upgrade package

2. Double click setup.exe in the NPP folder.



NPP.



Upgrade Stage 7: Upgrade All SMP Servers

Follow the procedure below to upgrade each SMP Server

NOTE If a session timeout value has been configured before upgrading SMP servers working in session management mode, this value will be reset to its default (disabled). The value will need to be reconfigured following upgrade. For more details refer to SMP User Guide.

Downloading the Software

1. Login to the SMP using username admin, password allot

2. Create a folder on the SMP in which the target software version will be stored.

For example: /root/MD11.1

3. Once the new distributed collector software version has been released for

general availability you can download it from the Allot FTP site:


4. Download the two files below for the target software version to the folder

created.

a. md-11.1.0-6.tgz

b. md-inst.sh

5. For SMP high availability installations, download the two additional files below

from the SMP-HAP directory on the FTP site:

a. ha-11.1.0-6.tgz

b. hainstall.sh

NOTE: The exact name of the tgz files will change per software version.

6. Extract the installation files from the tgz file using the following tar command: tar -xzvf <filename>.tgz

Standalone SMP Servers

1. Login to the SMP using username admin and password allot

2. Change directory to the directory in which the installation files are stored – e.g:

/root/MD11.1

3. Change md-inst to executable by entering: chmod +x md-inst.sh

4. Perform the upgrade by entering: ./md-inst.sh

5. SMP will reboot immediately after the upgrade




SMP High Availability Servers

Follow the procedure below to upgrade the SMP high availability nodes. Take care to

follow the procedure in exactly the order stated below.

WARNING Any additional bond interface configuration will be deleted during the process of upgrading the SMP High Availability Nodes.

NOTE Before starting the upgrade, open the file /etc/rc.d/rc.conf in each node and verify the IFTYPE is HA. You should see: IFTYPE[1]="HA"

If the IFTYPE is not HA, do not start the upgrade and contact Allot customer support

NOTE NX server must be stopped before starting the SMP upgrade. In NX-HAP installations, make sure BOTH NX nodes are stopped before starting the SMP upgrade (upgrade stage 4 above).

Upgrade the Passive Node

1. Obtain root privileges for the passive node using the following

command:

su –

2. Enter a user name and password.

3. Using the monit status command, determine which node is

currently passive.

4. Download the .tgz file and the md-inst.sh installation script.

5. Make the md-inst.sh file executable by entering the following

command:

chmod +x md-inst.sh

6. Execute the following installation script:

md-inst.sh

4. When prompted press Enter to start the install

smp-1:/var/tmp# ./md-inst.sh

Please wait...ready to start installation of 11.1.0-6.

The system will reboot automatically after the installation.

Are you sure you want to install now (y/n) [y]?

5. The install script will identify that this is an HA installation and will

ask you to enter the installation type. Choose option 2 for passive.

Installation had detected ha is enabled.



Are you sure you want to install now (y/n) [n]?

y

Please choose installation type:

1 - active

2 - passive

2

6. The installation will now run. When it completed you will be asked to

reboot.

The installation of md-11.1.0-6.tgz finished successfully.

System will need to reboot in order to function properly.

Would you like to reboot now (y/n) [y]?

7. Press Enter to reboot

Upgrade the Active Node

1. Wait for the passive node to come back from reboot.

2. Obtain root privileges for the Active node using the following

command:

su –

3. Enter a user name and password.

4. Download the .tgz file and the md-inst.sh installation script.


command:

chmod +x md-inst.sh

6. Execute the following installation script:

md-inst.sh

7. When prompted press Enter to start the install

smp-1:/var/tmp# ./md-inst.sh

Please wait...ready to start installation of 11.1.0-6.

The system will reboot automatically after the installation.

Are you sure you want to install now (y/n) [y]?

8. The install script will identify that this is an HA installation and will

ask to enter the installation type. Choose option 1 for Active



Please choose installation type:

1 - active

2 - passive

1

Sybase is being shut down, This could take few minutes

9. The installation will now run. When it completed you will be asked

to reboot.

The installation of md-11.1.0-6.tgz finished successfully.

System will need to reboot in order to function properly.

Would you like to reboot now (y/n) [y]?

10. When the upgrade completes press Enter to reboot

11. After the Active Node reboots, a switch over will occur

automatically which will complete the upgrade.

12. Confirm that the previously Passive mode is now Active, and also

upgraded.



Upgrade Stage 8: Start NX Service

Once all of the upgrades are completed, you can start the NetXplorer service. The

procedure for doing so depends on whether you are working with a Windows based

NetXplorer server or a Linux based NetXplorer server and whether or not you are

working with a NetXplorer High Availability Platform.

NetXplorer Standalone (Windows Based) 1. Click Start on the Windows Task Bar and select Settings > Control Panel


3. Right-click NetXplorer in the list of Services and select Start from the drop-

down menu

NetXplorer Standalone (Linux Based) 1. Start an SSH session to the NetXplorer server.

2. Enter: service netxplorer start

NetXplorer High Availability Platform (Linux Based) 1. Open an SSH session to one of the NetXplorer servers

2. Enter service heartbeat start

NOTE: After entering the command, wait until you receive an “OK” message.

This may take several minutes. Even after receiving the “OK”, this does

not necessarily mean that the heartbeat process has started and the

NetXplorer processes are running. It may take up to 20 minute from the

moment you enter the command for all processes to start.

3. Ensure that the server is correctly mounted to the storage by using the mount

command

4. Ensure that the NetXplorer server is up by using ps –ef|grep /opt/allot

NOTE: If the NetXplorer service is still not started after 20 minutes, contact

[email protected].

5. Open an SSH session to the second NetXplorer server

6. Enter service heartbeat start




Upgrade Stage 9: Verify Normal Operation

Verify Normal operation of the system. Depending on the component parts in your

system, Allot recommends the following steps

Verifying NetXplorer Operation

To verify that the NetXplorer is working correctly, perform the following steps:

1. Open the NetXplorer GUI

2. From the Help menu, choose “about NetXplorer” and check the

installed software version

3. From the Tools menu, choose “NetXplorer Application Server

Registration” and check that the correct features are activated

4. Select the NetEnforcers or Service Gateways on your network and

open the configuration dialog to check that the NetXplorer is

correctly communicating with the devices

5. Open a real-time or long-term report (depending on the license

purchased) and verify graph functionality

Verifying NX-HAP Operation

To verify that the NetXplorer high availability platform is working correctly, perform

the following steps:

1. Verify that the NX GUI can be accessed from the virtual IP

2. Login to one of the NetXplorer nodes and enter the command

crm_mon. Check which node is active.

3. Login to the active node and initiate a switchover by entering

service heartbeat stop ; service heartbeat start

4. Wait 20 minutes. Check which node is active by entering the

command crm_mon. If the NX-HAP is operating correctly, the

previously active node will have become passive and the

previously passive mode will have become active

5. Verify that the NX GUI can still be accessed from the virtual IP

6. Login to the currently passive node and initiate a switchover by

entering service heartbeat stop ; service heartbeat start

7. Wait 20 minutes. Check that the switchover was completed by

entering the command crm_mon



Verifying SMP Operation

To verify that the SMP is working correctly, perform the following steps:

1. Open the NX GUI. Select the SMP from the servers tree. Right

click and choose configuration

2. Check the software version of the SMP from the Identification

Tab

3. Open a real-time statistics graph on the fallback pipe. You should

see that as time passes, the fallback pipe will decrease as new

subscribers are matched to their appropriate service plans.

4. Open up a most active subscribers graph and check that it is

working correctly

Verifying SMP-HAP Operation

To verify that the SMP high availability platform is working correctly, perform the

following steps:

1. Open the NX GUI. Verify that a most active subscribers graph can

be opened

2. Login to one of the SMP nodes and enter the command monit

status. Check which node is active.

3. Login to the active node and initiate a switchover by entering

hb_standby

4. Check which node is active by entering the command monit

status. If the SMP-HAP is operating correctly, the previously

active node will have become passive and the previously passive

mode will have become active

5. Verify that the most active subscribers graph can still be accessed

from the virtual IP

6. Login to the currently passive node and initiate a switchover by

entering hb_takeover

7. Check that the switchover was completed by entering the

command monit status

Verifying DC Operation

To verify that the distributed collector is working correctly, perform the following steps:

1. Open the NX GUI. Select the STC from the servers tree. Right

click and choose configuration



2. Check the software version of the SMP from the Identification

Tab

3. Select the STC from the servers tree. Right click and choose

properties

4. Verify that the STC has been associated with the correct

NetEnforcers and/or Service Gateway from the “associated

NetEnforcers” tab

5. Open a real-time statistics graph on a NetEnforcer or Service

Gateway to which the collector is associated

Verifying NPP Operation

To verify that the NetPolicy Provisioner is working correctly, perform the following

steps:

1. Open the NX GUI. From the Tools menu, choose “NetXplorer

Application Server Registration” and check that NPP is activated

by the license

2. Open a browser and enter https://<NetXplorer IP>/npp

3. Login to the NPP using one of the user names and passwords that

you defined in the NetXplorer NPP accounts tab

4. Verify that you can monitor a pipe via the NPP GUI

Verifying NetXplorer Accounting Operation

To verify that NetXplorer Accounting is working correctly, perform the following steps:

1. Open the NX GUI. From the Tools menu, choose “NetXplorer

Application Server Registration” and check that NetAccounting is

activated by the license

2. Select network from the servers tree. Right click and choose

configuration

3. Select the NetAccounting tab and verify that “enabled

accounting” is checked

4. Note the path listed under “export directory”.

5. Login to the accounting server and open the export directory.

Verify that TRN files are written here (every 5 minutes or every 1

hour depending on the configuration)



Appendix B - Upgrading NetXplorer from Versions Earlier than NX9.2.1

NetXplorer Server and Mediation Device Version 9.2.0 build 03 and above use a newer

version (10 – SA10) of Sybase Anywhere database than previous versions. The upgrade

process from previous NetXplorer and Mediation Device versions to 9.2.0 build 03 and

above includes an automatic conversion process of CFG, LTC and SMF databases from

ASA version 9 to SA version 10. The STC database will be recreated as a new database

in SA version 10.

It is recommended that software versions previous to NX9.2.1 first upgrade to

NX9.2.1b7, then upgrade to the most recent version of the NetXplorer software. For

more information, contact Allot Technical Support at [email protected].

The database conversion process can be time consuming depending on the amount of

collected data. Due to the large size of the LTC database, this process can take up to 6

hours. To reduce the LTC database conversion time, the standard upgrade procedure

runs a process that reduces the resolution of collected data older than one month. Data

older than one month collected in resolution of hours and days will be reduced to a

resolution of months. For this reason, an additional manual conversion process also

exists, to avoid losing long term data. Both procedures are outlined below.

NOTE After performing an upgrade to the NetXplorer server the NetXplorer Client Java cache should be cleared. See page 7-6 for details.

Standard Upgrade Procedure

NOTE The standard upgrade procedure outlined below, reduces the resolution of collected data older than one month.

Manual Upgrade Procedure

To avoid losing long term data, the following procedure should be performed prior to

upgrading NetXplorer:

1. Stop the NetXplorer service.

On Windows – Open the services console, and locate the

NetXplorer Server service. Right click it and select stop.

On Linux – Open CLI and type /opt/allot/bin/nx_stop.sh.

2. Copy the entire ltc folder located in <allot root>\data\db\

(Windows) or /opt/sybase/data/db/ (Linux) and paste it outside

the Allot folder.

NOTE: Make sure that enough free disk space is left on the same hard drive (approximately 90% of LTC database size) for the conversion process to take place.



3. Upgrade NetXplorer and/or Mediation Device version. Once the

installation completes you may be asked to restart your server.

4. Once the server boots up, stop the NetXplorer service.

5. Delete the contents of the <allot root>\data\db\ltc folder.

6. Copy the contents of the ltc folder previously backed up and paste

them back in <allot root>\data\db\ltc.

7. Launch the LTC database conversion process by executing the

following script:

On Windows - <allot root>\bin\db_upgrade_ltc_2sa10.bat

On Linux - /opt/allot/bin/db_upgrade_ltc_2sa.sh

8. The process is logged in two log files located in

On Windows - <allot root>\log\

On Linux - /opt/allot/log

1) dbunload_log_ltc.txt

2) dbunload_log_time_cfg.txt.

9. Start the NetXplorer Server service:

On Windows – Open the services console, and locate the NetXplorer

Server service. Right click it and select start.

On Linux – Open CLI and type /opt/allot/bin/nx_start.sh.

NOTE NetXplorer Accounting cannot be upgraded directly. The old version

must be uninstalled and the new version of Accounting may then be

installed

Example of Log File Content

Below is a successful conversion process log for reference:

dbunload_log_time_cfg.txt

*************************************************************

Start Convert DB to version SA10 - 6/18/2009 2:11:14 PM

Unload LTC data to C:\Allot\tmp\ltc_datadirectory

Finish Unload LTC data - 6/18/2009 2:11:34 PM

Create new LTC database - 6/18/2009 2:15:49 PM

Default PARAM table truncated - 6/18/2009 2:15:58 PM

Load data into new LTC database - 6/18/2009 2:16:49 PM



*************************************************************

dbunload_log_ltc.txt

SQL Anywhere Unload Utility Version 10.0.1.3807

Connecting and initializing

Unloading "nms"."CONVER_STAT_" into C:\Allot\tmp\ltc_data/438.dat

(relative to server)

Unloading "nms"."DEVICE" into C:\Allot\tmp\ltc_data/439.dat (relative to

server)

Unloading "nms"."EVENT" into C:\Allot\tmp\ltc_data/440.dat (relative to

server)

Unloading "nms"."EVENT_VALUE" into C:\Allot\tmp\ltc_data/442.dat


Unloading "nms"."LINE_BURST_" into C:\Allot\tmp\ltc_data/443.dat


Unloading "nms"."PARAM" into C:\Allot\tmp\ltc_data/444.dat (relative to

server)

Unloading "nms"."VC_STAT_HRS_1_3" into C:\Allot\tmp\ltc_data/453.dat


...

...

...

Unloading "nms"."SERVICE_STAT_DAY_3_11" into

C:\Allot\tmp\ltc_data/1664.dat (relative to server)

Unloading "nms"."SERVICE_STAT_DAY_3_12" into

C:\Allot\tmp\ltc_data/1665.dat (relative to server)

Unloading "nms"."SERVICE_STAT_MON_1" into C:\Allot\tmp\ltc_data/1666.dat






Unloading "nms"."SMS_QUOTA_" into C:\Allot\tmp\ltc_data/1669.dat




Appendix C – Downgrade Procedures

The following procedures detail how to downgrade the NetXplorer, SMP and

Distributed Collector to the previous released versions

STAGE AIM TYPICAL TIME

NOTES

1 Back Up All SMPs 15 mins

(per SMP)

If SMP is deployed

2 Back Up NetXplorer 15mins - 2

hours

Longer time is required for

backing up LT database. If

LT backup required, verify

enough disk space is

available

3 Downgrade NetXplorer 1hr – 2hrs Time depends on if

downgrading NX-HAP.

Separate procedure for NX

and NX-HAP

4 Restore NX Configuration and

Databases

1hr – 2hrs Time depends on size of

databases that were backed

up in stage 2

5 Stop NetXplorer Service 15 mins Necessary if additional

elements beside NX are to

be upgraded (e.g: SMP,

STC, NPP)

6 Downgrade All Collectors 30 mins per

collector

If deployed. Can be

performed simultaneously

to save time.

7 Downgrade Additional Deployed

Services (e.g: Accounting / NPP)

30 mins

per service

If deployed. Can be

performed simultaneously

to save time.

8 Downgrade All SMPs 2hr – 3hrs If deployed. Time depends

on whether downgrading

SMP-HAP. Separate

procedure for SMP and

SMP-HAP

9 Restore SMP Configuration 30 mins



10 Start NetXplorer Service 20 mins Necessary if NX service

was stopped in 5 above

11 Verify Normal Operation 30 mins –

1hr

Time required depends if

working with HAPs

NOTE: The approximate times shown in the table above give a very rough

guideline only. Actual downgrade times may be significantly different,

depending on the specific circumstances

A typical downgrade may not include all of the components detailed above.

Consequently, different tracks can be planned through this master-plan depending on

the equipment which needs to be downgraded. For example:

For downgrading NX only follow stages 234 9

For downgrading NX and STC only: Stages 234561011

For upgrading NX and SMP only: Stages 12345891011

Make sure you have all root user passwords before the downgrade process starts.

Downgrade Stage 1: Backup All SMPs

Follow the same steps outlined in the upgrade process Upgrade Stage 1: Backup All

SMPs above

NOTE: Make sure that all of the SMP files which you have backed up are saved

outside of the SMP servers

Downgrade Stage 2: Backup NX

Follow the same steps outlined in the upgrade process Upgrade Stage 2: Backup

NetXplorer above

Downgrade Stage 3: Downgrading NetXplorer

Follow the steps in this stage, to downgrade the NetXplorer: At end of download stage 3

you will have the equivalent of a cleanly installed NetXplorer (or NX-HAP) with the

previous software version and with empty databases and the default configuration.

In advance of the downgrade, close all NetXplorer GUI Sessions and delete the Java

Cache. The procedure for deleting the Java Cache is described on on page 7-6 above.

The steps required to downgrade the NetXplorer differ, depending on whether you are

working with NetXplorer (Windows), NetXplorer (Linux) or NetXplorer (HAP). Each

will be examined in turn now




1. Stop the NetXplorer service by following the steps below

Click Start on the Windows Task Bar and select Settings >

Control Panel


Right-click NetXplorer in the list of Services and select Stop

from the drop-down menu

2. Refer to the following Knowledge Base item and follow the steps

within: https://c.eu0.visual.force.com/apex/KB?KBID=5538500



Start an SSH session to the NetXplorer server.

Enter: service netxplorer stop

2. Enter the following command to remove the old package: rpm -e

netxplorer-11.1.0-6 Do not reboot after entering the command.

3. Enter the following command to install the old package rpm -ivh

netxplorer-10.2.1-12.i386.rpm

4. Edit the /opt/allot/conf/swKeeper.ini file and change the java

location to /usr/java/jdk1.6.0_20/bin

5. NX10.2.1 uses JDK 1.6 update 13. NX11.1.0 uses JDK 1.6

update 20. In order to ensure that the GUI opens following

downgrade, you should:

Remove JDK 1.6 update 20 by entering rpm –e jdk-6u20-linux-

i586.rpm

Install JDK 1.6 update 13 by entering rpm –U jdk-6u13-linux-

i586.rpm –nodeps

6. Reboot NX by entering the command reboot

NetXplorer High Availability Platform (Linux Based)


Start an SSH session to the passive NetXplorer server

Enter service heartbeat stop and wait for the command

output to issue an ok message

Now start an SSH session to the active NetXplorer server

Enter service heartbeat stop and wait for the command

output to issue an ok message.

https://c.eu0.visual.force.com/apex/KB?KBID=5538500



WARNING: After entering the command, wait until you receive

an “OK” message. This may take several minutes.

Even after receiving the “OK”, this does not

necessarily mean that the heartbeat process has

stopped. The heartbeat process may take up to 15

minutes to stop each time. You are advised to wait

15 minutes before proceeding. You can check that

heartbeat is stopped by entering: ps -ef | grep

heartbeat | grep –v grep. If the heartbeat process

has stopped, the output of this command will be

empty. In case there are still NetXplorer processes

running, contact [email protected] and do not

continue with the upgrade.

2. On NX1 mount the disk array - mount /dev/dm-1

/opt/sybase/data

3. Enter the following command to remove the old package: rpm -e

netxplorer-11.1.0-6 - do not reboot after.

4. Enter the following command to install the old package rpm -ivh

netxplorer-10.2.1-12.i386.rpm

5. Remove startup scripts in /etc/rc5.d and /etc/rc3.d (S90netxplorer)

6. Repeat steps 3-5 on the other node

7. NX10.2.1 uses JDK 1.6 update 13. NX11.1.0 uses JDK 1.6

update 20. In order to ensure that the GUI opens following

downgrade, you should:

Remove JDK 1.6 update 20 by entering rpm –e jdk-6u20-

linux-i586.rpm

Install JDK 1.6 update 13 by entering rpm –U jdk-6u13-linux-

i586.rpm –nodeps

8. On NX1 unmount the disk array - umount /dev/dm-1

/opt/sybase/data

9. Reboot NX1 by entering the command reboot

10. Wait for NX1 to come up from reboot and then reboot NX2.




Downgrade Stage 4: Restore NX Configuration and Databases

The steps required to restore the configuration and databases to the NetXplorer differ,

depending on whether you are working with NetXplorer (Windows), NetXplorer

(Linux) or NetXplorer (HAP). Each will be examined in turn now.


1. Stop the NetXplorer service:


Control Panel


Right-click NetXplorer in the list of Services and select Stop


2. Restore backup cfg and ltc databases by using the cold restore

procedure:

Copy allot_cfg.log and allot_cfg.db from the directory where

you saved them to /opt/sybase/data/db/cfg

Copy allot_ltc.log and allot_ltc.db from the directory where

you saved them to /opt/sybase/data/db/ltc

3. Start the NetXplorer service again:


Control Panel


Right-click NetXplorer in the list of Services and select Start



1. Stop the NetXplorer Service using “service netxplorer stop”

2. Restore backup cfg and ltc databases on NX1 by using the cold

restore procedure:



Change file owner to Sybase allot by running the command:

chown –R /opt/sybase/data/db/cfg/*






chown –R /opt/sybase/data/db/ltc/*

3. Start the NetXplorer service using "service netxplorer start".

NetXplorer High Availability Platform

1. Stop the heartbeat service once again. Refer to page 8-6 (Upgrade

Stage 4) above for full details on how to safely stop the heartbeat

service on each node.

2. On NX1 mount the disk array - mount /dev/dm-1

/opt/sybase/data

3. Restore backup cfg and ltc databases on NX1 by using the cold

restore procedure:




chown –R /opt/sybase/data/db/cfg/*




chown –R /opt/sybase/data/db/ltc/*

4. Start services on both nodes using "service heartbeat start".

Downgrade Stage 5: Stop NetXplorer Service

Follow the same steps outlined in the Upgrade Stage 4: Stop NetXplorer Service above

Downgrade Stage 6: Downgrade All Collectors

Follow the instructions below to downgrade the distributed collector:

1. Download the tgz file and scripts for 10.2.1 to each STC which

you wish to downgrade. Store the files in a directory which is not

/opt

2. Login to the Collector and delete the /opt directory by running the

command: rm –R /opt

3. Reboot the collector by entering the command reboot



4. Login to the STC which you wish to downgrade. Go to the

directory in which you stored the software tgz file and script.

5. Change the permissions for the md-inst.sh script by entering:

chmod +x md-inst.sh

6. Run the md-inst.sh script for MD10.2.1 by entering ./md-inst.sh

7. After the downgrade is complete you will be prompted to reboot

the collector.

8. Once the collector is up and running after the reboot, enter dev

setup –m stc

Downgrade Stage 7: Downgrade Additional Services

Downgrading NetXplorer Accounting

NetXplorer Accounting cannot be downgraded directly. The newer version must be

uninstalled and the older version of NetXplorer Accounting may then be reinstalled.

On a Linux Accounting Server:

1. Download the older version of the NetXplorer software files as

described on on page 8-4 above. The file you require is prefixed

accounting-manager

2. Uninstall the installed NetAccounting service by entering the

command: rpm –e accounting-manager-11.1.0-6

3. Install the older version of the NetXplorer Accounting software by

entering rpm -ivh <Accounting filename>.rpm

NOTE You may discover the name of the NetAccounting installation package

by entering the following command: rpm -qa accounting-manager

4. Dependencies are checked and error message issued if additional

packages are needed. JDK 6 (Java development kit) is included in

the installation set. To install the packages, run rpm -ivh <JDK

filename>.rpm (version numbers may differ).

5. After the installation is finished, you see the following:

rpm -ivh accounting-manager-10.2.1-12i386.rpm

Preparing...

########################################### [100%]

1: accounting-manager ########################################### [100%]





accounting/bin/set_acct_nx_ip.sh.





7. To set the NetXplorer IP address, (so that the NetAccounting

Server can communicate with it) run the following:



9. After the upgrade finishes, inform the accounting server of the

NetXplorer IP address by running


On a Windows Accounting Server

NOTE NetXplorer Accounting cannot be downgraded directly on a Windows server. The current version must be uninstalled and the older version of Accounting may then be installed.

1. Uninstall the current NetXplorer Accounting installation.

2. Open the ACCT folder in the NetXplorer Upgrade package

3. Double click setup.exe in the ACCT folder.


4. Follow the onscreen instructions in the Setup Wizard to install the

older version of NetXplorer Accounting.



Downgrading NPP

On a Linux NPP Server:

1. Download the older NetXplorer software files as described on on

page 8-4 above. The file you require is prefixed netpolicy-

provisioner

2. Uninstall the installed NetPolicy Provisioner service by entering

the command: rpm –e netpolicy-provisioner-11.1.0-6

3. Install the older version of the NetPolicy Provisioner software by

entering rpm -ivh <NPP filename>.rpm

NOTE You may discover the name of the NPP installation package by entering the following command: rpm -qa netpolicy-provisioner

On a Windows NPP Server

NOTE NPP cannot be downgraded directly on a Windows server. The current version must be uninstalled and the older version of NPP may then be installed.

1. Uninstall the current NPP installation

2. Open the NPP folder in the NetXplorer Upgrade package

3. Double click setup.exe in the NPP folder.


4. Follow the onscreen instructions in the Setup Wizard to

downgrade NPP.



Downgrade Stage 8: Downgrade All SMPs

The steps required to downgrade the SMP differ, depending on whether you are

working with SMP or SMP-HAP. Each will be examined in turn now. At the end of

downgrade stage 8, the SMP will be downgraded, without any data.

WARNING: Make sure that all of the SMP files which you have backed up in

Downgrade Stage 1: Backup All SMPs above are saved outside of the

SMP servers!

NOTE: Remember that the NX service (on both nodes if working with NX-HAP)

must be down during the SMP downgrade procedure (as shown in

Downgrade Stage 5: Stop NetXplorer Service above)

NOTE: This downgrade stage requires access to the ISO image for the software

to which you wish to downgrade the SMP Nodes. You will also need

console connectivity to each SMP node.

SMP

1. Delete /opt by entering the command: rm –R /opt/*

2. Reboot the node by entering reboot

3. When the SMP node comes back up, download the .tgz file and

the md-inst.sh installation script.


command: chmod +x md-inst.sh

5. Execute the following installation script: md-inst.sh

6. Define device parameters on the node (dev setup). Refer to the

subsection of SMP User Guide Chapter 2 entitled “Configuring

Device Parameters” for full instructions]

SMP-HAP

Follow the instructions below to downgrade SMP-HAP:

1. Make sure the smp-0 is active by logging in to SMP-0, changing

the login to super user and entering monit status

NOTE: The active SMP of the two nodes is the node for which the

swkeeper process is running. In the output below the

monitoring status of SMP-0 (on the left side) is “not

monitored”. The monitoring status of SMP-1 (on the right

side) is “monitored”. In this case, SMP-0 is passive. In order

to make the passive SMP active, run hb_takeover



2. Stop HA monitoring on both nodes by entering monit unmonitor

all on each of the two nodes

3. On the active node (SMP-0) stop the heartbeat process by

entering: monit stop heartbeat

4. Mount the storage to the active node (SMP-0) by entering mount

/dev/sdb1 /opt/sybase/data

5. Delete /opt/sybase by entering the command: rm –R

/opt/sybase/*

6. Un-mount the storage by entering umount /dev/sdb1

7. For each SMP node, follow the steps below:

Connect a serial cable (or keyboard and monitor) directly to

the SMP node

Insert the bootable CD with the ISO image of the SMP

software to which you wish to downgrade the SMP nodes

(e.g: SMP10.2.1)

Reboot the node by entering reboot

When the SMP node comes back up, the CD will run. Follow

the onscreen instructions to complete the downgrade

Define network settings on the node (go config ips). Refer to

the subsection of SMP User Guide Chapter 2 entitled

“Configuring Network Parameters” for full instructions



Define device parameters on the node (dev setup). Refer to the

subsection of SMP User Guide Chapter 2 entitled

“Configuring Device Parameters” for full instructions]

8. Once the tasks in step 7 above have been carried out on both SMP

nodes, download the hainstall files for the software version to

which you are downgrading to both of the SMP nodes

9. Run the hainstall script on both nodes as described in the

subsection of SMP User Guide Chapter 2 entitled “Preparing an

SMP HA Cluster” for full instructions



Downgrade Stage 9: Restore SMP Configuration

The steps required to restore a previous SMP configuration differ,

depending on whether you are working with SMP or SMP-HAP. We

will examine each case in turn:

SMP

1. Restore the folders which you backed up in Downgrade Stage 1

above, to each respective SMP:

/etc/rc.d/*

/etc/hosts/*

/opt/allot/conf/*

/opt/allot/radius/etc/raddb/* (if working with RADIUS mode)


2. To restore the database, stop the SMP service by entering

dc_stop.sh

3. Copy allot_smf.log and allot_smf.db from the destination where

you stored the database backup files to the directory below:

/opt/sybase/data/db/smf

4. Start the SMP service by entering dc_start.sh

SMP-HAP

1. Restore the folders which you backed up in Downgrade Stage 1

above, to each respective SMP:

/etc/rc.d/*

/etc/hosts/*

/opt/allot/conf/*

/opt/allot/bin/active_standby_node_status.sh

/opt/allot/radius/etc/raddb/* (if working with RADIUS mode)


/etc/modprobe.d/bonding (if extra bond was configured on

SMP)

2. In order to restore the database, determine which is the active

mode by logging in to SMP-0, changing the login to super user

and entering monit status

3. Stop HA monitoring on both nodes by entering monit unmonitor

all on each of the two nodes



4. On the active node (SMP-0) stop the heartbeat process by

entering: monit stop heartbeat

5. Mount the storage to the active node (SMP-0) by entering mount

/dev/sdb1 /opt/sybase/data

6. Copy allot_smf.log and allot_smf.db from the destination where

you stored the database backup files to the directory below:

/opt/sybase/data/db/smf

7. Un-mount the storage by entering umount /dev/sdb1

8. Start the SMP service by entering the command: monit monitor

all

9. Now open an SSH connection to the second SMP node and start

the SMP service by entering monit monitor all This node will

remain the passive node.

10. On the passive node, enable a switchover by entering the

command: hb_takeover

Downgrade Stage 10: Start NetXplorer Service

Follow the same steps outlined in the Upgrade Stage 8: Start NX Service above

Downgrade Stage 11: Verify Normal Operation

Follow the same steps outlined in the Upgrade Stage 9: Verify Normal Operation above



Appendix D – IBM DS Storage Manager

In order to be able to send SNMP traps from the storage server in the NetXplorer High

Availability platform, the IBM System Storage Manager Client must first be installed.

Instead of installing the IBM System Storage Manager Client on a separate PC, it is also

possible to install the client on the NetXplorer Servers themselves. This procedure,

described below, enables the NetXplorer to communicate directly with the Storage

Server in-band over the SAS cables.

The RAID storage server on the NX-HAP consists of two controllers as seen in Figure

‎8-1 below.

NOTE: The left hand controller has a default IP of 192.168.128.101. The right hand controller has a default IP of 192.168.128.102

Figure ‎8-1: SNMP Traps Sent from Storage Controllers

Installing Storage Manager Client on NX Servers

Before installing, confirm that the NX High Availability server is installed and

configured. The following procedure should be performed on both nodes (NX hosts).

1. Copy the appropriate file (for example - SM10.60_Linux_SMIA-

10.60.xx.11.tar) to a folder on the NX server host (for instance,

/home/Install)



2. Locate the file in the File Browser window, right-click on it and

choose Extract Here from the drop-down menu, or in the

Terminal window enter the following commands:

cd /home/Install

tar –xf SM10.60_Linux_SMIA-10.60.xx.11.tar

3. Locate the file SMIA-LINUX-10.60.A5.11.bin

4. Change its permission and execute the file by running the

following commands:

cd Linux10p60/Linux/

chmod +x SMIA-LINUX-10.60.A5.11.bin

./SMIA-LINUX-10.60.A5.11.bin

Figure ‎8-2: Storage Manager Installation Wizard

The Storage Manager Installation Wizard opens.

5. Click OK to select English as the installation language.

Follow the instructions in the Wizard. When the Select Installation

Type screen opens, select Typical (Full) Installation and click

Next.



Figure ‎8-3: Select Installation Type

6. Click Install and wait for the Installation Completed

Successfully message to appear, then click Done.

An IMB DS Storage Manager icon is created on the desktop.

Double-click this icon to run the application.

Figure ‎8-4: Select Addition Method

7. When the Select Addition Method screen appears, select the

default Automatic option to discover storage subsystems

throughout the entire and click OK. This method is useful for

adding Storage Manager Collectors‟ (SMP, PCC etc.) storage

subsystems as well as NetXplorer storage.

A progress bar appears in the lower right hand corner of the

window.



8. When automatic discovery completes, a message is shown in the

status bar and the discovered subsystems appear in the Devices

hierarchy tree.

Figure ‎8-5: Devices Hierarchy Tree

9. If the required subsystems are located in a different network or if

you intend to manage just some of the available local subsystems

via the Storage Manager, you may add subsystems manually.

Right click on a top level object in the Devices tab and choose

Add Storage Subsystem from the menu.

Figure ‎8-6: Devices Tab Menu

10. Choose In-band (if a subsystem is connected directly to the

management host) or Out-band (if a subsystem is connected to

another network), then type the subsystem‟s IP or host name.

11. Repeat Step 10 to add additional subsystems if needed.



Configuring Storage Manager to Send SNMP Traps from the Storage Device

Follow the steps below to configure the storage manager to send SNMP traps to an

external trap receiver:

1. Right click on an object in the Devices tab (e.g: the DS3200

storage subsystem) and select Configure Alerts from the menu.

The Configure Alerts dialog box appears.

Figure ‎8-7: Configure Alerts

2. Open the SNMP tab and enter a Community name (public is

added by default) and Trap destination (host name or IP address).

Click Add. The new SNMP address will appear in the Configured

SNMP addresses list.

3. Click Test to confirm that a trap arrives at the destination host

(this test requires appropriate „trap listening‟ software to be

running on the destination host).

4. Click the Mail Server tab to enter a mail server and the Email tab

to enter an Email address for Alerts, if desired.



Appendix E - Configuring NX to Work Behind an HTTP Proxy

To configure the NetXplorer to work in conjunction with an HTTP Proxy follow the

instructions below:

NOTE On a Linux machine make sure to configure HTTP Proxy as the root user (privileges for cp and chown are needed).

To use an automatic script in SNX-SRV:


2. Run http_proxy.sh (in Linux) or http_proxy.bat (in Windows),

located at <Allot_Root_Dir>\bin.

3. Select option '1' when prompted.

4. Restart the NetXplorer service.

To use an automatic script in SNX-SRV-HAP:

1. Stop the heartbeat on the passive node by running the following


2. Stop the heartbeat on the Active node by running the following


3. On the NX-0 node mount common disk storage with the following

command:

mount /dev/dm-1 /opt/sybase/data

4. On the NX-0 node run the following script: http_proxy.sh

5. On the NX-1 node run the following script (script will be run on

local database): http_proxy.sh

NOTE When running the script on nx-1, the following output is expected

Could not connect to the database.

Request to start/stop database denied

SQLCODE=-75, ODBC 3 State="42000"

You are not connected to a database.



Please restart your NetXplorer Service to enable http proxy

configuration.

6. On the NX-0 node un-mount common disk storage with the

following command: umount /dev/dm-1

7. Reboot NX-0 node.

8. Wait for NX-0 to come back from Reboot.

9. Reboot NX-1 to start working in HA mode

To revert to the regular configuration:

To stop using HTTP Proxy you may reverse the steps of the manual configuration

above, or follow the procedure below.


2. Run http_proxy.sh (in Linux) or http_proxy.bat (in Windows),

located at <Allot_Root_Dir>\bin.

3. Select option '2' when prompted.

4. Restart the NetXplorer service.



Appendix F - Events and Recommended Actions

In the table below you will find a list of events which can be recorded in NX11.1 and

their recommended actions. Note that in the “Alarm” column, “UD” indicates that the

user can define this event as alarmable. In the “Trap” column, “UD” indicates that the

user can configure the NX to send a trap to an external NMS for this event. “Auto”

means that a trap is automatically sent from the NX to the NMS.

ID EVENT RECOMMENDED ACTION ALARM TRAP

1 Rising TCA (Threshold Crossing Alarm)

The relevant action here depends on the particular alarm which has been triggered

N/A N/A

2 Falling TCA (Threshold Crossing Alarm)

N/A N/A

3 Device Configuration Someone made changes to the configuration of the SG. Review the audit trail to see who make the change and what changes had been made

UD UD

4 Line Policy Change Someone made changes to the policy. Review the audit trail to see who make the change and what changes had been made

UD UD

5 Pipe Policy Change UD UD

6 Virtual Channel Policy Change UD UD

7 Catalog Entry Change Someone made changes to the Catalog Entry. Review the audit trail to see who make the change and what changes were made

UD UD

8 Suspected DoS Attack Started Perform further analysis of incoming traffic – check threat detection and mitigation systems (such as Allot Service Protector) if installed

AUTO

9 Suspected DoS Attack Stopped Information Only – No Action Required

10 External Data Source Down Information Only – No Action Required AUTO

11 External Data Source Up

12 Software Problem Open an incident with [email protected] for unit with valid maintenance contract




13 NetEnforcer Access Violation Attempted access from list machines. Too many entries could mean intrusion. Try to connect device's management port to a local network, if it is on a public one.

14 Link Down Can be information only as the link may be down administratively or not connected. Otherwise, check physical connectivity of NE or SG.

UD UD

15 Link Up Information Only – No Action Required

16 Cold Start Device restart, check logs to find out cause. On the SGSV blade, check the nedbg.swKeeper.log. On the SGCC blade, check the nedbg.prcMngr.log

UD UD

17 Warm Start

18 Authentication Failure Wrong password. Check and enter a valid one.

19 NetEnforcer IP Address Change

IP Address of the NE or SG was changed. Make sure that this was intentional

UD UD

20 Connection Routing Configuration

A change was made in the routing setting "go config network -ar"

21 Device Status Down NE or SG is not active. Check logs to identify root cause.

UD UD

22 Device Status Up Information only. No action required.

23 Application Info Information only. No action required AUTO

24 Protocol Update Installation Information only. No action required

25 Board Status Changed If an intentional change has been made to the device (e.g: blade inserted or removed) no action is necessary. If no intentional change has been made, analyze current status of all boards from the slots&boards tab of the NX GUI

100 Server Unreachable No connectivity between NE/SG and NX. Check network communication and make sure all required firewall

ports are open (see Firewall Settings

aboveabove for full list)

UD UD

101 Server Reachable Information only. No action required.




102 Device Unreachable NE or SG cannot be pinged. Make sure all required firewall ports are open (see

Firewall Settingsabove above for full

list)

UD UD

103 Device Reachable Information only. No action required.

104 User Forced Clear Information only. No action required

107 Device Hardware Change A replacement of device is identified. No action required, unless it is not intentional.

UD UD

108 User Force Cleared All Alarms Information only. No action required.

109 User Logged In Information only. No action required.

110 User Logged Out Information only. No action required.

111 Catalogs Synchronization Problem

112 Catalog Rejected by NetEnforcer

113 Automatic Alarm Purge The server removes all the alarms (e.g: due to SG reboot)

114 Policy and Catalogs Export Information only. No action required.

115 NetEnforcer Configuration Import

Configuration of policies is being imported from SG to NX DB.

116 Server Management Ownership Taken from Device

There is more than one NX managing the device. Make sure you do not add new device on another NX server. (another server added the SG to its DB and the SG is deleted from the current server).

AUTO

117 Server Management Ownership of Device Taken

AUTO

118 Missing Events Were not Found on Device Trap Table During Synchronization

There is mismatch between the device events counter and the server events counter - the server is trying to find the missing events but failed

119 Device Add Information only. No action required.

120 License expiration warning Contact [email protected] for a new NX license

AUTO

121 License is expired AUTO

122 Server license registered Information only. No action required. AUTO





123 Clear license expiration warning Information only. No action required.

124 Device policy replaced with rescue policy

Existing policies are refreshed with default one. This can be software related problems. Consult with Allot KB Item: https://c.eu0.visual.force.com/apex/KB?KBID=12124297

AUTO

125 Policy data is not synchronized on device

Save the policy again, to sync it. And remove the alarm from log manually.

126 AS does not support device software version

Invalid firmware used on device. Update the firmware to the release supported by the NX server. Consult Allot support for more information, if necessary.

127 Device was deleted from system

If it is not intentional, identify the reason why NE or SG was removed from the NX.

128 Collector was deleted from system

130 Configuration Database Incremental Backup failed

Failure of the backup process

131 Configuration Database Full Backup failed

132 Country classification file updated

Information only. No action required. Auto

133 New Protocol Updates are Available

If you have a valid support contract, you can download the new protocol updates to your NetXplorer server and to your device by following the instructions in the NetXplorer Operations Guide (Chapter 4: Service Catalogs)

Auto

134 Install new protocol updates to AS


135 Install new protocol updates to device


136 Scheduler forced clear alarms Note that all alarms will have been cleared.

137 Device license expiration warning

Contact [email protected] for a new NE or SG license

Auto







138 Device license is expired

139 Clear device license expiration warning

Information only. No action required.

140 Rollback AS protocol updates Information only. No action required. Auto

141 Rollback device protocol updates


142 Asymmetric remote device configuration changed

A change has been made to the asymmetric traffic configuration. If this change was intentional, no further action is required. If not, check the current asymmetric configuration is as required by right clicking on the device from the NX GUI and selecting „Asymmetry Configuration‟

143 Asymmetric remote device Health Check Status changed

144 Blacklist source up Information only. No action required.

145 Blacklist source down Check communication with the Websafe blacklist files

Auto

146 Blacklist server status up Information only. No action required.

147 Blacklist server down Check communication with the server from which Websafe blacklist files are downloaded

Auto

148 License Warning The attribute stated in the warning is approaching the limit set by your license. Review your license.

Auto

149 License Critical The attribute stated in the warning has reached the limit of your license. Review your license urgently

Auto

150 Board Temperature Status Check the temperature readings on each of the sensors on the blade, either via the CLIA command or from the Boards&Slots tab on the NX GUI

200 Collector Reported Device Unreachable

Data Collector cannot ping / access the SG for short term data collection. Check network, possible firewall and ACL rules.

UD UD

201 Collector Reported Device Reachable





202 Invalid Bucket Time in Collector Time on SG and NX/Data Collector is not synchronized. Make sure you set the SG‟s time, Data Collector's time and NX's time and they are the same. May require to reboot the device and/or Data Collectors.

Auto

203 Valid Bucket Time in Collector Information only. No action required

204 Invalid Bucket in Collector

205 Real Time Bucket Overload in Collector

There is high load on the server and the DB isn‟t able to handle all the buckets (for example weak server with a lot of devices). As a result there may be some data missing from graphs. If problem persists open a support incident with [email protected]

206 Short-term Bucket Overload in Collector

207 Bucket Validated in Collector End of bucket overload. No action required.

208 Invalid Bucket Time in Collector Time on SG and NX/Data Collector is not synchronized. Make sure you set SG, Data Collector and NX to the same time. May require to reboot the SG and/or Data Collectors

Auto

209 Valid Bucket Time in Collector Information only. No action required.

210 Real Time + Short-term Bucket Overload in Collector

There is high load on the server and the DB isn‟t able to handle all the buckets (for example weak server with a lot of devices)

211 Bucket Overload in Collector Finished


212 Collector Reported Disk Space Problem

Not enough free space on the ST Collector hard disk. (less than 10%)

Auto

213 Collector Reported Disk Space Problem Fixed


214 Short Term Collector Reported Database Full Backup failed

STC database incremental backup failed.

300 Long Term Collector Reported Short Term Collector Unreachable

Long term data collection process cannot gather from the short term database. If data collector is installed, check NX to data collector connectivity.

UD UD





301 Long Term Collector Reported Short Term Collector Reachable


302 Invalid Bucket Time in Collector Auto

303 Valid Bucket Time in Collector Information only. No action required.

304 Long Term Collector Reported Disk Space Problem

Not enough free space on the LT Collector hard disk. (less than 10%)

Auto

305 Long Term Collector Reported Disk Space Problem Fixed


306 Long Term Collector Reported Database Full Backup failed

401 Quota violation A subscriber has used all of his quota. In most cases, this event is for information only and no action is required.

402 Quota recovery A subscriber was in violation of his quota, but now the quota cycle is over and his quota has been reset. In most cases, this event is for information only. No action required

403 Domain not found A particular subscriber has been allocated an IP which doesn‟t fall into a predefined domain. Check the IP that has been allocated to this subscriber and decide if you wish to extend an existing domain or create an additional one to cover this IP address

404 SMP provision error trap Review the details of the event and fix the provisioning error using tools presented in the troubleshooting section of the SMP User Guide.

UD UD

405 SMP multi fail trap UD UD

406 SMP High Availability Trap Troubleshoot the high availability platform using tools presented in the troubleshooting section of the SMP User Guide.

UD UD

407 SMP System Trap Troubleshoot the PCC process and communication with the PCRF using tools presented in the troubleshooting section of the SMP User Guide.

500 Disk Storage Trap Check the hardware status Auto



Appendix G – NX IP Address for UI Script

The set_nx_ip4ui.sh (Linux) or set_nx_ip4ui.bat (Windows) script is located in the

/opt/allot/bin directory. The script can be used in either of the circumstances listed

below:

Changing the NetXplorer IP address (before NX operation)

Selecting a NetXplorer IP address from multiple IPs (to be used by GUI)

Changing the NetXplorer IP Address

The script can be used where the IP address of a NetXplorer server needs to be changed

after the NetXplorer software has been installed, but before the NetXplorer is

operational. A typical example of such a need is when NX-SRV has been purchased

(NetXplorer software pre-installed on a dedicated IBM server). NX-SRV is shipped

with a default IP address of 11.11.11.1. After changing the IP address at a Linux level,

the customer will need to run the set_nx_ip4ui.sh script in order to bind the new IP

address.

NOTE: If you wish to change the IP address of a NetXplorer server after the

NetXplorer has become operational, contact [email protected]

Selecting a NetXplorer IP Address for the GUI

In cases where the NetXplorer has been defined with multiple IP addresses (e.g:

multiple network interfaces or multiple addresses on the same interface), the NX GUI

(from NX11.1) can communicate with the NX Server over only one of these. The

customer will need to run the set_nx_ip4ui script in order to select the required IP

address.

NOTE: After installing NX-HAP, the script needs to be run on each NX node

and the Virtual IP address of the NX-HAP should be chosen.

Running the Script

Run the script from its location and follow the on-screen prompts. You will be asked to

enter the IP address that the NX GUI should communicate to the server over. The script

then updates the NetXplorer configuration files accordingly.

Once the procedure is completed, the NetXplorer service should be restarted.


NX Installation Admin Guide R7

Documents

Transcript of NX Installation Admin Guide R7