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.Réponses:
J'ai pu résoudre le problème. Sur le Kemp (avec paire HA), vous avez la possibilité d'utiliser une "adresse MAC virtuelle". Si cette case n'est pas cochée, le MAC d'un équilibreur de charge VIP est celui de l'interface physique de l'unité Kemp active. Si cette case est cochée, l'adresse MAC du VIP est un MAC VRRP. Comme vous l'avez mentionné ci-dessus, le RFC VRRP indique que le MAC est "00:00" {blah}, le dernier octet étant l'ID du routeur. L'ID Kemp HA [routeur] par défaut est 01. Sur mes Powerconnects utilisant le firmware 5.1.xx, je n'utilise pas VRRP mais j'ai exécuté quelques traces et déterminé que le Powerconnect supprimera une trame VRRP si l'ID du routeur est le même que lui-même. Ils le font MÊME si VRRP n'est pas configuré et dans ce mode, ils sont définis par défaut sur 01. Ainsi, la modification de l'ID du routeur Kemp HA en quelque chose comme 22 (0x16) a fait que tout fonctionnait.
la source
L'adresse de multidiffusion que vous recherchez est 224.0.0.18 [mac: 01005e.000012]. Il s'agit du canal de contrôle pour tous les nœuds VRRP. [modifier] Sauf si KEMP a changé le code, CARP (UCARP) génère du trafic en utilisant le MAC VRRP unicast [00005e.0001xx] - c'est là qu'un commutateur l'apprendrait naturellement.
Si vous n'avez pas de demandeur sur le réseau (vraisemblablement dans chaque segment), vos commutateurs oublieront finalement quels sont les groupes - les hôtes n'envoient pas d'appartenance périodique à moins que cela ne soit demandé. [modifier: Selon la configuration, un commutateur peut abandonner la multidiffusion inconnue, par rapport à l'inondation.] Cela peut être un demandeur dédié (il envoie le paquet, il ne se soucie pas des réponses), ou plus généralement le routeur de multidiffusion au sein de votre infrastructure . Dans ce cas simple, un demandeur est tout ce qui est nécessaire car les messages VRRP sont interdits de traverser les segments de toute façon.
Je ne connais pas les commutateurs Dell, donc je ne sais pas de quelles commandes cli vous avez besoin.
[METTRE À JOUR]
Ce n'est pas le mac multicast. C'est la source MAC unicast du trafic multicast. Le mac multicast n'apparaîtra pas dans la table d'adresses mac. C'est dans une table de groupe de multidiffusion. Cisco IOS a un
show mac-address-table multicast(ne montre rien sur mon routeur) etshow ip igmp groups(montre 3 groupes). Ce routeur est réglé en mode clairsemé pim; les commutateurs nortel et cisco le voient comme un demandeur.Et la méthode KEMP est profondément défectueuse en utilisant l'hôte NIC MAC pour les adresses virtuelles. Dans votre cas, 5004 appartient à un nic. Lorsque 5004 disparaît, tout le monde aura toujours "IP: 6 == MAC: 5004" dans ses tables; ils continueront d'essayer de parler à l'hôte mort jusqu'à ce que cette entrée soit remplacée. KEMP mise évidemment sur le fait que l'arp gratuit soit honoré par tout le réseau. HSRP, VRRP et le CARP conçu par OpenBSD utilisent tous un MAC virtuel pour cette raison. (Ils semblent avoir échoué à pirater UCARP pour utiliser le mac nic au lieu du mac virtuel VRRP lors de la transmission de son trafic multidiffusion.)
Étant donné qu'ils ont piraté UCARP, êtes-vous sûr qu'il utilise même la multidiffusion?
la source
show ip igmp snooping querier vlan 367pour un cisco)