Practicando MPLS: Primeras configuraciones

Como comentaba en la entrada anterior, vamos a empezar a realizar algunas prácticas desde cero para intentar comprender las configuraciones y así ir complicando el escenario según vallamos asentando conocimientos para hacerlo lo más real que podamos.

Vamos a utilizar el emulador de red GNS3 con el que podemos cargar las imágenes IOS que necesitemos y así disponer de todos los comandos y configuraciones. En la página Artículos por fascículos de este mismo blog, podéis encontrar la serie Emulador de Red donde se describe el uso de herramientas como Dinamyps/Dinagen y GNS3, así como otras funcionalidades como hipervisores para repartir la carga del programa.

El escenario que vamos a desarrollar es el siguiente:

El direccionamiento de los PEs utilizado es:

Vamos a introducir un concepto clave dentro de las redes MPLS, los VRFs (Virtual Routing Forwarding), routers virtuales que aíslan el tráfico de los clientes dentro de la red MPLS, aún utilizando el mismo direccionamiento.

Los VRFs se definen principalmente con un Nombre y un valor numérico llamado RD (Route Distinguisher) que identifica a cada cliente. Además, y como punto fundamental, tenemos el concepto RT (Route Target) con el que podemos exportar e importar la información de una VRF.

Me ha gustado la siguiente definición del estándar BGP/MPLS (RFC-4364):

"A VPN-IPv4 address is a 12-byte quantity, beginning with an 8-byte Route Distinguisher (RD) and ending with a 4-byte IPv4 address. If several VPNs use the same IPv4 address prefix, the PEs translate these into unique VPN-IPv4 address prefixes. This ensures that if the same address is used in several different VPNs, it is possible for BGP to carry several completely different routes to that address, one for each VPN."

Nos dice que el campo RD, de 8 Bytes de tamaño, junto con una dirección IPv4 (4 Bytes) definen una dirección VPN-IPv4 (VPNv4) de 12 Bytes de tamaño, que identifica de forma única la VPN de un cliente utilizando el protocolo BGP inclusive usando el mismo direccionamiento IP.

La cabecera VPNv4 (12 Bytes) anteriormente comentada obviando los 4 Bytes menos significativos correspondientes a la dirección IPv4, constan de un campo Tipo (2 Bytes) y otro Valor (6 Bytes) del que existen tres tipos:

* Type 0 (ASN:nn): En este primer caso se utiliza el sistema autónomo de BGP (ASN), de 2 Bytes de tamaño, junto con un valor numérico que identifique únicamente la VRF (4 Bytes).
* Type 1 (IPv4:nn): En este caso, en el primer campo se utiliza una dirección IP de 4 Bytes de tamaño junto un valor numérico identificativo de 2 Bytes.
* Type 2 (ASN:nn): Éste último es inverso al primero, el campo correspondiente al ASN ocupa 4 Bytes de tamaño mientras que el valor numérico único ocupa 2 Bytes.

En nuestro caso vamos a utilizar el modelo ASN:nn, donde utilizaremos los 2 o 4 primeros Bytes de tamaño dependiendo del valor ASN que configuremos en nuestro routing BGP.

La gracia de todo esto es que tenemos disponibles políticas de exportación e importación de rutas, pudiendo importar la información no sólo de nuestra VRF sino también de otras que sean necesarias. Intentaré hacer algún ejemplo para que se entienda mejor con la práctica.

En relación a los Route Targets, el estándar citado anteriormente define:

"When a VPN-IPv4 route is created (from an IPv4 route that the PE has learned from a CE) by a PE router, it is associated with one or more Route Target attributes.  These are carried in BGP as attributes of the route.

[...]

Associating a particular Route Target attribute with a route allows that route to be placed in the VRFs that are used for routing traffic that is received from the corresponding sites."

Que en pocas palabras nos viene a decir que cuando se crea una dirección VPNv4 se asocia con uno o más RT y que asociando un RT a una VRF podremos utilizar el tráfico que aprendamos por la misma.

La configuración que utilizaremos para nuestras VRFs sera la siguiente:

Y el direccionamiento de cada cliente (VRF):

Manos a la masa

Vamos añadiendo equipos al escenario hasta que tenemos la siguiente topología:

* Configuración Inicial:

