By Andreja Jarc and Doug Arnold.
The Simple Network Managment Protocol
Most network connected devices support a number of management options including the Simple Network Management Protocol, or SNMP. SNMP is a network protocol which allows a single network management system to monitor a large number of devices on the network. Indeed this is one of the chief reasons why SNMP is prevalent. An entire network summarized in one screen with the ability to drill down into more detail when needed. Popular management software options include HP’s Openview and IBM’s Tivoli Netview.
The way it works is each network element has an Agent which communicates with the Manager via SNMP (Figure 1). Each Agent has a corresponding Management Information Base, or MIB. The MIBs organize data elements in a tree structure. It is written in a standard, highly structured language so that the MIBs from all of the devices on the network can be compiled into the same Manager. See examples in the next section taken from a Meinberg network time server.
Figure 1: Communication between Agents and Manager via SNMP.
MIB elements are called Object Identifiers or OIDs. They consist of configuration variables, status variables, tree structure labels and notifications. The OIDs can be read or changed using SNMP SET and GET commands. In practice SNMP is often used for monitoring only, so GETs are more common than SETs. There are also recursive commands which allow the Manager to ask for all of the OIDs in a branch (subtree), or even the whole tree. This process is referred to as “walking the MIB”. Event Notifications, commonly referred to as traps, are a special type of OID. A trap can be configured so that when the status of the device changes a message is immediately sent from the Agent to the Manager.
The ability for the Agents to tell the Manager that something significant has just happened is most important property of SNMP. Indeed many network administrators use SNMP solely for this event driven monitoring capability. The latest version of SNMP is SNMPv3. It is standardized with a series of documents created by the Internet Engineering Task Force. These are the fine people who brought us the Internet Protocol, http, NTP, and many of the other protocols which make the Internet function. Among many features, SNMPv3 includes a security mechanism to encrypt and authenticate SNMP messages. For more information on SNMP see the Open Directory Project SNMP page.
Using SNMP with Meinberg Time Servers
Here is an example of SNMP management software and LANTIME specific OIDs:
Figure 2: Example of LANTIME SNMP Monitoring. “mbgLantimeNGStatus” marked green is a subtree which includes all of the main OIDs for LANTIME monitoring.
As shown in Figure 2 the main OIDs for LANTIME monitoring are in the mbgLantimeNGStatus subtree. “NG” label stands for “New Generation” which corresponds to V6.x versions of LANTIME CPU firmware. This is in contrast to MIB objects from V5.x firmware which have no NG label in their names.
Here is a detailed description of the most important OIDs which can be found in the NGStatus subtree:
1: Refclock subtree
| mbgLtNgRefclockState This OID describes a current state of a LANTIME refclock (hardware clock module) referring to GPS or any other time source signal in MRS (Multi Reference Source) model. | ||
| Status | Description | |
| 0: | refclock is not available: See the possible troubleshooting:
| |
| 1: | synchronized: The reflock of your system is correctly synchronized to the selected time source (GPS or MRS). In an MRS system, a refclock can be synchronized to a reference time source from the priority list. See an example in the next figure.
Figure 3: LANTIME M600 MRS priority list. The MRS system above synchronizes first to GPS, but if the GPS signal is unavailable, the refclock switches to the next time source from the priority list (PTP in our case). The switch happens only after a trust time of the unavailable time source (GPS signal) has run out. This is to prevent hopping from one time source to another in short time periods. If GPS becomes available again, the refclock switches back to GPS, without waiting for the PTP trust time in this case, since GPS itself a higher precision than PTP. | |
| 2: | not synchronized: Obviously the refclock is not synchronized to its time source. Here is the possible troubleshooting:
| |
| It is recommended configuring your network management software to check this status regularly, if possible every 60 s. | ||
| mbgLtNgRefclockLeapSecondDate This OID conveys information about the next Leap Second Date. If the upcoming Leap Second Date has not been announced yet, the OID holds information about the previous leap second event. | ||
| Here is short summary of the leap seconds. There are two different timescales we usually talk about in the sync environment: GPS, which stands for Global Positioning System time and UTC (Universal Time Coordinated), formerly known as GMT (Greenwich Mean Time). They differ from each other by number of leap seconds introduced since beginning of GPS time on 6-Jan-1980. In the moment of writing the UTC is 16 seconds behind the GPS time, which is due to the uneven rotation of the Earth. | ||
Since the introduction of a new leap second influences the time in the whole system being synchronized, we suggest to check this status regularly, e.g. 1/hour. | ||
Next in a row of OIDs are those referring to NTP status. They can be found in the “mbgLtNgNtp” subtree.
2: NTP subtree
| mbgLtNgNtpCurrentState This is one of the most important OID in this subtree to check regularly. It informs about the NTP service of your LANTIME. There are three states possible: | ||
| Status | Description | |
| 0: | not available: See the possible troubleshooting:
| |
| 1: | not synchronized: In case of “not synchronized” the NTP service is not yet synchronized to a reference clock. Possible causes for this state are as follows:
| |
| 2: | synchronized: The NTP service is in normal operation. The LANTIME is now working properly. | |
| It is recommended to check NTP status regularly, but not more than every 64 s. | ||
3: Hardware subtree
| mbgLtNgSysPsStatus If a LANTIME has a redundant power supply (RPS) unit, it is important to check the status of both RPS modules regularly. This PowerSupplyStatus OID can be found in the System Hardware subtree. The following states are available: | ||||
| Status | Description | |||
| 0: | notAvailable: The queried power supply unit is not recognized by a system. Check to see if it is damaged, and replace it if necessary. | |||
| 1: | down: The power supply unit of interest is not in service. Check to see if it is damaged, and replace it if necessary. | |||
| 2: | up: The queried power supply module is in operation. | |||
| It is recommended to check this OID every 60 s. | ||||
4: Misc subtree
| mbgLtNgEthPortLinkState In the mbgLtNgMisc subtree one can find an EthPortLinkState OID which identifies the status of each physical Ethernet port of a LANTIME. Available values: | ||
| Status | Description | |
| 0: | down: The queried port is down, check the link LED. If faulty, replace the network card. | |
| 1: | up: The port of interest is in normal operation. | |
| It is recommend that you check this OID every 60 s. | ||
5: PTP subtree
If your LANTIME has IEEE 1588 PTPv2 functionality, the corresponding PTP OIDs can be found in the “mbgLtNgPtp” subtree.
These are the most important OIDs to monitor:
| mbgLtNgPtpPortState The following PTP Port States are possible: | ||
| Status | Description | |
| 0: | uninitialized: The port is booting up, the software daemon has not yet started, the IP address is not yet assigned. | |
| 1: | initializing: In this state the port initializes its data sets, hardware, and communication facilities. | |
| 2: | faulty: Not defined in a LANTIME. | |
| 3: | disabled: PTP service has been disabled on this port, either by user configuration or because the module is in a standby mode. | |
| 4: | listening: The port is waiting for the announceReceiptTimeout to expire or to receive an Announce message from a master. | |
| 5: | preMaster: A short transitional state while the port is becoming a master. | |
| 6: | master: The port is a current master. | |
| 7: | passive: The port is in passive mode, meaning there is another master clock active in the PTP domain. The port can enter master state when it wins the BMCA due to a failure/service degradation of the current master. | |
| 8: | uncalibrated: One or more master ports have been detected in the domain. | |
| 9: | slave: The port has successfully subscribed to a master and receives all expected messages. It also successfully measured the path delay using delay request messages. | |
It is recommended to monitor the PtpPortState OID every 3 s. | ||
We are considering using a Meinberg M600/MRS/PTP as the PTP grandmaster across an IP network to a Meinberg SyncBox N2X to generate IRIG-B pulses into Arbiter Systems 1133A PMUs, to avoid the need for local GPS antennas.
The network is composed of Cisco IE 2000/ 3000 switches.
Where would you suggest we should be monitoring with SNMP for loss of synchronisation?
Hello David, both Meinberg devices M600/MRS/PTP and SyncBoxN2X are SNMP compliant, therefore you can monitor both for their Sync Status.
Respected Sir/Madam,
We are using meinberg lantime M300 GPS. The time on meimberg device is showing correct time where as in the system lan time it’s showing time in 1980s . We were unable to change synchronize both. We also found error in lan time as receiver unsynchronized.. kindly help us in setting the system date & time same as that displaying on meinberg m300 device. Thank you
Dear Rajesh,
concerning this issue, please contact the Meinberg support at techsupport@meinberg.de
Thanks!
Kind regards,
Andreja
Hello,
we have getting this snmp trap “process NTP Reboot” very frequently.
Any idea?
thnaks in advance
Sif
Hi Sif,
can it be that you are using a server from another vendor, not Meinberg? It doesn’t hear like Meinberg. Please check the output of that trap again and send it me over to my email address.
Regards!
Requesting an update to this article to include Linux command-line examples using “snmpwalk” and “snmpget” binaries. Thanks in advance!
Hello Andreja,
is there a possibility to restrict the snmp v3 access to only one host/IP ?
Regards, Liviu
If I answer this one, i’ll probably get it wrong, since the software team is always adding new capabilities to the management interfaces. I suggest sending an email to info@meinberg.de for any product feature questions.