3. The SNMP Architecture
Nell'architettura SNMP è implicita una collezione di stazioni di network management e di elementi di rete. Le stazioni di network management eseguono applicazioni di gestione che monitorano e controllano gli elementi di rete. Gli elementi di rete sono dispositivi quali host, gateway, terminal server e simili, che dispongono di agent di gestione responsabili dell'esecuzione delle funzioni di network management richieste dalle stazioni di network management. Il Simple Network Management Protocol (SNMP) viene utilizzato per comunicare le informazioni di gestione tra le stazioni di network management e gli agent negli elementi di rete.
3.1 Goals of the Architecture
L'SNMP riduce al minimo il numero e la complessità delle funzioni di gestione realizzate dall'agente di gestione stesso. Questo obiettivo è vantaggioso sotto almeno quattro aspetti:
-
Il costo di sviluppo del software per l'agente di gestione necessario a supportare il protocollo risulta di conseguenza ridotto.
-
Il grado di funzioni di gestione supportate da remoto risulta di conseguenza aumentato, consentendo il pieno impiego delle risorse Internet nel compito di gestione.
-
Il grado di funzioni di gestione supportate da remoto risulta di conseguenza aumentato, imponendo così il minor numero possibile di restrizioni sulla forma e sulla sofisticazione degli strumenti di gestione.
-
Insiemi semplificati di funzioni di gestione sono facilmente compresi e utilizzati dagli sviluppatori di strumenti di network management.
Un secondo obiettivo del protocollo è che il paradigma funzionale per il monitoraggio e il controllo sia sufficientemente estensibile da accogliere aspetti aggiuntivi, forse imprevisti, del funzionamento e della gestione della rete.
Un terzo obiettivo è che l'architettura sia, per quanto possibile, indipendente dall'architettura e dai meccanismi di particolari host o particolari gateway.
3.2 Elements of the Architecture
L'architettura SNMP definisce una soluzione al problema del network management in termini di:
-
ambito delle informazioni di gestione comunicate dal protocollo,
-
rappresentazione delle informazioni di gestione comunicate dal protocollo,
-
operazioni sulle informazioni di gestione supportate dal protocollo,
-
forma e significato degli scambi tra le entità di gestione,
-
definizione delle relazioni amministrative tra le entità di gestione, e
-
forma e significato dei riferimenti alle informazioni di gestione.
3.2.1 Scope of Management Information
L'ambito delle informazioni di gestione comunicate dal funzionamento di SNMP è esattamente quello rappresentato dalle istanze di tutti i tipi di oggetto non aggregati definiti sia nella MIB di standard Internet sia altrove secondo le convenzioni stabilite nella SMI di standard Internet [5].
Il supporto per i tipi di oggetto aggregati nella MIB non è richiesto per la conformità con la SMI né realizzato da SNMP.
3.2.2 Representation of Management Information
Le informazioni di gestione comunicate dal funzionamento di SNMP sono rappresentate secondo il sottoinsieme del linguaggio ASN.1 [9] specificato per la definizione dei tipi non aggregati nella SMI.
L'SGMP adottò la convenzione di utilizzare un ben definito sottoinsieme del linguaggio ASN.1 [9]. L'SNMP prosegue ed estende questa tradizione impiegando un sottoinsieme moderatamente più complesso di ASN.1 per descrivere gli oggetti gestiti e le unità di dati di protocollo utilizzate per gestirli. Inoltre, il desiderio di agevolare l'eventuale transizione a protocolli di network management basati su OSI portò alla definizione, nel linguaggio ASN.1, di una Structure of Management Information (SMI) [5] e di una Management Information Base (MIB) [6] di standard Internet. L'uso del linguaggio ASN.1 fu incoraggiato, in parte, dal successo dell'impiego di ASN.1 in precedenti sforzi, in particolare l'SGMP. Le restrizioni sull'uso di ASN.1 che fanno parte della SMI contribuiscono alla semplicità sostenuta e convalidata dall'esperienza con l'SGMP.
Anche per amore della semplicità, SNMP utilizza solo un sottoinsieme delle basic encoding rules di ASN.1 [10]. In particolare, tutte le codifiche impiegano la forma a lunghezza definita. Inoltre, ove permesso, si utilizzano codifiche non costruttore anziché codifiche costruttore. Questa restrizione si applica a tutti gli aspetti della codifica ASN.1, sia per le unità di dati di protocollo di livello superiore sia per gli oggetti dati in esse contenuti.
3.2.3 Operations Supported on Management Information
L'SNMP modella tutte le funzioni dell'agente di gestione come alterazioni o ispezioni di variabili. Pertanto, un'entità di protocollo su un host logicamente remoto (forse lo stesso elemento di rete) interagisce con l'agente di gestione residente sull'elemento di rete per recuperare (get) o modificare (set) variabili. Questa strategia ha almeno due conseguenze positive:
-
Ha l'effetto di limitare il numero di funzioni essenziali di gestione realizzate dall'agente di gestione a due: un operatore per assegnare un valore a un parametro di configurazione o altro specificato e un altro per recuperare tale valore.
-
Un secondo effetto di questa decisione è di evitare di introdurre nella definizione del protocollo il supporto per comandi di gestione imperativi: il numero di tali comandi è nella pratica in continua crescita e la loro semantica è generalmente arbitrariamente complessa.
La strategia implicita in SNMP è che il monitoraggio dello stato della rete a un livello di dettaglio significativo è realizzato principalmente tramite polling per le appropriate informazioni da parte dei centri di monitoraggio. Un numero limitato di messaggi non sollecitati (trap) guida la tempistica e il fuoco del polling. Limitare il numero di messaggi non sollecitati è coerente con l'obiettivo di semplicità e di minimizzazione del traffico generato dalla funzione di network management.
L'esclusione dei comandi imperativi dall'insieme delle funzioni di gestione esplicitamente supportate è improbabile che precluda qualsiasi operazione desiderabile dell'agente di gestione. Attualmente, la maggior parte dei comandi sono richieste o di impostare il valore di qualche parametro o di recuperarne tale valore, e la funzione dei pochi comandi imperativi attualmente supportati è facilmente assolta in modo asincrono da questo modello di gestione. In questo schema, un comando imperativo potrebbe essere realizzato come l'impostazione di un valore di parametro che successivamente innesca l'azione desiderata. Ad esempio, anziché implementare un "comando di riavvio", tale azione potrebbe essere invocata semplicemente impostando un parametro che indica il numero di secondi al riavvio del sistema.
3.2.4 Form and Meaning of Protocol Exchanges
La comunicazione delle informazioni di gestione tra le entità di gestione è realizzata in SNMP tramite lo scambio di messaggi di protocollo. La forma e il significato di tali messaggi è definita nel Paragrafo 4.
Coerente con l'obiettivo di minimizzare la complessità dell'agente di gestione, lo scambio di messaggi SNMP richiede solo un servizio di datagramma non affidabile, e ogni messaggio è interamente e indipendentemente rappresentato da un singolo datagramma di trasporto. Sebbene questo documento specifichi lo scambio di messaggi tramite il protocollo UDP [11], i meccanismi di SNMP sono generalmente adatti all'uso con un'ampia varietà di servizi di trasporto.
3.2.5 Definition of Administrative Relationships
L'architettura SNMP ammette una varietà di relazioni amministrative tra le entità che partecipano al protocollo. Le entità risiedenti sulle stazioni di gestione e sugli elementi di rete che comunicano tra loro utilizzando SNMP sono dette entità applicative SNMP. I processi peer che implementano SNMP, e che quindi supportano le entità applicative SNMP, sono detti entità di protocollo.
L'accoppiamento di un agent SNMP con un insieme arbitrario di entità applicative SNMP è chiamato community SNMP. Ciascuna community SNMP è denominata da una stringa di ottetti, che è chiamata nome della community per detta community.
Un messaggio SNMP originato da un'entità applicativa SNMP che in effetti appartiene alla community SNMP denominata dalla componente community di detto messaggio è chiamato messaggio SNMP autentico. L'insieme delle regole mediante le quali un messaggio SNMP è identificato come messaggio SNMP autentico per una particolare community SNMP è chiamato schema di autenticazione. Un'implementazione di una funzione che identifica messaggi SNMP autentici secondo uno o più schemi di autenticazione è chiamata servizio di autenticazione.
È chiaro che la gestione efficace delle relazioni amministrative tra entità applicative SNMP richiede servizi di autenticazione che (tramite l'uso della crittografia o di altre tecniche) siano in grado di identificare messaggi SNMP autentici con un elevato grado di certezza. Alcune implementazioni SNMP potrebbero voler supportare solo un servizio di autenticazione banale che identifica tutti i messaggi SNMP come messaggi SNMP autentici.
Per ciascun elemento di rete, un sottoinsieme degli oggetti nella MIB che pertengono a tale elemento è chiamato vista MIB SNMP. Si noti che i nomi dei tipi di oggetto rappresentati in una vista MIB SNMP non devono appartenere a un singolo sottoalbero dello spazio dei nomi dei tipi di oggetto.
Un elemento dell'insieme { READ-ONLY, READ-WRITE } è chiamato modalità di accesso SNMP.
L'accoppiamento di una modalità di accesso SNMP con una vista MIB SNMP è chiamato profilo di community SNMP. Un profilo di community SNMP rappresenta privilegi di accesso specificati a variabili in una vista MIB specificata. Per ogni variabile nella vista MIB in un dato profilo di community SNMP, l'accesso a tale variabile è rappresentato dal profilo secondo le seguenti convenzioni:
-
se detta variabile è definita nella MIB con "Access:" di "none", non è disponibile come operando per alcun operatore;
-
se detta variabile è definita nella MIB con "Access:" di "read-write" o "write-only" e la modalità di accesso del profilo dato è READ-WRITE, tale variabile è disponibile come operando per le operazioni get, set e trap;
-
altrimenti, la variabile è disponibile come operando per le operazioni get e trap.
-
Nei casi in cui una variabile "write-only" è un operando usato per le operazioni get o trap, il valore dato per la variabile è specifico dell'implementazione.
L'accoppiamento di una community SNMP con un profilo di community SNMP è chiamato politica di accesso SNMP. Una politica di accesso rappresenta un profilo di community specificato concesso dall'agente SNMP di una community SNMP specificata ad altri membri di quella community. Tutte le relazioni amministrative tra entità applicative SNMP sono definite architetturalmente in termini di politiche di accesso SNMP.
Per ogni politica di accesso SNMP, se l'elemento di rete su cui risiede l'agente SNMP per la community SNMP specificata non è quello a cui la vista MIB per il profilo specificato pertiene, allora tale politica è chiamata politica di accesso proxy SNMP. L'agente SNMP associato a una politica di accesso proxy è chiamato agent proxy SNMP. Sebbene la definizione trascurata di politiche di accesso proxy possa dar luogo a cicli di gestione, la definizione prudente di politiche proxy è utile in almeno due modi:
-
Consente il monitoraggio e il controllo di elementi di rete altrimenti non indirizzabili utilizzando il protocollo di gestione e il protocollo di trasporto. Cioè, un agent proxy può fornire una funzione di conversione di protocollo che consente a una stazione di gestione di applicare un quadro di gestione coerente a tutti gli elementi di rete, inclusi dispositivi quali modem, multiplexer e altri dispositivi che supportano diversi quadri di gestione.
-
Potenzialmente scherma gli elementi di rete da elaborate politiche di controllo degli accessi. Ad esempio, un agent proxy può implementare un controllo degli accessi sofisticato mediante il quale diversi sottoinsiemi di variabili nella MIB sono resi accessibili a diverse stazioni di gestione senza aumentare la complessità dell'elemento di rete.
A titolo di esempio, la Figura 1 illustra la relazione tra stazioni di gestione, agent proxy e agent di gestione. In questo esempio, l'agent proxy è concepito come un normale Internet Network Operations Center (INOC) di qualche dominio amministrativo che ha una relazione di gestione standard con un insieme di agent di gestione.
+------------------+ +----------------+ +----------------+
| Region #1 INOC | |Region #2 INOC | |PC in Region #3 |
| | | | | |
|Domain=Region #1 | |Domain=Region #2| |Domain=Region #3|
|CPU=super-mini-1 | |CPU=super-mini-1| |CPU=Clone-1 |
|PCommunity=pub | |PCommunity=pub | |PCommunity=slate|
| | | | | |
+------------------+ +----------------+ +----------------+
/|\ /|\ /|\
| | |
| | |
| \|/ |
| +-----------------+ |
+-------------->| Region #3 INOC |<-------------+
| |
|Domain=Region #3 |
|CPU=super-mini-2 |
|PCommunity=pub, |
| slate |
|DCommunity=secret|
+-------------->| |<-------------+
| +-----------------+ |
| /|\ |
| | |
| | |
\|/ \|/ \|/
+-----------------+ +-----------------+ +-----------------+
|Domain=Region#3 | |Domain=Region#3 | |Domain=Region#3 |
|CPU=router-1 | |CPU=mainframe-1 | |CPU=modem-1 |
|DCommunity=secret| |DCommunity=secret| |DCommunity=secret|
+-----------------+ +-----------------+ +-----------------+
Domain: il dominio amministrativo dell'elemento PCommunity: il nome di una community che utilizza un agent proxy DCommunity: il nome di una community diretta
Figure 1 Example Network Management Configuration
3.2.6 Form and Meaning of References to Managed Objects
La SMI richiede che la definizione di un protocollo di gestione conforme affronti:
-
la risoluzione di riferimenti MIB ambigui,
-
la risoluzione di riferimenti MIB in presenza di multiple versioni MIB, e
-
l'identificazione di particolari istanze di tipi di oggetto definiti nella MIB.
3.2.6.1 Resolution of Ambiguous MIB References
Poiché l'ambito di qualsiasi operazione SNMP è concettualmente limitato a oggetti rilevanti per un singolo elemento di rete, e poiché tutti i riferimenti SNMP a oggetti MIB sono (implicitamente o esplicitamente) tramite nomi di variabili univoci, non vi è alcuna possibilità che un riferimento SNMP a qualsiasi tipo di oggetto definito nella MIB possa risolversi in multiple istanze di tale tipo.
3.2.6.2 Resolution of References across MIB Versions
L'istanza di oggetto cui si riferisce qualsiasi operazione SNMP è esattamente quella specificata come parte della richiesta di operazione o (nel caso di un'operazione get-next) il suo immediato successore nella MIB nel suo complesso. In particolare, un riferimento a un oggetto come parte di qualche versione della MIB di standard Internet non si risolve in alcun oggetto che non sia parte di detta versione della MIB di standard Internet, eccetto nel caso in cui l'operazione richiesta sia get-next e il nome di oggetto specificato sia lessicograficamente l'ultimo tra i nomi di tutti gli oggetti presentati come parte di detta versione della MIB di standard Internet.
3.2.6.3 Identification of Object Instances
I nomi per tutti i tipi di oggetto nella MIB sono definiti esplicitamente sia nella MIB di standard Internet sia in altri documenti che conformano alle convenzioni di denominazione della SMI. La SMI richiede che i protocolli di gestione conformi definiscano meccanismi per identificare singole istanze di quei tipi di oggetto per un particolare elemento di rete.
Ciascuna istanza di qualsiasi tipo di oggetto definito nella MIB è identificata nelle operazioni SNMP da un nome univoco chiamato suo "nome di variabile". In generale, il nome di una variabile SNMP è un OBJECT IDENTIFIER della forma x.y, dove x è il nome di un tipo di oggetto non aggregato definito nella MIB e y è un frammento OBJECT IDENTIFIER che, in un modo specifico del tipo di oggetto denominato, identifica l'istanza desiderata.
Questa strategia di denominazione ammette il pieno sfruttamento della semantica della GetNextRequest-PDU (vedere Paragrafo 4), poiché assegna nomi per variabili correlate in modo da essere contigui nell'ordinamento lessicografico di tutti i nomi di variabili noti nella MIB.
La denominazione specifica per tipo delle istanze di oggetto è definita di seguito per un numero di classi di tipi di oggetto. Le istanze di un tipo di oggetto a cui non è applicabile alcuna delle seguenti convenzioni di denominazione sono denominate da OBJECT IDENTIFIER della forma x.0, dove x è il nome di detto tipo di oggetto nella definizione MIB.
Ad esempio, supponiamo di voler identificare un'istanza della variabile sysDescr. La classe di oggetto per sysDescr è:
iso org dod internet mgmt mib system sysDescr
1 3 6 1 2 1 1 1
Pertanto, il tipo di oggetto, x, sarebbe 1.3.6.1.2.1.1.1 a cui è accodato un sottoidentificatore di istanza di 0. Cioè, 1.3.6.1.2.1.1.1.0 identifica l'unica istanza di sysDescr.
3.2.6.3.1 ifTable Object Type Names
Il nome di un'interfaccia di sottorete, s, è il valore OBJECT IDENTIFIER della forma i, dove i ha il valore di quella istanza del tipo di oggetto ifIndex associata a s.
Per ciascun tipo di oggetto, t, la cui definizione di nome, n, ha un prefisso di ifEntry, un'istanza, i, di t è denominata da un OBJECT IDENTIFIER della forma n.s, dove s è il nome dell'interfaccia di sottorete di cui i rappresenta informazioni.
Ad esempio, supponiamo di voler identificare l'istanza della variabile ifType associata all'interfaccia 2. Di conseguenza, ifType.2 identificherebbe l'istanza desiderata.
3.2.6.3.2 atTable Object Type Names
Il nome di un indirizzo di rete memorizzato nella cache AT, x, è un OBJECT IDENTIFIER della forma 1.a.b.c.d, dove a.b.c.d è il valore (nella consueta notazione a "punti") del tipo di oggetto atNetAddress associato a x.
Il nome di un'equivalenza di traduzione degli indirizzi e è un valore OBJECT IDENTIFIER della forma s.w, tale che s è il valore di quella istanza del tipo di oggetto atIndex associata a e e tale che w è il nome dell'indirizzo di rete memorizzato nella cache AT associato a e.
Per ciascun tipo di oggetto, t, la cui definizione di nome, n, ha un prefisso di atEntry, un'istanza, i, di t è denominata da un OBJECT IDENTIFIER della forma n.y, dove y è il nome dell'equivalenza di traduzione degli indirizzi di cui i rappresenta informazioni.
Ad esempio, supponiamo di voler trovare l'indirizzo fisico di una voce nella tabella di traduzione degli indirizzi (cache ARP) associata a un indirizzo IP 89.1.1.42 e all'interfaccia 3. Di conseguenza, atPhysAddress.3.1.89.1.1.42 identificherebbe l'istanza desiderata.
3.2.6.3.3 ipAddrTable Object Type Names
Il nome di un elemento di rete indirizzabile IP, x, è l'OBJECT IDENTIFIER della forma a.b.c.d tale che a.b.c.d è il valore (nella consueta notazione a "punti") di quella istanza del tipo di oggetto ipAdEntAddr associata a x.
Per ciascun tipo di oggetto, t, la cui definizione di nome, n, ha un prefisso di ipAddrEntry, un'istanza, i, di t è denominata da un OBJECT IDENTIFIER della forma n.y, dove y è il nome dell'elemento di rete indirizzabile IP di cui i rappresenta informazioni.
Ad esempio, supponiamo di voler trovare la maschera di rete di una voce nella tabella delle interfacce IP associata a un indirizzo IP 89.1.1.42. Di conseguenza, ipAdEntNetMask.89.1.1.42 identificherebbe l'istanza desiderata.
3.2.6.3.4 ipRoutingTable Object Type Names
Il nome di una rotta IP, x, è l'OBJECT IDENTIFIER della forma a.b.c.d tale che a.b.c.d è il valore (nella consueta notazione a "punti") di quella istanza del tipo di oggetto ipRouteDest associata a x.
Per ciascun tipo di oggetto, t, la cui definizione di nome, n, ha un prefisso di ipRoutingEntry, un'istanza, i, di t è denominata da un OBJECT IDENTIFIER della forma n.y, dove y è il nome della rotta IP di cui i rappresenta informazioni.
Ad esempio, supponiamo di voler trovare il successivo hop di una voce nella tabella di routing IP associata alla destinazione 89.1.1.42. Di conseguenza, ipRouteNextHop.89.1.1.42 identificherebbe l'istanza desiderata.
3.2.6.3.5 tcpConnTable Object Type Names
Il nome di una connessione TCP, x, è l'OBJECT IDENTIFIER della forma a.b.c.d.e.f.g.h.i.j tale che a.b.c.d è il valore (nella consueta notazione a "punti") di quella istanza del tipo di oggetto tcpConnLocalAddress associata a x e tale che f.g.h.i è il valore (nella consueta notazione a "punti") di quella istanza del tipo di oggetto tcpConnRemoteAddress associata a x e tale che e è il valore di quella istanza del tipo di oggetto tcpConnLocalPort associata a x e tale che j è il valore di quella istanza del tipo di oggetto tcpConnRemotePort associata a x.
Per ciascun tipo di oggetto, t, la cui definizione di nome, n, ha un prefisso di tcpConnEntry, un'istanza, i, di t è denominata da un OBJECT IDENTIFIER della forma n.y, dove y è il nome della connessione TCP di cui i rappresenta informazioni.
Ad esempio, supponiamo di voler trovare lo stato di una connessione TCP tra l'indirizzo locale 89.1.1.42 sulla porta TCP 21 e l'indirizzo remoto 10.0.0.51 sulla porta TCP 2059. Di conseguenza, tcpConnState.89.1.1.42.21.10.0.0.51.2059 identificherebbe l'istanza desiderata.
3.2.6.3.6 egpNeighTable Object Type Names
Il nome di un vicino EGP, x, è l'OBJECT IDENTIFIER della forma a.b.c.d tale che a.b.c.d è il valore (nella consueta notazione a "punti") di quella istanza del tipo di oggetto egpNeighAddr associata a x.
Per ciascun tipo di oggetto, t, la cui definizione di nome, n, ha un prefisso di egpNeighEntry, un'istanza, i, di t è denominata da un OBJECT IDENTIFIER della forma n.y, dove y è il nome del vicino EGP di cui i rappresenta informazioni.
Ad esempio, supponiamo di voler trovare lo stato del vicino per l'indirizzo IP 89.1.1.42. Di conseguenza, egpNeighState.89.1.1.42 identificherebbe l'istanza desiderata.
Return: RFC 1157 Home