Memoria - 230606 M Puñales

PROYECTO FIN DE CARRERA PLAN 92
Tema: Diseo e implementacin de una red IP con troncal MPLS
Ttulo: MPLS: Aplicacin y funcionalidades. Diseo e implementacin del servicio VPN-MPLS.
Mario Puales Casquero Junio 2006
INDICE
Introduccin 4
1. Introduccin a Multiprotocol Label Switching (MPLS) 1.1 Enrutamiento tradicional 1.2 Ingeniera de trfico en MPLS ... 1.3 Componentes de MPLS ..
6 7 8 10
2. Protocolo de distribucin de etiquetas (LDP) .. 2.1 Modo de operacin de LDP ... 2.2 Mensajes LDP
14 14 18
3. VPN-MPLS. Redes Privadas Virtuales MPLS 3.1 Topologa Hub-and-spoke .. 3.2 Topologa Partial o Full-Mesh ... 3.3 Topologas Hbridas ...
20 26 29 31
4. QoS. Calidad de servicio en redes MPLS . 4.1 La necesidad de aplicar una QoS ... 4.2 Condicionantes del trfico: El otro lado de Diff-Serv ... 4.3 IP Bearer Services .. 4.4 MPLS QoS .
33 33 38 43 46
5. MPLS Traffic Engineering 5.1 TE-RSVP 5.2 CR-LDP .. 5.3 Discusin tcnica, iniciativas de ingeniera de trafico en MPLS ... 5.4 Diferencias entre CR-LDP y TE-RSVP . 5.5 Conclusiones a las similitudes y las diferencias 5.6 MPLS TE Conceptos .. 5.7 MPLS TE Configuracin ... 5.8 MPLS TE Operacin ..
50 50 52 53 56 59 59 66 67
6. Escenario real de una red MPLS .. 6.1 Introduccin ... 6.2 Desarrollo ... 6.3 OSPF ..
69 69 70 72 2
6.4 BGP 6.5 Configuracin de LDP 6.6 Introduccin a la configuracin de VPN-MPLS
77 79 82
Conclusiones ... Glosario ... Bibliografa y Referencias . Anexo A: Manual bsico de configuracin MPLS sobre Cisco . Anexo B: Prcticas Propuestas . Anexo C: Automatizacin de la configuracin de la red ....
98 100 106 109 116 141
Captulo 1: Introduccin a Multiprotocol Label Switching (MPLS)
Introduccin
El entorno en el que se basa el proyecto es en el de las redes IP actuales con troncal MPLS y los servicios asociados a MPLS. MPLS (Multi-Protocol Label Switching) es un protocolo que surge para mejorar el enrutamiento de las redes IP sobre ATM, aadir diferentes funcionalidades a estas redes (ingeniera de trfico (TE), parmetros de calidad de servicios (QoS), etc.) y mejorar los retardos en el transporte del trfico en tiempo real y no real. Cabe destacar la clara separacin que hace MPLS de las funciones del control de la informacin sobre la topologa de la red y el trfico sobre la misma, y del envo de datos en s entre los elementos de la propia red. El proyecto comienza con una breve descripcin de los componentes que forman parte del protocolo MPLS con una comparacin del mtodo de routing en MPLS con el routing tradicional. Ms adelante en captulos posteriores se ver como MPLS puede a su vez convivir con los protocolos de routing tradicionales como BGP (Border Gateway Protocol) y OSPF (Open Shortest Path First). Tambin se discuten las ventajas de MPLS para el soporte de procedimientos de encaminamiento y envo de paquetes en la malla central (backbone) de las redes IP, y la posibilidad de proporcionar nuevas aplicaciones y servicios en redes IP. En concreto, se presenta la utilidad del MPLS para el soporte de aplicaciones de ingeniera de trfico, de diferenciacin de servicios en distintas clases (QoS) y de establecimiento de redes privadas virtuales (VPN) sobre una topologa "inteligente", muy superior en prestaciones a las soluciones tradicionales de tneles y circuitos virtuales. Para ello se instaura una topologa de red basada en dos partes: una parte de ncleo o backbone MPLS (core) en el que los equipos encaminan el trfico mediante la conmutacin de etiquetas, y otra parte externa en la que los equipos sustituirn las etiquetas usadas en el encaminamiento dentro del core por las direcciones IP correspondientes. Slo los routers de core tendrn configurado MPLS. El encaminamiento mediante estas etiquetas presenta grandes ventajas en el tiempo de latencia de los equipos y en la simplicidad de la conmutacin, con lo que se reducirn los retardos de la red. Se presta especial atencin a la utilizacin de MPLS en las Redes Privadas Virtuales (VPN), donde las operadoras emplean gran parte de sus recursos para satisfacer las necesidades de sus abonados, tanto particulares como pymes y grandes empresas. De hecho este es el captulo principal del libro, en el que se hace referencia a los diferentes tipos de topologa que se pueden implementar sobre un dominio MPLS (Topologas Hub & Spoke, Partial o Full Mesh, hbridas.). El objetivo final es la implementacin de una maqueta para la realizacin de prcticas cuya topologa y servicios ofrecidos se corresponden con los propios de este tipo de redes.
Se identifican cada uno de los pasos a seguir durante el diseo, configuracin, operacin y mantenimiento persiguiendo el que la implementacin de esta maqueta, sea valida en aplicaciones docentes y sirva como un documento didctico para futuras prcticas en algn laboratorio de las asignaturas que se imparten por DIATEL. Otro aspecto interesante es la resolucin de algunos de los problemas mas comunes en la configuracin de interfaces, anlisis de estadsticas del trfico, solucin de problemas de red y gestin, etc. En definitiva lo que se define como troubleshooting de red. Adems para facilitar la configuracin de los diferentes routers de acceso y de core, se ha hecho uso de una aplicacin que se ejecuta a travs de un entorno Web, lo cual implica que se puede ejecutar de forma remota y a la cual se hace referencia en el ltimo cpitulo. En la implementacin de la maqueta descrita en este PFC se han utilizado routers del fabricante Cisco, pudiendo implementarse en routers, que soporten MPLS, de otros fabricantes.
1. Introduccin a Multiprotocol Label Switching (MPLS)

Con el crecimiento exponencial de Internet en los ltimos aos, la tecnologa ha tenido que adaptarse constantemente a las nuevas demandas de los usuarios de los diferentes servicios que se ofrecen en funcin del incremento del ancho de banda. En definitiva, continuara vindose un grandsimo crecimiento de Internet debido al incremento de la demanda de mas ancho de banda en los servicios domsticos (entre otros) a los que ya se esta llegando mediante servicios de banda ancha. Con la previsin de que haya un incremento de mas de 250 millones de nuevos usuarios en la prxima dcada y con la implementacin del protocolo de Internet versin 6 (IPv6), los proveedores de servicio y las operadoras de telecomunicaciones se esfuerzan en mejorar sus infraestructuras actuales por la inevitable demanda que se avecina sobre los servicios ofrecidos en sus redes. Para alcanzar y poder ofrecer la demanda de ancho de banda debida al aumento de usuarios y de necesidades de los mismos, los proveedores de servicios de Internet (ISP) necesitan mejorar el rendimiento en sus productos de enrutamiento y conmutacin de sus redes. Adems la mayora de los proveedores y operadores de las redes de datos tienen sus grandes redes montadas con tecnologa ATM, la mayora de conexiones a estos proveedores contina siendo mediante Frame Relay y conexiones punto a punto, lo que implica la presencia de latencia y alguna vez cuellos de botella en los puntos de acceso a la red. Los routers del ncleo de red tambin contribuyen al incremento de las latencias en los tiempos, ya que cada uno debe de tomar la decisin de por donde encaminar el trfico que le llega. Tradicionalmente, IP ha sido montado sobre redes ATM, usando IP sobre ATM a travs de circuitos virtuales (VC). Estos mtodos de transporte de datos esta probado que son engorrosos y complicados. La necesidad de un mtodo simple de transporte de datos, uno en el que el trfico sea gestionado mediante las caractersticas de rendimiento normales de un conmutador junto con la inteligencia en el transporte y reenvo de trfico de un router, es absolutamente necesario para las redes de hoy en da. Todas estas necesidades pueden ser cubiertas con el Multiprotocolo de conmutacin de etiquetas (MPLS: Multiprotocol Label Switching) en adelante MPLS. Porque integra las caractersticas clave de las capas 2 y 3 del modelo OSI. Pero lo ms importante es que no limita el uso de ningn protocolo de nivel 2 o 3, ni se ve limitado por alguno de ellos. En particular, MPLS tiene algunas aplicaciones y pueden ser extendidas a travs de mltiples segmentos de producto, por ejemplo, un router MPLS, un conmutador o router IP, un conmutador multiservicio, un switch Ethernet, etc
1.1 Enrutamiento tradicional

En un entorno de routing tradicional, un paquete es transportado a travs de una red mediante el concepto de hop-by-hop, usando un protocolo de enrutamiento interno a la red (IGP: internal gateway protocols), como por ejemplo RIP (Routing Information Protocol), OSPF (Open Shortest Path First), o usando protocolos de routing externo (EGP: external gateway protocols), como por ejemplo BGP (Border Gateway Protocol). El funcionamiento ser en funcin a las referencias de direcciones destino de nivel 3 contra las tablas de enrutamiento que tienen los diferentes equipos de la red, es decir, comprobaran en sus tablas de enrutamiento cual es el siguiente salto para una direccin destino concreta. En definitiva, a cada paquete de datos que atraviesa un router se le comprobara cual es su direccin de destino mediante un campo que aparece en la cabecera IP del mismo. Esta comprobacin debe ser realizada para determinar cual es el siguiente salto de ese paquete hasta llegar a su destino. La direccin destino de nivel 2 es entonces reemplazada con la direccin de nivel 2 del siguiente salto y la direccin origen de nivel 2 ser reemplazada con la direccin de nivel 2 del router donde se encuentra el paquete. Sin embargo las direcciones origen y destino de nivel 3 para que el router del siguiente salto sepa enrutar el paquete hasta su destino. Este proceso debe ser repetido en cada salto del paquete hasta su destino. Se puede ver un ejemplo de funcionamiento del routing tradicional en la siguiente figura, donde se envan paquetes al router F, el router C har referencia solo a la direccin destino del router F. El router C entonces determinara cual es la mejor ruta para llegar al F, basndose en los atributos que estn definidos en funcin del IGP que este funcionando en la red. Si el router estuviese usando RIP, se enviaran los paquetes por el camino que tuviese menos saltos en su trayecto completo, teniendo en cuenta que el numero mximo de saltos nunca puede ser mayor de 15. Sin embargo, si se estuviese usando OSPF, se tendra en cuenta el coste total del camino entre el router origen hasta el destino (por ejemplo, mediante las mtricas, normalmente basadas en el ancho de banda de cada enlace) y se elegira el camino que supusiera el menos coste de toda la red.
Figura 1.1. Ejemplo de enrutamiento tradicional.
Como se puede ver en la figura 1.1, el router C debe tomar las decisiones de envo de los paquetes que le llegan con destino el router F basndose en las mtricas definidas en el IGP que haya sido implementado en la red. Si ha sido OSPF, las mtricas se podrn basar en diferentes criterios, pero el criterio mas usado es el ancho de banda. Si el IGP que se usa es RIP, en este caso se basara en las mtricas del nmero de saltos, descartando el paquete si alcanza los 15 saltos antes de llegar a su destino como ya se ha indicado antes. Segn la figura 1.1 todos los paquetes que llegan desde los routers A o B con destino el router F, sern enviados por el mismo sitio, a travs del camino seleccionado como el de mejores mtricas. Por lo tanto, si el camino hacia el router F a travs del router D es el de mayor ancho de banda disponible, se usara ese camino a no ser que haya algn fallo en la red que lo impida, en ese caso los paquetes serian enviados a travs del router E.
1.2 Ingeniera de trfico en MPLS

Sin embargo, MPLS usa un mtodo de envo de paquetes con un alto grado de velocidad en comparacin con el routing tradicional. Combina la velocidad y el rendimiento de la capa 2 con la escalabilidad y la inteligencia IP de la capa 3. Los routers en la frontera de la red, los Label Edge Router, en adelante LER, son los routers que se encuentran en el borde de la zona MPLS y son los encargados de aadir cabeceras MPLS entre las cabeceras de red y de enlace del paquete entrante. Tambin son los encargados de retirar esa informacin cuando el paquete sale de la nube MPLS. Estos routers aaden las etiquetas basndose en conjuntos o flujos de paquetes, denominados Forward Equivalence Class, en adelante FEC, a los cuales se les aade una cabecera en la zona MPLS que hace que sean tratados de la misma forma independientemente de que sean paquetes de distintos tipos de trfico. A efectos prcticos, es el conjunto de paquetes que ingresan por un mismo LER y a los cuales este les asigna la misma etiqueta. Estos FEC son conmutados dentro de la red, es decir, se hace la conmutacin de las etiquetas asociadas a los paquetes dentro de la red, mediante los routers conmutadores de etiquetas o Label Switch Router, en adelante LSR. Bsicamente los LSR son conmutadores de la nube MPLS que interpretan el valor de la cabecera MPLS y la modifican si es necesario. No aade ni elimina cabeceras MPLS solo cambian el valor de la etiqueta en funcin de sus tablas de enrutamiento. La idea ms importante es que aadiendo una simple etiqueta en un LER, el LSR es capaz de conmutar un paquete mucho ms rpido y de forma ms eficiente ya que lo hace en
funcin un solo elemento, en contraste con el concepto de hop-by-hop usado en el enrutamiento tradicional. Una etiqueta tiene generalmente significado local nicamente, facilitando de esta forma el anlisis de la cabecera IP de un paquete, que esta ligada a un FEC concreto (como si fuese un prefijo IP), en los LER y en los LSR se comprueba la etiqueta que tiene el paquete que les ha llegado y en funcin de sus tablas de etiquetas enviaran el paquete por un camino o por otro, cambiando el valor de la etiqueta en caso de que sea necesario (en los LSR), estas tablas se llaman LIB, base de datos de informacin de etiquetas (Label information base). Cuando se habla de la LIB no se hace alusin a las verdaderas ventajas con que cuenta la ingeniera de trfico basada en MPLS pero existen mltiples ventajas. Cuando un LSR o un LER construyen su LIB, tienen control total para poder encaminar paquetes hacia la red. La mayor ventaja del algoritmo de enrutamiento que usa MPLS es que el anlisis de la cabecera de los paquetes IP solo se necesita hacer una vez, cuando el paquete llega al LER de entrada a la red MPLS. A partir de ah, el paquete es asociado a un FEC, encaminando el paquete mediante el uso de las etiquetas a travs de un camino conmutado de etiquetas o Label Switch Path, en adelante LSP. Donde el LSP rigurosamente es el camino que describen el conjunto de routers y conmutadores que atraviesan los paquetes de un FEC concreto en la nube MPLS. Todos los paquetes del mismo FEC siguen el mismo LSP siempre, de principio a fin en la nube MPLS. En las figuras 1.2 y 1.3 puede verse un ejemplo de enrutamiento MPLS:
Figura 1.2 Ejemplo de ingeniera de trafico en MPLS.
Figura 1.3 LIB del router C.
En la figura 1.2 se puede ver que los paquetes con destino al router F y enviados desde el router A seguirn el camino de color verde o el LSP verde (a travs de los routers A, C, D y F). Los paquetes que se enven desde el router B sern encaminados a travs del camino de la lnea punteada roja o LSP rojo. Esto se hace en funcin de las referencias que haya para las distintas etiquetas en la LIB de cada router, hasta que la etiqueta alcance su valor de salida del dominio MPLS. En la figura 1.3 se ve la LIB del router C como ejemplo. Los paquetes que forman parte de un FEC con destino el router F llegaran al router C por la interfaz S2 con etiqueta 50, el router C en funcin de su LIB mirara por donde tiene que enviar ese paquete y vera que lo tiene que enviar por la interfaz S0 con un nuevo valor de etiqueta, el 12, realiza una conmutacin de etiqueta. La ventaja de controlar los patrones del trafico rpidamente se hace evidente cuando se compara con los IGP tradicionales (como OSPF), los cuales encaminan los paquetes basndose en la direccin destino de la capa de red (capa 3) solo. La mayora de las redes OSPF se disean con varios caminos para un mismo destino, pero usando solo la ruta que tiene el menor coste, lo que implica ms tiempo de computacin para el clculo.
1.3 Componentes de MPLS

Aunque ya se ha hecho referencia a muchos de los componentes de este protocolo a continuacin se har una breve referencia a ellos de forma un poco ms amplia para su comprensin. MPLS tiene muchas mejoras respecto al enrutamiento IP en lo que al encaminamiento de paquetes se refiere. Muchas de esas mejoras son sobre todo a nivel de ingeniera de trafico y de calidad de servicio (QoS: Quality of Service), tcnicas empleadas en ATM. Otros componentes de MPLS hacen posible que estas tcnicas funcionen con un mayor grado de rendimiento e inteligencia. Tambin proporcionan una manera ms eficiente de encaminar los paquetes desde el origen hasta el destino que el encaminamiento basado en el hop-byhop del enrutamiento tradicional, como ya se describi anteriormente. Muchos de estos
10
componentes son simples extensiones de tecnologas ya existentes, como por ejemplo las extensiones de componentes existentes en protocolos de routing como BGP. Adems las funcionalidades de LSR y de LER pueden ser aadidas a routers IP, conmutadores ATM, etc, normalmente aadindoles una carga de software adicional y en algunos casos algo de hardware que permita a los equipos tener estas funcionalidades. En definitiva, se puede decir que MPLS puede tener componentes que son extensiones de otros componentes porque las funciones de enrutamiento y de control de componentes estn separadas en los dispositivos capaces de trabajar con MPLS. El componente de encaminamiento es responsable de transportar los paquetes basndose en una tabla de routing. Por otro lado el componente de control es el responsable de la construccin y del mantenimiento de la tabla de rutas, as como trabajar con los componentes de control de otros nodos para completar la informacin de encaminamiento en las tablas de routing.
Label La etiqueta es un identificador de la cabecera de un paquete IP, adems dentro de ella esta contenida toda la informacin necesaria para que el paquete sea encaminado. A diferencia de la cabecera IP, la etiqueta no contiene una direccin IP, pero si un valor numrico valido para al menos los dos routers que estn a ambos extremos de un LSP y que ambos han acordado su valor. La etiqueta es de reducido tamao, tiene una longitud fija y tiene normalmente significado local nicamente. Cuando a un paquete se le asigna una etiqueta que a la vez se relaciona a un FEC se hace siempre en funcin de la direccin destino del mismo. En resumen, la etiqueta que se le asigna a un paquete representa el FEC al que se asocia dicho paquete en el dominio MPLS. Dentro de algunos medios de transporte, existen etiquetas que pueden ser usadas por nodos MPLS cuando tienen que tomar decisiones de encaminamiento con el trafico que les llega, como por ejemplo los identificadores de camino virtual / identificadores de circuito virtual (Virtual path identifier / Virtual connection identifier VPI/VCI) en ATM y en el caso de Frame Relay el DLCI (Data Link Connection identifier). Otras tecnologas como Ethernet y los enlaces punto a punto, deben usar lo que se llama una Shim Label, como se muestra en la figura 1.4:
11
Figura 1.4 Campos de una Shim label
La Shim Label esta formada por 32 bits, se usa para identificar localmente un FEC.
Forwarding Equivalence Class (FEC) Un FEC puede ser considerado como un conjunto de paquetes que son encaminados en la misma direccin a travs de la red. Un FEC puede incluir todos los paquetes que compartan una direccin destino con el mismo prefijo IP o paquetes que formen parte de una aplicacin particular entre un host origen y un host destino. Los FEC generalmente se construyen mediante la informacin aprendida a travs del IGP correspondiente, como por ejemplo OSPF o IS-IS (intermediate system to intermediate system). Label Switch Path (LSP) Un LSP es fundamentalmente la ruta predeterminada que un conjunto de paquetes que forman parte de un FEC atraviesan a travs de una red MPLS hasta alcanzar su destino. Cada LSP es unidireccional; por consiguiente, tiene que haber dos LSP diferentes para los dos sentidos del trfico en una misma ruta. Label Stack (Pila de etiquetas) Es un conjunto de etiquetas dispuestas en forma de pila. Se produce cuando existen zonas MPLS dentro de otras zonas MPLS. La pila de etiquetas es LIFO (Last-in, First-out, ltimo en entrar, primero salir). En otras palabras, la etiqueta que esta en la cima de la pila es la del dominio MPLS en el que se encuentra el paquete y la ltima etiqueta es la del dominio MPLS por el que debe salir el paquete de la red MPLS.
12
Label Distribution Protocol (LDP, Protocolo de distribucin de etiquetas) Para que un LSR al que le llega un paquete, pueda conmutarlo y enviarlo al vecino correspondiente segn su tabla de etiquetas (LIB), debe tener un mtodo de aprendizaje del valor de la etiqueta que debe enviar al par correspondiente. Actualmente, algunos protocolos pueden ser usados para la distribucin de etiquetas entre pares LSR, como por ejemplo LDP (Label Distribution Protocol), CR-LDP (Constraintbased routed-label distribution protocol), RSVP (Resource reservation protocol) y BGP (Border Gateway Protocol). En captulos posteriores se entrar ms en detalle en el funcionamiento de estos protocolos de distribucin de etiquetas. La arquitectura de MPLS, segn la RFC-3031, no especifica que protocolo de distribucin de etiquetas debe usarse entre pares LSR. De hecho, el protocolo usado depender de los requerimientos que se deben cumplir para cada red de forma particular, es decir, lo decidir el administrador de la red en funcin de la ingeniera de red, recursos disponibles, etc El protocolo LDP fue diseado nicamente para este uso, pero el LDP por s solo no rene las necesidades de calidad de servicio (QoS) necesarias para una red en explotacin. Para soportar aplicaciones de calidad de servicio, un protocolo de distribucin de etiquetas, como LDP, debe ser capaz de seleccionar y reservar apropiadamente los recursos de red necesarios para formar los diferentes LSP en la red. Para soportar esto, puede estar usndose un protocolo de reserva de recursos y extenderlo a las funciones de distribucin de etiquetas, como por ejemplo el caso de RSVP, o a la inversa, tener un protocolo de distribucin de etiquetas y extender su uso a funciones de reserva de recursos de red, como por ejemplo BGP o LDP. El Draft draft-ietf-mpls-ldp-07.txt que contiene la especificacin de LDP, define el conjunto de procedimientos y mensajes mediante los cuales los LSR establecen los LSP a travs de la red. Sin embargo, cuando estos LSP son construidos hay que asegurarse de que pueden soportar requerimientos de calidad de servicio y de ingeniera de trafico. En definitiva, existen algunos casos donde se da la necesidad de tener un mtodo de creacin explicita o manual de un LSP, por lo tanto habr dos tipos de LSP en un dominio MPLS: LSP dinmicos que se crean en funcin de los FEC y de las tablas de etiquetas junto con la tabla de routing creada por el IGP que se este usando. LSP estticos que pueden ser creados manualmente por el administrador de la red en funcin de las necesidades o para diferenciar diferentes tipos de trafico, prioridades o servicios
13
Captulo 2: Protocolo de distribucin de etiquetas (LDP)
2. Protocolo de distribucin de etiquetas (LDP).

La arquitectura MPLS define un protocolo de distribucin de etiquetas como un conjunto de procedimientos por los cuales los Label Switched Router (LSR) informan a otros LSR del significado de las etiquetas usadas para enviar trfico entre y a travs de ellos. El protocolo de distribucin de etiquetas LDP (Label Distribution Protocol) es un protocolo estndar del IETF de distribucin de parejas <label, prefix> para el funcionamiento de MPLS. Es decir, LDP distribuye los paquetes por la red en funcin de la dupla anterior: Si quieres llegar a este prefijo, utiliza esta etiqueta. LDP funciona en paralelo junto a los protocolos de routing internos IP que actan sobre la red, como por ejemplo OSPF. Mediante la tabla de forwarding creada por el protocolo de routing interno, que est configurado en la red troncal, los LSR generarn los LSP (Label Switched Path) en la red. A su vez LDP asociar un FEC (Forwarding Equivalence Class) a cada LSP creado, de esta manera se especificar que tipo de trfico circular por cada LSP de la red. Puede funcionar junto a otros mecanismos de distribucin de etiquetas como por ejemplo BGP-4 (Border Gateway Protocol version 4) o TDP (Tag Distribution Protocol), este ltimo fue el antecesor de LDP y es propietario de Cisco. A continuacin se va a hacer una breve sntesis de la RFC haciendo referencia nicamente a las caractersticas bsicas de mensajes y operacin de LDP para comprender mejor el funcionamiento de una red con troncal MPLS que use como protocolo de distribucin de etiquetas LDP. Se puede encontrar ms informacin tambin en el draft del IETF: draftietf-mpls-ldp-07.txt y en la RFC-3036
Eliminado: e Eliminado: a Eliminado: a Eliminado: a Eliminado: a
Eliminado: h Eliminado: u
2.1 Modo de operacin de LDP

El modo de operacin de LDP se puede definir en tres pasos: 1. Descubrimiento. 2. Establecimiento de la sesin. 3. Anuncio de etiquetas. A continuacin se describen brevemente cada uno de estos pasos.
14
2.1.1 Descubrimiento Se han definido dos mecanismos para la fase de descubrimiento de pares LDP: Mecanismo de descubrimiento bsico: Los LSR descubren a sus vecinos mediante el envo de mensajes Hello. Los mensajes Hello se enviarn a la direccin de broadcast por todas las interfaces del router. Mecanismo de descubrimiento extendido: es utilizado en el caso de LSR que no estn directamente conectados. Un LSR enva peridicamente mensajes Hello dirigidos a una direccin especfica, estos mensajes llevan entre otra informacin el identificador de LDP para el espacio de etiquetas y la interfaz que el LSR est usando. Cuando el LSR destino recibe los mensajes Hello decide si responderlos o ignorarlos; cuando escoge responder, lo hace enviando tambin de forma peridica mensajes Hello al originador, de esta forma se establecer una adyacencia con el LSR originador establecindose una sesin LDP. A diferencia del mecanismo bsico, slo se mandar a una direccin de LSR especifica y no se hace multicast.
Eliminado: a
Eliminado: el Eliminado: a Eliminado: ,
Eliminado: o Eliminado: a
2.1.2 Establecimiento de la sesin. Una vez se han enviado y recibido mensajes Hello, el LSR que tenga la MAC mas alta comenzar a establecer una sesin TCP con su vecino para negociar los parmetros de la sesin LDP mediante el intercambio de mensajes de inicializacin. lLos parmetros a negociar son por ejemplo el rango de etiquetas, modo de anuncio, etc. Los LSR mantienen sus sesiones LDP para la transmisin continuada y peridica de paquetes Hello para indicar la ausencia de problemas en un enlace a nivel fsico. Tambin para la transmisin peridica de mensajes Keepalive en la conexin TCP, para una monitorizacin de la misma, es decir, para saber que el vecino esta manteniendo la sesin TCP operativa. Es importante apreciar que debe de existir una nica sesin TCP por cada sesin LDP entre dos LSR. En el caso de LSR que no estn conectados directamente las sesiones LDP son creadas mediante aplicaciones de ingeniera de trfico usando LSP explcitamente. A continuacin se detalla la maquina de estados del proceso de inicializacin del establecimiento de una sesin LDP, ya que sta es la mejor forma de describir el comportamiento de la negociacin de una sesin LDP. Se tendrn cinco posibles estados que representarn los distintos comportamientos como una transicin entre los estados. Esta mquina de estados est definida en la RFC-3036 en la que adems se explica de una forma ms detallada el proceso de establecimiento de una sesin LDP entre dos LSR.
Eliminado: e Eliminado: a Eliminado: a Eliminado: a Eliminado: a Eliminado: a Eliminado: , Eliminado: o
Comentario [RDM1]: No entiendo esta frase
15
NON EXISTENT
Conexin TCP de sesin establecida. Rx cualquier otro mensaje LDP. Tx mensaje notificacin error. Recibir cualquier otro mensaje LDP.
INITIALIZED
(Papel Pasivo) Rx mensaje de inicio aceptable / Tx mensajes inicio y mantenimiento. (Papel Activo) Transmitir mensaje de inicio.
OPENREC
OPENSENT
Rx cualquier otro mensaje LDP. Tx mensaje de notificacin de error.
Recibir mensaje de mantenimiento
Recibir un mensaje de iniciacin aceptable. Tx mensaje de mantenimiento.
OPERATIONAL
Rx Shutdown msg or Timeout / Tx Shutdown msg Recibir cualquier otro mensaje LDP
Figura 2.1. Maquina de estados LDP.
16
Los eventos que se generan en la transicin entre los diferentes estados se pueden ver brevemente resumidos en la siguiente tabla: ESTADO
NON EXISTENT
EVENTO
Conexin TCP de sesin establecida Transmitir mensaje de inicio(papel activo) Recibir mensaje de inicio aceptable (papel pasivo). Accin: transmitir mensajes de inicio y mantenimiento. Recibir cualquier otro mensaje LDP. Accin: transmitir mensaje de notificacin de error (NAK) y cerrar la conexin de transporte Recibir mensaje de mantenimiento Recibir cualquier otro mensaje LDP. Accin: transmitir mensaje de notificacin de error (NAK) y cerrar la conexin de transporte. Recibir un mensaje de iniciacin aceptable. Accin: transmitir un mensaje de mantenimiento. Recibir cualquier otro mensaje LDP. Accin: transmitir mensaje de notificacin de error (NAK) y cerrar la conexin de transporte. Recibir mensaje de finalizacin. Accin: transmitir mensaje de finalizacin y cerrar la conexin de transporte. Recibir cualquier otro mensaje LDP Intervalo de tiempo sobrepasado. Accin: transmitir mensaje de finalizacin y cerrar la conexin de transporte.
NUEVO ESTADO
INITIALIZED OPENSENT OPENREC
INITIALIZED INITIALIZED
INITIALIZED OPENREC OPENREC
NON EXISTENT
OPERATIONAL
NON EXISTENT
OPENSENT
OPENREC
OPENSENT
NON EXISTENT
OPERATIONAL OPERATIONAL OPERATIONAL
NON EXISTENT
OPERATIONAL
NON EXISTENT
Figura 2.5. Estados de LDP 2.1.3 Anuncio de etiquetas. Para cualquier sesin LDP dada, cada LSR debe ser consciente del mtodo de distribucin de etiquetas usado por su par. Se han definido dos mtodos de anuncio de etiquetas en LDP: Downstream Unsolicited: en el que el LSR anuncia una etiqueta para un prefijo cuando est preparado para recibir paquetes MPLS con destino a dicho prefijo. De
17
esta forma, un LSR puede anunciar su mapeo de etiquetas para un FEC a sus vecinos siempre que haya completado la misma con la conmutacin de etiquetas que se aplique a ese FEC. Existirn respuestas rpidas y de iniciativa local a cambios en las rutas. La ventaja principal de este mtodo es la rpida reaccin a los cambios de routing que se pueden producir porque las etiquetas ya existen. Una desventaja es que los mapeos de etiquetas que no son necesarios tambin se envan a los pares LDP. Downstream on Demand: en el que el LSR anuncia una etiqueta para un prefijo cuando el LSR vecino se lo solicita. El LSR solicitar una etiqueta en el momento que aprenda una nueva ruta para dicho prefijo, de esta forma un LSR puede contestar a una peticin de mapeo de etiquetas inmediatamente, sin esperar al mapeo de etiquetas que le enve algn vecino para completar su tabla de etiquetas, adems el LSR debe mantener un dialogo constante con otros LSR para poder responder adecuadamente a cambios de routing en la red, ya sea por cambios de topologa de la misma o por incidencias en los enlaces. Este mtodo se usa principalmente cuando se quiere conservar el valor de las etiquetas (por ejemplo, en un conmutador ATM). La ventaja principal en este caso es que se asignan slo las etiquetas que se requieren para reenviar paquetes de datos. Una desventaja es que si se producen cambios de routing que afectan al siguiente salto para un destino dado, debe obtenerse una nueva etiqueta para el siguiente salto antes de que los paquetes etiquetados con esa etiqueta puedan enviarse.
Eliminado: e Eliminado: a
2.2 Mensajes LDP