En primer lugar deberemos de configurar ciertos servicios y protocolos, así como desactivar ciertos comportamientos molestos. En mi caso, realizo la siguiente configuración:

! Services and features

no ip domain-lookup

no logging console

logging buffered 100000

no ip http server

service password-encryption

!

! Hostname

hostname <Hostname>

!

! Conf MPLS

mpls label protocol ldp

mpls ldp loop-detection

mpls ldp explicit-null

* Configuración Interfaces

Vamos a configurar las interfaces que participarán en el core MPLS así como una interfaz Loopback para las sesiones iBGP entre los distintos PEs.

! Interface Loopback
interface Loopback 0
  description <Description>
  ip address <IP> <Mask>
!
! Interface WAN -> FastEthernet
interface FastEthernet <Number>
  description <Description>
  ip address <IP> <Mask>
  speed 100
  duplex full
  mpls ip
  ! Depend of IOS version and platform
  ! 'override' word is mandatory
  mpls mtu [override] 1520
  no shutdown

Comprobamos que tenemos conexión entre las interfaces directamente conectadas:

Comando: ping <IP>

* Routing IGP

Como comentaba en la entrada anterior, para la conexión de los P y PEs vamos a utiliza el protocolo OSPF en el que definiremos el área 0 para las redes del core.

! Routing OSPF
router ospf 100
  log-adjacency-changes
  network <Network> <Wildcard Mask> area <Number>

Pasados pocos minutos comprobamos que conocemos por OSPF las redes definidas en el peer vecino.

Comando: show ip route

* Routing MP-BGP

Como comentaba en la entrada anterior y un poco más arriba, debemos configurar el enrutamiento para la conexión VPNv4 entre los PEs. Estableceremos sesiones iBGP con el Sistema Autónomo 300 para la conexión con el peer vecino (neighbor) a través de la interfaz Loopback.

! Routing iBGP
router bgp <ASN>
  bgp log-neighbor-changes
  neighbor <IP> remote-as <ASN>
  neighbor update-source Loopback 0
!
address-family vpnv4
  neighbor <Neighbor> activate
  neighbor <Neighbor> send-community both

Comprobamos que existe comunicación BGP entre los PEs vecinos:

Comando: show ip bgp summary

* Creando Clientes

En este punto pasamos a crear los VRFs de los distintos clientes, en nuestro caso ROJA y VERDE utilizando los valores de la tabla anterior.

! Create VRF
ip vrf <VRF>
  rd <ASN>:<nn>
  route-target export <ASN>:<nn>
  route-target import <ASN>:<nn>
!
! Routing VRF IPv4 Address Family
router bgp <ASN>
!
address-family ipv4 vrf <VRF>
  redistribute connected

Comprobamos que la configuración es correcta y que todavía no tenemos asociada ninguna interfaz a las VRFs:

Comando: show ip vrf

* Configurando clientes

Vamos a realizar una configuración básica utilizando VLANs en interfaces FastEthernet y ni siquiera vamos a realizar subnetting, es un ejemplo simple para entender el enrutamiento MPLS y comprobar que podemos tener el mismo direccionamiento en distintas VRFs.

! Physic Interface -> FastEthernet
interface FastEthernet <Number>
  no shutdown
  speed 100
  duplex full
!
! VLAN Subinterface
interface FastEthernet <Number>.<VLAN>
  description <Description>
  encapsulation Dot1Q <VLAN>
  ! Define VRF before IP address
  ip vrf forwarding <VRF>
  ip address <IP> <Mask>

Y comprobamos que conocemos por BGP la red configurada en el nodo vecino:

Comando: show ip route vrf <VRF>

Y si probamos a lanzar pines por las distintas VRFs vemos que tenemos conexión con los equipos distantes.

Comando: ping vrf <VRF> <IP>

Comentarios

Recomiendo realizar la práctica con routers Cisco 2691 para la configuración de los PEs y utilizar una IOS de la familia 12.4 dado que es una de la más utilizadas actualmente. La última familia de IOS publicada por Cisco es la 12.5 15.2 como se puede ver en el siguiente enlace:

http://www.cisco.com/en/US/products/sw/iosswrel/products_ios_cisco_ios_software_releases.html

He realizado esta misma práctica, saltándome el switch, en un par de equipos físicos de la serie 1800 (Cisco 1841) con una IOS también de la familia 12.4 y la configuración, aunque básica es funcional.

