MESSAGING STANDARDS

You will need to be familiar with current messaging standards for network management and understand the basics of how they work in order to effectively plan an SME.

TCP/IP and UDP

We defined TCP/IP and UDP in Chapter 6, but we mention them again here in the context of network management in order to show the different philosophies under which some of the standards were created. To put things in perspective, there are two major components in an SNMP-based management system: the management station and the SNMP agent. The management station polls agents on a cyclic basis to assess status and health. The agent responds to these queries with formatted information. Additionally, the agent can send an unsolicited SNMP "trap" asynchronously when it detects a health-or status- related event. The normal SNMP transport protocol is UDP, which uses a "best effort" delivery mechanism. There is no guarantee the packet will ever arrive at its destination. The advantage is that UDP packets are small and of a similar size , lacking the complexity of a TCP/IP packet.

Note 

UDP packets are not of fixed size; they are variable up to 65,536 bytesthe largest datagram IP can support. Generally, UDP frames will be 576 bytes or less, because IP requires all network links to support an MTU of 576 bytes. Sending a UDP datagram larger than this risks fragmentation.

Given the limitations of UDP, it may seem that TCP is more appropriate for delivery of management information. This is not necessarily true; it depends on the application. All TCP really does is automatically retransmit if it doesn't receive an acknowledgment (ACK). When running with UDP, the SNMP manager is responsible for detecting the lack of response and retransmitting. Consider the case in which a response packet is lost, and the network remains down for five seconds. With a TCP-based SNMP, TCP will retransmit several times and will eventually deliver the response. The response it delivers will be at least five seconds out-of-date. With UDP, the management console will reissue the request, and when the network is finally operational again, the response will be the most up-to-date possible.

Note 

A trap, however, can be lost. Generally, administrators don't depend on SNMP traps as the only notification of failures because traps work poorly in a lot of NMS implementations . Instead, the management console periodically polls for status.

TCP/IP also lacks a guaranteed delivery mechanism, but it at least supports packet resequencing and destination routing, making it less prone to delivery failure. This is important when considering which protocol would provide a better transport option for system status and alert messages.

Simple Network Management Protocol

Simple Network Management Protocol (SNMP) is an application-layer protocol that uses the underlying transport services of the protocol stack. SNMP version 1 (SNMPv1) uses UDP and IP. The inclusion of SNMPv1 in networking equipment is widespread, and you are likely to encounter it. SNMPv2 has been enhanced in a number of ways to make it more robust than its predecessor and is the most common implementation today. Ironically, SNMPv2 fell far short of the vision set forth in its specification, particularly in the area of security. SNMPv3 is the implementation designed to address the security issue as well as the other shortcomings of its predecessors. The current specifications, RFCs, and a supported hardware list can be found at http://www.snmp.org.

Note 

SNMPv1 and SNMPv2 have significant security weaknesses. Microsoft implementations rely on these versions and default to one community string (public) and "Accept Packets from all hosts." Immediately upon installation of the SNMP service, these values should be changed to a unique community string and "Accept Packets from these hosts " with a list of valid host addresses. Virtually every LAN/WAN hardware vendor's default implementation of SNMP suffers from these same weaknesses, with community strings of "public," "private," or a documented string, and no trap or manager restrictions. Thus, it is important to always change default SNMP settings.

image from book

The data exchanged between managers and agents follows a standard hierarchical format described as the management information base (MIB). The manager is responsible for taking the MIB data sent by the agents, interpreting the format, aggregating, collating, and correlating it to higher-level events. The manager's task is also to make this information available for queries or reports . The structure of the MIBs is defined by the IETF in several requests for comments (RFCs), and new MIBs are being created all the time. MIBs for various categories of devices store their information in a standard place on the tree hierarchy. Thus, all routers are in the same branch of the tree, all hubs are in the same branch, and all CSU/DSU devices are in the same branch, as shown in Figure 9-1, a simplified view of a network equipment MIB.

