Curso NSX

Introduccin a VMware NSX.
Conceptos iniciales
NSX es un nuevo producto de VMware el cual permite virtualizar las redes y seguridad. De
forma anloga a como el ESXi permite crear mquinas virtuales, NSX es el hypervisor que
virtualiza las redes y en s crean redes virtuales.
NSX es un software que se vende totalmente por aparte y se licencia por el nmero de
sockets.
En un Centro de Datos sin virtualizacin de servidores, toda la configuracin y polticas de
networking residen especficamente en la red fsica hardware fsico de la red, como Switches,
Routers, Firewalls, etc. Esto significa que la inteligencia reside en el Hardware, atndolo a un
vendedor especfico y requiriendo as una configuracin y gestin manual. A esto se le conoce
como Centro de datos definido por Hardware o HDDC, pos su siglas en ingles Hardware-Defined
Data Center.
Un Centro de Datos que emplea VMware vSphere virtualiza sus cargas de trabajo servidores
en mquinas virtuales, las cuales son ms fciles de crear, gestionar y editar, dando agilidad y
flexibilidad. Parte de la configuracin de Red en este caso se realiza en los switches virtuales
de VMware. VMware cuenta con dos tipos de switches virtuales:
Standard Switch vSS: Es un switch virtual que reside a nivel de host. Est incluido en
todas las ediciones de VMware vSphere. Su escalabilidad y gestin se complican a medida
que el centro de datos escala.
Distributed Switch o vDS: Es el segundo tipo de switch virtual de VMware y reside en
vCenter Server y no a nivel de Host. Es un Switch que centraliza la configuracin del
Networking del centro de datos virtual y a diferencia del Estndar, el Switch distribuido
requiere licencia Enterprise Plus. Algunas caractersticas nicas del vDS son:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
NIOC
Netflow (IPFIX)
QoS (CoS y DSCP)
Port Mirroring RESPAN Y ERESPAN
LACP por medio de LAG
VXLAN
PVLAN
ACLs
LLDP
Traffic Shaping In/Out, entre otras funciones
Un Centro de Datos que emplea NSX es un Datacenter que ya ha virtualizado con vSphere u
otros hypervisors de terceros. VMware NSX corre por encima de la capa de virtualizacin que
crea VMware vSphere o terceros. Cuando se utiliza NSX, se podra configurar toda la red y
polticas directamente en la capa de software y no en el Hardware, proporcionando ms

flexibilidad, independencia de la ubicacin y del Hardware fsico utilizado. A este enfoque se le
conoce como Centro de Datos definido por Software SDDC , por sus siglas en Ingls
Software-Defined Data Center. A diferencia del HDDC, en el SDDC la inteligencia corre
directamente en el software, permitiendo una configuracin y gestin automatizadas. En un
SDDC tambin es necesario virtualizar el Storage. En conclusin, un centro de datos definido
por software ha virtualizado:
Los servidores (VMware vSphere).

Las redes (VMware NSX).
El almacenamiento (vSAN).
Adicional, un SDDC puede automatizar los procesos con vRealize Automation. Puede tambin
hacer ms fcil la gestin y configuracin con vRealize Operations Manager. Finalmente puede
medir los costes mediante vRealize IT Business.
Los servidores fsicos que corren a nivel de bare-metal el ESXi se conectan de la siguiente
forma a las redes fsicas:
Figura 1 VMware NSX. Existing Physical Network

En la siguiente figura se puede ver claramente en dnde corre el ESXi y el vSwitch Switch
Virtual:
Figura 2 VMware NSX. Existing Physical Network and VMware vSphere
Finalmente en la siguiente figura se observa en dnde correra VMware NSX.
Figura 3 VMware NSX runs over vSphere

De la figura 3 notar que:
VMware NSX corre por encima de la infraestructura de Red Fsica y de la capa de

virtualizacin de VMware vSphere.
NSX trabaja por encima de red existente, sin la necesidad de modificar o reemplazar la
infraestructura de red actual y lo mejor, puede ser cualquier red fsica.
NSX utiliza la red existente como un Backplane IP. La configuracin se traslada a la capa de
software.
Los vSwitch de la figura 3 deben ser Distributed Switch. NSX no trabaja con el vSS. Por
tanto, la licencia requerida de los ESXi para emplear NSX debe ser Enterprise Plus.
NSX crea una capa de virtualizacin de red encima de la capa de vSphere, lo que podra
verse tambin como un Hypervisor de red.
Encima de esta capa de NSX se podrn crear finalmente redes virtuales o virtual networks,
como se muestra a continuacin:
Figura 4 VMware NSX. Virtual Networks
Sobre de la capa de virtualizacin de VMware vSphere se crean mquinas virtuales. De forma

similar, por encima de la capa de NSX se crean redes virtuales. VMware vSphere administra los
componentes de un servidor x86, tales como CPU, Memoria RAM, Red y Disco y los virtualiza
para las mquinas virtuales. Las mquinas virtuales cuentan con Hardware virtual, como vCPU,
vRAM, vDisks y vNICs:
Figura 5 VMware vSphere

En VMware NSX, no se crean maquinas virtuale sino redes virtuales. A diferencia de reproducir
atributos como CPU, Memoria, Disco y Red, NSX reproduce un conjunto de servicios de L2 a
L7, como Switching, Routing, Balanceo de carga, Firewall, QoS, etc.
Figura 6 VMware NSX
Pero qu es una red virtual o virtual network?

En VMware vSphere se habla de mquinas virtuales. En VMware NSX se crean redes virtuales.
Una mquina virtual es un conjunto de hardware virtual (vCPU, vRAM, etc), en donde se
instala un sistema operativo y el aplicativo. Una mquina virtual es un contenedor de software.
Una red virtual tambin es un contenedor de software que agrupa y entrega servicios de red,
tales como Enrutamiento, VPN, Conmutacin, Balanceo de carga, etc.
De forma similar a como una mquina virtual virtual se puede crear, guardar, mover, eliminar
y restaurar, una red virtual tambin puede ser creada, guardada, movida, eliminada y
restaurada.
Planos de VMware NSX

VMware NSX cuenta con 3 planos:
Data Plane
Control Plane
Managment Plane
Figura 1 VMware NSX. Planes

Plano de Datos (Data Plane)
El plano de datos consta de los siguientes componentes:
VMware Distributed Switch

Hypervisor Kernel Modules
NSX Virtual Switch
NSX Edge Services Gateway
VMware Distributed Switch: En el Data Plane es donde reside el Switch Distribuido de

VMware, el cual es un dispositivo virtual de capa 2 del modelo OSI.
Hypervisor Kernel Modules: En un proceso conocido como preparacin del Host, NSX
Manager instala tres VIBs vSphere Installation Bundles en los ESXi. Las VIBs son:
1. VXLAN: Permite el funcionamiento de VXLAN directamente en cada ESXi. Esto permite
principalmente la creacin de los VTEPs, los cuales sern puertos tipo vmkernel y los
encargados de encapsular y desencapsular el encabezado de VXLAN.
2. Distributed Logical Router: Es un Router Distribuido instalado en cada ESXi por el NSX
Manager y su funcin principal es la de enrutar trfico de Este a Oeste, es decir, el trfico
entre las VXLANs y/o VLANs.
3. Distributed Firewall: El ltimo componente es un Firewall Distribuido que permitir crear
reglas de Este a Oeste.
Notar que los anteriores VIBs no son Virtual Appliances sino servicios que corrern dentro de
los ESXi.
Nota: NSX Manager de forma ms precisa instala 5 mdulos de vmkernel:
1. VXLAN.
2. Distributed Logical Router.
3. Distributed Firewall.
4. Switch Security.
5. User World Agent.
NSX Virtual Switch: Cuando el Switch Distribuido cuenta con las tres VIBs toma la forma y
el nombre de NSX Virtual Switch. Dicho de otra forma este Switch Virtual es el Distributed
Switch Plus los VIBs. Este es el mismo Logical Switch.
NSX Edge Services Gateway: El NSX Edge Services Gateway es un Virtual Appliance
desplegado por el NSX Manager que ofrece diversos servicios, como Firewall, NAT, Balanceo e
carga, Enrutamiento de Norte a Sur, entre otros. Este componente literalmente se encuentra
en el borde entre el plano de datos y el plano de control.
Plano de Control (Control Plane)
En el Plano de Control se encuentran los siguientes componentes:
NSX Logical Router Control Virtual Machine: Es un virtual appliance y es desplegado

por el NSX Manager cada vez que se crea un Dsitributed Router. Recordar que el Router
distribuido en s se encuentra en el plano de datos pero su control es realizado por el NSX
Logical Router Virtual Machine. Este componente se estara encargando de entablar las
relaciones con otros routers para descubrir y formar las tablas de enrutamiento que luego
son pasadas tanto al NSX Manager como al NSX Controller. El NSX controller a continuacin
enva estas tablas de enrutamiento directamente a cada ESXi, de esta forma el Distributed
Router conocer cmo enrutar el trfico.
NSX Controller. Es otro virtual Appliance y es desplegado por el NSX Manager. Sus
funciones son varias:
1. Retener la tabla de direcciones MAC, ARP, vTEP y Enrutamiento.

2. Redistribuye la carga: NSX Controller redistribuye el rol de Logical Switch (VXLAN) y Logical
Routing.
3. Si se requiere, podra eliminar el enrutamiento de Multicast: NSX Controller puede eliminar
la necesidad de emplear PIM (Protocol Independent Multicast).
4. Eliminacin de los mensajes de broadcast. Si NSX Controller contiene la direccin MAC en
su tabla ARP de una mquina virtual, el ARP request puede ser atendido por este mismo.
User World Agent UWA. UWA es un agente instalado por NSX Manager a travs del
agente de bus de mensajes en cada host ESXi. Este agente consta de dos
servicios/demonios:
1. ntcpad: Se encarga de la comunicacin entre NSX Controller y los mdulos de Kernel

VXLAN y Distributed Router.
2. vsfwd. Media en la comunicacin entre NSX Manager y el mdulo de Kernel Distributed
Firewall.
UWA interviene en las siguientes comunicaciones:
Comunicacin entre NSX Controller y los host ESXi.
Comunicacin entre NSX Manager y los host ESXi.
Otra funcin de UWA es la de conseguir/recuperar informacin del NSX Manager a travs del
agente de bus de mensajes. Finalmente la comunicacin entre UWA y NSX Controller sucede a
travs de TCP over SSL (Puerto TCP 443).
Plano de Gestin (Managment Plane)
En este plano se encuentran tres componentes:
NSX Manager.
vCenter Server.
Agente de bus de mensajes Message Bus Agent. (RabbitMQ).
NSX Manager ya fue introducido al inicio de este Post y ser profundizado en el siguiente Post.
NSX Manager deber ser conectado en una relacin 1:1 con vCenter Server. El Agente de bus
de mensajes es el agente del Plano de Gestin que se comunica con el UWA para su instalacin
y posterior comunicacin entre NSX Manager y los ESXi. La comunicacin entre NSX Manager y
los ESXi se realiza entre el agente de bus de mensajes o RabbitMQ y el vsfwd.
El RabbitMQ es utilizado por NSX Manager para enviar informacin a los ESXi por el puerto
TCP 6871, tales como:
Enviar reglas de seguridad al firewall distribuido de los ESXi (vsfwd).

Enviar las direcciones IP de los nodos de NSX Controller.
Llaves privadas y certificados.
Peticiones de crear/eliminar routers distribuidos.
Instalacin y configuracin de NSX Manager 6.X

NSX Manager
Es un OVA y la nica entidad que se instala en la solucin de NSX. Todos los componentes
restantes, tales como NSX Controller, NSX Router Control Virtual Machine, entre otros, son
desplegados por el NSX Manager.
NSX Manager se integra en una relacin 1:1 con vCenter Server. En grandes proveedores de
nube la probabilidad de contar con varias instancias de vCenter Server es muy alta. Si por
ejemplo se tienen 5 instancias de vCenter Server se necesitaran entonces 5 instancias de NSX
Manager. NSX Manager y toda la infraestructura de NSX en s solo puede ser configurado por
el vSphere Web Client. Algunas funciones de NSX Manager son las siguientes:
Proporciona la interfaz grfica de administracin UI y la NSX API. La API permite que

cualquier CMP Cloud Managment Platform se integre con NSX
Instala en los host el agente UWA y los mdulos de Kernel (XVLAN, Distributed Router y
Distributed Firewall).
Configura el NSX Controller a travs del REST API. Los CMPs Cloud Managment Platform
tambin puede configurar el NSX Controller a travs de la REST API.
Configura los host a travs del bus de mensajes.
Genera y almacena los certificados para una comunicacin segura entre componentes.
Requerimientos de NSX Manager
12 GB de RAM.
60 GB de Disco.
4 vCPUs.
vCenter Server 5.5 y despus.
ESXi 5.5 y despus.
Si los ESXi fueron adicionados a vCenter Server por FQDN, habr que garantizar que esos
nombres puedan ser resueltos de forma directa e inversa.
Permisos para adicionar y encender mquinas virtuales.
Acceso y permisos al datastore en donde se desplegar y copiarn los archivos de NSX
Manager.
Cookies activados en el navegador.
Navegadores soportados: IE 8, 9 (Solo de 64 Bit) y 10. Adicionalmente las dos versiones
ms recientes de Mozilla y Chrome.
En cuanto a puertos:
Figura 1 NSX Manager Port Requirements
Instalacin y configuracin de NSX Manager 6.X

Paso 1: Descargar NSX Manager.
Paso 2: Desde vSphere Web Client, desplegar el OVA. Seleccionar la fuente.
Figura 2 NSX Manager Deploy VA Select Source

Paso 3: Revisar detalles. Aceptar opciones de configuracin extra.
Figura 3 NSX Manager Deploy VA Reviwe Details

Paso 4: Aceptar el EULA.
Figura 4 NSX Manager Deploy VA EULA

Paso 5: Definir nombre de la mquina virtual y folder de la vista de VMs and Templates en
donde ser ubicado.
Figura 5 NSX Manager Deploy VA Select name and folder

Paso 6: Definir en qu Datastore ser ubicada esta mquina virtual.
Figura 6 NSX Manager Deploy VA Select Storage

Paso 7: Configurar la red.
En destination seleccionar el grupo de puertos de mquina virtual en donde estar corriendo
el NSX Manager. Generalmente este es implementado en la red de Administracin. Desde esta
red, NSX Manager deber ser capaz de comunicarse con vCenter Server.
Figura 7 NSX Manager Deploy VA Setup Networks

Paso 8:
Definir la contrasea para ingresar por CLI o lnea de comando a NSX Manager. Esta clave
ser empleada ms adelante para iniciar sesin con el usuario admin.
Figura 8 NSX Manager Deploy VA Customize template CLI password
Especificar la contrasea para el modo privilegiado.
Figura 9 NSX Manager Deploy VA Customize template Privilege mode password
Network Properties: Definir el FQDN, IP, Mscara y default gateway de esta mquina
virtual. Se deber crear el registro A en los DNS.
Figura 10 NSX Manager Deploy VA Customize template Network Properties
Configuracin de DNS:
Figura 11 NSX Manager Deploy VA Customize template DNS
Configuracin de servicios tales como NTP y SSH. Se recomienda sincronizar el NSX

Manager y SSO bajo el mismo servidor NTP.
Figura 12 NSX Manager Deploy VA Customize template Services Configuration

Verificacin de la mquina virtual
Una vez desplegado el OVA nacer una nueva mquina virtual, con nombre segn el
especificado en el paso 5. Verificar que sta se encuentre encendida.
Figura 13 NSX Manager Virtual Machine

Configuracin de NSX Manager
Para la configuracin de NSX Manager es preciso ingresar con un navegador web a la UI
especificando la direccin IP dada en el paso 8. En este caso sera:
https://192.168.1.57
El usuario es admin. La contrasea es la que fue definida en el paso 8.
Figura 14 NSX Manager Login UI

La siguiente es la interfaz de administracin de NSX Manager. En esta interfaz se podrn
configurar aspectales como la red, registro de vCenter Server, NTP, Backups, etc.
Figura 15 NSX Manager User Interface Home Page

Para configurar los settings iniciales, dar clic en Manage Appliance Settings.
General
En General se podr configurar el reloj, syslog y la ubicacin.
Figura 16 NSX Manager User Interface General Settings
Network
Bsicamente los mismos settings configurados en el paso 8, como FQDN, IP, mscara, default
gateway y DNS.
Figura 17 NSX Manager User Interface Network

SSL Certificates: Permite generar o cargar certificados.
Backup & Restore: Salvaguardar o restaurar la configuracin del NSX Manager, la cual incluye
configuracin del sistema, eventos y tablas de logs (audit logs del firewall distribuido). El
Backup puede ser sacado manualmente a travs de la GUI o programado para realizarse
peridicamente.
Nota: La configuracin del sistema, eventos y logs son almacenados en la base de datos
embebida vPostgres de NSX Manager.
Nota: La restauracin del backup es posible solo en una instancia de NSX recin desplegada.
Upgrade: Realizar actualizaciones a partir de ficheros entregados por el centro de soporte de
VMware.
NSX Manager Service:
Este es el punto ms importante. Se deber definir quin es vCenter Server y Lookup Service.
Nota: El puerto por defecto de Lookup service es 7444.
Figura 18 NSX Manager User Interface NSX Managment Service
Nota: La opcin Modify plugin script download location permite definir la IP y puerto de NSX
Manager. Se requiere esta configuracin en ambientes con NAT.
Finalmente:
En el web client deber aparecer Network and Security, el cual permite configurar y
administrar NSX:
fIGURA 19 NSX Manager Network and Security
Figura 20 NSX Manager Network and Security NSX Home
VMware NSX Controller

Es tiempo de hablar acerca de NSX Controller, el cual es otra mquina virtual que se estara
encargando de varias funciones, como las tablas de ARP, enrutamiento, MAC y VTEP.
VMware NSX Controller
Recordar de la Parte 2 de esta serie de Post que NSX cuenta con tres planos. En el plano de
control se puede hallar a NSX Controller.
NSX Controller es el encargado de almacenar cuatro tablas:
Tabla
Tabla
Tabla
Tabla
ARP
MAC
VTEP (Para el funcionamiento de VXLAN)
de enrutamiento
Tambin es el encargado de:

1. NSX Controller cuenta con dos Roles utilizados por las cargas de trabajo. El primero es el
rol de Distribuir las VXLAN y el segundo el de Informacin de red de enrutamiento lgico. Al
primer Rol se le puede resumir como VXLAN y al segundo Logical Router, aunque
ciertamente el primer rol es ms conocido como Logical Switch.
Figura 1 NSX Controller Roles

