In che modo gli switch gestiti gestiscono Broadcast Multicast e Unicast?


8

In scenari tipici, uno switch di rete deve gestire contemporaneamente i messaggi broadcast, multicast e unicast.

Mi piacerebbe capire

Su un tipico switch gestito (Ethernet da 1 Gb / Ethernet da 10 Gb),

a) come vengono gestiti i messaggi broadcast / multicast / unicast in modo diverso?

b) qual è la larghezza di banda e la latenza della gestione dei messaggi broadcast / multicast / unicast?

c) in che modo il carico di diversi tipi di messaggi si influisce reciprocamente?

d) Perché il passaggio dalla trasmissione al multicast (o è probabile, se eseguito correttamente) riduce il carico sull'interruttore?

Risposte:


5

Ciò dipende fortemente dall'architettura del particolare interruttore in questione. L'ampia gamma di prezzi per uno "switch gestito" a 48 porte (ad esempio da meno di $ 300 a ben oltre $ 10.000) dovrebbe dirti che c'è qualcosa di fondamentalmente diverso in corso all'interno. Se non hai pagato molto per il tuo switch (e spero di non averlo fatto), è molto probabile che il multicast (e altre funzionalità "enterprise") vengano trasferite al software (se supportate).

L'inoltro unicast di base è diventato piuttosto economico da eseguire in hardware, quindi mi aspetto che qualsiasi moderno switch Ethernet funzioni ragionevolmente bene all'inoltro unicast di base con carichi leggeri.

Quando inizi ad aggiungere più funzionalità all'hardware, il costo aumenta in modo significativo. Ad esempio, l'inoltro di frame unicast è molto diverso rispetto alla replica di pacchetti basata sullo stato dinamico multicast. Sono entrambi compiti molto specializzati. Ci vogliono bit specifici di hardware per fare bene uno dei due. La maggior parte degli utenti di switch di fascia bassa non ha enormi esigenze multicast. Il pagamento di hardware specifico per multicast è uno spreco per questi utenti.

Ma la maggior parte delle reti usa un po 'di multicast. Di conseguenza, è comune per i produttori implementare le funzionalità multicast e altre meno utilizzate nel software. Ad esempio, all'hardware di inoltro unicast verrebbe richiesto di inoltrare qualsiasi cosa con un indirizzo MAC multicast a una porta interna in cui sono ricevuti da un sottosistema CPU (o almeno un microcontrollore di qualche tipo). Quindi un processo software è in grado di esaminare il frame, consultare la tabella di inoltro multicast, replicare il frame e restituire più copie all'hardware, una per porta da inoltrare. Ovviamente molte funzioni possono essere aggiunte a questo punto nel software senza influenzare significativamente il costo dello switch.

In un tale sistema, le prestazioni non saranno mai vicine a ciò che è per unicast. Le prestazioni della CPU avranno ovviamente un certo impatto, ma se stai inviando così tanto traffico "d'eccezione" che non può essere inoltrato nell'hardware, stai sbagliando . Devi acquistare un interruttore diverso.

Nel peggiore dei casi, uno switch veramente di fascia bassa non avrà alcuna protezione delle risorse, quindi la stessa CPU che viene sbattuta con traffico multicast dimenticherà che è anche responsabile della cura e dell'alimentazione di tutto il resto dello switch. Se la CPU è troppo occupata a replicare il traffico multicast per mantenere aggiornate le tabelle unicast nell'hardware (o qualsiasi altra cosa la CPU dovrebbe fare), avrai tutti i tipi di problemi.


2
  1. Lo stesso degli switch non gestiti; possibilmente con l'aggiunta della complessità di vLAN e simili.
  2. Questo è specifico dell'implementazione, ma generalmente non c'è differenza. Le tempeste di pacchetti possono causare latenza, ma ciò non è correlato specificamente al tipo di pacchetto.
  3. Come il n. 2: implementazione specifica e generalmente nessuna differenza.
  4. "Carica" ​​non è un termine ben definito, penso che intendi l'utilizzo della porta. Il multicast viene inoltrato solo alle porte iscritte al gruppo in cui Broadcast viene inviato a ogni porta (soggetto ancora a complessità aggiunte come le vLAN).

Grazie Chris, vedo un'applicazione che causa una tempesta di trasmissione, generata da una grande quantità di messaggi di trasmissione. Dopo alcune ricerche, ho scoperto che i messaggi broadcast e multicast sono gestiti dal livello del software piuttosto che dall'hardware, l'elevato carico della CPU provoca la caduta dei pacchetti. Ecco perché mi piacerebbe sapere come uno switch (gestito / non gestito) gestisce ciascuno dei tipi di messaggio.
Anthony S.

Mi riferisco al carico della CPU su uno switch.
Anthony S.

Non c'è CPU su uno switch tipico. Ci sono processori di commutazione, alcuni switch gestiti hanno un processore di gestione dedicato ma nella maggior parte dei casi è integrato.
Chris S,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.