Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D La Corte in Rete
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Giorgio Ventre » 9.SNMP - Parte I


Indice della lezione

  • Riproporre le prove pratiche in prospettiva teorica
  • Familiarizzare col linguaggio utilizzato in ambito SNMP
  • Dettagli relativi al protocollo SNMP

Obiettivi di SNMP

  • Semplicità (bassi costi di implementazione): numero limitato di primitive, meccanismi elementari, in particolare lato Agent
  • Ubiquità (stessa tecnologia per una stampante o un Cray)
  • Estendibilità (possibilità di definire nuove MIB)
  • Rappresentazione dei dati indipendente dalla piattaforma
  • Robustezza (scelta di UDP, connectionless protocol)
  • Indipendenza da altri servizi di rete (DNS, NIS…)
  • Standard internazionale (“vendor-independent”)

Storia

  • 1988: Simple Network Management Protocol (SNMP) – proposed
  • 1990: Simple Network Management Protocol – standard
  • 1991: Management Information Base II – standard
  • 1993: SNMPv2 (Party/Context) – historical
  • 1996: SNMPv2 (Communities) – draft/experimental
  • 1998: SNMPv3 (User-based) – draft
  • SNMPv1 molto diffusa in ambito reti dati
  • SNMPv2 ha portato alcuni miglioramenti, ma non ha raggiunto gli obiettivi e non è diventato uno standard
  • SNMPv3 accettato, ma ancora poco usato

Processo di standardizzazione IETF


RFC relative ad SNMP

  • RFC 1155: SMI
  • RFC 1157: specifica formale di SNMPv1
  • RFC 1213: definizione MIB II
  • RFC 1215 (non standard): definizione trap
  • RFC 1441: SNMPv2
  • RFC 2271-2275: SNMPv3
  • tante altre RFC che definiscono altre MIB

Il protocollo SNMP

  • Messaggi scambiati tra Agent e Manager chiamati PDU (Protocol Data Unit)
  • Viaggiano sul protocollo UDP
  • I dati richiesti o forniti vengono codificati secondo le BER (Basic Encoding Rules) per renderli indipendenti dalla rappresentazione interna di ciascun apparato

Il protocollo SNMP


SNMP PDU

  • I tipi di messaggio si chiamano primitive
  • 3 primitive Manager → Agent
    • GetRequest
    • GetNextRequest
    • SetRequest
  • 1 primitiva Agent Manager
    • Trap

SNMP: agent-manager interaction


Struttura della PDU


Campi dell PDU

  • Version: vale 1 per SNMPv1
  • Community: “password” di autenticazione in chiaro
  • PDU Type: non è un vero campo del messaggio, ma una “meta-informazione” di tipo ASN.1 del messaggio…
  • Request ID: ID univoco per ogni richiesta; permette di appaiare le risposte (in caso di perdita di sequenza)
  • Error Status: vale 0 nelle richieste, e nelle risposte fornisce un esito della richiesta:

Campi dell PDU

  • Error Index: vale 0 nelle richieste; nelle risposte, è non-nullo in caso di errore, e dà l’indice della prima variabile che ha causato l’errore
  • Variable Bindings (varbinds): lista di coppie nome/valore. Nelle GetRequest e GetNextRequest il valore è nullo.
    • è quindi possibile richiedere più variabili in contemporanea
    • viene eseguita la stessa operazione (get, get-next, set) su tutte le variabili
    • permette di limitare il numero di richieste da fare e gli scambi manager-agent
    • utilizzato molto per la scansione delle tabelle…

Struttura della Trap


Campi della Trap

  • Enterprise: basato sulla variabile sysObjectID, permette di individuare il tipo di apparato/sottosistema originario
  • Agent Address: indirizzo IP dell’agent generatore
  • Generic Trap: tipo di trap tra un insieme predefinito
  • Specific Trap: tipo di trap non standard
  • Timestamp: indica il momento in cui è stata inviata la trap
  • Variable bindings: come per le altre PDU