Es interesante saber que estos dos Roles son distribuidos a travs del Clster. NSX
Controller puede ser desplegado como una nica mquina virtual, pero tambin pueden ser
desplegadas varias instancias, formando as un Clster. La idea de un clster permite
escalabilidad y disponibilidad.
Nota: VMware recomienda que el clster sea formado por tres instancias o tambin conocido
como Nodos.
Nota: Nodo es lo mismo a instancia como a mquina virtual de NSX Controller.
Nota: NSX Controller en realidad dispone de 5 roles.

Nota: El mximo nmero de nodos por clster es de tres.
Nota: El rol de Distributed Router y Logical Switch es en realidad el mismo rol, llamado
Directory Services.
Cada rol necesita un maestro, por tanto un proceso de eleccin se lleva a cabo para elegirlos.
VMware se basa en un algoritmo Paxos para llegar a un consenso y elegir un maestro por
cada rol. Es decir que habr un master para el Rol de VXLAN y un master para el de Logical
Router. Podra suceder que un nodo tenga ambos maestros, es decir, que una mquina virtual
de NSX Controller posea tanto el rol de Logical Switch como el de logical router o podra
suceder tambin que en un nodo cuente con el rol de Logical Switch y otro nodo el de logical
router.
Figure 2 NSX Controller Master Failure

En la figura 2 notar que se tiene un clster con tres nodos, A,B, y C. Paxos ha llegado a un
consenso y ha decidido que el nodo B sea el maestro tanto del rol de Logical Switch como el
de Logical Router. Una funcin vital del maestro es la de repartir de la carga de trabajo
de forma uniforme entre los nodos. Llmese a carga de trabajo tanto Logical Switch como
a Logical Router. Ahora, si por ejemplo el Nodo B falla, el clster inicia un nuevo proceso de
eleccin entre A y C. El nuevo maestro de cada rol debe reasignar las cargas de trabajo que
estaba ejecutando B y debe hacerlo entre A y C.
NSX Controller debe en conclusin distribuir las cargas de trabajo (Logical Switch y Logical
Router) entre todos los nodos, pero tambin debe redistribuir las cargas cuando falla un nodo
o cuando se ingresa un nuevo nodo al clster y todo esto de forma transparente para las
aplicaciones. VMware ide un mtodo para garantizar esta distribucin y redistribucin. La
solucin fue el Slicing o rebanadas.
En el Slicing:
Por cada rol se crea un nmero de rebanadas: NSX Controller primero debe ser conciente
de cuntos Logical Switch y Logical Routers existen y cul es el nmero de nodos de NSX
Contoller. Con base en esto, divide los LS y LR entre todos los nodos del clster.
El maestro de LS Logical Switch divide los LS en rebanadas y los asigna a los distintos
nodos.
El maestro de LR Logical Router divide los LR en rebanas y los asigna a los distintos
nodos.
Por ltimo, los objetos son asignados a los slices.
Notar que el maestro tambin se estara encargando de realizar esta tarea. Suponer en un
ejemplo que se han creado 9 slices por cada rol en un clster con tres nodos.
Figura 3 NSX Controller Slices
Suponer tambin que los nueve primeros en color azul son slices para los LS y los 9 restantes
para los LR.
A continuacin se definen los objetos que sern rebanados:
Figura 4 NSX Controller Objects

Por ltimo los objetos son asignados a los slices:
Figura 5 NSX Controller Objects assigned to slices

Cmo serian repartidos estos slices a cada uno de esos tres nodos? Una idea podra darla la
siguiente figura:
Figura 6- NSX Controller Slicing

En conclusin, las tareas del maestro son:
Distribuir los slices entre los nodos del clster.

Redistribuid las cargas de un nodo fallido entre los nodos activos.
Redistribuir las cargas cuando un nuevo nodo es insertado en el clster.
Redistribuir las cargas cuando un nodo regresa despus de haber fallado.
Monitorear el estado de los nodos

Informar a los ESXi si un nodo ha fallado o cuando ste se ha recuperado.
2. NSX Controller tambin se encarga de recibir informacin de los ESXi y el NSX Logical
Router Virtual Machine acerca de lo que han aprendido a nivel de red, como tablas VTEP en el
caso de los ESXi y tablas de enrutamiento para el caso de NSX Logical Router Virtual Machine.
Mediante el agente de UWA los ESXi pueden tener comuinicacin con NSX Controller.
3. Podra remover el enrutamiento de multicast y la necesidad de configurar el protocolo PIM
en la red fsica. Para ms informacin acerca de esto visitar el Post: VMware NSX Modos de
Replicacin
4. Podra remover el trfico de broadcast. Si por ejemplo una mquina virtual enva un
ARP request en busca de la direccin MAC de otra mquina virtual, este broadcast es
capturado por el ESXi y por medio de UWA enviado al NSX Controller. NSX Controller busca la
direccin MAC para esa direccin IP en su tabla ARP y si tiene una entrada para esta, devuelve
la direccin MAC al ESXi. En este caso se suprime un broadcast que no estara viajando por la
insfraestructura, ahorrando ancho de banda.
5. NSX Controller emplea certificados autogenerados por NSX Manager para la comunicacin
de forma segura con otros componentes de la solucin.
Primero, NSX Manager crea certificados autogenerados. A continuacin estos son almacenados
en su base de datos. Cuando un NSX Controller es desplegado, NSX Manager le da el
certificado. A continuacin y empleando el Bus de mensajes, NSX Manager instala los VIBs en
los ESXi. La comunicacin entre los ESXi y NSX Controller se da a travs de UWA. Finalmente
la interaccin entre NSX Manager y NSX Controller y NSX Controller con ESXi se da a travs de
SSL.
Cmo desplegar NSX Controller
Para desplegar NSX Controller no es necesario descargar un OVA u OVF. Recordar que NSX
Manager es el encargado de facilitarnos esta tarea.
NSX Controller requiere:
NSX Manager previamnete instalado y lincado con vCenter Server.

4GB de RAM por cada nodo.
20 GB de disco por nodo.
4 vCPUs por nodo.
Paso 1. Ir a Network and Security y despes clic en Installation.
Figura 7 NSX Controller Deployment Installation

Paso 2. A la derecha, clic en + debajo de NSX Controller Nodes.
Figura 8 NSX Controller Deployment Add NSX Controller Node

Paso 3. Especificar:
NSX Manager: La instancia de NSX Manager en la cual este NSX Controller ser
registrado.
Datacenter: En qu Datacenter lgico ser ubicada esta mquina virtual.
Cluster/Resource Pool: En este punto se debe definir en qu clster o pool de
recursos se destinar esta mquina virtual.
Datastore: Elegir el datastore en dnde se ubicar la mquina virtual.
Host: Definir el ESXi en donde correr la mquina virtual.
Coonected to: Especificar el grupo de puertos de mquina virtual a dnde se conectar

NSX Controller. Es importante que esta red pueda alcanzar a NSX Manager. Generalmente
se conecta a la red de administracin.
Password: La clave para ingresar por CLI. Es importante que esta misma clave sea
especificada en cada nodo del clster.
Figura 9 NSX Controller Deployment Add Controller

En IP Pool se crea un pool de IPs para que cada Nodo de NSX Controller pueda contar con una
direccin IP. A medida que se vayan desplegando nuevos nodos, NSX Manager destina una IP
de este pool. En IP Pool seleccionar la opcin New IP Pool:
Figura 10 NSX Controller Deployment Add IP Pool

Nota: Si no est seguro acerca de qu informacin especificar en la figura 10, consultar con el
administrador de la red. Lo que si es cierto es que este Pool debe tener informacin (IPs)
acorde con la red escogida en Connected to de la figura 9.
Ya est todo listo, finalmente dar clic en OK para dar inicio al despliegue del primer NSX
Controller:
Figura 11 NSX Controller Deployment
Paso 4. Monitorear el estado del despliegue. En status verifcar el estado del deployment de
esta mquina virtual. Se ver como Deploying mientras NSX Manager est creando y
configurando la VM. Pasar a Normal una vez est listo:
Figura 12 NSX Controller Deploying Virtual Appliance

Nota: Este proceso puede tomar varios minutos. Se est copiando una mquina virtual y
despus se encender y configurar automticamente por primera vez.
Tras el despliegue, encendido y configuracin inicial, la mquina virtual de NSX Controller
debera verse de la siguiente forma:
Figura 13 NSX Controller Virtual Machine

Verificacin de NSX Controller
Con la ayuda de un cliente SSH ingresar a NSX Controller. Segn la figura 13 la IP de esta
primera instancia de NSX Controller es 192.168.1.170. El usuario es admin y la contrasea es
la especificada en la figura 9.
show control-cluster status
Una vez se encuentre en el NSX Controller va SSH, ingresar el siguiente comando:

show control-cluster status
Figura 14 NSX Controller Commands Show control-cluster status
Join status: Muestra el estado actual de unin al clster de este NSX Controller. El
resultado del comando muestra que se encuentra en Join Complete y desde cundo
(01/07 16:34:28).
Majority status: Muestra si el controlador se encuentra activo. El resultado Connected
to cluster majority significa que este nodo se encuentra activo y parte de la mayora de
los nodos. Si hay un nodo la mayora es 1. Si hay dos la mayora tambin es dos. Si hay
un clster con tres nodos la mayora es 2 tambin. Recordar que el maestro se elige
basado Paxos. Paxos emplea un consenso de votos, donde la mayora de votos (cantidad
de nodos que votan) adquirida por un nodo, ser el maestro.
Restart status: Muestra si este nodo puede ser reiniciado de forma segura.
Cluster ID: Aqu se puede encontrar el identificador del clster, un nmero de 32 dgitos
hexadecimales que identifican un clster y es automticamente generado durante el
despliegue del primer nodo.
Node UUID: Otro identificador de 32 dgitos hexadecimales que identifican un nodo de
forma nica. Este tambin es generado automticamente durante el despliegue de este
primer nodo.
Role: Permite ver los distintos Roles, estado de configuracin y estado activo.
De lo anterior se puede decir que:
Hay 5 roles habilitados (enabled) y activados (actived).

Este controlador puede ser reiniciado de forma segura (safely restarted). El comando para
reiniciar un NSX Controller es restart controller.
Este controlador est atado/unido a un clster identificado con el ID 13cc8298-7071-44bf968e-5f2027b03031. Todos los demas nodos que sean desplegados deberan ser atados al
mismo ID de clster.
Segn la figura 14 hay 5 roles:
API Provider.
Persistence Server.
Logical Manager.
Switch Manager
Directory Services.
API Provider: Maneja las peticiones HTTP (web services API) de clientes externos como el NSX
Manager.
Persistence Server: Almacena datos como por ejemplo los vDS (Informacin del estado de la
red) que deben persistir en todos los nodos del controlador, asegurando que la prdida de un
nodo no conlleve a la prdida de datos.
Logical Manager: Monitorea si los ESXi se conectan o abandonan los vDS con el fin aplicar las
polticas y topologa de la red.
Switch Manager: Es quien administra los ESXi, envandoles informacin y configuracin.
Tambin mantiene conexiones de administracin con los vDS.
Directory Services: Administra los Logical Switches (VXLAN) y el Distributed Logical Router.
show control-cluster startup-nodes
Para verificar las direcciones IP de los nodos activos en el lster, dar el siguiente comando:
show control-cluster startup-nodes
Figura 15 NSX Controller Commands Show control-cluster startup-nodes

Hasta ahora se ha desplegado solo un NSX Controller. El resultado del comando de la figura 15
refleja esa realidad.
show control-cluster roles
Para ver un reporte ms detallado acerca de los roles, dar el siguiente comando:
show control-cluster roles
Figura 16 NSX Controller Commands Show control-cluster role

De la figuras 16 puede notar que etse nodo es el maestro de todos los 5 roles. Es normal ver
api_provider como Not Configured.
show control-cluster connections
Otro comando til es connections, el cual permite ver qu conexiones tiene el contralador
actualmente y qu tipos de conexiones emplea.
show control-cluster connections
Figura 17 NSX Controller Commands Show control-cluster connections

En la figura 17 se puede apreciar que:
Hay 4 roles que tienen componentes que activamente estn escuchando en un puerto de
red.
Existen 7 puertos usados para las comunicaciones de estos 4 roles. Los puertos son el 443,
2878, 2888, 3888, 6632, 6633 y 7777.
El puerto 2878 no est siendo usado por este nodo (-). Este puerto ser empleado (Y) si
este nodo fuera el maestro y tambin si en este clster hay mas de un nodo. Aunque este
nodo es le maestro es el nico nodo, por tanto este puerto no se usa. Si por ejemplo
hubieran 3 NSX Controllers (3 nodos), este nodo podra ser el maestro y en el puerto 2878
dira Y (Yes) y la cantidad de conexiones abiertas sern 2 (una para el nodo 2 y otra para
el nodo 3).
Nota: Para una lista ms detallada de comandos, visitar:
https://pubs.vmware.com/NSX-6/topic/com.vmware.ICbase/PDF/nsx_60_cli.pdf
A continuacin se recomienda desplegar dos nodos ms empleando los mismos 4 pasos
descritos anteriormente. VMware NSX Manager automticamente ata los nodos al clster, elige
los maestros, divide las cargas de trabajo y asigna los slices a cada nodo.
VMware NSX Introduccin a la VXLAN

Por aos la tecnologa de las VLANs han suplido distintas necesidades a nivel de seguridad,
segmentacin/aislamiento, reduccin del broadcast y administracin. Hoy en da siguen siendo
ampliamente utilizadas por pequeas, medianas y grandes empresas en todo el mundo; sin
embargo, para algunos tipos de negocio el nmero de VLANs disponibles es pequeo. Por citar
un caso se puede observar a los Proveedores de Servicios de Nube. Para un proveedor de este
tipo, el cual puede llegar a tener muchos clientes y cada uno de estos distintas redes, 4096
VLANs o redes es poco. Aqu es cuando entra a jugar la VXLAN en cuyo caso permite ms de
16 millones de segmentos de red.
VXLAN: Introduccin
VXLAN es una tecnologa tipo Overlay Network. Por Overlay Network se entiende como una
red lgica creada encima de una red fsica existente. En algunos casos incluso puede ser
independiente de la red fsica. Para que una red sea catalogada Overlay Network debe
cumplir con lo siguiente:
Ser una red lgica.

Contar con un proceso de encapsulacin/desencapsulacin.
Comunicacin desarrollada entre un tnel establecido por dos terminales.
VXLAN cumple con estas tres consideraciones:
Ser una red lgica: VXLAN por sus siglas en ingls Virtual Extensible Local Area Network
es una tecnologa que permite segmentar las redes de forma virtual/lgica.
Contar con un proceso de encapsulacin/desencapsulacin: VXLAN encapsula la trama
Ethernet original (la trama ethernet de la mquina virtual) en un paquete UDP.
Comunicacin desarrollada entre un tnel establecido por dos terminales: En VXLAN el
encargado de encapsular y desencapsular las tramas ethernet de las mquina virtuales es
el VTEP Virtual Tunnel Endpoint. El VTEP es un vmkernel port en un ESXi. Cada Host (en
realidad clster) que desee participar en una red VXLAN deber tener el VTEP (vmkernel
port) instalado y funcionando.
VXLAN aunque no ha sido estandarizada ya ha sido enviada a la IETF. Fue desarrollada

inicialmente por variascompaas, como VMware, Arista Networks y Cisco. VXLAN permite
extender redes de capa 2 a travs de los lmites de red de capa 3. Mediante la encapsulacin,
VXLAN ampla el nmero de redes de capa 2 con la ayuda de un Identificador de Red Virtual
VNI VXLAN Number Identifier, el cual tiene una longitud de 24 bits. Con 24 bits se puede
tener hasta 16777.216 de redes lgicas, mucho mayor que las 4096 proporcionadas por las
VLAN.
Dada la anterior introduccin es hora de profundizar en cada concepto. Se comenzar por los
VTEP.
VTEP: Virtual Tunnel End Point

VTEP es el encargado de encapsular y desencapsular el trfico de las mquinas virtuales en
paquetes o encabezados UDP.
Nota: Para una mquina virtual las VXLAN sern totalmente trasparentes.
A continuacin suponer que se tiene dos Cluster (A y B). En el Cluster A ha sido configurada la
VLAN X y el Cluster B la VLAN Y.
Figura 1 VXLAN Without VXLAN

Como se puede ver en la figura 1 no existe configuracin de VXLAN. Para que las mquinas
virtuales de la VLAN X del cluster A logren comunicarse con las mquinas virtuales de la VLAN
Y del cluster B es necesario contar con un router que interconecte ambos cluster.
Nota: Notar que hay dos redes distintas (VLAN X y Y).
Al configurar VXLAN, la figura 1 ahora se vera de la siguiente forma:
Figura 2 VXLAN With VXLAN

En este caso ya no es necesario contar con un router. Las mquinas virtuales del cluster A y
del B pueden estar en la misma red de capa 2 (mismo dominio de broadcast de capa 2). Las
VLANs no son necesarias ya que la VXLAN en si est garantizando el aislamiento.
Nota: VXLAN Wire es una representacin lgica de la conexin entre dos VTEPs.
Nota: Vale la pena resaltar que VXLAN solo encapsula y de ninguna manera cifra la
informacin.
Host Preparation
En un post anterior sobre los planos de NSX se explic que VMware NSX Manager instala tres
VIB vSphere Installation Bundles en los ESXi en un proceso conocido como Host
Preparation. Los VIBs son:
VXLAN.
Distributed Logical Router.
Distributed Firewall.
Nota: Estos VIBs son instalados directamente en el ESXi. Tambin se conocen como
Hypervisor Kernel Modules. A parte de los tres VIBs mencionados, NSX Manager tambin
instala dos mdulos adicionales: Switch Security Module y el agente UWA.
En cuanto a VXLAN se refiere, NSX Manager prepara los ESXi instalando y configurando en
stos los VTEPs. Los pasos para realizar esta labor son los siguientes:
Paso 1: Conectado a vCenter Server con el Web Client, ir a Home, Inventories, Networking and
Security:
Figura 3 VMware NSX Networking and Security

Paso 2: En la barra lateral izquierda, seleccionar Installation y luego en Host Preparation:
Figura 4 VMware NSX Host Preparation
Nota: En Installation Status notar que la opcin es Install. Esto significa que el Clster Gold
no tiene an instalado los tres mdulos de Kernel (VXLAN, Logical Distributed Router y Logical
Distributed Firewall). Notar tambin que no da la opcin de escoger un ESXi en particular; en
vez de eso se debe seleccionar es en qu Clsteres se desea instalar los mdulos.
Paso 3: Para cada Clster de inters, clic en Install. Se podr monitorear el estado de la
instalacin en Installation Status:
Figura 5 VMware NSX Installation Status Installing

Cuando NSX Manager est instalando los mdulos o VIBs en el ESXi, se puede observar la
tarea de instalacin en Recent Tasks:
Figura 5a VMware NSX Recent Task Installing VIBs

