Internet Management Overview

Size: px

Start display at page:

Download "Internet Management Overview"

Kristian Osborne
5 years ago
Views:

1 Internet Management Overview Based on the Manager-Agent Model Initially SNMPv1 (1990), SNMPv Managed Objects similar to OSI attributes, specified through ASN.1 Macros the SNMP Structure of Management Information (SMI) SNMP provides the management access service Unreliable, connectionless service Multiple object selection through GET-NEXT, GET- BULK (v2) No Filtering Event capabilities only between management systems (not bound to MOs) Minimal aspect only standardised The Internet Management framework was conceived a a simpler version of OSI Management to meet the needs of private networks (LANs, MANs) and the Internet. It is specified in a series of Internet Requests For Comments (RFCs). The first version appeared in 1990 and achieved wide acceptance because of its simplicity. Its limitations though become soon apparent: version 2 was proposed in 1993 but was only been agreed at the end of It enhances the known problems of SNMPv1 but does not address security issues, as it was initially intended. SNMP is a specialisation of the manager-agent model with the following specific features: Its information model is rudimentary, with managed objects similar to OSI attributes. A set of ASN.1 macros are used to specify formally managed objects. This language is known as the SNMP Structure of Management Information (SMI). The management access mechanism is provided by the Simple Network Management Protocol (SNMP). This operates over the Internet UDP/IP and offers an unreliable connectionless service: management applications should take care of reliability through retransmission. The event model is very limited in SNMPv1: few traps are emitted by managed elements but they are not reliable and their reception cannot be controlled by managers. This is extended in SNMPv2 with reliable inform requests but only in the manager-to-manager domain. Finally, only minimal aspects are standardised i.e. there is no wide range of generic specifications similar to the OSI systems management functions. 1

2 The Information Model Object-based rather than fully objectoriented No inheritance and composite object boundary Object similar to OSI attributes Managed Object Operations Only SET and GET Actions emulated through SET operations Create and delete operations apply only to table entries, hence also emulated through SET operations Notifications are associated with the agent The SNMP information model is rudimentary: objects are similar to OSI attributes or simply variables that may be accessed remotely. There is no composite object boundary grouping many of these objects together in an object instance as in OSI management. In addition, there is no inheritance and associated object-oriented properties. Finally, the SNMP objects may have only integer and string syntaxes. Entities that need to be modelled through more complex syntaxes will have to use many of these simple objects. Naming is based in some notion of containment but in a different sense to OSI management. ASN.1 Object Identifiers are used to name objects as opposed to the OSI Distinguished Names. Given the fact that there is no composite object boundary, the only operations allowed on the simple SNMP objects are Get and Set. Actions may be emulated through Set operations e.g. reboot may be emulated by setting a relevant state object to true. Of course, this is more difficult for arbitrary remote operations with parameters and results e.g. testing operations. This emulation also results in complex and not elegant information models. Creation and deletion are only allowed for table entries or rows. Creation is emulated by a set request with all the objects of a non-existing entry while deletion is emulated by setting a rowstatus object that all tables have to delete. Creation and deletion did not work very well is SNMPv1 but have been fixed in SNMPv2. Finally, notifications are not associated to objects as in OSI management but to the whole of the agent (v2). In SNMPv1 traps were associated with the protocol itself i.e. they were part of the relevant PDU and were not specified formally otherwise. 2

3 SNMP Managed Objects Objects are of simple scalar types (Integer, String) Two-dimensional tables are the only constructed types allows Table entries or rows consist of scalar objects Tables and their entries are conceptual object, only the row cab be accessed via SNMP. The SNMP information model does not use Object-Oriented (O-O) concepts such as classes and inheritance which are though as unnecessary complications; as such, is often referred to as Objectbased. The basic building block of an SNMP MIB is the object. Objects belong to a particular object type and have values. Object values are restricted to a very small set of allowed syntaxes, resulting ultimately to the basic ASN.1 scalar types INTEGER and OCTET STRING. In addition, the only constructed type allowed is a simple two-dimensional table, consisting of elements of the previous primitive types. Thus the SNMP SMI is analogous to a computer language which has a small set of basic types together with two-dimensional arrays. The advantage of using only a small fixed set of syntaxes is that it is possible to hand-code the encoding and decoding software in an optimal fashion. The disadvantage is lack of expressive power. The SNMP notation for specifying new object types is an ASN.1 template called OBJECT-TYPE. ASN.1 is used to specify the object syntaxes and the tabular structure. SNMP object-types can be either single or multiple instanced, with multiple instanced objects only allowed in tables. SNMP objects are similar to OSI Management / OMG CORBA attributes while there is no notion of a composite object-boundary that encapsulates a number of scalar objects modelling a manageable entity. The only composite relationship relates objects to tables. A table has rows (also referred to as entries or records), with each row represented by a SEQUENCE ASN.1 type that contains a statically defined number of objects. The table itself is modelled as SEQUENCE OF ASN.1 type with respect to the rows or entries, allowing an arbitrary number of those to be dynamically instantiated. A table thus resembles to a dynamic array of records. A further rule restricts the syntaxes used within a row to be scalar ; thus one cannot define tables within tables. Note also that tables and table entries are only conceptual composite objects in SNMP: only the individual scalar objects that constitute a table entry are accessible through the management protocol. 3

