The Simple Times is an openly-available publication devoted to the promotion of the Simple Network Management Protocol. In each issue, The Simple Times presents: a refereed technical article, an industry comment, and several featured columns. In addition, some issues include brief announcements, summaries of recent publications, and an activities calendar. For information on submissions, see the end of this issue.
The Simple Times is openly-available. You are free to copy, distribute, or cite its contents; however, any use must credit both the contributor and The Simple Times. (Note that any trademarks appearing herein are the property of their respective owners.) Further, this publication is distributed on an "as is" basis, without warranty. Neither the publisher nor any contributor shall have any liability to any person or entity with respect to any liability, loss, or damage caused or alleged to be caused, directly or indirectly, by the information contained in The Simple Times.
The Simple Times is available via both electronic mail and hard copy. For information on subscriptions, see the end of this issue.
In this issue: Network Design Using the RMON MIB
There are a wealth of network devices available to a network designer that help segment traffic on a local area network. It is often useful to obtain some data about the traffic on the current network segment before modification or redesign. A network designer may have to choose between using bridging, switching, or routing technologies when formulating a network design. This article will show you how to use information available in the Remote Network Monitoring Management Information Base (RMON MIB), defined in RFC 1271, to facilitate this decision process.
The RMON MIB defines objects designed to help manage network segments. Some of this help comes in many useful forms including current and historical segment statistics, individual host specific statistics and host traffic matrices. Although this list of objects is only a subset of the overall information provided by the RMON MIB, this is the set of information which can significantly aid network design.
The probe can monitor all the traffic seen on a network segment because it has the ability to put its interfaces in promiscuous mode (hearing all frames). This enables the probe to monitor all traffic, not just the traffic sent to its own media-specific address (such as ethernet address). This is a significant difference in the monitoring ability of the RMON probe in comparison to those devices that only support MIB-II (RFC 1213). Devices that support MIB-II only maintain statistics on frames sent to their own address (or broadcasts).
Before talking further about network design, we need to define some MIB groups that exist in the RMON MIB. The first group, the Statistics group, has MIB objects that give statistics about each network segment the probe is monitoring. Examining these statistics will help us design a network using real-time information. Currently, these statistics are for ethernet and token ring only. For each segment being monitored the probe keeps a separate table of statistics. Some of the statistics kept about each segment include: total bytes, total packets, total broadcasts, and total collisions.
The next group, the History group, has objects that are similar to the Statistics group. The difference is that the History group provides a way for a network engineer or network management system to take periodic statistical samples from a segment. As we will see, the History group provides a historical perspective which is often necessary when doing network design. The probe can store statistics about network segments and allow you to retrieve them at a later date for analysis. The History group stores data the probe has gathered at each polling interval for ethernet and token ring media. Like the Statistics group, at the time of this writing, these are the only media supported in the History group, although the potential for other media-specific monitoring does exist.
The Matrix group of the RMON MIB stores statistics about conversations between hosts on the network segment. These statistics include the number of packets and bytes sent during each conversation. These statistics will become useful when trying to find an optimal way to segment a network.
The final RMON MIB group which will help us in network design is the Host group. The Host group contains statistics about each host on the network segment. These statistics include for each host: total bytes sent and received, total packets sent and received, total broadcasts sent, and total errors sent. These host specific statistics will also help us determine how to segment and divide a network segment.
When using these statistics to aid in network design, it is important to remember that different designs may be correct for different situations. For example, some network designers tend to optimize a network for maximum traffic rate, while others design for the mean traffic rate. Regardless, it is often necessary to examine the network over time (like a week or more) before making a definitive judgment about design. Throughout this article we will try to look at how to acquire the necessary information to allow you to make these design decisions properly.
The utilization of the network segment may be a direct indication that segmentation is necessary. You can compute the current utilization of the segment using objects from the Statistics group and the interface speed (using the Interface group object ifSpeed from MIB-II) as follows:
bit-rate =
8 * [delta(etherStatsOctets,t1,t0)
/ (t1 - t0)]
utilization =
bit-rate / ifSpeed
where
delta(X,t1,t0).
denotes the change between the statistic X at time t0 and time t1.
With ethernet, most experts agree that a consistent utilization above approximately 50 percent requires some form of segmentation to maintain adequate performance. To determine if the current utilization on your segment is consistent, you can use the History group object etherHistoryUtilization. This object gives you the percentage utilization of the segment, which you can poll over time using the probe.
Even if your ethernet utilization is consistently below 50 percent, segmentation may be necessary if you have excessive collisions. The definition of ``excessive'' may be different in many environments, but network administrators typically do not like to have more than 5 percent of their total ethernet packets causing collisions. You can calculate this percentage on your segment using objects from the Statistics group as follows:
collision-rate =
rate(etherStatsCollisions,t1,t0)
packet-rate =
rate(etherStatsPkts,t1,t0)
collision-percentage =
collision-rate / packet-rate
where
rate(X,t1,t0) = delta(X,t1,t0) / (t1 - t0).
If you find out that your current collision rate on the segment is
``excessive'' you may then use objects in the History group to find
out
if the collision percentage you are seeing is normal for the segment
by
polling these objects over time and performing the same calculations.
broadcast-rate =
rate(etherStatsBroadcastPkts,t1,t0)
multicast-rate =
rate(etherStatsMulticastPkts,t1,t0)
Experience shows that small hosts
(i.e., networked PCs)
often have difficulties when the broadcast rate is over 30
packets/second
(e.g.,
the internal bus on the PC becomes congested moving broadcast packets
from the interface card to the CPU).
Of course,
if a large percentage of your segment traffic is broadcasts and
multicasts,
an examination of the applications sending these frames may
be necessary!
Now, let us assume that you have found out that bridging may help your segment because broadcasts are not a significant amount of the traffic and you want to reduce your collision domain. The next thing to do is to determine where on your network segment would be the best location for the bridge. Ideally, you would like to keep a major percentage of the traffic on a single side of the bridge.
The probe monitors all of the conversations on the segment using the Matrix group. You can acquire information on the amount of bytes, packets, and errors sent between any two hosts using the objects in the Matrix group. The objects refer to communication from source to destination (the ``SD'' prefix in the object name) and the traffic from the destination back to the source (the ``DS'' prefix in the object name). For example, if you collect the object matrixSDOctets for each conversation, you can determine which hosts send the most bytes between themselves. Upon installation, you should ensure that both of these hosts are on the same side of the bridge.
When you consider about using a switch to segment your network, it might be useful to see if a majority of your traffic is many-to-many or many-to-one. If it is the latter, you may want to consider an alternative device. Using the RMON MIB objects you can easily tell the flow of your traffic using the Matrix group, as we saw previously. You can use the same objects as described earlier (i.e., matrixSDOctets) to make your determination.
Likewise, to the bridged environment, it is important to examine the amount of broadcasts and multicasts on your segment. If you have a large number of broadcast or multicast packets, switching may not help eliminate your problem as the switch needs to propagate these packets to each host.
You may find that a small subset of hosts on your segment have conversations with a large number of other hosts (by using the Matrix group objects). If this is true, you can use the Host Group objects to discover the percent utilization of the entire segment by a single host:
host-rate =
rate(hostInOctets,t1,t0)
+ rate(hostOutOctets,t1,t0)
byte-rate =
rate(etherStatsOctets,t1,t0)
host-utilization =
host-rate / byte-rate
You can use yet another group in the RMON MIB,
the HostTopN group which sorts the traffic seen on the network
segment by host.
You could further sort this information by bytes sent by each host.
This allows you to quickly identify which hosts communicate most
on the segment.
You can use the above formulas by using the HostTopN group
to show the top senders of octets,
and modifying the host-rate formula as follows:
host-rate = rate(hostTopNRate,t1,t0).
We may have found that a small number of hosts dominate the
traffic on
the segment and this may make a majority of our traffic many-to-
many.
Using this data,
we may decide to segment the traffic with a switch.
In some environments,
with a larger number of hosts,
network designers will attach the busiest hosts to a dedicated port
on
the switch and have other hosts which do not require dedicated
bandwidth
to share a port on the same switch.
By sorting hosts by traffic sent and received, the HostTopN group
objects can help you make the decision of how to attach each host to
the switch.
Likewise, the router ethernet address would be the source of a large percentage of traffic and appear as one of the busiest hosts in the HostTopN group.
It's the end of the year. I'm busy working on the test suite for next month's SNMP Testing Summit. So, no comment.
In this issue: {The Trend Towards Hierarchical Network Management
}
One of the keys to SNMP's success has been its centralized nature, which has helped to reduce its cost and increase its reliability. As SNMP-managed environments have grown and SNMP has been introduced into new environments, new goals have emerged. SNMP users are looking for new features such as further scalability, distributed intelligence, and eased integration. These goals can be achieved when network management is less centralized, especially when it forms a hierarchical management architecture, while still preserving the nature of SNMP's high manager to agent ratio. The RMON MIB and SNMPv2's Manager-to-Manager MIB are current examples of this, and new MIBs are under development that expand on this theme.
Remote ping and traceroute MIBs have been proposed that will allow these operations to be performed remotely. In the future, distributed expert systems applications will be able to send fault reports to higher level managers when network errors are detected.
Each of these developments brings hierarchical management to a particular network management function, providing the benefits of scalability, distributed intelligence, and enhanced integration.
In particular, the Manager-to-Manager MIB can be configured to poll one or more MIB variables on any number of devices. If the values of these variables cross pre-configured thresholds, an event report is forwarded to higher-level network managers. If any event report is dropped, it will be retransmitted. For example, a mid-level manager implementing the Manager-to-Manager MIB could be placed in a west coast office to monitor a network of thousands of machines, while only error reports are sent across the country to the management station in the New York network operations center.
The RMON MIB was designed to handle an even more difficult performance problem. A third-party network service organization may wish to manage a customer's network without having to install an expensive network link to the customer's site. Attaching a probe to a modem on a dialup phone line is an obvious choice, but long distance charges could still be expensive. The RMON MIB will allow the network manager to configure the probe to collect and store data and check thresholds continuously, then to hang up the phone line. If the probe detects a problem, it can dial the phone line, establish a PPP link, and send the error information to the manager. The manager will also periodically call the probe to download daily performance statistics and for other maintenance tasks, often at night when the rates are low.
If these MIBs are coupled with the aggregate MIB, the periodic diagnostics can become even more intelligent. Mathematical and logical functions of several variables may be continuously checked for health, alerting a manager when problems seem evident. In the future, expert systems may be distributed to each network with similar notifications when things go wrong.
An example is the Aggregate MIB. If a customer wishes to graph the sum of the disk operations on several servers, he might be out of luck if his graphing tool doesn't support that function. However, he could install an Aggregate MIB implementation and configure it to perform the mathematical operation and to return the result as a MIB variable, which can be graphed by his tool.
This sort of application-to-application interoperability can be applied to diagnostic applications, auto-discovery applications, and data analysis applications, as well.
The advantages that are provided by hierarchical applications will bring good cheer to those who need their higher efficiency, intelligence, or ease of integration. Even better news is that this technology has already been forging ahead and parts of it are ready to provide solutions today.
Dear Dr. SNMP,
I just ran a MIB-walker on a new release of an agent and the walker complained that a bunch of variables were of the wrong type. After some investigation we discovered that vendor had a new version of its MIB module with many new features implemented in its new code. They reused many of the OBJECT IDENTIFIERs in their old MIB. As a result, now the new MIB module works only with the new agent, and the old MIB modules work only with the old agent... You know the story. How can this happen?
-- Freaked-out in Fremont
Dear Freaked-out in Fremont,
Down on the farm (in merry ol' England), they have a saying:
``You cannot make people honest by an act of Parliament.''It seems to Dr. SNMP that the text in the Internet-standard SMI (RFC 1155, page 16) is pretty clear: ``New versions may not change the semantics of any previously defined object without changing the name of that object...''
However, every rule seems to have a loophole. The rigorous process for MIB extension and modification, as defined by the rules stated in the SMI, were intended by the authors to pertain to all MIB objects, including those in the mgmt(2) subtree and variables introduced by particular implementations of the protocol (experimental variables and variables found in enterprise MIB documents). These rules clearly prohibit the reuse you have witnessed. Regrettably, depending upon how one defines the term ``Internet-standard MIB'', one can argue about whether these rules apply to an enterprise MIB module, irrespective of the authors' clear intent. In fact, Dr. SNMP was quite surprised to find this loophole when researching the answer.
Of course, many things lawful are not expedient and Dr. SNMP is unwilling to condone the poor manners of this vendor. It is obvious that this vendor is imprudent, even if its actions do not violate the initial SNMP SMI, in that its actions have caused great difficulty for you, its customer. What is doubly troubling is that the vendor could have done the right thing at less expense.
Thankfully, RFC 1442, the SNMPv2 SMI, is crystal clear (at least in this matter). This is yet another loophole that has been closed by the SNMPv2 framework.
For both SNMPv1 and SNMPv2, the semantics of the set PDU require that it be implemented as a multi-phase operation. In this article, we'll examine some of the issues behind the need for multiple phases, and look at one possible implementation strategy.
Third, for some variables, the agent's validation of one variable can be dependent upon the values of other variables, and these other variables might also be modified by the same PDU. In such cases, the validation of the one variable must be performed using the values of the other variables as they would be after the set PDU is successful, i.e., using their values, if any, specified by the PDU. For example, suppose an agent imposes the restriction that the value of objectA.1 must be less than the value of objectB.1, and further suppose that the agent receives a set PDU which includes both objectA.1 and objectB.1 in its variable-bindings, with the new value of objectA.1 greater than the existing value of objectB.1, but less than the new value for objectB.1, then this set PDU must not fail because of that restriction.
Fourth, for some variables, the setting of a new value requires an agent to obtain additional resources. Further, the agent must keep temporary state information on the additional resources required since two variables in the same set PDU might contend for the same additional resources. If the required resources cannot be obtained, then the set PDU must fail. For example, when the setting of an object can cause the creation of a new entry in a fixed-length table, multiple instances of that object can be set in the same PDU. Thus, not only does the agent have to check that the table is not already full, but it must also keep track of how many additional entries in the table will need to be assigned for the set PDU to succeed.
Fifth, experience has shown that for some variables, the success of setting a new value cannot be absolutely guaranteed prior to the actual assignment of the new value. This is more often true for variables which have some type of action semantics, or some interaction with other parts of the (dynamic) system being managed. The implication here is that, if and when an actual assignment fails, an ``undo'' function is required to be executed for any other assignments already made.
In the first phase, local checking of the specified values for each of the variables is performed, i.e., checking which is not dependent on the values of any other variable which might also be set in the same PDU. This includes checking for the correct syntax, and that the new value is within the maximum range permitted by the agent under any circumstances. This phase records state information concerning which variables are being set (and to what values) by this PDU.
In the second phase, global checking is performed on the specified values, i.e., checking the values against the values of other variables, either those contained in the state information recorded in the first phase, or for any of the other variables not being set in this PDU, then their existing values. This phase also allocates any resources which will be needed for the assignment to be successful.
In the third phase, the actual assignments are made using the allocated resources, if any, obtained in the second phase.
The fourth phase is called when, and only if, an error was returned by the processing in any of the preceding phases. This phase attempts to undo assignments, if any, which have already been made, and releases any allocated resources which will not now be used.
For an SNMPv2 set PDU, a failure in the third phase will result in a commitFailed error, except when the fourth phase also fails, in which case it will result in an undoFailed error. For an SNMPv1 set PDU, both of these types of failures will result in a genErr error. Note that an agent should take all possible measures to avoid having to return either the commitFailed or the undoFailed errors. This is especially true of the latter, since an agent which returns the undoFailed error code is admitting that it has disobeyed the protocol specification!
For simple variables, there may be no need for global checking, no need for the allocation of any resources, and no possibility that the assignment can fail. For such variables, the second and fourth phases can be null.
Since the last issue, there have been no new SNMP related standards published. In the pipeline are several including the DNS server and resolver MIBs, an update of the DECnet Phase IV MIB, and the new IF table MIB.
Switching topics, the IETF standards process is still undergoing update and review. At the Houston IETF, a presentation was given on the new section about copyrights. Many people had questions. It appeared that this section needed to be reworded to explicitly state that it was allowable to create derivative works (i.e., stripped MIBs from RFCs) and publish them without any restrictions.
In the next issue, we'll present some opinions on why no standards have been created in the IETF on programmatic interfaces.
SNMPv2 Framework (Proposed Standards):
Full Standards:
Draft Standards:
Proposed Standards:
Experimental:
Informational:
Historical:
January 10-14, San Jose, CA
For information: +1 415 969 4544
March 28-April 1, Seattle, WA
For information: +1 703 620 8990
The Simple Times also solicits terse announcements of products and services, publications, and events. These contributions are reviewed only to the extent required to ensure commonly-accepted publication norms.
Submissions are accepted only via e-mail, and must be formatted in HTML version 1.0. Each submission must include the author's full name, title, affiliation, postal and electronic mail addresses, telephone, and fax numbers. Note that by initiating this process, the submitting party agrees to place the contribution into the public domain.
In addition, The Simple Times has numerous hard copy distribution outlets. Contact your favorite SNMP vendor and see if they carry it. If not, contact the publisher and ask for a list.