Identificazione di una variabile

  • Ogni variabile è identificata dalla sua “posizione” nell’albero di naming di una MIB.
  • L’identificativo di una variabile e’ rappresentato dall’OBJECT IDENTIFIER
  • SNMPv1 permette solo la gestione di variabili scalari. Le uniche strutture dati composte permesse sono le tabelle, che vengono rappresentate come variabili indicizzate.

Che cos’è una MIB

  • La MIB non è un database…
  • E’ una definizione dell’informazione gestita (“specifica” dell’interfaccia)
  • Si rappresenta come una lista ordinata di valori (vedi il meccanismo della getNextRequest)
  • L’agent non è l’entità gestita (managed device), ma il componente software che conosce le informazioni locali da gestire e le trasforma in forma compatibile con SNMP
  • La MIB non è l’entità gestita, ma solo la sua modellazione

MIB: esempio


Object identifier

  • E’ l’identificativo univoco di un nodo dell’albero
  • Si esprime con la concatenazione degli identificativi dei nodi su tutta la gerarchia (fino alla radice)
  • In notazione simbolica, si usa il punto come separatore
  • Ad esempio: la variabile upTime ha object identifier: 1.2.2
  • Per accedere al valore della variabile, bisogna indicare che si accede ad una istanza dell’oggetto (Instance Identifier)
  • per questo va aggiunto uno zero finale: 1.2.2.0
  • Per le tabelle… ne riparleremo!

Object identifier

  • Se ogni nodo dell’albero è numerato in maniera univoca sotto ad uno stesso padre, allora ogni nodo può essere individuato univocamente
  • Si definisce una relazione di ordine di tipo lessicografico, basato sui valori numerici dell’identificativo dei nodi
  • La comparazione parte dalla radice, livello per livello
  • In questo modo:
    • 1.2.2 > 1.1
    • 1.3 > 1.2.2
    • 1.5.10 > 1.5.2
    • 1.1.0 > 1.1

SMI: obiettivi

  • Per consentire l’interoperabilità delle varie implementazioni agent e manager, è necessario definire senza alcuna ambiguità:
    • la struttura della MIB (in modo che sia univoco il mapping tra un object identifier e la semantica associata)
    • la rappresentazione binaria dei valori scambiati
  • Il primo obiettivo si raggiunge definendo un linguaggio o notazione astratta di descrizione della struttura della informazione gestita
  • Il secondo obiettivo si raggiunge definendo le modalità di codifica e trasmissione dell’informazione nei messaggio SNMP (BER — Basic Encoding Rules)

Abstract Syntax/Transfer Syntax


ASN.1

  • OSI specifica gli oggetti astratti con una notazione definita nella raccomandazione X.208: ASN.1 (Abstract Syntax Notation One)
  • ASN.1 serve a definire i tipi astratti e i valori
  • Un tipo è un insieme di valori (per certi tipi è un insieme finito, per altri è infinito)
  • SNMP utilizza un sottinsieme di ASN.1

Alcune strutture ASN.1

  • Simple Type: un tipo semplice è definito specificando direttamente l’insieme dei suoi valori. Sono tipi atomici. Tutti gli altri tipi sono definiti in base ai tipi semplici.
  • Structured Type: un tipo strutturato è costituito da componenti e permette di costruire tipi di dati complessi.
  • Macro: notazione per estendere i tipi ASN.1 in maniera arbitraria.
  • Module: insieme di definizioni utilizzabili da altri moduli.

ASN.1 modulo


Tipi ASN.1

  • I tipi ASN.1 utilizzati in SNMP sono di due classi:
    • UNIVERSAL (definiti nella X.208):
      • INTEGER (2)
      • OCTET STRING (4)
      • NULL (5)
      • OBJECT IDENTIFIER (6)
      • SEQUENCE, SEQUENCE OF (16)
    • APPLICATION (definite nelle RFC):
      • IpAddress: indirizzo a 32 bit
      • Counter: intero positivo (32 bit) che può solo essere incrementato
      • Gauge: intero positivo (32 bit) che può crescere e decrescere
      • TimeTicks: intero positivo che conta il tempo in centesimi di secondo
      • Opaque: dati binari senza formato esplicito