Tras finalizar la instalacin, NSX Manager habr instalado los siguientes VIBs en el ESXi:
esx-dvfilter-switch-security
esx-vsip: VMware internetworking Service Insertion Platform (Distributed
Firewall).
esx-vxlan
A continuacin y modo de demostracin, se conectar a un ESXi por medio de SSH para

verificar el mdulo de VXLAN (esx-vxlan) con el comando esxcli software vib get vibname
esx-vxlan:
Figura 5b VMware NSX esx-vxlan vib

La clave para conocer si la instalacin finaliz consiste en observar el campo Installation
Status. Cuando pase a Unistall significa que se encuentra listo.
Figura 6 VMware NSX Installation Status Installed

Notar en la figura 6 que la opcin Configure de VXLAN est ahora habilitada.
VXLAN Encapsulated Frame
VTEP es el encargado de encapsular y desencupsular la trama ethernet original de las mquina
virtuales. A continuacin se detallar en qu consiste este proceso de encapsulacin.
La siguiente es la trama XVLAN para IPV4:
Figura 7 VXLAN Encapsulated Frame for IPv4

Nota: En la figura 7 se puede apreciar dos conceptos Inner y Outer. Inner hace referencia a
la trama ethernet original, es decir, la trama que enva una mquina virtual. Por otro lado
Outer establece los campos/encabezados que estar instalando el VTEP dentro del proceso de
encapsulacin.
De derecha a izquierda:
Inner L2 Header and Payload: Esta es la trama original Ethernet de capa 2 de la mquina
virtual. Sus campos son:
Destination Address (4 bytes): Direccin MAC de destino (direccin MAC a quin va

dirigida la trama) con la cual la mquina virtual de origen se desea comunicar. Esta
direccin puede ser la MAC de un dispositivo fsico o virtual siempre y cuando la IP de
destino est en la misma red que la mquina de origen. Tambin podra ser la MAC del
default geteway si la direccin IP de destino est en otra red.
Source Address (4 bytes): Esta es la direccin MAC de la mquina virtual que enva la
trama.
VLAN Type 0x8100 (2 bytes): Solo s esta mquina virtual de origen se encuentra en un
grupo de puertos de mquina virtual configurado con una VLAN, el switch virtual (sea el
Standard o Distributed) debe colocar un Tag, cuyo valor puede variar entre 1 y 4094. En
caso de ser as, en la trama ethernet original VMware debe agregar un campo de 2 bytes
justo despes del Source Address. Este campo siempre ser 0x8100 (cuatro dgitos
hexadecimales lo que equivale a 16 bits) indicando que la trama ethernet ha sido
modificado para llevar un VLAN ID, es decir, una VLAN. Por otro lado, si la mquina virtual
se encuentra conectada a un grupo de puertos de mquina virtual que no precisa de un
tag, es decir que el valor del VLAN es cero, el grupo de puertos no coloca un tag a la
trama de la mquina virtual y este campo no se emplear. En conclusin, este campo es
opcional y podra o no emplearse dependiendo si las VLANs son o no utilizadas.
VLAN ID (2 bytes): El campo de VLAN ID est compuesto por tres campos; User Priority
con 3 bits, CFI con 1 y finalmente VLAN ID con 12. La funcin de User Priority es la de
proporcionar QoS o calidad de servicio de capa 2, tambin conocido como Class of Service.
Al tener 3 bits establece 8 posibles valores para QoS. CFI o Canonical Format Indicator
es un campo que ayuda a identificar si los 12 bits siguientes de VLAN ID son para el
protocolo Ethernet o Token Ring. Si este valor es 0 significa que es Ethernet. Si es 1 es
Token Ring. El ltimo campo, VLAN ID, se emplea para identificar la VLAN (Tag). Al tener
este campo 12 bits da la posibilidad de tener hasta 4096 VLANs.
Ethernet Type 0x0800 (2 bytes): Este campo indica el tipo de protocolo que contiene
los Datos o Payload. Si los datos o payload estn basados en IPv4, este campo ser
0x0800. Si fuese por ejemplo IPv6 sera entonces 0x86DD.
Payload o Datos (1500 bytes): Aqu viene los datos que entrega la capa 3 o capa de
red. Recordar que la capa de red del modelo OSI se encarga de fragmentar los datos. Los
fragmentos tendrn un tamao igual a la MTU, es decir, 1500 bytes. La MTU solo significa
la cantidad de informacin que Ethernet podr transportar sin importar cul es el header o
el Trailer de capa 2. Finalmente clarificar que los fragmentos de 1500 bytes que crea la
capa de red no contiene el paquete IP entero, es solo los datos.
FCS (4 bytes): FCS o Frame Check Sequence es el encargado de hacer el CRC o cdigo
de reduncia cclica. Este campo se encarga de velar por la integridad de la informacin.
VXLAN Header:
VXLAN Flags (1 byte): Son banderas empleadas para algn prposito en VXLAN. Un
ejemplo acerca de este campo ser dado en el siguiente Post: VMware NSX Modos de
replicacin.
Reserved (3 bytes): Reservado para el futuro. Este campo es puesto en ceros.
VNI (3 bytes): El campo de VNI o VXLAN Number Identifier es quien lleva el identificar
de red. VNI est constituido por 24 bits, proporcionando ms de 16 millones de posibles
redes, sin embargo VMware ha decidido comenzar desde el nmero 5000 con el fin de no
sobrelapar los valores de VLAN ID de las VLAN (0-4096). VNI en conclusin es quien
idnetifica una red de VXLAN. Cada red de VXLAN es una red lgica aislada. VNI permite
identificar a qu VXLAN pertenece una trama ethernet.
Reserved (1 byte): Reservado para el futuro. Este campo es puesto en ceros.
Outer UDP Header: Estos campos tienen como propsito especificar informacin de capa 4 o
capa de transporte para los VTEPs.
Source Port (2 bytes): El puerto de origen es escogido por el VTEP que est
encapsulando la trama original de ethernet. VTEP calcula este puerto utilizando un
algoritmo hash. El hash emplea el header de la trama original de ethernet (Inner L2
Header).
VXLAN Port (2 bytes): NSX usa el puerto 8472. Este es el puerto de destino. Este valor
puede ser cambiado por a travs de REST API call.
UDP Length (2 bytes): Especifica la longitud en bytes del header de este segmento UDP.
UDP Checksum 0x0000 (2 bytes): Este valor siempre ser 0x0000. El VTEP que enviar
la trama deber esteblecer este valor. Si el VTEP que recibe la trama nota que este valor es
distinto, la dropear y no la desencapsular.
Outer IPV4 Header: Estos campos tienen como propsito especificar informacin de capa 3
o capa de red acerca de los VTEPs.
Misc Data (9 bytes): Son una combinacin de varios campos, tales como:
Versin (4 Bits): Si este valor es 4 significa que la versin de IP es IPv4. De

no ser as simplemente no es IPv4.
IHL (4 bits): IHL o Internet Header Length se encarga de avisar si el
campo de Options ser o no utilizado.
Type of Service (1 byte): Permite establecer calidad de servicio de capa 3,
tambin conocido como DSCP Differentiated Services Code Point.
Total Length (2 bytes): Este campo establece el tamao total del paquete,
incluyendo el header. Este valor en el caso de IPv4 es de 20 Bytes.
Time to Live (1 byte): Time to Live o TTL es el encargado de eliminar
bucles de capa 3.
Options (3 bytes): Permite ampliar las opciones de IPv4.
Padding (1 byte): Este campo se encarga de garantizar que la longitud del
paquete sea mltiplo de 32.
Nota: Los campos Identification, Flags y Fragment offset no son empleados por la tecnologa
de VXLAN. Los VTEPs no desfragmentan la informacin.
Protocol 0x11 (1 byte): Identifica el protocolo de capa de transporte que se est

empleando. VXLAN utiliza UDP como protocolo de capa de transporte. El valor 0x11 notifica
que UDP est siendo empleado.
Header Checksum (2 bytes): Este valor permite verificar la integridad de los datos.
Source IP (4 bytes): En este campo se refleja la direccin IPv4 del VTEP de origen (el
VTEP que estar encapsulando).
Destination IP (4 bytes): En este campo se refleja la direccin IPv4 del VTEP de
destino (el VTEP que estar desencapsulando).
Outer Mac Header: Estos campos tienen como propsito especificar informacin de capa 2 o
capa de enlace de datos acerca de los VTEPs.
Destination Address (4 bytes): Direccin MAC de destino (direccin MAC del VTEP a
quien va dirigida la trama) con la cual el VTEP de origen se desea comunicar. Puede
suceder que la comunicacin sea local, es decir en la misma red. Tambin podra pasar que
el destino se encuentre en otra red. En este caso la direccin MAC podra ser de un
dispositivo de capa 3 que se encargue de enrutar el trfico de Multicast (PIM Protocol) o de
un VTEP Proxy. De esto se hablar en el siguiente Post.
Source Address (4 bytes): Esta es la direccin MAC del VTEP que enviar la trama.
VLAN Type 0x8100 (2 bytes): Es opcional en VXLAN. Podra ser que una o varias VXLAN
viaje a travs de una VLAN. De ser as, si el vmkernel port del VTEP especifica una VLAN,
0x8100 dictar que los siguientes 12 bits son el VLAN ID.
VLAN ID (2 bytes): De nuevo, utilizar VLAN es opcional en una implemnentacin de
VXLAN. De ser empleado el valor de la VLAN ir en este campo.
Ethernet Type 0x0800 (2 bytes): Este campo indica el tipo de protocolo que VTEP
emplear en capa 3. Si VTEP emplea IPv4, este campo ser 0x0800.
La siguiente es la trama de VXLAN para IPv6:
Figura 8 VXLAN Encapsulated Header for IPv6
Es muy importante notar que en la figura 7, en el caso de IPv4, el tamao total es de 1564
bytes sin emplear VLANs y de 1572 bytes con VLANs. En el caso de IPv6 sin VLAN es de 1592
bytes y 1600 bytes con VLANs. El peor escenario es de 1600 bytes. VMware recomienda que
de ser empleado IPv4 IPv6, con o sin VLANs, la MTU para VXLAN debe ser configurada
con un valor de 1600 bytes. La red fsica debe ser acondicionada con este valor, de
lo contratio VXLAN no funcionar.
De la figura 8 solo es necesario explicar el siguiente campo:
Outer IPV6 Header: Estos campos tienen como propsito especificar informacin de capa 3
o capa de red acerca de los VTEPs.
Misc Data (7 Bytes): Contiene una serie de campo, descritos a continuacin:
Versin (4 bits): Este campo siempre tendr como valor 6, especificando

que la versin de IP es IPv6.
Class of Traffic (1 byte): Permite establecer calidad de servicio de capa 3,
tambin conocido como DSCP Differentiated Services Code Point.
Flow Label (20 bits): Permite marcar el paquete por el VTEP de origen para
que los dispositivos como Routers le den un tratamiento especial.
Payload Length (2 bytes): El tamao del Payload en bytes.
Hop Limit (1 byte): Este campo reemplaza al campo de TTL de IPv4.
Next Header (1 byte): Este campo especifica el protocolo de capa de transporte que
ser utilizado por el VTEPs. UDP es el procolo que emplea VXLAN. El valor es siempre es
0x11.
Source IP (16 Bytes): Contiene la direccin IPv6 del VTEP de origen.
Destination IP (16 Bytes): Contiene la direccin IPv6 del VTEP de destino.
IPv6 Data and Control (8 bytes): Este campo, utilizado solamente en IPv6, especifica
informacin de datos y control para el manejo de capa de red entre la comunicacin de los
VTEPs.
Configuracin de VXLAN en los ESXi

Para la configuracin de VXLAN en los hosts seguir los siguientes pasos:
Paso 1: En el clster de la figura 6 dar clic en Configure.
Paso 2: Configurar la red de VXLAN:
Figura 9 VMware NSX Configure VXLAN networking
Switch: Seleccionar el Switch Distribuido en dnde se crear el vmkernel port para los
VTEP.
VLAN: Especificar si se utilizar una VLAN para transportar el trfico de VTEP. Si este valor
es cero O significa que no hay tag y el trfico de las VTEPs ser transportado por la VLAN
nativa de los switches fsicos. De ser requerida la confgiruacin de VLAN, el rango
permitido es de 1 a 4094.
MTU: Mxima Unidad de Trasnferencia. VMware recomienda configurar el MTU en 1600
bytes, con el fin de acomodar los campos adicionales que conlleva la encapsulacin de la
trama original de ethernet. Recordar que a la red subyacente tambin se debe cambiar la
MTU.
VMKnic IP addresing: VMware proporciona dos formas de dar direccin IP a los
vmkernel ports que emplearn las VTEP. Una opcin es emplear DHCP. En caso de optar
por esta configuracin, un servidor DHCP debera existir en la red. La segunda opcin
consiste en crear un Pool de direcciones para ser entregadas a las VTEP.
VMKnic Teaming Policy: Permite especificar la poltica de balanceo de carga en el grupo
de puertos vmkernel de las VTEP. Si se requiere dotar con alta disponibilidad al trfico de
VTEP, una opcin es contar con dos tarjetas fsicas atadas al grupo de puertos de VTEP y
configurar la poltica de balanceo que ms se ajuste a las necesidades actuales.
VTEP: En este campo se puede especificar el nmero de VTEPs por ESXi.
Si la configuracin incluye un pool para VTEP, la siguiente figura muestra qu valores pueden
ser configurados:
Figura 10 VMware NSX Configure VXLAN networking Add IP Pool
Paso 3: Verificacin.
Para la verificacin basta con observar el estado del campo VXLAN:
Figura 11 VMware NSX VXLAN Enabled
Tambin se podr verificar si los ESXi recibieron direccin IP:
Figura 12 VMware NSX VXLAN Transport

Otra forma de verificar la configuracin es observando el switch distribuido:
Figura 13 VMware NSX VTEP vmkernel port
Segn la figura 13, VMware NSX Manager ha creado un grupo de puertos distribuido llamado
vxw-vmknicPg-dvs-364-0-a6e.. En este grupo de puertos se ha atado el dvUplink8.
Tambin es posible observar que se han creado dos vmkernel adapter; vmk6 con IP
10.10.11.3 y vmk6 con IP 10.10.11.4.
Al observar de nuevo estas direcciones IP se concluye que concuerdan con el rango del IP Pool
creado en la figura 10. Tambin es posible concluir que la IP 10.10.11.3 es del host esxi01 y
10.10.11.4 de esxi02, como se evidencia en la figura 12. Por lo tanto, esxi01 ya tiene un VTEP
con IP 10.10.11.3 y esxi02 cuenta con un VTEP con IP 10.10.11.4. Una forma de representarlo
grficamente podra ser de la siguiente manera:
Figura 14 VMware NSX VTEP

Donde:
esxi01 y esxi02 pertenecen al clster Gold y Silver respectivamente.
VMware NSX VXLAN Modos de Replicacin

Continuando con VXLAN es tiempo de hablar acerca de la Zona de Transporte y los modos de
replicacin.
En el pasado Post se introdujo acerca de las VXLAN y se mencion varias veces qu es un
VTEP. Virtual Tunnel End Point es el encargado de encapsular y desencapsular la trama
ethernet de las mquinas virtuales en paquetes UDP. Tambin se mostr cmo instalar y
configurar VTEP. Recordar que en un proceso conocido como Host Preparation, NSX
Manager instala tres mdulos en los ESXi:
Mdulo de VXLAN
Mdulo de Logical Distributed Router
Mdulo de Distributed Firewall
En cuanto al mdulo de VXLAN, NSX permite configurar VTEP en los clsteres.

Nota: Se puede pensar en una VXLAN como una VLAN, excepto que se tiene un nmero
mucho mayor de redes lgicas con VXLAN.
Tras un rpido repaso, es hora de hablar acerca de la zona de transporte.
Transport Zone:
Una zona de transporte define qu VTEPs sern capaces de comunicarse y participar en una
red VXLAN. Realmente cuando se est creando una zona de transporte no es posible elegir qu
VTEPs participarn en esta. Lo que si se puede hacer es escoger qu Clsteres harn parte de
la zona de transporte. (Un clster contiene ESXi y stos ltimos tienen configurado los VTEP).
Una zona de transporte puede incluir ESXi de diferentes clsteres y un clster puede
pertenecer a ms de una zona de transporte. Una zona de transporte tambin puede tener
uno o varios VNI. Por ejemplo, por una zona de transporte llamada A existen tres redes
lgicas, VXLAN 5000, 50001 y 5002. Todos los clsteres que pertenecen a la misma zona de
transporte comparten el mismo VNI. Como se ver ms adelante, una zona de transporte
tambin permite definir qu Logical Switches sern parte de sta. El Logical Switch es tal vez
el parmetro ms importante en el momento de disear cuntas zonas de transporte se
necesitarn. Por lo general con tan sola una es suficiente.
Antes de crear una zona de transporte es preciso primero configurar un Segment ID pool,
Identificadores de segmento de VXLAN, el cual definir el rango de VXLAN.
Identificadores de Segmentos de VXLAN
En el pasado Post se habl acerca de la trama encapsulada de VXLAN. Un valor dentro del
Header de VXLAN es el VNI o VXLAN Number Identifier. Este campo tiene 24 bits (dos elevado
a ese valor da ms de 16 millones). Esto significa que con VXLAN se pueden crear ms de 16
millones de redes lgicas. Aunque tcnicamente es posible trabajar con todo este rango,
VMware ha decidido iniciar con el nmero 5000 con el fin de no interferir con el rango actual
de la VLAN (0-4096).
Para crear un Identificador de segmento de VXLAN o Segment ID Pool, los pasos son los
siguientes:
Paso 1: Conectado a vCenter Server con el Web Client, ir a Home, Inventories y clic en
Networking and Security.
Paso 2: Clic en Installation, ubicado en la barra lateral izquierda. A continuacin hacer clic
en Logical Network Preparation y finalmente en Segment ID:
Fifura 1 VMware NSX Segment ID

Paso 3: A la derecha de Segment ID pool: clic en Edit.
Figura 2 VMware NSX Segment ID pool
Segment ID Pool: Este campo permite definir el rango de identificadores de red de

VXLAN. Este rango ser utilizado de forma secuencial cada vez que se cree un segmento de
red virtual (Logical Switch). Notar que el rango puede ser del 5000 al 16777.216.
Enable Multicast Addreessing: Es muy prematuro hablar acerca de este campo, pero, si
se tiene planeado utilizar el modo de replicacin Multicast o Hbrido, seleccionar esta opcin
y configurar un rango de direcciones multicast. Por otro lado, si se emplear el modo de
replicacin Unicast, no seleccionarla. Si la versin de los ESXi es 5.1, esta opcin debe ser
seleccionada. En la versin 5.5 de VMware, Multicast ya no es una obligacin y trae dos
modos de replicacin adicionales (Hbrido y Multicast).
Para verificar si el pool fue definido de forma correcta basta con observar el campo Segment
ID pool:
Figura 3 VMware NSX Segment ID pool verification

