• You can monitor your network continuously and in real-time
  • You can use threshold analyses to efficiently manage the system
  • You can identify potential bottlenecks in advance
  • You can consolidate alerts for all used network components, all on one platform


Operating a network management system requires a number of functions to support network administrators. This would include SNMP traps or syslog processing, as much as an intelligent event correlation.

The central recipients of the events are the SATs, which have all the mechanisms for receiving these events; they will then transmit all alerts to the CENTER from where all events will be processed and prepared so they can be viewed. ERAMON distinguishes between the following event types, according to the type or the process to be notified:

  • SNMP Traps
    Traps can be set with a wide range of parameters
  • SNMP Port Status
  • IP Polling
  • Syslog
    Syslog messages are checked against the ruleset and processed accordingly
  • Program messages
  • Ping Groups
  • Performance Management (EPM)
  • ERA Health

Correlation and Collation of Events

Within ERAMON we understand correlation as a pooling of related events in the event tool. Their relationship is established – and at times assessed – through various methods (RCA). The advantages are:

  • Improved clarity through groupings
  • Relationships are made immediately evident
  • Targeted announcements
  • Simplified error analysis

It is also possible to adjust the correlation individually, allowing customers to decide for themselves which events are to be correlated and which priority each event should be given. Below is an excerpt of existing correlations:

  • Passive
    The passive correlation is applied if an event occurs several times. Where an event is created after its initial occurrence in the event tool, which will not happen for any identical follow-on events; this will only increase the overall count for this event.
  • Normal
    If device/port/event source coincide, the events will be grouped together. The event source can be specified in various places, such as in the trap settings or syslog administration.
  • Sub-Interfaces
    Since logical interfaces can be laid on top of physical ones, where the logical ones are obviously also affected when the physical one goes down, it would make sense to correlate these events. For this reason, the events of subinterfaces are correlated to the events of the physical interfaces, if they correspond to the event source.
  • Transfer Networks
    If ERAMON recognizes a remote station via a transfer network (/30), the corresponding events are correlated with those of the remote station.
  • Port Channels
    This correlation is an expansion of the transfer network correlation. A port channel consists of two or more physical interfaces and one logical (virtual) channel interface. If an individual physical interface goes down the normal correlation, as shown above, will be carried out. If the second physical interface also goes down, however, and with this the virtual tunnel, then all events are correlated with one another. In this case, the root event would be the channel interface going down. In addition, due to the transfer network correlation, all events of the remote stations, physical and logical interfaces, will also be correlated.
  • OSPF and BGP Neighborhoods
    At this point the corresponding port is being identified from the original device event, for example: OSPF Neighbor Down. A failure is then generated for this port and the events of the remote station correlated to it.


With the help of announcements automatic actions dealing with the notifications for particular events can be set up in ERAMON. In the settings for announcements you can specify when which action is to be carried out due to an event.

Any major events of the “Backbone” device group occurring in the night must result in an sms to the on-call number, while during the day an e-mail is to be sent.

The following actions are available:

  • Email Transmission: Enter address in the following field, multiple addresses are delimited by a semicolon
  • Bulk Email: Collation of announcements until their transmission as a batch e-mail
  • Script: Running of a script on the OS
  • Trap: Transmission of a trap to a different server
  • Syslog: Transmission of a syslog message
  • PAM: Generating a specific event for the proactive management

Device Backup

Based on pre-defined login modules, the device configurations are periodically backed up. It is also possible to back up the firmware. By linking to other functions or modules you can obviously also carry this out controlled by events, based on a specific trap, for example. Below is a list of just some of the backup methods:

  • FTP
  • TFTP
  • SCP
  • Telnet/SSH
  • SNMP

By default, 90 different configurations are backed up periodically for each device. The number of saved configs per device can be configured individually in the archive management. The config history function allows you to identify when which line has been changed or has been added. The provisioning module also allows a reset to any configuration.

Monitoring Group

Checking for services

By default, the ping is monitored to calculate the availability of a device. For a web server, however, mere ping monitoring is not enough; here it is necessary to also check the function of the web server. A device is assigned to a monitoring group; within this group the device is marked as either reachable or unreachable based on specific criteria. With the help of these monitoring groups a monitoring of the most commonly used services/protocols, such as: pop3, radius, smtp, dns, tacacs, has been integrated.

Scheduled Maintenance Tasks

Scheduled maintenance tasks can be set up, which can then also be included in any subsequent SLA calculation. The alerted events during this time period are automatically assigned to the maintenance and are not actively announced.


Optional expansion to the Operations module

A list of all VRFs on the system, including the parameters. Details regarding the VRF via the customer, port and device, as well as routed prefixes, are automatically detected.

VLAN Manager

Optional expansion to the Operations module

When using VTP the domains, as well as all the devices in the domain, are visible. You can also create groups as a VTP domain alternative and check the integrity of the VLAN names for correctness.