Tipi ASN.1

  • Non c’è tipo “enumerativo”
  • Una lista di possibili valori viene fatta con il tipo INTEGER
  • Il valore 0 non viene usato (per convenzione)
  • Si possono usare solo i valori elencati (in caso si deve quindi prevedere un valore speciale “altro”)
  • Ad esempio: vedi figura

Notazione ASN.1

  • TestoAlcune definizioni chiavi sono fatte nella RFC 1155, nonché la 1212 (e.g. le macros), che vengono riutilizzate (attraverso la clausola IMPORT) nelle altre definizioni di MIB
  • Definizione di nodi dell’albero: vedi figura in alto
  • Definizione di tipi: vedi figura in basso

Notazione ASN.1


Notazione ASN.1

  • Quando si definisce un nodo:
    • SYNTAX: un tipo ASN.1 (e.g. INTEGER, DisplayString)
    • ACCESS: tipo di accesso consentito (read-write, read-only, write-only, not-accessible)
    • STATUS: supporto richiesto alle implementazioni (mandatory, optional, deprecated, obsolete)
    • DESCRIPTION: serve a fini di documentazione

BER

  • OSI definisce la modalità di codifica binaria nella raccomandazione X.209: BER (Basic Encoding Rules)
  • La codifica definita dalle BER si basa sulla struttura type-length-value (TLV)
    • Type: indica il tipo, e se l’encoding è primitivo o strutturato.
    • Length: indica la lunghezza della rappresentazione
    • Value: la rappresentazione del valore del tipo ASN.1 come sequenza di ottetti.
  • La struttura è ricorsiva: per ogni valore ASN.1 costituito da uno o più componenti, il campo V della sua TLV consiste, a sua volta, di una o più TLV.

Metodi di codifica

  • Primitive, Definite-Length Encoding
    • Utilizzato per tipi semplici.
  • Constructed, Definite-Length Encoding
    • Utilizzato per tipi strutturati (p.e. SEQUENCE, SEQUENCE-OF,…)
  • Constructed, Indefinite-Length Encoding
    • Utilizzato per dati strutturati o stringhe la cui lunghezza non è nota a priori.

Esempi di codifica


Object identifier rivisited

  • Esiste una notazione alternativa per l’identificazione dei nodi: la notazione simbolica
  • Si basa sull’identificazione simbolica dei nodi nelle definizioni ASN.1 dei moduli di MIB dell’SMI
  • è possibile:
    • sostituire ogni numero di nodo con la notazione simbolica corrispondente: iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0
    • fare a meno di tutto il path dalla radice e scrivere semplicemente: sysDescr.0
  • Attenzione che non è quello che viene trasmesso in rete (bensì la codifica fatta secondo le Basic Encoding Rules…)

SNMP GetRequest


SNMP GetRequest

  • Permette di richiedere il valore di una o più variabili di MIB
  • Possibili errori:
    • noSuchName: l’oggetto non esiste o non è una foglia dell’albero
    • tooBig: la risposta non sta nella PDU di risposta
    • genErr: errore generico, tutti gli altri casi

SNMP GetRequest

  • Esempi:
    • get(1.1.0) → response (1.1.0 → 130.89.16.2)
    • get(1.2.0)→ response (Error-Status = noSuchName)
    • get(1.1) → response(Error-Status = noSuchName)
    • get(1.1.0; 1.2.2.0)→ response(1.1.0 → 130.89.16.2; 1.2.2.0 → 23874383)

SNMP SetRequest


