Network Management Essentials

Network Management

• Network management involves activities, methods, procedures, and tools for the operation, administration, maintenance, and provisioning of networked systems.
• It is essential for command and control practices and is typically carried out from a network operations center.
• Operation deals with maintaining the network and its services in a smooth, running state.
• Administration handles resource tracking within the network and their assignments.
• Maintenance involves performing necessary repairs and upgrades.
• Provisioning configures network resources to support specific services.
• Data for network management is acquired via agents on infrastructure, synthetic monitoring simulating transactions, logs of activity, sniffers, and real user monitoring.

Need for Network Management Tools

• In the early Arpanet days, name services were managed by distributing a single file with all network IP addresses; today it would be DNS.
• As networks grow, they become more important to organizations.
• Network size increase means there are more potential issues, leading to disabled or poor performance.
• Managing a large modern network requires software assistance.

SNMP & Network Management History

• In 1983, TCP/IP replaced ARPANET at the U.S. Dept. of Defense, marking the birth of the Internet.
• The first network management model was HEMS (High-Level Entity Management System) Based on RFCs 1021, 1022, 1024, 1076.
• In 1987, ISO OSI proposed CMIP (Common Management Information Protocol) and ​​​​​​​CMOT (CMIP over TCP) for network management.
• November 1987 saw ​​​​​​​SGMP (Simple Gateway Monitoring protocol) - RFC 1028.
• In 1989, Marshall T. Rose formed an ​​​​​​​SNMP working group to develop a common network management framework compatible with both ​​​​​​​SGMP and CMOT to allow transition to ​​​​​​​CMOT.
• August 1989 saw the definition of the "Internet-standard Network Management Framework" based on RFCs 1065, 1066, and 1067.
• April 1989, ​​​​​​​SNMP gained recommended status as the de facto TCP/IP network management framework (RFC 1098).
• June 1989 the ​IAB committee decided that ​​​​​​​SNMP and CMOT would develop separately.
• IAB promoted ​​​​SNMP to a standard protocol with recommended status in May 1990 (RFC 1157).
• March 1991 defined the format of MIBs and traps (RFCs 1212, 1215).
• Creation of ​​​​​​​SNMPv1 from the revised TCP/IP MIB definition (RFC 1213).

Technologies

• A standardized protocol is necessary for heterogeneous environments as it prevents network engineers spending too much time developing customized management tools.
• Access methods for network and device management include:
  • ​​​​​​​SNMP
  • command-line interface
  • custom XML
  • ​​​​​​​CMIP
  • Windows Management Instrumentation (WMI)
  • Transaction Language 1
  • CORBA
  • NETCONF
  • Java Management Extensions (JMX)

Use of Standardized Protocol

• The goals are to:
  • Minimize complexity in management functions.
  • Provide flexibility and extensibility.
  • Ensure independence from specific host and gateway architectures and mechanisms.

SNMP

• It is an "Internet-standard protocol for managing devices on IP networks."
• It enables local and remote management of network items, servers, workstations, routers, switches, and other managed devices.
• It is comprised of standards for network management, including a database schema, an application layer protocol, and a set of data objects.

Key Components

• Manager: An application program which queries or modifies the database in an ​​​​​​​SNMP agent.
• Agent: Software installed on network equipment (like hosts, routers, and printers) which keeps configuration, and the current state in a database.
• Network Management Station (NMS): Executes applications to monitor and control managed devices and provides the resources needed for network management. One or more NMSs can exist on a network.
• Management Information Bases (MIBs): Describe the database information.
• SNMP Protocol: The application layer protocol used by ​​​​​​​SNMP agents and managers for data exchange.

Network Management Station (NMS)

• Executes network management applications (NMAs) that monitor and oversee network elements (NE) such as hosts, gateways, and terminal servers
• Network elements employ a management agent (MA) to execute the network management tasks requested by the network management stations.

Management Information Base (MIB)

• It structures management data of a device subsystem, using a hierarchical namespace including object identifiers (OID).
• Each OID allows for reading or modifications via ​​​​​​​SNMP.
• MIBs rely on standard notation, Structure of Management Information Version 2 (SMIv2, RFC 2578), a subset of ASN.1 (Abstract Syntax Notation One).

