NETWORK MANAGEMENT

Network management refers to the activities, methods, procedures, and tools that pertain to the operation, administration, maintenance, and provisioning of networked systems.
[1]

Operation deals with keeping the network (and the services that the network provides) up and running smoothly. It includes monitoring the network to spot problems as soon as possible, ideally before users are affected.

Administration deals with keeping track of resources in the network and how they are assigned. It includes all the "housekeeping" that is necessary to keep the network under control.

Maintenance is concerned with performing repairs and upgradesfor example, when equipment must be replaced, when a router needs a patch for an operating system image, when a new switch is added to a network. Maintenance also involves corrective and preventive measures to make the managed network run "better", such as adjusting device configuration parameters.

Provisioning is concerned with configuring resources in the network to support a given service. For example, this might include setting up the network so that a new customer can receive voice service.

A common way of characterizing network management functions is FCAPSFault, Configuration, Accounting, Performance and Security.

Note: Network management does not include user terminal equipment. [edit]Technologies A small number of accessories methods exist to support network and network device management. Access methods include the SNMP,command-line interface (CLIs), custom XML, CMIP, Windows Management Instrumentation (WMI), Transaction Language 1, CORBA,NETCONF, and the Java Management Extensions (JMX). Schemas include the WBEM, the Common Information Model, and MTOSI amongst others. Medical Service Providers provide a niche marketing utility for managed service providers; as HIPAA legislation consistently increases demands for knowledgeable providers. Medical Service Providers are

liable for the protection of their clients confidential information, including in an electronic realm. This liability creates a significant need for managed service providers who can provide secure infrastructure for

SNMP
Simple Network Management Protocol (SNMP) is an "Internet-standard protocol for managing devices on IP networks. Devices that typically support SNMP include routers, switches, servers, workstations, printers, modem racks, and more.SNMP is a component of the Internet Protocol Suite as defined by the Internet Engineering Task Force (IETF). It consists of a set of standards for network management, including an application layer protocol, a database schema, and a set of data objects.
[2]

SNMP exposes management data in the form of variables on the managed systems, which describe the system configuration. These variables can then be queried (and sometimes set) by managing applications. [edit]Overview

and basic concepts

In typical SNMP uses, one or more administrative computers called managers have the task of monitoring or managing a group of hosts or devices on a computer network. Each managed system executes, at all times, a software component called an agent which reports information via SNMP to the manager. Essentially, SNMP agents expose management data on the managed systems as variables. The protocol also permits active management tasks, such as modifying and applying a new configuration through remote modification of these variables. The variables accessible via SNMP are organized in hierarchies. These hierarchies, and other metadata (such as type and description of the variable), are described byManagement Information Bases (MIBs). An SNMP-managed network consists of three key components: Managed device Agent software which runs on managed devices Network management system (NMS) software which runs on the manager

A managed device is a network node that implements an SNMP interface that allows unidirectional (readonly) or bidirectional access to node-specific information. Managed devices exchange node-specific information with the NMSs. Sometimes called network elements, the managed devices can be any type of device, including, but not limited to, routers, access servers, switches, bridges, hubs, IP telephones, IP video cameras, computer hosts, and printers.

An agent is a network-management software module that resides on a managed device. An agent has local knowledge of management information and translates that information to or from an SNMP specific form. A network management system (NMS) executes applications that monitor and control managed devices. NMSs provide the bulk of the processing and memory resources required for network management. One or more NMSs may exist on any managed network. [edit]Management

information base (MIB)

Main article: Management information base SNMP itself does not define which information (which variables) a managed system should offer. Rather, SNMP uses an extensible design, where the available information is defined by management information bases (MIBs). MIBs describe the structure of the management data of a device subsystem; they use a hierarchical namespace containing object identifiers (OID). Each OID identifies a variable that can be read or set via SNMP. MIBs use the notation defined by ASN.1. [edit]Protocol

details

