NSX – L2 bridging

Que tal gente, el día de hoy voy a cubrir uno de los aspectos de integración de NSX con la infraestructura física adyacente y/o servicios externos. Recordemos que muchas de las grandes funcionalidades que NSX ofrece se logran a través de crear un “overlay” con VXLAN, permitiendo separar el espacio lógico de los componentes físicos, el problema surge cuando tenemos que seguir trabajando con servicios externos (ej. aplicaciones) que no forman parte de un switch lógico basado en VXLAN. Vamos a revisar este caso.

Casos de uso para extender el mundo de VXLAN a un mundo físico (VLAN)

Los casos de uso mas comunes que podemos encontrar para esto son los siguientes:

  • Migración – Este caso de uso será de importancia cuando se introduzca NSX a un ambiente existente donde la migración de servicios físicos y virtuales (VMs) se de en fases. Con esto podemos extender L2 entre los Switches lógicos de NSX y las VLANs en el ambiente.

Screen Shot 2016-07-07 at 5.37.14 PM

  • Integración de servicios o cargas físicas – Existirán ocaciones en las cuales no podremos virtualizar cargas existentes por multiples razones (políticas, rendimiento, etc) al igual que servicios (ej. firewall física) existentes en el ambiente que el cliente o el proyecto en si dicte que deberán continuar siendo físicos.

Screen Shot 2016-07-07 at 5.40.38 PM

¿Que opciones tenemos para extender L2?

NSX ofrece dos opciones para poder extender L2, una basada en SW que forma parte de NSX y otra basada en HW a través de partners (ej. Arista). Vamos a revisar que diferencias y ventajas tiene cada uno:

  • SW L2 Gateway – En este caso estamos hablando de una capacidad propia del hipervisor a través de la cual se realiza un “puente” entre un switch lógico de NSX con una VLAN (VNI-VLAN). Por lo que podemos conectar switches lógicos con portgroups existentes basados en VLAN, esto ayuda a extender la capa 2 entre VMs que ya están sobre un overlay de VXLAN hacia VMs sobre vSphere sin NSX o servidores físicos. En la siguiente imagen podemos ver lo sencillo que es configurar un “bridge” desde un Distributed Logical Router, simplemente hacemos el mapeo:Screen Shot 2016-07-07 at 8.20.35 PM
    Ahora la pregunta seguro será ¿Como sucede esto dentro del hipervisor?… bueno para esto se crea un puerto llamado “sink” port que permite redireccionar el trafico entre un switch de VXLAN a un portgroup:Screen Shot 2016-07-07 at 8.36.36 PM
    Es importante comprender que en el momento que creamos un puente de L2 solo existirá en un host que se le conoce como “Designated host”, por lo que el tráfico de este-oeste tendrá que llegar a dicho host para poder ser comunicado al exterior, el host designado será aquel donde la control vm del DLR resida y en caso de falla se designa nuevamente donde la control VM reinicie (a través de HA) o donde se encuentre el par en “stanby” (que tomará el rol activo). Esta instancia de bridge manda una copia de las MACs aprendidas al cluster de control para que se pueda saber como alcanzar aquellas VMs, servidores o servicios externos, en caso de falla de la instancia de L2bridging el cluster de control envia una copia de estas MACs anteriormente aprendidas.
  • HW VTEP – Otra opción que tenemos para poder extender L2 e interconectar VXLAN con VLANs es a través de appliances físicos. Existen múltiples partners hoy en día que ofrecen esta alternativa, que básicamente coloca un VTEP o “VXLAN Tunnel End Point” fuera de VMware e interconecta un VNI (VXLAN Network Identifier) con una VLAN. Existen HW VTEPs en forma de switches y gateways (L3) lo cual nos permite crear esquemas interesantes de interconexión de VNIs y VLANs. En la siguiente imagen podemos entender mejor como funciona un HW VTEP:Screen Shot 2016-07-09 at 10.28.53 PMEn la imagen podemos notar que básicamente el appliance se comporta como otro host ESXi presentando un VTEP en el mismo segmento o en otro segmento (a través de L3) permitiendo extender VXLAN, después este HW VTEP ofrece puertos donde podremos estar realizando trunking de VLANs para así dentro de el appliance hacer el mapeo entre VNIs y VLANs. Claramente para que esto pueda suceder debemos de registrar el HW VTEP desde NSX, es importante considerar que desde el appliance también tendremos que contactar a NSX (especificamente el cluster de controladores) ya que se estará realizando una comunicación utilizando el protocolo OVSDB (disponible desde NSX 6.2) para poder orquestrar y publicar las distintas redes de VXLAN que estamos creando desde NSX. En la siguiente imagen podemos ver como se agrega el HW VTEP desde NSX, yendo a la sección de “Service Definitions” y la pestaña de “Hardware Devices” donde basicamente tendremos que copiar y pegar el certificado SSL de dicho HW VTEP para poder entablar comunicación bidireccional.El primer paso será crear el cluster de replicación para el tráfico BUM (Broadcast, unknown unicast, multicast) ya que el HW VTEP no estará replicando todo este tipo de tráfico, para ello se apoya de hosts ESXi que fungen como el rol de Replication Service Nodes (RSN), por lo que cuando se requiera replicar trafico BUM desde el HW VTEP a hosts ESXi (ej. ARP) los nodos seleccionados como RSN tendrán que apoyar con esta tarea, cualquier comunicación entre hosts ESXi seguirá siendo dictada en base al modo de replicación seleccionado para el switch logico (o el Transport Zone) la siguiente imagen nos puede apoyar a entender el rol de los RSNs
    Screen Shot 2016-07-09 at 11.20.41 PM
    Podemos notar que la comunicación entre los hipervisores y el HW VTEP se realizará a través de BFD para poder determinar fallas. La configuración del cluster de replicación es muy sencillo:Screen Shot 2016-07-09 at 11.25.34 PMDespués tenemos que agregar un nuevo dispositivo y pegar el certificado SSL:
    Screen Shot 2016-07-09 at 10.55.34 PM
    Una vez listo podemos notar que se marca como conectado:Screen Shot 2016-07-09 at 10.58.18 PMEl último paso sería mapear los switches lógicos de NSX con puertos del appliance:
    Screen Shot 2016-07-09 at 11.00.45 PM

