En este nuevo post de NSX Blog LATAM, Gonzalo Atienza, especialista de VMware NSX va a explicar cuáles son las integraciones de Hardware VTEP que tenemos con VMware NSX y vamos a identificar algunos casos de uso principales en los cuales haría falta este tipo de integraciones.
Hardware VTEP con VMware NSX
En este post vamos a explicar cuáles son las integraciones de Hardware VTEP que tenemos con VMware NSX y vamos a identificar algunos casos de uso principales en los cuales haría falta este tipo de integraciones.
Antes de comenzar debemos repasar algunos conceptos. NSX-v utiliza un overlay para poder extender conectividad de capa 2 sobre cualquier tipo de red de capa 3. De manera tal de que una VM o equipo físico puede comunicarse con otra VM o equipo físico en el mismo dominio de broadcast, por más que se encuentren detrás de redes físicas distintas. Este overlay es VXLAN.
Los endpoints que encapsulan VXLAN son denominados VTEPs (VXLAN Tunnel Endpoints). Con NSX-v, los VTEPs son interfaces vmk que residen en cada host ESXi. De esta manera, para poder contar con este overlay, NSX es agnóstico e independiente al equipamiento físico. Otras soluciones terceras utilizan múltiples switches específicos que requieren funcionalidades y licenciamiento de VXLAN para poder utilizar este overlay en la capa física, generando un costo superior.
Pueden ver este video de nuestro NSX Blog LATAM explicando switching lógico de NSX, incluyendo una rápida demo.
¿Como podemos intégranos con el mundo físico?
Existen varias formas en las que NSX se comunica con el mundo físico. En una primera instancia, vamos a separar dos tipos distintos de conectividad:
1. Equipo físico y VM en redes distintas:
En este caso el tráfico será considerado Norte-Sur hacia NSX. De la misma manera en la que lo hace el tráfico que ingresa al datacenter. Como, por ejemplo, una PC de escritorio comunicándose con una VM de manera tradicional. No se requiere ninguna funcionalidad avanzada, solamente ruteo lógico de NSX.
2. Equipo físico y VM en la misma red:
Si el equipo físico y la VM se encuentran ambos en la misma red, necesitamos extender una VXLAN al mundo físico. Para este caso hay dos alternativas:
2.1. NSX L2 Bridge
Nativamente, NSX cuenta con una funcionalidad para crear una instancia de bridge de capa 2, en donde un Host ESXi conecta un segmento VXLAN con una VLAN física. La configuración es muy simple y suele ser la más adoptada por clientes para extender este tipo de conectividad, sin requerir funcionalidades avanzadas en los switches físicos.
Si bien el NSX L2 Bridge es el método más adoptado por clientes, para casos avanzados de automatización del mundo físico y, en menor medida, por otros casos de requerimientos muy exigentes de escalabilidad y performance existe la segunda alternativa.
2.2. Hardware VTEP:
Finalmente hemos llegado al tópico principal de este blog. En lugar de utilizar nativamente la funcionalidad de bridge dentro de un Host ESXi, esta integración extiende la terminación del overlay de VXLAN a un switch ToR (Top-of-Rack). De esta manera el mismo ToR pasa a ser un VTEP adicional dentro del plano de control de NSX, en conjunto con los otros Hosts ESXi. Este switch ToR requiere de OVS-DB para integrarse con el clúster de controladores de NSX, que intercambian las tablas de ARP, MAC y VTEP.
Posterior a la configuración de esta integración, desde la misma interfaz gráfica o API de NSX se puede configurar el mapeo de un Logical Switch (segmento de VXLAN) hacia un puerto específico del switch ToR. Múltiples vendors de equipamiento de redes han homologado sus switches ToR y se integran con NSX por medio de esta funcionalidad. La lista de los mismos se puede encontrar en nuestra Guía de Compatibilidad de VMware.
Related Sites:
