ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA
FACOLTA' DI INGEGNERIA - SEDE DI CESENA
LABORATORIO DI INFORMATICA
Network Management
9. Visita guidata alle MIB standard
9.1. snmpMIB, ifMIB, etherMIB, mauMIB
Claudio Salati
Copyright © 2001 by Claudio Salati
1
Quali MIB?
•
RFC 1907: MIB for SNMPv2.
•
RFC 2233: The Interface Group MIB using SMIv2
•
RFC 2665: Definition of Managed Objects for the Ethernet-like
Interface Types
•
RFC 2668: Definition of Managed Objects for IEEE 802.3 Medium
Attachment Units (MAUs)
•
RFC 2011: SNMPv2 MIB for IP using SMIv2
•
RFC 2096: IP Forwarding Table MIB
•
RFC 2012: SNMPv2 MIB for TCP using SMIv2
•
RFC 2013: SNMPv2 MIB for UDP using SMIv2
2
OBJECT IDENTIFIER utilizzati nelle MIB
internet = 1.3.6.1
Vedi:
mgmt (2)
mib-2 (1)
transmission (10)
system (1) -- RFC 1907
snmp (11) -- RFC 1907
•
RFC 1902, SNMPv2-SMI
•
RFC 1907, SNMPv2MIB
•
RFC 2233, ifMIB
interfaces (2) -- RFC 2233
ifMIB (31) -- RFC 2233
experimental (3)
private (4)
enterprises (1)
snmpV2 (6)
snmpModules (1)
snmpMIB (1) -- (RFC 1907)
snmpMIBObjects (1)
3
RFC 1907: MIB for SNMPv2
•
Deriva dalla MIB-II di SNMPv1.
•
Si occupa:
•
della gestione del sistema gestito in quanto tale:
• systemGroup,
•
della gestione dell'agent SNMPv2
• snmpGroup
• snmpBasicNotificationsGroup
•
della gestione della sincronizzazioni di diverse richieste di set
da parte di uno o piu' manager
• snmpSetGroup
•
della gestione dell'infrastruttura amministrativa Communitybased
• snmpCommunityGroup
4
RFC 1907: MIB for SNMPv2
mib-2 = 1.3.6.1.2.1
system (1)
sysDescr (1)
sysObjectID (2)
sysUpTime (3)
sysContact (4)
sysName (5)
sysLocation (6)
sysServices (7)
sysORLastChange (8)
sysORTable (9)
sysOREntry (1)
sysORIndex (1)
sysORID (2)
sysORDescr (3)
sysORUpTime (4)
5
RFC 1907: MIB for SNMPv2
mib-2 = 1.3.6.1.2.1
snmp (11)
snmpInPkts (1)
snmpInBadVersions (3)
snmpInBadCommunityNames (4)
snmpInBadCommunityUses (5)
snmpInASPNarseErrs (6)
snmpEnableAuthenTraps (30)
snmpSilentDrops (31)
snmpProxyDrops (32)
6
RFC 1907: MIB for SNMPv2
snmpMIBObjects = 1.3.6.1.6.3.1.1
snmpTrap (4)
snmpTrapOID (1)
snmpTrapEnterprise (3)
snmpTraps (5)
coldStart (1)
warmStart (2)
authenticationFailure (5)
snmpSet (6)
snmpSetSerialNo (1)
7
RFC 1907: MIB for SNMPv2
•
systemGroup
• vedi lez. 5.4 per la definizione dell'object-group
• vedi lez. 5.2 per la definizione degli object-type principali
• vengono registrate:
• informazioni di inventory:
tipo, funzionalita', identificazione-cliente, localita' di
installazione dell'apparato
• il tempo di vita dell'agent SNMP
• le capability di gestione dell'agent: tabella sysORTable
8
RFC 1907: MIB for SNMPv2
•
snmpGroup
• vedi lezione 5.4 per la definizione dell'object-group
• oltre che una serie di contatori di PDU SNMP il gruppo
contiene l'object-type snmpEnableAuthenTraps (vedi lez. 5.3)
• l'object-type snmpTrapOID (vedi lez. 5.3) non appartiene
formalmente a questo (e a nessun altro) gruppo, anche se
logicamente dovrebbe farne parte
In realta' questo oggetto e' contenuto, insieme a
snmpTrapEnterprise a un sottoalbero OBJECT IDENTIFIER
autonomo, ma non "associato" ad alcun object-group
• l'RFC definisce anche l'object-type snmpTrapEnterprise che
deve essere utilizzato nella realizzazione di un proxy di
traduzione SNMPv2-SNMPv1
9
RFC 1907: MIB for SNMPv2
•
snmpBasicNotificationsGroup
• vedi lez. 5.4 per la definizione del notification-group
• vedi lez. 5.3 per la definizione delle notifiche
• la notifica di warmStart (vedi lez. 5.3) non fa parte del gruppo,
ne' di alcun altro gruppo
•
snmpSetGroup
• vedi lez. 5.4 per la definizione dell'object-group
• vedi lez. 5.2 per la definizione dell'object-type
snmpSetSerialNo, che e' l'unico object-type del gruppo
•
snmpCommunityGroup
• vedi lez. 5.4 per la definizione dell'object-group
• vedi lez. 7 per la definizione degli object-type del gruppo
10
RFC 2233: The Interfaces Group MIB using SMIv2
•
Deriva indirettamente dalla MIB-II di SNMPv1
tramite RFC 1573 di SNMPv2 (Evolution of the Interfaces Group of
MIB-II), che RFC 2233 rende obsoleto
•
Si occupa della gestione di base (type independent) delle
interfacce del sistema gestito
•
N.B.: in un'ottica puramente di gestione di Internet, una
interfaccia si identifica con una sottorete di IP
•
per questo nella tabella delle interfacce e' normalmente
compresa anche l'interfaccia di loopback
11
RFC 2233: The Interfaces Group MIB using SMIv2
la MIB si compone sostanzialmente di 4 tabelle, 3 scalari e 2 notifiche:
• lo scalare ifNumber indica quante sono le interfacce descritte
• lo scalare ifTableLastChange che indica l'istante dell'ultima
modifica di ifNumber
• la tabella ifTable contiene la descrizione di base (indipendente dal
tipo della singola interfaccia) delle ifNumber interfacce
• la tabella ifXTable costituisce una prima estensione di ifTable
indipendente dal tipo della singola interfaccia
• la tabella ifStackTable descrive la struttura layerizzata di
interfacce complesse (l'oggetto scalare ifStackLastChange indica
l'istante di ultima modifica di ifStackTable)
• la tabella ifRcvAddressTable e' utilizzata per interfacce che
utilizzano in ricezione piu' di un indirizzo
• le due notifiche spontanee linkDown e linkUp servono per
informare un/i manager della variazione dello stato operazionale di
una interfaccia (vedi lez. 5.3)
12
RFC 2233: The Interfaces Group MIB using SMIv2
mib-2 = 1.3.6.1.2.1
interfaces (2)
ifNumber (1)
ifTable (2)
ifEntry (1)
ifIndex (1)
ifDescr (2)
ifType (3)
ifSpeed (5)
ifPhysAddress (6)
ifAdminStatus (7)
ifOperStatus (8)
ifLastChange (9)
...
13
RFC 2233: The Interfaces Group MIB using SMIv2
mib-2 = 1.3.6.1.2.1
ifMIB (31)
ifMIBObjects (1)
ifTableLastChange (5)
ifXTable (1)
ifXEntry (1)
ifName (1)
ifLinkUpDowTrapEnable (14)
ifHighSpeed (15)
ifConnectorPresent (17)
ifAlias (18)
...
ifRcvAddressTable (4)
ifRcvAddressEntry (1)
ifRcvAddressAddress (1)
ifRcvAddressStatus (2)
ifRcvAddressType (3)
14
RFC 2233: The Interfaces Group MIB using SMIv2
mib-2 = 1.3.6.1.2.1
ifMIB (31)
ifMIBObjects (1)
ifStackLastChange (6)
ifstackTable (2)
ifStackEntry (1)
ifStackHigherLayer (1)
ifStackLowerLayer (2)
ifStackStatus (3)
15
RFC 2233: The Interfaces Group MIB using SMIv2
snmpMIBObjects = 1.3.6.1.6.3.1.1
snmpTraps (5)
linkDown (3)
linkUp (4)
16
RFC 2233: The Interfaces Group MIB using SMIv2
da RFC 2233: Gestione generica delle interfacce
•
One of the strengths of internetwork-layer protocols such as IP is
that they are designed to run over any network interface.
•
In achieving this, IP considers any and all protocols it runs over as
a single "network interface" layer. A similar view is taken by other
internetwork-layer protocols.
 This concept is represented in MIB-II by the 'interfaces' group
which defines a generic set of managed objects such that any
network interface can be managed in an interfaceindependent manner through these managed objects.
 The 'interfaces' group provides the means for additional managed
objects specific to particular types of network interface (e.g., a
specific medium such as Ethernet) to be defined as extensions
to the 'interfaces' group for media-specific management.
17
RFC 2233: oggetti semplici
ifNumber OBJECT-TYPE
SYNTAX
Integer32
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"The number of network interfaces (regardless of their current state)
present on this system."
::= { interfaces 1 }
ifTableLastChange OBJECT-TYPE
SYNTAX
TimeTicks
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"The value of sysUpTime at the time of the last creation or deletion of
an entry in the ifTable. If the number of entries has been unchanged
since the last re-initialization of the local network management
subsystem, then this object contains a zero value."
::= { ifMIBObjects 5 }
18
RFC 2233: tabella ifTable
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 }
19
RFC 2233: tabella ifTable
IfEntry ::=
SEQUENCE {
ifIndex
InterfaceIndex,
ifType
IANAifType,
ifSpeed
Gauge32,
ifAdminStatus INTEGER,
ifLastChange TimeTicks,
ifInUcastPkts Counter32,
ifDescr
DisplayString,
ifMtu
Integer32,
ifPhysAddress
PhysAddress,
ifOperStatus
INTEGER,
ifInOctets
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
}
20
RFC 2233: tabella ifXTable
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 }
21
RFC 2233: tabella ifXTable
IfXEntry ::=
SEQUENCE {
ifName
ifInMulticastPkts
ifOutMulticastPkts
ifHCInOctets
ifHCInMulticastPkts
ifHCOutOctets
ifHCOutMulticastPkts
DisplayString,
Counter32,
Counter32,
Counter64,
Counter64,
Counter64,
Counter64,
ifLinkUpDownTrapEnable
ifHighSpeed
ifPromiscuousMode
ifConnectorPresent
ifAlias
ifCounterDiscontinuityTime
ifInBroadcastPkts
ifOutBroadcastPkts
ifHCInUcastPkts
ifHCInBroadcastPkts
ifHCOutUcastPkts
ifHCOutBroadcastPkts
Counter32,
Counter32,
Counter64,
Counter64,
Counter64,
Counter64,
INTEGER,
Gauge32,
TruthValue,
TruthValue,
DisplayString,
TimeStamp
}
22
RFC 2233: The Interfaces Group MIB using SMIv2
da RFC 2233: Aggiunta/rimozione dinamica di interfacce
• While some interfaces, for example, most physical interfaces, cannot be
created via network management, other interfaces such as logical
interfaces sometimes can be. The ifTable contains only generic
information about an interface. Almost all 'create-able' interfaces have
other, media-specific, information through which configuration parameters
may be supplied prior to creating such an interface.
 Thus, the ifTable does not itself support the creation or deletion of