En la siguiente entrada añadiremos un router P y otro PE al escenario y comentaremos las limitaciones surgidas con este tipo de configuraciones.

Un saludo, Brixton Cat.

Practicando MPLS: Introducción

Como hace poco comente por Twitter, últimamente he estado investigando y practicando con redes MPLS y como no podía ser de otra manera traigo algunos ejercicios que me gustaría compartir con ustedes.

Las siglas MPLS corresponden con el término Multi-Procotol Label Switching, donde el transporte de la información no se realiza conmutando paquetes como en las redes Ethernet IP tradicionales, sino etiquetas (Label Switching) al estilo de otras tecnologías de capa 2 como ATM.

MPLS es una tecnología escalable de alta disponibilidad y fácil de mantener que proporciona mecanismos para decidir qué camino tomar (ingeniería de tráfico), compartir direccionamiento en distintos clientes, configuraciones QoS para priorizar el tráfico, políticas de importación/exportación de rutas, etc. La gallina de los huevos de oro que se podría decir...

Caracterizado por una red mallada (full-mesh) de routers intermediarios, llamados P's (Provider), en los que se conectarán los equipos fronterizos, llamados PE's (Provider Edge), que darán servicio a los equipos de las sedes remotas, CE's (Customer Edge).

MPLS es un protocolo llamado de capa 2 y media, dado que añade una cabecera de 32 bits entre la capa de enlace (Layer 2) y la de red (Layer 3). Es posible que dicha etiqueta supere el MTU designado para el protocolo, por lo que es común modificar dicho valor en las interfaces que intervienen en el core.

La cabecera que se incorpora al paquete IP tradicional esta compuesta por los siguientes campos:

* Label: Valor numérico de 20 bits asociado al puerto por el que pasa el paquete dentro de la red MPLS.

* Exp: Campo experimental de 3 bits que se utiliza, por lo menos, para la priorización del trafico mediante QoS a través del campo CoS de la trama Ethernet (Si está disponible).

* Stack: Valor booleano de 1 bit de tamaño para indicar si el paquete es el último en ser transmitido.

* TTL: Valor de 8 bits de tamaño para indicar el tiempo de vida del paquete (Time To Live).

Para nuestras prácticas nos imaginaremos un núcleo repleto de routers P's y PE's que se conocerán utilizando algún protocolo IGP (Interior Gateway Protocol) mientras que para conectar los distintos CE's deberíamos utilizar  protocolos EGP (Exterior Gateway Protocol) como BGP (Border Gateway Protocol), aunque es posible utilizar otros como RIP (Routing Information Protocol).

En nuestro caso utilizaremos OSPF (Area 0) para el core MPLS e iBGP (AS 300) para la conexión entre los distintos PE's que configuremos.

Como comentaba anteriormente, las redes MPLS utilizan la conmutación de etiquetas y no revisan la MAC de origen o destino así como las correspondientes IP's de los paquetes. Aparte de mantener una tabla ARP, mantienen un listado donde se especifican los puertos utilizados por un cliente así como las etiquetas correspondientes.

Entre las distintas interfaces MPLS estableceremos túneles LDP's (Label Distribution Protocol) para distribuir la información. Cada equipo ira añadiendo y quitando etiquetas (Etiquetas) según el paquete vaya pasando por las interfaces (Puertos), entre o salga de algún router frontera.

Desde 1998 que algunas empresas del sector comenzaron a desarrollar tecnologías de switching y etiquetado de paquetes IP, hasta la actualidad en el que se ha convertido en un estandar IETF (RFC 3031). MPLS proporciona alta velocidad de enrutamiento y VPNs sobre redes IP con ingeniería de tráfico. Otras tecnologías como VPLS amplían las capacidades LAN de los clientes simulando un switch en la red del proveedor o GMPLS que permite crear túneles LSPs (Label-Switched Paths) sobre tecnologías de transmisión como SDH con la que cubrir grandes distancias.

Hasta aquí un pequeño resumen teórico de lo que suponen las redes MPLS y los distintos protocolos que se utilizan o se pueden utilizar. En siguientes entradas, pasaremos a realizar algunos ejercicios básicos e iremos ampliando y dificultando el escenario para "asemejarlo" a una situación real.

Un saludo, Brixton Cat.