Modulo2Vers5.1

Reti di calcolatori: applicazioni
Secondo Modulo
Protocolli
RIP, DHCP, DNS,SNMP;
Tecniche di Natting
(vers. 5.1)
Docente: Claudio Covelli

Esercitatore: Stefano Setti
Trento, 15 ottobre 2010
Agenda modulo n.2
Protocollo RIP
Protocollo DHCP
Tecniche di Natting
Domain Name System (DNS)
SNMP
2
RIP (Routing Information Protocol)
Uno dei protocolli storici dello stack TCP/IP; progettato al PARC di Palo
Alto venne incluso in una delle prime versioni di Unix BSD e divenne
standard de facto
Un router può essere configurato in modo statico o dinamico
Nel primo caso la tabella di routing viene inizializzata, in modo automatico,
all'accensione, rilevando tutte le sottoreti direttamente collegate
La tabella viene quindi aggiornata, conoscendo la topologia della rete,
aggiungendo manualmente i next hop richiesti per raggiungere le reti non
direttamente collegate
3
192.168.4.0
R4
Tabella di routing di R1
192.168.2.0
Destination Gateway Interface R2
192.168.1.0/24 0.0.0.0 eth0
192.168.2.0/24 R2 eth1
eth1
192.168.3.0/24 R3 eth2
192.168.4.0/24 R2 eth1 192.168.3.0
eth0 R1
eth2 R3
192.168.1.0
Nota: Rx = indirizzo ip del router x sul link di collegamento punto a punto; nella tabella non sono riportate
per semplicità le reti di link fra i vari router 4
Quando il numero dei router cresce e la rete assume una certa complessità,
la gestione statica, oltre a comportare la possibilità di errori, costringe ad
interventi manuali di sistemazione delle tabelle di routing nel caso si
interrompa un link
Ad esempio se si interrompe il link fra R1 ed R3 occorre correggere la
tabella di routing di R1 per consentire il raggiungimento della rete
192.168.3.0 attraverso R2
5
192.168.4.0
R4
192.168.2.0
Destination Gateway Interface R2
192.168.1.0/24 0.0.0.0 eth0
192.168.2.0/24 R2 eth1
eth1
192.168.3.0/24 R2 eth1
192.168.4.0/24 R2 eth1 192.168.3.0
eth0 R1
eth2 R3
192.168.1.0
E' possibile evitare interventi manuali, ricorrendo ad una configurazione
dinamica delle tabelle di routing
Il protocollo RIP (V1 e V2) fornisce un esempio di tale configurazione e si
basa su un algoritmo di tipo distance vector (minimo numero di hop)
All'accensione il router popola la sua tabella di routing riportandovi, in
modo automatico, esclusivamente le reti direttamente collegate
Il router invia ogni 30 secondi, in modalità broadcast (RIP V1) o multicast
(RIP V2), a tutti i router direttamente collegati (adiacenti;neighbors), un
particolare messaggio (RIP Response) contenente la configurazione della
propria tabella di routing
Le informazioni vengono inviate, via UDP, alla wellknown port 520, Si
tratta quindi chiaramente di un protocollo di livello 7, anche se in molti 7
testi viene erroneamente definito protocollo di livello 3
192.168.4.0
R4
192.168.2.0
R2
eth1
192.168.3.0
eth0 R1
eth2 R3
192.168.1.0
Il router R1, all'accensione, comunica a R2 e R3 che ad esso è direttamente collegata la rete 192.168.1.0;
analogamente si comporterà R2 nei confronti di R1 ed R4 etc 8
Quest'operazione è ripetuta ad intervalli regolari (di norma 30 sec.)
Ogni router, analogamente, riceve ,sempre via RIP e ad intervalli regolari,
da tutti i router direttamente collegati (adiacenti), la configurazione
completa delle rispettive tabelle di routing
In tal modo ogni router riceverà, dai router adiacenti, le informazioni
necessarie a definire le modalità di raggiungimento delle reti ad esso non
direttamente collegate
Ad esempio il router R1 riceverà da R2 l'informazione di raggiungibilità,
attraverso quest'ultimo, delle reti 192.168.2.0 , 192.168.4.0 ed 192.168.3.0
9
In conclusione, viene a configurarsi in ogni router una tabella di routing le cui
destinazioni, a parte quelle direttamente collegate, sono state segnalate dai
router adiacenti
Se ci sono più percorsi per la stessa destinazione, il router memorizza, nella
tabella di routing quella che minimizza il numero di link (hop) necessari
(distance vector algorithm) per raggiungerla
Ad esempio la raggiungibilità di 192.168.3.0 viene comunicata ad R1 da R2 e
R3; mentre però tale destinazione è immediatamente raggiungibile da R3, per
R2 richiede il passaggio attraverso R4
L'ottimizzazione del numero di hop, pur essendo di semplice implementazione,
non corrisponde, spesso, alla migliore scelta; per reti molto complesse si usano,
pertanto, protocolli alternativi (diffuso è OSPF) basati su algoritmi più efficienti
che tengono conto non solo della topologia ma anche dello stato delle
10
connessioni
Per minimizzare il numero di hop, ogni router trasmette , agli adiacenti,
per ogni destinazione/netmask presente nella sua tabella di router, anche il
parametro metric che indica appunto il numero di hop ad esso necessari per
raggiungere la destinazione
Occorre però notare che il valore di metric, trasmesso tramite il protocollo
RIP, corrisponde a quello presente nella tabella di routing del mittente
incrementato di uno, per tener conto dell'hop esistente fra mittente e
destinatario (ad esempio la metrica per una rete direttamente collegata,
memorizzata nella tabella di routing con valore zero, viene trasmessa al
router adiacente con valore 1)
Ad esempio nella tabella di routing di R2
la destinazione 192.168.2.0 ha metrica 0 in quanto direttamente collegata
la destinazione 192.168.4.0 ha metrica 1 in quanto corrisponde al
valore trasmesso dal router R4 che vede tale rete come direttamente 11
collegata
Destination Gateway Interface Metrics
192.168.2.0/24 0.0.0.0 eth0 0 192.168.4.0
192.168.1.0/24 R1 eth1 1
192.168.3.0/24 R1 eth1 2 R4
192.168.4.0/24 R4 eth2 1
eth0
192.168.2.0 eth2
Destination Gateway Interface Metrics R2
eth1
192.168.1.0/24 0.0.0.0 eth0 0
192.168.2.0/24 R2 eth1 1
eth1
192.168.3.0/24 R3 eth2 1
192.168.3.0
192.168.4.0/24 R2 eth1 2
eth0 R1
eth2 R3
192.168.1.0
R2 informa a sua volta R1 che la rete 192.168.4.0 può essere da esso
raggiunta con metrica 2 (ossia il valore presente nella sua tabella di routing
incrementato di 1) ed R1 aggiorna di conseguenza la sua tabella di routing
Ovviamente se un altro router adiacente (es. R3) comunicasse una
destinazione 192.168.4.0 con valore di metrica minore, si considererebbe
quest'ultimo percorso
13
 Si è visto che ogni router aggiorna gli adiacenti ad intervalli regolari
(default 30 secondi)
 Se la metrica di una destinazione cambia improvvisamente (es. link down)
gli aggiornamenti vengono inviati immediatamente ai router adiacenti
(triggered updates)
 Dopo un certo lasso di tempo predefinito (180 secondi), a partire dalla
