en Blog profesional

El modelo de 3 capas de Cisco (Acceso, Distribución y Core) es un buen modelo, pero a veces podemos optar en determinadas situaciones por modelos muy diferentes.

En entornos empresariales el modelo de una red de nivel 2 es fantástico pues permite tener los dispositivos en la misma red y que todos se vean entre si, además hablamos de dispositivos físicos como impresoras o PCs que rara vez van a moverse de sitio.

Ahora imaginemos un entorno de máquinas virtuales donde cada máquina es de un cliente y que no quiere que otros clientes vean su máquina por nivel 2, además, queremos poder mover la máquina de hipervisor, e incluso de rack o CPD. Imaginemos un entorno en el que lo queremos limpio sin multitud de vlans ni problemas de spanning tree.

Existen soluciones parciales, como trill u otras cerradas similares. Luego tenemos soluciones que nos permiten mover máquinas virtuales entre hipervisores, pero todas tienen una cosa en común, hay que “casarse con el proveedor de red y/o virtualización” y eso es algo que va en contra de la forma de trabajar que tenemos en Tecnocrática o en Neodigit.

Nosotros nos encontramos con ese problema en el momento de definir la plataforma de virtualización ya que queríamos ofrecer una serie de servicios que o no podíamos ofrecer con plataformas como VMWare o simplemente no eran soluciones competitivas ni en tiempo ni en dinero.

Ante esa situación lo que hicimos fue encerrarnos durante unos meses para intentar encontrar una solución, y al final la solución salió, por una parte una solución propia para el tema de los hipervisores de la que no puedo ofrecer muchos detalles al no estar directamente en mi área, pero totalmente automatizada y la solución de red que voy a pasar a describir a continuación y que se basa en anunciar rutas /32 dentro de nuestra red, una para cada servidor.

Al anunciar /32 lo que conseguimos es una granularidad total de la red, el problema es que el modelo de 3 capas de Cisco, que hasta ese día para mi era algo sagrado dejó de servir.

La forma de hacerlo consiste en ejecutrar uno o varios routers virtuales en cada hipervisor y hacer ahí los anuncios de routing, es decir, la solución fue llevar el nivel 3 directamente al hipervisor, sin vlans, sin nivel 2. Sin querer nos encontramos con un servicio nivel 3 puro desde el punto de tránsito hasta la propia máquina virtual, pero extremadamente flexible.

Una vez teníamos la teoría y alguna maqueta rudimentaria el siguiente paso era la automatización desde el panel de control que desarrollamos para nuestros servicios y que fuera el panel de control el que configurara los servidores virtuales y los routers.

Por supuesto no valía eso de crear plantillas y clonar pues eso requería de un trabajo de mantenimiento de plantillas totalmente absurdo pudiendo tener otras soluciones como PXE que sirve para configurar servidores, y ojo, fijaros que cosa tan curiosa, pero con PXE también podíamos levantar máquinas Debian con Quagga, es decir, routers de forma automática.

Mapa general de red

Red pura de nivel 3

En nuestra solución el servidor que se aprovisionaba tenía que pasar por varios estados, el primero era autoconfigurarse por PXE y una vez configurado tenía que levantar con el direccionamiento público.

Una vez configurado el servidor éste arrancaba con la siguiente configuración de red.

# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 31.47.76.xxx
netmask 255.255.255.255
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx
dns-search neodigit.net

post-up route add 10.10.10.10 dev eth0
post-up route add default gw 10.10.10.10

Como podéis ver la máquina tiene una IP y una máscara /32 y un gateway 10.10.10.10.

Para hacer esto todos los routers son iguales y tienen una pata, donde se conectan las máquinas virtuales que tienen la IP: 10.10.10.10/24 y la MAC: 00:80:10:10:10:10, todos iguales, por cierto, la mac es de un Commodore, por si alguien quiere ver qué router usamos la MAC le dirá que un Commodore, esta fue una licencia poética, pero nos permite que si movemos una máquina de hipervisor su gateway esté donde esté tendrá la misma IP y la misma MAC.

Ahora, el interfaz del router con al IP 10.10.10.10 correrá proxy arp. Antes de que nadie lo diga existe una opinión muy extendida que el rendimiento con proxy arp baja, pero claro, en este escenario podemos levantar tantos routers como queramos, así que el rendimiento nos da básicamente lo mismo porque nos cuesta lo mismo tener un router cada 200 máquinas que cada 10, así que en este escenario el rendimiento no es un problema, además es todo automático, nosotros no tocamos manualmente ningún equipo.

Para anunciar el servidor lo único que hacemos es inyectar una ruta /32 a la IP del servidor por el interfaz de proxy arp y esta se redistribuye automáticamente en el protocolo de routing, en nuestro caso y de momento OSPF, pero como es independiente a la plataforma es cambiable por otros.

Si queremos mover una máquina de hipervisor, o de país, lo único que hacemos es mover la máquina virtual borrar la ruta del router viejo y añadirla al nuevo, esta se redistribuirá automáticamente y a funcionar.

Además se pueden dar otro tipo de soluciones más imaginativas, por ejemplo un hipervisor en Madrid, otro en Miami, el de Miami, los dos con la misma IP y sincronizándose por otro interfaz, el de Madrid se anuncia con un coste y el Miami con un coste muy penalizado, si cae el de Madrid automáticamente la máquina de Miami cogería todo el tráfico y ya tendríamos un servicio de BRS.

Las posibilidades como podéis ver son enormes y nos abren un mundo de posibilidades casi infinito.

Este post es un resumen de una presentación hecha en el esNOG 17 en Barcelona el 12 de Mayo de 2016. La presentación la podéis descargar desde el siguiente enlace: Modelo de distribución sin VLANs para centros de datos virtualizados: El enfoque tecnócrata.

15 Mayo de 2016 – ACTUALIZACIÓN

Ya tengo el enlace al vídeo de la charla, así que aquí os la dejo.