an interface (specifically, it has no RowStatus column).
 Rather, if a particular interface type supports the dynamic creation
and/or deletion of an interface of that type, then that media-specific
MIB should include an appropriate RowStatus object (see the ATM
LAN-Emulation Client MIB for an example of a MIB which does this).
 Typically, when such a RowStatus object is created/deleted, then the
conceptual row in the ifTable appears/disappears as a by-product, and an
ifIndex value (chosen by the agent) is stored in an appropriate object in the
media-specific MIB.
23
RFC 2233: tabella ifTable: oggetti colonna
ifIndex OBJECT-TYPE
SYNTAX
InterfaceIndex
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"A unique value, greater than zero, for each interface.
-- indice della tabella ifTable+ifXTable
-- rappresenta l'identificatore univoco di una interfaccia del sistema
-- gestito
• It is recommended that values are assigned contiguously
starting from 1.
• The value for each interface sub-layer must remain constant at
least from one re-initialization of the entity's network
management system to the next re-initialization."
::= { ifEntry 1 }
24
RFC 2233: textual-convention InterfaceIndex
InterfaceIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS
current
DESCRIPTION
"A unique value, greater than zero, for each interface or
interface sub-layer in the managed system.
• It is recommended that values are assigned
contiguously starting from 1.
• The value for each interface sub- layer must remain
constant at least from one re-initialization of the entity's
network management system to the next reinitialization."
SYNTAX
Integer32 (1..2147483647)
25
RFC 2233: tabella ifTable: oggetti colonna
ifType OBJECT-TYPE
SYNTAX
IANAifType
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"The type of interface.
 Additional values for ifType are assigned by the Internet