SNMP operates in the Application Layer of the Internet Protocol Suite (Layer 7 of the OSI model). The SNMP agent receives requests on UDP port 161. The manager may send requests from any available source port to port 161 in the agent. The agent response will be sent back to the source port on the manager. The manager receives notifications (Traps and InformRequests) on port 162. The agent may generate notifications from any available port. SNMPv1 specifies five core protocol data units (PDUs). Two other PDUs, GetBulkRequest and InformRequest were added in SNMPv2 and carried over to SNMPv3. All SNMP PDUs are constructed as follows: IP header UDP header version community PDU-type request-id error-status error-index variable bindings

The seven SNMP protocol data units (PDUs) are as follows: [edit]GetRequest A manager-to-agent request to retrieve the value of a variable or list of variables. Desired variables are specified in variable bindings (values are not used). Retrieval of the specified variable values is to be done as an atomic operation by the agent. A Response with current values is returned.

[edit]SetRequest A manager-to-agent request to change the value of a variable or list of variables. Variable bindings are specified in the body of the request. Changes to all specified variables are to be made as an atomic operation by the agent. A Response with (current) new values for the variables is returned. [edit]GetNextRequest A manager-to-agent request to discover available variables and their values. Returns a Response with variable binding for the lexicographically next variable in the MIB. The entire MIB of an agent can be walked by iterative application of GetNextRequest starting at OID 0. Rows of a table can be read by specifying column OIDs in the variable bindings of the request. [edit]GetBulkRequest Optimized version of GetNextRequest. A manager-to-agent request for multiple iterations of GetNextRequest. Returns a Response with multiple variable bindings walked from the variable binding or bindings in the request. PDU specific non-repeaters and max-repetitions fields are used to control response behavior. GetBulkRequest was introduced in SNMPv2. [edit]Response Returns variable bindings and acknowledgement from agent to manager for GetRequest, SetRequest, GetNextRequest, GetBulkRequest andInformRequest. Error reporting is provided by error-status and error-index fields. Although it was used as a response to both gets and sets, this PDU was called GetResponse in SNMPv1. [edit]Trap Asynchronous notification from agent to manager. Includes current sysUpTime value, an OID identifying the type of trap and optional variable bindings. Destination addressing for traps is determined in an application-specific manner typically through trap configuration variables in the MIB. The format of the trap message was changed in SNMPv2 and the PDU was renamed SNMPv2-Trap. [edit]InformRequest Acknowledged asynchronous notification from manager to manager. This PDU uses the same format as the SNMPv2 version of Trap. Manager-to-manager notifications were already possible in SNMPv1 (using a Trap), but as SNMP commonly runs over UDP where delivery is not assured and dropped packets are not reported, delivery of a Trap was not guaranteed. InformRequest fixes this by sending back an acknowledgement on receipt. Receiver replies with Response parroting all information in the InformRequest. This PDU was introduced in SNMPv2. [edit]Development

and usage

[edit]Version

SNMP version 1 (SNMPv1) is the initial implementation of the SNMP protocol. SNMPv1 operates over protocols such as User Datagram Protocol (UDP), Internet Protocol (IP), OSI Connectionless Network Service (CLNS), AppleTalk Datagram-Delivery Protocol (DDP), and Novell Internet Packet Exchange (IPX). SNMPv1 is widely used and is the de facto network-management protocol in the Internet community.
[citation needed]

The first RFCs for SNMP, now known as SNMPv1, appeared in 1988: RFC 1065 Structure and identification of management information for TCP/IP-based internets RFC 1066 Management information base for network management of TCP/IP-based internets RFC 1067 A simple network management protocol

These protocols were obsoleted by: RFC 1155 Structure and identification of management information for TCP/IP-based internets RFC 1156 Management information base for network management of TCP/IP-based internets RFC 1157 A simple network management protocol

After a short time, RFC 1156 (MIB-1) was replaced by more often used: RFC 1213 Version 2 of management information base (MIB-2) for network management of TCP/IP-based internets Version 1 has been criticized for its poor security.
[3]

Authentication of clients is performed only by a

