D'accord - je me bats depuis au moins 20 heures consécutives .. Désolé si cela ressemble à une longue diatribe ou à un article de blog, mais j'arrive au point d'épuisement.
Alors, voici l'affaire. Nous utilisons des équilibreurs de charge KEMP, qui utilisent UCARP (un clone Linux de CARP, qui est un clone VRRP) pour les pulsations HA et les états persistants. Nous voulons utiliser IGMP dans notre environnement pour éviter les inondations dans le centre de données.
Nous avons deux commutateurs Dell PowerConnect 8124F exécutant SW 5.1.1.7 agissant comme haut de rack. Ces deux sont connectés à une paire empilée de Cisco 3750-X, qui est notre cœur.
Les problèmes ont commencé lorsque nous avons effectué une mise à niveau vers PowerConnect 5.1.x, où ils ont apparemment omis de laisser IGMP espionner, sauf indication contraire. Et voici - nos équilibreurs de charge sont entrés dans le cerveau divisé, provoquant toutes sortes d'amusements chauds et flous.
- Si je désactive l'espionnage IGMP sur le VLAN où les équilibreurs de charge font leur multidiffusion, rien ne se passe, la multidiffusion est toujours morte
- Si je configure IP PIM sur notre cœur, les commutateurs PowerConnect le voient sur le même VLAN, mais toujours pas de trafic de multidiffusion
- Si j'active l'inondation de tout le trafic de multidiffusion non enregistré, cela ne fait rien du tout.
- Si je désactive l'espionnage IGMP globalement sur les commutateurs PowerConnect, tout le trafic de multidiffusion fonctionne. Cela fonctionne si bien, que nous obtenons un trafic de multidiffusion inondé vers chaque port unique qui a le même tag VLAN. Magnifique.
J'ai remarqué d'étranges entrées d'adresse MAC sur le VLAN en notre cœur:
coresw#sh mac address-table vlan 367 | include 5e00
367 0000.5e00.0101 DYNAMIC Po13 seq_no:0
Et je pense .. N'est-ce pas l'adresse de multidiffusion? Pourquoi n'est-ce pas dans la "multidiffusion de la table d'adresses sh mac"?
coresw#sh mac address-table multicast vlan 367
Vlan Mac Address Type Ports
---- ----------- ---- -----
coresw#
Et puis j'ai lu ceci dans le guide CLI PowerConnect:
Le trafic de multidiffusion est le trafic destiné à un groupe d'hôtes. Les groupes d'hôtes sont identifiés par l'adresse MAC de destination, c'est-à-dire la plage 01: 00: 5e: 00: 00: 00-01: 00: 5e: 7f: ff: ff: ff pour le trafic multidiffusion IPv4 ou 33: 33: xx: xx : xx: xx pour le trafic multicast IPv6.
On dirait qu'il nous manque un "01" au début de l'adresse MAC, non? L'entrée MAC dynamique ci-dessus commence par "00". À ce stade, je pense à appeler KEMP et à leur faire savoir que leur produit est horriblement mal configuré. Mais ensuite je vais lire le RFC pour VRRP - et voici:
L'adresse MAC du routeur virtuel associée à un routeur virtuel est une adresse MAC IEEE 802 au format suivant:
Cas IPv4: 00-00-5E-00-01- {VRID} (en hexadécimal, dans l'ordre des bits standard Internet)
Très bien - les commutateurs ne récupèrent donc normalement pas la plage d'adresses MAC de multidiffusion pour VRRP. Très bien, configurons un groupe d'hôtes statique sur les commutateurs Dell. Nan.
Entrée non valide: l'adresse MAC de multidiffusion doit être au format 01XX: XXXX: XXXX
OK alors .. Étape suivante, essayez d'ajouter une entrée mac statique:
osl-sys-swrack03(config)#mac address-table multicast ?
forbidden forbid adding specific multicast addresses to
specific ports.
osl-sys-swrack03(config)#
Donc - aucun moyen de configurer une entrée MAC multicast statique. Si j'essaie de faire la même chose avec une entrée MAC statique régulière, je ne peux la lier qu'à un seul port - ce cluster d'équilibrage de charge s'exécute sur 4 ports 10gig différents.
Mise à jour : Il semble y avoir une certaine confusion concernant les adresses MAC. 172.30.1.0/24 est le réseau d'équilibrage de charge orienté vers l'avant. 172.30.1.6 est le VIP partagé par défaut pour le cluster, .7 est l'IP de gestion pour le premier équilibreur de charge et .8 est pour le deuxième équilibreur de charge. Toutes les autres adresses (30, 40, 70, 80, etc.) sont toutes VIP avec différents services. Lorsqu'un basculement se produit, tous les VIP changent leur adresse MAC en adresse MAC physique du deuxième LB. L'adresse de multidiffusion dans le tableau du bas ne change pas .
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
Et c'est l'histoire. Qu'est-ce que je vais faire avec ça?
What on earth am I going to do with this?<- Tequila. Beaucoup.