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!

Advertisements
Posted in NSX

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s