Los mensajes LDP se dividen en cuatro categoras: Los mensajes Discovery, con estos mensajes los LSR anuncian su presencia en la red mandando mensajes Hello peridicamente. Todos los mensajes Discovery son enviados sobre una conexin TCP. Los mensajes Session, se usan para establecer, mantener y terminar sesiones entre pares LDP. Cuando un LSR establece una sesin con otro LSR lo har mediante el procedimiento de inicializacin sobre transporte TCP que se explicar ms adelante. Cuando el proceso de inicializacin se completa satisfactoriamente se dice que los LSR son un par LSR y podrn intercambiar mensajes Advertisement. Los mensajes Advertisement, se usan para crear, modificar y anular el mapeo de informacin en los FEC. Los mensajes Notification, se usan para proporcionar informacin preventiva y de error.
Eliminado: a Eliminado: a
Los diferentes tipos de mensajes incluidos en cada una de estas categoras se pueden consultar en la RFC-3036
18
2.2.1 Formato de los mensajes LDP Todos los mensajes LDP tendrn el mismo formato, puede verse en la siguiente figura:
2 Bytes
2 Bytes
Tipo del mensaje
Longitud del mensaje
Identificador del mensaje Parmetros obligatorios
Parmetros opcionales
Figura 2.2 Formato de los mensajes LDP Donde los diferentes campos que aparecen en la figura anterior significan lo siguiente: Bit U: Mensaje desconocido. Si el bit U tiene como valor 0 se enva una notificacin al originador del mensaje, en el caso de que el bit U tenga como valor 1, el mensaje ser ignorado. Tipo Mensaje: como su propio nombre indica es el tipo de mensaje. Longitud Mensaje: como su propio nombre indica es la longitud del mensaje incluyendo el identificador y los parmetros opcionales del mensaje. Identificador mensaje: es el identificador del mismo. Parmetros obligatorios del mensaje: Tiene longitud variable. Hay mensajes LDP que no tienen parmetros obligatorios. Parmetros opcionales del mensaje: Campo de longitud variable.
Con formato: Sangra: Izquierda: 17,85 pto, Sangra francesa: 17,85 pto, Con vietas + Nivel: 1 + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36
Eliminado: i
19
Captulo 3: VPN-MPLS. Redes privadas virtuales MPLS
3. VPN-MPLS. Redes Privadas Virtuales MPLS.

A continuacin se van a introducir los principales conceptos e implementaciones de redes privadas virtuales (VPN) utilizando MPLS. Una VPN se puede definir como un conjunto de sites que comparten una informacin de routing comn (tabla de routing). Un site puede pertenecer a varias VPN como se ve en la figura siguiente:
Site-1
Site-2
VPN-A
VPN-B
Site-3
VPN-C
Site-4
Figura 3.1. Correspondencia Sites-VPN. Las VPN son utilizadas por las empresas para desplegar y administrar en sus redes servicios de valor aadido incluyendo aplicaciones, servicios de telefona, etc La funcionalidad de IP VPN para MPLS permite en una red desarrollar servicios de VPN a nivel 3 en un backbone nicamente IP, en el que los clientes pueden disponer de una red privada, de una forma escalable y segura para su comunicacin interna. Tambin se pueden necesitar VPNs de gestin por parte del proveedor de servicio para controlar el servicio a sus clientes pero en las que no se pueden conectar los clientes. La seguridad es un aspecto primordial en las VPN. En redes IP tradicionales existen dos tecnologas que se emplean para establecer tneles que pueden coexistir con la conmutacin de etiquetas mediante MPLS: IP Security: proporciona autenticacin del cliente en la red y cifrado de datos opcional. Su principal desventaja es que slo soporta protocolo IP.
20
Generic Route Encapsulation: es ms rpido y sencillo y adems soporta mltiples protocolos adems de IP (IPX,...). Sin embargo no proporciona seguridad con lo que no es muy adecuado para servicios VPN que discurren a travs de Internet.
A continuacin se va a describir la arquitectura MPLS VPN, las principales opciones de diseo, operaciones posibles a realizar en estas redes y terminologa relacionada. Las redes tradicionales de routers se implementaron originalmente con enlaces punto a punto dedicados, que conectaban los sitios de los clientes. El coste de tales redes era alto debido a que: Los enlaces dedicados punto a punto no permiten cualquier infraestructura que comparta el proveedor de servicio asignando estadsticamente un tiempo a cada uno de los diferentes clientes, lo que resulta en altos costes para el cliente final. Cada enlace requiere un puerto dedicado en un router, con el coste que ello supone.
Las redes VPN se introdujeron con X.25 y Frame Relay, tecnologas que utilizan circuitos virtuales para establecer conexiones extremo a extremo sobre una infraestructura en un Internet Service Provider compartido. Los circuitos virtuales pueden ser: PVC: Circuitos Virtuales Permanentes. Previamente establecidos manualmente o mediante herramientas de gestin de red (por ejemplo Conection Manager en Cisco). Siempre estar activo. SVC: Circuitos virtuales conmutados. Se configuran bajo demanda a travs de una solicitud de establecimiento de llamada del dispositivo CE con el que se crear un circuito no permanente entre el dispositivo CE y el PE.
Las ventajas que se obtienen con el modelo de VPN MPLS frente a los modelos tradicionales son: Es una plataforma que permite un rpido y poco costoso despliegue de los servicios IP de valor aadido, entre los que se incluyen intranets, extranets, voz, servicios multimedia y comercio electrnico. Es decir, mayor flexibilidad que las VPN de nivel 2 (Intranets o Extranets) Privacidad y seguridad, al igual que en las VPN de Capa 2, pero limitando la distribucin de las rutas de las VPN, estas solo se distribuirn a los routers que pertenezcan a cada VPN. Es decir, soporte de direccionamiento privado (ver RFC 1918) en las redes de los clientes permitiendo el solapamiento del espacio de direccionamiento de los clientes. Se mejora la escalabilidad del provisionamiento para el proveedor. Es mucho ms sencillo provisionar un nuevo cliente ya que simplemente hay que configurar un nico enlace entre su router y un router PE para permitir el acceso a la red MPLS. En las VPN tradicionales se tendra que establecer un enlace entre la nueva sede y todas las dems sedes. Esto permite implementar escenarios en los que existan miles de sites para cada VPN y las VPN clasificadas segn las clases de servicio IP (QoS) proporcionadas, y
21
con diferentes prioridades. Estas clasificaciones por clases de servicio pueden darse tanto para servicios ofrecidos por una VPN entre sus diferentes sites, como entre VPN. Existencia de mecanismos IP QoS. Simplificacin del routing para el cliente.
Sin embargo las VPN tradicionales todava comparten aspectos con las VPN actuales: Los enlaces dedicados se reemplazan con una infraestructura comn que emula enlaces punto a punto para el cliente, resultando en una comparticin estadstica del proveedor de servicio. Esta comparticin de infraestructura habilita al proveedor de servicio para ofrecer conectividad a bajo precio, con lo que los costes operacionales de los clientes disminuyen.
A continuacin se va a ver un ejemplo para estudiar la terminologa:
Figura 3.2. Terminologa VPN MPLS.
22
Se pueden definir los siguientes elementos dentro de un servicio VPN sobre una nube MPLS: Red P: Red del proveedor del servicio. Infraestructura que el proveedor de servicio utiliza para ofrecer servicios VPN a los clientes. Red C: Red del cliente. Es la parte de toda la red del cliente que est exclusivamente bajo el control del cliente. Sitios de clientes (VPN Sites): Equipos propios de la red del cliente.
Y en cuanto a los dispositivos que habilitan a la VPN para que funcione: Router CE: Router del cliente que conecta el site del cliente a la red del proveedor de servicio. Dispositivos PE: Dispositivos del proveedor de servicio en los que se conectan los dispositivos del cliente. Por ejemplo en redes WAN suelen ser Switches de Frame Relay. Dispositivos P: Pertenecen al proveedor de servicio y slo proporcionan transporte de datos a travs del backbone MPLS y no poseen conexiones directas con los clientes.
Los servicios VPN MPLS pueden ofrecerse basndose en dos modelos principales: VPN overlays: El proveedor de servicio proporciona enlaces virtuales punto a punto entre los sites de los clientes pero no participa en el routing de cliente. Este modelo presentar diversos problemas como el de ancho de banda, sobrecarga de encapsulacin, y una necesidad de un mallado completo (full mesh) para implementar las rutas ptimas. VPN peer-to-peer: El proveedor de servicio participar en el routing del cliente. Se utilizarn filtros de paquetes en los routers PE para aislar a los clientes. El proveedor de servicio asignar parte de su espacio de direcciones y gestionar los filtros en los PE para asegurar que todos los equipos de cliente tienen conectividad.
La filosofa de las VPN se debe basar en la presencia fundamental del protocolo IP entre las distintas sedes de un cliente. Cada sede debe saber encaminar su trfico hacia las dems con lo que lgicamente debe existir un protocolo de routing que distribuya la informacin de los diferentes prefijos pero que no permita que se inmiscuya trfico perteneciente a redes de otros clientes. Si existe un cliente con dos sedes que quieran crear una VPN entre ellas se debe actuar de la siguiente manera: Las sedes de los clientes tendrn asignado previamente un rango de direcciones privadas (por ejemplo 47.x.y.z) que pueden estar incluso reutilizadas en las distintas sedes para reducir el nmero de direcciones IP que necesita el cliente. Los equipos del ncleo MPLS no van a encaminar los paquetes en base a direcciones IP puras y adems no sera lgico
23
desde el punto de vista del cliente que se le ofreciera un nuevo servicio en el que el cliente tuviera que modificar su direccionamiento para poder aceptar este servicio. Las direcciones de los clientes slo las van a conocer los equipos PE. Si los dems routers MPLS no pueden ver el direccionamiento de los clientes los equipos PE tienen que saber de alguna manera hacia qu VPN est dirigido cada paquete. En este momento es cuando entra en juego la facilidad de apilar etiquetas existentes en MPLS. Haciendo uso de la figura anterior se va a explicar el funcionamiento bsico del servicio VPN en una nube MPLS, por ejemplo si se enva trfico entre las sedes de la VPN A, el PE 4 introduce en el paquete la etiqueta que indique cul es la VPN y despus introduce la etiqueta bsica MPLS que le indica cmo llegar al PE 3. La etiqueta de VPN le dir a PE 4 por qu interfaz debe sacar el paquete. La pila de etiquetas quedara de la siguiente manera.
Etiqueta MPLS Etiqueta VPN

Datagrama IP Figura 3. 3. Pila de etiquetas VPN MPLS Lgicamente debe existir un protocolo (LDP u otro) para intercambiar estas etiquetas VPN y que ser independiente o no del protocolo que se utilice para distribuir las etiquetas MPLS bsicas. El backbone MPLS slo ver la etiqueta MPLS. El problema de la seguridad no es tal en las VPN MPLS ya que se asegura que slo cada cliente va a ver su direccionamiento. Los routers PE tienen que comprobar que los prefijos de cada VPN slo se enviarn hacia las dems sedes de la VPN y no se mezclarn con los otras VPN. Los identificadores ID de las VPN (se vern en el captulo de diseo prctico de un escenario real) no pueden ser objeto de spoofing (que algn intruso simule que es un cliente), ya que las etiquetas se asignan dinmicamente. El modelo VPN tambin permite, dependiendo de las restricciones que se impongan, que parte del trfico de una de las VPN se vea en otra pero en las dems no,... Por lo tanto se podr permitir que las sedes de la VPN B reciban todos o parte de los paquetes de la VPN A y a su vez impedir que este trfico llegue a las sedes de la VPN C. Como puede apreciarse, el modelo tiene gran flexibilidad. La construccin de las VPN se basa principalmente en el intercambio de las communities. Las communities van a ser parmetros identificadores de cada conexin. Este concepto proviene de BGP, protocolo de routing externo entre diferentes sistemas autnomos, en el que mediante la combinacin de estas communities se puede conseguir mltiples restricciones, permisos, filtros,... a la hora de enviar trfico entre dos sistemas autnomos.
24
Una extensin de BGP (Multiprotocol BGP) va a ser de hecho el protocolo de distribucin de las etiquetas VPN y los ID van a ser communities. Las communities principales de las VPN son: Route Distinguiser RD y Route Target RT. Route Target se encargar de controlar el routing de la VPN. Se pueden colocar varios RT en cada router. Route Distinguiser sirve para evitar la duplicidad de las direcciones IP. Cada router slo importar los prefijos que vea con su RD y no podr importar rutas con otros RD. El funcionamiento bsico es que el RD se usa para generar un prefijo VPNMPLS que distingue unas VPN de otras, de forma que cada VPN tenga un prefijo nico y univoco dentro de la nube MPLS.
El proceso de distribucin de routing comienza entonces con MBGP entre los routers PE, mientras que para la distribucin desde el router CE al PE se utilizar algn IGP (OSPF, RIP,...), BGP o sencillamente routing esttico. Para llegar desde un PE a otro se utilizar MPLS va IGP atravesando los routers P. Por ltimo los PE egress importarn el routing desde MBGP y a su vez lo enviarn al CE va IGP, routing esttico o BGP.
Figura 3.4. Distribucin de routing entre PE-CE.
En las VPN se suele utilizar el Penultimate Hop Popping, para comprender mejor este concepto se usar un ejemplo basado en la figura 3.2, si se quiere enviar trfico desde CE2 a CE3 por ejemplo a travs de PE3 P - P se puede hacer que PE3 le indique a P que si quiere entregarle un paquete antes le suprima la etiqueta. Si la ruta fuese la PE3 P, que por otra parte sera la ruta de camino ms corto, no interesara habilitar PHP porque slo se tendra un router P y entonces el envo de paquetes se convertira en IP puro. En cada router PE se van a crear una serie de instancias de routing diferentes para cada VPN llamadas tablas de routing virtuales (VRF). Sera como crear dentro de cada router PE mltiples routers virtuales. Podemos ver un ejemplo de configuracin de una VRF en el captulo de escenario real de una red MPLS.
25
Los pasos a seguir para la configuracin de una VRF son: Definir las VRF. Configurar las listas de importacin / exportacin. Asignacin de las interfaces a VRF. Configuracin de los contextos de routing. Configuracin del Multiprotocol BGP para la distribucin de las rutas BGP.
Cada VPN est asociada a una o ms tablas VPN routing/forwarding (VRF). Una VRF define a cada miembro de una VPN que cuelga de cada router PE. Es decir, una VRF consiste en una tabla de rutas IP, un conjunto de interfaces que usan esta tabla de forwarding y un conjunto de reglas y parmetros del protocolo de routing que gestionan la informacin que est incluida en la tabla de routing. Las VRF se generan a partir de la tabla de forwarding que se ha creado al activar el protocolo de routing interno en la nube MPLS. Un site, como se vi al comienzo de este documento, no tiene por que pertenecer a una nica VPN, sino que puede pertenecer a varias VPN. Sin embargo un site solo puede tener asociada una nica VRF donde vendrn reflejadas todas las rutas disponibles para los paquetes que se generan hacia y desde ese site.
3.1 Topologa Hub-and-spoke

En una topologa Hub and Spoke todas las sedes de una empresa actan como spokes enviando todo el trfico que quieren intercambiar entre ellas hacia la sede central de la empresa que actuara como Hub, esta ltima, distribuir el trfico que le llega hacia sus destinos segn sus polticas de routing. Normalmente se suele utilizar esta topologa de red para VPN cuando se tiene un acceso Internet de empresa, firewalls, granjas de servidores, etc, todo ello sito en la sede central, de ah que sea esta sede la que acte como Hub. Es similar a una topologa en estrella. En cualquier caso, cuando se implementa esta topologa de red para una VPN/MPLS es necesario que la sede que acta como Hub conozca todas las rutas para poder llegar a todos y cada uno de los spokes que pertenecen a esa VPN. Esto se consigue haciendo que los spokes exporten sus rutas hacia el Hub y este a su vez hace que el resto de spokes puedan importar las rutas de los dems, es decir, el Hub exporta las rutas que ha importado de un spoke a los dems spokes de la misma VPN. De esta forma, con esta topologa se asegura que todo el trfico que se genere entre spokes pase siempre por el Hub. Esto se hace mediante los Route Target y Route Distinguiser que se han explicado anteriormente. Normalmente no existir conectividad directa entre spokes sino que solo tendrn conectividad con el Hub y este ltimo tendr conectividad con todos, debido a las tablas de rutas y a la VRF de la VPN a la que pertenecen el Hub y los spokes.
26
Sede Central (HUB)
Sede Remota (Spoke)
Red MPLS
Sede Remota (Spokes)
Sede Remota (Spokes)
Figura 3.5. Topologa Hub & Spoke
Existe la posibilidad de que el router que tiene la funcionalidad de Hub en esta topologa de red pueda sufrir algn tipo de incidencia que lo pueda dejar total o parcialmente fuera de servicio. Esto se puede prevenir con alguna de las soluciones siguientes: Una topologa Hub and Spoke simple como la de la figura anterior se puede mejorar aadiendo un router mas en la sede central que acte como Hub, es decir, desdoblando esta funcionalidad, de esta forma se tendr redundancia ganando sobre todo seguridad en el servicio, se puede ver un ejemplo en la figura 3.6. Otra alternativa que ofrece la topologa Hub and Spoke es con un router de backup para la sede central, en este caso se enlazara con la sede central (duplicando los enlaces que tiene en el acceso a la nube MPLS) mediante conexiones de alta velocidad y con un elevado ancho de banda como se puede apreciar en la figura 3.7.
La forma mas simple de configurar una VPN-MPLS con topologa Hub and Spoke sera asignando el mismo RD (Route Distinguiser) a cada VRF de cada una de las sedes que acten como spoke. De esta forma el spoke no intercambiar informacin de routing directamente con el resto de spokes y tampoco sus Route Targets.
27
HUB 1
Sede Central
HUB 2
Red MPLS
Sede Remota (Spoke)
Sede Remota (Spokes) Sede Remota (Spokes)
Figura 3.6. Topologa Hub & Spoke con dos routers centrales.
Sede Central (HUB)
Sede Central (HUB)
Red MPLS
Sede Remota (Spoke)
Sede Remota (Spokes) Sede Remota (Spokes)
Figura 3.7. Topologa Hub & Spoke con dos Sites centrales.
28
A continuacin se enumeran los pasos que se deben seguir para llevar a cabo la configuracin de una topologa bsica Hub and Spoke: En todas las sedes que componen la VPN, se configurara una ruta esttica entre los equipos CE y los equipos PE, esto implica que todo el routing se har entre los equipos PE asociados a cada sede de la VPN. Una vez se han creado todas las rutas estticas para que el trafico de las sedes remotas pueda ser enrutado por la nube MPLS, se crea la VRF asociada a la VPN, esto se hace en los equipos PE que como se ha indicado anteriormente son los encargados del routing de los paquetes pertenecientes a la VPN. De esta forma las subredes que unen a los equipos PE con los equipos CE han pasado a la tabla de routing de la propia VRF, con lo que est asegurada la conectividad local. En este tipo de VPN cada equipo PE debe tener una ruta esttica apuntando a aquello que tiene localmente accesible a travs de su propio CE. Pero una vez que se configuran los equipos PE hay que tener en cuenta que no todos tienen la misma funcionalidad, pues ya se sabe que al menos uno de ellos tiene funcionalidad de Hub y el resto de Spokes. Por lo tanto en los equipos que tienen funcionalidad de Spoke hay que configurar una ruta esttica entre este y el CE local para tener conectividad total entre ellos. En el caso del PE que tiene funcionalidad de Hub, hay que tener en cuenta que todo lo que no le propaguen sus vecinos iMBGP (los otros equipos con funcionalidad PE) supondr que se podr alcanzar a travs del CE local. Recordar que previamente a la configuracin de la VPN ha habido que configurar OSPF y BGP (aunque podran haberse utilizado otros protocolos de routing interno). Por ultimo para asegurarse de que todos los prefijos pertenecientes a cada una de las sedes que forman parte de la VPN puedan ser propagados entre los equipos PE con funcionalidad spoke y el/los equipos PE con funcionalidad Hub, hay que configurar iMBGP en todos ellos. Una vez establecidas las sesiones iMBGP con el resto de equipos PE y verificada la conectividad local con los integrantes de la VPN faltara propagar los prefijos locales de los respectivos clientes al resto de equipos PE para que stos sepan encaminar los paquetes hacia dichos prefijos. Como cada equipo PE conoce el prefijo del equipo CE local mediante una ruta esttica entonces bastar con redistribuir dicha ruta esttica en el iMBGP.
3.2 Topologa Partial o Full-Mesh

Los servicios de redes privadas virtuales estn orientados claramente hacia el cliente, por y desde el punto de vista de cliente, pero no en todos los casos se puede implementar cualquier tipo de topologa de red por motivos estructurales de la empresa, distribucin de
29
sedes de la misma, tipo de aplicaciones y servidores utilizados y su disposicin en las distintas sedes de la empresa, etc. En resumen, por los elevados costes que puede significar la implementacin o no de un tipo de topologa de red determinado, como puede ser el caso de la topologa Hub and Spoke que se ha descrito brevemente en el apartado anterior. Por estos y otros motivos, en muchos casos, se buscan otras soluciones topolgicas para implementar el servicio VPN en una empresa. Estas soluciones son topologas totalmente o parcialmente malladas. Existe una topologa Full-Mesh cuando cada nodo de una red tiene conectividad directa con el resto de nodos de la red. Normalmente estas topologas se implementan en los backbones de las redes. Existe una topologa Partial-Mesh cuando solo algunos nodos de la red tienen conectividad directa con el resto de nodos de la red, es decir, algunos de los nodos tendrn conectividad directa con el resto de nodos y otros nicamente estarn conectados a uno o dos nodos en la red de forma directa. Una topologa Partial Mesh normalmente se implementa en redes de acceso que a su vez estn conectadas a redes con topologa Full-Mesh. Podemos ver un ejemplo de red con topologa Partial-Mesh en la figura 3.8 y de red con topologa Full-Mesh en la figura 3.9.
B A
D H G E F
Figura 3.8. Topologa parcialmente mallada o Partial-Mesh.
30
CE CE
PE PE
CE
CE P P
PE CE CE CE PE
Figura 3.9 Topologa totalmente mallada o Full-Mesh. Hay que hacer notar, que una topologa en Full-Mesh lleva inherente un alto coste debido al gran nmero de enlaces que son necesarios para su implementacin. Viene expresado por la siguiente formula. Donde VCs es el nmero de enlaces y n es igual al nmero de routers que pertenecen a la red: VCs = [(n-1) x n] / 2] Tanto en las redes totalmente malladas como en las parcialmente malladas el nmero de problemas e incidencias en la red es directamente proporcional al crecimiento de la misma. Es labor de los departamentos de ingeniera de red de las empresas que gestionan las redes el dimensionar las mismas en funcin del trfico y de las necesidades de la empresa, para as evitar tanto costes innecesarios como problemas de red.
3.3 Topologas Hbridas

Una topologa de red se dice que es hbrida cuando combina diferentes tipos de topologa en una misma red. Una topologa de red de este tipo es muy comn en grandes redes, en redes WAN por ejemplo. Debido a que cada topologa de red tiene sus ventajas y sus inconvenientes se pueden combinar diferentes topologas para intentar recoger las ventajas de cada una en una nica topologa, es decir, en una nica red.
31
Por lo general cuando se implementa el servicio VPN sobre una red de grandes dimensiones lo que se hace es combinar diferentes tipos de topologas de red, es decir, se puede usar una topologa Hub and spoke sobre una topologa parcialmente o totalmente mallada. Cara a las diferentes sedes, la topologa del backbone de la red es transparente para ellas y les es independiente si est parcialmente o totalmente mallado. Las sedes nicamente sabrn que se comunican unas con otras. Para evitar costes innecesarios se suele configurar la parte de acceso al backbone con una topologa Hub and Spoke y el propio backbone con una topologa total o parcialmente mallada dependiendo del nmero de routers que lo formen y el nmero de enlaces que sean necesarios. A continuacin se puede ver una figura de una red con topologa hbrida en la que conviven dos topologas diferentes, para la parte de acceso al backbone habr una topologa totalmente mallada y para el backbone se ha optado por una topologa parcialmente mallada. De esta forma se limita el trfico que circulara por el backbone de la red pero a costa de un mayor nmero de enlaces en la parte de acceso, con el consecuente incremento de coste que ello puede suponer. Este es solo un ejemplo pero existen mltiples combinaciones de topologas de red aunque siempre se usara la que ms se adecue a las necesidades econmicas y de red en cada caso. En la figura 3.10 se muestra un ejemplo de una organizacin como la mencionada anteriormente:
1 2
5 H G 3 F E 6 D
Figura 3.10 Ejemplo de topologa Hbrida.
32
Captulo 4: QoS. Calidad de servicio en redes MPLS
4. QoS. Calidad de servicio en redes MPLS.