4 Example SNMP MIB tp group object ordering tpconn table entries SNMP transport protocol object SNMP transport connection tabular object Let us examine the use of this modelling framework in two examples. A typical single-instanced set of objects are, for example, those modelling aspects of a connection-oriented transport protocol entity such as OSI Transport Protocol (TP), Internet Transmission Control Protocol (TCP), etc. Such objects will cover the number of current and previous connections, the number of incoming and outgoing unsuccessful connection requests, the number of transport packets sent, received and retransmitted and the number of various protocol-related errors. All these will have to be separate objects, loosely related through a transport protocol group. The group will also comprise transport connections, which are multiple-instanced objects and have to be modelled through a table. A tpconntable may be defined as a SEQUENCE OF tpconnentry, with tpconnentry being a SEQUENCE of objects modelling various aspects of the connection, such as source and destination access points, the connection state, etc. The figure above shows objects of a single-instanced group, e.g. tp, and two table entries, e.g. tpconnentry. Note that both the group and table entries are depicted with dotted lines as there is no notion of a composite object boundary the SNMP information model. Another example could be a table representing users of a computer system and their disc quota. A discquotatable may be defined as a SEQUENCE OF discquotaentry. The latter could be a SEQUENCE of objects modelling the user number and name and the corresponding used and maximum disc quota for that user. 4

5 SNMP Managed Object Naming OIDs are used for naming For single-instaced objects the type OID is suffixed by 0 E.g. tpcurrentconnection.0 For multiple-instanced tabular objects the type OID is suffixed by the unique object Key value e.g. discquotamaxquota.1234 Naming thus exhibits tight binding between type and instance identifiers Cannot reuse a type in multiple contexts, i.e. in different MIBs When objects are instantiated they must be named so they can be addressed unambiguously. The SNMP framework uses object identifiers for naming. Every object type has a registration OID while an object instance is identified by the object type OID, suffixed by a part that identifies uniquely that instance. For non-tabular objects any suffix would do, so the minimal.0 is used. For example, tpcurrentconnections.0 is the instance of the object type tpcurrentconnections. In the case of multiple-instanced tabular objects such as the discquotamaxquota, the suffix needs to signify the table entry. The latter can be constructed from the values of one or more objects of that entry that constitute the key ; as specified in the relevant OBJECT-TYPE template for that table entry. In our example, the value of the discquotausernumber object may be used. As such, discquotamaxquota.1234 is the instance of the object type discquotamaxquota, corresponding to the user whose number is Note that in the case that object values are strings as opposed to integers, they need to be converted to object identifier suffixes: this is done by converting each character to the corresponding ASCII numeric value. The SNMP naming architecture exhibits a very tight binding between object type and instance identifiers and this is both a strength and a weakness. On the plus side, the scheme is easy to understand and only one hierarchical naming scheme needs to be understood. On the minus side it means that instances of a particular object type can only appear in one particular place in the registration tree. This means that one cannot define generic object types to be used in several contexts. For example, a common object for representing the state as perceived by a managed resource is the operationalstate. In the SNMP framework, it is not possible to define such generic objects but specific objects have to be defined for every particular context e.g. tpentityoperationalstate, etc. An additional minus is that object names formed through OID suffixes are arguably not natural. 5

