Standard de facto. Inventato negli anni '70 da Metcalfe. Disegno nella tesi di PhD #x004 Si vede come il protocollo sia stato originariamente pensato per funzionare su una rete con topologia a bus.
Attualmente la topologia a stella è predominante.
Inizialmente pensato per viaggiare a 10Mbps, ora un Cat 8 può arrivare a 100Gbps.
#Vedi Ethernet over optical fiber
Tipo di collegamento: pensato per funzionare su canali broadcast (grazie all'indirizzamento MAC) - quindi non punto-punto - siccome inviato un pacchetto, tutti gli altri host connessi alla rete lo ricevono. Ma utilizzato per trasmissioni unicast.
- Indirizzamento: MAC address
- Frame Ethernet (contenuto degli header)
- Protocollo ARP
- Accesso al mezzo (CSMA/CD)
A livello Ethernet gli host usano un indirizzo MAC - Media Access Control - o indirizzo hardware associato alla NIC - Network Interface Card - dell'host. L'indirizzo MAC di ogni NIC è univoco, ha 48 bit (= 6 ottetti) ed è tipicamente rappresentato come 6 coppie di nibble - cifre esadecimali: a6:99:a7:77:49:76
L'indirizzo broadcast è FF:FF:FF:FF:FF:FF -> accettato da tutte le NIC sulla rete
Caratteristiche dell'inidirizzo:
- permanente memorizzato sulla ROM della NIC e non modificabile, anche se l'autenticazione basata su MAC è inaffidabile; gli amministratori del PC possono, attraverso il sistema operativo, impostare un differente indirizzo MAC temporaneo, senza modificare quello permanente.
- univoco in quanto assegnato dai produttori delle NIC in accordo con l'autorità centrale IEEE. Per convenzione (non è una questione tecnica) la prima parte dell'indirizzo ("prefisso") è assegnata ad ogni produttore; ma esistono aziende (soprattutto piccoli produttori meno popolari) che non rispettano questa convenzione. L'univocità è importante a livello locale.
- piatto (vs gerarchico come numeri di telefono o IP addresses)
Autenticazione = processo attraverso il quale si cerca di avere una prova che un dispositivo sia realmente quello che si pensa che sia. Es: allowed-list (whitelist) su bridge and switch
Ciascun host di una LAC ha un indirizzo IP e un indirizzo MAC associato alla NIC. Perché due sistemi di indirizzamento? non si potrebbe avere un unico indirizzo (tipo quello IP) univoco globalmente? No, per diverse ragioni. Tra queste vogliamo che il livello 2 resti semplice e facilmente implementabile via hardware.
L'operazione di filtraggio viene eseguita dalla NIC, senza interpellare il sistema operativo; il micro gestisce l'accettazione con interrupt e simili senza interrompere la CPU. La logica viene spezzata tra SO e NIC.
Se un host vuole trasmettere inserisce il MAC di destinazione nel frame e lo trasmette.
Le interfacce possono essere configurate in modo tale da non fare filtraggio -> sniffing: ispezione del traffico -> modalità promiscua
I pacchetti scambiati a livello h2n vengono chiamati frame (cornici, non pacchetti, perché il payload è circondato da informazioni di gestione). Tutte le tecnologie ethernet fanno uso dello stesso frame.
| preambolo | indirizzo dst | indirizzo src | tipo | dati ... | CRC |
| 8 byte | 6 byte | 6 byte | 2 byte | | 4 byte |
Preambolo e CRC servono prettamente per la comunicazione fisica del segnale; infatti questi campi non si vedono mai a livello SO. Indirizzo dst e src servono per la logica di livello 2.
Non ha contenuto informativo, dato che trasporta sempre lo stesso treno di bit. Ha un ruolo di attivazione e sincronizzazione.
I primi 7 byte sono 10101010, mentre l'ultimo 10101011.
Il campo tipo serve per la logica di multiplazione, nella maggior parte dei casi IP, sebbene non sia sempre così. A cosa interessa al livello 2 quale protocollo di livello 3 sta incapsulando? Questo sporca l'eleganza dello stack: in base al tipo il frame può essere gestito diversamente. Ad esempio se il protocollo contenuto è ARP esso non viene inoltrato al SO (o qualsiasi altro protocollo gestibile dalla NIC). Ogni volta che inseriamo un campo aggiungiamo un costo. Qual'era l'alternativa? ispezionare il payload.
controllo a ridondanza ciclica. È un digest o checksum.
È una garanzia di integrità del frame -> permette di rilevare la presenza di un errore nel frame ricevuto.
Si mette alla fine perché calcolato dopo la trasmissione di tutto il frame (con il contenuto del buffer di trasmissione?)
Integrità diverso da affidabilità (avere una logica di ritrasmissione e in grado di accorgersi della perdita di un pacchetto) e da sicurezza (se il pacchetto arriva allora non è stato compromesso ecc.)
Gli algoritmi CRC sono più veloci di hash crittografici e simili. I bit di parità sono più efficienti ma meno efficaci.
Eseguire in software un algoritmo (pensa gli anni '70) di checksum è un'operazione lenta.
La dimensione massima del payload contenuto nel frame ethernet (MTU - Maximum Transfer Unit) è 1500 bytes ovvero 1.5Kb. Questa dimensione non include preambolo e CRC. Superati 1500 byte è necessario frammentare il pacchetto. Il frame è grande 1520 bytes.
La dimensione minima del payload è 46 byte -> stuffing se la dimensione è inferiore.
Tradeoff dell'MTU?
- grande:
- PRO: ho un overhead basso
- CONTRO: è più probabile che qualcosa vada storto (corruzione porta alla ritrasmissione di molti dati) Con canali di comunicazioni affidabili si può aumentare la dimensione dell'MTU. Raccomandazione dimensione minima MTU: 600 byte. Si possono avere sullo stello livello MTU di dimensioni diverse. Fino a 600 byte la frammentazione è garantita, per MTU inferiori no.
Jumbo frame: frame di dimensioni superiori a quelle standard -> 9000 byte su reti ad alta velocità.
Come fa la NIC a gestire la traduzione tra IP e MAC? Si usa un sottoprotocollo di Ethernet - ARP (Address Resolution Protocol) - per l'associazione dinamica IP - MAC.
---------------------------------------
| | | | |
v w x y z
Fasi:
- w vuole comunicare un host nella sua rete - y, ma conosce solo il suo IP.
- Invia una richiesta broadcast
- Stanno tutti in silenzio a parte y, che risponde alla richiesta ARP. L'indirizzo si deduce da SRC ADDR in eth's frame
Ogni quanto eseguo il protocollo? ARP cache -> tabella in cui vengono salvati i risultati delle risoluzioni ARP precedenti. Per ridurre il traffico di rete causato dallo scambio di messaggi ARP.
Ciascun host effettua caching nella tabella di instradamento. Ogni entry della tabella ha un TTL - Time To Live - dopo il quale è necessaria una nuova richiesta.
Dato un indirizzo IP:
- se presente lo uso
- se assente o TTL scaduto -> invio una nuova richiesta ARP
- La risposta arriva -> aggiorno/inserisco la voce nella tabella
- La mancata risposta significa che l'host non è presente nella rete -> equivale a rispondere negativamente
I protocolli ARP possono essere attaccati: arp poisoning -> una mitigazione potrebbe essere la compilazione della tabella ARP manualmente da parte dell'amministratore di rete con TTL infiniti
Il protocollo RARP - Reverse ARP -, ormai deprecato, serve ad ottenere un indirizzo IP a partire dal proprio indirizzo MAC.
Le comunicazioni moderne sono IP-centriche (vedi clessidra).
L'accesso al mezzo è una questione prettamente fisica.
Ogni volta che voglio trasmettere qualcuno potrebbe star facendo lo stesso sul mezzo condiviso (topologia a bus). Devo fare listen before talking o CS - Carrier Sense (rilevazione della portante = la NIC rileva il segnale elettrico sul bus).
Se il mezzo è libero trasmetto subito o aspetto un po' di tempo? Aspetto, ascoltando, una quantità di tempo pari all'inter frame gap -> due frame consecutivi vengono sempre distanziati da un tempo pari a IFG; questo è un dato derivato pari al tempo corrispondente alla lunghezza del pacchetto più piccolo, quindi dipende dalla velocità della rete. #Riguarda
A causa del ritardo di propagazione del segnale elettrico possono avvenire accessi multipli - MA
Mentre trasmetto ascolto: CD - Collision Detection -> si avvisano tutti gli altri host che la rete ha avuto una collisione: segnale di jamming (disturbo) per avvisare tutti gli host; lunghezza di 48 bit.
Per evitare che tutti si affollino nella ritrasmissione si usa un jitter pseudo-casuale per generare uno sfasamento tra le ritrasmissioni (fino a un massimo di 16). #Vedi algoritmo di exponential back-off: aumenta sempre di più la probabilità di disaccoppiare due invii simultanei. n è limitato a 10. Da 10 a 15 rimane costante. Alla 16 collisione si rinuncia.
Cerco di risolverlo best-effort: provo ma non garantisco.
Dispositivi intermedi:
- L1 hub
- L2 switch
- L2 bridge
L'hub è un dispositivo di rete intermedio a livello 1 a.k.a. un ripetitore elettrico che opera a livello dei "bit". Permette di contrastare l'attenuazione dei segnali. Aumenta distanze e resilienze ai guasti
Dominio di collisione: all'interno di una rete eth si definisce dominio di collisione l'insieme degli host che ricevono gli stessi segnali elettrici (ricevono lo stesso frame se inviato da un dispositivo della LAN), ovvero il set di host che potrebbero, inviando un segnale contemporaneamente, far avvenire una collisione.
Switch: dispositivo di rete fisico, intermedio, con una o più interfacce simile ad un hub che implementa la funzionalità di inoltro selettivo grazie alla sua capacità di leggere il frame Ethernet. Ha i vantaggi dell'hub, ma in più limita i domini di collisione, aumentando il massimo throughput consentito sulla rete.
Logica store and forward: memorizza tutto il frame ricevuto, analizza dst, verifica errori (nel caso scarata) e inoltra. Riduce il numero di collisioni (perché implementa l'inoltro selettivo), ma potrebbero emergere problematiche di congestione (quando memoria finisce vengono scartati i frame + vecchi). Evita che frame malformati girino per la rete.
Logica cut through: alternativa alla logica store and forward che non immagazzina tutto il frame ethernet, ma ne legge una parte, inoltrando il frame direttamente (appena conosce il destinatario).
#Ricorda: collisione e congestione
Filtraggio: logica che inoltra pacchetti solo ai segmenti di LAN interessati, non a tutti gli altri Inoltro: logica che conosce quale segmento della rete LAN deve essere inoltrato il frame? usa il MAC address. Apprende la disposizione dei segmenti attraverso il mac address sorgente.
Ricorda che il frame è composto così: ... | MAC DST | MAC SRC | ...
La destinazione viene prima perché utile agli switch cut through.
Algo per frame broadcast -> easy -> inoltro su tutte le porte Algo per frame unicast:
- leggo mac src e dst. Mappo la src alla porta su cui ho ricevuto il frame.
- [PORTA IGNOTA] se non conosco la dst inoltro a tutte le porte -> fallback logic
- [PORTA NOTA] se la conosco inoltro solo alla porta interessata
#Attenzione mappo solo in base alla porta sorgente
Le informazioni vengono memorizzate sulla switching table: anche in questo caso ogni entry ha un TTL associato. Utile per evitare che la rete si riempia, ma anche per ripopolare la tabella se un dispositivo viene spostato: non esistono logiche di timeout o simili
Problematiche:
- la tabella di switching si può riempire. Cosa succede? la policy solitamente prevede che, quando piena, non venga più riempita
- la memoria di inoltro può riempirsi
#Ricorda : uno switch è un dispositivo passivo, non esegue logica di discovery, non genera traffico
Spesso le interfacce degli switch sono full-duplex, non ho una collisione neanche se un host invia mentre riceve un frame. Total capacity: N * speed_of_segment
#Ricorda che ad una porta di uno switch possono essere collegati più host (topologia a bus, hub, ecc.) -> un mac è collegato sicuramente ad una sola porta, ogni porta non è detto che sia associata ad un solo mac. Topologia a stella diramata.
#Ricorda che gli switch implementano anche una logica di bridging
Sono dispositivi simili agli switch le cui interfacce possono implementare protocolli h2n differenti. Sono in grado di analizzare i frame per consentire la "conversione di protocollo"
2 logiche di inoltro:
- bridging trasparente: inoltra frame tra porte con logiche di lv1 analoghe
- bridging non trasparente: inoltra frame adattandoli alla logica di lv1 della porta di destinazione
Uno switch è un bridge specializzato per avere ogni porta che opera con protocollo h2n uguali tra loro -> bridge trasparente.
Se gli switch hanno più porte a velocità differenti quella più performante viene assegnata al dispositivo che probabilisticamente genera più traffico.
Lo switch può essere considerato un bridge trasparente che traduce frame inviati a velocità differenti.
**![[TreeNet.png]]
Rete multi-livello**: uso gli switch per creare un "albero" di host, ovvero una rete gerarchica. Consentono la combinazione di interfacce eterogenee (velocità differenti, sbilanciate verso le interfacce verso la radice). Non scala bene con il numero di nodi: tutta la rete "saturata" quando viene inviata una richiesta ARP. È una topologia a single point of failure: rompo un collegamento a monte e disconnetto molti nodi dalla rete (disservizio); per mitigare questo problema si crea ridondanza. ![[Redundancy.png]] Ridondanza della rete gerarchica, per aumentare l'affidabilità: si predispongono cammini alternativi
Problema: si creano loop = cammini chiusi che portano all'origine
Serve un estensione di Ethernet per gestirli: spanning tree protocol -> albero di copertura completo senza cicli, riconfigurabile automaticamente. Non è gestito dagli host ma dagli switch. Scelgo selettivamente quali link disattivare per impedire i cicli.
Prevede una logica per riattivare i link disabilitati. Ma non una logica per sfruttare la presenza di più link per aumentare il throughput.
Si definisce un root switch, con id più basso, quindi a priorità maggiore. Si tengono attivi solamente i link a priorità maggiore che permettono di comunicare con il root switch.
Normative che evitano caos nel cablaggio delle reti.
Regole per la creazione di cablatura in edifici, nei campus o tra civici differenti.
- armadio di piano
- cavo di distribuzione di piano
- dorsale edificio
- dorsale di comprensorio
#Attenzione alla differenza tra topologia logica e fisica