4.1 La necesidad de aplicar una QoS
La aparicin de nuevas aplicaciones en las redes actuales como la creacin de redes corporativas entre clientes, el trfico en tiempo real de videoconferencias, la transmisin de video de alta definicin,... hace necesario establecer una diferencia en el tratamiento del trfico para los operadores. Ya no existe slo el tpico trfico relacionado con el paradigma de best effort, es decir, sin restricciones ni parmetros mnimos de calidad y que se enva cuando se puede, como las consultas normales a pginas web, las solicitudes de transferencia de ficheros va FTP o el envo de correo electrnico, con lo que es necesario asignar unos compromisos de niveles de servicio que garanticen una determinada fiabilidad de la red, independientemente de si la cantidad de trfico es elevada o no e incluso de los fallos de la red. En este captulo se tratarn los sucesivos pasos que se han dado para dotar de distintas calidades de servicio al trfico de las redes IP y la funcionalidad que presenta MPLS para asignar o no prioridad a segn qu tipo de trfico. En la tabla siguiente se pueden ver los diferentes requerimientos dependiendo del tipo de aplicacin:
Caracterstica/ Tipo trfico Ancho de banda Sensibilidad de eliminacin de paquetes Sensibilidad al retardo Sensibilidad al jitter
de Voz Entre bajo y moderado Bajo Alto Alto
FTP Entre bajo y moderado Alto Bajo Bajo
ERP (Enterprise Resource Planning) y trfico crtico
Bajo Entre bajo y moderado Entre bajo y moderado Moderado
Figura 4.1. Requerimientos en funcin del trfico. El trfico de voz necesitar un retardo bajo, una mnima variacin de este retardo para que la conversacin se pueda entender, mientras que la prdida de algunos paquetes no afecta demasiado a la calidad de la conversacin. El trfico de datos puede presentar un retardo y una variacin del retardo sensiblemente mayor al trfico de voz, mientras que es tolerante a la variacin del ancho de banda. El trfico de vdeo puede soportar un retardo mayor que el de voz, pero la prdida de paquetes puede afectar considerablemente a la calidad del servicio.
33
Por tanto para conseguir que la red opere de manera eficiente, cada aplicacin se debe considerar en trminos de sus requerimientos de calidad de servicio y agruparse en un nmero determinado de clases. Una de estas clases no tendr mayores requerimientos que los tradicionales del trfico best effort, pero con trfico como el de vdeo,... existirn otras clases que requieran una calidad de servicio mayor. En la figura siguiente se puede ver la evolucin temporal de las diferentes tcnicas para aplicar QoS a las redes:
Figura 4.2. Pndulo QoS IP Las primeras tecnologas que se crearon para dotar de cierto control de QoS a las redes fueron TOS (Tipo de servicio) e Int-Serv (Servicio Integrado). Las limitaciones de estas tecnologas restringieron bastante su uso, y han sido incapaces de proporcionar un adecuado entorno de trabajo para provisionar servicios que cumplan los SLA (Service Level Agreements). Una de estas primeras tecnologas permiti a las redes distinguir entre el trfico de control y el trfico de usuario. Esta tcnica proporcionaba una clasificacin de servicio y un nmero reducido de clases de servicio, basndose en el campo TOS (tipo de servicio) definido en la cabecera de los paquetes IP. Lo que sucedi fue que estas clases de servicio se definieron sin tener muy claras las necesidades reales de los usuarios. Otra tcnica que se desarroll posteriormente fue Int-Serv. Int-Serv proporciona un servicio extremo a extremo entre los hosts para aplicaciones punto a punto y punto a multipunto. En Int-Serv, la aplicacin inicia una sesin bajo demanda con la red utilizando el protocolo RSVP (Resource Reservation Signaling Protocol). Esta sesin identifica los requerimientos de servicio de la aplicacin, incluyendo informacin como el ancho de banda, el retardo y el origen de los datos.
34
El objetivo de Int-Serv ha influido en las propiedades del protocolo RSVP tradicional, como el estado de las conexiones o las solicitudes de recursos. Mientras estos aspectos de Int-Serv lo hicieron un protocolo potente, habilitndolo para garantizar los requerimientos mnimos de cada aplicacin, tambin haba que pagar un alto precio en trminos de procesamiento y sealizacin. El RSVP tradicional requiere una mquina de estados que incluye temporizadores para cada sesin y clasificadores para cada router, lo que hace que la capacidad de memoria y procesamiento sea muy alta. En un router de backbone Internet pueden establecerse muchas sesiones RSVP con otros hosts, y estos routers no tienen los recursos necesarios para tratar todas las sesiones. Esta limitacin restringe generalmente el empleo de Int Serv a los routers frontera de la red. Esto reduce la efectividad, ya que no se asegura que los dems routers, aparte de los routers frontera, cumplan los mismos requisitos para conseguir una calidad de servicio extremo a extremo. La principal ventaja de Int-Serv/RSVP es que el establecimiento de la QoS se realiza automticamente. El nico parmetro a provisionar manualmente es el ancho de banda asignado por RSVP en las interfaces. Por el contrario, presenta varios inconvenientes: La sobrecarga correspondiente a la sealizacin para la QoS y a la informacin de estado en el caso de redes de gran tamao es muy alta. Se deben enviar mensajes constantes de refresco de la informacin de estado.
Ms adelante se desarroll el mecanismo Diff-Serv. Al contrario que en Int-Serv, el objetivo de Diff-Serv no es proporcionar un servicio extremo a extremo para la aplicacin, sino crear un conjunto de building blocks que sirvan como base para los servicios extremo a extremo. Diff-Serv parte como una aproximacin similar al TOS pero est mejor dirigido a las necesidades de las aplicaciones actuales. Es lo suficientemente escalable como para poderse configurar tanto en los routers frontera como en los routers de core. En vez de establecer estados para cada sesin, cada paquete lleva la informacin sobre cada clase de servicio. Se pueden combinar los building blocks para conseguir un servicio final hacia el cliente. Diff-Serv define un nmero determinado de modelos de tratamiento de datos, conocidos como Per Hop Behaviour PHB (los PHB son un tipo de building blocks), que pueden aplicarse a los paquetes en cada nodo. El PHB se usa para identificar el tratamiento que se le va a dar en cada nodo. Este tratamiento incluye la seleccin del tipo de cola donde se van a almacenar los paquetes, la disciplina de planificacin que se aplicar en el interfaz de egress (ingreso en la red), y los umbrales de congestin. Por ejemplo, un determinado modelo de tratamiento de datos puede seleccionar una cola con una prioridad alta y sin embargo un umbral de congestin bajo, y con un esquema para gestionar las congestiones. Si se le da a un paquete un tratamiento similar a ste en cada uno de los nodos a travs de la red, puede conseguirse un efecto extremo a extremo. Los paquetes se marcan para identificar el tipo de tratamiento
35
que van a recibir utilizando el byte DS. Este byte DS reemplaza al byte de TOS de la cabecera IP. Fue elegido este byte debido a que originalmente se usaba para indicar cul era la informacin de servicio, pero como se ha dicho antes, su uso ha estado limitado. Dentro de este byte DS se define un campo llamado DSCP (Diff-Serv CodePoint) que identifica el comportamiento o el tratamiento que se debe aplicar al paquete dentro de cada nodo de la red. Para conseguir un comportamiento efectivo cada nodo aplicar el mismo tratamiento.
Figura 4.3. Byte DS en un paquete Ipv4. El campo DSCP ser de 6 bits, mientras que los otros 2 bits actualmente no se utilizan (bits CU en la figura 4.3) y estn reservados para el futuro. Los 6 bits se emplean como una tabla indexada para identificar el PHB, con lo que se pueden obtener hasta 64 cdigos independientes que se mapean en cada nodo para determinar qu tratamiento se va a aplicar. Dependiendo de este mapeo es posible tener mltiples cdigos que seleccionan el mismo comportamiento. Los primeros 3 bits de estos 6 forman el CSC (Class Selector Codepoint).
36
A continuacin se detallan los PHB definidos en Diff-Serv: Expedited Forwarding (EF): El PHB EF proporciona bajas prdidas, bajo jitter y un retardo bajo dentro de cada nodo. Para lograr este retardo se define que la tasa agregada de recepcin de datos mxima no debe ser mayor que la tasa de transmisin mnima disponible para este PHB. Con este requerimiento se asegura que no se completar la cola para este servicio dentro del nodo y que el retardo y la variacin del retardo sean mnimos. Los valores de DSCP recomendados para EF son 101110. Assured Forwarding (AF): El grupo de PHB define N clases independientes de encaminamiento (actualmente se encuentran definidas 4) denominadas AF1 hasta AFn. Dentro de cada una de las clases de encaminamiento aparecen M subclases (actualmente 3 definidas) que representan los niveles de la probabilidad de entrega. El nivel ms alto de probabilidad de entrega debe tener una probabilidad de entrega mayor que el segundo nivel para hacer frente a casos de congestin. Cada clase de encaminamiento dentro de este grupo se configura independientemente: espacio de buffer, capacidad de entrada mnima de los routers egress,... Los niveles de probabilidad de entrega se pueden ver tambin como niveles de probabilidad de eliminacin de paquetes (drop), como se observa en la figura siguiente perteneciente a la tecnologa Cisco. En situaciones especiales, como cuando el trfico excede el CIR configurado (en caso de estar configurado Frame Relay por debajo de MPLS por ejemplo) los nodos se basarn en estos niveles de prioridad de drop o de entrega para descartar o no los paquetes.
Figura 4.4. Definicin de grupos AF PHB. Default Behaviour (DE): El PHB DE identifica el trfico best effort existente. Este comportamiento define que el nodo entregar tantos paquetes best effort como sea posible, tan pronto como sea posible. Por supuesto, otros comportamientos definidos presentan mejores requerimientos en cuanto a la fiabilidad de entrega, con lo que las frases tantos paquetes como sea posible y tan pronto como sea posible estn supeditadas a los dems tipos de PHB.
37
Otros PHB: Las dems combinaciones de bits de Class Selector (CS) crean un conjunto de cdigos de comportamiento PHB, adems de los que ya se han comentado, para conseguir una compatibilidad hacia atrs con el byte TOS de IPv4 que se utiliza como byte DS. Estos tipos de PHB aseguran que los routers que implementen TOS proporcionarn un comportamiento compatible con los routers que implementen Diff-Serv con los mismos valores. Algunas otras combinaciones de los bits CSC todava no se han asignado a ningn PHB, a la espera de crear nuevos PHB en un futuro con restricciones de seguridad y probabilidades de entrega todava mayores. Otros se han establecido para usos locales al equipo o experimentales.
Figura 4.5. Correspondencia TOS de IP vs DSCP.
4.2 Condicionantes del trfico: El otro lado de Diff-Serv

Ya se ha visto que el DSCP identifica el comportamiento que se debe aplicar en cada nodo. En un dominio Diff-Serv, el DSCP debe establecerse en cada paquete para los nodos para determinar el comportamiento requerido. Por tanto, el nodo en extremo de entrada a la red Diff-Serv (Ingress) debe asegurarse de que este campo DSCP se ha establecido apropiadamente para cada paquete. El nodo debe decidir cmo los paquetes de los diferentes PHB tienen que ser encaminados fuera del enlace. Los mecanismos de planificacin pueden considerar rdenes de prioridad entre las clases, pero deben controlar el acceso al ancho de banda de cada enlace para cada clase. El trfico de las clases de mayor prioridad se enva antes que el de clases de menor prioridad, con lo que se podra correr el peligro de inanicin de las clases de menor prioridad, y que el trfico perteneciente a estas clases nunca se llegue a enviar, con lo que
38
es necesario aplicar un shapping (limitacin del ancho de banda utilizado) a los niveles de trfico. Se utilizan diversos mecanismos para obtener estas limitaciones. FIFO (First in First Out): Es el mecanismo ms sencillo de implementar. Sin embargo, en FIFO puede ocurrir que un paquete con prioridad alta se acumule detrs de miles de paquetes pertenecientes a trfico best-effort. RR (Fair Queing o Round Robin): Se trata de una planificacin sencilla round robin para colas mltiples. Esto hace que el ancho de banda disponible se reparta de manera justa entre las diferentes colas. Uno de los problemas de este tipo de mecanismos es que las rfagas de un gran nmero de paquetes requieren una comparticin muy grande del ancho de banda disponible. Weighted Round Robin (WRR): Con este mecanismo se consigue un acceso ponderado (weighted) al ancho de banda disponible para cada clase organizndose la distribucin de ancho de banda en round-robin. Weighted Fair Queing (WFQ): Ayuda de manera similar a WRR a distribuir el ancho de banda disponible sobre las clases definidas. Utiliza una combinacin de informacin de temporizacin y ponderacin para seleccionar a qu cola debe entregarle paquetes. La distribucin del ancho de banda est en todo momento controlada por el sistema de ponderacin, que tambin se encarga de en caso de necesidad hacer variar el retardo si hubiera clases infrautilizadas. Class Based Queing (CBQ): CBQ es un trmino general que se refiere a cualquier mecanismo basado en clases. CBQ puede permitir que la capacidad no utilizada se distribuya segn un algoritmo diferente al de menor peso de ancho de banda. Por ejemplo, podra haber un tipo de peso diferente que se configure para una capacidad mayor que la media, o puede depender de la carga de trfico en cada clase, o de la prioridad,... Las clases agrupan trfico con alguna caracterstica comn: interfaz de entrada o salida, lista de control de acceso, trfico en tiempo real, bits EXP MPLS, valor de precedencia IP o DSCP,...
Existen otras condiciones que se pueden aplicar al uso de los diferentes PHB. Por ejemplo, el PHB EF tiene un requerimiento en el que la capacidad de salida de un enlace para este comportamiento es mayor que la tasa de entrada. Ya que la definicin de un PHB puede especificar distintos perfiles de trfico, el nodo de entrada hacia el dominio Diff-Serv debe proporcionar ms funciones adems del simple marcado (marking) del byte DS. Estas condiciones o funciones adicionales se reflejan a continuacin.
4.2.1 Classifier
Los datos tienen que clasificarse para los PHB en la frontera del dominio Diff-Serv en relacin a una funcin de clasificacin. La clasificacin considera normalmente los campos de la cabecera IP, como protocolo, direcciones IP fuente y destino, puertos fuente y destino. El classifier aplica un filtro a cada paquete. Este filtro define las condiciones que la
39
cabecera debe cumplir para ser aceptada. Si el filtro acepta el trfico entonces el perfil asociado a ese filtro se aplica a ese trfico. Algunos ejemplos de filtros de clasificacin son: Trfico bsico entre dos nodos corporativos: La direccin destino est dentro del rango de la red corporativa mediante una mscara de red. Trfico de un servidor de correo: La direccin fuente ser la del host o el servidor. El protocolo utilizado es UDP.
4.2.2 Meter
Despus de que los datos han atravesado el mdulo classifier, pasan a travs de un mecanismo de metering que calcula el nivel de trfico y lo compara con el perfil de SLA del cliente. El perfil de trfico puede incluir aspectos tales como las tasas de datos medias acordadas con el cliente, la tasa de datos mxima y el tamao de la rfaga de datos mxima. El mdulo de metering aplica la poltica establecida a los niveles de trfico para cada clase de servicio y puede tomar parte y realizar modificaciones si el nivel excede los parmetros acordados.
4.2.3 Marker
Cuando los datos han sido clasificados y se ha determinado la tasa, el PHB seleccionado se marca en el byte DS. La razn por la que el PHB no se marca directamente desde el mdulo classifier es que el PHB no es independiente de la tasa de datos. En el caso de la tecnologa Cisco el proceso de marking se realiza asignando un nmero de bits variable segn el tipo de marking: Tipo de marking Precedencia IP DSCP MPLS EXP bits Ethernet QoS bits ATM CLP bit FR DE bit # de bits 3 6 3 3 1 1 Localizacin de los bits Los 3 bits ms significativos del byte TOS en las cabeceras Los 6 bits ms significativos del byte TOS en las cabeceras Parte de la etiqueta MPLS de 20 bits Cabecera 802.1 q/p Cabecera de celda ATM Cabecera FR
Figura 4.6. Tipos de marking en Cisco. Un ejemplo de configuracin sencilla de un router Cisco sera: Router(config)# policy-map access-in Router(config)# class Silver Router(config)# set ip dscp 26 Router(config)# exit 40
El valor de DSCP en el ejemplo sera 26. Silver es un tipo de clase en Cisco (se definen las clases Gold, Silver, Bronze,... segn el tipo de trfico). A continuacin se puede ver cmo se divide el trfico en clases y se trata en la frontera de los dominios Diff-Serv:
Figura 4.7. Diff-Serv en Cisco.
4.2.4 Shaper
Una vez que los datos han atravesado los mdulos meter y marker el router sabe si la tasa de datos est dentro del perfil de trfico permitido o si ste se ha superado. Si la tasa de datos est dentro del perfil los datos pueden enrutarse hacia el destino. Si por el contrario la tasa de datos excede el perfil se pueden tomar dos posibles acciones. La primera es limitar (shape) el trfico. Los datos se encaminan mediante los procesos normales de routing a una tasa definida por el perfil de trfico del cliente. Como esta tasa es menor que la tasa con la que se han recibido los datos, es necesario almacenar en un buffer este exceso de datos y enviarlo ms tarde cuando el perfil lo permita. En un router Cisco se configurara de la siguiente forma: Router(config)# policy-map access-out Router(config-pmap)# class Silver Router(config)# shape {average | peak} cir bc be Router(config)# exit 41
Esta configuracin correspondera a un enlace FR, en el que se ajustan los valores medios de los parmetros relativos a la conexin FR: Bc: Committ burst (rfaga acordada) Be: Excess burst (rfaga de exceso) shape peak limita la tasa al valor cir * (1+be/bc)
4.2.5 Dropper
La segunda accin a realizar en caso de excederse el perfil la lleva a cabo el mdulo dropper (descartador). En este caso, el exceso de datos simplemente se puede descartar. Esto ocurre cuando el buffer del mdulo shaper est lleno. En algunos casos el propio servicio no puede tolerar ningn exceso en la tasa de datos, con lo que podra suceder que prcticamente todo el trfico exceda el perfil con lo que se descartara, a no ser que los buffers fueran de gran tamao. Aunque esta accin pudiera parecer drstica, puede ser necesario para algunos tipos de PHB como por ejemplo EF, para el que se tienen requerimientos estrictos en los niveles de trfico. En las siguientes figuras se ve cmo se realiza el proceso de los diferentes mdulos:
Clasification/ Marking
Drop Policy
Scheduling Policy
Red de Conmutacin Cola de Recepcin Cola de Transmisin
Figura 4.8. Buffering entre los diferentes mdulos condicionantes del trfico en Diff-Serv.
42
Se aplica Diff-Serv Accesos de cliente
Edge Router Accesos de cliente
Core Routers
Core Router
Edge Router Edge Router
Pares de Red Se aplican condicionantes de trfico y Diff-Serv Entrada de datos Classifie Mete Marke Shape Droppe Salida de datos
Condicionantes de Trfico
Figura 4.9. Secuencia de aplicacin de los mdulos condicionantes del trfico en Diff-Serv.
4.3 IP Bearer Services

Dentro de cada nodo de la red de la figura anterior se puede definir lo que se conoce como IBS (IP Bearer Services), mediante la combinacin de los PHB con los condicionantes del trfico que se han visto. Se puede combinar el mismo PHB con parmetros diferentes con los condicionantes del trfico para obtener un servicio portador (bearer service) distinto con caractersticas diferentes. Adems de los diferentes condicionantes de trfico, los diferentes IBS tambin dependen la ingeniera que se aplique a cada servicio. Por ejemplo, incrementar la capacidad ofrecida a un IBS ms all de su nivel de trfico asignado puede proporcionar al servicio una latencia menor. Dependiendo de la capacidad de los buffers tambin se puede lograr una probabilidad de congestin menor. A continuacin se describe brevemente la evolucin de los mecanismos que se aplican para reducir la congestin. Los primeros mecanismos de congestin eran muy simples, se basaban en descartar los paquetes cuando los buffers alcanzaban un nivel umbral definido. Este sistema protega a los routers pero incrementaba la posibilidad de aparicin de un fenmeno no esperado conocido como sincronizacin global. Cuando los paquetes TCP se descartan, el algoritmo de planificacin de TCP responde disminuyendo su tasa de transmisin. Cuando los routers de core se sobrecargan, descartan paquetes procedentes de muchos hosts haciendo que se
43
cancelen muchas sesiones TCP y/o incrementando simultneamente las tasas de transmisin de otras con lo que se pueden producir patrones de dientes de sierra de infrautilizacin y congestin. Para incrementar la utilizacin media de los enlaces, se introdujo un mecanismo denominado RED (Random Early Detection) para evitar el efecto de sincronizacin indicado anteriormente. En vez de descartar todo el trfico cuando se supere el umbral, se pone en marcha un mecanismo que descarte de manera aleatoria los paquetes segn los buffers se van llenando, para conseguir una mayor proporcin en el nmero de sesiones TCP canceladas frente a las que se le aumenta la tasa de transmisin. Actualmente se han propuesto muchas variantes de RED, como por ejemplo Weighted RED (WRED), Fair RED (FRED), RED with In-Out (RIO) y RED adaptativo. No est excesivamente claro cul de estas variantes proporcionar los mejores resultados a un backbone determinado pero s est claro que un backbone debe poseer alguno de estos mecanismos para proporcionar una diferenciacin de clases respecto a la posibilidad de descarte de los paquetes. La combinacin de estos mecanismos de congestin con los PHB facilitan que el proveedor de la red pueda establecer diferentes niveles de servicio y por tanto proporcionar a los clientes diferentes SLA y con ello diferentes IBS. Los IBS ms comunes que se crean son ELL (Emulated Leased Line), EVLL (Emulated Virtual Leased Line), BBE (Better than Best Effort), BE (Best Effort) y otros servicios.
4.3.1 ELL (Emulated Leased Line)

El principal objetivo de este servicio es proporcionar un enlace equivalente a una lnea alquilada en un entorno VPN o en cualquier otro entorno con requerimientos estrictos de QoS como throughput, retardo o jitter como por ejemplo los enlaces de Voz sobre IP (VoIP) entre los diferentes GateWays deVoz (VoGW). El servicio ELL proporciona garantas cuantitativas de retardo y congestin y utiliza el PHB EF.
4.3.2 EVLL (Emulated Virtual Leased Line)

El objetivo de este servicio es similar al del servicio ELL pero con requerimientos de retardo, prdida de paquetes y jitter ms permisivos. Este servicio se puede utilizar por ejemplo en cadenas de trfico pertenecientes a aplicaciones en tiempo real interactivas. Este servicio utiliza un PHB AF y los condicionantes de trfico se definen punto a punto como en el servicio ELL. EVLL permite trfico de datos a rfagas bajo un modelo similar al token bucket, y se permite el exceso de datos. Sin embargo elimina los paquetes en caso de congestin.
44
4.3.3 BBE (Better than Best Effort)

Este servicio crea una o ms clases de servicios a las que se le da un trato preferencial comparado con el servicio bsico best effort. A cada clase se le asigna parte de los recursos de red y se proporciona un mejor servicio que en el caso del trfico Best Effort (retardo ms bajo, tasa de descarte menor). BBE tpicamente utiliza uno o ms PHB del grupo de AF. Los condicionantes de trfico permiten un perfil a rfagas para el usuario y tambin el exceso de datos, pero al trfico se le aplica una gran probabilidad de descarte.
4.3.4 BE(Best Effort)

Este es el servicio tradicional que se ofrece en las redes IP actualmente. No hay garantas en los parmetros (retardo, throughput,...) y los datos hacia cualquier destino se envan de la mejor manera que la red pueda hacerlo. Este servicio utiliza tpicamente el PHB DE y los condicionantes de trfico son similares a los de BBE.
4.3.5 Otros servicios

Los operadores de red pueden crear otras clases de servicio para una aplicacin especfica que deseen proporcionar y que requiera condiciones ms rigurosas. Por ejemplo, una aplicacin de voz tiene unos requerimientos de retardo y jitter muy rigurosos, por lo que el operador de la red puede crear un servicio nuevo llamado por ejemplo voz. Este servicio podr tener restricciones similares al servicio ELL, pero el operador de red puede diferenciarlos basndose en otras caractersticas como la garanta de fallo de la red. Adems hay que tener en cuenta en Diff-Serv ciertos aspectos: Ser necesario establecer estos mecanismos en ambos extremos de la sesin y marcar tambin los paquetes que se envan de vuelta con la misma clase de servicio que tengan los paquetes que se han enviado anteriormente. A los paquetes de asentimiento del protocolo TCP obviamente tambin se les debe aplicar los mismos mecanismos de congestin, planificacin,... ya que no servira de nada aplicar una determinada clase de servicio a un tipo de trfico IP mientras que el trfico a nivel superior (por ejemplo los asentimientos TCP) sufre los retardos. Hasta ahora slo se han considerado los condicionantes de trfico en el router ingress (ver figura 4.7), pero estos condicionantes son tan importantes en los routers ingress como en los routers receptores (egress). En casos de enlaces de baja velocidad como accesos mviles o en enlaces de alta utilizacin el control puede proporcionarse por el receptor de los datos, que podra rebajar la rigurosidad de los condicionantes del router ingress para evitar por ejemplo ataques perniciosos como intentos de flooding del enlace,... Esto quiere decir que los clientes pueden aplicar
45
filtros en la red para decidir cules de los paquetes que le llegan son ms crticos y no descartarlos en caso de principio de congestin. En caso de que el trfico atraviese distintos dominios (dos sistemas autnomos diferentes) puede ser necesario volver a aplicar el mdulo de marker en la frontera de un dominio para decidir cul va a ser el PHB para el siguiente dominio.
4.4 MPLS QoS

MPLS puede combinar las tcnicas de Diff-Serv con los mecanismos de ingeniera de trfico que aparecen en el captulo de MPLS Traffic Engineering para ofrecer una determinada QoS. MPLS crea rutas dirigidas a travs de una red IP. Estas rutas (los LSP) permiten que el trfico IP entre dos nodos se enrute slo en el router de entrada (ingress) del dominio MPLS. Cada LSP que se crea a travs de la red se establece por sealizacin. Esta sealizacin transporta la informacin sobre las caractersticas requeridas para cada LSP, que pueden ser: Ancho de banda: Tasas de datos sostenidas, pico y tamao mximo de las rfagas. Retardo y variacin del retardo. Seleccin de ruta.
Los LSP que transportan la informacin de ancho de banda, retardo, seleccin de ruta, etc, se denominan de sealizacin, y son independientes de los que se crean para transportar servicios de clientes. Dentro de un dominio MPLS se pueden crear mltiples LSP entre dos nodos. Un motivo para tener varios LSP entre dos nodos es proporcionar algunas de las funcionalidades del traffic engineering al enlace, para obtener redundancia y distribucin de carga con otros enlaces. Por ejemplo, se puede crear un LSP para proporcionar un servicio de lnea alquilada que soportar el trfico utilizando un PHB EF, mientras que se puede crear otro LSP para tener una subclase dentro del servicio BBE que pueda llevar un tipo de trfico acorde con el PHB AF. El router ingress va a controlar a qu tipo de trfico se le permite utilizar cada LSP. En el caso de un router de acceso a un sistema autnomo, el trfico perteneciente a un tipo de PHB de alta prioridad ser el nico que atraviese este router. Este control se va a realizar de manera idntica al funcionamiento de Diff-Serv. En el caso de Cisco se deben seguir los siguientes pasos para establecer un mapa de clases segn el tipo de trfico:
46
1. Crear una Class Map. Router(config)# Class-map [match-any | match-all] class-name Una class map es una clase de trfico que se crea en relacin a un parmetro determinado (lista de acceso, el interfaz de entrada, el byte DSCP, el bit EXP de la etiqueta MPLS,...). Por ejemplo: Router(config)# class-map class1 Router(config-cmap)# match ip precedence 5 Router(config-cmap)# exit 2. Crear una Policy Map Router(config)# policy-map policy-map-name Asociar una class map con una o ms polticas de QoS (en funcin de BW, lmite de colas, deteccin aleatoria, etc. como ya se ha visto). En el ejemplo se establecen valores del bit EXP (5), del lmite de cola (30) y del ancho de banda (3000). Por ejemplo: Router(config)# policy-map policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# set mpls experimental 5 Router(config-pmap-c)# bandwidth 3000 Router(config-pmap-c)# queue-limit 30 Router(config-pmap)# exit 3. Adjuntar una Poltica de Servicio Router(config)#Service-policy {input | output} policy-map-name Por ejemplo: Router(config)# interface e1/1 Router(config-if)# service-policy output policy1 Router(config-if)# exit Asocia las polticas de servicio con un interfaz de entrada o de salida. En el ejemplo, es el interfaz Ethernet 1. Por ltimo, se va a analizar la relacin entre las clases que pueden definirse en MPLS y el modelo de calidad de servicio que presentan las redes ATM tradicionales. Ya se ha visto que por debajo de MPLS pueden existir tecnologas ATM o FR.
47
Los LSP de MPLS son similares a las conexiones que se establecen en los entornos ATM mediante la configuracin de los valores VPI y VCI relativos a las rutas virtuales y a los circuitos virtuales que se establezcan para conexin. En ATM cada conexin se caracteriza por estos valores y por los parmetros de conexin tales como la tasa de celdas pico, el tamao mximo de las rfagas o el retardo. El tratamiento de asignacin de clases o prioridades se realiza para cada ruta o conexin individual. En MPLS sobre ATM sin embargo no es factible determinar los parmetros de calidad de servicio para cada ruta individual ya que es muy variable a lo largo del tiempo dependiendo de la naturaleza del trfico. Por tanto la planificacin se aplica a un conjunto agregado de conexiones que comparten la misma clase de servicio de acuerdo a algn tipo de algoritmo de ponderacin como WFQ. Esta capacidad de ponderacin es la clave para obtener un buen soporte de MPLS sobre ATM y es incluso ms importante cuando el nodo en cuestin soporta aplicaciones tanto MPLS como ATM al mismo tiempo sobre un solo enlace. Tanto los servicios MPLS como los ATM deben alcanzar sus requerimientos sin interferir mutuamente. Esta capacidad se conoce como Ships In the Night (SIN). El parmetro que se ha propuesto recientemente para este tipo de redes es el PFC (Per Hop Behaviour Forwarding Class). Este parmetro se utiliza para especificar una clase de comportamiento para el encaminamiento salto a salto, y es un concepto anlogo a los PHB que soporta un router con funcionalidad Diff-Serv. Puede haber mltiples LSP establecidos entre dos nodos para soportar varias clases de servicio cada uno o bien mantener un LSP por separado para cada clase de servicio. Tambin se puede utilizar un LSP para un grupo de servicios como por ejemplo el conjunto de las clases AF1. En este caso las subclases para las diferentes probabilidades de servicio se mapean en el LSP utilizando el bit CLP de la cabecera ATM (bit de prioridad). Aunque este bit slo proporciona dos clases de servicio existe una propuesta de draft para estandarizar el mapeo de las subclases de descarte en el bit CLP. En el caso de que el nodo ejecute la capacidad SIN para combinar trfico ATM y MPLS hay que tener en cuenta la relacin entre las categoras de servicio ATM y las clases de servicio MPLS. No es necesario establecer siempre un mapeo directo entre cada columna de esta tabla pero s en el caso de algunas aplicaciones: Ejemplos de Mapeo entre servicios Categora de servicio ATM Diff-Serv PHB CBR EF rt-VBR AF prioridad 1 nrt-VBR AF prioridad 2, CS AF prioridad 3 ABR, GFR, UBR, W-UBR AF prioridad 4 Figura 4.10. Correspondencia ATM MPLS QoS .
48
Aunque el hecho de tener que aplicar el tratamiento de calidades de servicio a un conjunto agregado de conexiones pueda parecer un inconveniente en realidad MPLS puede ofrecer ventajas sobre ATM incluso en redes de pequeo tamao, ya que MPLS puede proporcionar un mejor agrupamiento de clases de servicio mediante Diff-Serv que empleando las categoras de servicio ATM. Adems la naturaleza dinmica del trfico IP hace ms apropiada la asignacin de la capacidad entre los nodos que las conexiones ATM requieren. El acceso compartido al ancho de banda que se realiza con MPLS (ver figura 4.11) proporciona una configuracin de red ms efectiva.
MPLS permite agrupar conexiones para compartir un ancho de banda determinado En ATM todas las conexiones se caracterizan individualmente
Figura 4.11. Agregacin de conexiones en MPLS
49
Captulo 5: MPLS Traffic Engineering
5. MPLS TRAFFIC ENGINEERING

