VXLAN i NSX-V — felsökning av underlay

Hej, och först lite lyrik. Jag avundas ibland kollegor som arbetar på distans — det är fantastiskt att kunna arbeta från vilken plats som helst i den uppkopplade världen, ta ledigt när som helst, ha ansvar för projekt och deadlines, istället för att befinna sig på kontoret mellan 8 och 17. Min position och arbetsuppgifter utesluter nästan möjligheten till långvarig frånvaro från datacentret. Men — då och då inträffar intressanta fall, likt det som beskrivs nedan — och jag förstår att det finns få positioner där det finns så mycket utrymme för kreativt uttryck av den interna felsökaren.

En liten disklaimer — vid tidpunkten för artikelns skrivande är fallet inte helt löst, men med tanke på svarstiden från leverantörer kan det dröja månader att få en fullständig lösning, och jag vill gärna dela med mig av mina fynd redan nu. Jag hoppas att ni, kära läsare, kan förlåta mig denna brådska. Men nog med vatten — vad händer med fallet?

Först en introduktion: det finns ett företag (där jag arbetar som nätverksingenjör) som hostar kundlösningar i en privat VMWare-moln. De flesta nya lösningar ansluts till VXLAN-segment som hanteras av NSX-V — jag ska inte bedöma hur mycket tid detta beslut har gett mig, kort sagt — mycket. Jag har till och med lyckats lära kollegor att konfigurera NSX ESG och små kundlösningar implementeras utan min inblandning. En viktig notering — kontrollplanet har vi med unicast-replikering. Hypervisorerna är anslutna redundanta med två gränssnitt till olika fysiska Juniper QFX5100-switchar (som är ihopkopplade i ett Virtual Chassis) och en policy för rutning baserad på den ursprungliga virtuella porten — detta för att få en helhetsbild.

Kundlösningarna är mycket skiftande: från Windows IIS, där alla komponenter av webbservern är installerade på en och samma maskin, till ganska stora — exempelvis lastbalanserade Apache-webbfronter + LB MariaDB i Galera + delad servrar, synkroniserade med GlusterFS. Nästan varje server måste övervakas separat, och offentliga adresser finns inte för alla komponenter — om du har stött på denna uppgift och har en mer elegant lösning, skulle jag uppskatta ett tips.
Min övervakningslösning innebär att "koppla" brandväggen (Fortigate) till varje intern kundnätverk (+SNAT och självklart strikt begränsning av tillåten trafik) och övervaka interna adresser – på så sätt uppnås en form av enhetlighet och förenkling av övervakningen. Själv övervakning görs från en kluster av PRTG-servrar. Övervakningsschemat ser ungefär ut så här:

När vi endast arbetade med VLAN fungerade allt ganska vanligt och förutsägbart, som en klocka. Efter implementeringen av NSX-V och VXLAN ställdes vi inför frågan – kan vi fortsätta övervaka som tidigare? Vid tidpunkten för denna fråga var den "snabbaste" lösningen att distribuera NSX ESG och koppla VXLAN trunk-gränssnittet till VTEP-nätverket. Snabbt i citat – eftersom användning av GUI för att konfigurera kundnätverk, SNAT och brandväggsregler kanske enhetliggör hanteringen i ett enda vSphere-grinterfaces, men enligt min åsikt är det ganska klumpigt och, utöver allt, begränsar det verktygssatserna för felsökning. De som har använt NSX ESG som ersättning för en "riktig" brandvägg kommer nog att hålla med. Även om, kanske, en sådan lösning skulle vara mer stabil – eftersom allt sker inom en leverantörs ramverk.

