Introducción a Open vSwitch

      1 Comment on Introducción a Open vSwitch

ovsbanner

Soy un ingeniero de redes acostumbrado a pelear contra ejércitos de cables y dispositivos malvados intentando hacerse su camino a través de un nuevo mundo hecho de lo que nosotros, quienes venimos desde el submundo y las cavernas más profundas del modelo OSI, solemos ser alérgicos: programación de software o cualquier cosa sobre la capa 4.  Este nuevo mundo llamado SDN o Redes Definidas por Software (Software Defined Networks) es sin duda el gran cambio que estábamos esperando en la industria de las redes desde hace muchos años. Todos los ingenieros en redes veíamos como nuestros colegas “de las capas superiores” año tras año han ido evolucionando en herramientas nuevas, modelos optimizados, procesos más flexibles y en general un cambio que ha sido congruente con el avance de las tecnologías. Todo esto, mientras nosotros nos quedábamos mirándolos y luchando aún contra equipos y tecnologías que no han cambiado mucho en los últimos 20 años. Las redes han sido siempre relegadas al último lugar de los cambios de la industria, pero eso ya es cosa del pasado. SDN es ese gran cambio que todos estábamos esperando desde hace mucho tiempo.

Los primeros pasos para ingresar al mundo de SDN es, primero, aceptar el cambio de paradigma de reemplazar cables por software y ,segundo, comprender algunas de las tecnologías más populares disponibles. Dentro de esas tecnologías tenemos conceptos como virtualización, NFV, switches virtuales, OpenFlow, entre otros.