Uno de los aspectos ms interesantes que ofrece MPLS es la posibilidad de establecer tneles en los que se realiza ingeniera de trfico; es decir, definir rutas alternativas por las que poder encaminar un tipo de trfico determinado para dotarle de menor retardo aunque la ruta alternativa tenga un mayor nmero de saltos. Dos aproximaciones, TE-RSVP y CR-LDP, estn siendo actualmente desarrolladas por el grupo de trabajo IETF-MPLS, este grupo es el que clasifica las clases de Traffic Engineering dentro del estndar MPLS. Hay dos formas de implementar un LSP en una red MPLS: Control-Driven (Hop-by-Hop) usando LDP y mediante encaminamiento explicito LSP (ER-LSP, Explicit-Routed LSP). Tanto TE-RSVP como CR-LDP representan estas aproximaciones. Estos dos modelos proporcionan mejoras y capacidades que pueden ser usadas por los ingenieros que operan y mantienen una red MPLS para poder elegir, crear, disear diferentes rutas para diferentes QoS del trfico que circula por sus redes, en funcin tambin de los parmetros de QoS, de esta forma se puede asegurar que el LSP optimo para un tipo de trafico determinado ser el mas idneo. Adems esta flexibilidad permite la definicin de ER-LSP de dos formas diferentes pero que en el fondo tienen la misma funcionalidad, es decir, una definicin estricta del concepto ER-LSP y una definicin ms liberal del concepto ER-LSP. En el caso estricto de ER-LSP proporciona una ruta que tendr que seguir el trafico de forma fija, es decir, atravesando un grupo de nodos (siempre por las interfaces que tengan definidas para componer esta ruta) fijos siempre. Mientras que en el otro caso el escenario es mas adaptable a cada situacin y permite definir grupos de nodos, especificados con un numero de sistema autnomo, y actan como un todo por el que puede circular el trfico, siempre respetando el concepto de rutas en Traffic Engineering.
5.1 TE-RSVP
TE-MPLS, es una extensin de TE-RSVP ya existente (RFC2205). Usando TE-RSVP no es necesario que exista una implementacin total de RSVP en los componentes de la nube MPLS (LER, LSR). Un LER o un LSR solo requieren las extensiones de RSVP que se soportan en las redes MPLS para encaminamiento explicito. TE-RSVP es un protocolo que no es orientado a la conexin (UDP) y usa datagramas IP como mecanismo de sealizacin para establecer los LSP, incluyendo descubrimiento de adyacencias, peticin de etiquetas, y mapeo y gestin, como se puede ver en la figura siguiente:
50
Figura 5.1. TE-RSVP En este ejemplo, habiendo usado BGP para descubrir el LER apropiado para sacar el trfico MPLS, es decir, el LER de salida del LSP, hacia otro sistema autnomo o directamente hacia el destino, el Ingress LER enva un mensaje RSVP PATH hacia el LER de salida o Egress LER, pasando por todos los LSR a lo largo del LSP. En cada nodo que recibe el mensaje PATH se creara, si es posible, el camino que seguir el trafico por ese tnel, se va creando nodo a nodo, se van reservando los recursos necesarios. Cuando el mensaje PATH llega al Egress LER, este responde con el mensaje RESV, para reservar los recursos con la QoS necesaria en cada uno de los enlaces que forman el LSP. Una vez que el Ingress LER ha recibido el mensaje RESV este enva un mensaje de confirmacin: RESVConf hacia el Egress LER confirmando que se ha llevado a cabo la configuracin del LSP. Una vez que el ER-LSP ha sido establecido se mandan peridicamente mensajes de mantenimiento entre los LERs y LSR para mantener el LSP y los parmetros con los que se reservo. Hay que indicar que ninguno de los mensajes de mantenimiento entre los LER y los LSR en ningn sentido (cabecera-salida, salida-cabecera) es fiable ya que UDP o los datagramas IP que se utilizan para el mantenimiento del path no lo son tampoco. TE-RSVP esta compuesto por un conjunto de caractersticas robusto y que proporcionan importantes capacidades para proporcionar servicios de ingeniera de trafico para MPLS. Parmetros de Trafico y QoS Notificacin ante fallos, durante el establecimiento de un LSP o en un LSP ya existente, enviaran un mensaje de fallo, existirn una serie de contadores que harn fiable el mtodo de deteccin de fallos. Recuperacin ante fallos, es lo que se denomina make before break, y re-enrutara el trfico que debiera circular por el enlace que tiene problemas haca en enlace designado como backup. Deteccin de bucles, detecta posibles inconsistencias en los LSP debido a otros fallos en los enlaces que lo componen, o a una mala configuracin de los mismos. Gestin, LSP ID identifica a cada LSP, por lo tanto permite la fcil gestin de LSP de forma individualizada. 51
5.2 CR-LDP
CR-LDP se implementa por encima de LDP, que a su vez forma parte de MPLS. Aunque no es tan maduro como RSVP, no requiere la implementacin de un protocolo adicional. Usa estructuras de mensajes ya existentes y solo utiliza extensiones de estos cuando es necesario para implementar servicios de ingeniera de trafico. Como con TE-RSVP, CR-LDP soporta la deteccin de fallos en un enlace LSP. UDP se usa para descubrir vecinos MPLS en la red, y TCP es usado para el plano de control, gestin, peticiones de etiquetas, etc
Figura 5.2. CR-LDP En la figura anterior puede verse como se ha establecido un CR-LDP LSP entre los LERs cabecera y de salida. El path ha sido predeterminado por ambos LERs y es limitado para dos LSR especficos en este caso. La peticin de etiquetas ha sido enviada a cada dispositivo que forma el path, salto a salto, en direccin LER cabecera LER de salida. Y la asignacin de etiquetas, o mapeo de etiquetas se produce de la misma manera pero en sentido contrario, LER de salida LER cabecera. Como se puede apreciar en la figura anterior, la ruta que se ha utilizado para el establecimiento del path debe de ser pactada por el LER cabecera y los LSR, utilizando las direcciones IP. Las extensiones de ingeniera de trfico con CR-LDP para el conjunto de funcionalidades de LDP estn muy bien definidas: Parmetros de trfico y QoS: Estos ofrecen la capacidad de definir las reglas y el comportamiento en cada salto basadas en los tipos de datos, ancho de banda por enlace y el peso dado a cada uno de estos parmetros. Path Preemption: es la capacidad de configurar la prioridad para permitir o no la reserva de recursos por parte de otro LSP. Path Reoptimization: Ofrece la capacidad de recuperacin ante fallos en los enlaces LSP, basado en patrones de trfico cambiante. Se mapean polticas de recuperacin ante fallos en cada dispositivo que soporta un LSP. 52
Notificacin ante fallos: Cuando se produce un fallo en el establecimiento de un LSP, se notifica mediante TCP con cdigos de notificacin de fallos. Deteccin de bucles. Soporte Multiprotocolo: soporta cualquier tipo de protocolo. Gestin: El LSP ID identifica cada LSP, por lo tanto es fcil gestionar LSP de forma individual.
5.3 Discusin tcnica de las iniciativas de ingeniera de trfico en MPLS

5.3.1 Conmutacin de etiquetas:
Una sesin o flujo de datos se define como una serie de datagramas IP que comparten un destino IP comn y unas caractersticas de ingeniera de trfico comunes. CR-LDP y TERSVP proporcionan un mecanismo para traducir estas sesiones a LSP que viajan a travs de la red. En el router de entrada o LSR Cabecera se asigna una etiqueta a cada datagrama IP, la que corresponda por LSP y que se transmitir hasta el destino. De esta forma en cada salto a lo largo de todo el LSP, la etiqueta se usara para remitir el paquete a su prximo salto. CR-LDP y TE-RSVP crean LSP enviando primero la peticin de asignacin de etiquetas a lo largo de toda la red hasta el punto de salida o LSR de salida, salto por salto. En cada salto, MPLS usa la etiqueta y la informacin de la cabecera IP correspondiente para programar el hardware ( firmware) para cambiar la entrada en sus tablas de forwarding a su prximo salto. Mientras que los algoritmos reales pueden ser diferentes, el resultado final de ambos protocolos de sealizacin es establecer una conexin extremo a extremo entre las interfaces de entrada y salida de la nube MPLS.
5.3.2 Escalabilidad (Protocolos Hard-State vs Soft-State):

En la actualidad, los routers deben recibir y deben procesar grandes cantidades de trfico. Para lograr esto y que no se produzcan cuellos de botella, tienen que emplear muy poco tiempo en procesar los datagramas IP. Como se ha comentado anteriormente, la conmutacin de etiquetas disminuye el tiempo necesario para analizar cada datagrama IP ya que solo comprueba por que interfaz ha llegado y por cual lo tiene que sacar y si es necesario o no cambiar la etiqueta. Hay que tener en cuenta que es necesario, por parte de los routers, algn tiempo para crear, mantener y eliminar la informacin necesaria para establecer los LSP. Sin embargo, este coste es mnimo comparado con el tiempo empleado en el procesamiento de las cabeceras IP en las redes IP.
53
En la jerga de redes de datos, un LSP basado en CR-LDP se denomina protocolo HardState. Esto significa que toda la informacin, es intercambiada en el momento de la negociacin inicial, y que una vez establecido el LSP no se intercambia ninguna informacin adicional entre los routers que intervienen en el establecimiento del LSP hasta que este se elimina. Cuando el sistema de gestin de red o el operador de la misma determine que el LSP ya no se necesita, deben intercambiarse mensajes de gestin de red notificando a todos los routers que los recursos deben ser liberados. Este proceso de la liberacin de recursos es poco frecuente y utiliza muy poco ancho de banda y recursos de la CPU del routers. Recprocamente, TE-RSVP se denomina protocolo Soft-State. Despus del proceso de negociacin del establecimiento de un LSP y que es similar a CR-LDP, se deben estar intercambiando mensajes de gestin peridicamente entre los pares para mantener el LSP activo y de esta forma tener reservados los recursos necesarios de forma permanente. Si no fuese as, un timer de mantenimiento se da cuenta de que la conexin esta inactiva y libera todos los recursos que se estuviesen utilizando para ese LSP, notificando esta situacin a todos los routers que forman parte de esa conexin. El Soft-State puede verse como un protocolo autolimpiable porque con el tiempo todos los recursos sern liberados tarde o temprano. Como con CR-LDP, RSVP normalmente libera recursos de un LSP que ya no se va a utilizar o que el gestor de red decide que no quiere tenerlo activo o simplemente que el sistema de gestin de la red detecta que ese LSP ya no se desea tener activo. Los que se oponen a RSVP defienden que un protocolo Soft-State en el que es necesario intercambiar mensajes de gestin para tener establecido un enlace no es escalable. De hecho la RFC-2208 dice lo siguiente: Los recursos necesarios para que un router trabaje con RSVP aumentan de forma proporcional al numero de sesiones RSVP que ese router este gestionando, lo cual supone un incremento del ancho de banda necesario para mantenerlos as como mas uso de recursos de CPU del router, por lo que puede no ser aconsejable en ciertos escenarios de red, Derivando por lo tanto en la conclusin de que RSVP no es escalable. El IETF ha publicado extensiones a RSVP que combinan informacin de sumarizacin para nuevos objetos RSVP que se envan dentro de los mensajes estndar de RSVP, lo cual hace que se usen menos recursos de red y de CPU. Para reducir el volumen de intercambio de informacin entre dos nodos, un nodo de RSVP puede agrupar el nmero de mensajes de mantenimiento del RSVP en un solo mensaje. Este mensaje se enva al router del otro extremo del enlace donde lo desensamblara y procesara cada mensaje RSVP por separado. Este proceso se denomina Bundling o Atar. Adems de atar los mensajes, se han agregado dos nuevos mensajes al protocolo, estos nuevos mensajes son: MESSAGE_ID y MESSAGE_ID_ACK. Estos mensajes se usan para mantener la secuencia numrica correspondiente al intercambio de mensajes de mantenimiento del enlace. Mientras el
54
router del otro extremo del enlace reciba un mensaje MESSAGE_ID igual que el anterior, asume que el estado del enlace es idntico que cuando se recibi el ltimo mensaje. Slo cuando el MESSAGE_ID cambie con respecto al ltimo mensaje recibido deber comprobar la informacin incluida en el mensaje y actuar en consecuencia. Esta estrategia diminuye substancialmente el tiempo necesario para el intercambio de informacin entre los routers extremo a extremo en el enlace, sin embargo no elimina ni mejora el tiempo de uso de CPU para generar y procesar los mensajes de gestin del estado del enlace. Es decir, aun se tendr que tener en cuenta el tiempo que se necesita para comprobar los contadores y chequear el estado de cada sesin RSVP. De esta forma se ha conseguido acallar las crticas que rodean la escalabilidad de RSVP pero no se ha resuelto completamente el problema. CR-LDP parece tener ventaja por lo escalable de su naturaleza, recordar que es un protocolo Hard-State, CR-LDP se basa en el concepto de una entidad LDP. Una vez que dos routers que hablen LDP se descubran uno a otro, se establecer una sesin TCP/IP entre ellos. De esta forma, todos los mensajes del plano de control usados para el establecimiento y mantenimiento de LSP, deben viajar a travs de esta conexin TCP/IP segura. Como actualmente se describe en la especificacin de MPLS, se requiere que todos los LSP asociados a una sesin TCP/IP deben liberarse cuando la sesin TCP/IP se libera, bloquea o falla. En el caso de que cientos o quizs miles de LSP hayan sido establecidos previamente entre dos LSR, el impacto sobre la red puede ser sustancialmente importante. Los miembros del IETF estn trabajando en soluciones para enmendar este problema.
5.3.3 Seguridad y fiabilidad:

Uno de los beneficios de la arquitectura de MPLS es la separacin de las decisiones de la asignacin de ruta y envo de los datos. Una vez el enlace se ha establecido entre dos LSR y los datos se estn enviando (o conmutando) a travs de los dispositivos hardware de la red, las tramas de informacin no se comprueban en los niveles superiores ya que solo se comprueba la etiqueta MPLS asignada a los paquetes IP. Hay una mnima posibilidad de que los intrusos puedan interceptar, rastrear, intervenir o redireccionar informacin. En MPLS a los datos solo se les permite entrar y salir de un LSP desde y hacia lugares autorizados y que han sido configurados desde el plano de control de MPLS. Esto minimiza la posibilidad de ciertos tipos de spoofing o flooding que son los tipos de ataques ms comunes en las redes de datos IP o No-MPLS. Adems, CR-LDP usa una conexin TCP/IP, ofreciendo por lo tanto una conexin fiable y ms segura as entre los pares. LDP y la especificacin TE-RSVP tambin soportan el uso de una firma contrasea MD5 que asegura an mas la sesin TCP/IP.
55
Las conexiones TCP/IP tambin ofrecen la notificacin de error oportuna si hay un fallo de comunicacin entre los pares. Esta notificacin puede ser rpidamente reportada al sistema de gestin de red para que se pongan en marcha las acciones apropiadas. Cuando un router MPLS se da cuenta de que se ha producido un fallo en la conexin TCP/IP, puede iniciar el proceso de desactivacin del LDP y el envo de mensajes a sus pares notificndoles esta situacin para que se pongan en marcha las acciones de recuperacin de la conexin. Sin embargo, RSVP, usa UDP y datagramas IP para comunicarse entre pares. Esto conlleva a tener dos preocupaciones respecto a la fiabilidad: la vulnerabilidad de la seguridad frente a los ataques y el no tener un sistema de recuperacin ante fallos rpido. IPSEC y otros sistemas de encriptacin o autenticacin pueden usarse para garantizar un enlace RSVP vlido y mensajes de RESV, sin embargo, podran producirse ataques de spoofing que podran afectar al rendimiento de TE-RSVP. Adems el fallo de una conexin solo se descubrir despus de que un vecino de TE-RSVP no reciba un mensaje de mantenimiento del enlace de uno de sus pares. Dependiendo de cmo se hayan configurado los timers que regulan el envo de estos mensajes, podra tardar segundos o incluso minutos en darse cuenta de que ha habido un fallo con uno de los enlaces RSVP con alguno de sus pares y as poner en marcha los mecanismos de recuperacin ante fallos para recuperar el LSP afectado.
5.4 Diferencias entre CR-LDP y TE-RSVP

Existen pequeas diferencias entre CR-LDP y TE-RSVP. A continuacin se enumeran para intentar determinar cual es el mejor protocolo de sealizacin para MPLS. Cuando un router que habla LDP descubre algn par, se establece una sesin TCP/IP, para un intercambio de informacin de sealizacin fiable. Cada par de routers establecen que tipo y rango de etiquetas usaran para cada LSP que se establezca, y la sesin LDP escoge la etiqueta a usar en cada caso para los datagramas IP que van a circular por el. Si no se pudiesen asignar ningn rango de etiquetas por le motivo que fuese, la sesin LDP se liberara. Con RSVP no hay negociacin del rango de etiquetas, este debe ser configurado por el gestor de la red. Si la red es muy grande o contiene un gran numero de interfaces de distintos tipos, el esfuerzo para configurar las etiquetas seria considerable. CR-LDP puede especificar el origen de una ruta para un LSP incluyendo una ruta explcita TLV en el mensaje de peticin de etiqueta. TE-RSVP tambin tiene la habilidad de proporcionar la misma informacin de la asignacin de ruta mediante la peticin de una ruta explcita. Los dos soportan el concepto de rutas libres, es decir, son rutas que pueden atravesar una red dada donde cualquier router de la misma puede hacer funciones de router de transito para establecer una ruta extremo a extremo entre dos pares. TE-RSVP y CR-LDP notificaran al LSR de entrada o cabecera el xito o el fracaso en el establecimiento de un LSP. CR-LDP y TE-RSVP permiten fijar una ruta concreta. Es decir, es la posibilidad de obligar a un LSP a ser la ruta fija para una serie de paquetes, segn los intereses del gestor de la red de que cierto tipo de trfico siempre siga el mismo trayecto extremo a extremo. En CR-LDP esto se tiene que llevar a cabo en el momento de la
56
negociacin del establecimiento del LSP, pero en el caso de RSVP puede ser en cualquier momento. RSVP puede usar el objeto de grabar una ruta, es decir, mostrar cual es el camino que seguirn los paquetes que circulen por un LSP, esta funcionalidad puede usarse para conocer la lista de nodos que han sido involucrados en la negociacin del establecimiento del LSP extremo a extremo. Esto puede ayudar al administrador de la red a recoger la informacin sobre el estado de la red y a solucionar problemas en la misma. CR-LDP no tiene ninguna manera de mostrar la ruta seguida por un paquete en un LSP establecido. Vea las tablas siguientes para ver las similitudes y las diferencias entre TE-RSVP y CRLDP.
Caractersticas
initiate setup
CR-LDP
label request message
TE-RSVP
PATH message Containing LABEL_REQUEST Object.
Comentarios
setup accomplished
mapping message
RESV message
differentiated services defined
DIFF-SERV_PSC TLV
DIFFSERV_PSC object
Both contain the DiffServ code point or DSCP information and are included in the setup request message.
support for tomultipoint LSP
point-
No
This is carried in EXPLICIT_ROUTE list TLV.
No
This is yet to be defined by the IETF.
source route capability
This is carried in EXPLICIT_ROUTE object.
Specify route used to set up switched path.
Figura 5.3. Similitudes entre CR-LDP y TE-RSVP.
57
Caractersticas
development stage
CR-LDP
new
TE-RSVP
old with extensions being added, support for legacy networks
Comentarios
RSVP objects being modified to be used in a MPLS environment
signaling transport
UDP for discovery, TCP for sessions
raw IP datagrams UDP encapsulation for message exchange
nondeterministic failure detection with RSVP; TCP failure can have catastrophic impact on LSP with CRLDP
connection state
hard state
soft state
soft state said to be nonscalable; RSVP to support aggregation of refreshes (also known as refresh reduction)
reliability
failure produces proactive signaling action
dependent on softstate timer response to detect failure
nondeterministic failure detection with RSVP
manageability
LSR, LDP, TE MIBs
modified RSVP and LSR MIBs
extensibility
vendor-specific, opaque, and experimental TLVs
experimental objects
very similar in function
scalability
hard-state connections reduce session signaling overhead
requires refresh reduction, aggregation to minimize soft state overhead
interoperability
well-defined support for most transports: ATM, frame relay, Ethernet
tunneling through ATM network must be manually configured
Figura 5.4. Diferencias entre CR-LDP y TE-RSVP.
58
5.5 Conclusiones a las similitudes y las diferencias.

MPLS se dise para dirigirse hacia las necesidades orientadas a la conexin de la nueva Internet. Se esta adaptando y evolucionando hacia las nuevas tecnologas, as como IP he estado evolucionando durante los ltimos 30 aos. Como con todos los nuevos protocolos, hay aun mucho trabajo que llevar a cabo. La necesidad de apoyar las rutas de ingeniera de trfico en Internet han requerido las nuevas extensiones de los protocolos IGP tradicionales y de los protocolos EGP como OSPF y BGP. Los continuos avances basados en tecnologas de fibra ptica estn requiriendo ms modificaciones de MPLS en las reas de encaminamiento y sealizacin de MPLS sobre fibra ptica. CR-LDP y TE-RSVP mantienen la funcionalidad de ingeniera de trfico de forma muy similar, as como en el establecimiento de los LSP. Cada uno tiene sus ventajas y sus desventajas. Mientras LDP es el ms joven de los dos protocolos, RSVP ha sido previamente desarrollado y utilizado y tiene a su favor esa veterana. Tambin es cierto que se han ido desarrollando mejoras en las funcionalidades del protocolo RSVP para soportar las necesidades que iban surgiendo con el uso de MPLS. A medida que CR-LDP y TERSVP evolucionan ofrecen funcionalidades cada vez ms similares. En un futuro, la ingeniera de trfico sobre MPLS debe ir evolucionando en una nica entidad que englobe lo mejor de ambos protocolos (CR-LDP y TE-RSVP). Mientras tanto, cualquier implementacin por parte de los distintos fabricantes de dispositivos que soporten MPLS deben soportar las funcionalidades de LER o LSR y a su vez deben soportar ambos protocolos para la implementacin de ingeniera de trfico, es decir, deben soportar tanto CR-LDP como TE-RSVP asegurando la compatibilidad entre equipos de distintos fabricantes.
5.6 MPLS TE Conceptos

MPLS traffic engineering ofrece una aproximacin al modelo definido como ingeniera de trfico a nivel 3 en el modelo de referencia OSI (Open System Interconnection): Routing especial para el trfico IP, si se desea. Comprobacin automtica del BW (Autobandwith en Cisco MPLS por ejemplo). Capacidad del backbone vs Requerimientos del trfico. Utilizacin optimizada de la topologa del backbone. Ofrece mecanismos de recuperacin frente a fallos de enlaces o nodos (FastReroute en Cisco MPLS).
El Traffic Engineering ofrece establecer un routing especial para el trfico IP del que marca el protocolo de routing interno (Por ejemplo OSPF) que se est ejecutando. Optimiza el trfico por otras rutas que no coinciden con la que el OSPF ha elegido como ptima. El Traffic Engineering tiene que permitir como mnimo comprobar los anchos de banda de forma automtica para ver si son capaces de soportar trfico de mayor capacidad. 59
Permite que el administrador de red decida qu tipo de trfico va a discurrir por cada enlace. Debern existir tambin mecanismos de recuperacin frente a fallos. El establecimiento de estos tneles depender en gran medida de la tecnologa que se este utilizando. Se podrn establecer en el equipo inicial, final, en los equipos intermedios,... En este captulo se explicara cmo se establecen estos tneles empleando la tecnologa de Cisco Systems ya que de este fabricante son los medios que de los que se dispone en la escuela a nuestro alcance para poder realizar suposiciones prcticas de configuracin y operacin. En Cisco, el tnel se va a tener que configurar en el primer equipo en el sentido del envo del trfico. A este equipo se le conocer como cabecera del tnel, y va a ser el encargado de decidir qu tipo de trfico enrutar por cada enlace y cmo gestionar el tnel. Es el equipo que tendr que solicitar el establecimiento del LSP, la posterior optimizacin de los tneles LSP y deber notificar al protocolo de routing interno si el tnel est up o down. Para el establecimiento de estos tneles se utilizar el protocolo RSVP al que se le aaden diversas extensiones. RSVP es un protocolo de sealizacin que se utiliza en las comunicaciones de voz para ir nodo a nodo reservando recursos. Simplemente se han aadido extensiones para colorear los enlaces, es decir, aplicar un tratamiento diferente a cada enlace para decidir si el trfico discurre o no por l en un determinado momento. El router cabecera inicia mediante un mensaje path la solicitud de reserva de recursos y los nodos de la red le respondern mediante mensajes reservation con etiquetas indicndole el ancho de banda que le ofrecen o bien el rechazo a la solicitud de reserva. El flujo de trfico es unidireccional.
Figura 5.5. Ejemplo de tnel RSVP Con un sencillo ejemplo se intentara explicar el mecanismo de establecimiento de los tneles. Para ello deben fijarse en la figura siguiente, en la que se van a establecer dos tneles. Uno de ellos pasando por los routers A-B-D-E y el otro con los equipos A-B-C-DE. 60
Figura 5.6. Terminologa del tnel TE.
Se puede, por ejemplo, establecer que el trfico de usuarios de acceso gratuito a Internet vaya por el tnel 2, ya que tiene un mayor nmero de saltos, mientras que se encaminara otro tipo de trfico por el tnel 1, por ejemplo, clientes con mayor prioridad. Una caracterstica muy importante a tener en cuenta es que los tneles se establecen en un nico sentido. No son bidireccionales. Es decir, si se quisiera configurar un tnel desde el equipo E hacia el equipo A se debera establecer en el equipo E, y podra tener otro tipo de atributos diferentes a los de los tneles 1 2. Los atributos de un tnel con traffic engineering pueden ser: Dinmico: Elige el tnel con el mejor camino. Vienen determinados por lo que decida el protocolo de routing interno. Esttico: Utiliza un camino preestablecido. Se pueden definir todos y cada uno de los saltos. Ancho de Banda: Se refiere a la capacidad del tnel. Este es el atributo que como mnimo debe estar siempre definido. Prioridad: Tneles con prioridad ms alta tienen preferencia. Si se establece un segundo tnel con mayor prioridad que uno anterior, el trfico de este ltimo se deja de lado y se pasa a enviar trfico del segundo tnel.
En Cisco el comando para configurar un tnel sera: tunnel mpls traffic-eng priority 3 4 Las prioridades deben estar en el rango entre 0 y 7. El primer valor (en este caso 3) indica la prioridad para establecer un tnel, mientras que el segundo valor (4) marca la prioridad para mantener establecido ese tnel frente a los intentos de otros tneles por establecerse.
61
En cada nodo se toma una decisin en funcin del ancho de banda disponible mediante un mdulo software de control de admisin del enlace, como puede verse en la figura siguiente:
Pool de BW Libre
Mensaje Path
RSVP
Mensaje Reservation
Link Admission Control
Figura 5.7. Proceso de prioridad de tneles. Esto es lo que se denomina Coloreado de enlaces: Es una medida de afinidad. El administrador de la red puede colorear (asignar una determinada prioridad a cada enlace) los enlaces como crea ms oportuno. Un ejemplo de tnel dinmico:
Figura 5.8. Ejemplo de establecimiento de tnel. En este caso se van a utilizar las mtricas del protocolo de routing interno correspondiente para crear el tnel dinmico. Por ejemplo, en OSPF se tendrn en cuenta prefijos destino, mscara de direccin destino y coste del enlace. OSPF, al igual que el protocolo IS-IS utilizado en OSI no tendr en cuenta parmetros importantes en MPLS como el ancho de banda del enlace, con lo que se utilizaran estos mismos protocolos de routing interno
62
(OSPF, IS-IS,...) pero con extensiones MPLS para conseguir que propaguen parmetros como el ancho de banda, el color del enlace,... Con estas extensiones OSPF por ejemplo calcular de manera normal el shortest path first (camino ms corto) pero considerando adems el ancho de banda del enlace y no el coste. En Cisco el comando para establecer este tnel dinmico sera: Router A (config-if)# tunnel mpls traffic-eng path-option 1 dynamic Por el contrario un tnel esttico sera el compuesto por los routers A-B-C-D-E y se creara manualmente. Sera un tnel explcito. En Cisco se configurara de la siguiente manera: Router A (config-if)# tunnel mpls traffic-eng path-option 1 explicit name longpath ip explicit-path name longpath enable next-address <direccin IP del interfaz de salida de A> next-address <direccin IP del interfaz de salida de B hacia C> next-address <direccin IP del interfaz de salida de C> next-address <direccin IP del interfaz de salida de D> En el caso de fallo de un enlace, por ejemplo entre el router B y D, el router cabecera detectar este fallo en el tnel 1 (dinmico) e inicializar el tnel 2. El trfico se encamina automticamente por el tnel 2. Los routers intermedios dejan pasar el trfico de los tneles pero no lo controlan. Un caso comn es tener configurado el tnel 2 como back-up del tnel 1, pero hay que tener en cuenta que en caso de recuperarse el fallo del enlace que pertenece al tnel principal, el trfico debe volver a encaminarse por este tnel (tnel 1) ya que podra suceder despus del fallo que el trfico no se est enviando por el mejor camino. Cmo se soluciona este problema? Un temporizador se encarga de chequear peridicamente el camino actual y si detecta que el tnel principal recupera se vuelve a enviar el trfico por este tnel. Tambin puede optarse por realizar balanceo de carga entre los dos tneles basndose lgicamente en ponderar el envo de datos segn el ancho de banda configurado para cada tnel. En caso de producirse los siguientes eventos habra que distribuir la informacin entre los routers: Al principio en la configuracin de la red. Despus de cambios significativos en el enlace (ancho de banda, color,...) Fallo en la creacin de los LSP. Por vencimiento de un temporizador peridico. Cambio de los parmetros de un enlace (BW).
63
La informacin a enviar en estos casos es: El ancho de banda disponible. El peso administrativo. Los atributos de los enlaces (colores).
Por ejemplo, un protocolo de vector de distancias configurado para permitir flooding servira para enviar esta informacin. Se crear una base de datos distribuida de los enlaces y de los recursos disponibles en ellos. Este protocolo estar soportado por OSPF e IS-IS y se configurar dentro de estos protocolos de routing interno (IGP). Cada interfaz susceptible de ser utilizada por un tnel TE debe ser configurado con el BW correcto requerido por el router cabecera, que inicia el tnel.
Figura 5.9. Ejemplo de asignacin de BW en un tnel.
Se deben respetar las siguientes condiciones: Si cualquier enlace no soporta un requerimiento de X Kbps (El ancho de banda mnimo que se quiera reservar) el establecimiento del tnel fallar. Si el tnel a construir tiene mayor prioridad que uno ya establecido ste ltimo se anular si no hay ancho de banda disponible.
Lo que realmente interesa es el ancho de banda til para efectuar Traffic Engineering. Puedes disponer de 1 Giga y dejar 100 Megas para establecer TE. El ancho de banda que se va a reservar en cada nodo, se debe configurar previamente. Una vez configurado el protocolo de routing interno (OSPF por ejemplo) utilizar las extensiones para comunicrselo al resto de equipos. En cada interfaz susceptible de ser utilizado por el que puede pasar un tnel debe configurarse con el ancho de banda correcto y coincidir como mnimo con el ancho de banda que pide el router cabecera.
64
En el caso de la tecnologa Cisco se suele hablar del routing de El pez en un smil ms o menos acertado de las diferentes rutas por las que puede llevarse el trfico. Puede verse en la siguiente figura como la ruta a travs de los routers R2, R3, R4 y R5 se asemeja a la espina dorsal de un pez, mientras que la ruta alternativa a travs de R6 y R7 sera la aleta de ese pez.
Figura 5.10. Routing El pez. La asignacin del ancho de banda del enlace para los tneles en Cisco se realizara, interfaz por interfaz, de la siguiente manera: ip rsvp bandwith 10000 (BW=10000 en este caso)
Y la asignacin de ancho de banda a un tnel as: tunnel mpls traffic-eng bandwith 1000 Recordar que en las tecnologas IP existentes el modelo de separacin de funciones es el siguiente:
Figura 5.11. Modelo IP. 65
La red de nivel 2, ya sea ATM o FR, se utiliza para gestionar el ancho de banda, es decir, para establecer la ingeniera de trfico mientras que los equipos de nivel 3 se ven entre s como un full-mesh. El camino que elige el protocolo de routing como mejor ruta puede resultar ser el peor de los caminos fsicos. Los aspectos negativos que presentan las redes tradicionales y frente a los que las topologas MPLS resultan ventajosas son los siguientes: Son necesarios equipos de nivel 2 con el coste que ello supone. Las redes de nivel 2 y nivel 3 son paralelas con lo que hay que realizar una gestin de red y una provisin de servicios especfica para cada nivel. No existe diferenciacin de servicios (Class of Service) en el nivel 3 (IP). En ATM s existen categoras de servicio que se pueden relacionar con las clases de servicio de estas nuevas topologas MPLS. Tanto en ATM como FR se configuran los denominados PVC (Circuitos virtuales Permanentes) pero slo se puede dar una misma calidad de servicio a todo el trfico que discurra por el mismo PVC sin tener la posibilidad de diferenciar distintos tipos de trfico que vayan por el PVC.
5.7 MPLS TE Configuracin

