Passa al contenuto principale

2. Raccomandazioni per lo snooping IGMP (IGMP Snooping Recommendations)

Le sezioni seguenti elencano le raccomandazioni per uno switch con snooping IGMP. La raccomandazione viene enunciata e poi integrata dalla descrizione di un possibile approccio implementativo. Tutte le discussioni implementative sono solo esempi e vi sono certamente altri modi per ottenere la stessa funzionalità.

2.1. Regole di inoltro (Forwarding Rules)​

La funzionalità di snooping IGMP si divide in una parte di controllo (inoltro IGMP) e in una parte dati (inoltro dei dati).

2.1.1. Regole di inoltro IGMP (IGMP Forwarding Rules)​

  1. Uno switch con snooping DOVREBBE (SHOULD) inoltrare i rapporti di appartenenza IGMP solo alle porte a cui sono collegati router multicast.

In altri termini: uno switch con snooping NON DOVREBBE (SHOULD NOT) inoltrare i rapporti di appartenenza IGMP alle porte a cui sono collegati solo host. Può essere previsto un controllo amministrativo che annulli questa restrizione, consentendo di inondare i messaggi di rapporto verso altre porte.

Questa è la principale funzionalità di snooping IGMP per il percorso di controllo.

Per IGMPv1 e IGMPv2, l'invio di rapporti di appartenenza ad altri host può impedire involontariamente a un host di unirsi a uno specifico gruppo multicast. Quando un host IGMPv1 o IGMPv2 riceve un rapporto di appartenenza per un indirizzo di gruppo a cui intende unirsi, sopprime il proprio rapporto di appartenenza per lo stesso gruppo. Questa soppressione dell'adesione (o del messaggio) è un requisito per gli host IGMPv1 e IGMPv2. Tuttavia, se lo switch non riceve un rapporto di appartenenza dall'host, non gli inoltrerà i dati multicast.

Ciò non costituisce un problema in una rete composta solo da IGMPv3, perché non vi è soppressione dei rapporti di appartenenza IGMP.

Il controllo amministrativo consente ai messaggi di rapporto di appartenenza IGMP di essere elaborati da apparecchiature di monitoraggio della rete, quali analizzatori di pacchetti o replicatori di porta.

Lo switch che supporta lo snooping IGMP DEVE (MUST) mantenere un elenco dei router multicast e delle porte a cui sono collegati. Tale elenco può essere costruito con qualsiasi combinazione dei seguenti metodi:

  • a) L'elenco DOVREBBE (SHOULD) essere costruito facendo inviare dallo switch messaggi di sollecitazione del router multicast (Multicast Router Solicitation) come descritto nella IGMP Multicast Router Discovery [MRDISC]. Esso può anche intercettare i messaggi di annuncio del router multicast (Multicast Router Advertisement) inviati da e verso altri nodi.

  • b) La porta di arrivo delle query IGMP (inviate dai router multicast) il cui indirizzo sorgente non è 0.0.0.0. L'indirizzo 0.0.0.0 rappresenta un caso speciale in cui lo switch inoltra per conto terzi (proxying) le query IGMP per accelerare la convergenza della rete, ma non è esso stesso il Querier. Lo switch non usa il proprio indirizzo IP (anche se ne possiede uno), perché ciò farebbe apparire le query come provenienti da un Querier appena eletto. L'indirizzo 0.0.0.0 è usato per indicare che i pacchetti di query NON provengono da un router multicast.

  • c) Porte configurate esplicitamente dalla gestione come porte di inoltro IGMP, in aggiunta o in alternativa a uno dei metodi precedenti di rilevamento delle porte dei router.

  1. Le reti IGMP possono anche includere dispositivi che implementano il "proxy-reporting", in cui i rapporti ricevuti dagli host a valle vengono riepilogati e usati per costruire stati di appartenenza interni. Tali dispositivi possono usare l'indirizzo sorgente IP tutto-zero quando inoltrano i rapporti riepilogati verso monte. Per questo motivo, i rapporti di appartenenza IGMP ricevuti dallo switch NON DEVONO (MUST NOT) essere respinti perché l'indirizzo IP sorgente è impostato a 0.0.0.0.

  2. Lo switch che supporta lo snooping IGMP DEVE (MUST) inondare tutti i messaggi IGMP non riconosciuti verso tutte le altre porte e NON DEVE (MUST NOT) tentare di utilizzare informazioni oltre la fine dell'intestazione di livello rete.

Inoltre, le versioni precedenti di IGMP dovrebbero interpretare i campi IGMP come definiti per la propria versione e NON DEVONO (MUST NOT) modificarli durante l'inoltro del messaggio. Quando genera nuovi messaggi, una determinata versione di IGMP dovrebbe impostare i campi ai valori appropriati per la propria versione. Se alcuni campi sono riservati o non definiti per una determinata versione di IGMP, essi dovrebbero essere ignorati durante l'analisi del messaggio e DEVONO (MUST) essere posti a zero quando le implementazioni di quella versione generano nuovi messaggi. Può verificarsi un'eccezione se lo switch sta svolgendo una funzione di spoofing ed è a conoscenza delle impostazioni dei campi nuovi o riservati necessarie per falsificare correttamente un'altra versione di IGMP.

