VXLAN NSX-V-s — lahendame underlay

Tere! Alustuseks natuke luulet. Kartan vahel oma kaugtööd tegevate kolleegide kadedust – see on ju imeline, et on võimalus töötada ükskõik millisest Interneti-ühendusega maailma nurgast, puhata igal ajal, kanda vastutust projektide ja tähtaegade eest, mitte viibida kontoris kell 8-17. Minu ametikoht ja tööülesanded praktiliselt välistavad pikaajalise puudumise andmekeskusest. Siiski – aeg-ajalt juhtuvad huvitavad juhtumid, nagu allpool kirjeldatud – ja ma saan aru, et on vähe ametikohti, kus on nii palju ruumi oma sisemise troubleshooter’i loova väljendamise jaoks.

Veidi sissejuhatust – artikli kirjutamise ajal ei ole juhtum täielikult lahendatud, kuid arvestades tarnijate vastuse kiirus, võib täielik lahendus võtta veel kuid, ja ma tahan jagada oma mõtteid juba praegu. Loodan, et austatud lugejad, te saateandeks mu kiirustamise. Aga nüüd, piisavalt juttu – mis on selle juhtumiga?

Esiteks, lühidalt: on olemas firma (kus ma töötan võrguinsenerina), mis majutab kliendilahendusi privaatsetes VMWare pilvedes. Enamik uusi lahendusi ühendatakse VXLAN-segmentidega, mida haldab NSX-V — ma ei hakka hindama, kui palju aega see lahendus mulle säästis, öeldes lühidalt — palju. Olen isegi suutnud õpetada kolleege NSX ESG seadistama ning väiksed kliendilahendused käivitatakse ilma minu osaluseta. Oluline märkida — meie control plane töötab unicast-replikeerimisega. Hüpperviisorid on ühendatud üleliigselt kaheliidesega erinevatesse füüsilistesse Juniper QFX5100 lülititesse (kokku pandud Virtuaalsesse Chassisse) ja marsruutimise poliitikas kasutatakse originating virtual port'i põhjal baseeruvat ajastust — selleks, et anda täielik ülevaade.

