¿Por qué nos gusta tanto Quagga?

Muy buenas,

Esta entrada intentará ser una mezcla entre alabanzas/howto técnico de Quagga y una descripción de lo interesante de aplicar enfoques de routing  dinámico, o simplemente, de dar un pequeño paso en el mundo del networking que no sea lo más básico de todo.

Antes de nada, un poco de literatura/breve definición de Quagga (fork del proyecto original Zebra, ambos GPL): Se trata de una suite completa de software routing, que implementa los conocidos protocolos de routing: OSPFv2, OSPFv3, RIPv1/v2, RIPng y BGP-4, pudiendo ser ejecutado sobre sistemas Unix Like (FreeBSD, Linux, Solaris y similares). Es decir, se trata de software que permite, entre otros, que nuestros fantásticos servidores ejecuten tb funciones de routing avanzado, tareas generalmente delegadas o controladas por la electrónica de red habitual (SW L3, Routers, Firewalls). De hecho, no nos referimos a que nos guste reemplazar o usar servidores «pesados» para funciones que pueden hacer «simples» 😉 routers, sino a que muchas veces, dejar de ser «agnósticos del path» nos puede interesar, o simplemente, queremos o debemos participar en la arquitectura de red porque nos estamos integrando de prestado en un entorno ajeno.

Se trata de un tema generalmente muy tratado con nuestros clientes, en proyectos generalmente de VoIP o sistemas, se acaba siempre hablando de las bondades de aplicar este tipo de enfoques y en muchos casos, el cliente acaba «importando» en sus infraestructuras nuestros planteamientos. De base nos marcamos dos objetivos:

• Route clean to everywhere from everywhere
• High Availability (Alta Disponibilidad)

Tanto si consideramos a otros departamentos de Irontec «clientes» del deparmento de Networking/Systems, como si analizamos únicamente los clientes externos, siempre hay una premisa: Se quiere llegar «YA MISMO» sin túneles ssh ni rebotes ni nada, y DESDE TODOS LOS SITIOS (Servidor de monitorización, VPN IronWorkers at Home, Sistemas de storages y backups), de ahí el concepto de «route clean».

Dicho esto, en una infraestructura de redes global mantenida como la nuestra, que no para de crecer, o que es mixta/mezclada con redes de clientes, mantener rutas estáticas no es algo sostenible en el tiempo, sobre todo si lo mezclamos con el siguiente punto: HA de comunicaciones. Generalmente, cuando en reuniones de ante-proyecto / análisis se toma el primer contacto, se estudia siempre desde el punto de vista interno:

¿Queremos un servidor? ¿Queremos dos servidores en HA? ¿Queremos integrarlo en nuestra infraestructura de virtualización ?o incluso, si no hay nada interno, porque se tienda al famoso «cloud» (aka: «no tengo nada en mi casa que mantener»

¿Pero que pasa con las comunicaciones? Es algo que muchas veces no se entra en detalle, mas allá de tener controlada la salida para tener llamadas VoIP de calidad, switches stackados en local para tener HA de electrónica base, con los servers cross-stack LACP configurado. Y, al menos nuestra apuesta, es algo que debería estar controlado, sobre todo si cada vez tendemos mas y mas a sacar infraestructura fuera y somos mas dependientes del canuto hacia Internet o de la MPLS que une nuestras delegaciones.

Bueno, basta de tanta charla pseudo teórica generalista, como siempre se suele decir: Stop Buffing and show me the sample scenario 😉

Así que sirva este pequeño esquema para ilustrar de partida el concepto de routing dinámico y HA que queremos comentar en esta entrada y que forma parte en general de nuestros diseños. Se trata de un esquema simplificado, eso sí:

 

En este sencillo esquema los elementos que tenemos son 4:

• Server VPN Principal. Pongamos que lo tenemos en el datacenter principal.
• Server VPN Backup. Pongamos que lo tenemos en un datacenter de respaldo.
• Cliente VPN (Target). En este caso se trata de un único cliente dibujado, que será un equipo «in house», tras un nat/firewalling clásico.
• Cliente VPN(Source). Sería un equipo que tiene que poder llegar a todos los posibles Targets, siendo por ejemplo un sistema de monitorización.

Podríamos haber pintado dos servers VPN en la misma ubicación, y configurados en un cluster Pacemaker/Corosync compartiendo una IP Virtual, pero no es el caso, queríamos dibujar una arquitectura a prueba de fallos de datacenters, para ilustrar las bondades y tener algo de lo que escribir 😉 (para hablar de Pacemaker y Corosync ya tendremos tiempo, seguro que algo escribiremos).

Llegados a este punto, cabe comentar que los enlaces pintados en rojo y verde son túneles VPN, no entramos a comentar si son OpenVPN (TUN o TAP) o PPPTP, o IPSEC, que tb serán dignos de futuros posts, simplemente asumimos que están y que tienen direccionamiento privado punto a punto y que funcionan correctamente, pero si tenemos que elegir, que sea OpenVPN !

Sobre este planteamiento inicial, si queremos Source pueda llegar a Target: Tiene que conocer por donde ir, que es través de server VPN Principal normalmente y se se cae, a través del server VPN de Backup. Pero que pasa si queremos:

• No tener que modificar Source cada vez que añadimos un Target, no queremos ponerle rutas a mano.
• No tener que modificar nada en caso de caídas del server VPN (para algo queremos HA, para que funcione sólo, automáticamente y bien 😉 ).

Así pues, pongamos unas IPs en juego para ordenar esto:

<table>

sssss aqui van las Ip’s

</table>

Dados los objetivos expuestos antes, está claro que tenemos optar por un protocolo de routing dinámico que se vaya enterando y actualizando la tabla de routing del kernel, nos salen varias opciones soportadas por Quagga: RIP, OSPF, BGP. La documentación de Cisco resulta siempre muyyyy útil: Cisco Press Dynamic Routing  En nuestro caso escogemos BGP, habitualmente escogido para la parte ‘edge’/’border’, que nos convence mucho también. Desde el punto de vista de BGP, lo primero a determinar son los sistemas autónomos (más info aquí de Cisco tb), estamos en el mundo del direccionamiento privado, así que escogeremos:

• Server VPN Principal:  65501
• Server VPN Backup: 65502
• Cliente VPN Target: 65503
• Cliente VPN Source: 65504