Muy bien, he estado luchando contra esto durante al menos 20 horas consecutivas. Perdón si esto parece una queja larga, o una publicación de blog, pero estoy llegando al punto de agotamiento.
Entonces, aquí está el trato. Estamos utilizando equilibradores de carga KEMP, que utiliza UCARP (un clon de CARP en Linux, que es un clon de VRRP) para latidos cardíacos HA y estados persistentes. Queremos utilizar IGMP en nuestro entorno para evitar inundaciones en el centro de datos.
Tenemos dos conmutadores Dell PowerConnect 8124F con SW 5.1.1.7 que actúan como parte superior del bastidor. Estos dos están conectados a un par apilado de Cisco 3750-X, que es nuestro núcleo.
Los problemas comenzaron cuando actualizamos a PowerConnect 5.1.x, donde aparentemente no pudieron dejar IGMP husmeando a menos que usted indique lo contrario. Y he aquí, nuestros equilibradores de carga entraron en un cerebro dividido, causando todo tipo de diversión cálida y difusa.
- Si deshabilito la inspección IGMP en la VLAN donde los equilibradores de carga realizan su multidifusión, no sucede nada, la multidifusión sigue muerta
- Si configuro IP PIM en nuestro núcleo, los conmutadores PowerConnect lo ven en la misma VLAN, pero aún no hay tráfico de multidifusión
- Si habilito la inundación de todo el tráfico de multidifusión no registrado, todavía no hace nada.
- Si deshabilito la inspección IGMP globalmente en los conmutadores PowerConnect, todo el tráfico de multidifusión funciona. Funciona tan bien que obtenemos tráfico de multidifusión en cada puerto que tiene la misma VLAN etiquetada. Maravilloso.
Noté algunas entradas de direcciones MAC extrañas en la VLAN en nuestro núcleo:
coresw#sh mac address-table vlan 367 | include 5e00
367 0000.5e00.0101 DYNAMIC Po13 seq_no:0
Y creo ... ¿No es esa la dirección de multidifusión? ¿Por qué no está esto en la "multidifusión de tabla de direcciones sh mac"?
coresw#sh mac address-table multicast vlan 367
Vlan Mac Address Type Ports
---- ----------- ---- -----
coresw#
Y luego leí esto en la guía de la CLI de PowerConnect:
El tráfico de multidifusión es el tráfico que está destinado a un grupo host. Los grupos de hosts se identifican por la dirección MAC de destino, es decir, el rango 01: 00: 5e: 00: 00: 00-01: 00: 5e: 7f: ff: ff: ff para el tráfico de multidifusión IPv4 o 33: 33: xx: xx : xx: xx para tráfico de multidifusión IPv6.
Parece que nos falta un "01" al comienzo de la dirección MAC, ¿no? La entrada MAC dinámica anterior comienza con "00". En este punto, estoy pensando en llamar a KEMP y hacerles saber que su producto está terriblemente mal configurado. Pero luego voy a leer el RFC para VRRP , y he aquí:
La dirección MAC del enrutador virtual asociada con un enrutador virtual es una dirección MAC IEEE 802 en el siguiente formato:
Caso de IPv4: 00-00-5E-00-01- {VRID} (en hexadecimal, en orden de bits estándar de Internet)
Muy bien, por lo que los conmutadores normalmente no recogen el rango de direcciones mac de multidifusión para VRRP. Bien, configuremos un grupo host estático en los conmutadores Dell. No
Entrada no válida: la dirección MAC de multidifusión debe tener el formato 01XX: XXXX: XXXX
OK, entonces ... Siguiente paso, intente agregar una entrada de Mac estática:
osl-sys-swrack03(config)#mac address-table multicast ?
forbidden forbid adding specific multicast addresses to
specific ports.
osl-sys-swrack03(config)#
Entonces, no hay forma de configurar una entrada MAC de multidifusión estática. Si trato de hacer lo mismo con una entrada MAC estática normal, solo puedo vincularlo a un puerto: este clúster de equilibrio de carga se ejecuta en 4 puertos de 10 gig diferentes.
Actualización : Parece haber cierta confusión con respecto a las direcciones MAC. 172.30.1.0/24 es la red de balanceo de carga frontal. 172.30.1.6 es el VIP compartido predeterminado para el clúster, .7 es la IP de administración para el primer equilibrador de carga y .8 es para el segundo equilibrador de carga. Todas las demás direcciones (30, 40, 70, 80, etc.) son todas VIP con diferentes servicios. Cuando ocurre una conmutación por error, todos los VIP cambian su dirección MAC a la dirección MAC física del segundo LB. La dirección de multidifusión en la tabla inferior no cambia.
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
Y esa es la historia. ¿Qué demonios voy a hacer con esto?
What on earth am I going to do with this?<- Tequila. Montones.