Snooping IGMP e indirizzi multicast link-local

Ho una rete che ha molti dispositivi che inviano dati a 224.0.0.225 su una VLAN che si estende su più switch. Ogni dispositivo (circa 12 di questi) invia dati di reportistica a circa 500-600 kbps. Ogni porta sulla VLAN, indipendentemente dal fatto che il ricevitore invii o meno un join, viene invasa da traffico multicast di circa 6 Mbps.

Lo snooping IGMP è abilitato su tutti gli switch e sulla VLAN locale.
pim sparse-mode è configurato sul mrouter / gateway predefinito.

Se faccio un show ip igmp snooping groupsinterruttore, non c'è alcuna voce nella tabella snooping.

So che 224.0.0.1 - 224.0.0.255 rientrano nell'intervallo IP multicast riservato al collegamento locale, il che significa che un router non inoltrerà i pacchetti all'interno di questo intervallo. Questi intervalli vengono utilizzati anche per le chatter di protocollo di routing. es.) EIGRP, OSPF, HSRP ... ecc

Ho due domande:
1) Penso che la risposta sia SÌ - per 224.0.0.1 224.0.0.255 ... IGMPv2 ignora questo intervallo per lo snooping e lo switch lo inoltra a tutte le porte?
2) Esiste un modo per forzare IGMP a ficcare il traffico multicast e inviarlo solo alle porte che lo richiedono con un join IGMP?

Ho la sensazione che questo sia uno di quei casi in cui l'applicazione / i programmatori devono progettare i propri dispositivi e applicazioni per rispettare reti non consumer scalabili. Pertanto, dovrebbero utilizzare un indirizzo multicast nell'intervallo 239.0.0.0/8.

Ho continuato a scavare in Internet .... e penso di aver risposto alla mia domanda.
Ora devo tornare all'applicazione / ai proprietari dei dispositivi / agli sviluppatori e vedere cosa possiamo fare o bloccare ulteriormente questi dispositivi nella loro VLAN.

Si prega di lasciare commenti o risposte con ulteriori consigli.

RFC 4541 2.1.2 :

1) I pacchetti con un indirizzo IP di destinazione esterno a 224.0.0.X che non sono IGMP devono essere inoltrati secondo le tabelle di appartenenza delle porte basate su gruppi e devono anche essere inoltrati sulle porte del router.

  This is the main IGMP snooping functionality for the data path.
  One approach that an implementation could take would be to
  maintain separate membership and multicast router tables in
  software and then "merge" these tables into a forwarding cache.

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

  This recommendation is based on the fact that many host systems do
  not send Join IP multicast addresses in this range before sending
  or listening to IP multicast packets.  Furthermore, since the
  224.0.0.X address range is defined as link-local (not to be
  routed), it seems unnecessary to keep the state for each address
  in this range.  Additionally, some routers operate in the
  224.0.0.X address range without issuing IGMP Joins, and these
  applications would break if the switch were to prune them due to
  not having seen a Join Group message from the router.

C'è un altro avvertimento: a seconda della piattaforma, lo switch punterà tutti i multicast link-local alla CPU. Ciò include ad esempio il traffico OSPF.

Ho notato questo su Ciscos Catalyst 4500 che invierà tutto il traffico 224.0.0.x alla CPU. Quando la CPU è occupata, i pacchetti verranno eliminati, inclusi i pacchetti OSPF. Divertiti a eseguire il debug del motivo per cui cadono le sessioni OSPF.

Anche disattivare lo snooping igmp sulla piattaforma non aiuta. A un certo punto Cisco ha notato che questa probabilmente non è la migliore idea e ha introdotto il comando:

access-list hardware capture mode vlan

Ciò collegherà i pacchetti multicast nell'hardware.

Vedere http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/configuration/guide/secure.html#wp1128851 per i dettagli