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.Odpowiedzi:
Byłem w stanie rozwiązać problem. W Kempie (z parą HA) masz opcję użycia „wirtualnego adresu MAC”. Jeśli to pole nie jest zaznaczone, wówczas MAC modułu równoważenia obciążenia VIP to interfejs fizyczny aktywnej jednostki Kemp. Jeśli to pole jest zaznaczone, wówczas adresem MAC VIP jest VRRP MAC. Jak wspomniano powyżej, RFC VRRP stwierdza, że MAC to „00:00” {bla}, a ostatni oktet to identyfikator routera. Domyślny identyfikator Kemp HA [routera] to 01. Na moich Powerconnectach z oprogramowaniem układowym 5.1.xx Nie używam VRRP, ale uruchomiłem trochę śladów i ustaliłem, że Powerconnect upuści ramkę VRRP, jeśli identyfikator routera jest taki sam. Robią to NAWET, jeśli VRRP nie jest skonfigurowany iw tym trybie domyślnie ma wartość 01. Zatem zmiana identyfikatora routera Kemp HA na coś w rodzaju 22 (0x16) spowodowała, że wszystko działało.
źródło
Szukany adres multiemisji to 224.0.0.18 [mac: 01005e.000012]. To jest kanał kontrolny dla wszystkich węzłów VRRP. [edytuj] O ile KEMP nie zmieni kodu, CARP (UCARP) inicjuje ruch przy użyciu MAC VRRP Unicast MAC [00005e.0001xx] - to jest miejsce, w którym przełącznik naturalnie by się tego nauczył.
Jeśli nie masz zapytania w sieci (prawdopodobnie w każdym segmencie), twoje przełączniki ostatecznie zapomną, gdzie są grupy - hosty nie wysyłają okresowego członkostwa, chyba że zostanie o to poproszony. [edytuj: W zależności od konfiguracji przełącznik może upuścić nieznaną multiemisję, a nie zalanie.] Może to być dedykowane zapytanie (wysyła pakiet, nie przejmuje się żadnymi odpowiedziami), lub częściej router multiemisji w Twojej infrastrukturze . W tym prostym przypadku wystarczy zapytanie, ponieważ wiadomości VRRP i tak nie mogą przekraczać segmentów.
Nie znam przełączników Dell, więc nie wiem, jakich poleceń cli potrzebujesz.
[AKTUALIZACJA]
To nie jest mac multiemisji. To źródło MAC emisji pojedynczej ruchu multiemisji. Mac multiemisji nie pojawi się w tabeli adresów mac. To jest w tabeli grupy multiemisji. Cisco IOS ma
show mac-address-table multicast(pokazuje nic na moim routerze) ishow ip igmp groups(pokazuje 3 grupy). Router jest ustawiony na tryb pim sparse; Przełączniki nortel i cisco postrzegają to jako kwestię sporną.Metoda KEMP jest głęboko wadliwa, ponieważ używa hosta NIC MAC dla adresów wirtualnych. W twoim przypadku 5004 należy do nic. Kiedy 5004 zniknie, wszyscy nadal będą mieć w swoich tabelach „IP: 6 == MAC: 5004”; będą kontynuować próby rozmowy z martwym gospodarzem, dopóki ten wpis nie zostanie zastąpiony. KEMP oczywiście gra na darmowym arpie, który jest honorowany przez wszystko w sieci. HSRP, VRRP, a OpenBSD zaprojektowany karp wszystkie wykorzystanie wirtualnego MAC dla tego samego powodu. (Wygląda na to, że nie udało im się zhakować UCARP, aby użyć Nic Mac zamiast VR Mac VRRP podczas przesyłania ruchu multiemisji).
Biorąc pod uwagę, że hakują UCARP, czy jesteś pewien, że używa nawet multiemisji?
źródło
show ip igmp snooping querier vlan 367dla cisco)