1 LABORATORIO DI INFORMATICA Network Management 5. Structure of Management Information (SMIv2) 5.2....

1

LABORATORIO DI INFORMATICANetwork Management

5. Structure of Management Information (SMIv2)

5.2. OBJECT-TYPE

Claudio Salati

Copyright © 2001 by Claudio Salati

ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA

FACOLTA' DI INGEGNERIA - SEDE DI CESENA

2

Structure of Management Information: object

• Le variabili (dell'agent) che descrivono lo stato del sistema gestito sono istanze di object-type

• Un object-type rappresenta la modellazione astratta di una risorsa, o di un particolare aspetto di una risorsa di un sistema gestitoIl modello astratto comprende:

1. La signature dell'object-type, cioe' la definizione dell'interfaccia (sintattica) tramite cui una instanza dell'object-type puo' essere manipolata dal manager

2. La definizione della semantica dell'object-type

• La definizione di un object-type avviene utilizzando la frase OBJECT-TYPE del linguaggio SMI (Structure of Management Information)

3

Signature di un object-type

La signature dell'object-type

• e' descritta in linguaggio formale (parte formale dello SMI)

• comprende:

1. La descrizione della struttura dati astratta che modella un valore del tipo. Questo puo' essere

1.un tipo (o sottotipo) ASN.12.una textual-convention

N.B. in alcuni casi (tipicamente quando si riferisce una textual-convention) alla struttura dati e’ gia’ associata una semantica, che viene acquisita dall’object-type

2. La lista delle operazioni applicabili sulle istanze dell'object-type • da selezionare in un insieme predefinito di operazioni pre-

definite dallo SMI e supportate dal protocollo SNMP (get, set, …)

• la lista delle operazioni applicabili comprende tutte le operazioni che hanno senso operazionale data la semantica dell’object-type

4

Semantica di un object-type

La semantica dell'object-type

• e' descritta in linguaggio naturale

(testo non-formale previsto in modo formale nello SMI: clausola DESCRIPTION)

• comprende:

1. significato dei valori che istanze dell'object-type possono assumere

2. effetto delle operazioni che si possono applicare alle istanze dell'object-type

1. ovviamente la semantica specificamente definita per l'object-type non puo' essere in conflitto con quella gia' incorporata nella sua sintassi astratta (nel tipo o sottotipo ASN.1, o nella textual-convention citati nella clausola SYNTAX della definizione dell'object-type)

5

OBJECT-TYPE

ASN.1-valueID OBJECT-TYPE

SYNTAX <ASN.1-object-type-denotation>

-- or the BITS construct

[ UNITS ""-delimited-string ]

MAX-ACCESS <access>

STATUS <status>

DESCRIPTION ""-delimited-string

[ REFERENCE ""-delimited-string ]

[ <index-part> ]

[ DEFVAL { ASN.1-value } ]

::= object-identifier

6

OBJECT-TYPE

<access> not-accessible | accessible-for-notify | read-only | read-write | read-create

<status> current | deprecated | obsolete

<index-part> INDEX { <index-type> { , <index-type> } } | AUGMENTS { <entry> }

<index-type> IMPLIED object-type-name | object-type-name

<entry> object-type-name

7

OBJECT-TYPE

• SYNTAX tipo ASN.1 utilizzato per la rappresentazione del valore dell'oggetto. Quali tipi ASN.1 sono ammessi (e quindi quali sintassi sono ammesse come <ASN.1-object-type-denotation>) dipende dalla categoria dell'object-type (vedi il seguito)

• UNITS indicazione in linguaggio naturale dell'unita' di misura del valore dell'object-type

• STATUS indicazione dello stato di utilizzabilita' dell'object-type

8

OBJECT-TYPE

• MAX-ACCESS indicazioni di quali operazioni possono coinvolgere istanze di questo object-type sull'interfaccia manager-agent

set [create]

set [assignment]

get

[any kind]

trap

read-create

read-write

read-only

accessible-for-notify

not-accessible

9

OBJECT-TYPE

• MAX-ACCESS (continua)

Il livello di accesso specificato (e quindi consentito) nella clausola MAX-ACCESS e’ quello massimo operazionalmente significativo sull’interfaccia manager-agent.

• Condizioni dinamiche (e.g. sincronizzazione di piu’ operazioni di uno o piu’ manager su di un unico agent) o

• Diritti amministrativi (politica di security)possono portare a limitazioni ulteriori rispetto a quanto indicato dalla definizione dell’object-type.

Anche l'implementazione di un agent puo' porre limiti al livello di accesso previsto per un object-type dalla MIB:• perche' cio' e' consentito dal livello minimo di compliance

comunque richiesto clausola MIN-ACCESS di MODULE-COMPLIANCE

• perche' comunque l'agent ha imposto ulteriori restrizioni clausola ACCESS di AGENT-CAPABILITIES

10

OBJECT-TYPE

• DESCRIPTION una descrizione in linguaggio naturale dell'object-type, e in particolare della sua semantica specifica