La ragione per occuparsi di questi dettagli è che IGMPv3 riutilizza il vecchio messaggio di query IGMP con lo stesso numero di tipo (0x11) ma con un'intestazione estesa. Esiste quindi il rischio che le query IGMPv3 vengano interpretate come query di versioni precedenti, ad esempio da switch con snooping IGMPv2. Ciò è già stato segnalato [IETF56] ed è discusso nella sezione 2.2.

  1. Uno switch con snooping IGMP DOVREBBE (SHOULD) essere consapevole dei cambiamenti di topologia dello strato di collegamento causati dall'operazione di spanning tree. Quando una porta viene abilitata o disabilitata dallo spanning tree, è possibile inviare una General Query su tutte le porte attive non-router per ridurre il tempo di convergenza della rete. Gli switch non Querier DOVREBBERO (SHOULD) sapere se il Querier è in modalità IGMPv3. In tal caso, lo switch NON DOVREBBE (SHOULD NOT) falsificare alcuna General Query, a meno che non sia in grado di inviare una query IGMPv3 conforme alle informazioni più recenti inviate dal vero Querier. In nessun caso uno switch deve introdurre una query IGMPv2 falsificata in una rete IGMPv3, poiché ciò può causare gravi perturbazioni della rete.

Se lo switch non è il Querier, DOVREBBE (SHOULD) usare l'indirizzo sorgente IP "tutto-zero" in queste query per conto terzi (anche se alcuni host possono scegliere di non elaborare query con indirizzo sorgente IP 0.0.0.0). Quando tali query per conto terzi vengono ricevute, NON DEVONO (MUST NOT) essere incluse nel processo di elezione del Querier.

  1. Uno switch con snooping IGMP NON DEVE (MUST NOT) utilizzare le informazioni contenute nei pacchetti IGMP in cui le intestazioni IP o IGMP presentano errori di checksum o di integrità. Lo switch NON DOVREBBE (SHOULD NOT) inondare tali pacchetti; se tuttavia lo fa, DOVREBBE (SHOULD) prenderne nota (ad esempio incrementando un contatore). Tali errori e la loro gestione sono ulteriormente discussi in [IGMPv3], [MLD] e [MLDv2].

  2. Lo switch NON DEVE (MUST NOT) affidarsi esclusivamente alla comparsa di annunci di abbandono del gruppo IGMP (Group Leave) per determinare quando le voci devono essere rimosse dalla tabella di inoltro. DOVREBBE (SHOULD) implementare un meccanismo di timeout dell'appartenenza, come la funzionalità lato router del protocollo IGMP descritta nelle specifiche IGMP e MLD (si veda la sezione dei riferimenti normativi per IGMPv1-3 e MLDv1-2), su tutte le porte non-router. Tale valore di timeout DOVREBBE (SHOULD) essere configurabile.

2.1.2. Regole di inoltro dei dati (Data Forwarding Rules)​

  1. I pacchetti con indirizzo IP di destinazione al di fuori di 224.0.0.X che non sono IGMP DOVREBBERO (SHOULD) essere inoltrati secondo le tabelle di appartenenza delle porte basate sui gruppi e DEVONO (MUST) essere inoltrati anche sulle porte dei router.

Questa è la principale funzionalità di snooping IGMP per il percorso dati. Un approccio possibile consiste nel mantenere in software tabelle separate di appartenenza e di router multicast, per poi "fonderle" in una cache di inoltro.

  1. I pacchetti con indirizzo IP di destinazione (DIP) nell'intervallo 224.0.0.X che non sono IGMP DEVONO (MUST) essere inoltrati su tutte le porte.

Questa raccomandazione si basa sul fatto che molti sistemi host non inviano un Join per gli indirizzi multicast di questo intervallo prima di inviare o ascoltare pacchetti multicast IP. Inoltre, poiché l'intervallo 224.0.0.X è definito come locale al collegamento (non instradabile), sembra inutile mantenere lo stato per ogni indirizzo di questo intervallo. Infine, alcuni router operano nell'intervallo 224.0.0.X senza emettere Join IGMP, e queste applicazioni si romperebbero se lo switch le eliminasse per non aver visto un messaggio Join Group proveniente dal router.

  1. Un pacchetto non registrato è definito come un pacchetto multicast IPv4 con indirizzo di destinazione che non corrisponde a nessuno dei gruppi annunciati in precedenti rapporti di appartenenza IGMP.

Se uno switch riceve un pacchetto non registrato, DEVE (MUST) inoltrarlo su tutte le porte a cui è collegato un router IGMP. Uno switch può inoltrare per impostazione predefinita i pacchetti non registrati su tutte le porte. Gli switch che non inoltrano i pacchetti non registrati a tutte le porte DEVONO (MUST) includere un'opzione di configurazione per forzare l'inondazione dei pacchetti non registrati su porte specificate.

