Vmware Architecting Tenant Networking With NSX in VCD PDF

VMware vCloud® Architecture Toolkit™
for Service Providers
Arquitectura de redes
de tenant con VMware
NSX® en VMware
vCloud Director®
Versión 2.8
Agosto de 2017
Steve Dockar
Arquitectura de redes de tenant con VMware NSX en VMware vCloud Director
© 2017 VMware, Inc. Todos los derechos reservados. Este producto está protegido por las leyes de
propiedad intelectual y de copyright internacionales y de los Estados Unidos. Este producto está cubierto
por una o varias de las patentes que se detallan en http://www.vmware.com/download/patents.html.
VMware es una marca registrada o una marca comercial de VMware, Inc. en los Estados Unidos u otras
jurisdicciones. Todos los demás nombres y marcas mencionados aquípodrían ser marcas comerciales
de sus respectivas compañías.
VMware, Inc.
3401 Hillview Ave
Palo Alto, CA 94304
www.vmware.com
2 | VMware vCloud® Architecture Toolkit™ for Service Providers

Contenido
1 Introducción ......................................................................................... 6
1.1 Descripción general ............................................................................................................ 6
1.2 Objetivo y alcance del documento ...................................................................................... 6
1.3 Definiciones, acrónimos y abreviaturas .............................................................................. 7
2 Redes de clientes en un entorno de proveedor de servicios .............. 9

2.1 Topologías de red del cliente .............................................................................................. 9
2.2 Replicación de una topología de cliente de servicios administrados en vCloud Director....... 10
3 Estructura jerárquica en un proveedor de servicios de nube ............ 16

3.1 Estructura jerárquica de vCloud Director .......................................................................... 17
3.2 Topología de tenant básica de vCloud Director ................................................................ 19
3.3 Redes de estructura jerárquica ......................................................................................... 21
4 Capas de redes examinadas ............................................................ 23

4.1 Redes de tenant ................................................................................................................ 23
4.2 Redes del centro de datos de estructura jerárquica de vCloud Director en vSphere ...... 26
4.3 Redes en una topología de infraestructura de varios clústeres de hoja........................... 28
4.4 Redes de estructura jerárquica de vCloud Director en NSX ............................................ 29
5 Administración de direcciones IP y enrutamiento ............................. 31

5.1 Administración de direcciones del tenant ......................................................................... 31
5.2 Asignación de direcciones del cliente ............................................................................... 33
5.3 Administración de direcciones de Internet ........................................................................ 36
5.4 Subasignación de direcciones de red externa .................................................................. 38
5.5 Enrutamiento en un entorno de proveedor de servicios de estructura jerárquica ............ 40
5.6 Consideraciones sobre IPv6 ............................................................................................. 43
6 Consideraciones comerciales ........................................................... 44

6.1 Autoservicio o servicio administrado................................................................................. 44
6.2 Licencias de productos adicionales .................................................................................. 45
7 Referencias ....................................................................................... 47
Apéndice A: Aprovisionamiento de una red externa en vCloud Director ... 48

Lista de tablas
Tabla 1. Términos de jerarquía de VMware vCloud Director ...................................................................... 17
Tabla 2. Jerarquía y elementos de red de NSX y vSphere en vCloud Director ......................................... 29
Tabla 3. Apéndice A: Parámetros de configuración ................................................................................... 49
Lista de figuras
Figura 1. Ejemplo de topología de cliente de servicios administrados ....................................................... 11
Figura 2. Topología de cliente de proveedor de servicios de nube básica ................................................ 13
Figura 3. Microsegmentación con Distributed Firewall ............................................................................... 14
Figura 4. Topología básica de cliente con NSX Distributed Firewall .......................................................... 15
Figura 5. Ejemplo de topología de centro de datos de estructura jerárquica de servicios administrados ........ 16
Figura 6. Transición de software en capas de MSP a CSP en el programa VMware Cloud Provider ....... 17
Figura 7. Grupos de recursos y clústeres de vSphere del centro de datos del proveedor de servicios .... 18
Figura 8. Asignación de VDC de proveedor a recursos de vSphere .......................................................... 19
Figura 9. Topología de cliente básica de vCloud Director .......................................................................... 20
Figura 10. Administración de puertas de enlace Edge y redes de VDC de organización en vCloud
Director ...................................................................................................................................... 21
Figura 11. Administración de NSX Distributed Firewall en vCloud Director ............................................... 21
Figura 12. Ejemplo de topología de centro de datos de estructura jerárquica de un proveedor
servicios de nube ....................................................................................................................... 22
Figura 13. Redes de tenants de proveedor de servicios de nube .............................................................. 24
Figura 14. Redes de tenants de proveedor de servicios de nube .............................................................. 25
Figura 15. Redes de estructura jerárquica de proveedor de servicios de nube de vSphere ..................... 26
Figura 16. Configuración de un enlace troncal de VLAN para un grupo de puertos de vínculo
superior de dvSwitch ................................................................................................................. 27
Figura 17. Conexión con enlace troncal de varias redes externas a un entorno de vCloud Director ........ 28
Figura 18. NAT en la puerta de enlace de servicios Edge de VDC de organización ................................. 32
Figura 19. Mensaje de error provocado por aprovisionar un rango de direcciones superpuestas ............ 33
Figura 20. Asignación de direcciones de grupos de direcciones IP estáticas ............................................ 33
Figura 21. Configuración de grupo de direcciones IP estáticas de red de VDC de organización .............. 34
Figura 22. Habilitación del flujo de trabajo de redes mejorado................................................................... 34
Figura 23. Asignación estática-manual de direcciones .............................................................................. 34
Figura 24. Asignación de direcciones DHCP .............................................................................................. 35
Figura 25. Red externa de Internet de vCloud Director .............................................................................. 36
Figura 26. Traducción de direcciones salientes (SNA/PAT)....................................................................... 38
Figura 27. Asignación de direcciones IP de red externa ............................................................................ 39
Figura 28. Subasignación de direcciones de red externa........................................................................... 39

Figura 29. Enrutamiento de Internet del proveedor .................................................................................... 40

Figura 30. Red de VDC de organización de la DMZ enrutada ................................................................... 41
Figura 31. Emparejamiento del enrutador WAN por tenant........................................................................ 42
Figura 32. Administrar certificados en la puerta de enlace de servicios Edge ........................................... 44
Figura 33. Centro de datos de proveedores de servicios de nube con opciones de licencias por tenant........ 46
Figura 34. Agregar una red externa nueva ................................................................................................. 48

1 Introducción
1.1 Descripción general
El programa VMware Cloud Provider es un ecosistema de más de 4.000 proveedores de servicios en
más de 100 países que ofrecen servicios de nube basados en VMware. Los proveedores locales protegen
la soberanía de los datos y proporcionan una amplia gama de servicios de nube y experiencia en el
mercado vertical con conformidad y certificaciones especializadas.
Los proveedores de VMware Cloud tienen una capacidad única para prestar servicios en el mercado y
representan una extensión perfecta de los centros de datos en las instalaciones de los clientes empresariales
de VMware. Los proveedores de servicios administrados tradicionalmente operan centros de datos que
alojan varios tenants y desarrollan modelos de topología de referencia que ofrecen separación de
tenants y permiten al proveedor ofrecer servicios de valor agregado que requieren acceso a cada
entorno de tenant desde plataformas de administración comunes.
Una de las inquietudes iniciales al ofrecer una plataforma de estructura jerárquica mediante una solución
de administración superpuesta orientada al cliente, como VMware vCloud Director®, es comprender las
capacidades y restricciones de las soluciones del cliente que se pueden entregar y de la infraestructura
del proveedor de servicios que admitirá estas soluciones. Con la inclusión de VMware NSX® en versiones
posteriores de vCloud Director, aumentó la capacidad para crear topologías de cliente complejas, pero
también aumentaron las inquietudes que pueden surgir de manera justificable en torno a la implementación
de ambos productos en términos técnicos y operativos.
1.2 Objetivo y alcance del documento

En este documento, se analiza la forma en que pueden replicarse las topologías de cliente familiares en
la oferta de un proveedor de VMware Cloud con el uso de las capacidades de NSX, que se controlan
mediante vCloud Director. Aunque este documento se centra en la arquitectura de un entorno de
estructura jerárquica de un proveedor de servicios, empieza por la evolución de una topología de un
cliente de servicios administrados hacia la topología de un cliente de servicios de nube. Una vez
establecida una topología de cliente simple e ilustrativa, este documento analiza la forma en que se
implementa esa topología en la infraestructura subyacente y, a continuación, se ofrecen ejemplos de
topologías para separar varios clientes tanto del mundo virtualizado como del mundo del centro de datos
más grande y su conectividad externa.
Si bien vCloud Director requiere una configuración y un entorno de red compatibles propios para aprovisionar
cargas de trabajo informáticas, esas áreas están fuera del alcance de este documento. Por este motivo,
se da por sentado un grado de familiaridad con vCloud Director y NSX. Para obtener más información
sobre la arquitectura y el funcionamiento de una solución vCloud Director, consulte la sección 7,
Referencias. De forma similar, si bien la topología de la infraestructura de redes de acceso utilizada por
los proveedores de servicios para administrar cargas de trabajo, aplicaciones y servicios de tenants
sigue modelos similares a los analizados para las redes de clientes, los desafíos específicos de
proporcionar acceso de administración para redes de tenants están fuera del alcance de este documento.
Este documento está diseñado para ayudar a los arquitectos de la infraestructura de proveedores de
servicios que deben diseñar redes de tenants en el entorno del centro de datos. Su objetivo es también
ayudar a los arquitectos de soluciones de cliente de proveedores de servicios con el diseño de entornos
de cliente, previo o posterior a la venta, en un servicio de nube con tecnología vCloud Director.

1.3 Definiciones, acrónimos y abreviaturas

1.3.1 Definiciones
Cliente Cliente del proveedor de servicios; la organización que paga por el servicio y los
usuarios que utilizan el servicio.
Tenant Parte de la infraestructura que el cliente utiliza y de la cual obtiene servicios.
Red externa Una red que conecta al tenant de vCloud Director a la infraestructura de red del
centro de datos.
1.3.2 Acrónimos y abreviaturas
AS El sistema autónomo (Autonomous System, AS) es una recopilación de nodos de enrutamiento

dentro del mismo límite administrativo (consulte BGP).
BGP El protocolo de puerta de enlace de borde (Border Gateway Protocol, BGP) es un protocolo de
enrutamiento dinámico, utilizado en la red pública de Internet y en redes privadas de área
extensa. Puede utilizarse con un sistema autónomo único como protocolo interno (iBGP) y
entre sistemas autónomos (eBGP) de forma externa.
CE Edge del cliente (enrutador) (Customer Edge, CE) es un término utilizado para describir la
función de un enrutador de proveedor de servicios ubicado en el perímetro de la red del
proveedor y que se conecta a la red local en las instalaciones del cliente.
CSP Proveedor de servicios de nube (Cloud Service Provider, CSP) es el término utilizado para una
capacidad de proveedor de servicios que ofrece algunos o todos los atributos clave que deben
reconocerse como proveedores de un servicio de nube. Consulte el vínculo sobre la definición
de NIST de computación de nube en la sección 7, Referencias para obtener más información.
DHCP El protocolo de configuración dinámica de host (Dynamic Host Configuration Protocol, DHCP)
(rfc2131 y actualizaciones) es un protocolo que permite inicializar un host en una red basada
en una dirección IP sin una dirección IP configurada. Este protocolo establece un proceso para
que el host asuma una dirección temporal y solicite una dirección IP de una entidad local o
remota en la red a la que está conectado.
ECMP Múltiples rutas de igual coste (Equal Cost Multi-Path, ECMP) es un término de enrutamiento en
el que varias opciones de salto siguiente implican las mismas preferencias o el mismo “coste”,
lo cual permite distribuir tráfico entre varios vínculos o dispositivos para aumentar la resistencia
y el rendimiento de la red.
ESG La puerta de enlace de servicios VMware NSX Edge™, a veces denominada simplemente
“Edge”, o “puerta de enlace Edge” en vCloud Director, es un dispositivo virtual de redes y
seguridad que ofrece numerosos servicios. Consulte la sección 2.2.2, Topología de cliente de
proveedor de servicios de nube básica para obtener más información.
MPLS La conmutación de etiquetas multiprotocolo (Multi-Protocol Label Switching, MPLS) es una
tecnología de reenvío de paquetes de red a menudo utilizada por los proveedores de servicios en
sus redes centrales de alta velocidad. Utiliza etiquetas de salto a salto en lugar de direcciones de
destino para permitir la ingeniería o la administración de tráfico en rutas de red y flujos de tráfico.
MSP Proveedor de servicios administrados (Managed Services Provider, MSP) es el término que se
utiliza para una capacidad de proveedor de servicios que, por lo general, no proporciona un
portal de autoservicio orientado al cliente que los clientes utilizan para controlar sus entornos
directamente.