En la figura 3 notar que:
El rango de VXLAN es del 5000 al 6000.

No se est empleando el modo de replicacin multicast o hbrido.
Cmo crear una Zona de Transporte:

Una vez definido el rango de las VXLAN, el siguiente paso es crear la zona de transporte.
Paso 1: Clic en Transport Zones:
Figura 4 VMware NSX Transport Zones

Paso 2: Clic en el smbolo de ms de color verde. A continuacin aparecer la siguiente
ventana:
Figura 5 VMware NSX New Transport Zone
Name: El nombre que se dar a esta zona de transporte.

Description: De forma opcional, una descripcin de la zona de transporte.
Control Plane Mode: En este campo se debe definir el modo de replicacin (Multicast,
Unicast o Hbrido).
Select clusteres to add: Clic en los clsteres que se desean incluir en esta zona de
transporte.
Al finalizar verificar que la zona haya sido creada de manera exitosa:
Figura 6 VMware NSX Transport Zone verification

Nota: Cuando en un Transport Zone ha sido creado un Logical Switch, ste podr ser visto por
todos los clsteres de la zona.
Modos de Replicacin
Segn la figura 5 hay tres modos de replicacin:
Unicast
Hybrid
Multicast
Antes de introducir cada uno es necesario que se tengan los conceptos claros acerca de
Multicast. Se comenzar por los modos de comunicacin.
Modos comunicacin
Un modo de comunicacin define la forma cmo se comunican las entidades en una red.
Existen varios modos:
Modos en IPv4
Unicast
Broadcast
Multicast
Modos en IPv6
Unicast
Multicast
Anycast
Comunicacin Unicast
Figura 7 VMware NSX Unicast Communication

Para comprender cmo funciona Unicast, suponer que en la figura 7 hay seis Nodos. Un nodo
puede verse como una computadora. El Nodo 1 desea comunicarse con el Nodo 2. Si la
comunicacin es Unicast significa que ser uno a uno y N2, N3, N4, N5 y N6 no la vern. El
nico que ver y recibir la comunicacin ser N2. En conclusin, unicast es una comunicacin
uno a uno y solo involucra dos entidades en una red (el que enva y el que recibe).
Comunicacin Broadcast
Figura 8 VMware NSX Broadcast Communication

En una comunicacin del tipo broadcast, un mensaje originado por un nodo ir dirigido a todos
los nodos de la misma red. En este caso, la informacin que env N1 ser recibida y escuchada
por todos los nodos. Es una comunicacin de uno a todos.
Observando las figuras 7 y 8, cmo podra N1 enviar un mensaje no a uno, ni a todos, sino a
un grupo de nodos. Por ejemplo, suponer que N1 desea enviar un mensaje a N5 y N6, pero no
a N2, N3 y N4. Al tratar de emplear broadcast es evidente que no funciona para este caso.
Qu sucede con Unicast?. N6 enva un mensaje unicast solicitando un servicio a N1. N1 enva
el mensaje unicast a N6. N5 enva un mensaje unicast solicitando servicio a N1. N1 enva el
mensaje unicast a N5. Esto significa que N1 habr enviados dos mensajes (el mismo mensaje)
por la red. Unicast tampoco es eficiente en este tipo de comunicacin y nace la necesidad de
emplear Multicast.
Comunicacin Multicast
Figura 9- VMware NSX Multicast Communication

En Multicast, un nodo enva un mensaje a un grupo de receptores. La ventaja de este tipo de
comunicacin con respecto a Unicast reside en la forma y cantidad de veces en que el emisor
debe enviar el mensaje. Con Multicast, el mensaje puede ser enviado tan solo una vez a
diferencia de varias veces si fuese el caso de Unicast.
En IPv4 existen 5 clases de direcciones IP:
Clase
Clase
Clase
Clase
Clase
A (Rango: 0-127)
B (Rango: 128-191)
C (Rango 192-223)
D (Rango: 224-239)
E (Rango: 240-255)
Unicast utiliza las clases A, B y C. Por ejemplo, En la figura 7 suponer que N1 tiene la direccin
IP 172.16.25.10/24 y N2 172.16.25.89/24. Estas direcciones son clase B.
Broadcast emplea la direccin 255.255.255.255. En la Figura 8 suponer que N1 es un nodo
que desea adquirir direccin IP por DHCP. N1 enva un mensaje con destino a
255.255.255.255, el cual llegar a todos los nodos de la misma red.
Multicast se encuentra en le rango de la Clase D. En la figura 9 suponer que N1 es un VTEP

con direccin 239.1.1.1. N5 y N6 tambin son VTEPs en otros ESXi con la misma direccin
(239.1.1.1). Si N1 enva un mensaje de multicast, slo N5 y N6 recibirn los datos.
Para comprender los modos de replicacin en VXLAN es preciso tratar tambin dos protocolos
de multicast:
IGMP (Internet Group Managment Protocol)

PIM (Protocol Independent Multicast)
IGMP
Es un protocolo de capa de red o tres del modelo de referencia OSI, el cual permite vincular
Nodos a un Grupo de Multicast. En la figura 7 suponer que N5 y N6 han eviado peticiones a N1
para unirse al grupo de multicast 239.1.1.1. Cuando N1 enva un mensaje a esta direccin, N5
y N6 recibirn esos datos.
IGMP Snooping
Para que un dispositivo de capa 2 como un Switch fsico pueda utilizar IGMP es preciso
configurar sobre ste IGMP Snooping. IGMP Snooping le permite a un Switch conocer qu
dispositivos pertenecen a qu grupos de multicast. Para comprender cmo funciona suponer
que se tiene la siguiente red:
Figura 10 VMware NSX IGMP Snooping

La anterior red consta de dos servidores Webcast. Webcast A tiene la direccin de Multicast
239.1.1.1 y Webcast B 239.1.1.2. La principal funcin de IGMP Snooping, protocolo que corre
en el swtich fsico, es la de monitorear los siguientes de mensajes:
Report: Cuando un switch recibe un mensaje de Reporte de un nodo atado a un grupo de

multicast, el swtich adiciona el nmero de puerto a la tabla de envo, mapeando puerto con
direccin de multicast.
Leave: Cuando un swtich recibe un mensaje de Abandonar de un host, ste libera el
puerto de la direccin de multicast.
Query: Estos mensajes son enviados por los routers de forma peridica a todas las VLANs.
Los nodos interesados en ese trfico de multicast enviarn mensajes de Reporte para
unirse a ese grupo de multicast.
Con base en esos mensajes, IGMP Snooping construye la tabla de envo. Podra darse dos
casos:
Caso 1: Los nodos envan mensajes de reporte no solicitados.

Si N1 y N2 son configurados para pertenecer al grupo de Multicast 239.1.1.1,
estos enviarn un Report message (mensaje de reporte no solicitado) al
switch fsico solicitando unirse al grupo 239.1.1.1 . El switch lo recibir y
ahora sabr que los puertos P1 y P2 pertenecen al grupo de Multicast
239.1.1.1. De forma similiar, si N4 y N5 son configurados en el grupo de
Multicast 239.1.1.2, estos dos nodos enviarn un Report message y el switch
fsico maperar los puertos P4 y P5 al grupo de Multicast 239.1.1.2. Si el
servidor Webmaster A enva un mensaje a 239.1.1.1, el switch fsico revisa
su tabla y nota que los puertos P1 y P2 estn mapeados a ese grupo y solo
lo reenva a los nodos N1 y N2. N3 y N6 son nodos que no pertenecen a
ningn grupo, por lo tanto nunca recibirn nada de Webmaster A ni B. Lo
que enve Webmaster B ser escuchado solo por N4 y N5.
Caso 2: El router enva menajes de query.
En el caso 1 los nodos son quienes piden unirse a un grupo. En el caso 2 es
el router quien pide a los nodos unirse. Cuando un router enva un mensaje
de query, el swtich lo recibe y replica en todos los puertos de la VLAN
especificada en el mensaje. Los nodos conectados a esos puertos enviarn
un mensaje de report y se atarn al grupo de multicast.
PIM
PIM es configurado en dispositivos de capa tres como Routers. PIM permite enrutar el trfico
de Multicast. Este protocolo tiene tres modos de configuracin:
Bidireccional.
Denso.
Dispero.
VMware recomienda emplear el modo bidireccional.

Nota: Este Post no pretende adentrarse en la configuracin de los dispositivos fsicos. IGMP
Sooping y PIM no sern tratados con detalle debido a que estos son configurados en el lado de
la red fsica y no dentro de VMware. Adems PIM no es estrictamente necesario para que la
solucin funcione.
Regresando al tema, segn la figura 5 existen tres modos de replicacin; Unicast, Hybrid y
Multicast. El modo de replicacin define cmo ser tratado el trfico BUM (Broadcast, Unknow
unicast and Multicast). Por ejemplo, si una mquina virtual conectada a la VXLAN 5000 enva
un mensaje de broadcast a una mquina virtual en otro ESXi, cmo ser transportado? A esto
se refiere los modos de replicacin.
Antes de comprender los tres modos es necesario entender lo que es un Segmento VTEP.
Figura 11 VMware NSX VTEP Segments

En la figura 11 suponer que se tienen dos Clster. El Clster A est constituido por ESXi-1 y
ESXi-2. El Clster B tiene a ESXi-3 y ESXi-4. El Clster A y B estn compartiendo el mismo
Switch Distribuido. En el Clster A ha sido configurado el segmento de VTEP 10.20.10.0/24,
mientras que en B es 10.20.11.0/24. Ambos Clsteres pertenecen a la misma zona de
transporte. De esta figura finalmente se puede concluir que hay dos segmentos VTEP:
VXLAN Transport Subet A 10.20.10.0/24 (ESXi-1 y ESXi-2)
VXLAN Transport Subet B 10.20.11.0/24 (ESXi-3 y ESXi-4)
Modo Unicast
El modo Unicast es el ms fcil de configurar. No requiere ninguna configuracin en los
switches ni routers fsicos aparte de la MTU, sin embargo, para ambientes grandes es
ineficiente en consumo de ancho de banda y CPU de los ESXi. Este modo est basado en el
NSX Controller, quien administra el plano de control en este caso.
En el modo Unicast tanto el trfico local como remoto es replicado empleando unicast. Los
ESXi son divididos en grupos o segmentos VTEP, dependiendo del direccionamiento IP al que
pertenecen. NSX Controller elige un VTEP en cada segmento de VTEP. A este VTEP se le
conoce como Proxy VTEP y en el caso de Unicast como UTEP Unicast Tunnel End Point.
Esta eleccin es por VNI.
Si por ejemplo se tiene una mquina virtual VM1 conectada a una VXLAN 5001 en el ESXi-1 y
requiere comunicarse con una mquina virtual VM2 en la misma VXLAN en un ESXi-2, pero
VMA no conoce la MAC de VMB, el trfico de broadcast de la mquina virtual A ser
encapsulado en una trama VXLAN. El VTEP de origen (el VTEP del ESXi01) deber replicar esta
trama a cada uno de los VTEPs del mismo segmento y al UTEP del segmento remoto:
Figura 12 VMware NSX Unicast Mode

De la figura 12 se puede deducir que:
Hay 4 VMs, todas conectadas a las misma VXLAN 5001.

Hay 2 clster. Cada uno con dos ESXi y distinto segmento de VTEP.
Hay dos segmentos de VTEP.
La VXLAN 5001 abarca dos clsteres.
NSX Controller es quien elige el UTEP en cada segmento de VTEP.
ESXi-2 es el UTEP del segmento 10.20.10.0/24.
ESXi-3 es el UTEP del segmento 10.20.11.0/24.
1. VM1 enva un broadcast (ARP Request) en busca de la direccin MAC de destino de VM2.
2. ESXi-1 (Source VTEP) mira su tabla de VTEP y observa que debe replicarla a todos los ESXi
del mismo segmento VTEP y a cada UTEP de cada segmento VTEP remoto. Dado que hay solo
dos segmentos, ESXi-1 encapsula la trama original de VM1 (el ARP request que en realidad es
un broadcast) en un paquete UDP y lo replica por unicast al VTEP de ESXi-2 (es el nico VTEP
local) y tambin es replicado al ESXi-3 (ya que este el UTEP del segmento remoto).
A modo de parntesis, recordar la trama encapsulada de VXLAN:
Figura 13 VXLAN Header for IPv4

Especficamente en el encabezado de VXLAN VXLAN Flags de 8 bits, un bit llamado
REPLICATE_LOCALLY es usado para el UTEP. Continuando con la explicacin del punto 2,
cuando ESXi-1 enva la trama a ESXi-2, el bit REPLICATE_LOCALLY es cero dado a que el VTEP
de ESXi-2 es local y no un UTEP remoto. Pero, cuando ESXi-1 enva la trama al UTEP remoto
ESXi-3, el bit es 1 indicando al UTEP que esta trama proviene de un VTEP de un segmento
remoto y que debe ser replicada localmente en su segmento de VTEP.
3. El UTEP del segmento remoto (ESXi-3) recibe la trama con el bit REPLICATE_LOCALLY = 1,
revisa su tabla VTEP y la replica a todos los VTEPs de su segmento local.
4. Cada mquina virtual recibir la trama ethernet original (desencapsulada por el VTEP) y solo
responder al broadcast aquella que coincida con la IP de destino contenida en el mensaje de
ARP Request.
Conclusiones:
La trama encapsulada de VXLAN fue entregada tanto a ESXi-2, ESXi-3 y ESXi-4 empleando
Unicast.
Cuando la trama encapsulada de VXLAN lleg a ESXi-2, ste la desencapsul y entreg el
broadcast a VM2. VM2 responde con un ARP Reply y el VTEP de ESXi-2 encapsula la trama
y es enviada solo a ESXi-1.
Cuando la trama encapsulada de VXLAN lleg a ESXi-3, ste la desencapsul y envi el
broadcast a VM3. VM3 la descarta ya que la IP de destino no es la de l. Sin embargo ESXi2 es el UTEP de ese segmento remoto, as que la replicar a todos los VTEP del mismo
segmento.
broadcast a VM4. VM4 la descarta ya que la IP de destino no es la de l.
Observaciones:
Cambiando un poco el ejemplo, suponer que VM2 enva un ARP request en busca de la
direccin MAC de destino de VM1. En este caso ESXi-2 es quien recibe la trama original de la
mquina virtual y la debe encapsular para su envo. ESXi-2 revisa su tabla VTEP y replica la
trama a ESXi-1 y al UTEP remoto. Lo interesante aqu es que el UTEP remoto no

necesariamente debera ser ESXi-3, podra pasar que para este caso sea ESXi-4. NSX Controller
elige los UTEP de forma local (al interior de los ESXi) e independientemente de cada ESXi.
En resumen:
Source VTEP
Replica por medio de unicast la trama encapsulada a todos los VTEP del segmento VTEP
local.
Replica por medio de unicast la trama encapsulada al UTEP de cada segmento VTEP
remoto.
Destination UTEP
Es quien recibe la trama encapsulada del Source VTEP.

Replica la trama encapsulada por medio de unicast a cada VTEP local de su segmento local.
Requerimientos:
Red Fsica: Solo se necesita configurar una MTU de 1600 bytes. No es necesario IGMP
Snooping ni PIM.
El modo unicats puede ser configurado por VNI durante la creacin del Logical Switch.
Modo Hbrido
El modo hbrido es una combinacin entre Multicast y Unicast. Este es tambin el mtodo ms
recomendado por VMware. Aparte de una MTU de 1600, el mtodo hbrido y a diferencia de
unicast, si requiere una configuracin especifica en la red fsica. Este modo tambin est
basado en el NSX Controller, quien administra el plano de control en este caso.
Cuando el Modo Hbrido es seleccionado, la replicacin local se hace por medio de Multicast
(IGMP Snooping) pero para la replicacin remota se emplea Unicast, eliminando la necesidad
de emplear protocolos de enrutamiento multicast como PIM. Los ESXi son divididos en grupos
o segmentos VTEP, dependiendo del direccionamiento IP al que pertenecen. NSX Controller
elige un VTEP en cada segmento VTEP. A este VTEP se le conoce como Proxy VTEP y en el
caso del modo Hbrido como MTEP Multicast Tunnel End Point. Esta eleccin es por VNI.
Suponer que se tiene la siguiente red:
Figura 14 VMware NSX Hybrid Mode


NSX Controller es quien elige el MTEP en cada segmento de VTEP.
ESXi-2 es el MTEP del segmento 10.20.10.0/24.
ESXi-3 es el MTEP del segmento 10.20.11.0/24.
El grupo de multicast es 239.1.1.1.
Cada uno de los ESXi ha enviado un mensaje de Reporte para unirse al grupo 239.1.1.1.
1. VM1 desea comunicarse con VM2 pero no conoce su direccin MAC de destino. VM1 enva
un ARP Request solicitando esta informacin. Como ESXi-1, ESXi-2, ESXi-3 y ESXi-4 tienen al
menos una mquina vitual en la VXLAN 50001 (VNI 5001), cada ESXi enva al switch fsico (al
swtich que los conecta a la red fsica) un mensaje de Reporte para unirse al grupo de multicast
239.1.1.1.
2. ESXi (Source VTEP) recibe la trama, observa su tabla VTEP y la encapsula con direccin IP
de destino 239.1.1.1. La direccin IP de destino del campo Destination Address del Outer IP
Header de la figura 13 es definida como 239.1.1.1 por el VTEP de ESXi-1. El switch fsico
recibe el paquete UDP y lo reenva a todos los VTEPs del segmento local, en este caso, solo a
ESXi-2 (ESXi-2 recibe la trama encapsulada con el bit REPLICATE_LOCALLY = 0).
3. En la tabla VTEP de ESXi-1 tambin se establece que debe replicar por medio de unicast
esta trama al MTEP de cada segmento remoto (solo a ESXi-3 en este ejemplo). En este caso
ESXi-3 recibe la trama encapsulada con el bit REPLICATE_LOCALLY = 1, indicndole que
proviene de un VTEP remoto y que debe replicarla por medio de multicast a cada VTEP de su
propio segmento local.
4. ESXi-3 replica por medio de multicast (al grupo 239.1.1.1) la trama encapsulada a cada
VTEP del segmento local (solo ESXi-4 en este ejemplo).
responder al broadcast aquella VM que coincida con la IP de destino contenida en el mensaje
de ARP Request.
Conclusiones:
La trama encapsulada de VXLAN fue entregada a ESXi-2 con multicast, a ESXi-3 con unicast
y ESXi-4 con multicast.
broadcast a VM3. VM3 la descarta ya que la IP de destino no es la de l. Sin embargo ESXi2 es el MTEP de ese segmento remoto, as que la replicar a todos los VTEP del mismo
segmento emplenado multicast.
broadcast a VM4. VM4 la descarta ya que la IP de destino no es la de l.
Observaciones:
Cambiando un poco el ejemplo, suponer que VM2 enva un ARP request en busca de la
direccin MAC de destino de VM1. En este caso ESXi-2 es quien recibe la trama original de la
mquina virtual y la debe encapsular para su envo. ESXi-2 revisa su tabla VTEP y replica la
trama a ESXi-1 y al MTEP remoto. Lo interesante aqu es que el MTEP remoto no
necesariamente debera ser ESXi-3, podra pasar que para este caso sea ESXi-4. NSX Controller
elige los UTEP de forma local (Al interior de los ESXi) e independientemente de cada ESXi.
En resumen:
Source VTEP
Replica por medio de Multicast la trama encapsulada a todos los VTEP del segmento VTEP
local.
Replica por medio de unicast la trama encapsulada al MTEP de cada segmento VTEP
remoto.
Destination MTEP
Es quien recibe la trama encapsulada del Source VTEP.

