Witam, na początek trochę refleksji. Czasami zazdroszczę kolegom pracującym zdalnie — to wspaniałe mieć możliwość pracy z dowolnego miejsca na świecie z dostępem do Internetu, wziąć wakacje w dowolnym momencie, ponosząc odpowiedzialność za projekty i terminy, a nie siedzieć w biurze od 8 do 17. Moja pozycja i obowiązki zawodowe praktycznie wykluczają długotrwałą nieobecność w centrum danych. Jednak od czasu do czasu zdarzają się ciekawe przypadki, takie jak opisany poniżej — i rozumiem, że jest niewiele stanowisk, gdzie można wyrazić swoją kreatywność jako wewnętrzny troubleshooter.
Mała uwaga — w momencie pisania artykułu sprawa nie została całkowicie rozwiązana, ale biorąc pod uwagę tempo odpowiedzi dostawców, pełne rozwiązanie może zająć jeszcze kilka miesięcy, a chciałbym się już teraz podzielić swoimi spostrzeżeniami. Mam nadzieję, że drodzy czytelnicy, wybaczycie mi tę pochopność. Ale dość teorii — co tam w tej sprawie?
Na początek kontekst: jest firma (gdzie pracuję jako inżynier sieci), która hostuje rozwiązania klientów w prywatnej chmurze VMWare. Większość nowych rozwiązań jest podłączana do segmentów VXLAN zarządzanych przez NSX-V — nie będę oceniać, ile czasu zaoszczędziło mi to rozwiązanie, powiem krótko — bardzo dużo. Udało się nawet przeszkolić kolegów w konfigurowaniu NSX ESG, a mniejsze rozwiązania klientów są uruchamiane bez mojego udziału. Ważna uwaga — nasz plane kontrolny działa na bazie replikacji unicast. Hypervisory są podłączone w redundantny sposób przez dwa interfejsy do różnych fizycznych przełączników Juniper QFX5100 (zbudowanych w ramach Virtual Chassis) oraz polityka timingowa oparta na porcie wirtualnym — to dla pełniejszego obrazu.
Rozwiązania dla klientów są bardzo zróżnicowane: od Windows IIS, gdzie wszystkie komponenty serwera www są zainstalowane na jednej maszynie, do całkiem dużych — na przykład zrównoważone obciążenie frontendów Apache + LB MariaDB w Galera + serwery udostępniania, synchronizowane za pomocą GlusterFS. Praktycznie każdy serwer trzeba monitorować osobno, a publiczne adresy nie są dostępne dla wszystkich komponentów — jeśli zetknęliście się z tym problemem i macie bardziej eleganckie rozwiązanie, będę wdzięczny za radę.
Moje rozwiązanie monitorowania polega na „podłączeniu” firewalla (Fortigate) do każdej wewnętrznej sieci klientów (+SNAT i oczywiście surowe ograniczenia dotyczące dozwalonego ruchu) oraz obserwacji wewnętrznych adresów — w ten sposób osiąga się pewną unifikację i uproszczenie monitorowania. Samo monitorowanie odbywa się z klastra serwerów PRTG. Schemat monitorowania wygląda mniej więcej tak:
Dopóki obsługiwaliśmy tylko VLAN, wszystko było dość normalne i działało jak w zegarku. Po wdrożeniu NSX-V i VXLAN pojawił się problem — czy można kontynuować monitorowanie w stary sposób? W momencie zadania tego pytania najszybszym rozwiązaniem było uruchomienie NSX ESG i podłączenie interfejsu trunk VXLAN do sieci VTEP. Szybkim w cudzysłowie — ponieważ używanie interfejsu graficznego do konfigurowania sieci klientów, SNAT i zasad firewalla może unifikować zarządzanie w jednym interfejsie vSphere, ale moim zdaniem jest dość nieporęczne i ogranicza zestaw narzędzi do rozwiązywania problemów. Ci, którzy używali NSX ESG jako zastępstwa „prawdziwego” firewalla, myślę, zgodzą się. Chociaż być może takie rozwiązanie byłoby bardziej stabilne — przecież wszystko dzieje się w ramach jednego dostawcy.
Kolejnym rozwiązaniem jest użycie NSX DLR w trybie bridge między VLAN a VXLAN. Myślę, że to jasne — po prostu traci się korzyści z zastosowania VXLAN, ponieważ w takim przypadku trzeba ciągnąć VLAN do instalacji monitorującej. Zresztą, w trakcie pracy nad tym rozwiązaniem natknąłem się na problem, gdy DLR bridge nie wysyłał pakietów do maszyny wirtualnej, z którą znajdował się na tym samym hoście. Wiem, wiem — w książkach i przewodnikach dotyczących NSX-V jest wyraźnie napisane, że dla NSX Edge należy przeznaczyć osobny klaster, ale to w książkach... Tak czy inaczej, po kilku miesiącach z pomocą techniczną nie rozwiązaliśmy problemu. Zasadniczo zrozumiałem logikę działania — moduł jądra hypervisora odpowiedzialny za kapsułkowanie VXLAN nie był używany, gdy DLR i monitorowany serwer znajdowały się na tym samym hoście, ponieważ ruch nie opuszczał hosta i zgodnie z logiką powinien być podłączony do segmentu VXLAN — kapsułkowanie nie jest potrzebne. Z pomocą techniczną zatrzymaliśmy się na wirtualnym interfejsie vdrPort, który logicznie łączy uplinki i realizuje bridging/kapsułkowanie — tam zauważono niespójność w ruchu przychodzącym, którą wziąłem do analizy w bieżącym przypadku. Ale jak powiedziano, nie doprowadziłem tego przypadku do końca, ponieważ zostałem przerzucony na inny projekt, a gałąź była początkowo martwa, więc nie miałem szczególnej ochoty jej rozwijać. Jeśli się nie mylę, problem występował w wersjach NSX 6.1.4 i 6.2.
I tu — bingo! Fortinet ogłasza natywną . I nie tylko point-to-point czy VXLAN-over-IPSec, nie ma oprogramowania do bridżowania VLAN-VXLAN — wszystko to zaczęto wdrażać już od wersji 5.4 (i jest przedstawione u innych ), a rzeczywista obsługa unicast control plane. W trakcie wdrażania rozwiązania napotkałem jeszcze jeden problem – monitorowane serwery okresowo „znikały”, a następnie pojawiały się w monitoringu, chociaż sama wirtualna maszyna była aktywna. Okazało się, że zapomniałem włączyć Ping na interfejsie VXLAN. W trakcie rebalansowania klastrów wirtualne maszyny były przenoszone, a Ping kończył vMotion, aby oznaczyć nowego hosta ESXi, na który przeniosła się maszyna. Moja głupota, jednak ten problem ponownie podważył zaufanie do wsparcia producenta – w tym przypadku Fortinet. Nie wspomnę już, że każda sprawa związana z VXLAN zaczyna się od pytania „a gdzie w ustawieniach softswitcha jest VLAN-VXLAN?” Tym razem doradzono mi zmianę MTU – to dla Pingu, który ma 32 bajty. Następnie „pobaw się” z tcp-send-mss i tcp-receive-mss w polityce – dla VXLAN, który jest enkapsulowany w UDP. Uf, przepraszam – nagromadziło się. W każdym razie ten problem rozwiązałem samodzielnie.
Po pomyślnym przetestowaniu ruchu zdecydowano się wdrożyć to rozwiązanie. W produkcji okazało się, że po jednym lub dwóch dniach wszystko, co jest monitorowane przez VXLAN, stopniowo przestaje działać. Dezaktywacja/aktywacja interfejsu pomagała, ale tylko na moment. Pamiętając o opóźnieniach wsparcia producenta, zajmowałem się troubleshootingiem z własnej strony – w końcu moja firma, moja sieć – moja odpowiedzialność.
Pod spoilerem przebieg troubleshootingu. Kto zmęczony literami i przechwałkami – proszę przejść do postanalizy.
Przebieg troubleshootinguDziękuję, że kontynuujesz czytanie – jedźmy dalej!
Więc monitorowanie działa przez jakiś czas, potem samodzielnie przestaje. Oznacza to, że w politykach zapory prawdopodobnie nie ma problemów. Jednak, ponieważ miałem do czynienia z problemem zablokowanych procesów systemowych w Fortigate wersji 5.6 i wyższych, najpierw sprawdzamy „diagnose debug flow” – oczekiwanie jest, że ruch jest dozwolony i opuszcza interfejs, a nic nie przychodzi w odpowiedzi. Oznacza to, że kopimy dalej po stosie. Niestety, będę musiał ukryć adresy, nawet te zgodne z RFC1918, ale mam nadzieję, że dostarczę wystarczający opis, aby ułatwić zrozumienie. Serwer wewnątrz VXLAN ma adres x.x.x.15, interfejs Fortigata x.x.x.254, wszystkie pozostałe adresy należą do sieci VTEP.
Aby pomyślnie przesłać pakiety kapsułkowane w VXLAN, konieczne jest posiadanie poprawnych informacji w kilku tabelach. Dla overlay to ARP i OVSDB, a dla underlay ARP i CAM. W przypadku Fortigate VXLAN FDB to OVSDB. Tam zaczniemy:
fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=у.у.у.47 port=4789 vni=5008 ifindex=7
Tu wszystko jest dość proste — adres MAC wirtualnej maszyny musi znajdować się na VTEP z adresem у.у.у.47. Po sprawdzeniu zawartości i ustawień klastra ESXI widzę, że adres MAC wirtualnej maszyny jest poprawny, a adres VTEP również. Sprawdzam tabelę CAM/ARP na fortigate — znowu wszystko zgadza się z ustawieniami hosta ESXI:
fortigate (root) #get sys arp | grep у.у.у.47
у.у.у.47 0 00:50:56:65:f6:2c dmz
Tabele są poprawne i ruch wychodzi — może problem nie leży na fortigate? Celowo pominąłem analizę przełączania ruchu na Juniperze — logicznie rzecz biorąc, to tam należy wykonać następny krok rozwiązywania problemu, ale moja sieć jest prosta — tylko jeden VLAN dla VTEP, a wszystkie komponenty są podłączone bezpośrednio. Plus przypominam sobie przypadek z mostem DLR, VDR i znikającym ruchem — idę sniffować na hoście ESXI, jednocześnie tworząc sprawę już do VMWare. Poniżej MAC „97:6e” należy do forti, vmnic1 — to interfejs, który ma VTEP z adresem у.у.у.47 sniffuję w obu kierunkach "—dir 2":
pktcap-uw --uplink vmnic1 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
Postęp — w sniffie widzę zapytanie ARP i nadchodzącą odpowiedź. Przedstawiam tylko odpowiedź ARP i tam wszystko jest poprawne. Nie wspomniałem, ale przez cały ten czas serwer monitorowania pingował adres х.х.х.15 — gdzie jest ruch ICMP? Przypominam sobie, że mam dwa uplinki. Można tu polemizować i powiedzieć, że wirtualny port źródła jest ten sam (moja polityka grupowania), to znaczy dla tej samej vNIC powinien być wybierany ten sam uplink, ale skoro jestem na hoście, sprawdzenie drugiego uplinku nie stanowi problemu:
pktcap-uw --uplink vmnic4 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
Przychodzą zapytania z Fortigate, ale odpowiedzi brak. To znaczy, że problem nie leży w Fortigate. Cóż, myślę sobie — znowu ten sam problem z znikającym ruchem na VDR, znów muszę przez kilka miesięcy kierować sprawę w odpowiednie tory. Po kilku dniach, ochłonąwszy, i nie chcąc się godzić z zawieszeniem, postanowiłem zebrać jeszcze snify dla wsparcia, aby przyspieszyć proces. I tu „przypadkowo” mój wzrok pada na Ethernet encapolation underlay. Król nie jest prawdziwy, a adres MAC VTEP nie zgadza się z jego IP. Resetuję do zera, snifuję, kopię — słusznie, że nie słychać. Zestawię tabelę ARP obok, aby łatwiej porównywać. Zwróć uwagę na pierwszą encapsulację Ethernet na górnym obrazku:
fortigate (root) #get sys arp | grep u.u.u.47
u.u.u.47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep u.u.u.42
u.u.u.42 0 00:50:56:6a:78:86 dmz
Tak więc, co mamy na końcu — po migracji maszyny wirtualnej, Fortigate próbuje wysłać ruch do VTEP z (poprawnego) VXLAN FDB, ale używa błędnego MAC DST i ruch oczekiwanie jest odrzucany przez interfejs hyperwizora, który go odbiera. Przy czym w jednym przypadku na cztery ten MAC należał do pierwotnego hyperwizora, z którego rozpoczęto migrację maszyny.
Wczoraj otrzymałem e-mail od wsparcia technicznego Fortinet — w moim przypadku otworzyli błąd 615586. Nie wiem, czy się cieszyć, czy smucić: z jednej strony — problem nie leży w ustawieniach, z drugiej — poprawka przyjdzie dopiero z aktualizacją oprogramowania, w najlepszym przypadku następnym. Moje samouwielbienie podgrzewa także inny błąd, który wykryłem w zeszłym miesiącu, wprawdzie tym razem w HTML5 GUI vSphere. Cóż, prawdziwy lokalny dział QA dostawców...
Zaryzykuję przypuszczenie, że:
1 — kontrola multikastowa prawdopodobnie nie będzie poddana opisanemu problemowi — adresy MAC VTEP są uzyskiwane z adresu IP grupy, do której przypisany jest interfejs.
2 — prawdopodobnie problem Fortigate leży w zrzucie sesji na Procesor Sieciowy (podobny do CEF) — jeśli każdy pakiet przepuszczany jest przez CPU, będą wykorzystywane tabele zawierające poprawne — przynajmniej na pierwszy rzut oka — informacje. Na korzyść tej tezy przemawia to, że pomocne jest zamknięcie/otwarcie interfejsu lub odczekanie chwili — więcej niż 5 minut.
3 — zmiana polityki teaming, na przykład na explicit failover, lub wdrożenie LAG nie rozwiąże problemu, ponieważ zauważono „zatrzymywanie się” MAC pierwotnego hyperwizora w enkapsulowanych pakietach.
W świetle tego mogę podzielić się, że niedawno odkryłem blog , gdzie w jednym z artykułów twierdzono, że strefowe zapory i buforowane sposoby przesyłania danych to obejścia. Cóż, nie jestem na tyle doświadczony w IT, aby to stwierdzić, zresztą nie zgadzam się z większością twierdzeń artykułów blogowych za każdym razem. Jednak coś mi mówi, że jest prawda w słowach Ivana.
Dziękuję za uwagę! Chętnie odpowiem na pytania i wysłucham konstruktywnej krytyki.
Źródło: habr.com
