Soluciones MPLS con GNU/Linux

Buenas!

Volvemos a nuestro querido mundo del networking, sobre la potencia absoluta que nos dan los entornos GNU/Linux y que tanta pasión nos despierta 😉

Esta vez queremos comentar una de las principales novedades del kernel 4.3 que nos interesan mucho: el soporte de lo que se conoce como “light weight tunnels”  (lwtunnel), en concreto, en el área MPLS, que es la que nos interesa describir en este post.

Antes de esta release del Kernel, hubo un intento importante por parte de Igor Maravić, publicado en Github junto con las herramientas de user space necesarias (principalmente: iproute2 parcheado para soportar MPLS), se trató en la lista NETDEV del Kernel, y, posteriormente está muy comentado, casi de forma recurrente en lista de Quagga DEV.

MPLS en sí

El protocolo MPLS, en muchos casos considerado como de capa “2.5”, se podría decir que es  como un MUST BE en toda red grande, sobre todo ahora que fabricantes como Mikrotik con soporte nativo  MPLS e interoperable en su routerOS venden devices a un precio muy asequible.

Existe múltiples presentaciones comentándolo en detalle, nosotros nos quedamos especialmente con esta presentación de Alex Vishnyakov dónde explican desde el punto de vista del ISP las ventajas de tener una red con soporte MPLS; y con esta otra presentación resumen, que como intro es más que suficiente.

Lo que nos aplica en este caso

¿Dónde estamos en este post y para qué?

En este post no queremos entrar en el detalle de asuntos reservados ISP’s y/o carriers de tránsito o similares con complejas técnicas de Traffic Engineering. Nos centraremos exclusivamente en su soporte reciente nativo en Linux así como en alguna posibilidad moderna, de estas que nos gustan ;).

Principalmente hablamos desde la perspectiva de alguien que no es “Network Owner” y que se construye su infraestructura con ingenierías de routing sobre túneles, mezclando “clouds” de operadores e infraestructura propia, algo así como un Net Power User 🙂 (o un net cowboy obligado 😉 ).

Proof of concept!

Preparando el kernel

La versión mínima que tenemos que disponer es 4.3, Debian Jessie por defecto viene con 3.16. Así que tenemos dos opciones:

Si optamos por la compilación manual, debemos asegurarnos que al menos estas opciones están activadas (al hacer el clásico y casi olvidado ya make menuconfig): lwtunnel, mpls-iptunnel, mpls-gso y finalmente mpls-router.

Una vez descomprimido el fuente, ejecutado el make menuconfig, podemos crear paquetes DEB para instalarlos cómodamente:

(podemos añadir opciones -j para compilación paralela).

Tras bootear con el new kernel podemos cargar mpls_router por ejemplo y ver:

Este nuevo kernel nos expone un interface en /proc, siendo /proc/sys/net/mpls/conf/ dónde se define la activación o no global por interface.

 

Herramients de user space

Principalmente, necesitamos iproute2 con soporte MPLS para poder realizar configuraciones, descargable por ejemplo aquí.

La compilación no tiene misterior (./configure;make && make install).

Una vez instalado, vemos que ejecutando directamente “ip” obtenemos ya un output indicando soporte mpls:

y podemos, igualmente ejecutar por ejemplo:

dónde “-f mpls” es de address family MPLS, ni IPV4 ni IPV6, MPLS! Bienvenidos al mundo de los labels!

Ni routing por origen ni destino, decisión/”switching” por etiquetas 😉

Hello World MPLS

De cara a tener un esquema mínimo de prueba, necesitamos al menos:

  • Ingress node (LER label edge router): Equipo que recibe tráfico y lo re-encamina hacia la red MPLS, encapsulado en MPLS.
  • Egress node (LER también): Equipo recibe tráfico encapsulado en MPLS y finalmente elimina la parte MPLS y hace el delivery.

Es decir, partimos de un primer ejemplo sin tránsito ni nada MPLS, casi que punto a punto y fin.

Para comenzar con este despliegue, la base, tan sencilla como:

esquema_helloworld

Es decir, un par de hosts conectados en una red cualquiera, con una dirección de loop añadida (que hacemos se parezca a su NIC eth0 para que sea más fácil verlo):

MPLS01:

MPLS02:

Con esto tenemos las loopbacks ready.

Para realizar el envío de tráfico MPLS Encapsulated:

MPLS01

MPLS02:

 

Llegados a este punto, podríamos intentar pingar, peroooo:

Peroooooooooooooooooooo ¿Porqué no llegan?!!!

Si capturamos tráfico, vemos el ICMP:

icmp

 

Entrando en detalle vemos:
layer25