• REFERENCEse l'object-type e' in qualche modo correlato ad un altro object-type, questa clausola consente di riferirlo tramite una indicazione in linguaggio naturale(vedi RFC 2665, e i suoi estratti alla fine di questa lezione, per diversi esempi d'uso)

• <index-part> (INDEX/AUGMENTS)il significato e le condizioni di presenza di questa clausola verranno esaminati quando verranno considerate categorie di object-type composti.Questa clausola puo’ e deve essere presente solo nella definizione di object-type riga.

11

OBJECT-TYPE

• DEFVAL

• scopo di questa clausola e' di fornire un valore iniziale di default indicativo da assegnare in creazione ad istanze di questo object-type (di categoria semplice o colonna).

• Ovviamente il valore deve essere congruente con il tipo ASN.1 dell'object-type

in caso di OBJECT IDENTIFIER il valore deve essere indicato citando un identificatore di valore ASN.1

• La clausola DEFVAL consente solo di specificare valori in termini di value-notation ASN.1, quindi valori costanti.

• Regole di calcolo del valore di inzializzazione piu’ complesse (anche dinamiche) possono essere espresse come behaviour all’interno della clausola DESCRIPTION

vedi la clausola DESCRIPTION della textual convention TestAndIncr (qui di seguito)

• Esempi: vedi prossimo lucido

12

OBJECT-TYPE

• DEFVAL (continua)

da RFC 1902, SMI for SNMPv2

By way of example, consider the following possible DEFVAL clauses:

ObjectSyntax DEFVAL clause------------------ ---------------------Integer32 DEFVAL { 1 }

-- same for Gauge32, TimeTicks, Unsigned32INTEGER DEFVAL { valid }

-- enumerated valueOCTET STRING DEFVAL { 'ffffffffffff'H }OBJECT IDENTIFIER DEFVAL { sysDescr }BITS DEFVAL { { primary, secondary } }

-- enumerated values that are setIpAddress DEFVAL { 'c0210415'H } -- 192.33.4.21

Object types with SYNTAX of Counter32 and Counter64 may not have DEFVAL clauses, since they do not have defined initial values. However, it is recommended that they be initialized to zero.

13

OBJECT-TYPE

• Lo statement OBJECT-TYPE consente di definire un ADT utilizzabile nell'interfaccia manager-agent

• La rappresentazione del valore di una istanza di object-type e' descritta tramite un tipo ASN.1

Lo statement OBJECT-TYPE prende una struttura dati ASN.1 e la trasforma-arricchisce in un ADT

• In quanto descritta in ASN.1 la rappresentazione del valore di un object-type e' astratta, architecture/implementation-independent

• All'object-type vengono associati due nomi:1. Un identificatore (stringa) che viene utilizzato nel testo SMI

e nel dialogo tra esseri umani o su una GUI per riferire l'object-type

2. Un valore OBJECT IDENTIFIER, che viene utilizzato per riferire l'object-type (le sue istanze) nelle interazioni manager-agent

14

OBJECT-TYPE: esempio da RFC 1907, MIB for SNMPv2

snmpSetSerialNo OBJECT-TYPE

SYNTAX TestAndIncr -- vedi prossima pagina

MAX-ACCESS read-write

STATUS current

DESCRIPTION

"An advisory lock used to allow several cooperating SNMPv2 entities, all acting in a manager role, to coordinate their use of the SNMPv2 set operation.

• This object is used for coarse-grain coordination. • To achieve fine-grain coordination, one or more similar

objects might be defined within each MIB group, as appropriate.“

::= { snmpSet 1 }

15

da RFC 1903, Textual Conventions for SNMPv2

TestAndIncr ::= TEXTUAL-CONVENTION

STATUS current

DESCRIPTION

"Represents integer-valued information used for atomic operations.

When the management protocol is used to specify that an object instance having this syntax is to be modified, the new value supplied via the management protocol must precisely match the value presently held by the instance.

• If not, the management protocol set operation fails with an error of `inconsistentValue'.

• Otherwise, if the current value is the maximum value of 2^31-1 (2147483647 decimal), then the value held by the instance is wrapped to zero;

• otherwise, the value held by the instance is incremented by one.

-- continua nella pagina seguente

16


-- TestAndIncr : continua

Note that regardless of whether the management protocol set operation succeeds, the variable-binding in the request and response PDUs are identical.

The value of the ACCESS clause for objects having this syntax is either `read-write' or `read-create'.

When an instance of a columnar object having this syntax is created, any value may be supplied via the management protocol. When the network management portion of the system is re-initialized, the value of every object instance having this syntax must either be incremented from its value prior to the re-initialization, or (if the value prior to the re-initialization is unknown) be set to a pseudo-randomly generated value.“

SYNTAX INTEGER (0..2147483647)

17


sysDescr OBJECT-TYPE

SYNTAX DisplayString (SIZE (0..255))

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"A textual description of the entity. This value should include the full name and version identification of the

• system's hardware type,• software operating-system, and• networking software."

::= { system 1 }

18


DisplayString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "Represents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object's length defined using this syntax may not exceed 255 chars." SYNTAX OCTET STRING (SIZE (0..255))

19


sysObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor's authoritative identification of the network management subsystem contained in the entity. This value is allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides an easy and unambiguous means for determining `what kind of box' is being managed. For example, if vendor `Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.4242, it could assign the identifier 1.3.6.1.4.1.4242.1.1 to its `Fred Router'." ::= { system 2 }

20


sysUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." ::= { system 3 }

sysName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "An administratively-assigned name for this managed node. By convention, this is the node's fully-qualified domain name. If the name is unknown, the value is the zero-length string." ::= { system 5 }

21


sysLocation OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "The physical location of this node (e.g., `telephone closet, 3rd floor'). If the location is unknown, the value is the zero-length string." ::= { system 6 }

22


sysServices OBJECT-TYPE SYNTAX INTEGER (0..127) MAX-ACCESS read-only STATUS current DESCRIPTION

"A value which indicates the set of services that this entity may potentially offer. The value is a sum. This sum initially takes the value zero, Then, for each layer, L, in the range 1 through 7, that this node performs transactions for, 2 raised to (L - 1) is added to the sum. For example, a node which performs only routing functions would have a value of 4 (2^(3-1)). In contrast, a node which is a host offering application services would have a value of 72 (2^(4-1) + 2^(7-1)). Note that in the context of the Internet suite of protocols, values should be calculated accordingly:

layer functionality 1 physical (e.g., repeaters) 2 datalink/subnetwork (e.g., bridges) 3 internet (e.g., supports the IP) 4 end-to-end (e.g., supports the TCP) 7 applications (e.g., supports the SMTP)

For systems including OSI protocols, layers 5 and 6 may also be counted." ::= { system 7 }

23

Categorie di object-type

Il framework definisce 5 categorie di object-type:

1. Object-type semplici

2. Object-type tabella

3. Object-type riga (base)

4. Object-type colonna

5. Object-type estensione (di riga)

In realta’ solo gli object-type semplici e colonna (entrambi con una sintassi astratta di tipo ASN.1 semplice) sono realmente istanziabili e sono accessibili sull’interfaccia manager-agent tramite i servizi SNMP

gli object-type delle altre categorie sono solo concettuali

24


1. Oggetti semplici

• il cui valore e' rappresentato tramite • Uno dei tipi semplici ASN.1 ammessi dal framework

(ObjectSyntax);• Un sottotipo di questi;• Il costrutto BITS;• Una textual-convention.

Questo tipo ASN.1 deve essere indicato nella clausola SYNTAX della definizione dell'object-type

• Un object-type semplice puo' essere istanziato su un agent una sola volta .

• L'OBJECT IDENTIFIER che identifica questa istanza e' derivato dall'OBJECT IDENTIFIER che identifica l'object-type suffissandolo con 0. Ad esempio l'unica istanza dell'object-type semplice

sysDescr ha nome sysDescr.0

25


2. Oggetti tabella (conceptual table)

• Il framework consente al manager di manipolare solo oggetti semplici (o oggetti con la struttura analoga, cioe’ il cui valore sia rappresentabile attraverso un tipo semplice ASN.1)

• Tuttavia:

• Ci sono risorse del sistema gestito che non possono essere modellate tramite un tipo semplice ASN.1• Ma richiedono l’uso di strutture dati piu’ complesse• Ad esempio SEQUENCE, cioe’ (con i vincoli del

framework) un insieme di tipi semplici

• Ci sono object-type che devono essere istanziati piu’ di una volta per modellare le risorse di un sistema (e.g. su un sistema ci possono essere piu’ di un disco, o piu’ di una porta seriale o Ethernet, o ...)

26

Oggetti tabella (conceptual table) – (continua)

Da RFC 1902, SMI for SNMPv2

It is sometimes convenient for developers of management applications to impose an imaginary, tabular structure on an ordered collection of objects within the MIB.

Each such conceptual table contains zero or more rows, and each row may contain one or more scalar objects, termed columnar objects.

This conceptualization is formalized by using the OBJECT-TYPE macro to define both an object which corresponds to a table and an object which corresponds to a row in that table (oltre che gli oggetti colonna di tipo ASN.1 semplice).

A conceptual table has SYNTAX of the form:

SEQUENCE OF <EntryType>

where <EntryType> refers to the SEQUENCE type of its subordinate conceptual row.

The MAX-ACCESS clause for conceptual tables is "not-accessible".

27

Oggetti tabella (conceptual table) – (continua)

• Un object-type tabella non e’ instanziabile di per se stesso, ma possono essere istanziate un numero indefinito di righe che lo compongono.

• Il numero di righe che compongono una tabella puo’ variare durante la vita di un sistema gestito.

• In particolare, il manager puo' avere la possibilita’ di chiedere all’agent di creare o cancellare righe in una tabella

(per rendere possibile cio’ deve/dovrebbe essere definito nella riga della tabella un oggetto colonna di tipo ASN.1 RowStatus e con MAX-ACCESS read-create)

• In realta’ non e’ l’object-type riga associato alla tabella che viene istanziato ma l’insieme degli object-type colonna che lo compongono.

28


3. Oggetti riga (base)

Da RFC 1902, SMI for SNMPv2

A conceptual row has SYNTAX of the form: <EntryType>

where <EntryType> is a SEQUENCE type defined as follows:

<EntryType> ::= SEQUENCE { <type1>, ... , <typeN> }

where there is one <type> for each subordinate object (oggetto colonna), and each <type> is of the form:

<descriptor> <syntax>

where <descriptor> is the descriptor naming a subordinate object, and <syntax> has the value of that subordinate object's SYNTAX clause, normally omitting the sub-typing information.

The MAX-ACCESS clause for conceptual rows is "not-accessible".

29

Oggetti riga (base) – (continua)

• L’OBJECT IDENTIFIER che denomina un object-type riga e’ (deve essere) derivato da quello che denomina l’object-type tabella di cui fa parte suffissandolo con il sub-identificatore 1

• Nella definizione dell’object-type deve essere presente la clausola <index-part> che deve assumere la forma INDEX

• la clausola INDEX riferisce uno o piu’ oggetti colonna che fanno parte della riga

• L’insieme dei valori degli oggetti colonna riferiti nella clausola INDEX deve essere tale da identificare univocamente ciascuna riga della tabella

Quindi: la selezione di una riga nella tabella non e' basata su un indiciamento (come in un array C) ma su un accesso a chiave (come in una tabella di un database)

poiche' la clausola INDEX puo' riferire piu' oggetti colonna l'accesso e' effettivamente a chiave multipla

30


4. Oggetti colonna

• Per ogni campo di un object-type riga deve essere definito un corrispondente object-type colonna

• L’identificatore di un object-type colonna deve essere identico alla label del corrispondente campo della SEQUENCE che definisce la rappresentazione dell’object-type riga di cui l’object-type colonna fa parte

• Il tipo (ASN.1 della rappresentazione) di un object-type colonna deve essere identico al (o un sottotipo del) tipo ASN.1 del corrispondente campo della SEQUENCE che definisce la rappresentazione dell’object-type riga di cui l’object-type colonna fa parte

• Il tipo (ASN.1 della rappresentazione) di un object-type colonna deve essere analogo a quello di un object-type semplice (deve cioe' essere uno dei tipi ASN.1 semplici ammessi dal framework, o un suo sottotipo)

31

Oggetti colonna – (continua)

• L’OBJECT IDENTIFIER che denomina un object-type colonna e’ derivato da quello che denomina l’object-type riga di cui fa parte suffissandolo con un sub-identificatore univoco positivo

• Un object-type colonna puo’ essere istanziato piu’ volte, una per ogni riga esistente nella tabella

• L’OBJECT IDENTIFIER che denomina una istanza di object-type colonna e’ ottenuto

• suffissando l’OBJECT IDENTIFIER dell’object-type colonna

• con una successione di interi derivata dai valori delle istanze degli object-type citati nella clausola INDEX che appartengono alla medesima riga

gli oggetti indice sono considerati nell'ordine in cui vengono citati nella clausola INDEX

32

Esempio di definizione di tabella

da RFC 1907, MIB for SNMPv2

sysORTable OBJECT-TYPE SYNTAX SEQUENCE OF SysOREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the capabilities of the local

SNMPv2 entity acting in an agent role with respect to various MIB modules. SNMPv2 entities having dynamically-configurable support of MIB modules will have a dynamically-varying number of conceptual rows.“

::= { system 9 }

-- espansione della macro genera la definizione di valore-- sysORTable OBJECT IDENTIFIER ::= { system 9 }

33

Esempio di definizione di tabella (continua)

sysOREntry OBJECT-TYPE SYNTAX SysOREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the sysORTable.“ INDEX { sysORIndex } ::= { sysORTable 1 }

SysOREntry ::= SEQUENCE { sysORIndex INTEGER, sysORID OBJECT IDENTIFIER, sysORDescr DisplayString, sysORUpTime TimeStamp}

34


sysORIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used for identifying instances of the

columnar objects in the sysORTable.“ ::= { sysOREntry 1 }

sysORID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An authoritative identification of a capabilities statement with

respect to various MIB modules supported by the local SNMPv2 entity acting in an agent role.“

::= { sysOREntry 2 }

35


sysORDescr OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the capabilities identified by the

corresponding instance of sysORID.“ ::= { sysOREntry 3 }

sysORUpTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this conceptual row was

last instanciated.“ ::= { sysOREntry 4 }

36


mgmt OBJECT IDENTIFIER ::= { internet 2 } -- da RFC 1902mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- da RFC 1902

system OBJECT IDENTIFIER ::= { mib-2 1 } -- mib-2.1

-- OBJECT IDENTIFIER(sysORTable) = system.9

-- OBJECT IDENTIFIER(sysOREntry) = sysORTable.1-- = system.9.1-- (riga di tabella)

-- OBJECT IDENTIFIER(sysORIndex) = sysOREntry.1-- (colonna #1 di

riga)

-- OBJECT IDENTIFIER(sysORID) = sysOREntry.2-- (colonna #2 di

riga)

-- OBJECT IDENTIFIER(sysORDescr) = sysOREntry.3-- (colonna #3 di

riga)

-- OBJECT IDENTIFIER(sysORUpTime)= sysOREntry.4-- (colonna #4 di

riga)

37


Tabella sysORTable (di righe sysOREntry) di 3 righe:

sysORIndex

OBJECT IDENTIFIER

sysORIndex

valore

sysORID sysORDescr sysORUpTime

sysORIndex.1

1 sysORID.1

sysORDescr.1

sysORUpTime.1

sysORIndex.2

2 sysORID.2

sysORDescr.2

sysORUpTime.2

sysORIndex.3

3 sysORID.3

sysORDescr.3

sysORUpTime.3

38

Struttura della MIB (instance)

• Possono essere effettivamente istanziati solo oggetti semplici o colonna (cioe’ oggetti di tipo ASN.1 non strutturato)

• Ogni object-instance nella MIB viene identificato (denominato) con un OBJECT IDENTIFIER

Visione 1

Poiche’ tra OBJECT IDENTIFIER vale una relazione d’ordine, possiamo vedere la MIB (instance) come una lista unidimensionale di object-instance ordinati secondo il loro nome

Notare che in questa lista ordinata

gli object-instance di un medesimo object-type colonna sono tra loro adiacenti.

i gruppi di object-instance degli object-type colonna di una stessa tabella concettuale sono tra loro adiacenti

(raggruppati per instance di object-type colonna).

39

Visone 1 - esempio• sysORTable ha OBJECT IDENTIFIER internet.2.1.1.9• sysOREntry ha OBJECT IDENTIFIER internet.2.1.1.9.1• Tutti gli object-type colonna di sysOREntry condividono lo stesso

prefisso: internet.2.1.1.9.1• OBJ.ID.(sysORIndex) =

internet.2.1.1.9.1.1• OBJ.ID.(sysORID) =

internet.2.1.1.9.1.2• OBJ.ID.(sysORDescr) =

internet.2.1.1.9.1.3• OBJ.ID.(sysORUpTime) =

internet.2.1.1.9.1.4• Tutte le object-instance dell’object-type colonna sysORIndex

condividono lo stesso prefisso: internet.2.1.1.9.1.1• OBJ.ID.(sysORIndex in riga 1) =

internet.2.1.1.9.1.1.1• OBJ.ID.(sysORIndex in riga 1) =


internet.2.1.1.9.1.1.1• Tutte le object-instance dell’object-type colonna sysORID

condividono lo stesso prefisso: internet.2.1.1.9.1.2• OBJ.ID.(sysORIndex in riga 1) =



internet.2.1.1.9.1.2.1• . . .

40

Struttura della MIB (instance)

Visione 2

Considerando il loro nome OBJECT IDENTIFIER gli object-instance possono essere visti come • foglie del sottoalbero degli OBJECT IDENTIFIER • che ha radice internet e • che contiene tutte le MIB (schema) supportate dal sistema

gestito.

Si puo’ quindi immaginare la MIB instance come consistere di un albero contenente • la MIB schema (in forma concettuale) • piu’ tutti gli object-instance (in forma reale).

Notare che l’ordinamento lessicografico sugli OBJECT IDENTIFIER si riflette anche sull’albero in quanto determina una denominazione in pre-ordine dei suoi nodi.

41

Struttura della MIB (instance) : esempio

internet=1.3.6.1

system(1) snmp(11)

sysDescr(1)

private(4) snmpV2(6)

mib-2(1) enterprises(1)

mgmt(2)

sysORTable(9) snmpInPkts(1) snmpSilentDrops(31)

sysOREntry(1)

sysORIndex(1) sysORID(2)

(0) (0) (1) (n) (0) (1) (n) (0) (0)

42

Oggetti colonna INDEX

• Un oggetto colonna INDEX puo’ avere un valore

1. Intero da 0 a 232-1

2. Stringa di ottetti di lunghezza N fissa (e.g. IpAddress)

3. Stringa di ottetti di lunghezza N variable

4. OBJECT IDENTIFIER di lunghezza N (variable)

• Per ciascuno di queste categorie di valori c’e’ una regola che definisce la modalita’ di estensione OBJECT IDENTIFIER che consente di distinguere le righe di una tabella

(in realta’ le istanze delle colonne che costituiscono la riga)

• vedi regole dettagliate alla pagina seguente

43


• Regola di estensione dell’OBJECT IDENTIFIER che identifica un istanza di oggetto colonna in base al tipo della colonna INDEX:

1. Intero: Singolo sub-identificatore con il valore dell’intero

2. Stringa di lunghezza fissa: Successione di N sub-identificatori, dove ogni sub-identificatore ha il valore del corrispondente ottetto

3. Stringa di lunghezza variabile: Successione di N+1 sub-identificatori, dove il primo ha valore N, e quelli successivi hanno il valore del corrispondente ottetto

4. OBJECT IDENTIFIER: Successione di N+1 sub-identificatori, dove il primo ha valore N, e quelli successivi hanno il valore del corrispondente sub-identificatore dell’OBJECT IDENTIFIER

44

OBJECT-TYPE: esempio da RFC 2011, MIB for IP

-- the IP Address Translation table

-- The Address Translation tables contain the IpAddress to-- "physical" address equivalences. Some interfaces do not-- use translation tables for determining address-- equivalences (e.g., DDN-X.25 has an algorithmic method);-- if all interfaces are of this type, then the Address-- Translation table is empty, i.e., has zero entries.

ipNetToMediaTable OBJECT-TYPE SYNTAX SEQUENCE OF IpNetToMediaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP Address Translation table used for mapping from IP addresses to physical addresses." ::= { ip 22 }

45


ipNetToMediaEntry OBJECT-TYPE SYNTAX IpNetToMediaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one IpAddress to `physical' address equivalence." INDEX { ipNetToMediaIfIndex, ipNetToMediaNetAddress }::= { ipNetToMediaTable 1 }

IpNetToMediaEntry ::= SEQUENCE { ipNetToMediaIfIndex INTEGER, ipNetToMediaPhysAddress PhysAddress, ipNetToMediaNetAddress IpAddress, ipNetToMediaType INTEGER }

46


ipNetToMediaIfIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION

"The interface on which this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface as identified by the same value of RFC 1573's (obsoleted by RFC 2233) ifIndex."

::= { ipNetToMediaEntry 1 }

ipNetToMediaPhysAddress OBJECT-TYPE SYNTAX PhysAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The media-dependent `physical' address." ::= { ipNetToMediaEntry 2 }

47


ipNetToMediaNetAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IpAddress corresponding to the media-dependent `physical' address." ::= { ipNetToMediaEntry 3 }

N.B.: IpAddress e' una stringa di lunghezza fissa: 4 ottetti

48


ipNetToMediaType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following invalid(2), -- an invalidated mapping dynamic(3), static(4) } MAX-ACCESS read-create STATUS current DESCRIPTION

"The type of mapping. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the ipNetToMediaTable. That is, it effectively disassociates the interface identified with said entry from the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipNetToMediaType object."

::= { ipNetToMediaEntry 4 }

49

OBJECT-TYPE tabella (concettuale): esercizio

Creare un esempio di ipNetToMediaTable (con 2 righe) indicando:

• L'object-identifier di ogni object-type colonna.

• L'object-identifier di ogni istanza (object-instance) di object-type colonna.

Inventare i valori necessari.

NB: gli OBJECT IDENTIFIER che identificano le diverse istanze di un oggetto colonna della tabella ipNetToMediaTable hanno la seguente struttura:

ipNetToMediaColumn.suff1.suff2-1.suff2-2.suff2-3.suff2-4

dove:

• ipNetToMediaColumn: OBJECT IDENTIFIER del particolare object-type colonna

• suff1: valore della colonna iPNetToMediaIfIndex in quella riga• suff2-1: valore del primo ottetto della colonna iPNetToMediaNetAddress

in quella riga• suff2-2: valore del secondo ottetto della colonna

iPNetToMediaNetAddress in quella riga• suff2-3: valore del terzo ottetto della colonna iPNetToMediaNetAddress in

quella riga• suff2-4: valore del quarto ottetto della colonna iPNetToMediaNetAddress

in quella riga

50


• Considerando l’ordinamento lessicografico degli object-instace nella MIB (istanza) e’ evidente che, data la regola di denominazione di righe, colonne, e istanze di oggetti colonna, Le istanze di oggetti di una stessa colonna sono contigue

tra loro I gruppi di istanze di oggetti delle successive colonne della

tabella sono contigui tra loro

• Problema: utilizzando come indice di una tabella un object-type il cui valore abbia lunghezza variabile (e.g. una stringa di ottetti di lunghezza variabile), date le regole di denominazione delle istanze utilizzate, si ottiene lo spiacevole effetto che• la riga di indice “salati” (estensione .6.115.97.108.97.116.105)

• precede la riga di indice “romagnoli” (estensione .9.114.111.109.97.103.110.111.108.105)

• Soluzione: clausola IMPLIED

51


1. Attributo IMPLIED nella clausola INDEX

• Se l’ultimo object-type citato nella clausola INDEX ha valore di lunghezza variabile (cioe’ e’ una stringa di ottetti di lunghezza variabile o un OBJECT IDENTIFIER), esso puo’ essere prefissato con l’attributo IMPLIED.

• In questo caso la regola con cui il suo valore e’ utilizzato per identificare le righe della tabella viene modificata in quanto non si deve piu’ inserire come primo sub-identificatore il numero di sub-identificatori generati di seguito

• In questo modo la riga di indice “romagnoli” (estensione .114.111.109.97.103.110.111.108.105) viene a precedere (come intuitivo) la riga di indice “salati” (estensione .115.97.108.97.116.105)

52


2. Oggetti ausiliari

• Puo’ succedere che un oggetto colonna sia presente in una tabella al solo scopo di identificarne le righe.

• Un oggetto di questa natura e’ detto ausiliario.

• E’ il caso dell’oggetto colonna sysORIndex della tabella sysORTable.

• Un oggetto ausiliario ha di norma MAX-ACCESS not-accessible, e comunque

il valore di una sua istanza e’ comunque derivabile dall’OBJECT IDENTIFIER che identifica una qualunque (in particolare: qualunque altra) colonna della stessa riga

53


5. Oggetti estensione (di riga)

• Consentono di estendere una tabella (l’insieme delle sue colonne) senza toccarne la definizione base

• Ad esempio per aggiungere caratteristiche vendor-specific ad un tipo di risorsa che e’ modellato da un object-type tabella standard

• SMI consente di arricchire la modellazione standard di una risorsa con estensioni proprietarie senza interagire in alcun modo con il modello base

• E’ addirittura possibile la coesistenza di diverse estensioni indipendenti (tra loro ortogonali) di una stessa tabelle

Una estensione di riga utilizza le stesse regole di identificazione delle istanze (eredita la clausola INDEX) della riga base che riferisce

utilizzando il costrutto AUGMENTS {…}

54

Oggetti estensione (di riga) – (continua)

• Tuttavia l’OBJECT IDENTIFIER che denomina un object-type estensione di riga e’ scorrelato dall’OBJECT IDENTIFIER che denomina la riga della tabella che si vuole estendere

• Gli oggetti estensione sono definiti come righe di una tabella concettuale estensione della tabella base

• L'OBJECT IDENTIFIER che identifica un oggetto estensione e' derivato (come quello di una normale riga) dall'OBJECT IDENTIFIER della tabella concettuale cui appartiene:

cioe' dall’OBJECT IDENTIFIER della tabella estensione,

quindi non e' di norma collegato con quello della riga base

• Gli object-type colonna dell'estensione sono denominati a partire dall'OBJECT IDENTIFIER dell'estensione

55

Oggetti estensione (di riga) – (continua)

• Gli oggetti estensione sono anch’essi delle righe e quindi

• Il tipo ASN.1 citato nella clausola SYNTAX deve essere una SEQUENCE

• Nella definizione dell’object-type deve essere presente la clausola <index-part> che deve assumere la forma AUGMENTS

• la clausola AUGMENTS riferisce l’object-type riga (base) della tabella che si vuole estendere

• tramite la clausola AUGMENTS la estensione eredita il sistema di indicizzazione della riga base

• La clausola MAX-ACCESS deve avere valore not-accessibe

56

Esempio di estensione di tabellada RFC 1573, Evolution of the Interfaces Group of MIB-II

ifTable OBJECT-TYPE SYNTAX SEQUENCE OF IfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION

"A list of interface entries. The number of entries is given by the value of ifNumber."

::= { interfaces 2 } ifEntry OBJECT-TYPE SYNTAX IfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION

"An entry containing management information applicable to a particular interface."

INDEX { ifIndex } ::= { ifTable 1 }

57

Esempio di estensione di tabella (continua)

IfEntry ::= SEQUENCE { ifIndex InterfaceIndex, ifDescr DisplayString, ifType IANAifType, ifMtu Integer32, ifSpeed Gauge32, ifPhysAddress PhysAddress, ifAdminStatus INTEGER, ifOperStatus INTEGER, ifLastChange TimeTicks, ifInOctets Counter32, ifInUcastPkts Counter32, ifInNUcastPkts Counter32,

-- deprecated ifInDiscards Counter32, ifInErrors Counter32, ifInUnknownProtos Counter32, ifOutOctets Counter32, ifOutUcastPkts Counter32, ifOutNUcastPkts Counter32, -- deprecated ifOutDiscards Counter32, ifOutErrors Counter32, ifOutQLen Gauge32, -- deprecated ifSpecific OBJECT IDENTIFIER -- deprecated }

58


ifXTable OBJECT-TYPE SYNTAX SEQUENCE OF IfXEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION

"A list of interface entries. The number of entries is given by the value of ifNumber. This table contains additional objects for the interface table."

::= { ifMIBObjects 1 }

ifXEntry OBJECT-TYPE SYNTAX IfXEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION

"An entry containing additional management information applicable to a particular interface."

AUGMENTS { ifEntry } ::= { ifXTable 1 }

59


IfXEntry ::= SEQUENCE { ifName DisplayString, ifInMulticastPkts Counter32, ifInBroadcastPkts Counter32, ifOutMulticastPkts Counter32, ifOutBroadcastPkts Counter32, ifHCInOctets Counter64, ifHCInUcastPkts Counter64, ifHCInMulticastPkts Counter64, ifHCInBroadcastPkts Counter64, ifHCOutOctets Counter64, ifHCOutUcastPkts Counter64, ifHCOutMulticastPkts Counter64, ifHCOutBroadcastPkts Counter64, ifLinkUpDownTrapEnable INTEGER, ifHighSpeed Gauge32, ifPromiscuousMode TruthValue, ifConnectorPresent TruthValue }

60

Colonne mancanti

• guardando la definizione delle colonne di ifTable e ifXTable molte colonne risultano:

• logicamente in alternativa tra loro (potrebbero avere valore nullo quando non significative?), o

• obsolete (e.g. ifSpecific)

• i gruppi di conformita' (vedi lez. 5.4) definiti su queste tabelle non comprendono in effetti tutte le colonne

• cio' che si istanzia davvero in una MIB-istanza sono solo gli oggetti colonna, non righe e tabelle concettuali

e' in effetti ammissibile che una tabella in una MIB-istanza non comprenda tutte le colonne previste dalla definizione della tabella stessa nella MIB-schema

e' addirittura possibile che il contenuto delle diverse righe di una tabella sia diverso, cioe' che oggetti colonna siano presenti in una riga e non in un'altra

61

Colonne mancanti - da RFC 2233 1

• There are a number of situations where an agent does not know the value of one or more objects for a particular interface.

In all such circumstances, an agent MUST NOT instantiate an object with an incorrect value;

rather, it MUST respond with the appropriate error/exception condition (e.g., noSuchInstance for SNMPv2).

• As a result of this "known values" rule, management applications MUST be able to cope with the responses to retrieving the object instances within a conceptual row of the ifTable revealing that some of the row's columnar objects are missing/not available.

• N.B.: e’ una reintroduzione surrettizia di valori opzionali, con tutte le conseguenti complessita’ implementative!

62



• One example is where an agent is unable to count the occurrences defined by one (or more) of the ifTable counters.

• In this circumstance, the agent MUST NOT instantiate the particular counter with a value of, say, zero.

• To do so would be to provide mis-information to a network management application reading the zero value, and thereby assuming that there have been no occurrences of the event (e.g., no input errors because ifInErrors is always zero).

63



• Sometimes the lack of knowledge of an object's value is temporary.

• For example, when the MTU of an interface is a configured value and a device dynamically learns the configured value through (after) exchanging messages over the interface (e.g., ATM LAN- Emulation).

In such a case, the value is not known until after the ifTable entry has already been created.

In such a case, the ifTable entry should be created without an instance of the object whose value is unknown;

later, when the value becomes known, the missing object can then be instantiated (e.g., the instance of ifMtu is only instantiated once the interface's MTU becomes known).

64

Estensione di una tabella per riferimento esplicito

• oltre che in modo formale (come nel caso di ifXTable rispetto a ifTable) una tabella puo' essere "estesa" anche attraverso una o piu' tabelle correlate

queste altre tabelle non sono propriamente estensioni, in quanto

• non utilizzano (tutte e sole) le stesse colonne indice della tabella primaria

• non necessariamente hanno una riga in corrispondenza (1 a 1) a ciascuna riga della tabella primaria

• la tabella ifTable puo' ad esempio essere estesa tramite tabelle che descrivono le caratteristiche ifType-specifiche di una interfaccia

• RFC 2665 definisce ad esempio la tabella per "estendere" ifTable con le caratteristiche specifiche delle interfacce Ethernet-like

• le righe della tabella "estensione" sono correlate alle relative righe di ifTable attraverso un "riferimento esplicito"

65

Estensione di una tabella per riferimento esplicito Esempio da RFC 2665: MIB for Ethernet-like Interface Types

dot3StatsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3StatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION

"Statistics for a collection of ethernet-like interfaces attached to a particular system. There will be one row in this table for each ethernet-like interface in the system."

::= { dot3 2 }

dot3StatsEntry OBJECT-TYPE SYNTAX Dot3StatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION

"Statistics for a particular interface to an ethernet-like medium." INDEX { dot3StatsIndex } ::= { dot3StatsTable 1 }

66


Dot3StatsEntry ::= SEQUENCE { dot3StatsIndex InterfaceIndex, dot3StatsAlignmentErrors Counter32, … }

dot3StatsIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION

"An index value that uniquely identifies an interface to an ethernet-like medium.The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex."

REFERENCE "RFC 2233, ifIndex" ::= { dot3StatsEntry 1 }

67


dot3StatsAlignmentErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION

"A count of frames received on a particular interface that are not an integral number of octets in length and do not pass the FCS check....Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime."

REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.7, aAlignmentErrors"

::= { dot3StatsEntry 2 }

68

Estensione di una tabella per riferimento implicito

• esiste un'altra tecnica di estensione delle tabelle, che si puo' denominare ”tabella correlata con riferimento implicito"

• i motivi per introdurre questo tipo di estensione sono gli stessi che portano all'introduzione dell'estensione per riferimento esplicito

• la tecnica di estensione per riferimento implicito si basa sul fatto che

• non necessariamente un indice di una tabella deve essere un oggetto colonna della tabella stessa (vedi prossima pagina)

• spesso gli indici non convogliano informazione di per se', ma servono solo per l'identificazione delle righe:vedi ad esempio gli oggetti ausiliari che di norma hanno MAX-ACCESS not-accessible

secondo la tecnica di estensione per riferimento implicito un indice della tabella estensione e' costituito dalla colonna indice della tabella che si vuole estendere

69

INDICI che non sono colonne della tabella

• da RFC 1902:

• Note that objects specified in a conceptual row’s INDEX clause need not be columnar objects of that conceptual row.

• In this situation, the DESCRIPTION clause of the conceptual row must include a textual explanation of how the objects which are

• included in the INDEX clause

• but not columnar objects of that conceptual row,

are used in uniquely identifying instances of the conceptual row’s columnar objects.

70

Estensione di una tabella per riferimento implicito Esempio da RFC 2233: MIB delle interfacce

ifRcvAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF IfRcvAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION

"This table contains an entry for each address (broadcast, multicast, or uni-cast) for which the system will receive packets/frames on a particular interface, except as follows:

• for an interface operating in promiscuous mode, entries are only required for those addresses for which the system would receive frames were it not operating in promiscuous mode.

• for 802.5 functional addresses, only one entry is required, for the address which has the functional address bit ANDed with the bit mask of all functional addresses for which the interface will accept frames.

A system is normally able to use any unicast address which corresponds to an entry in this table as a source address."

::= { ifMIBObjects 4 }

71


ifRcvAddressEntry OBJECT-TYPE SYNTAX IfRcvAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION

"A list of objects identifying an address for which the system will accept packets/frames on the particular interface identified by the index value ifIndex."

INDEX { ifIndex, ifRcvAddressAddress } ::= { ifRcvAddressTable 1 }

IfRcvAddressEntry ::= SEQUENCE { ifRcvAddressAddress PhysAddress, ifRcvAddressStatus RowStatus, ifRcvAddressType INTEGER }

72


• notare che l'object-type ifIndex non e' una colonna della tabella!

• ifIndex e’ l’indice della tabella “base” ifTable

• anche in questo caso non abbiamo propriamente una tabella estensione, perche’ non c’e’ necessariamente una relazione 1 a 1 tra le righe della tabella base e quelle della nuova tabella

• in questo caso ci possono essere piu’ righe di ifRcvAddressTable per ogni riga di ifTable

(in corrispondenza a diversi indirizzi fisici di ricezione utilizzati dal sistema sulla stessa sottorete, cioe’ con diverso valore della colonna ifRcvAddressAddress)

Date post:	01-May-2015
Category:	Documents
Upload:	lucrezia-riva
View:	212 times
Download:	0 times

1 LABORATORIO DI INFORMATICA Network Management 5. Structure of Management Information (SMIv2) 5.2....

Documents