Passa al contenuto principale

3. Elements Of Procedure

Le seguenti sezioni descrivono le procedure seguite da ciascuno dei cinque tipi di applicazioni SNMP durante la generazione e il processamento dei messaggi SNMP.

3.1. Applicazioni Command Generator​

Un'applicazione command generator utilizza il sottosistema di processamento dei messaggi SNMP per passare messaggi SNMP a un'applicazione SNMP remota.

Il command generator deve essere in grado di determinare il dominio di trasporto e l'indirizzo di trasporto dell'applicazione remota. Il metodo con cui questo viene realizzato è dipendente dall'implementazione e al di fuori dello scopo di questo documento.

Il command generator deve essere in grado di determinare i parametri appropriati del messaggio SNMP (message processing model, security model, security level e security name) da utilizzare quando comunica con l'applicazione remota. Il metodo con cui questo viene realizzato è dipendente dall'implementazione e al di fuori dello scopo di questo documento.

3.1.1. Generazione di una Richiesta di Comando​

Per inviare una richiesta di comando SNMP, l'applicazione command generator:

  1. Utilizza le sue informazioni di configurazione locali per determinare:

    • Dominio di trasporto e indirizzo di trasporto
    • Message processing model
    • Security model
    • Security name
    • Security level
    • Context engine ID (contextEngineID)
    • Context name (contextName)
    • La PDU appropriata (GetRequest, GetNextRequest, GetBulkRequest o SetRequest)

  2. Invoca la primitiva send PDU del sottosistema di processamento dei messaggi, passando:

    • Dominio di trasporto e indirizzo di trasporto
    • Message processing model
    • Security model
    • Security name
    • Security level
    • contextEngineID
    • contextName
    • PDU

  3. Il sottosistema di processamento dei messaggi restituisce un'indicazione di stato. Se viene restituito un errore, il command generator dovrebbe gestire l'errore appropriatamente.

3.1.2. Processamento di una Risposta​

Quando un command generator riceve una risposta:

  1. Il sottosistema di processamento dei messaggi invoca la primitiva receive PDU del command generator, passando:

    • Message processing model
    • Security model
    • Security name
    • Security level
    • contextEngineID
    • contextName
    • PDU
    • Dimensione massima (maxSizeResponseScopedPDU)
    • Informazioni di stato

  2. Il command generator verifica che la risposta corrisponda a una richiesta in sospeso (tramite request-id).

  3. Il command generator controlla l'error-status nella risposta. Se il campo error-status è diverso da zero, si è verificato un errore.

  4. Il command generator processa la lista variable-bindings nella risposta.

3.1.3. Timeout e Tentativi​

Se non viene ricevuta alcuna risposta entro un ragionevole periodo di tempo, il command generator può ritrasmettere la richiesta. Il numero di tentativi e i valori di timeout sono determinati dalla configurazione locale o dalla policy.

Per protocolli di trasporto affidabili (come TCP), il livello di trasporto stesso può fornire la ritrasmissione. In tali casi, i tentativi a livello di applicazione possono essere non necessari o inappropriati.

3.2. Applicazioni Command Responder​

Un'applicazione command responder riceve richieste di comando SNMP e genera risposte appropriate.

3.2.1. Processamento di una Richiesta​