memorizzazione di una certa destinazione raggiungibile attraverso i router
adiacenti, se non si ricevono aggiornamenti, questa viene considerata
obsoleta (timeout) e viene inviata una richiesta (RIP request) ai router
adiacenti per un aggiornamento
 Esempio con Netsimk
14
rip version 2 packet (transport UDP; port 520)

Valori più importanti dei campi
Command (request/response)
Address Field Identifier (valore fisso corrispondente ad IP)
Destination IP network address
Destination subnet mask
Destination next hop
Destination metric
In un messaggio RIP V2 possono essere presenti fino a 25 destinazioni
15
Protocollo DHCP
Dynamic Host Configuration Protocol
Protocollo applicativo (livello 7) basato su UDP ed utilizzato per
l'assegnazione automatica ad una scheda di rete dei principali parametri
di configurazione :
ip address
subnet mask
default gateway
dns primario e secondario

16
Protocollo DHCP
DHCP
Vantaggi
Gestione centralizzata delle configurazioni
Si eliminano gli inevitabili errori di configurazione manuale (es. conflitti
nell'assegnazione degli indirizzi IP)
Lo stesso indirizzo viene riutilizzato da un altro host, alla scadenza del
lease time (vantaggio ora superato dall'indirizzamento privato)
Svantaggi
Si può creare un single point of failure, se non è disponibile una
soluzione ridondata, non solo in termini di server ma anche di percorsi
di rete
17
Protocollo RARP
DHCP costituisce l'evoluzione di precedenti protocolli
RARP: protocollo di livello 3 che assegna un indirizzo IP fisso in
base al MAC Address
Obsoleto: utilizzato in passato per host diskless
RARP usa gli stessi frame di ARP (cambiano solo gli opcode) e si
basa sulla presenza di un server che mantiene una tabella di
associazione fra gli indirizzi IP ed i MAC Address, gestita
manualmente e memorizzata su disco
Il client , al boot, invia in un frame Ethernet una richiesta specifica in
broadcast Ethernet
Il server risponde con un frame Ethernet inviato al MAC Address
richiedente e riportante l'indirizzo Ip assegnato
18
Protocollo RARP
Occorre un server RARP

per ogni sottorete,
in quanto RARP si basa
su broadcast
Ethernet
da www.tcpipguide.com
19
Protocollo RARP
MAC ADDRESS IP ADDRESS
00:01:27:45:67 192.168.0.1
opcode = 3 24:34:56:72:31:03 192.168.0.2
opcode = 4
20
Protocollo BOOTP
BOOTP
RARP è stato sostituito nel tempo dal protocollo BOOTP
RARP presenta infatti il grosso limite di fornire solo gli indirizzi IP
BOOTP: protocollo client server (livello 7) basato su UDP ed
utilizzato inizialmente per gli host diskless:
supera i limiti di RARP consentendo l'invio di tutti i parametri
necessari per la configurazione di rete
permette inoltre di indicare il percorso del file che contiene il
sistema operativo ed i driver necessari per avviare l'host (da
scaricare successivamente via TFTP)
non consente però assegnazione dinamica degli indirizzi IP;
l'indirizzo è assegnato in base al MAC richiedente
21
Protocollo BOOTP
BOOTP
l'host, appena collegato alla rete, trasmette, dalla porta 68 (quindi non
efemerale), una richiesta (BOOTREQUEST), riportante il suo MAC
Address, diretta alla porta UDP 67
Tale richiesta è inviata di norma in limited broadcast IP di sottorete
(255.255.255.255), in quanto il client non conosce l'indirizzo IP del
server (se il client conosce a priori il nome del server l'invio è
ovviamente di tipo unicast)
il server invia, a sua volta di norma in limited broadcast IP di sottorete
(il client non ha ancora un indirizzo IP), la risposta (BOOTREPLY)
alla porta UDP 68, ricavando l'indirizzo IP in base a MAC mittente
22
Protocollo BOOTP
Una parentesi sugli indirizzi IP speciali
Subnet ID Host ID Example Note

Limited broadcast ossia limitato
a tutti gli host della sottorete del
mittente; il router blocca sempre
all 1 all 1 255.255.255.255 tale broadcast
Broadcast to all subnets (es.
192.168.x.y); il router di default
blocca tale broadcast per
subnetid all 1 192.168.255.255 problemi di sicurezza
23
Protocollo BOOTP
BOOTP
limited
broadcast
MAC ADDRESS IP ADDRESS
limited 00:01:27:45:67 192.168.0.1
broadcast 24:34:56:72:31:03 192.168.0.2
24
Protocollo BOOTP
BOOTP
BOOTP usa quindi porte wellknown nei due sensi:
Host BOOTP
68 67
(client) Server
l'uso, per il client, di una porta non efemerale(>= 1024) si giustifica
per il fatto che non sarebbe corretto, da parte del server, inviare un
messaggio in limited broadcast ad una porta efemerale, in quanto
quest'ultima è univoca solo all'interno di uno specifico host
Altri client potrebbero infatti inviare richieste UDP usando come
porta mittente la stessa porta efemerale e questo comporta
ovviamente dei problemi
25
Protocollo BOOTP
BOOTP
solo i client che hanno inviato una BOOTREQUEST si attendono la
risposta sulla porta UDP 68 e questo limita il rischio di mandare
informazioni errate ai client
può comunque succedere che due client mandino
contemporaneamente una BOOTREQUEST e quindi ricevano ,
successivamente, la relativa risposta
i client BOOTP sono però sono realizzati in modo tale da scartare
ogni risposta non associata alla loro richiesta
ogni richiesta viene infatti numerata (transaction ID) e riportata
nella risposta
26
Protocollo BOOTP
BOOTP
da www.tcpipguide.com 27
Protocollo BOOTP
BOOTP
Vendor Specific Area:

inizialmente pensata per inviare parametri
proprietari, ora viene usata per inviare le
altre informazioni necessarie alla
configurazione:
1) Subnet mask
2) DNS primario e secondario
28
Protocollo DHCP
BOOTP
Il BOOTP server fornisce nella risposta i vari parametri di configurazione
(indirizzo IP, default gw etc)
L'indirizzo IP è assegnato, analogamente a RARP, sulla base di una
tabella di associazione biunivoca fra Mac Address ed indirizzi IP
Pertanto il protocollo funziona solo se tale Mac Address è stato inserito
dall'amministratore di rete; non è possibile un'assegnazione dinamica degli
indirizzi
BOOTP inoltre è pensato per una specifica sottorete; infatti di norma un
invio in modalità limited broadcast IP non è instradabile
29
Protocollo DHCP
BOOTP
Se si vuole un BOOTP server che gestisca più sottoreti occorre introdurre
configurazioni specifiche del router (Bootp agent relay) che consentano di
inoltrare la richiesta, inviata in broadcast alla porta 67 , trasformandola in
richiesta unicast diretta al server BOOTP
30
Protocollo DHCP
BOOTP
•Il router,configurato come bootp agent

