The first SNMP release came out in 1988. 28 years later, SNMP is still around, a go to Network Management tool … Will this still be the case in 10 years from now? Difficult to say but the odds are lower these days. Why are we predicting SNMP could go away?
If you’re already savvy about SNMP, check out this blog for getting insight into current SNMP limitations and why we are making this prediction.
SNMP was designed to make it simple for the NMS to request and consume data. But those same data models and operations make it difficult for routers to scale to the needs of today’s networks. To understand this, you first need to understand the fundamentals of SNMP.
SNMP stands for Simple Network Management Protocol. It was introduced to meet the growing need for managing IP devices in a standard way. SNMP provides its users with a “simple” set of operations that allows these devices to be managed remotely. SNMP was designed to make it simple for the NMS to request and consume data. But those same data models and operations make it difficult for routers to scale to the needs of today’s networks. To understand this, you first need to understand the fundamentals of SNMP.
For example, you can use SNMP to shut down an interface on your router or check the speed at which your Ethernet interface is operating. SNMP can even monitor the temperature on your router and warn you when it is getting too high.
The overall architecture is rather simple – there are essentially 2 main components (see Figure 1)
- A centralized NMS system
- Distributed agents (little piece of software running on managed network devices)
NMS is responsible for polling and receiving traps from agents in the network:
- Polling a network device is the act of querying an agent for some piece of information.
- A trap is a way for the agent to alert the NMS that something wrong has happened. Traps are sent asynchronously, not in response to queries from the NMS.
How is information actually structured on network devices? A Management Information Base (MIB) is present on every network device. This can be thought as a database of objects that the agent tracks. Any piece of information that can be accessed by the NMS is defined in a MIB.
Managed objects are stored into a treelike hierarchy as described in Figure 2:
The directory branch is actually not used. The management branch (mgmt) defines a standard set of objects that every network device needs to support. The experimental branch is for research purposes only and finally the private branch is for vendors to define objects specific to their devices.
Each managed object is uniquely defined by a name, e.g. an OID (Object Identifier). An object ID consists of a series of integers based on the nodes in the tree, separated by dots (.).
Under the mgmt branch, one can find the MIB-II that is an important MIB for TCP/IP networks. It is defined in RFC 1213 and you can see an extract in Figure 3.
With that mind, the OID for accessing information related to interfaces is: 126.96.36.199.2.1.2 and for information related to system: 188.8.131.52.2.1.1
Finally, there are 2 main SNMP request types to retrieve information.
GET request – request a single value by its Object identifier (see Figure 4)
GET-NEXT request – request a single value that is next in the lexical order from the requested Object Identifier (see Figure 5)
This is a repost of a blog by one of our service partners Cisco.