SNMP Protocol

• It is found in the Application Layer and has three versions: ​​​​​​​SNMPv1, ​​​​​​​SNMPv2, and ​​​​​​​SNMPv3.
• SNMP Managers send requests using UDP port 161.
• SNMP Agents send notifications on UDP port 162.
• ​​​​​​​SNMPv1 specifies five core protocol data units (PDUs), with SNMPv2 adding two more which are carried over to ​​​​​​​SNMPv3.

Sending a Request

• Form the right PDU according to the operation type and VarBindList.
• The PDU, agent identity and security data go into a security mechanism for authentication/encryption, community strings and also creates an ​​​​​​​SNMP message.
• The message goes using UDP transport, to the ​​​​​​​SNMP agent. Serialization happens using the BER encoding scheme.

PDU Type Used: GetRequest

• It is a manager-to-agent request to retrieve the value of one or more variables; specifying which variables in variable bindings, returning retrieval as an atomic operation. A ​​​​​​​Response with values is then returned.

Receiving a Request

• The incoming message is de-serialized to construct an ASN.1 message.
• The version number is verified.
• The security mechanism authenticates input from the community name, and security information in the ​​​​​​​SNMP message.
• An ASN.1 object is built which correlates to an ​​​​​​​SNMP PDU object.

Sending a Response

• Construct a Response PDU using the saved request-id value and the values for error-status, error-index and VarBindList from the request.
• Security mechanism, via community string and SNMP message, secures the PDU with security information and agent identity.
• Sender serializes and sends the message back to the manager.

Pdu Type Used: Response

• Returns the variable bindings and acknowledgment from agent to manager for a GetRequest or any similar request.
• Error reporting uses error-status and error-index fields.
• This PDU was called GetResponse in ​​​​​​​SNMPv1, but was used as a response to both gets and sets.

Receiving a Response

• The incoming message is de-serialized.
• The PDU version is verified.
• The security community name, security information and data from the ​​​​​​​SNMP message goes to the security mechanism.
• The ASN.1 object is parsed.

GetRequest/GetResponse Errors

• tooBig happens when the response is too large, exceeding device limits.
• noSuchName happens when the request references a non-existent management instance or violates access restrictions.
• genErr refers to when an identified instance of management information is unavailable due to some reason.

Other Request PDU Types: GetNextRequest

• The GetNextRequest is a manager-to-agent request to discover available variables and their values, returning the subsequent variable binding lexicographically found in the MIB with a suitable response.
• The entire MIB of an agent can be walked by iteratively applying GetNextRequest starting at OID 0.

Other Request PDU Types: GetBulkRequest

• Built from GetNextRequest, this is a manager-to-agent request that optimizes multiple iterations of requests and provides increased performance for network monitoring.
• GetBulkRequest gives a Response with multiple variable bindings and uses non-repeaters and max-repetitions to control the response behavior.

Other Request PDU Types: SetRequest

• The SetRequest is a manager-to-agent request that is made to change variables, performed in the body of a request. When changes happen, a Response including modified values is returned.

SetRequest/GetResponse Errors

• badValue occurs when the field won't comply with data types or standards.
• noSuchName occurs when the information isn't accessible, control access or because of an instance.
• genErr The management information isn't available, due to some reason.

Other PDU Types: Trap

• A Trap constitutes asynchronous notification from agent to manager, where an agent can alert the management station to notable events by sending an unsolicited ​​​​​​​SNMP message.
• They also contain the current sysUpTime , an OID for trap type, and optional variable bindings. A response is not expected.

TRAP Types

• coldStart occurs when a protocol entity restarts and reinitializes, possibly altering its configuration or implementation.
• warmStart is similar, but the protocol entity restarts without changing its configuration or implementation.
• linkDown signals when one communication link represented in the agent's configuration has failed.
• linkUp indicates that one communication link represented in the agent's configuration has successfully come up.
• authenticationFailure is received when the protocol entity can't validate a given message.
• egpNeighorLoss, when an EGP neighbor has has been marked down or no longer exists.
• enterpriseSpecific is for enterprise events.

