Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 LABORATORIO DI INFORMATICA Network Management 9. Visita guidata alle MIB standard 9.1. snmpMIB, ifMIB, etherMIB, mauMIB Claudio Salati Copyright © 2001.

Similar presentations


Presentation on theme: "1 LABORATORIO DI INFORMATICA Network Management 9. Visita guidata alle MIB standard 9.1. snmpMIB, ifMIB, etherMIB, mauMIB Claudio Salati Copyright © 2001."— Presentation transcript:

1 1 LABORATORIO DI INFORMATICA Network Management 9. Visita guidata alle MIB standard 9.1. snmpMIB, ifMIB, etherMIB, mauMIB Claudio Salati Copyright © 2001 by Claudio Salati ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA FACOLTA' DI INGEGNERIA - SEDE DI CESENA

2 2 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

3 3 OBJECT IDENTIFIER utilizzati nelle MIB internet = 1.3.6.1 mgmt (2) mib-2 (1) experimental (3) private (4) enterprises (1) snmpV2 (6) snmpModules (1) snmpMIB (1) -- (RFC 1907) snmpMIBObjects (1) transmission (10) Vedi: RFC 1902, SNMPv2-SMI RFC 1907, SNMPv2MIB RFC 2233, ifMIB system (1) -- RFC 1907 snmp (11) -- RFC 1907 interfaces (2) -- RFC 2233 ifMIB (31) -- RFC 2233

4 4 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 Community- based snmpCommunityGroup

5 5 RFC 1907: MIB for SNMPv2 mib-2 = 1.3.6.1.2.1system (1) sysDescr (1) sysUpTime (3) sysContact (4) sysName (5) sysLocation (6) sysServices (7) sysORLastChange (8) sysObjectID (2) sysORTable (9)sysOREntry (1) sysORIndex (1) sysORID (2) sysORDescr (3) sysORUpTime (4)

6 6 RFC 1907: MIB for SNMPv2 mib-2 = 1.3.6.1.2.1snmp (11) snmpInPkts (1) snmpInBadCommunityNames (4) snmpInBadCommunityUses (5) snmpInASPNarseErrs (6) snmpEnableAuthenTraps (30) snmpSilentDrops (31) snmpProxyDrops (32) snmpInBadVersions (3)

7 7 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) snmpSet (6) snmpSetSerialNo (1) authenticationFailure (5)

8 8 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

9 9 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

10 10 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

11 11 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

12 12 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)

13 13 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)...

14 14 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)

15 15 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)

16 16 RFC 2233: The Interfaces Group MIB using SMIv2 snmpMIBObjects = 1.3.6.1.6.3.1.1 snmpTraps (5) linkDown (3) linkUp (4)

17 17 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 interface- independent 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.

18 18 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 }

19 19 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 }

20 20 RFC 2233: tabella ifTable IfEntry ::= SEQUENCE { ifIndexInterfaceIndex,ifDescr DisplayString, ifTypeIANAifType,ifMtu Integer32, ifSpeedGauge32,ifPhysAddress PhysAddress, ifAdminStatusINTEGER,ifOperStatus INTEGER, ifLastChangeTimeTicks,ifInOctets Counter32, ifInUcastPktsCounter32,ifInNUcastPkts Counter32, -- deprecated ifInDiscardsCounter32,ifInErrors Counter32, ifInUnknownProtosCounter32, ifOutOctetsCounter32,ifOutUcastPkts Counter32, ifOutNUcastPktsCounter32, -- deprecated ifOutDiscardsCounter32,ifOutErrors Counter32, ifOutQLenGauge32, -- deprecated ifSpecificOBJECT IDENTIFIER -- deprecated }

21 21 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 }

22 22 RFC 2233: tabella ifXTable IfXEntry ::= SEQUENCE { ifNameDisplayString, ifInMulticastPktsCounter32,ifInBroadcastPktsCounter32, ifOutMulticastPktsCounter32,ifOutBroadcastPktsCounter32, ifHCInOctetsCounter64,ifHCInUcastPktsCounter64, ifHCInMulticastPktsCounter64,ifHCInBroadcastPktsCounter64, ifHCOutOctetsCounter64,ifHCOutUcastPktsCounter64, ifHCOutMulticastPktsCounter64,ifHCOutBroadcastPktsCounter64, ifLinkUpDownTrapEnableINTEGER, ifHighSpeedGauge32, ifPromiscuousModeTruthValue, ifConnectorPresent TruthValue, ifAliasDisplayString, ifCounterDiscontinuityTimeTimeStamp }

23 23 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.

24 24 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 }

25 25 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 re- initialization." SYNTAX Integer32 (1..2147483647)

26 26 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 }

27 27 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

28 28 IANAifType-MIB IANAifType-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION 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: iana@iana.org" 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." …

29 29 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 }

30 30 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 (iana@iana.org). 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 OID- subtree 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

