Tudo bem - estou lutando contra isso por pelo menos 20 horas consecutivas. Desculpe se isso parece um longo discurso, ou um post de blog, mas estou chegando ao ponto de exaustão.
Então, aqui está o acordo. Estamos usando os balanceadores de carga KEMP, que utilizam o UCARP (um clone do Linux do CARP, que é um clone do VRRP) para pulsação de HA e estados persistentes. Queremos utilizar o IGMP em nosso ambiente para evitar inundações no datacenter.
Temos dois comutadores Dell PowerConnect 8124F executando o SW 5.1.1.7, atuando como parte superior do rack. Esses dois estão conectados a um par empilhado do Cisco 3750-X, que é o nosso núcleo.
Os problemas começaram quando atualizamos para o PowerConnect 5.1.x, onde aparentemente eles deixaram o IGMP bisbilhotado, a menos que você diga o contrário. E eis que nossos balanceadores de carga entraram no cérebro dividido, causando todo tipo de diversão quente e confusa.
- Se eu desabilitar a espionagem IGMP na VLAN onde os balanceadores de carga fazem o multicast, nada acontece, o multicast ainda está morto
- Se eu configurar o IP PIM em nosso núcleo, os comutadores PowerConnect o verão na mesma VLAN, mas ainda não haverá tráfego multicast
- Se eu ativar a inundação de todo o tráfego multicast não registrado, ele ainda não fará nada.
- Se eu desabilitar a espionagem IGMP globalmente nos comutadores PowerConnect, todo o tráfego multicast funcionará. Ele funciona tão bem que temos o tráfego multicast inundado em todas as portas que possuem a mesma marca de VLAN. Maravilhoso.
Notei algumas entradas estranhas de endereço MAC na VLAN em nosso núcleo:
coresw#sh mac address-table vlan 367 | include 5e00
367 0000.5e00.0101 DYNAMIC Po13 seq_no:0
E eu acho ... Esse não é o endereço multicast? Por que isso não está no "multicast da tabela de endereços sh mac"?
coresw#sh mac address-table multicast vlan 367
Vlan Mac Address Type Ports
---- ----------- ---- -----
coresw#
E então eu li isso no guia da CLI do PowerConnect:
Tráfego multicast é o tráfego destinado a um grupo de hosts. Os grupos de hosts são identificados pelo endereço MAC de destino, ou seja, o intervalo 01: 00: 5e: 00: 00: 00-01: 00: 5e: 7f: ff: ff: ff para tráfego multicast IPv4 ou 33: 33: xx: xx : xx: xx para tráfego multicast IPv6.
Parece que falta um "01" no início do endereço MAC, não? A entrada dinâmica do MAC acima começa com "00". Neste momento, estou pensando em ligar para o KEMP e avisá-los de que seu produto está terrivelmente mal configurado. Mas então eu vou ler o RFC para VRRP - e eis:
O endereço MAC do roteador virtual associado a um roteador virtual é um endereço MAC IEEE 802 no seguinte formato:
Caso IPv4: 00-00-5E-00-01- {VRID} (em hexadecimal, em ordem de bits padrão da Internet)
Tudo bem - então os switches normalmente não atendem ao intervalo de endereços mac multicast para VRRP. Tudo bem, vamos configurar um grupo de hosts estáticos nos comutadores Dell. Não.
Entrada inválida: o endereço MAC de difusão seletiva deve estar no formato 01XX: XXXX: XXXX
OK then .. Próximo passo, tente adicionar uma entrada estática do mac:
osl-sys-swrack03(config)#mac address-table multicast ?
forbidden forbid adding specific multicast addresses to
specific ports.
osl-sys-swrack03(config)#
Portanto - não há como configurar uma entrada MAC multicast estática. Se eu tentar fazer o mesmo com uma entrada MAC estática regular, só posso vinculá-la a uma porta - esse cluster de balanceamento de carga funciona em 4 portas 10gig diferentes.
Atualização : Parece haver alguma confusão em relação aos endereços MAC. 172.30.1.0/24 é a rede do loadbalancer voltada para a frente. 172.30.1.6 é o VIP compartilhado padrão para o cluster, .7 é o IP de gerenciamento para o primeiro balanceador de carga e .8 é para o segundo balanceador de carga. Todos os outros endereços (30, 40, 70, 80, etc.) são todos VIP com serviços diferentes. Quando ocorre um failover, todos os VIPs alteram seu endereço MAC para o endereço MAC físico do segundo LB. O endereço multicast na tabela inferior não muda.
coresw#sh ip arp vlan 367
Protocol Address Age (min) Hardware Addr Type Interface
Internet 172.30.1.6 78 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.40 204 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.80 167 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.70 38 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.66 12 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.35 185 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.60 97 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.30 80 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.61 33 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.7 27 0050.56b4.5004 ARPA Vlan367 <- Management - Loadbalancer1 physical MAC
Internet 172.30.1.8 21 0050.56b4.08c2 ARPA Vlan367 <- Management - Loadbalancer2 physical MAC
osl-sys-coresw#sh mac address-table dynamic vlan 367
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
367 0000.5e00.0101 DYNAMIC Po13 seq_no:0 <- multicast HA mac (UCARP)
367 0050.56b4.08c2 DYNAMIC Po13 seq_no:0 <- Loadbalancer1 physical MAC
367 0050.56b4.5004 DYNAMIC Po13 seq_no:0 <- Loadbalancer2 physical MAC
E essa é a história. O que diabos eu vou fazer com isso?
What on earth am I going to do with this?<- Tequila. Muitos disso.