En annan lösning är att använda NSX DLR i bridge-läge mellan VLAN och VXLAN. Här tycker jag att allt är klart – man förlorar helt enkelt fördelen med att använda VXLAN – eftersom man fortfarande måste dra VLAN till övervakningsinstallationen. För övrigt stötte jag under arbetet med den här lösningen på ett problem där DLR-bryggan inte skickade paket till den virtuella maskin med vilken den befann sig på samma värd. Jag vet, jag vet – i böcker och guider om NSX-V står det klart att en separat kluster ska tilldelas NSX Edge, men det är i böckerna… Hur som helst, efter ett par månader med supporten löste vi inte problemet. I princip förstod jag logiken bakom – kärnmodulen i hypervisorn, som är ansvarig för inkapsling av VXLAN, aktiverades inte om DLR och den observerade servern befann sig på samma värd, eftersom trafiken inte lämnar värden och enligt logiken skulle vara kopplad till VXLAN-segmentet – inkapsling behövs inte. Med supporten kom vi fram till det virtuella gränssnittet vdrPort, som logiskt förenar uplinks och även utför bryggning/inkapsling – där noterades en avvikelse i den inkommande trafiken, som jag tog med mig i det aktuella ärendet. Men som sagt, jag avslutade inte detta ärende helt, eftersom jag blev överflyttad till ett annat projekt och dessutom var den grenen från början en återvändsgränd, och jag hade inte särskilt mycket lust att utveckla den. Om jag inte misstar mig observerades problemet i versionerna NSX 6.1.4 och 6.2.

Och där - bingo! Fortinet tillkännager nativ stöd för VXLAN. Och inte bara point-to-point eller VXLAN-over-IPSec, inte programvarubryggning av VLAN-VXLAN - allt detta började implementeras redan med version 5.4 (och finns representerat hos andra leverantörer), och den verkliga supporten av unicast control plane. När jag implementerade lösningen stötte jag på ett annat problem - de övervakade servrarna försvann periodvis från övervakningen, även om själva virtuella maskinen var aktiv. Anledningen var att jag glömde att tillåta Ping på VXLAN-gränssnittet. Under ombalanseringen av klustren flyttades de virtuella maskinerna, och Ping avslutade vMotion för att ange den nya ESXi-värden som maskinen flyttades till. Det var en dumhet från min sida, men detta problem skadade återigen förtroendet för supporten från tillverkaren - i detta fall Fortinet. Jag nämner inte ens att varje ärende relaterat till VXLAN börjar med frågan

Efter att ha testat trafik framgångsrikt beslutades det att implementera denna lösning. Och i produktion visade det sig att efter en eller två dagar försvann allt som övervakades genom VXLAN gradvis. Deaktivering/aktivering av gränssnittet hjälpte, men bara för en kort stund. Med tanke på tillverkarens långsamhet i support, satte jag igång med felsökningen från min sida - i slutändan är det mitt företag, mitt nätverk - mitt ansvar.

Under spoiler-texten finns felsökningsprocessen. Den som tröttnat på bokstäver och överdrifter - hoppa över detta och gå vidare till postanalysen.

FelsökningsprocessenTack för att du fortsatte läsa - vi fortsätter!

Så, övervakningen fungerar under en tid, sedan bryter den ner av sig själv. Det antyder att det förmodligen inte finns några problem i brandväggens policyer. Men eftersom jag har stött på problemet med hängande systemprocesser i Fortigate versioner 5.6+, så kollar vi först på "diagnose debug flow" - som väntat tillåts trafiken och skickas ut från gränssnittet och som väntat kommer det inget svar. Så vi gräver vidare i stacken. Tyvärr måste vi dölja adresser, även om de är RFC1918, men jag hoppas kunna ge processen en tillräcklig beskrivning för förståelse. Servern inom VXLAN har adress x.x.x.15, Fortigate-gränssnittet x.x.x.254, och alla andra adresser tillhör VTEP-nätverket.

För en lyckad överföring av VXLAN-kapslade paket krävs korrekt information i flera tabeller. För overlay är det ARP och OVSDB, för underlay är det ARP och CAM. I fallet med Fortigate är VXLAN FDB och OVSDB samma sak. Här börjar vi:

 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

Här är allt ganska enkelt — MAC-adressen för den virtuella maskinen måste finnas på VTEP med adressen у.у.у.47. Genom att titta på innehållet och inställningarna i ESXI-klustret finner jag att MAC-adressen för den virtuella maskinen är korrekt, och adressen för VTEP likaså. Jag kontrollerar CAM/ARP-tabellen på fortigate — återigen stämmer allt överens med inställningarna på ESXI-värden:

fortigate (root) #get sys arp | grep у.у.у.47
у.у.у.47 0 00:50:56:65:f6:2c dmz