relay, si comporta di fatto come un
proxy,intercettando la richiesta da
Device A e trasmettendola, in unicast,
verso il bootp server (Device D)
•L'invio unicast implica che il router sia
configurato in modo che conosca l'IP
address del Bootp server
•Alla ricezione della risposta da parte
del server , il router la ritrasmette in
limited broadcast alla rete dove è
situato l'host mittente (Device A)
31
Protocollo DHCP
DHCP
DHCP perfeziona il protocollo BOOTP consentendo un'allocazione
dinamica degli indirizzi IP, non più vincolati quindi ai MAC Address,
consentendo quindi una gestione più semplice della rete (laptop, palmari,
schede WIFI)
E' costituito da due componenti:
un protocollo standard di comunicazione client server basato su UDP
un meccanismo (non standardizzato) per l'assegnazione degli indirizzi IP
L'indirizzo IP viene assegnato per un certo intervallo di tempo (lease time)
che può anche avere valore infinito (allocazione automatica)
32
Protocollo DHCP
DHCP
Standard sempre più diffuso. Supporta:
allocazione statica (esiste una tabella predefinita di mapping fra
indirizzi IP e MAC Address)
allocazione dinamica (indirizzo IP assegnato in modo casuale da un
pool di indirizzi disponibili); ad esempio si assegna il primo libero
degli indirizzi compresi fra 192.168.2.10 e 192.168.2.254
Utilizza messaggi di request/reply molto simili al protocollo BOOTP,
ma standardizzando la Vendor Specific Area del messaggio BOOTP, ora
diventata campo standard (DHCP Options). Aggiunge inoltre nuovi
messaggi per aumentare le funzionalità rispetto a BOOTP
33
Protocollo DHCP
DHCP
Il client invia le sue richieste in modalità limited broadcast IP
(255.255.255.255)
Di norma i router non devono instradare i pacchetti con IP limited
broadcast e quindi il protocollo è pensato per una singola sottorete
Qualora si vogliano gestire più sottoreti si installano uno o più DHCP
server in alcune delle sottoreti
Occorre quindi un meccanismo per consentire l'inoltro dei pacchetti di
broadcast al/ai DHCP server
Questo si ottiene configurando in modo opportuno i router (DHCP agent
relay) in modo da trasformare la richiesta broadcast in una di tipo
unicast diretta al server DHCP (analogamente a quanto già visto con
BOOTP)
34
Protocollo DHCP
DHCP
Vediamo il funzionamento della modalità dinamica
I server DHCP risiede su una o più sottoreti ed ascoltano sulla porta
UDP 67
Quando un client attiva la scheda di rete, configurata per ottenere
l'indirizzo IP dinamicamente, invia, in limited broadcast IP
(255.255.255.255), un messaggio DHCP DISCOVER dalla porta UDP
68.
In certi casi il client può invece richiedere, come parametro opzionale.
di mantenere un certo indirizzo IP, già assegnato in una precedente
attivazione effettuata al booting
Il server DHCP, ricevuta questa richiesta, alloca un indirizzo IP (il primo
disponibile da un pool preassegnato) e lo invia , in modalità broadcast
limited IP (DHCPOFFER).Se l'indirizzo IP assegnato coincide con
35
quello richiesto come opzione, l'invio può avvenire in modalità unicast
Protocollo DHCP
DHCP
36
Protocollo DHCP
DHCP
Il client, ricevuto il messaggio DHCPOFFER da più server , ne sceglie
uno (il primo arrivato o quello che fornisce il lease più durevole) ed
invia in broadcast IP una richiesta di conferma dell'indirizzo IP
assegnato (messaggio DHCPREQUEST ove è specificato l'indirizzo IP
del server scelto)
Infine il server scelto conferma con il messaggio unicast DHCPACK e
vi riporta sia l'indirizzo IP precedentemente assegnato sia gli altri
parametri indispensabili per configurare la scheda di rete (default
gateway, dns primario e secondario, netmask)
37
Protocollo DHCP
DHCP
Scaduto il tempo stabilito nel parametro leasetime il client invia una
nuova richiesta DHCPREQUEST al server
38
Protocollo DHCP
DHCP
Allocazione semplificata nel caso di lease già ottenuto in

precedenza e non ancora scaduto (50% lease time)
Da www.tcpipguide.com 39
Protocollo DHCP
# Sample configuration file for ISC dhcpd for Debian

