Allot SNMP Integration v2.b6

2010 Allot Communications. All rights reserved. No part of this may be reproduced, disclosed or used except as authorized by contract or other express written permission by Allot.

Integration Guide,

November 2010

Allot SNMP Integration

SNMP Integration Guide

2010 Allot Communications. All rights reserved. 2

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-2009 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.

NOTE: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to Part

15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio frequency

energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio

communications. Operation of this equipment in a residential area is likely to cause harmful interference in which case the user will be required to correct the interference at his own expense.

Changes or modifications not expressly approved by Allot Communication Ltd. could void the user's authority to operate

the equipment.



Version History

Doc

Version

Date Author Revisions Added

V1b1 May 2009 Dan Shalem -

V1b2 May 2009 Dan Shalem SMP Traps and KPIs

NX Mib Structure

V1b3 02.06.09 Dan Shalem IBM RSA-II traps added

V1b4 11.06.09 Dan Shalem IBM DS-3200 trap added

V1b5 22.06.09 Dan Shalem How to set devices (NE, NX, SG, SMP, STC) to

send traps to external server & how to set NX to

send traps to external server both added.

V1b6 12.07.09 Dan Shalem More information about statistics

V1b7 14.07.09 Dan Shalem Procedure for NX KPIs updated

V1b8 27.10.09 Dan Shalem alUserDefinedSignature, extra alSMPSystemTrap

for PCRF integration and examples of SG KPIs

V1b9 28.10.09 Dan Shalem Updated to Allot.Mib rev 200909021333Z

V1b10 05.11.09 Dan Shalem Updated to Allot.Mib rev 200910290948Z New

KPIs added.

V1b11 09.11.09 Dan Shalem Minor Errors fixed

V1b12 14.12.09 Dan Shalem Updated to Allot.mib rev 200912011518

V1b13 03.01.10 Dan Shalem Updated to Allot.mib rev 200912221326Z

V1b14 04.02.10 Dan Shalem Updated to Allot.mib rev from 04.02.2010; Fixed

syntax errors on p9

V2b1 10.05.10 Dan Shalem Updated with new SNMP features for AOS10.2.1

V2b2 22.07.10 Dan Shalem Additional Events

V2b3 17.08.10 Dan Shalem Missing SMP KPI added

V2b4 12.09.10 Dan Shalem Interface statistics on SG-Sigma added

Trap Forwarding Section updated

V2b5 13.09.10 Dan Shalem Updated to AOS11.1 and NX11.1

V2b6 25.11.10 Dan Shalem Updated to Allot.mib rev 201011181000Z



Product Versioning

This SNMP integration guide is verified as correct for the following product versions

NOTE: Some of the features documented here are available only for some of the products listed below. Wherever this is the case, a note is added in the document

Product Version

NetXplorer NX11.1

SMP SMP11.1

Short-Term Monitoring Collector MD11.1

SG-Sigma, AC-1400, AC-3000,

AC-5000, AC-10000

AOS11.1

SG-Omega SG9.1.1

AC-400/800 Series E9.1.0

AC-1000 Series S9.1.0

AC-2500 Series C9.1.1

Allot MIBs Revision

allot.mib 201011181000Z

allot-nx-mib.mib 200811090915Z

allot-smp-snmp-mib.mib 200902251342Z

ne-stat-mib.mib 200408111040Z



Table of Contents

Version History ........................................................................................................................ 3

Overview ................................................................................................................................... 8

Available MIB Files ................................................................................................................ 9

SNMP Traps .............................................................................................................................. 9

How to Send Traps from NE/SG/SMP/STC to External Server ............................................ 9

Sending Traps in SNMPv3 format .................................................................................... 9

Sending Traps in SNMPv2 format .................................................................................. 10

Sending Traps in SNMPv1 format .................................................................................. 10

Sending Traps to Additional Servers .............................................................................. 11

Deleting the Trap Server ................................................................................................. 11

Viewing the Trap Server Currently Configured ............................................................... 12

How to Send Traps from NX to External Server ................................................................. 13

Configuring the NX Server .............................................................................................. 13

List of Traps Sent from Allot Network Elements ................................................................. 16

NE & SG Traps ............................................................................................................... 16

SMP Server Traps .......................................................................................................... 18

SMP Storage Device Traps ............................................................................................ 21

IBM RSA-II Traps ............................................................................................................ 21

NX Trap Forwarding ........................................................................................................ 24

Key Performance Indicators & Health Monitoring ............................................................. 29

Service Gateway ................................................................................................................. 29

Temperature ................................................................................................................... 31

Fans ................................................................................................................................ 34

Power Supply .................................................................................................................. 35

CPU ................................................................................................................................. 36

Memory ........................................................................................................................... 37

Storage............................................................................................................................ 38

CER ................................................................................................................................. 39

NOC ................................................................................................................................ 40

Active Lines ..................................................................................................................... 41

Active Pipes .................................................................................................................... 42

Active VCs ...................................................................................................................... 43

Registered Subscribers ................................................................................................... 44

Software Status ............................................................................................................... 45

Hardware Status ............................................................................................................. 46

NetXplorer ........................................................................................................................... 47

Preparing the NX Server (NET-SNMP Tools)................................................................. 47



Disk Usage ...................................................................................................................... 49

CPU Usage ..................................................................................................................... 50

SMP and STC ..................................................................................................................... 51

Disk Usage ...................................................................................................................... 51

CPU ................................................................................................................................. 52

Incoming Subscriber Provisioning Messages ................................................................. 53

Number of Registered Subscribers ................................................................................. 54

High Availability Status ................................................................................................... 55

Additional KPIs (Using RSA-II Card) .............................................................................. 56

Statistics Monitoring ............................................................................................................. 57

Polling NetEnforcer for Statistics......................................................................................... 57

Step #1: Determining SNMP IDs .................................................................................... 57

Step #2: Turning on MIBs for these SNMP IDs .............................................................. 57

Step #3: Poll the relevant MIBs ...................................................................................... 58

Polling SG-Sigma for Statistics ........................................................................................... 59

Polling NetXplorer for Statistics (MRTG Only) .................................................................... 60

Appendix A: Allot MIB Structure .......................................................................................... 64

Appendix B: KPIs Per SG Blade ........................................................................................... 65

SG-Sigma ............................................................................................................................ 65

SG-Omega .......................................................................................................................... 66

Examples ............................................................................................................................. 67

Running an snmpget Command ..................................................................................... 67

Running an snmpwalk Command ................................................................................... 67

Appendix C: Allot MIB in Detail ............................................................................................ 68

Events Group ...................................................................................................................... 68

Activation Group .................................................................................................................. 69

Activation Limits Subgroup ............................................................................................. 69

Objects Group ..................................................................................................................... 70

Products Subgroup ......................................................................................................... 70

Generic Subgroup ........................................................................................................... 70

Provisioning/Catalogs Subgroup .................................................................................... 73

Provisioning/Policies Subgroup ...................................................................................... 73

Statistics Subsgroup ....................................................................................................... 74

Alerts Subgroup .............................................................................................................. 74

LoadConfig Subgroup ..................................................................................................... 77

Conf Group .......................................................................................................................... 78

Groups Subgroup ............................................................................................................ 78

Compls Subgroup ........................................................................................................... 78

NXMIB Group ...................................................................................................................... 78



Events Subgroup ............................................................................................................ 78

Objects Subgroup ........................................................................................................... 78

Conf Subgroup ................................................................................................................ 78

SNMP Glossary ...................................................................................................................... 80



Overview The Allot solution typically requires the deployment of equipment at the Network Element Layer and the Element Management System layer of the service provider or carrier network.

At the Network Element Layer, NetEnforcer (NE) and Service Gateway (SG) devices are responsible for implementing application control and subscriber management policies and collecting network usage data.

At the Element Management System Layer, the NetXplorer (NX) manages and communicates with the different clients that access the system. It facilitates NetEnforcer or Service Gateway configuration, policy provisioning, alarms, monitoring and reporting. The NetXplorer also includes an integrated data collector, which streamlines the required collection of data from the NE or SG devices. Distributed Short Term Data Collectors (STCs) are also sometimes required in large deployments. Finally, when the Subscriber Management Platform (SMP) is deployed, an SMP server integrates with the Service Providers IP allocation system and OSS to ensure subscriber-level awareness and policy enforcement for the Allot solution.

At the Network Element layer, the NE and SG devices run standard SNMP Agents which communicate over SNMP V1/V2 or V3 and maintain standard MIB-II information together with Allot MIB extensions. These MIB extensions maintain information on the device such as alarms, statistics and status. The SNMP Agent enables the NE or SG to be remotely configured and controlled, and includes the ability to set traps on major KPI values.