NAT La traducción de direcciones de red (Network Address Translation, NAT) es una técnica en la
que se cambian las direcciones de origen y destino en el encabezado de un paquete IP para
ocultar la dirección real de un servicio. Se usa, por ejemplo, cuando se conectan dispositivos
en una red privada a la red pública de Internet.
NIC La tarjeta de interfaz de red (Network Interface Card, NIC) es el adaptador de red que conecta
los hosts ESX a la infraestructura de red externa.
OS El sistema operativo (OS) es la capa de software que se implementa en la capa de hardware
de un equipo físico o virtual. En las soluciones basadas en VMware ESXi™, el hardware físico
utiliza VMware ESXi como sistema operativo, y las máquinas virtuales que ESXi admite
ejecutan una variante de Microsoft Windows de una distribución Linux como el “sistema
operativo invitado”.
PE Edge de proveedor (enrutador) (Provider Edge, PE) es el término utilizado para describir la
función de un enrutador de proveedor de servicios que conecta varios enrutadores Edge del
cliente (CE) a los enrutadores clave del proveedor (o “P”). En algunas plataformas de
proveedor, se virtualiza la función del enrutador CE, de modo que este se conecta físicamente
a la infraestructura de forma directa, lo que permite admitir las soluciones del cliente en lugar
de conectarse a través de un enrutador CE por tenant.
SDN Las redes definidas por software (Software-defined networking, SDN) constituyen una
tecnología que crea elementos de red de usuario final definidos en software que,
posteriormente, se implementan en una red física “subyacente”.
VCDNI El aislamiento de red de vCloud Director (vCloud Director Network Isolation, VCDNI) es una
encapsulación de propiedad “MAC en MAC” utilizada en versiones anteriores de vCloud
Director que permitía conectar en “túnel” varias redes de cliente aisladas entre hosts por medio
de una red única.
vDC El centro de datos virtual (Virtual data center, VDC) es una recopilación de recursos administrados
por vCloud Director. Consulte Tabla 1 para obtener más información.
VIP IP virtual (Virtual IP, VIP) es un término que hace referencia a una dirección IP adicional que
proporciona acceso a uno o más dispositivos sin que se asigne de forma permanente a
ninguno de ellos. Se encuentra en soluciones donde dos o más dispositivos proporcionan alta
disponibilidad mediante la presentación de una única dirección IP para que los clientes se
conecten, sin necesidad de saber qué dispositivo procesará su solicitud.
VLAN LAN virtual es un protocolo de red que permite transportar varias redes de Capa 2 distintas en
el mismo medio físico (Capa 1).
VPN La red privada virtual es una técnica para separar el tráfico en una infraestructura compartida.
Se suele usar cuando se agrega una superposición cifrada a una red compartida no segura,
como Internet, o cuando se proporciona la separación de clientes por medio de un proveedor
de servicios WAN.
VRF El enrutamiento y reenvío virtual (Virtual routing and forwarding, VRF) es una técnica en la que
un dispositivo de red único puede administrar varias tablas de enrutamiento independientes a la
vez y aplicar las reglas de reenvío resultantes al tráfico asociado con una instancia específica.
VXLAN La red de área local virtual extensible es un protocolo de encapsulación que permite transportar
varias redes distintas de Capa 2 por medio de una red de Capa 3 común.
WAN Una red de área extensa es una red de telecomunicaciones que abarca un área geográfica
amplia.

2 Redes de clientes en un entorno de proveedor de servicios

En la creación de topologías de cliente complejas con entornos de VMware vSphere®, el proveedor de
servicios administrados se ve limitado solo por las capacidades y topologías que se pueden crear
mediante el uso de la configuración de red en vSphere junto con la configuración de la infraestructura de
red de centro de datos subyacente. Sin embargo, cuando los clientes desean cambiar la configuración de
red, los servicios tradicionales presentan dificultades en dos áreas diferentes. En primer lugar, mientras
no todos los clientes saben cómo diseñar sus propias configuraciones de red, aquellos que sílo saben
tuvieron poco acceso (si es que lo tuvieron) para poder hacer cambios en los entornos administrados del
proveedor de servicios. En su lugar, el cliente debe generar un pedido o solicitar la participación de un
arquitecto de soluciones de proveedores de servicios para que capte sus requisitos y los proporcione a
los equipos de operaciones del proveedor de servicios. La segunda dificultad en la experiencia del
usuario reside en los requisitos del cliente: los equipos operativos deben establecer los cambios
necesarios para implementar los requisitos del cliente, documentar los cambios, elevar la solicitud o las
notificaciones de cambio correspondientes, y esperar las aprobaciones y las interrupciones programadas
para que pueda comenzar el trabajo. Una vez iniciado el trabajo, resulta desafiante coordinar los cambios
entre equipos y tecnologías distintos, las pruebas son complejas y consumen mucho tiempo, y la planificación
de la recuperación debe contemplar los errores en todas las áreas afectadas por el cambio.
Tras haber simplificado la entrega de complejas soluciones informáticas de cliente mediante la virtualización
de los entornos de servidor con vSphere, el proveedor de servicios puede utilizar un método similar para
simplificar la capa de redes de una solución de cliente. Para ello, introducirá NSX a fin de proporcionar
redes definidas por software (software-defined networking, SDN). Mediante el uso de una red “subyacente”
común en el centro de datos físico, NSX permite al proveedor de servicios configurar topologías y
servicios de red complejos de varios clientes sin necesidad de volver a configurar la red subyacente
todas las veces. Además, ya que estos servicios se definen en el software, la segunda de las dos
dificultades descritas anteriormente puede solucionarse de diversas maneras. La primera, y la más
sencilla, aprovecha que una red definida por software se puede administrar desde un solo punto. Si bien
es posible automatizar la configuración de varios dispositivos de red heredados interconectados, esta
automatización a menudo es compleja y propensa a errores debido, en parte, al hecho de que muchos
de estos dispositivos no estaban originalmente diseñados según la administración de la configuración
remota. Con NSX, el ingeniero de red de un proveedor de servicios puede, desde una única ubicación,
configurar, crear, implementar, modificar y retirar la conectividad y los servicios de red para cualquier
tenant del centro de datos. Si bien este control central es de gran ayuda, eficiencia y coherencia, los
beneficios a menudo se obtienen a través de la automatización de tareas recurrentes. NSX ofrece una
API con muchas funciones que permite la configuración de esas mismas redes y esos mismos servicios
desde herramientas externas. Las API pueden utilizarse para crear y administrar cambios, o bien para
“leer” el estado de un entorno del cliente para propósitos de supervisión o conformidad.
vCloud Director permite que el proveedor de servicios aborde la primera de las dificultades mencionadas
anteriormente, y aquella que es posiblemente la más evidente para el cliente. Proporciona un portal que
permite a los clientes llevar a cabo tareas de aprovisionamiento y cambios propios, almacenar
configuraciones de uso frecuente como plantillas y acceder a plantillas creadas y compartidas por el
proveedor de VMware Cloud. vCloud Director es capaz de controlar los entornos de vSphere subyacentes
que administra a través de las API expuestas por VMware vCenter Server® y otros componentes de
vSphere. La introducción de un acceso similar por API a la capa de red definida por software como se
mencionó anteriormente significa que, en las versiones más recientes (v8.20 al momento de la redacción
del documento), los clientes ahora pueden administrar las redes y los servicios de NSX de su entorno a
través del mismo portal de vCloud Director y de la misma API de vCloud Director.
2.1 Topologías de red del cliente

Gracias al acceso completo a las interfaces de todos los elementos que se utilizan para crear una
solución de cliente, los proveedores de servicios pueden utilizar el rango completo de capacidades
expuestas a través de esas interfaces para que cada cliente reciba un entorno personalizado y
perfectamente adaptado a cumplir sus requisitos. Sin embargo, esto presenta desafíos en toda la
organización del proveedor de servicios. Cada diseño personalizado debe “documentarse”

cuidadosamente para que los equipos de operaciones y de soporte puedan comprender una solución
cuando se les solicite trabajar en ella, o bien para los equipos de infraestructura cuando sea necesario
trabajar en los sistemas de refrigeración o de alimentación del centro de datos. En el lado comercial de la
empresa, las tarifas y los sistemas de facturación deben poder hacer frente a la configuración individual
de cada cliente y a las complejidades que supone llevar a cabo los cambios reflejados en todos los
gastos asociados.
La estandarización de las topologías de red sin dejar de ofrecer la flexibilidad suficiente a los clientes es
un factor clave para aumentar la velocidad y la eficiencia en la prestación de servicios. Por naturaleza, la
introducción de una plataforma de administración de la nube (Cloud Management Platform, CMP) abstrae
a los usuarios, tanto el proveedor de servicios como el cliente, de las interfaces de la infraestructura
subyacente. Al hacerlo, restringe en alguna medida el rango de funciones que expone desde esa
infraestructura subyacente. Sin embargo, al agregar capacidades de nube, un proveedor de servicios
administrados puede empezar a ver estas mejoras en velocidad y eficiencia que proporciona la
“estandarización” aplicada de la CMP.
2.2 Replicación de una topología de cliente de servicios administrados

en vCloud Director
A la hora de planear la implementación de vCloud Director y NSX desde la perspectiva de un cliente o
del arquitecto de soluciones de proveedores de servicios, es importante comprender cómo se pueden
replicar las topologías de cliente familiares del ámbito del proveedor de servicios administrados en el
ámbito del proveedor de servicios de nube basado en el portal. En esta sección, se analiza el modelo de
topología de cliente tradicional y se examinan los nuevos bloques de creación proporcionados por
vCloud Director y NSX, asícomo las topologías de cliente equivalentes que se crean en la plataforma de
proveedor de servicios de nube posteriormente.
2.2.1 Topología tradicional de cliente de servicios administrados

Las topologías de cliente, particularmente en las implementaciones personalizadas de servicios administrados,
pueden adoptar muchas formas, pero en su mayoría comparten características comunes. Por lo general,
presentan algunas o todas las siguientes características:
 Acceso externo desde redes no confiables, como Internet.
 Acceso externo desde redes de área extensa corporativas de confianza o de confianza parcial.
 Seguridad del perímetro en algunas o todas las rutas de acceso de entrada.
 Redes distintas dentro de la solución para la separación administrativa de los componentes de la
solución.
 Seguridad interna para la separación controlada de los componentes de la solución.
 Enrutamiento/conmutación para permitir la comunicación entre los componentes de la solución.
En la siguiente figura, se presenta un ejemplo de red de “res niveles” que muestra elementos típicos.

Figura 1. Ejemplo de topología de cliente de servicios administrados
En la figura, se separa la conexión WAN del enrutador central con un firewall. Según el nivel de
confianza que garantice la WAN y la carga de trabajo, asícomo el nivel de riesgo que el cliente esté
dispuesto a asumir, esto puede no ser necesario. Cuando no hay ningún firewall, una sola red (por lo
general, una VLAN) conecta el enrutador central del tenant directamente a la presentación de WAN, por
lo general, en forma de un enrutador Edge del cliente (CE) por tenant físico y dedicado. Este modelo
simplificado se utilizará como base para las ilustraciones en este documento, aunque se reconoce que
este enfoque de topología no es el único que podría implementarse.
2.2.2 La puerta de enlace de servicios NSX Edge

vCloud Director permite el aprovisionamiento de cargas de trabajo informáticas (y su almacenamiento
asociado) en los entornos de vSphere subyacentes que controla, asícomo el aprovisionamiento de las
cargas de trabajo que los admiten. Gracias a la capacidad de consumo y administración de NSX en las
versiones recientes de vCloud Director, las redes ahora se aprovisionan mediante una VXLAN administrada
por NSX y no a través del aislamiento de red de vCloud Director (VCDNI) que se utilizaba en versiones
anteriores. Además de estas redes NSX, vCloud Director ahora proporciona la capacidad para aprovisionar y
administrar un dispositivo de red y seguridad NSX denominado “puerta de enlace de servicios Edge”
(ESG) en lugar del edge VMware vCloud® Network and Security™ utilizado en versiones anteriores.
A diferencia de las redes virtuales que se implementan en el hipervisor de VMware ESXi, la puerta de
enlace de servicios Edge es una máquina virtual de dispositivo de red (o dispositivo virtual) con interfaces que
se conectan a las redes dentro de la solución. De esta manera, la puerta de enlace de servicios Edge
puede proporcionar numerosos servicios de red. Entre los principales, se encuentran los siguientes:

 Enrutamiento: uso de rutas estáticas o protocolos de enrutamiento dinámico.

 Firewall: para proporcionar filtrado de tráfico de “norte-sur” entrante y saliente de la solución.
 Traducción de direcciones de red: dirección de origen o de destino, o ambas.
 Equilibrio de carga: en la capa 7 para obtener mayores capacidades de función o en la capa 4 para
un mayor rendimiento.
 Terminación de VPN: ya sean VPN de sitio a sitio o de cliente de 3 capas o VPN de 2 capas1 para
permitir el puente de soluciones híbridas donde parte de la solución se encuentra fuera del centro de
datos o del entorno de vCloud Director.
 Interconexión de físico a virtual: permite el enrutamiento entre redes físicas externas (en forma de
VLAN) y redes NSX virtuales internas (en forma de VXLAN).
 DHCP/DNS: la puerta de enlace de servicios Edge también es compatible con DHCP (como servidor
o auxiliar/retransmisión) y un reenviador de DNS.
Al proporcionar capacidades de enrutamiento y protección de firewall, la puerta de enlace de servicios
Edge puede realizar las funciones de enrutador principal de tenant y firewall interno como se muestra en
la Figura 1. En la siguiente sección, se describe la topología de cliente equivalente creada con la puerta
de enlace de servicios Edge.
2.2.3 Topología de cliente de proveedor de servicios de nube básica

Al mover un cliente de un entorno de MSP tradicional a la plataforma de nube del proveedor de servicios,
no cambian los requisitos básicos sobre los que se creó el servicio. Los atributos enumerados en la
sección 2.2.1, Topología tradicional de cliente de servicios administradosse siguen aplicando. La
traducción de la topología a un servicio administrado de vCloud Director genera una topología muy
similar a la que se muestra en la siguiente figura.
1
Consulte el artículo sobre optimización de la incorporación del cliente con servicios VPN de 2 capas de NSX en la
sección de referencias para obtener más información.