Assigned Numbers Authority (IANA), through updating the
syntax of the IANAifType textual convention."
::= { ifEntry 3 }
26
IANAifType-MIB
•
non e' (piu') un RFC
•
e' un modulo MIB scaricabile dal sito della Internet Assigned
Numbers Authority (IANA)
•
definisce la textual-convention IANAifType che enumera tutti i tipi
possibili di interfaccia
•
in particolare definisce diversi valori di ifType per indicare reti di tipo
Ethernet (CSMA/CD)
• ethernetCsmacd(6),
• iso88023Csmacd(7),
• starLan(11), obsoleto
• ieee80212(55),
-- 100BaseVG
• fastEther(62),
-- Fast Ethernet (100BaseT)
• fastEtherFX(69), -- Fast Ethernet (100BaseFX)
• gigabitEthernet (117), -- Gigabit Ethernet
anche se RFC 2665 raccomanda che venga utilizzato il tipo
ethernetCsmacd(6) indipendentemente dal tipo particolare di
Ethernet
27
IANAifType-MIB
IANAifType-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2
TEXTUAL-CONVENTION
FROM SNMPv2-SMI
FROM SNMPv2-TC;
ianaifType MODULE-IDENTITY
LAST-UPDATED "200105110000Z" -- May 11, 2001
ORGANIZATION "IANA"
CONTACT-INFO "
Internet Assigned Numbers Authority
Postal: ICANN
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
Tel: +1 310 823 9358
E-Mail: [email protected]"
DESCRIPTION
"This MIB module defines the IANAifType Textual Convention, and thus the
enumerated values of the ifType object defined in MIB-II's ifTable."
REVISION "200105110000Z" -- May 11, 2001
DESCRIPTION "Registration of new IANAifType 197."
…
28
IANAifType-MIB
REVISION "200004250000Z" -- Apr 25, 2000
DESCRIPTION "Registration of new IANAifTypes 168 and 169."
REVISION "200003060000Z" -- Mar 6, 2000
DESCRIPTION
"Fixed a missing semi-colon in the IMPORT. Also cleaned up the REVISION log a
bit. It is not complete, but from now on it will be maintained and kept up to date with
each change to this MIB module."
REVISION "199910081430Z" -- Oct 08, 1999
DESCRIPTION
"Include new name assignments up to cnr(85).
This is the first version available via the WWW at:
ftp://ftp.isi.edu/mib/ianaiftype.mib"
REVISION "199401310000Z" -- Jan 31, 1994
DESCRIPTION "Initial version of this MIB as published in RFC 1573."
::= { mib-2 30 }
29
IANAifType-MIB
IANAifType ::= TEXTUAL-CONVENTION
STATUS
current
DESCRIPTION
"This data type is used as the syntax of the ifType object in the (updated)
definition of MIB-II's ifTable.
The definition of this textual convention with the addition of newly
assigned values is published periodically by the IANA, in either the
Assigned Numbers RFC, or some derivative of it specific to Internet
Network Management number assignments. (The latest arrangements
can be obtained by contacting the IANA.)
Requests for new values should be made to IANA via email
([email protected]).
The relationship between the assignment of ifType values and of OIDs to
particular media-specific MIBs is solely the purview of IANA and is subject
to change without notice. Quite often, a media-specific MIB's OIDsubtree assignment within MIB-II's 'transmission' subtree will be the same
as its ifType value. However, in some circumstances this will not be the
case, and implementors must not pre-assume any specific relationship
between ifType values and transmission subtree OIDs."
-- continua alla prossima pagina
30
IANAifType-MIB
SYNTAX INTEGER {
other(1),
-- none of the following
…
ddnX25(4),
rfc877x25(5),
ethernetCsmacd(6),
iso88023Csmacd(7),
iso88024TokenBus(8),
iso88025TokenRing(9),
iso88026Man(10),
…
hyperchannel(14),
fddi(15),
lapb(16),
sdlc(17),
ds1(18),
-- DS1-MIB
e1(19),
-- Obsolete see DS1-MIB
basicISDN(20),
primaryISDN(21),
propPointToPointSerial(22), -- proprietary serial
ppp(23),
softwareLoopback(24),
31
IANAifType-MIB
…
slip(28),
-- generic SLIP
…
ds3(30),
-- DS3-MIB
…
frameRelay(32), -- DTE only.
rs232(33),
para(34),
-- parallel-port
…
atm(37),
-- ATM cells
…
sonet(39),
-- SONET or SDH
…
iso88022llc(41),
…
frameRelayService(44), -- FRNETSERV-MIB
v35(45),
…
modem(48),
-- Generic modem
…
ieee80212(55),
-- 100BaseVG
…
32
IANAifType-MIB
frameRelayInterconnect(58), -- Obsolete use either
-- frameRelay(32) or
-- frameRelayService(44)
…
fastEther(62),
-- Fast Ethernet (100BaseT)
…
v11(64),
-- CCITT V.11/X.21
v36(65),
-- CCITT V.36
g703at64k(66),
-- CCITT G703 at 64Kbps
g703at2mb(67),
-- Obsolete see DS1-MIB
…
fastEtherFX(69), -- Fast Ethernet (100BaseFX)
…
ieee80211(71),
-- radio spread spectrum
…
lapd(77),
-- Link Access Protocol D
…
ds0(81),
-- Digital Signal Level 0
ds0Bundle(82),
-- group of ds0s on the same ds1
bsc(83),
-- Bisynchronous Protocol
…
33
IANAifType-MIB
adsl(94),
-- Asymmetric Digital Subscriber Loop
...
sdsl(96),
-- Symmetric Digital Subscriber Loop
vdsl(97),
-- Very H-Speed Digital Subscrib. Loop
…
gigabitEthernet (117), -- Gigabit Ethernet
hdlc (118),
-- HDLC
…
mplsTunnel (150), -- MPLS Tunnel Virtual Interface
…
mpls (166), -- MPLS
…
pos (171), -- Packet over SONET/SDH Interface
…
plc (174), -- Power Line Communtications
…
opticalChannel (195), -- Optical Channel
opticalTransport (196), -- Optical Transport
…
}
END
34
RFC 2233: The Interfaces Group MIB using SMIv2
da RFC 2233: Eterogeneita' delle interfacce
•
About half the objects in the ifTable are applicable to every type of
interface: packet-oriented, character-oriented, and bit-oriented.
•
Of the other half, two are applicable to both character-oriented and
packet-oriented interfaces, and the rest are applicable only to
packet-oriented interfaces.
•
Thus, while it is desirable for consistency to be able to represent
any/all types of interfaces in the ifTable, it is not possible to
implement the full ifTable for bit- and character-oriented sub-layers.
35
RFC 2233: The Interfaces Group MIB using SMIv2
da RFC 2233: Eterogeneita' delle interfacce
•
The solution adopted builds upon the fact that compliance
statements in SNMPv2 refer to object groups, where object groups
are explicitly defined by listing the objects they contain.
•
Thus multiple compliance statements can be specified, one for all
interfaces and additional ones for specific types of interfaces.
•
The separate compliance statements can be based on separate
object groups, where the object group for all interfaces can contain
only those objects from the ifTable which are appropriate for every
type of interfaces.
•
Using this solution, every sub-layer can have its own conceptual
row in the ifTable.
36
RFC 2233: gruppi di conformita' non ifType-specifici
ifGeneralInformationGroup OBJECT-GROUP
OBJECTS { ifIndex, ifDescr, ifType, ifSpeed, ifPhysAddress,
ifAdminStatus, ifOperStatus, ifLastChange,
ifLinkUpDownTrapEnable, ifConnectorPresent,
ifHighSpeed, ifName, ifNumber, ifAlias,
ifTableLastChange }
STATUS current
DESCRIPTION
"A collection of objects providing information applicable to all network
interfaces."
::= { ifGroups 10 }
ifCounterDiscontinuityGroup OBJECT-GROUP
OBJECTS { ifCounterDiscontinuityTime }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to interface counter
discontinuities."
::= { ifGroups 13 }
37
RFC 2233: gruppi di conformita' ifType-specifici
•
sono definiti 5 gruppi di contatori (misure di performance)
mutuamente esclusivi tra di loro
•
per ogni interfaccia, in base al suo tipo, uno e uno solo di questi
gruppi e' significativo e deve essere implementato
•
uno stesso contatore puo' comparire in diversi gruppi (essere
significativo per diversi tipi di interfacce)
•
i 5 gruppi sono:
•
ifFixedLengthGroup
•
ifHCFixedLengthGroup
•
ifPacketGroup
•
ifHCPacketGroup
•
ifVHCPacketGroup
38
RFC 2233: gruppi di conformita' ifType-specifici
ifFixedLengthGroup OBJECT-GROUP
OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos, ifInErrors, ifOutErrors }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to non-high speed
(non-high speed interfaces transmit and receive at speeds less than or
equal to 20,000,000 bits/second) character-oriented or fixed-lengthtransmission network interfaces."
::= { ifGroups 2 }
ifHCFixedLengthGroup OBJECT-GROUP
OBJECTS { ifHCInOctets, ifHCOutOctets, ifInOctets,
ifOutOctets, ifInUnknownProtos, ifInErrors, ifOutErrors }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to high speed (greater
than 20,000,000 bits/second) character-oriented or fixed-lengthtransmission network interfaces."
::= { ifGroups 3 }
39
RFC 2233: gruppi di conformita' ifType-specifici
ifPacketGroup OBJECT-GROUP
OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos, ifInErrors, ifOutErrors,
ifMtu, ifInUcastPkts, ifInMulticastPkts, ifInBroadcastPkts,
ifInDiscards, ifOutUcastPkts, ifOutMulticastPkts,
ifOutBroadcastPkts, ifOutDiscards, ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to non-high speed
(non-high speed interfaces transmit and receive at speeds less than or
equal to 20,000,000 bits/second) packet-oriented network interfaces."
::= { ifGroups 4 }
40
RFC 2233: gruppi di conformita' ifType-specifici
ifHCPacketGroup OBJECT-GROUP
OBJECTS { ifHCInOctets, ifHCOutOctets, ifInOctets, ifOutOctets,
ifInUnknownProtos, ifInErrors, ifOutErrors, ifMtu, ifInUcastPkts,
ifInMulticastPkts, ifInBroadcastPkts, ifInDiscards, ifOutUcastPkts,
ifOutMulticastPkts, ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to high speed
(greater than 20,000,000 bits/second but less than or equal to
650,000,000 bits/second) packet-oriented network interfaces."
::= { ifGroups 5 }
41
RFC 2233: gruppi di conformita' ifType-specifici
ifVHCPacketGroup OBJECT-GROUP
OBJECTS { ifHCInUcastPkts, ifHCInMulticastPkts, ifHCInBroadcastPkts,
ifHCOutUcastPkts, ifHCOutMulticastPkts, ifHCOutBroadcastPkts,
ifHCInOctets, ifHCOutOctets, ifInOctets, ifOutOctets,
ifInUnknownProtos, ifInErrors, ifOutErrors, ifMtu, ifInUcastPkts,
ifInMulticastPkts, ifInBroadcastPkts, ifInDiscards,
ifOutUcastPkts, ifOutMulticastPkts, ifOutBroadcastPkts,
ifOutDiscards, ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to higher speed
(greater than 650,000,000 bits/second) packet-oriented network
interfaces."
::= { ifGroups 6 }
42
RFC 2233: estensione ifType-specifica di ifTable
ifSpecific OBJECT-TYPE
-- oggetto colonna di ifTable
SYNTAX
OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS
deprecated
DESCRIPTION
"A reference to MIB definitions specific to the particular media being
used to realize the interface.
...
If no MIB definitions specific to the particular media are available, the value
should be set to the OBJECT IDENTIFIER { 0 0 }."
::= { ifEntry 22 }
 In realta' RFC 2233 indica che:
• The only definition that can both be made explicit and can cover
all the useful situations is to have ifSpecific be the OBJECT
IDENTIFIER that defines the media-specific MIB.
• This effectively makes it redundant because it contains no more
information than is provided by ifType.
• Thus, ifSpecific has been deprecated.
43
RFC 2233: tabella ifTable: oggetti colonna
ifDescr OBJECT-TYPE
SYNTAX
DisplayString (SIZE (0..255))
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"A textual string containing information about the interface.
This string should include
• the name of the manufacturer,
• the product name and
• the version of the interface hardware/software."
::= { ifEntry 2 }
44
RFC 2233: tabella ifTable: oggetti colonna
ifMtu OBJECT-TYPE
SYNTAX
Integer32
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"The size of the largest packet which can be sent/received on the
interface, specified in octets.
 For interfaces that are used for transmitting network
datagrams, this is the size of the largest network datagram that
can be sent on the interface."
::= { ifEntry 4 }
45
RFC 2233: tabella ifTable: oggetti colonna
ifSpeed OBJECT-TYPE
SYNTAX
Gauge32
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"An estimate of the interface's current bandwidth in bits per second.
• For interfaces which do not vary in bandwidth or for those
where no accurate estimation can be made, this object should
contain the nominal bandwidth.
• If the bandwidth of the interface is greater than the maximum
value reportable by this object then this object should report its
maximum value (4,294,967,295) and ifHighSpeed must be used
to report the interace's speed.
• For a sub-layer which has no concept of bandwidth, this object
should be zero."
::= { ifEntry 5 }
46
RFC 2233: tabella ifXTable: oggetti colonna
ifHighSpeed OBJECT-TYPE
SYNTAX
Gauge32
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"An estimate of the interface's current bandwidth in units of
1,000,000 bits per second.
• If this object reports a value of 'n' then the speed of the interface
is somewhere in the range of `n-500,000' to `n+499,999'.
• For interfaces which do not vary in bandwidth or for those
where no accurate estimation can be made, this object should
contain the nominal bandwidth.
• For a sub-layer which has no concept of bandwidth, this object
should be zero."
::= { ifXEntry 15 }
47
RFC 2233: tabella ifTable: oggetti colonna
ifPhysAddress OBJECT-TYPE
SYNTAX
PhysAddress
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"The interface's address at its protocol sub-layer.
 For example, for an 802.x interface, this object normally
contains a MAC address.
• The interface's media-specific MIB must define the bit and byte
ordering and the format of the value of this object.
• For interfaces which do not have such an address (e.g., a serial
line), this object should contain an octet string of zero length."
::= { ifEntry 6 }
48
RFC 2233: tabella ifTable: oggetti colonna
ifAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1),
-- ready to pass packets
down(2),
testing(3) -- in some test mode
}
MAX-ACCESS read-write
STATUS
current
DESCRIPTION
"The desired state of the interface.
• The testing(3) state indicates that no operational packets can be passed.
• When a managed system initializes, all interfaces start with
ifAdminStatus in the down(2) state.
• As a result of either explicit management action or per
configuration information retained by the managed system,
ifAdminStatus is then changed to either the up(1) or testing(3)
states (or remains in the down(2) state)."
::= { ifEntry 7 }
49
RFC 2233: tabella ifTable: oggetti colonna
ifOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1),
down(2),
testing(3),
unknown(4),
dormant(5),
notPresent(6),
lowerLayerDown(7)
-- ready to pass packets
-- in some test mode
-- status can not be determined
-- for some reason.
-- some component is missing
-- down due to state of
-- lower-layer interface(s)
}
MAX-ACCESS read-only
STATUS
current
-- DESCRIPTION ...
-- vedi prossima pagina
50
RFC 2233: tabella ifTable: oggetti colonna
-- ifOperStatus OBJECT-TYPE: continua da pagina precedente
DESCRIPTION
"The current operational state of the interface.
• The testing(3) state indicates that no operational packets can be
passed.
• If ifAdminStatus is down(2) then ifOperStatus should be down(2).
• If ifAdminStatus is changed to up(1) then
• ifOperStatus should change to up(1) if the interface is ready to
transmit and receive network traffic;
• it should change to dormant(5) if the interface is waiting for
external actions (such as a serial line waiting for an incoming
connection);
• it should remain in the down(2) state if and only if there is a
fault that prevents it from going to the up(1) state;
• it should remain in the notPresent(6) state if the interface has
missing (typically, hardware) components."
::= { ifEntry 8 }
51
RFC 2233: tabella ifTable: oggetti colonna
ifLastChange OBJECT-TYPE
SYNTAX
TimeTicks
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"The value of sysUpTime at the time the interface entered its current
operational state.
• If the current state was entered prior to the last re-initialization
of the local network management subsystem, then this object
contains a zero value."
::= { ifEntry 9 }
52
RFC 2233: The Interfaces Group MIB using SMIv2
da RFC 2233: Notifiche spontanee
 Operational experience indicates that management stations are