Use of Events

• Agents give certain data after being asked by managers.
  • This is called "polling."
• The time it takes the manager to understand the event is the "event detection latency".
• In one management model, agents in manage systems make responses to managers.
  • This is called "Traps (pushing)".
    • If communication fails, the manager can't know the event

SNMP Versions

• SNMPv1 is the initial version, but it has poor security because it uses a simple "community string" for authentication.
• SNMPv2 aims to improve in areas of performance, security, etc, by introducing GetBulkRequest
• SNMPv3 adds security, remote configuration, as well as all its functionality of previous versions.

SNMPv1: Limitations

• Limited data types.
• Some increase in complexity of MIB understanding and design exists.
• Limited performance.
• Inefficient for large retrievals, such as entire MIBs or tables.
• Limited error codes.
• No hierarchies.
• Inherently centralized.
• Lack of security (relying on community strings).

​​​​​​​SNMPv2

• There are more data types.
• It is more complex.
• It tries to bypass ​​​​​​​SNMPv1 problems by giving the community security, ​​​​​​​SNMPv2 and ​​​​​​​SNMPv1 can function simultaneously.

SNMPv2: Features

• Adds new data types
• Is community-based, so much like SNMPv1.
• GET & GETNEXT operation is same for SNMPv1.
• SET Request operate in two phases.
• Expansions for the protocol operations take places.
  • Also adds INFROM Request and GETBULK Request.

GETBULK Request

• It is efficient if you have to get many VarBinds for getting so, two parameters have to be called:
  • Non-repeaters: the first "N" lists are called with a GETNEXT operation.
  • max-repetitions: other lists act in the operation, having the number of GETNEXT Request operations.

INFORM Request

• Unlike SNMPv1, it sends no trap messages. There is no trap, but no message is sent.
• As a result, ​SNMPV2 introduces the INFORM operation.
  • In other words, it is a trap that is confirmed.
    • it is to inform a higher level manager.
• If there is error, tooBig results.

​​​​​​​SNMPv2: Feautures

• Exceptions added, such as noSuchObject or noSuchInstance
• GETNEXT gets errors like endofMibView
• The coded exceptions are placed in VarBinds, so there will be no Error Status and Index raised.

​​​​​​​SNMPv2: Limitations

• Too complex
• GETBULK doesn't stop during the end of a table - the overshoot problem.
• Its complex that it overshoted SNMPv1, so a basic system was used instead for SNMPv2: community-based security.

SNMPv3: Features

• Better in remote configuration capabilities.
• Adds ability to control agents via a specific management MIB.
• Contains of function from both and ​​​​​​​SNMPv1 and ​​​​​​​SNMPv2.
• Incorporates ​​​​​​​SNMPv2 data types

SNMPv3: Entities

• Both Manager and Agency are SNMP.
  • Which are both defined by ​​​​​​​SNMP engine and ​​​​​​​SNMP appications.

SNMPv3

• SNMP manager uses the command dispatcher to send getRequest and getNextRequest to the SNMP GetBulk
  • At the SNMP agent; then checks the parameters, the local database, then returns to the SNMP manager,

SNMP Engine: Dispatcher

• The dispatcher is a traffic manager that sends and receives messages.
• For incoming messages, the dispatcher establishes the version number, which then leads to the correct message processing model.
• The dispatcher picks and choose the right ports for outgoing signals and will dispatch PDU.

SNMP Engine: Message Processing Subsystem

• For the outgoing message section, it receives the PDU and wraps their message.
• The dispatcher get the incoming signals.
  • And if it has the right version, it would support and contain separate modules and each version

SNMP Engine: Security Subsystem

• It checks the right encrypted messages by the message processing subsystem.
  • It relies if its safe via PDU and messages.
    • It can make authenticaited codes and insert the message by the message handling, then it provides after the after-encryption messages.

​​​​​​SNMP Engine: Security System

• The incomming message has information.
  • This allows the right authentication for description.