Hoy cubriré los aspectos básicos de Open vSwitch, un switch virtual de tipo Open Source y completamente multicapa, utilizado ampliamente para entregar mayor flexibilidad a la infraestructura de Datacenters definidos por Software (SDD o Software Defined Datacenters). Open vSwitch extiende esas rudimentarias (y a veces primitivas) herramientas tradicionales de networking encontradas en Linux que han sido utilizadas por años para trabajar en entornos virtualizados (como por ejemplo el horroroso soporte para bridging del kernel de Linux) y ofrece un modelo centralizado mucho más simple de administrar y que permite fácilmente implementar VLANs, túneles GRE, VXLANs, políticas básicas de QoS, IPsec, LACP y muchas otras características (la lista completa la pueden encontrar aquí: http://openvswitch.org/features/). Pero antes de que sus corazones empiecen a latir más rápido tienen que tener en cuenta cuales son dos de las más grandes desventajas que he encontrado hasta ahora en OVS: la falta de una buena documentación y el mismo kernel de Linux.

Tristemente, Open vSwitch está muy pobremente documentado y puede llegar a ser una gran batalla implementarlo en escenarios complejos. Bueno, ese es el costo que las tecnologías “free” y “open source” siempre han tenido (¿ves? Nada es gratis en realidad). Sin embargo, el principal problema  de OVS yace directamente en su propio nacimiento: el obeso, lento e hinchado kernel de Linux (y aquí estoy citando al mismísimo Linus Torvalds). Verdad: Linux ofrece ventajas innegables por sobre otros sistemas, pero un switch virtual basado en Linux jamás va a tener mejor performance que un dispositivo de hardware dedicado y diseñado específicamente para las tareas de conmutación de paquetes, quizá con la única excepción de la comunicación “intra-hypervisor”.  Esto es algo de lo cual tenemos que ser conscientes para poder crear verdaderas redes resilientes, redundantes y bien diseñadas. Entonces ¿porqué utilizar Open vSwitch? Por que simplifica la vida del administrador de redes que trabaja con entornos virtualizados y si tú eres uno de ellos, al final lo amarás con todos sus defectos también.

Implementación
Menos blabla y más acción me decía un colega mío siempre. Para probar OVS he utilizado Virtualbox para crear 2 máquinas virtuales Linux (aunque pueden ser Windows también) dentro del host físico que corre Ubuntu.

ovs1

La figura superior muestra nuestro entorno inicial (click para agrandar). Nada nuevo acá sino solamente un par de VMs conectadas a la interfaz eth0 del host físico en modo puente (bridge) recibiendo su configuración vía DHCP desde Internet.

Primero instalaremos Open vSwitch como paquete. OVS tiene muchas opciones pero instalaremos solamente las herramientas básicas para comenzar. Todos los comandos de este artículo están ejecutados en la máquina física Ubuntu.

Una vez instalado, crearemos nuestro primer Bridge. Es importante tener en cuenta que la terminología en OVS es muy específica y puede ser confusa a veces, sobretodo para quienes venimos desde el mundo Cisco. Open vSwitch crea “bridges” en vez de switches. Podemos tener múltiples bridges dentro de un mismo host físico e incluso conectarlos unos con otros.

Crearemos el bridge0 y lo levantaremos. Bridge0 se mostrará como una interface Linux más.

 

ovs2

Ahora conectaremos la interfaz eth0 de Ubuntu al bridge0. Importante: al realizar este paso se perderá la conexión a Internet, por lo cual deberás asegurarte de tener un acceso alternativo a la consola Linux. La razón de esto es muy sencilla: bajo circunstancias normales, el stack IP del host físico está configurado para conectarse a Internet a través de eth0 (ejecutando route -n puedes ver la interfaz de salida de la ruta por defecto). Al conectar eth0 al bridge0, eth0 no estará disponible directamente, por lo que deberemos configurar bridge0 para recibir el direccionamiento IP de Internet.

Para recuperar Internet debemos eliminar la dirección IP existente en eth0:

Y ejecutar una nueva consulta DHCP, esta vez desde bridge0

Si todo salió bien, deberíamos ahora tener la dirección IP en la interfaz bridge0

ovs3

y nuestra topología ahora se ve así:

ovs4

No olviden que las dos máquinas virtuales conservarán sus direcciones IP asignadas previamente por DHCP ya que su tiempo de concesión (lease time) aún no ha expirado. Sin embargo, ninguna de ellas tendrá conexión con la otra hasta que las conectemos a nuestro bridge0. Para hacer esto utilizaremos dos interfaces TAP. Estas son interfaces virtuales que simulan un cable físico, lo cual las hace ideal para nuestro escenario. Si tuviésemos 50 máquinas virtuales necesitaríamos 50 interfaces TAP.

Para crear estas interfaces debemos invocar a los antiguos espíritus con los siguientes comandos y las llamaremos “vmport1” y “vmport2” (pueden escoger el nombre que quieran):

Al ejecutar ifconfig debiésemos ver ambas interfaces tap:

ovs5

Nota: Es posible que veas más interfaces dependiendo de tu entorno, pero ellas no están relacionadas con nuestra configuración.

Genial. Ahora tenemos nuestro bridge0 y dos interfaces tap llamadas vmport1vmport2 corriendo en nuestra máquina Linux. ¿Qué viene ahora? Ya que nuestras habilidades y conocimientos en redes no se han perdido solamente por haber pasado al mundo del software y no hemos olvidado esas decenas o cientos de horas que hemos pasado cableando racks en datacenters, nuestro instinto nos señala que sería lógico agregar esas interfaces tap a bridge0. Esto se hace de manera muy sencilla con el comando de control de OVS:

Veamos nuestro diagrama y demos un vistazo a lo que hemos hecho hasta ahora:

ovs6png

Ambas interfaces han sido conectadas a bridge0. Podemos revisar esto ejecutando el comando ovs-vsctl show

ovs7
Podríamos pensar en ovs-vsctl show como una analogía al comando show interfaces status en switches Cisco. Analicemos lo que muestra esta salida antes de avanzar en nuestra configuración. La primera línea es el UUID o Identificador Único Universal (Unique Universal ID) de nuestro entorno según el RFC 4122. Luego vemos nuestro bridge llamado “bridge0” que tiene cuatro puertos (eth0, bridge0, vmport1 y vmport2). Si se agregan más bridges (ejemplo: bridge1), también se mostrará acá. Cada uno de estos cuatro puertos tiene una interfaz con el mismo nombre. Entonces ¿cuál es la diferencia entre Puertos e Interfaces en Open vSwitch?. Si alguna vez has trabajado con Etherchannels (llamado también NIC bonding), podrás entender claramente la diferencia. Un puerto (port) es una entidad que puede contener múltiples interfaces físicas (las llamo físicas para diferenciarlas, aunque claramente acá son virtuales). En Etherchannel se puede crear un puerto 1 (Port1) que contenga las interfaces FastEthernet 0/1, FastEthernet 0/2 y FastEthernet 0/3. El mismo concepto aplica a OVS con LACP. No te preocupes, hoy no llegaremos tan profundo 😉

Otra cosa que confunde mucho a veces es que el bridge0 tiene un puerto que también se llama bridge0. Cuando creamos nuestro bridge y lo llamamos bridge0, automáticamente se creó un puerto con el mismo nombre, que contiene una interfaz que también se llama bridge0 de tipo “internal” (esto es lo que vez cuando ejecutas ifconfig). La idea de una interfaz internal es que si algún día quieres asignarle una dirección IP a tu bridge0, puedes hacerlo en este interfaz interna, del mismo modo que se le asigna una SVI en un switch Cisco. Que sea de tipo “internal” solamente guarda relación con aspectos de compatibilidad con las utilidades de bridging del kernel de Linux.

Volvamos a nuestra topología. Tenemos un bridge conectado a Internet y dos taps. Ahora nos falta conectar nuestra máquina virtual 1 (VM1) con la interfaz vmport1 y VM2 con vmport2. Para eso vamos a las configuraciones de red de cada máquina virtual, seleccionamos el adaptador 1 en modo Bridged Adapter (o adaptador puenteado) y lo conectamos a vmport1 y vmport2 respectivamente:

En VM1 (Debian1):

ovs8

En VM2 (Debian2):
ovs9

y ahora nuestro diagrama de red luce así:

ovs10

Al haber conectado las máquinas virtuales, ambas podrán conectarse a Internet y tendrán conectividad entre ellas:

ovs11

Ahora podemos seguir jugando con nuestro entorno para poder agregar VLANs, QoS y mucho más. Revisaremos esos conceptos en otro artículo.
Si surgen problemas pueden revisar los logs dentro de /var/log/openvswitch
Más información en http://www.openvswitch.org

  • wineloy garcia

    Excelente información! 🙂 no tenia idea de como funcionaba open vSwitch, ahora ya tengo una idea de su funcionamiento, le agradezco el tiempo !