Équilibreurs de charge KEMP utilisant UCARP (VRRP) - L'adresse MAC de multidiffusion n'est pas récupérée

10

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?

pauska
la source
What on earth am I going to do with this?<- Tequila. Beaucoup.
voretaq7
Vous confondez l'adresse de multidiffusion utilisée entre les «routeurs virtuels» (pour dire qui est là et qui est le maître) et l'adresse de monodiffusion utilisée pour le routeur virtuel lui-même (c'est-à-dire le MAC pour l'IP virtuelle).
Ricky Beam
@RickyBeam Pourriez-vous être un peu plus précis? La raison pour laquelle il y avait (il y avait) deux adresses mac dans la liste ci-dessus est parce que nous avons deux paires d'équilibreurs de charge, chacune avec leur propre ID (01 et 02 à la fin) - si c'est ce que vous pensez?
pauska
1
Non, vous êtes toujours confus au sujet du MAC unicast associé à l'IP du routeur virtuel - c'est les hôtes MAC utilisent pour parler à leur service à charge équilibrée. Une adresse de multidiffusion est ce que les équilibreurs de charge utilisaient pour savoir qui est en charge. (lire la section 5.1.1)
Ricky Beam
@RickyBeam Désolé, cela n'a aucun sens pour moi. L'adresse MAC unicast pour chaque équilibreur de charge (00:56, vmware) est totalement différente de la 0000.5e00.0101 que je vois lorsque je désactive l'espionnage IGMP.
pauska

Réponses:

5

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.

Ed Smith
la source
Tu es mon héros. Merci d'avoir enfin compris cela! Formulation extrêmement médiocre de la part de KEMP - ils devraient vous donner une description qui vous indique réellement que cela se traduit par l'ID du routeur VRRP.
pauska du
2

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]

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

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

Ricky Beam
la source
J'ai déjà configuré un routeur PIM dans notre cœur sur le même VLAN - cela ne devrait-il pas éliminer le besoin d'un demandeur?
pauska
1
En théorie, oui. Confirmez que le ou les commutateurs voient un demandeur. ( show ip igmp snooping querier vlan 367pour un cisco)
Ricky Beam
Ils ne voient aucun demandeur, mais ils voient le mrouter (sh ip igmp snooping mrouter). Suis-je censé avoir un demandeur ET un routeur? Je pensais que ce dernier remplace le premier ..
pauska
1
Je ne sais pas si Dell le traite. Mes commutateurs cisco, hp et adtran affichent le routeur PIM comme demandeur, mais ils manquent (ou ne sont pas configurés pour) le support PIM eux-mêmes.
Ricky Beam