NSX hardware vtep

 ( VincentV | 2018. április 13., péntek - 22:18 )

NSX-et tanulgatok egy ideje, szeretném a hw vtep featuret is kipróbálni a laborban amit összeraktam. Ciscohoz és Juniperhez nagyon jó doksik vannak (gyártói, és community dolgok is), viszont sajnos engem egy HPE 5930-al ver a sors, amihez meg kb. semmi nincs. VMware és HP compatibility guide-ok szerint jó vagyok, tud az eszköz vxlan tunnelt, ovsdb-t, és kifejezetten NSX certified. A neten kutatva egyetlen HP doksit leltem fel a témában, de az csak az 5930-ak közötti vxlan tunnelingre ad valamiféle referenciát, illetve példákat, szinte magyarázat nélkül. Ezzel el tudtam indulni, de kevés az üdvösséghez sajnos.

Odáig szeretnék minimum eljutni, hogy felépüljön az nsx controller cluster és a switch között a vxlan tunnel, illetve a switch oldalon tudjak egy meghatározott vni-t kibontani, majd egy access portra map-elni, a rajta lógó fizikai gépet pedig ezen L2 hálózat vm-jeiről elérni.

Foglalkozott már valaki ilyen, vagy hasonló Comware alapú switchekkel és NSX-el? Szívesen látnék switch oldali példaconfigot, vagy egyéb iránymutatást.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Az első szériában gyártott aluminiumkasztnis autó. Senna tesztelte, szerette.

> Sol omnibus lucet.

Értem célzást, de remélem a hálózatok topicban nem kell magyarázni, hogy nem az autóra gondolok, hanem egy piacvezető SDN megoldásra :) Akiknek mégis, azok meg vélhetően nem fognak tudni válaszolni a kérdésre.

Szerintem a H3C vagyis HP switchre gondolt.

A GP-nal próbálkoztal már? Ezt már rég meg kellett volna oldani.

Öööö, ez?

https://kb.vmware.com/s/article/2146574

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Igen, ebben van egy általános vxlan guide HP-HP eszközök közötti kapcsolatokhoz, erre írtam, hogy el tudtam vele indulni, de az nsx-hp vtep tunnel nem áll össze.

Egyébként ma találtam ezt (jól el volt dugva):

https://support.hpe.com/hpsc/doc/public/display?docId=mmr_sf-EN_US000021071&docLocale=en_US

Valamivel jobb, de nálam hiányzik pár pki command, szóval majd nézek a switchez R26xx-es sw-t, hátha.

Szerk.: esélyes hogy ez a gond, NSX 6.3 óta TLS 1.2 engedélyezett csak, azt meg nem tudja a switch a jelenlegi (R24xx) sw-vel.

Allitolag IRF stackelt switchekkel problemas (azert irjak a comp.matrixaban a standalone topologiat), reszben emiatt mi meg meg se probaltuk...

Úgy néz ki siker. A újabb comware sw (R2609) megoldotta a problémát.

Mivel elobb-utobb mi is szeretnenk kiprobalni, ezert legyszi linkeld ide a hasznosnak talalt doksikat.
Koszi szepen!

Egyelőre csak a fenti két doksim van HPE 5930 vonatkozásban. Ti milyen eszközökkel fogjátok használni? A Cisco/Juniperes dolgokat nem mentettem el, mert nekem most (sajnos) nem szükséges, viszont azokat könnyen meg fogod találni.

Egyébként még nem vagyok teljesen sínen, egyelőre nem tudtam a HP-n portra/vlanra vxlant mapelni, de legalább az NSX-ben már látom a switchet mint hw vtep.

Szerk: sikerült :) Nagyon benéztem. Rohadtul figyelni kell rá, hogy mikor milyen IP-ket és subneteket ad meg az ember. Az NSX controller cluster ugye két komponensű (NSX controller appliance vm-ek és esxi kernel modulok), mindkettőnek külön IP-je van értelemszerűen.

A fizikai switchen az osvdb kapcsolatot az appliancekre kell létrehozni. Miután ez összeáll, az ovsdb meg fogja mondani a switchnek, hogy hová is kell felépíteni a vxlan tunneleket (a hostokra). Viszont ha a switchnek nincs IP-je ebben a másik szegmensben, akkor ugye a data plane nem fog működni. Ráadásul HP-nél (de nyilván mindenhol) kell hozzá egy ilyen is:

tunnel global source-address 1.2.3.4

Ahol az 1.2.3.4 az esxi hostok nsx kernel moduljának, pontosabban a hozzá tartozó vmk interfacenek a szegmensében kell hogy legyen.

Azt hiszem kicsit túlbonyolítottam, mert ez a két szegmens lehetett volna egy, és akkor nincs ez a probléma. Én valamiért kézenfekvőnek láttam, ha az applianceket az esxi hostok meglevő management networkjébe deployolom, ami viszont egy standard vswitch. Az NSX kernelmodul vmk nic-jei viszont csak dvs-en lehetnek, így hát oda tettem őket, ezért lett két eltérő subnet. Szóval érdemes erre figyelni, ez, és a jól dokumentált HP switch kombinációja elvitte pár napomat :)

Nalunk HPE 5940 es Dell Z9100-ek vannak.

Szerintem az termeszetes, hogy az NSX controllerek management IPje (control plane) nem azonos szegmensben van a VTEP interface-ekkel (data plane).

Nem olvastam meg utana, de a HW VTEP redundaciaja hogy van megoldva? Stackelt switcheknek van egy kozos VTEP cimuk, vagy minden switchnek sajat VTEP es vmi alapjan loadbalancolja a forgalmat?

Így van, csak ez egy egyszerű labor (3db host, 1db switch), és nem tudatosan állítottam be, később pedig elfelejtettem :)

Hw vtep redundanciát én is csak érintőlegesen néztem meg (doksikban, és tanfolyami anyagban), a gyakorlatban nem próbáltam. A VMware azt mondja, hogy úgy biztosítsd a redundanciát "egy" TOR switch esetén pl., hogy több switchet alkalmazz, és ezeket 1db logikai vtep gw-ként add oda a hypervisornak. Ehhez használj bármit ami szimpi, vagy amit a gyártó ajánl/támogat (pl. lacp, mlag, vpc) az NSX-nek mindegy.