|
|
|
|
|
|
|
SNMP v3 may claim to resolve many inherent network management problems but it is just one of many innovations that will contribute towards improved network and application visibility, reports Stuart Mark. Network Management Technologies As networks grow in complexity, the technologies used to manage them are becoming less and less effective. Ironically, the very nature of network management means that it is constantly playing catch-up to technology that highlights its shortcomings. Only when a network manager tries to apply some form of control to his new multi-layer switches, VPN based network or multi-tiered application, does he become acutely aware of the management infrastructure’s flaws. This deficiency is widely acknowledged and has resulted in a variety of improvement initiatives from different areas of the networking community. Some of these are being co-ordinated by Internet Engineering Task Force (IETF) Working Groups while others are vendor driven. Many of the shortcomings facing today’s network manager revolve around the use of what has become the network management framework of choice, SNMP (Simple Network Management Protocol). Version 3 of this framework is now appearing in the marketplace but do the improvements go far enough to satisfy today’s increasingly stringent management requirements? SNMP vs CMIP The first SNMPv1 Request For Comments (RFCs) were published in 1989. The framework was originally intended to provide a standard method of managing the growing number of LAN networking devices coming on to the market and has evolved over the years to accommodate emerging protocols and medium. It is modular in nature and, although its name refers to a particular network protocol, that protocol is only one of four components that define the SNMP architecture;
Security and protocol inefficiency are two of the major shortcomings of SNMPv1. In certain situations, SNMPv1 could easily flood low bandwidth network links and, while inadequate security may be acceptable on a private enterprise, its use on wide area links and in the public domain is a real risk. To address these, the ISO introduced a new network management framework based on the Open Systems Interconnection (OSI) seven layer model called the Common Management Information Protocol (CMIP). This has extensions to provide compatibility with IEEE802 LANs called CMIP Over LLC (CMOL) and TCP-IP LANs called CMIP Over TCP (CMOT) While CMIP was a functional improvement on SNMPv1, there are two operational issues that have mostly restricted its use to the telecommunication domain. Firstly, it requires a large amount of system resources to run while SNMP requires modest processing power. Secondly, CMIP is very complex which means that a degree of specialist skill is required to run a CMIP implementation. SNMP is widely supported in the industry and is consequently, relatively easy to use. SNMP v2 & v3 The IETF has since attempted to improve SNMP but the proposed version two was never fully ratified because of disagreements over SNMPv2’s proposed security enhancements. Where version2 did succeed was in improving the efficiency of SMI by introducing bulk attribute retrieval capabilities to SNMP and some MIB enhancements. SMI has been updated to version 2 which, although the IETF claims loose interoperability between SMI versions and MIB types, introduces enough incompatibilities to cause problems. Nevertheless, the benefits to be gained have earned SNMPv2 a degree of industry acceptance in the form of several splinter specifications, most notably SNMPv2c, SNMPv2u and SNMPv2*. The ‘c’ version is endorsed by the IETF but has no security improvements while the ‘u’ and ‘*’ efforts carry security at the price of the aforementioned endorsement. Enter SNMPv3. The IETF have tried to address the maelstrom that is SNMP by issuing this latest standard which is based on the v2 ‘u’ and ‘*’ concepts. Most focus has been placed on security so SMIv2 has been retained in SNMPv3. A User Based Security Model (USM) has been introduced which uses MD5 and the Secure Hash algorithms. Support for the Data Encryption Standard (DES) is also provided. Vendor support of SNMPv3 is still sparse but looks promising with Cisco including it in IOS 12.0(6) and higher and provision in Redhat Linux 6.1 distribution. RMON Although SNMP is a great improvement, it is still only capable of providing connectivity management of individual network devices. Broader network views still need additional technologies like Remote Network Monitoring (RMON). The RMON MIB is intended to provide some of the functions of a local network analyser like segment statistics and packet capture from a distance to give network managers a way to centrally maintain their network. A McConnell Consulting Study recently estimated that a network team can support 150% more users and network segments using RMON. RMON2 which provides conversation and protocol oriented monitoring across a network is undergoing some enhancements. An IETF working group is updating the RMON MIB to support improved application performance measurement monitoring through the use of the RMON2 MIB protocol directory (RFC2021). Other functionality improvements will be differentiated services monitoring for QOS management, new monitoring for TopN Reporting on high density switches and username-to-address mapping among others. New strains of RMON are further enhancing it’s usefulness; Switched Monitoring (SMON), RFC2613 provides monitoring for switched network environments and High Capacity RMON (HCRMON) will be able to return statistics on today’s and tomorrow’s fastest media technologies. Application Management Vendors have also taken steps to improve our ability to manage applications. Agilent, Compuware and Netscout offer products that can provide different levels of application response time and latency management from the network. In fact, the solution developed by Netscout, known as the Application Response Time (ART) MIB, has been adopted by the IETF as a MIB extension to RMON2 and is currently in draft status. A further level of management can be attained through the Application Response Monitor Application Program Interface (ARM-API). Developed in a joint venture between HP and Tivoli in 1996 and updated in 1997, ARM allows software developers to incorporate transaction tracking and measurement into applications as they are written. The ARM-API is not part of the SNMP framework and cannot be managed by an SNMP management product. Instead, it requires dedicated management software, available from a number of vendors. Enterprise management solutions from companies like Tivoli should allow ARM and SNMP data to be accessed and correlated to give the first real end-to-end view of mutli-tiered application performance. So SNMP will finally become a secure network management protocol but it, alone, will not be enough to manage the enterprise network. Remember RMON and always keep up to date with vendor developments. www.tivoli.com www.hp.com www.netscout.com RFC2570 - 2575 SNMPv3 RFC2021 RMON2 RFC2613 SMON Summary
|
This site was last updated 04/25/07
