Netmond V2. Design

This is short description of architecture and basic algorithms of Netmond.


Basic algorithms.

Netmond running is based on one main cycle of asynchronous socket and timer events processing. Single process operates multiple sessions concurrently. All monitoring operations are defined in single configuration file.

Netmond consider The Network as a hierarchy of objects of some type.
The upper hierarchy level consist of nodal (parent) objects, it have individual IP address like hosts and routers. Every parent object has a number of subobjects - interfaces, services, etc. Nodal objects are ordered as a tree in terms of net paths, starting from monitoring server (hierarchy root).
This enable unambiguously set object dependencies and

  • Build network topology
  • Optimize monitoring traffic - eliminate traffic for inaccessible objects.
  • Eliminate erroneous alarms.

Two different ways exist to monitor objects:

Trapping
Object himself send events notifications to Netmond with special SNMP messages.
Polling
Periodically Netmond ask (poll, inquire) the object with different protocols, and collect and analyze answers.

This ways have benefits and disadvantages. To achieve maximum efficiency and flexibility Netmond use both.

Queries are distributed on a polling time interval accordingly net distance (hop count) if possible, so close objects queried before distant objects. Distance metrics are evaluated automatically with ICMP echoRecord-Route option (built-in method PING).

Returned data are saved in internal structures named variable This structures hold current and previous value.
Variables are referred by his names. Variables are not typified, and the same variable can hold string value in one time, and integer value in other time.

Variables can be global or can be bound to some object or subobject. A number of predefined variables are created and bound for every object. Additional variables can be defined in configuration file.

With saving methods collected data can be passed for:

  • Writing to file.
  • External process.
  • Simple internal analyzer.

Also collected data are accessible via built-in NetState service. This is telnet-like service with simple textual protocol.


Object types

Objects with similar behavior and characteristics are grouped in TYPE.
TYPE name reflect essence and destiny of the object.

Netmond deal with following objects types:

OBJECT
The basic monitoring target. Parent object. Has IP address.
INTERFACE
Network interface, subobject of OBJECT.
SERVICE
Arbitrary network service, subobject of OBJECT.
BGPAS
Autonomous system number, subobject of OBJECT.
BGPPEER
BGP peer in this AS (IP address), subobject of BGPAS.
ENVMON
Cisco environment probe, subobject of OBJECT.
ENVTEMP
Cisco thermal probe, subobject of ENVMON.

Every OBJECT can have:

  • Network address (IP or FQDN).
  • Short description.
  • List of polling methods METHOD.
  • Polling interval POLLING (time between METHODs list evaluating).
  • List of traps TRAP.
  • List of variables VARIABLE.
  • List of data saving methods SAVE.
  • Saving interval SAVING (time between SAVE list evaluating).
  • List of network interfaces INTERFACE.
  • List of network services SERVICE.
  • List of autonomous systems BGPAS.
  • List of thermal probes ENVTEMP.

Every INTERFACE can have:

  • Short description.
  • Nominal speed.
  • List of data saving methods SAVE.

Every SERVICE can have:

Every BGPAS can have:

  • Short description.
  • List of BGP peers BGPPEER( or autodetect )
  • List of data saving methods SAVE.

Every ENVTEMP can have:

  • Short description.
  • List of thermal probes (or autodetect).
  • List of data saving methods SAVE.

Memory space for objects data structures allocated dynamically.

Internal 'state' of any object changes when some object polling method get new data or SNMP trap caught from it.


Polling (inquiry) methods

Network objects have been monitored with various polling methods METHOD. Methods have been grouped to list and bound to objects. Each method makes simple network interaction with this object to check it characteristics.
Some of these interactions can be described in chat-script form, with regular expressions matching for flexibility.
Methods can use various network protocols.

Methods in object's list have evaluated sequentially in order as defined by user. Current list evaluation stops when any method in list fall (return error or timeout elapsed),
Result of evaluation of object's methods list is the current status of this object.

Only OBJECT and SERVICE objects can have arbitrary polling methods. Other objects have been checking during built-in ROUTER method evaluation for parent OBJECT.

Data mined in METHOD evaluation can be stored to internal variable VARIABLE for this object.

Following built-in methods METHOD can be bound to OBJECT or SERVICE:

PING
ICMP-echo request with Record-Route option. Used for simple network accessibility testing and for network path detecting.
ATTENTION! not all OSes support ICMP Record-Route option.
ICMP
ICMP-echo - request like UNIX 'ping' command do.
SNMP
SNMP v1 Get - simple request for various SNMP variables VARIABLE.
ROUTER
Complex sequence of SNMP requests, used for MIB tables detecting and scanning. Have to be used for OBJECT with defined INTERFACE, BGPPEER or ENVTEMP subobject. During evaluating fills the number of predefined variables.
TCP
TCP - based session with arbitrary textual interaction script. User can define destination port and source ports for TCP session. Regexp matched elements can be stored to VARIABLE.
UDP
UDP - based session arbitrary textual interaction script. User can define destination port and source ports for UDP session. Regexp matched elements can be stored to VARIABLE.
RADIUS
RADIUS Authenticate-Only - simple session with remote RADIUS service.
TACACS
TACACS+ PAP Authentication - simple session with remote TACACS+ service.
DNS
DNS IN A or DNS IN SOA - simple UDP request to DNS service (like named).

All protocols and scripts realized as separate independent modules with unified Netmond API. New modules can easily be added.


SNMP traps

