Snooping IGMP e endereços de multicast local de link


8

Eu tenho uma rede que possui muitos dispositivos enviando dados para 224.0.0.225 em uma VLAN que abrange vários comutadores. Cada dispositivo (aproximadamente 12 deles) está enviando dados de relatórios a aproximadamente 500-600 kbps. Cada porta na VLAN, independentemente de o receptor enviar ou não uma junção, está sendo inundada com aproximadamente 6 Mbps de tráfego multicast.

A espionagem IGMP é ativada em todos os comutadores e na VLAN local.
O modo esparso pim é configurado no gateway do mrouter / padrão.

Se eu fizer um show ip igmp snooping groupsno switch, não há entrada na tabela de espionagem.

Eu sei que 224.0.0.1 - 224.0.0.255 se enquadram no intervalo de multicast IP reservado local do link, o que significa que um roteador não encaminhará pacotes dentro desse intervalo. Esses intervalos também são usados ​​para o roteamento do protocolo. por exemplo) EIGRP, OSPF, HSRP ... etc

Tenho duas perguntas:
1) Acho que a resposta é SIM - para 224.0.0.1 224.0.0.255 ... o IGMPv2 ignora esse intervalo para bisbilhotar e o switch apenas encaminha isso para todas as portas?
2) Existe uma maneira de forçar o IGMP a bisbilhotar esse tráfego de difusão seletiva e enviá-lo apenas para as portas que o solicitam com uma junção IGMP?

Sinto que esse é um daqueles casos em que os aplicativos / programadores precisam projetar seus dispositivos e aplicativos para respeitar redes não consumidoras escaláveis. Portanto, eles devem usar um endereço multicast no intervalo 239.0.0.0/8.


Acho que a resposta correta aqui é encontrar quem escolheu abusar dos endereços "não atribuídos" e educá-los no erro de suas maneiras com um 2x4. Você está certo; o "aplicativo" deve estar usando 239/8. Até que seja, há muito pouco que você pode fazer sobre isso.
Ricky feixe

11
para adicionar a isso - a Cisco também declara que esta é a abordagem pretendida para vincular o multicast local. cisco.com/en/US/tech/tk828/...
knotseh

Respostas:


7

Continuei pesquisando na internet ... e acho que respondi minha própria pergunta.
Agora preciso voltar aos desenvolvedores do aplicativo / dispositivo e ver o que podemos fazer ou bloquear ainda mais esses dispositivos na sua própria VLAN.

Deixe comentários ou respostas com mais conselhos.

RFC 4541 2.1.2 :

1) Pacotes com um endereço IP de destino fora de 224.0.0.X que não sejam IGMP devem ser encaminhados de acordo com as tabelas de associação de portas baseadas em grupo e também devem ser encaminhados nas portas do roteador.

  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) Pacotes com um endereço IP de destino (DIP) no intervalo 224.0.0.X que não sejam IGMP devem ser encaminhados em todas as portas.

  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.

Olá, considere aceitar esta resposta. Acabei de descobrir isso enquanto pesquisava sobre uma pergunta semelhante.
Mike Pennington

6

Há outra ressalva: dependendo da plataforma, o switch direcionará todo o multicast local de link para a CPU. Isso inclui, por exemplo, tráfego OSPF.

Notei isso no Ciscos Catalyst 4500, que enviará todo o tráfego 224.0.0.x para a CPU. Quando a CPU está ocupada, ela descarta os pacotes, incluindo os pacotes OSPF. Divirta-se depurando por que suas sessões OSPF são interrompidas.

Também desativar o rastreamento de igmp na plataforma não ajuda. Em algum momento, a Cisco notou que essa provavelmente não é a melhor ideia e apresentou o comando:

access-list hardware capture mode vlan

Isso fará a ponte dos pacotes multicast no hardware.

Consulte http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/configuration/guide/secure.html#wp1128851 para obter detalhes


você conhece uma maneira de bloquear o mcast 224.0.0.x no nível da porta?
knotseh

Mmmh, isso depende. Você pode aplicar o policiamento do plano de controle: cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/… Mas você está limitado aos mapas de classe predefinidos. Se o seu tráfego for correspondido por um dos mapas de classe, você terá sorte. Edit : Ok, lendo isso de novo. Não tenho certeza se você tem seus próprios mapas de classe, além dos mapas predefinidos. Você precisaria testá-lo.
Sebastian Wiesinger

Portanto, meus comutadores de acesso são, na verdade, comutadores da série 3560x. Depois de obter minha janela de manutenção, tentarei o multicast sw block conforme recomendado em uma pergunta de falha do servidor. Talvez eu repense isso como uma pergunta mais tarde
knotseh

Então, da minha leitura inicial no meu telefone ... parece que ele classificará tudo ou nada em termos de tráfego local do link. É claro que se eu puder bloquear esse mapa de classe predefinido, ele também eliminará o hsrp, que é a única outra coisa que preciso trabalhar.
Knotseh
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.