Proxy ARP en VMware NSX: funcionamiento y consideraciones (2/2)

Continuando el tema que inicié hace un par de semanas, en éste post exploraremos un poco otro aspecto de la implementación de proxy ARP en la arquitectura de NSX, particularmente en la interacción entre redes VXLAN y redes “físicas” tradicionales (VLANs).

Hablaremos del DLR (Distributed Logical Router) que ejecuta, precisamente, funciones de enrutamiento desde el kernel space de los ESXi participantes del entorno NSX. Efectivamente y, como su nombre lo indica, es un router que está distribuido a lo largo de todos los hosts, todos ellos tienen el mismo router y tanto el plano de control como el de datos están distribuidos para no generar puntos únicos de falla. Como todo router lógico, sus interfaces también son lógicas, y son conocidas como LIFs (Logical Interfaces, –¿qué mas podrían ser? Winking smile ). Si requiero interconectar dos segmentos VXLAN, eso consume dos (2) LIFs y el enrutamiento se hace posible inmediatamente a lo largo de todos los hosts.

NSX 6.2 habilita, en éste sentido, un nuevo caso de uso: enrutamiento entre una red VXLAN y una red física (si, de las de VLAN). Como sabrán, la primera vez que se establezca dicha sesión, indefectiblemente tendrá que ocurrir una consulta ARP (“Tengo una IP, ¿donde está su MAC?) pero, ¿ésto significa que todos los hosts potencialmente estarán ejecutando ARP broadcast? Si la respuesta fuese si, no habría razón para éste post sino para hacer un Feature Request. Pero afortunadamente la respuesta es no, y es aquí donde el DRL hace uso de la Designated Instance.

Veamos de qué se trata.

He tomado prestado éste diagrama del buen Brad Hedlund y su post original al respecto del DLR con redes físicas. No teman, que ésto no es sólo una traducción, aportaré un enfoque diferente.

Figura 1. Entorno NSX con DLR conectado a red física. Tomado de bradhedlund.com

¿Se fijan cómo no hay hosts ESXi en éste diagrama? Bueno, para propósitos de claridad resulta útil que así sea, lo importante es que esa capa de NSX DLR está distribuida a lo largo de múltiples hosts y las tres LIF que utiliza están presentes en todos y cada uno de los hosts, hasta ahora todos son iguales.

1. La VM1 (que se ejecuta, digamos, en el host ESX1) requiere comunicarse con el equipo PH1 (quizá el proverbial ejemplo del servidor físico de base de datos) por primera vez, de manera que lanza una consulta ARP. La IP de PH1 es 192.168.0.100, por citar un ejemplo.

2. ¿Qué hará el host ESX1?.

Aquí nos detenemos un momento. Hay varias cosas que han sucedido antes que entráramos a la escena, y éstas son:

  • a. El controller cluster ha elegido a uno de los hosts ESXi para asignarle el rol de Designated Instance. El receptor de semejante honor tiene la responsabilidad de ejecutar todas las consultas ARP que vayan hacia/desde la red física y responderlas con su propia MAC (pMAC para ser preciso, que es una suerte de MAC address por LIF única por host). Ajá! allí estás proxy ARP. Curiosamente sólamente la documentación oficial se refiere al DI como un proxy ARP, y efectivamente lo es. En éste caso, vamos  a imaginar que el controller cluster eligió al host ESX3 para ser el DI de ésta red física específica.

b. El dispositivo físico (ya sea el servidor o router) cuenta con una ruta hacia la red de VXLAN cuyo next hop ó siguiente salto es la IP de la LIF del host ESX3 (la Designated Instance). Dicho en otras palabras, todo ésto es muy interesante pero no va a funcionar si hacemos tanto esfuerzo en enviar un paquete que luego no sabe cómo regresar.

— Dadas éstas consideraciones, podemos continuar:

El host ESX3 va a capturar la legítima consulta ARP que hace el ESX1 y, una vez tenga la respuesta va a actualizar su tabla ARP con una entrada que se vé así

IP Address MAC Address
192.168.0.100 (IP PH1) pMAC ESX3

3. Inmediatamente, el controller cluster publica la nueva entrada a todos los hosts en el clúster

4. Contrario a lo que podría pensarse, una vez que el paquete alcanza su destino, no retorna necesariamente por el ESX3 (Designated Instance). Si la VM1 está en el ESX1, entonces el paquete retornará directamente por el LIF3 del ESX1. SI la VM1 se mueve al host ESX3, entonces el paquete retornará por allí, pero sólo se debe a que la VM está presente allí. En otras palabras, el Designated Instance no hace parte de la ruta de regreso lo cual optimiza el enrutamiento de manera efectiva.

Como discutimos en la parte 1 de éste post, uno de los mayores argumentos contra proxy ARP es que crea una vulnerabilidad para ataques de tipo Man in the middle: si capturas al proxy ARP, entonces podrás falsificar toda comunicación de capa 2 y hacia arriba. Sin embargo NSX 6.2 incorpora un control para éste riesgo con el establecimiento de comunicación cifrada por SSL entre el controller cluster y los hosts ESXi; éste es el canal donde se transmite información sensible, como por ejemplo el host que ha sido elegido como Designated Instance.