Figura 2. Topología de cliente de proveedor de servicios de nube básica
Con la introducción de NSX, las funciones del enrutador físico central de tenant y del firewall interno se
reemplazan por la puerta de enlace de servicios Edge. Debido a que este dispositivo proporciona
capacidades de firewall norte/sur, también puede eliminar la necesidad de un firewall WAN dedicado, lo
que permite ahorrar el coste y la complejidad de un proveedor de servicios. De esta manera, se contribuye
a la reducción de gastos operativos y de capital. Aunque la topología parece casi idéntica a la mostrada
anteriormente, lo que no se ve en la figura es la habilidad del cliente para implementar servicios informáticos y
de red de la puerta de enlace de servicios Edge en dirección sur a través del portal de vCloud Director.
Esto soluciona las dos dificultades identificadas con los servicios MSP, es decir, la habilidad del cliente
para realizar cambios en su propio entorno, asícomo la velocidad y confiabilidad con las que se pueden
implementar los cambios.
2.2.4 NSX Distributed Firewall

Además de las redes con respaldo de VXLAN y la puerta de enlace de servicios Edge, la introducción de
las funciones de NSX en vCloud Director presenta otro beneficio clave. La presencia de los componentes
de NSX en cada host ESXi permite a los clientes de vCloud Director utilizar NSX Distributed Firewall
(DFW). NSX Distributed Firewall implementa una capacidad de filtrado de paquetes con estado en cada
vNIC de cada máquina virtual bajo su administración. Además del control del tráfico que llega a la
máquina virtual desde fuera de la red a la que está conectada la máquina virtual, Distributed Firewall
permite controlar el tráfico entre máquinas virtuales de la misma red. Este control detallado de tráfico
dentro de la misma red se conoce como “microsegmentación”. La microsegmentación habilita un grado
de control sobre el tráfico que ya se permitió a través del firewall perimetral, algo que antes no era
posible. En el siguiente ejemplo, se muestra una parte de la “política” de Distributed Firewall aplicada al
tráfico que ingresa y sale desde dos máquinas virtuales de “servidor web”.

Figura 3. Microsegmentación con Distributed Firewall
Las políticas de DFW que controlan el flujo de paquetes hacia y desde las VNIC de cada máquina virtual
se configuran de forma centralizada mediante la nueva interfaz de administración de firewall basada en
HTML5 de vCloud Director y, posteriormente, se distribuyen al host ESXi que se implementará en la máquina
virtual en ejecución. En caso de que deba moverse la máquina virtual, la política se vuelve a aplicar en el host
de destino. En la siguiente figura, se muestra esta administración distribuida de políticas con implementación
según vNIC cuando se aplica en toda la topología de la red.

Figura 4. Topología básica de cliente con NSX Distributed Firewall
En la ilustración, cada vNIC está eficazmente separada de la red mediante un firewall. Esto permite
controlar el tráfico entre las máquinas virtuales de la misma red mediante una política de firewall, algo
que no resulta práctico con la infraestructura de redes tradicional. Consulte la sección 7, Referencias
para obtener más información sobre los beneficios de la microsegmentación. Tanto la política norte/sur
en la puerta de enlace de servicios Edge como la política de Distributed Firewall en sípueden administrarse
desde la interfaz de usuario de vCloud Director; lo puede hacer el proveedor de servicios o el cliente
mismo, en caso de que el proveedor de servicios eligiera ofrecer las instalaciones.
Debido a que la puerta de enlace de servicios Edge ofrece servicios de VPN y firewall, los clientes
pueden cuestionar la presencia de dos firewalls en la conectividad a Internet, especialmente a medida
que se aceptan los beneficios de la microsegmentación. En este punto, el proveedor de servicios puede
reducir aún más el coste y la complejidad. Para hacerlo, debe quitar el firewall de Internet físico y mover
sus funciones a la puerta de enlace de servicios Edge. Este nivel de aceptación de riesgos suele ser
diferente para cada cliente, y es posible que los proveedores de servicios elijan ofrecer soluciones con y
sin el firewall de Internet físico.
2.2.5 Compatibilidad de funciones de NSX adicional en vCloud Director

Cada versión de vCloud Director proporciona nuevas funciones y funcionalidades. Si bien la versión
actual no admite el conjunto completo de funciones de NSX, todas las versiones recientes de vCloud
Director agregaron mayor compatibilidad para el consumo y la administración de funciones de NSX
adicionales. Esta tendencia pretende continuarse, por lo que se recomienda al lector revisar las notas de
la versión de vCloud Director más recientes para establecer el nivel de compatibilidad en el momento de
la lectura.

3 Estructura jerárquica en un proveedor de servicios de nube

Los proveedores de servicios administrados están acostumbrados a proporcionar una estructura
jerárquica en una ubicación de centro de datos única. A menudo la crean con hardware discreto para los
servicios de cada cliente, en general, mediante hardware dedicado informático, de almacenamiento, de
redes o de seguridad con conectividad directa a enrutadores de CE físicos y dedicados de acceso a
WAN. De forma similar, la capa de ESXi de cada tenant a menudo se administra desde una instancia
dedicada de VMware vCenter Server®. En la siguiente figura, se muestra la topología de tenant básica en
un centro de datos de proveedor de servicios administrados de estructura jerárquica.
Figura 5. Ejemplo de topología de centro de datos de estructura jerárquica de servicios
administrados
La introducción de servicios de nube permite consolidar esa capa de administración de virtualización en

quizás una sola instancia de vCenter Server, lo que posibilita administrar hosts informáticos donde se
proporciona servicio a varios clientes. Si el proveedor de servicios de nube va a ofrecer la incorporación
rápida de nuevos tenants, también es mucho más rápido y más económico compartir hardware de red.
Anteriormente, era posible compartir hardware de seguridad, pero se requería el aprovisionamiento de
dispositivos de seguridad de alta capacidad y gran tamaño que pudieran ofrecer la separación lógica
para cada tenant, a menudo en forma de instancias o contextos virtuales. Sin embargo, el gran gasto de
capital que implicaba aprovisionar tales dispositivos con capacidad para ampliar la cantidad de tenants
requeridos supuso un desafío para los casos de negocios de los proveedores de servicios de nube. Los
proveedores de servicios de VMware Cloud ahora tienen la ventaja de poder aprovisionar los dispositivos
de seguridad dedicados en la forma de puertas de enlace de servicios NSX Edge cada vez que lo
necesitan. Solo deben tener la capacidad para administrar la plataforma informática subyacente en la que
se ejecutan los servicios y la plataforma de red subyacente que conecta los hosts informáticos entre sí.
Si bien los beneficios comerciales del uso compartido de hardware son fáciles de ver (el aumento de la
utilización de hardware minimiza la cantidad de hardware que debe procurarse, implementarse y
administrarse), se presenta el nuevo desafío de proporcionar la separación lógica de tenants en todos los
niveles de la pila de infraestructura. La creación de una separación en la capa de vSphere puede ser
sencilla, pero extender esa separación a la interfaz de usuario o a las API es más complejo. vCloud
Director tiene en cuenta este problema y abstrae los elementos bajo su control del usuario final; en su
lugar, proporciona una nueva interfaz gráfica de usuario para interacciones manuales y una API para
interacciones de máquina. Es importante que el arquitecto del proveedor de servicios comprenda cómo

se coordinan las capas de una solución vCloud Director y cómo se llevan a cabo las acciones de una
capa en las otras capas.
Si bien el modelo de centro de datos definido por software (software-defined data center, SDDC) de
VMware incluye virtualización del almacenamiento, en la siguiente figura, se presentan las capas clave
que muestran la migración del proveedor de servicios administrados al proveedor de servicios de nube
consideradas en este documento.
Figura 6. Transición de software en capas de MSP a CSP en el programa VMware Cloud Provider
3.1 Estructura jerárquica de vCloud Director

Al proporcionar una superposición de estructura jerárquica, vCloud Director presenta algunos términos
nuevos en las teorías que describen el modelo de estructura jerárquica. Los términos, que se utilizan en
todo este documento, se describen brevemente en la siguiente tabla. Para ver una explicación más
detallada, consulte los documentos vinculados en la sección 7, Referencias.
Tabla 1. Términos de jerarquía de VMware vCloud Director
Término Descripción
Organización Una organización es un grupo lógico de todos los usuarios

a quienes se presentarán recursos.
Centro de datos virtual de Un VDC (centro de datos virtual) de proveedor es una

proveedor recopilación de recursos de vSphere (almacenamiento,
CPU y memoria) que vCloud Director puede administrar y
utilizar.
Centro de datos virtual de Un VDC de organización es un subconjunto de los recursos

organización de un VDC de proveedor que están disponibles para una
organización.

En las siguientes imágenes, se muestran estos conceptos.

Figura 7. Grupos de recursos y clústeres de vSphere del centro de datos del proveedor de
servicios
En la Figura 7, el centro de datos tiene dos nodos de vCenter Server, y cada uno de ellos administra dos
clústeres. En vCenter-01, los dos clústeres contienen diferentes tipos de hosts. Cluster-01 incluye hosts
con mayores velocidades de reloj de CPU para cargas de trabajo de uso intensivo de CPU, mientras que
Cluster-02 tiene hosts con memoria adicional para hosts con mayores exigencias de memoria. Por otro
lado, vCenter-02 contiene dos clústeres con el mismo tipo de hosts, cada uno con un equilibrio de
velocidad de reloj y memoria diseñado para cargas de trabajo generales. Dado que no es posible colocar
un grupo de recursos en otro lugar que no sea en todos los hosts de un clúster, y como vCloud Director
ubica las cargas de trabajo dentro de un grupo de recursos, todos los hosts de un único grupo de
recursos y, por lo tanto, el clúster, deben ser del mismo tipo para garantizar la coherencia en el
rendimiento.
Debido a que un VDC de proveedor (PVDC) está conectado a una sola instancia de vCenter Server, el
ejemplo de vCloud Director de la Figura 7 debe tener al menos dos nodos de vCenter Server. Sin embargo,
para permitir la colocación de cargas de trabajo en hosts con alto consumo de memoria o CPU, los
recursos en vCenter-01 deben dividirse en dos VDC de proveedor, cada uno asignado a un grupo de
recursos en uno de los clústeres. Debido a que un VDC de proveedor puede tener asignados varios
grupos de recursos de la instancia de vCenter Server, los recursos de vCenter-02 podrían presentarse
como dos VDC de proveedor distintos, o bien, como se muestra en la Figura 8, como un PVDC con
varios grupos de recursos.

Figura 8. Asignación de VDC de proveedor a recursos de vSphere
El PVDC presenta recursos que pueden consumir las organizaciones que se suscriben al servicio de
nube del proveedor. A fin de presentar los recursos a esas organizaciones, vCloud Director utiliza un
VDC de organización (u OVDC) para representar un subconjunto de un VDC de proveedor. Un cliente,
representado por una organización de vCloud Director, puede acceder a varios VDC de organización. En
el ejemplo ilustrado en la Figura 8, un cliente puede requerir algunas cargas de trabajo de memoria alta y
algunas estándar, en cuyo caso tienen dos OVDC, uno en PVDC2 y otro en PVDC3. Un cliente que solo
requiere cargas de trabajo estándar puede tener un único OVDC, o bien puede optar por tener dos para
aplicar diferentes índices de exceso de suscripciones o colocaciones de cargas de trabajo para cargas
de trabajo de desarrollo y producción.
Al acceder a vCloud Director, los usuarios de una organización con privilegios de acceso adecuados ven
todos sus OVDC enumerados.
3.2 Topología de tenant básica de vCloud Director

En la figura siguiente, se muestra el modelo de estructura jerárquica de vCloud Director superpuesto en
una topología de cliente simple.

Figura 9. Topología de cliente básica de vCloud Director
El VDC de organización contiene las cargas de trabajo del cliente que se conocen como vApps en vCloud
Director, tanto si están en una sola máquina virtual en una red o en varias máquinas virtuales en
diferentes redes. Debido a que vCloud Director no administra todos los recursos del cliente, esos
recursos que se encuentran afuera en el centro de datos físico deben ser administrados por el proveedor
de servicios o a través de un portal distinto orientado al cliente. Las redes que conectan los VDC de
organización a recursos del centro de datos externo se describen en vCloud Director como “redes
externas”. Terminan en una puerta de enlace de servicios Edge de VDC de organización para proporcionar
acceso enrutado, de traducción de direcciones de red (NAT) o de conexión directa hacia y desde las
cargas de trabajo incluidas en el VDC de organización. Las redes que se limitan al entorno de vCloud
Director se conocen como “redes de VDC de organización”.
Tanto las puertas de enlace de servicios Edge de una organización como las redes de VDC de
organización pueden administrarse desde la página de administración de VDC de organización de
vCloud Director tal como se muestra en la siguiente figura.

Figura 10. Administración de puertas de enlace Edge y redes de VDC de organización en vCloud
Director
En la versión actual de vCloud Director, NSX Distributed Firewall utiliza la nueva interfaz HTML5 que se
inicia desde el menú Acciones del VDC de la organización, como se muestra en la siguiente figura.
Figura 11. Administración de NSX Distributed Firewall en vCloud Director
3.3 Redes de estructura jerárquica

En un entorno de proveedor de servicios administrados de VMware, las redes se administran desde
varios puntos. La infraestructura de red física se administra por dispositivo, desde una plataforma de
administración central suministrada por el proveedor o desde una capacidad de automatización
personalizadas. La infraestructura de red virtual se administra desde uno o varios nodos de vCenter
Server, donde cada uno es responsable de la conectividad entre la red física y las cargas de trabajo
virtuales. En un entorno de proveedor de servicios de VMware Cloud, vCloud Director abstrae algunas de
las tareas de administración de red virtual; la administración de red pasa entonces a las capas que se
describen en la siguiente sección.
3.3.1 Capas de red en una plataforma de nube de estructura jerárquica

 Centro de datos y redes subyacentes a NSX: la capa de configuración de red que sigue siendo la