Ventajas y desventajas de ambas opciones

Ahora se podrán preguntar cuales son los pros y contras de cada una de estas opciones, de entrada debemos tener en mente que para la mayoría de las cargas y casos de uso el bridge de L2 desde software es mas que suficiente ya que puede entregar de manera sencilla y con un throughput de casi 10Gbps. Pero claramente las opciones por HW tienen sus ventajas:

  • HW VTEP

Screen Shot 2016-07-09 at 11.47.03 PM

  • SW VTEP

Screen Shot 2016-07-09 at 11.54.52 PM

Consideraciones de diseño

Existen ciertos puntos que debemos tener en mente cuando estemos trabajando con ambas opciones:

  • Software bridge
    • solo podemos tener una instancia por switch lógico, por lo cual solo podremos mapear dicho switch lógico con una VLAN.
    • El ancho de banda esta limitado a la instancia de bridge.
    • Se podría necesitar extender las VLANs para tener acceso a los servidores o servicios físicos:Screen Shot 2016-07-10 at 12.07.38 AM
  • HW VTEP 
    • No se requiere presentar las VLANs en todos los racks, se pueden mantener locales
    • Se pueden contar con multiples HW VTEPs simultáneamente, solo considerando que debemos conectar hosts ESXi exclusivamente y no componentes que puedan crear loops (ej. switch).
    • Debemos de considerar los mecanismos de alta disponibilidad ofrecidos por el fabricante del HW VTEP a diferentes niveles, primero protección para el HSC (Hardware Switch Controller, que es el servidor de OVSDB con el cual habla NSX) y después mecanismos como MLAG para ofrecer acceso a multiples switches desde los hosts ESXi (aunque esto puede ser logrado desde el host ESXi mismo con vmnics activas/pasivas).

      Screen Shot 2016-07-10 at 12.22.09 AM

Leave a Reply