Szembesültem a fenti kérdéssel és gondoltam érdemes kicsit körüljárni a témát. Sok-sok cikk elérhető a témában, de néha nehéz azt a saját esetükre lefordítani.
Az NSX-T világában – és innentől NSX néven hívom minden cikkben, mivel az NSX-V végre valahára end of support lett – a T0 egy különös elem. Nélküle az overlay hálózat nem igazán elérhető befelé, sem az abban lévő virtuális gépek nem érik el a külvilágot. A szerepe így nyilvánvaló, a virtuális és a fizikai hálózat határát jelenti az NSX szempontjából.
Mint az ismert, a T0 két komponensből áll – ahogyan a T1 is – az SR és a DR komponensből. A SR a stateful szolgáltatásokat, a DR az elosztottakat valósítja meg. Az SR komponens központosított az Edge Node-ban/okban.
Az összerendelés a kérdéses, mármint egy Edge Node-ban csak egy T0 entitás lehet, egy Edge Node csak egy Edge Cluster tagja lehet és egy T0 csak egy Edge Cluster-ben realizálható. A fenti példában tehát az a két Edge Node például lehet egy Edge Cluster tagja – nem kötelezően – ezzel biztosítva a redundanciát és ha igény van rá, akkor az aktív-aktív működést is.
Logikailag ez a következő módon néz ki. A T0-nak van két uplink-je, két különböző VLAN-ban.
Az Edge Node és az ESXi oldaláról ez így képzelhető el.
Azt gondolom a fenti képen már látszik is a probléma. Egy Edge VM redundánsan csak két port group-hoz csatlakozhat. Egy port group pedig használ X darab fizikai interfészt. Tehát ha vmnic0 és vmnic1 is mondjuk 10 Gbit-en van bekötve a ToR switch-ekbe és a két VLAN-ban ECMP-zünk, akkor 2x10Gbit sávszélesség érhető el. Ha a T0-k is ECMP-ben vannak és az Edge VM-ek nem futnak azonos hoszton – javasolt hogy ne fussanak 🙂 – akkor 4 x 10Gbit az észak-déli kapacitás.
Milyen opciók vannak tehát, hogy több irányba is legyen routing?
- kell egy – de inkább kettő – új uplink VLAN
- kell egy másik peer
- kell még egy – de inkább kettő – Edge Node és egy új T0
- VRF lite
Midegyik megoldás működhet, de kicsit vesézzük ki őket.
Kell egy – de inkább kettő – új uplink VLAN
A trunk interfészeken és port group-okon beviszünk a már létező Edge Node-okba egy-két új VLAN-t és a T0-n felvesszük őket mint uplink interfész és felhasználva őket egy/két új peer-t.
Mit érünk el ezzel? Fizikailag továbbra is azonos interfészeken megy ki a forgalom az ESXi kiszolgálókból – ahol az Edge VM-ek futnak – és egy kábel csak egy helyre lehet bedugva. Az OCD-t nem trigger-elni, de értelme túl sok nincs.
Kell egy másik peer
Majdnem azonos az előzővel, csak az újabb peer/peer-ek nem egy újabb VLAN-ban érhetőek el, hanem a már használtakban. Itt csak annyi történik, hogy mint neighbor, felveszünk egy/több eszközt és bizonyos forgalmakat az irányába továbbítunk. Ettől még azonos trönkön, azonos fizikai portokat használunk csak a T0-ból felfelé a céltól függően más a next hop, viszont még az uplink VLAN-ok is azonosak.
Kell még egy – de inkább kettő – Edge Node, egy új T0 és egy/két uplink VLAN
A egy/két uplink VLAN magától értetődik – bár nem kötelező. Az egy/két Edge Node pedig azért kell, mert egy Edge Node-ban csak egy T0 lehet, olyan pedig már van a létező Edge Node-okban. Ha itt tartunk, akkor létre lehet hozni egy/két új port group-ot is, amelyek vagy azonos vDS-en vagy egy új vDS-en vannak és természetesen saját fizikai interfészeket használnak. Ekkor már látható az, hogy az Edge VM-et futtató ESXi kiszolgálóból is már külön interfészen jön ki az uplink irányú forgalom, a T0-tól függően. Ebben az esetben nyilvánvalóan 2 x (2 x (2 x 10Gbit)) sávszélességet kaphatunk a teljes rendszerre nézve. Ha többszörözzük az Edge VM-eket, akkor pedig nyilván ennek sokszorosa érhető el, de így volt ez az előző esetben. Amit itt nyerünk, az ténylegesen az, hogy már a fizikai rétegben is szét lehet választani a forgalmakat és itt már megvalósul az, hogy például a zöld és a lila szegmens forgalma a külső eszközöket is megjárja.
VRF – korábbi nevén VRF lite
Mielőtt belekezdek, fontos, hogy az előbbi esetet nem tudja kiváltani. Azért nem képes rá mert nem biztosít fizikai szeparációt, csak logikait. Sávszélességben nem tud segíteni, ahogy azt sem teljesíti, ha valaki biztonsági szempont miatt szeretné szeparálni.
Amit tud az tulajdonképpen a két korábbi megoldás hibridje. Létre tudunk hozni egy kvázi T0-t, amihez T1-et/eket is tudunk kapcsolni, ezáltal adott szegmensek logikailag más kommunikációs útvonalon érhetőek el befelé és forgalmaznak kifelé, északi irányba.
Vannak megkötések és lehetőségek, amiket nem árt ismerni:
- csak T0-hoz kapcsolható
- a VRF saját routing és forwarding-al rendelkezik – függetlenül a többi VRF-től és nyilván a T0-tól is
- szegmensek kapcsolhatók hozzá, de nyilván T1 is
- két VRF vagy a VRF és a “mellette” lévő T0 között IS a külső eszközön történik az útválasztás. Fel lehet venni őket peer-ként, illetve lehet VRF leaking-et is használni, így ez biznyos esetekben elkerülhető
- VLAN tag használata nyilvánvalóan szükséges az uplink vlan-ban/vlan-okban
- örököl sok beállítást a T0-tól (HA mode, nyilván az Edge Cluster maga, BGP kapcsán pár érték (AS számot, graceful restart beállításokat stb.)
A VRF létrehozásakor az első lépésben meg kell adni mely T0-hoz kapcsolódjon. Ez természetesen automatikusan kitölti az Edge Cluster mezőt is. Látszik, hogy a HA mode az szintén örökölt, nem lehet átállítani csak a VRF-re.
Az interfészek hozzáadását lényegében az uplink irányba létrehozott VLAN-ok és azokat reprezentáló VLAN backed szegmensek és IP-címek jelentik.
A routing-ban van néha félreértés, mert csak azért mert a “rendes” T0-ban mondjuk BGP-t használunk, attól a VRF-ben még nem kötelező szintén BGP-t konfigurálni. A VRF-ben lehet statikus routing, viszont olyan nem lehetséges, hogy a rendes T0-ban BGP-t konfiguráltunk, de a VRF-ben OSPF-et.
Ha multitier a kívánt kiépítés akkor a T1-et simán lehet csatolni az előbb létrehozott kvázi T0-hoz
Logikailag az alábbi képen látható. Ha a zöld szegmensből egy virtuális gép szeretne a lila szegmensben lévő géppel kommunikálni, akkor az ilyen forgalom mindenképpen megjárja a külső eszközöket is, az alábbi példában egy külső router-t.
Van-e értelme? Igen. Ha egy T0-nak több peer-je van, akkor az izoláció igazából csak a DFW/GW tűzfalak által lehetséges NSX-ben, mivel bármely szegmens ami olyan T1-hez/T1-ekhez van kapcsolva, ami azonos T0-t használ, képes lehet forgalmazni az összes irányba, amit a T0 ismer. Logikailag ez csak a VRF lite-tal lehet eválasztani, de ez tényleg csak izolációt jelent, attól még a sávszélesség továbbra is megosztott a T0 és a hozzá kapcsolt egy vagy több VRF között.
Egy szó mint száz, ha már az ESXi-ből kifelé néző fizikai interfészeken is dedikálni/izolálni akarjuk a kívánt forgalmat, akkor a harmadik opció a megoldás. Ha nincs rá szükség, akkor én a VRF opciót választanám, az átláthatóság kedvéért és alapvetően ha már kell egy új T0 – kvázi T0 – akkor ott könnyen lehet, hogy a kötöttségei nem elfogadhatók és a végén azonos interfészeken, de több edge node-dal és rendes T0-val végezzük.