# option definitions common to all supported networks...
subnet 192.168.1.0 netmask 255.255.255.0 {

range 192.168.1.201 192.168.1.220;
default-lease-time 600;
max-lease-time 7200;
option broadcast-address 192.168.1.255;
option routers 192.168.1.1;
option domain-name-servers 192.168.1.100;
}
40
IP Nat (Network Address Translation)
Indirizzi privati (non utilizzabili su Internet) usati nelle LAN
da 10.0.0.0 a 10.255.255.255
da 172.16.0.0 a 172.31.255.255
da 192.168.0.0 a 192.168.255.255
Una sottorete con indirizzi privati si può collegare ad Internet tramite un router che
effettui il natting dinamico ossia sostituisca l'indirizzo IP mittente privato con uno
pubblico (Basic Nat), prelevato da un pool di indirizzi IP pubblici, preconfigurati
sul router ed acquistati da ISP
Si memorizza tale associazione per gestire i pacchetti di risposta
Alla ricezione della risposta sulla scheda di rete, ogni indirizzo IP destinatario viene
rimappato in quello privato originario
PAT: il mapping interessa sia gli indirizzi IP che le porte
41
Dynamic IP Nat
Vantaggi
Riduzione del numero di indirizzi pubblici utilizzati
Maggior facilità nella gestione della configurazione degli host e nel cambio di
ISP
Maggior sicurezza ( non è possibile aprire una connessione direttamente
dall'esterno, se non attraverso specifiche configurazioni del router di
interconnessione)
Trasparenza per i client
Svantaggi
Problemi di funzionamento con alcuni protocolli (es. IPSEC)
Maggior complessità di analisi di eventuali problemi di rete
42
Terminologia
Nome Sgnificato
Indirizzo con il quale un host è visto all'interno della rete locale (es.
Inside local address 192.168.1.3). Di solito è un indirizzo privato.
Indirizzo con il quale l'host del punto precedente è visto da Internet
Inside global address (es. 194.132.1.1). Indirizzo necessariamente pubblico
Indirizzo con il quale un host esterno alla rete locale è visto da
Internet (es. l'indirizzo IP di www.google.com). Indirizzo
Outside global address necessariamente pubblico
Indirizzo con il quale lo stesso host esterno è visto dall'interno della
rete locale (può coincidere o meno con quello precedente). Di solito
Outside local address pubblico ma non necessariamente
Nota Inside/Outside indicano se l'indirizzo IP si riferisce ad un host interno od esterno alla LAN
Local/Global indicano se l'indirizzo IP è usato all'interno od all'esterno della LAN 43
Terminologia
1) L'indirizzo sorgente locale (SA Inside Local) può essere nattato in uno global (SA Inside Global)
2) L'indirizzo destinazione locale (DA Outside Local) può essere nattato in uno globale (DA Outside Global)
Analogamente:
3) un indirizzo DA Inside Global può essere nattato in un indirizzo DA Inside Local
4) un indirizzo SA Outside Global può essere nattato in un indirizzo SA Outside Local
44
Terminologia
Inside Local Address: è l'indirizzo nativo di un host della rete locale (di solito
privato ma non necessariamente)
Inside Global Address: è l'indirizzo pubblico con il quale l' host della rete locale si
presenta su Internet (può essere ottenuto per natting dell' indirizzo inside local; es.
host 192.168.1.1 si presenta all'esterno come 193.4.5.7)
Outside Global Address: è l'indirizzo pubblico di un host esterno
Outside Local Address: è l'indirizzo tramite il quale un host esterno viene visto,
dalla rete locale; può essere ottenuto per natting del precedente
L'operazione di natting può, in sintesi, effettuare la trasposizione degli
45
indirizzi da locale a globale e viceversa; vedi esempi seguenti
Nat (Network Address Translation)
Basic Nat
Nota: è unidirezionale in quanto funziona solo se la richiesta parte da un client interno 46

Nat (Network Address Translation)
PAT (Port Address Translation)
Oltre agli indirizzi IP, nel mapping si tiene anche conto delle porte mittente e destinatario 47
Inbound Nat (Bidirectional Nat)
Le tecniche finora viste possono essere utilizzate solo se la transazione nasce
dalla rete con indirizzi privati ed è diretta verso server con indirizzi pubblici
Quando si vuole esporre su Internet uno degli host gestiti con indirizzi privati,
nasce il problema derivante dal fatto che non è ovviamente possibile una
connessione dall'esterno su un indirizzo non pubblico
Occorre pertanto che sia disponibile un indirizzo pubblico da associare
all'indirizzo privato dell'host esposto su Internet
48
● Static mapping:
si pubblica su DNS l'indirizzo IP di questo server usando uno degli
indirizzi pubblici a disposizione da ISP
nel router di interconnessione ad Internet, si mappa tale indirizzo
pubblico (inside global address) nel relativo indirizzo privato (inside
local address)
In tal modo l'host viene contattato da Internet usando il suo indirizzo
pubblico; il router trasla l'indirizzo IP pubblico nel corrispondente
privato all'ingresso del pacchetto
Ovviamente i pacchetti di risposta subiscono un natting simmetrico
49
Start
50
DNS
Un client accede al server conoscendo 5 valori:
protocollo (TCP/UDP)
indirizzo IP mittente
porta (efemerale) mittente
indirizzo IP destinatario
porta destinatario
Questi valori consentono di attivare la socket di connessione client
server
Il protocollo, è associato al tipo di servizio richiesto dal client (es. http,
smtp richiedono TCP)
L'indirizzo IP mittente dipende esclusivamente dall'host sul quale lavora
il client 51
DNS
La porta mittente viene determinata in modo automatico
(efemerale)
La porta del destinatario molto spesso non deve essere
esplicitamente specificata, a livello client, in quanto univocamente
associata al protocollo utilizzato (wellknown ports: es 80 per http,
25 per smtp etc)
Quindi l'unico parametro della socket che l'utente del client deve
indicare è, nella maggior parte delle volte, il solo indirizzo IP
destinatario
Normalmente, al posto dell'indirizzo IP destinatario, è conosciuto, il
suo indirizzo mnemonico (es. www.google.it)
52
DNS
Occorre quindi un meccanismo nel client (DNS resolver) che sia in
grado di trasformare il nome mnemonico di un server in un
indirizzo IP (ad es. da www.google.it a 66.102.9.104 e viceversa)
Il DNS (Domain Name System) è:
Un insieme di nomi, organizzati in modo gerarchico, che
consente di individuare in modo univoco gli host di Internet
(name space) mediante un opportuno nome mnemonico
Un insieme di authorities, gerarchicamente collegate,
responsabili dell'assegnazione univoca di tali nomi nel name
space
Un insieme di server e di protocolli software, per la gestione e
l'utilizzo di tali nomi, in grado di effettuare la conversione da
nome mnemonico ad indirizzo IP e viceversa (non trattato) 53
DNS
Un po' di storia
Inizialmente i client gestivano il mapping, memorizzando un file
testuale (HOST.TXT) riportante, per ogni indirizzo IP, il relativo
nome mnemonico
La versione originale di tale file era detenuta presso l'Università di
Stanford (SRI NIC) che gestiva tutti gli indirizzi IP mondiali
Periodicamente ogni client scaricava, via FTP, tale file sul proprio
hard disk in modo da aggiornare le definizioni
Con il crescere di Internet, questo sistema si rivelò del tutto
inefficace
54
DNS
Un po' di storia
Banda: il file host.txt assumeva, di giorno in giorno, dimensioni
sempre maggiori e questo comportava elevato impegno di banda nel
download
Univocità dei nomi: SRI NIC assegnava gli indirizzi ma non aveva
alcuna autorità sui nome. Ciò comportava potenziali problemi di
duplicazione (clashing) con effetti ben evidenti
Inefficienza: ogni giorno sempre più host si collegavano ad Internet
ed il sistema basato sulla distribuzione di un singolo file non
riusciva più a garantire una rapida sincronizzazione
55
DNS
Si progettò quindi una nuova architettura (DNS) che:
consentisse una gestione distribuita del mapping
ne garantisse, nel contempo, una visione integrata ed unitaria
I nomi degli host appartenti ad Internet vengono definiti, in analogia ai
nomi delle directory di un file system Unix, mediante una struttura ad
albero rovesciato (inverted tree) in cui:
la radice rappresenta il cosiddetto dominio di root (analoga alla root
di un file system unix)
ogni nodo costituisce, a sua volta, la radice di un sottoalbero
(subtree)

ogni subtree rappresenta un dominio (directory in Unix)
ogni foglia rappresenta un host 56
DNS
root (/)
UNIX
bin etc lib usr var
bin
esempio /usr/src/Documento.txt
sbin
src
Documento.txt
57
DNS
Name space Dominio di root (si indica con spazio vuoto)
DNS
domini nodo Domini di primo livello TLD

com org mil edu it,us,uk, ...
Domini di secondo livello unitn.com. e di terzo

dominio livello edu.unitn.com. (sottodominio di unitn.com.)
unitn.com.
unitn
dominio UN DOMINIO È L'INSIEME DEI NOMI
cisco cisco.com. CONTENUTI NEL SUBTREE CHE SI
smtp DIPARTE DAL SUO NODO RADICE
edu
Fully Qualified Domain Name (FQDN)
www ftp host.dominio
ftp www
xyz Esempi (notare il punto)
www
www.ibm.com. ftp.cisco.com. 58
DNS
Il dominio indica quindi un sottoinsieme di nomi , identificato dal
subtree che si diparte dal nodo che rappresenta la sua radice
Ogni nodo ed ogni foglia hanno una label, analogamente ai files ed
alle directories di Unix
Il nome di dominio (FQDN) è formato dai nomi, separati da punti,
di tutte le label incontrate partendo dal nodo che ne rappresenta la
radice, salendo verso la root (up the tree),
Per la root non si usa alcuna label
Un host si indica con il nome della foglia seguito dal punto e dal
nome del dominio di appartenenza (es. www.ibm.com.)
59
DNS
Il DNS prevede anche un'organizzazione di authorities e server
(nameserver) per la risoluzione dei nomi inseriti nel name space
Anche le authorities sono organizzate gerarchicamente; esse
agiscono per delega
L'authority principale (ICANN), no profit con sede in California,
assegna i nomi ai domini di primo livello generici (gTLD) e
countrycode (ccTLD)
ICANN gestisce anche i nuovi TLD biz. , coop. , info. etc
ICANN delega ad altre authorities (registry) la gestione dei domini
di primo livello (ad es. it. è delegato al CNR di Pisa)
60
DNS
I registry , a loro volta, delegano la gestione di un loro
sottodominio di secondo livello (es. unitn.it.) ad altre
authorities (registrant), che registrano tale sottodominio
presso il registry rivolgendosi a specifici Enti detti registrar
(di solito è ISP)
Si noti che la responsabilità di un certo sottodominio è in
carico al registrant; il registrar è solo un intermediario
In sintesi ogni authority controlla un certo sottoinsieme del
name space; tale sottoinsieme viene definito zona
La zona può coincidere con un dominio; se però uno o più
sottoinsiemi di nomi di tali domini vengono delegati ad altre
authorities si è in presenza di un dominio suddiviso in più
zone (ossia ad un dominio corrispondono n zone; ad es. al
dominio unitn.it. corrispondono le zone unitn.it. e
science.unitn.it.) 61
DNS
L'authority alla quale viene delegata una zona (registrant) mette,
solitamente, a disposizione almeno due nameserver per la
risoluzione dei nomi in essa contenuti (name server autoritativi per
la zona)
In alternativa la zona può essere, per comodità, gestita tramite i
nameserver del registrar; la responsabilità della zona e l'
aggiornamento dei relativi nomi è comunque sempre a carico del
registrant. Un nameserver può infatti gestire più zone
Gerarchia di authorities: ICANN > Registry > Registrant (la zona
può essere gestita su nameserver autonomi oppure tramite i
nameserver del registrar) → Registrant (se un sottodominio viene
ulteriormente delegato; anche in questo caso la zona può essere
gestita mediante nameserver autonomi o tramite i nameserver del
registrar o del registrant delegante) etc 62
DNS
root (si indica con spazio vuoto)
DNS
it org mil edu ...........
zona unitn.it. corrisponde a dominio unitn.it.

comprendente anche il sottodominio science.unitn.it.
unitn
cisco
apps primario second.
science
www nameserver per la zona unitn.it.

ftp www ftp
xyz
www
63
DNS
DNS
it org mil edu ..............
zona unitn.it.
primario second.
unitn
nameserver per la zona unitn.it.
cisco
www apps
zona science.unitn.it.
science
www primario second.
xyz ftp
www ftp
64
nameserver per la zona science.unitn.it.
DNS
DNS
it org mil edu ..............
zona unitn.it.
primario second.
unitn
cisco nameserver per la zona unitn.it. e per la
www apps zona science.unitn.it.
science
zona science.unitn.it.
ftp www
xyz
www ftp
65
DNS
In sintesi, mentre il dominio è un concetto che si riferisce al contesto del
name space, il termine “zona” si riferisce al contesto della gerarchia
delle authorities
Una zona può coincidere o meno con un dominio; si differenzia solo
quando alcuni sottodomini di un certo dominio sono delegati ad altre
authorities; in questo caso il dominio è formato da tante zone quanti
sono i suoi sottodomini gestiti da authorities differenti
Ad esempio, nelle slide precedenti, il dominio unitn.it è formato dalla
zona unitn.it, che comprende i nomi degli host direttamente collegati
al nodo unitn.it., e dalla zona science.unitn.it. che include tutti i nomi
collegati al nodo omonimo
66
DNS
Si dice, in gergo tecnico, che un nameserver è autoritativo per una certa
zona, ad indicare che è responsabile dei nomi di tutti gli host
appartenenti a quella zona
Il nameserver gestisce delle specifiche informazioni (RR resource
record) delle quali le più importanti sono:
SOA (Start of Authority): ne esiste uno per zona e riporta dei
parametri di gestione
NS (name server): indica il nome dei nameserver (primario e
secondari) dove reperire le informazioni di una zona (un record
per host)
A (address): indica l'indirizzo IP (un record per host)
67
DNS
Esempio di zona definita in un nameserver
; zone fragment for example.com Nome zona equivale a @
example.com IN SOA ns1.example.com. hostmaster.example.com. (
2003080800 ; serial number
2h ; slave refresh = 2 hours
SOA: definisce il nameserver principale, l'emal
15M ; slave update retry = 15 minutes
della persona di riferimento ed i parametri
3W12h ; slave expiry = 3 weeks + 12 hours
temporali di gestione
2h20M ; minimum = zone default TTL
)
; main domain name servers NS: si definiscono i nameserver principale e secondario
IN NS ns1.example.com.
; main domain mail servers MX: si definisce il mailserver del dominio
IN MX mail.example.com.
; A records for name servers above A: si definiscono gli indirizzi IP dei due nameserver
ns1.example.com. IN A 194.207.0.3
ns2.example.com. IN A 194.207.0.4 A: si definiscono gli indirizzi IP degli host del dominio
; A record for mail server above
mail.example.com. IN A 194.207.0.5
www.example.com. IN A 194.207.0.6
....
68
DNS
Nel caso di zona delegata, sul nameserver del delegante dovranno
essere presenti delle informazioni (glue records) che consentano di
puntare, per la zona delegata, ai nameserver di competenza
In effetti tutto il DNS si basa sul concetto di delega:
il nameserver del dominio di root delega ai nameserver dei
domini di primo livello la relativa gestione dei nomi
ad esempio uno dei 13 root nameservers fornisce gli indirizzi dei
nameservers delegati per la gestione degli indirizzi di primo
livello (Top Level Domain)
69
DNS
DNS
com org mil edu it,us,uk, ...
zona example.com.
Primario Secondario
example ns2.example.com
ns1.example.com
cisco www
glue records
mail
us
ftp www primario second.
xyz
www ftp
70
nameserver per la zona us.example.com.
DNS
; zone fragment for example.com
example.com. IN SOA ns1.example.com. hostmaster.example.com. (
2003080800 ; serial number
2h ; refresh = 2 hours
15M ; update retry = 15 minutes
3W12h ; expiry = 3 weeks + 12 hours
2h20M ; minimum = 2 hours + 20 minutes
)
; main domain name servers
; main domain mail servers
IN MX mail.example.com.
; A records for name servers above
; A record for mail server above
mail .example.com. IN A 194.207.0.5
....
71
DNS
; subdomain definitions
; we define two name servers for the subdomain
us.example.com IN NS ns3.us.example.com.
; the second name server
us.example.com. IN NS ns4.us.example.com.
; subdomain address records for name server only glue record
ns3.us.example.com IN A 11.10.0.24 ; 'glue' record
ns4.us.example.com IN A 11.10.0.25; 'glue' record
72
DNS
Vantaggi
Distribuzione del carico di lavoro e migliori performance
Ridondanza e quindi affidabilità
Ogni organizzazione è direttamente responsabile dei suoi dati
Impossibilità di nomi duplicati
73
DNS
Modalità di risoluzione dei nomi
Il client (ad esempio il browser) contatta il nameserver associato
all'host sul quale è installato (parametro di configurazione) e chiede
che venga risolto un certo nome (supponiamo www.unitn.it.) in
modalità ricorsiva (ossia il nameserver dovrà effettuare tutte le
ricerche necessarie restituendo al client solo il risultato finale)
Il nameserver locale, se non ha già disponibile l'indirizzo richesto in
cache, contatta, in modalità iterativa, uno dei rootserver richiedendo
la risoluzione del nome cercato
Il rootserver risponde fornendo gli indirizzi IP dei nameserver
autoritativi per il dominio di primo livello presente nel nome
cercato (nel nostro caso it.)
74
DNS
Modalità di risoluzione dei nomi
Il nameserver locale contatta quindi, sempre in modalità iterativa,
uno di questi due nameserver che risponderà con gli indirizzi IP
dei name server autoritativi per la zona unitn.it
Il nameserver locale contatta, in modalità iterativa, uno dei due
nameserver autoritativi per la zona unitn.it. ed otterrà finalmente
l'indirizzo IP dell' host cercato (www.unitn.it)
L'indirizzo così ottenuto viene restituito al client
Parte di questo processo può essere semplificato e ridotto ricorrendo
a meccanismi di caching delle informazioni
75
DNS
Client unitn.it.
Indirizzo IP di root
www.unitn.it? nameserver
Cache DNS resolver
4
www.unitn.it. ?
(richiesta ricorsiva)
1 vai a
2 dns.nic.it.
3 dns.nic.it
DNS locale
Cache 5
www.corriere.it.
ns for corriere.it. ?
ns for it.?
vai a
dns.unitn.it.
193.205.206.23 La richiesta 2 è di tipo ricorsivo, nel
6 senso che il DNS contattato si fa
carico di tutto il processo di risoluzione
dns.unitn.it. Le richieste 4-6 sono iterative

76
DNS
Laboratorio
Verifica del processo ricorsivo di risoluzione di un nome
Si userà il comando dig:
dig @<NomeNameServer> <nome cercato> +norec Non effettuare ricerca in modo
ricorsivo
Esempio
dig @dns.nic.it www.unitn.it +norec
77
DNS
Laboratorio
Analisi dei protocolli di una ricerca mediante ethereal,attivando un
nameserver di test
Esempio
sudo /etc/init.d/bind9 start
dig @10.10.10.102 www.example.com.
dig @10.10.10.102 ftp.example.com.
dig @10.10.10.102 www.example.com. +norec
78
DNS
TLD (Top Level Domains)
com (commercial)
edu (educationa)
gov (government; es. nasa.gov)
mil (military)
net (network infrastructure)
org (not commercial organizatios)
int (international)
arpa (usato per reverse mapping)
country code (it,us,uk, de etc). ISO 3166
new (es. aero, biz, coop, info, museum, eu etc)

79

DNS
I 13 Root Servers
0) A.ROOTSERVERS.NET. 198.41.0.4
1) B.ROOTSERVERS.NET. 192.228.79.201
2) C.ROOTSERVERS.NET. 192.33.4.12
3) D.ROOTSERVERS.NET. 128.8.10.90
4) E.ROOTSERVERS.NET. 192.203.230.10
5) F.ROOTSERVERS.NET. 192.5.5.241
6) G.ROOTSERVERS.NET. 192.112.36.4
7) H.ROOTSERVERS.NET. 128.63.2.53
8) I.ROOTSERVERS.NET. 192.36.148.17
9) J.ROOTSERVERS.NET. 192.58.128.30
10) K.ROOTSERVERS.NET. 193.0.14.129
11) L.ROOTSERVERS.NET. 198.32.64.12
12) M.ROOTSERVERS.NET. 202.12.27.33
80
SNMP
Network Management
Con il termine “network management” si intende l'insieme delle attività che si
rendono necessarie per la gestione di una rete dati complessa (configuration, fault,
performance management) al fine di :
disporre di un quadro d'insieme degli apparati costituenti la rete
controllare il corretto funzionamento della rete
essere prontamente notificati di eventuali guasti e poter intervenire prontamente
disporre di dati statistici che consentano di adattare in modo proattivo gli apparati
di rete alle crescenti esigenze di utilizzo (network planning)
81
SNMP
Motivazioni del Network Management
Crescente complessità delle reti dati
Crescente estensione geografica della rete
Eterogeneità degli apparati in termini funzionali (hub, switch, router, host) e di
modelli utilizzati
Necessità di ridurre al minimo le interruzioni di funzionamento (Service Level
Agreement) e, sempre più spesso, di garantire il funzionamento della rete anche in
presenza di guasti (fault tolerance)
82
SNMP
Motivazioni del Network Management
La raccomandazione ISO 74984 identifica 5 aree funzionali per il network
management
Configuration Management
CONTROLLO
Security Management
________________________________________________________________
Fault Management
Performance Management MONITORAGGIO
Accounting Management
83
SNMP
Network Management
1. Configuration Management
Raccogliere informazioni sulla configurazione degli apparati di rete
Modificare la loro configurazione
Disporre di un inventario degli apparati costituenti la rete (asset), anche al fine di
individuare eventuali problemi di compatibilità
Router
Internet
Switches
Hosts 84
SNMP
Network Management
2. Fault Management
Essere notificati della presenza di errori nella rete
Isolare la causa degli errori
Intervenire correggendo l'errore, ove questo è possibile con modifiche alla
configurazione
Router
Internet
Switches
85
Hosts
SNMP
Network Management
3. Performance Management
Raccogliere dati sull'utilizzo della rete
Individuare potenziali problemi di rete (packet dropped,timeout,CRC errors)
Impostare soglie di utilizzo, oltre le quali un apparato è considerato in condizioni
anomale
Utilization = 87%
Router
Internet
Switches
Hosts 86
SNMP
Network Management
4. Accounting Management
Misurare l'utilizzo della rete da parte degli utenti autorizzati, a scopo di
fatturazione e per impostare limiti di utilizzo (quote)
5. Security Management
Controllare il corretto accesso agli apparati di rete da parte dell'utenza
Registrazione degli accessi ad apparati sensibili della rete
87
SNMP
Network Management Architecture
E' basata su tre componenti:
1) Managed nodes (host, switch, router, stampanti etc), ossia unità componenti la
rete fornite, ognuna, di una componente software (SNMP entity), in grado di
raccogliere informazioni del nodo e di trasmetterle, via SNMP/UDP/IP a:
2) Una (o più) network management station, ossia unità di rete (es. un PC) fornita
di software (SNMP entity) suddiviso in due macrocomponenti:
a) SNMP manager (client), che riceve le informazioni dai vari agent
b) SNMP Application ossia software applicativi in grado di consentirne un
controllo ed una visione integrata delle informazioni raccolte dai vari manged
nodes)
3) Protocollo SNMP per consentire l'interscambio di informazioni (SNMP 88
messaging) fra agent e manager
SNMP
SNMP architecture
89
SNMP
SNMP architecture
MANAGER AGENT
Management Application
MIB
SNMP PDUs
CONNECTIONLESS TRANSPORT SERVICE PROVIDER
UDP
90
SNMP
Network Management Architecture
Ogni apparato di rete ha installato una componente software denominato SNMP
entity. Ogni SNMP entity è costituita da due macrocomponenti
Per Managed Nodes
1) SNMP agent: consente l'invio di informazioni da un nodo al manager NMS
2) SNMP Management Information Base (MIB) che stabilisce i vari tipi di dati
(managed objects) che l'agent può raccogliere nel singolo nodo per trasmetterli
al manager NMS
Per Network Management Station
1) SNMP manager: raccoglie le informazioni inviate dai vari agent
2) SNMP application che consente l'aggregazione dei dati e la gestione della rete
91
SNMP
Manager
Il manager può lavorare contemporaneamente in modalità attiva e passiva
In modalità attiva (polling), il manager interroga ad intervalli periodici i vari agent
raccogliendo da ognuno di essi (comando get) le informazioni individuate per la
gestione della rete (es. quanti messaggi del tipo ICMP port unreachable sono stati
generati?); il manager può anche modificare, tramite l'agent, queste informazioni
(comando set)
In modalità passiva (interruptdriven), l'agent invia al manager dei messaggi (trap)
al verificarsi di eventi significativi (es. caduta di un'interfaccia di rete)
I comandi utilizzati da agent e manager sono quelli previsti dal protocollo
applicativo (livello 7) SNMP, che approfondiremo in seguito
92
SNMP
Tre Standards
SMI (STRUCTURE OF MANAGEMENT INFORMATION); RFC 1155
linguaggio di definizione dati per gli oggetti (managed object) gestiti da manager/agent
MIBII MANAGEMENT INFORMATION BASE; RFC 1213
database distribuito formato dai vari managed object presenti nei MIB dei managed devices
SNMP SIMPLE NETWORK MANAGEMENT PROTOCOL; RFC 1157

standard che stabilisce le modalità con le quali agent e manager si scambiano informazioni
relative ai managed objects

93
SNMP
Protocollo SNMP
Si è visto che Agent e Manager si scambiano informazioni attraverso uno specifico
protocollo (SNMP)
Si potrebbe dedurre che SNMP sia un protocollo commandoriented intendendo
che, analogamente ad altri protocolli, il client (manager) chieda al server (agent)
l'esecuzione di particolari comandi che riguardino ad es. la lettura di una specifica
informazione gestita dall'agent (es. lettura del numero di interfacce installate presso
un certo apparato di rete) oppure l'attivazione di una determina funzione (es.
shutdown di un'interfaccia)
Non si è però considerato conveniente seguire tale approccio, in quanto occorre
sempre considerare che ogni rete è formata da apparati eterogenei implementati da 94
vendor diversi
SNMP
Protocollo SNMP
Ci si sarebbe trovati ben presto in una situazione caratterizzata da una proliferazione
di comandi , caratterizzati da un forte intreccio con i dati gestiti (analogamente a
quanto avveniva, prima della nascita dei DB relazionali, con i primi programmi che
gestivano direttamente, tramite file, un proprio subset di dati)
Anche informazioni dello stesso tipo sarebbero state verosimilmente gestite con
formati e nomi diversi da ogni vendor di apparati
Ogni modifica dei comandi avrebbe comportato l'aggiornamento del protocollo su
tutti gli apparati
95
SNMP
Protocollo SNMP
Occorre inoltre tenere presente il fatto che SNMP è nato come protocollo di
transizione ad un nuovo standard, basato sul modello OSI, che in realtà non ha mai
visto la luce. Questo però ha comportato l'esigenza di tenere il protocollo di
comunicazione (SNMP) ben separato dai dati gestiti, in modo che potesse essere
facilmente sostituito
Si è, in definitiva, opportunamente deciso di optare per una separazione netta fra
comandi e dati, utilizzando per questi ultimi una modellazione standard
96
SNMP
Protocollo SNMP
Invece di molti comandi di lettura e scrittura, specifici per ogni apparato e gestiti in
modo proprietario, ogni apparato deve gestire dati
definiti in modo standard, sia dal punto di vista semantico che formale
(managed object) in modo da garantire omogeneità di gestione
raggruppati in blocchi inseriti all'interno di una struttura ad albero
inverso standard detta MIB (Management Information Base)
il MIB è a sua volta inserito nell'albero ISO degli identificatori di oggetti
lo scopo, in analogia a quanto già visto per DNS, è di associare una chiave
97
testuale e numerica (ad es. del tipo .1.3.6.1.2.1.1.6) ad ogni managed object
SNMP
MIB (Management Information Base)
root 1) i dati sono definiti e raccolti in gruppi,
all'interno del MIB , usando lo standard SMI
itu-t(0) iso (1) joint iso/itu-t (2)
org (3)
system (1) sysLocation OBJECTTYPE
albero ISO dod (6) SYNTAX OctetString (SIZE (0..255))
sysDescr (1)
sysObjectId (2) MAXACCESS readwrite
internet (1) sysUpTime (3) STATUS current
sysContact (4)
mgmt (2) sysName (5) DESCRIPTION “The physical location of this
sysLocation (6) node (e.g. 'telephone closet, 3rd floor').”
sysServices (7)
::= {system 6}
private (4) mib-2 (1) ......................
2) ad ogni dato viene

