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?
fonte
What on earth am I going to do with this?<- Tequila. Muitos disso.Respostas:
Consegui resolver o problema. No Kemp (com par HA), você tem a opção de usar um "Endereço MAC virtual". Se essa caixa não estiver marcada, o MAC de um VIP do balanceador de carga é o da interface física da unidade Kemp ativa. Se esta caixa estiver marcada, o endereço MAC do VIP é um VRRP MAC. Como você mencionou acima, o VRRP RFC indica que o MAC é "00:00" {blah} com o último octeto sendo o ID do roteador. O ID do [roteador] Kemp HA padrão é 01. Nos Powerconnects usando o Firmware 5.1.xx, não estou usando VRRP, mas executei alguns rastreios e determinei que o Powerconnect eliminaria um quadro VRRP se o ID do roteador fosse o mesmo. Eles fazem isso MESMO se o VRRP não estiver configurado e, nesse modo, o padrão é 01. Portanto, alterar o ID do roteador Kemp HA para algo como 22 (0x16) resultou em tudo funcionando.
fonte
O endereço multicast que você está procurando é 224.0.0.18 [mac: 01005e.000012]. Esse é o canal de controle para todos os nós VRRP. [edit] A menos que o KEMP altere o código, o CARP (UCARP) origina o tráfego usando o MAC de VRRP unicast [00005e.0001xx] - é aí que um switch naturalmente o aprende.
Se você não tiver um consultor na rede (presumivelmente em todos os segmentos), seus comutadores eventualmente esquecerão quais grupos estão - os hosts não enviam associações periódicas a menos que solicitado. [editar: Dependendo da configuração, um switch pode eliminar multicast desconhecido versus inundação.] Esse pode ser um consultor dedicado (ele envia o pacote, não se preocupa com nenhuma resposta) ou, mais comumente, o roteador multicast em sua infraestrutura . Nesse caso simples, um consultor é tudo o que é necessário, pois as mensagens VRRP são proibidas de cruzar segmentos de qualquer maneira.
Eu não estou familiarizado com os switches Dell, então não sei quais comandos cli você precisa.
[ATUALIZAR]
Esse não é o mac multicast. Essa é a fonte MAC unicast do tráfego multicast. O mac multicast não será exibido na tabela de endereços do mac. Isso está em uma tabela de grupo multicast. O Cisco IOS possui um
show mac-address-table multicast(não mostra nada no meu roteador) eshow ip igmp groups(mostra três grupos). Esse roteador está definido como pim sparse-mode; os switches nortel e cisco o veem como um consultador.E o método KEMP é profundamente falho ao usar o host NIC MAC para endereços virtuais. No seu caso, 5004 pertence a um nic. Quando o 5004 desaparecer, todo mundo ainda terá "IP: 6 == MAC: 5004" em suas tabelas; eles continuarão tentando conversar com o host morto até que essa entrada seja substituída. O KEMP está obviamente apostando no arp gratuito sendo honrado por tudo na rede. HSRP, VRRP, e do OpenBSD projetado CARP todos uso um MAC virtual por esta mesma razão. (eles parecem ter falhado em invadir o UCARP para usar o nic mac em vez do virtual VRRP ao transmitir seu tráfego de transmissão múltipla.)
Dado o hackery do UCARP, você tem certeza de que está usando multicast?
fonte
show ip igmp snooping querier vlan 367Para um cisco)