Kliendilahendused on väga erinevad: alates Windows IIS-st, kus kõik veebiserveri komponendid on ühel masinal, kuni üsna suurte lahendusteni — näiteks tasakaalustatud Apache veebifrontide + LB MariaDB Galera + failiserverite, mis on sünkroniseeritud GlusterFS abil. Praktikas tuleb iga serverit eraldi jälgida ning avalikke aadresse ei ole kõigil komponentidel — kui olete selle probleemiga silmitsi seisnud ja teil on elegantsem lahendus, oleksin tänulik nõuande eest.
Minu seirelahendus koosneb igas sisevõrgus (Fortigate'i tulemüüriga) „ühendamise“ protsessist (+SNAT ja muidugi rangest lubatud liikluse piiramisest) ning siseaadresside jälgimisest — nii saavutatakse teatud ühtsus ja seire lihtsustus. Seire toimub PRTG serveriklastri kaudu. Seire skeem on enam-vähem järgmine:

Kuni, kui tegelesime ainult VLAN-iga, töötas kõik täiesti tavaliselt ja ennustatult, just nagu kell. Pärast NSX-V ja VXLAN rakendamist tekkis küsimus – kas saame jälgimist jätkata vanaviisi? Selles etapis oli kõige "kiirem" lahendus NSX ESG käivitamine ja VXLAN trunk-interfääsi ühendamine VTEP-võrku. "Kiire" sisseükkega – kuna GUI kasutamine kliendisüsteemide, SNAT ja tulemüürireeglite seadistamiseks võib küll ühtlustada haldust ühes vSphere'i liideses, kuid minu arvates on see üsna kohmakas ja piirab tõrkeotsingu tööriistade kogumit. Need, kes on kasutanud NSX ESG-d kui asendust "päris" tulemüüri jaoks, arvan, et nõustuvad. Kuigi selline lahendus oleks võib-olla stabiilsem – sest kõik toimub ühe müüja raames.

Teine lahendus on kasutada NSX DLR-i sildrežiimis VLAN-i ja VXLAN-i vahel. Siin on kõik arusaadav — lihtsustatult kaob VXLAN-i kasutamise eelised, kuna tuleb ikkagi tuua VLAN jälgimisinstalleerimise juurde. Muide, selle lahenduse töötlemise käigus kohtusin probleemiga, kus DLR-sild ei saatnud pakette virtuaalmasinale, millega ta oli üksikul hostil. Ma tean, tean — NSX-V raamatutes ja juhendites öeldakse otse, et NSX Edge'ile peab olema eraldatud eraldi klaster, aga need on raamatud… Kuid igal juhul, pärast mõneaastast koostööd toega me probleemi ei lahendanud. Praktiliselt mõistsin tegevuse loogikat — hüperviisori südamike moodul, mis vastutab VXLAN-i kapseldamise eest, ei aktiveeritud, kui DLR ja jälgitav server asusid ühel hostil, kuna liiklus ei lahkunud hostist ja loogika kohaselt pidi olema ühendatud VXLAN-segmendiga — kapseldamine ei olnud vajalik. Toega lõpetasime virtuaalsel liidesel vdrPort, mis loogiliselt ühendab ülesülesande ja just see viib läbi sildamise/kapseldamise — seal märgati sissetulevas liikluses mittevastavust, mida ma võtsin käsitleda praeguses juhtumis. Kuid nagu öeldud, ei viinud ma seda juhtumit lõpuni, kuna mind suunati teisele projektile ja algne haru oli sisuliselt surnud ning ei olnud erilisi soove selle arendamiseks. Kui ma nüüd ei eksi, ilmnes probleem versioonides NSX ja 6.1.4 ja 6.2.

Ja siin — bingo! Fortinet kuulutab välja natiivse VXLANi toe. Ja mitte lihtsalt point-to-point või VXLAN-over-IPSec, mitte VLAN-VXLAN tarkvara sillamine — seda hakati rakendama juba versioonist 5.4 (ja see on esitatud ka teistel tootjatel), vaid tõeline unicast control plane'i toetus. Lahendust rakendades kokku puutusin veel ühe probleemiga — jälgitud serverid kadusid perioodiliselt jälgimisse ja ilmusid tagasi, kuigi virtuaalmasin elas. Põhjuseks selgus, et olin unustanud lubada Ping VXLAN-liidesel. Klastrite ümberjaotamise käigus liikusid virtuaalmasinad, ja Pinguga lõpetati vMotion, et tähistada uut ESXi hosti, kuhu masin kolis. Minu rumalus, aga see probleem õõnestas veel kord usaldust tootja, seekord Fortineti, toe vastu. Ma ei räägi juba sellest, et iga VXLANiga seotud juhtum algab küsimusega: „Kus on teie seadistustes softswitch VLAN-VXLAN?“ Seekord soovitati mul muuta MTU — see on Pingile, mis on 32 baiti. Siis „mängi“ tcp-send-mss ja tcp-receive-mss politsiaga — VXLANi jaoks, mis kapseldatakse UDP-s. Uuh, vabandage — on loobunud. Ühesõnaga, selle probleemi lahendasin oma jõududega.

Testliiklus edukalt tagasi võtmiseks otsustati see lahendus rakendada. Ja tootmises selgus, et pärast päeva-kahte hakkavad järk-järgult kaduma kõik, mis on VXLAN kaudu jälgitav. Liidese deaktiveerimine/aktiveerimine aitas, kuid ainult ajutiselt. Meeles pidades tootja toe aeglasust, hakkasin ise tõrkeotsingut tegema — lõpuks on minu ettevõte, minu lähivõrk — minu vastutus.

Tõrkeotsingu käik peidetud. Kes on tähetest ja üleolekust väsinud — jätke vahele ja liikuge postanalüüsile.

Tõrkeotsingu käikAitäh, et lugemist jätkasite — jätkame!

Nii, jälgimine töötab mõnda aega, siis lakkab see iseenesest toimimast. Seega on tulemüürü poliitikates tõenäoliselt probleeme. Kuid kuna olen kokku puutunud Fortigate versioonide 5.6+ probleemiga, kus süsteemiprotsessid hanguvad, vaatame kõigepealt "diagnose debug flow" — ootuspäraselt lubatakse liiklus ja see läheb liideselt välja ning ootuspäraselt ei tule midagi vastuseks. Seega kaevame edasi. Kahjuks tuleb peita adresse, olgu need isegi RFC1918, kuid loodan protsessi piisava kirjeldusega varustada, et mõista. Server VXLAN-i sees on aadress x.x.x.15, Fortigate'i liides x.x.x.254, kõik ülejäänud aadressid kuuluvad VTEP-võrku.

VXLAN-i kapseldatud pakettide edukaks edastamiseks on vajalik õige teave mitmetes tabelites. Overlay jaoks on see ARP ja OVSDB, underlay jaoks on see ARP ja CAM. Fortigate'i puhul on VXLAN FDB ja OVSDB üks ja sama. Seal alustame:

 fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=y.y.y.47 port=4789 vni=5008 ifindex=7

Siin on kõik üsna lihtne — virtuaalmasina MAC-aadress peab asuma VTEP-aadressil u.u.u.47. Vaadates ESXI klastrisse, leian, et virtuaalmasina MAC on õige, samuti VTEP-aadress. Kontrollin CAM/ARP tabelit Fortigate'is — kõik vastab ESXI hosti seadistustele:

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

Tabelid on õiged ja liiklus väljub — võib-olla probleem ei ole Fortigate'is? Olen tahtlikult jätnud välja liikluse vahepingutuse analüüsi Juniper'is — loogiliselt peaks järgmine tõrkeotsing käima seal, kuid minu võrk on lihtne — vaid üks VLAN VTEP jaoks ja kõik komponendid on otse ühendatud. Peale selle meenutan juhtumit DLR-silla, VDR ja kadunud liiklusega — lähen sniffima ESXI hostis, samal ajal loon juba juhtumi VMWare'ile. Allpool olev MAC „97:6e“ kuulub Fortigate'ile, vmnic1 — see on liides, mis omab VTEP-i aadressiga u.u.u.47, snifime mõlemas suunas "—dir 2":

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

Progress — näen sniffis ARP-päringu ja tuleva vastuse. Toon välja ainult ARP vastuse ja seal on kõik õige. Ma ei maininud, aga kogu selle aja server jälgib aadressi x.x.x.15 — kus on ICMP liiklus? Meenutan, et mul on kaks uplinki. Siin võib vaielda ja öelda, et virtuaalne allika port on sama (minu teaming policy), st sama vNIC jaoks peaks valima sama uplinki, kuid kuna ma olen hostis, ei ole probleemi kontrollida teist uplinki:

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

Fortigate'ilt tulevad päringud, aga vastust ei ole. Seega ei ole probleem Fortigate'is. No kõik — mõtlen ma — jälle see sama probleem kadunud liiklusega VDR-is, jälle paar kuud juhtumiga õigesse suunda suunata. Paari päeva pärast jahtun, ja mitte soovides lepida jääknavigatsiooniga, otsustasin koguda veel sniffing'uid support'ile, et protsessi kiirendada. Ja siis mu pilk „juhuslikult“ jääb Etherneti kapseldumisele underlay. Tõeline ei ole tõeline ja VTEP MAC-aadress ei ühti tema IP-ga. Nullin, sniffin, kaevan — tõesti, et ei ole õige. Toodan ARP-tabeli kõrvale, et oleks mugavam võrrelda. Pange tähele, et esimene Etherneti kapseldumine pildil ülal:

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

Seega, mis meil lõpuks on — pärast virtuaalmasina migreerimist proovib Fortigate suunata liiklust VTEP-ile (korrektse) VXLAN FDB-st, kuid kasutab vale DST MAC-i ja liiklus lükatakse ootuspäraselt tagasi hyperviisori vastuvõtva liidese poolt. Lisaks juhtus ühes neljast juhusest, et see MAC kuulus algsele hyperviisorile, millega masin migreeriti.

Eile sain Fortineti klienditoelt kirja — minu juhtumi puhul avati viga 615586. Ma ei tea, kas rõõmustada või kurvastada: ühelt poolt — probleem ei ole seadetes, teisest küljest — parandamine tuleb alles koos järgmise püsivara uuendusega. Minu enesetunne tõuseb samuti veel ühe vea tõttu, mille avastasin eelmisel kuul, kuigi seekord HTML5 GUI vSphere'is. Tõeliselt kohalik QA osakond tarnijatele...

Julgen oletada järgmist:

1 — multicast kontrollplaan ei ole tõenäoliselt kirjeldatud probleemile vastuvõtlik — MAC-aadressid VTEP-ile saadakse grupi IP-aadressist, millele liides on tellitud.

2 — tõenäoliselt on probleem Fortigate'i sessioonide väljalülitamisega Network Processor'is (umbes sarnane CEF-ile) — kui lasta iga pakett läbi CPU, kasutatakse tabeleid, mis sisaldavad õiget — väidetavalt visuaalselt — teavet. Selle oletuse toetuseks räägib see, et aitab liidest sulgeda/avaneda või oodata natuke aega — rohkem kui 5 minutit.

3 — teaming policy muutmine, näiteks explicit failover, või LAG rakendamine ei lahenda probleemi, kuna täheldati, et MAC jääb kinni lähte hüperviisoris inkapsuleeritud pakettides.

Selle valguses saan jagada, et avastasin hiljuti blogi, kus ühes artiklis väideti, et stateful tulemüürid ja vahemäluga andmete edastusmeetodid on toetavad lahendused. Noh, ma ei ole IT-s nii kogenud, et sellist asja väita, ja ma ei nõustu kohe kõigi artikli väidetega. Kuid midagi ütleb mulle, et Ivanil on oma sõnades tõde.

Aitäh tähelepanu eest! Olen rõõmus, kui saan vastata küsimustele ja kuulda konstruktiivset kriitikat.

Allikas: habr.com