most concerned with an interface being in the down state and
the fact that this state may indicate a failure.
•
Instrumenting transitions into or out of the down state (to/from all
other states except notPresent) has the advantages:
• A transition into the down state (from a state other than
notPresent) will occur when an error is detected on an
interface. Error conditions are presumably of great interest to
network managers.
• Departing the down state (to a state other than the notPresent
state) generally indicates that the interface is going to either
up or dormant, both of which are considered "healthy" states.
•
Transitions to/from the notPresent state are concerned with the
insertion and removal of hardware, and are outside the scope of
these traps.
53
RFC 2233: The Interfaces Group MIB using SMIv2
da RFC 2233: Notifiche spontanee
•
LinkUp and linkDown traps are generated on just after
ifOperStatus leaves, or just before it enters, the down state,
respectively; except that LinkUp and linkDown traps never
generated on transitions to/from the notPresent state.
•
An exception to the above generation of linkUp/linkDown traps on
changes in ifOperStatus, occurs when an interface is "flapping",
i.e., when it is rapidly oscillating between the up and down states.
If traps were generated for each such oscillation, the network and
the network management system would be flooded with
unnecessary traps. In such a situation, the agent should rate-limit
its generation of traps.
54
RFC 2233: notifiche
linkDown NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION "
• A linkDown trap signifies that the SNMPv2 entity, acting in an
agent role, has detected that the ifOperStatus object for one of
its communication links is about to enter the down state from
some other state (but not from the notPresent state).
• This other state is indicated by the included value of
ifOperStatus."
::= { snmpTraps 3 }
 notare che il valore comunicato di ifOperStatus e' quello dell'istante
in cui viene teoricamente generata la notifica
55
RFC 2233: notifiche
linkUp NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION "
• A linkDown trap signifies that the SNMPv2 entity, acting in an
agent role, has detected that the ifOperStatus object for one of
its communication links left the down state and transitioned into
some other state (but not into the notPresent state).
• This other state is indicated by the included value of
ifOperStatus."
::= { snmpTraps 4 }
notare che il valore comunicato di ifOperStatus e' quello dell'istante in
cui viene teoricamente generata la notifica
56
RFC 2233: The Interfaces Group MIB using SMIv2
da RFC 2233: Controllo delle notifiche spontanee
•
In the multi-layer interface model, each sub-layer for which there is
an entry in the ifTable can generate linkUp/Down Traps.
 Since interface state changes would tend to propagate
through the interface (from top to bottom, or bottom to top), it
is likely that several traps would be generated for each
linkUp/Down occurrence.
•
It is desirable to provide a mechanism for manager stations to
control the generation of these traps.
 To this end, the ifLinkUpDownTrapEnable object has been
added.
 This object allows managers to limit generation of traps to just