Replica la trama encapsulada por medio de multicast a cada VTEP local de su segmento.
Requerimientos:
Red fsica: Los switches que conectan a los ESXi (a las tarjetas fsicas mapeadas a los
VTEPs) deben estar configurados con IGMP Snooping. De esta forma los mensjaes de
report enviados por los VTEPs sern interpretados por la infraestructura fsica. Los routers
no requieren PIM, ya que la replicacin remota se hace por medio de unicast.
Se requiere direccionamiento Multicast. En la figura 2 se debe especificar un rango para
multicast.
Se puede configurar por VNI durante la creacin del Logical Switch.
MTU 1600 bytes.
Modo Multicast
El modo multicast es quizs el tipo de replicacin ms compleja de mantener. Aparte de una
MTU de 1600 bytes, requiere una configuracin de IGMP Snooping pero tambin de PIM con el
fin de enrutar el trfico de multicast. Este modo es totalmente independiente del NSX
Controller, ya que no se elegirn VTEP proxy en segmentos VTEP remotos, por lo tanto,
multicast est basado en el plano de datos y no en el de control.
En el modo multicast el trfico local y remoto es replicado utilizando multicast. No existen los
roles de UTEP o MTEP, ya que el protocolo PIM es utilizado para replicar de forma remota. Los
ESXi son divididos en grupos o segmentos VTEP, dependiendo del direccionamiento IP al que
pertenecen.
Suponer que se tiene la siguiente red:
Figura 15 VMware NSX IGMP Joins


NSX Controller no juega un papel en este caso.
El grupo de multicast es 239.1.1.1.
ESXi-1, ESXi-2 y ESXi-3 tienen al menos una VM encendida en la VXLAN 5001, por lo tanto, el
VTEP de cada ESXi enva un mensaje de IGMP a los switches fsicos para unirsen al grupo
239.1.1.1. ESXi-4 no enva ningn mensaje ya que no tiene mquinas vituales encendidas en
esa VXLAN.
Si la VM1 desea comunciarse con la VM2 y no conoce la direccin MAC de destino, enviar un
ARP request (broadcast) y el flujo y tipos de mensajes de la figura 15 se vera ahora de la
siguiente forma:
Figura 16 VMware NSX Multicast Mode

1. VM1 enva un ARP Request en busca de la direccin MAC de destino de VM2.
2. ESXi-1 recibe la trama original (broadcast de VM1) y la encapsula. La direccin IP de destino
del campo Destination Address del Outer IP Header de la figura 13 es definida como
239.1.1.1 por el VTEP de ESXi-1.
3. El switch fsico recibe el paquete multicast y lo replica por medio de IGMP snooping a todos
los VTEPs conectados al grupo 239.1.1.1 (en este caso solo a ESXi-2 y la interfaz del router
conectada al swtich fsico).
4. El router recibe la trama y la enruta por medio de PIM a la red 10.20.11.0/24.
5. El switch fsico recibe la trama encapsulada y la replica a todos los VTEPs conectados a
239.1.1.1 (en este caso solo a ESXi-3).
responder al broadcast aquella VM que coincida con la IP de destino.
Conclusiones:
La trama encapsulada de VXLAN fue entregada tanto a ESXi-2 y ESXi-3 con multicast.
broadcast a VM3. VM3 la descarta ya que la IP de destino no es la de l. Sin embargo ESXi-
2 es el MTEP de ese segmento remoto, as que la replicar a todos los VTEP del mismo
segmento empleando multicast.
En resumen:
Source VTEP
Replica por medio de Multicast la trama encapsulada a todos los VTEP del segmento VTEP
local y remoto.
Destination
El modo multicast no tiene los roles de UTEP y MTEP.
Requerimientos:
Red fsica: Los switches que conectan a los ESXi (a las tarjetas fsicas mapeadas a los
VTEPs) deben estar configurados con IGMP Snooping. De esta forma los mensjaes de
report enviados por los VTEPs sern interpretados por la infraestructura fsica. Los
routers requieren PIM. Se recomienda PIM bidireccional.
Se requiere direccionamiento Multicast. En la figura 2 se debe especificar un rango para
multicast.
Se puede configurar por VNI durante la creacin del Logical Switch.
MTU de 1600 bytes.
Nota final: Tener en cuenta que cada vez que se mencionaba la palabra encapsula o
encapsular se hace referencia al proceso que lleva a cabo un VTEP. El VTEP toma la trama
ethernet original de la mquina virtual (en todos los ejemplos era un ARP Request) y lo
encapsulaba en una trama VXLAN como el de la figura 13. Por otro lado, desencapsular hace
referencia al VTEP que recibe la trama y elimina todos los encabezados a excepcin del Inner
L2 Header and Payload de la figura 13, el cual es en realidad la nica informacin que le
interesa a la mquina virtual de destino. Tener presente que VXLAN es transparente para las
mquinas virtuales.
Para finalizar, la siguiente tabla muestra la diferencia entre cada modo de replicacin:
Feature
Unicast Mode
Hybrid Mode
Multicast Mode
MTU
1600 Bytes
1600 Bytes
1600 Bytes
NSX
Controller
Basado en NSX
Controller
Basado en NSX
Controller
No basado en NSX
Controller
VTEP Proxy
Role?
NSX Controller elige

un UTEP por cada
segmento
NSX Controller elige un

MTEP por cada
segmento
No existe el rol de VTEP

Proxy
IGMP
Snooping
No es necesario
Es necesario
Es necesario
PIM
No es necesario
No es necesario
Es necesario
Source
VTEP
Replica por medio de

unicast la trama
encapsulada a todos
los VTEP del segmento
VTEP local.
unicast la trama
encapsulada al UTEP
de cada segmento
VTEP remoto.

Multicast la trama
encapsulada a todos
los VTEP del segmento
VTEP local.
unicast la trama
encapsulada al MTEP
de cada segmento
VTEP remoto.

Multicast la trama
encapsulada a todos los
VTEP del segmento
VTEP local y remoto.
Destination
Proxy
Es el UTEP. Es quien
recibe la trama
encapsulada del
Source VTEP.
Replica la trama
encapsulada por
medio de unicast a
cada VTEP local de su
segmento local.
Es el MTEP. Es quien
recibe la trama
encapsulada del
Source VTEP.
Replica la trama
encapsulada por medio
de multicast a cada
VTEP local de su
segmento.
El modo multicast no
tiene los roles de UTEP
ni MTEP.
VMware NSX Logical Switch

Con todos los conceptos vistos hasta el momento ya estamos listos para comenzar a hablar
acerca del Logical Switch.
Logical Switch
Un Switch Lgico es un segmento de red vitual que ha sido identificado con un VNI. Algunas de
sus caractersticas ms importantes son:
Un switch lgico tiene su propio y nico VNI, por lo tanto es una red virtual de capa dos.
Un swtich lgico puede abarcar ms de un clster.
La capa dos puede extenderse ms all de los lmites de capa tres.
Un switch lgico es un grupo de puertos distribuido.
Las mquinas virtuales son quienes finalmente se conectan a estos switches.
Cada VXLAN es en realidad un switch lgico.
Dentro de una misma zona de transporte todos los clsteres inmediatamente podrn ver un
logical swtich que haya sido creado.
Un switch lgico tan solo podr tener un VNI.
Se puede concluir entonces que la zona de transporte define la extensin y visibilidad (span)
de un logical switch.
Cmo crear un Logical Switch
Estos son los pasos para crear un Logical Switch:
Paso 1: Por medio de vSphere Web Client iniciar sesin en vCenter Server.
Paso 2: Ir a Home, Inventories, Networking and Security.
Paso 3: En Dar clic en Logical Switches de la barra lateral izquierda. A continuacin dar clic
en el smbolo ms (+) de color verde con el fin de adicionar un Logical Switch:
Figura 1 VMware NSX Add a Logical Switch

Pas0 4: Configurar los siguientes campos.
Figura 2 VMware NSX New Logical Switch
Name: Ingresar un nombre para esta switch lgico.

Description: De forma opcional se puede dar a una descripcin.
Trasnport Zone: Definir la zona de transporte en la cual este switch lgico se atar.
Control Plane Mode: (Modos de Replicacin). Por defecto el switch lgico toma la
configuracin del modo de replicacin de la zona de transporte, sin embargo puede ser sobre
escrito.
Nota: Para ms informacin acerca de los modos de replicacin visitar este Post.
Nota: Como se observa en la figura 2, no se puede especificar a que VXLAN ir atado este
logical switch. VMware secuencialmente ir asignando VNIs basado en el rango de
identificadores de red. Para ms informacin visitar el siguiente Post y ver figura 2.
Paso 5: Verificacin.
Figura 3 VMware NSX Logical Switch verification

Segn la figura 3 se han creado dos Logical Switches:
Win-Servers
Linux-Servers
Win-Servers es la XVLAN 5000. Por otro lado Linux-Servers es la VXLAN 5001. Estos valores
son tomados secuncialmente por el rango de Segment ID que haya sido configurado:
Figura 4 VMware NSX Segment ID

Cada Logical Switch es un grupo de puertos distribuido establecido automticamente por NSX
Manager. Los grupos de puertos distribuidos son configurados en todos los VTEPs en la misma
zona de transporte donde el Switch Lgico fue creado. Al observar la figura 3, los Logical
Switches fueron creados en la zona de transporte Transport-Zone1. Esta zona est
constituida por dos Clsteres (Gold y Silver). Gold alberga a esxi01 y Silver a esxi02. Por lo
tanto, un grupo de puertos distribuido por logical switch ser creado y los hosts esxi01 y
esxi02 estarn conectados a ste.
Figura 5 VMware NSX Distributed Port Group

En la figura 5 se observa que se han creado dos grupos de puertos distribuidos:
vxw-dvs-364-virtualwire-2-sid-5000-Win-Servers: Este grupo de puertos fue creado en

representacin del Logical Switch Win-Servers.
vxw-dvs-364-virtualwire-3-sid-5001-Linux-Servers: Este grupo de puertos fue creado en
representacin del Logical Switch Linux-Servers.
Nota: El nombre dadode forma automtica a un grupo de puertos distribuidos involucra tanto
al nmero de VXLAN como al nombre del Logical Switch.
Migracin de mquinas virtuales
NSX Manager cuenta con un asistente para migrar mquinas virtuales a Logical Switches de
forma fcil y rpida. Para migrar una VM a un Logical Switch los pasos son los siguientes:
Paso 1: Seleccionar el Logical Switch al que se desea conectar VMs y despus clic en el
smbolo Add Virtual Machine:
Figura 6 VMware NSX Add Virtual Machine
En la figura 6 se ha seleccionado el Logical Switch Win-Servers y despus se ha dado clic en

Add Virtual Machine:
Paso 2: Definir qu VMs sern conectadas al logical switch. A continuacin clic en Next.
Figura 7 VMware NSX Win-Servers Add Virtual Machine

Paso 3: Seleccionar qu vNICs de las VMs sern atadas al logical switch. Despus clic en
Next.
Figura 8 VMware NSX Win-Servers Add Virtual Machine Select VNICs
Finalmente dar clic en Finish.

Tras la migracin, la figura 5 toma ahora la siguiente forma:
Figura 9 VMware NSX vDS Switch

A continuacin una representacin grfica de esta red:
Figura 10 VMware NSX Virtual Network
Conclusiones:
El ping desde Win-Server1 a Win-server 2 fue exitoso ya que ambas VMs se encuentran en
la misma red lgica, es decir, en el mismo Logical Switch o lo que es lo mismo, en la misma
VXLAN.
El ping de Linux-Server1 a Linux-Server2 tambin fue exitoso ya que se encuentran en la
misma red lgica.
El ping de Win-Server1 a Linux-Server1 y Linux-Server2 fracas. En este caso se necesita
de un dispositivo de capa tres que permita enrutar el trfico entre las VXLANs.
VMware NSX Distributed Logical Router

Continuando con NSX es tiempo de hablar ahora sobre el Distributed Logical Router,
palabras que abreviar como DLR. En el pasado Post se vio cmo crear un Logical Switch. Se
concluy que un switch lgico es prcticamente un grupo de puertos distribuido en un switch
distribuido. NSX no trabaja con el switch estndar de VMware. Tambin se pudo observar que
un switch lgico es bsicamente una VXLAN. Tambin se detall cmo migrar las mquinas
virtuales a los switches lgicos y finalmente se pudo concluir que las VMs en una misma VXLAN
podan alcanzarse pero entre distintas VXLANs no. Porqu no? Porque la comunicacin de
VXLAN a VXLAN es en esencia una comunicacin de una red a otra y para esto se necesita
entonces de un dispositivo de capa 3, como un router o en el caso de VMware NSX, un
Distributed Logical Router.
En este post se ver la funcin que desempea el Distributed Logical Router de VMware en el
enrutamiento de Este-Oeste.
VMware NSX Distributed Logical Router
El DLR de VMware NSX es un router lgico (100% por software) que permite enrutar el trfico
de Este-Oeste de la infraestructura virtual. Por trfico de Este-Oeste se puede definir como
aquel trfico que cursa entre las mquinas virtuales conectadas a redes lgicas (Logical
Switches).
Nota: El trfico de Norte-Sur se define como el trfico que cursa entre el espacio lgico
(VMware NSX) y el mundo fsico. NSX Edge fue diseado para enrutar este tipo de trfico.
En un parntesis, VMware desde hace mucho tiempo ha permitido configuar VLANs bajo el
estndar 802.1q. A continuacin suponer que se tiene la siguiente infraestructura:
Un clster llamado A.
En el clster A hay dos ESXi (ESXi01 y ESXi02).
VM1 y VM2 estn en el ESXi01.
VM3 y VM4 estn en el ESXi02.
VM1 y VM3 pertenecen a la VLAN 10.
VM2 y VM4 pertenecen a la VLAN 20.
Si VM1 se desea comunicar con VM2, notar que son mquinas virtuales en diferentes VLANs
pero ubicadas en el mismo ESXi. Es evidente que la comunicacin entre stas precisa de un
dispositivo de capa 3, como un router. El punto en este ejemplo es que cuando VM1 quiera
comunicarse con VM2, aunque estn el mismo host el trfico deber salir del ESXi, dado a que
comnmente el router es fsico (fuera del ESXi). A esto se le conoce como Hairpinning. Habr
una solucin capaz de evitar esta situacin?. Que tal si cuando VM1 se comunique con VM2 el
trfico no salga del ESXi y sea enrutado internamente por el mismo host; esto es posible y lo
hace el DLR de VMware. DLR es un router que se distribuye entre todos los ESXi y su punto de
control centralizado se encuentra en la capa de control de los planos del NSX, llamado el
Logical Router Control Virtual Machine LR Control VM.
Del anterior ejemplo se puede concluir dos cosas importantes:
DLR o Distributed Logical Router es un Router Distribuido y corre en los ESXi. No es una
mquina virtual. NSX Manager lo instala en cada Hypervisor en un proceso conocido como
Host Preparation. Durante la preparacin de un Host, NSX Manager instala tres mdulo o
VIBs en el ESXi, tales como la vib para VXLAN, otra vib para el Distributed Logical Router y
otra ms para el Distributed Firewall. Por lo tanto el plano de datos es distribuido en el
Hypervisor.
En cuanto a capa tres, en el plano de control se ubica el Logical Router Control Virtual
Machine, el cual no es distribuido y no corre cmo mdulo en los ESXi; en vez de eso, es
una mquina virtual.
La relacin que existe entre DLR y LR Control VM es la siguiente:
Cada vez que se crea un DLR se desplegar una mquina virtual (LR Control VM). Esta
mquina virtual se encargar de formar adyacencias y la tabla de enrutamiento con otros
dispositivos fsicos o virtuales de capa 3 e informarle al NSX Controller. NSX Controller
deber pesarle la tabla de enrutamiento a cada ESXi. NSX Controller juega un papel
importante en este desarrollo de VMware. Es fcil preguntarse porqu este intermediario.
Recordar que NSX Controller alberga cuatro tablas: MAC, ARP, VTEP y enrutamiento. NSX
Controller tambin ser el encargado de distribuir y redistribuir las cargas. Si por ejemplo
hay tres NSX Controller en clster y se han creado 9 DLRs, es probable que cada NSX
Controller administre tres DLRs. De forma similar, si hay tambin 18 Logical Switches,
cada NSX Controller probablemente administrar 6. Por ltimo, DLR es quien realiza el
enrutamiento, no LR Control VM.
Escalabilidad
En cuanto a la escalabilidad, DLR cuenta con las siguientes caractersticas:
Se pueden crear hasta 1000 interfaces virtuales por DLR.

Se pueden crear hasta 1200 DLRs por instancia de NSX Manager.
No ms de 100 DLRs por ESXi.
Hairpinning
Hairpinning es el trfico que debe salir de un ESXi de manera indeseada pero necesaria para la
comunicacin entre mquinas vituales en un mismo Hypervisor pero en distintas redes. Para
comprender este concepto suponer que se tiene la siguiente red virtual:
Figura 1 VMware NSX Hairpinning

1. Win-Server 1 enva trfico a Linux-Server1. Estas dos mquinas virtuales se encuentran en
el mismo ESXi pero en distintas redes. Win-Server1 deber enviar la trama a su default
gateway (172.26.28.1), el cual es un interfaz virtual de un NSX Edge Gateway ubicado en otro
Host.
2. ESXi01 encapsula el trfico en una trama VXLAN, la cual viaja por la red de transporte hasta
alcanzar a ESXi02.
3. ESXi02 recibe la trama encapsulada, la desencapsula y entrega al NSX Edge.
4. NSX Edge revisa su tabla de enrutamiento y nota que la red de destino (172.16.30.0) la
tiene directamente conectada a su interfaz virtual.
5. NSX Edge enva la trama por la VXLAN 5000, ESXi02 la encapsula y enva por la red de
transporte.
6. ESXi01 recibe la trama, la desencapsula y entrega a la mquina virtual Linux-Server1.
Como se pudo observar, el trfico tuvo que salir de ESXi01 aunque la mquina de origen y
destino estuvieran asentadas en el mismo host. Esto conlleva tambin a la necesidad de
encapsular y desencapular las tramas ethernet originales en paquetes UDP (VXLAN), lo cual
tiene efecto tanto en la CPU de los ESXi como en el consumo de ancho de banda de la red de
transporte.
El Logical Distributed Router de VMware NSX evita el Hairpanning.

