Torna alla pagina di Sistemi per l'elaborazione delle informazioni
:: Sistemi per l'elaborazione delle informazioni ::
Lezione 15 Ottobre 2007
NOTA: questa pagina in realtà sfora un po', nel senso che contiene anche roba che è stata affrontata in lezioni diverse. Però non era carino dividere il materiale, quindi è tutto qui dentro.
ARP
ARP sta per Address Resolution Protocol. È un sistema tramite il quale un host che per la prima volta si affaccia ad una rete recupera i MAC associati ad un certo IP. ARP è limitato ad una singola rete. Una macchina invia in broadcast un messaggio, e solo la macchina interessata gli risponde. Ecco che quindi posso costruirmi la mia tabella ARP con tutti i MAC corrispondenti agli IP sulla mia stessa rete.
Gli indirizzi IP, così come sono stati pensati in origine, permettono già nel guardarli di determinare se un indirizzo appartiene ad una rete o no. Ogni macchina fa questo controllo, prima di inviare un pacchetto. Se si accorge che l'Ip appartiene alla sua stessa rete, ma non ha il suo MAC, lo chiede tramite ARP. Se invece si accorge che l'IP appartiene ad un'altra rete, allora invia il pacchetto al gateway predefinito, il quale poi ci penserà lui a smistarlo dove deve.
In questo caso, com'è fatto lo header IP? Siamo nel caso in cui A vuole parlare con C che sta su una rete diversa. Il mittente è ancora A. Il destinatario IP è ancora C. Il destinatario MAC invece è il Gateway. Il default Gateway prende il pacchetto, e mette al posto del suo MAC il MAC di C. Detto così sembra un ballo di sigle e lettere ma in realtà è facile.
Inoltre, la tabella ARP che ogni host si crea è transitoria. Infatti, può benissimo darsi che dopo un po' un certo host si disconnetta dalla rete, e come facciamo a saperlo? Ethernet non ci aiuta, perché non garantisce la consegna di un frame. Semplicemente, il pacchetto gira a vuoto per poi scomparire nel nulla cosmico.
Quindi, dopo circa 20 minuti, la cache ARP viene rigenerata tramite il solito procedimento
Condizione d'integrità e frammentazione
Tutto il bel parlare fatto finora si basa su di un presupposto: se A vuole mandare un messaggio a C che sta su di un'altra rete, il suo pacchetto deve poter cambiare di rete. Se A sta su una Ethernet e C su una FDDI, allora anche il formato del frame cambierà. E il pacchetto che ci stava nei frame della Ethernet di A deve starci anche nel frame della FDDI, altrimenti non è possibile la comunicazione.
Questa è la famosa condizione d'integrità: il frame della rete sottostante deve essere grosso almeno quanto l'header IP, altrimenti non sarà possibile trasportare nessun payload.
Quindi, il gateway può trovarsi nella situazione di dover frammentare in modo diverso il bel pacchetto che A ha inviato a C, perché i frame della rete su cui si trova A sono diversi dai frame della rete su cui si trova C.
Un bell'esercizio potrebbe essere questo: il frame della rete 1 è 1500 byte, il frame della rete 2 è 500 byte. Il pacchetto è di 3000 byte. Scrivere i vari header IP con gli offset etc. etc. etc.. Divertitevi.
Nel caso contrario, ovvero che un pacchetto va da una rete con frame piccolo ad una rete con frame grande, il gateway non si preoccupa di riassemblarlo. O meglio, ci sono anche gateway che lo fanno, ma in genere non è proprio così.
Le Backbone
Le backbone già sappiamo che cosa sono. Collegano reti diverse. Ma per essere veloci, spesso non sono Ethernet, né tantomento Fast Ethernet. Sappiamo anche noi che una Fast Ethernet ha una lunghezza massima dei cavi che è risibile. Se devo collegare la sede della RaimonDigital di Mozzanica con gli uffici di Somaglia, mi occorre un bel fibrone ottico di quelli massicci, per inviare tutti i video porno in tempo utile. Per esempio, la Telecom mi affitta una SONET. Ma la SONET non è Ethernet, usa tecnologie diverse, come faccio io, povero studente di Crema, a sapere come far funzionare una SONET? A malapena so districarmi in un frame Ethernet...
La soluzione è presto servita: ci sono apparecchi che fanno uno sporco lavoro chiamato adaptation, ovvero SIMULANO una Ethernet. In pratica metto un computer all'estremità della mia sede di Mozzanica, il quale da un lato funziona come un Gateway Ethernet, e dall'altro invece converte tutto in SONET. Nella sede di Somaglia faccio la stessa cosa, e agli occhi della mia rete la SONET in mezzo appare come un altro frammento di Ethernet.
L'Adaptation è quindi il mettere insieme payload di diversi livelli 2, facendo sì che alle estremita ricompaia automagicamente un pacchetto di livello 3 accettabile. In questo caso, le macchine che fanno l'Adaptation mi vengono fornite in comodato dalle società che mi offrono la fibra ottica, e ci pensano loro a frammentare, non la mia rete.
Un altro scenario è quello in cui ho diverse reti locali, e devo collegarle insieme. In questo caso è utile avere Gateway diversi. Ci sono i gateway ai capi di ciascuna rete locale, i quali poi inoltrano i pacchetti che vanno alle altre reti ad un Gateway centrale, che poi li smista alla sottorete adatta. Questi Gateway costituiscono tra di loro delle reti interne per questo scopo.
E qui introduciamo la vera e propria gioia del corso di Sistemi: le sottoreti!
Sottoreti
Quando Internet veniva progettata, venne una bella idea ai suoi ideatori. Come accennavo qui sopra, un indirizzo deve sapermi dire subito se quell'host appartiene alla mia rete o meno. In pratica, l'indirizzo non è solo il nome di un host, ma è anche la via per raggiungerlo. Avendo stabilito di usare 32 bit per gli indirizzi, si è pensato di creare diverse classi che utilizzano più o meno bit per l'identificatore di rete, e i bit restanti per l'identificatore di host. Quando mando un pacchetto, confronto l'identificatore di sottorete del mio destinatario: se è uguale al mio, spedisco quel pacchetto sulla mia rete locale. Se non lo è, lo mando al Gateway di default e si arrangerà lui.
Le classi
Nell'innocenza dei primi tempi, si era pensato a dividere i vari indirizzi possibili in 5 classi, che pensavano sarebbero bastate. E invece no. Ma cmq ve le presento, con le loro sequenze di bit.
- Classe A: 0 | 7 bit di net ID | 24 bit di host ID
- Classe B: 10| 14 bit di net ID | 16 bit di host ID
- Classe C: 110 | 21 bit di net ID | 8 bit di host ID
- Classe D: 1110 | 28 bit di indirizzo multicast
- Classe E: 1111 | riservato per uso futuro.
Lo dico subito: delle classi D e E non ce ne frega niente.
Oltre all'assonanza con i modelli della Mercedes, ecco le caratteristiche delle nostre classi.
Gli indirizzi di classe A, vanno da 1.0.0.0 fino a 126.0.0.0, identificano quindi 127 reti diverse, ciascuna delle quali può avere 2^24 host, ovvero 16.777.216. Tantini, eh?
La classe B va da 128.1.0.0 fino a 191.255.0.0. Ci sono quindi (191 - 128) * 255 = 16.065 reti diverse, ognuna con 2^16 = 65.536 host diversi.
La classe C va da 192.0.1.0 a 223.255.255.0, quindi con tante tante reti, ma 2^8 = 256 host ciascuna.
Per essere veramente fighi, occorre saper riconoscere la classe d'appartenenza di un indirizzo al volo.
Ok, dov'è il problema?
Il problema balza all'occhio. Innanzitutto, essendo gli IP non solo il nome dell'host ma anche la via per raggiungerlo, quando un computer cambia rete deve anche cambiare host. Questo è ciò che accade comunemente.
Ma c'è dell'altro: se compro un indirizzo classe C, potrò avere al max 256 computer collegati in rete. Se compro un classe B ne avrò 256*256. Un classe A 256*256*256. Insomma, non ci sono molte vie di mezzo. Nel momento in cui la RaimonDigital passa da 256 computer a 257, dovrà passare dal suo classe C ad un classe B, e saranno dolori per gli amministratori di rete, e ci saranno tanti tanti tanti host sprecati. Insomma, così non va. Vedremo poi come risolvere queste imbarazzanti situazioni.
Multicast e Unicast
Internet lavora essenzialmente in Unicast. Ovvero mando un pacchetto ad uno e un solo destinatario, contrassegnato dal suo IP. Devo mandare lo stesso pacchetto a 2 destinatari? Lo replico. Se devo mandarlo a 1000 destinatari, lo replico 1000 volte.
Problema: se devo mandare in rete la trasmissione di un filmato, e ho 1000 utenti che me la stanno guardando, dovrò inviare 1000 pacchetti contemporaneamente. Ci sto dietro? Probabilmente sì. Ma se gli utenti sono 10.000? Allora la mia rete non ce la farà mai più.
Ecco che viene in soccorso il multicast: invio pacchetti a certi host, i quali poi rigirano agli host che si appoggiano a loro. In questo modo, se mando 1000 pacchetti a 1000 host, e ognuno regge altri 1000 host, trasmetterò a 1000*1000 spettatori. La classe D serve a questo, e non ci è dato sapere altro:)
Quali indirizzi usare?
Se la mia rete rimane isolata, posso usare gli indirizzi che voglio. A parte quelli con tutti 0 o tutti 1 nei vari campi net id o host id, che non dovrebbero usarsi (anche se adesso li si usano e basta), posso dare ai miei host gli indirizzi che voglio.
Però, che cosa succede se do ad un mio host l'indirizzo 72.14.253.104? Succede che tutte le volte che vado in Internet e vado su www.google.it, sarò reindirizzato al mio host, perché l'indirizzo di Google in rete è proprio 72.14.253.104! Ciò vuol dire che finché la mia rete è isolata posso usare gli indirizzi che voglio. Il problema nasce quando devo andare in Internet, perché gli indirizzi sono già stati usati.
Chi da via gli indirizzi? La IETF. Per esempio, gli indirizzi che vanno da 9.0.0.0 a 9.255.255.255 (che classe è? Una A) sono di IBM. 12.0.0.0 è di AT&T. 13.0.0.0 è di Xeros Palo Alto Research Center, 17.0.0.0 è proprietà di Apple Computer, Inc. Se volete scoprire di chi è un certo sito, oppure viceversa a chi appartiene un certo IP, http://www.who.is è quello che fa per voi.
Classful e classless
L'indirizzamento Classful è quello che abbiamo illustrato qui sopra: usa le classi. L'indirizzamento Classless invece fa a meno delle classi, o meglio, trasforma una classe in qualcosa di più utilizzabile.
Innanzitutto, dobbiamo vedere come fa un computer a stabilire se un IP è sulla sua stessa rete o no. Prendiamo un classe B 180.23.45.70. Devo inviare messaggi a 180.23.60.90. È sulla mia stessa rete o no? La risposta è sì, perché un classe B usa i primi 2 ottetti per identificare la rete, e in questo caso sono uguali.
Il sistema che usa il computer è il seguente: so che è un classe B, quindi so che deve avere i primi 16 bit di net id. Prendo quindi una maschera, cioè una stringa di bit. In questo caso la mia maschera avrà 16 bit tutti a 1, e 16 bit tutti a 0: 11111111 11111111 00000000 00000000.
Perché? Perché so che il mio indirizzo è un classe B, quindi ha 16 bit di net id (l'ho detto qui sopra). Ma perché 1? Presto detto. Se faccio un AND logico tra i bit del mio indirizzo e quelli della maschera, esce una cosa così:
180.23.45.70 diventerebbe 10110100.00010111.00101101.01000110.
180.23.45.90 diventa invece 10110100.00010111.00101101.01011010.
Adesso faccio l'AND logico del mio indirizzo e di quello della maschera di sottorete, ovvero 255.255.0.0 = 11111111.11111111.00000000.00000000
10110100.00010111.00101101.01000110 &
11111111.11111111.00000000.00000000 =
------------------------------------
10110100.00010111.00000000.00000000
Ora faccio l'AND logico dell'indirizzo di destinazione e di quello della maschera.
10110100.00010111.00101101.01011010 &
11111111.11111111.00000000.00000000 =
-------------------------------------
10110100.00010111.00000000.00000000
I primi 16 bit (sono su un classe B, quindi mi interessano solo quelli) corrispondono? SÌ => 180.23.45.90 è sulla mia stessa rete, quindi lo invio in locale.
Se invece NON corrispondevano, allora mandavo il pacchetto al default gateway, secondo la procedura descritta sopra. Ecco quindi come fanno i computer a stabilire se un host è sulla mia stessa rete o no.
Il trucco ora comincia a diventare chiaro. Se invece della maschera normale che dovrei avere ne uso un'altra, che cosa succederebbe? Mi spiego: i classe A hanno come maschera 255.0.0.0, i classe B hanno 255.255.0.0, e i classe C hanno 255.255.255.0. Ogni host fa il controllo spiegato qui sopra, e si vede subito se l'IP appartiene alla mia rete o no.
Ma mettiamo il caso di avere comprato un classe C, e di volerlo usare per tutti i computer, di cui alcuni al piano di sopra e alcuni al piano di sotto. Per evitare che tutti i pacchetti girino per la casa inutilmente, ho deciso di creare due reti distinte, una per il piano di sopra, e una per il piano di sotto. Entrambe sono collegate ad un gateway piazzato sul pianerottolo delle scale, il quale poi è connesso anche ad Internet. I computer che ho al primo piano comunicano spesso tra di loro, e raramente con quelli del piano di sotto. Quelli del piano di sotto comunicano, allo stesso modo, spesso tra di loro e raramente con quelli di sopra. Mi sembra quindi ovvio avere due sottoreti distinte.
Come faccio a distinguere due sottoreti, avendo una gamma continua di indirizzi che va da 220.82.10.0 fino a 220.82.10.255? Il sistema che adotto è quello di configurare i miei host non con la maschera che sarebbe normale con un classe C, ovvero 255.255.255.0, ma con una maschera diversa, più lunga.
Se usassi la maschera normale, tutti i pacchetti girerebbero per tutta la rete, perché ovviamente tutti i computer di casa mia appartengono alla stessa sottorete chiamata 220.82.10.x. E questo è ciò che voglio evitare.
Allora faccio così: la mia maschera di default sarebbe 11111111.11111111.11111111.00000000. Bene, decido di usare un bit in più per maschera: 11111111.11111111.11111111.10000000. Che cosa succede? Succede che usando questa maschera, tutti i computer che hanno un indirizzo il cui primo bit del quarto ottetto è a 0, si vedranno su di una rete locale. Idem per tutti i computer che hanno il primo bit del quarto ottetto a 1. Quando un computer che ha il primo bit a 0 vuole comunicare con un computer che ha il primo bit a 1, si accorge che non è nella sua stessa sottorete, e invia il pacchetto al Gateway.
Traducendo dal binario all'italiano, la maschera da 255.255.255.0 diventa 255.255.255.128. Il quarto ottetto è 128 perché 10000000 in binario è 128. Le mie sottoreti sono fatte così:
- va da 220.82.10.0 fino a 220.82.10.127
- va da 220.82.10.128 fino a 220.82.10.255
Usando quindi una maschera non standard, ho utilizzato un bit in più del dovuto (nessuno me lo impedisce) per creare due sottoreti ad uso e consumo della disposizione dei computer in casa mia.
Quanti host ho, alla fine?
Come disse Pier Damiani, gli host (e i net id) con tutti 0 non si usano. Nel mio caso, 220.92.10.0 NON lo uso, così come NON posso usare 220.92.10.127, 220.82.10.128 e 220.82.10.255. I due .0 e .255 li posso capire, ma perché non posso usare nemmeno i .127 e i .128? Il motivo è che, avendo usato un bit in più per la sottorete, l'effettivo host id di questi due computer in binario sarebbe 11011100.01011100.00001010.01111111. In grassetto ho messo l'host ID. Siccome ho usato 25 bit per l'indirizzo di RETE, i rimanenti 7 bit sono l'indirizzo di HOST => 127 in binario si scrive 01111111 (se uso 8 bit) => tolgo il primo => mi rimane 1111111 e per la regola enunciata sopra gli host id tutti a 1 NON li uso.
Stesso discorso per 220.92.10.280: sarebbe 11011100.01011100.00001010.10000000 con in grassetto l'host id, e l'host id tutto a 0 non posso usarlo. Quindi, in totale spreco 4 host, ma ho due sottoreti con un unico classe C.
Ampliamo il discorso
Voglio quattro sottoreti con un classe C? Pronti: uso 2 bit del quarto ottetto. La maschera da 255.255.255.0 (in binario 11111111.11111111.11111111.00000000) diventa 255.255.255.192 (in binario 11111111.11111111.1111111.11111111.11000000), e spreco 8 host. Voglio otto sottoreti? Uso 3 bit, la maschera diventa 255.255.255.224 e spreco 16 host etc. etc. etc. Tutto questo discorso si chiama FLSM, ovvero Fixed Length Subnet Mask: la maschera di sottorete che uso per tutti i miei host è sempre la stessa.
C'è da fare un'altra osservazione: prima ho scritto che NON si possono usare i prefissi di rete tutti a 0 o tutti a 1. Nella divisione che ho fatto sopra, ho 2 sottoreti, una il cui prefisso è proprio 0, e l'altra il cui prefisso è proprio 1. A parte il fatto che non è vero che non si possono usare ste sottoreti, se l'esercizio lo chiede, per avere 2 sottoreti devo crearne in realtà 4, e non usare le due sottoreti che stanno all'estremo. Spreco quindi degli host, per rispettare questo risibile standard.
La cosa è ammissibile e fattibile, ma c'è un limite, che si incontra abbastanza rapidamente. A parte il fatto che spreco host, va beh, non sono poi molti. Ma supponiamo di volere 4 sottoreti. Quanti host possono avere al massimo le mie 4 sottoreti? Ho detto che per avere 4 sottoreti uso 2 bit del 4° ottetto. Mi rimangono 6 bit, quindi 2^6 = 64 possibili host per rete. Tolgo i 2 estremi, e ho 62 host per ogni sottorete.
Ma se ho 4 sottoreti, di cui una da 80 host, e le altre da 20? Posso farlo con questo sistema? La risposta è evidente: NO. Non ci sto dentro, semplicemente: se divido un classe C in 4 sottoreti con questo sistema, le reti possono arrivare a 62 host ciascuna, non di più, quindi o compro un classe B (sprecando centinaia di host) oppure escogito qualche altro sistema.
VLSM
VLSM sta per Variable Length Subnet Mask. Vuol dire che il trucchetto che ho appena usato per creare sottoreti a partire da un indirizzo lo estendo: per alcune sottoreti uso un bit in più, per altre ne uso 2 etc.
Sempre rimanendo nell'ipotesi di poter usare anche i net id tutti 0 o tutti 1, se ho una situazione con 3 sottoreti da 80, 20 e 30 pc ciascuna, ecco come posso fare:
- la rete da 80 la metto con maschera 255.255.255.128, e attribuisco indirizzi da .0 a .127.
- le altre reti avranno invece come maschera 255.255.255.225: una con indirizzi da .128 a .192, l'altra da .192 a .256.
Per quanto riguarda i Gateway, ne metto uno a capo di ciascuna rete, e un altro che butta su Internet, collegato a ciascuno dei miei 3 gateway interni.
Semplice, no? La cosa si complica quando devo stare attento a non usare i famosi tutti 0 e tutti 1 etc. etc. Però in questo modo sono un po' più flessibile che nemmeno col sistema precedente.
Configurare le sottoreti
Dopo queste spiegazioni, ecco che possiamo scoprire quali parametri servono per configurare un qualsiasi host collegato in rete:
- indirizzo IP
- indirizzo IP del default Gateway
- maschera di sottorete
Con queste tre cose ben configurate, si viaggia alla grande:) Vai zio!
DHCP
Supponiamo di avere in casa 300 computer, e un classe C. Un classe C ovviamente non basta, però so anche che contemporaneamente non avrò mai più di 200 computer accesi. Quindi, che faccio? Mi occorrerebbe un sistema per dare un indirizzo IP valido solo ai computer effettivamente accesi.
Ebbene, quel sistema c'è e si chiama DHCP, che vuol dire Dynamic Host Configuration Protocol. Ha avuto dei predecessori, che si chiamavano RARP e BOOTP, ma chi se ne frega.
Funziona così: un computer che è stato configurato per usare DHCP, quando si connette in rete broadcasta un messaggio che implora un indirizzo. Il server DHCP lo sente, e in base alla sua configurazione gli assegna un indirizzo valido.
La configurazione di un server DHCP è tale per cui posso stabilire il range di indirizzi da attribuire (eg, da 192.168.1.100 fino a 192.168.1.200), e il tempo di LEASE, ovvero quanto a lungo l'indirizzo rimane assegnato a quella macchina. Scaduto il tempo, la macchina deve richiederlo nuovamente. La faccenda del leasing serve perché se gli IP vengono assegnati con durata di 1 giorno, per esempio, e io sto connesso solo 2 ore e poi me ne vado col mio portatile, quell'IP non sarà più utilizzabile per il resto della giornata. Assieme all'IP naturalmente il DHCP dà via anche il default gateway e la maschera di sottorete.
Inoltre è possibile configurare un server DHCP in modo che assegni sempre lo stesso indirizzo a certi host. Per esempio, la mia stampante laser è una stampante di rete, solo che non è in grado di tenere in memoria il suo indirizzo IP. Ho quindi configurato il mio DHCP in modo che ogni volta che la stampante cerca un indirizzo col suo MAC, il server controlla, vede che il MAC deve corrispondere ad un certo indirizzo, e quindi assegna alla mia stampante sempre lo stesso indirizzo 192.168.0.100. Altrimenti ogni volta che la accendo dovrei configurare i driver sui computer su di un nuovo indirizzo.
Classi di indirizzi privati
Le autorità di Internet, visto il mezzo pasticcio che hanno combinato con le classi, hanno pensato di ovviare in qualche modo alla situazione. In effetti, perché mai dovrei comprare indirizzi classe C per andare su Internet quando ho 10 computer e basta! Al giorno d'oggi, i vari provider hanno un range di indirizzi, e quando uno si connette ne riceve uno da quelli disponibili. E se voglio una rete in casa?
IETF ha riservato alcuni indirizzi all'uso privato: vuol dire che non possono esistere sulla Internet pubblica host con questo indirizzo.
- classe A privato: 10.0.0.0 ~ 10.255.255.255
- classe B privato: 172.16.0.0 ~ 172.32.255.255 (ho 16 classe B contigui)
- classe C privato: 192.168.0.0 ~ 192.168.255.255 (ho 255 classe C contigui)
Tutti i router sono configurati per NON inviare su Internet questi pacchetti, che possono quindi essere usati felicemente all'interno di ogni rete. Poi posso subnettare a volontà queste sottoreti, come più mi piace e pare.
Zeroconf
C'è un ulteriore modo per ottenere indirizzi. Se all'avvio non riesco a contattare nessun server DHCP, se uso la configurazione Zeroconf allora mi autoassegno un indirizzo che va da 169.254.1.0 a 169.254.254.255. Me lo autoassegno con una procedura pseudocasuale. In caso qualcun altro sta usando il mio stesso indirizzo zeroconf sulla mia stessa rete, ne creo un altro.
Torna alla pagina di Sistemi per l'elaborazione delle informazioni