SNMP SetRequest

  • Per assegnare un valore a istanze di variabili già esistenti, o per comandare azioni
  • Possibili errori:
    • noSuchName: l’oggetto non esiste o non è una foglia dell’albero
    • badValue: valore fornito inadeguato per il tipo
    • tooBig: la risposta non sta nella PDU di risposta
    • genErr: errore generico, tutti gli altri casi

SNMP SetRequest

  • Esempi:
  • set(1.2.1.0 → my-printer) →response(noError, 1.2.1.0 → my-printer)
  • set(1.2.1.0 → my-printer, 1.2.2.0 → 0) → response(noSuchName, error-index=2)

UpTime non e’ scrivibile…

SNMP GetNextRequest


SNMP GetNextRequest

  • Restituisce il nome e il valore della successiva istanza di variabile del MIB; è usata per accedere alla struttura del MIB, e per navigare tabelle.
  • Possibili errori:
    • noSuchName: il MIB è stato scandito interamente
    • tooBig: la risposta non sta nella PDU di risposta
    • genErr: errore generico, tutti gli altri casi

SNMP GetNextRequest

  • Esempi:
    • get-next(1.1.0)→ response (1.2.1.0 → printer-1)
    • get-next(1.2.1.0)→ response (1.2.2.0 → 23874383)
    • get-next(1) → response(1.1.0 → 130.89.16.2)
    • get-next(1.4)→ response(Error-Status = noSuchName)

SNMP Trap


SNMP Trap

  • Segnala un evento.
  • La ricezione di una trap non è confermata (unreliable).
  • Gli Agent possono essere configurati in modo da:
    • non emettere traps
    • emettere traps solo verso manager specifici

Impatto dell’uso di UDP

  • UDP è connectionless e unreliable (non affidabile): l’invio di un messaggio non significa la garanzia della sua consegna
  • → fatta una richiesta SNMP, la risposta arriva in maniera asincrona, senza garanzia
  • Vanno messi in piedi meccanismi di timeout e di retry per simulare una interazione affidabile (quello che fa TCP)
  • Ma rimane a carico dello strato SNMP (più leggero di TCP)
  • Il fatto di rimanere su UDP dà robustezza al meccanismo (in particolare in condizioni critiche, quali sono quelle di una rete in situazione di “crisi”)

Interazione SNMP: scenario 1


Interazione SNMP: scenario 2


Interazione SNMP: scenario 3


Interazione SNMP: scenario 4


Interazione SNMP: parametri

  • Timeout: tempo trascorso prima di ritentare
    • non deve essere troppo lungo, per consentire un rinvio rapido in caso di non risposta, ne troppo corto per evitare rinvii inutili (vedi scenario 3)
  • Retry count: numero di tentativi prima di dichiarare fallita la connessione
    • non deve essere troppo basso, per dare un minimo di affidabilità, ne troppo alto, per non sovracaricare la rete di richieste

Proxy management

  • proxy” in inglese = nel nome di qualcuno
  • un proxy agent è un agent SNMP di cui la MIB non rappresenta informazioni di gestione dell’apparato su cui gira
  • traduce un protocollo proprietario in SNMP
  • aggrega le informazioni di basso livello in informazioni di più alto livello

Meccanismi di monitoraggio

  • Un manager SNMP monitora lo stato degli apparati attraverso una interrogazione periodica di opportune variabili di stato (polling)
  • Trade-off sulla scelta della periodicità e delle variabili interrogate (traffico generato in rete vs. qualità dell’info.)
  • Le trap SNMP vengono in aiuto (in maniera unreliable) in quanto segnalano i casi eccezionali nel momento in cui accadono
  • Trap-directed polling: il manager adegua la sua politica di polling su ricezione di trap (e.g. interrogazione completa + aumento frequenza di polling, ecc.)