In un ambiente in cui host IGMPv3 sono mescolati con switch con snooping che non supportano ancora IGMPv3, la mancata inondazione dei flussi non registrati da parte dello switch potrebbe impedire agli host v3 di ricevere il proprio traffico. Viceversa, in ambienti in cui lo switch supporta tutte le versioni IGMP presenti, l'inondazione dei flussi non registrati può sopraffare gli host IGMP con traffico multicast, al punto da non ricevere più le query e da non emettere nuovi rapporti di appartenenza per i propri gruppi.

Gli switch con snooping sono incoraggiati a riconoscere ed elaborare almeno i rapporti di Join IGMPv3, anche se tale elaborazione è limitata al comportamento previsto per i Join IGMPv2, cioè senza considerare alcun filtro aggiuntivo "include source" o "exclude source". Quando i Join IGMPv3 non vengono riconosciuti, uno switch può erroneamente eliminare i flussi dati non registrati di quei gruppi (come sopra indicato); in alternativa, può non aggiungere l'inoltro verso nuovi host IGMPv3 se il gruppo è già stato unito come IGMPv2 (poiché il flusso dati è considerato già registrato).

  1. Tutti i pacchetti multicast non IPv4 DOVREBBERO (SHOULD) continuare a essere inondati verso tutte le porte rimanenti nello stato di inoltro, secondo le normali operazioni di bridging IEEE.

Questa raccomandazione deriva dal fatto che i gruppi costituiti da host IPv4 e quelli costituiti da host IPv6 sono gruppi completamente separati e distinti. Di conseguenza, le informazioni ricavate dalla topologia tra i membri di un gruppo IPv4 non sarebbero applicabili nel formare la topologia tra i membri di un gruppo IPv6.

  1. Gli switch con snooping IGMP possono mantenere tabelle di inoltro basate su indirizzi MAC o su indirizzi IP. Se uno switch supporta entrambi i tipi di tabella, il comportamento predefinito DOVREBBE (SHOULD) essere quello di usare gli indirizzi IP. L'inoltro basato sugli indirizzi IP è preferibile perché la corrispondenza tra indirizzi multicast IP e indirizzi multicast di livello collegamento è ambigua. Nel caso di Ethernet, un indirizzo Ethernet corrisponde a 32 indirizzi IP [RFC1112].

  2. Gli switch che si basano sulle informazioni dell'intestazione IP DOVREBBERO (SHOULD) verificare che il checksum dell'intestazione IP sia corretto. Se il checksum non è valido, le informazioni del pacchetto NON DEVONO (MUST NOT) essere incorporate nella tabella di inoltro. Inoltre, il pacchetto DOVREBBE (SHOULD) essere scartato.

  3. Quando su segmenti condivisi vengono ricevuti rapporti di appartenenza IGMPv3 di tipo "include source" ed "exclude source", lo switch deve inoltrare il sovrainsieme di tutti i rapporti di appartenenza ricevuti verso il segmento condiviso. L'inoltro del traffico da una particolare sorgente S verso un gruppo G DEVE (MUST) avvenire se almeno un host sul segmento condiviso segnala un'appartenenza IGMPv3 del tipo INCLUDE(G, Slist1) o EXCLUDE(G, Slist2), dove S è un elemento di Slist1 e non è un elemento di Slist2.

L'implementazione pratica delle tabelle di inoltro dei dati basate su (G,S1,S2,...) non rientra nell'ambito di questo documento. Una possibilità è mantenere due elenchi di inoltro (G,S): uno per il filtro INCLUDE, in cui è richiesta la corrispondenza di uno specifico (G,S) perché avvenga l'inoltro, e uno per il filtro EXCLUDE, in cui la corrispondenza di uno specifico (G,S) comporta la mancata inoltro.

Un problema particolare si presenta nelle reti composte da router IGMPv3 e da host IGMPv2 e IGMPv3 interconnessi da uno switch con snooping IGMPv2, come recentemente segnalato [IETF56]. Il router continuerà a mantenere IGMPv3 anche in presenza di host IGMPv2, e quindi la rete non convergerà su IGMPv2. Tuttavia è probabile che lo switch con snooping IGMPv2 non riconosca né elabori i rapporti di appartenenza IGMPv3. I gruppi relativi a questi rapporti non riconosciuti saranno quindi inondati (con tutti i problemi che ciò può creare agli host in una rete con carico multicast elevato) oppure eliminati dallo switch.

Pertanto, in una rete di questo tipo si raccomanda di configurare il router multicast per usare IGMPv2. Se ciò non è possibile, e se lo switch non è in grado di riconoscere ed elaborare i rapporti di appartenenza IGMPv3, si raccomanda invece di disabilitare la funzionalità di snooping IGMP dello switch, poiché non esiste una soluzione chiara a questo problema.