W porządku - walczę z tym przez co najmniej 20 godzin z rzędu .. Przepraszam, jeśli wydaje się to długim rantem lub postem na blogu, ale dochodzę do punktu wyczerpania.
Oto oferta. Korzystamy z równoważenia obciążenia KEMP, który wykorzystuje UCARP (klon CARP Linuksa, który jest klonem VRRP) do bicia serca HA i stanów trwałych. Chcemy wykorzystać IGMP w naszym środowisku, aby zapobiec zalaniu centrum danych.
Mamy dwa przełączniki Dell PowerConnect 8124F z oprogramowaniem 5.1.1.7, działające jako najwyższe stelaże. Te dwa są połączone ze skumulowaną parą Cisco 3750-X, która jest naszym rdzeniem.
Problemy zaczęły się, kiedy uaktualniliśmy do PowerConnect 5.1.x, gdzie najwyraźniej domyślnie pozostawili włączanie podglądania IGMP, chyba że powiesz inaczej. A oto - nasze moduły równoważenia obciążenia przeszły w rozszczepiony mózg, powodując różnego rodzaju ciepłą, rozmytą zabawę.
- Jeśli wyłączę szpiegowanie IGMP w sieci VLAN, w której moduły równoważące obciążenia wykonują multiemisję, nic się nie dzieje, multiemisja jest nadal martwa
- Jeśli skonfiguruję IP PIM na naszym rdzeniu, przełączniki PowerConnect widzą go w tej samej sieci VLAN, ale nadal nie ma ruchu multiemisji
- Jeśli włączę zalewanie całego niezarejestrowanego ruchu multiemisji, nadal nic nie robi.
- Jeśli wyłączę globalne podglądanie IGMP na przełącznikach PowerConnect, cały ruch multiemisji będzie działał. Działa tak świetnie, że zalewany jest ruch multiemisji do każdego portu, na którym jest oznaczony ten sam VLAN. Wspaniale.
Zauważyłem niektóre dziwne wpisy adresów MAC w sieci VLAN w naszym rdzeniu:
coresw#sh mac address-table vlan 367 | include 5e00
367 0000.5e00.0101 DYNAMIC Po13 seq_no:0
I myślę ... Czy to nie jest adres multiemisji? Dlaczego nie ma tego w „multiemisji tabeli adresów MAC mac”?
coresw#sh mac address-table multicast vlan 367
Vlan Mac Address Type Ports
---- ----------- ---- -----
coresw#
A potem przeczytałem to w przewodniku CLI PowerConnect:
Ruch multiemisji to ruch przeznaczony dla grupy hostów. Grupy hostów są identyfikowane przez docelowy adres MAC, tj. Zakres 01: 00: 5e: 00: 00: 00-01: 00: 5e: 7f: ff: ff: ff dla ruchu multiemisji IPv4 lub 33: 33: xx: xx : xx: xx dla ruchu multiemisji IPv6.
Wygląda na to, że brakuje nam „01” na początku adresu MAC, nie? Dynamiczny wpis MAC powyżej zaczyna się od „00”. W tym momencie myślę o skontaktowaniu się z KEMP i poinformowaniu ich, że ich produkt jest strasznie źle skonfigurowany. Ale potem idę przeczytać RFC dla VRRP - i oto:
Adres MAC routera wirtualnego powiązany z routerem wirtualnym to adres MAC IEEE 802 w następującym formacie:
Obudowa IPv4: 00-00-5E-00-01- {VRID} (szesnastkowo, w standardowej kolejności bitów w Internecie)
W porządku - więc przełączniki zwykle nie wychwytują zakresu adresów MAC multiemisji dla VRRP. Dobrze, skonfigurujmy statyczną grupę hostów na przełącznikach Dell. Nie.
Niepoprawne wejście: adres MAC multiemisji musi mieć format 01XX: XXXX: XXXX
OK, a następnie .. Następny krok, spróbuj dodać statyczny wpis Mac:
osl-sys-swrack03(config)#mac address-table multicast ?
forbidden forbid adding specific multicast addresses to
specific ports.
osl-sys-swrack03(config)#
Więc - nie ma sposobu, aby skonfigurować statyczny wpis MAC multiemisji. Jeśli spróbuję zrobić to samo ze zwykłym statycznym wpisem MAC, mogę powiązać go tylko z jednym portem - ten klaster równoważenia obciążenia działa na 4 różnych portach 10 gig.
Aktualizacja : Wydaje się, że istnieją pewne nieporozumienia dotyczące adresów MAC. 172.30.1.0/24 to czołowa sieć modułu równoważenia obciążenia. 172.30.1.6 jest domyślnym wspólnym VIP dla klastra, .7 to adres IP zarządzania dla pierwszego modułu równoważenia obciążenia, a .8 to drugi moduł równoważenia obciążenia. Wszystkie pozostałe adresy (30, 40, 70, 80 itd.) Są adresami VIP z różnymi usługami. Kiedy nastąpi przełączenie awaryjne, wszyscy VIP-y zmieniają swój adres MAC na fizyczny adres MAC drugiego LB. Adres multiemisji w dolnej tabeli nie zmienia się.
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
I taka jest historia. Co ja mam z tym zrobić?
What on earth am I going to do with this?<- Tequila. Dużo tego.