Questo argomento descrive i tipi di oggetto in SNMP v1 e v2.
È possibile individuare le informazioni sugli oggetti descritti nelle sezioni di seguito riportate selezionando un modulo nella vista Moduli MIB e ricercando ifIndex nel campo Cerca della vista Struttura ad albero OID. Fare clic sull'oggetto ifIndex nella gerarchia Struttura ad albero OID per visualizzare le informazioni sull'oggetto e le informazioni sulle convenzioni testuali nella vista Dettagli.
OBJECT IDENTIFIER è definito da SNMP v1 e rappresenta il blocco di generazione principale della struttura ad albero MIB. Gli identificativi di oggetto sono analoghi ad un'intestazione di capitolo in un manuale, non contengono in sé dati reali ma danno un'idea del tipo di contenuto che verrò trasmesso dai relativi discendenti.
OBJECT-TYPE è definito da SNMP v1 e viene utilizzato come un contenitore per memorizzare informazioni sul dispositivo gestito o su alcuni valori misurati sul dispositivo.
TEXTUAL-CONVENTION (TC) è una definizione di un tipo di oggetto ma non è un oggetto effettivo. Nella vista Moduli MIB, è possibile selezionare Convenzioni testuali dall'elenco Vista per visualizzare le convenzioni testuali analizzate visualizzate nella struttura ad albero MIB. Selezionare un nome TC nella struttura ad albero MIB per visualizzare la relativa definizione nella vista Dettagli.
bgpEstablished TRAP-TYPE ENTERPRISE bgp VARIABLES { bgpPeerRemoteAddr, bgpPeerLastError,
bgpPeerState } DESCRIPTION "The BGP Established event is generated when the BGP FSM
enters the ESTABLISHED state." ::= 1 La sezione ENTERPRISE definisce quale oggetto è parent del trap. Tuttavia, è possibile che un oggetto della struttura ad albero MIB sia definito con bgp come parent e sia definito come numero child 1. In realtà, bgpVersion è definito come { bgp 1} nel modulo RFC1269-MIB. Quindi, è impossibile aggiungere un trap v1 alla struttura ad albero MIB come foglia, utilizzando ENTERPRISE come parent.
SNMP v2 modifica la definizione per TRAP-TYPE in NOTIFICATION-TYPE e specifica che questo nuovo trap v2 sia definito come altri oggetti MIB, con un numero parent e un numero child che costituiscono solo un problema per i trap v1. In RFC1155 Sezione 4.1 viene definito che l'utilizzo di zero (0) come un numero child non è valido ed è riservato per uso futuro. SNMP v2 permette l'utilizzo di quello zero consentendo ai fornitori di aggiungere i propri trap v1 ad un MIB v2, aggiungendo uno zero al nome dell'azienda e aggiungendo quindi il numero di trap dopo lo zero. Quindi, con v2, è appropriato definire un identificativo di oggetto con uno zero come un child dell'azienda e aggiungere quindi i trap v1 come child di quello zero.
Questa convenzione ha causato un altro errore comune effettuato dagli autori MIB. In RFC1155, sezione 4, viene affermato quanto segue:
"An object type definition consists of five fields: OBJECT: ------- A textual name, termed the OBJECT DESCRIPTOR, for the object type, along with its corresponding OBJECT IDENTIFIER. Syntax: The abstract syntax for the object type. This must resolve to an instance of the ASN.1 type ObjectSyntax (defined below). Definition: A textual description of the semantics of the object type. Implementations should ensure that their instance of the object fulfills this definition since this MIB is intended for use in multi-vendor environments. As such it is vital that objects have consistent meaning across all machines. Access: One of read-only, read-write, write-only, or not-accessible. Status: One of mandatory, optional, or obsolete. Future memos may also specify other fields for the objects which they define."
adslAtucPerfLofsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLofs, adslAtucThresh15MinLofs } STATUS current DESCRIPTION "Loss of Framing 15-minute interval threshold reached." ::= { adslAtucTraps 0 1 } Gli oggetti che vengono trasmessi con il trap v1 o la notifica v2 sono noti come varbind. I varbind contengono informazioni aggiuntive sull'evento riportato. In un trap v1, i varbind sono elencati nella sezione VARIABLES e in una notifica v2 i varbind sono elencati nella sezione OBJECTS. Hanno lo stesso uso in tutte le versioni di SNMP. L'ordine in cui i varbind vengono visualizzati nell'elenco è importante perché il PDU (pacchetto SNMP) codifica i valori associati nello stesso ordine in cui sono elencati nel MIB.
Ad esempio, nella sezione OBJECTS, sono stati specificati i seguenti tre varbind: ifIndex, ifAdminStatus e ifOperStatus. Quindi, ifIndex è il primo varbind da codificare, ifAdminStatus è il secondo e ifOperStatus è il terzo. Controllando l'elemento IF-MIB, si nota che il tipo di oggetto ifIndex è definito come InterfaceIndex. Poiché non è un tipo ASN.1 primitivo valido per SNMP, deve essere una convenzione testuale. Eseguendo una ricerca nelle convenzioni testuali, si nota che InterfaceIndex viene risolto in realtà in un Integer32 (numero intero a 32 bit). Di conseguenza, quando la PDU arriva a MIB Manager, il primo varbind sarà un numero intero. Per stabilire cosa indica il numero intero, MIB Manager deve fare riferimento al modulo IF-MIB, ricercare ifIndex e leggere le informazioni sull'oggetto associate. Verificando il secondo varbind, si nota un tipo di numero intero enumerato:
SYNTAX INTEGER { up(1), -- ready to pass packets down(2),
testing(3) -- in some test mode }Quando il varbind è decodificato dal pacchetto SNMP, il relativo valore sarà un numero intero, il valore del quale deve essere interpretato in base agli elementi presenti in questo elenco enumerato. Quando MIB Manager viene utilizzato per creare un file delle regole, crea una tabella di ricerca per collegare automaticamente il numero intero enumerato alla relativa rappresentazione testuale. Anche il terzo varbind è un tipo enumerato con gli stessi valori. Quindi, se ifAdminStatus è 1 (up) e ifOperStatus è 2 (down), è noto il motivo per cui l'evento è stato generato e si può procedere con il tentativo di determinare la causa di questa interruzione.
I varbind vengono presentati all'utente in un file delle regole come $1, $2, $3 e così via, con ciascun numero che rappresenta un numero varbind. MIB Manager crea gli elementi in base agli elementi varbind e li utilizza per impostare le variabili nella tabella dettagli. Ad esempio, gli elementi utilizzati nella tabella dettagli potrebbero essere $ifIndex = $1, che sarà un numero intero, $ifAdminStatus = $2, che sarà up (1), e $ifOperStatus = $3, che sarà down (3). Qualsiasi modifica apportata alle impostazioni degli oggetti viene impostata automaticamente nel file delle regole, utilizzando le convenzioni impostate da NCKL (Netcool Knowledge Library).
Le tabelle rappresentano l'equivalente di un array multidimensionale con righe e colonne di dati. L'oggetto tabella è definito come SEQUENCE OF di un oggetto voce. L'oggetto voce è definito come SEQUENCE di oggetti OBJECT-TYPE. Occasionalmente, un fornitore progetta un sistema insolito, ad esempio il router Cisco 10k. Questo dispositivo mantiene una tabella interna di condizioni di allarme e genera un trap o una notifica quando la tabella viene modificata. È necessario quindi emettere una richiesta GET SNMP relativa al contenuto della tabella per determinare lo stato corrente degli allarmi attivi sul dispositivo. In questo modo, ottenere gli allarmi dal gestore SMNP diventa leggermente più difficile, ma non impossibile, se l'amministratore dispone degli strumenti necessari.
Un ottetto è un costrutto di dati costituito di otto bit (comunemente noti come byte). Un OCTET STRING quindi, è un array di byte, o una stringa di byte. Il termine OCTET STRING non implica che tutti i byte nella stringa siano alfanumerici. I byte possono essere anche caratteri binari e vengono utilizzati come maschere di bit.