"community string", in effect a type of password, which is transmitted in cleartext. The '80s design of SNMP V1 was done by a group of collaborators who viewed the officially sponsored OSI/IETF/NSF (National Science Foundation) effort (HEMS/CMIS/CMIP) as both unimplementable in the computing platforms of the time as well as potentially unworkable. SNMP was approved based on a belief that it was an interim protocol needed for taking steps towards large scale deployment of the Internet and its commercialization. In that time period Internet-standard authentication/security was both a dream and discouraged by focused protocol design groups. [edit]Version

SNMPv2 (RFC 1441RFC 1452), revises version 1 and includes improvements in the areas of performance, security, confidentiality, and manager-to-manager communications. It introduced GetBulkRequest, an alternative to iterative GetNextRequests for retrieving large amounts of management data in a single request. However, the new party-based security system in SNMPv2, viewed by many as overly complex, was not widely accepted.
[3]

Community-Based Simple Network Management Protocol version 2, or SNMPv2c, is defined in RFC 1901RFC 1908. In its initial stages, this was also informally known as SNMPv1.5.
[citation needed]

SNMPv2c

comprises SNMPv2 without the controversial new SNMP v2 security model, using instead the simple community-based security scheme of SNMPv1. While officially only a "Draft Standard", this is widely considered the de facto SNMPv2 standard. User-Based Simple Network Management Protocol version 2, or SNMPv2u, is defined in RFC 1909RFC 1910. This is a compromise that attempts to offer greater security than SNMPv1, but without incurring the high complexity of SNMPv2. A variant of this was commercialized as SNMP v2*, and the mechanism was eventually adopted as one of two security frameworks in SNMP v3. [edit]SNMPv1
[citation needed]

& SNMPv2c interoperability

As presently specified, SNMPv2 is incompatible with SNMPv1 in two key areas: message formats and protocol operations. SNMPv2c messages use different header and protocol data unit (PDU) formats from SNMPv1 messages. SNMPv2c also uses two protocol operations that are not specified in SNMPv1. Furthermore, RFC 2576 defines two possible SNMPv1/v2c coexistence strategies: proxy agents and bilingual network-management systems. [edit]Proxy agents A SNMPv2 agent can act as a proxy agent on behalf of SNMPv1 managed devices, as follows: A SNMPv2 NMS issues a command intended for a SNMPv1 agent. The NMS sends the SNMP message to the SNMPv2 proxy agent. The proxy agent forwards Get, GetNext, and Set messages to the SNMPv1 agent unchanged. GetBulk messages are converted by the proxy agent to GetNext messages and then are forwarded to the SNMPv1 agent. The proxy agent maps SNMPv1 trap messages to SNMPv2 trap messages and then forwards them to the NMS. [edit]Bilingual network-management system Bilingual SNMPv2 network-management systems support both SNMPv1 and SNMPv2. To support this dual-management environment, a management application in the bilingual NMS must contact an agent. The NMS then examines information stored in a local database to determine whether the agent supports SNMPv1 or SNMPv2. Based on the information in the database, the NMS communicates with the agent using the appropriate version of SNMP.

[edit]Version

Although SNMPv3 makes no changes to the protocol aside from the addition of cryptographic security, its developers have managed to make things look much different by introducing new textual conventions, concepts, and terminology.
[1]

SNMPv3 primarily added security and remote configuration enhancements to SNMP.

[4]

Security has been the biggest weakness of SNMP since the beginning. Authentication in SNMP Versions 1 and 2 amounts to nothing more than a password (community string) sent in clear text between a manager and agent.
[1]

Each SNMPv3 message contains security parameters which are encoded as an

octet string. The meaning of these security parameters depends on the security model being used. SNMPv3 provides important security features:
[6]

Confidentiality - Encryption of packets to prevent snooping by an unauthorized source. Integrity - Message integrity to ensure that a packet has not been tampered with in transit including an optional packet replay protection mechanism.

Authentication - to verify that the message is from a valid source.

As of 2004 the IETF recognizes Simple Network Management Protocol version 3 as defined by RFC 3411RFC 3418
[7]

(also known as STD0062) as the current standard version of SNMP. The IETF has
[8]

designated SNMPv3 a full Internet standard,

the highest maturity level for an RFC. It considers earlier