Efectivamente! Se trata de un paquete ICMP, pero tiene un layer adicional entre l2(frame ethernet) y l3(ip), de ahí que mucha gente lo llame protocolo 2.5

¿Entonces porque no llegan? No llegan porque hace falta realizar la salida ! El LER final tiene que desencapsular !

Por tanto, como queremos que funcione tanto en ida como en vuelta:

MPLS01:

MPLS02:

Y finalmente:

 

Encaminando tráfico

En el lado de GNU/Linux, actuar como un LSR (Label Switch Router) es prácticamente igual de sencillo que un LER:

Dónde:

 

  • X es la etiqueta recibida
  • Y es la etiqueta sobre-escrita
  • 192.168.2.2 (ejemplo) es el nexthop al que mandar los paquetes MPLS recibidos con la etiqueta X y que serán re-enviados con la etiqueta Y.

Y ya está! Con esto ya hemos transformado nuestra linux box en un LSR 🙂

Transportando MPLS over OpenVPN !

¿Por qué alguien puede querer hacer esto ? 😉

Generalmente, como comentábamos al principio, MPLS está presente en las redes grandes y/o de ISPS’s, en las que finalmente se ha acabando transportando ATM over IP y caminos semejantes. Bajo la perspectiva de empresas usuarias de redes, salvo acuerdos de integración en MPLS de ISP’s que actúen tb como Hoster’s y tengamos máquinas ahí que querer integrar de una forma muy específica, no parecen presentarse muchos casos de uso claros. Uno que si vemos muy probable es el de interconnecting entre los diversos clouds, transportando MPLS over OpenVPN y siendo por tanto agnósticos a lo que haya por de bajo, direccionamiento incluido 🙂 Así podemos hacer uso interno de las bondades de cada tipo de cloud, o, si se da el caso y por tipos de proyecto/legislación/X tenemos que estar si o si principalmente en una 😉

esquema_multinube

Fight!

De cara a realizar el escenario mínimo de proof of concept, nos planteamos:

esquema_mplsopenvpn (1)

Lo que es la configuración:

MPLS01

MPLS02

Siendo “VPN” el iface OpenVPN (importante, tiene que ser ‘tap’, no ‘tun’).

MPLS03

MPLS04

Una vez llegados a este punto, si pingamos desde MPLS04 con su origen loopback (el que usamos para MPLS):

¿Pero, está realmente viajando por el interface VPN? Basta con capturar en MPLS02 por ejemplo:

 

Despedida y cierre!

Realmente, nos ha quedado un micro-post esta vez 🙂 La verdad es que de MPLS se puede hablar un rato largo y hay muchos mas ingredientes a meter en la cazuela: ¿Routing dinámico? Existe este  Quagga de Renato Westphal   disponible con soporte LDPD.  ¿Interoperabilidad? Con la facilidad que da RouterOS de ser instalado en una MV, montar un escenario piloto es realmente trivial.

Nada más por el momento! Que tengáis un buen inicio de verano!



¿Te gusta este post? Es solo un ejemplo de cómo podemos ayudar a tu empresa...
Sobre Gorka Gorrotxategi

CTO en Irontec, en el frente técnico desde un par de lustros ya, para todo lo que tenga que ver con Networking, VoIP y Sistemas, en ese orden :D) Desde @zetagor escribo algo, pero poco verbose la verdad

1 Comentario

¿Por qué no comentas tú también?


  • Muy interesante lo de los MPLS, donde se pueden conseguir más información al respecto, principalmente sobre aplicaciones concretas de esta.
    Gracias

    Tuanity Hace 2 años Responde


  • Excelente informacion , habras probado la parte interoperatividad ?

    Norman Hace 2 años Responde


  • Buenas Norman,

    Pues sinceramente, lo empezamos a montar, se monta fácil un entorno de test con Mikrotik-RouterOS, permiten descargar un IMG que en KVM(Proxmox, …) arranca fácilmente y puedes por tanto conectarle ifaces contra bridges virtuales con VM’s con MPLS Linux y tal. Lo dejamos montado, pero no acabamos de aterrizarlo, saltamos a otros frentes variopintos 😉

    Gorka Gorrotxategi Hace 2 años Responde


  • Me podrían ayudar, cada vez que intento hacer el encaminamiento recibo este error:
    RTNETLINK answers: Invalid argument

    Jose Luciano Hace 9 meses Responde


  • Hola, muy bueno el post. He seguido todos los pasos pero me pasa que el ping no se me responde. Puedo notar que el ping llega al destino, pero este no responde el ping

    Rafael Hace 9 meses Responde


Queremos tu opinión :)