To catch SNMP notifications from objects, Netmond have built-in 'trap' service listening on 162/UDP port.
However, it is possible to disable this service.

Such a notification consists of the number of SNMP variables. Each variable presented as variable name and their value.
Variable name is a special SNMP identifier - ASN.1 Object Identifier. It is a sequence of period separated integers.
Values can be numbers, strings, IP addresses, other ASN.1 Object Identifiers, etc.

Notifications from objects utilized via extracting SNMP variables and their values to internal variables VARIABLE for corresponded object.

In some cases object 'state' changes also.

There are the number of trap messages supported by Netmond by default:

Generic Traps
Standard and universal SNMP traps:
  • Cold-Start - "cold" equipment reload.
  • Warm-Start - "warm" or "software" equipment reload.
  • Link-Up - corresponded interface became working.
  • Link-Down - corresponded interface became non-working.
Enterprise-specific Traps
Special enterprise SNMP traps:
  • BGP-Established - corresponded BGP-peer became working.
  • BGP-BackWardTransition - corresponded BGP-peer became non-working.
  • Cisco-Reload - This Cisco device was reloaded.

Traps of other sort have to be explicitly defined as TRAP methods and bound to corresponding objects with needed variables VARIABLE.


Data representation

All useful information is stored in program memory as a VARIABLEs

Some variables are 'read-only' constants - they cannot be changed until next reconfiguration like object name.
Polling methods or traps change other variables change from time to time. A number of variables are created automatically when specific polling method defined. For example if ROUTER polling method have been bound to object, variables $sysDescr, $sysObjID, $sysUpTime etc. appear for this object.

Some constants and variables are the part of program code - they exist all the time the program run. They have some meaningful values. These are - HardCode VARIABLEs.
Variables created dynamically are Soft VARIABLEs. Their values can be 'undefined' until first usage.

Variables are grouped to lists and bound to objects of subobjects. Some subobjects like INTERFACE BGPAS ENVMON have only the number of individual predefined automatic variables.
Objects of type OBJECT and SERVICE can have arbitrary variables defined by user.

Variable is the structure consisting of the name of and value. Variable name reflect it's meaning and is collection of uppercase and lowercase latin letters, digits and underscore signs - [a-zA-Z0-9_]. But while running letter case ignored.
Variable name have to begin with letter and can occupy up to 100 chars. All HardCode VARIABLEs are in uppercase for usability.
In configuration file variables are prefixed with dollar sign - $.

Variables values can be:

Integer
Simple singed integer.
Unsigned
Unsigned 32bit number, SNMP-counter.
Floating
Floating-point number, (really double).
IpAddress
IP address.
String
Sequence of 8bit chars, ended with '\0' char.
ObjID
SNMP identifier, OID = 1.3.6.1...

Soft VARIABLE untypified. The same variable can hold different value types in different times.

String value is outputted in quotes. Undefined value is outputted as Unused keyword.

Soft VARIABLE structure include:

  • Variable name.
  • SNMP identifier OID (only for SNMP variables).
  • Current value.
  • Previous(old) value.
  • Modification time (if Netmond compiled with USE_VAR_MTIME option).

For a numeric Soft VARIABLE with Integer, Unsigned or Floating type there are additional fields:

  • Maximum value.
  • Minmal value.
  • Average value.
  • Delta increment.

This fields are updated every data saving interval for parent object. The number of POLLING cycles can happen during this saving interval.

Some Soft variables values can be outputted as a 'state' string (UP, DOWN, ESTABLISHED etc.).

Additional fields for variable $Name accessible via variable name with suffixes:

$Name.Old
Get the previous value of $Name.
$Name.State
Get $Name value as a 'state' string.
$Name.Ave
Get average $Name value for a parent last saving interval.
$Name.Min
Get minimum value for a saving interval.
$Name.Max
Get maximum value for a saving interval.
$Name.Delta
Get increment value for a saving interval.

Variable names can be used in a configuration file or in a request to built-in NetState service. Do not forget, letter case is ignored.


Data saving

Data saving method SAVE is the way to output internal data to outside 'world'. Every object or subobject can have the number of different saving methods.

Predefined simple saving methods SAVE exist for every object type. This methods store data to a plain text file.
User defined saving method can flexibly satisfy any needs. I hope.

User can SAVE VARIABLEs following ways:

  • Write to a plain text file.
  • Write to a pipe (connected to external process).
  • Run additional program and pass data as arguments.

Saving can happen:

  • Periodically with SAVING interval.
  • When object state changes.
  • When defined expression have been evaluated as TRUE.

User can define output format.

Using this way user can create simple network alerting framework.


NetState service

As above mentioned, Netmond store colleted data in VARIABLEs. VARIABLE values are modified during polling and trapping and outputted with saving methods.

So with SAVE methods Netmond himself decide when to save data, and what data to save.
But sometimes user needs more flexible way to get a full actual snapshot of situation in a network.

Built-in NetState service mission is to serve asynchronous authorized user requests and to provide read-only access to all VARIABLEs.

All VARIABLEs considered as hierarchy of variable names and their parents names. Variable 'path' in this hierarchy is a sequence of object and subobjects names separated with special char '!' like this:

object!subobject!variable = value

Suffixed variable names also available this way.
User can use REGEX mask in requests for selective data access.

Initially NetState service was designed to provide actual data for operator interface.


See also:
Configuration statements
Variables
NetState service
Configuration examples

© 1998-2002, Rinet Software