La maggior parte dei sistemi di gestione della rete (NMS) consente all'utente di caricare i MIB. Il caricamento di un MIB consente al sistema NMS di ottenere informazioni sui nuovi oggetti MIB, quali i nomi, gli identificatori di oggetto (OID) e il tipo di dati (ad esempio, Counter).
Il MIB può essere analizzato al momento del caricamento o in un secondo momento, ad esempio quando viene eseguita un'applicazione NMS. Il software che esegue l'analisi è un compilatore MIB.
Qualsiasi MIB sintatticamente corretto deve essere analizzato correttamente da qualsiasi compilatore MIB del fornitore. Sfortunatamente, diversi compilatori MIB possono presentare diversi quirk.
Cisco si impegna costantemente per garantire che i MIB pubblicati per i clienti siano sintatticamente corretti. Cisco evita anche i costrutti MIB che si sono dimostrati problematici nei prodotti NMS più diffusi. Nonostante questi sforzi, non è possibile soddisfare le anomalie di tutti i compilatori MIB sul campo.
Questo documento affronta alcuni dei problemi comuni e suggerisce le soluzioni. Se si verifica uno di questi problemi con il compilatore MIB del fornitore (ad eccezione del problema RFC 14xx rispetto a RFC 19xx), è dovuto a una carenza in tale compilatore MIB. È possibile invitare il fornitore o i fornitori a correggere i compilatori.
I lettori di questo documento dovrebbero conoscere i MIB.
Il documento può essere consultato per tutte le versioni software o hardware.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
L'ordine di caricamento è il problema più importante e comune quando si caricano file MIB. Molti MIB utilizzano definizioni definite in altri MIB. Queste definizioni sono elencate nella clausola IMPORTS nella parte superiore del MIB.
Ad esempio, se MIB mumble importa una definizione da MIB bumble, alcuni compilatori MIB richiedono il caricamento di MIB bumble prima di MIB mumble. Se l'ordine di caricamento è errato, il compilatore dichiarerà che i MIB importati non sono definiti.
Questo è un elenco di MIB da cui vengono importati molti altri MIB e l'ordine in cui devono essere caricati. Questo probabilmente risolve il 95% dei problemi dell'ordine di caricamento (la maggior parte degli altri MIB può essere caricata in qualsiasi ordine):
SNMPv2-SMI.my
SNMPv2-TC.my
SNMPv2-MIB.my
RFC 1213-MIB.my
IF-MIB.my
CISCO-SMI.my
CISCO-PRODUCTS-MIB.my
CISCO-TC.my
Nota: se si caricano le versioni v1 di questi MIB, il nome del file MIB sarà in realtà simile a IF-MIB-V1SMI.my ("-V1SMI" viene aggiunto al nome dei MIB convertiti da v2 a v1). L'eccezione è rappresentata dal file RFC1213-MIB.my MIB, che esiste solo come versione v1, ovvero non esiste alcun file RFC1213-MIB-V1SMI.my.
Se si tenta di caricare un altro MIB e il compilatore si lamenta degli elementi non definiti, identificare i MIB importati da questo MIB e verificare di aver caricato prima tutti gli altri MIB.
Nota: per ogni MIB, è possibile visualizzare l'elenco esatto dei MIB che devono essere caricati prima di esso, con l'ordine esatto di compilazione, in SNMP Object Navigator > View & Download MIBs; selezionare View MIB dependencies and download MIB (Visualizza dipendenze MIB) e scarica MIB.
Anche se le definizioni dei tipi di dati MIB di Cisco non corrispondono, è possibile che lo siano per alcuni MIB RFC standard. Ad esempio:
MIB mumble definisce: TipoDati ::= INTEGER(0..100)
MIB bumble definisce: SomeDatatype ::= INTEGER(1..50)
Questo esempio viene considerato un errore insignificante e il MIB viene caricato correttamente con un messaggio di avviso.
L'esempio successivo è considerato un errore non banale (anche se le due definizioni sono essenzialmente equivalenti) e il MIB non viene analizzato correttamente.
MIB mumble definisce: SomeDatatype ::= StringaVisualizzazione
MIB bumble definisce: SomeDatatype ::= STRINGA OTTETTO (SIZE(0..255))
Se il compilatore MIB considera questi errori o se si desidera eliminare i messaggi di avviso, modificare uno dei MIB che definiscono lo stesso tipo di dati in modo che le definizioni corrispondano.
Se si caricano questi MIB, è possibile che si verifichino ridefinizioni OID (anche se potrebbero esserci altre istanze in cui si verifica questo errore):
Ad esempio:
OLD-CISCO-CPU-MIB.my definisce: identificatore oggetto lcpu ::= { local 1 }
OLD-CISCO-ENV-MIB.my definisce: ID OGGETTO lenv ::= { local 1 }
Quando si caricano questi due MIB, il compilatore MIB potrebbe lamentarsi che l'identificatore oggetto lcpu venga ridefinito con un nuovo nome lenv. Allo stesso modo, i file OLD-CISCO-MEMORY-MIB.my e OLD-CISCO-SYSTEM-MIB.my possono assegnare nuovi nomi a { local 1 }.
Questo viene trattato come un semplice errore e il MIB viene caricato correttamente con un messaggio di avviso.
Se il MIB non viene caricato correttamente o se si desidera eliminare il messaggio di avviso, modificare uno dei MIB in modo che tutti i MIB utilizzino lo stesso nome.
Molti compilatori MIB dispongono di una conoscenza incorporata di alcuni tipi di dati, ad esempio DisplayString. Alcuni di questi compilatori si lamentano se vedono una definizione per questi tipi di dati in un MIB. Ad esempio, DisplayString è definito in SNMPv2-TC.
Per ovviare al problema, rimuovere o commentare la definizione che causa l'errore nel file MIB.
Questo è un esempio sintatticamente valido, che indica che un valore di tipo MyDatatype sarà lungo 0, 5 o 20 ottetti:
MyDatatype ::= OCTET STRING (SIZE(0 | 5 | 20))
Alcuni compilatori MIB non accettano questa sintassi. Solitamente, una soluzione sufficiente è scegliere una delle dimensioni e rimuovere le altre. Dovrebbe mantenere la dimensione più grande. L'esempio precedente verrebbe ad esempio modificato nel modo seguente:
MyDatatype ::= OCTET STRING (SIZE(20))
Alcuni OID sono considerati dispari perché non fanno riferimento a un nodo nell'SMI (come la maggior parte degli OBJECT IDENTIFIER). Tuttavia, sono sintatticamente validi. Un esempio comune è l'identificatore di oggetto nullo, ad esempio { 0 0 }. Ad alcuni compilatori MIB non interessa OBJECT IDENTIFIER che non corrispondono a un nodo in SMI. Di seguito sono riportati alcuni esempi di sintassi MIB che potrebbero causare problemi ai compilatori:
zeroDotZero OBJECT IDENTIFIER ::= { 0 0 } myMIBObject OBJECT-TYPE DEFVAL { {0 0} }
Per ovviare al problema, è possibile rimuovere o commentare questi tipi di riferimenti nel file MIB.
Nei MIB SNMPv1, le trap vengono definite con la macro TRAP-TYPE. Nei MIB SNMPv2, le trap vengono definite utilizzando la macro NOTIFICATION-TYPE.
Ad alcuni compilatori MIB non piacciono queste definizioni nei file MIB che stanno analizzando (non supportano queste macro).
In questo caso, è possibile rimuovere le definizioni di trap o impostare come commento le definizioni (ad esempio, inserire il delimitatore di commento MIB — all'inizio delle righe).
Le RFC da 1442 a 1452 definiscono il protocollo SNMPv2 basato su parti. Queste RFC sono obsolete in base alle nuove RFC standard da 1902 a 1908.
Per quanto riguarda la sintassi MIB, esistono pochissime differenze tra queste due versioni di SNMPv2; ce ne sono alcune, tuttavia. I MIB Cisco sono attualmente basati sulle regole RFC 19xx.
Nota: qualche anno fa, quando i MIB Cisco erano basati sulla RFC 14xx, alcuni compilatori basati sulla RFC 19xx si lamentavano della riga Unsigned32 ::= TEXTUAL-CONVENTION nei MIB CISCO-TC.my e PNI-MIB.my. Infatti Unsigned32 è un tipo di dati predefinito in RFC 19xx. Per questo motivo, Cisco utilizzava versioni alternative di questi MIB (CISCO-TC-NO-U32.my e PNI-MIB-NO-U32.my) senza alcuna definizione di Unsigned32, da caricare nei compilatori che già conoscono questo tipo di dati. Non è più applicabile.
Il modo migliore e più efficiente per caricare MIB, trap e icone Cisco in un NMS di terze parti è utilizzare CiscoWorks Integration Utility (Integration Utility), disponibile come parte di CiscoWorks Common Services (o in versione standalone all'indirizzo http://www.cisco.com/cgi-bin/tablebuild.pl/cw2000-utility), con l'adattatore di Integration Utility corrispondente all'indirizzo http://www.cisco.com/tacpage/sw-center/cw2000/cmc3rd.shtml e l'ultimo Network Management Integration Data Bundle (NMIDB). Per ulteriori informazioni, consultare la documentazione di Integration Utility.
In alternativa, è possibile consultare la documentazione di NMS di terze parti sul caricamento e la compilazione MIB. Questo documento include istruzioni per HP OpenView e IBM NetView; ma devi comunque consultare la documentazione di HP o IBM, in quanto i prodotti potrebbero cambiare.
Per caricare i MIB Cisco desiderati, attenersi alla procedura seguente:
Copiare i file nella directory /usr/OV/snmp_mibs della stazione di gestione di rete.
Questa è la directory predefinita in cui HP OpenView e IBM NetView cercano i documenti MIB. Se li inserite altrove, specificate i nomi di percorso espliciti nell'interfaccia grafica loadmib.
Impostare le autorizzazioni in modo da disporre dell'accesso in lettura ai MIB.
Dal menu GUI, scegliere Opzioni > Carica/scarica MIB.
Per compilare o caricare i MIB Cisco, attenersi alle istruzioni contenute nella documentazione della piattaforma.
Utilizzare il comando /opt/OV/bin/xnmloadmib -load filename per caricare il file MIB.