assegnato un codice
system (1) at (3) icmp(5) udp (7) .......... numerico e testuale per la
sua individuazione
interface (2) ip (4) tcp (6) all'interno del MIB
.1.3.6.1.2.1.1.6
98
.iso.org.dod.internet.mgmt.mib-2.system.sysLocation
SNMP
MIB : Management Information Base
Invece che vedere un apparato come un dispositivo che richiede specifici comandi per
leggerne i dati operativi o per modificarne le modalità di funzionamento, ogni
apparato è quindi visto come un insieme di gruppi di dati standard (managed object),
che il manager è in grado di leggere/scrivere interagendo con il relativo agent
Ad esempio invece di un comando specifico per l'apparato del tipo “dimmi il numero
totale di ore di funzionamento”, l'apparato tiene in memoria un managed object, che
contiene questa informazione (sysUpTime), inserita in un blocco standard di
informazioni (“system”)
99
SNMP
Analogamente, invece di un comando specifico per attivare una certa funzione
dell'apparato, è sufficiente sovrascrivere il valore di una specifica variabile che
l'apparato interpreta come richiesta di attivazione di tale funzione
Si può vedere in tal modo il MIB come un database distribuito: ogni managed device
mantiene in memoria la propria porzione di MIB ed il manager è in grado di accedere,
tramite i vari agent, ad ognuno dei relativi managed object
100
SNMP
La chiave numerica, resa possibile dall'inserimento del managed object all'interno
del MIB, viene utilizzata per l'interscambio di informazione agentmanager,
standardizzando e semplificando in tal modo il protocollo SNMP
La chiave testuale, invece, viene utilizzata solo per comodità di interpretazione e
lettura ma non viene mai usata all'interno del protocollo
Sia per la codifica standard dei dati che per la definizione della loro posizione
all'interno del MIB si usa un particolare linguaggio (SMI Structure of Management
Information), formato da un subset di costrutti sintattici di un linguaggio più ampio
denominato ASN.1
101
SNMP
SMI: Standard Management Interface (SMIv1 , SMIv2)
Scopo di tale linguaggio è stabilire in modo rigoroso, preciso, omogeneo le
caratteristiche di ogni managed object e la posizione di questo all'interno del MIB
Si veda ad esempio come sono definiti in Linux/Ubuntu i dati di un MIB nel file
/usr/share/snmp/mibs/SNMPv2MIB.txt
Si noti che il linguaggio SMI sta al MIB come un linguaggio sta ad un programma
compilato con esso. Il linguaggio SMI serve a creare il file di definizione dei dati
(managed object), il loro raggruppamento e la posizione del gruppo nell'ambito del
MIB. Il MIB è il risultato della compilazione di tale file!
102
SNMP
SMI: Standard Management Interface (SMIv1 , SMIv2)
Ogni managed object, in accordo allo standard SMIv2,, deve essere definito con le
seguenti cinque caratteristiche minime:
Object Name: nome testuale (object descriptor) e numerico (oid object
identifier))
Syntax: data type(es. Integer, Octet String); scalare o tabellare
MaxAccess: modalità di accesso (es readcreate, readwrite, readonly)
Status : current/obsolete/deprecated
Description: descrizione testuale (semantica)
103
SNMP
Esempio di definizione di un ManagedObject secondo SMIv2
Object Name (object descriptor)
sysLocation OBJECTTYPE
SYNTAX OctetString (SIZE (0..255))
MAXACCESS readwrite
STATUS current
DESCRIPTION “The physical location of this node (e.g. 'telephone closet, 3rd floor').”
::= {system 6}

