Operating a network management system requires a number of functions to support network administrator. This would include SNMP traps or syslog processing, as much as an intelligent event correlation.
The central recipients for events are the SATs, which have all the mechanisms for receiving these events; they will then transmit all alerts to the CENTER from where on all events will be processed and prepared for notification. ERAMON distinguishes between the following event types, according to the type or the notifiable process:
- SNMP Traps
Traps can be set with a wide range of parameters
- SNMP Port Status
- IP Polling
Syslog messages are checked against the ruleset and processed accordingly.
- Program messages
- Ping Groups
- ERA Health
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:
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.
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.
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.
- L3 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/BGP neighborhoods
At this point the corresponding port is being identified from the original device event, for example: OSPF Neighbor Down. A down is then generated for this port and the events of the remote station correlated to this.
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. The setting options can be combined via drag and drop.
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:
- E-mail Transmission
Enter address in the following field, multiple addresses are delimited by a semicolon (;)
- Bulk E-mail
Collation of announcements until their transmission as a batch e-mail
Running of a script on the OS
Transmission of a trap to a different server
- New Ticket
Generating a new ticket in the ERAMON ticket system
Transmission of a syslog message
Generating a specific event for the proactive management
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 the 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 various backup methods:
By default, 90 different configurations are backed up periodically for each device. 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.
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.
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.
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.