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 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.

Understanding SNMP's Information-Oriented Design

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.

Key Concept: Unlike most protocols, which are command-oriented, SNMP is information-oriented. SNMP operations are implemented using objects called variables that are maintained in managed devices. Rather than issuing commands, a network management station checks the status of a device by reading variables, and controls the operation of the device by changing (writing) variables.

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!