A continuacin se van a describir algunos ejemplos de configuracin de TE en routers Cisco, es necesario establecer un mecanismo denominado CEF (Cisco Express Forwarding) para obtener las funcionalidades MPLS y entre ellas la de Traffic Engineering. Un truco muy interesante al configurar los tneles de Traffic Engineering es emplear en la configuracin en el caso de los routers cabecera y final del tnel las direcciones de loopback para evitar estar condicionando el establecimiento y el correcto funcionamiento de un tnel al estado de un interfaz fsico. Se debe configurar globalmente el tnel en cada router y despus individualmente en cada interfaz: mpls traffic-eng tunnels ip rsvp bandwith 10000 Dos configuraciones completas posibles de los dos tneles anteriores pueden ser: Tnel 1: interface tunnel 1 tunnel destination 15.13.2.6 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 3 4 tunnel mpls traffic-eng bandwith 1000 tunnel mpls traffic-eng path-option 1 dynamic
66
Tnel 2: interface tunnel 2 tunnel destination 15.13.2.6 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name Mientras que la configuracin para la ruta explcita ser la siguiente: ip explicit-path name longpath enable next-address <direccin IP del interfaz de salida de A> next-address <direccin IP del interfaz de salida de B hacia C> next-address <direccin IP del interfaz de salida de C> next-address <direccin IP del interfaz de salida de D>
5.8 MPLS TE Operacin

A continuacin se enumeran los principales comandos en Cisco para realizar la operacin y mantenimiento de los tneles TE y cul es su funcin. 1) Estado del establecimiento de un tnel LSP (en la cabecera) show ip interface brief Mirar si las interfaces estn up. show mpls traffic-eng tunnel summary Mirar el estado del clculo del camino y la sealizacin.
show ip rsvp [{send | reservation | ...}] Mirar los registros de la sesin RSVP: mensajes path (emisor) y reservation (cabecera y puntos intermedios). 2) Estado del establecimiento de un tnel LSP (en puntos intermedios) show mpls traffic-eng link admission Mostrar las conexiones admitidas. show ip rsvp Mostrar las sesiones RSVP establecidas. show mpls ip binding Mostrar el registro de asignacin de etiquetas. 3) Debugs en el establecimiento. debug mpls traffic-eng path calc
67
Debug para el clculo de ruta. debug ip rsvp [access-list] Debug para la sealizacin de ruta. 4) Estado del protocolo IGP show mpls traffic-eng link advertisements El mdulo local de Traffic Engineering pasa la informacin al protocolo de routing interno. show ospf database opaque-area Ver la informacin de los atributos extendidos (database) y los que no aparecen normalmente en la tabla de routing (opaque-area). show traffic-eng topology [brief] Comprobar si la base de datos global para el routing recibe la informacin. El mejor camino de Traffic Engineering no tiene por qu coincidir con el que eligiera el protocolo de routing. 5) Routing en los tneles LSP El mecanismo de TE y el protocolo de routing interno cooperan para determinar qu prefijos deben ser encaminados a los tneles LSP. show ip route show ip cef Ver los prefijos que son encaminados sobre tneles TE. Show ip route X/X incluye el factor de balanceo. show mpls traffic-eng autoroute Mostrar los tneles que han sido anunciados al protocolo de routing interno.
68
Captulo 6 Escenario real de una red MPLS
6. ESCENARIO REAL DE UNA RED MPLS

6.1 Introduccin
El escenario sobre el que se va a realizar la explicacin de cmo se configurara una red real de forma prctica (ver tambin Anexo B: Prcticas propuestas, en el que se puede ver el escenario real que se ha configurado para la realizacin de las prcticas del laboratorio de la asignatura de Redes y Servicios II) es el que se muestra en la figura siguiente. Se tendrn cuatro grupos diferenciados: Norte, Sur, Este y Oeste. En la figura siguiente se pueden ver los equipos que corresponden a cada grupo y las conexiones existentes en cada uno de ellos. La tecnologa utilizada en este escenario ser enteramente Cisco.
NORTE-U1 NORTE-T EQUIPO NORTE NORTE-U2
NORTE-C EQUIPO ESTE OESTE-U1 OESTE-C ESTE-C ESTE-U2
OESTE-T OESTE-U2 EQUIPO OESTE SUR-T EQUIPO SUR
ESTE-T ESTE-U1 SUR-C
SUR-U2
SUR-U1
Figura 6.1. Distribucin de equipos por grupo y conexiones entre ellos.
69
Cada grupo dispone de cuatro equipos, uno de ellos de core (con funcionalidad de P cuando se hable de VPN), otro de acceso (con funcionalidad de PE en el caso de VPN) y dos de clientes (uno para cada VPN). Para acceder a los equipos de cliente, en adelante equipos U, se utilizara el puerto COM1 del PC que estar directamente conectado al puerto de consola de los routers U. La consola de los equipos C y T de cada grupo ser accesible mediante telnet. Tambin puede usarse un servidor de consolas. Se les entregaran a los alumnos los routers preconfigurados para que nicamente tengan que configurar las funcionalidades MPLS que se quieren implementar. Una vez presentado el escenario se detallara el proceso a seguir para preparar los equipos para que puedan tener funcionalidades de una red MPLS.
6.2 Desarrollo
Se comenzara trabajando slo con los routers del backbone. De momento se dejan a un lado los equipos de clientes.
NORTE-U1
Se0/0
NORTE-U2 NORTE-T
Se0/0
Se0/0 Se0/2
Se0/1
NORTE-C OESTE-U2
Se0/0 Se0/1 Se0/0 Fe0/0
Se2/0 Fe1/0
ESTE-U1
Se0/0
OESTE-C
Fe1/0 Fe0/0 Fe0/0
ESTE-C
Se0/0 Se0/1 Fe1/0
OESTE-T
Se0/0
ESTE-T
Se0/0
OESTE-U1
Fe1/0
Fe0/0
ESTE-U2
SUR-C
SUR-T
Se0/1 Se0/0 Se0/0 Se0/0
SUR-U2
SUR-U1
Figura 6.2. Conexiones fsicas.
70
NORTE-U1
NORTE-U2
NORTE-T
10.255.255.5 .2 10.10.1.0/30 10.255.255.1
NORTE-C
.1
.1 .10 10.1.1.8/30
OESTE-U2 OESTE-C
10.255.255.4 10.10.4.0/30 .2 .1 .2 .13 10.255.255.8
ESTE-U1 ESTE-C
10.255.255.3 10.10.3.0/30 .9 .1 .2 .6
10.1.1.0/30
OESTE-T
10.1.1.12/30 .14 .1 .2
10.1.1.4/30 .5 10.255.255.2 10.10.2.0/30
10.255.255.7
ESTE-T
OESTE-U1
ESTE-U2 SUR-C
SUR-T
10.255.255.6
SUR-U2
SUR-U1
Figura 6.3. Direccionamiento IP en el backbone.
6.2.1 Comprobacin del estado de las interfaces y direccionamiento IP.

El primer paso es comprobar que todas las interfaces entre los equipos C y T estn UP, UP (es decir, que estn levantadas a nivel fsico y de protocolo) y que el direccionamiento coincide con el de la figura 6.3. Se podra haber diseado otro direccionamiento utilizando otras direcciones IP privadas (10.*.*.*) o bien otra loopback distinta de la cero, ya que las loopbacks no son ms que interfaces lgicas. No interesa tener direccionamiento pblico dentro de la red, con lo que resultan adecuadas estas direcciones. Para comprobar el estado de las interfaces se ejecutar el siguiente comando show ip interface brief en el equipo C:
71
NORTE-C#sh ip interface brief Interface IP-Address OK? FastEthernet0/0 10.1.1.1 YES FastEthernet1/0 10.1.1.10 YES Serial2/0 10.10.1.1 YES Loopback0 10.255.255.1 YES
Method Status NVRAM up NVRAM up NVRAM up NVRAM up
Protocol up up up up
Comprobar tambin que todas las interfaces tienen configurado el subnetting de forma correcta. Todas deben tener mscara /30 excepto la loopback 0 que debe tener mscara /32. Utilizar el comando show ip interface en los equipos C para ir viendo interfaz a interfaz el subnetting correspondiente: NORTE-C#sh ip interface FastEthernet0/0 is up, line protocol is up Internet address is 10.1.1.1/30 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes FastEthernet1/0 is up Comprobar ahora la conectividad de los equipos C con sus vecinos directamente conectados mediante el comando ping: NORTE-C# ping < IP DEL VECINO> Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round trip min/avg/max = 1/1/4 ms
6.3 OSPF
A continuacin hay que establecer como protocolo de routing dinmico el OSPF en el futuro backbone MPLS. En la figura 6.4 puede verse el rea que abarca el protocolo de routing y las direcciones que deben propagarse por dicho protocolo:
72
Figura 6.4. Diagrama de la cobertura OSPF.
Se impondr que no exista ningn tipo de redistribucin de rutas entre protocolos de routing. Es decir, todas las direcciones deben ser propagadas como nativas en el protocolo OSPF. A continuacin, se configuraran los equipos C y T. Se debe asignar un nmero al proceso OSPF que se va a ejecutar. En este caso el proceso ser el 255.
6.3.1 Configuracin de un equipo C

En la figura 6.4 se puede observar que todos los equipos directamente conectados a los equipos C estn dentro del rea OSPF, con lo que se debe habilitar OSPF por todas las interfaces: Router C# conf t Enter configuration commands, one per line. End with CNTL/Z. Router C (config) # router ospf 255 Router C (config-router)# network 0.0.0.0 255.255.255.255 area 0 Router C (config-router)# passive-interface loopback 0
73
Para poder configurar el OSPF se debe entrar en los routers en modo enable (modo configuracin). De ah que el prompt que aparece sea # en lugar de >, que corresponde a un modo normal de operacin de los routers, sin capacidad para poder modificar configuraciones de las interfaces, protocolos,... Cada modo posee un password diferente. Mediante el comando router ospf 255 se declara el proceso nmero 255 para que en l se corra el protocolo de routing OSPF. Luego se indica en qu interfaces queda habilitado OSPF mediante el comando network 0.0.0.0 255.255.255.255 area 0. En este caso queda habilitado en todos las interfaces (las 3 que tiene cada router C), al aparecer 0.0.0.0 255.255.255.255. La primera direccin IP pertenece a la interfaz en la que se habilita OSPF y la segunda a la mscara. Tambin pueden aparecer wild cards en lugar de la mscara (son los bits inversos). Por ltimo, con el comando passive-interface loopback 0 no se permite que la interfaz de loopback se anuncie. OSPF quedar activado en esta interfaz pero no va a tener vecinos. Si no se ejecuta este comando el interfaz loopback intentara enviar hellos. OSPF es un protocolo de routing interno (IGP) del tipo estado de enlace. Los equipos anuncian toda la informacin al arrancar el protocolo. Se enviarn entre s paquetes link state cuando se detectan fallos en algn enlace. Entonces, todos los routers actualizan la base de datos topolgica, se copian los link state e inundan a los vecinos. Por tanto, slo se van enviando las nuevas actualizaciones de rutas (y no la tabla completa).Otras caractersticas a tener en cuenta son: Los equipos ejecutan el algoritmo de Dijkstra, generando una nueva tabla de rutas. Soporta mscaras de longitud variable. Selecciona las rutas basndose en el ancho de banda. Soporta rutas de igual coste. Siempre existir un rea 0 al menos y todas las dems reas si existen tendrn al menos un punto de interconexin con el rea 0. Soporta diferentes topologas: multiacceso broadcast, punto a punto, NBMA (non broadcast): FR,... En una topologa multiacceso broadcast (una LAN por ejemplo) se debe elegir un equipo como DR (Designated Router) y otro como BDR (Backup Designated Router). Cada uno de los dems equipos establecer la adyacencia con su DR y BDR y no con los dems equipos. En una topologa punto a punto no hay eleccin de DR y BDR. La adyacencia se establece automticamente cuando dos routers se pueden comunicar. Los routers se descubren rutas entre s mediante el envo de paquetes hello. El equipo con router ID (una direccin IP) mayor es el que inicia el intercambio.
Sin salir de la configuracin de OSPF se debe establecer la autenticacin del rea 0: Router C (config-router)#area 0 authentication Router C (config-router)#exit
74
Se debe configurar tambin la clave de autenticacin en todas las interfaces que sirven para conectar equipos C y T. Router C (config-router)#interface <NOMBRE DE LA INTERFAZ> Router C (config-if)# ip ospf authentication-key ******* Por ltimo, salir del modo configuracin guardndola: Router C (config-if)#end Router C# wr
6.3.2 Configuracin de un equipo T

Se debe configurar primero OSPF en todas las interfaces que dan al backbone (ver figura 6.4). Todas tienen direccionamiento 10.x.y.z. Router T# conf t Enter configuration commands, one per line. End with CNTL/Z. Router T (config) # router ospf 255 Router T (config-router)# network 0.0.0.0 255.255.255.255 area 0 Router T (config-router)# passive-interface loopback 0 Puede verse que el comando network es el mismo que en el caso de las interfaces de equipos C. Con este comando se habilita OSPF en todas aquellas interfaces con direccin IP 10.*.*.*. Es decir, las interfaces de los equipos C entre ellos y con los equipos T. O sea, las interfaces del rea 0 (ver figura 6.4). Sin salir de la configuracin se debe establecer la autenticacin del rea 0 como en el caso anterior: Router T (config-router)#area 0 authentication Router T (config-router)#exit A continuacin se deber configurar en las interfaces que conectan equipos C y T la clave de autenticacin: Router T (config-router)#interface <NOMBRE DE LA INTERFAZ> Router T (config-if)# ip ospf authentication-key ******* Hay que tener en cuenta en este apartado y en el anterior que donde aparece <NOMBRE DE LA INTERFAZ hay que colocar el nombre del interfaz: Ej) Se0/0. Si se pone la direccin IP de la interfaz correspondiente no se entra en la configuracin de dicha interfaz. Por ltimo, salir del modo configuracin guardndola al igual que antes: Router T (config-if)#end Router T# wr
75
6.3.3 Verificacin del funcionamiento de OSPF

6.3.3.1 Las interfaces Todas las interfaces que abarca el rea amarilla de la figura 6.4 deben estar activas en el protocolo OSPF con autenticacin. Se puede comprobar con el comando show ip ospf interface: ROUTER#sh ip ospf interface FastEthernet0/0 is up, line protocol is up Internet Address 10.1.1.1/30, Area 0 Process ID 255, Router ID 10.255.255.1, Network Type BROADCAST, Cost: 1 Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 10.255.255.4, Interface address 10.1.1.2 Backup Designated Router (ID) 10.255.255.1, Interface address 10.1.1.1
Debe haber un equipo DR y BDR como se coment antes, y cada equipo tiene un Router ID para poder establecer prioridades en el envo de hellos. En la salida del comando puede verse que este equipo es el que hace las funciones de BDR 6.3.3.2. Los vecinos Para poder propagar prefijos de routing tiene que haberse establecido adyacencias con los vecinos directamente conectados. Habra que verificar que se han establecido dichas adyacencias con el comando show ip ospf neighbors. La salida de este comando para uno de los routers T: NORTE-T#sh ip ospf neighbors Neighbor ID Pri State Dead Time Address 10.255.255.1 1 FULL/ 00:00:35 10.10.1.1
Interface Serial0/2
6.3.3.3 Las rutas A continuacin se ha de verificar que se reciben todas las rutas o prefijos que se deberan estar propagando por OSPF mediante el comando show ip route. Para un equipo T la salida sera: NORTE-T#sh ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP I - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR
76
P - periodic downloaded static route Gateway of last resort is not set C 10.10.1.0/30 is directly connected, Serial0/2 O 10.10.2.0/30 [110/98] via 10.10.1.1, 01:50:20, Serial0/2 ... C 10.255.255.5/32 is directly connected, Loopback0 Al principio de la salida del comando puede verse una lista de cdigos que indican cmo fue aprendida cada ruta. Es interesante observar que las loopback tiene mscara /32 ya que son direcciones virtuales.
6.4 BGP
Antes de configurar el protocolo MPLS, hay que establecer primero un full-mesh de sesiones iMBGP entre los equipos T para tener preparado el escenario de una red MPLS. Las sesiones a establecer se muestran en la figura 6.5.
Figura 6.5. Mapa de sesiones iBGP. El sistema autnomo que se elegir para este escenario ser el 65000 (uno de los nmeros reservados en BGP para sistemas autnomos privados).
77
6.4.1 Configuracin de las sesiones iBGP

A continuacin se va a configurar el protocolo de routing BGP para que exista un full-mesh de sesiones internas entre los equipos T de cada grupo. Las sesiones iMBGP debern establecerse entre las direcciones IP asociadas a la nueva loopback 255 que debe ser creada previamente. sta ser la loopback BGP. Configurar para cada peer BGP (anlogo al trmino vecino en OSPF) lo siguiente: Crear primero la nueva interfaz loopback 255: Router T# conf t Enter configuration commands, one per line. End with CNTL/Z. Router T (config)# interface loopback 255 Router T (config-if)# ip address < IP-ADDRESS> 255.255.255.255 Router T (config-if)# exit La interfaz loopbak 255 debe incluirse a su vez en el protocolo de routing OSPF para que se propague a sus futuros vecinos BGP: Router T (config) # router ospf 255 Router T (config-router)# network < IP-ADDRESS> 0.0.0.0 area 0 Router T (config-router)# passive-interface loopback 255 Se configura el proceso de routing BGP: Router T (config-router)# router bgp 65000 Router T (config-router)# no synchronization Con el comando: router bgp 65000 declarar el protocolo BGP en el sistema autnomo 65000. Con el comando no synchronization se deshabilita la regla de sincronizacin de BGP, que dice No utilizar, o anunciar a un vecino externo, una ruta aprendida por IBGP, hasta que haya sido aprendida mediante un IGP. Con esta regla se asegura la consistencia de la informacin dentro del AS y se evitan agujeros negros dentro del AS. Esta regla se puede desactivar cuando todos los routers del AS estn corriendo BGP. ste es el caso de este escenario, ya que se ha establecido un full-mesh entre todos los routers T. Con el no synchronization el router aprender rutas por BGP, antes de aprenderlas por un IGP (OSPF en este caso). Para cada vecino iMBGP se debe configurar BGP en cada interfaz loopback 255: Router T (config-router)# neighbor < dir IP loop 255> remote-as 65000 Router T (config-router)# neighbor < dir IP loop 255> update-source loop 255 Router T (config-router)# end Router T# wr
78
6.4.2 Verificacin del funcionamiento.

Una vez configuradas las sesiones BGP hay que verificar que stas estn funcionando mediante el comando show ip bgp neighbor. EBRO-T#sh ip bgp neighbors BGP neighbor is 172.31.31.2, remote AS 65000, internal link BGP version 4, remote router ID 172.31.31.2 BGP state = Established, up for 00:00:51 Last read 00:00:51, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received(new) Address family IPv4 Unicast: advertised and received Received 299 messages, 0 notifications, 0 in queue Sent 299 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Default minimum time between advertisement runs is 5 seconds Tambin se puede utilizar el comando sh ip bgp summary para ver los prefijos que se reciben de cada vecino.
6.5 Configuracin de LDP

Una vez establecidos los protocolos de routing hay que crear la nube MPLS. Para ello hay que arrancar el protocolo de distribucin de etiquetas en las distintas interfaces por las que se va a hablar MPLS. El mapa final que se pretende conseguir se muestra en la figura 6.6. Norte-T
LDP
Oeste-C Oeste-T Norte-C Sur-C Este-C Este-T
Sur-T
Figura 6.6. Mapa de la red MPLS.
79
Un dato importante es que actualmente todas las familias de routers Cisco que hablan MPLS son capaces de soportar LDP como protocolo de distribucin de etiquetas.
6.5.1 Activacin del protocolo de distribucin de etiquetas.

En primer lugar hay que activar el CEF (conjunto de funcionalidades de los routers Cisco para poder ejecutar MPLS) en todos los equipos: Router T# conf t Enter configuration commands, one per line. End with CNTL/Z. Router T (config)# ip cef
CEF: Cisco Express Forwarding: Se muestra a continuacin el estado normal de un equipo con cef habilitado utilizando el comando show ip cef summary: Router# show ip cef summary IP CEF with switching (Table Version 131), flags=0x0, bits=8 32 routes, 0 resolve, 0 unresolved (0 old, 0 new) 32 leaves, 18 nodes, 23004 bytes, 125 inserts, 93 invalidations 1 load sharing elements, 336 bytes, 1 references universal per-destination load sharing algorithm, id 355643BG 1 CEF resets, 6 revisions of existing leaves 6 in-place modifications refcounts: 4909 leaf, 4864 node Si el cef no estuviera habilitado no aparecera nada en la salida de este comando. A continuacin habra que habilitar la distribucin de etiquetas para las interfaces T-C y para las conexiones entre equipos C. Por tanto hay que activar en los equipos T el protocolo de distribucin de etiquetas LDP en la interfaz que les une a los equipos C de su mismo grupo o equipo: Router T (config)# interface <INTERFAZ> Router T (config-if)# mpls ip Router T (config-if)# mpls label protocol ldp Router T (config-if)# end Router T# wr Igualmente en los equipos C en la interfaz que les une a los T se realizara el mismo proceso as como en los interfaces que unen los equipos C entre si.
80
6.5.2 Verificacin del funcionamiento de la nube MPLS.

Comprobar los parmetros que est utilizando el protocolo en este equipo. Para ello se ejecutara el comando show mpls ldp parameters con el que se visualizaran atributos como la versin del protocolo LDP, rango de etiquetas valores mnimo y mximo-, hold-time, keep alive,... Tambin se puede comprobar que LDP est funcionando en las interfaces que se ha planificado con el comando show mpls interfaces mediante el cual puede verse por ejemplo si hay establecidos o no tneles de traffic engineering, el estado del protocolo (operationalimplica activo, NO implica interfaz cado,...) y aadiendo detail a este comando se obtiene el valor de la MTU de la interfaz. As mismo habra que verificar que los equipos T hayan podido establecer la sesin con los equipos C y por tanto se hayan reconocido como vecinos. El comando preciso es show mpls ldp neighbors. Para el equipo NORTE-T por ejemplo se veran datos como nombre de vecino:10.255.255.1, protocolo: LDP, peer IDENT:10.255.255.1:0, puerto TCP local y remoto en el que se establece la conexin:711 y 11007, estado, enlace fsico: Serial 0/2. A continuacin una vez que se hayan establecido las sesiones LDP todos los equipos asignarn etiquetas a cuantos prefijos existan propagados por el IGP (OSPF en este caso). Otro comando til que se puede resear es show mpls ldp binding, que muestra el contenido de la tabla LIB (Label Information Base). Puede comprobarse a continuacin la salida de uno de estos comandos: SUR-T#sh mpls ldp bindings lib entry: 10.1.1.0/30, rev 28 local binding: label: 37 remote binding: tsr: 10.255.255.2:0, label: 26 lib entry: 10.1.1.4/30, rev 38 local binding: label: 41 remote binding: tsr: 10.255.255.2:0, label: imp-null lib entry: 10.1.1.8/30, rev 14 local binding: label: 31 remote binding: tsr: 10.255.255.2:0, label: 22 lib entry: 10.1.1.12/30, rev 22 local binding: label: 34 remote binding: tsr: 10.255.255.2:0, label: imp-null lib entry: 10.10.1.0/30, rev 10 local binding: label: 29 remote binding: tsr: 10.255.255.2:0, label: 20 Este comando muestra datos como entradas de la LIB, siguiente salto (tsr), etiqueta local (de entrada al router) y remota (de salida). Cuando aparece imp-null en una de las etiquetas local o remota implica que el router ser de ingress (recibe paquetes IP nativo) o de egress
81
(entrega paquetes IP nativo). stos son los routers de borde de la red MPLS. No hacen una conmutacin de etiquetas pura. Para ver qu etiqueta local y remota se ha asignado a una interfaz en particular existe el comando sh mpls ldp binding <subred> <mascara>, donde la subred y la mscara es la de la lnea serie que une los equipos T y C por ejemplo. En este caso podrn verse etiquetas imp-null. Por ltimo se puede emplear sh mpls forwarding table para ver la tabla LFIB. En ella aparecern las interfaces directamente conectadas de los usuarios (equipos U): SUR-T#sh mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 26 16 172.31.31.4/32 0 Se0/2 point2point 27 17 172.31.31.1/32 0 Se0/2 point2point 28 19 172.31.31.3/32 0 Se0/2 point2point 29 20 10.10.1.0/30 0 Se0/2 point2point 30 21 10.255.255.8/32 0 Se0/2 point2point 31 22 10.1.1.8/30 0 Se0/2 point2point 32 23 10.10.3.0/30 0 Se0/2 point2point 33 24 10.10.4.0/30 0 Se0/2 point2point 34 Pop tag 10.1.1.12/30 0 Se0/2 point2point 35 Pop tag 10.255.255.2/32 0 Se0/2 point2point 36 25 10.255.255.3/32 0 Se0/2 point2point 37 26 10.1.1.0/30 0 Se0/2 point2point 38 27 10.255.255.1/32 0 Se0/2 point2point 39 29 10.255.255.7/32 0 Se0/2 point2point 40 30 10.255.255.4/32 0 Se0/2 point2point 41 Pop tag 10.1.1.4/30 0 Se0/2 point2point 42 31 10.255.255.5/32 0 Se0/2 point2point 44 Untagged 192.168.255.3/32[V] 0 Se0/0 point2point
En la salida de este comando se puede observar la presencia de conmutacin de etiquetas hacia equipos marcadas con pop tag. Esto indica que en la red est funcionando el fenmeno de Penultimate Hop Popping.
6.6 Introduccin a la configuracin de VPN-MPLS

Para comprender mejor el funcionamiento de las VPN con MPLS se van a crear dos modelos distintos de VPN en este captulo. Una VPN con topologa hub & spoke en la que el equipo NORTE har de sede central y otra VPN en full-mesh. La siguiente figura muestra la distribucin de los equipos y cules estn involucrados en cada modelo.
82
Figura 6.7. Diagrama de los dos modelos de VPN
El primer paso es configurar los equipos para que exista conectividad fsica IP por los enlaces directamente conectados.
83
NORTE-U1
192.168.255.1 .2 192.168.1.0/30 .1 .1 .2 192.168.2.0/30
NORTE-U2
192.168.255.2
NORTE-T
192.168.255.8
192.168.255.5
OESTE-U2
.14 192.168.1.12/30 .14 192.168.2.12/30 .13 .13 192.168.1.8/30 .9 .9
ESTE-U1
.10
OESTE-T
10.255.255.7
ESTE-T
192.168.2.8/30 .10
OESTE-U1
192.168.255.7
ESTE-U2
192.168.255.6
SUR-T
.5 192.168.2.4/30 .6 .5 192.168.1.4/30 .6
SUR-U2
192.168.255.4
SUR-U1
192.168.255.3
x.y.w.z
loopback 1
Figura 6.8. Direccionamiento IP de los equipos de clientes
Se puede verificar con el comando sh ip int brief en los equipos T y en los dos U que la configuracin existente se ajusta al direccionamiento que se ha sugerido en la figura 6.8, y realizando ping se comprobar que no hay errores en la lnea serie que une los equipos T y U. A continuacin se determinaran los pasos a seguir en el desarrollo de los dos modelos de VPN propuestos.
6.6.1 VPN A: Routing esttico; Hub & Spoke.