Object Name (object identifier)
Esempio di definizione di un managed object: l'object name è suddiviso in due parti

ad individuare rispettivamente, il nome testuale e quello numerico 104
SNMP
Esempi di data type SMI usati per la definizione dei managed objects
Data Tye Code Description
A 32bit signed integer in two's complement notion, capable of holding a value
from 2.147.483.648 to +2.147.483.647. Can also be used to represent an
Integer/integer32 enumerated type
OctetString A variablelength of binary or text data
Unsigned A 32bit unsigned integer, from 0 to 4.294.967.295
IpAddress An IP address, encoded as a 4btye octet string
.............. ...................................................................................
105
SNMP
MIB MIB
Object 1 managed
Syntax Max-Access Status Description
Name object
Object 2
Name
Object 3
Name
s
Object n
Name

Più managed object vengono definiti e raggruppati, usando costrutti specifici

dello standard SMI, a formare uno dei nodi del MIB;
106
SNMP
Esempio di MIB definito con SMIV2
IPFORWARDMIB DEFINITIONS ::= BEGIN
IMPORTS
MODULEIDENTITY, OBJECTTYPE,
IpAddress, Integer32, Gauge32,
Counter32 FROM SNMPv2SMI
RowStatus FROM SNMPv2TC
MODULECOMPLIANCE, OBJECTGROUP FROM SNMPv2CONF
InterfaceIndexOrZero FROM IFMIB
ip FROM IPMIB
IANAipRouteProtocol FROM IANARTPROTOMIB
InetAddress, InetAddressType,
InetAddressPrefixLength,
InetAutonomousSystemNumber FROM INETADDRESSMIB;
ipForward MODULEIDENTITY
107
SNMP
LASTUPDATED "200402091200Z"
ORGANIZATION
"IETF IPv6 Working Group"
CONTACTINFO
"Editor:
Brian Haberman
Caspian Networks
753 Bridgewater Drive
Sykesville, MD 21784
Phone: +1 410 5521421
Email: brian@innovationslab.net
Send comments to <ipv6@ietf.org>"
DESCRIPTION
"The MIB module for the management of CIDR multipath IP
Routes. 108
RFC Ed : replace xxxx with actual RFC number & remove note
SNMP
REVISION "199207022156Z"
DESCRIPTION
"Initial version, published as RFC 1354."
::= { ip 24 }
da questo punto in poi inizia la definizione dei singoli managed object