image from book
Figure 9-1: The MIB hierarchy

SNMP's community is similar to a domain in NT networking. An SNMP community defines a set of agents that are related in some way. A community could define a company division, a geographic location (such as a data center), or even a similar class of equipment, such as all routers. A manager can typically receive and process messages from multiple communities and provide views into the messages separated by those communities, as shown in Figure 9-2.

image from book
Figure 9-2: SNMP communities

SNMP is being improved and extended continuously, but the current widespread standard is SNMPv2. Though any implementation must provide the basic features of the manager and agent, vendors are free to add functionality as they see fit according to the needs of the platform. SNMP has the following advantages and limitations. These are some advantages of SNMP:

  • It works well in its limited scope and is easy to extend.

  • Agents are ubiquitous on network equipment and operating systems.

  • The specifications are simple and easy to implement.

  • The performance overhead of an agent is minimal.

  • A polling approach to collecting data is good for managed objects on a LAN.

These are among the limitations:

  • Weak security!

  • It is very limited in scope and does not scale well in large implementations.

  • Its unique messaging structure makes it hard to integrate with other management tools.

  • Polling can cause a large bandwidth overhead in large networks.

  • It has many vendor-specific extensions to each standard MIB.

Note 

SNMPv1 and SNMPv2 can coexist by implementing a so-called SNMP Proxy to convert message formats. Many manufacturers of monitoring tools, such as Hewlett-Packard, include such a proxy with their standard offerings.

Remote Monitoring Agent

Defined in RFC 1757, Remote Monitoring Agent (RMON) is an extension of the most current SNMP MIB structure (MIB II) and attempts to address many of its limitations. RMON collects nine types of information:

  • Host table of all addresses

  • Host statistics

  • Historical data

  • Alarm thresholds

  • Configurable statistics

  • Traffic matrix with all nodes

  • "Host top N" tables

  • Packet capture/protocol analysis

  • Distributed logging of events

RMON represents the next generation in network monitoring and addresses the need for network planning, fault troubleshooting, and performance tuning better than any other current monitoring implementation. The additional capabilities of RMON change the agent-manager paradigm somewhat. Since sending richer data packets over the network would increase the SNMP demand for bandwidth significantly, implementations of RMON agents are typically " smarter " than their SNMP counterparts. That is, more processing is done on the agent platform, and only aggregated information is sent over the network. The trade-off is that more processing power is needed on the agent platform.

CMIP

Similar to RMON, the complexity required of a CMIP agent and the potential amount of information the agent sends over the network are high. It is a common feature in telecommunications equipment specifications, but it is rarely used in practice. It was probably included due to the fact that messages can be sent over an alternate channel from those used by data.

Note 

SNMP is common in telecommunications equipment, even though the ISO standards say it shouldn't be. For example, the SONET D1+D2+D3 bytes are an out-of- band communications channel used to communicate control and management information between SONET equipment. According to the SONET specifications, CMIP is used over this channel. If you look at actual SONET networks, the D1+D2+D3 channel is actually carrying either Bellcore's old ASCII command language or SNMP.

CMIP functions similarly to SNMP, in that it sends an alert if certain thresholds are reached or a fault is detected .

These are some advantages of CMIP:

  • Its object-oriented approach is very ordered, making extensions relatively easy to accomplish and manage.

  • It supports communication between managers as well as managers and agents.

  • It supplies a standard framework for automation.

Limitations include these factors:

  • It is not widely supported in the data-networking world.

  • It is the most complex protocol and puts high demands on the agent platform.

  • Its sheer complexity also means that CMIP implementations from different vendors frequently cannot communicate.

  • Its extensible messaging architecture can cause high network bandwidth utilization.



Citrix Access Suite 4 for Windows Server 2003. The Official Guide
Citrix Access Suite 4 for Windows Server 2003: The Official Guide, Third Edition
ISBN: 0072262893
EAN: 2147483647
Year: 2004
Pages: 137

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net