Quando un command responder riceve una richiesta:

  1. Il sottosistema di processamento dei messaggi invoca la primitiva receive PDU del command responder, passando:

    • Message processing model
    • Security model
    • Security name
    • Security level
    • contextEngineID
    • contextName
    • PDU
    • Dimensione massima (maxSizeResponseScopedPDU)
    • Informazioni di stato

  2. Il command responder verifica che il contextEngineID identifichi il motore SNMP locale. In caso contrario, la richiesta viene scartata.

  3. Il command responder utilizza il sottosistema di controllo degli accessi (come VACM definito in RFC 3415) per determinare se il security name è autorizzato a eseguire l'operazione richiesta.

  4. Il command responder processa la PDU:

    • GetRequest: Recupera i valori degli oggetti MIB richiesti
    • GetNextRequest: Recupera il prossimo oggetto MIB lessicograficamente successivo al nome dell'oggetto richiesto
    • GetBulkRequest: Esegue un recupero multi-variabile ottimizzato
    • SetRequest: Modifica i valori degli oggetti MIB specificati

  5. Il command responder costruisce una PDU di risposta contenente:

    • Lo stesso request-id della richiesta
    • Error-status (noError o un codice di errore appropriato)
    • Error-index (se si è verificato un errore, indica quale variable-binding ha causato l'errore)
    • Lista variable-bindings (per operazioni Get, contiene i valori recuperati; per operazioni Set, contiene le variabili impostate)

3.2.2. Generazione di una Risposta​

Il command responder genera una risposta:

  1. Costruendo una Response-PDU con l'appropriato error-status, error-index e lista variable-bindings.

  2. Invocando la primitiva return response PDU del sottosistema di processamento dei messaggi, passando:

    • Message processing model (stesso della richiesta)
    • Security model (stesso della richiesta)
    • Security name (stesso della richiesta)
    • Security level (stesso della richiesta)
    • contextEngineID (stesso della richiesta)
    • contextName (stesso della richiesta)
    • PDU (la PDU di risposta)
    • Dimensione massima (il maxSizeResponseScopedPDU della richiesta)
    • State reference (ottenuto dal processamento della richiesta)

  3. Il sottosistema di processamento dei messaggi gestisce la formattazione e la trasmissione del messaggio di risposta.

3.2.3. Gestione degli Errori​

Se si verifica un errore durante il processamento della richiesta, il command responder deve impostare un error-status appropriato nella PDU di risposta:

  • tooBig: Il messaggio di risposta è troppo grande per essere trasmesso entro i vincoli di dimensione massima del messaggio
  • noSuchName: L'oggetto richiesto non esiste (solo SNMPv1)
  • badValue: Il valore fornito è inappropriato per l'operazione richiesta (solo SNMPv1)
  • readOnly: Tentativo di modificare un oggetto in sola lettura
  • genErr: Si è verificato un errore generale
  • noAccess: Accesso negato (SNMPv2 e successivi)
  • wrongType: La variabile ha il tipo sbagliato (SNMPv2 e successivi)
  • wrongLength: Il valore ha la lunghezza sbagliata (SNMPv2 e successivi)
  • wrongEncoding: Il valore ha la codifica sbagliata (SNMPv2 e successivi)
  • wrongValue: Il valore è errato (SNMPv2 e successivi)
  • noCreation: La creazione non è consentita (SNMPv2 e successivi)
  • inconsistentValue: Il valore è inconsistente (SNMPv2 e successivi)
  • resourceUnavailable: Le risorse non sono disponibili (SNMPv2 e successivi)
  • commitFailed: Commit fallito (SNMPv2 e successivi)
  • undoFailed: Undo fallito (SNMPv2 e successivi)
  • authorizationError: Errore di autorizzazione (SNMPv2 e successivi)
  • notWritable: L'oggetto non è scrivibile (SNMPv2 e successivi)
  • inconsistentName: Il nome è inconsistente (SNMPv2 e successivi)

3.3. Applicazioni Notification Originator​

Un'applicazione notification originator genera messaggi di notifica SNMP (trap o inform request).

3.3.1. Generazione di una Notifica​

Per inviare una notifica SNMP, il notification originator:

  1. Determina l'insieme dei management target che dovrebbero ricevere questa notifica. Questo viene tipicamente fatto consultando l'SNMP-TARGET-MIB e l'SNMP-NOTIFICATION-MIB.

  2. Per ogni management target selezionato:

    a. Determina il dominio di trasporto e l'indirizzo di trasporto

    b. Determina i parametri del messaggio SNMP:

    • Message processing model
    • Security model
    • Security name
    • Security level

    c. Determina il tipo di notifica (trap o inform)

    d. Costruisce la PDU appropriata:

    • SNMPv2-Trap-PDU: Per notifiche non confermate
    • InformRequest-PDU: Per notifiche confermate

    e. La PDU dovrebbe contenere:

    • Variabile sysUpTime.0 (tempo dall'avvio del motore)
    • Variabile snmpTrapOID.0 (identificatore di oggetto della notifica)
    • Variable-bindings aggiuntivi per la notifica

    f. Invoca la primitiva send PDU del sottosistema di processamento dei messaggi

3.3.2. Processamento di una Risposta a un Inform Request​

Se il tipo di notifica è inform (InformRequest-PDU), il notification originator deve attendere una risposta:

  1. Se viene ricevuta una risposta entro il periodo di timeout:

    • Verificare che la risposta corrisponda all'inform request in sospeso (tramite request-id)
    • Controllare l'error-status
    • Confermare che la notifica è stata consegnata con successo

  2. Se non viene ricevuta alcuna risposta entro il periodo di timeout:

    • A seconda della policy di retry configurata, può ritrasmettere l'inform request
    • Oppure, registrare il fallimento localmente e abbandonare questo tentativo di consegna

  3. Per i trap (SNMPv2-Trap-PDU), non è attesa alcuna risposta, quindi il notification originator completa immediatamente dopo l'invio.

3.4. Applicazioni Notification Receiver​

Un'applicazione notification receiver riceve messaggi di notifica SNMP.

3.4.1. Processamento di una Notifica Ricevuta​

Quando un notification receiver riceve una notifica:

  1. Il sottosistema di processamento dei messaggi invoca la primitiva receive PDU del notification receiver, passando:

    • Message processing model
    • Security model
    • Security name
    • Security level
    • contextEngineID
    • contextName
    • PDU
    • Dimensione massima
    • Informazioni di stato

  2. Il notification receiver estrae le informazioni di notifica:

    • sysUpTime.0 (timestamp)
    • snmpTrapOID.0 (tipo di notifica)
    • Variable-bindings aggiuntivi (dati di notifica)

  3. Il notification receiver processa la notifica secondo la policy locale:

    • Registra in un file di log
    • Mostra un avviso
    • Attiva un'azione di risposta automatizzata
    • Inoltra ad altri sistemi di gestione

3.4.2. Risposta a un Inform Request​

Se viene ricevuto un InformRequest-PDU, il notification receiver deve generare una risposta:

  1. Costruire una Response-PDU contenente:

    • Lo stesso request-id della richiesta
    • Error-status (tipicamente noError)
    • Error-index (tipicamente 0)
    • Lista variable-bindings (tipicamente la stessa della richiesta)

  2. Invocare la primitiva return response PDU del sottosistema di processamento dei messaggi per inviare la risposta.

Per SNMPv2-Trap-PDU, non viene generata alcuna risposta.

3.5. Applicazioni Proxy Forwarder​

Un'applicazione proxy forwarder inoltra messaggi SNMP tra entità SNMP. I proxy forwarder possono eseguire traduzione di protocollo, traduzione di sicurezza o traduzione di vista delle informazioni di gestione.

Un'applicazione proxy forwarder esegue due tipi di inoltro:

  1. Request Forwarding: Inoltro di richieste di comando e loro risposte
  2. Notification Forwarding: Inoltro di messaggi di notifica

3.5.1. Request Forwarding​

Quando un proxy forwarder riceve una richiesta di comando:

  1. Il sottosistema di processamento dei messaggi invoca la primitiva receive PDU del proxy forwarder, passando i parametri della richiesta.

  2. Il proxy forwarder utilizza l'SNMP-PROXY-MIB per determinare come inoltrare la richiesta:

    a. Consulta la snmpProxyTable, utilizzando i parametri ricevuti come chiave:

    • contextEngineID
    • contextName
    • Dominio di trasporto e indirizzo di trasporto
    • Tipo di PDU

    b. Se viene trovata una voce corrispondente, estrae i parametri di inoltro:

    • Dominio di trasporto e indirizzo di trasporto target
    • Message processing model target
    • Security model target
    • Security name target
    • Security level target
    • contextEngineID target
    • contextName target

  3. Il proxy forwarder potrebbe aver bisogno di modificare la PDU per accomodare la versione SNMP target. Ad esempio:

    • SNMPv2 a SNMPv1: Convertire i codici error-status
    • SNMPv1 a SNMPv2: Convertire il formato trap PDU

  4. Il proxy forwarder invoca la primitiva send PDU del sottosistema di processamento dei messaggi per inoltrare la richiesta modificata al target.

  5. Quando viene ricevuta una risposta dal target:

    a. Potrebbe aver bisogno di modificare nuovamente la PDU di risposta per accomodare la versione SNMP del richiedente originale

    b. Invoca la primitiva return response PDU del sottosistema di processamento dei messaggi per inoltrare la risposta al richiedente originale

3.5.2. Notification Forwarding​

Quando un proxy forwarder riceve una notifica:

  1. Il sottosistema di processamento dei messaggi invoca la primitiva receive PDU del proxy forwarder, passando i parametri di notifica.

  2. Il proxy forwarder utilizza l'SNMP-PROXY-MIB per determinare come inoltrare la notifica:

    a. Consulta la snmpProxyTable, utilizzando i parametri ricevuti come chiave

    b. Se viene trovata una voce corrispondente, estrae i parametri di inoltro

  3. Il proxy forwarder potrebbe aver bisogno di modificare la PDU di notifica:

    • Trap SNMPv1 a trap SNMPv2: Convertire formato PDU e variable-bindings
    • Trap SNMPv2 a trap SNMPv1: Convertire formato PDU

  4. Il proxy forwarder invoca la primitiva send PDU del sottosistema di processamento dei messaggi per inoltrare la notifica al target.

  5. Se la notifica originale era un InformRequest-PDU e la notifica inoltrata è anche un InformRequest-PDU:

    a. Attendere una risposta dal target

    b. Quando viene ricevuta la risposta, inoltrare la risposta al notification originator originale

3.5.3. Considerazioni Speciali per i Proxy Forwarder​

I proxy forwarder devono gestire diversi casi speciali:

  1. Aggiustamento della Dimensione PDU: Se il target supporta una dimensione massima di messaggio inferiore alla richiesta originale, il proxy forwarder potrebbe dover restituire un errore tooBig o dividere la richiesta.

  2. Traduzione di Contesto: Il proxy forwarder potrebbe dover mappare tra diversi contextEngineID e contextName.

  3. Controllo degli Accessi: Il proxy forwarder applica le proprie policy di controllo degli accessi in aggiunta a qualsiasi controllo degli accessi al command responder target.

  4. Mappatura degli Errori: Durante la traduzione tra versioni SNMP, i codici di errore potrebbero dover essere mappati. Ad esempio, un errore noAccess di SNMPv2 potrebbe dover essere mappato a genErr in SNMPv1.

  5. Timeout e Tentativi: Il proxy forwarder potrebbe dover implementare il proprio meccanismo di timeout e retry per richieste inoltrate, indipendentemente dal timeout del richiedente originale.

  6. Filtraggio delle Notifiche: Per l'inoltro delle notifiche, il proxy forwarder può applicare regole di filtraggio per inoltrare selettivamente tipi specifici di notifiche.

Ultimo aggiornamento il