SNMPv1: Sicurezza

  • La gestione della sicurezza da parte del protocollo SNMPv1 è estremamente elementare. Approcci più adeguati sono definiti per le versioni successive: SNMPv2 e SNMPv3.
  • Il concetto fondamentale è quello di community, a cui sono associati dei diritti di accesso READ-ONLY o READ-WRITE.
  • La gestione delle community non viene specificata dagli standard ed è quindi lasciata all’implementazione. Lo standard specifica solo che la community è una stringa che va trasmessa con il messaggio SNMP.
  • La community viaggia in chiaro sulla rete…

SNMPv1: Sicurezza

  • Per limitare i rischi, alcune misure:
    • utilizzare password non banali, e cambiare spesso
    • configurare l’Agent ad inviare le trap di authenticationFailure
    • configurare la rete (con filtri o firewalls) per impedire il traffico SNMP al di fuori dai percorsi Manager-Agent
  • Nella realtà, gli apparati forniscono anche meccanismi di ACL (Access Control List), dove vanno inseriti gli indirizzi dei manager di fiducia.

MIB–II Organization


Relevant data in MIB-II

  • sysUpTime
    • Tempo (in centesimi di secondo) trascorso da quando la porzione del sistema per la gestione della rete è stata reinizializzata
  • ifspeed
    • Banda corrente dell’interfaccia, in bit per secondo (esempio: Ethernet 10.000.000; Fast Ethernet 100.000.000)
  • ifInOctets/ifOutOctets
    • Numero totale di ottetti (byte) ricevuti sul/trasmessi dall’interfaccia, inclusi caratteri di definizione
  • ifInUcastPkt/ifUcastPkts
    • Numero di pacchetti subnet-unicast inbound/outbound
  • ifInNUcastPkts/ifOutNUcastPkts
    • Numero di pacchetti subnet-nonunicast inbound/outbound (broadcast + multicast)
  • ifInDiscard/ifOutDiscard
    • Numero di pacchetti inbound/outbound cancellati nel caso di nessun errore rilevato (esempio: in caso di congestione)

Counters rollover

  • Warning: tutti i counter in MIB-II sono interi a 32 bit, quindi eseguono un conteggio modulo 32!
  • Massimo intero non negativo rappresentabile: 4.294.967.295=232-1
  • Alla velocità della Fast Ethernet i contatori possono riazzerarsi in 5,8 minuti (348 secondi)
  • Gli NMS risolvono questo problema campionando il contatore ad una velocità di campionamento più bassa rispetto al più basso rollover possibile. Se un NMS campiona abbastanza spesso, può sempre rilevare un riazzeramento del contatore e quindi compensarlo
  • Il sysUpTime si riazzera ogni 487 giorni

Counters rollover (esempio)

Un NMS sta misurando l’ifInUcastPkts su una Fast-Ethernet. Considerato che il periodo di campionamento è inferiore rispetto al minimo tempo di riazzeramento del contatore (non più di un riazzeramento può verificarsi tra due campioni successivi), se un valore campionato V2 è minore del valore previsto V1, vuol dire che si è verificato un riazzeramento. Quindi, il valore corretto per l’ifInUcastPkts è:

ifInUcastPkts = (232 –V1) + V2

Example:

V1 = 4,292,824,677

V2 = 2,785

ifInUcastPkts = 2,145,404 = (4,294,967,296 – 4,292,824,677) + 2,785


MIB-II Interface Extension

  • L’RFC1573 (1994) definisce un nuovo insieme di oggetti come estensione dell’originale MIB-II
  • Molte di queste estensioni cadono nell’Interface Group
  • Principali miglioramenti
    • Contatori a 64 bit
    • Differenti contatori per pacchetti multicast e broadcast
    • Esempio: InUcastPkts, InMulticastPkts e InBroadcastPkts