Conclusiones

Utilizando funciones de proxy ARP, NSX puede entregar routing optimizado entre entornos virtuales y físicos así como una importante reducción en el tráfico broadcast debido a consultas ARP, lo cual agrega a los ya numerosos beneficios de la virtualización de redes.

Los comentarios son bienvenidos, saludos!

Proxy ARP en VMware NSX: funcionamiento y consideraciones (Parte 1/2)

Proxy ARP es un mecanismo utilizado en redes y seguridad desde hace décadas. Consiste en configurar un dispositivo de capa 3 (típicamente un router) para que responda a las solicitudes de ARP (traducción de IP a MAC address) con su propia MAC Address, evitando que el dispositivo que hizo la solicitud tenga que salir de la red para hacer la consulta y convirtiéndose, a su vez, en el punto designado por el cual se redirijan (forwarding) las subsiguientes sesiones de comunicación hacia la recién aprendida IP/MAC.

Dicho de otro modo, si dispositivos conectados en subredes diferentes requieren conectarse entre sí van a necesitar un router que actúe ademas como el default gateway para cada subred, esto es Networking 101 o menos para muchos. Pero ¿que pasa si no hay tal dispositivo? ¿Podría insertar un dispositivo que facilite esa comunicación incluso SIN configurar un gateway  para ninguna de las sub-redes? Esto es precisamente para lo que hace casi 30 años se concibió ProxyARP documentado inicialmente en el RFC 1027 (lectura interesante)

Utilidad

  • Introducir ProxyARP en la red no implica cambios en las tablas de enrutamiento de otros dispositivos en la red. Realmente, éste puede ser un beneficio que se pase por alto pero si hablamos de un entorno virtualizado donde es tán fácil crear VMs con múltiples vNICs, y si dicho entorno aun cuenta con un esquema tradicional de VLANs, entonces esas tablas pueden estar llegando a su límite operacional; que es más cercano de lo que pensamos como lo confirma el RFC 5556 (TRILL).
  • Por otro lado, habilita la creación de un modelo de red plana (flat-network) sin intervenir los dispositivos finales que, gracias a ProxyARP, piensan estar directamente conectados con dispositivos en las demás sub-redes. Esto puede habilitar el diseño de una DMZ en la cual los equipos no cuenten con un gateway configurado.

Dificultades

ProxyARP no es nada popular en muchos círculos, algunas de las razones que se esgrimen para ello son:

  • Afecta la confidencialidad de la red más de lo que la beneficia: si un atacante logra hacerse pasar como la MAC address del ARP Proxy (MAC-spoofing) entonces tendrá visibilidad de todo el tráfico de sesiones establecidas así como de consultas ARP.
  • Debido a que los dispositivos (por ejemplo máquinas virtuales) no pueden pasar a otra sub-red sus solicitudes ARP, la presencia del proxy a largo plazo eleva el volúmen de tráfico ARP que tiene que ir y regresar a la subred.
  • Como si no fuese suficiente, debido a que siempre habría una respuesta a una solicitud ARP, el dispositivo que originó la consulta confía en que efectivamente encontró el destino y continuará el envío de paquetes hacia allí. Sin embargo, en ningún punto el proxy verificó que efectivamente pudiese llegar al destino real. Esto crea el llamado efecto hoyo negro, pues se establecerá una “comunicación” que realmente no está llegando a ningún destino y los dispositivos no lo notan.

De aquí en adelante, ¿para qué hablar más de Proxy ARP? ¿Es completamente fallido? ¿Alguien lo sigue utilizando?

Veamos.

Proxy ARP en VMware NSX

Si eres nuevo en NSX, recomiendo ampliamente el webinar de arquitectura desarrollado por ipSpace (el hombre, la leyenda Ivan Pepelnjak)

En NSX, el plano de control es distribuido y el rol le pertenece a un cluster de Controllers (virtual appliances) que aprenden y distribuyen la información de forwarding a todos los VTEPs participando en la red para VXLAN.

Una de las funciones que provee el controller cluster se conoce como “ARP Supression” en la que habilita a los VTEPs instalados en los hosts ESXi para actuar como ARP Proxy cuando una VM hace una solicitud de ARP broadcast para resolver la MAC address de otra VM. Quizá sea más claro con una imagen (tomada de la guía de diseño de NSX-v):

image

Trataré de ampliar lo descrito por la guía de diseño (de otro modo, Google Translator habría sido en vano):

1. La VM1 pregunta “¿Dónde esta la dirección física de ésta dirección IP?”. Eso, en suma, es una solicitud ARP (“dónde ubico la MAC address corrrespondiente con ésta IP address). Normalmente esa amplia pregunta (broadcast) se hace en todo el dominio L2 de la VM, es decir, en su red VXLAN 5001 y, debido a que ésa red atravies múltiples hosts, la consulta se haría sobre múltiples puertos físicos. Esto es lo que tratará de evitar el “ARP supression”.

2. Antes de obedecer ciegamente la solicitud de la VM1 y pasarla a hacer broadcast a lo largo de todos los hosts en el Transport Zone, ESXi-1 le pasa la solicitud al Controller Cluster: “¿Dónde esta la dirección física de ésta dirección IP?”