En este apartado se van a explicar las fases de creacin de una VPN, denominada A, en la que aparecern los equipos que se ven en la figura siguiente y que tendr una topologa Hub & Spoke.
84
VPN A
NORTE-U1
NORTE-T
ESTE-U1
RED MPLS OESTE-T OESTE-U1 ESTE-T
SUR-T
SUR-U1
Figura 6.9. Equipos involucrados en la VPN-A Esta VPN se va a configurar de forma que el routing en los enlaces T U sea esttico y la topologa que se generar ser un punto-multipunto (hub&spoke), como puede apreciarse en la figura 6.10:
Figura 6.10. Topologa y visin lgica del routing en la VPN-A
85
6.6.1.1. Configuracin en los U1. Como se ha indicado en el apartado anterior el routing ser esttico en la VPN-A y es importante recordar tambin que en una VPN-MPLS el routing de los clientes se implementa en los equipos con funcionalidad PE; en este caso en los equipos T. As, el routing que hay que configurar en todos los equipos U1 es sencillo: una ruta por defecto a travs del equipo T: Router U1 # conf t Enter configuration commands, one per line. End with CNTL/Z. Router U1 (config) # ip route 0.0.0.0. 0.0.0.0 < IP del equipo T en la interfaz serie > Router U1 (config) # end Router U1 # wr
6.6.1.2. Configuracin de la VRF. El equipo U1 est preparado. Ahora hay que crear la VRF asociada a esa VPN-A. Los parmetros necesarios para crearla (RD y RT) pueden verse en la figura siguiente.
Figura 6.11. Parmetros bsicos para la creacin de las VRF de la VPN-A Las flechas apuntando al equipo T identifican el route-target que debe importar el equipo. Las flechas apuntando hacia la nube MPLS identifican el route-target que debe exportar el equipo.
86
Se configura la VPN-A: Router T# conf t Enter configuration commands, one per line. End with CNTL/Z. Router T (config)# ip vrf < NOMBRE DEL EQUIPO U1> Router T (config-vrf)# rd <VALOR DEL RD segn figura 6.11> Router T (config-vrf)# route-target export <VALOR FLECHA SALIENTE> Router T (config-vrf)# route-target import <VALOR FLECHA ENTRANTE> Router T (config-vrf)# int <SERIAL QUE UNE A U1> Router T (config-if)# ip vrf forwarding <NOMBRE DE LA VRF (NORTE-U1,...)> En este momento aparecer un mensaje similar al siguiente, indicando que en dicha interfaz ha desaparecido la configuracin IP al crear la VRF, por lo que habr que volver a configurarla: % Inteface Serial0/1 IP address x.y.w.z removed due to enabling VRF Router T (config-if) # ip add 192.168.1.z 255.255.255.252 Router T (config-if) # end Router T # wr En lo que respecta a la VRF ya estara todo configurado. Har falta comprobar la conectividad entre el equipo T y el equipo U1 con el ping. Qu ocurre? Los pings no llegan, porque se estn lanzando a una direccin fsica. El comando que se debe utilizar es: ping vrf < NOMBRE VRF > < DIR IP DE U1 EN LA INTERFAZ SERIE>
As mismo se debe usar el comando show ip route vrf <NOMBRE VRF> para ver la tabla de routing de la VRF. Hasta ahora nicamente se ha configurado la VRF en los equipos T y las subredes que les unen a los equipos U1 han pasado a la tabla de routing de la propia VRF, con lo que est asegurada la conectividad local, pero si se lanzara un ping desde un equipo T con destino la loopback 1 del equipo U1 no llegara (slo llegara a la direccin serie).
6.6.1.3. Configuracin del routing esttico en el equipo T. En este tipo de VPN (hub&spoke) cada equipo T debe tener una ruta esttica apuntando a aquello que tiene localmente accesible a travs de su propio U1. Al ser NORTE-T el equipo concentrador de la VPN-A, hay dos formas distintas de configurar los equipos T, ya que los dems routers T se configuran como spokes (SUR-T, ESTE-T, OESTE-T).
87
Routers SUR-T, ESTE-T, OESTE-T Hace falta configurar una ruta esttica en la VRF que indique al equipo T que la direccin de la loopback 1 del equipo U1 se puede alcanzar por la interfaz serie que le une a l. Router T# conf t Enter configuration commands, one per line. End with CNTL/Z. Router T (config) # ip route vrf <NOMBRE VRF> <IP LOOPBACK 1 DE U1> 255.255.255.255 <IP DE U1 EN LA SERIE> Router T (config) # end Router T # wr
Router NORTE-T Este caso es particular puesto que para este equipo todo lo que no le propaguen sus vecinos iMBGP (los otros equipos T) supondr que se podr alcanzar a travs de NORTE-U1. Por tanto, se va suponer, en este caso, que el resto de la red 192.168/16 est detrs de NORTE-U1: Router T# conf t Enter configuration commands, one per line. End with CNTL/Z. Router T # ip route vrf NORTE-U1 192.168.0.0 255.255.0.0 192.168.1.2 Router T (config)# end Una vez est esto configurado habra que comprobar la conectividad local de la red. Se comprobar que el prefijo /32 de la loopback de U1 (en el caso de ESTE-T, OESTE-T, SUR-T) o que el prefijo 192.168/16 en el caso de NORTE-T estn en la tabla de routing de la VRF mediante el comando show ip route vrf <EQUIPO U1>
6.6.1.4. Configuracin del iMBGP Para que los prefijos aprendidos puedan ser transmitidos a los otros equipos T, hay que configurar el iMBGP. Primero se debes comprobar que los vecinos iBGP siguen activos y operativos mediante el comando sh ip bgp summary. El siguiente paso sera configurar el protocolo iMBGP en los equipos T:
Router T (config)# router bgp 65000 Router T (config-router)# address-family vpnv4
88
Hay que activar los vecinos existentes con la nueva funcionalidad. Segn se vayan ejecutando los comandos siguientes se irn reseteando las sesiones BGP. Este comportamiento es normal, ya que los peers tienen que renegociar las capabilities (caractersticas de BGP). Se debe configurar para cada vecino el envo de las communities (uno de los atributos de BGP que nos sirve para anunciar o no rutas de nuestros peers). Router T (config-router-af)# neighbor <DIR IP VECINO iBGP> activate Router T (config-router-af)# neighbor <DIR IP VECINO iBGP> send-community Extended Cuando estn todos los vecinos configurados se puede verificar que iMBGP est activado con el comando sh ip bgp neighbors:
NORTE-T#sh ip bgp neighbors BGP neighbor is 172.31.31.2, remote AS 65000, internal link BGP version 4, remote router ID 172.31.31.2 BGP state = Established, up for 00:00:51 Last read 00:00:51, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received(new) Address family IPv4 Unicast: advertised and received Address family VPNv4 Unicast: advertised and received Received 299 messages, 0 notifications, 0 in queue Sent 299 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Default minimum time between advertisement runs is 5 seconds For address family: IPv4 Unicast BGP table version 1, neighbor version 1 Index 2, Offset 0, Mask 0x4 0 accepted prefixes consume 0 bytes Prefix advertised 0, suppressed 0, withdrawn 0 Number of NLRIs in the update sent: max 0, min 0 For address family: VPNv4 Unicast BGP table version 5, neighbor version 5 Index 1, Offset 0, Mask 0x2 0 accepted prefixes consume 0 bytes Prefix advertised 0, suppressed 0, withdrawn 0 Number of NLRIs in the update sent: max 0, min 0 ... Observar que ahora aparece una nueva capability, address family vpnv4, que acaba de negociarse y con la que se establece la funcionalidad VPN. Tambin aparece informacin de los prefijos propagados por BGP estndar, que de momento ser 0 porque faltan por configurar los equipos U.
89
6.6.1.5. Envo de los prefijos de la VPN-A al resto de equipos T Una vez establecidas las sesiones iMBGP con el resto de equipos T y verificada la conectividad local con los integrantes de la VPN hay que propagar los prefijos locales de los respectivos clientes al resto de equipos T para que stos sepan encaminar los paquetes hacia dichos prefijos. Como cada equipo T conoce el prefijo de la loopback 1 del equipo U1 mediante una ruta esttica entonces bastar con redistribuir dicha ruta esttica en el iMBGP: Router T# conf t Enter configuration commands, one per line. End with CNTL/Z. Router T (config)# router bgp 65000 Router T (config-router)# address-family ipv4 vrf < NOMBRE VRF> Router T (config-router-af)# redistribute static Router T (config-router-af)# end Router T# wr Router T# clear ip bgp * Con el comando sh ip route vrf < NOMBRE VRF > se pueden comprobar los prefijos aprendidos por cada equipo. Para el equipo OESTE-T por ejemplo:
OESTE-T>sh ip route vrf OESTE-U1 Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 192.168.255.0/32 is subnetted, 1 subnets S 192.168.255.7 [1/0] via 192.168.1.14 192.168.1.0/30 is subnetted, 1 subnets C 192.168.1.12 is directly connected, Serial0/0 B 192.168.0.0/16 [200/0] via 172.31.31.1, 00:02:35 Aprende por redistribucin esttica la ruta de su U1 y por iMBGP las dems rutas (192.168.0.0/16) a travs de NORTE-T.
6.6.1.6. Identificacin de etiquetas. Una vez que existen prefijos que se propagan por iMBGP, se produce el proceso de asignacin de etiquetas para cada prefijo y aparece la pila de etiquetas que ya ha sido
90
explicada en el captulo en el que se hacia referencia a las VPN. La pila queda de la forma siguiente:
Figura 6.12. Paquete que se propaga por la nube MPLS en un entorno VPN
ste es el formato de pila de etiquetas que se propaga por la nube MPLS. El campo VPN (o sea, la etiqueta inferior de la pila) permanece invariante durante su paso por la red MPLS, mientras que la etiqueta MPLS (etiqueta superior de la pila) es la que va conmutando su valor por los diferentes routers de core de la red MPLS. Comprobacin de etiquetas asignadas a los prefijos locales de la VPN Con el comando show mpls forwarding-table vrf <NOMBRE VRF> se puede identificar la etiqueta que ha elegido cada equipo T y que notificar a todos aquellos vecinos que quieran enviar trfico a dicho prefijo.
NORTE-T#sh mpls forwarding-table vrf NORTE-U1 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 44 Untagged 192.168.0.0/16[V] 6240 Se0/0 point2point
En NORTE-T se ven todas las dems redes con el 192.168.0.0/16 (recordar que era el equipo que se eligi como hub).
Comprobacin de etiquetas asignadas a los prefijos remotos de la misma VPN Se utiliza el comando sh ip bgp vpnv4 all labels para identificar las etiquetas que hay que poner en el paquete MPLS. El resultado diferir en el equipo NORTE de los dems. Para el SUR-T, por ejemplo, se obtendran los siguientes resultados:
91
Prefijo 192.168.0.0/16 192.168.255.3/32
Siguiente salto 172.31.31.1 192.168.1.6
Etiqta. entrante No tag 44
Etiqta. saliente 44 No tag
Para el equipo NORTE-T:
Comentario [RDM2]: No he visto el commando que permite conocer las etiquetas de una VPN. Mira tlima parte de la 2 practica 5 de RRSS2. Comentario [m3]: El commando sh ip bgp vpnv4 all labels no lo hemos incluido en las practicas, no consideramos que hiciese falta incluirlo, pero si recuerdas cuando probamos la primera practica si que lo usamos cuando estuvimos capturando trafico con el Ethereal.
Prefijo 192.168.0.0/16 192.168.255.3/32 192.168.255.5/32 192.168.255.7/32
Siguiente salto 192.168.1.2 172.31.31.2 172.31.31.3 172.31.31.4
Etiqta. entrante 44 No tag No tag No tag
Etiqta. saliente No tag 44 44 44
Los campos no tag indican entrada o salida, al o desde el cliente. Siempre hay un campo no tag a la entrada o a la salida en este caso ya que se trata de routers T (de trnsito) y no se realiza una conmutacin pura etiqueta a etiqueta.
6.6.2 VPN B: Routing OSPF; Full-Mesh.

Por ltimo se van a explicar las fases a seguir en la creacin de una segunda VPN, denominada B, en la que aparecern los equipos de cliente U2 y que tendr topologa FullMesh.
92
VPN B
NORTE-U2
NORTE-T
ESTE-U2
RED MPLS ESTE-T OESTE-T OESTE-U2
SUR-T
SUR-U2
Figura 6.13. Equipos involucrados en la VPN-B En esta VPN el routing en los enlaces TU va a ser dinmico mediante OSPF y la topologa que se genera ser una topologa totalmente mallada (full-mesh), como se puede ver en la figura siguiente:
Figura 6.14. Topologa y visin lgica del routing en la VPN-B 93
Ahora los equipos U2 van a tener configurado OSPF rea 0 en los enlaces que les unen al backbone MPLS. Existir una nueva loopback (loopback 172) que estar englobada en distintas reas de la 0. 6.6.2.1. Configuracin en los equipos U2. El routing va a ser dinmico en la VPN-B, por lo tanto habr que configurar OSPF en todos los equipos U2. Router U2# conf t Enter configuration commands, one per line. End with CNTL/Z. Router U2 (config)# int loopback 172 Router U2 (config-if)# ip add <DIR IP LOOPBACK 172> 255.255.255.255 Router U2 (config-if)# router ospf 1 Router U2 (config-router)# passive-interface loop 1 Router U2 (config-router)# passive-interface loop 172 Router U2 (config-router)# network 192.168.0.0 0.0.255.255 area 0 Router U2 (config-router)# network <DIR IP LOOPBACK 172> 0.0.0.0 area <AREA GRUPO> Router U2 (config-router)# end 6.6.2.2 Configuracin de la VRF. Los equipos U2 ya estn preparados. Ahora hay que crear la VRF asociada a esa VPN-B en cada equipo T. En este caso los routers exportan e importan la misma community 65000:100, ya que se trata de un modelo full-mesh.
NORTE-U2
NORTE-T RD=65000:21
65000:100
65000:100
OESTE-U2 65000:100
65000:100
RD=65000:24 OESTE-T 65000:100
RD=65000:23 ESTE-T 65000:100 ESTE-U2
65000:100
65000:100
SUR-T SUR-U2
RD=65000:22
Figura 6.15. Parmetros bsicos para la creacin de las VRF de la VPN-B 94
Como en el caso anterior, las flechas apuntando al equipo T identifican el route-target que debe importar el equipo y las flechas apuntando hacia la nube MPLS identifican el routetarget que debe exportar el equipo. Se configura la VRF de manera anloga a la VPN-A, salvo que ahora los route-target sern iguales (full mesh). Router T# conf t Enter configuration commands, one per line. End with CNTL/Z. Router T (config)# ip vrf < NOMBRE DEL EQUIPO U2> Router T (config-vrf)# rd <VALOR DEL RD segn figura 6.15> Router T (config-vrf)# route-target both <VALOR FLECHAS> Router T (config-vrf)# int <SERIAL QUE UNE A U2> Router T (config-if)# ip vrf forwarding <NOMBRE DE LA VRF (NORTE-U2,...)> En este momento y como en el caso de la VPN-A aparecer un mensaje similar al siguiente, indicando que en dicha interfaz ha desaparecido la configuracin IP al crear la VRF, por lo que habr que volver a configurarla: % Interface Serial0/1 IP address x.y.w.z removed due to enabling VRF Router T (config-if) # ip add 192.168.2.z 255.255.255.252 Router T (config-if) # end Router T # wr Har falta comprobar la conectividad entre el equipo T y el equipo U1 con el ping virtual. ping vrf < NOMBRE VRF > < DIR IP DE U2 EN LA INTERFAZ SERIE> 6.6.2.3. Configuracin del routing dinmico en la VRF. En este paso habr que determinar un proceso de routing OSPF 1 que sea til slo a la VRF que se acaba de configurar. Router T (config) # router ospf 1 vrf <NOMBRE VRF> Router T (config-router)# network 192.168.2.0 0.0.0.255 area 0 Router T (config-router)# end Router T# wr 6.6.2.4. Configuracin de iMBGP Para que los prefijos aprendidos puedan ser transmitidos a los otros equipos T, hay que configurar el iMBGP, como en el caso anterior. De igual manera cuando estn todos los vecinos configurados se puede verificar que iMBGP est activado con el comando sh ip bgp neighbors
95
6.6.2.5. Envo de los prefijos aprendidos localmente al resto de equipos T A continuacin se deben propagar ahora los prefijos locales al resto de equipos T para que stos sepan encaminar los paquetes hacia dichos prefijos. Se pueden comprobar con el comando sh ip route vrf <NOMBRE VRF> los prefijos de la tabla de routing VRF. Slo se van a propagar las loopbacks. Por ltimo se configurar la propagacin de los prefijos en el iMBGP. Como en este caso el equipo T conoce el prefijo de las loopbacks del equipo U2 mediante OSPF, entonces bastar redistribuir dicho protocolo en el iMBGP. Router T# conf t Router T (config)# router bgp 65000 Router T (config-router)# address-family ipv4 vrf <NOMBRE VRF> Router T (config-router-af)# redistribute ospf 1 vrf <NOMBRE VRF> Router T (config-router-af)# end Router T# wr Router T# clear ip bgp * 6.6.2.6. Envo de los prefijos aprendidos por iMBGP al equipo U2 va OSPF Hasta ahora se ha propagado lo que aprende del OSPF local a los equipos T vecinos y el equipo T local ha aprendido por BGP los prefijos que estn propagando los U2 remotos, pero todava no se ha configurado el OSPF de la VRF local, que le propague al U2 local los prefijos aprendidos por BGP. La configuracin sera la siguiente: Router T# conf t Router T (config)# router ospf 1 vrf < NOMBRE VRF> Router T (config-router-af)# redistribute bgp 65000 subnets metric 20 Router T (config-router-af)# end Router T# wr Router T# clear ip bgp * 6.6.2.7. Comprobando la topologa full mesh. A continuacin se comprobar que la topologa resultante coincide con lo que se pretenda configurar: un modelo full-mesh. Para ello hay que realizar dos comprobaciones. Hay que ejecutar el comando traceroute (extendido) hacia la <DIR IP REMOTA> para identificar los saltos que se producen y el camino atravesado desde el equipo U2 de un grupo hacia la direccin IP de la loopback 1 del grupo que est enfrente y desde el mismo U1 hacia la direccin IP de la loopback 172 del equipo U2 del grupo que est a su derecha. 6.6.2.8. Identificacin de etiquetas. Como en el caso anterior una vez que existen prefijos que se propagan por iMBGP, se produce el proceso de asignacin de etiquetas para cada prefijo y aparece la pila de
96
etiquetas/ labels que ya se ha visto en el captulo dedicado a las VPN. La pila queda de igual manera que en el caso VPN-A (ver figura 6.12) Comprobacin de etiquetas asignadas a los prefijos locales de la VPN Al igual que en la VPN-A con el comando show mpls forwarding-table vrf <NOMBRE VRF> se identificar la etiqueta que ha elegido cada equipo T y que notificar a todos aquellos vecinos que quieran enviar trfico a dicho prefijo. Comprobacin de etiquetas asignadas a los prefijos remotos de la misma VPN Con el comando sh ip bgp vpnv4 vrf <NOMBRE VRF> labels se pueden identificar las etiquetas que hay que poner en el paquete MPLS. Con este comando se obtendr informacin anloga a la representada en las tablas del apartado 6.6.1.6 (prefijo, siguiente salto, etiquetas entrante y saliente).
6.6.3 Troubleshooting.
ste es un resumen bsico de actuaciones a realizar para resolucin de problemas en estas redes (troubleshooting): 7.6.3.1 Troubleshooting MPLS Procedimientos de troubleshooting: 1. Verificar que el protocolo de routing est funcionando 2. Verificar el CEF 3. Verificar MPLS 4. Verificar la conectividad entre los vecinos 5. Verificar la distribucin de etiquetas 6. Verificar la asignacin de etiquetas 7. Verificar que se utilizan las etiquetas 7.6.3.2 Troubleshooting VPN-MPLS Troubleshooting. Configuraciones de VRF 1. show ip vrf [vrf-name] 2. show ip vrf [{detail | interfaces}] vrf name 2. Informacin de routing 1. Tabla de routing 3. BGP 4. Protocolo de routing PE-CE 5. Labels 6. Test
97
Glosario
Conclusiones
Durante el desarrollo de este Proyecto Final de Carrera, se han realizado dos tareas muy concretas: Primero, he presentado de manera breve la tecnologa MPLS, haciendo referencia tanto a sus componentes principales como a las diferentes funcionalidades y servicios que se pueden configurar en redes que tengan una troncal que implemente este multiprotocolo. Segundo, se ha modelado y configurado un conjunto de prcticas basadas en el diseo y configuracin de un supuesto real sobre una maqueta de red con troncal MPLS, desarrollando un servicio VPN con el objetivo de que pueda ser usada con fines didcticos para una mayor comprensin del diseo, implementacin, gestin y mantenimiento de una red de estas caractersticas.
En cuanto al primer punto, al describir las caractersticas de MPLS se puede concluir que: MPLS es la evolucin natural de las redes existentes que quieren converger en sistemas de comunicaciones que puedan soportar las capacidades necesarias que el impresionante crecimiento de Internet implica; y al mismo tiempo, que permitan a los administradores de redes controlar el trfico de una forma ms sencilla, visual y especfica. El hecho de simplemente intercambiar etiquetas, en vez de la interpretacin y el procesamiento de todo un encabezado IP en cada salto de un paquete IP, provee una mejor manera de enviar paquetes, lo que al mismo tiempo ofrece la oportunidad de enviar flujos de trfico a una mayor velocidad. Al ser MPLS un multiprotocolo, permite flexibilidad de arquitectura con respecto al medio que se usa como transporte (Tecnologa de Capa 2), como ATM, frame-relay, Ethernet Gigabit, o paquetes sobre SONET (PoS). Como MPLS es una integracin de las tecnologas de Capa 2 y de Capa 3, permite la aplicacin de Ingeniera de Trfico, cuyo objetivo bsico es adaptar los flujos de trfico a los recursos fsicos de la red.
En cuanto al segundo punto y objetivo principal del proyecto, he enumerado los pasos necesarios para la implementacin y diseo, de la forma mas concreta y precisa posible, de una red MPLS y sus servicios de VPN, como la que hemos desarrollado en el laboratorio de la escuela de forma fsica y sobre la que, como ya he comentado anteriormente, se han elaborado un conjunto de prcticas de laboratorio para su realizacin por el alumnado que curse el laboratorio de Redes y Servicios II. He optado por la implementacin de una maqueta VPN con topologa Full-Mesh porque es uno de los servicios que con ms asiduidad se configuran en las operadoras de telecomunicaciones as como pequeas y grandes empresas para preservar la seguridad de sus comunicaciones as como la velocidad en la transmisin de informacin entre diferentes sedes de una misma compaa. Tambin hago mencin a los pasos a seguir para configurar
98
Glosario
una VPN con topologa Hub&Spoke ya que la mayor parte de la configuracin es anloga a una topologa Full-Mesh con pocos cambios que las diferencien. Se han descrito paso a paso, indicando la configuracin del backbone de la red y de los diferentes tipos de protocolos de enrutamiento que deben coexistir con MPLS para que la ingeniera de red este lo ms optimizada posible y dejando patente que este tipo de redes al ser implementadas usando OSPF/BGP/MPLS estn dotadas de una gran escalabilidad. En general, se puede concluir que MPLS, por sus caractersticas, resulta ser la mejor opcin para funcionar como ncleo o backbone de cualquier tipo de red (incluyendo IP, ATM, frame-relay, Ethernet, etc.). MPLS ofrece una mayor estabilidad en lo que respecta al ancho de banda, una mayor confiabilidad para la entrega de informacin (prdida de paquetes), mejores mecanismos de sealizacin, un envo de paquetes mucho ms rpido, y la capacidad de adecuacin a las necesidades del administrador de red como consecuencia del uso de aplicaciones de ingeniera de trfico. Y por ltimo desde el punto de vista personal, la realizacin de este Proyecto Final de Carrera, ha supuesto para m un importante incremento curricular en las reas relacionadas con el mismo que describo brevemente a continuacin. A lo largo del desarrollo del proyecto he ido adquiriendo conocimientos ms profundos en protocolos de comunicaciones como OSPF, BGP y sobre todo MPLS, pero lo mas importante ha sido el poder llevarlo a la prctica, con total libertad, y sin limitaciones de configuracin (obviamente teniendo en cuenta la equipacin con la que hemos contado, y las limitaciones intrnsecas a estos equipos). He podido realizar labores de ingeniera de red, en el diseo del backbone MPLS, he impartido un seminario sobre el funcionamiento y servicios soportados por MPLS, as como sobre los conceptos bsicos de las redes privadas virtuales sobre MPLS, haciendo especial hincapi en sus ventajas y limitaciones. Tambin he realizado labores de consultor ayudando a Oscar Prieto en la realizacin de su Proyecto Final de Carrera (con el que he colaborado en la configuracin de la red) a resolver dudas de configuracin y resolucin de problemas de red.
Comentario [m4]: No se como quieres que ponga la referencia al proyecto de Oscar, Asi o de otra forma? Comentario [RDM5]: Ponlo en las referencias bibliogrficas. Pdele a Oscar el ttulo. Mejor que Oscar Prueto algo as: Al realziarse el trabajo en colaboracin con otro compaero [ref]he tenido tambin ocasin de trabajar como consultor.
99
Glosario
Glosario
A
AAL ABR AF API AS ATM ATM Adaptation Layer. Nivel de adaptacin ATM. Available Bit Rate. Categora de servicio ATM, ancho de banda disponible en el tiempo. Assured Forwarding. Reenvo asegurado. Application Program Interface. Programa de aplicacin de interfz. Autonomous System. Sistema Autnomo. Asynchronous Transfer Mode. Modo de transferencia asncrono.
B
Backbone BBE Bc BDR Be BGP BW Conjunto de routers que componen la parte troncal de una red. Better than Best Effort. Servicio de flujo de datos IP. Committ burst. Rfaga acordada, parmetro de configuracin de Frame Relay. Back-up Designated Router. Router designado de back-up. Excess burst. Rfaga de exceso, parmetro de configuracin de Frame Relay Border Gateway Protocol. Protocolo de pasarela externa. BandWidth. Ancho de banda.
C
CBQ CBR CCIT Class Based Queing, Es un trmino general que se refiere a cualquier mecanismo basado en clases Constant Bit Rate. Categora de servicio ATM, ancho de banda constante. Consultative Committee for International Telegraphy and Telephony. Comit Consultivo Internacional Telegrfico y Telefnico. Router del cliente que conecta el site del cliente a la red del proveedor de servicio. Cisco Express Forwarding. Conjunto de funcionalidades de los routers Cisco para poder ejecutar MPLS Channel Identifier. identificador de canal. Committed information rate. Parmetro de configuracin de Frame Relay. Cell Loss Priority. Prioridad de prdida de celdas ATM. Communications Port. Puerto de comunicaciones. Ncleo de una red. Central Processing Unit. Unidad de proceso central. Cyclic Redundancy Code. Cdigo de redundancia cclica.
CE CEF CID CIR CLP COM Core CPU CRC
100
Glosario
CR-LDP CSC
Constraint-based Routing LDP. Encaminamiento basado en restricciones del protocolo de distribucin de etiquetas. Class Selector Codepoint. Cdigo selector de clase.
D
DE DIATEL DiffSer DLCI DR DRAM DS DSCP Default Behaviour. Comportamiento por defecto. Tipo de PHB (ver PHB). Departamento de Arquitectura e Ingeniera Telemtica. Differentiated Services. Servicios diferenciados. Data Link Connection Identifier. identificador de la conexin del enlace de datos. Designated Router. Router designado. Dynamic Random Access Memory. Memoria de acceso aleatorio dinmico Byte Differentiated Services de un paquete IPV4 Differentiated Services Codepoint. Cdigo de servicios diferenciados, campo que forma parte del byte DS de un paquete IPV4.
E
EF EGP ELL ER-LSP ERP Ethernet EVLL Expedited Forwarding. Reenvi acelerado. Tipo de PHB (ver PHB). External Gateway Protocol. Protocolo exterior de pasarela. Emulated Leased Line. Tipo de servicio de flujo de datos IP. Explicit-Routed LSP. Encaminamiento explcito LSP. Enterprise Resource Planning. Sistemas de planificacin de recursos de empresa Protocolo para redes de rea local Emulated Virtual Leased Line. Tipo de servicio de flujo de datos IP.
F
FEC FIB FIFO Frame Relay FTP Full-Mesh Functional Equivalence Class. Clase de equivalencia funcional. Forwarding Information Base. Base de informacin del reenvo. First In First Out. Cola, Primero en entrar, primero en salir. Protocolo para la transmisin rpida de datos digitales en redes de comunicaciones. File Transfer Protocol. Protocolo de transferencia de ficheros, sistema de transferencia de ficheros en Internet Totalmente mallado.
101
Glosario
G
GFR GSR Guaranteed Frame Rate. Categora de servicio ATM. Gigabit Switch Routers. Conmutador-enrutador con capacidad de varios gigabits
I
IBS ID IETF IGP iMBGP IOS IP IPSEC IPv6 IPX IS-IS ISP IP Bearer Services. Servicios de flujos de datos IP. Identificador. Internet Engineering Task Force. Grupo de trabajo de ingenieros de Internet. Interior Gateway Protocol. Protocolo interior de pasarela. Internal Multiprotocol Border Gateway. Extensin de BGP para su utilizacin entre otros junto al protocolo MPLS. Internetwork Operating System. Sistema Operativo de Interconexin de Redes. Creado por Cisco Systems. Internet Protocol. Protocolo de Internet. Internet Protocol security. Extensin al protocolo IP al que aade servicios de seguridad. IP versin 6. Internetwork Packet Exchange. Intercambio de paquetes Inter-red. Intermediate System-Intermediate System. Protocolo de enrutamiento interno. Internet Service Provider. Proveedor de servicios del Internet
L
Label Label Stack LAN LDP LER LFIB Etiqueta. Pila de Etiquetas. Local Area Network. Red de rea local. Label Distribution Protocol. Protocolo de distribucin de etiquetas. Label Edge Router. Encaminador de etiquetas frontera. Label Forwarding Information Base. Tabla incluida en el servicio MPLS en routers Cisco con la informacin de envo y recepcin de etiquetas. Label Information Base. Tabla incluida en el servicio MPLS en routers Cisco con el listado de etiquetas a utilizar. Last In First Out. Cola, ultimo en entrar, primero en salir. Label Switched Path. Camino de conmutacin de etiquetas. Label Switching Router. Encaminador de conmutacin de etiquetas.
LIB LIFO LSP LSR
102
Glosario
M
MED Multi-Exit Discriminator Attribute. Atributo de configuracin de BGP, para determinar la mejor ruta de salida para un paquete. Multiprotocol Label Switching. Multiprotocolo de conmutacin de etiquetas. Maximum Transmission Unit. Unidad mxima de transmisin.
MPLS MTU
N
NAK nrt-VBR Negative Acknoledge. Notificacin de error. Non real time Variable Bit Rate. Flujo variable de bits en tiempo no real, servicio ATM.
O
OSI OSPF Open System Interconnection. Sistema de interconexin abierta. Open Shortest Path First. Protocolo abierto del primer camino ms corto.
P
P Partial Mesh PC PDU PE PFC PHB PHP Router del ncleo de red o backbone en un dominio MPLS. Mallado parcial. Personal Computer. Ordenador personal. Protocol Data Unit. Unidad de datos del protocolo. Router de acceso de una red no MPLS a un dominio MPLS. Proyecto final de carrera. Per-Hop-Behaviour. Comportamiento por salto. Penultimate-Hop-Popping. Proceso en el que el ltimo router de un dominio MPLS retira la etiqueta y enva un paquete IP sin etiqueta. Point to Point Protocol. Protocolo punto a punto. Permanent Virtual Circuit. Circuito virtual permanente.
PPP PVC
Q
QoS Quality Of Service. Calidad de servicio.
R
RD RDSI Red C Route Distinguisher. Valor de 64 bits que se usa para evitar el solapamiento de direcciones IP en un entorno iMBGP. Red digital de servicios integrados. Conjunto de routers en la sede de cliente que estn enfrentados a un dominio MPLS. 103
Glosario
Red P RESV RFC RIP Router-T Router-U RSVP RSVP-TE RT rt-VBR
Conjunto de routers del backbone o ncleo de red de un dominio MPLS. Mensaje de RSVP que indica la reserva de recursos de red. Request For Comments. Documento de especificaciones del IETF. Routing Information Protocol. Protocolo de informacin de encaminamiento. Otra nomenclatura utilizada para denominar a los routers PE ( Ver PE ). Otra nomenclatura utilizada para denominar a los routers CE ( Ver CE ). Resource reSerVation Protocol. Protocolo de reserva de recursos. RSVP tunnel Extensions. Extensiones de RSVP para tneles LSP. Route Target. Identificadores de prefijos a exportar e importar en una VPN. Real time Variable Bit Rate. Flujo variable de bits en tiempo real, servicio ATM.
S
Shim Label SLA SNMP SONET SVC Formada por 32 bits, se usa para identificar localmente un FEC en Ethernet. Service Level Agreement. Acuerdo de Nivel de Servicio. Simple Network Management Protocol. Protocolo simple de gestin de redes. Synchronous Optical Network. Es un estndar para el transporte de telecomunicaciones sobre redes de fibra ptica. Switched Virtual Circuit. Circuito virtual conmutado.
T
TCP TCP/IP TDP Transmision Control Protocol. Protocolo de control de la transmisin. Transmisin Control Protocol/Internet Protocol. Protocolo de control de la transmisin/Protocolo IP. Tag Distribution protocol es un protocolo de distribucin de etiquetas propietario de Cisco que es muy similar al estndar LDP Traffic Engineering. Ingeniera de Trfico. Tag information base, igual que LIB para LDP. Tipo-Longitud-Valor, Tipo de estructura comn de todos los mensajes LDP. Type Of Service. Tipo de servicio. Time To Live. Tiempo de vida.
TE TIB TLV TOS TTL
104
Glosario
U
UBR UDP Unspecific Bit Rate. Flujo de bits con ancho de banda sin especificar, categora de servicio ATM. User Datagram Protocol. Protocolo de datagramas de usuario.
V
VCI VC VoIP VPI VPN VPN-MPLS VRF Virtual Channel Identifier. Identificador de canal virtual. Virtual Channel. Canal virtual. Voice over Internet Protocol. Voz sobre Protocolo Internet. Virtual Path Identifier. Identificador de trayecto virtual. Virtual Private Network. Red privada virtual. Virtual Private Network MPLS. Red privada virtual sobre MPLS. Virtual Routing and Forwarding table. Tabla de rutas y reenvi en un router PE perteneciente a un VPN-MPLS.
X
x.25 Estndar para redes de paquetes recomendado por CCITT
105
Bibliografa y Referencias
BGP
RFC 1771. A Border Gateway Protocol 4 (BGP-4). RFC 1772. Application of the Border Gateway Protocol in the Internet. RFC 1773. Experience with the BGP-4 protocol. RFC 1774 . BGP-4 Protocol Analysis. RFC 1997. BGP Communities Attribute. RFC 1998. An Application of the BGP Community Attribute in Multihome Routing, RFC 2796. BGP Route Reflection An alternative to full mesh IBGP. RFC 3065. Autonomous System Confederations for BGP. Parkhurst, William R., and David R. Jackson. Practical BGP for Internet Routing. Cisco Press, Indianapolis, in press. Advanced BGP and Troubleshooting, Cisco press, Session 317, 1998. Dominique, Jean Simon. BGP-4 Advanced Tutorial, Nortel Networks, 2005. William R, Cisco BGP-4 Command and configuration Handbook, Cisco press, 2002
Con formato: Sangra: Izquierda: 18,3 pto, Con vietas + Nivel: 1 + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36
Con formato: Sangra: Izquierda: 17,85 pto, Sangra francesa: 17,85 pto, Con vietas + Nivel: 1 + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36 Con formato: Sangra: Izquierda: 17,85 pto, Sangra francesa: 17,85 pto, Con vietas + Nivel: 1 + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36 pto
LDP y Traffic Engineering

RFC 3036. LDP Specification RFC 3212. Constraint-Based LSP Setup using LDP. RFC 3213. Applicability Statement for CR-LDP. RFC 3209. RSVP-TE: Extensions to RSVP for LSP Tunnels Welcher. Peter, RSVP- Resource Reservation Protocol, Chesapeake NetCraftsmen, tambin en http://www.netcraftsmen.net/welcher/papers/index.htm, Sep 1999. Deploying MPLS traffic engineering, Cisco Press, Session RST-2603, May.2004. Configuring MPLS Basic Traffic Engineering Using OSPF, Cisco System Inc.
2003. MPLS Basic Traffic Engineering Using OSPF Configuration, Cisco Systems Inc. 2005.
Con formato: Sangra: Izquierda: 18,3 pto, Con vietas + Nivel: 1 + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36 pto Con formato: Sangra: Izquierda: 18,3 pto, Con vietas + Nivel: 1 + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36 pto, Punto de tabulacin: No en 36 pto
Miscelaneous
Stallings, William, Computer Networking with Internet Protocols, Prentice Hall, 2004 Joe Habraken, Routers Cisco, Prentice Hall.Pearson Education, Madrid 2000 David Culley, Crish Fuchs, Duncan Sharp, Network protocols and performance , April 2001. 106
Con formato: Sangra: Izquierda: 17,85 pto, Sangra francesa: 17,85 pto, Con vietas + Nivel: 1 + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36 pto
B.Williams. Quality of Service. Diff-Serv & MPLS , Ericsson. March 2000 MPLS Quality of Service (QoS), Cisco Systems Inc. 2005. Alvarez. S. QoS in MPLS Networks, Cisco press, Session RST-1607 A.S. Tanenbaum "Redes de ordenadores, tercera edicin", Editorial Prentice-Hall, 1997. R. Perlman Interconnections Bridges and Routes ,Ed. Addison-Wesley, 1993. Gua rpida de los routers de la serie Cisco 1800 de servicios integrados (modulares), Cisco Systems Inc. 2004 Gua rpida para routers de la serie Cisco 2800 de servicios integrados. , Cisco Systems Inc. 2004.
MPLS
RFC 3031. MultiProtocol Label Switching Architecture. RFC 3032. MPLS Label Stack Encoding. RFC 3443. Time to Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks. Netplane Inc, Layer 3 Switching using MPLS. White paper, Dic.2000 Regan. J, CCIP- MPLS Student Guide, Sybex, Alameda Ca , 2002 Multiprotocol Label Switching (MPLS) , The International Engineering Consortium, Tutorial, tambin disponible en: http://www.iec.org Jamoussi, Bilel, Nortel Networks MPLS eSeminar, Nortel Networks. May 30, 2001 Nortel Networks, MPLS An introduction to MultiProtocol label switching, Marketing Publications, April 2001. MPLS Advanced concepts and developments in MPLS, Cisco Press, Session RST-2T09, Jun. 2004. Introduction to MPLS, Cisco Press, Session RST-1601, May. 2004.
Con formato: Sangra: Izquierda: 18,3 pto, Con vietas + Nivel: 1 + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36 pto Con formato: Sangra: Sangra francesa: 17,85 pto, Con vietas + Nivel: 1 + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36 pto Con formato: Sangra: Izquierda: 17,85 pto, Sangra francesa: 17,85 pto, Con vietas + Nivel: 1 + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36 Con formato: Sangra: Izquierda: 17,85 pto, Sangra francesa: 17,85 pto, Con vietas + Nivel: 1 + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36
OSPF
RFC 2328, The Open Shortest Path First (OSPF) protocol. Halabi. S, OSPF Design Guide, Cisco Press, April 1996. Configuring Basic MPLS using OSPF, Cisco System Inc. 2003. William R. Parkhurst,Cisco Router OSPF, McGraw-Hill Cisco Technical Expert Titles, 1998.
107
VPN-MPLS
RFC2547 bis. VPN MPLS. Guichard, Jim and I. Pepelnjak. MPLS and VPN Architectures: A Practical Guide to Understanding, Designing and Deploying MPLS and MPLS-Enabled VPN. Cisco Press, 2000. How to Troubleshoot the MPLS VPN, Cisco Systems Inc. 2005.
Troubleshooting LSP Failure in MPLS VPN, Cisco Systems Inc. 2005.
Con formato: Sangra: Izquierda: 18,3 pto, Con vietas + Nivel: 1 + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36 Con formato: Sangra: Izquierda: 18,45 pto, Sangra francesa: 17,85 pto, Con vietas + Nivel: 1 + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36 Con formato: Sangra: Izquierda: 17,85 pto, Sangra francesa: 17,85 pto, Con vietas + Nivel: 1 + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36
Cisco Press. Cisco remote access to MPLS VPN integration 2.0 overview and provisioning guide. Cisco Press, Julio 2002. Scott, C., Wolfe. P, Erwin. Mike, Virtual Private Networks, OReally, Enero 1999. Tomsu, Peter and G. Weiser. MPLS-Based VPN. Prentice Hall, 2001. Jim Guichard, Ivan Pepelnjak, Jeff Apcar, MPLS and VPN Architectures, Volume II, Cisco Press, Junio 2003. MPLS Virtual Private Networks (VPN). Cisco Systems Inc. 2003. MPLS VPN Design Guidelines, Cisco Systems Inc. Bootcamp. 2000 Troubleshooting MPLS VPN Networks,Cisco Press, Session RST-3061 VPLS & BGP MPLS VPN, VPLS.ORG Feature Paper. 2004. www.vpls.org
108
Anexo A: Manual Rpido de Configuracin MPLS de un Router Cisco
Anexo A
Laboratorio de Redes y Servicios II. Diatel Manual Rpido de Configuracin MPLS de un Router Cisco
Este documento describe de forma resumida los principales comandos de configuracin de un router Cisco para que pueda trabajar en un dominio MPLS, como los disponibles en el laboratorio de Redes y Servicios II del Departamento de Ingeniera y Arquitecturas Telemticas.
1. Configuracin de una interfaz Loopback

La interfaz de loopback servir para el identificador del router. Una interfaz de loopback se crea de la siguiente manera: cisco# configure terminal cisco(config)# interface loopback<nmero de la interfaz> cisco(config-if)# ip address <direccin IP> <mscara> El motivo de configurar una interfaz de loopback es que, como se ver ms adelante en la configuracin de OSPF y de BGP, esta interfaz se asociara a los procesos OSPF y BGP, asegurndo de esta forma que no se van a perder las sesiones OSPF o BGP por un problema fsico en el interfaz ya que las interfaces de loopback son interfaces lgicas.
2. Configuracin bsica de OSPF

Configurar OSPF como protocolo de routing dinmico en el futuro backbone MPLS. Ver el punto 10 de Configuracin bsica de OSPF del Manual Rpido de Configuracin de un router Cisco disponible en la web de la asignatura. Recordar que OSPF es un protocolo de routing interno (IGP) del tipo estado de enlace. Los equipos anuncian toda la informacin al arrancar el protocolo. Se enviarn entre s paquetes link state cuando se detectan fallos en algn enlace. Entonces, todos los routers actualizan la base de datos topolgica, se copian los link state e inundan a los vecinos. Por tanto, slo se van enviando las nuevas actualizaciones de rutas (y no la tabla completa). Un comando de gran importancia para comprobar las adyacencias OSPF es: show ip route
109
Permite ver la tabla de rutas del router donde se ejecuta el comando y si el router aprende las rutas por OSPF.
Verificacin del estado de OSPF

Se puede comprobar el estado de OSPF por interfaz as como los vecinos OSPF que habr en un interfaz, mediante los comandos siguientes: show ip ospf interface show ip ospf neighbors
3. Configuracin bsica de BGP

Antes de configurar MPLS en la red, hay que establecer un full-mesh de sesiones BGP en el backbone y as dejar preparado el escenario de red para la configuracin final de MPLS en los routers. El uso de BGP en un dominio MPLS no es del todo necesario, ya que se puede implementar una red con funcionalidad MPLS sobre OSPF directamente, el hecho de configurar BGP en un dominio MPLS es para dejarlo preparado por si se quieren crear servicios de redes privadas virtuales sobre MPLS (VPN-MPLS) que s necesitan la configuracin de un protocolo del tipo de BGP para poder ofrecer servicio. La configuracin de BGP requiere los siguientes pasos: 1. Configurar el proceso de routing BGP: cisco# configure terminal cisco(config)# router bgp <nmero de proceso BGP> El nmero de proceso BGP que generalmente se pone es el 65000, para entorno de pruebas, ya que hay otras numeraciones que estn reservadas, lo que realmente se esta configurando con el comando router bgp <numero de proceso BGP> es el sistema autnomo en el que se quiere que se hable BGP. 2. Para cada pareja de routers que estn enfrentados hay que configurar lo siguiente: En uno de los routers especifica el router vecino y le se le indica que actualice el encaminamiento a travs de la interfaz de loopback configurada anteriormente: cisco(config-router)# neighbor <dir IP de la interfaz del vecino que tiene enfrentada> remote-as <nmero de proceso BGP > cisco(config-router)# neighbor <dir IP de la interfaz del vecino que tiene enfrentada > update-source loopback<nmero de la interfaz>
Con formato: Sangra: Sangra francesa: 36 pto, Numerado + Nivel: 1 + Estilo de numeracin: 1, 2, 3, + Iniciar en: 1 + Alineacin: Izquierda + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36 pto, Punto de tabulacin: 9 pto, Lista con tabulaciones + No en 36 pto
110
En el otro router hay que especificar el router vecino con la interfaz de loopback con la que se le ha indicado que actualice el encaminamiento: cisco(config-router)# neighbor <dir IP de la interfaz de loopback del vecino> remote-as <nmero de proceso BGP >
Verificacin del estado de BGP

Algunos comandos de inters relacionados con BGP para verificar su funcionamiento, son los siguientes: 1. show ip bgp neighbor Muestra los routers que mantienen una relacin de vecindad con el router en el que se ejecuta el comando, as como la informacin relativa a esa relacin. 2. show ip bgp summary Muestra los routers que mantienen una relacin de vecindad con el router en el que se ejecuta el comando, as como el estado en el que se encuentran. 3. clear ip bgp * Permite resetear las sesiones BGP establecidas.
4. Configuracin bsica de MPLS

Una vez establecidos los protocolos de routing se han de establecer las funcionalidades MPLS en los routers. Para ello hay que arrancar el protocolo de distribucin de etiquetas en las distintas interfaces por las que se va a hablar MPLS. La configuracin de MPLS requiere los siguientes pasos: 1. Configurar el CEF (Cisco Express Forwarding) en todos los routers con funcionalidad PE y P, CEF es el conjunto de funcionalidades que renen los equipos Cisco para poder trabajar en un entorno MPLS entre otras funciones. Los comandos que hay que ejecutar para activar CEF en un router que soporte estas funcionalidades son: cisco# configure terminal cisco(config)# ip cef Para comprobar si se ha activado CEF correctamente se utilizara el siguiente comando: show ip cef summary
111
En caso de que no se hubiese habilitado CEF no saldra nada a la salida de este comando. 2. Activacin del protocolo de distribucin de etiquetas LDP: Hay que realizar la siguiente configuracin en cada interfaz que vaya a hablar MPLS: cisco(config)# interface <nombre de la interfaz> cisco(config-if # mpls ip cisco(config-if)# mpls label protocol ldp
Verificacin del funcionamiento de MPLS en la red

Para realizar la verificacin del funcionamiento de MPLS, algunos comandos de inters son los siguientes: 1. show mpls interfaces Muestra las interfaces en las que est funcionando MPLS-LDP. 2. show mpls ldp parameters Muestra los parmetros que est utilizando el protocolo en el equipo donde se ejecuta el comando. 3. show mpls ldp neighbor Muestra los routers que mantienen una relacin de vecindad con el router en el que se ejecuta el comando. 4. show mpls ldp binding Muestra la tabla de etiquetas que est utilizando el router donde se ejecuta el comando. 5. show mpls forwarding-table Muestra la tabla de forwarding del router donde se ejecuta el comando.
5. Configuracin de VPN sobre MPLS

La configuracin que se detalla a continuacin es para crear VPN en las que el encaminamiento entre los equipos de cliente (CE) y los equipos del proveedor (PE) se realiza de forma dinmica mediante OSPF y la topologa que se generar ser totalmente mallada (Full-Mesh). Hay una configuracin distinta segn se este trabajando en un equipo de cliente (CE) o en un equipo de proveedor (PE). Los routers con funcionalidad CE van a tener configurado el proceso 255 de OSPF en el rea 0 en los enlaces que les unen al backbone MPLS, ya que es el proceso configurado en
112
el backbone. Adems, tendrn configurado otro proceso OSPF para las reas distintas de la cero.
Configuracin de equipos con funcionalidad PE

La configuracin de VPN sobre MPLS requiere los siguientes pasos en cada uno de los routers con funcionalidad PE: 1. Configuracin de la VRF asociada a la VPN que se va a configurar en los routers con funcionalidad PE: Una VRF (VPN routing and forwarding) incluye las tablas de envo y encaminamiento de los sitios pertenecientes a una VPN. Los parmetros necesarios para crearla son:

Route Distinguisher (RD) que permite identificar unvocamente un prefijo de VPNIPv4. Route-Target (RT) que identifica los routers que deben recibir la ruta. cisco# configure terminal cisco (config)# ip vrf <nombre de la VRF> cisco(config-vrf)# rd <valor del rd> cisco(config-vrf)# route-target export <valor que tiene que exportar> cisco(config-vrf)# route-target import <valor que tiene que importar>
El siguiente comando unifica en uno solo los dos ltimos, para indicar que el router donde se ejecuta debe exportar e importar el mismos route-target: cisco(config-vrf)# route-target both <valor que tiene que importar y exportar> NOTA: Los parmetros rd y route-target se pueden extraer del dibujo de la VPN en el enunciado de la prctica. 2. Configuracin del forwarding en las interfaces de los routers PE que estn enfrentadas a los routers CE: cisco# configure terminal cisco(config)# interface <nombre de la interfaz> cisco(config-if)# ip vrf forwarding <nombre de la VRF> 3. Asignacin de la direccin IP a la interfaz donde se acaba de de configurar el forwarding dentro de la VPN, ya que pierde el direccionamiento de dicha interfaz. Despus de ejecutar este ltimo comando se mostrar un mensaje indicando que en la interfaz anterior se le ha quitado la configuracin IP, por lo que habr que volver a configurarla: cisco(config-if)# ip address <direccin IP> <mscara>
113
4. Configuracin del encaminamiento dinmico en la VRF creada: - Hay que arrancar un nuevo proceso OSPF dedicado al encaminamiento dentro de la VRF: cisco# configure terminal cisco(config)# router ospf <identificador del proceso> vrf <nombre VRF> - Definir el rea en la que se encuentran las interfaces pertenecientes a la VPN: cisco(config-router)# network <red> <wildcard>area 0 Por ejemplo: cisco(config-router)# network 192.168.43.0 0.0.0.255 area 0 5. Configuracin de iMBGP: Para que los prefijos aprendidos puedan ser transmitidos a los otros equipos PE, hay que configurar iMBGP siguiendo los siguientes pasos: Comprobar que los vecinos iBGP siguen activos y operativos. Utilizar el comando show ip bgp summary. Hay que preparar la configuracin de BGP del router: cisco# configure terminal cisco(config)# router bgp <nmero de proceso BGP que est configurado> Configurar iMBGP para la VPN: cisco(config-router)#address-family vpnv4 Hay que activar los vecinos existentes con la nueva funcionalidad. Segn se vayan ejecutando los comandos siguientes se irn reseteando las sesiones BGP, este comportamiento es normal porque los vecinos renegocian sus capabilities. Configurar para cada vecino iBGP mostrado con el comando show ip bgp summary lo siguiente: cisco(config-router-af)# neighbor <dir IP del vecino iBGP> activate cisco(config-router-af)#neighbor <dir IP del vecino iBGP> send-community both
114
6. Configuracin del envo de los prefijos aprendidos al resto de los equipos con funcionalidad PE. Una vez establecidas las sesiones iMBGP con el resto de equipos PE y verificada la conectividad local con los integrantes de la VPN, queda pendiente propagar los prefijos locales al resto de equipos PE para que stos sepan encaminar los paquetes hacia dichos prefijos. Para ello, bastar con redistribuir OSPF en el iMBGP: cisco# configure terminal cisco(config)# router bgp <nmero de proceso BGP que est configurado> cisco(config-router)# address-family ipv4 vrf <nombre del VRF> cisco(config-router-af)# redistribute ospf <identificador del proceso OSPF> vrf <nombre del VRF> NOTA: El identificador del proceso OSPF se corresponde con el identificador del proceso OSPF que se ha utilizado para configurar el encaminamiento dinmico en la VRF en el paso 4. 7. Configuracin del envo de los prefijos aprendidos a los equipos con funcionalidad CE: cisco# configure terminal cisco(config)# router ospf <identificador del proceso OSPF> vrf <nombre del VRF> cisco(config-router)# redistribute bgp <nmero de proceso BGP que est configurado> subnets metric 20
Verificacin del funcionamiento de la VPN-MPLS

Con los siguientes comandos se puede verificar que la VPN que se ha configurado est funcionando segn lo esperado: 1. show ip route vrf <nombre VRF> Con este comando se pueden comprobar los prefijos que se han exportado y los que se han importado en la tabla de routing de la VRF y por ende los prefijos que formarn parte de la VPN. 2. traceroute vrf <nombre VRF> <Direccin a la que se quiere llegar> El funcionamiento de este comando es exactamente el mismo que el de un traceroute normal, pero para comprobar el funcionamiento de la VPN y usando direcciones destino de la propia VPN, con origen un equipo que pertenezca a la misma VPN se necesita aadir el parmetro vrf junto al nombre de la vrf que pertenece la VPN. 3. ping vrf <nombre VRF> <Direccin a la que se quiere llegar> El funcionamiento es exactamente el mismo que el de un ping normal, la explicacin del uso del parmetro vrf se aplica exactamente igual que en el comando anterior.
Con formato: Sangra: Sangra francesa: 36 pto, Numerado + Nivel: 1 + Estilo de numeracin: 1, 2, 3, + Iniciar en: 1 + Alineacin: Izquierda + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36 pto Con formato: Sangra: Sangra francesa: 36 pto, Numerado + Nivel: 1 + Estilo de numeracin: 1, 2, 3, + Iniciar en: 1 + Alineacin: Izquierda + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36 pto
115
Anexo B: Prcticas Propuestas
Anexo B
En este anexo se incluyen las prcticas que se han propuesto para el laboratorio de Redes y Servicios del departamento DIATEL de la EUITT de la Universidad Politcnica de Madrid. Estas prcticas han sido desarrolladas integramente con el material disponible en el laboratorio de Redes y Servicios. Se ha realizado el diseo de la red y la configuracin de los diferentes servicios propuestos en las prcticas intentando hacerlo de la forma ms sencilla y didctica posible para que puedan ser seguidas sin problemas por los alumnos que las cursen. La primera prctica propuesta esta pensada para que los alumnos se familiaricen con un dominio MPLS, similar al que se pueden encontrar en una red en produccin en cualquier operador de servicios de telecomunicaciones en un entorno laboral. En esta primera prctica tendrn que configurar un backbone que hable MPLS partiendo de una red IP genrica. As, tendrn que configurar OSPF, BGP y MPLS para de esta forma tener preparado el backbone de red y poder empezar a configurar servicios. En la segunda prctica propuesta, se tratara de configurar diferentes servicios VPN sobre un backbone MPLS, en concreto se trata de configurar una VPN con topologa Full-Mesh y otra VPN con topologa Hub & Spoke, y realizar una serie de actividades sobre estas VPN para comprender mejor su funcionamiento as como el de MPLS.
116
Prctica 1: Configuracin y Administracin de una red MPLS/IP (1 parte).

1. Introduccin y descripcin de la red experimental
El escenario del laboratorio para esta primera parte de las prcticas es el que se muestra en las figuras 1 y 2:
Figura 1. Puesto 1
Figura 2. Puesto 2 Como puede observarse, habr 2 grupos, en cada grupo se dispondr de 4 routers interconectados para utilizarlos en las prcticas que a continuacin se desarrollan. En la figura anterior se muestran los equipos que corresponden a los grupos y las conexiones existentes en cada una de ellas. La red troncal la integran dos routers Cisco 2811 capaces de hablar MPLS con funcionalidad PE. Cada uno de ellos tiene interconectado un router Cisco 1841, con funcionalidad CE, que a su vez tiene interconectada una red con un PC.
117
Todos los segmentos de red utilizados estn basados en Fast Ethernet. Para poder analizar el trfico que fluye entre los routers de la troncal se ha pinchado un PC en el que se ejecutar Ethereal. Ha sido necesario configurar el puerto al que est conectado este PC en el conmutador ethernet con la funcionalidad de port-mirror. Esta primera parte de la prctica de MPLS est dividida en dos fases: 1. Parte 1: Configuracin de OSPF y BGP. 2. Parte 2: MPLS-LDP La configuracin de OSPF se ha de realizar para que el proceso MPLS pueda conocer la estructura de la red extrada de la base de datos de topologa OSPF. La configuracin de BGP se har de cara a la 2 parte de la prctica, dado que se utilizar en la creacin de las VPN implementadas en dicha parte. La segunda parte de la prctica permitir aprender cmo se configura una red MPLS en routers Cisco. Sobre dicha red se realizar una captura y un anlisis del trfico generado.
Acceso a los equipos:

Los equipos sern accedidos por la consola a travs del servidor de consolas. La consola de los equipos de Clientes (CE) y la de los equipos con funcionalidad PE estar conectada al servidor de consolas. La consola de los equipos de cada grupo ser accesible mediante telnet al nombre del servidor de consolas (cs1.lab.diatel.upm.es) indicando el puerto correspondiente al equipo que vayamos a configurar y que son los que se muestran en la siguiente tabla:
Router Cisco2800_1 Cisco2800_2 Cisco2800_3 Cisco2800_4 Cisco1800_1 Cisco1800_2 Cisco1800_3 Cisco1800_4 Cisco1800_5
Puerto 41 42 43 44 45 46 47 48 49
118
2. Configuracin preliminar de los puestos de trabajo
Configurar las interfaces ethernet de los PC D16-D12 o D06-D08 de acuerdo a la numeracin IP descrita en la figura 1. Como las conexiones son Ethernet, es conveniente deshabilitar las conexiones serie de los routers y dejarlas en estado DOWN. Para que no haya ningn problema, debe comenzarse la prctica reseteando los routers y as empezar la configuracin desde cero. Comprubese que todas las interfaces entre los equipos PE estn UP, UP y que el direccionamiento coincide con el que indica la figura anterior. Para la comprobacin se usar el comando show ip interface brief o show interfaces en los equipos del backbone. Comprubese la conectividad de los equipos del backbone con sus vecinos directamente conectados. Utilice el comando ping.
3. Configuracin de OSPF
Esta parte de la prctica tiene como objetivo establecer como protocolo de routing dinmico el OSPF en el futuro backbone MPLS. En la figura siguiente se puede ver el rea que abarcara el protocolo de routing y las direcciones que deben propagarse por dicho protocolo.
Figura 3. Mapa cobertura OSPF Puesto 1
Figura 4. Mapa cobertura OSPF Puesto 2
119
No existir ningn tipo de redistribucin (en nuestro caso). Todas las direcciones deben ser propagadas como nativas en el protocolo OSPF. En este caso se usar el rea OSPF 0 que es la nica obligatoria, y al que deben pertenecer todos los equipos. Abra una sesin del analizador de protocolos Ethereal en el PC dispuesto para ello en la red troncal. El objetivo ser capturar los paquetes OSPF que circulen por el enlace entre los dos equipos del backbone y adems poder comprobar posibles problemas de conectividad. Hay que configurar OSPF tanto en los routers de la nube como en los equipos de cliente para que haya una conectividad total en cada uno de los puestos. A la hora de configurar OSPF es importante elegir adecuadamente los identificadores que utilizar el protocolo para nombrar a cada router. Si no se especifica nada, el router eligir como identificador una de sus direcciones IP. Comprobar qu direccin eligen los routers de Cisco como identificador de OSPF. En los PC hay que crear una ruta esttica hacia la red de cada puesto, configurando como puerta de enlace la interfaz del router que tiene directamente conectado.
Verificacin del funcionamiento de OSPF

Conectividad Comprobar que existe conectividad en toda la red realizando ping desde los PC a todos los equipos de la red. Interfaces Todas las interfaces que abarca el rea OSPF en la figura anterior deben estar activas en el protocolo OSPF. Para comprobarlo utilizar el comando: show ip ospf interface Fjese en que las interfaces estn UP, en que el estado del protocolo no sea DOWN, en el identificador del router (Router ID), en el DR (Designated Router) y en el BDR (Backup Designated Router). Para comprobar que se ha ejecutado los pasos anteriores de forma correcta y el protocolo OSPF est activo en todo el rea que debe abarcar habra que rellenar la tabla siguiente:
Interfaz rea ID IP Interfaz Tipo Coste Estado Existe DR/BDR Quin es el DR
120
Vecinos Para poder propagar prefijos de routing tienen que haberse establecido adyacencias con los vecinos directamente conectados. Verificar que se han establecido dichas adyacencias con el commando: show ip ospf neighbor Rellenar la siguiente tabla con los resultados obtenidos para comprobar que el protocolo OSPF est funcionando correctamente:
Neighbor ID
Estado
Dead Time
Address
Interface
Las rutas A continuacin verifica que se reciben todas las rutas o prefijos que se deberan estar propagando por OSPF, utilizar el comando show ip route en los equipos PE para obtener la tabla de rutas y saber las que est aprendiendo por OSPF. Copiar la tabla de rutas y responde a las siguientes preguntas: Cuntos prefijos /32 hay en la tabla de routing? A quin pertenecen esos prefijos? Cuntas direcciones tiene cada router en su tabla de rutas? Cuntas direcciones tiene conectadas directamente? Cuntas direcciones se estn recibiendo por OSPF?
121
4. Configuracin de BGP
En esta parte de la prctica se va a establecer el full-mesh de sesiones iBGP entre los equipos PE. Esto nos servir para tener preparada la red para un escenario de red MPLS.
Figura 5. Mapa de sesiones iBGP Puesto 1
Figura 6. Mapa de sesiones iBGP Puesto 2 En esta parte de la practica slo se utilizarn los equipos PE de cada grupo. El sistema autnomo que utilizaremos en el laboratorio ser el 65000. Configurar el protocolo de routing BGP para que exista un full-mesh de sesiones internas entre los equipos PE de cada grupo. Las sesiones iBGP debern establecerse entre las direcciones IP asociadas a la nueva loopback 255 que deber crearse y que se corresponden con la siguiente tabla: EQUIPO Cisco 2800_1 Cisco 2800_2 Cisco 2800_3 Cisco 2800_4 Direccin de loopback 255 192.168.43.17 192.168.43.18 192.168.43.19 192.168.43.20
122
Configurar para cada vecino lo siguiente:

Crear la nueva interfaz loopback 255 segn el anterior direccionamiento. Incluir la interfaz de loopback que acabamos en el protocolo de routing OSPF para que se propague a sus futuros vecinos BGP. Configurar el proceso de routing BGP.
Verificacin del funcionamiento:

Una vez configuradas las sesiones BGP, hay que verificar que stas estn funcionando. Para comprobarlo utilizar los siguientes comandos en cada router PE: show ip bgp neighbor show ip bgp summary Fjese en los vecinos que tiene conectados cada router PE, el sistema autnomo al que pertenece, el estado de BGP, si tiene activa la sesin TCP, la direccin y el puerto local y la direccin y el puerto remoto. Copiar los resultados obtenidos con el comando show ip bgp summary y rellenar la siguiente tabla con la informacin recogida:
Nombre Vecino
Remote ID
State
HoldTime
Keepalive
Capabilities
Local Port
Foreign Port
Contestar a las siguientes preguntas: Cuntos prefijos esta recibiendo cada vecino? Por qu? Cul es el estado de las sesiones BGP? Por qu?
123
5. Configuracin de MPLS - LDP

En esta parte de la prctica se va a crear la nube MPLS. Se debe arrancar el protocolo de distribucin de etiquetas en las distintas interfaces por las que se quiera hablar MPLS. En la figura siguiente se muestra la nube MPLS que quedar despus de configurarlo en la red.
Figura 7. Nube MPLS Puesto 1
Figura 8. Nube MPLS Puesto 2 Como se ve en la figura anterior, los routers PE hablarn MPLS. En el caso de las interfaces que enfrentan a los equipos PE con los CE no hay que configurar LDP ya que por esa interfaz no se habla MPLS. Hay que configurarlo en la interfaz que enfrenta a los dos equipos PE de la nube MPLS.
Activacin del protocolo de distribucin de etiquetas

Para la activacin del protocolo de distribucin de etiquetas se han de llevar a cabo los siguientes pasos:
Configurar el CEF en todos los routers PE. 124
En el equipo PE, activar el protocolo de distribucin de etiquetas LDP en la interfaz que le une al otro equipo PE de su grupo, y a la inversa, en definitiva en todos los interfaces de todos los routers que vayan a hablar MPLS.
Verificacin del funcionamiento de la nube MPLS

El protocolo Comprobar los valores de los parmetros que est utilizando el protocolo en este equipo. Utilizar el comando: show mpls ldp parameters Rellenar la siguiente tabla con la informacin mostrada con el comando anterior:
Atributo Versin Etiqueta min. Etiqueta max Hold-Time Keepalive
Valor
Las interfaces Verificar que el protocolo de distribucin de etiquetas est funcionando en las interfaces que se han planificado. Usar el comando show mpls interfaces para verificar que esta configurado y operacional y es el protocolo LDP el que est funcionando en dichas interfaces. Copiar el resultado obtenido al ejecutar el comando anterior y responder a las siguientes preguntas: Qu campos aparecen por interfaz? A que crees que se refiere el campo tnel? Qu extensin se debe aadir al comando show mpls interface para conocer la MTU utilizada en la interfaz?
125
Los vecinos Verificar que el equipo PE ha podido establecer la sesin con el otro equipo PE y lo ha reconocido como vecino. Usar el comando: show mpls ldp neighbor Copiar el resultado obtenido al ejecutar el comando anterior y rellenar la siguiente tabla con la informacin mostrada: Router PE Vecino (Nombre) Local Ident: Puerto TCP Local Remoto
Protocolo Dist Etiq
Peer Ident
Estado
Enlaces Fsicos
La asignacin de etiquetas Una vez que se hayan establecido las sesiones LDP, todos los equipos asignarn etiquetas a cuantos prefijos existan propagados por OSPF. Para verificar la asignacin de etiquetas usar los comandos: show mpls ldp binding show mpls forwarding-table Copiar los resultados obtenidos al ejecutar el comando show mpls forwarding-table y responder a las siguientes preguntas: Cuntas entradas hay en la TIB? Deberan de ser las mismas que en la tabla de routing? Comprobarlo contando las entradas que hay en la tabla de routing global (show ip route) Tienen el mismo nmero de entradas? Qu significado tiene la etiqueta local? Y la remota? Qu significado tiene el atributo tsr? Cuntos prefijos aparecen?
126
Usar el comando show mpls ldp binding <subred> <mscara>, donde la subred y mscara son las del enlace que une a cada equipo PE con otro PE. Qu etiquetas local y remota se han asignado? Qu significa la etiqueta imp-null? Cuntos prefijos aparecen en la tabla de forwarding? Cules son los que faltan respecto de lo que muestra el comando show mpls ldp bindings?
Capturas MPLS
Para comprender mejor los protocolos vistos en la realizacin de la prctica se va a analizar la captura realizada con el analizador de protocolos Ethereal. Explicar los mensajes intercambiados cuando se ha configurado OSPF. Explicar los mensajes intercambiados cuando se ha configurado BGP. Explicar los mensajes intercambiados cuando se ha configurado MPLS-LDP. Explicar los mensajes intercambiados cuando se han realizado pings.
127
Puesto 1
128
Puesto 2
129
Prctica 2: Configuracin y Administracin de una red MPLS/IP (2 parte)

1. Introduccin y descripcin de la red experimental
En la siguiente prctica se van a crear dos VPN: VPN-A y VPN-B. En esta parte de la prctica se trabaja con la configuracin normal de la red experimental. La Figura 1 representa parte de la red experimental. En ella se aprecian nicamente la troncal y las sedes regionales implicadas. El resto de elementos de la red experimental (sucursales y sede central) siguen estando operativos
Figura 1. Red experimental
Para ello se da configurada la red troncal con MPLS y los routers Cisco 1841 (routers CE). Lo que hay que configurar es lo referente a los equipos con funcionalidad PE, para que ofrezcan el servicio de VPN a los clientes. Los equipos de los clientes van a estar conectados al resto de la red experimental de acuerdo a las prcticas anteriores.
130
Esta prctica est dividida en tres partes:
1. Comprobacin de la configuracin de la red. 2. Creacin de las VPN. 3. Unificacin de las VPN.
2. Comprobacin de la configuracin de la red

La red est configurada de acuerdo a las prcticas anteriores, existiendo conectividad entre todas las sedes que la forman. Lo primero que hay que comprobar es la configuracin de los PC en los que se va a trabajar, su direccin IP y las rutas que tienen establecidas. Lo segundo es comprobar la conectividad existente entre las sedes que forman la red. Utilizar el comando ping < IP@ vecino>.
Llegan los pings?
Por ltimo, es importante comprobar aspectos de configuracin de los equipos que forman el backbone:
Verificar con el comando show ip interface brief en los equipos PE y en los equipos CE que la configuracin existente se ajusta al direccionamiento que aparece en la figura anterior. En los equipos PE, estn en la tabla de routing global las subredes de los enlaces que le unen con los equipos CE? Verificar en los equipos P y PE con el comando show mpls interfaces, que el protocolo de distribucin de etiquetas est funcionando en las interfaces que deben hablar MPLS. Verificar en los equipos P y PE con el comando show mpls ldp neighbor, que se han establecido las vecindades LDP. Comprobar en los equipos P y PE con el comando show mpls forwarding-table, la tabla de forwarding MPLS.
Una vez que hemos comprobado los PC, la conectividad entre los equipos que forman la red y el correcto funcionamiento de la troncal MPLS, vamos a pasar a realizar las prcticas de VPN.
131
3. Creacin de las VPN: VPN-A y VPN-B

Se van a crear dos VPN, denominadas VPN-A y VPN-B, en la que estn involucrados todos los equipos que se indican en la figura. La sede regional de Salamanca, que est reservada, se utilizar para comprobar la conectividad existente fuera de las VPN.
16 8.
43 .
88 /
30
/30 .84 .43 68 2.1 19
19 2.
0 0/3 3.6 8.4 .16 2 19
Figura 2. VPN-A y VPN-B
En esta configuracin de VPN el routing en los enlaces PE CE va a ser dinmico con OSPF y la topologa que se generar ser una totalmente mallada (full-mesh). Los routers con funcionalidad CE van a tener configurado el proceso 255 de OSPF en el rea 0 en los enlaces que les unen al backbone MPLS, ya que es el proceso configurado en el backbone. Y, adems, tendrn configurado otro proceso OSPF en un rea distinto del 0, que engloba los enlaces pertenecientes a la sede regional en la que se encuentran y sus sucursales.
/30 .96 .43 68 2.1 19
19 2.1 68 .43 .56 /30
19 1 2. . 68 .5 43 3 2/ 0
132
Comprobar con el comando show ip ospf interface qu interfaces quedan activas para el protocolo de routing y a qu rea pertenecen: Interfaz Activa el OSPF? rea a la que pertenece
Para la creacin de las VPN se seguirn los siguientes pasos:

Configuracin de las dos VRF. Configuracin del forwarding en las interfaces pertenecientes a cada VPN. Configuracin del encaminamiento dinmico para cada VRF. Configuracin de iMBGP. Configuracin del envo de los prefijos aprendidos al resto de los equipos PE. Configuracin del envo de los prefijos aprendidos a los equipos CE.
3.1 Configuracin de la VRF

Hay que crear la VRF asociada a cada VPN en cada equipo con funcionalidad PE. Los parmetros necesarios para crearla Router Distinguisher y Route-Target (RD y RT) se pueden extraer de la siguiente tabla, a continuacin hay que seguir los pasos indicados para crear la VRF:
VPN VPN-A VPN-B
RT PE4 65000:400 65000:200
RD PE4 65000:41 65000:14
RT PE3 65000:400 65000:200
RD PE3 65000:31 65000:13
En este caso, al ser una VPN con topologa Full-Mesh, el RT que se importa tiene que ser el mismo al que se exporta. A continuacin hay que seguir los pasos que aparecen en el manual para crear la VRF asociada a cada VPN y aplicar el envo de paquetes en las interfaces de los routers PE que estn enfrentadas a los routers CE y que entran dentro de la VPN correspondiente. En lo que respecta a la VRF ya est todo configurado. Hace falta comprobar la conectividad entre el equipo PE y el equipo CE. Utilizar el comando ping < IP@ del CE > para comprobar la conectividad entre ellos. Responder a las siguientes preguntas: - Llegan los pings?
133
- Es correcto? - Debera estar la subred del enlace que les une en la tabla de routing global? Utilizar el comando show ip route para comprobarlo. - Est el enlace up, up? Si la respuesta es afirmativa, en qu tabla de routing debera aparecer la subred del enlace que une al equipo PE con el CE? Utilizar el comando ping vrf <Nombre de la VRF><IP@ de CE en el enlace> Llegan los pings?
Utilizar el comando show ip route vrf <Nombre de la VRF> Cuntos prefijos aparecen?Cules?
Hasta aqu se ha configurado la VRF en el equipo con funcionalidad PE y la subred que le une al equipo con funcionalidad CE ha pasado a la tabla de routing de la propia VRF (saliendo de la tabla de routing global). Por lo tanto est asegurada la conectividad local.
3.2 Configuracin del routing dinmico para cada VRF

El siguiente paso es crear un proceso de routing OSPF 1 que sea til slo a la VRF que se ha creado. Para ello hay que seguir los pasos que se explican en el manual. Una vez realizados los pasos, comprobar el establecimiento de la adyacencia OSPF con el comando show ip ospf neighbor. Comprobar tambin la conectividad existente entre los equipos PE y CE haciendo ping desde ambos.
3.3 Configuracin del iMBGP

Para que los prefijos aprendidos puedan ser transmitidos a los otros equipos PE, hay que configurar iMBGP. Este paso es comn en la creacin de las dos VPN, por lo tanto slo uno de los grupos deber configurar iMBGP en los routers PE. Por ello es aconsejable ponerse de acuerdo para que solamente lo realice uno de los grupos y el otro compruebe su correcto funcionamiento. Hay que activar iMBGP tal y como se indica en el manual. Una vez se ha configurado iMBGP, con el comando show ip bgp neighbors verificar que se ha activado el iBGP para cada vecino. - Qu capabilities aparecen para todos los vecinos? Cul es la que indica que el iMBGP est activo en la sesin? 134
3.4 Envo de los prefijos aprendidos localmente al resto de equipos PE

Una vez establecidas las sesiones iMBGP con el resto de equipos PE y verificada la conectividad local con los integrantes de la VPN, queda propagar los prefijos locales al resto de equipos PE para que stos sepan encaminar los paquetes hacia dichos prefijos. Bastar con seguir los pasos que se muestran en el manual. Con el comando show ip route vrf <Nombre de la VRF> comprobar el nmero de prefijos que existe ahora en la tabla de routing para la VRF. -Cules aparecen? -Tendrn todos los equipos el mismo nmero de prefijos?Cuantos? -Qu prefijos debern aparecer como OSPF en los CEs y de que tipo? Rellenar la tabla siguiente: Prefijo Tipo de prefijo OSPF
A continuacin se va a configurar la propagacin de los prefijos por el iMBGP, bastar con redistribuir OSPF en el iMBGP. Para ello hay que seguir los pasos que se muestran en el manual. Con el comando show ip route vrf <Nombre de la VRF> comprobar: Qu prefijos aprendidos por BGP aparecen en la tabla de routing de la VRF? Qu prefijos recibe el CE por OSPF? Por qu?
3.5 Envo de los prefijos aprendidos por iMBGP al equipo CE va OSPF

Hasta ahora se ha propagado lo que aprende del OSPF local a los equipos PE vecinos y el equipo PE local ha aprendido por BGP los prefijos que estn propagando los CE remotos, pero en ningn momento se ha configurado el OSPF de la VRF local que le propague al CE local los prefijos aprendidos por BGP. Esto es lo que se va a configurar a continuacin siguiendo los pasos indicados en el manual. Comprobar con el comando show ip route en el equipo con funcionalidad CE : Qu prefijos recibe por OSPF?
135
4. Comprobacin de la topologa Full-Mesh

A continuacin se comprobar que la topologa resultante es full-mesh, para ello hay que realizar dos comprobaciones: Utilizar el comando traceroute hacia la <IP@ Remota> para identificar los saltos que se producen y el camino seguido en: Equipo CE. Realizar el traceroute hacia la direccin IP del equipo de otra sede perteneciente a la VPN-A. Apuntar las direcciones IP de los saltos por los que pasa el paquete e identificar el nombre del equipo asociado a cada IP. Nmero de Salto Direccin IP Nombre Equipo
Indicar grficamente el recorrido que hace el paquete desde el origen hasta el destino. Para comprobar que la conectividad en la VPN est bien configurada, realizar las siguientes comprobaciones:
Ping desde el equipo CE hacia la interfaz del equipo PE que tiene directamente conectado. Ping desde el equipo CE hacia otro router que est dentro de la misma VPN. Ping desde el equipo CE hacia el equipo CE de la sede reserva de Salamanca. Este ping llega? Por qu? Ping normal desde el equipo PE hacia los equipos pertenecientes a la VPN. Este ping llega? Por qu? Ping referente a la VPN (ping vrf ) desde el equipo PE hacia los equipos pertenecientes a la VPN. Este ping llega? Por qu?
5. Identificacin de Etiquetas
En el momento de la existencia de prefijos que se propagan por iMBGP, se asignan etiquetas para cada prefijo y aparece la pila de etiquetas. A continuacin se identificarn las etiquetas, a nivel de VPN, para cada prefijo en nuestra VPN.
136
Asignadas a los prefijos locales de la VPN Utilizar el comando show mpls forwarding-table vrf <nombre de la VRF> para identificar la etiqueta que ha elegido cada equipo PE y que notificarn a todos aquellos vecinos que quieran enviar trfico a dicho prefijo:
Etiqueta Local
Etiqueta de Salida
Prefijo
Interfaz de Salida
Siguiente salto
6. Unificacin de las VPN

En este ltimo punto se unificarn las dos VPN creadas: VPN-A y VPN-B en una sola VPN. Para ello, se dejar operativa solamente la VPN-A, quedando la red tal y como se muestra en la siguiente figura.
Figura 3. Unificacin VPN
137
Por lo tanto, slo habr que cambiar lo referente a la VPN-B. En los dos routers con funcionalidad PE se han realizado los siguientes pasos:

Configuracin de las dos VRFs. Configuracin del forwarding en las interfaces pertenecientes a cada VPN. Configuracin del encaminamiento dinmico para cada VRF. Configuracin de iMBGP. Configuracin del envo de los prefijos aprendidos al resto de los equipos PE. Configuracin del envo de los prefijos aprendidos a los equipos CE.
El nico cambio que hay que realizar es la configuracin del forwarding en las interfaces que pertenecen a la VPN-B, para que a partir de ahora el forwarding se realice a travs de la tabla de rutas de la VPN-A. Para ello, solo hay que ejecutar los siguientes comandos en las interfaces de los equipos PE que les unen a los equipos CE: cisco#configure terminal cisco(config)#interface <nombre de la interfaz> cisco(config-if)#ip vrf forwarding <nombre de la VRF> Siendo el nombre de la VRF el de la VPN-A. Y volviendo a asignar las direcciones IP que se borrarn despus de ejecutar el ltimo comando. De esta forma los paquetes se enviarn respecto a lo configurado para la VPN-A. Para comprobar que la conectividad en la VPN est bien configurada, realizar las siguientes comprobaciones:
Ping desde los equipos CE hacia la interfaz del equipo PE que tienen directamente conectado. Ping desde los equipos CE hacia todos los dems equipos que pertenezcan a la VPN-A. Ping desde el equipo CE hacia el equipo CE de la sede reserva de Salamanca. Este ping llega? Por qu? Ping normal desde el equipo PE hacia los equipos pertenecientes a la VPN. Este ping llega? Por qu? Ping referente a la VPN (ping vrf ) desde el equipo PE hacia los equipos pertenecientes a la VPN. Este ping llega? Por qu?
138
30 8/ .8 43 8. 16 2. 19 .90 S0/0/0
S0/0/1 .89
S0/0/0 .86
2.1 19 .84 .43 68 /30 .4 68 2.1 .61 19 S0/1/0 0 0/3 3.6
VPN - B
S0/0/1 .93
S0/1/1 .46
192.1 6 8.43 .4
S0/1/0 P .97
192.1
6 2.1 19 0 6/3 3.9 8.4
68.4
.85 S0/0/0
3.9 2/30
.1
.62 CE S0/1/1 S0/0/1 .94

19 2.1 68 .43
CE 3
4/30
.45 S0/1/1
3.48 192.1 68.4 /30
.98 S0/0/0
PE 3 Red Troncal
.49 S0/1/0
.57 S0/1/1
.56 /3
.58 S0/1/1 .53 S0/0/1
VPN - B
.50 S0/1/1
VPN - A PE 4 CE 4
19 2. 1
CE 1
68 .4 3. 52 /3 0
.54
S0/1/1
CE 5
VPN - A
139
19 2.1 68 .37 .22
4/3 0
19 2.1 68 /3 0
19 2.1 68 .33 .22 8/3 0
.3 3.2 24
0 8/3 .22 .37 68 2.1 19
68 2.1 19
30 8/ 3.8 .4
2.1 19 /30 .84 .43 68 /30 .60 .43 68 2.1 19 /30 .96 .43 68 2.1 19 19 2.1 68 .43 .56 /30
19 2. 16 8.4
3. 52 /3 0
19 2.1 68 .35 .22 4/3 0
19 2.1 68 .35 .22 8/3 0
140
Anexo C: Automatizacin de la configuracin de la red.
Anexo C
Automatizacin de la configuracin de la red.
1. Introduccin
Una vez realizadas las distintas configuraciones de la red troncal y probado su correcto funcionamiento, se ha realizado la automatizacin de la configuracin de la red utilizando un programa llamado Telnet Scripting Tool. Dicho programa realiza un telnet a la mquina y al puerto indicado y permite el envo de comandos para configurar el dispositivo al que se ha conectado.
2. Funcionamiento
El programa Telnet Scripting Tool (tst10.exe) se ejecuta desde la lnea de comandos de Windows utilizando la siguiente sintaxis: tst10.exe /r:script.txt [opciones] Donde:

/r: script.txt: fichero de texto que contiene el script que se tiene que ejecutar. [opciones]: pueden ser las siguientes: o /o: output.txt: guarda la sesin en el fichero de texto output.exe. o /m: lanza el programa con la ventana minimizada.
Ejemplo de uso: tst10.exe /r:script.txt /o:output.txt /m El fichero de texto que contiene el script que debe ejecutar el programa tiene que cumplir la siguiente sintaxis: NOMBRE DEL HOST PUERTO WAIT "cadena de caracteres": cadena que espera recibir. SEND cadena de caracteres ": cadena que tiene que enviar. \" : representa el carcter comillas. \m : representa un retorno de carro <CR/LF>.
141
Un ejemplo de uso del fichero de texto del script sera:
cs1 41 SEND "\m" WAIT "Router>" SEND "enable\m" WAIT "Router#" SEND "configure terminal\m" WAIT "Router(config)#" SEND "hostname cisco2800_1\m" WAIT "cisco2800_1(config)#" SEND "end\m" WAIT "cisco2800_1#" SEND "logo\m"
Los comandos del fichero de texto pueden empezar por WAIT o por SEND, pero es obligatorio alternarlos para el correcto funcionamiento del script. El programa se desconectar y cerrar la sesin tan pronto como se haya ejecutado el ltimo comando que aparezca en el fichero de texto del script. Si es necesario, se pueden introducir comandos en la ventana del programa que se abre cuando se ejecuta el programa. Se puede guardar la sesin en un fichero de texto de salida que permitir depurar la configuracin que se pretenda realizar en el dispositivo al que se haya conectado. Esto permite obtener los resultados que se necesiten y ver posibles errores que se puedan cometer a la hora de configurar los dispositivos. Las configuraciones que se han realizado han sido las correspondientes a la red troncal, as como la de reseteo de los routers que la forman. Dichas configuraciones son:

Configuracin OSPF (Configuracin bsica). Configuracin BGP. Configuracin MPLS.
Estas configuraciones permiten configurar la red troncal para poder solucionar las prcticas propuestas para el laboratorio de la asignatura de Redes y Servicios II. Los scripts configuran los routers Cisco 2811 que forman la red troncal tal y como se ha indicado en la memoria del proyecto fin de carrera, por lo que este anexo no tiene como fin entrar en detalle en las configuraciones. Por cada configuracin se ha realizado un fichero de texto para cada router que contiene el script de configuracin de dicho router. Esto permite tener aislada la configuracin de cada router para as hacerlo de forma individual y poder depurar posibles errores.
142
Para ejecutar el programa de una forma sencilla puede hacerse de dos formas distintas:

Ejecutando directamente un fichero por lotes MS-DOS (fichero .bat). Ejecutando una pgina web que contiene un script para realizar la llamada al programa.
El fichero por lotes MS-DOS contiene la sintaxis necesaria para ejecutar los scripts de cada configuracin. Dicho fichero abre una ventana de comandos de Windows y ejecuta lnea a lnea lo editado en l. Existen cuatro ficheros .bat correspondientes a cada una de las configuraciones de la red troncal. Por ejemplo, el fichero mpls.bat contiene las llamadas para ejecutar el programa TST10.exe que configura cada uno de los routers que forman la red troncal. Dicho fichero se muestra a continuacin:
cd escritorio cd telnet tst10.exe /r:mpls1.txt /o:salidampls1.txt tst10.exe /r:mpls2.txt /o:salidampls2.txt tst10.exe /r:mpls3.txt /o:salidampls3.txt tst10.exe /r:mpls4.txt /o:salidampls4.txt
La pgina web contiene funciones realizadas en JavaScript para cada una de las cuatro configuraciones posibles. Cada una de estas funciones son llamadas, de forma individual, cuando se pulsa un botn de un formulario y su misin es ejecutar el archivo .bat correspondiente a la configuracin deseada. Por ejemplo, la siguiente funcin se ejecuta cuando se ha pulsado el botn correspondiente a la configuracin de OSPF de la red troncal:
function confOSPF () { alert("Configuracin OSPF"); var theShell = new ActiveXObject("WScript.Shell"); theShell.run("ospf.bat"); }
Dicha funcin ejecuta el archivo ospf.bat que contiene las llamadas para ejecutar el programa TST10.exe que configura cada uno de los routers que forman la red troncal, sus interfaces y activa el protocolo OSPF para el encaminamiento dinmico de la red. La pgina web diseada tiene el siguiente aspecto para poder ejecutar los scripts de forma fcil y sencilla:
143
Para las dos formas de ejecutar el programa de configuracin hay que tener en cuenta los siguientes puntos. Los archivos .bat tienen que estar en la carpeta donde arranca la lnea de comandos de Windows. El programa TST10.exe y los archivos de texto que contienen los scripts estn alojados en una carpeta llamada telnet que debe estar en el escritorio.
144

Memoria - 230606 M Puñales

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Memoria - 230606 M Puñales

Hochgeladen von

Copyright:

Verfügbare Formate

PROYECTO FIN DE CARRERA PLAN 92

Tema: Diseo e implementacin de una red IP con troncal MPLS

Ttulo: MPLS: Aplicacin y funcionalidades. Diseo e implementacin del servicio VPN-MPLS.

Mario Puales Casquero Junio 2006

6.4 BGP 6.5 Configuracin de LDP 6.6 Introduccin a la configuracin de VPN-MPLS

98 100 106 109 116 141

Captulo 1: Introduccin a Multiprotocol Label Switching (MPLS)

Captulo 1: Introduccin a Multiprotocol Label Switching (MPLS)

Captulo 1: Introduccin a Multiprotocol Label Switching (MPLS)

1. Introduccin a Multiprotocol Label Switching (MPLS)

Captulo 1: Introduccin a Multiprotocol Label Switching (MPLS)

1.1 Enrutamiento tradicional

Figura 1.1. Ejemplo de enrutamiento tradicional.

Captulo 1: Introduccin a Multiprotocol Label Switching (MPLS)

1.2 Ingeniera de trfico en MPLS

Captulo 1: Introduccin a Multiprotocol Label Switching (MPLS)

Figura 1.2 Ejemplo de ingeniera de trafico en MPLS.

Captulo 1: Introduccin a Multiprotocol Label Switching (MPLS)

Figura 1.3 LIB del router C.

1.3 Componentes de MPLS

Captulo 1: Introduccin a Multiprotocol Label Switching (MPLS)

Captulo 1: Introduccin a Multiprotocol Label Switching (MPLS)

Figura 1.4 Campos de una Shim label

Captulo 1: Introduccin a Multiprotocol Label Switching (MPLS)

Captulo 2: Protocolo de distribucin de etiquetas (LDP)

2. Protocolo de distribucin de etiquetas (LDP).

Eliminado: e Eliminado: a Eliminado: a Eliminado: a Eliminado: a

2.1 Modo de operacin de LDP

Captulo 2: Protocolo de distribucin de etiquetas (LDP)

Eliminado: el Eliminado: a Eliminado: ,

Comentario [RDM1]: No entiendo esta frase

Captulo 2: Protocolo de distribucin de etiquetas (LDP)

Recibir mensaje de mantenimiento

Recibir un mensaje de iniciacin aceptable. Tx mensaje de mantenimiento.

Figura 2.1. Maquina de estados LDP.

Captulo 2: Protocolo de distribucin de etiquetas (LDP)

INITIALIZED OPENREC OPENREC

OPERATIONAL OPERATIONAL OPERATIONAL

Captulo 2: Protocolo de distribucin de etiquetas (LDP)

2.2 Mensajes LDP

Captulo 2: Protocolo de distribucin de etiquetas (LDP)

Tipo del mensaje

Longitud del mensaje

Identificador del mensaje Parmetros obligatorios

Captulo 3: VPN-MPLS. Redes privadas virtuales MPLS

3. VPN-MPLS. Redes Privadas Virtuales MPLS.

Captulo 3: VPN-MPLS. Redes privadas virtuales MPLS

Captulo 3: VPN-MPLS. Redes privadas virtuales MPLS

A continuacin se va a ver un ejemplo para estudiar la terminologa:

Figura 3.2. Terminologa VPN MPLS.

Captulo 3: VPN-MPLS. Redes privadas virtuales MPLS

Captulo 3: VPN-MPLS. Redes privadas virtuales MPLS

Etiqueta MPLS Etiqueta VPN

Captulo 3: VPN-MPLS. Redes privadas virtuales MPLS

Figura 3.4. Distribucin de routing entre PE-CE.

Captulo 3: VPN-MPLS. Redes privadas virtuales MPLS

3.1 Topologa Hub-and-spoke

Captulo 3: VPN-MPLS. Redes privadas virtuales MPLS

Sede Central (HUB)

Sede Remota (Spoke)

Sede Remota (Spokes)

Sede Remota (Spokes)

Figura 3.5. Topologa Hub & Spoke