A bit of decomposition would be in order here IMHO.
The network isolation of internal vcdni-backed networks (whether they are connected to an external nw or not is irrelevant here) is achieved by Vmware's 0x80de ethertype (erstwhile Akimbi) - which is fine by all means and I understand less of interest for folks dismissive of the physcial network side of the actual solution (after all one will still need a real physical infra to back it all up - no ESX server will be hooked up to internet edge as some of the diagrams are suggesting)-
If one was to verify connectivity problems "outside" the vCD/vCenter perimeter it'd be good to understand a bit of "traditional" networking as well . So FWIW - underneath just an excerpt on how we "isolate" a VCDNI backed org network - > vlan 20 from the external interface represented by vlan 100 (also not the OUI for these mac-addresses differ )- Note that i/f 2/1 is a regular dot1q trunk connected to one of the ESX nodes encapsed by vCD.
ae-n7k-3# sh mac address-table int eth 2/1
Legend:
age - seconds since last seen,+ - primary entry using vPC Peer-Link
VLAN MAC Address Type age Secure NTFY Ports
-
----
--
+
+--
++--
ae-n7k-3# sh mac address-table int eth 2/2
Legend:
age - seconds since last seen,+ - primary entry using vPC Peer-Link
VLAN MAC Address Type age Secure NTFY Ports
-
----
--
+
+--
++--
From a pure functionality pov I understand you'll shrug this off as overhead but just thought it'd be adequate to point this little aspect out in some more detail. If one were to capture a frame from vcdni network 20 - you'd notice the actual "real" 0050.65.xx.xx.xx belonging to the src/dst VM's - (see attached - but again , nothing shocking there)
Kind regards
Rik
