Internal Errigal Collaboration Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== SNMP & Traps in a Nutshell ======

Author: Cathal O'Keeffe

===== Introduction - What is SNMP =====

SNMP stands for simple network management protocol. As the name suggests, it is a standard protocol designed for managing devices. 

Wikipedia has a brief description of the theory [[https://en.wikipedia.org/wiki/SNMP|here]]. 

One of the most important things to note about SNMP is that it is a fire and forget protocol. This means there is no handshake to verify that anything has actually been received.

As a result, it is very important that monitoring has minimum downtime as devices being monitored will have no feedback that nothing is receiving their messages.


----


===== Traps =====

The part of the SNMP protocol we are most interested in is the traps. 

Traps are how we monitor devices for alarms and issues. 

For instance, the devices we monitor are all connected over private networks to our servers. When they experience an issue, they send a small UDP packet called a trap to us. 

This shifts the processing from the monitoring software. This means we don't have to constantly poll devices for fault (though we also do that to some extent), the devices send us alarms when they experience faults.

Traps are simple data objects. They are identified by an object identifier (OID). 

The OID is a series of numbers separated by dots. An example OID is ''.1.3.6.1.4.1.33582.1.1.2.6.4.1''.

----


===== Mibs =====

We use a file called a management information base (MIB) to translate OIDs. 

A MIB is a text file with a specific standard structure that defines what the OID values mean. 

The [[http://www.ireasoning.com/mibbrowser.shtml|MIB Browser]] tool made by iReasoning is very useful for exploring and understanding MIBs.

MIBs contain a tree structure that is used to translate the numbers of the OID into something understandable. 

**//But how do we know what MIB translates each trap?//** 

The long number in the middle of the OID is the enterprise number. It signifies which company made the device or the software the trap is being sent from and therefore who you can get the MIB from. 

These numbers are registered with the [[https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers|IANA]].

If you look up which company is identified by 33582 you'll find it's Errigal. This is one of our own internal traps. 

The MIB file to translate it is ''ERRIGAL-INTERNAL-SYSTEM-MIB.mib''. 

With this, we can translate the OID and find that this trap is called ''errigalMonitoredCarrierDeviceMissingAlarm''. 

This is a trap we send to our own systems to signify that we have received an alarm from a device that does not exist on our system yet.


----


===== Varbinds =====

**//But the trap just telling us that a device is missing isn't exactly very useful. What's missing?//** 

Traps also contain variable bindings (varbinds). Varbinds, similar to traps themselves, have an OID that identifies their name. 

They also have a value. A varbind's value can be a number, string, null or another OID (though in practice they are mostly strings and numbers). 

The varbind's OIDs are translated using the same MIB. 

Varbinds for our device missing alarm could be something like this:


^    Name OID                   ^  Name translated         ^  value                          ^
| .1.3.6.1.4.1.33582.1.1.1.1.0  | alarmNotificationStatus  |  information                       |
| .1.3.6.1.4.1.33582.1.1.1.2.0  | hostName                 |  VD_WD_PeoplesPark_03              |
| .1.3.6.1.4.1.33582.1.1.1.3.0  | equipmentIdentifier      |  VD_WD_PeoplesPark_03-RM_20        |
| .1.3.6.1.4.1.33582.1.1.1.4.0  | equipmentType            |  MOBILE_ACCESS                     |
| .1.3.6.1.4.1.33582.1.1.1.5.0  | customerName             |  VODA                              |
| .1.3.6.1.4.1.33582.1.1.1.6.0  | alarmIdentifier          |  btscRfSwOn                        |
| .1.3.6.1.4.1.33582.1.1.1.7.0  | alarmDescription         |  btscRfSwOn                        |
| .1.3.6.1.4.1.33582.1.1.1.8.0  | ipAddress                |  9.9.9.9                           |

The varbinds each have a specific meaning that is usually documented within the MIB itself. 

In this case it would signify:
  *  That we have received a btscRfSwOn alarm 
  *  From a piece of equipment called VD_WD_PeoplesPark_03-RM_20 
  *  Which is attached to a host VD_WD_PeoplesPark_03 
  *  From IP address 9.9.9.9 
  *  Which we have processed as being part of the MOBILE_ACCESS technology 
  *  And belongs to customer VODA. 

If not all of this information makes sense yet don't worry. 

Just know that each different type of trap will have different varbinds with different values that have to be interpreted by our software. 

We take all this information at a later stage and put it into a standardised format using [[onboarding:snmpmanager:trap_rule_testing|Trap Rules]].

----

===== Trap Handling Diagram =====

{{ :onboarding:snmpmanager:trap_handling.png?nolink |}}




===== Onboarding Exercise =====

  * Download the [[http://www.ireasoning.com/mibbrowser.shtml|MIB Browser]] and get a copy of the ''ERRIGAL-INTERNAL-SYSTEM-MIB.mib'' (ask one of the developers or senior support staff).
  * Explore the MIB and find where in it the ''errigalMonitoredCarrierDeviceMissingAlarm'' is defined as well as each of the varbinds specified above. 
  * See what other types of alarms and varbinds are defined in the MIB.
Sidebar

Internal Errigal Collaboration Wiki

User Tools

Site Tools

Page Tools