inetCidrRouteNumber OBJECTTYPE
SYNTAX Gauge32
MAXACCESS readonly
STATUS current
DESCRIPTION
"The number of current inetCidrRouteTable entries that
are not invalid."
::= { ipForward 6 }
inetCidrRouteDiscards OBJECTTYPE
SYNTAX Counter32
109
SNMP
Protocollo SNMP
Il manager, per effettuare funzioni di controllo, chiede all'agent, tramite il
protocollo SNMP, la lettura di questi gruppi di managed objects, che ogni apparato
deve gestire conformemente agli standard (SMI, MIB)
In tal modo il protocollo è costituito da un numero molto limitato di comandi
(GetRequest, SetRequest etc) che specificano come parametro il solo gruppo di dati
richiesto (es. system, interface, tcp etc)
Analogamente le funzioni di controllo del comportamento di un apparato vengono
risolte in richieste all'agent di modifica di uno o più valori di managed object
110
SNMP
Sviluppo del protocollo SNMP
SNMPv3
SNMPv2
security,
estensione di crittografia dei
SNMPv1
SNMP a protocolli dati
differenti da IP
SGMP SNMP over
UDP/IP
1987 1989 1994 1998
111
SNMP
SNMP protocol operations
I messaggi scambiati fra agent e manager sono detti Protocol Data Units
(PDU). I più utilizzati sono:
Class Description SNMPv1 PDU's SNMP v2/3 pDU's