Ethernet-Specific MIB

  • Gli oggetti MIB-II appena presentati possono essere applicati non solo ad Ethernet, ma anche a FDDI, Token Ring, etc.
  • L’RFC1650 definisce un insieme di oggetti utilizzabili unicamente per interfacce Ethernet-like (interfacce basate su CSMA/CD)
  • Esempio di oggetti Ethernet-specific:
    • AlignmentErrors
    • FCSErrors
    • SingleCollisionFrames
    • MultipleCollisionFrames
    • LateCollisions
  • Nota
    • Se il LateCollisions counter è diverso da zero, il diametro di rete del segmento è troppo grande!

SNMP evolution

  • SNMPv1 è stato originariamente definito nell’RFC1157 (1990)
  • Nel 1993 un insieme di Internet draft definirono SNMPv2
  • Ancora nel 1993, fu definita l’estensione RMON allo standard MIB
  • SNMPv2
    • Fornisce strumenti più potenti per la gestione dei dati
    • Il draft originale proponeva un modello per la security migliorato
    • La security fu cancellata nell’RFC relativo a SNMPv2 del 1996
  • RMON
    • Consente di raccogliere statistiche per una intera rete, mentre MIB-II può fare riferimento solo a statistiche relative a singoli device

Network Management

Applications

Calcolo della dell’utilizzo di rete

  • L’utilizzo delle rete (medio) nell’intervallo (t0, t1) per un segmento Fast Ethernet connesso alla porta di uno switch, corrisponde al numero totale di bit trasmessi nel dominio di collisione in frame nonerror durante (t0, t1), diviso per il numero totale di bit trasmettibili su tale periodo di tempo alla velocità di banda (vedi figura)
  • La funzione delta(later, earlier) calcola la differenza tra il valore campionato dopo ed il valore campionato prima. La funzione delta considera inoltre i counter rollover

totalOctets=(ifInOctets + ifOutOctets)

ifSpeed=100.000.000 per un segmento FastEthernet


Calcolo dell’utilizzo di rete (esempio)

  • Nota: l’NMS è settato per interrogare il contatore ogni 5 minuti
  • Tuttavia, considerata la polling nature del software NMS, l’effettiva differenza t1-t0 risulta essere 1,86 secondi più grande rispetto al valore nominale
Valore nominale (300 sec = 30.000 sysUpTime tick)

Altre interessanti statistiche

  • Frame di broadcast trasmesse al secondo su un segmento
  • Frame di broadcast inoltrate al secondo da altri segmenti ad un segmento
  • Frame unicast generate al secondo da un segmento
  • Frame unicast inoltrate al secondo verso un segmento
  • Byte generati al secondo da un segmento
  • Nota
    • Tali statistiche sono espresse per secondo, ma vengono in realtà calcolate come valore medio su un intervallo lungo (esempio 5 minuti)

Network Management Applications


Dyscovery e Topology Map


MIB Node Viewer


MIB Browser


SNMP Walker


SNMP Graph Viewer


Conclusione

  • SNMPv1 è un protocollo semplice, basato sul polling (di variabili critiche) e che modella gli oggetti gestiti in termini di variabili scalari o tabelle.
  • La sua semplicità è stata il fattore principale del suo successo. Tuttavia, a lungo andare si è anche rivelata l’inconveniente principale nell’estensione dell’utilizzo di SNMPv1 a realtà diverse dalle LAN.

Conclusione

  • Le limitazioni principali di SNMP si possono identificare in:
    • Gestione della sicurezza insufficiente
    • Strutture dati troppo elementari per modellare in maniera semplice realtà complesse
    • Numero di eventi asincroni definiti troppo ridotto
    • Primitive insufficienti per garantire prestazioni adeguate
  • Queste limitazioni hanno portato alla specifica di SNMPv2 e SNMPv3

SNMP – Parte II

  • Evidenziare le problematiche di gestione delle reti
  • Doppio approccio top-down e bottom-up
  • Definizione di un’architettura di gestione
  • Cenno sulla gestione integrata

I materiali di supporto della lezione

Cisco Network Management System: Best Practices White Paper

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion

Fatal error: Call to undefined function federicaDebug() in /usr/local/apache/htdocs/html/footer.php on line 93