ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA
FACOLTA' DI INGEGNERIA - SEDE DI CESENA
LABORATORIO DI INFORMATICA
Network Management
5. Structure of Management Information (SMIv2)
5.2. OBJECT-TYPE
Claudio Salati
Copyright © 2001 by Claudio Salati
1
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
gestito
Il 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)
2
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.1
2.una textual-convention
N.B. in alcuni casi (tipicamente quando si riferisce una textualconvention) 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 predefinite 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
3
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)
4
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
5
OBJECT-TYPE
<access>

|
|
|
|
<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
not-accessible
accessible-for-notify
read-only
read-write
read-create
6
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
7
OBJECT-TYPE
•
MAX-ACCESS
indicazioni di quali operazioni possono coinvolgere istanze di
questo object-type sull'interfaccia manager-agent
set
[create]
read-create
read-write
read-only
accessible-for-notify

set
get
[assignment] [any kind]
trap









not-accessible
8
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
9
OBJECT-TYPE
•
DESCRIPTION
una descrizione in linguaggio naturale dell'object-type, e in
particolare della sua semantica specifica
•
REFERENCE
se l'object-type e' in qualche modo correlato ad un altro objecttype, 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.
10
OBJECT-TYPE
• DEFVAL
• scopo di questa clausola e' di fornire un valore iniziale di default
indicativo da assegnare in creazione ad istanze di questo objecttype (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
11
OBJECT-TYPE
•
DEFVAL (continua)
da RFC 1902, SMI for SNMPv2
By way of example, consider the following possible DEFVAL clauses:
ObjectSyntax
-----------------Integer32
INTEGER
OCTET STRING
OBJECT IDENTIFIER
BITS
IpAddress
DEFVAL clause
--------------------DEFVAL { 1 }
-- same for Gauge32, TimeTicks, Unsigned32
DEFVAL { valid }
-- enumerated value
DEFVAL { 'ffffffffffff'H }
DEFVAL { sysDescr }
DEFVAL { { primary, secondary } }
-- enumerated values that are set
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.
12
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
13
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 }
14
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
15
da RFC 1903, Textual Conventions for SNMPv2
-- 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 reinitialized, the value of every object instance having this syntax
must either be incremented from its value prior to the reinitialization, or (if the value prior to the re-initialization is
unknown) be set to a pseudo-randomly generated value.“
SYNTAX
INTEGER (0..2147483647)
16
OBJECT-TYPE: esempio da RFC 1907, MIB for SNMPv2
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 }
17
da RFC 1903, Textual Conventions for SNMPv2
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))
18
OBJECT-TYPE: esempio da RFC 1907, MIB for SNMPv2
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 }
19
OBJECT-TYPE: esempio da RFC 1907, MIB for SNMPv2
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 }
20
OBJECT-TYPE: esempio da RFC 1907, MIB for SNMPv2
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 }
21
OBJECT-TYPE: esempio da RFC 1907, MIB for SNMPv2
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 }
22
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
23
Categorie di object-type
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
24
Categorie di object-type
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 ...)
25
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".
26
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.
27
Categorie di object-type
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".
28
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

29
Categorie di object-type
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’objecttype 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)
30
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
31
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 }
32
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}
33
Esempio di definizione di tabella (continua)
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 }
34
Esempio di definizione di tabella (continua)
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 }
35
Esempio di definizione di tabella (continua)
mgmt OBJECT IDENTIFIER ::= { internet 2 }
mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
-- da RFC 1902
-- 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)
36
Esempio di definizione di tabella (continua)
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
37
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).
38
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
• 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
• OBJ.ID.(sysORIndex in riga 1)
= internet.2.1.1.9.1.2.1
• OBJ.ID.(sysORIndex in riga 1)
= internet.2.1.1.9.1.2.1
39
• ...
Struttura della MIB (instance)
Visione 2
 Considerando il loro nome OBJECT IDENTIFIER gli objectinstance 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.