Enrutamiento del trfico
DLR puede enrutar trfico:
De redes Lgicas a Fsicas (o viceversa). Ejemplo: De la XLAN 50001 a la red fsica

10.10.10.0/24.
De Redes Lgicas a Lgicas. Ejemplo: De la VXLAN 50000 a la VXLAN 50001. O de la VLAN
100 a la VLAN 2000. O de la VXLAN 5000 a la VLAN 200.
Armando el rompecabezas de NSX, a continuacin se mostrar la grfica que representa los

planos:
Figura 2 VMware NSX. Planes

La red que se ha venido implementando a lo largo de todos estos Posts acerca de NSX es la
siguiente:
Figura 3 VMware NSX DLR

Nota: En la figura 3 se detalla la ubicacin de cada Plano del NSX. Por lo general, las mquinas
virtuales como NSX Manager, vCenter Server, NSX Controller, Logical Router Control VM y otros
productos de VMware como Site Recovery Manager, vCloud Director, entre muchos otros, son
ubicados en un clster destinado nicamente a la administracin, evitando que la
infraestructura que administra y controla el entorno virtual compita por los recursos del
entorno de produccin.
Utilizando la figura 3 como ejemplo, suponer que Win-Server1 enva trfico a Linux-Server1.
Ambas VMs se encuentran en redes distintas. DLR podr en este caso enrutar el trfico y
evitar incluso el Hairpanning. Esto significa que el trfico no saldr (no se emplearn los VTEPs
ni se encapsular/desencapsular la trama ethernet de las VMs) de ESXi01.
De la figura 3 tambin se puede decir que:
Hay un DLR.
Hay un Logical Router Control VM.
El DLR tiene hasta ahora dos interfaces virtuales, tambin conocidas como LIFs Logical
Interfaces.
Si por ejemplo se creara una nueva interfaz lgica travs de NSX Manager, NSX Controller
deber replicar esta informacin a cada DLR, los cuales se ubican directamente en los
hosts.
Nota: Recordar que NSX Controller es deplegado manualmente desde el NSX Manager.
Recordar tambin que el Logical Router Control VM es despegado tambin por NSX Manager
en el momento que un DLR es creado.
El Logical Router Control VM LRCVM administra las adyacencias y la tabla de enrutamiento.
Esta mquina virtual permite configurar tanto enrutamiento esttico como dinmico,
soportando:
Rutas estticas
OSPF
BGP
Cuando LRCVM hace una adyacencia y aprende una ruta, se las informar a NSX Controller,
quin despus se las enviar a cada ESXi. En resumen, el LRCVM tiene tres funciones:
Informar sobre el tipo/funcin de las interfaces virtuales del Distributed Logical Router. Por
ejemplo, si se crea un DLR con tres interfaces virtuales/lgicas, llamadas LIFs, el LRCVM
deber pasar estar informacin al NSX Controller, quien finalmente se la dar a cada host.
Formar adyacencias y obtener informacin de enrutamiento, tiles para armar la tabla de
enrutamiento. Esta informacin es enviada luego al NSX Controller, quien finalmente las
enviar a cada hosts.
Como se ver ms adelante, tambin har de Bridge instance, concepto exclusivo de Bridge
L2.
Logical Interface (LIF)

En el mundo fsico un router tiene interfaces fsicas. Cada interfaz representa una red o lo que
es lo mismo, un dominio de broadcast. En las interfaces fsicas de los routers se debe
configurar una direccin IP. Un router sin IP prcticamnete no hace nada.
En NSX el DLR tambin tiene interfaces, pero son lgicas, conocidas como LIFs. Hasta 1000
LIFs podrn ser creada por DLR. Cada LIF podra tener su propia direccin IP, representar
una red o dominio de broadcast y podr ser conectada a un Logical Switch o Distributed Port
group. Nuevamente al observar la figura 3, un LIF del DLR fue conectada al Logical Switch
Win-Servers que representa la VXLAN 5000 y la otra interfaz al Logical Switch Linux-Server,
representado por la VXLAN 5001.
Por cada red que se conecte a un DLR ste tendr su propia tabla ARP. En la figura 3 hay dos
LIFs (redes), por tanto este DLR maneja dos tablas ARP.
Un DLR posee dos tipos de direccin MAC:
vMAC: LIF conectada a un Logical Switch (VXLAN).

pMAC: LIF Conectada a un Distributed Port Group (VLAN).
vMAC o Virtual MAC es la direccin MAC de una LIF conectada a un Logical Switch. Esta
direccin ser la misma en todos los ESXis y LIFs. Esta es la razn por la cual se le conoce
como Distributed Logical Router, ya que ciertas caractersticas del router son distribuidas y
las mismas en los ESXi. Para que una MAC sea catalogada como vMAC es necesario que la
LIF sea conectada a un Logical Switch.
Figura 4 DLR LIFs

La figura 4 muestra dos LIFs (LIF1 y LIF2). LIF1 tiene direccin IP 172.16.28.1 y vMAC
00:01:02:03:04:05. LIF2 tiene la direccin IP 172.16.30.1 y vMAC 00:01:02:03:04:05. En la
misma figura se puede apreciar que cada LIF del DLR tendr distinta IP pero la misma vMAC
para todos. Si por ejemplo se tiene un DLR con 4 interfaces lgicas o LIFs conectadas a
distintos Logical Switches, ste tendr entonces 4 direcciones IP y una misma vMAC para
todas las cuatro.
Cuando Win-Server1 enve trfico a Linux-Server1 o Linux-Server2 se utilizar el default
gateway, en este caso, LIF1. La mquina virtual utilizar la vMAC como direccin MAC de
destino. vMAC es una direccin que solo puede ser vista en el dominio de las VXLAN. Los
switches fsicos no pueden ver esta direccin ni mucho menos introducirla en sus tablas de
direcciones MAC. Porqu? Es muy sencillo. Cuando Win-Server1 enva trfico a Linux-Server1,
la informacin de la trama ethernet que enviar ser la siguiente:
Destination MAC Address: 00:01:02:03:04:05. Dado a que la direccin IP de destino se
encuentra en otra red, se emplear el default gateway. Sin no conoce la MAC del default
gateway, Win-Server1 har un ARP request.
Source MAC Address: La direccin MAC de Win-Server1
La trama es enviada por Win-Server1, recibida por el Logical Switch Win-Servers. El Logical
Switch revisa su tabla de direcciones MAC y enva la trama al puerto que se conecta a la LIF1.
DLR recibe la trama, mira la direccin MAC de destino, se da cuenta que esa trama es para l,
revisa la direccin IP de destino y preparar (cambiar) la trama para ser enviada a LinuxServer1. La trama ethernet cambiar de la siguiente forma:
Destination MAC Address: La MAC Address de Linux-Server1. Si no la conoce, har un ARP
Request.
Source MAC Address: La direccin MAC de la interfaz LIF que se conecta a un enlace uplink
para salir al mundo fsico. (En este caso sera la pMAC si la LIF se conecta de forma directa al
mundo fsico o una vMAC si la LIF se conecta a un NSX Edge). La pMAC si puede ser vista por
el mundo fsico. Como conclusin la vMAC no es vista por los switches fsicos y ser la misma
en cada ESXi.
pMAC o Physical MAC es la direccin MAC de una LIF conectada a un Distributed Port Group
configurado con una o varias VLANs. Esta direccin MAC ser distinta en cada ESXi.
En un DLR hay dos tipos de LIFs:
VXLAN LIF.
VLAN LIF.
VXLAN LIF
Si una LIF se conecta a un Logical Switch (Un switch lgico es una nica VXLAN), se le
considera una VXLAN LIF y la direccin MAC es la vMAC, la cual no ser vista por los switches
fsicos. A un Switch Lgico solo se le podr conectar una VXLAN LIF. Lo que se observa en la
Figura 4 son 2 VXLAN LIFs.
VLAN LIF
Si una LIF se conecta a un Distribued Port Group respaldado por una VLAN, se le conoce como
VLAN LIF y la direccin MAC es la pMAC, la cual si podr ser vista por los switches fsicos. Este
tipo de LIF es la que le da al DLR conectividad directa con el mundo fsico.
Dado a que un Distributed Port Group solo puede pertenecer a un solo Distributed Switch, una
VLAN LIF solo podr existir en un solo switch distribuido. En contaste, un Logical Switch,
aunque en esencia tambin es un Distributed Port Group, es un Logical Switch y este si

puede ser configurado en distintos switches distribuidos.
Dado tambin a que la pMAC es distinta en cada Host pero en esencia son direcciones MAC del
mismo DLR, un swtich fsico podra entrar en confusin. Para remediarlo, NSX Controller
elegir una VLAN LIF en nombre de todos los ESXi. A esta LIF se le conoce como Designated
Instance y es la encargada de:
Responder ARPs enviados por el mundo fsico en nombre de todos los LIFs.
Enviar ARPs en nombre de todos los LIFs al mundo fsico.
As que si por ejemplo se hay dos ESXi entonces habrn dos VLAN LIF. Una de estas ser
elegida como la instancia designada. Cuando el trfico fluye del mundo fsico a la VLAN LIF, la
instancia designada recibir el trfico. Cuando el trfico fluye de un ESXi hacia el mundo fsico,
ste no pasar por la instancia designada.
VLAN LIF no es el nico mtodo que permite a un DLR salir al mundo fsico. Hay dos formas
para dotar a un DLR de una salida a la infraesturcura fsica:
Conectando un LIF a un Distributed Port group configurado con una o ms VLANs.

Bsicamente el VLAN LIF. Se recomienda emplear este mtodo solo si se requiere salir
directamente al mundo fsico. Recordar que VLAN LIF requiere de una intancia designada.
Conectando un LIF a un Logical Switch. A este Logical Switch se le conecta tambin una
interfaz del NSX Edge. Se recomienda emplear este mtodo si se instalar un NSX Edge
entre el mundo fsico y el DLR. Esta opcin es la ms recomendada por VMware y no
requiere de una instancia designada.
VLAN LIF
Figura 5 VMwrae NSX VLAN LIF

De la figura 5 se puede concluir que:
El DLR tiene 5 LIFs.

LIF1 es una VXLAN LIF conecta al Logical Switch 1 (VXLAN 5000).
LIF5 es una VLAN LIF conectada directamente a un grupo de puertos distribuido
configurado con la VLAN 10.
Este DLR est enrutando el trfico de Este-Oeste (De forma horizontal).
El enrutamiento de Norte-Sur lo estara realizando el DLR.
LIF1,2,3 y 4 usan la misma vMAC y no ser vista en el mundo fsico.
LIF5 (VLAN LIF) emplea una pMAC que ser vista por el mundo fsico.
Como la VXLAN 5000, 50001, 50002 y 5003 estn directamente conectadas al DLR, no es
necesario configurar ningn protocolo de enrutamiento esttico ni dinmico para enrutar el
trfico entre stas.
Si de la VXLAN 5000 a la 5003 requieren alcanzar una red del mundo fsico, en este caso el
DLR no tiene esas redes directamente conectadas, por tanto se necesita de rutas estticas
o un protocolo de enrutamiento dinmico para tal propsito.
VXLAN LIF
Figura 6 VMware NSX VXLAN LIF

De la figura 6 se puede concluir que:
El DLR tiene 4 LIFs.

LIF1 es una VXLAN LIF conectada a Web Logical Switch.
LIF2 es una VXLAN LIF conectada a App Logical Switch.
LIF3 es una VXLAN LIF conectada a DB Logical Switch.
LIF4 es una VXLAN LIF conectada a Transit Logical Switch.
NSX Edge tiene una interfaz conectada a Transit Logical Switch.
Este DLR est enrutando el trfico de Este-Oeste (De forma horizontal).
El enrutamiento de Norte-Sur lo estara realizando el NSX Edge (De forma vertical).
LIF 1,2,3 y 4 usan la misma vMAC y no ser vista por el mundo fsico.
En este ejemplo no existe la pMAC.
Como las redes 172.16.10.0, 172.16.20.0 y 172.16.30.0 estn directamente conectadas al
DLR, no es necesario configurar ningn protocolo de enrutamiento esttico ni dinmico
para enrutar el trfico entre stas.
Si por ejemploo la red 172.16.10.0 requiere alcanzar a la red 192.168.100.0, se neceista en
este caso configurar enrutamiento esttico o dinmico.
Cmo crear un Distributed Logical Router

Para crear un DLR se pueden seguir los siguientes pasos:
Paso 1: Abrir una conexin a vCenter Server empleando el vSphere Web Client.
Paso 2: Ir a Home, Inventories, Networking and Security.
Paso 3: En el panel izquierdo seleccionar NSX Edges. En el panel de navegacin dar clic en
el smbolo ms (+) de color verde:
Figura 7 VMware NSX Add a Distributed Logical Router

Paso 4: Name and description.
Figura 8 VMware NSX New NSX Edge Name and Description
Install Type: Permite definir si se crear un NSX Edge (Edge Services Gateway) o un
Distributed Logical Router (Logical (Distributed) Router). Como lo que se busca es crear un
Distributed Logical Router se selecicona esa opcin.
Enable High Availability: Tanto el NSX Edge como el DLR permiten manejar mltiples
instancias para dotarlos de alta disponibilidad. En un futuro post se hablar ms acerca de
esto.
Name: Nombre que se dar al Logical Router Control VM. Con este nombre se visualizar
en el inventareio de vCenter Server.
Hotname: Nombre de mquina que se dar al Logical Router Control VM.
Description: Una descripcin de este DLR.
Tenant: A qu Tenant ser destinado este DLR.
Clic en Next para continuar.

Paso 5: CLI credentials.
Figura 9 VMware NSX New NSX Edge CLI credentials

Aunque el Distributed Logical Router se encuentra en el plano de datos (es un mdulo dentro
de los ESXis), en el plano de control se necesita desplegar el Logical Router Control VM.
Command Line Interface credentials permite definir el usuario y clave para ingresar por SSH o
de forma local a esta mquina virtual y as poder ingresar comandos de solo lectura.
Username: Por defecto es admin

Password: Clave del usuario. La password deber ser de mnimo 12 y mximo 255
caracteres. Deber tener al menos una mayscula, una minscula y un carcter especial.
Enable SSH: Activar esta opcin si se tiene planeado gestionar por SSH el Logical Router
Control VM.

Paso 6: Configure deployment
Figura 10 VMware NSX New NSX Edge Configure Deployment
Datacenter: Especificar en qu datacenter lgico ser desplegado el Logical Router

Control VM.
NSX Edge Appliances: Dar clic en el smbolo ms (+).
Figura 11 VMware NSX New NSX Edge Configure Deployment Add NSX Edge Appliance
Clster/Resource Pool: En qu clster o pool de recursos ser ubicado el Logical Router

Control VM.
Datastore: En qu Datastore se albergar el Logical Router Control VM.
Host: El ESXi que tendr el Logical Router Control VM.
Folder: En qu folder de la vista VMs and Templates se ubicar el Logical Router Control
VM.

Paso 7: Configure interfaces.
Figura 12 VMware NSX New NSX Edge Configure interfaces

Managment Interface Configuration
Connected to: Clic en Select para seleccionar en qu grupos de puertos distribuido o

logical swtich se conectar el Logical Router Control VM. Es importante que el grupo de
puertos distribuido especificado pueda alcanzar a NSX Manager y NSX Controller. En la
siguiente grfica se ha seleccionado el grupo de puertos distribuido Managment, el cual
es la red de administracin en donde se encuentra vCenter Server, NSX Manager y NSX
Controller:
Figura 13 VMware NSX New NSX Edge Configure interfaces Managment Interface
(+): Dar clic en el ms de color verde para adicionar una direccin IP a esta interfaz:
Figura 14 VMware NSX New NSX Edge Configure interfaces Add IP Address to the
Managment Interface
Figura 15 VMware NSX New NSX Edge Configure interfaces Managment Interface
Add Subnet
1. Dar clic en el + apara adicionar una direccin IP a la interfaz de administracin del Logical
Router Control VM.
2. IP Address: Especifcar la direccin IP.
3. OK: Es importante que se de clic en OK o de lo contrario la direccin IP no ser tenida en
cuenta en la configuracin.
4. Subnet prefix length: Introducir la mscara de red.
Configure interfaces of this NSX Edge
Figura 16 VMware NSX New NSX Edge Configure interfaces Configure Interfaces of this
NSX Edge
En la figura 16 dar clic en el + para adicionar las interfaces (LIFs) del Distributed Logical
Router:
Figura 17 VMware NSX New NSX Edge Configure interfaces Configure Interfaces of this
NSX Edge Add Interface
Name: Introducir un nombre a la LIF.

Type: Hay dos tipos de LIF. Internal se emplea para conectarse a un Logical Switch. Uplink
se emplea como VLAN LIF o VXLAN LIF si ste ultimo cuenta con un NSX Edge entre el DLR
y el mundo fsico. Ver figuras 5 y 6.
Connected to: Seleccionar el Logical Switch o Distributed Port Gorup al cual se conectar
esta interfaz.
Connectivity Status: Modo de la interfaz (Activa o Desactiva).
Configure Subnets: Clic en + para adicionar la direccin IP. Es similar al procedimiento
realizado en la figura 15.
MTU: Definir la unidad mxima de transferencia de la interfaz virtual. 1500 Bytes es el
valor por defecto. No confundir este valor con la MTU de 1600 bytes de los VTEPs. Las LIFs
no encapsulan ni desencapsulan las tramas de las mquinas virtuales en paquetes UDP.
Figura 18 VMware NSX New NSX Edge Configure interfaces Ready

En la figura 18 se puede ver que se han creados dos LIFs. La LIF con IP 172.16.30.1 se
conecta al Logical Switch Win-Servers. La LIF con IP 172.16.30.1 se conect al Logical Switch
Linux-Servers. Observar tambin la figura 4 para un mejor entendimiento.
Paso 8: Configure HA.
Tanto NSX Edge como el DLR pueden ser protegidos en alta disponibilidad. En un futuro Post
se estar hablando ms acerca de esto.
Paso 9: Ready to complete
Clic en Finish.
Verificacin
Una vez finalizado el despliegue, el Logical Router Control VM podr ser visto en la lista de
NSX Edges:
Figura 19 VMware NSX Logical Router -Verification

Tambin puede ser verificado revisando directamente la mquina virtual:
Figura 20 VMware NSX Logical Router -Verification VM

Pruebas:
Figura 21 DLR LIFs
El ping desde Win-Server1 a Linux-Server1 funcion. En este caso la trama ethernet de

