Okay - ich habe mindestens 20 Stunden hintereinander dagegen gekämpft. Tut mir leid, wenn dies wie ein langer Scherz oder ein Blog-Beitrag erscheint, aber ich bin an einem Punkt der Erschöpfung angelangt.
Also, hier ist der Deal. Wir verwenden KEMP-Load-Balancer, die UCARP (einen Linux-Klon von CARP, einem VRRP-Klon) für HA-Heartbeat und persistente Zustände verwenden. Wir möchten IGMP in unserer Umgebung verwenden, um Überschwemmungen im gesamten Rechenzentrum zu verhindern.
Wir haben zwei Dell PowerConnect 8124F-Switches mit SW 5.1.1.7, die als Top-of-Rack fungieren. Diese beiden sind mit einem gestapelten Cisco 3750-X-Paar verbunden, das unser Kern ist.
Die Probleme begannen mit dem Upgrade auf PowerConnect 5.1.x, bei dem offenbar standardmäßig IGMP-Snooping aktiviert blieb, sofern Sie nichts anderes angeben. Und siehe da - unsere Load Balancer sind in Split-Brain geraten und haben allerlei warmen Fuzzy-Spaß verursacht.
- Wenn ich das IGMP-Snooping in dem VLAN deaktiviere, in dem die Load Balancer ihren Multicast ausführen, geschieht nichts. Multicast ist immer noch tot
- Wenn ich IP PIM auf unserem Core einrichte, sehen die PowerConnect-Switches es im selben VLAN, aber immer noch keinen Multicast-Verkehr
- Wenn ich das Überfluten des gesamten nicht registrierten Multicast-Verkehrs aktiviere, wird immer noch nichts unternommen.
- Wenn ich das IGMP-Snooping auf den PowerConnect-Switches global deaktiviere , funktioniert der gesamte Multicast-Verkehr. Es funktioniert so gut, dass Multicast-Verkehr auf jeden einzelnen Port mit demselben VLAN-Tag übertragen wird. Wunderbar.
Ich habe einige seltsame MAC-Adresseinträge im VLAN in unserem Kern bemerkt:
coresw#sh mac address-table vlan 367 | include 5e00
367 0000.5e00.0101 DYNAMIC Po13 seq_no:0
Und ich denke ... Ist das nicht die Multicast-Adresse? Warum ist das nicht im "sh mac address-table multicast"?
coresw#sh mac address-table multicast vlan 367
Vlan Mac Address Type Ports
---- ----------- ---- -----
coresw#
Und dann habe ich dies im PowerConnect CLI-Handbuch gelesen:
Multicast-Verkehr ist Verkehr, der an eine Hostgruppe gerichtet ist. Hostgruppen werden durch die Ziel-MAC-Adresse identifiziert, dh den Bereich 01: 00: 5e: 00: 00: 00-01: 00: 5e: 7f: ff: ff: ff für IPv4-Multicast-Verkehr oder 33: 33: xx: xx : xx: xx für IPv6-Multicast-Verkehr.
Scheint, als ob uns am Anfang der MAC-Adresse eine "01" fehlt, oder? Der obige dynamische MAC-Eintrag beginnt mit "00". An diesem Punkt denke ich darüber nach, KEMP anzurufen und sie wissen zu lassen, dass ihr Produkt schrecklich falsch konfiguriert ist. Aber dann lese ich den RFC für VRRP - und siehe da:
Die einem virtuellen Router zugeordnete MAC-Adresse des virtuellen Routers ist eine IEEE 802-MAC-Adresse im folgenden Format:
IPv4-Fall: 00-00-5E-00-01- {VRID} (in hexadezimaler Reihenfolge, in Internet-Standard-Bitreihenfolge)
In Ordnung - Switches erfassen normalerweise nicht den Multicast-Mac-Adressbereich für VRRP. Lassen Sie uns eine statische Hostgruppe auf den Dell-Switches konfigurieren. Nee.
Ungültige Eingabe: Die Multicast-MAC-Adresse muss das Format 01XX: XXXX: XXXX haben
OK dann .. Versuchen Sie im nächsten Schritt, einen statischen Mac-Eintrag hinzuzufügen:
osl-sys-swrack03(config)#mac address-table multicast ?
forbidden forbid adding specific multicast addresses to
specific ports.
osl-sys-swrack03(config)#
Also - keine Möglichkeit, einen statischen Multicast-MAC-Eintrag zu konfigurieren. Wenn ich versuche, dasselbe mit einem regulären statischen MAC-Eintrag zu tun, kann ich ihn nur an einen Port binden - dieser Lastausgleichscluster läuft über 4 verschiedene 10-Gig-Ports.
Update : Es scheint einige Verwirrung hinsichtlich der MAC-Adressen zu geben. 172.30.1.0/24 ist das nach vorne gerichtete Loadbalancer-Netzwerk. 172.30.1.6 ist der standardmäßige gemeinsam genutzte VIP für den Cluster, .7 ist die Verwaltungs-IP für den ersten Load Balancer und .8 ist für den zweiten Load Balancer. Alle anderen Adressen (30, 40, 70, 80 usw.) sind VIP-Adressen mit unterschiedlichen Diensten. Wenn ein Failover auftritt, ändern alle VIPs ihre MAC-Adresse in die physische MAC-Adresse der zweiten LB. Die Multicast-Adresse in der unteren Tabelle ändert sich nicht .
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
Und das ist die Geschichte. Was um alles in der Welt soll ich damit machen?
What on earth am I going to do with this?<- Tequila. Viel davon.