the sub-layers of interest.
57
Propagazione degli allarmi
•
Si distingue tra guasti primari e guasti secondari (o indotti)
•
Esempio: rete SDH
• se stacco un cavo ho un guasto di LOS sul livello fisico
• verso i livelli superiori il livello fisico propaga un segnale di AIS
che quando rilevato e' anch'esso considerato una condizione
anomala (secondaria)
•
In una rete si possono distinguere due tipi di propagazione dei
guasti:
• locale al nodo su cui e' rilevato anche il guasto primario
•
condizione anomala di SSF (Server Signal Fail)
•
politiche locali di soppressione dei defect secondari
(AIS)
• remota: se del caso, la notifica di defect secondari deve
essere soppressa esplicitamente
58
RFC 2233: The Interfaces Group MIB using SMIv2
da RFC 2233: Controllo delle notifiche spontanee
•
The default setting should limit the number of traps generated to
one per interface per linkUp/Down event.
•
Furthermore, it seems that the state changes of most interest to
network managers occur at the lowest level of an interface stack
(e.g. layer fisico OSI).
 Therefore we specify that by default, only the lowest sub-layer
of the interface generate traps.
N.B.:
•
•
•
quanto detto e' vero per quanto riguarda l'individuazione dei guasti primari.
in realta', dal punto di vista dei servizi applicativi e' opportuna la
generazione di eventi di up/down a livello end-to-end, quindi a livello piu'
alto di quello fisico o anche IP (e.g. layer di trasporto).
Poiche' le interfacce di cui si parla sono di livello inferiore al layer IP una
notifica di linkUp/Down che le riguardi non puo' comunque riguardare una
diagnosi end-to-end
59
RFC 2233: tabella ifXTable: oggetti colonna
ifLinkUpDownTrapEnable OBJECT-TYPE
SYNTAX
INTEGER { enabled(1), disabled(2) }
MAX-ACCESS read-write
STATUS
current
DESCRIPTION
"Indicates whether linkUp/linkDown traps should be generated for
this interface.
 By default, this object should have the value