3. El controller cluster recibe la solicitud. Nota para candidatos a VCIX-NV: el agente que lleva a cábo ésta comunicación se llama netcpa y se comunica con el Controller Cluster a través de un canal SSL establecido en el momento en que se prepara el cluster para NSX.

4. El controller hace lo que cualquier dispositivo L2 haría: consultar su tabla ARP local a ver si tiene ese registro.

5. En caso de contar con la respuesta, se la envía de vuelta al host ESXi-1

6. El host ESXi-1 hace lo que todo dispositivo de L2 en ése caso: recibe el mensaje del plano de control y actualiza su tabla local pero fíjense: lo que guarda en su tabla es la IP y MAC address del VTEP del host ESXI-2 donde se encuentra la VM2, no la información sobre la VM2 específicamente.

7. Aquí viene el truco: ESXi-1 fabrica una respuesta ARP en la cual la MAC address origen no es realmente la MAC de la VM2, sino la del VTEP del ESXi-2 que, de aquí en adelante, actuará como el ARP proxy para ésta comunicación.

Claro está, si en el paso 4 el controller determinó que NO cuenta con ésa entrada, entonces ejecutará el L2 broadcast y cuando tenga una respuesta de la red, actualizará su tabla y le informará el cambio a los hosts ESXi.

¿Qué pasa si la VM es migrada a otro host? En condiciones normales, al ejecutar vMotion ESXi envía, como parte del proceso, un ARP reverso (RARP) para actualizar las entradas ARP, por lo que una nueva comunicación entre VM1 y VM2 (que ahora está en el host ESXi-3) no debe pasar por el proceso de ARP descrito. En todo caso, tener en cuenta lo descrito en este KB, pues podría evitar el funcionamiento del RARP.

En la siguiente entrada, hablaremos más de funcionalidades similares que NSX despliega para la comunicación optimizada entre VXLAN y redes tradicionales basadas en VLAN.

Bienvenidos los comentarios!

Configuración de Agents para Horizon View en Log Insight

Saludos

Hace ya un buen tiempo VMware lanzó el Content Pack de Horizon View para vRealize Log Insight. La necesidad de contar con recolecciòn centralizada y análisis de eventos para toda la infraestructura de EUC que entrega Horizon View es innegable y este complemento llegó en un momento muy necesario.

¿Cómo funciona? Cliente-servidor. El servidor (Log Insight) ofrece la descarga de agentes para Windows o Linux que llevan una configuración básica que le permite a cada máquina que ejecute el agente, redirigir sus eventos hacia la instancia de Log Insight desde la que se descargó el instalador del agente. Sin embargo para hacer una captura más precisa de eventos e incluso filtrarlos desde archivos planos de logs, es necesario crear una plantilla de configuración desde el server, quien se encarga de publicarle esa configuración a los agentes que así se definan.

Aunque la documentación oficial de vRealize Log Insight describe el procedimiento de configuración de dichos agentes, en el caso específico del CP para Horizon View, la información dista de ser completa y, más bien, evita el funcionamiento inicial del logging de todos los componentes, como puede verse en éste thread

En éste post se describe brevemente los pasos necesarios para lograr que los servidores “core” de Horizon View 6 (Connection Server, Composer y Security Server) envíen sus eventos a vRealize Log Insight 3.3

  1. 1. Primero es necesario haber instalado el Content Pack v3.0 para Horizon View desde la sección Content Packs > Marketplace en Log Insight:
  2. image
  3. 2. Adicionalmente, es necesario instalar el agente de Log Insight para Windows en los servidores de Horizon View en mención: Connection Servers, Composers y Security Servers. Este agente se descarga desde la sección Administration > Agents:
  4. image
  5. 3. Una vez instalado el agente en los servidores, regresar a la sección Administration > Agents de Log Insight
  6. 4. Verificar que en el listado de Agents figuran todos los servidores en los que ha instalado el agente. Es posible que todos ellos muestren en la columna Events sent el número 0, lo que muestra la necesidad de configurar los Agents para recibir datos correctamente
  7. 5. Del menú desplegable Agents selecciónar la opción New Group:

image

6. En esta sección, se sugiere crear un grupo para cada rol de servidores (Connection, Composer, Security):

image