6 The Management Protocol SNMP Simple Network Management Protocol Connectionless, unreliable communications over UDP/IP Management operations GET, GET-NEXT, SET, TRAP (v1) GET-BULK, INFORM (added in v2) Maximum PDU size limited to ~500 bytes The Simple Network Management Protocol provides communication capabilities between applications in manager and agent roles. It provides a connectionless, unreliable service and operated over the Internet User Datagram Protocol (UDP) and the Internet Protocol (IP). The overall protocol stack is SNMP over UDP (transport layer) over IP (network layer). The SNMP operations are a superset of those provided by the managed objects. SNMPv1 offers the Get, Get-Next (traversal), Set and Trap primitives. Traps are emitted by agents in network elements but are not retransmitted by them, so their reception is unreliable. SNMPv2 has added Get-Bulk and Inform primitives; Inform can be thought as a reliable trap but applies only in the manager-tomanager domain (not allowed in network elements). Get, Set, Get-Next and Get-Bulk may need to be retransmitted by applications in manager roles to cope with packet loss. Note that either the request or reply packet may be lost, which means that intrusive operations (Set) need to be idempotent: the same operation should not have any side-effects if it is performed accidentally more than once. Get-Next and Get-Bulk provide traversal and bulk retrieval facilities. In fact, Get-Bulk is an enhanced Get-Next where more than one next objects may be requested. All the objects in a SNMP agent are ordered: there is a first and a last object and the next object may be requested; this is how Get-Next and Get-Bulk work. There is always only one reply packet to SNMP requests i.e. there is no facility such as linked replies in OSI management. The bulk data retrieval capabilities are restricted by the fact that the maximum allowed packet size is around 500 bytes. This is because larger packets will most probably be fragmented by the network layer and this increases the probability that a fragment may be lost. In fact, management applications are expected to provide functionality similar to those of reliable transport protocols. 6

7 The SNMP Protocol Stack A SNMP T N I/F UDP IP Note Note: The Internet interface layer is deliberately left undefined In the Internet management framework, the fundamental axiom has been simplicity at the agent part of the manager-agent spectrum. This important design decision aimed at the provision of standard management interfaces to the majority of network devices at a minimal cost and has influenced the associated access paradigm. SNMP has been designed to support a connectionless style of management communication and, as such, it has been mapped over the User Datagram Protocol (UDP) and the Internet Protocol (IP) as shown above. The relevant thinking is that reliable transport protocols such as the Transport Control Protocol (TCP) impose too much memory and processing overhead to be supported by simple network devices such as routers, bridges, etc. In addition, maintaining transport connections requires state information, which again is considered to be expensive and, as such, undesirable. Also, bearing in mind SNMP projects a largely centralised model, it is impossible to maintain simultaneously thousands of connections from a Management Operations Centre (MOC) to the managed devices. Applications using the SNMP protocol will need to ensure the reliability of underlying communication by undertaking retransmission. In other words, applications should try to emulate the functionality of a reliable transport protocol by setting timers every time they perform a transaction and possibly retransmit. An important related aspect is that only applications in manager roles do retransmit, agents simply respond to requests. As such, there is the possibility that either the request or the response packet is lost. If the response packet is lost, the management operation will be eventually performed more than once; this is fine for information retrievals but could cause problems for intrusive operations. As such, either the latter should be idempotent or measures should be taken in the agent to prevent an operation from being performed twice (test-and-set, etc.). Finally, agents in managed devices do not even retransmit notifications (or traps), it is only applications in dual manager-agent roles that are allowed to retransmit manager-level notifications in SNMPv2 (or inform-requests). 7

8 SNMP Protocol Operations MANAGER NETWORK AGENT Get, Set Get-next, Get-bulk Response Trap time Inform Response Note 1: Inform is only allowed for dual agent-manager entities Note 2: Get-bulk and Inform have been added in SNMPv2 The management protocol operations are a superset of the operations available at the object boundary inside agents. SNMP objects accept only Get and Set operations while imperative commands (actions) and table entry creation and deletion are emulated through Set. As such, the SNMP protocol has also Get and Set request packets. Also, agents emit notifications, which are sent to manager applications through the Trap SNMP packet. In addition to those operations, it is necessary for manager applications to be able to discover transient objects, for example table entries for which it is impossible to know their names in advance, e.g. connections, routes, etc. The SNMP naming architecture relies on ASN.1 object identifiers and since the latter have ordering qualities, a collection of SNMP objects visible across an interface is ordered in a linear fashion, with a first and last object. It is exactly this linear structure that is exploited through the Get-next operation which allows to retrieve the next object of any other object in the MIB. This is typically used for traversing tables and allows the retrieval of one table entry at a time if the entry names are not known in advance. In SNMPv2, two more primitives have been added. The inform-request packet is to be used between hybrid manager-agent applications in order to report asynchronous notifications to each other; its receipt should be acknowledged by the receiving application. This means that it should be retransmitted, so it can be thought as a reliable trap. Note though that managed devices are not supposed to use this facility. The second addition has been the Get-bulk primitive; which is an extension of Get-next as it allows to retrieve more than one next objects. Though it is better than Get-next, it is still a poor bulk data retrieval facility because SNMP does not allow multiple replies but the result should fit in one response packet. Given the fact the underlying transport is unreliable, the maximum allowed application-level packet size is about 500 bytes in order to avoid networklevel segmentation. In short, the SNMP mode of operation is request-reply or request only for traps. The possible interactions using SNMP operations are shown above. 8

9 SNMP Event-based Operation SNMPv1 Traps are send from managed agent to predefined manager applications Not configurable at runtime No reliable transmission of event Hence polling model still dominant, which raises scaling problems SNMPv2, reliable event possible between hybrid manager-agents Configurable No OSI style filtering Event-based operation in SNMP is pretty simple-minded. Traps are sent asynchronously from managed devices to predefined managers and are not retransmitted. This means they are inherently unreliable and, as such, managers should not rely on them but should also monitor managed devices through periodic polling. This approach does not scale as it imposes management traffic on the managed network even when nothing happens. It also requires careful trade-off between the polling frequency and the potential elapsed time after a significant change before a manager knows about it. In SNMPv2, the event model between hybrid manager-agent applications is more flexible as it allows to request particular events by creating entries in a relevant table. These events are retransmitted until an acknowledgement is received. On the other hand, it is not possible to specify any other event-associated conditions through filtering, in order to minimise further management traffic. 9

10 SNMP Distribution Aspects Location Transparency not an issue Agents are addressed through their IP address at UDP port 161 Managers listen for events at UDP port 162 Agents discovered using multicast on LAN/MANs Mainly suited to centralise management model Distribution in terms of location transparency is not an issue in SNMP. Manager applications address agents in managed devices through their IP address while the agent is always attached to the UDP port number 161. This simplistic model allows for the discovery of device agents in LANs and MANs because of their broadcast nature: a multicast SNMP message is sent to all the nodes of the LAN at the known port number, requesting the first MIB object e.g. Get-next(name=0.0) and the nodes that respond have been discovered. On the other hand, such discovery is not possible for higher-level hybrid manager-agent applications as it is not specified on which port they should be attached. The only aspect that is specified regarding manager applications is they should be listening on UDP port 162 for traps and confirmed inform-requests. In summary, the SNMP distribution model is very simple, in a similar fashion to the whole framework. It serves well enough the centralised model for managing LANs and MANs but has obvious limitations in more complex environments. 10

11 Comparison of OSI and Internet Management Similar in: manager-agent model separation of information structure, MIBs and protocols Differ in: object oriented vs. object based MO definition separation of naming and registration tree scoping and filtering event granularity and control connection-oriented vs. connectionless OSI and Internet Management are similar in their use of the management-agent model and the abstraction of resources through managed objects. They are also similar in the way their respective standards have been structured with a separation between the definition of how management information is structured, the definition of specific management information and definition of the protocol used to communicate management information. For OSI Management these are GDMO, SMFs and specific MIBs and CMIP respectively, while in Internet Management these correspond to SMI, the MIB and SNMP. The two approaches differ in the following: MO definition is object oriented in OSI Management, enabling the MO definer to exploit object inheritance and making allomorphism (the distributed version of polymorphism) possible. In Internet Management MOs are simple type or table entries and cannot exploit object-oriented features. In Internet Management the naming, and therefore containment of MOs is defined in the MIB definition by its ANS.1 registration name. In OSI Management MO naming/containment is separate from MO definition, so the MO can appear in different places in the containment tree. OSI Management offers the ability to scope a request over a range of levels in an MO containment tree and to select MO to which a request is applied by defining composite logical expressions. Internet Management does not support this. OSI Management allows events to be defined for individual MOs and provides run time control of the conditions under which an event is emitted and to which manager. Internet Management only support agent level events. OSI management used connection-oriented communications, while Internet Management uses connectionless, so operations and events may be lost in transit. 11

Management Standards

Communications Management Standards David Lewis Elements of Open Communications Management Structure of Management Information + Formal MIB Specifications + Management Protocol + Common underlying protocol