40
Struttura della MIB (instance) : esempio
internet=1.3.6.1
mgmt(2)
private(4)
mib-2(1)
enterprises(1)
system(1)
snmp(11)
sysORTable(9)
sysDescr(1)
snmpV2(6)
snmpInPkts(1)
snmpSilentDrops(31)
sysOREntry(1)
sysORIndex(1) sysORID(2)
(0)
(0) (1)
(n) (0) (1)
(n)
(0)
(0)
41
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
42
Oggetti colonna INDEX
• 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 subidentificatori, dove ogni sub-identificatore ha il valore del
corrispondente ottetto
3. Stringa di lunghezza variabile: Successione di N+1 subidentificatori, 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
43
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 }
44
OBJECT-TYPE: esempio da RFC 2011, MIB for IP
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
ipNetToMediaPhysAddress
ipNetToMediaNetAddress
ipNetToMediaType
}
INTEGER,
PhysAddress,
IpAddress,
INTEGER
45
OBJECT-TYPE: esempio da RFC 2011, MIB for IP
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 }
46
OBJECT-TYPE: esempio da RFC 2011, MIB for IP
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
47
OBJECT-TYPE: esempio da RFC 2011, MIB for IP
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 }
48
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
49
in quella riga
Oggetti colonna INDEX
•
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
50
Oggetti colonna INDEX
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 subidentificatore 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)
51
Oggetti colonna INDEX
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 notaccessible, 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
52
Categorie di object-type
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 {…}
53
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
54
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
55
Esempio di estensione di tabella
da 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 }
56
Esempio di estensione di tabella (continua)
IfEntry ::=
SEQUENCE {
ifIndex
ifType
ifSpeed
ifAdminStatus
ifLastChange
ifInUcastPkts
InterfaceIndex,
IANAifType,
Gauge32,
INTEGER,
TimeTicks,
Counter32,
ifDescr
ifMtu
ifPhysAddress
ifOperStatus
ifInOctets
ifInNUcastPkts
DisplayString,
Integer32,
PhysAddress,
INTEGER,
Counter32,
Counter32,
-- deprecated
Counter32,
ifInDiscards
Counter32,
ifInErrors
ifInUnknownProtos Counter32,
ifOutOctets
Counter32,
ifOutUcastPkts Counter32,
ifOutNUcastPkts
Counter32, -- deprecated
ifOutDiscards Counter32,
ifOutErrors
Counter32,
ifOutQLen
Gauge32, -- deprecated
ifSpecific
OBJECT IDENTIFIER -- deprecated
}
57
Esempio di estensione di tabella (continua)
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 }
58
Esempio di estensione di tabella (continua)
IfXEntry ::=
SEQUENCE {
ifName
ifInMulticastPkts
ifInBroadcastPkts
ifOutMulticastPkts
ifOutBroadcastPkts
ifHCInOctets
ifHCInUcastPkts
ifHCInMulticastPkts
ifHCInBroadcastPkts
ifHCOutOctets
ifHCOutUcastPkts
ifHCOutMulticastPkts
ifHCOutBroadcastPkts
ifLinkUpDownTrapEnable
ifHighSpeed
ifPromiscuousMode
ifConnectorPresent
}
DisplayString,
Counter32,
Counter32,
Counter32,
Counter32,
Counter64,
Counter64,
Counter64,
Counter64,
Counter64,
Counter64,
Counter64,
Counter64,
INTEGER,
Gauge32,
TruthValue,
TruthValue
59
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
60
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!
61
Colonne mancanti - da RFC 2233
2
• There are a number of situations where an agent does not know the
value of one or more objects for a particular interface.
• 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).
62
Colonne mancanti - da RFC 2233
3
• There are a number of situations where an agent does not know the
value of one or more objects for a particular interface.
• 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).
63
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"
64
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 }
65
Estensione di una tabella per riferimento esplicito

Esempio da RFC 2665: MIB for Ethernet-like Interface Types
Dot3StatsEntry ::= SEQUENCE {
dot3StatsIndex
dot3StatsAlignmentErrors
… }
InterfaceIndex,
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 }
66
Estensione di una tabella per riferimento esplicito

Esempio da RFC 2665: MIB for Ethernet-like Interface Types
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 reinitialization 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 }
67
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
68
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.
69
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 }
70
Estensione di una tabella per riferimento implicito

Esempio da RFC 2233: MIB delle interfacce
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
}
71
Estensione di una tabella per riferimento implicito

Esempio da RFC 2233: MIB delle interfacce
•
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)
72