7.  Una vez se cree el grupo es necesario configurar su membresía utilizando alguno de los criterios disponibles para ello. Esta regla debe poder incluír unicamente a los servidores correctos en cada grupo (típicamente especificados por IP y/o hostname:

image

8. Luego de verificar que los servidores que se visualizan en la sección Agents son los correctos para el grupo, es necesario dirigir la atención a la sección inferior Agent configuration. Por defecto la sección no tiene contenido, por lo que es necesario dar clic en Edit:

image

9. ATENCIÓN: es aquí donde el procedimiento debe tratarse diferente a cómo la documentación del Content Pack (ver pestaña Tech Specs) lo enuncia. Allí se indica que se debe crear una configuración genérica del agente y distribuirla a todos los servidores:

[filelog|ViewMain]
directory=C:\ProgramData\VMware\VDM\logs
include=log-*.txt;debug-*.txt;pcoip_agent*.txt;pcoip_server*.txt
exclude=pcoip_perf*.txt;v4v*.log;wsnm_starts.txt

Make sure that agent is installed on the base image so that it runs on each View desktop, plus it should be installed on all the other servers as well including: ALL connection, security, & composer servers.

Es decir, se trata de la misma manera a los desktops así como a los servidores de Horizon View, lo cual no es preciso principalmente porque la ruta de ubicación de los logs no es la misma en todos estos componentes.

Dicha configuración es apropiada para los Connection Server, Security Server y Transfer Server (ver KB 1027744) pero NO para el Composer Server.

10. Es por ello que verificando la configuración genérica y contrastando contra la ubicación real de los logs así como el contenido de esas ubicaciones, aquí propongo generar la siguiente configuración específicamente para los Composer Server:

[filelog|ViewComposer]
directory=C:\ProgramData\VMware\View Composer\Logs

*No se especifica ninguna exclusión pues todos los archivos contenidos en esa ubicación para el Composer Server todos los archivos corresponden al log actual y los logs que han rotado y se requieren para análisis.

11. Una vez guardada la configuración, máximo 5 minutos después se puede evidenciar que empiezan a recibirse eventos por parte de los Composer Server así como los demás servidores de Horizon View.image

La configuración del agente del Horizon Client así como el agente para los Desktops puede ser tomado de la plantilla precargada en la sección Agents por parte del Content Pack para Horizon View.

Espero haber aportado en algo a ésta labor tan importante.

Saludos!

Algunas consideraciones de diseño para Microsoft AD Certificate Services 2012

Recientemente he recopilado algo de experiencia en el despliegue del rol Active Directory Certificate Services sobre Windows Server 2012 y 2012 R2 y, sin ser para nada una guía exhaustiva ni ser escrita por un experto en infraestructura Windows Server; quisiera compartir algunas consideraciones a tener en cuenta, especialmente en un ambiente en el que los consumidores de los certificados serán servicios de VMware:

La arquitectura

Hay varias opciones para el despliegue para lo cual considero recomendable leer y revisar la documentación de Microsoft al respecto de éste tema. Sin embargo la versión corta e imprecisa es que hay que tomar varias decisiones:

¿Enterprise o Standalone CA?

Standalone CA quiere decir que no va a estar unida al dominio y, por lo tanto, va a carecer de funciones como autenticar solicitudes de certificados contra AD, entregar certificados automáticamente ó usar plantillas.

Las Enterprise CA de Microsoft están unidas al entorno de Active Directory y por lo tanto, complementan la autenticación de AD con la entrega automatizada de certificados a los miembros del dominio, el uso de plantillas y la autenticación de solicitudes de certificado. Para el uso de Microsoft CA en un entorno con VMware vSphere, es necesario hacer configurar Enterprise CAs pues, como tocaré más adelante, se requiere plantilla de certificado con algunas variables adicionales a partir de vSphere 5.1

Root y Subordinates

Microsoft AD Certificate Services contempla una jerarquía de niveles de confianza y de autoridad en la que el mayor nivel es la Root Certificate Authority (Root CA) que debe ser confiada por todos los miembros del dominio y tiene permisos para emitir así como para revocar certificados, y también tiene el rol de distribuir los Listados de Revocación (CRLs) actualizados a todos los miembros de la jerarquía.

Las entidades subordinadas son todas aquellas que están bajo la entidad Root, siendo la subordinada inmediatamente abajo la que se conoce como entidad “Intermedia” que obtiene los certificados de la Root CA y los puede usar para emitir a entidades más “abajo” en la jerarquía.

En resumen, la decisión de diseño aquí corresponde a si el entorno de despliegue requiere solamente una Root CA que es autosuficiente para emitir certificados o se requieren también subordinadas.  La mejor práctica de Microsoft se refiere a desplegar una Root CA que permanezca aislada (de hecho, apagada después de implementada) y que sea una o más entidades subordinadas las que sean visibles para los dispositivos finales y controlen la emisión y revocación de certificados digitales; con la firma original de la Root CA.

Algoritmo de hash

Al configurar el rol de AD Certificate Services (para ello se puede seguir la guía de Technet)  la opción de algoritmo de hashing predeterminado es SHA-2 cuyo equivalente más seguro y completamente soportado por las versiones recientes de vSphere (ver KB) es SHA-256 que es mucho más resistente a ataques de colisión y tiene el potencial de ser el estándar de uso en la implementación de Public Key Infrastructure (PKI) en un entorno VMware.

Conclusión

Espero hayan sido de utilidad algunos de éstos datos, en el futuro si el todopoderoso tiempo lo permite, estaré agregando diagramas para clarificar mejor los asuntos.

 

Saludos!

Libro: vRealize Operations Performance and Capacity Management

Por una gentil invitación de la editorial Packt Publishing, he tenido la oportunidad de dar mi opinión para el libro “vRealize Operations: Performance and Capacity Management” que como todo recurso en vROPs (antes vCOPs) es muy bien recibido porque la documentación no siempre es clara o incluso existente.

Se trata pues de la ópera prima de Iwan Rahabok que incluye varias novedades que trataré de manera breve a continuación:

Primera novedad: el autor

De acuerdo con la introducción del libro, el autor Iwan Rahabok ha desempeñado desde hace varios años un rol como Systems Engineer para cuentas estratégicas, lo que es un cargo con un marcado acento comercial pero que, de ser ejercido con suficiente profundidad técnica, puede ser muy relevante para entregar soluciones oportunas a los clientes de VMware, en este caso. No es común ver a un SE tan involucrado con los detalles de un producto, por lo que es un ejemplo digno de imitarse.

Segunda novedad: el enfoque

El libro logra dar temas de interés y elementos para profundizar a una audiencia diversa: desde las diferencias fundamentales entre el centro de datos físicos y el virtual (como un CxO lo entendería) hasta profundizar en un tema cuya documentación ha sido notablemente escasa en el pasado: la definición de métricas de vROPs y su relación con las de vCenter.  De manera que un enfoque amplio y que se enfoca en los asuntos importantes y frecuentemente no tratados, hace del libro un recurso muy valioso.

Una palabra final: aplicación práctica

Como si los aportes mencionados no bastasen, Iwan Rahabok agrega un capítulo dedicado a un tema que suele ser tratado de manera muy operativa pero que ha carecido del componente de planeación y diseño: la creación de custom dashboards de vROPs que aunque implica Licenciamiento Advanced o Enterprise, definitivamente explota mucho del potencial de la herramienta para el monitoreo preventivo y la visualización de indicadores clave del centro de datos virtual.

Conclusión

VMware planea ahora para la suite de management un enfoque mucho más abierto e híbrido, y el enfoque de éste libro precisamente va alineado con esa visión de dar apertura a vROPs 6 y su paradigma de Intelligent Operations a diferentes tipos de ambientes, que son consumidos por diversos tipos de usuarios. Es definitivamente un recursos muy necesario y que fué publicado en el mejor momento.

Tres niveles de (in) dependencia de Multicast en VXLAN

Continuando  con la temática del protocolo VXLAN, en ésta ocasión trataré lo que ha solido citarse como la principal barrera para su adopción: el requisito de Multicast y la carga operacional que implica su administración y la complejidad de la implementación.

Para VMware y Cisco, dos de los principales impulsores de VXLAN no ha sido desconocido éste tema y han hecho diferentes actualizaciones a la línea de productos para ofrecer tunelamiento VXLAN en diferentes sabores con respecto al requisito de multicast. He identificado tres variantes hasta ahora, que pasaré a describir:

1. vCloud Networking & Security: barato como un cachorrito

Si una organización tiene acceso a vCloud Suite en edición Standard, ya tiene en su bolsillo el licenciamiento para vCNS. Con éste producto es posible crear una completa implementación de VXLAN que incluso pueda ser consumida como redes organizacionales por tenants de vCloud Director. Sin embargo aquí es completamente necesaria la presencia de Multicast en la red física, aspecto que se debe tener en cuenta a la hora de evaluar la solución y su costo operacional.

2. Cisco Nexus 1000V: viviendo al filo del RFC

A comienzos de 2013, Cisco anunció la implementación de al menos dos nuevos mecanismos en el switch Cisco Nexus 1000V que harían posible implementar VXLAN sin el requisitio de Multicast:

a. Nexus 1000V puede crear múltiples réplicas de cada paquete y enviar cada réplica a un VTEP en la red usando sólamente Unicast. Esta opción claramente dista de ser escalable pues en un entorno masivo se producirá algo similar a una “tormenta” Unicast.

b. Hacer uso del VSM (Virtual Supervisor Module) que hace parte de la implementación de Nexus 1000V para que actúe efectivamente como un plano de control distribuyendo la información de direcciones MAC de máquinas virtuales a los VEM (Virtual Ethernet Module) presentes en la red. Esto, aunque efectivo, contradice lo que establece el RFC de VXLAN con respecto a que el protocolo no debe depender de un plano de control ni entidad alguna de administración centralizada. Cisco lo sabe pero, el cliente siempre tiene la razón 😉

VMware NSX: el auge del plano de control distribuido

Durante el VMworld US 2014, el Dr. Bruce Davie compartió conceptos avanzados y el futuro de NSX en la sesión NET1674.

Allí detalló el uso de VXLAN como protocolo de tunelamiento para NSX y, con respecto a lo que nos ocupa, la manera en que NSX habilta el uso de OVSDB (Open vSwitch Database) como el protocolo a través del cual distribuye la tabla de direcciones MAC de las Máquinas virtuales a lo largo de los switches físicos que soporten el protocolo y que hagan parte de la infraestructura sobre la cual tiene alcance el NSX Controller.

OVSDB es un protocolo de administración cliente-servidor que busca dar acceso programático a la base de datos OVSDB que contiene la información de cómo opera la conmutación del Open vSwitch con datos como, por ejemplo, la tabla de direcciones MAC de las MVs del entorno.

El mecanismo principal con el cual NSX crea redes virtuales (llámense segmentos, virtual wires, túneles,etc) es VXLAN que en este caso, y dado que la tarea de distribución y actualización de direcciones MAC la asume el protocolo OVSDB, solo requiere la presencia del protocolo IP como transporte o underlay eliminando así el requerimiento de multicast en la red física.

Sin embargo, no todas las organizaciones van a poder abrazar éste enfoque pues surge un nuevo requerimiento quizá más etéreo que el de multicast: switches físicos que soporten OVSDB. Actualmente existe oferta al respecto por parte de fabricantes como Juniper o Arista y aparentemente Open vSwitch ha llegado para quedarse, que es lo que se desprende de su adopción no solo por parte de los grandes fabricantes sino de la iniciativa OpenDayLight de Linux Foundation, que busca establecer un marco de referencia para el avance de SDN como un programa abierto e interoperable (el mundo empieza a reaccionar contra la proliferación del vendor lock-in, o eso esperaría).

Saludos!

VXLAN: conceptos, funcionamiento e implementación (2/2)

Ha pasado un buen tiempo desde que publiqué la primera parte de esta entrada y bueno, ya es hora de continuar.

Entre más aprendo sobre el tema, más difícil se hace comprimir todo en un post. En ésta ocasión cubriré la implementación de VXLAN en un entorno VMware vSphere y algunos de los siguientes temas serán tratados en entradas posteriores:

A. VXLAN y el requisito de multicast: tres niveles diferentes de (in)dependencia de Multicast

B. vCNS Edge como un eficiente y costo-efectivo gateway VXLAN

C. Un día en la vida de una trama VXLAN

Sin más, entremos en materia.

Configuración de VXLAN en un entorno vSphere

Para preparar un clúster para VXLAN se deben cumplir los siguientes prerrequisitos:

A. Una VLAN aprovisionada en la red física. Esta se usará para la comunicación entre VTEPs

B.Todos los host del clúster deben estar unidos a un distributed Virtual Switch

C. La red física debe soportar el paso de paquetes con tamaño mínimo de 1600 bytes sin requerir fragmentación

El procedimiento se lleva a cabo desde la interfaz de vCNS Manager con los siguientes pasos:

1. Dirigirse a Datacenters > Network Virtualization > Preparation

2. Dar clic en Edit…

vxlan21

3. Seleccionar un cluster y asociarlo con el respective dVS y VLAN ID que se haya obtenido previamente:

vxlan22

4. En la siguiente pantalla, seleccionar la política de Teaming de los uplinks o interfaces de red en el dVS. Está soportado Etherchannel, Link Aggregation Group o Static Failover, éste último es el que selecciono en el laboratorio pues no cuento con una implementación que soporte los demás métodos en la red física.

vxlan23

El resultado de los procesos anteriores luciría algo mejor que lo siguiente:

vxlan24

La solución al inconveniente anterior en gran parte, consiste en asignar las IPs a las vmknic creadas por VXLAN en cada host ó configurar un DHCP server en la VLAN que usuarán los VTEP.

Ahora se configurarán los rangos del grupo Multicas tasi como de los VNI que se usarán en la implementación. Para ello los pasos continúan de ésta manera:

5. Dar clic en “Segment ID” > “Edit…”

vxlan25

Es necesario que se configure la misma cantidad de VNI o “Segment IDs” que de IPs multicast en el grupo, cada segmento VXLAN llevará asociada una IP del grupo Multicast.

Los pasos siguientes aplican si el entorno de implementación no es administrador por vCloud Director (en caso que lo fuere, en éste punto el Provider vDC ya estaría listo para hacer uso de redes VXLAN). El post de @punchingclouds brinda mayores luces al respecto.

6. Dirigirse al link de “Network scopes” y crear un scope con el clúster previamente preparado:

vxlan267. En este punto se puede iniciar con la creación de redes, segmentos o VXLAN virtual wires (los nombres son equivalentes) que en vCenter se verán como portgroups del dVS a los cuales se pueden conectar máquinas virtuales de la manera tradicional. La creación de redes se lleva a cabo en el link “Networks”:

vxlan27

8. Finalmente en la pestaña “Edges” se puede aprovisionar una instancia de vCNS Edge que sirva como Gateway para las MVs conectadas a un VXLAN virtual wire y que puedan salir al “mundo exterior” para comunicarse con servicios en Internet o con equipos físicos en VLANs tradicionales.

Profundizaré en ello en un post posterior.

Gracias!

VXLAN: conceptos, funcionamiento e implementación (1/2)

Por estos días VXLAN parece cada vez más estar en boca de todos los que siguen el mercado de la virtualización de redes. Por un lado el Internet Engineering Task Force  (IETF) aprobó hace cerca de tres semanas pasar la tecnología VXLAN del estado borrador o draft a ser un protocolo reconocido por un RFC, lo que provee una base más sólida para su consolidación.

Por otra parte, el creciente auge de la suite de SDN de VMware: NSX ha llevado a partners como Juniper Networks, Arista Networks, entre otros; a ofrecer dispositivos capaces de integrarse con NSX usando como protocolo overlay a VXLAN, por sus capacidades y su flexibilidad en cuanto a requerimientos de infraestructura.

Esta es la motivación para ésta serie de 2 entradas que, dedos cruzados, se convertirán en más publicaciones sobre el avance de NSX como plataforma para SDN.

Entremos en materia.

VXLAN: ¿qué es?

Es un protocolo de superposición de redes (overlay networks) definido por el RFC 7348 que el IETF aprobó hace algunas semanas, y que hace uso del protocolo IP como la base sobre la cual implementa segmentos LAN similares a las VLAN, pero con un esquema diferente de encapsulación que eleva considerablemente el número de redes que es posible transportar, a la vez que aprovecha la ubicuidad y alcance geográfico de IP para agregar flexibilidad y extensibilidad a la implementación de redes L2.

¿Por qué VXLAN?

Uno de los desafíos a los que se enfrentan actualmente los arquitectos de red en el centro de datos moderno, consiste en las limitaciones del omnipresente Spanning Tree Protocol que es casi el mecanismo de-facto que las organizaciones implementan para evitar los loops en capa 2, sin embargo STP inevitablemente deja múltiples links sin uso por lo que en la escala masiva de los datacenter para la nube, esto significa un enorme costo de inversión en puertos que finalmente no se pueden usar.

Por otro lado y a diferencia de protocolos de capa 3 como IP, las redes de capa 2 tienen poca movilidad fuera del datacenter y ciertamente la carga operacional para extenderlos o activar dominios capa 2 en un sitio alterno reduce las opciones para la implementación efectiva de requerimientos como Disaster Recovery de cargas de trabajo virtualizadas hacia un datacenter alterno, manteniendo todas las propiedades de conectividad del sitio principal de forma automatizada.

Por si fuera poco, el mecanismo tradicional de aislamiento de red en capa 2 que son las VLANs, definen el VLAN ID como un atributo numérico de 12 bits, limitando el número de redes posibles a 4094. Por muchos años pareció lejana la posibilidad de alcanzar este límite, pero en el datacenter actual con múltiples tenants consumiendo servicios de conectividad y a la vez creando sus propias redes y servicios, éste límite rápidamente se ha convertido en un obstáculo a la vista para la escalabilidad del centro de datos.

Figura 1. VXLAN agrega un ID de 24 bits antes de transportar el paquete por la red IP. En el destino se lleva a cabo la desencapsulación.

VXLAN surge, pues, como una propuesta conjunta de fabricantes como VMware, Cisco, RedHat, Arista, entre otros; para convertirse en el mecanismo que efectivamente extienda la funcionalidad de las VLAN tanto en escala como en alcance. En escala pues su identificador de red, definido como VNI (VXLAN Network Identifier o Segment ID) es de 24 bits de longitud con lo que se alcanza un máximo de 16 millones de redes que pueden converger en una misma implementación VXLAN.

La extensión del alcance de las VLAN la logra VXLAN al valerse del protocolo IP, tan ampliamente implementado y con diversos mecanismos de movilidad, como medio de transporte para las redes L2 que viajan encapsuladas. Es por esto que a VXLAN también se le incluye en la categoría de tecnologías o protocolos de tunelamiento.

Componentes

La siguiente es una lista de componentes necesarios para una implementación de VLXAN en un entorno VMware:

A. VTEP (VXLAN Tunnel Endpoint): es la entidad que origina y/o termina túneles VXLAN. Se implementa en cada host ESXi y se compone a su vez de los siguientes módulos:

  1. Módulo vmkernel: hace parte del distributed Virtual Switch (dVS) y se instala como un vib en el hipervisor. Actúa como plano de datos al mantener las tablas de enrutamiento así como se encarga de la encapsulación y desencapsulación de paquetes
  2. Adaptador vmknic: se instala uno en cada host cuando el clúster se prepara para VXLAN. Se encarga de transportar el tráfico de control de VXLAN. Actúa en parte como control plane al alimentar la información de rutas visible en la red IP y alimentarla a la tabla mantenida por el plano de datos en el módulo vmkernel de VXLAN.
  3. Port group VXLAN: incluye la información tradicional de los portgroups dVS de vSphere, y se crea un portgroup automáticamente por cada red ó segmento VXLAN implementado.

B. vCNS Manager: este es el verdadero plano de administración o management plane, pues ofrece la gestión centralizada de los segmentos VXLAN así como de las interfaces vmknic y los clústers en cuyos hosts se ha instalado el VTEP. No administra el tráfico como tal, pero si mantiene el estado actual de la implementación VXLAN dentro de un vCenter.

C. vCNS Gateway: es un appliance que ofrece servicios de conectividad y seguridad avanzados y que es implementado y administrado por vCNS Manager. Se trata de un componente realmente especial dentro de la arquitectura de VMware VXLAN pues tiene la capacidad de dar salida a las MVs conectadas a los segmentos VXLAN hacia el “mundo exterior” con funcionalidades de NAT, Firewall perimetral, DHCP, DNS Relay, VPN, entre otras y es una alternativa para la eterna pregunta acerca de cómo terminar segmentos o túneles VXLAN en dispositivos físicos. Esto será materia de otra entrada, pero quedémonos con que el vCNS Gateway es efectivamente el puente entre redes VXLAN y servicios externos de conectividad.

vxlan_componentes
Figura 2. Arquitectura simplificada de implementación de VMware VXLAN

En la próxima entrada veremos los mecanismos bajo los cuales opera VXLAN así como los pasos prácticos para la implementación del protocolo en un entorno VMware.

Saludos!

Mi experiencia en el VCAP-CIA

El pasado lunes, Pat Gelsinger (VMware CEO) compartió una definición de valentía: ser decisivo en tiempos de incertidumbre. Bueno, debo decir que las circunstancias que en últimas me llevaron a tomar y aprobar el examen VCAP-CIA darían para pensar que algo de valentía hay en m, pues llegue el sábado pasado a San Francisco para VMworld y fue allí en la habitación del hotel donde decidí aprovechar el descuento, programar el examen para el día siguiente (!!) y terminar de estudiar en menos de 24 horas el 48% del blueprint, que era lo que me faltaba. Habiendo tardado alrededor de 3 meses estudiando el primer 52% (con toda la práctica necesaria) la tarea por momentos me pareció que había sido un gran error.

Finalmente presenté el examen y después de intensas 4 horas, esta es mi experiencia y mis recomendaciones:

1. Si ha leído previamente que uno de los factores más importantes para el éxito en un examen VCAP es la administración del tiempo, yo agregaría a ello la habilidad de desarrollar múltiples (entre 2 y 3) preguntas al mismo tiempo. Esto tiene que ver con que, al menos en mi experiencia, me había tomado 2 horas en resolver nada mas 8 preguntas, restaban 24 y la regla de tres simplemente daba para reprobar el examen por contestar solo la mitad. Fue allí que empecé a desarrollar tres preguntas a la vez anotando en la pizarra que Pearson suministra en el examen los números de esas preguntas para tener una rápida referencia visual y no olvidar responder ninguna a medida que avanzaba en las demás. Esta técnica salvó mi resultado en el examen.

2. Si ha leído previamente que el examen toca TODO el blueprint ha leído bien. No subestime ningún skill o habilidad que allí vea pues todas sin excepción serán evaluadas.

3. Recuerde que vCloud Director corre en un ambiente Linux por lo que debe sentirse a gusto con la linea de comandos y sin importar la tarea, siempre las man pages y la ayuda de los comandos evita que tenga que aprender de memoria comandos u opciones de los mismos.

4. El examen, como lo indica su versión de prueba o mock disponible en my.learn.vmware.com esta pensado para simular un ambiente de producción por lo que no debe temer considerarlo como tal y operarlo con el cuidado y proactividad necesarias.

Utilicé como principal recurso de estudio la guía de virtualizationexpress.com y el laboratorio que mi empleador me ha suministrado.

Sin mas, estoy feliz y sorprendido de haber aprobado. Se puede lograr mucho cuando estas bajo presión 😉

Saludos

¿Cómo configurar widgets en vCenter Operations Manager?

No se puede corregir aquello que no puedes medir. Es ésta una de las premisas que en mi opinión guía la planeación de TI en sus diferentes capas.

VMware vCenter Operations Manager ofrece una cantidad casi abrumadora de métricas para el Software-Defined Data Center y poder asignarle un contexto y una metodología clara de presentación y análisis es clave en el éxito de la introducción de vCOPS en la organización.

Para lograr ésta meta, la creación de dashboards personalizados para vCOPS Custom ha probado ser una estrategia eficaz,  incluyendo en ésos espacios los widgets apropiados.

En éste artículo se cubrirá la configuración del widget “Top-N Analysis” en el contexto de la creación de un nuevo dashboard. Para conocer los diferentes tipos de widget así como mayores generalidades sobre dashboards de vCOPS, recomiendo la lectura del manual de usuario.

Procedimiento

1. Inicie sesión en vCOPS custom (https://URL_vCOPS_UI/vcops-custom)

2.  Dirigirse a la parte superior y dar click en Dasboards > Add:

23. En la sección de la izquierda, seleccionar el widget que se va a agregar y arrastrarlo a la sección derecha:

54. Una vez haya terminado de editar las propiedades del dashboard, proceda a dar click en OK

5. Dirigirse al nuevo dashboard y editar el widget haciendo click en el ícono de engrane de la parte superior:

46.  Allí verá múltiples opciones. Mencionaremos algunas puntuales:

Self provider: se deshabilita ésta opción en caso que se desee colectar métricas desde otro widget para mostrarlas en el widget actual. En caso de habilitarlo, el widget actual será quien colecte y despliegue las métricas, siendo éste el caso más común.

Bars count: define el tipo de Top que se va a desplegar, por ejemplo un valor de 5 en éste campo, significa que se mostrará un Top 5 de la métrica que elija.

Widget mode: puede trabajar con etiquetas o métricas. En éste caso se fija la opción en “Metric”.

7. En la parte inferior podrá seleccionar el tipo de métrica a desplegar. En el ejemplo se desplegará un Top 10 con las más altas latencias de lectura en los datastore de los múltiples vCenter conectados a ésta instancia de vCOPS:

6

Y éste es el resultado final (se omiten nombres para proteger la identidad de los implicados 😉 ):7Esta fue una muy breve introducción a la configuración del widget TOP-N Analysis.

Recursos adicionales

Curso: vCOPS Analyze and Predict

Libro: vCOPS Essentials de Lauren Malhoit

Saludos!