Pár hete kifakadtam azon, hogy mégis miért nincs új design guide az NSX-T-hez, mikor a 3.0 és a vSphere 7 házassága elég sok változást és lehetőséget is hozott. Imáim meghallgattattak, ki is adtak egy újat. Mielőtt azonban megnéznénk, több egyéb is érkezett:
NSX-T 3.0 Security Reference Guide (link)
Jó anyag, de az alábbi hibákat találtam, amelyet az 1.1-es kiadásban javítanak majd/javítottak.
Last two lines in the attached picture tells 11 and just below that 10 predefined roles.
Page 17 – I would amend Option 1 with the term „security focused design” as this was the name of this approach back in the time with NSX for vSphere.
Page 20 – „In the physical representation, both T0 and the T1 firewalls are on the Edge Transport Node. Thus the packed does not leave the Edge host until it has passed through T1 Gateway Firewall” This is true, but not always as active instance of the T1 can be elsewhere, so within an other Edge node and in that case the traffic will leave the T0 hosing Edge node and flow to the one hosting the active T1.
Page 32 – Flow 3 is in the text as example but picture talks about flow 2.
Page 34 – I’d iclude some lines about that the „applied to” can be configured at the section level also which is also important.
NSX-T 3.1 Multi-Location Design Guide (Federation + Multisite) (link)
Találtam benne pár hibát amit jeleztem nekik és javítottak. Elsősorban a 21-ik oldalon volt rossz a rajz, mivel a zöld szegmensnek nem volt aktív T0-ja, nem tudott volna kommunikálni északi irányba.
VMware® NSX-T Reference Design (link)
Végre valahára megérkezett és hogy tárgyalja-e a VDS-es részeket kicsit mélyebben? Igen!
A 204-ik oldalon egy rajzon megmutatja a javasolt módot 2 pNIC esetén – ami nem sokban tér el nyilván akkor ha peering VLAN-okat egy másik pár pNIC-en és ezáltal vDS-en hozzuk ki.
Itt a dokumentum így nyilatkozik:
Transport zone – one overlay and VLAN – consistent compared to three N-VDS design
where external VLANs have two specific VLAN transport zone due to unique N-VDS
per peering
◼ N-VDS-1(derived from matching transport zone name – both overlay and VLAN)
defined with dual uplinks that maps to unique vNICs, which maps to unique DVPG at
VDS – duality is maintained end-to-end
◼ N-VDS-1 carries multiple VLANs per vNIC – overlay and BGP peering
o The overlay VLAN must be same on both N-VDS uplink with source ID teaming
o BGP Peering VLAN is unique to each vNIC as it carries 1:1 mapping to ToR with
named teaming policy with only one active pNIC in its uplink profile
◼ VDS DVPG uplinks is active-standby (Failover Order teaming for the trunked DVPG) to
leverage faster convergence of TEP failover. The failure of either pNIC/ToR will force
the TEP IP (GARP) to register on alternate pNIC and TOR. This detection happens only
after BFD from N-VDS times out, however the mapping of TEP reachability is
maintained throughout the overlay and thus system wide update of TEP failure is avoided
(host and controller have a mapping or VNI to this Edge TEP), resulting into reduced
control plane update and better convergence. The BGP peering recovery is not needed as
alternate BGP peering is alive, the BGP peering over the failed pNIC will be timed out
based on either protocol timer or BFD detection.
Semmi újdonság, illetve azért mégis. Látszik, hogy amennyiben a vNIC2-n szakadás történik, legyen az kábel, TOR switch vagy bármi miatt, a TEP-IP-1 átkerül a vNIC3-ra. Az ábrán a VLAN 300-al azonosított uplink VLAN egy bábbá válik, tehát bár a vDS „Trunk DVPG-1” port group beállításai redundanciát adnak neki és biztosítják a P2 porton keresztüli kommunikációt, alapvetően el kell halnia a BGP-nek rajta. Nem is akarja azt, hogy abban a VLAN-ban megmaradjon a forwarding. Ezért is írja azt, hogy a TOR1-en az egyik uplink VLAN legyen csak ott, a TOR2-n pedig a másik.
Amit én hiányolok, hogy mi van akkor amikor nem a TOR switch-ekkel van peering, hanem azok csak layer 2-t adnak és egy másik eszköz(párral) történik a BGP kapcsolatok kiépítése. Akkor közel teljesen mindegy, hogy a TOR eszközökön csak az egyik vagy mindkét VLAN ott van-e, hiszen nem függ a TOR-on a peer IP-től.
A 7.3.2. pontban végre valahára beszél arról milyen „Teaming mode”-ok vannak, viszont ezt nem az collaped cluster esetén tárgyalja, csak mezei host transport-ok esetén, mikor az Edge VM valahol máshol fut. Én hiányolom ezt, ez volt az előző posztom legnagyobb kiváltója.
A single TEP vs multi TEP esetén egészen egyértelmű a bare metal mérések alapján:
Én azért a Dual TEP-et telepítem minden rendszerben Edge VM-ek esetén is, eddig is így tettem.
Összefoglaló
Ezzel a három dokumentummal szerintem most elég jól le van fedve a 3.X mit/hogyan/miért kérdések jó része, néhány hiányossággal, de arra vagyunk mi, az integrátoroknál dolgozó szakemberek.
A szabály változatlan: miután megépítetted, teszteld le elejétől a végéig.
