Hei, og fĂžrst litt lyrikk. Jeg misunner noen ganger kolleger som jobber eksternt â for det er fantastisk Ă„ kunne jobbe fra hvor som helst i en internett-tilkoblet verden, ta ferie nĂ„r som helst, ta ansvar for prosjekter og frister, i stedet for Ă„ vĂŠre pĂ„ kontoret fra 8 til 17. Min posisjon og arbeidsoppgaver utelukker nesten muligheten for langvarig fravĂŠr fra datasenteret. Men - av og til skjer det interessante saker, som beskrevet nedenfor - og jeg innser at det finnes fĂ„ posisjoner hvor det er sĂ„ mye rom for kreativt uttrykk fra en intern troubleshooter.
En liten disclaimere - pĂ„ tidspunktet for skrivingen av artikkelen er saken fortsatt ikke lĂžst, men med tanke pĂ„ responstiden fra leverandĂžrene, kan det ta mĂ„neder fĂžr det er helt lĂžst, og jeg Ăžnsker Ă„ dele mine funn allerede nĂ„. Jeg hĂ„per, kjĂŠre lesere, at dere tilgir meg for denne hastverket. Men nok med vann â hva er status pĂ„ saken?
FĂžrst litt bakgrunn: det er et selskap (hvor jeg jobber som nettverksingeniĂžr) som hoster kundelĂžsninger i en privat sky pĂ„ VMWare. De fleste nye lĂžsninger kobles til VXLAN-segmenter, som styres av NSX-V - jeg vil ikke vurdere hvor mye tid denne lĂžsningen har gitt meg, men kort sagt â mye. Jeg har til og med klart Ă„ lĂŠre opp kolleger i konfigurasjonen av NSX ESG, og smĂ„ kundelĂžsninger settes opp uten min deltakelse. Viktig Ă„ merke seg - kontrollplanet vĂ„rt har unicast-replikering. Hypervisorene er koblet redundant via to grensesnitt til forskjellige fysiske Juniper QFX5100 svitsjer (satt sammen i Virtual Chassis) og med en rute-policy basert pĂ„ opprinnelig virtuell port â dette for Ă„ fĂ„ helhetsbildet.
Kundens lÞsninger er svÊrt varierte: fra Windows IIS, hvor alle komponentene for webserveren er installert pÄ én maskin, til ganske store - for eksempel lastbalanserte Apache web-fronter + LB MariaDB i Galera + delte servere synkronisert med GlusterFS. Praktisk talt hver server mÄ overvÄkes separat, og offentlige adresser er ikke tilgjengelige for alle komponenter - hvis du har stÞtt pÄ denne oppgaven og har mer elegante lÞsninger, vil jeg gjerne hÞre rÄd.
Mine overvĂ„kningslĂžsning gĂ„r ut pĂ„ Ă„ «koble til» brannmuren (Fortigate) til hvert internt kundnettverk (+SNAT og selvsagt strenge begrensninger pĂ„ type tillatt trafikk) og overvĂ„ke interne adresser â slik oppnĂ„s en form for enhetlighet og forenkling av overvĂ„kningen. Selve overvĂ„kningen skjer fra en klynge av PRTG-servere. OvervĂ„kningsskjemaet er omtrent slik:
SĂ„ lenge vi bare jobbet med VLAN, fungerte alt ganske normalt og forutsigbart, som et klokkeverk. Etter implementeringen av NSX-V og VXLAN stĂžtte vi pĂ„ spĂžrsmĂ„let â kan vi fortsette overvĂ„kningen som fĂžr? PĂ„ dette tidspunktet var den «raskeste» lĂžsningen Ă„ sette opp NSX ESG og koble VXLAN trunk-grensesnittet til VTEP-nettverket. Rask i anfĂžrselstegn â ettersom bruken av GUI for Ă„ konfigurere kundnettverk, SNAT og brannmurregler kan forene administrasjonen i det samme grensesnittet i vSphere, men etter min mening er det ganske klĂžnete og begrenser dessuten verktĂžyene for feilsĂžking. De som har brukt NSX ESG som en erstatning for en «ekte» brannmur, tror jeg vil vĂŠre enige. Selv om det kanskje ville vĂŠrt en mer stabil lĂžsning â for alt skjer innenfor en enkelt leverandĂžr.
En annen lĂžsning er Ă„ bruke NSX DLR i bro-modus mellom VLAN og VXLAN. Her tror jeg det er ganske klart â man mister enkelt gevinsten ved Ă„ bruke VXLAN, for i sĂ„ fall mĂ„ man fortsatt trekke VLAN til overvĂ„kningsinstallasjonen. For Ăžvrig stĂžtte jeg pĂ„ et problem i prosessen med Ă„ implementere denne lĂžsningen, hvor DLR-broen ikke sendte pakker til den virtuelle maskinen som den befant seg pĂ„ samme vert som. Jeg vet, jeg vet â i bĂžker og guider om NSX-V stĂ„r det klart at NSX Edge mĂ„ tildeles en egen klynge, men det er i bĂžkene... Uansett, etter et par mĂ„neder med support klarte vi ikke Ă„ lĂžse problemet. Generelt forsto jeg logikken i handlingsforlĂžpet â kjernemodulen til hypervisoren, ansvarlig for innkapslingen av VXLAN, ble ikke aktivert hvis DLR og den overvĂ„kede serveren befant seg pĂ„ samme vert, ettersom trafikken ikke forlot verten og logisk sett burde vĂŠrt koblet til VXLAN-segmentet â innkapsling er ikke nĂždvendig. Sammen med support fokuserte vi pĂ„ den virtuelle grensesnittet vdrPort, som logisk sammenfĂžyer uplinks og som ogsĂ„ utfĂžrer broing/innkapsling â der ble det observert en uoverensstemmelse i den inngĂ„ende trafikken, som jeg tok med meg for behandling i den aktuelle saken. Men som nevnt, jeg fullfĂžrte ikke denne saken, da jeg ble overfĂžrt til et annet prosjekt, og denne grenen var opprinnelig en blindvei, sĂ„ det var ikke mye lyst til Ă„ utvikle den. Hvis jeg ikke tar feil, ble problemet observert i versjoner NSX 6.1.4 og 6.2.
Og her â bingo! Fortinet annonserer innebygd . Og ikke bare point-to-point eller VXLAN-over-IPSec, ikke programvarebroing VLAN-VXLAN â alt dette begynte de Ă„ implementere allerede fra versjon 5.4 (og er representert hos andre ), og den faktiske stĂžtten til unicast control plane. Da jeg implementerte lĂžsningen, mĂžtte jeg et annet problem â de overvĂ„kede serverne «forsvant» og dukket opp igjen i overvĂ„kingen, selv om selve virtuelle maskinen var oppe. Ă rsaken viste seg Ă„ vĂŠre at jeg glemte Ă„ tillate Ping pĂ„ VXLAN-grensesnittet. I prosessen med Ă„ rebalansering av klynger, ble de virtuelle maskinene flyttet, og Ping avsluttet vMotion, for Ă„ indikere den nye ESXI-vert som maskinen hadde blitt flyttet til. Det var dumt av meg, men dette problemet undergravde igjen tilliten til stĂžtten fra produsenten â i dette tilfellet Fortinet. Jeg nevner ikke engang at hver sak relatert til VXLAN begynner med spĂžrsmĂ„let «hvor har du innstillingene for programvaredisken VLAN-VXLAN?» Denne gangen ble jeg rĂ„det til Ă„ endre MTU â det gjelder Ping, som er 32 byte. Deretter «lek med» tcp-send-mss og tcp-receive-mss i policy â for VXLAN som er kapslet i UDP. Uf, beklager â det har bygget seg opp. Uansett, dette problemet lĂžste jeg med egne krefter.
Etter Ă„ ha testet trafikken, ble det bestemt at denne lĂžsningen skulle implementeres. Og i produksjon viste det seg at etter en dag eller to, begynte alt som ble overvĂ„ket gjennom VXLAN gradvis Ă„ falle bort. Deaktivering/aktivering av grensesnittet hjalp, men bare for en periode. Med tanke pĂ„ den trege stĂžtten fra produsenten, tok jeg fatt pĂ„ feilsĂžking pĂ„ min side â tross alt, mitt selskap, mitt nettverk â mitt ansvar.
Under spoileren finnes fremdriften av feilsĂžkingen. De som er lei av bokstaver og skryting â hopp over og gĂ„ til etteranalysen.
Fremdrift av feilsĂžkingenTakk for at du fortsatte Ă„ lese â la oss fortsette!
SĂ„, overvĂ„kingen fungerer en stund, fĂžr den faller bort av seg selv. Det betyr at det sannsynligvis ikke er noe problem med brannmurpolitikkene. Men, siden jeg har stĂžtt pĂ„ problemet med hengende systemprosesser i Fortigate versjoner 5.6+, ser vi fĂžrst pĂ„ «diagnose debug flow» â som forventet blir trafikken tillatt og gĂ„r ut av grensesnittet, mens ingenting kommer tilbake. SĂ„ vi graver videre nedover i stakken. Jeg mĂ„ dessverre skjule adresser, selv om det er RFC1918, men jeg hĂ„per Ă„ sĂžrge for tilstrekkelig beskrivelse for forstĂ„else. Serveren inne i VXLAN har adressen x.x.x.15, Fortigate-grensesnittet er x.x.x.254, alle andre adresser tilhĂžrer VTEP-nettverket.
For the successful transmission of VXLAN-encapsulated packets, correct information must be available in several tables. For overlay, this is ARP and OVSDB; for underlay, ARP and CAM. In the case of Fortigate, the VXLAN FDB is OVSDB. Thatâs where we will start:
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
It's quite simple here â the virtual machine's MAC address must be on the VTEP with the address Ń.Ń.Ń.47. After reviewing the contents and settings of the ESXI cluster, I find that the virtual machine's MAC is correct, and the VTEP address is also correct. I check the CAM/ARP table on the Fortigate â again, everything matches the settings of the ESXI host:
fortigate (root) #get sys arp | grep Ń.Ń.Ń.47
Ń.Ń.Ń.47 0 00:50:56:65:f6:2c dmz
The tables are correct and the traffic is passing â could the issue be not on the Fortigate? I intentionally skipped analyzing the traffic switching on the Juniper â logically, it should be the next troubleshooting step there, but my network is simple â just one VLAN for VTEP with all components directly connected. Plus, I remember a case with a DLR bridge, VDR, and disappearing traffic â Iâm going to sniff on the ESXI host and simultaneously create a case with VMWare. Below, the MAC "97:6e" belongs to Fortigate, vmnic1 â this is the interface that has the VTEP with the address Ń.Ń.Ń.47, sniffing in both directions "âdir 2":
pktcap-uw --uplink vmnic1 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
Progress â in the sniff, I see an ARP request and the incoming response. Iâm only providing the ARP response and everything is correct there. I didnât mention that throughout this time the monitoring server is pinging the address Ń
.Ń
.Ń
.15 â where is the ICMP traffic? I remember that I have two uplinks. One might argue that the virtual source port is the same (my teaming policy), meaning the same uplink should be selected for the same vNIC, but since Iâm on the host, checking the other uplink is not a problem:
pktcap-uw --uplink vmnic4 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
Det kommer forespĂžrselar frĂ„ Fortigate, men det kjem ingen svar. AltsĂ„, problemet ligg ikkje hos Fortigate. Vel, tenker eg â det er igjen det same problemet med tapt trafikk pĂ„ VDR, igjen nokre mĂ„nader med Ă„ leite opp saken. Etter nokre dagar, nĂ„r eg har roe meg ned, og ikkje vil godta det hengande, bestemte eg meg for Ă„ samle fleire sniffar for supportteamet, for Ă„ fĂ„ prosessen til Ă„ gĂ„ raskare. Og her «tilfeldigvis» falt blikket mitt pĂ„ Ethernet-kapsling underlay. Kongen er ikkje ekte, og MAC-adressa til VTEP samsvarer ikkje med IP-en hans. Eg nullstiller, sniffer, graver â det er rett at det ikkje er rett. Eg legg ved ARP-tabellen slik at det er enklare Ă„ samanlikne. VĂŠr merksam pĂ„ den fĂžrste Ethernet-kapslinga pĂ„ bildet ovanfor:
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Ă„, kva har vi til slutt â etter migrering av den virtuelle maskinen, prĂžver Fortigate Ă„ sende trafikk til VTEP frĂ„ (korrekte) VXLAN FDB, men bruker feil DST MAC, og trafikken vert forventa avvist av grensesnittet i hypervisoren som mottar den. I eitt av fire tilfeller hĂžyrde denne MAC-en til den opprinnelege hypervisoren som vi starta migreringa frĂ„.
I gĂ„r fekk eg ei e-post frĂ„ Fortinet si tekniske stĂžtte â dei har opna ein feil i mitt case, 615586. Eg veit verkeleg ikkje om eg skal vere glad eller trist: pĂ„ den eine sida â problemet ligg ikkje i innstillingane, pĂ„ den andre â fixen kjem fĂžrst med ein firmware-oppgradering, i beste fall neste gong. Eg har ogsĂ„ funne ei anna feil som held pĂ„ Ă„ varme opp egoet mitt, som eg oppdaga i forrige mĂ„nad, denne gongen i HTML5 GUI vSphere. Verkeleg som eit lokalt QA-team for leverandĂžrarâŠ
Eg vil tĂžrre Ă„ anta fĂžlgjande:
1 â multicast control plane vil mest sannsynleg ikkje vere utsett for det beskrevne problemet â sidan MAC-adressene til VTEP blir henta frĂ„ IP-adressa til gruppa som grensesnittet er abonnera pĂ„.
2 â det er sannsynleg at problemet til Fortigate ligg i offloadinga av sesjonar til Network Processor (tilsvarande CEF) â dersom kvart pakke blir sendt gjennom CPU, vil tabellene som inneheld korrekt â i alle fall visuelt â informasjon bli brukt. Det stĂžttar denne antagelsen at det hjelper Ă„ lukke/opne grensesnittet eller Ă„ vente ei lita stund â meir enn 5 minutt.
3 â endring av teaming policy, til dĂžmes til explicit failover, eller innfĂžring av LAG vil ikkje lĂžysa problemet, sidan det har vore observert «hefting» av MAC-adressa til den opprinnelege hypervisoren i innkapsla pakkar.
I lys av dette kan eg dele at eg nyleg har oppdaga , hvor det i en af artiklerne blev hÊvdet, at stateful firewalls og cacheable dataoverfÞrselsmetoder er en slags nÞdlÞsninger. NÄ, jeg er ikke sÄ erfaren inden for IT, at jeg vil gÞre sÄdanne pÄstande, og jeg er heller ikke straks enig i alle pÄstande fra blogartiklerne. Men noget fortÊller mig, at der er en portion sandhed i Ivans ord.
Tak for opmÊrksomheden! Jeg ser frem til at besvare spÞrgsmÄl og hÞre konstruktiv kritik.
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish