En estas entradas no tengo pensado hacer mucho hincapié en la resolución de problemas dado que tengo en mente una entrada propia para tareas de troubleshooting y algunos trucos de la consola.
El escenario que vamos a desarrollar va a ser el siguiente, si alguien se pregunta si podemos utilizar los equipos y configuraciones de la entrada anterior. Mi recomendación sería que no, dado que el direccionamiento varía y para aprender los comandos es mejor empezar el ejercicio desde cero.
Como se puede apreciar hemos añadido un nuevo router frontera (PE) y un router intermediario (P) al escenario. Nuestro P se encargará de conectar los routers frontera y participará en el core MPLS y en el routing OSPF, pero no participará en las sesiones iBGP que distribuyen la información de los VRFs.
El direccionamiento del P será
Mientras que el de los PEs será
Y como ya sabemos que significa todo esto de las VRF, los datos que vamos a utilizar van a ser los siguientes.
Y el direccionamiento de los distintos clientes es:
Recomendaciones
Para los equipos fronterizos (PEs) he utilizado la plataforma 2691 mientras que para el equipo intermediario (P) utilizo la plataforma 7200. La familia IOS utilizada es la 12.4 al igual que en la práctica anterior por las mismas razones comentadas.
La última familia publicada por Cisco es la 15.2 como se puede observar en el siguiente enlace:
http://www.cisco.com/en/US/products/sw/iosswrel/products_ios_cisco_ios_software_releases.html
Práctica
En primer lugar nos debemos asegurar que todos los equipos cuentan con el número de conexiones que necesitamos. Además, la plataforma 7200 no cuenta por defecto con ninguna interfaz por lo que deberemos añadir alguna antes de configurar el equipo.
El escenario con el que estamos trabajando es el siguiente:
* Configuración Inicial
Al igual que en la entrada anterior, inicialmente vamos a desactivar ciertas funciones y activaremos el etiquetado LDP para el switching MPLS.
! 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
Configuramos las interfaces que intervendrán en el core MPLS, tanto las interfaces físicas así como la de gestión Loopback.
! Interface Loopback
interface Loopback 0
description <Description>
ip address <IP>
!
! Interface WAN -> FastEthernet
interface FastEthernet
description
ip address
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 redes directamente conectadas:
Comando: ping <IP>
Al igual que en la práctica anterior y como se puede observar en el esquema mostrado al principio de la entrada, vamos a utilizar el protocolo OSPF con el área 0 para las redes del core MPLS.
! Routing OSPF
router ospf 100
log-adjacency-changes
network <Network> <Wildcard Mask> area <Number>
Y pasados pocos minutos comprobamos que aprendemos por OSPF todas las redes definidas anteriormente.
Comando: show ip route
Hasta aquí la configuración común a todos los equipos que intervienen en el switching MPLS, tanto para los equipos Ps así como los PEs. A continuación realizaremos el routing propio de los PEs y crearemos las diferentes direcciones VPNv4 de los clientes.
Configuración propia de PEs
* Routing MP-BGP
Como comentábamos un poco más arriba, los Ps no intervienen en el routing iBGP y no tienen constancia de la información que están transmitiendo. Simplemente reciben unos paquetes con unas etiquetas, localizan el puerto de salida del mismo y lo envían añadiendo la etiqueta correspondiente.
! 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 tenemos conexión a medida que vamos configurando peers:
Comando: show ip bgp summary
* Creando Clientes
Igualmente que en la práctica anterior, pasamos a crear los VRFs siguiendo los datos de la tabla anterior. En este caso además añadiremos un nuevo cliente al escenario.
! 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 no tenemos asociada ninguna interfaz.
Comando: show ip vrf
* Configurando Clientes
Al igual que en la práctica anterior, vamos a desarrollar una configuración básica utilizando una interfaz FastEthetnet para crear diferentes VLANs para los clientes.
! 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>
Vemos que aprendemos por BGP las redes definidas en las VRFs de los peers vecinos:
Comando: show ip route vrf <VRF>
Y comprobamos que tenemos conexión con las redes definidas en las VRFs de los equipos remotos.
Comando: ping vrf <VRF> <IP>
Limitaciones
En nuestros ejercicios estamos suponiendo una situación ideal para nuestras configuraciones, pero la vida real no siempre es un camino de rosas...
* Routing MP-BGP
Nosotros hemos comenzado con dos equipos fronterizos que generaban un total de 2 conexiones iBGP para la comunicación de las VRFs. Pero en el segundo ejemplo añadiendo un solo equipo más, obtenemos un total de 6 conexiones y añadiendo un cuarto PE tendríamos 12 conexiones.
Podemos calcular el número total de sesiones iBGP que nuestro core MPLS va a mantener. Es tan simple como multiplicar el número de PEs por el mismo valor menos uno, es decir:
Sesiones iBGP = PEs (PEs - 1)
En la siguiente gráfica podemos observar el crecimiento exponencial del número de sesiones iBGP a medida que añadimos PEs al escenario. He tomado un límite de 20 PEs que generan un total de 380 sesiones, podemos igualmente calcular un core de 100 PEs con 9900 sesiones iBGP...
Aparte del hecho que mantener una carga de trabajo que soporte cerca de 400 sesiones BGP y que cada vez que surja un cambio en la topología, 19 equipos tendrán que reconfigurar sus rutas/métricas en función del tráfico que vallan recibiendo de los distintos peers...
Tenemos que pensar en el hecho que dicho escenario llegará un día que tenga que ser ampliado y añadir nuevos vecinos (neighbors) a la red, que supondrá una tarea tediosa en función del número de equipos del que conste nuestro núcleo. En este caso la solución es bastante fácil y se basa en añadir un nuevo elemento a la red que aglutina el routing iBGP (Route Reflector) a través del que se transmiten las redes de los distintos clientes.
* Topología Full-Mesh
Teniendo nuevamente en cuenta los recursos de los routers y debido a que las redes MPLS utilizan una topología full-mesh para la conexión de los distintos elementos del core, el protocolo de distribución de etiquetas LDP mantiene igualmente un esquema lógico totalmente mallado.
Al igual que en el caso anterior y en mayor medida, en función que añadimos equipos al núcleo MPLS (Ps y PEs), el número de sesiones LDPs crece exponencialmente. La siguiente fórmula calcula el número total de túneles LDPs en función del número de nodos (N) de la red.
Túneles LDPs = N (N - 1) / 2
En la siguiente gráfica podemos observar como aumenta el número de túneles a medida que vamos añadiendo nodos a la red. En este caso, el número total de nodos es igual a 30 (Ps + PEs) y se establecen un total de 435 túneles.
Tecnologías como H-VPLS (Hierarchical VPLS) añaden un tercer nivel (Multi-Tenant Unit) al core MPLS pasando a ser los routers fronterizos que dan servicio a los distintos CEs. Esta configuración establece una red mallada entre los distintos PEs a los que se conectarán los MTUs, rebajando el número de sesiones LDPs establecidas en el core.
* Detección de Bucles
En las redes Ethernet tradicionales donde existe la redundancia de conexiones que propician la creación de bucles, es necesario implementar un mecanismo de control que los evite. Normalmente se utiliza el protocolo estándar STP (Spanning Tree Protocol) que dinámicamente calculará una serie de prioridades en las interfaces que intervengan en la conmutación.
En redes VPLS se utiliza un mecanismo distinto con el que controlar la generación de bucles. Dado que esta tecnología simula un switch virtual entre los distintos routers fronterizos (PEs) y las redes Ethernet no disponen del campo TTL, siguen el siguiente planteamiento:
"[...]Una trama recibida en un PE desde otro PE, nunca será retransmitida a ningún otro router fronterizo[...]"
En topologías full-mesh utilizando dicha regla junto con avisos Split horizont, aseguramos que no se aprenderán las mismas direcciones a través de equipos/conexiones diferentes evitando así la generación de bucles en la red.
Comentarios
He realizado esta misma práctica en equipos físicos, utilizando routers Cisco 1841 para los equipos fronterizos y Cisco 7204 para el equipo intermedio. Igualmente utilizando imágenes IOS de la familia 12.4 sin problemas en la configuración.
En siguientes entradas realizaremos la configuración de un reflector de rutas para solucionar el problema surgido a medida que ampliamos el número de PEs y simplificaremos la configuración y el mantenimiento de la red de nuestro "proveedor".
Un saludo, Brixton Cat.
No hay comentarios:
Publicar un comentario
Bienvenid= si quieres dejar un comentario