versions to be obsolete (designating them "Historic").

In practice, SNMP implementations often support multiple versions: typically SNMPv1, SNMPv2c, and SNMPv3.
[10]

[edit]Implementation

issues

SNMP implementations vary across platform vendors. In some cases, SNMP is an added feature, and is not taken seriously enough to be an element of the core design. Some major equipment vendors tend to over-extend their proprietary command line interface (CLI) centric configuration and control systems.
in citation given] [11][not

SNMP's seemingly simple tree structure and linear indexing may not always be understood well enough within the internal data structures that are elements of a platform's basic design. As a result, processing SNMP queries on certain data sets may result in higher CPU utilization than necessary. One example of this would be large routing tables, such as BGP or IGP. [edit]Resource
[citation needed]

indexing

Modular devices may dynamically increase or decrease their SNMP indices (aka instances) whenever slotted hardware is added or removed. Although this is most common with hardware, virtual interfaces have the same effect. Index values are typically assigned at boot time and remain fixed until the next reboot. Hardware or virtual entities added while the device is 'live' may have their indices assigned at the end of the existing range and possibly reassigned at the next reboot. Network inventory and monitoring tools need to have the device update capability by properly reacting to the cold start trap from the device reboot in order to avoid corruption and mismatch of polled data. Index assignments for an SNMP device instance may change from poll to poll mostly as a result of changes initiated by the system admin. If information is needed for a particular interface, it is imperative to determine the SNMP index before retrieving the data needed. Generally, a description table like ifDescr will map a user friendly name like Serial 0/1 (Blade 0, port 1) to a SNMP index. [edit]Security

implications

SNMP versions 1 and 2c are subject to packet sniffing of the clear text community string from the network traffic, because they do not implement encryption.

All versions of SNMP are subject to brute force and dictionary attacks for guessing the community strings, authentication strings, authentication keys, encryption strings, or encryption keys, because they do not implement a challenge-response handshake.

Although SNMP works over TCP and other protocols, it is most commonly used over UDP that is connectionless and vulnerable to IP spoofing attacks. Thus, all versions are subject to bypassing device access lists that might have been implemented to restrict SNMP access, though SNMPv3's other security mechanisms should prevent a successful attack.

SNMP's powerful configuration (write) capabilities are not being fully utilized by many vendors, partly due to lack of security in SNMP versions before SNMPv3 and partly due to the fact that many devices simply are not capable of being configured via individual MIB object changes.

SNMP tops the list of the SANS Institute's Common Default Configuration Issues with the issue of default SNMP community strings set to public and private and was number ten on the SANS Top 10 Most Critical Internet Security Threats for the year 2000.

For more detail on SNMP security implications see the CERT SNMP Vulnerabilities FAQ [edit]Autodiscovery SNMP by itself is simply a protocol for collecting and organizing information. Most toolsets implementing SNMP offer some form of discoverymechanism, a standardized collection of data common to most platforms and devices, to get a new user or implementor started. One of these features is often a form of automatic discovery, where new devices discovered in the network are polled automatically. For SNMPv1

and SNMPv2c, this presents a security risk, in that your SNMP read communities will be broadcast in cleartext to the target device. While security requirements and risk profiles vary from organization to organization, care should be taken when using a feature like this, with special regard to common environments such as mixed-tenant datacenters, server hosting and colocation facilities, and similar environments. [edit]RFC

references

RFC 1155 (Standard 16) Structure and Identification of Management Information for the TCP/IPbased Internets

cmip

The common management information protocol (CMIP) is a protocol for network management. It provides an implementation for the services defined by theCommon management information service (CMIS), allowing communication between network management applications and management agents. CMIS/CMIP emerged out of the ISO/OSI Network management model and is defined by the ITU-T X.700 series of recommendations, its more popular correspondent designed by the IETF being SNMP. CMIP models management information in terms of managed objects and allows both modification and performing actions on managed objects. Managed objects are described using GDMO (Guidelines for the Definition of Managed Objects), and are identified by a distinguished name (DN), similar in concept to the X.500directory. CMIP also provides good security (support authorization, access control, and security logs) and flexible reporting of unusual network conditions.

Contents
[hide]

1 Services implemented 2 Deployment

3 History 4 See also 5 References

[edit] Services implemented

[edit] Deployment
CMIP is implemented in association with the ACSE and ROSE protocols.Both are Layer 7 OSI protocols (Application Layer). ACSE is used to manage associations between management applications (i.e. manage connections between CMIP agents). ROSE is employed for all data exchange interactions. Besides the presence of these Layer 7 protocols, CMIP assumes the presence of all OSI layers at lower levels but does not explicitly specify what these should be. There have been some attempts to adapt CMIP to the TCP/IP protocol stack. Most notable is CMOT contained in RFC 1189 (detailing CMIP over TCP). Other possibilities include RFC 1006 (which provides an ISO transport service on top of TCP), and CMIP over LPP (a presentation layer protocol that can run on top ofTCP or UDP). There is also a form of CMIS that is developed to operate directly on top of the LLC sublayer. It is called the LAN/MAN Management Protocol (LMMP), formerly it was the Common Management Information Services and Protocol over IEEE 802 Logical Link Control (CMOL). This protocol does away with the need for the OSI stack as is the case with CMIP.

[edit] History
CMIP was designed in competition with SNMP, and has far more features than SNMP. For example, SNMP defines only "set" actions to alter the state of the

managed device, while CMIP allows the definition of any type of action. CMIP was to be a key part of the Telecommunications Management Network vision, and was to enable cross-organizational as well as cross-vendor network management. On the Internet, however, most TCP/IP devices support SNMP and not CMIP. This is because of the complexity and resource requirements of CMIP agents and management systems. CMIP is supported mainly by telecommunication dev

FAULT MANAGEMENT
In network management, fault management is the set of functions that detect, isolate, and correct malfunctions in a telecommunications network, compensate for environmental changes, and include maintaining and examining error logs, accepting and acting on error detectionnotifications, tracing and identifying faults, carrying out sequences of diagnostics tests, correcting faults, reporting error conditions, and localizing and tracing faults by examining and manipulating database information. When a fault or event occurs, a network component will often send a notification to the network operator using a protocol such as SNMP. An alarm is a persistent indication of a fault that clears only when the triggering condition has been resolved. A current list of problems occurring on the network component is often kept in the form of an active alarm list such as is defined in RFC 3877,the Alarm MIB. A list of cleared faults is also maintained by most network management systems. Fault management systems may use complex filtering systems to assign alarms to severity levels. These can range in severity from debug to emergency, as in the syslog protocol.[1] Alternatively, they could use the ITU X.733 Alarm Reporting Function's perceived severity field. This takes on values of cleared, indeterminate, critical, major, minor or warning. Note that the latest version of the syslog protocol draft under development within the IETF includes a mapping between these two different sets of severities. It is considered good practice to send a

notification not only when a problem has occurred, but also when it has been resolved. The latter notification would have a severity of clear. A fault management console allows a network administrator or system operator to monitor events from multiple systems and perform actions based on this information. Ideally, a fault management system should be able to correctly identify events and automatically take action, either launching a program or script to take corrective action, or activating notification software that allows a human to take proper intervention (i.e. send e-mail or SMS text to a mobile phone). Some notification systems also have escalation rules that will notify a chain of individuals based on availability and severity of alarm.
[edit]Types

There are two primary ways to perform fault management - these are active and passive. Passive fault management is done by collecting alarms from devices (normally via SNMP) when something happens in the devices. In this mode, the fault management system only knows if a device it is monitoring is intelligent enough to generate an error and report it to the management tool. However, if the device being monitored fails completely or locks up, it won't throw an alarm and the problem will not be detected. Active fault management addresses this issue by actively monitoring devices via tools such as ping to determine if the device is active and responding. If the device stops responding, active monitoring will throw an alarm showing the device as unavailable and allows for the proactive correction of the problem. Fault management includes any tools or procedure for diagnosing testing or repairing the network when a failure occurs.
[edit]Notes

1.

^ RFC 3164

[edit]