Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Network Configuration and Management Protocols (BOOTP, DHCP, SNMP and RMON)            9  TCP/IP Network Management Framework and Protocols (SNMP and RMON)                 9  TCP/IP Structure of Management Information (SMI) and Management Information Bases (MIBs)

TCP/IP Structure of Management Information (SMI) and Management Information Bases (MIBs) 1 2 3 TCP/IP MIB Objects, Object Characteristics and Object Types

The key to really understanding TCP/IP network management is to comprehend the information-oriented nature of the entire Internet Standard Management Framework (SNMP Framework). To see what I mean by this, let's step back for a moment and consider in general terms the problem of network management, and more specifically, the problem of managing devices on a network.

A network administrator needs to perform two basic types of actions: gather data about devices to learn how they are functioning, and give commands to devices to change how they are functioning. In the simplest terms, the first category can be considered like a “read” operation, and the second is comparable to a “write” operation.

A classical way of implementing this functionality is to define a communication protocol. Most such protocols are command-oriented—they consist of a specific set of commands to perform the “read” and “write” operations we mentioned above. For example, a network management protocol might have a read command such as “report on number of hours device has been in use”, and a write command such as “put this device into test mode”. The network manager would control the device by giving the appropriate commands.

A command-oriented management protocol has the advantage of simplicity: it's clear what the commands are for and how they are to be used. It can be reasonably well-suited for use in certain environments, but it doesn't work well on a large, heterogeneous TCP/IP internetwork. The main reason for this is that command-orientation inextricably ties the protocol to the devices being managed. Consider:

• Every type of device might require a distinct set of commands. For example, the commands given to a router might need to be different than those given to a host. This would lead either to a proliferation of commands in the protocol, or to inflexibility in allowing proper management of different device types.
  
  
• Every time a company created a new type of device, or made a unique version of a type of device, the network management protocol would have to be changed.
  
  
• Whenever the operation of a kind of device changed, due perhaps to a change in another protocol, the management protocol would need to be updated.
  
  
• The protocol itself could not be easily changed without affecting a lot of hardware.

The solution to the problems of command-oriented management protocols was to use an information-oriented model. Instead of defining specific commands that interrogate or control devices, the devices are defined in terms of units of information that are to be exchanged between the devices and a management station.

Instead of “read” commands and “write” commands, we have variables that can be “read” or “written”. Take the two examples mentioned earlier. Instead of a command like “report on a number of hours device has been in use”, the device keeps a variable called “number of hours in use” and the network management station can “read” this as one of many variables, with no need for a specific protocol command. Instead of a “write” command called “put this device into test mode”, the device has a variable called “current mode”. The network manager can change the mode of the device to “test” by changing the value of the variable.

This difference may seem subtle, but it in fact underlies every aspect of how SNMP works. I believe part of why the SNMP Framework is hard to understand is because insufficient emphasis is placed on looking at things in the “SNMP way”, which means thinking about information objects and not commands.

TCP/IP Structure of Management Information (SMI) and Management Information Bases (MIBs) 1 2 3 TCP/IP MIB Objects, Object Characteristics and Object Types