Tabellerna är korrekta och trafiken går — kanske problemet inte ligger hos fortigate? Jag har avsiktligt hoppat över analysen av trafikväxlingen på Juniper — logiskt sett bör nästa steg i felsökningen göras där, men mitt nätverk är enkelt — bara en VLAN för VTEP och alla komponenter är direktanslutna. Dessutom minns jag ett fall med DLR-bryggan, VDR och försvinnande trafik — jag går för att sniffa på ESXI-värden och skapar samtidigt ett ärende till VMWare. Nedan har MAC "97:6e" tillhör fortigate, vmnic1 — detta är gränssnittet som har VTEP med adressen у.у.у.47, vi sniffar i båda riktningar "—dir 2":

pktcap-uw --uplink vmnic1 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

Framsteg — i sniffen ser jag ARP-förfrågan och det inkommande svaret. Jag visar bara ARP-svaret och där är allt korrekt. Jag nämnde inte, men under hela denna tid pingade övervakningsservern adressen х.х.х.15 — var är ICMP-trafiken? Jag minns att jag har två uplinks. Här kan man diskutera och säga att den virtuella portens källa är densamma (min teaming policy), det vill säga för samma vNIC borde samma uplink väljas, men eftersom jag är på värden är det inget problem att kontrollera den andra uplinken:

pktcap-uw --uplink vmnic4 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

Jag får förfrågningar från Fortigate, men inget svar. Det vill säga att problemet inte ligger hos Fortigate. Tja, jag tänker att det är samma gamla problem med förlorad trafik på VDR, återigen måste jag spendera ett par månader för att få till rätt person med ärendet. Efter ett par dagar, när jag svalt ner det och inte ville acceptera situationen, bestämde jag mig för att samla fler sniffar för supporten för att påskynda processen. Och här, "av en slump", dras min blick till Ethernet-inkapslingen underlay. Kungen är inte verklig och MAC-adressen för VTEP överensstämmer inte med dess IP. Jag nollställer, sniffer, gräver — sant eller falskt. Jag kommer att visa ARP-tabellen bredvid, så att det är lättare att jämföra. Notera den första Ethernet-inkapslingen på bilden ovan:

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

Så, vad har vi kommit fram till — efter migreringen av den virtuella maskinen, försöker Fortigate skicka trafik till VTEP från (korrekt) VXLAN FDB, men använder fel DST MAC och trafiken kasseras som förväntat av den mottagande hypervisorgränssnittet. Och i en av fyra fall tillhörde denna MAC den ursprungliga hypervisorn, från vilken migreringen av maskinen påbörjades.

Igår fick jag ett mejl från Fortinet-supporten — de har öppnat en bugg 615586 för mitt ärende. Jag vet inte om jag ska vara glad eller ledsen: å ena sidan — problemet ligger inte i inställningarna, å andra sidan — fixen kommer bara med nästa firmware-uppdatering, i bästa fall nästa. Mitt ego får också en extra boost av en annan bugg som jag identifierade förra månaden, dock vid HTML5 GUI vSphere. Det är verkligen som en lokal QA-avdelning hos leverantörer...

Jag vågar göra följande antagande:

1 — multicast-kontrollplanet kommer förmodligen inte att vara utsatt för det beskrivna problemet — eftersom MAC-adresserna för VTEP fårs från gruppens IP-adress som gränssnittet är prenumererat på.

2 — förmodligen ligger felet hos Fortigate i avlastningen av sessioner till Network Processor (ungefär som CEF) — om varje paket passerar genom CPU:n, kommer de att använda tabeller som innehåller korrekt — i alla fall visuellt — information. Det stöder detta antagande att det hjälper att stänga/öppna gränssnittet eller vänta en stund — mer än 5 minuter.

3 — att ändra teaming-policy, till exempel till explicit failover, eller att införa LAG kommer inte att lösa problemet, eftersom det har observerats "fastna" MAC-adressen för den ursprungliga hypervisorn i inkapslade paket.

I detta ljus kan jag dela med mig av att jag nyligen har upptäckt bloggen, där en av artiklarna påstod att stateful brandväggar och cachade dataöverföringsmetoder är tillfälliga lösningar. Tja, jag är inte tillräckligt erfaren inom IT för att påstå något sådant, dessutom håller jag inte alltid med om påståendena i blogginläggen. Men något säger mig att det finns en del sanning i Ivans ord.

Tack för uppmärksamheten! Jag ser fram emot att svara på frågor och höra konstruktiv kritik.

Källa: habr.com