Win-Server1 nunca se encapsul en un paquete UDP por el VTEP de ESXi01.
El ping desde Win-Server1 a Linux-Server2 funcion. En este caso el VTEP del ESXi01 su
encapsulo la trama.
VMware NSX Cmo funcionan y aprenden los VTEPs

Continuando con esta serie de Posts acerca de VMware NSX, es tiempo de hablar acerca de
cmo funcionan y aprenden los VTEPs.
Mucho se ha hablado acerca del NSX Controller. Se sabe que es una mquina virtual
desplegada por el NSX Manager y que puede ser construida en un clster de nodos. Tambin
se ha visto que sta es capaz de eliminar la necesidad de configurar IGMP y/0 PIM de la red
fsica, dependiendo del modo de replicacin. Tambin se mencion que podra eliminar el
trfico de broadcast. El objetivo de este Post es conocer de qu forma ayuda a la reduccin de
broadcast, cmo funcionan y cmo aprenden.
Recordar que el NSX Controller se encarga de administrar los mdulos de Logical Switch y
Logical Router de los ESXi y tambin almacena las siguientes tablas:
Tabla
Tabla
Tabla
Tabla
de VTEPs.
de MACs.
ARP.
de enrutamiento. (No oncludo en este Post).
Lo primero que se debe conocer es cmo aprende y de dnde obtiene esta informacin.
Nota: No se recomienda leer este Post sin antes haber visto o tener claro:
Introduccin a las VXLAN

Modos de replicacin
Construccin de la tabla VTEP

Cuando una mquina virtual es conectada a un Logical Switch y siempre y cuando est
encendida, el ESXi enviar un mensaje por medio del agente UWA al NSX Controller indicando
la relacin VNI/VTEP_IP.
VMware NSX VNI-VTEP Report

En la figura 1 se tienen 3 ESXis. ESXi-1 tiene la VM1 conectada a la VXLAN 5001. ESXi-2 tiene
la VM2 conectada a la VXLAN 5001. ESXi-3 no tiene ninguna VM encendida. Cuando VM1 se
enciende en el ESXi-1, el host enviar un mensaje al NSX Controller indicando que la VNI 5001
se encuentra en la IP 10.20.10.10. Cuando la VM2 se enciende, el host enva un mensaje al
NSX Controller indicando que el VNI 5001 se encuentra en la IP 10.20.10.11. Esta informacin
es recibida por el nodo de NSX Controller que controla y administra a ese Logical Switch
(dependiendo de los slices); suponer que en este caso es el nodo A. El nodo A del NSX
Controller recibe esta informacin, actualiza su tabla VTEP y la replica a todos los ESXi
conectados a la VXLAN 5001; esto significa que ESXi-3 no recibe esta actualizacin, ya que
no tiene ninguna VM conectada en esa VXLAN (Logical Switch). De esta forma cada host
recibir la actualizacin del nodo A:
ESXi-1 actualiza su tabla VTEP y ahora conoce que 10.20.10.10 y 10.20.10.11 tienen VMs
conectadas a la VXLAN 50001.
ESXi-2 actualiza su tabla VTEP y ahora conoce que 10.20.10.10 y 10.20.10.11 tienen VMs
conectadas a la VXLAN 50001.
ESXi-3 no envi ni recibi actualizacin debido a que no tiene VMs conectadas a la VXLAN
5001.
En un parntesis, suponer que VM1 enva un ARP request para conseguir la MAC de VM2. Este
trfico es de BUM y ser tratado segn el modo de replicacin. Suponer que se ha configurado
en modo Unicast, por lo tanto, ESXi-1 revisa su tabla VTEP y deber enviar ese broadcast
encapsulado solo a 10.20.10.11.
Como conclusin se puede decir que hay dos tablas VTEP:
Tabla VTEP del host

Tabla VTEP del NSX Controller
La tabla VTEP del host es la que finalmente se revisar para conocer a quin o quines debe
ser enviado un trfico de BUM (Modo de replicacin).
Construccin de la tabla MAC
Cada ves que un Logical Switch aprende una direccin MAC, el ESXi que contiene a esa VM
enviar un mensaje al NSX Controller encargado de esa red lgica informando acerca de la
relacin VNI/MAC/VTEP_IP . A continuacin el nodo encargado de ese slice deber actualizar
su tabla MAC pero no enviar actualizacin a los ESXi. Esto significa que cada host solo tendr
inicialmente conocimiento de las direcciones MAC de las mquinas virtuales que actualmente
est corriendo, pero ir aprendido con el tiempo las MAC de las VMs en otros ESXi.
Figura 2 VNI-MAC Address Report

En el ejemplo de la figura 2, ESXi-1 enva un mensaje a travs del agente UWA al nodo
encargado de esa VNI que la MAC1 se encuentra en la VNI 5001 con IP 20.10.10.10. Del
mismo modo, ESXi-2 enva un mensaje a travs del agente UWA al nodo encargado de esa
VNI que la MAC2 se encuentra en la VNI 5001 con IP 20.10.10.11.
NSX Controller posee una tabla indicando que la MAC1 est en la VNI 5001 y en el VTEP con
IP 10.20.10.10. La MAC2 est en la VNI 5001 y en el VTEP con IP 10.20.10.11. Cada host
inicialmente solo tendr informacin de las MAC de sus propias VMs.
Construccin de la tabla ARP

Para formar la tabla ARP es necesario que el NSX Controller tenga conocimiento de las
direcciones IP de las mquinas virtuales. Un ESXi sabr de la direccin IP de sus mquinas
virtuales de dos formas:
Si la VM recibe IP por DHCP, el host har un snooping del mensaje de la respuesta del
mensaje DHCP.
Si la VM tiene IP fija, el VTEP informar la IP de la mquina virtual descubierta en los
mensajes de ARP Request.
Cuando un ESXi aprende una IP de una de sus mquinas virtuales, enviar un mensaje
VNI/MAC/VM_IP/VTEP_IP al nodo del NSX Controller encargado de ese Logical Switch. En este
caso NSX Controller tampoco actualizar a los ESXi.
Figura 3 VNI-IP Address Report

En la figura 3 por ejemplo, el ESXi-1 enva un mensaje al nodo de NSX Controller encargado de
administrar el Logical Switch con VXLAN 5001 indicando que la IP1 pertenece a la MAC1 y se
encuentra en la VNI 5001 con direccin de VTEP 10.20.10.10.
A continuacin se estudiarn varios escenarios:
Escenario 1: Trfico de BUM con modo de replicacin Unicast. VM de origen y de destino se

encuentran en el mismo ESXi.
Escenario 2: Trfico de BUM con modo de replicacin Unicast. VM de origen y de destino se
encuentran en distintos ESXi.
Escenario 3: Trfico de Unicast. VM de origen y de destino se encuentran en distintos ESXi.
Escenario 4: Trfico de BUM con modo de replicacin Multicast. VM de origen y de destino

se encuentran en distintos ESXi.
Escenario 1: Trfico de BUM con modo de replicacin Unicast. VM de origen y de

destino se encuentran en el mismo ESXi
Cmo aprenden y se construyen las tablas VTEPs en este escenario? A continuacin un
ejemplo:
Figura 4 VMware NSX E1

En la figura 4:
Posibilidad 1: VM2 nunca se ha visto involucrado en mensajes de broadcast, como ARP y
DHCP.
VM1 y VM2 estn conectados al mismo Logical Switch (lo que es lo mismo decir que estn
conectados a la misma VXLAN, VNI o red lgica), en este ejemplo la VNI 5001.
VM1 y VM2 se encuentran en el mismo ESXi.
VM1 enva un mensaje de ARP Request solicitando la direccin MAC de VM2.
El mensaje de broadcast es recibido por el Logical Switch y reenviado a todos quienes
estn conectados al mismo switch lgico del mismo host.
En paralelo sucedern dos cosas: VM2 recibir el broadcast dado a que se encuentra en
ese mismo Logical Switch. Mientras tanto, el mdulo de seguridad del switch lgico enviar
un mensaje al NSX Controller preguntando por la MAC de VM2. Segn la figura 4, este
mensaje ser enviado por la red de administracin.
Es evidente que VM2 responder primero con un ARP Reply antes de que el NSX Controller
enve una respuesta.
El ARP reply llega el swtich lgico y es enviado a la VM1.
Dado a que VM2 nunca se ha visto involucrado en mensajes de broadcast, como ARP y
DHCP, el NSX Controller no conoce la MAC de VM2
ESXi actualiza su tabla ARP y enviar una actualizacin VNI/MAC/VTEP_IP al NSX
Controller, indicando que en la VNI 5001 hay una MAC2 en el VTEP con direccin IP
10.20.10.10.
Posibilidad 2: VM2 se ha visto involucrado en mensajes de broadcast, como ARP y DHCP.

Si el NSX Controller si tiene la MAC de VM2, responder al ESXi, pero, es probable que
responda primero VM2 con un mensaje de ARP Reply.
Conclusin:
No fue necesario encapsular la trama ethernet original de VM1 dado a que ambas
mquinas virtuales (origen y destino), se encontraban en el mismo ESXi.
NSX Controller no juega un rol vital en este escenario.
No fue necesario emplear un Distributed Logical Router para la comunicacin entre las
VMs.
Escenario 2: Trfico de BUM con modo de replicacin Unicast. VM de origen y de

destino se encuentran en distintos ESXi
Figura 5 VMware NSX E2
En la Figura 5:
VM1 y VM2 estn conectadas al mismo Logical Switch 5001 pero se encuentran en distintos
ESXis.
1. VM1 enva un ARP Request solicitando la MAC asociada a la IP2. El logical Switch en ESXi-1
recibe el broadcast y lo reenva a todos los equipos conectados a la misma VXLAN del mismo
ESXi. Como en ese host no est la VM2, nadie responde hasta el momento al mensaje de
broadcast.
2. En paralelo al paso 1, el mdulo de seguridad de ese Logical Switch enva un mensaje al
NSX Controller empleando la red de administracin preguntando por la direccin MAC de IP2.
Si NSX Controller tuviera la respuesta, se evitara enviar el broadcast por la red de transporte.
En este ejemplo NSX Controller si tiene la respuesta en su tabla ARP.
3. NSX Controller recibe la peticin.
4. NSX Controller revisa su tabla ARP y encuentra una coincidencia.
5. NSX Controller enva la respuesta al ESXi-1.
6. ESXi-1 recibe la informacin, actualiza su tabla y ennva un ARP Reply en nombre de VM2;
esto significa que la MAC de origen en la respuesta que dar a VM1 tendr la MAC2. VM1
recibe la respuesta.
Conclusin:
Se evit enviar un broadcast y emplear el modo de replicacin ya que NSX Controller

conoca la MAC de la IP2.
NSX Controller juega un rol vital en este escenario.
VMs.
Qu sucede si NSX Controller no conoce la MAC de IP2?
VM1 enva un ARP Request solicitando la MAC asociada a la IP2. El logical Switch en ESXi-1
recibe el broadcast y lo reenva a todos los equipos conectados a la misma VXLAN del
mismo ESXi. Como en ese host no est la VM2, nadie hasta el momento responde al
mensaje de broadcast.
En paralelo al paso 1, el mdulo de seguridad de ese Logical Switch enva un mensaje al
NSX Controller empleando la red de administracin preguntando por la direccin MAC de
IP2. En este ejemplo NSX Controller no tiene la respuesta en su tabla ARP.
NSX Controller recibe la peticin.
NSX Controller revisa su tabla ARP y no encuentra una coincidencia.
Como ESXi-1 no obtiene la MAC de IP2 del NSX Controller, se prepara entonces para tratar la
comunicacin como una BUM (Broadcast, Unknow Unicast and Multicast) y emplear el modo
de replicacin Unicast.
ESXi-1 revisa su tabla de VTEP y se da cuenta que tanto 10.20.10.10 y 10.20.10.11 tienen
VMs conectadas a la VNI 5001. ESXi-1 concluye que solo debe enviar a 10.20.10.11. En
este ejemplo no hay segmentos VTEPs remotos, por lo tanto ESXi-1 no tiene en su tabla
UTEPs.
ESXi encapsula la trama original de VM1 (un ARP Request) de la siguiente manera:
Figura 5a VMware NSX E2a

Donde:
IP DA: Es la IP del VTEP de destino en donde se encuentra VM2.

IP SA: Es la IP del VTEP de origen, en este caso, en donde se encuentra VM1.
XVLAN: VNI 5001 es la red lgica en donde se encuentra conectada VM1.
L2 DA: Es la MAC de la mquina virtual de destino, en este caso un broadcast, ya que se
trata de un ARP Request.
L2 SA: Es la MAC de la mquina virtual de origen, en este caso MAC1.
ESXi-2 recibe la trama encapsulada, revisa si tiene VMs conectadas en esa VNI, la
desencapsula y pasa a la VM2. ESXi-2 tambin actualiza su tabla indicando que en la VNI
5001, hay una VM1 con MAC1/IP1 en el VTEP 10.20.10.10.
VM2 responde con un ARP Reply (un arp reply es un mensaje de unicast) y ESXi-2 lo
encapsula de la siguiente forma:
Figura 5b- VMware NSX E2b
ESXi-2 acaba de aprender una nueva MAC e IP, por lo tanto se la enviar al NSX Controller
para futuras referencias y consultas.
ESXi-1 recibe la el paquete encapsulado, revisa la VNI, nota que tiene VMs conectadas a
esa VXLAN, desencapsula el paquete y lo entrega a la VM1. ESXi-1 aprovecha tambin para
actualizar su tabla.
Conclusin:
No se evit enviar un broadcast y emplear el modo de replicacin ya que NSX Controller no

conoca la MAC de la IP2.
NSX Controller juega un rol vital en este escenario.
VMs.
La conclusin ms importante del escenario 2 es que si la comunicacin se realiza gracias al

NSX Controller, ESXi-2 nunca recibe ese broadcast y no aprende la ubicacin de VM1. Pero, si
NSX Controller no es empleado, ESXi-2 recibe el broadcast y conocer la ubicacin de VM1.
Escenario 3: Trfico de Unicast. VM de origen y de destino se encuentran en
distintos ESXi
El escenario 1 y 2 mostraron cmo se aprenda en la red si el mensaje original fuese un
broadcast. Una mquina virtual realizar un ARP request si al revisar su propia tabla ARP no
tiene una entrada que le indique cul es la direccin MAC para esa IP de destino. En los
escenarios 1 y 2, la VM1 recibi finalmente la respuesta (ARP Reply) y actualiz su propia tabla
ARP del sistema operativo. Aunque los mensajes de ARP son los paquetes de broadcast que
ms se difunden en las redes actuales, VM1 en realidad no ha enviado su mensaje original a
VM2. Durante todo este tiempo lo ha guardado en cach a la espera de obtener la MAC de
VM2 para terminar de encapsular la trama ethernet. Cuando VM1 termina de armar la trama,
la enviar por su vNIC a VM2. En el escenario 3 se mostrar qu sucede cuando VM1 enva
informacin a VM2 pero ya conociendo todos los parmetros de L2, es decir, enviar un
mensaje de unicast y no un broadcast:
Figura 6 VMware NSX Intra Logical Switch Unicast Communication

En la figura 6:
VM1 y VM2 se encuentran en la misma red (VXLAN 5001) pero en distintos ESXis.
VM1 se desea comunicar con VM2, pero conoce la MAC de destino.
1. VM1 enva un mensaje unicast, especificando como IP de origen IP1, IP de destino IP2,
MAC de origen MAC1 y MAC de destino MAC2.
2. La trama ethernet original de VM1 es recibida por el Logical Switch y se consulta la tabla
VTEP de ESXi-1. Este host ya ha tenido comunicacin previa con VM2, por lo tanto, tiene una
entrada que le ndica a qu VTEP debe enviar esta trama. ESXi-1 encapsula la trama ethernet
en como se indica en la figura, especificando que la IP de destino ser el VTEP en dnde est
VM2 y al enva a ese host. Notar que no se est empleando ningn modo de replicacin, ya
que la comunicacin en s es unicast.
3. ESXi-2 recibe el paquete, revisa la VNI, nota que tiene VMs conectadas a esa red,
desencapsula la informacin y entrega la trama original de ethernet a VM2. Notar que las VMs
no tienen idea alguna de qu es una VXLAN. Las VXLANs son totalmente transparentes para
las VMS. Dependiendo si en el escenario 2 ESX-2 recibi o no el broadcast, ESXi-2 aprovecha o
no para actualizar su tabla, ya que podra acabar de aprender que en la VNI 5001, hay una
VM1 con IP1 y MAC2 ubicada en la VTEP 10.20.10.10.
Escenario 4: Trfico de BUM con modo de replicacin Multicast. VM de origen y de

destino se encuentran en distintos ESXi
Suponer la siguiente te red virtual:
Cuatro ESXi en clster.

Todos los VTEPs en el mismo segmento de red.
Se ha configurado la direccin de multicast 239.1.1.100.
Se ha configurado en la red fsica IGMP Snooping y Querier.
VM1 y VM2 estn en la misma red lgica.
VM1 se desea comunicar con VM2, pero no conoce la MAC de destino.
Para comprender este ejemplo y a modo de repaso de todo lo que ha observado en esta serie
de Posts, se pueden concluir varias cosas:
Cuando VM1 es encendida, el VTEP del Host 1 enviar un mensaje IGMP report para
unirse al grupo de Multicast 239.1.1.100. El switch fsico recibe este paquete y asocia ese
puerto a ese grupo. El VTEP del host 1 tambin enviar un mensaje a NSX Controller
indicando que en el VTEP 10.20.10.10 hay una VM conectada a la VXLAN 5001.
Cuando VM2 es encendida, el VTEP del Host 4 enviar un mensaje IGMP report para
unirse al grupo de Multicast 239.1.1.100. El switch fsico recibe este paquete y asocia ese
puerto a ese grupo. El VTEP del host 4 tambin enviar un mensaje a NSX Controller
indicando que en el VTEP 10.20.10.10 hay una VM conectada a la VXLAN 5001.
Host 2 y 3 no envan nada porque no tienen VMs encendidas en la VXLAN 5001 y otra red
lgica.
NSX Controller recibe las actualizaciones y enva un mensaje al Host 1 y 4 para que
actualicen sus tablas. Host 1 ahora sabe que hay mquinas conectadas a la VNI 5001 en el
VTEP 10.20.10.10 y 10.20.10.13. Del mismo modo Host 4 sabr que hay VMs en la VNI
5001 en el VTEP 10.20.10.13 y 10.20.10.10.
1. VM1 enva un mensaje de broadcast a VM2, ya que no conoce su direccin MAC. En el