Available MIB Files

4 different Allot MIB files are available for use as needed:

Name Description

ALLOT.mib MIB file for use with all NetEnforcers using NetXplorer

management, and all Service Gateway products.

ALLOT-NX-MIB.mib MIB file used for SNMP communication with NetXplorer server. The NetXplorer forwards various alarms collected from its managed nodes.

ALLOT-SMP-SNMP-MIB.mib MIB file for use with SMP and STC devices. Serves as an extension to ALLOT.mib

NE-STAT-MIB.mib MIB file used to enable SNMP compatibility for all NetEnforcers using basic management (i.e not managed by the NetXplorer Centralized management system)

SNMP Traps The Allot Network elements (NetEnforcer and/or Service Gateway) send standard SNMP traps both to the NetXplorer and to the Service Provider or Carriers monitoring system. The SMP server, which is part of the Element Management System Layer also sends traps to the NX server and to a third party server where defined. In addition, the NetXplorer can serve as a single point of integration for system administrators. Its SMP agent forwards traps to the NOC collected from the managed entities.

How to Send Traps from NE/SG/SMP/STC to External Server

The procedure below outlines how to set up an Allot NetEnforcer (running NX version), a Service Gateway, an SMP Server or a Short Term Collector to send SNMP traps to an external server in addition to the NetXplorer server. In each of the cases described below, the snmpset command should be executed from an external application that has the option to run snmpset on SNMPv3.

NOTE: The Allot SGSV blade is capable of running snmpset commands for the SG-Omega. In this case, there is no need for an external application to run snmpset.