GetRequest, GetRequest,
Messaggi SNMP che leggono managed object GetNextRequest getNextRequest,
Read con meccanismi di polling (tabular data) GetBulkRequest
Messaggi SNMP per la modifica di managed
Write object SetRequest SetRequest
Messsaggi SNMP inviati in risposta ad una
Response precedente richiesta GetResponse Response
Messaggi SNMP interrupt driven da agent a Trapv2,
Notification manager Trap InformRequest
112
SNMP
SNMP protocol operations (GetRequest)
MANAGER AGENT
CreaGet Request-PDU,
specificando i nomi
dei managed objects
Invia Request-PDU Riceve ed elabora

Get Request-PDU
UDP/IP
port 161 Crea Respose-PDU,
con i valori del MIB
Invia Response-PDU
Elabora Respose-PDU
113
SNMP
SNMP protocol operations (SetRequest)
MANAGER AGENT
CreaSetRequest-PDU,
specificando il set di
managed objects
da modificare
Invia SetRequest-PDU Riceve ed elabora
Set Request-PDU,
modificando il MIB
UDP/IP
port 161 Crea Respose-PDU,
con i valori del MIB
Invia Response-PDU
Elabora Respose-PDU
114
SNMP
SNMP protocol operations (SetRequest)
es. security features
campi che descrivono la PDU:

es. pdu type, request ID, trap
coode, IP agent
per dettagli si veda www.tcpipguide.com 115

SNMP
Protocollo SNMP
Laboratorio: Esempio di utilizzo dei comandi snmp get e snmp getnext (snmpwalk)
da parte di un manager nei confronti dell'agent
116
SNMP
SNMP protocol: esempio di GetRequest in ubuntu
$ sudo /etc/init.d/snmpd start avvia l'agent snmp
$ verifica corretto avvio con netstat uan
$ sudo snmpwalk localhost c public v1
$ sudo snmpget localhost v 1 c public SNMPv2MIB::sysUpTime.0
$ sudo snmpwalk localhost c public v1 at [tcp udp ip icmp]
$ sudo snmpget localhost c public v1 .1.3.6.1.2.1.1.9.1.4.1
117

Lingua

Benvenuto in Scribd!

Modulo2Vers5.1

Caricato da

Informazioni sul documento

Data di caricamento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Descrizione:

Copyright:

Formati disponibili

Modulo2Vers5.1

Caricato da

Descrizione:

Copyright:

Formati disponibili

Titoli correlati

Reti di calcolatori: applicazioni

Docente: Claudio Covelli

rip version 2 packet (transport UDP; port 520)

Occorre un server RARP

Subnet ID Host ID Example Note

Vendor Specific Area:

•Il router,configurato come bootp agent

Allocazione semplificata nel caso di lease già ottenuto in

# Sample configuration file for ISC dhcpd for Debian

subnet 192.168.1.0 netmask 255.255.255.0 {

Nota: è unidirezionale in quanto funziona solo se la richiesta parte da un client interno 46

bin etc lib usr var

Name space Dominio di root (si indica con spazio vuoto)

domini nodo Domini di primo livello TLD

Domini di secondo livello unitn.com. e di terzo

root (si indica con spazio vuoto)

it org mil edu ...........

zona unitn.it. corrisponde a dominio unitn.it.

www nameserver per la zona unitn.it.

root (si indica con spazio vuoto)

it org mil edu ..............

root (si indica con spazio vuoto)

it org mil edu ..............

root (si indica con spazio vuoto)

com org mil edu it,us,uk, ...

dns.unitn.it. Le richieste 4-6 sono iterative

CONNECTIONLESS TRANSPORT SERVICE PROVIDER

SNMP SIMPLE NETWORK MANAGEMENT PROTOCOL; RFC 1157

2) ad ogni dato viene

Object Name (object descriptor)

Object Name (object identifier)

Esempio di definizione di un managed object: l'object name è suddiviso in due parti

Più managed object vengono definiti e raggruppati, usando costrutti specifici

da questo punto in poi inizia la definizione dei singoli managed object

1987 1989 1994 1998

Class Description SNMPv1 PDU's SNMP v2/3 pDU's

Invia Request-PDU Riceve ed elabora

es. security features

campi che descrivono la PDU:

per dettagli si veda www.tcpipguide.com 115

Interessi correlati

Documenti simili a Modulo2Vers5.1

Popolare in Leisure

Titoli correlati

Valuta

Condividi