Network Management Basics: SNMP
Abstract:
From the dawning days of The Internet, the network grew from hosts on a wire, to hosts on a wire joined by a bridge to extend electrical signals, to a logical group of hosts on wires being defined as a network and joined to other networks via routers. Throughout these periods, there was always a need for a way to manage the infrastructure, and SNMP is The Internet Standard. The SNMP Internet Standard is a critical piece of total management business requirements.
The Network:
Every device on The Internet has a physical Hardware Address, to facilitate communications on it's own wire, and a logical Internet Protocol (IP) Address, to facilitate communications to other locations, provided through Routers. Someone on that network has to provide the logical IP Addresses, this person is normally some kind of network administrator. This person has some kind of responsibility to manage the network.
[ARPANET diagram, courtesy wikipedia]
The Creation:
Networks were traditionally circuit switched, driven by a telephone company. In 1969, Steve Crocker developed a system to track agreed upon standards, called RFC's (Request for Comments), to facilitate interconnection of networks. The worlds first operational packet switching network came into existence, known as ARPANET (the Advanced Research Projects Agency Network) in 1977.
Ping:
As The Internet started to grow, basic diagnosis utilities were needed. Mike Muuss created a utility called Ping in December 1983. The most important function of this tool was the use of the ICMP Echo Request (type 8) network packet to another IP Address and the observation of the returned value.
The Manager may send an Echo Request or Ping to a remote device's logical IP Address to see if there is connectivity. If there is no connectivity, no packet is returned, or sometimes an Router in the path may return a message such as "Host Unreachable" or "TTL Exceeded" (packet time-to-live.) The manager may receive additional information such as the time it took for the packet to make the round trip.
Traceroute:
As networks continued to get more complex, the management requirements grew. Traceroute was born, attributed to Van Jacobson in 1987. Now, the manager could send a packet to an agent and receive a path of each router which the packet would traverse, bundling in the round trip times.
The Problem:
Such tools like "ping" and "traceroute" were critical for an individual manager to understand network connectivity - but neither provided in-depth information about the target agent device. A "ping" not being returned did not necessarily mean that the agent or target device is "down".
A “ping” returning does not necessarily mean
that the agent did not go down a few minutes earlier. A "traceroute" response to another location does not necessarily mean there is a problem with the agent or target device. These tools did not do much to allow a manager to understand history of a device or the intermediate network devices.
SNMPv1:
In 1988, SNMP (now referred to as Version 1) was born, through a variety of published RFC's. SNMP retained many of the advantages of ICMP and Traceroute (light-weight, avoided use of heavy TCP protocol), but brought to the world:
- programmable name for a device agent
- programmable location field for a device agent
- a description of the hardware and firmware on the device agent
- last-reboot counter of the device agent
- configuration, fault, and performance knowledge of interfaces (Interface Table)
- other physical hardware devices connected on the network (ARP Table)
- other neighboring logical devices connected on the network (Routing Table)
- passwords (called community strings) for basic protection
- framework for vendors to extend the management capabilities
This information is held in the MIB (Management Information Base) of the device - a database of information that each device holds regarding the health of the hardware, firmware, operating system, and applications.)
SNMPv1 was made up of RFC 1065, 1066, 1067. Updates included 1155, 1156, 1157. RFC 1213 (called MIB-1) was later updated 1156 (called MIB-2.)
SNMPv2:
In 1993, SNMP Version 2 was created through RFC's 1141-1452. Security was updated, but not widely adopted. Introduced was an efficient way to transfer information (GetBulkRequest) - which was readily adopted, to alleviate concerns of the protocol being "overly chatty".
SNMPv2c:
In 1996, SNMPv2c (Community-Based Simple Network Management Protocol Version 2) was introduced in RFC 1901-1908. The most important added the capability was to encrypt the password (community string) in transit, alleviating the concerns of the protocol being "insecure".
SNMPv3:
In December 2002, SNMPv3 was released, comprised of RFC's 3411-3418. In 2004, the IETF (Internet Engineering Task Force) designated SNMPv3 as STD0062 or a Full Internet Standard. Practically speaking, SNMPv3 adds encryption of the payload, to completely secure the protocol.
Modern Computing:
Today, nearly every modern equipment vendor, who instruments their internet equipment for management, bundles SNMP in their standard packaging - since
SNMPv3 is The Internet Standard. This means that most equipment that plugs into a network via ethernet or wireless can be managed in an "agentless" manor (i.e. without loading any special additional components.)
Most Internet Infrastructure (i.e. computers, servers, routers, switches, etc.) allow for the following basic capabilities (sometimes using an internet standard, sometimes using vendor extension):
- Interface Configuration (administratively up, down; interface capacity)
- Interface Fault Status (Up, Down, Testing, Last-Change Time-stamp))
- Interface Performance Statistics (packets, bytes, errors, etc.)
- SNMP Agent Last-Reboot Timestamp
- Memory and/or Buffer Usage; Buffer Allocation Errors
- Flash and/or Disk Capacity and Usage
- Running Processes
- Installed Software
- CPU Usage
- Alert to a Manager when an Agent detects a problem
Customer Benefit:
Since SNMPv3 is The IETF Internet Standard, most equipment on a network can be reasonably managed without ever adding software to an end device. This means a service provider can provide greater insight into the health and performance of a customer estate with proper management software, especially historical trends when data is captured and stored in a database.
Difficulties:
SNMP is only a piece of the puzzle for managing a network.
- Business Processes
A customer must know what business services are traversing a device to understand the impact of an outage or what business processes are at risk when assets in the estate are performing poorly.
- Security / End-of-Life Management
A customer must know the version of the hardware and firmware is in the
estate in order to understand when a security vulnerability or end-of-life equipment may place
their business at risk.
- Logistics / Asset Management
A customer must know what assets make up their network estate and where the assets are located in order to understand where impacts originate during faults or where security risks exist.
- Configuration Management
A customer must know how to update the firmware on managed devices in the estate when defects in the software may be impacting business processes or creating security risks due to vulnerabilities.
- Performance Management
A customer must know what "normal" operation of their estate is, collecting this data over time, in order to predict when faults will arise, so impacts to business processes are minimized.
- Fault Management
A customer must know when faults occurred in the past, where they occured, when they occurred, what the problem was, and what the solution was - in order to understand the business impacts and create a strategy to mitigate future similar business impacts.
SNMP is a single skill, which can be leveraged to manage any number of device vendor, types, and model numbers. Network Management requires an expertise in all of the above areas, in addition to understanding SNMP.
This open up a prime opportunity for service providers with experience to assist customers since customers may only have experience with a particular device vendor/model/type or not have experience in SNMP.