mensaje de la trama ethernet original, VM1 especificar como IP de origen IP1 e IP2 como
destino. Direccin MAC de origen MAC1 y un broadcast como destino. El broadcast llega al
Switch Lgico (VXLAN 5001) del host 1 y enva ese broadcast a todos los equipos que tenga
conectado en esa misma red en ese mismo host. Nadie responde hasta el momento. El host 1
consulta al NSX Controller encargado de la VNI 5001. NSX Controller no tiene la direccin MAC
de VM2. Host 1 enva un mensaje a NSX Controller especificando que en el VTEP 10.20.10.10
hay una MAC1 con IP1.
2. El host 1 revisa su tabla VTEP y se prepara para encapsular la trama ethernet origial.
Aunque sabe que en el host 4 hay una VM en esa misma red, no sabe con certeza si esa VM
tiene la MAC que esta buscando. El mensaje es un broadcast y ser tratado bajo el modo de
replicacin configurado, en este caso, Multicast. En el paquete encapsulado que enviar, como
direccin IP de origen especificar su propia IP del VTEP (10.20.10.10) y como destino, la
direccin de multicast 239.1.1.100.
El switch fsico recibe el paquete y lo replica por todos los puertos registrados a ese grupo de
multicast; en este ejemplo, solo al host 4.
3. Host 4 recibe el paquete, aprovecha para actualizar su tabla, aprendiendo que en la VNI
5001 hay una VM con IP1, MAC1 y est ubicada en la VTEP 10.20.10.10. Revisa la VNI y se da
cuenta que tiene VMs conectadas a esa misma red. Desencapsula el paquete y entrega solo la
trama ethernet original a VM2.
4. VM2 recibe la trama ethernet, revisa la IP de destino, concluye que es para l mismo y
responde el mensaje con un ARP Reply, especificando como IP de origen IP2, IP de destino
IP1, MAC de origen MAC2 y MAC de destino MAC1. Tambin aprovecha para actualizar su
propia tabla ARP. El mensaje llega al Switch Lgico y enva un mensaje al controller
indicndole que acaba de aprender la IP y MAC de VM2. De esta forma el NSX Controller podr
contar con esta informacin. El host 4 revisa su tabla, encapsula la trama, indicando que la IP
del VTEP de origen es 10.20.10.13 y de destino 10.20.10.10. Host 1 recibe el paquete,
actualiza su tabla, revisa la VNI, desencapsula y pasa a VM1. VM1 recibe, oberva la MAC de
destino, concluye que es para l, desencapsula y mapea la IP2 con MAC2 en su tabla ARP.
VMware NSX NSX Edge

Continuando con esta serie de Posts acerca de VMware NSX, es el turno del NSX Edge. En el
Post acerca de VMware NSX Distributed Logical Router se aclar que su funcin principal es la
de enrutar trfico de Este a Oeste, aunque ciertamente tambin puede hacerlo de Norte a Sur.
El Distributed Logical Router o DLR de NSX solo permite desplegar servicios hasta capa 3 y no
cuenta con muchos protocolos que si proporciona NSX Edge.
VMware NSX NSX Edge
NSX Edge es una mquina virtual que despliega NSX Manager, permitiendo as contar con
servicios de capa 3 a 7, tales como:
Enrutamiento: Permite enrutar trfico de Norte a Sur. Aunque tambin lo puede hacer de
Este a Oeste, el DLR es ms eficiente en este trabajo. NSX Edge soporta rutas estticas,
redistribucin de rutas, OSPF, IS-IS y BGP.
Firewall: Permite crear reglas de firewall para el trfico que cursa entre los segmentos
lgicos (logical Switch) y el mundo exterior, es decir, de Norte a Sur. DLR no permite crear
reglas de firewall ni para el trfico Este a Oeste ni Norte a Sur.
NAT (Network Address Translation): Esta caracterstica permitir traducir o
enmascarar direcciones IP. Sopora SNAT (Source NAT) y DNAT (Destionation NAT). El DLR
no puede hacer NAT.
DHCP: NSX Edge puede servir como servidor DHCP y DHCP Relay. DLR no sporta DHCP.
Balanceo de Carga: NSX Edge soporta dos mtodos de Balanceo de carga: Inline y OneArmed. El DLR no puede balancear carga.
VPN (Virtual Private Network): NSX Edge soporta tres tipos de VPNs; Site-to-Site, SSL
VPN (Remote Access) y L2VPN (VPNs de capa dos). Con DLR no es posible hacer VPNs.
DNS Relay. DLR no soporta DNS Relay.
Todos los anteriores servicios pueden ser habilitados en NSX Edge de ser necesario.
Nota: Este Post no pretende hablar acerca de servicio en profundidad. En futuros Posts se
hablar de cada uno de los servicios.
NSX Edge puede ser desplegado con cuatro tamaos, supliendo as diferentes necesidades:
Tamao
# vCPUs Memoria (GB)
Comentarios
Compact
0,512
Firewall Basico
Large
Firewall de mediano nivel
Quad-Large 4
Firewall de alto desempeo
Tamao
X-Large
# vCPUs Memoria (GB)

6
Comentarios
Firewall de alto desempeo + Balanceador de carga
Showing 1 to 4 of 4 entries
Nota: NSX Edge puede ser re-dimensionado. Si se tiene por ejemplo un NSX Edge Compacto,
este puede ser pasado a Largo re-desplegndo. NSX desplegar un nuevo NSX y copiar la
configuracin al nuevo. Esto puede implicar indisponibilidad.
Smbolos de los servicios
Para poder comprender diagramas es preciso tener en cuenta los siguientes smbolos:
Figura 1 VMware NSX Network icons
Cmo desplegar NSX Edge

NSX Edge es deplegado por NSX Manager. Los pasos para esto son los siguientes:
Paso 1: Conectado a vCenter Server mediante el Web Client, ir a Home, Inventories,
Paso 2: En la barra lateral izquierda, clic en NSX Edges. Despes clic en el smbolo + de
color verde:
Figura 2 VMware NSX Add NSX Edge

Paso 3: Name and description.
Figura 3 VMware NSX New NSX Edge Name and description
Install Type: Definir si lo que se desplegar es un NSX Edge (Edge

Services Gateway) o un Distributed Logical Router. Opcionalmente se puede
activar la opcin Enable High Availability para dotar con alta disponibilidad
ya sea el DLR o el NSX Edge en un esquema Activo/Pasivo.
Name: Nombre como se ver esta mquina virtual en el inventario de

vCenter Server, folder y archivos.
Hostname: Nombre a nivel de mquina.
Description: Una descripcin opcional.
Tenant: Opcionalmente, para qu Tenant ser este NSX Edge o DLR.
Paso 4: CLI Credentials.
Figura 4 VMware NSX New NSX Edge CLI Credentials
User Name: Usuario para conectarse por consola o SSH al CLI de este
mquina virtual. Por defecto es admin.
Password: Esta password debe tener mnimo 12 caracteres, al menos una
mayscula, una minscula, un dgito y un caracter especial.
Enable SSH Access: Activar si se desea gestionar remotamente esta
mquina virtual.
Nota: La conexin por CLI con este usuario permitir monitorear y configurar
el NSX Edge.
Paso 5: Configure Deployment.
Figura 5 VMware NSX New NSX Edge Configure Deployment
Datacenter: Especificar en qu datacenter lgico ser desplegada esta

mquina virtual.
Appliance Size: Tamao del Appliance. Para ms informacin observar la
tabla 1 de este Post.
Enable auto rule generation: Si esta casilla est marcada, el sistema
generar automticamente reglas de firewall, NAT y enrutamiento para
activar el control de trfico de esos servicios. Al no ser activada esta opcin
simplemente si por ejemplo se configura balanceo de carga en modo OneArmed, el sistema no crear automticamente el SNAT ni el DNAT; esta tarea
deber ser de forma manual.
NSX Edge Appliances: Clic en + para especificar en qu clster/pool de
recursos, host, datastore y folder se desea desplegar esta mquina virtual.
Paso 6: Configure interfaces.
Clic en el smbolo + para aadir interfaces:
Figura 6 VMware NSX New NSX Edge configure interfaces

Nota: El nmero mximo de interfaces de un NSX Edge es 10.
Paso 7: Default gateway settings.
Figura 7 VMware NSX New NSX Edge Default gateway settings
Configure Default Gateway: Inicialmente si a este NSX Edge no se le

configurar enrutamiento, se debe entonces configurar el default gateway.
vNIC: Especificar la interfaz del NSX Edge (creada en el paso 6) por donde
se deber desbordar todo el trfico que no est directamente conectado o
que no se encuentra en la tabla de enrutamiento definido de forma explcita.
Gateway IP: Definir la direccin IP del dispositivo de capa 3 al que se
enviar el trfico en caso de no estar presente en la tabla de enrutamiento
una red de destino. Esta IP debe poder ser alcanzada segn la interfaz
seleccionada en vNIC.
MTU: Tamaa en bytes de la mxima unidad de transferencia.
Paso 8: Firewall and HA
En este punto del Wizard se puede especificar cul ser la poltica por defecto del firewall
(Aceptar o Denegar) y si se har logging o no. En futuros Posts se estar hablando acerca de
la configuracin del Firewall del NSX Edge.
Tambin es posible definir los parmetros de HA si en el paso 3 fue activada esta
funcionalidad. En futuros Posts se tratar este tema con ms detalle.
Paso 9: Ready to complete. Clic en finish para finalizar.
Figura 8 VMware NSX New NSX Edge Ready to complete

Verificacin
Para verificar que todo ha salido bien con el despliegue, ir al inventario de vCenter Server y
observar si la mquina virtual se encuentra all y encendida:
Figura 9 VMware NSX New NSX Edge Verification
VMware NSX Enrutamiento esttico

Continuando con esta serie de Post acerca de VMware NSX, en esta oportunidad se tocar el
tema de enrutamiento esttico.
VMware NSX soporta tanto enrutamiento esttico como dinmico. A continuacin un breve
repaso.
Enrutamiento
El enrutamiento es la capacidad que tiene un dispositivo de capa tres para definir cul camino
debe tomar un paquete y ms an, el mejor camino para llegar al destino. Cuando un router
recibe un paquete, ste debe verificar la direccin IP de destino, revisar la tabla de
enrutamiento y sacar/enrutar el paquete por la interfaz adecuada para que pueda alcanzar su
destino. Un router decide qu ruta tomar basado en dos factores clave:
Distancia administrativa
Mtrica
La distancia administrativa DA califica la confiabilidad de un protocolo de enrutamiento. Entre

ms baja la distancia administrativa, en s, el protocolo y la ruta es mejor. Si por ejemplo un
router tiene dos rutas para llegar a un mismo destino, uno con DA 110 y otra con 120, el
router enviar en trfico por la ruta con DA 110. Pero qu sucede si ambas rutas tienen un DA
idntico? Aqu en donde entra a jugar la mtrica. La mtrica define qu camino es mejor que
otro en caso de que un router cuente con varias rutas para llegar al mismo destino y bajo el
mismo protocolo de enrutamiento. La mtrica se calcula dependiendo del protocolo de
enrutamiento; algunos emplean el nmero de saltos como RIP, otros el ancho de banda como
es el caso de OSPF.
Para comprender cmo funciona un router es necesario considerar lo siguiente:
Caso 1: Un router recibe un paquete, revisa la IP de destino y su tabla de enrutamiento y

nota que no tiene ninguna ruta para esa IP. Si el router no tiene configurada una ruta por
defecto, el paquete ser descartado.
nota que no tiene ninguna ruta para esa IP. Si el router tiene configurada una ruta por
defecto, el paquete es enviado al prximo salto de esa ruta por defecto.
nota que tiene dos rutas para llegar a ese destino. Una ruta tiene una distancia
administrativa menor que otra. El router enva el paquete por aquella ruta con menor
distancia administrativa.
caso 4: Un router recibe un paquete, revisa la IP de destino y su tabla de enrutamiento y
nota que tiene dos rutas para llegar a ese destino. Ambas rutas tienen la misma distancia
administrativa. Una de las rutas tiene una mtrica menor que otra. El Router enva el
paquete por aquella ruta con menor mtrica.

nota que tiene dos rutas para llegar a ese destino. Ambas rutas tienen la misma distancia
administrativa y la misma mtrica. El Router utilizar ambas rutas (balanceo de carga).
Enrutamiento esttico en VMware NSX

El enrutamiento esttico nos da la posibilidad de definir y ensearle a los dispositivos de capa
tres cmo alcanzar cada uno de los destinos de forma manual. En contraste, el enrutamiento
dinmico automticamente descubre las rutas para llegar a todos los destinos.
El enrutamiento esttico tiene la ventaja de conocer exactamente la topologa de la red, ya que
es el propio administrador quin define cmo se llega a cada destino. Su principal desventaja
es que escala muy mal; a medida que la red crece, la introduccin o eliminacin redes conlleva
un proceso de actualizacin manual en cada router, lo cual en infraestructuras grandes, es
inimaginable. Otra ventaja del enrutamiento esttico es la seguridad, esto debido a que los
routers no necesitarn intercambiar nada para conocer las rutas.
Como regla global, el enrutamiento esttico se debe especificar de forma bidireccional.
Por lo general, el enrutamiento esttico es til redes pequeas y con pocas probabilidades de
crecer.
Tanto el NSX Edge como el DLR de VMware soportan enrutamiento esttico. Esto puede ser
configurado ya sea por CLI o GUI.
Cmo crear un ruta esttica en el Distributed Logical Router
Para crear una ruta esttica en el DLR de VMware NSX, seguir los siguientes pasos:
Paso 1: Conectado a vCenter Server por medio del Web Client, clic en Inventories, Networking
and Security.
Paso 2: Clic en NSX Edge de la barra lateral izquierda.
Paso 3: Seleccionar la instancia del DLR y dar doble clic sobre ste.
Paso 4: Clic en Manage, Routing, Static Routes y finalmente en el smbolo +.
Figura 1 VMware NSX DLR Add static route

Paso 5:
Figura 2 VMware NSX DLR Add static route2
Description: Una descripcin opcional de esta ruta esttica.

Interface: Seleccionar la interfaz por la cual se alcanza al Next Hop.
Network: Especificar la direccin de la red de destino, en formato CIDR.
Next Hop: Introducir la direccin IP del prximo salto
MTU: Mxima unidad de transferencia.
Finalmente, clic en Publish Changes.

Cmo crear un ruta esttica en el NSX Edge
Paso 1: Conectado a vCenter Server por medio del Web Client, clic en Inventories,
Paso 2: Clic en NSX Edge de la barra lateral izquierda.
Paso 3: Seleccionar la instancia de NSX Edge y dar doble clic sobre ste.
Paso 4: Clic en Manage, Routing, Static Routes y finalmente en el smbolo +.
Figura 3 VMware NSX NSX Edge Add static route

Paso 5:
VMware NSX NSX Edge Add static route2
Description: Una descripcin opcional de esta ruta esttica.

Interface: Seleccionar la interfaz por la cual se alcanza al Next Hop.
Network: Especificar la direccin de la red de destino, en formato CIDR.
Next Hop: Introducir la direccin IP del prximo salto
MTU: Mxima unidad de transferencia.
Finalmente, clic en Publish Changes.
Ejercicio:
Dada la siguiente red, configurar el enrutamiento esttico que garantice la alcanzabilidad entre
las redes 172.16.28.0/24 y 172.16.30.0/24 con la red 192.168.1.0/24. El diagrama de la red
es:
NSX ejercicio 1

Curso NSX

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Curso NSX

Hochgeladen von

Copyright:

Verfügbare Formate

Introduccin a VMware NSX.

polticas directamente en la capa de software y no en el Hardware, proporcionando ms

Los servidores (VMware vSphere).

Figura 1 VMware NSX. Existing Physical Network

Figura 2 VMware NSX. Existing Physical Network and VMware vSphere

Finalmente en la siguiente figura se observa en dnde correra VMware NSX.

Figura 3 VMware NSX runs over vSphere

VMware NSX corre por encima de la infraestructura de Red Fsica y de la capa de

Figura 4 VMware NSX. Virtual Networks

Sobre de la capa de virtualizacin de VMware vSphere se crean mquinas virtuales. De forma

Figura 5 VMware vSphere

Figura 6 VMware NSX

Pero qu es una red virtual o virtual network?

Planos de VMware NSX

Figura 1 VMware NSX. Planes

VMware Distributed Switch

VMware Distributed Switch: En el Data Plane es donde reside el Switch Distribuido de

NSX Logical Router Control Virtual Machine: Es un virtual appliance y es desplegado

1. Retener la tabla de direcciones MAC, ARP, vTEP y Enrutamiento.

1. ntcpad: Se encarga de la comunicacin entre NSX Controller y los mdulos de Kernel

Enviar reglas de seguridad al firewall distribuido de los ESXi (vsfwd).

Instalacin y configuracin de NSX Manager 6.X

Proporciona la interfaz grfica de administracin UI y la NSX API. La API permite que

Requerimientos de NSX Manager

Figura 1 NSX Manager Port Requirements

Instalacin y configuracin de NSX Manager 6.X

Figura 2 NSX Manager Deploy VA Select Source

Figura 3 NSX Manager Deploy VA Reviwe Details

Figura 4 NSX Manager Deploy VA EULA

Figura 5 NSX Manager Deploy VA Select name and folder

Figura 6 NSX Manager Deploy VA Select Storage

Figura 7 NSX Manager Deploy VA Setup Networks

Figura 8 NSX Manager Deploy VA Customize template CLI password

Especificar la contrasea para el modo privilegiado.

Figura 9 NSX Manager Deploy VA Customize template Privilege mode password

Figura 10 NSX Manager Deploy VA Customize template Network Properties

Figura 11 NSX Manager Deploy VA Customize template DNS

Configuracin de servicios tales como NTP y SSH. Se recomienda sincronizar el NSX

Figura 12 NSX Manager Deploy VA Customize template Services Configuration

Figura 13 NSX Manager Virtual Machine

El usuario es admin. La contrasea es la que fue definida en el paso 8.

Figura 14 NSX Manager Login UI

Figura 15 NSX Manager User Interface Home Page

Figura 16 NSX Manager User Interface General Settings

Figura 17 NSX Manager User Interface Network

Figura 18 NSX Manager User Interface NSX Managment Service

fIGURA 19 NSX Manager Network and Security

Figura 20 NSX Manager Network and Security NSX Home

VMware NSX Controller

Tambin es el encargado de:

Figura 1 NSX Controller Roles

Nota: NSX Controller en realidad dispone de 5 roles.

Figure 2 NSX Controller Master Failure

Figura 4 NSX Controller Objects

Figura 5 NSX Controller Objects assigned to slices

Figura 6- NSX Controller Slicing

Distribuir los slices entre los nodos del clster.

Monitorear el estado de los nodos

NSX Manager previamnete instalado y lincado con vCenter Server.

Paso 1. Ir a Network and Security y despes clic en Installation.

Figura 7 NSX Controller Deployment Installation

Figura 8 NSX Controller Deployment Add NSX Controller Node

Coonected to: Especificar el grupo de puertos de mquina virtual a dnde se conectar

Figura 9 NSX Controller Deployment Add Controller