Troubleshooting NSX 4

Po co powstał ten poradnik?

Pracując co dzień na rozwiązaniu jakim jest NSX mierzymy się z problemami jakie powstają podczas pracy w oparciu o rozwiązania VMware. Bardzo trudno jest zebrać w jednym miejscu informacje o tym jak podejść do rozwiązywania problemów, tym bardziej, że z wersji na wersję rozwiązanie jest coraz bardziej rozbudowane i coraz to nowe funkcje zapisują tu i ówdzie informacje o błędach i statusie pracy.

Dla utrudnienia Administration Guide stają się coraz bardziej opasłe i trudno z nich wyłuskać wartościowe informacje, a ostatnia wersja oficjalna Troubleshooting Guide pochodzi z ponad 3 lat.

Jak żyć?

Dlatego dziękuje, że tutaj jesteś i specjalnie dla Ciebie przygotowałem esencję informacji pomagających w codziennej pracy w oparciu o platformę VMware NSX.

Administrując rozwiązaniem mamy najważniejsze komponenty:

NSX Management Cluster

Główne wskazane na rysunku usługi pełnią następujące funkcje:

• Datastore: Storage containers for files (Corfu Database) – baza danych zawierająca konfigurację NSX.
• Cluster_Boot_Manager jest odpowiedzialny za orkiestrację usług klastrowania na platformie NSX Manager nodes.
• Controller: to system zarządzania stanami rozproszonego środowiska sieciowego, który zapewnia funkcje warstwy sterowania dla switchingu oraz routingu w NSX.
• Manager: udostępnia GUI oraz REST API do tworzenia, konfigurowania i monitorowania komponentów NSX Data Center, takich jak przełączniki logiczne, routery logiczne, firewall etc.
• Policy: Dzięki NSX Policy można zarządzać dostępem do zasobów i ich wykorzystaniem bez zagłębiania się w szczegóły.
• HTTPS:  Główny punkt wejścia do obsługi żądań do API oraz UI. Komponent reverse-proxy rozdziela połączenia przychodzące między komponenty NSX Manager.
• MONITORING: Przesyła anonimowe dane do VMware podczas uczestnictwa w programie poprawy jakości obsługi klienta (CEIP).
• IDPS_REPORTING: Realizuje rozproszone usługi wykrywania i zapobiegania włamaniom (IDPS), które umożliwiają identyfikację prób włamań za pomocą introspekcji sieciowej.
• CORFU_NONCONFIG: Kontener do przechowywania danych, który nie jest związany z konfiguracją dla usług które nie wymagają małych opóźnieniach, takich jak używany przez IDPS.

Wiedząc jakie usługi za co odpowiadają należy znać lokalizację dla każdej z nich.

get cluster status (nsxcli)	Linux service (/etc/init.d/)	Log in as root (Linux)
DATASTORE	corfu-server	/var/log/corfu/corfu.9000.log
CLUSTER_BOOT_MANAGER	nsx-cluster-boot-manager	/var/log/cbm/cbm.log
CONTROLLER	nsx-ccp	/var/log/cloudnet/nsx-ccp.log
MANAGER	proton	/var/log/proton/nsxapi.log
POLICY	nsx-policy-manager	/var/log/policy/policy.log
HTTPS	proxy	/var/log/proxy/reverse-proxy.log
MONITORING (CEIP)	phonehome-coordinator	/var/log/phonehome-coordinator/phonehome-coordinator.log
IDPS_REPORTING	idps-reporting-service	/var/log/idps-reporting/idps.log
CORFU_NONCONFIG	corfu-nonconfig-server	/var/log/corfu-nonconfig/corfu.9040.log
Node API logs	–	/var/log/nvpapi/api_server.log

Aby nie okrywać koła na nowo większość błędów jakie można znieść w tych logach znajdują się tutaj w KB VMware o numerze: 71077 – NSX Data Center Error Codes

Transport Node – to nic innego jak Hypervisor lub serwer, który obsługuje workload dla naszego środowiska NSX

Opierając się o powyższy schemat komunikacyjna następuje:

• NSX Manager management plane communicates with the transport nodes by using APH Server over NSX-RPC/TCP through port 1234.
• Warstwa zarządzania NSX Manager komunikuje się z nodami transportowymi przy użyciu serwera APH za pomocą NSX-RPC/TCP przez port 1234.
• CCP komunikuje się z węzłami transportowymi przy użyciu serwera APH przez NSX-RPC/TCP przez port 1235.
• TnProxy (nazywany NSX-Proxy) na nodzie transportowym odbiera komunikaty NSX-RPC z NSX Manager i CCP.
• Appliance Proxy Hub (APH)  – usługa nsx-appl-proxy która działa na NSX Manager.

Lokalizacja plików gdzie zapisywana jest konfiguracja odpowiednio znajduje się:

Opis	Log in as root (ESXi)
Stan instalacji VIB (vSphere Installation Bundle) od NSX Data Center oraz inne pakiety zainstalowane na ESXi	/var/log/esxupdate.log
Zweira informacje o dvports tworzonych na hoście ESXi oraz powiązanych komponentach	/var/log/vmkernel.log
Plik zawiera UUID vswitch-a, identyfikator UUID dla stref transportowych, porty TEP oraz informacje o interfejsach Hyperbus.	/var/log/nsxaVim.log
Plik zawiera log z przygotowania noda transportowego. Zawiera identyfikatory przełącznika, identyfikator strefy transportowych, szczegóły interfejsu Geneve	/var/log/nsx-syslog.log
Zapewnia zapis z komunikacji warstwy zarządzania z centralną warstwa zarządzania (CCP)	/var/log/nsx-proxy.log
Plik zawiera zapis reguł obejmujych wszystkie decyzje dotyczące dostępu pod warunkiem, że reguły włączono rejestrowanie	/var/log/dfwpktlogs.log