31 31 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),

32 32 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 …

33 33 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 …

34 34 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

35 35 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.

36 36 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.

37 37 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 }

38 38 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

39 39 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-length- transmission 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-length- transmission network interfaces." ::= { ifGroups 3 }

40 40 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 }

41 41 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 }

42 42 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 }

43 43 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.

44 44 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 }

45 45 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 }

46 46 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 }

47 47 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 }

48 48 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 }

49 49 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 }

50 50 RFC 2233: tabella ifTable: oggetti colonna ifOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3),-- in some test mode unknown(4),-- status can not be determined -- for some reason. dormant(5), notPresent(6),-- some component is missing lowerLayerDown(7)-- down due to state of -- lower-layer interface(s) } MAX-ACCESS read-only STATUS current -- DESCRIPTION... -- vedi prossima pagina

51 51 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 }

52 52 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 }

53 53 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.

54 54 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.

55 55 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

56 56 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

57 57 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.

58 58 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

59 59 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

60 60 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 }

61 61 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 }

62 62 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 }

63 63 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 }

64 64 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 }

65 65 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 re- initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime." ::= { ifEntry 14 }

66 66 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 re- initialization of the local management subsystem, then this object contains a zero value." ::= { ifXEntry 19 }

67 67 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" sub- layers through INTEGER "pointers" to the appropriate conceptual rows in the ifTable.

68 68 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

69 69 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 sub- layer 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 }

70 70 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 { ifStackHigherLayerInteger32, ifStackLowerLayerInteger32, ifStackStatusRowStatus }

71 71 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

72 72 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

73 73 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 }

74 74 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 re- initialization of the local network management subsystem, then this object contains a zero value." ::= { ifMIBObjects 6 }

75 75 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 }

76 76 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 }

77 77 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

78 78 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 }

79 79 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 }

80 80 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 not- accessible

81 81 RFC 2233: module compliance1 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 character- oriented 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."

82 82 RFC 2233: module compliance2 GROUP 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 media- specific MIBs. Media-specific MIBs must define the exact meaning, use, and semantics of the addresses in this group."

83 83 RFC 2233: module compliance3 OBJECT 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')

84 84 RFC 2233: module compliance4 OBJECT 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 }

85 85 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

86 86 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

87 87 RFC 2665: MIB for Ethernet-like Interface Types Questa MIB modella (e' applicabile a) tutti i tipi di interfacce Ethernet- like (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 sub- layer 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)

88 88 RFC 2665: MIB for Ethernet-like Interface Types Struttura layerizzata di una sottorete IEEE 802 LLC MAC CONTROL MAC Physical MAU normalmente non implementato opzionale Gestiti da RFC 2665

89 89 RFC 2665: MIB for Ethernet-like Interface Types sez. 3.2.4 definisce la necessita' da parte delle interfacce Ethernet- like 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.

90 90 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)

91 91 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."

92 92 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 MAU- MIB 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.

93 93 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)...

94 94 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 }

95 95 RFC 2665: MIB for Ethernet-like Interface Types Dot3StatsEntry ::= SEQUENCE { dot3StatsIndexInterfaceIndex, dot3StatsAlignmentErrorsCounter32, dot3StatsFCSErrorsCounter32, dot3StatsSingleCollisionFramesCounter32, dot3StatsMultipleCollisionFramesCounter32, dot3StatsSQETestErrorsCounter32, dot3StatsDeferredTransmissionsCounter32, dot3StatsLateCollisionsCounter32, dot3StatsExcessiveCollisionsCounter32, dot3StatsInternalMacTransmitErrorsCounter32, dot3StatsCarrierSenseErrorsCounter32, dot3StatsFrameTooLongsCounter32, dot3StatsInternalMacReceiveErrorsCounter32, dot3StatsEtherChipSetOBJECT IDENTIFIER, dot3StatsSymbolErrorsCounter32, dot3StatsDuplexStatusINTEGER }

96 96 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 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 }

97 97 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 }

98 98 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 }

99 99 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."

100 100 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 }

101 101 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 BITS, dot3ControlInUnknownOpcodes Counter32 }

102 102 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 }

103 103 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 }

104 104 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 { dot3PauseAdminModeINTEGER, dot3PauseOperModeINTEGER, dot3InPauseFramesCounter32, dot3OutPauseFramesCounter32 }

105 105 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 auto- negotiation is running, administrative control of the PAUSE mode may be accomplished using the ifMauAutoNegCapAdvertisedBits object in the MAU-MIB." ::= { dot3PauseEntry 1 }

106 106 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 }

107 107 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 }

108 108 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 }


Download ppt "1 LABORATORIO DI INFORMATICA Network Management 9. Visita guidata alle MIB standard 9.1. snmpMIB, ifMIB, etherMIB, mauMIB Claudio Salati Copyright © 2001."

Similar presentations


Ads by Google