• enabled(1) for interfaces which do not operate on 'top' of
any other interface (as defined in the ifStackTable), and
• disabled(2) otherwise."
::= { ifXEntry 14 }
60
RFC 2233: tabella ifXTable: oggetti colonna
ifName OBJECT-TYPE
SYNTAX
DisplayString
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"The textual name of the interface.
• The value of this object should be the name of the interface as assigned
by the local device and should be suitable for use in commands entered
at the device's 'console'. This might be a text name, such as 'le0' or a
simple port number, such as '1', depending on the interface naming
syntax of the device.
• If several entries in the ifTable together represent a single interface as
named by the device, then each will have the same value of ifName.
• Note that for an agent which responds to SNMP queries concerning an
interface on some other (proxied) device, then the value of ifName for
such an interface is the proxied device's local name for it.
• If there is no local name, or this object is otherwise not applicable, then
this object contains a zero-length string."
::= { ifXEntry 1 }
61
RFC 2233: tabella ifXTable: oggetti colonna
ifAlias OBJECT-TYPE
SYNTAX
DisplayString (SIZE(0..64))
MAX-ACCESS read-write
STATUS
current
DESCRIPTION
"This object is an 'alias' name for the interface as specified by a network manager,
and provides a non-volatile 'handle' for the interface.
• On the first instantiation of an interface, the value of ifAlias associated with that
interface is the zero-length string.
• As and when a value is written into an instance of ifAlias through a network
management set operation, then the agent must retain the supplied value in the
ifAlias instance associated with the same interface for as long as that interface
remains instantiated, including across all re-initializations/reboots of the network
management system, including those which result in a change of the interface's
ifIndex value.
• An example of the value which a network manager might store in this object for
a WAN interface is the (Telco's) circuit number/identifier of the interface.
• Some agents may support write-access only for interfaces having particular
values of ifType. An agent which supports write access to this object is required
to keep the value in non-volatile storage, but it may limit the length of new
values depending on how much storage is already occupied by the current
values for other interfaces."
::= { ifXEntry 18 }
62
RFC 2233: tabella ifXTable: oggetti colonna
ifConnectorPresent OBJECT-TYPE
SYNTAX
TruthValue
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"This object has the value 'true(1)' if the interface sublayer has a
physical connector and the value 'false(2)' otherwise."
::= { ifXEntry 17 }
63
RFC 2233: tabella ifXTable: oggetti colonna
ifPromiscuousMode OBJECT-TYPE
SYNTAX
TruthValue
MAX-ACCESS read-write
STATUS
current
DESCRIPTION
"This object has a value of false(2) if this interface only accepts
packets/frames that are addressed to this station.
This object has a value of true(1) when the station accepts all
packets/frames transmitted on the media.
• The value true(1) is only legal on certain types of media. If
legal, setting this object to a value of true(1) may require the
interface to be reset before becoming effective.
• The value of ifPromiscuousMode does not affect the reception
of broadcast and multicast packets/frames by the interface."
::= { ifXEntry 16 }
64
RFC 2233: tabella ifXTable: oggetti colonna
ifInErrors OBJECT-TYPE
SYNTAX
Counter32
MAX-ACCESS read-only
STATUS
current
DESCRIPTION "
• For packet-oriented interfaces, the number of inbound packets
that contained errors preventing them from being deliverable to a
higher-layer protocol.
• For character-oriented or fixed-length interfaces, the number of
inbound transmission units that contained errors preventing them
from being deliverable to a higher-layer protocol.
• 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."
::= { ifEntry 14 }
65
RFC 2233: tabella ifXTable: oggetti colonna
ifCounterDiscontinuityTime OBJECT-TYPE
SYNTAX
TimeStamp
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"The value of sysUpTime on the most recent occasion at which any
one or more of this interface's counters suffered a discontinuity.
• The relevant counters are the specific instances associated
with this interface of any Counter32 or Counter64 object
contained in the ifTable or ifXTable.
• If no such discontinuities have occurred since the last reinitialization of the local management subsystem, then this
object contains a zero value."
::= { ifXEntry 19 }
66
RFC 2233: The Interfaces Group MIB using SMIv2
da RFC 2233: Interface Sub-Layers
•
Experience in defining media-specific management information
has shown the need to distinguish between the multiple sub-layers
beneath the internetwork-layer.
•
In addition, there is a need to manage these sub-layers in devices
(e.g., MAC-layer bridges) which are unaware of which, if any,
internetwork protocols run over these sub-layers.
•
As such, a model of having a single conceptual row in the
interfaces table (MIB-II's ifTable) represent a whole interface
underneath the internetwork-layer, and having a single associated
media-specific MIB module is too simplistic.
•
… have an individual conceptual row in the ifTable to represent
each sub-layer, and have a new separate MIB table (the
ifStackTable) to identify the "superior" and "subordinate" sublayers through INTEGER "pointers" to the appropriate conceptual
rows in the ifTable.
67
Interface Sub-Layers: esempi
• Le sottoreti Ethernet/IEEE 802.3 che si vedranno in seguito
possono venire convenientemenet modellizzate attraverso la
combinazione di 4 diversi layer.
 In realta' esiste anche la possibilita' che un sub-layer operi
come un multiplexer per diverse istanze del layer sottostante
• Una sottorete X.25 inserita in un contesto di inter-rete IP e'
composta di 4 sublayer (dall'alto):
• Sub-Network Dependent Convergence, che si occupa di
fornire al layer IP una interfaccia omogenea a tutte le altre
• Layer di rete (PLP)
• Data Link Layer (LAPB)
• Layer Fisico
 In realta' esiste anche la possibilita' che un sub-layer (quello di
rete PLP) operi come un multiplexer per diverse istanze del
layer sottostante
68
RFC 2233: tabella ifStackTable
ifStackTable OBJECT-TYPE
SYNTAX
SEQUENCE OF IfStackEntry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION
"The table containing information on the relationships between the multiple
sub-layers of network interfaces. In particular, it contains information on
which sub-layers run 'on top of' which other sub-layers, where each sublayer corresponds to a conceptual row in the ifTable.
• For example, when the sub-layer with ifIndex value x runs over the
sub-layer with ifIndex value y, then this table contains:
ifStackStatus.x.y=active
• For each ifIndex value, I, which identifies an active interface, there are
always at least two instantiated rows in this table associated with I.
• For one of these rows, I is the value of ifStackHigherLayer;
• for the other, I is the value of ifStackLowerLayer.
(If I is not involved in multiplexing, then these are the only two rows associated
with I.)
• Two rows exist even for an interface which has no others stacked on
top or below it:: ifStackStatus.0.x=active && ifStackStatus.x.0=active ."
::= { ifMIBObjects 2 }
69
RFC 2233: tabella ifStackTable
ifStackEntry OBJECT-TYPE
SYNTAX
IfStackEntry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION
"Information on a particular relationship between two sub-layers,
specifying that one sub-layer runs on 'top' of the other sub-layer.
Each sub-layer corresponds to a conceptual row in the ifTable."
INDEX { ifStackHigherLayer, ifStackLowerLayer }
::= { ifStackTable 1 }
IfStackEntry ::=
SEQUENCE {
ifStackHigherLayer
ifStackLowerLayer
ifStackStatus
}
Integer32,
Integer32,
RowStatus
70
RFC 2233: tabella ifStackTable: oggetti colonna
ifStackHigherLayer OBJECT-TYPE
SYNTAX
Integer32
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION
"The value of ifIndex corresponding to the higher sub-layer of the
relationship,
• i.e., the sub-layer which runs on 'top' of the sub-layer
identified by the corresponding instance of ifStackLowerLayer.
 If there is no higher sub-layer (below the internetwork layer),
then this object has the value 0."
::= { ifStackEntry 1 }
 Notare che questo oggetto non e' di per se stesso accessibile :
il suo valore e' deducibile dal nome dell'oggetto ifStackStatus della
stessa riga
71
RFC 2233: tabella ifStackTable: oggetti colonna
ifStackLowerLayer OBJECT-TYPE
SYNTAX
Integer32
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION
"The value of ifIndex corresponding to the lower sub-layer of the
relationship,
• i.e., the sub-layer which runs 'below' the sub-layer identified
by the corresponding instance of ifStackHigherLayer.
 If there is no lower sub-layer, then this object has the value 0."
::= { ifStackEntry 2 }
 Notare che questo oggetto non e' di per se stesso accessibile :
il suo valore e' deducibile dal nome dell'oggetto ifStackStatus della
stessa riga
72
RFC 2233: tabella ifStackTable: oggetti colonna
ifStackStatus OBJECT-TYPE
SYNTAX
RowStatus
MAX-ACCESS read-create
STATUS
current
DESCRIPTION
"The status of the relationship between two sub-layers.
• Changing the value of this object from 'active' to 'notInService'
or 'destroy' will likely have consequences up and down the
interface stack.
• Thus, write access to this object is likely to be inappropriate for
some types of interfaces, and many implementations will
choose not to support write-access for any type of interface."
::= { ifStackEntry 3 }
73
RFC 2233: oggetti semplici
ifStackLastChange OBJECT-TYPE
SYNTAX
TimeTicks
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"The value of sysUpTime at the time of the last change of the
(whole) interface stack.
• A change of the interface stack is defined to be any creation,
deletion, or change in value of any instance of ifStackStatus.
• If the interface stack has been unchanged since the last reinitialization of the local network management subsystem, then
this object contains a zero value."
::= { ifMIBObjects 6 }
74
RFC 2233: tabella ifRcvAddressTable
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 }
75
RFC 2233: tabella ifRcvAddressTable
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 }
-- N.B.: ifRcvAddressAddress non e' IMPLIED
::= { ifRcvAddressTable 1 }
IfRcvAddressEntry ::=
SEQUENCE {
ifRcvAddressAddress PhysAddress,
ifRcvAddressStatus RowStatus,
ifRcvAddressType
INTEGER
}
76
RFC 2233: tabella ifRcvAddressTable
notare che:
•
l'object-type ifIndex non e' una colonna della tabella!
•
Non e' possibile utilizzare la clausola AUGMENTS { ifEntry }
perche' ci possono essere piu' righe di ifRcvAddressTable associate
ad una unica riga di ifTable
•
infatti ci possono essere
• piu' indirizzi diversi attivi su una stessa interfaccia
• piu' indirizzi uguali attivi su interfacce diverse
•
l'univocita' dell'indiciamento e l'informazione di associazione
interfaccia-indirizzo sono date indiciando le righe della tabella sia
con ifIndex che con ifRcvAddressAddress
•
ifRcvAddressAddress stesso non e’ accessibile esplicitamente ma
solo tramite il suo uso in quanto indice, cioe’ come (ultimo) suffisso
del nome OBJECT IDENTIFIER degli oggetti della tabella
effettivamente accessibili
77
RFC 2233: tabella ifRcvAddressTable: oggetti colonna
ifRcvAddressAddress OBJECT-TYPE
SYNTAX
PhysAddress
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION
"An address for which the system will accept packets/frames on
this entry's interface."
::= { ifRcvAddressEntry 1 }
ifRcvAddressStatus OBJECT-TYPE
SYNTAX
RowStatus
MAX-ACCESS read-create
STATUS
current
DESCRIPTION
"This object is used to create and delete rows in the
ifRcvAddressTable."
::= { ifRcvAddressEntry 2 }
78
RFC 2233: tabella ifRcvAddressTable: oggetti colonna
ifRcvAddressType OBJECT-TYPE
SYNTAX
INTEGER { other(1),
volatile(2),
nonVolatile(3) }
MAX-ACCESS read-create
STATUS
current
DESCRIPTION "
• This object has the value nonVolatile(3) for those entries in the
table which are valid and will not be deleted by the next restart of
the managed system.
• Entries having the value volatile(2) are valid and exist, but have
not been saved, so that will not exist after the next restart of the
managed system.
• Entries having the value other(1) are valid and exist but are not
classified as to whether they will continue to exist after the next
restart."
DEFVAL { volatile }
::= { ifRcvAddressEntry 3 }
79
RFC 2233: gruppi di conformita'
ifStackGroup2 OBJECT-GROUP
OBJECTS { ifStackStatus, ifStackLastChange }
STATUS current
DESCRIPTION
"A collection of objects providing information on the
layering of MIB-II interfaces."
::= { ifGroups 11 }
ifRcvAddressGroup OBJECT-GROUP
OBJECTS { ifRcvAddressStatus, ifRcvAddressType }
STATUS current
DESCRIPTION
"A collection of objects providing information on the
multiple addresses which an interface receives."
::= { ifGroups 7 }
 N.B.: sono citati solo oggetti con MAX-ACCESS diverso da notaccessible
80
RFC 2233: module compliance
1
ifCompliance2 MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities which have network
interfaces"
MODULE -- this module
MANDATORY-GROUPS { ifGeneralInformationGroup, ifStackGroup2,
ifCounterDiscontinuityGroup }
GROUP
ifFixedLengthGroup
DESCRIPTION
"This group is mandatory for all network interfaces which are characteroriented or transmit data in fixed-length transmission units."
GROUP
ifHCFixedLengthGroup
DESCRIPTION
"This group is mandatory only for those network interfaces which are
character-oriented or transmit data in fixed-length transmission units,
and for which the value of the corresponding instance of ifSpeed is
greater than 20,000,000 bits/second."
81
RFC 2233: module compliance
GROUP
2
ifPacketGroup
DESCRIPTION
"This group is mandatory for all network interfaces which are
packet-oriented."
GROUP
ifHCPacketGroup
DESCRIPTION
"This group is mandatory only for those network interfaces which
are packet-oriented and for which the value of the corresponding
instance of ifSpeed is greater than 650,000,000 bits/second."
GROUP
ifRcvAddressGroup
DESCRIPTION
"The applicability of this group MUST be defined by the mediaspecific MIBs.
Media-specific MIBs must define the exact meaning, use, and
semantics of the addresses in this group."
82
RFC 2233: module compliance
OBJECT
3
ifLinkUpDownTrapEnable
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT
ifPromiscuousMode
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT
ifStackStatus
SYNTAX
INTEGER { active(1) } -- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one of the six
enumerated values for the RowStatus textual convention
need be supported, specifically: active(1)."
-- sostanzialmente ci dice che non e' necessario supportare lo stato
-- notInService. Infatti, lo stato notReady in questo caso non ha
-- alcun senso (esercizio: spiegare il perche')
83
RFC 2233: module compliance
OBJECT
4
ifAdminStatus
SYNTAX
INTEGER { up(1), down(2) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required,
nor is support for the value testing(3)."
OBJECT
ifAlias
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { ifCompliances 2 }
84
RFC 2233: The Interfaces Group MIB using SMIv2
Test
•
Il supporto della gestione di test sulle interfacce e' definito come
opzionale in RFC 2233.
•
In realta' la tabella ifTestTable che modella questa funzionalita' ha
STATUS deprecated, e tutto quanto riferito ai test in precedenti
versioni del documento e' stato rimosso
•
tuttavia il testo della MIB dichiara in un commento:
-- The Interface Test Table
--- This group of objects is optional. However, a media-specific
-- MIB may make implementation of this group mandatory.
•
In questo momento e' in via di sviluppo una nuova MIB per il
supporto del Test Management: questa nuova MIB dovrebbe
rendere definitivamente obsoleta la ifTestTable di ifMIB
85
MIB per tipi specifici di interfaccia
•
Da RFC 2233:
The 'interfaces' group provides the means for additional managed
objects specific to particular types of network interface (e.g., a
specific medium such as Ethernet) to be defined as extensions to
the 'interfaces' group for media-specific management.
•
RFC 2233 specifica anche le linee guida che devono essere seguite
nella definizione di MIB per interfacce specifiche. Tra le altre cose
viene richiesto alla MIB specifica di
•
indicare a quale/i valori di ifType si applica
•
indicare se per il tipo di interfaccia supportato e' significativo
l'uso della ifRcvAddressTable
•
indicare il modello di layering per quel tipo di interfaccia
•
chiarire le possibili ambiguita' semantiche presenti nella
definizione nella MIB generica delle interfacce
86
RFC 2665: MIB for Ethernet-like Interface Types
•
Questa MIB modella (e' applicabile a) tutti i tipi di interfacce Ethernetlike (o IEEE 802.3 e derivati-like):
• da 3Mb/s a 1 Gb/s
• con funzionamento half-duplex o full-duplex
•
La sua relazione con la MIB generica delle interfacce e' definita
esplicitamente (come prescritto da RFC 2233) nella sez. 3.2 dell'RFC
•
sez. 3.2.1 definisce che le interfacce Ethernet non sono layerizzate (il
sub-layer di MAC-control, in particolare, anche se modellato
esplicitamente non viene rappresentato tramite una riga della tabella
delle interfacce)
•
RFC 2665 lascia tuttavia aperta la strada alla introduzione di sublayer in caso di disponibilita' di MIB per IEEE 802.2 (LLC) e
transceivers.
• Da RFC 2665: "One could foresee the development of an 802.2
and enet-transceiver MIB. They could be higher and lower
sublayers, respectively."
• La MIB per i MAU IEEE 802.3 e' disponibile (RFC 2668)
87
RFC 2665: MIB for Ethernet-like Interface Types
 Struttura layerizzata di una sottorete IEEE 802
LLC
MAC CONTROL
MAC
normalmente non implementato
opzionale
Gestiti da
RFC 2665
Physical
MAU
88
RFC 2665: MIB for Ethernet-like Interface Types
•
sez. 3.2.4 definisce la necessita' da parte delle interfacce Ethernetlike di utilizzare la tabella ifRcvAddressTable di ifMIB
• infatti una interfaccia Ethernet puo' ricevere frame sulla base
di uno o piu' indirizzi individuali, multicat, broadcast (un solo
indirizzo broadcast)
• quale indirizzo registrare nell'oggetto colonna ifPhysAddress di
ifTable nel caso ci siano piu' indirizzi individuali?
RFC 2665:
 This object contains the IEEE 802.3 address which is
placed in the source-address field of any Ethernet frames
•
•
•
In a system where there are several such addresses the
designer has a tougher choice. The address chosen should be
the one most likely to be of use to network management (e.g.
the address placed in ARP responses for systems which are
primarily IP systems).
If the designer truly can not chose, use of the factory-provided
ROM address is suggested.
If the address can not be determined, an octet string of zero
length should be returned.
89
RFC 2665: MIB for Ethernet-like Interface Types
•
sez. 3.2.7 definisce le linee guida per applicare gli oggetti della MIB
generica delle interfacce ad interfacce Ethernet-like.
•
Notare che il valore dell'oggetto colonna ifMTU di ifTable
dipende dal fatto che l'interfaccia sia utilizzata come pura
Ethernet (secondo IEEE 802 equivalente ad un layer MAC) o
come IEEE 802.2 (LLC)
•
poiche' non esiste una layerizzazione esplicita (non esiste
nemmeno una MIB IEEE 802.2), permane l'ambiguita', che
pero' e' risolta in pratica dal fatto che
•
in realta' una interfaccia Ethernet offre si' un servizio
multiprotocollo (puro Ethernet ma anche MAC layer IEEE
802.3)
•
ma mai di norma un servizio IEEE 802.2 (CL o CO)
90
RFC 2665: MIB for Ethernet-like Interface Types
•
le linee guida per utilizzare l'oggetto ifSpeed della MIB generica
delle interfacce (specifica analoga si applica a ifHighSpeed).
•
"The current operational speed of the interface in bits per second.
•
For current ethernet-like interfaces, this will be equal to 1,000,000 (1
million), 10,000,000 (10 million), 100,000,000 (100 million), or
1,000,000,000 (1 billion).
•
If the interface implements auto-negotiation, auto-negotiation is
enabled for this interface, and the interface has not yet negotiated to
an operational speed, this object SHOULD reflect the maximum
speed supported by the interface.
•
Note that this object MUST NOT indicate a doubled value when
operating in full-duplex mode. It MUST indicate the correct line speed
regardless of the current duplex mode.
•
The duplex mode of the interface may be determined by examining
either the dot3StatsDuplexStatus object in this MIBmodule, or the
ifMauType object in the 802.3 MAU MIB."
91
RFC 2665: MIB for Ethernet-like Interface Types
•
relazione con la MIB MAU
RFC 2665:
•
Support for the mauModIfCompl2 compliance statement of the
MAU-MIB (RFC 2668) is REQUIRED for Ethernet-like
interfaces.
•
This MIB is needed in order to allow applications
•
•
to determine the current MAU type in use by the interface,
and
•
to control autonegotiation and duplex mode for the
interface.
Implementing this MIB module without implementing the MAUMIB would leave applications with no standard way to
determine the media type in use, and no standard way to
control the duplex mode of the interface.
92
RFC 2665: MIB for Ethernet-like Interface Types
transmission =
1.3.6.1.2.1.10
dot3 (7)
dot3StatsTable (2)
dot3StatsEntry (1)
dot3StatsIndex (1)
...
dot3StatsDuplexStatus (19)
dot3CollTable (5)
dot3CollEntry (1)
dot3CollCount (2)
dot3CollFrequencies (3)
dot3ControlTable (5)
dot3ControlEntry (1)
dot3ControlFunctionsSupported (1)
dot3ControlInUnknownOpcodes (2)
dot3PauseTable (10)
dot3PauseEntry (1)
dot3PauseAdminMode (1)
dot3PauseOperMode (2)
...
93
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 }
94
RFC 2665: MIB for Ethernet-like Interface Types
Dot3StatsEntry ::=
SEQUENCE {
dot3StatsIndex
InterfaceIndex,
dot3StatsAlignmentErrors
dot3StatsFCSErrors
dot3StatsSingleCollisionFrames
dot3StatsMultipleCollisionFrames
dot3StatsSQETestErrors
dot3StatsDeferredTransmissions
dot3StatsLateCollisions
dot3StatsExcessiveCollisions
dot3StatsInternalMacTransmitErrors
dot3StatsCarrierSenseErrors
dot3StatsFrameTooLongs
dot3StatsInternalMacReceiveErrors
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
dot3StatsEtherChipSet
OBJECT IDENTIFIER,
dot3StatsSymbolErrors
Counter32,
dot3StatsDuplexStatus
INTEGER
}
95
RFC 2665: MIB for Ethernet-like Interface Types
dot3StatsIndex OBJECT-TYPE
SYNTAX
InterfaceIndex
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"An index value that uniquely identifies an interface to an ethernetlike 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 }
96
RFC 2665: MIB for Ethernet-like Interface Types
dot3StatsEtherChipSet OBJECT-TYPE
SYNTAX
OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS
deprecated
DESCRIPTION "
This object contains an OBJECT IDENTIFIER which identifies the chipset
used to realize the interface.
• Ethernet-like interfaces are typically built out of several different
chips. The MIB implementor is presented with a decision of which
chip to identify via this object.
• The implementor should identify the chip which is usually called the
Medium Access Control chip.
• If no such chip is easily identifiable, the implementor should identify
the chip which actually gathers the transmit and receive statistics
and error indications.
• This would allow a manager station to correlate the statistics and
the chip generating them, giving it the ability to take into account
any known anomalies in the chip."
::= { dot3StatsEntry 17 }
97
RFC 2665: MIB for Ethernet-like Interface Types
dot3StatsDuplexStatus OBJECT-TYPE
SYNTAX
INTEGER { unknown(1), halfDuplex(2), fullDuplex(3) }
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"The current mode of operation of the MAC entity.
•
•
•
•
•
'unknown' indicates that the current duplex mode could not be
determined.
Management control of the duplex mode is accomplished through the
MAU MIB (infatti l'oggetto dot3StatsDuplexStatus ha MAX-ACCESS
read-only).
When an interface does not support autonegotiation, or when
autonegotiation is not enabled, the duplex mode is controlled using
ifMauDefaultType.
When autonegotiation is supported and enabled, duplex mode is
controlled using ifMauAutoNegAdvertisedBits.
In either case, the currently operating duplex mode is reflected both
in this object and in ifMauType. ..."
REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.32, aDuplexStatus."
::= { dot3StatsEntry 19 }
98
RFC 2665: MIB for Ethernet-like Interface Types
dot3StatsDuplexStatus
DESCRIPTION "
-- continua
•
Note that this object provides redundant information with
ifMauType.
•
Normally, redundant objects are discouraged.
•
However, in this instance, it allows a management application
to determine the duplex status of an interface without having
to know every possible value of ifMauType.
•
This was felt to be sufficiently valuable to justify the
redundancy."
99
RFC 2665: MIB for Ethernet-like Interface Types
dot3ControlTable OBJECT-TYPE
SYNTAX
SEQUENCE OF Dot3ControlEntry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION
"A table of descriptive and status information about the MAC
Control sublayer on the ethernet-like interfaces attached to a
particular system.
• There will be one row in this table for each ethernet-like
interface in the system which implements the MAC Control
sublayer.
• If some, but not all, of the ethernet-like interfaces in the
system implement the MAC Control sublayer, there will be
fewer rows in this table than in the dot3StatsTable."
::= { dot3 9 }
100
RFC 2665: MIB for Ethernet-like Interface Types
dot3ControlEntry OBJECT-TYPE
SYNTAX
Dot3ControlEntry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION
"An entry in the table, containing information about the MAC
Control sublayer on a single ethernet-like interface."
INDEX
{ dot3StatsIndex }
-- N.B.: non e' AUGMENTS {dot3StatsEntry }
-- infatti non necessariamente c'e' una riga di dot3ControlTable per
-- ogni riga di dot3StatsTable.
-- pero' si usa la colonna indice di dot3StatsTable anche qui!
::= { dot3ControlTable 1 }
Dot3ControlEntry ::=
SEQUENCE {
dot3ControlFunctionsSupported
dot3ControlInUnknownOpcodes
}
BITS,
Counter32
101
RFC 2665: MIB for Ethernet-like Interface Types
dot3ControlFunctionsSupported OBJECT-TYPE
SYNTAX
BITS { pause(0) } -- 802.3x flow control
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"A list of the possible MAC Control functions implemented for this
interface."
REFERENCE
"[IEEE 802.3 Std.], 30.3.3.2, aMACControlFunctionsSupported."
::= { dot3ControlEntry 1 }
102
RFC 2665: MIB for Ethernet-like Interface Types
dot3PauseTable OBJECT-TYPE
SYNTAX
SEQUENCE OF Dot3PauseEntry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION
"A table of descriptive and status information about the MAC
Control PAUSE function on the ethernet-like interfaces attached to
a particular system.
• There will be one row in this table for each ethernet-like
interface in the system which supports the MAC Control
PAUSE function (i.e., the 'pause' bit in the corresponding
instance of dot3ControlFunctionsSupported is set).
• If some, but not all, of the ethernet-like interfaces in the
system implement the MAC Control PAUSE function (for
example, if some interfaces only support half-duplex), there
will be fewer rows in this table than in the dot3StatsTable."
::= { dot3 10 }
103
RFC 2665: MIB for Ethernet-like Interface Types
dot3PauseEntry OBJECT-TYPE
SYNTAX
Dot3PauseEntry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION
"An entry in the table, containing information about the MAC
Control PAUSE function on a single ethernet-like interface."
INDEX
{ dot3StatsIndex }
::= { dot3PauseTable 1 }
Dot3PauseEntry ::=
SEQUENCE {
dot3PauseAdminMode
dot3PauseOperMode
dot3InPauseFrames
dot3OutPauseFrames
}
INTEGER,
INTEGER,
Counter32,
Counter32
104
RFC 2665: MIB for Ethernet-like Interface Types
dot3PauseAdminMode OBJECT-TYPE
SYNTAX
INTEGER { disabled(1), enabledXmit(2),
enabledRcv(3), enabledXmitAndRcv(4) }
MAX-ACCESS read-write
STATUS
current
DESCRIPTION
"This object is used to configure the default administrative PAUSE mode for this
interface. This object represents the administratively-configured PAUSE mode for
this interface. Attempts to set the object to 'enabledXmit(2)' or 'enabledRcv(3)' will
fail on interfaces that do not support operation at greater than 100 Mb/s. The value
of this object is ignored when the interface is not operating in full-duplex mode.
If auto-negotiation is not enabled or is not implemented for the active MAU
attached to this interface, the value of this object determines the operational
PAUSE mode of the interface whenever it is operating in full-duplex mode. In this
case, a set to this object will force the interface into the specified mode.
If auto-negotiation is implemented and enabled for the MAU attached to this
interface, the PAUSE mode for this interface is determined by auto-negotiation,
and the value of this object denotes the mode to which the interface will
automatically revert if/when auto-negotiation is later disabled. Note that when autonegotiation is running, administrative control of the PAUSE mode may be
accomplished using the ifMauAutoNegCapAdvertisedBits object in the MAU-MIB."
::= { dot3PauseEntry 1 }
105
RFC 2665: MIB for Ethernet-like Interface Types
dot3PauseOperMode OBJECT-TYPE
SYNTAX
INTEGER { disabled(1), enabledXmit(2),
enabledRcv(3), enabledXmitAndRcv(4) }
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"This object reflects the PAUSE mode currently in use on this
interface, as determined by either
1. the result of the auto-negotiation function or
2. if auto-negotiation is not enabled or is not implemented for
the active MAU attached to this interface, by the value of
dot3PauseAdminMode.
•
•
•
Interfaces operating at 100 Mb/s or less will never return
'enabledXmit(2)' or 'enabledRcv(3)'.
Interfaces operating in half-duplex mode will always return
'disabled(1)'.
Interfaces on which auto-negotiation is enabled but not yet
completed should return the value 'disabled(1)'."
::= { dot3PauseEntry 2 }
106
RFC 2665: MIB for Ethernet-like Interface Types
-- the Ethernet-like Collision Statistics group
-- Implementation of this group is optional; it is appropriate
-- for all systems which have the necessary metering
-- (e che funzionano in modalita' half duplex)
dot3CollTable OBJECT-TYPE
SYNTAX
SEQUENCE OF Dot3CollEntry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION
"A collection of collision histograms for a particular set of
interfaces."
REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.30, aCollisionFrames."
::= { dot3 5 }
107
RFC 2665: MIB for Ethernet-like Interface Types
dot3CollEntry OBJECT-TYPE
SYNTAX
Dot3CollEntry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION
"A cell in the histogram of per-frame collisions for a particular
interface. An instance of this object represents the frequency of
individual MAC frames for which the transmission (successful or
otherwise) on a particular interface is accompanied by a particular
number of media collisions."
INDEX
{ ifIndex, dot3CollCount }
::= { dot3CollTable 1 }
Dot3CollEntry ::=
SEQUENCE {
dot3CollCount
INTEGER,
dot3CollFrequencies Counter32
}
108