responsabilidad del proveedor de servicios. Además de las redes de administración, esto incluye la
red de transporte de NSX, que transmite el tráfico encapsulado de VXLAN entre hosts ESXi y las
redes por tenant que deben configurarse dentro de la infraestructura del centro de datos cuando se
incorpora un cliente nuevo.
 Redes de vCloud Director: las redes de VDC de organización que se crean y se administran
completamente desde el interior de vCloud Director y utilizan la red de transporte de NSX preconfigurada
para la conectividad entre hosts.

 Redes administradas desde vCloud Director: las redes externas que se crean inicialmente en la
instancia de vCenter Server del VDC de proveedor relevante, pero que, a continuación, se “agregan”
a vCloud Director y posteriormente se pueden administrar en la API o la interfaz de usuario de
vCloud Director.
Estos tres tipos de redes se muestran en la siguiente figura. El diagrama muestra las redes por tenant
necesarias para conectar el acceso a WAN de cada cliente a su VDC de organización de vCloud Director.
Figura 12. Ejemplo de topología de centro de datos de estructura jerárquica de un proveedor
servicios de nube
En este gráfico, las redes de la distribución de Internet y de los enrutadores WAN se administran dentro
de la infraestructura de red del centro de datos, por lo general, en la incorporación de clientes. Las redes
“web”, “de aplicaciones” y “de base de datos” del VDC de organización de cada tenant se crean y se
administran desde vCloud Director, ya sea por el cliente o por el proveedor de servicios. Las redes de los
firewall de Internet (si existen) y de los enrutadores de WAN, una vez configuradas, se muestran en
vCloud Director como redes externas y, posteriormente, se administran desde la interfaz de usuario de
vCloud Director. Consulte Apéndice A: Aprovisionamiento de una red externa en vCloud Director para ver
más detalles.
La conectividad externa del centro de datos en un entorno de proveedor de servicios de nube sigue los
mismos modelos en la infraestructura física que seguiría en un entorno de proveedor de servicios
administrados.
 Se utilizan redes por tenant donde se requiere la separación de capa 2 en toda la infraestructura
compartida del centro de datos. Esto ocurre, por ejemplo, en casos donde hay superposición de
direcciones de clientes o se necesita administrar flujos de tráfico sin recurrir al enrutamiento de capa
3. Algunos ejemplos del uso de redes por tenant son el acceso de clientes desde su WAN a entornos
de vCloud Director o el acceso desde servicios con ubicación conjunta dentro del centro de datos de
proveedor físico.
 Las redes compartidas pueden utilizarse cuando no hay ningún riesgo de superposición de direcciones
(por ejemplo, el acceso a la red pública de Internet) y donde el enrutamiento de capa 3 puede servir
para dirigir el tráfico al destino correcto.

Al compartir redes entre varios clientes dentro de un solo dominio de difusión de capa 2, se corre el
riesgo de experimentar un problema de red que afecte a varios clientes. Para mitigar esta situación, los
proveedores de VMware Cloud pueden elegir un enfoque híbrido en el que se cierran las redes en
común (nuevamente, como el acceso a Internet) en los dispositivos de capa 3 de alto rendimiento que
reenvían el tráfico a varias redes posteriores más pequeñas. Estas redes ofrecen dominios de difusión
independientes, por lo que reducen el efecto que un cliente puede producir en otros.
4 Capas de redes examinadas

En un proveedor de servicios de nube de vCloud Director, los cambios de configuración de red pueden
instigarse y administrarse desde la API o la interfaz de usuario de vCloud Director por los propios clientes
o por el proveedor de VMware Cloud en lugar de ellos. Mientras que algunos cambios, como en la
administración de grupos de direcciones IP o en las direcciones de puerta de enlace, se producen dentro
de la base de datos de configuración de vCloud Director, la mayoría de los cambios afectan a las capas
inferiores. Por ejemplo, en el caso de una nueva red de VDC de organización, la solicitud se pasa de
vCloud Director a la instancia de VMware NSX Manager™ conectada a la instancia de vCenter Server que
aloja el grupo de recursos para el VDC de proveedor en el VDC de organización donde se creará la nueva
red. NSX Manager configura la red dentro de su modelo de estado interno y, a continuación, la capa de
vSphere subyacente a través del vínculo de NSX Manager a su instancia principal de vCenter Server.
En las siguientes secciones, se examina este modelo en capas desde la perspectiva de la topología de
tenant único anterior, además de la vista de estructura jerárquica en las capas de configuración de
vSphere y de NSX.
4.1 Redes de tenant

La topología básica de tenants de proveedor de servicios de nube en la Figura 2 (se muestra también en
la siguiente figura para su comodidad) se crea a partir de doce segmentos de red independientes.

Figura 13. Redes de tenants de proveedor de servicios de nube

La siguiente figura representa la misma topología de tenants que aparece en las capas de NSX y
vSphere.
Figura 14. Redes de tenants de proveedor de servicios de nube
 La conexión 1 se realiza en la infraestructura de red del centro de datos físico y no alcanza a las
capas de NSX o vSphere de la solución.
 La conexión 2 se compone de dos partes: por un lado, una conexión física entre el firewall de
Internet del cliente “dentro” de la interfaz, que se presenta ante un puerto en el grupo de puertos de
Internet respaldado por VLAN en el dvSwitch de vSphere y, por el otro lado, la conexión de interfaz
de Internet de la puerta de enlace de servicios Edge con un segundo puerto en el mismo grupo de
puertos.
 La conexión 3 también está formada por dos partes: una conexión física entre la interfaz “LAN” del
enrutador WAN del cliente, que se presenta ante un puerto en el grupo de puertos WAN respaldado
por VLAN en el dvSwitch de vSphere, y una conexión de interfaz WAN de la puerta de enlace de
servicios Edge con un segundo puerto en el mismo grupo de puertos.
 Las conexiones 4 y 5 presentan las máquinas virtuales web ante los puertos en el grupo de puertos
web que, debido a que la red web es una red de VDC de organización de vCloud Director, se crea en
NSX como una “conexión virtual”. Por lo tanto, el grupo aparece en el dvSwitch como un grupo de
puertos respaldado por VXLAN.
 La conexión 6 presenta la interfaz web de la puerta de enlace de servicios Edge ante el grupo de
puertos web.

 Las conexiones 7 a 9 siguen el mismo patrón que 4, 5 y 6, excepto por el grupo de puertos y la red
de aplicaciones.
 Las conexiones 10 a 12 siguen el mismo patrón que 4, 5 y 6, pero esta vez para el grupo de puertos
de la base de datos.
 También se muestra la posición lógica de NSX Distributed Firewall en cada interfaz de máquina
virtual para representar el punto en el que se aplica una política de DFW para el flujo de tráfico
entrante o saliente de una vNIC en una máquina virtual.
4.2 Redes del centro de datos de estructura jerárquica de vCloud

Director en vSphere
El análisis detallado de la sección anterior ilustra la representación de un tenant único dentro de la capa
de vSphere. Las siguientes secciones representan el mismo análisis, pero aplicado a un centro de datos
de estructura jerárquica de vCloud Director.
Figura 15. Redes de estructura jerárquica de proveedor de servicios de nube de vSphere
 El acceso a Internet que se muestra en este gráfico se comparte entre todos los tenants que no
requieren un firewall físico. La conexión de acceso compartido a Internet se presenta como un puerto
en un grupo de puertos respaldado por VLAN en el dvSwitch de vSphere. Cada tenant de vCloud
Director tiene una conexión de red externa entre un puerto en este grupo y la interfaz de Internet de
la puerta de enlace de servicios Edge en su VDC de organización.
 El tenant 4 decidió conservar un firewall de Internet físico. En su caso, dentro de la infraestructura del
centro de datos físico, el acceso compartido a Internet se presenta al “exterior” del firewall, en tanto
que una red VLAN independiente conecta el “interior” del firewall a un grupo de puertos separado
respaldado por VLAN en el dvSwitch de vSphere. Una red externa conecta un segundo puerto de
este grupo de puertos a la interfaz de Internet de la puerta de enlace de servicios Edge en su VDC
de organización.

 Cada cliente tiene un enrutador CE de WAN independiente. Debido a que, por lo tanto, la conexión
con los entornos de tenants puede tener superposición de direcciones (desde el interior de su
organización de vCloud Director o desde su WAN), cada una debe estar separada mediante el centro
de datos y en el entorno administrado de vCloud Director. Por lo general, esto significa que la conexión
WAN de cada tenant se presenta como una red externa independiente con un identificador de VLAN
independiente; por lo tanto, requiere un grupo de puertos independiente respaldado por VLAN en el
dvSwitch de vSphere para conectarse a la interfaz WAN de sus respectivas puertas de enlace de
servicios Edge.
 Las redes de VDC de organización de cada tenant aparecen como un grupo de puertos respaldados
por VXLAN en el dvSwitch, con los puertos para la interfaz de puerta de enlace de servicios Edge y
las máquinas virtuales de vApp conectados a esa red. En este gráfico, las redes aparecen simplificadas
por motivos de clarificación, en la misma forma que las interfaces de puerta de enlace de servicios
Edge y las interfaces de máquina virtual en la Figura 14.
Aunque este ejemplo ilustra la separación de las redes VLAN detrás del acceso a WAN por tenant, en un
centro de datos del proveedor de servicios es probable que, en algún punto de la infraestructura, varias
VLAN de un mismo tipo y nivel de seguridad se enlacen de manera “troncal” en un solo vínculo. En ese
caso, no es necesaria la presentación por VLAN entre la capa de redes de vSphere (debajo del VDC del
proveedor) y la infraestructura del centro de datos que se muestra en la Figura 15. De manera similar a
un conmutador físico, un puerto de vínculo superior de dvSwitch puede transportar varias VLAN encapsuladas
en el único vínculo conectado mediante IEEE 802.1q. Para ello, cuando se está creando un grupo de
puertos de vínculo superior de dvSwitch, su tipo de VLAN se establece en “enlace troncal de VLAN”
como se muestra en la siguiente figura. Aquítambién puede configurarse el rango de VLAN permitido en
el enlace troncal.
Figura 16. Configuración de un enlace troncal de VLAN para un grupo de puertos de vínculo
superior de dvSwitch
En la siguiente figura, se muestra un ejemplo de dónde puede aplicarse esta configuración. En este
ejemplo, el proveedor de servicios presenta el acceso a WAN conectando el enrutador en el servidor
Edge del proveedor (Provider Edge, PE) de MPLS a la plataforma de vCloud Director. El enrutador de PE
presenta el VRF de VPN WAN de cada cliente ante una subinterfaz en una conexión troncal, cuyo otro
extremo se conecta al tenant de vCloud Director del cliente y, así, cierra su puerta de enlace de servicios
Edge. De forma similar, se pueden cerrar varias conexiones del enrutador de CE de WAN del cliente en
los puertos de acceso etiquetados con VLAN de un conmutador de “agrupación”, cuyo vínculo superior
luego envía las conexiones troncales a la puerta de enlace de servicios Edge de cada tenant.

Figura 17. Conexión con enlace troncal de varias redes externas a un entorno de vCloud Director
Esta técnica también puede aplicarse a varias redes de Internet VLAN independientes donde cada una
se presenta ante un firewall de cliente independiente en el centro de datos, o bien donde los servicios
con ubicación conjunta de varios clientes se enlazan de manera “troncal” en el entorno de vCloud
Director mediante conexiones compartidas de ancho de banda alto.
La cantidad de dvSwitches utilizados para enviar estos grupos de puertos respaldados por VLAN
depende de una serie de consideraciones de diseño, entre ellas, la cantidad de adaptadores de red física
en el host ESXi. En los hosts con un solo par de adaptadores, todas las VLAN deben enlazarse de
manera troncal con el mismo grupo de puertos de vínculo superior (como se muestra en el rango de la
Figura 16 ). En el caso de un host con varios adaptadores o con adaptadores que pueden simular varios
adaptadores a vSphere (por ejemplo, algunos servidores blade), pueden crearse dvSwitches para
separar, por ejemplo, el tráfico de administración, de Internet y de WAN. Para facilitar la configuración
cuando sea posible, puede preasignarse un rango de identificadores de VLAN para “vínculos superiores
de WAN” y, a medida que se incorpora cada tenant, se les asigna el siguiente identificador del rango. El
grupo de puertos de vínculo superior se crea con el rango específico configurado y el grupo de puertos
para cada “red externa” del nuevo tenant configurado con el identificador de VLAN específico del rango.
4.3 Redes en una topología de infraestructura de varios clústeres de hoja

En las ilustraciones de esta sección, se asume que es posible conectar (con enlace troncal) la misma
VLAN entre los entornos de conectividad externa del centro de datos y los entornos informáticos de la
carga de trabajo. En algunas topologías de infraestructura, esto no es posible porque normalmente
pueda que existan varios saltos de enrutamiento entre distintas partes de la infraestructura. Las
soluciones que emplean nodos informáticos montados en bastidor discretos (en lugar de soluciones
basadas en blade con redes integradas) a menudo se configuran en una topología de hoja donde las
VLAN están limitadas dentro de un bastidor y la conectividad entre bastidores se logra a través de un
núcleo de capa 3 enrutada.

Cuando no se produce una cobertura ubicua de capa 2 a través del arrendamiento informático completo,
la ubicación de puertas de enlace de servicios Edge del tenant en los recursos informáticos con acceso a
la conectividad externa requerida se convierte en un desafío. vCloud Director ofrece cierta asistencia, ya
que su motor de ubicación implementa máquinas virtuales Edge en clústeres según la conectividad
VLAN. La presentación de las VLAN directamente en un subconjunto de bastidores (por lo general, al
menos dos para resistencia) garantiza que las puertas de enlace de servicios Edge solo se implementen
en esos clústeres debido a su disponibilidad de VLAN. Sin embargo, vCloud Director también podrá
aprovisionar cargas de trabajo normales a esos mismos clústeres debido a la disponibilidad de las redes
de tenants requeridas para la conectividad en dirección sur de las mismas puertas de enlace de servicios
Edge. Por este motivo, los clústeres con conectividad externa en este modelo se conocen como
clústeres Edge/informáticos combinados.
Hay una serie de modelos alternativos para ubicar las puertas de enlace de servicios Edge en “clústeres
de Edge” independientes sin cargas de trabajo de tenants, cada una de las cuales conlleva su propia
complejidad y sobrecarga operativa. Aún rigen los principios descritos anteriormente en esta sección,
pero deben aplicarse sobre la opción del clúster Edge elegida por el proveedor. Las opciones se
describen más detalladamente en Arquitectura de la solución VMware vCloud Director para proveedores
de nube de VMware (sección 6.3.2). Consulte la sección 7, Referencias para obtener más información.
4.4 Redes de estructura jerárquica de vCloud Director en NSX

Para que vCloud Director saque el máximo partido de NSX, el entorno de vSphere que vCloud Director
administrará primero debe estar preparado para NSX. Las consideraciones de diseño para redes
subyacentes a NSX (transporte de VTEP) son las mismas si el consumidor es vCloud Director u otra
plataforma CMP o una herramienta de orquestación, cuyos detalles quedan fuera del alcance de este
documento. Sin embargo, durante el diseño de una implementación independiente de NSX, a los arquitectos
se les presenta una serie de opciones. Cuando vCloud Director administra el entorno de NSX, algunas
de las decisiones las toma vCloud Director tanto en la instalación como durante la posterior administración del
entorno.
En la siguiente tabla, se examina la relación entre los elementos de red en vCloud Director y los de las
plataformas subyacentes de vSphere y de NSX.
Tabla 2. Jerarquía y elementos de red de NSX y vSphere en vCloud Director
vCloud Director NSX o vSphere Notas
vDC de proveedor Zona de transporte de La configuración de un PVDC genera la

NSX creación de una zona de transporte dentro de
NSX. El modo de plano de control de la nueva
zona de transporte se establece inicialmente
en multidifusión y debe cambiarse
inmediatamente desde la API o la interfaz de
usuario de NSX si no es la configuración
preferida.
Red externa Grupo de puertos de Se crea una red externa en la infraestructura

vSphere del centro de datos, las redes de vCenter
Server y los cuadros de diálogo de recursos de
nube de vCloud Director. Consulte Apéndice
A: Aprovisionamiento de una red externa en
vCloud Director para ver más detalles.

vCloud Director NSX o vSphere Notas
Puerta de enlace de NSX Edge Una puerta de enlace de servicios Edge

servicios Edge creada con la configuración de VDC de
organización se traduce en la creación de una
instancia de NSX Edge. El nombre inicial
asignado a la puerta de enlace de servicios
Edge en vCloud Director se codifica en el
nombre de NSX Edge junto con un campo
UUID para garantizar que los nombres sean
exclusivos en todos los tenants.
Redes de VDC de Conmutador lógico de La creación de una red de VDC de

organización NSX/ organización en vCloud Director resulta en la
creación de un conmutador lógico de NSX con
Grupo de puertos de
el nombre de la red de VDC de organización
vSphere
inicial y un UUID en su nombre. Como
consecuencia, se crea un dvPortGroup en
vSphere con el nombre de conmutador lógico
y el identificador (segmento) de red VXLAN
codificado en su nombre.

5 Administración de direcciones IP y enrutamiento

5.1 Administración de direcciones del tenant
Hay una serie de opciones de conectividad externa que permite a los clientes alcanzar las cargas de
trabajo en las redes dentro de su entorno de tenants. Cada una requiere que las direcciones IP que se
usan de forma externa para acceder a las cargas de trabajo del tenant sean conocidas por el método de
conectividad de los clientes, ya sea WAN, VPN u otro. Las direcciones que se utilizan para acceder a la
solución pueden ser proporcionadas por el proveedor de servicios o por el cliente. Los detalles de las
direcciones utilizadas para acceder a las redes de tenants pueden configurarse de manera estática en
los dispositivos de enrutamiento que se usan para el acceso, pero a menudo se distribuyen mediante
protocolos de enrutamiento dinámico. La configuración del enrutamiento estático depende en gran
medida del hardware de enrutamiento en cuestión y, por lo tanto, está fuera del alcance de este documento.
En cambio, la distribución de información de enrutamiento mediante protocolos dinámicos es un elemento
clave de la eficiencia que pretende ofrecer el proveedor de servicios de nube.
Los distintos métodos de aprovisionamiento y administración de direcciones para las redes de tenants y
los anuncios a redes de acceso de clientes se describen en la siguiente sección.
5.1.1 Direcciones administradas por el proveedor de servicios

Algunos proveedores de servicios eligen administrar el espacio de direcciones dentro de sus entornos de
tenants y asignar a sus tenants rangos de direcciones del tamaño adecuado. La ventaja para el proveedor
de servicios es que no necesita operar con varios clientes que utilizan las mismas direcciones “superpuestas”;
de este modo, se simplifica notablemente el acceso desde las plataformas de administración del proveedor a
entornos de varios tenants. Sin embargo, una desventaja de este enfoque es que es muy probable que
las direcciones asignadas a un cliente estén en uso en otro lugar dentro de la red del cliente más amplia.
Para evitar que la duplicación de direcciones genere un problema, los proveedores de servicios aplican
una capa de NAT en el límite del servicio. En casos como este, las redes de VDC de organización del
cliente se abordan desde el espacio de direcciones coordinado del proveedor de servicios; en general,
se usan direcciones “privadas” que proceden de los rangos definidos en RFC1918 (consulte la sección 7,
Referencias). Para que el cliente pueda alcanzar estas direcciones, los rangos de direcciones (mutuamente
acordados, a menudo la red pública de Internet) se asignan y se traducen a las direcciones internas
utilizadas dentro de las redes de tenants.
La traducción de direcciones (NAT) puede configurarse y llevarse a cabo en un dispositivo externo y
administrado por el proveedor en el centro de datos que suele estar dedicado a cada tenant. O bien,
puede realizarse en la puerta de enlace de servicios Edge y administrarse mediante vCloud Director. La
NAT se conoce específicamente como NAT de destino o “DNAT” cuando se lleva a cabo en las conexiones
de entrada y cuando se cambia la dirección IP de destino, donde la dirección IP real del destino reemplaza a
la dirección de la red de límite. Cuando la NAT se realiza en la puerta de enlace de servicios Edge, a la
red externa que conecta la puerta de enlace de servicios Edge del tenant al enrutador Edge del cliente se
le asigna la subred que contiene el rango de direcciones NAT. Esto se muestra en la siguiente figura con
la topología básica de tenants utilizada anteriormente.

Figura 18. NAT en la puerta de enlace de servicios Edge de VDC de organización
A las interfaces de la puerta de enlace de servicios Edge y los dispositivos ascendentes se les asignan
direcciones desde la subred asignada a la red externa; el resto queda disponible para usarlas con las
direcciones NAT de entrada o salida asignadas a las máquinas virtuales dentro del VDC de organización
del cliente. Este proceso se examina en detalle en la sección 5.4, Subasignación de direcciones de red
externa.
Aunque este modelo simplifica la configuración de red del proveedor de servicios, puede presentar
problemas para el cliente, dado que algunas aplicaciones no pueden tolerar la NAT y o bien no funcionan,
o bien se requieren pasos adicionales para solucionar los problemas provocados por NAT. Debido a que
los rangos asignados a las redes de VDC de organización están ocultos detrás de las direcciones NAT,
las direcciones reales de las máquinas virtuales y los IP virtuales (VIP) no necesitan intercambiarse con
los dispositivos WAN ascendentes. Las direcciones que se utilizan para NAT proceden de los rangos
asignados a las redes que conectan directamente los dispositivos WAN a la puerta de enlace de servicios
Edge. Por lo tanto, los dispositivos WAN aprenderán los rangos de NAT como redes “conectadas” y, a
continuación, pueden distribuir esas direcciones a sus conexiones ascendentes según sea necesario.
5.1.2 Aporte de los propios IP

Dejando de lado la simplicidad que las direcciones administradas por el proveedor de servicios
representan para el proveedor, permitirle al cliente que aporte sus propias direcciones puede simplificar
en gran medida la configuración de red del cliente. Los clientes remotos en la WAN del cliente usan las
direcciones asignadas a las máquinas virtuales de la carga de trabajo o los VIP de equilibrio de carga
directamente para conectarse a los servicios en el VDC de organización, con lo cual ya no es necesaria
la NAT. Algunos clientes consideran que un centro de datos de terceros es un entorno menos confiable y
podrían insistir en una capa de NAT entre las cargas de trabajo en el centro de datos y su entorno WAN.

En estos casos, incluso si el cliente proporciona tanto las direcciones de red de VDC de organización
como el rango NAT, su configuración es efectivamente idéntica a la que se describe en la sección 5.1.1,
Direcciones administradas por el proveedor de servicios, salvo que es posible que se superpongan con
direcciones utilizadas por otro tenant o el entorno de administración del proveedor.
Los flujos de trabajo que, ya sea en la incorporación de tenants o como una acción de “Día 2”, crean
nuevas redes de VDC de organización deben asignar nuevas subredes de direcciones a esas redes.
Para ello, el cliente requiere un esquema de direcciones IP a partir del cual se asignarán direcciones
para su uso dentro de las redes administradas en vCloud Director. Como se muestra en la siguiente
figura, vCloud Director genera un mensaje de error si se solicita una red con un rango de direcciones que
se superponen. El cliente o el proveedor que crea la red debe tener acceso a una asignación de subred
adecuada para solucionar el mensaje de error.
Figura 19. Mensaje de error provocado por aprovisionar un rango de direcciones superpuestas
Existe una serie de técnicas para asignar direcciones a partir de un esquema más grande. En algunos
casos, cada subred de la red debe solicitarse al propietario del esquema en el lugar de aprovisionamiento. En
otros casos, el propietario del esquema del cliente asigna un rango mayor de “superredes” de direcciones
para su uso en el entorno del proveedor. Esto permite delegar la administración al proveedor de servicios
si se proporciona un servicio de administración o al propietario de la solución del cliente responsable de
las cargas de trabajo en los VDC de organización de vCloud Director.
5.2 Asignación de direcciones del cliente

La asignación de direcciones para consumo por parte de las cargas de trabajo en las redes de VDC de
organización del “cliente” (provistas por el cliente o el proveedor) puede llevarse a cabo de tres maneras.
Dos de ellas implican que vCloud Director configure la dirección en la máquina virtual durante su creación,
mientras que la tercera permite que el sistema operativo (SO) invitado de la máquina virtual se construya
sin una dirección IP y solicite una durante el arranque. Cada método se describe en las siguientes secciones.
5.2.1 Asignación de grupos de direcciones IP estáticas

Con la asignación de grupo de direcciones IP estáticas, vCloud Director elige una dirección del grupo de
direcciones IP asignado a la red de VDC de organización. En el SO invitado compatible, con VMware
Tools™ instalado y con la opción “Personalización de invitado” habilitada, la dirección seleccionada se
configura en la nueva máquina virtual de manera estática durante el aprovisionamiento. Esta es la opción
predeterminada dentro de vCloud Director y produce un error si se intenta realizar un aprovisionamiento
de máquina virtual sin un grupo de direcciones IP que tenga al menos una dirección de reserva asignada
a la red.
Figura 20. Asignación de direcciones de grupos de direcciones IP estáticas

En esta figura, se muestra el aprovisionamiento de una nueva máquina virtual “VM6” en una red llamada
“172.18.2.0_24”. Debido a que se está aplicando el método predeterminado de selección y asignación de
direcciones “Grupo de direcciones IP estáticas”, se elegirá una dirección de un grupo asignado a la red
(consulte la siguiente figura).
Figura 21. Configuración de grupo de direcciones IP estáticas de red de VDC de organización
A menos que esté habilitado el flujo de trabajo de redes mejorado en la página “Configurar redes” del
cuadro de diálogo de aprovisionamiento de vApp (consulte la siguiente figura), Grupo de direcciones IP
estáticas es la única opción disponible en la pestaña Especificaciones de red de la configuración de la
máquina virtual que se muestra en la Figura 21.
Figura 22. Habilitación del flujo de trabajo de redes mejorado
5.2.2 Asignación estática-manual

En muchos entornos de centro de datos, la opción preferida para los servidores es asignarles de manera
permanente una dirección IP fija. La administración se facilita al conocer que un servidor conserva su
dirección después de un reinicio. Sin embargo, en algunas soluciones, la dirección específica asignada a
una máquina virtual conlleva una importancia adicional. En ese caso, si se habilita el flujo de trabajo de
redes mejorado y se selecciona la opción Estática-Manual (consulte la siguiente figura), el usuario
puede seleccionar manualmente una dirección específica para asignarla a la máquina virtual que se está
aprovisionando.
Figura 23. Asignación estática-manual de direcciones

Hay una serie de puntos para tener en cuenta sobre la asignación manual de direcciones, incluidas las
siguientes:
 La dirección introducida manualmente se valida con la subred de la red y si la dirección está fuera de
la red asignada a la red, se produce un error.
 Una dirección introducida manualmente no se valida con otras asignaciones de direcciones que ya
se encuentran en la red, pero síse le realiza un seguimiento. En el cuadro de diálogo Asignaciones
de IP, se muestra cuáles de las máquinas virtuales se configuraron con las mismas direcciones,
siempre que se hayan configurado a través de vCloud Director, ya sea mediante la interfaz de
usuario o la API. Sin embargo, también debe tenerse en cuenta que vCloud Director no encenderá
una máquina virtual con una dirección IP duplicada mientras que esté haciendo el seguimiento (o
esté al tanto de él) de ambas asignaciones de la dirección.
 Si la dirección asignada proviene de un rango que ya tiene asignado un grupo de direcciones IP en la
red, se guarda la asignación y el uso del espacio de direcciones de red se actualiza para reflejar la
dirección recién asignada.
 Si la dirección se asigna desde la subred configurada en una red, pero no desde un grupo de
direcciones IP de esa red, se guarda la asignación, aunque no se calcula el porcentaje de uso para
esa red.
 Una vez que hay direcciones con seguimiento en uso en una red, no es posible asignar un grupo de
direcciones IP que contiene esas direcciones. No obstante, es posible crear varios grupos “en torno”
y “entre” ellas, pero los porcentajes de uso solo se calculan para los grupos de direcciones IP y no
para la subred completa.
La asignación manual de direcciones IP a las máquinas virtuales dentro de vCloud Director también
permite completar la flexibilidad, pero da por sentado que un usuario (o una llamada API) que elige la
asignación manual tiene una razón para hacerlo y es consciente de las consecuencias. Con la
personalización de invitado habilitada, la máquina virtual se configurará con la dirección IP especificada
que, si es incorrecta, podría causar problemas de servicio. La asignación manual de direcciones IP es útil,
por ejemplo, cuando la máquina virtual debe tener su dirección IP establecida sin la ayuda de la
personalización de invitado, pero el administrador desea realizar un seguimiento de la dirección utilizada
dentro de vCloud Director. Una asignación manual estática proporciona que se actualice la base de
datos de vCloud Director incluso si la dirección de la máquina virtual luego se debe establecer
directamente mediante el SO invitado.
5.2.3 Asignación de DHCP

Aunque vCloud Director puede administrar y realizar un seguimiento de la asignación de direcciones a
las máquinas virtuales, y asimismo puede realizar el seguimiento de las asignaciones manuales si se le
solicita, también es posible administrar las direcciones IP fuera de vCloud Director. Al seleccionar la
asignación de DHCP durante la creación de la máquina virtual (consulte la siguiente figura), vCloud
Director puede configurar el SO invitado compatible para que use DHCP a fin de obtener una dirección
IP durante la secuencia de arranque en lugar de hacerlo durante la configuración inicial.
Figura 24. Asignación de direcciones DHCP
Cuando una máquina virtual está configurada para usar DHCP a fin de obtener una dirección IP, se
requiere un servidor DHCP en la red a la que está conectado, o bien un “asistente” o “proxy” DHCP en la
red, que pueda enviar la solicitud de la máquina virtual para una asignación de direcciones a una entidad
en un red remota. vCloud Director no puede hacer el seguimiento del uso de la dirección cuando se
utiliza DHCP, pero es posible asignar parte del espacio de direcciones de una red de VDC de organización

a un grupo de direcciones IP (al que se le realizará el seguimiento) y parte a un ámbito DHCP (sin
seguimiento). Esto puede resultar útil en situaciones donde, por ejemplo, una parte de una pila de
aplicaciones es relativamente estática y el resto se amplía dinámicamente según sea necesario. La parte
estática debería utilizar un grupo de direcciones IP y las direcciones específicas asignadas a las cargas
de trabajo temporales deberían usar DHCP, debido a que no son significativas.
5.3 Administración de direcciones de Internet

Si se administran adecuadamente, las direcciones internas y “privadas” administradas por el proveedor
de servicios o el cliente tienen capacidad suficiente para que a todas las redes se les puedan asignar
subredes que aportan espacio para la expansión. Este no es el caso de las direcciones de Internet
“públicas” registradas, que son escasas. El acceso a Internet se presenta a un VDC de organización
como una red externa. Según la topología del centro de datos del proveedor, puede haber uno o varios
saltos de red entre el entorno de vCloud Director y el dispositivo de agrupación o acceso a Internet local.
Debido a que la topología precisa está fuera del alcance de este documento, aquísolo se considera el
dispositivo de enrutamiento final.
En la siguiente figura, se muestran los elementos de acceso a Internet del centro de datos. La red roja
muestra la red de acceso compartido a Internet que está conectada a un dispositivo ascendente de salto
siguiente. Como antes, el tenant 4 tiene un firewall físico externo; entonces, mientras que las puertas de
enlace de servicios Edge de los otros tenants tienen una conexión a la red externa de Internet, la puerta
de enlace de servicios Edge del tenant 4 está conectada a una red externa independiente de vCloud
Director con la interfaz “interna” del firewall físico como siguiente salto.
Figura 25. Red externa de Internet de vCloud Director
5.3.1 Red externa compartida de estructura jerárquica

En el ejemplo anterior, a la red externa de Internet se le asigna una subred /24 de clase C completa de la
cual se muestra solo el último octeto. La puerta de enlace de salto siguiente utiliza la dirección superior
en el rango (.254) y direcciones adicionales (.253 y .252 en el ejemplo), debido a que un dispositivo físico
puede ejecutar un protocolo de disponibilidad en hardware redundante. Las puertas de enlace de

servicios Edge del tenant están conectadas directamente a la red y tienen sus direcciones de interfaz
asignadas de .201 en adelante. Esto permite que se les asigne aproximadamente a 50 tenants una
dirección de puerta de enlace de servicios Edge del resto de las direcciones superiores en la subred.
Con 50 tenants y la puerta de enlace de salto siguiente asignada desde las direcciones de la subred /24,
la red “roja” aún tiene todas las direcciones de .1 a .200 disponibles para que los clientes utilicen los
servicios que desean que sean accesibles desde Internet. Estas direcciones pueden asignarse a los
clientes en rangos de cualquier tamaño determinado mediante un método denominado “subasignación”.
Consulte la sección 5.4, Subasignación de direcciones de red externa para obtener más información
sobre el proceso de subasignación. Cada tenant también debe tener la dirección de la interfaz de su
puerta de enlace de servicios Edge que le fue subasignada para que también se utilice para servicios de
tenant. Consulte la sección 5.3.3, Acceso saliente a Internet para obtener información sobre el uso de la
dirección de la interfaz para acceso saliente a Internet.
5.3.2 Red externa dedicada de tenant sencillo

El tenant 4 está consumiendo la dirección .204 en la red de Internet, pero lo hace en un dispositivo físico
fuera de vCloud Director. En este ejemplo, se asume una única dirección, pero en la práctica, un “par” de
firewalls de alta disponibilidad puede necesitar dos o tres direcciones. La puerta de enlace de servicios
Edge del tenant 4 necesita una conexión a una red externa, pero no puede usar la red de Internet “roja”,
por lo tanto, se necesitan una segunda red y la subred de direcciones asociada. Cada red pierde las
direcciones más altas y más bajas (direcciones de red y de difusión), además de las necesarias para las
dos interfaces de dispositivos conectados.
En una red /24, 2 direcciones de 256 es una proporción relativamente pequeña, pero si muchos tenants
requieren redes “amarillas” y estas son mucho más pequeñas en cuanto al tamaño de subred de
direcciones, se debe considerar la sobrecarga de perder cuatro direcciones de cada una. No obstante, la
red amarilla aún necesitará una subred de direcciones asignada. Ciertos protocolos y dispositivos de red,
como los utilizados en VPN, pueden ser poco tolerantes o verse complicados a causa de la presencia de
NAT, de modo que a la red amarilla, como a la red roja, se les debe asignar una subred de direcciones
de red pública de Internet, una que sea lo suficientemente grande para los requisitos del cliente, pero no
tan grande que resulte inútil. Esto representa un desafío para los proveedores de servicios con
direcciones IPv4 públicas limitadas. La conexión de los tenants a una red compartida empleando la
subasignación de direcciones constituye una forma más eficaz de proporcionar direcciones a puertas de
enlace de servicios Edge de tenants conectados.
En el caso del tenant 4 y los tenants conectados directamente, las direcciones en sus redes externas de
Internet, después de las asignadas a la puerta de enlace de servicios Edge de VDC de organización, se
pueden asignar a la NAT de origen o destino o a los VIP de servidor virtual del equilibrador de carga.
5.3.3 Acceso saliente a Internet

Para que las cargas de trabajo del tenant accedan a la red pública de Internet, sus direcciones internas y
privadas deben traducirse en direcciones públicas que puedan utilizarse en Internet. A diferencia de la
NAT de destino que se describe en la sección 5.1.1, Direcciones administradas por el proveedor de
servicios, cuando la conexión saliente a Internet necesita cambiar su dirección IP de origen, este proceso
NAT se conoce con más precisión como “NAT de origen” (Source NAT, SNAT). Una NAT de origen es
una asignación 1:1 entre la dirección IP utilizada por el dispositivo que se conecta a Internet y una
dirección de Internet adecuada asignada a ese dispositivo. Esta asignación 1:1 es necesaria, por lo
general, cuando el dispositivo en cuestión requiere conexiones entrantes no solicitadas para poder llegar
a él, como un servidor web o un host de transferencia de correo electrónico.
Sin embargo, a menudo uno o varios dispositivos en una solución pueden necesitar acceso a Internet,
pero no acceso entrante no solicitado desde Internet. Pueden ser servidores de aplicaciones que se
conectan a un origen de datos o actualizaciones en Internet, pero no deben recibir conexiones entrantes.
En casos como este, es posible “ocultar” muchos dispositivos detrás de una única dirección IP de
Internet. Por lo general, la dirección IP de origen de la conexión saliente de cada dispositivo cambia a la
dirección de la interfaz del dispositivo que realiza la traducción. El TCP de origen de la conexión o el

número de “puerto” de UDP cambian a un número seleccionado de forma aleatoria cuyo valor se rastrea
en una tabla de conexión para permitir que el dispositivo envíe la mitad entrante de la conexión al host
de origen correcto. Dado que cambian tanto la dirección IP de origen como la dirección del puerto del
protocolo de capa siguiente, esta versión de NAT se suele conocer como “puerto NAT” (Port NAT, PNAT)
o, más habitualmente, como “traducción de direcciones de puerto” (Port Address Translation, PAT).
En la siguiente figura, se vuelve a mostrar el diagrama de NAT de la Figura 18, pero esta vez se analizan
las conexiones salientes.
Figura 26. Traducción de direcciones salientes (SNA/PAT)
Como se indica en la sección 5.3.1, Red externa compartida de estructura jerárquica, la puerta de enlace
de servicios Edge debe tener su dirección de interfaz subasignada a símisma para que pueda usarse la
dirección para la PAT saliente.
5.4 Subasignación de direcciones de red externa

En un entorno de proveedor de servicios administrados, el espacio de direcciones IP en una red compartida,
como la red “Internet” en la Figura 25, está bajo el control del proveedor de servicios. Si las conexiones
del tenant a esa red fueran, por ejemplo, firewalls físicos por tenant bajo la administración del proveedor,
el consumo de direcciones en la red de Internet, por lo tanto, también seguiría bajo el control del proveedor.
La asignación de una dirección de Internet a un tenant determinado se lograría mediante la configuración
de NAT en el firewall adecuado, que respondería a los paquetes IP en la red de Internet destinada para
la dirección en la instrucción de NAT.
Como puede suceder en un entorno de proveedor de servicios de nube, si el cliente puede configurar sus
propias NAT de firewall o VIP de equilibrio de carga, estos pueden consumir, sin algún tipo de control,
tantas direcciones de Internet como deseen y, posiblemente, configuren una dirección que ya está en
uso en otro tenant en la red, lo que ocasionaría la interrupción del servicio. Para administrar este escenario,

vCloud Director presenta el concepto de “subasignación de direcciones”. Para que una puerta de enlace
de servicios Edge pueda consumir direcciones en una red externa (que no sean su dirección de interfaz
asignada), primero se le debe subasignar un rango de direcciones. Este es un proceso de dos etapas.
En primer lugar, la asignación de la subred de la red externa se realiza en el cuadro de diálogo de
propiedades Redes externas, como se muestra en la siguiente figura.
Figura 27. Asignación de direcciones IP de red externa
Luego, una vez que la red externa tiene al menos un grupo de direcciones IP asignado, el grupo puede
ser subasignado a las puertas de enlace de servicios Edge conectadas. La subasignación se realiza en
la configuración de la puerta de enlace de servicios Edge como se muestra en la siguiente figura.
Figura 28. Subasignación de direcciones de red externa
En este ejemplo, a la puerta de enlace de servicios Edge “ACME_GW2” se le asignó el rango de

direcciones de 100.64.67.20 a 100.64.67.29. Estas direcciones se encuentran en una red conectada, de
modo que no necesitan ser enrutadas específicamente a la puerta de enlace de servicios Edge y, por lo
tanto, no es necesario que se encuentren en los límites de la subred. Si el tenant necesita más direcciones en
el futuro, podrían agregarse con una asignación subsiguiente desde el grupo de direcciones IP. Si el
grupo de direcciones IP principal se agota, es posible agregar otro grupo de direcciones IP a la red externa
desde donde se pueden realizar más subasignaciones. Se debe tener cuidado al hacerlo, debido a que
el dispositivo de la puerta de enlace ascendente deberá configurarse con una dirección de interfaz
secundaria, y las configuraciones predeterminadas de la puerta de enlace y del enrutamiento se vuelven
más difíciles de configurar y solucionar si presentan problemas.

5.5 Enrutamiento en un entorno de proveedor de servicios de estructura

jerárquica
Como vCloud Director permite que los clientes (el proveedor de servicios) creen nuevas redes dentro de
sus VDC de organización del tenant o configuren servicios externos de WAN e Internet, es un requisito
hacer que las direcciones en cuestión sean accesibles desde redes externas. Aunque es posible administrar
esto mediante el enrutamiento estático, configurado en los dispositivos de enrutamiento de la solución,
los protocolos de enrutamiento dinámico proporcionan un mecanismo para automatizar la información de
distribución o de enrutamiento sin la necesidad de una intervención manual o una orquestación compleja
personalizada de la configuración de enrutamiento.
Por lo general, el enrutamiento del tráfico del tenant en un entorno de proveedor de servicios se divide en
dos categorías, red pública de Internet y red privada, por tenant. Cada uno de ellas se examina con más
detalle en las siguientes secciones.
5.5.1 Enrutamiento de Internet del centro de datos del proveedor

Teniendo en cuenta el modelo de la sección 5.3, Administración de direcciones de Internet, existen dos
tipos de direcciones que se deben anunciar desde el entorno de vCloud Director hacia el acceso de
Internet del centro de datos ascendente; y ambas son subredes asignadas a las redes externas de
“Internet” en la sección anterior. La red de Internet compartida “roja” está directamente conectada al
enrutador ascendente, por lo que figura de forma automática en la tabla de enrutamiento del enrutador.
Figura 29. Enrutamiento de Internet del proveedor
El primer intercambio de enrutamiento en esta figura es el anuncio de la subred interna F/W del tenant 4
a la puerta de enlace de salto siguiente de la red externa de Internet compartida. Esto es necesario
debido a que la red interna F/W no está conectada directamente a la red compartida de Internet y, de lo
contrario, sería inaccesible. La elección del protocolo de enrutamiento utilizado entre el firewall dedicado
y el enrutador ascendente depende de varios factores, aunque, por lo general, sigue la norma establecida
del proveedor de servicios. Algunos proveedores de servicios no ejecutan protocolos de enrutamiento

dinámico en firewalls físicos como medida de seguridad. Si este fuera el caso aquí, debería configurarse
una ruta estática en el enrutador de Internet compartido que dirija el tráfico a la subred interna F/W a
través de la dirección “.204” en la red conectada y compartida. De forma similar, el firewall dedicado
necesitará que su puerta de enlace predeterminada esté configurada en la dirección “.254” del enrutador
ascendente.
El segundo intercambio de enrutamiento sería el anuncio de la subred de Internet compartida (en este
ejemplo, 100.64.67.0/24) al enrutador de Internet de salto siguiente o ascendente del centro de datos del
proveedor. Por lo general, esto se lleva a cabo mediante el protocolo de puerta de enlace de borde (BGP)
y el sistema autónomo (AS) relativo dentro del cual los dos enrutadores determinarán si se trataría de un
BGP interno (iBGP) o un BGP externo (eBGP). Una vez que el enrutador de Internet compartido establece
una relación de emparejamiento con su vecino ascendente (2), anuncia la disponibilidad de la subred
conectada de Internet compartida y la subred interna F/W, que conoce a través del proceso de enrutamiento
dinámico o estático en (1).
Aunque no se señaló de forma explícita anteriormente, es posible que un cliente utilice direcciones de
Internet registradas en una red de VDC de organización. Estas pueden ser un rango asignado por su
proveedor de servicios o un rango de direcciones independientes de proveedor (Provider Independent
Address, PIA) que el cliente ya posee. Para ilustrar esto, la red web habitual en el VDC de organización
del tenant 1 en la siguiente figura se reemplazó por una red enrutada de “DMZ”. Aunque no aparece, la
red consistiría de direcciones de un rango de direcciones de red pública de Internet, con la interfaz de la
puerta de enlace de servicios Edge que consume una dirección y las direcciones utilizables restantes
asignadas a un grupo de direcciones IP para la asignación a vApps conectadas a la red.
Figura 30. Red de VDC de organización de la DMZ enrutada
5.5.2 Enrutamiento del centro de datos del proveedor por tenant

Como se indica en la sección 5, Administración de direcciones IP y enrutamiento, el proveedor o el
cliente pueden administrar las direcciones utilizadas en VDC de organización del tenant. En la mayoría
de las implementaciones, la persona que administra las direcciones debe hacerlo desde los rangos de
direcciones “privadas” proporcionados por RFC1918. Aún si se puede controlar su uso en el entorno del

proveedor, es probable que, en entornos WAN de clientes, las direcciones se superpongan entre los
clientes. Por este motivo, incluso cuando el proveedor garantiza que las direcciones en el centro de
datos son únicas, la necesidad de enrutar de forma exclusiva el tráfico hacia y desde las direcciones
WAN no exclusivas significa que deben mantenerse tablas de enrutamiento independientes para cada
tenant.
Uno de los casos donde esto no es necesario es cuando el proveedor utiliza direcciones registradas de
la red pública de Internet en la capa NAT de la red externa, que oculta completamente las direcciones de
red de VDC de organización del tenant y solo proporciona acceso externo a través de la red pública de
Internet. En este caso, tanto las direcciones (NAT) del tenant como las direcciones de conexión remota
son globalmente exclusivas, y se pueden compartir un enrutamiento único y una tabla de reenvío entre
todos los clientes utilizando los mismos mecanismos que se describen en la sección anterior.
Las direcciones del cliente que se superponen están separadas por las redes de VDC de organización
cuyo respaldo por VXLAN crea la misma separación de capa 2 que las redes tradicionales respaldadas
por VLAN. Las direcciones que se superponen pueden, por lo tanto, entrar en conflicto si las redes
separadas se conectaran luego a dispositivos compartidos de enrutamiento. En los ejemplos que se
utilizan en este documento, cada VDC de organización del tenant tiene una puerta de enlace de servicios
Edge dedicada y está conectada a la WAN del cliente respectivo a través de una red externa discreta de
vCloud Director. Por lo general, esta red respaldada por VLAN finaliza en un enrutador dedicado de CE
de WAN por tenant o un enrutador compartido de PE de estructura jerárquica en los que cada VLAN se
asigna internamente a un VRF por tenant (como se describe en la sección 4.2, Redes del centro de
datos de estructura jerárquica de vCloud Director en vSphere). La puerta de enlace de servicios Edge, el
enrutador de CE o el VRF de PE mantienen tablas de enrutamiento independientes, lo que permite que
cada cliente use direcciones idénticas dentro de sus organizaciones de tenants sin afectar a otros
tenants.
Figura 31. Emparejamiento del enrutador WAN por tenant

En esta figura, se muestra el emparejamiento entre cada puerta de enlace Edge de VDC de organización
del tenant y el enrutador de acceso WAN del cliente. La puerta de enlace de servicios Edge anuncia al
enrutador de acceso WAN las redes de VDC de organización a las que está conectada directamente, y
desde allílas anuncia al resto de la WAN del cliente. También se anuncian a su WAN las nuevas redes
de VDC de organización creadas por el proveedor de servicios o el cliente y que estén conectadas a su
puerta de enlace de servicios Edge correspondiente. Debido a que la puerta de enlace de servicios Edge,
por lo general, usa la ruta predeterminada hacia Internet, debe obtener los rangos de direcciones en uso
en la WAN para llegar a esos destinos. Para hacerlo, sea emplea el mismo protocolo de enrutamiento
que se utiliza para anunciar las redes de VDC de organización a la WAN, pero en la dirección opuesta.
La puerta de enlace de servicios Edge admite los protocolos de enrutamiento OSPF y BGP, que se
pueden utilizar para sistemas del mismo nivel con un enrutador de acceso WAN.
5.6 Consideraciones sobre IPv6

La versión actual de vCloud Director no puede administrar direcciones IPv6 para redes o dispositivos de
tenant. Algunos elementos de una solución de cliente, como el sistema operativo invitado de la máquina
virtual, y los componentes subyacentes de NSX pueden ofrecer compatibilidad con IPv6, pero se deben
administrar fuera del control de vCloud Director en sí.Si los clientes requieren IPv6 dentro de su organización
de tenant, se deben evaluar sus requisitos específicos para establecer si tiene sentido para el proveedor
de servicios alojarlos con un servicio administrado hasta que se lancen versiones de vCloud Director con
compatibilidad nativa.

6 Consideraciones comerciales
6.1 Autoservicio o servicio administrado
Los proveedores de servicios administrados de VMware han sido responsables de gran parte de la
configuración y la administración continua de las soluciones de sus clientes. Las oportunidades de
servicios de valor agregado durante el ciclo de vida de una solución han permitido que los proveedores
diferencien sus ofertas en función de sus áreas de experiencia. En algunos casos, los servicios de nube
con niveles más altos de automatización y estandarización pueden restringir oportunidades de
diferenciación.
Utilizar vCloud Director para ofrecer acceso directo a los clientes con el fin de administrar su configuración
de tenant no excluye que un proveedor de VMware Cloud pueda ofrecer servicios adicionales para
proporcionar diferenciación. Aunque esté fuera del alcance de este documento, el control de acceso
basado en funciones (Role-Based Access Control, RBAC) dentro de vCloud Director permite el control
detallado del acceso a muchas de las capacidades dentro de la interfaz de usuario de vCloud Director2.
Sin embargo, como se mencionó anteriormente, restringir la capacidad de los clientes de administrar los
cambios por cuenta propia puede verse como una limitación de la plataforma. Para maximizar los
beneficios de los clientes sin perder la capacidad de los proveedores de diferenciarse, vCloud Director
permite que tanto el proveedor como el cliente accedan a la solución a través de la misma interfaz.
Gracias a esto, los cambios realizados por cualquiera de las partes se aplican de forma coherente y se
reduce el riesgo de que el cliente afecte negativamente una solución que es responsabilidad del
proveedor dentro de un acuerdo de nivel de servicio.
La capacidad tanto para el proveedor como para el cliente de administrar la misma solución es
particularmente útil dentro de la parte de servicios de redes de un servicio de proveedor. Allí, los clientes
pueden tener habilidades internas para administrar las aplicaciones de negocios que residen en la
plataforma del proveedor, pero pueden no tener habilidades de seguridad o redes para configurar una
política de firewall de microsegmentación distribuida compleja. De forma similar, si el cliente desea
aprovechar el equilibrio de carga de NSX Edge, aunque comprenda los requisitos de equilibrio de carga
de sus aplicaciones, puede preferir que el proveedor de servicios sea responsable de adquirir, instalar y
administrar los certificados SSL para los mismos servicios.
Figura 32. Administrar certificados en la puerta de enlace de servicios Edge
El cuadro de diálogo de administración de certificados de vCloud Director puede ser bastante sencillo
para los ingenieros de entrega de contenido que comprenden las solicitudes de firma y las listas de
revocación, pero los clientes pueden estar dispuestos a pagar por esa experiencia de parte de su
proveedor de VMware Cloud.
2
La mayoría de los permisos de usuario se administran a través de la interfaz de usuario de vCloud Director, pero
algunos, especialmente los relacionados con las redes avanzadas y el firewall distribuido, deben administrarse
mediante la API de vCloud Director. Consulte la sección Referencias para obtener más información.

Si bien es solo un ejemplo, la administración de certificados SSL muestra que, con el simple hecho de
proporcionar acceso de cliente para administrar una parte de su servicio, el proveedor no descarta la
oferta de administrar los mismos servicios para su cliente. Incluso si un cliente intenta y no logra
configurar un elemento de su servicio por cuenta propia, el proveedor sabe que podrá acceder a la
configuración fallida a través de la misma interfaz que el cliente utiliza, ayudar al cliente a corregir el error
o asumir todo el control y completar la implementación en nombre del cliente. En cualquier caso, se
garantiza la satisfacción del cliente mediante la oferta de autoservicio, servicio de soporte o servicio
administrado, según sea necesario.
6.2 Licencias de productos adicionales

La implementación de vSphere en un entorno de alojamiento administrado requiere que los hosts y su
vCenter Server tengan las licencias apropiadas para habilitar el conjunto de funciones requeridas. De
forma similar, la introducción de vCloud Director y NSX requiere licencias apropiadas. Si los proveedores
de servicios utilizan los paquetes VMware vCloud Service Provider Bundle a fin de obtener licencias para
estado actual, el paquete de 5 puntos incluye vCloud Director3, pero no NSX. NSX para proveedores de
servicios está disponible en tres versiones diferentes según las funciones necesarias. Estas versiones se
conocen como NSX-SP Base, NSX-SP Advanced y NSX-SP Enterprise.
Si un pod de tenant no utiliza firewall distribuido, enrutamiento dinámico o conectividad VPN de 2 capas,
la puerta de enlace de servicios Edge (solo con enrutamiento estático) y las funciones de red basadas en
VXLAN están disponibles en la edición NSX-SP Base que se incluye en el paquete de 7 puntos
“Advanced”. Para habilitar el firewall distribuido y proporcionar los beneficios de la microsegmentación al
tenant, o agregar enrutamiento dinámico o VPN de 2 capas, las cargas de trabajo del cliente deben
obtener las licencias de NSX-SP Advanced, el cual se incluye en el paquete de 9 puntos “Advanced with
Networking”. Si el cliente requiere la integración de dispositivos físicos alojados externamente con sus
redes VXLAN, precisará NSX-SP Enterprise, el cual se incluye en el paquete de 12 puntos “Advanced
with Networking and Management”.
Es bastante probable que un proveedor de alojamiento administrado existente que presente servicios de
nube desee ofrecer el servicio a su base de clientes actual. Sin embargo, la disponibilidad de los
beneficios de NSX como la microsegmentación no garantiza que todos los clientes sean inmediatamente
elevados a un paquete de 9 o 12 puntos. Es posible utilizar VMware vCloud Usage Meter para informar
sobre varios tenants que usan funciones diferentes. De esta forma, el proveedor de servicios puede
incrementar las ventas de las nuevas prestaciones en su base de clientes existente para aumentar los
ingresos de acuerdo con el aumento en los puntos de licencia, en lugar de aumentar los costes antes de
que se generen ingresos incrementales para recuperar una inversión inicial.
En la siguiente figura, se muestra el modelo de centro de datos para proveedores de servicios utilizado
anteriormente con la adición de NSX-SP Advanced o Enterprise en algunos tenants, cuando otros solo
requieren NSX-SP Base con el resultante aumento menor en consumo de puntos.
3
Comparación de paquetes de productos mediante la guía de uso de productos VMware vCloud Air Network de T2
CY2017

Figura 33. Centro de datos de proveedores de servicios de nube con opciones de licencias por
tenant
En esta ilustración, el tenant 1 y el tenant 3 utilizan la puerta de enlace de servicios Edge en el modo
VMware vCloud Networking and Security™ y las redes lógicas VXLAN. Estas funciones, junto con
vCloud Director, se encuentran disponibles en el paquete de 7 puntos “Advanced”. El tenant 2 utiliza la
función de firewall distribuido que requiere NSX-SP Advanced, para el cual, a su vez, se requiere el
paquete de 9 puntos “Advanced with Networking”. Por otro lado (aunque no se muestra en el diagrama),
el tenant 4 utiliza funciones para las que se requiere NSX-SP Enterprise y el paquete de 12 puntos
“Advanced with Networking and Management”.
Es importante tener en cuenta que no se consumen puntos adicionales cuando el proveedor de servicios
pone a disposición las funciones en una ubicación determinada. El aumento en el consumo de puntos
solo se produce cuando el cliente de un proveedor de servicios adquiere servicios adicionales, lo que
también implica un aumento de los ingresos del proveedor de servicios.

7 Referencias
En la siguiente tabla, se detalla información adicional relacionada con este documento y sus temas.
Título del documento Vínculo o URL
VMware vCloud Architecture Toolkit for https://www.vmware.com/cloud-computing/cloud-

Service Providers architecture/vcat-sp.html
Blog de vCloud Architecture Toolkit (vCAT) https://blogs.vmware.com/vcat/
Arquitectura de soluciones de VMware https://www.vmware.com/content/dam/digitalmar

vCloud Director para proveedores de keting/vmware/en/pdf/vcat/vmware-architecting-
VMware Cloud a-vcloud-director-solution.pdf
Incorporación de clientes con los servicios de https://www.vmware.com/content/dam/digitalmar

VPN de 2 capas de VMware NSX para el keting/vmware/en/pdf/vcat/vmware-customer-
programa VMware Cloud Provider onboarding-with-nsx-l2vpn-services.pdf
Definición NIST de la computación de nube http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistsp

ecialpublication800-145.pdf
Informe de Forrester sobre la forma de https://www.vmware.com/ciovantage/article/forre

aprovechar la microsegmentación ster-report-available-zero-trust
Guía de diseño de virtualización de red de https://communities.vmware.com/docs/DOC-

VMware NSX for vSphere (VMware NSX for 27683
vSphere Network Virtualization Design
Guide)
Uso de la API de vCloud para otorgar https://kb.vmware.com/selfservice/microsites/sea

derechos de servicios de red avanzados y rch.do?language=en_US&cmd=displayKC&exter
firewall distribuido en vCloud Director 8.20 nalId=2149016
(Using the vCloud API to Grant Distributed
Firewall and Advanced Networking Services
Rights in vCloud Director 8.20)
Asignación de direcciones para conexiones a https://tools.ietf.org/html/rfc1918

Internet privadas
Guía de uso del producto vCAN https://vmware.my.salesforce.com/06980000000

bpky

Apéndice A: Aprovisionamiento de una red externa en vCloud

Director
En la sección 3.2, Topología de tenant básica de vCloud Director y la sección 3.3, Redes de estructura
jerárquica, se introdujo el concepto de una red externa con la que se conectan los recursos dentro de los
centros VDC de la organización de tenant a los recursos en el centro de datos del proveedor de servicios
de nube y sus superiores. Se mencionó en la Tabla 2. Jerarquía y elementos de red de NSX y vSphere
en vCloud Director que, como estas redes unen el dominio de administración de vCloud Director y el
centro de datos físico fuera del entorno de vSphere, no se pueden crear o administrar desde vCloud
Director únicamente. En la siguiente figura, se muestra la secuencia de actividades necesarias para
conectar un nuevo enrutador de CE WAN a una interfaz en una puerta de enlace de servicios Edge de
tenant recientemente aprovisionada.
Figura 34. Agregar una red externa nueva
En esta figura, se muestra la capa de vSphere en el análisis de redes de tenant de la sección 4.1, Redes
de tenant con la red externa de vCloud Director resaltada. En este ejemplo, se creará una nueva conexión
WAN entre el entorno de vSphere detrás del centro VDC de proveedor en el que se configuraron el centro
VDC de la organización de tenant y su puerta de enlace de servicios Edge. En la siguiente tabla, se
enumeran los detalles de la red nueva.

Tabla 3. Apéndice A: Parámetros de configuración
Elemento de configuración Detalle de configuración
ID de VLAN para acceder a WAN de tenant 1011
Subred VLAN 172.16.11.0/24
Dirección de interfaz de CE WAN 172.16.11.254
Dirección de interfaz de puerta de enlace de 172.16.11.1

servicios Edge
Pasos de la configuración
1. Cree el nuevo grupo de puertos distribuido respaldado por VLAN en la instancia de vCenter Server
del PVDC para conectar la red VLAN de acceso WAN (ya configurada dentro de la infraestructura de
red del centro de datos) con el conmutador vSphere dvSwitch.

2. Nombre y configure el nuevo grupo de puertos de DV.
3. Una vez que el nuevo grupo de puertos de DV se encuentre disponible en vCenter Server, se podrá
agregar como una red externa nueva dentro de vCloud Director. En la vista Redes externas de la
pestaña Administrar y supervisar de vCloud Director, haga clic en el icono verde con el signo “más”
para abrir el cuadro de diálogo Agregar red.

4. En el cuadro de diálogo Agregar red, seleccione la instancia de vCenter Server para mostrar las
redes de vSphere disponibles y seleccione la nueva red ACME_1_WAN con la red VLAN correcta a
su lado.
5. Cuando la red se muestre en la tabla inferior, haga clic en Siguiente para continuar.

6. A continuación, configure los detalles de direccionamiento IP de la nueva red. Gracias a esto, vCloud
Director puede conocer la dirección de puerta de enlace en el enrutador de CE WAN y el rango de
direcciones en la red nueva que puede asignar.
En este ejemplo, el grupo de direcciones que vCloud Director puede asignar se limita a las direcciones
entre 172.16.11.1 (que se utilizará para la dirección de la interfaz de Edge en un paso posterior) y
172.16.11.199. Es posible agregar al rango direcciones de 172.16.11.200 a 253, pero se retienen
para que el proveedor pueda liberar el resto y ofrecer asistencia en la expansión si el cliente se
queda sin direcciones.
7. Otorgue un nombre y una descripción a la red externa y haga clic hasta completar el cuadro de
diálogo para terminar de agregar la nueva red externa.

8. Las redes externas no se confinan a una sola organización dentro del VDC de proveedor con la instancia
de vCenter Server donde se configuraron. El proveedor de servicios debe, entonces, tener cuidado con el
siguiente paso para presentar la nueva red externa a la puerta de enlace de servicios Edge requerida. En
el menú Acciones de la puerta de enlace de servicios Edge, seleccione Propiedades.
9. En la pestaña Configurar redes externas del cuadro de diálogo Propiedades de la puerta de enlace
de servicios Edge, seleccione la nueva red externa de la lista en la tabla superior de redes
candidatas y haga clic en Agregar para copiar la red en la tabla inferior de redes conectadas.
10. En la pestaña Configurar valores de IP, seleccione el enlace Cambiar asignación de IP en la fila
de la red externa nueva para asignar manualmente la dirección.

11. En el cuadro de diálogo Cambiar asignación de IP, establezca el modo Asignación de IP en

Manual y escriba la dirección de la interfaz necesaria.
12. Si la nueva red será la ruta predeterminada de la puerta de enlace de servicios Edge, se debe
seleccionar la red externa en la pestaña Configurar puerta de enlace predeterminada. Debido a
que la red queda seleccionada, la puerta de enlace predeterminada configurada en el paso 6 debe
aparecer en la columna derecha. Tras finalizar los cambios, haga clic en Aceptar para cerrar el
cuadro de diálogo.
13. Una vez completada la configuración de la infraestructura, la puerta de enlace de servicios Edge
puede requerir cambios adicionales para agregar rutas estáticas adicionales y configurar el
emparejamiento a través de la nueva red, las reglas de firewall o las entradas NAT. Estos cambios
de configuración se realizan mediante la opción Servicios de puerta de enlace Edge del menú
Acciones de la puerta de enlace.

14. A continuación, se configuran las opciones en una pestaña nueva mediante la interfaz HTML5.

Vmware Architecting Tenant Networking With NSX in VCD PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Vmware Architecting Tenant Networking With NSX in VCD PDF

Cargado por

Copyright:

Formatos disponibles

VMware vCloud® Architecture Toolkit™

for Service Providers

2 | VMware vCloud® Architecture Toolkit™ for Service Providers

2 Redes de clientes en un entorno de proveedor de servicios .............. 9

3 Estructura jerárquica en un proveedor de servicios de nube ............ 16

4 Capas de redes examinadas ............................................................ 23

5 Administración de direcciones IP y enrutamiento ............................. 31

6 Consideraciones comerciales ........................................................... 44

3 | VMware vCloud® Architecture Toolkit™ for Service Providers

4 | VMware vCloud® Architecture Toolkit™ for Service Providers

Figura 29. Enrutamiento de Internet del proveedor .................................................................................... 40

5 | VMware vCloud® Architecture Toolkit™ for Service Providers

1.2 Objetivo y alcance del documento

6 | VMware vCloud® Architecture Toolkit™ for Service Providers

1.3 Definiciones, acrónimos y abreviaturas

1.3.2 Acrónimos y abreviaturas

AS El sistema autónomo (Autonomous System, AS) es una recopilación de nodos de enrutamiento

7 | VMware vCloud® Architecture Toolkit™ for Service Providers

8 | VMware vCloud® Architecture Toolkit™ for Service Providers

2 Redes de clientes en un entorno de proveedor de servicios

2.1 Topologías de red del cliente

9 | VMware vCloud® Architecture Toolkit™ for Service Providers

2.2 Replicación de una topología de cliente de servicios administrados

2.2.1 Topología tradicional de cliente de servicios administrados

10 | VMware vCloud® Architecture Toolkit™ for Service Providers

Figura 1. Ejemplo de topología de cliente de servicios administrados

2.2.2 La puerta de enlace de servicios NSX Edge

11 | VMware vCloud® Architecture Toolkit™ for Service Providers

 Enrutamiento: uso de rutas estáticas o protocolos de enrutamiento dinámico.

2.2.3 Topología de cliente de proveedor de servicios de nube básica

12 | VMware vCloud® Architecture Toolkit™ for Service Providers

Figura 2. Topología de cliente de proveedor de servicios de nube básica

2.2.4 NSX Distributed Firewall

13 | VMware vCloud® Architecture Toolkit™ for Service Providers

Figura 3. Microsegmentación con Distributed Firewall

14 | VMware vCloud® Architecture Toolkit™ for Service Providers

Figura 4. Topología básica de cliente con NSX Distributed Firewall

2.2.5 Compatibilidad de funciones de NSX adicional en vCloud Director

15 | VMware vCloud® Architecture Toolkit™ for Service Providers

3 Estructura jerárquica en un proveedor de servicios de nube

La introducción de servicios de nube permite consolidar esa capa de administración de virtualización en

16 | VMware vCloud® Architecture Toolkit™ for Service Providers

3.1 Estructura jerárquica de vCloud Director

Organización Una organización es un grupo lógico de todos los usuarios

Centro de datos virtual de Un VDC (centro de datos virtual) de proveedor es una

Centro de datos virtual de Un VDC de organización es un subconjunto de los recursos

17 | VMware vCloud® Architecture Toolkit™ for Service Providers

En las siguientes imágenes, se muestran estos conceptos.

18 | VMware vCloud® Architecture Toolkit™ for Service Providers

Figura 8. Asignación de VDC de proveedor a recursos de vSphere

3.2 Topología de tenant básica de vCloud Director

19 | VMware vCloud® Architecture Toolkit™ for Service Providers

Figura 9. Topología de cliente básica de vCloud Director

20 | VMware vCloud® Architecture Toolkit™ for Service Providers

3.3 Redes de estructura jerárquica

3.3.1 Capas de red en una plataforma de nube de estructura jerárquica

21 | VMware vCloud® Architecture Toolkit™ for Service Providers

22 | VMware vCloud® Architecture Toolkit™ for Service Providers

4 Capas de redes examinadas

4.1 Redes de tenant

23 | VMware vCloud® Architecture Toolkit™ for Service Providers

Figura 13. Redes de tenants de proveedor de servicios de nube

24 | VMware vCloud® Architecture Toolkit™ for Service Providers