29 de mayo de 2012

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.

No hay comentarios:

Publicar un comentario

Bienvenid= si quieres dejar un comentario