Sei sulla pagina 1di 117

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
RIP (Routing Information Protocol)

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
RIP (Routing Information Protocol)

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
RIP (Routing Information Protocol)

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 R2 eth1
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 6
RIP (Routing Information Protocol)

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  well­known 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 
RIP (Routing Information Protocol)

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
RIP (Routing Information Protocol)

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
RIP (Routing Information Protocol)

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
RIP (Routing Information Protocol)

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
RIP (Routing Information Protocol)

Tabella di routing di R2
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
Tabella di routing di R1
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

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 12
RIP (Routing Information Protocol)

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
RIP (Routing Information Protocol)

 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 (time­out)  e viene inviata  una richiesta (RIP request) ai router 
adiacenti per  un aggiornamento

 Esempio con Netsimk
14
RIP (Routing Information Protocol)

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

da www.tcpipguide.com
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 
subnet­id 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

da www.tcpipguide.com
24
Protocollo BOOTP

BOOTP
BOOTP usa quindi  porte well­known  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

da www.tcpipguide.com

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
da www.tcpipguide.com
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 WI­FI)

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

da www.tcpipguide.com

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 lease­time 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
IP Nat (Network Address Translation)

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
IP Nat (Network Address Translation)

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
IP Nat (Network Address Translation)

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
IP Nat (Network Address Translation)

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
IP Nat (Network Address Translation)

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
IP Nat (Network Address Translation)

Inbound Nat (Bidirectional Nat)
●  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
IP Nat (Network Address Translation)

Inbound Nat (Bidirectional Nat)
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 (well­known 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 
country­code (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

root (si indica con spazio vuoto)

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

root (si indica con spazio vuoto)

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.
              IN      NS     ns2.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

root (si indica con spazio vuoto)

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
              IN      NS     ns1.example.com.
              IN      NS     ns2.example.com.
; main domain mail servers
              IN      MX      mail.example.com.
; A records for name servers above 
ns1.example.com.           IN      A      194.207.0.3
ns2.example.com.           IN      A      194.207.0.4
; A record for mail server above 
mail .example.com.        IN      A      194.207.0.5
....

71
DNS

; sub­domain definitions

; we define two name servers for the sub­domain
us.example.com           IN      NS     ns3.us.example.com.

; the  second name server 
us.example.com.            IN      NS      ns4.us.example.com.
; sub­domain 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.ROOT­SERVERS.NET.     198.41.0.4
1) B.ROOT­SERVERS.NET.              192.228.79.201
2) C.ROOT­SERVERS.NET.                192.33.4.12
3) D.ROOT­SERVERS.NET.      128.8.10.90
4) E.ROOT­SERVERS.NET.     192.203.230.10
5) F.ROOT­SERVERS.NET.      192.5.5.241
6) G.ROOT­SERVERS.NET.      192.112.36.4
7) H.ROOT­SERVERS.NET.      128.63.2.53
8) I.ROOT­SERVERS.NET.      192.36.148.17
9) J.ROOT­SERVERS.NET.     192.58.128.30
10) K.ROOT­SERVERS.NET.      193.0.14.129
11) L.ROOT­SERVERS.NET.      198.32.64.12
12) M.ROOT­SERVERS.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 7498­4 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 macro­componenti:
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 macro­componenti
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 (interrupt­driven), 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

MIB­II 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 command­oriented 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 OBJECT­TYPE
albero ISO dod (6)     SYNTAX OctetString  (SIZE (0..255))
sysDescr (1)
sysObjectId (2)     MAX­ACCESS read­write
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
MIB :  Management  Information Base

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

MIB :  Management  Information Base

La chiave numerica, resa possibile dall'inserimento del managed object all'interno 
del MIB, viene utilizzata per l'interscambio di informazione agent­manager, 
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/SNMPv2­MIB.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
Max­Access:               modalità di accesso (es read­create, read­write, read­only)
Status :        current/obsolete/deprecated
Description:                 descrizione testuale (semantica)

103
SNMP

Esempio di definizione di un ManagedObject secondo SMIv2

Object Name (object descriptor)

sysLocation OBJECT­TYPE
    SYNTAX OctetString  (SIZE (0..255))
    MAX­ACCESS read­write
    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 32­bit 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 variable­length of binary or text data
Unsigned  A 32­bit unsigned integer, from 0 to 4.294.967.295
IpAddress  An IP address, encoded as a 4­btye octet string
.............. ...................................................................................
105
SNMP

MIB MIB

Object 1 managed
Syntax Max-Access Status Description
Name object
Object 2
Syntax Max-Access Status Description
Name

Object 3
Syntax Max-Access Status Description
Name
s
     Object n
Syntax Max-Access Status Description
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
   IP­FORWARD­MIB DEFINITIONS ::= BEGIN
    IMPORTS
        MODULE­IDENTITY, OBJECT­TYPE,
        IpAddress, Integer32, Gauge32,
        Counter32                          FROM SNMPv2­SMI
        RowStatus                          FROM SNMPv2­TC
        MODULE­COMPLIANCE, OBJECT­GROUP    FROM SNMPv2­CONF
        InterfaceIndexOrZero               FROM IF­MIB
        ip                                 FROM IP­MIB
        IANAipRouteProtocol                FROM IANA­RTPROTO­MIB
             InetAddress, InetAddressType,

            InetAddressPrefixLength,
        InetAutonomousSystemNumber         FROM INET­ADDRESS­MIB;

    ipForward MODULE­IDENTITY

107
SNMP

Esempio di MIB definito con SMIV2 
   LAST­UPDATED "200402091200Z"
        ORGANIZATION
               "IETF IPv6 Working Group"
        CONTACT­INFO
               "Editor:
                Brian Haberman
                Caspian Networks
                753 Bridgewater Drive
                Sykesville, MD  21784

                     Phone: +1 410 552­1421

                    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

Esempio di MIB definito con SMIV2 
       REVISION      "199207022156Z"
        DESCRIPTION
               "Initial version, published as RFC 1354."
        ::= { ip 24 }

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


    inetCidrRouteNumber OBJECT­TYPE
        SYNTAX     Gauge32
        MAX­ACCESS read­only
        STATUS     current
        DESCRIPTION
                    "The number of current inetCidrRouteTable entries that

                    are not invalid."
    ::= { ipForward 6 }

    inetCidrRouteDiscards OBJECT­TYPE
        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  SNMPv2­MIB::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