NOTE: When running snmpset from any Linux machine (including when snmpset is run from the SG-Omega SGSV blade, you need to add \ (backslash) before any apostrophe (). For example:

Windows: .1.3.6.1.6.3.12.1.3.1.2.'send_all_v1' would become:

Linux (or SGSV): .1.3.6.1.6.3.12.1.3.1.2.\'send_all_v1\'

NOTE: All snmpset commands below need to fit on a single line. Instead of performing copy/paste from this document, it is advised to copy into notepad, ensure that there are no line breaks, and paste from there.

Sending Traps in SNMPv3 format

The snmpset command below shows how using a machine that can run snmpset v3, you can set the NE, SG, SMP or STC to send SNMPv3 traps.

The command input is written below. Insert the IP address of the NE, SG, SMP or STC instead of . Insert the IP address of the server to which you require traps to be sent instead of .



snmpset -v 3 -u MD5 -a MD5 -A MD5UserAuthPassword12 -l authNoPriv .1.3.6.1.6.3.12.1.2.1.2.66 o .1.3.6.1.6.1.1 .1.3.6.1.6.3.12.1.2.1.3.66 d .0.162 .1.3.6.1.6.3.12.1.2.1.6.66 s v3trap .1.3.6.1.6.3.12.1.2.1.7.66 s send_all .1.3.6.1.6.3.12.1.2.1.9.66 i 4

snmpset -v 3 -u MD5 -a MD5 -A MD5UserAuthPassword12 -l authNoPriv .1.3.6.1.6.3.12.1.3.1.2.'send_all_v1' i 1 .1.3.6.1.6.3.12.1.3.1.3.'send_all_v1' i 2 .1.3.6.1.6.3.12.1.3.1.4.'send_all_v1' s v1v2Config .1.3.6.1.6.3.12.1.3.1.5.'send_all_v1' i 1 .1.3.6.1.6.3.12.1.3.1.7.'send_all_v1' i 4

snmpset -v 3 -u MD5 -a MD5 -A MD5UserAuthPassword12 -l authNoPriv .1.3.6.1.6.3.12.1.2.1.2.'B' o .1.3.6.1.6.1.1 .1.3.6.1.6.3.12.1.2.1.3.'B' d .0.162 .1.3.6.1.6.3.12.1.2.1.6.'B' s v3trap .1.3.6.1.6.3.12.1.2.1.7.'B' s send_all_v1 .1.3.6.1.6.3.12.1.2.1.9.'B' i 4

snmpset -v 3 -u MD5 -a MD5 -A MD5UserAuthPassword12 -l authNoPriv .1.3.6.1.6.3.13.1.2.1.1.'send_all_v1' s send_all_filter .1.3.6.1.6.3.13.1.2.1.3.'send_all_v1' i 4

snmpset -v 3 -u MD5 -a MD5 -A MD5UserAuthPassword12 -l authNoPriv .1.3.6.1.6.3.12.1.3.1.2.'send_all_v1' i 0 .1.3.6.1.6.3.12.1.3.1.3.'send_all_v1' i 1 .1.3.6.1.6.3.12.1.3.1.4.'send_all_v1' s v1v2Config .1.3.6.1.6.3.12.1.3.1.5.'send_all_v1' i 1 .1.3.6.1.6.3.12.1.3.1.7.'send_all_v1' i 4

snmpset -v 3 -u MD5 -a MD5 -A MD5UserAuthPassword12 -l authNoPriv .1.3.6.1.6.3.12.1.2.1.2.'B' o .1.3.6.1.6.1.1 .1.3.6.1.6.3.12.1.2.1.3.'B' d .0.162 .1.3.6.1.6.3.12.1.2.1.6.'B' s v3trap .1.3.6.1.6.3.12.1.2.1.7.'B' s send_all_v1 .1.3.6.1.6.3.12.1.2.1.9.'B' i 4


The instructions below show how using a machine that can run snmpset v3, you can set the NE, SG, SMP or STC to send SNMPv2 traps.

1. Add a row to snmpTargetParamsTable

2. Add new entry to NotifyAddrTable

3. add row in snmpNotifyFilterProfileTable


The instructions below show how using a machine that can run snmpset v3, you can set the NE, SG, SMP or STC to send SNMPv1 traps.

1. Add a row to snmpTargetParamsTable

2. Add new entry to NotifyAddrTable



snmpset -v 3 -u MD5 -a MD5 -A MD5UserAuthPassword12 -l authNoPriv .1.3.6.1.6.3.13.1.2.1.1.'send_all_v1' s send_all_filter .1.3.6.1.6.3.13.1.2.1.3.'send_all_v1' i 4

snmpset -v 3 -u MD5 -a MD5 -A MD5UserAuthPassword12 -l authNoPriv .1.3.6.1.6.3.12.1.2.1.2.67 o .1.3.6.1.6.1.1 .1.3.6.1.6.3.12.1.2.1.3.67 d .0.162 .1.3.6.1.6.3.12.1.2.1.6.67 s v3trap .1.3.6.1.6.3.12.1.2.1.7.67 s send_all .1.3.6.1.6.3.12.1.2.1.9.67 i 4

snmpset -v 3 -u MD5 -a MD5 -A MD5UserAuthPassword12 -l authNoPriv .1.3.6.1.6.3.12.1.2.1.9. i 6

3. add row in snmpNotifyFilterProfileTable

Sending Traps to Additional Servers

If you wish the NetEnforcer, Service Gateway, SMP Server or Short Term Collector to send traps to more than one SNMP server, the same command must be entered with a different index number. The index number of the NetXplorer is 65.83. The index number used in all of the examples above is 66. When sending traps to additional servers, make sure that the index is not less than 66. The index can for example be 67, 68 etc.

In the example below we use an index of 67. Note that the index appears in 5 different places in the snmpset command.

Deleting the Trap Server

If you wish the NetEnforcer, Service Gateway, SMP Server or Short Term Collector to stop sending traps to an additional trap server, use the following snmpset command. Replace with the index number (or ASCII notation string value) of that particular external trap server. E.g: in the example above where we added an additional trap server with an index of 67, we would insert in the command below 67.



snmpwalk -v 3 -u MD5 -a MD5 -A MD5UserAuthPassword12 -l authNoPriv 127.0.0.1 .1.3.6.1.6.3.12.1.2.1

iso.3.6.1.6.3.12.1.2.1.2.66 = OID: iso.3.6.1.6.1.1

iso.3.6.1.6.3.12.1.2.1.2.65.83 = OID: iso.3.6.1.6.1.1

iso.3.6.1.6.3.12.1.2.1.3.66 = Hex-STRING: CB 50 7B 4F00 B2

iso.3.6.1.6.3.12.1.2.1.3.65.83 = Hex-STRING: CB 50 7A 34 00 A2

iso.3.6.1.6.3.12.1.2.1.4.66 = INTEGER: 1500

iso.3.6.1.6.3.12.1.2.1.4.65.83 = INTEGER: 1500

iso.3.6.1.6.3.12.1.2.1.5.66 = INTEGER: 3

iso.3.6.1.6.3.12.1.2.1.5.65.83 = INTEGER: 1

iso.3.6.1.6.3.12.1.2.1.6.66 = STRING: "v3trap"

iso.3.6.1.6.3.12.1.2.1.6.65.83 = STRING: "v3trap"

iso.3.6.1.6.3.12.1.2.1.7.66 = STRING: "send_all_v1"

iso.3.6.1.6.3.12.1.2.1.7.65.83 = STRING: "send_all"

iso.3.6.1.6.3.12.1.2.1.8.66 = INTEGER: 3

iso.3.6.1.6.3.12.1.2.1.8.65.83 = INTEGER: 3

iso.3.6.1.6.3.12.1.2.1.9.66 = INTEGER: 1

iso.3.6.1.6.3.12.1.2.1.9.65.83 = INTEGER: 1

Viewing the Trap Server Currently Configured

If you wish to view which devices the NetEnforcer, ServiceGateway, SMP Server or Short Term Collector is configured to send traps to, use the following snmpwalk command (the example given is for snmpv3).

The output will look something like this:

In the third line in the output above, the 4 left hexa octets (CB 50 7B 4F) are the IP of the NX server. In the fourth line of the output above, the 4 left hexa octets (CB 50 7A 34) represent the IP address of the additional trap server.



How to Send Traps from NX to External Server

The following steps describe how to configure the NetXplorer server to forward certain predefined events collected from the different NetEnforcer , SMP, STC and Service Gateway devices to an external server.

Configuring the NX Server

Where to Send the Traps

To configure the external server to which traps from the NetXplorer should be sent, follow the procedure below:

1. From the network pane in the NetXplorer GUI, choose Network

2. Right click and select Configuration

3. Select the SNMP Tab

4. Set the appropriate community for the external trap server by filling in the Community field in the NX Agent window. The default community is public

5. Click on Add and enter the target IP address of the external trap server and the target port. The default target port is 162.

6. Choose OK. The chosen external trap server will appear in the Trap Target dialog.

Which Traps To Send

All events created by the Allot NE, SG, SMP and STC are automatically sent to the Allot NetXplorer Server, and appear in the server events log. If an external trap server has been defined, some of these events are automatically sent to it. For other events, the administrator can decide whether to send traps or not. This is done by clicking the External Trap checkboxes in the Event Types Configuration screen which is accessed from the Events/Alarms pane in the NetXplorer GUI, as shown below.



Consult with the table below to see which traps are sent automatically to an external server (marked in the column Auto), and which need to be defined manually from the event types configuration screen (marked in the column Man)

ID

Event

Sent to External Server

Auto Man

1 Rising TCA (Threshold Crossing Alarm)* X

3 Device Configuration X

4 Line Policy Change X

5 Pipe Policy Change X

6 Virtual Channel Policy Change X

7 Catalog Entry Change X

8 Suspected DoS Attack Started* X

10 External Data Source Down X

14 Link Down X

16 Cold Start X

19 NetEnforcer IP Address Change X

21 Device Status Down X

23 Application Info X

100 Server Unreachable X

102 Device Unreachable X



107 Device Hardware Change X

116 Server Management Ownership Taken from Device X

117 Server Management Ownership of Device Taken X

120 License expiration warning X

121 License is expired X

122 Server license registered X

124 Device policy replaced with rescue policy X

126 AS does not support device software version X

129 Catalog action failed X

132 Country classification file updated X

133 New Protocol updates are available** X

134 Install new protocol updates to AS** X

135 Install new protocol updates to device** X

137 Device license expiration warning X

138 Device license is expired X

140 Rollback AS protocol updates** X

141 Rollback device protocol updates** X

142 Asymmetric remote device configuration changed X

143 Asymmetric remote device HealthCheckStatus changed X

146 Blacklist server status up X

147 Blacklist server down X

148 License warning X

149 License critical X

200 Collector Reported Device Unreachable X

202 Invalid Bucket Time in Collector X


212 Collector Reported Disk Space Problem X

300 Long Term Collector Reported Short Term Collector Unreachable X


304 Long Term Collector Reported Disk Space Problem X

404 SMP provision error trap X

405 SMP multi fail trap X

406 SMP High Availability Trap X

407 SMP System Trap X

500 Disk Storage Trap X



NOTE: Event ID 1 is not supported by the Service Gateway and AC-10000 series. Event ID 8 is not supported by AOS devices

NOTE: Events 133,134,135, 140 and 141 are supported by the SG-Omega from SG9.1.1 onwards

List of Traps Sent from Allot Network Elements

NE & SG Traps

The traps that are sent are listed below are divided into traps which are part of the private Allot MIB, and standard traps. For each trap, the name, OID and an explanation are listed in the tables below.

Allots Private MIB

Each of the traps below begins with the OID: 1.3.6.1.4.1.2603.0

Name Description OID

alDeviceConfChangeTrap This trap is sent when one of

generic status variables on the

NetEnforcer or Service Gateway

is changed. (e.g: change to host

name of device). The generic

status variable is defined in the

MIB table

alGenericLastChangeVar

1.3.6.1.4.1.2603.0.1

alCatalogConfChangeTrap This trap is sent if a configuration change has been made on one of the catalogs (e.g: a new catalog has been added or an existing catalog has been modified.

1.3.6.1.4.1.2603.0.2

alLineConfChangeTrap This trap is sent if a configuration change has been made on one of the lines (e.g: a line has been added, or a catalog has been assigned to an existing line)

1.3.6.1.4.1.2603.0.3

alPipeConfChangeTrap This trap is sent if a configuration change has been made on one of the pipes (e.g: a pipe has been added, or a catalog has been assigned to an existing pipe)

1.3.6.1.4.1.2603.0.4

alVCConfChangeTrap This trap is sent if a configuration change has been made on one of the virtual channels (e.g: a VC has been added, or a catalog has been assigned to an existing VC)

1.3.6.1.4.1.2603.0.5

alAlertRisingTrap This trap is sent if one of the alerts crossed the defined threshold. For the SG, only disk overflow and memory overflow can be defined.

1.3.6.1.4.1.2603.0.6

alAlertFallingTrap This trap is sent if the alert value returned below the normal threshold

1.3.6.1.4.1.2603.0.7

alDataSourceDownTrap This trap is sent if the data source is unreachable (e.g: NTP server is unreachable). The relevant data source is listed in the trap and list of data sources is

1.3.6.1.4.1.2603.0.10




contained in alDataSourceType. Currently the trap will only be sent for the NTP data source.

alDataSourceUpTrap This trap is sent once the data source is reachable again (e.g: NTP server can now be reached)

1.3.6.1.4.1.2603.0.11

alSoftwareProblemTrap This trap is sent in the event of a severe internal software problem. If you receive this trap you should contact [email protected] for assistance.

1.3.6.1.4.1.2603.0.12

alAccessViolationTrap This trap is sent if an access violation attempt is discovered at the Linux level.

1.3.6.1.4.1.2603.0.13

alIpAddrConfChangeTrap This trap is sent if the IP Address of the management port has been added, removed or modified.

1.3.6.1.4.1.2603.0.14

alConnRouteConfChangeTrap This trap is sent if there has been a change in the connection routing configuration.

1.3.6.1.4.1.2603.0.15

alDeviceStatusUpTrap This trap is sent if any of the following device status changed from down to up:

Bypass Setting (for parallel redundancy only)

Power Status

Fan Status

Remote Bypass

Bypass The reading is taken from the alSystemStatus table.

1.3.6.1.4.1.2603.0.16

alDeviceStatusDownTrap This trap is sent if any of the device status listed above have changed from up to down.

1.3.6.1.4.1.2603.0.17

alApplicationInfoTrap This trap is for information only, and is reserved for customization as per requirements.

1.3.6.1.4.1.2603.0.18

alBoardStatusChangeTrap This trap is sent if the hardware or software status of any of the cards in a multi-board chassis (e.g: SG, AC-10000) has been changed. The trap will list the following:

Board ID this indicates the slot number of the card

Board Type this can be for example, any of the following: o third party o apc (SGCC) o dpic (SGFP) o host (SGSV-110) o byc (SGBP) o spider (CC-220) o switch (SFC-200) o dispatcher (FB-200) o bypass (BP-204) o VAS (NSS-MS/SP)

Board Software Status

1.3.6.1.4.1.2603.0.19




(SGFP) o not active (SGFP

bypass) o active o standby o NA

Board HW status (off/on)

alWebUpdateTrap This trap will be sent for each attempted web update. This trap is supported by the SG-Omega from SG9.1.1 onwards.

1.3.6.1.4.1.2603.0.20

alAsymmetricRemoteDeviceConfTrap This trap will be sent when the configuration of an asymmetric remote device is changed or if such a device has been added or removed.

1.3.6.1.4.1.2603.0.21

alAsymmetricRemoteDeviceStatusTrap This trap will be sent when the health check of an asymmetric remote device changes.

1.3.6.1.4.1.2603.0.22

alLicenseWarnEventTrap This trap will be sent for warning level states of the license. The trap includes details about the license parameter and its value.

1.3.6.1.4.1.2603.0.23

alLicenseCritEventTrap This trap will be sent for critical level states of the license. The trap includes details about the license parameter and its value.

1.3.6.1.4.1.2603.0.24

alBoardTemperatureStatusTrap This trap is sent when temperature crosses the range border

1.3.6.1.4.1.2603.0.25

SNMP Standard Traps

Each of the traps below are not part of the Allot private MIB, but belong to the standard SNMPv2 MIB. Each one begins with the OID: 1.3.6.1.6.3.1.1.5


coldStart This trap is sent if the NE or SG is reinitializing itself (e.g: reboot)

1.3.6.1.6.3.1.1.5.1

linkDown This trap is sent if one of the communication links on the NE or SG is about to go down. E.g: when disconnecting internal or external interfaces

1.3.6.1.6.3.1.1.5.3

linkUp This trap is sent if one of the communication links on the NE or SG is about to go up. E.g: when connecting internal and external interfaces

1.3.6.1.6.3.1.1.5.4

authenticationFailure This trap is sent if the NE or SG has received a protocol message that is not properly authenticated. (e.g: request for wrong community

1.3.6.1.6.3.1.1.5.5

SMP Server Traps

The SMP server sends 4 different types of traps to the NetXplorer. These traps can also be sent to the Service Providers NOC.


SMPProvisionErrTrap This trap is sent whenever the SMP server fails to provision a particular

1.3.6.1.4.1.2603.5.5.20.1.1




subscriber. The details included in the trap are:

Initiating Process (see below)

Provisioning Type (see below)

Fail Cause (see below)

Subscriber Name

Subscriber IP

SMPMultiFailTrap This trap is sent whenever the same provision errors are received for multiple subscribers . It includes the following details:


Fail Cause (see below)

1.3.6.1.4.1.2603.5.5.20.1.2

SmpHighAvailabilityTrap This trap is sent whenever there is a failure in the SMP high availability cluster. It includes the following details:

Fail Cause

HighAvailabilityStatus 0. active 1. passive 2. dead

1.3.6.1.4.1.2603.5.5.20.1.3

SMPSystemTrap This trap is sent if there is a communication problem between the PCC process and one (or both) of the external PCRFs. It includes the following details:


System Subject. Currently only: 0. none 1. pcrf

System Cause. Currently only: 101. Loss of

Communicatopm 102. Communication

Restablished

System Info

1.3.6.1.4.1.2603.5.5.20.1.4

Initiating Process

The SMPProvisionErr and SMPMultiFail traps detail the process which initiated the error. The process can be any of the following:

10: FastUpdate Process (responsible for communication between the SMP Server and SG/NE

50: SMF (responsible for mapping of IP address, subscriber name and service plan)

60: SMP Router (responsible for routing RADIUS or DHCP messages to the smf function, and in a distributed environment, for routing these messages to different SMP servers)

70: Quota Management (responsible for calculating the subscribers quota usage)

80: Event Distributor (responsible for sending updates with subscriber data from the SMP to the NX)

90: High Availability (responsible for the high availability cluster)

100: pcc (when SMP is integrated with an external PCRF)



Provisioning Type

In an SMPProvisionErr, the provisioning type information is also given. This indicates whether the error was in a start message (0), a stop message (1) or a timeout (2) for a given subscriber.

Fail Cause

The SMPProvisionErr and SMPMultiFail traps detail the cause of the failure. The cause recorded can be any of the following:

0. Unknown Cause

1. Invalid Parameter

2. Subscriber Limit Has Been Reached

3. Domain Not Found

4. Unknown Subscriber

5. Communication Error

6. Subscriber Timeout

7. SMP Node StartUp

8. HeartBeat SwitchOver (for high availability configurations)

9. Passive Node Not Synched (for high availability configurations)

10. Passive Node Down (for high availability configurations)

11. Host Not Active

12. IP Not Assigned to Host

14. Unknown IP



SMP Storage Device Traps

When an SMP HA platform is deployed, a storage device is deployed in addition to the 2 SMP servers. The storage device is based on IBM DS-3200 hardware and can also be configured to send a trap in cases where user intervention is required. IBM provides the following MIB file to enable interpretation of this trap:

SM10_R2.MIB


storageArrayCritical User-intervention is required. Includes

the following information:

Device IP Type (unknown,

ipv4, ipv6)

Device IP address

Device Host Name

Device User Label

Device Error Code

Event Time

Trap Description

Component Type

Component Location

.1.3.6.1.4.1.1123.4.500.2

IBM RSA-II Traps

If an IBM RSA-II is included in the SMP Server spec, additional traps will also be sent from the SMP server. IBM provides the following MIB files to enable interpretation of these traps:

RTALERT.MIB: IBM RSA II traps

RTRSAAG.MIB: IBM RSA II MIBs for SNMP

The traps are divided into critical, non-critical and system traps. Each trap contains the following information:

Timestamp

Application ID (always Remote Supervisor Adapter)

System ID (text identification)

System ID (numeric identification)

Host system universal ID

Host system serial number

Event ID

Alert Severity Value

o 0: Critical Alert

o 2: Non-Critical Alert

o 4: System Alert

o 8: Recovery Alert

o 255: Information Only Alert

Alert Message Text



Host Contact

Host Location

Critical Traps


ibmSpTrapTempC Critical Alert: Temperature threshold

exceeded

1.3.6.1.4.1.2.6.158.4.4.2.1.1

ibmSpTrapVoltC Critical Alert: Voltage threshold

exceeded

1.3.6.1.4.1.2.6.158.4.4.2.1.2

ibmSpTrapTampC Critical Alert: Physical intrusion of

system has occurred

1.3.6.1.4.1.2.6.158.4.4.2.1.3

ibmSpTrapMffC Critical Alert: Multiple fan failure 1.3.6.1.4.1.2.6.158.4.4.2.1.4

ibmSpTrapPsC Critical Alert: Power supply failure 1.3.6.1.4.1.2.6.158.4.4.2.1.5

ibmSpTrapHdC Critical Alert: Hard disk drive failure 1.3.6.1.4.1.2.6.158.4.4.2.1.6

ibmSpTrapVrmC Critical Alert: Voltage Regulator

Module(VRM) failure

1.3.6.1.4.1.2.6.158.4.4.2.1.7

ibmSpTrapSffC Critical Alert: Single Fan failure 1.3.6.1.4.1.2.6.158.4.4.2.2.2

ibmSpTrapIhcC Critical Alert: Incompatible hardware

configuration

1.3.6.1.4.1.2.6.158.4.4.2.1.9

Non Critical Traps


ibmSpTrapRdpsN Non-Critical Alert: Redundant Power

Supply failure

1.3.6.1.4.1.2.6.158.4.4.2.2.1

ibmSpTrapTempN Non-Critical Alert: Temperature

threshold exceeded

1.3.6.1.4.1.2.6.158.4.4.2.2.3

ibmSpTrapVoltN Non-Critical Alert: Voltage threshold

exceeded

1.3.6.1.4.1.2.6.158.4.4.2.2.4

ibmSpTrapRmN Non-Critical Alert: Redundant module 1.3.6.1.4.1.2.6.158.4.4.2.2.6

System Traps


ibmSpTrapRLogin Sev-Off Alert: Event Remote Login 1.3.6.1.4.1.2.6.158.4.5.2.6

ibmSpTrapLogFull Sev-Off Alert: Event error log 100

percent full

1.3.6.1.4.1.2.6.158.4.5.2.8

ibmSpTrapLog75 Sev-Off Alert: Event error log 75

percent full

1.3.6.1.4.1.2.6.158.4.5.2.12

ibmSpTrapSecDvS System Alert: Secondary Device

warning

1.3.6.1.4.1.2.6.158.4.5.2.14

ibmSpTrapPostToS System Alert: Post Timeout value

exceeded

1.3.6.1.4.1.2.6.158.4.4.2.3.1

ibmSpTrapOsToS System Alert: OS Timeout value

exceeded

1.3.6.1.4.1.2.6.158.4.4.2.3.2

ibmSpTrapAppS System Alert: Application Alert 1.3.6.1.4.1.2.6.158.4.4.2.3.3

ibmSpTrapPoffS System Alert: Power Off 1.3.6.1.4.1.2.6.158.4.4.2.3.4

ibmSpTrapPonS System Alert: Power On 1.3.6.1.4.1.2.6.158.4.4.2.3.5




ibmSpTrapBootS System Alert: System Boot Failure 1.3.6.1.4.1.2.6.158.4.4.2.3.6

ibmSpTrapLdrToS System Alert: OS Loader Timeout 1.3.6.1.4.1.2.6.158.4.4.2.3.7

ibmSpTrapPFAS System Alert: Predictive Failure

Analysis(PFA) information

1.3.6.1.4.1.2.6.158.4.4.2.3.8

ibmSpTrapKVMSwitchS System Alert:

Keyboard/Video/Mouse(KVM) or

Medial Tray(MT) switching failure

1.3.6.1.4.1.2.6.158.4.4.2.3.9

ibmSpTrapSysInvS System Alert: Inventory 1.3.6.1.4.1.2.6.158.4.4.2.3.10

ibmSpTrapSysLogS System Alert: System Log 75% full 1.3.6.1.4.1.2.6.158.4.4.2.3.11

ibmSpTrapNwChangeS System Alert: Network change

notification

1.3.6.1.4.1.2.6.158.4.4.2.3.12



NX Trap Forwarding

The NetXplorer forwards trappable alarms and sends them to the NOC. There are two types of traps which are forwarded:


alAlarmRisingTrap This trap is sent when an alarm is raised 1.3.6.1.4.1.2603.10.0.1

alAlarmFallingTrap This trap is sent when an alarm is cleared 1.3.6.1.4.1.2603.10.0.2

Traps can be forwarded for any of the alarms in the table below. Note the Alarm ID for each one. This alarm ID appears in the details for each trap.

ID Name Description Severity

1 Rising TCA Indicates a threshold crossing Alarm.

(Note: for the Service Gateway or AC-

10000 series, this can only be Memory

Overflow or Disk Overflow)

Minor

10 External Data Source Down

Indicates that a datasource is down Major

14 Link Down Indicates that a link has been

disconnected

Major

21 Device Status Down Indicates that the SG or NE is not active Major

23 Over subscription has occurred

Indicates a bandwidth allocation failure

(e.g: sum of minimums in low hierarchy is

higher than upper hierarchy max)

Indeterminate

25 Board Status Changed Indicates a change in the hardware or

software status of a blade

Indeterminate

100 Server Unreachable Indicates that there is no connectivity

between the NX and the SG or NE

Critical

102 Device Unreachable Indicates that the SG or NE cannot be

pinged

Critical

116 Server Management Ownership Taken from Device

Indicates that a second NX server has

added the NE or SG thus removing it

from the previous NX.

Major

117 Server Management Ownership of Device Taken

Major

120 License expiration warning

Indicates that the NX license is about to

expire

Critical

121 License is expired The NX license has expired Critical

122 Server license registered

A new NX license has been registered Indeterminate

124 Device policy replaced with rescue policy

The existing policy has been replaced

with the default one. Usually due to a

software related problem.

Critical

126 AS does not support device software version

Indicates that invalid firmware has been

used on NetEnforcer or Service Gateway

Critical

129 Catalog action failed The distribution of a catalog entry from

the NX server to the NE or NX failed

Indeterminate

132 Country classification file updated

Indicates that the country classification Indeterminate



ID Name Description Severity

file on the NX server has been updated

133 New protocol updates are available

Indicates that a new protocol pack is

available for download (not supported on

the SG-Omega)

Indeterminate

134 Install new protocol updates to AS

Indicates that a new protocol pack has

been installed on the NX server

Indeterminate

135 Install new protocol updates to device

Indicates that a new protocol pack has

been installed on the NetEnforcer or SG

Indeterminate

137 Device license expiration warning

Indicates that the NE or SG license is

about to expire

Critical

138 Device license is expired

Indicates that the NE or SG license has

expired

Critical

140 Rollback AS protocol updates

Indicates that the NX has been

successfully rolled back to the previously

installed protocol pack

Indeterminate

141 Rollback device protocol updates

Indicates that the NE has been

successfully rolled back to the previously

installed protocol pack (not supported on

SG-Omega)

Indeterminate

143 Asymmetric remote device HealthCheckStatus changed

The status of the remote asymmetric

device changed (to up or down)

Major

145 Blacklist source down The Websafe blacklist source is down Major

147

Blacklist server down

The server from which the websafe

blacklist is drawn is down

Major

148

License warning

A particular licensing parameter has

reached 70% of its limit

Major

149

License critical

A limiting licensing parameter has been

breached

Critical

150 Board temperature status

Indicates that the temperature of a

particular blade has crossed a threshold

Intermediate

200 Collector Reported Device Unreachable

Indicates that the data collector cannot

ping or access the NE or SG for short

term data collection.

Critical

202 208 302

Invalid Bucket Time in Collector

Indicates that the time on the SG or NE

and NX or Data Collector is not

synchronized.

Critical

212 Collector Reported Disk Space Problem

There is less than 10% free space on the

Short Term Collector hard disk.

Critical

300 Long Term Collector Reported Short Term Collector Unreachable

Indicates that the long term data

collection process cannot gather from the

short term database.

Critical

304 Long Term Collector Reported Disk Space Problem

There is less than 10% free space on the

Long Term Collector hard disk.

Critical

500 Disk Storage Trap The storage device reported an error Major



The trap received will also include the following four OIDs which provide the administrator with information about the alarm which has been raised or cleared:

AlSeverity: 1.3.6.1.4.1.2603.10.2.1.1.6

AlDescription: 1.3.6.1.4.1.2603.10.2.1.1.7

AlTimestamp: 1.3.6.1.4.1.2603.10.2.1.1.8

AlIndex: 1.3.6.1.4.1.2603.10.2.1.1.9

We will examine each one of these in turn.

AlSeverity

The OID which will be displayed is as follows:

1.3.6.1.4.1.2603.10.2.1.1.6.a.b.c.d.alarm.x.y.z = integer N

Where:

a.b.c.d IP address of the NE or SG from which the alarm was received alarm Alarm ID (as per table above) x Card ID (0 by default) y Source ID (0 by default) z TCA threshold crossing alarm ID N Alarm severity (as per table below)

The alarm severity values which will be displayed in the trap are as follows

Value Meaning

0 Unknown

1 Cleared

2 Indeterminate

3 Critical

4 Major

5 Minor

6 Warning

AlDescription


1.3.6.1.4.1.2603.10.2.1.1.7.a.b.c.d.alarm.x.y.z = STRING

The fields a.b.c.d.alarm.x.y.z are as described in AlSeverity above. The STRING here will contain a description of the alarm, which will only be seen for a rising trap.

AlTimestamp


1.3.6.1.4.1.2603.10.2.1.1.8.a.b.c.d.alarm.x.y.z = Counter 64

The fields a.b.c.d.alarm.x.y.z are as described in AlSeverity above. The timestamp for the alarm is presented here in UTC format.



2010-07-07 16:51:17 10.4.70.20 [UDP: [10.4.70.20]:161]:

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (144080) 0:24:00.80

SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.2603.10.0.1

SNMPv2-SMI::enterprises.2603.10.2.1.1.6.10.4.60.234.100.0.0.0 = INTEGER: 3

SNMPv2-SMI::enterprises.2603.10.2.1.1.7.10.4.60.234.100.0.0.0 = STRING: "Test-STC

is unreachable"

SNMPv2-SMI::enterprises.2603.10.2.1.1.8.10.4.60.234.100.0.0.0 = Counter64:

1278514270000

SNMPv2-MI::enterprises.2603.10.2.1.1.9.10.4.60.234.100.0.0.0 = STRING:

"10.4.60.234.100.0.0"

2010-07-07 16:55:53 10.4.70.20 [UDP: [10.4.70.20]:161]:

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (171737) 0:28:37.37

SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.2603.10.0.2

SNMPv2-SMI::enterprises.2603.10.2.1.1.6.10.4.60.234.100.0.0.0 = INTEGER: 1

SNMPv2-SMI::enterprises.2603.10.2.1.1.7.10.4.60.234.100.0.0.0 = ""

SNMPv2-SMI::enterprises.2603.10.2.1.1.8.10.4.60.234.100.0.0.0 = Counter64:

1278514546915

SNMPv2-SMI::enterprises.2603.10.2.1.1.9.10.4.60.234.100.0.0.0 = STRING:

"10.4.60.234.100

.0.0"

AlIndex


1.3.6.1.4.1.2603.10.2.1.1.9.a.b.c.d.alarm.x.y.z = STRING

The fields a.b.c.d.alarm.x.y.z are as described in AlSeverity above. The string here displays the alarm index (no new information is added here).

Example

A rising trap is forwarded to the trap receiver by NX 10.4.70.20. The forwarded trap contains the details below:

From this trap we can learn the following:

The trap is for a rising alarm (2603.10.0.1)

The trap was received from a device with IP address 10.4.60.234. (in this case an external collector)

The alarm ID of the trap is 100 (server is unreachable)

The description of the alarm tells us that the Test-STC is unreachable

The severity of the alarm is critical (indicated by Integer 3)

Subsequently, a falling trap is forwarded to the trap receiver by the same NX (10.4.70.20). This time the forwarded trap contains the details below:

From this trap we can learn the following:

The trap is for a falling alarm (2603.10.0.2)

The trap was received from a device with IP address 10.4.60.234. (as in the rising alarm)



The alarm ID of the trap is 100 (server is unreachable)

As this is a falling alarm, the description of the alarm is empty , however we can clearly tell to which alarm this refers from the alarm ID (100)

The severity of the alarm provides a further indication that this is a cleared alarm (indicated by Integer 1)



Key Performance Indicators & Health Monitoring Key Performance Indicators (KPIs) are metrics used to reflect strategic performance of Allot network equipment (e.g: SG-Omega) and its component parts (e.g: SGFP cards).

The Service Provider or Carrier can poll Allot Network Elements for global Key Performance Indicators (KPIs) such as memory usage, disk usage, temperature, CPU usage (on the host) and CPU Pico usage.

Service Gateway

Key Performance Indicators (KPIs) are metrics used to reflect strategic performance of Allot network equipment (e.g: SG-Omega, SG-Sigma) and its component parts (e.g: SGFP, CC-220 cards).

The Service Provider or Carrier can poll Allot Network Elements for global Key Performance Indicators (KPIs) such as memory usage, disk usage, temperature, CPU usage (on the host) and CPU Pico usage. Different KPIs are supported on different Service Gateway devices as shown in the table below:

KPI SG-Sigma SG-Omega

Temperature

Fan Status

Power Status

CPU

Memory

Storage

CER X (CLI only)

NOC X (CLI only)

Active Lines X (CLI only)

Active Pipes X (CLI only)

Active VCs X (CLI only)

Registered Subscribers X (CLI only)

The Allot Service Gateway products are based on a 14 slot ATCA chassis. Different KPIs poll sensors on different blades in the Service Gateway. In order to poll the relevant blade, you will need to know in which slot of the chassis it is inserted. The two tables below show the different boards (blades) which are housed in the different slots, depending on the type of Service Gateway deployed.

For a full description of which KPIs can be polled on which blades, see the reference table in Appendix B: KPIs Per SG Blade.



SG-Omega:

Slot Blade Full Name

1 SGFP Flow Processor Blade

2 Empty -





7 SGBP Bypass Blade

8 SGBP Bypass Blade

9 SGCC Core Controller Blade (occupies two slots)

10

11 SGCC Core Controller Blade (occupies two slots)

12

13 Empty -

14 SGSV-110 Server Blade

SG-Sigma

Slot Blade Full Name

1 SGSV-110 Server Blade

2 CC-220 Core Controller Blade (occupies two slots)

3

4 CC-220 Core Controller Blade (occupies two slots)

5

6 FB-200 Flow Balancer Blade

7 SFC-200 Switch Fabric Controller Blade

8 SFC-200 Switch Fabric Controller Blade

9 FB-200 Flow Balancer Blade

10 CC-220* Core Controller Blade (occupies two slots)

11

12 CC-220* Core Controller Blade (occupies two slots)

13

14 BP-204 Bypass Blade

NOTE: Slots 10-13 of the SG-Sigma can also be occupied by single-slot network and subscriber services blades NSS-SP (ServiceProtector) or NSS-MS (MediaSwift)



Temperature

This KPI measures the temperature in key sensors on different blades on the Service Gateway. As the SG-Omega and SG-Sigma have different mechanisms for polling temperature we will handle these separately

SG-Omega

Objects to Poll

Temperature can be polled for each of the SG-Omega blades shown below:

SGSV-110 (Slot 14)

SGFP (Slots 1, 3, 4, 5 and 6)

SGCC (Slots 9 and 11)

OIDs to Poll

Each SG-Omega blade includes several different sensors to measure the temperature of different components. The OIDs to be polled for each sensor on each blade in the SG-Omega are shown in the table below.

Card Name Slot No. Sensor Name (ID) OID to Poll

SGFP 1,3,4,5 or 6 Sensor 9 (009)

Sensor 10 (010)

Sensor 11 (011)

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1009

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1010

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1011

SGCC 9 or 11 Base Card 1 (007)

Base Card 2 (008)

Base Card 3 (009)

Host PRC (010)

Target PRC (011)

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1007

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1008

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1009

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1010

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1011

SGSV-110 14 SBC Temp 1 (048)

SBC Temp 2 (049)

SBC Temp 3 (050)

CPU 1 Temp (146)

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1048

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1049

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1050

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1046

Threshold Values

Each temperature sensor on each component part of the SG-Omega blades has built in thresholds. These thresholds are displayed below in degrees centigrade:

SGCC Sensors SGFP Sensors SGSV-110 Sensors

007 008 009 010 011 009 010 011 048 049 050 146

Upper Non-Critical Threshold

50 50 50 87 87 40 40 40 70 65 65 90

Upper Critical Threshold

60 60 60 92 92 60 60 60 80 75 74 100

Upper Non-Recoverable

80 80 80 95 95 80 80 70 90 85 85 115



Threshold

Lower Non-Critical Threshold

N/A N/A N/A N/A N/A N/A N/A N/A 5 5 5 5

Lower Critical Threshold

N/A N/A N/A N/A N/A N/A N/A N/A -5 -5 -5 -5

Recommended Actions

Recommended actions for when each threshold is crossed are indicated below:

If Temperature Recorded is: Recommended Action

Below Non-Critical Threshold (Low Range)

No Action is necessary

Between Non-Critical and Critical Threshold (Middle Range)

Monitor the sensor temperature for an extended period of time (e.g: sampling every 15mins for 2-3 hours) to see if the threshold breach is repeated

If threshold breach is constant, check if any change has been made to the physical operating environment of the SG

Between Critical and Non-Recoverable Threshold (High Range)

Monitor the sensor temperature for an extended period of time (e.g: sampling every 5mins for 1 hour) to see if the threshold breach is repeated


If the breach is constant and no operating environment change can be found, contact [email protected]

NOTE: Should the temperature of a sensor on a particular blade cross the non-recoverable threshold, the SMC will shut down the blade.

SG-Sigma

Objects to Poll

Temperature can be polled for each of the SG-Sigma blades shown below:

SGSV-110 (Slot 1)

CC-220 (Slots 2, 4, 10 and 12)

FB-200 (Slots 6 and 9)

SFC-200 (Slots 7 and 8)

BP-204 (Slot 14)

Board Temperature Range

SG-Sigma employs a sophisticated system which monitors all of the sensors on all of the blades mentioned in 0 above. Each sensor has a built-in set of thresholds:

Upper Non-Critical Threshold

Upper Critical Threshold

Upper Non-Recoverable Threshold



SG-Sigma measures the temperature on each of the sensors on each blade and checks if any of the built-in thresholds have been crossed. It then assigns each blade one of three statuses as shown below:

Low (1): If temperature of all sensors on this blade are below the non-critical threshold

Middle (2): If temperature of at least one sensor on this blade is between the non-critical and the critical threshold

High (3): If the temperature of at least one sensor on this blade is between the critical and non-recoverable threshold

OIDs to Poll SG-Sigma

The board temperature range can be checked by polling the OID below, where Slot is the slot number of the blade whose temperature range is being polled (1-14).

Board Temperature Range: 1.3.6.1.4.1.2603.5.2.6.20.1.1.8.Slot

If nonetheless, you wish to poll each individual sensor on each SG-Sigma card for its temperature reading, you can do this by using the OIDs in the table below:

Card Name Slot No. Sensor Name (ID) OID to Poll

CC-220 2, 4, 10 or 12 Base Card 1 (007)

Base Card 2 (008)

Base Card 3 (009)

Host PRC (010)

Target PRC (011)

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1007

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1008

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1009

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1010

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1011

SGSV-110 1 SBC Temp 1 (048)

SBC Temp 2 (049)

SBC Temp 3 (050)

CPU 1 Temp (146)

1.3.6.1.4.1.2603.5.5.18.1.3.1.1048

1.3.6.1.4.1.2603.5.5.18.1.3.1.1049

1.3.6.1.4.1.2603.5.5.18.1.3.1.1050

1.3.6.1.4.1.2603.5.5.18.1.3.1.1046

SFC-200 7 or 8 Power Module (007)

CNODE Ambient (008)

CNODE Airflow (009)

440 Ambient (010)

440 Core (011)

Base Ambient (013)

Base Core (014)

Fabric Ambient (015)

Fabric Core (016)

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1007

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1008

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1009

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1010

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1011

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1013

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1014

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1015

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1016

FB-200 6 or 9 Pwr Module (007)

CNODE Ambient (008)

XLR0 Ambient (010)

XLR0 Core (011)

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1007

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1008

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1010

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1011



XLR1 Ambient (014)

XLR1 Core (015)

FM3112 Ambient (017)

FM3112 Core (018)

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1014

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1015

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1017

1.3.6.1.4.1.2603.5.5.18.1.3.Slot.1018

BP-204 14 Bypass Sensor (007) 1.3.6.1.4.1.2603.5.5.18.1.3.14.1007

Expected Output and Recommended Action

When polling the board temperature range, the output will be as follows:

Output Meaning Recommended Action

1 Low No Action is necessary

2 Middle Monitor the sensor temperature for an extended period of time (e.g: sampling every 15mins for 2-3 hours) to see if the threshold breach is repeated


3 High Monitor the sensor temperature for an extended period of time (e.g: sampling every 5mins for 1 hour) to see if the threshold breach is repeated


If the breach is constant and no operating environment change can be found, contact [email protected]

Fans

The 14 slot SG-Omega and SG-Sigma chassis both contain 3 front pluggable fan trays. The status of each of these fan trays in the chassis can be polled as shown in the table below.

Product Fan ID OID to Poll

SG-Omega or SG-Sigma

001

002

003

1.3.6.1.4.1.2603.5.5.18.1.3.0.2001

1.3.6.1.4.1.2603.5.5.18.1.3.0.2002

1.3.6.1.4.1.2603.5.5.18.1.3.0.2003

Expected Output

The output is an integer value which represents the status of the fan:

Value Meaning

2 OK

3 Failure



RAG Values

For interpreting fan status output, refer to the table below

RAG Value Fan Speed Recommended Action

Green 2 None. Fans are working normally

Amber N/A N/A

Red 3 Check the display module on the SG chassis fan tray (SG-Sigma HW Guide Figure 2-8).

If the red Fan Tray alarm LED is lit, open a support incident with [email protected]

Power Supply

The 14 slot SG-Omega and SG-Sigma chassis both contain two pluggable redundant PEMs (Power Entry Module) at the rear bottom side of the Chassis. Each PEM provides power terminals for four 25A power feeds. The status of each of these power entry modules in the chassis can be polled as shown in the table below.

Product PEM ID OID to Poll

SG-Omega or SG-Sigma 001

002

1.3.6.1.4.1.2603.5.5.18.1.3.0.3001

1.3.6.1.4.1.2603.5.5.18.1.3.0.3002

Expected Output

The output is an integer value which represents the status of the power supply:

PS Status Meaning

0 OK

7 Not Working or not existing

RAG Values

For interpreting power supply output, refer to the table below

RAG Value PS Status Recommended Action

Green 0 No action is required. Power supply is working normally

Amber N/A N/A

Red 7 Check if the PEM is connected

Check the PEM LED on the rear of the chassis (SG-Omega Hardware Guide Fig 2-10; SG-Sigma Hardware Guide Fig 2-11). If the RED power failure LED is lit, contact [email protected]



CPU

This KPI measures the CPU usage on different blades on the Service Gateway.

Objects to Poll

CPU can be polled for each of the entities shown below:

SG-Omega:

SGSV-110 (Slot 14)


Device

SG-Sigma:

SGSV-110 (Slot 1)

CC-220 (Slots 2, 4, 10 and 12)

Device

OID to Poll

CPU can be checked by polling the OID below:

Per Blade: 1.3.6.1.4.1.2603.5.5.18.1.3.Slot.4001

Per Device: 1.3.6.1.4.1.2603.5.5.15

Expected Output

The output is an integer representing the CPU usage as a percentage of the maximum. Note: for device level OID, the output represents the highest CPU measured on each of the blades that can be polled.

RAG Values


RAG Value CPU %ge Recommended Action

Green 0-90% Normal functioning. No action necessary

Amber 9095% Monitor the CPU usage output over an extended period of time (e.g: sampling every 15mins for 2-3 hours) to see if the value returns to the normal range

Red 95-100% Monitor the CPU usage output over an extended period of time (e.g: sampling every 15mins for 2-3 hours) to see if the value returns to the normal range

If CPU usage is over 95% for over 50% of the time open a support incident with [email protected]



Memory

This KPI measures the RAM used on the various Service Gateway blades

Objects to Poll

Memory can be polled for each of the entities shown below:

SG-Omega:

SGSV-110 (Slot 14)


Device

SG-Sigma:

SGSV-110 (Slot 1)

CC-220 (Slots 2, 4, 10 and 12)

Device

OID to Poll

Memory usage can be checked by polling the OIDs below:

Per Blade: 1.3.6.1.4.1.2603.5.5.18.1.3.Slot.5001

Per Device: 1.3.6.1.4.1.2603.5.5.4

Expected Output

The output is an integer representing the device RAM usage in %. Note: for device level OID, the output represents the highest RAM usage % measured on each of the blades that can be polled.

RAG Values

For interpreting memory usage output, refer to the table below

RAG Value Memory Recommended Action


Amber 9095% Monitor the memory usage output over an extended period of time (e.g: sampling every 15mins for 2-3 hours) to see if the value returns to the normal range

Red 95-100% Monitor the memory usage output over an extended period of time (e.g: sampling every 15mins for 2-3 hours) to see if the value returns to the normal range

If memory usage is over 95% for over 50% of the time open a support incident with [email protected]



Storage

This KPI measures the disk storage space used on the various Service Gateway blades

Objects to Poll

Storage can be polled for each of the entities shown below:

SG-Omega:

SGSV-110 (Slot 14)


Device

SG-Sigma:

SGSV-110 (Slot 1)

CC-220 (Slots 2, 4, 10 and 12)

Device

OID to Poll

Disk Usage (storage) can be checked by polling the OIDs below:

Per Blade: 1.3.6.1.4.1.2603.5.5.18.1.3.Slot.6001

Per Device: 1.3.6.1.4.1.2603.5.5.5

Expected Output

The output is an integer representing the percentage of disk space used from the total 1Gbyte compact flash card. Note: for device level OID, the output represents the highest disk usage % measured on each of the blades that can be polled.

RAG Values


RAG Value Storage Recommended Action


Amber 9095% Continue to monitor the situation to see speed at which storage usage is rising.

Red 95-100% Login to the blade in question and check disk utilization using the df command

Open a support incident with [email protected] attaching the output of the df command.



CER

The connection establishment rate is the number of connections established per second. This KPI can be polled on AOS devices only (e.g: SG-Sigma)

Objects to Poll

The connection establishment rate can be polled for each of the entities shown below:

SG-Omega:

Not Applicable

SG-Sigma:

CC-220 (Slots 2, 4, 10 and 12)

Entire Device

OID to Poll

CER can be checked by polling the OIDs below:

For the Entire Device: 1.3.6.1.4.1.2603.5.4.7

1.3.6.1.4.1.2603.5.5.18.1.3.0.10001

Per Core Controller Blade: 1.3.6.1.4.1.2603.5.5.18.1.3.Slot.10001

Expected Output

The output is an integer representing the number of new connections established per second

RAG Values

In release AOS10.2.1, each core controller supports up to 150,000 new connections per second. For interpreting CER output, refer to the table below

RAG Value CER per CC-220 Recommended Action

Green Up to 90% of the CER threshold defined for the specific release

Normal functioning. No action necessary

Amber 90-95% of the CER threshold defined for the specific release

From the real-time monitoring menu on the NX GUI, open a most active hosts graph, and on the objects tab choose to open the graph by new connections.

Investigate if particular source has been responsible for an disproportionate rate of new connections

Using existing network tools (or Allots ServiceProtector if deployed), check for DDoS attacks on the network

Red Over 95% of the CER threshold defined for the specific release

Perform the steps required for Amber alert above

If the problem is consistent and is not related to transient patterns of subscriber activity, consult with Allot project manager to plan for expansion (additional SG)

NOTE: If the CER rises above the defined specification for new connections per sec for a given CC-220 blade, additional connections opened and dispatched to that CC-220 will pass through the system without classification or QoS enforcement.



NOC

The NOC statistic is the number of established connections at a given point in time. This KPI can be polled on AOS devices only (e.g: SG-Sigma)

Objects to Poll

The number of established connections can be polled for each of the entities shown below:

SG-Omega:

Not Applicable

SG-Sigma:

CC-220 (Slots 2, 4, 10 and 12)

Entire Device

OID to Poll

NOC can be checked by polling the OIDs below:


1.3.6.1.4.1.2603.5.5.18.1.3.0.11001


Expected Output

The output is an integer representing the number of established connections running through the SG-Sigma at this point in time.

RAG Values

In release AOS10.2.1, each Core Controller supports up to 5 million concurrent connections. For interpreting NOC output, refer to the table below

RAG Value NOC per CC-220 Recommended Action

Green Up to 90% of the maximum NOC per core controller defined for the specific release

Normal functioning. No action necessary

Amber 90-95% of the maximum NOC per core controller defined for the specific release

From the real-time monitoring menu on the NX GUI, open a most active hosts graph, and on the objects tab choose to open the graph by live connections.

Investigate if particular source has been responsible for an disproportionate number of concurrent

Using existing network tools (or Allots ServiceProtector if deployed), check for DDoS attacks on the network

Red Over 95% of the maximum NOC per core controller defined for the specific release

Perform the steps required for Amber alert above

If the problem is consistent and is not related to transient patterns of subscriber activity, consult with Allot project manager to plan for expansion (additional SG)



Active Lines

Lines are the highest level of hierarchy in a Service Gateway device. The active lines statistic records the total number of active lines. This KPI can be polled on AOS devices only (e.g: SG-Sigma)

Objects to Poll

The number of active lines can be polled for each of the entities shown below:

SG-Omega:

Not Applicable

SG-Sigma:

CC-220 (Slots 2, 4, 10 and 12)

Entire Device

OID to Poll

The number of active lines can be checked by polling the OIDs below:


1.3.6.1.4.1.2603.5.5.18.1.3.0.12001


Expected Output

The output is an integer representing the number of lines currently active in the SG-Sigma.

RAG Values

Each SG-Sigma supports up to 256 lines. For interpreting active lines output, refer to the table below

RAG Value Active Lines per Device

Recommended Action

Green 0 200 No action necessary

Amber 200 250 Consult with the system administrator responsible for building the traffic policy within the NetXplorer. If the system administrator has plans to add existing lines, advise to consult with Allots project manager and discuss ways to restructure the policy.

Red >250

NOTE: Lines can only be created statically by the system administrator (there are no line templates). The NetXplorer GUI will not allow the system administrator to create more than 256 lines.



Active Pipes

Pipes are the second level of hierarchy in a Service Gateway device. The active pipes statistic records the total number of active pipes. This KPI can be polled on AOS devices only (e.g: SG-Sigma)

Objects to Poll

The number of active pipes can be polled for each of the entities shown below:

SG-Omega:

Not Applicable

SG-Sigma:

CC-220 (Slots 2, 4, 10 and 12)

Entire Device

OID to Poll

The number of active pipes can be checked by polling the OIDs below:


1.3.6.1.4.1.2603.5.5.18.1.3.0.13001


Expected Output

The output is an integer representing the number of pipes currently active in the SG-Sigma.

RAG Values

Each Core Controller supports up to 100,000 pipes. A fully populated SG-Sigma with 4 Core Controllers therefore supports up to 400,000 pipes. For interpreting active pipes output, refer to the table below

RAG Value Active Pipes per CC-220 Recommended Action

Green 0 75,000 No action necessary

Amber 75,000 90,000 Consult with Allot project manager on ways to restructure the policy or rescale the project to handle the large number of pipes

Red >90,000



Active VCs

Virtual Channels are the third level of hierarchy in a Service Gateway device. The active VCs statistic records the total number of active virtual channels. This KPI can be polled on AOS devices only (e.g: SG-Sigma)

Objects to Poll

The number of active VCs can be polled for each of the entities shown below:

SG-Omega:

Not Applicable

SG-Sigma:

CC-220 (Slots 2, 4, 10 and 12)

Entire Device

OID to Poll

The number of active VCs can be checked by polling the OIDs below:


1.3.6.1.4.1.2603.5.5.18.1.3.0.14001


Expected Output

The output is an integer representing the number of virtual channels currently active in the SG-Sigma.

RAG Values

Each Core Controller supports up to 200,000 virtual channels. A fully populated SG-Sigma with 4 Core Controllers therefore supports up to 800,000 virtual channels. For interpreting active VCs output, refer to the table below

RAG Value Active VCs per CC-220 Recommended Action


Amber 150,000 175,000 Consult with Allot project manager on ways to restructure the policy or rescale the project to handle the large number of virtual channels

Red >175,000



Registered Subscribers

The registered subscribers statistic is relevant when working with Allots Subscriber Management Platform (SMP). It records the total number of subscribers in the system (not necessarily generating traffic). This KPI can be polled on AOS devices only (e.g: SG-Sigma)

Objects to Poll

The number of registered subscribers can be polled for each of the entities shown below:

SG-Omega:

Not Applicable

SG-Sigma:

CC-220 (Slots 2, 4, 10 and 12)

Entire Device

OID to Poll

The number of registered subscribers can be checked by polling the OIDs below:

For the Entire Device: 1.3.6.1.4.1.2603.5.5.18.1.3.0.15001


Expected Output

The output is an integer representing the number of subscribers currently registered in the SG-Sigma.

RAG Values

Each Core Controller supports up to 400,000 registered subscribers. A fully populated SG-Sigma with 4 Core Controllers therefore supports up to 1,600,000 registered subscribers. For interpreting registered subscribers output, refer to the table below

RAG Value Registered Subscribers per CC-220

Recommended Action


Amber 300,000 375,000 Consult with Allot project manager on ways to restructure the policy or rescale the project to handle the large number of registered subscribers

Red >375,000



Software Status

This KPI shows the status of the software on each of the boards of the Service Gateway

Objects to Poll

Software status can be polled for each of the entities shown below:

SG-Omega:

All blades

SG-Sigma:

All blades

OID to Poll

The software status can be checked by polling the OID below, where Slot is the slot number of the blade whose software status is being polled (1-14).

1.3.6.1.4.1.2603.5.2.6.20.1.1.6.Slot


The output will be as follows:


1 Not Active (Bypass for SGFP)

If the particular blade has not been manually moved to bypass by the system administrator, open an incident with Allot support at [email protected]

2 Active No action necessary

3 Standby This blade has been configured as standby. No action necessary

4 Not Applicable If a blade is inserted in this slot and is expected to be operational, open a support incident with Allot at [email protected]



Hardware Status

This KPI shows the status of the hardware on each of the boards of the Service Gateway

Objects to Poll

Hardware status can be polled for each of the entities shown below:

SG-Omega:

All blades

SG-Sigma:

All blades

OID to Poll

The hardware status can be checked by polling the OID below, where Slot is the slot number of the blade whose hardware status is being polled (1-14).

1.3.6.1.4.1.2603.5.2.6.20.1.1.7.Slot


The output will be as follows:


1 Off (no power on inserted blade or no blade exists in this slot)

Check if a blade has been inserted in this slot

Check if the blade has been powered up

If the blade is inserted in the slot and powered up, open a support incident with Allot: [email protected]

2 On No action necessary



NetXplorer

Preparing the NX Server (NET-SNMP Tools)

NOTE: Polling the NetXplorer for KPIs is currently only possible when working with a LINUX operating system.

In order for an external SNMP server to be able to poll the NetXplorer Server for the purpose of health monitoring, an SNMP tools agent needs to be installed.

NOTE: The SNMP tools agent is already pre-installed in the NX High Availability Platform that is shipped from Allot. If you are working with NX-HAP, no additional preparation is necessary and you can skip this section.

When working with Linux (Red Hat) there are four files which need to be installed. These files depend on the exact version of Red Hat installed and can be found on the Red Hat installation CD.

1. Download the 4 Redhat files from the Redhat installation disk.

NOTE: These files will differ with each RedHat version. To be sure you are running the correct version use only the files from the RedHat installation disk!

lm_sensors

net-snmp

net-snmp-libs

net-snmp-utils

NOTE: You can verify whether or not these files are already downloaded on your server by using the command rpm qa|grep i

2. If the files are installed before installing the NX serve

Date post:	29-Oct-2015
Category:	Documents
Upload:	mokles-miah
View:	874 times
Download:	23 times

Allot SNMP Integration v2.b6

Documents