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.Respuestas:
Pude resolver el problema. En Kemp (con par HA) tiene la opción de utilizar una "Dirección MAC virtual". Si esta casilla no está marcada, el MAC de un equilibrador de carga VIP es el de la interfaz física de la unidad Kemp activa. Si esta casilla está marcada, la dirección MAC del VIP es un MAC VRRP. Como mencionó anteriormente, el RFC VRRP establece que el MAC es "00:00" {blah} y el último octeto es la ID del enrutador. La ID de Kemp HA [enrutador] predeterminada es 01. En mis Powerconnects que usan el Firmware 5.1.xx no estoy usando VRRP, pero ejecuté algunos rastros y determiné que Powerconnect soltará una trama VRRP si la ID del enrutador es la misma. Lo hacen INCLUSO si VRRP no está configurado y, en ese modo, el valor predeterminado es 01. Por lo tanto, cambiar la ID del enrutador Kemp HA a algo así como 22 (0x16) hizo que todo funcionara.
fuente
La dirección de multidifusión que está buscando es 224.0.0.18 [mac: 01005e.000012]. Ese es el canal de control para todos los nodos VRRP. [editar] A menos que KEMP haya cambiado el código, CARP (UCARP) origina tráfico usando el MAC de unidifusión VRRP [00005e.0001xx], que es donde un switch lo aprendería naturalmente.
Si no tiene un interlocutor en la red (presumiblemente en cada segmento), sus conmutadores eventualmente olvidarán en qué grupos se encuentran: los anfitriones no envían membresías periódicas a menos que se les solicite. [editar: Dependiendo de la configuración, un conmutador podría soltar multidifusión desconocida frente a inundación.] Eso puede ser un interrogador dedicado (envía el paquete, no le importan las respuestas), o más comúnmente el enrutador multidifusión dentro de su infraestructura . En este caso simple, un interrogador es todo lo que se requiere ya que los mensajes VRRP tienen prohibido cruzar segmentos de todos modos.
No estoy familiarizado con los conmutadores Dell, así que no sé qué comandos cli necesita.
[ACTUALIZAR]
Esa no es la mac multidifusión. Esa es la fuente MAC de unidifusión del tráfico de multidifusión. La Mac de multidifusión no aparecerá en la tabla de direcciones de Mac. Eso está en una tabla de grupo de multidifusión. Cisco IOS tiene un
show mac-address-table multicast(no muestra nada en mi enrutador) yshow ip igmp groups(muestra 3 grupos). Ese enrutador está configurado en modo disperso pim; los conmutadores nortel y cisco lo ven como un querier.Y el método KEMP es profundamente defectuoso al usar la NIC MAC del host para las direcciones virtuales. En su caso, 5004 pertenece a un nic. Cuando 5004 desaparezca, todos seguirán teniendo "IP: 6 == MAC: 5004" en sus tablas; continuarán tratando de hablar con el anfitrión muerto hasta que se reemplace esa entrada. KEMP obviamente está apostando a que el arca gratuita sea honrado por todo en la red. HSRP, VRRP, y el OpenBSD diseñados CARP toda utilización de un MAC virtual por esta misma razón. (Parece que no pudieron hackear UCARP para usar el nic mac en lugar del VRRP virtual mac al transmitir su tráfico multidifusión).
Teniendo en cuenta la piratería de UCARP, ¿estás seguro de que incluso está usando multidifusión?
fuente
show ip igmp snooping querier vlan 367para un cisco)