Kroki jakie wykonujemy celem weryfikacji i analizy problemu zaczynamy na TN od:

Zainstalowanych VIB esxcli software vib list | grep –e nsx –e vsip

Lista vmkernel portów oraz przypisanych adresów IP: esxcli network ip interface ipv4 address list

esxcli network ip netstack list może pomóc w weryfikacji stosów TCP/IP używanych przez tunel entpoint protokołu GENEVE (TEP) oraz interfejsy typu hyperbus na ESXi o dodam niebawem kilka zmian wynikających z ostatnich wersji NSX

Weryfikacja stanu działania usługi odpowiedzialnej za połaczenie do Manager /etc/init.d/nsx-proxy status oraz jej połączenia do Manager: esxcli network ip connection list | grep 1235

A co z warstwą trzecią?

Kolejnym komponentem są Gateway, które tworzymy w środowisku i ich zadaniem jest realizacja funkcji routingu, które mogą działać na dwóch oddzielnych „jednostkach”: routerze rozproszonym (DR) i routerze usługowym (SR). Tak przygotowane Gateway, można wdrażać w dwóch typach (Tier-0 i Tier-1), w zależności od wymagań i używanej topologii. W zależności od wymagań Gateway można skonfigurować w dwóch typach trybów wysokiej dostępności: active-actvice lub active-standby.

Rozkładając komunikację pomiędzy Gateway T0 oraz T1 i ich wbudowane komponenty możemy wyróżnić następujące interfejsy oraz „jednostki”:

• Uplink – interfejs połączeniowy pomiędzy T0, a routerem fizycznym czy fizyczną za NSX
• Downlink – interfejs połączeniowy do wirtualnej maszyny, lub kontenera. Przypisanie adresu IP generuje domyślną bramę (LIF) na DR i otrzymuje adres MAC zwanym vMAC (Virtual MAC Address), który ma stałą wartość: 02:50:56:56:44:52.
• Router Link – interfejs pomiędzy routerami T0 oraz T1, generowany automatycznie (automplumbing) i przypisujący adresację z CGN (Carrier-grade NAT) czyli 100.64.x.x/31
• Intra Transit Tier Link – interfejs łączący router dystrybułowany z routerem usługowym (DR do SR). Dzieje się to w sposób automatyczny i adresacja przypisana pochodzi z APIPA (Automatic Private IP Addressing) czyli: 169.254.x.x/28

Gateway fizycznie jest alokowany na Edge Node, który występuje w postaci fizycznej lub wirtualnej maszyny i posiada 4 interfejsy.

Kroki jakie wykonujemy celem weryfikacji i analizy problemu z routingiem zaczynamy od:

Polecenia get logical-routers, aby pobrać identyfikator, nazwę i identyfikator UUID routera logicznego (SR lub DR).

Pozyskiwanie informacji o instancji DR na TN czyli hoście ESXi, wykonuje się za pomocą polecenia net-vdr -l -I

Bezpieczeństwo też przysparza problemy.

NSX w odróżnieniu od typowego rozwiązania security posiada firewall, jest typu distributed, czyli znajduje się na każdym TN.

Architektura przedstawia się następująco:

Funkcja przedstawionych komponentów przedstawia się następująco:

• VSIP – Odbiera reguły zapory sieciowej i przypisuje do vNIC każdej maszyny wirtualnej objętej polityką bezpieczeństwa
• VDPI – Przeprowadza kontrolę pakietów L7 czyli warstwy aplikacji
• Stats Exporter – odpowiada za dostarczanie do NSX-Manager informacji o statykach ruchu sieciowego objętego polityką bezpieczeństwa.

Tak dostarczone polityki bezpieczeństwa zamienione na reguły zapory sieciowej (firewall) za pomocą procesu vmware-sfw, są egzekwowane dla każdego przepływu. A następnie odkładane na tablicy sesji analogicznie jak to robi każdy stanowy firewall.

Jak to działa:

W tabeli połączeń (connection table) wykonywane jest wyszukiwanie w celu sprawdzenia, czy połączenie już istnieje. Jeśli połączenie nie jest obecne, pakiet jest dopasowywany do tabeli z dostarczonych wcześniej (rule table) z VISP reguł.

Jeśli pakiet jest dozwolony, a typ ruchu jest stanowy, w tabeli połączeń tworzony jest nowy wpis połączenia. W rezultacie wszystkie kolejne pakiety dla tego samego połączenia są obsługiwane bezpośrednio z tabeli połączeń. Pakiety bezstanowe są zawsze porównywane z tabelą reguł.

Jak w takim razie rozwiązywać problemy na takim poziomie abstrakcji:

Możesz zweryfikować Distributed Firewall CLI za pomocą polecenia get firewall orz get firewall summary

Na TN ESXi polecenie summarize-dvfilter wyświetla szczegóły maszyn wirtualnych działających na hoście ESXi, wraz z informacji o szczegółach nazw reguł przypisanych do vNIC (vmware-sfw_name).

Polecenie get firewall published-entitys pokazuje reguły opublikowane za pomocą CCP.

Pozyskane informacje o nazwach regułach można prztłumaczyć na zawartość tablic (rule table) za pomocą następujących poleceń:

vsipioctl getrules -f <vmware-sfw_name>

Na koniec to co tygrysy lubią najbardziej czyli analiza pakietu po pakacie.

Do tego jest zestaw poleceń:

start capture dvfilter < vmware-sfw_name > stage <pre|post>

start capture interface <interface-name> [direction <input|ouptput|dual>]

Lista przygotowanych tutaj zestawów poleceń oraz opisów architektury odnosi się do najnowszej wersji NSX i jest stale aktualizowana.