Balanceadores de carga KEMP usando UCARP (VRRP) - o endereço MAC multicast não está sendo captado


10

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.
voretaq7

Você está confundindo o endereço multicast usado entre os "roteadores virtuais" (para saber quem está lá e quem é o mestre) e o endereço unicast usado para o próprio roteador virtual (ou seja, o MAC para o IP virtual).
Ricky Beam

@RickyBeam Você poderia ser um pouco mais específico? A razão pela qual (havia) dois endereços MAC na lista acima é porque temos dois pares de balanceadores de carga, cada um com seu próprio ID (os 01 e 02 no final) - se é isso que você está pensando?
pauska

11
Não, você ainda está confuso sobre o MAC unicast associado ao IP do roteador virtual - que os hosts MAC usam para conversar com o serviço de balanceamento de carga. Um endereço multicast é o que os balanceadores de carga costumavam saber quem está no comando. (leia a seção 5.1.1)
Ricky Beam

@ RickyBeam Desculpe, não faz nenhum sentido para mim. O endereço MAC unicast para cada balanceador de carga (00:56, vmware) é totalmente diferente do 0000.5e00.0101 que estou vendo quando desabilito a espionagem IGMP.
pauska

Respostas:


5

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.


Você é meu herói. Obrigado por finalmente descobrir isso! Redação extremamente ruim da parte do KEMP - eles devem fornecer uma descrição que realmente informa que isso se traduz no ID do roteador VRRP.
pauska

2

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]

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
367    0000.5e00.0101    DYNAMIC     Po13   seq_no:0   <- multicast HA mac (UCARP)

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) e show 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?


Já configurei um roteador PIM em nosso núcleo na mesma VLAN - isso não deveria eliminar a necessidade de um consultor?
pauska

11
Em teoria, sim. Confirme se os comutadores estão vendo um consultor. ( show ip igmp snooping querier vlan 367Para um cisco)
Ricky feixe

Eles não veem nenhum consultante, mas vêem o mrouter (sh ip igmp snooping mrouter). Devo ter um consultor e um mrouter? Eu pensei que este último substitui o primeiro ..
pauska

11
Não sei se a Dell trata isso. Meus switches cisco, hp e adtran mostram o mrouter do PIM como o consultor, mas eles não têm (ou não estão configurados para) o suporte ao PIM.
Ricky feixe
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.