Configuración de EoMPLS en enrutadores Cisco. Redes VPN basadas en tecnología MPLS. Modelo IP VPN, en el que la configuración de VPN la proporciona el cliente

La red de nuestra empresa imaginaria linkmeup está creciendo. Ya cuenta con líneas principales en varias ciudades, base de clientes y un excelente equipo de ingenieros que crecieron en el ciclo SDSM.
Pero no todo les basta. Los servicios de banda ancha son buenos y necesarios, pero todavía existe un enorme mercado potencial para los clientes corporativos que necesitan VPN.
Los muchachos pensaron en esto, se devanaron los sesos y llegaron a la conclusión de que no había forma de hacer esto sin MPLS.

Si la multidifusión fue el primer tema que requirió cierta reestructuración de la comprensión de las redes IP, entonces, al estudiar MPLS, definitivamente tendrás que olvidar casi todo lo que sabías antes: este es un mundo especial con sus propias reglas.

El problema de hoy:

Comencemos con la pregunta: "¿Qué tiene de malo la propiedad intelectual?"

vídeo tradicional

Pero realmente, ¿qué pasa? ¿Por qué vallar MPLS?

Sí, todo eso es cierto. Las ventajas y desventajas de IP surgen del hecho de que apareció más tarde que las redes clásicas y es increíblemente flexible. Hoy en día hay una transición a la conmutación de paquetes en todas partes, que se basa en IP a nivel de red y a nivel de canal todo gran popularidad marca Ethernet.
Esto es bueno porque ahora, sobre la base de una red central y una red de acceso, es posible proporcionar telefonía IP, IPTV y otros posibles servicios.
Lo mismo se puede ver en las redes de los operadores móviles. Al principio, las redes de segunda generación se basaban íntegramente en . El núcleo de las redes 3G es principalmente IP, pero los servicios de telefonía aún se pueden proporcionar en modo de conmutación de circuitos. Las redes 4G ya son redes IP de pleno derecho, en las que la transmisión de voz es sólo una de las aplicaciones, así como el acceso de banda ancha.

Sin embargo, todavía hay una gran cantidad de segmentos en los que se utilizan tecnologías antiguas. Por ejemplo, en algún lugar hay un cajero automático, en otro lugar es necesario transferir PDH de una parte de la red a otra, pero aquí el cliente quería que su parte de la red Ethernet fuera accesible desde el otro extremo de la ciudad como si fuera conectado directamente, en otras palabras, VPN.
Cómo se solucionó esto antes: necesitas cajero automático entre dos puntos geográficos- construir un canal entre ellos basado en ATM, PDH - construir PDH.
Pero quiero hacer todo esto a través de una red y no crear una separada para cada tipo de tráfico.
Es por eso que se inventaron GRE, PPPoE, PPPoA, ATM sobre Ethernet, TDM sobre IP y muchos otros overs al mismo tiempo. Puede crear mil más para cubrir todas las combinaciones, y la felicidad universal vendrá en el caos de los estándares (. Por cierto, algunos pequeños fabricantes tomaron este camino.).

A mediados de los 90, a los exaltados de varias empresas (IBM, Toshiba, Cisco, Ipsilon) se les ocurrió la idea de crear un mecanismo que permitiera, al enrutar, no mirar dentro del paquete y peinar la tabla de enrutamiento. en busca del mejor camino, sino para navegar por una determinada etiqueta. Funcionó en Cisco y el mecanismo se llamó simplemente: TAG Switching.
Además, el objetivo perseguido por los desarrolladores era permitir que los conmutadores de alta velocidad transmitieran tráfico exclusivamente en hardware. El hecho es que el enrutamiento IP por hardware ha sido durante mucho tiempo un placer inaccesible y no era práctico usarlo en conmutadores económicos, pero tomar una decisión basada en una etiqueta podría ser simple y rápido.
Pero al mismo tiempo aparecieron los supergrandes. circuitos integrados(aunque no estoy de acuerdo con este término; el VLSI en inglés describe la esencia mucho mejor), y la tarea de ahorrar dinero en el análisis del contenido del paquete ya no es tan relevante. Además, apareció el concepto de FIB, que supone que para cada paquete no es necesario buscar el destino en la tabla de enrutamiento y, en consecuencia, involucrar al procesador central: toda la información activa ya está en la tarjeta de línea.
Es decir, en esencia, la necesidad de tal mecanismo ha desaparecido.

Pero de repente Quedó claro que el cambio de etiquetas tiene un potencial no planificado, no importa lo que haya debajo de la etiqueta: IP, Ethernet, ATM, Frame Relay. También permite deshacerse de las restricciones del enrutamiento IP.
De aquí se origina la tecnología aprobada por el IETF - MPLS - MultiProtocol Label Switching. El año era 1997.
Y este detalle aparentemente insignificante dio origen a una nueva era en las telecomunicaciones. Hoy en día encontrarás MPLS en cualquier proveedor más o menos grande.

Las principales aplicaciones de MPLS ahora:

• MPLS L2VPN
• MPLS L3VPN
• MPLS TE

Hablaremos de cada uno de ellos en artículos separados; estos son temas monstruosamente extensos. Pero los abordaremos brevemente al final del artículo.

MPLS

El propio MPLS puro rara vez se utiliza. La ganancia de rendimiento es insignificante, porque la diferencia entre mirar en FIB/cambiar algunos campos en los encabezados y mirar la tabla de etiquetas/cambiar la etiqueta en el encabezado MPLS no es tan grande. Por supuesto, se utilizan las aplicaciones enumeradas anteriormente.
Pero en este artículo seguiremos centrándonos en MPLS puro para comprender cómo funciona en su forma más básica.
También una aplicación de MPLS puro.

A pesar de que MPLS no está ligado al tipo de red en la que funcionará, hoy en día vive en simbiosis únicamente con IP. Es decir, la red en sí está construida sobre IP, pero al mismo tiempo puede transferir datos desde muchos otros protocolos.
Pero vayamos al grano y primero quiero decir que MPLS no reemplaza el enrutamiento IP, pero funciona además de eso.

Para ser más específico, tomaré una red como esta.

Ahora está en pleno funcionamiento, pero sin ningún indicio de MPLS. Es decir, R1, por ejemplo, ve R6 y puede hacer ping a su Loopback.
La PC1 envía una solicitud ICMP al servidor 172.16.0.2. Una solicitud ICMP es un paquete IP. En R1, de acuerdo con los principios básicos, el paquete pasa a través de la interfaz FE0/0 hasta R2; eso es lo que dice la tabla de enrutamiento.
R2, después de recibir el paquete, verifica la dirección de destino, mira su FIB, ve siguiente enrutador y envía el paquete a la interfaz FE0/0.
Y este proceso se repite una y otra vez. Cada enrutador decide de forma independiente el destino del paquete.

Así es como se ve un volcado de tráfico:

¿Qué pasa si habilitamos MPLS? De inmediato, en ese mismo segundo, el mundo cambia. Después de esto, se completan las tablas de etiquetas en los enrutadores y se crean numerosos LSP.

Y ahora el mismo camino se recorrerá de forma un poco diferente.

Cuando un paquete IP de la PC1 ingresa a la red MPLS, el primer enrutador adjunta una etiqueta, luego este paquete va al destino y cada enrutador subsiguiente cambia una etiqueta por otra. Al salir de la red MPLS, se retira la etiqueta y se transmite un paquete IP puro, como al principio.

Este es el principio básico de MPLS: los enrutadores cambian paquetes usando etiquetas sin mirar dentro del paquete MPLS. El primero añade, el último elimina.

Veamos paso a paso cómo transmitir un paquete de datos desde la PC1 al nodo de destino:

1. PC1, una computadora normal, envía un paquete normal a un servidor remoto.

2. El paquete llega a R1. Agrega la etiqueta 18. Esta se inserta entre el encabezado IP y Ethernet.
Puede tomar esta información de la FIB:

La FIB demuestra que el paquete con el destinatario 6.6.6.6 necesita ser etiquetado 18 y enviar a la interfaz FE0/0.
Esto es exactamente lo que hace: añade un título y escribe 18 en él:

Volcado entre R1 y R2.

3. R2 recibe este paquete, ve en el encabezado de Ethernet que es un paquete MPLS (Ethertype 8847), lee la etiqueta y accede a su tabla de etiquetas:

Vamos a explicarlo claramente: si llegó un paquete MPLS con la etiqueta 18, es necesario cambiarlo a 20 y enviar el paquete a la interfaz FE0/0.

Volcar después de R2.

4. R5 realiza acciones similares: ve que ha llegado un paquete con la etiqueta 20, debe cambiarse a 0 y enviarse a FE1/0. Sin ningún acceso a la tabla de enrutamiento.

5. R6, después de recibir el paquete MPLS, ve en su tabla que ahora se debe quitar la etiqueta. Y al eliminarlo, ya ve que el destino del paquete, 172.16.0.2, es una red conectada directamente. Luego, el paquete se transmite de la forma habitual a través de la tabla de enrutamiento sin etiquetas.

Es decir, todo el proceso se ve así:

No consideraremos los nodos finales para no complicar el diagrama.

Hasta ahora todo parece sencillo, aunque no está claro por qué.

Ahora los dominios IGP y MPLS son los mismos y MPLS sólo nos promete algunas ventajas en el futuro: L2VPN, L3VPN, MPLS TE.
Pero, de hecho, incluso el MPLS básico nos ofrece ventajas si recordamos que somos un proveedor.
Como proveedor, no utilizamos protocolos IGP para el enrutamiento entre AS. Para esto utilizamos BGP. Y es en combinación con BGP que las ventajas de MPLS quedarán claras.
Consideremos nuestra red en conjunto con los AS vecinos:

Por el tema BGP sabemos que en cada El router de nuestro AS debe estar configurado con BGP. De lo contrario, no podremos transmitir tráfico de los AS vecinos y de nuestros clientes a través de nuestro AS. Cada enrutador debe conocer todas las rutas.

¡Pero eso fue antes de MPLS!
Una vez que tengamos MPLS configurado en nuestra red, ya no necesitamos configurar BGP en todos los enrutadores de la red. Basta con configurarlo sólo en los routers de borde del AS, aquellos que están conectados a otros clientes o proveedores.

Pero no todo son buenas noticias. Además de eliminar la necesidad de configurar BGP en cada enrutador de un AS, los enrutadores ya no necesitan crear una etiqueta para cada prefijo BGP. Es suficiente saber cómo llegar a la dirección IP que figura como siguiente salto. Es decir, si se configura una sesión BGP entre Loopback0 R1 y Loopback0 R6, nada cambiará en la tabla de etiquetas, incluso si cada uno de ellos transmite cientos de miles de rutas a través de BGP:

Por ejemplo, el enrutador R1 recibió varias rutas a través de BGP del enrutador R6:

Veamos cómo se procesarán los paquetes que van a la red 100.0.0.0/16:

En el resultado anterior puede ver que los paquetes se agregarán con una etiqueta de 27.
Y, si miras la tabla de etiquetas, no hay etiquetas para rutas conocidas por BGP, pero sí la etiqueta 27 y corresponde a 6.6.6.6/32. Y esta es exactamente la dirección que vimos en las rutas que venían vía BGP desde R6:

Puede encontrar una configuración de ejemplo.

Nos adelantamos un poco, pero ahora que ha quedado más claro qué ventajas ofrece incluso el MPLS básico, podemos sumergirnos en el aparato conceptual del mundo del MPLS.

Terminología

Etiqueta - etiqueta: un valor de 0 a 1.048.575 En base a ello, el LSR decide qué hacer con el paquete: qué nueva etiqueta colgar, dónde enviarla.
Es parte del encabezado MPLS.

Pila de etiquetas - pila de etiquetas. Cada paquete puede llevar una, dos, tres o al menos 10 etiquetas, una encima de la otra. La decisión sobre qué hacer con el paquete se toma en función de la etiqueta superior. Cada capa juega su propio papel.
Por ejemplo, al transmitir un paquete se utiliza una etiqueta de transporte, es decir, una etiqueta que organiza el tránsito desde el primer al último enrutador MPLS.
Otros pueden transportar información de que un paquete determinado pertenece a una VPN específica.
En esta versión siempre habrá una sola etiqueta; no se necesitan más por ahora.

Empujar etiqueta - la operación de agregar una etiqueta a un paquete de datos se realiza desde el principio - en el primer enrutador de la red MPLS (en nuestro ejemplo, R1).

Cambiar etiqueta - operación de reemplazo de etiquetas: ocurre en enrutadores intermedios en la red MPLS: un nodo recibe un paquete con una etiqueta, lo cambia y lo envía con otra (R2, R5).

Etiqueta pop - operación de eliminación de etiquetas - realizada por el último enrutador - el nodo recibe el paquete MPLS y lo elimina arriba marca antes de pasarla (R6).

De hecho, se puede agregar y quitar una etiqueta en cualquier lugar dentro de una red MPLS.
Todo depende de los servicios específicos. Sería más correcto decir que la etiqueta la agrega el primer enrutador de la ruta (LSP) y la elimina el último.
Pero en este artículo, por simplicidad, hablaremos de los límites de la red MPLS.
Además, quitar la etiqueta superior no significa que quede un paquete IP puro, si hablamos de la pila de etiquetas. Es decir, si se realizó una operación de etiqueta emergente en un paquete con tres etiquetas, entonces quedan dos etiquetas y aún se procesa como MPLS. Pero en nuestro ejemplo había uno, pero después de eso no quedará ninguno, y esto ya es una cuestión de propiedad intelectual.

LSR- Enrutador de interruptor de etiquetas es cualquier enrutador en una red MPLS. Se llama así porque realiza algunas operaciones con etiquetas. En nuestro ejemplo, todos estos son nodos: R1, R2, R3, R4, R5, R6.
LSR se divide en 3 tipos:
LSR intermedio - enrutador MPLS intermedio: realiza la operación de intercambio de etiquetas (R2, R5).
LSR de ingreso - “entrada”, el primer enrutador MPLS: realiza la operación Push Label (R1).
LSR de salida - “salida”, el último enrutador MPLS - realiza la operación Pop Label (R6).
LER- Enrutador de borde de etiqueta es un enrutador en el borde de una red MPLS.
En particular, Ingress LSR y Egress LSR son de borde, lo que significa que también son LER.

LSP- Ruta conmutada de etiqueta - ruta para cambiar de etiqueta. Este es un canal unidireccional desde el LSR de entrada al LSR de salida, es decir, la ruta por la que el paquete pasará realmente a través de la red MPLS. En otras palabras, se trata de una secuencia LSR.
Es importante entender que LSP De hecho unidireccional. Esto significa que, en primer lugar, el tráfico a través de él se transmite solo en una dirección, en segundo lugar, si hay un "allí", no necesariamente hay un "atrás", en tercer lugar, el "atrás" no necesariamente sigue el mismo camino, es decir "allá". Bueno, es como las interfaces de túnel en GRE.

¿Cómo es LSP?

Sí, así de impresentable es.
Este es un resultado compilado de cuatro LSR: R1, R2, R5, R6. Es decir, en un LSR no verá una secuencia completa de nodos desde la entrada hasta la salida, como el atributo AS-PATH en BGP. Aquí, cada nodo conoce sólo las etiquetas de entrada y salida. Pero el LSP todavía existe.

Esto es un poco como el enrutamiento IP. Aunque existe una ruta desde el punto A al punto B, la tabla de enrutamiento solo conoce el siguiente salto hacia dónde enviar el tráfico. Pero la diferencia es que el LSR no decide sobre cada paquete en función de la dirección de destino: la ruta está predeterminada.

Y uno de los conceptos más importantes que debes comprender es FEC- Clase de equivalencia de reenvío . Por alguna razón me resultó muy difícil, aunque en esencia todo es sencillo. Los FEC son clases de tráfico. En el caso más simple, el identificador de clase es el prefijo de la dirección de destino (en términos generales, la dirección IP o subred de destino).
Por ejemplo, hay flujos de tráfico de diferentes clientes y diferentes aplicaciones que van todos a una dirección; todos estos flujos pertenecen a la misma clase, un FEC, usan un LSP.
Si llevamos otros flujos de otros clientes y aplicaciones a una dirección de destino diferente, esta será una clase diferente y un LSP diferente, respectivamente.

En teoría, además de la dirección de destino, FEC puede tener en cuenta, por ejemplo, etiquetas de QoS, dirección de origen, ID de VPN o tipo de aplicación. Es importante entender aquí que los paquetes del mismo FEC no tienen que ir a la misma dirección de destino. Y al mismo tiempo, aunque dos paquetes vayan al mismo lugar, no necesariamente pertenecerán al mismo FEC.

Explicaré por qué es necesario todo esto. El hecho es que para cada FEC se selecciona su propio LSP: su propio camino a través de la red MPLS. Y luego, por ejemplo, para navegar por la WEB, establece una prioridad (será un FEC) y para VoIP, otro FEC. Y además se puede indicar que para FEC BE el LSP debe tomar un camino amplio, pero largo y no garantizado, y para FEC EF puede ser estrecho pero rápido.

Desafortunadamente o afortunadamente, ahora sólo un prefijo IP puede actuar como FEC. No se consideran aspectos como las marcas de QoS.

Si presta atención a la tabla de etiquetas, FEC está presente allí, ya que los parámetros de reemplazo de etiquetas se determinan en función de FEC, pero esto se hace solo en el primer momento: cuando se distribuyen estas etiquetas. Cuando el tráfico real fluye a lo largo del LSP, nadie, excepto el LSR de Ingress, lo mira: solo etiquetas e interfaces. Todo el trabajo de determinar el FEC y a qué LSP enviar el tráfico lo realiza el Ingress LSR: una vez recibido un paquete limpio, lo analiza, comprueba a qué clase pertenece y le coloca la etiqueta adecuada. Los paquetes de diferentes FEC recibirán diferentes etiquetas y se enviarán a las interfaces correspondientes.
Los paquetes del mismo FEC reciben las mismas etiquetas.

Es decir, los LSR intermedios son máquinas trilladoras que no hacen más que cambiar de etiqueta para todo el tráfico de tránsito. Y todo el trabajo intelectual lo realizan los LSR de Ingress.

LIB- Base de información de etiquetas - tabla de etiquetas. Análogo a la tabla de enrutamiento (RIB) en IP. Indica para cada etiqueta de entrada qué hacer con el paquete: cambiar la etiqueta o eliminarla y a qué interfaz enviarlo.
LFIB- Base de información de envío de etiquetas - por analogía con FIB, esta es una base de etiquetas a la que accede el procesador de red. Al recibir un nuevo paquete, no es necesario ponerse en contacto con la CPU y consultar la tabla de etiquetas: todo ya está a mano.

Una de las ideas originales de MPLS (separar el plano de control y el plano de datos tanto como sea posible) ha caído en el olvido.
Los desarrolladores querían que no hubiera ningún análisis al transmitir un paquete a través de un enrutador: simplemente leían la etiqueta, la cambiaban por otra y la transmitían a la interfaz deseada.
Para lograr esto, hubo dos procesos separados: una construcción relativamente larga de la ruta (Plano de control) y una transmisión rápida de tráfico a lo largo de esta ruta (Plano de datos).

Pero con la llegada de chips baratos (ASIC, FPGA) y mecanismos FIB, la transmisión IP regular también se ha vuelto rápida y sencilla.
Para un enrutador, no importa dónde mirar al transmitir un paquete: al FIB o al LFIB.
Pero lo que sin duda es importante y útil es que MPLS es indiferente a lo que se transmite bajo su título: IP, Ethernet, ATM. No hay necesidad de preocuparse por GRE ni por ninguna otra VPN dolorosamente incómoda. Pero hablaremos de esto más tarde.

encabezado MPLS

Todo el encabezado MPLS es de 32 bits. El formato y la longitud del campo son fijos. A menudo, todo el encabezado se denomina etiqueta, aunque esto no es del todo cierto.

Etiqueta - la propia etiqueta. Longitud: 20 bits.
TC - Clase de Tráfico. Lleva la prioridad del paquete, como el campo DSCP en IP.
Longitud 3 bits. Es decir, puede codificar 8 valores diferentes.
Por ejemplo, al transmitir un paquete IP a través de una red MPLS, el valor en el campo DSCP se asigna de cierta manera al valor TC. Así, un paquete se puede procesar casi por igual en colas a lo largo de todo su recorrido, tanto en la sección IP pura como en MPLS.
Pero, naturalmente, esta conversión tiene pérdidas: seis bits DSCP están apretados en 3 bits TC: 64 frente a 8. Por lo tanto, existe una tabla de correspondencia especial, donde toda la gama- es sólo un significado.

Inicialmente, el campo se llamó EXP (experimental) y su contenido no estaba regulado. Se suponía que podría utilizarse para la investigación y la introducción de nuevas funciones. Pero eso es cosa del pasado.
Si alguien discute con usted que este campo es experimental y no ha sido aprobado formalmente para la función QoS, no está torpe, está bastante atrasado.

=====================

La red está configurada con una política de QoS simple en la que los paquetes IP que van desde el host 10.0.17.7 a la dirección 6.6.6.6 se marcan y transmiten a través de la red MPLS. El campo EXP se utiliza para marcar paquetes, valor de campo 3.

Esquema

El enrutador R6 está configurado con una política de QoS que clasifica los paquetes según el campo EXP.
Pero, al comprobarlo, resultó que la política no funciona en R6. Es decir, no llegan paquetes con un valor EXP de 3 y todos los paquetes caen en la clase predeterminada.

Tarea: Corrija la configuración para que funcione la política en R6.

El enrutador R7 se utiliza como cliente. En consecuencia, MPLS entre R7 y R1 no está habilitado.

Detalles de tarea y configuración.
=====================

S - Parte inferior de la pila: indicador de la parte inferior de la pila de etiquetas, de 1 bit de longitud. Puede haber varios encabezados MPLS en un paquete, por ejemplo, uno externo para conmutar en la red MPLS y uno interno que indica una VPN específica. Para que el LSR entienda a qué se enfrenta. Se escribe “1” en el bit S si esta es la última etiqueta (se ha llegado al final de la pila) y “0” si la pila contiene más de una etiqueta (aún no está al final). Es decir, el LSR no sabe cuántas etiquetas hay en la pila, pero sí sabe si hay una o más, y esto es suficiente. Después de todo, cualquier decisión se toma basándose únicamente en la marca superior, independientemente de lo que haya debajo. Pero, habiendo quitado la etiqueta, ya sabe qué hacer a continuación con el paquete: seguir trabajando con el proceso MPLS o dárselo a algún otro (IP, Ethernet, ATM, FR, etc.).

Esta frase: "Pero al quitar la marca, ya sabe qué hacer a continuación con el paquete": es necesario dar una explicación. El encabezado MPLS, como habrá notado, no contiene información sobre el contenido (como Ethertype en Ethernet o Protocol en IP).
Por un lado, esto es bueno, dentro puede haber cualquier cosa, mayor flexibilidad, pero por otro lado, ¿cómo se puede determinar ahora a qué proceso transferir toda esta gestión sin analizar el contenido?
Y aquí hay un pequeño truco: el enrutador, como verá más adelante, siempre asigna la etiqueta y la pasa a sus vecinos, por lo que sabe por qué la asignó: para IP o para Ethernet o algo más. Entonces simplemente agrega esta información a su tabla de etiquetas. Y la próxima vez que realice la operación Pop Label, ya sabrá por la tabla (y no por el paquete) qué hacer a continuación.

En general, la pila aquí es en el sentido clásico: último puesto, primero tomado (LIFO - Última entrada - Primera salida).

Como resultado, a pesar de que la longitud del encabezado MPLS es fija, puede haber muchos encabezados y todos están ubicados uno tras otro.

TTL - Time To Live - análogo completo. Incluso tiene la misma longitud: 8 bits. La única tarea es evitar que el paquete deambule sin cesar por la red en caso de un bucle. Al transmitir un paquete IP a través de una red MPLS, el valor TTL de IP se puede copiar al TTL de MPLS y luego regresar. O la cuenta regresiva comenzará nuevamente desde 255, y al ingresar a una red IP pura, el valor IP TTL será el mismo que antes de ingresar.

Como puede ver, el encabezado MPLS está comprimido entre capa de enlace y los datos que transporta - en el caso de IP - red. Por lo tanto, metafóricamente MPLS se denomina tecnología de capa 2.5 y el encabezado es Shim-header - encabezado de cuña.
Por cierto, la etiqueta no tiene por qué estar en el encabezado MPLS. Según la decisión del IETF, se puede integrar en encabezados ATM, AAL5 y Frame Relay.

Así es como se ve en la vida real:

Espacio de etiqueta

Como se mencionó anteriormente, puede haber 2 ^ 20 etiquetas.

De ellos, varios están reservados:

0 : Etiqueta NULL explícita de IPv4. "Etiqueta vacía explícita". Se utiliza en el último salto MPLS, antes del LSR de salida, para notificarle que esta etiqueta 0 se puede eliminar sin mirar la tabla de etiquetas (más precisamente LFIB).
Para aquellos FEC que se originan localmente (conectados directamente), Egress LSR asigna la etiqueta 0 y la pasa a sus vecinos: el penúltimo LSR (Penúltimo LSR).
Al transmitir un paquete de datos, el penúltimo LSR cambia la etiqueta actual a 0.
Cuando el LSR de salida recibe un paquete, sabe con certeza que simplemente se debe quitar la etiqueta superior.

No siempre fue así. Originalmente se propuso que la etiqueta 0 solo pudiera estar en la parte inferior de la pila de etiquetas y, al recibir un paquete con dicha etiqueta, el LSR debería borrar las referencias a MPLS por completo y comenzar a procesar los datos.
En algún momento, los teóricos, bajo presión de los profesionales, coincidieron en que esto era irracional y que no podían encontrar una aplicación real, por lo que abandonaron ambas condiciones.
Entonces, ahora la etiqueta 0 no es necesariamente la última (inferior) y durante la operación de etiqueta emergente solo se elimina, mientras que las inferiores permanecen y el paquete se procesa adicionalmente de acuerdo con la nueva etiqueta superior.

1 : Etiqueta Etiqueta de alerta del enrutador- análogo de la opción Alerta de enrutador en IP - puede estar en cualquier lugar excepto en la parte inferior de la pila. Cuando llega un paquete con dicha etiqueta, se debe transferir al módulo local y luego se conmuta de acuerdo con la etiqueta que estaba debajo, la de transporte real, y la etiqueta 1 se debe agregar nuevamente a la parte superior de la pila. .

2 : Etiqueta NULL explícita de IPv6- Igual que 0, sólo ajustado para la versión del protocolo IP.

3 : Nulo implícito. Una etiqueta ficticia que se utiliza para optimizar el proceso de transmisión de un paquete MPLS al LSR de salida. Esta etiqueta puede anunciarse, pero en realidad nunca se utiliza en el encabezado MPLS. Veámoslo más tarde.

4-15 : Reservado.

Dependiendo del proveedor, se pueden fijar otros valores de etiqueta, por ejemplo, en los equipos Huawei, las etiquetas 16-1023 se usan para LSP estáticos y todos los valores superiores se usan para LSP dinámicos. En Cisco, las etiquetas disponibles comienzan a partir del día 16.

En el siguiente diagrama, todos los enrutadores excepto el R5 son enrutadores de Huawei. R5-Cisco.

Esquema

Para la configuración del enrutador R5 a continuación, debe configurarlo para que la distribución del valor de la etiqueta coincida con Huawei. El caso es que en Huawei las etiquetas dinámicas comienzan con 1024 y en Cisco con 16.

Configuración R5

ip cef
!
interfaz Loopback0

enrutador ip isis
!
interfaz FastEthernet0/0
descripción a R4

enrutador ip isis
mps ip
!
interfaz FastEthernet0/1
descripción a R2

enrutador ip isis
mps ip
!
interfaz FastEthernet1/0
descripción a R6

enrutador ip isis
mps ip
!
enrutador isis
neto 10.0000.0000.0005.00
!

Rápido, sencillo, comprensible, aunque no siempre es necesario que todo el mundo lo sepa todo.

Segundo modo - Departamento de Defensa Downstream bajo demanda . El LSR conoce la FEC, tiene vecinos, pero hasta que preguntan cuál es la etiqueta para una FEC determinada, el LSR permanece en silencio.

Este método es conveniente cuando se imponen algunos requisitos al LSP, por ejemplo, en términos de ancho de banda. ¿Por qué enviar una etiqueta así si será descartada inmediatamente? Es mejor que el LSR ascendente le pregunte al LSR descendente: necesito una etiqueta suya para este FEC, y el LSR ascendente: "ok, aquí vamos".

El modo de asignación de etiquetas es específico de la interfaz y se determina en el momento en que se establece la conexión. Ambos métodos se pueden utilizar en una red, pero en una misma línea los vecinos deben ponerse de acuerdo solo en uno en concreto.

Control ordenado versus control independiente

En segundo lugar, El LSR puede esperar a que llegue la etiqueta de este FEC desde el LER de salida antes de avisar a sus vecinos ascendentes. O podría enviar etiquetas para FEC tan pronto como se enterara.

El primer modo se llama Control ordenado

Garantiza que para cuando se transmitan los datos, se habrá construido toda la ruta hasta el LER de salida.

Segundo modo - Control independiente .

Es decir, las etiquetas se transmiten desordenadas. Es conveniente porque el tráfico puede comenzar a transmitirse incluso antes de que se construya todo el camino. Por eso también es peligroso.

Modo de retención de etiquetas liberal versus modo de retención de etiquetas conservador

En tercer lugar Lo que importa es cómo el LSR maneja las etiquetas que se le pasan.
Por ejemplo, en tal situación, ¿debería R1 almacenar información sobre la etiqueta 20 recibida del vecino R3, que no es la mejor manera de llegar a R6?

Y esto está determinado por el modo de retención de etiquetas.
Modo de retención de etiquetas liberal - las etiquetas se guardan. En el caso de que R3 se convierta en el siguiente paso (por ejemplo, problemas con la ruta principal), el tráfico se redirigirá antes porque la etiqueta ya está allí. Es decir, la velocidad de reacción es mayor, pero el número de etiquetas utilizadas también es grande.
Modo de retención de etiquetas conservador - la etiqueta sobrante se desecha tan pronto como se recibe. Esto reduce la cantidad de etiquetas utilizadas, pero MPLS también responderá más lentamente en caso de un desastre.

PHP

No, este no es el PHP en el que estás pensando. se trata de Penúltimo salto de lúpulo. Todos los ingenieros Un poco optimizadores, y aquí los chicos pensaron: ¿por qué necesitamos procesar los encabezados MPLS dos veces: primero en el penúltimo enrutador y luego nuevamente en el enrutador de salida?
Y decidieron que la etiqueta debería eliminarse en el penúltimo LSR y llamaron a esta acción PHP.
Hay una etiqueta especial para PHP - 3.
Volviendo a nuestro ejemplo, para FEC 6.6.6.6 y 172.16.0.2, R6 asigna la etiqueta 3 y la informa a R5.
Al transmitir un paquete a R6, R5 debe asignarle una etiqueta ficticia: 3, pero en realidad no se aplica y se envía un paquete IP desnudo a la interfaz (vale la pena señalar que PHP solo funciona en redes IP), es decir , el procedimiento Pop Label se realizó en R5.

Sigamos la vida del paquete, teniendo en cuenta todo lo que sabemos ahora.

La forma en que se transmite el tráfico parece más o menos clara. ¿Pero quién hace todo el trabajo titánico de crear etiquetas y completar tablas?

Protocolos de distribución de etiquetas

No hay muchos: tres: LDP, RSVP-TE, MBGP.
Hay dos objetivos globales: la distribución de etiquetas de transporte y la distribución de etiquetas de servicio.
Expliquemos: etiquetas de envío son usados para la transmisión de tráfico a través de la red MPLS. Estos son exactamente de los que hemos estado hablando a lo largo de este episodio. Para ellos se utilizan LDP y RSVP-TE.

Marcas de servicio atender para la separación diversos servicios. Aquí es donde MBGP y la rama del PLD entran en escena.
En particular, MBGP permite, por ejemplo, marcar que tal o cual ruta pertenece a tal o cual VPN. Luego pasa esta ruta como familia vpn-ipv4 a su vecino con una etiqueta, para que luego pueda separar las moscas de las chuletas.
Entonces, para que pueda separarse, debe ser informado sobre el cumplimiento de la etiqueta FEC.
Pero ésta es la acción de otra obra, que representaremos dentro de seis meses o un año más.

Un requisito previo para el funcionamiento de todos los protocolos de distribución dinámica de etiquetas es la configuración básica de la conectividad IP. Es decir, los IGP deben estar ejecutándose en la red.

Bueno, ahora que te he confundido por completo, puedes empezar a desentrañar.
Entonces, ¿cuál es la forma más sencilla de distribuir las etiquetas? La respuesta es habilitar LDP.

PLD

Un protocolo con un nombre muy transparente - Protocolo de distribución etiquetado- tiene un principio de funcionamiento correspondiente.
Echemos un vistazo a la red linkmeup, que hemos estado cubriendo a lo largo de este episodio:

1. Después de habilitar LDP, el LSR multidifunde datagramas UDP a todas las interfaces a la dirección 224.0.0.2 y al puerto 646, donde se activa LDP; así es como se buscan los vecinos.
El TTL de dichos paquetes es 1 porque la adyacencia LDP se establece entre nodos conectados directamente.

En general, no siempre es así -se puede establecer una sesión LDP para determinados fines y con un nodo remoto, entonces se llama tLDP-. Hablaremos de ello en otros números.

Estos mensajes se llaman Hola.

2. Cuando se detectan vecinos se establece conexión TCP con ellos, también en el puerto 646 - Inicialización. Los demás mensajes (excepto Hello) se transmiten con un TTL de 255.

3. Los LSR ahora intercambian mensajes periódicamente Mantener vivo direccionado a través de TCP y aún así no dejes de intentar encontrar vecinos usando Hello.

4. En algún momento, uno de los LSR descubre una segunda personalidad, Egress LSR, es decir, es la salida de algún FEC. Este es un hecho que debe comunicarse al mundo.
Dependiendo del modo, espera una solicitud de etiqueta para un FEC determinado o la envía inmediatamente.

Esta información se transmite en un mensaje. Mensaje de asignación de etiquetas. Según el nombre, lleva la correspondencia entre el FEC y la etiqueta.

R5 recibe información sobre el cumplimiento de FEC 6.6.6.6/32 y la etiqueta 3 (nulo implícito) y la escribe en su tabla de etiquetas. Ahora, cuando necesite enviar datos a 6.6.6.6, sabrá que debe eliminar el encabezado MPLS superior y enviar el paquete restante a la interfaz FE1/0.

Ahora R5 sabe que si llega un paquete MPLS con la etiqueta 20, debe transmitirse a la interfaz FE1/0 quitando la etiqueta, es decir, ejecutando el procedimiento PHP.

R2 recibe información de R5 sobre el cumplimiento de la etiqueta FEC (6.6.6.6 - 20), la ingresa en la tabla y, habiendo creado su propia etiqueta de entrada (18), la transmite aún más arriba. Y así sucesivamente hasta que todos los LSR hayan recibido su etiqueta de salida.

Por lo tanto, hemos construido un LSP de R1 a R6. R1, al enviar un paquete a 6.6.6.6/32, le agrega la etiqueta 18 (Push Label) y lo envía al puerto FE0/0. R2, después de recibir un paquete con la etiqueta 18, cambia la etiqueta a 20 (Etiqueta de intercambio) y lo envía al puerto FE0/0. R5 ve que para un paquete con etiqueta 20, es necesario ejecutar PHP (etiqueta de salida - 3 - nulo implícito), elimina la etiqueta (Pop Label) y envía los datos al puerto FE1/0.

Al mismo tiempo, se construyeron en paralelo LSP de R2 a R6, de R5 a R6, de R4 a R6, etc. Es decir, de todos los LSR, simplemente no lo mostré en la ilustración.

Si tienes suficiente fuerza, en el gif a continuación puedes ver todo el proceso en dinámica.

Naturalmente, comprende que no solo R6 de repente comenzó a enviar sus coincidencias de etiquetas FEC, sino también todos los demás: R1 sobre 1.1.1.1/32, R2 - 2.2.2.2/32, etc. Todos estos mensajes se transmiten a la velocidad del rayo a través de la red MPLS, creando docenas de LSP. Como resultado, cada LSR conocerá todas las FEC existentes y se creará el LSP correspondiente.

Nuevamente, en el gif de arriba el proceso no se muestra completamente, R1 luego transmite información a R3, R3 a R4, R4 a R5.
Y si miramos R5, vemos que para FEC 6.6.6.6/32 no tenemos una etiqueta de salida, como se esperaba, sino 3:

Además, el propio R6 registrará la etiqueta para FEC 6.6.6.6, que recibe del R5:

en uso- correcto - diablillo-nulo hacia R6. Pero los otros dos del ring son de R2 y R4. Esto no es un error ni un bucle: simplemente R2 y R4 generaron estas etiquetas para el FEC 6.6.6.6/32 que conocen de la tabla de enrutamiento.

Surgen dos preguntas:
1) ¿Cómo planea usarlos? No tienen ni idea. Respuesta: de ninguna manera. No puede haber una situación en nuestra red en la que 2.2.2.2 o 4.4.4.4 sean los siguientes nodos en el camino hacia 6.6.6.6; IGP no construirá una ruta como esa. Esto significa que las etiquetas no se utilizarán. LDP es simplemente estúpido: sus mensajes se encuentran dispersos por toda la red y llegan a cada grieta. Y un LSR inteligente ya decidirá cuál usar.
2) ¿Qué pasa con los bucles? ¿Los mensajes LDP no viajarán por la red hasta que expire el TTL?
Pero aquí todo es simple: recibir un nuevo mensaje de asignación de etiquetas no inicia la creación de uno nuevo; la correspondencia resultante simplemente se escribe en la tabla LDP. Es decir, en nuestro caso, R5 ya creó una etiqueta para FEC 6.6.6.6/32 una vez y la envió a sus vecinos ascendentes, y no cambiará hasta que se reinicie el proceso LDP.

Es posible que ya haya notado que al configurar LDP, es posible habilitar la función de detección de bucle, pero me apresuro a tranquilizarlo: esto es para redes donde no hay TTL, por ejemplo, ATM. Esta funcionalidad cambiará LDP al modo DoD.

Esta es información básica sobre cómo funciona LDP.
De hecho, aquí todo depende en gran medida del fabricante. En principio, LDP admite todos los modos posibles de trabajar con etiquetas: DoD/DU, Control Independiente/Control Ordenado y Conservador/Liberal Retención de Etiquetas. Esto no está regulado de ninguna manera por el RFC, por lo que cada proveedor es libre de elegir su propio camino.
Por ejemplo, básicamente todo el mundo usa DU para LDP, pero en Juniper las etiquetas se distribuyen de forma ordenada y en Cisco se distribuyen de forma independiente.
Solo las interfaces LSR Loopback se seleccionan como FEC en Huawei y Juniper, mientras que Cisco FEC se crea para todas las entradas en la tabla de enrutamiento.

Pero es poco probable que todo esto tenga algún impacto en la red real.

Lo más importante que hay que entender sobre LDP es que no utiliza protocolos de enrutamiento dinámico en su funcionamiento; en principio, es similar a: inunda toda la red con etiquetas, pero al mismo tiempo se basa en información de la tabla de enrutamiento LSR. . Y si R1 recibe dos etiquetas para el mismo FEC de diferentes vecinos, seleccionará para el LSP solo la recibida a través de mejor interfaz ante esta FEC según información de TM.
Esto significa tres cosas:

• Eres libre de elegir el IGP que más te guste, incluso RIP.
• LDP siempre construye solo una (la mejor) ruta y no puede construir, por ejemplo, una de respaldo.
• Cuando cambia la topología de la red, el LSP se reconstruirá de acuerdo con la tabla de enrutamiento actualizada, es decir, el IGP primero debe converger y solo entonces el LSP aumentará.

En general, después de habilitar LDP, el tráfico fluirá de la misma manera que sin él, con la única diferencia de que aparecen etiquetas MPLS.
Incluyendo LDP, como IP, admite, solo que los algoritmos para calcular el hash y, por lo tanto, el equilibrio, pueden diferir.

Para habilitar MPLS globalmente, debe emitir dos comandos:
R1(configuración)#ip cef
R1(configuración)#mpls ip
El primero ya es un estándar de facto y de jure en casi cualquier equipo de red- inicia el mecanismo CEF en el enrutador, el segundo inicia MPLS y LDP globalmente (también se puede proporcionar de forma predeterminada).

La ID del enrutador (y en terminología más general (no de Cisco) LSR ID) en MPLS se selecciona simplemente:

1. La dirección más grande de interfaces Loopback.
2. Si no están allí, entonces la dirección IP más grande configurada en el enrutador.

Naturalmente, no debes confiar en la automatización; configuremos el ID de LSR manualmente:
R1(config)# mpls ldp router-id Loopback0 fuerza
Si no agrega una palabra clave "fuerza", la ID del enrutador cambiará solo cuando se restablezca la sesión LDP. "Fuerza" obliga al enrutador a cambiar la ID del enrutador a la fuerza y, si es necesario (si ha cambiado), restablece la conexión LDP.

A continuación, en las interfaces requeridas emitimos el comando mps ip:
R1(config)#interfaz FastEthernet 0/0
R1(config-if)#mpls ip
R1(config)#interfaz FastEthernet 0/1
R1(config-if)#mpls ip
Cisco vuelve a utilizar aquí su principio de ingeniero perezoso: mínimo esfuerzo por parte del personal. Equipo mps ip habilita LDP en la interfaz simultáneamente con MPLS, lo queramos o no. De igual manera el equipo ip pim en modo disperso habilita IGMP en la interfaz, como describí en el artículo sobre .
Después de activar LDP, el enrutador comienza a probar las aguas a través de UDP:

Los verificadores se envían a la dirección de multidifusión 224.0.0.2.

Ahora repetimos las mismas manipulaciones en R2.
R2(configuración)#ip cef
R2(configuración)#mpls ip
R2(config)# mpls ldp router-id Loopback0 fuerza
R2(config)#interfaz FastEthernet 0/0
R2(config-if)#mpls ip
R2(config)#interfaz FastEthernet 0/1
R2(config-if)#mpls ip
y disfruta del resultado.
R2 también busca vecinos.

Nos enteramos y R2 abre una sesión LDP:

Si te preguntas cómo establecen una conexión TCP

Ahora son vecinos, lo cual el equipo puede comprobar fácilmente. mostrar vecino mpls ldp.

Aquí ya puede ver los detalles: R1 transmite 12 FEC a la vez, uno para cada entrada en su tabla de enrutamiento. En la misma situación, Huawei o Juniper solo transmitirían seis direcciones FEC de interfaces Loopback, porque de forma predeterminada consideran que solo los prefijos /32 son FEC.
En este sentido, Cisco desperdicia mucho el uso de recursos de etiquetas.
Sin embargo, este comportamiento se puede cambiar en cualquier hardware. En nuestro caso, el equipo puede ayudar. mpls ldp etiquetas-publicitarias.

¿Pero cómo es esto posible?, os preguntaréis. ¿Es suficiente tener etiquetas sólo en Loopback?

Si recordamos que al principio del artículo consideramos que los prefijos BGP no reciben sus propias etiquetas y que las etiquetas solo son necesarias para el siguiente salto, entonces queda claro que las etiquetas para Loopback son suficientes.

Para poder llegar a otras redes dentro de nuestro AS sólo necesitamos un IGP.

=====================

Si Cisco anuncia de forma predeterminada etiquetas para todas las redes (excepto las recibidas a través de BGP), en Juniper, de forma predeterminada, solo se anuncia loopback.

Esquema

Todos los enrutadores excepto el R5 son enrutadores Juniper.

Para la configuración del enrutador R5 a continuación, configúrela de modo que la configuración del enrutador Cisco coincida con la configuración predeterminada en Juniper.

Configuración R5

ip cef
!
interfaz Loopback0
dirección IP 5.5.5.5 255.255.255.255
enrutador ip isis
!
interfaz FastEthernet0/0
descripción a R4
dirección IP 10.0.45.5 255.255.255.0
enrutador ip isis
mps ip
!
interfaz FastEthernet0/1
descripción a R2
dirección IP 10.0.25.5 255.255.255.0
enrutador ip isis
mps ip
!
interfaz FastEthernet1/0
descripción a R6
dirección IP 10.0.56.5 255.255.255.0
enrutador ip isis
mps ip
!
enrutador isis
neto 10.0000.0000.0005.00
!
mpls ldp router-id Loopback0 fuerza

Y después de eso, echemos un vistazo nuevamente a la tabla de conmutación MPLS en R1:

Ya han aparecido etiquetas para todos los FEC.
Caminemos por el LSP desde R1 hasta R6 y veamos cómo cambian las etiquetas a lo largo del camino.

Medio
1. cuando R1 21 Fa0/0 y cambiar la etiqueta a 18 .
2. cuando R2 recibe un paquete MPLS con una etiqueta 18 , debería pasarlo a la interfaz. Fa0/0 y cambiar la etiqueta a 20 .
3. Cuando R5 recibe un paquete MPLS con una etiqueta 20 , debería pasarlo a la interfaz. Fa1/0 y quitar la marca - PHP.

En este caso, los LSR ni siquiera piensan en mirar nada en la tabla de enrutamiento o en ip cef; simplemente hacen malabarismos con las etiquetas.

La tabla de conmutación, que ya hemos visto con el comando mostrar tabla de reenvío mpls- Este LFIB (Base de información de envío de etiquetas ) - casi una obviedad para la transferencia de datos - este es el Plano de Datos. Pero ¿qué pasa con el plano de control? ¿Es poco probable que el PLD sepa tanto? ¿Seguramente todavía tiene algunas cartas de triunfo bajo la manga?
Esto es cierto:

Para cada FEC vemos aquí información sobre varias etiquetas:
enlace local- ¿Qué transmite este LSR a sus vecinos?
enlace remoto- lo que este LSR recibió de sus vecinos.

En la ilustración de arriba puedes ver la palabra "tib". TIB es Base de información de etiquetas , que se llama correctamente Base de información de etiquetas - LIB.
Esta es una reliquia del antepasado fallecido del PLD.

Tenga en cuenta que hay 2 enlaces remotos en todas partes: estas son dos formas de obtener etiquetas. Por ejemplo, puede llegar a R2 desde R1 directamente o mediante R3-R4-R5-R2.
Es decir, lo entiendes, ¿verdad? No solo convierte FEC en cada entrada de la tabla de enrutamiento, sino que este sinvergüenza también utiliza el modo de retención liberal para conservar las etiquetas.
Resumamos: de forma predeterminada, LDP en Cisco funciona en los siguientes modos:

• Control independiente
• Modo de retención liberal
• Todas las entradas en la tabla de enrutamiento se seleccionan como FEC

En resumen, su generosidad no tiene límites.

hay otro equipo mostrar enlace ip mpls. Muestra algo similar y también le permite descubrir rápidamente qué ruta está activa actualmente, es decir, cómo está construido el LSP:

Y quizás la última pregunta que surge en relación con todos estos LSP es cuando el enrutador en sí es un Ingress LSR, ¿cómo entiende qué se debe hacer con los paquetes, cómo elegir un LSP?
Y para ello tendrás que investigar IP CEF. En general, es el Ingress LSR el que soporta toda la carga de procesar el paquete, determinar la FEC y asignar las etiquetas correctas.

Aquí tienes Next Hop y la interfaz de salida y la etiqueta de salida.

Y aquí debe notar que en LDP los conceptos de LER, Ingress LSR, Egress LSR no son la función de ningún nodo específico ni una característica de la ubicación de un nodo en la red. Son inseparables de FEC y LSP y son individuales para ellos. Es decir, para cada FEC específico hay uno o más LSR de salida y muchos LSR de entrada (normalmente todos los enrutadores) a los que conducen los LSP.
Incluso digamos que los conceptos de LER surgen cuando hablamos de un LSP específico, entonces podemos decir quién es el Ingress y quién es el Egress.

MPLS y BGP

Hasta ahora hemos hablado de cómo interactúa MPLS con los protocolos IGP. Nos aseguramos de que no tenga nada de complicado y que la configuración también sea bastante sencilla.

Pero lo más interesante radica en la interacción de MPLS con BGP. En este número sólo tocaremos brevemente este tema. Pero en los próximos hablaremos más sobre el papel que juega BGP y cómo con su ayuda y MPLS podemos organizar diferentes tipos de VPN.
Ahora necesitamos entender cómo interactúan MPLS y BGP en el nivel más básico.

La principal diferencia entre BGP e IGP es que MPLS no crea etiquetas para las rutas BGP. Si recuerdas cuántas rutas lleva BGP, queda claro que esto es muy Buena idea. ¿Cómo entonces conectar MPLS y BGP?
Es sencillo:

1. Creamos etiquetas solo para direcciones que se indicarán como siguiente salto para las rutas que recibimos a través de BGP (aquí no debemos olvidarnos del siguiente salto para los vecinos IBGP).
2. Cuando nuestro Ingress LSR necesita transmitir paquetes a lo largo de la ruta que se recibió a través de BGP, los enviamos al siguiente salto especificado en la ruta y usamos la etiqueta que se creó para ello.

Ahora, en lugar de configurar BGP en cada enrutador de nuestro AS, podemos configurarlo solo en los enrutadores de borde a los que están conectados los clientes u otros proveedores.

Veamos una red de ejemplo:

Si necesitamos pasar del R1 a las redes de Certificados Filkin, vemos que se puede acceder a ellas a través del R6 y “volar” a través de MPLS hasta la dirección 6.6.6.6. Y cuando llegamos a R6, ya sabe adónde ir a continuación. Lo mismo ocurrirá al revés, en Balagan-Telecom.

La configuración de este circuito y un par de comandos con salida de información se pueden encontrar en el enlace.

MPLS y OSPF están configurados en la red. MPLS se configura en toda la red excepto en la conexión entre R7 y R1.
Entre los enrutadores R1-R2-R3-R4-R5-R6, el tráfico debe transmitirse mediante MPLS.
La red también está configurada con BGP, que se ejecuta entre R1 y R6.

No se generan etiquetas para las rutas BGP.
Para que R1 alcance las rutas que se reciben vía BGP desde R6, los paquetes se transmiten vía MPLS a la dirección IP que se especifica como el siguiente salto en las rutas BGP.

Actualmente, la ruta anunciada vía BGP por el enrutador R6 no está disponible desde R7.

Ejercicio:
Restaure la operación de la red para que R7 pueda hacer ping a la dirección 100.0.0.1.

Restricciones:
La configuración de BGP no se puede cambiar.

Esquema

Detalles de la tarea y configuración del nodo.
=====================

Confirmar asistencia-TE

El PLD es bueno. Funciona de forma sencilla y clara. Pero existe una tecnología como MPLS TE - Ingeniería de tráfico. Y la mejor ruta que el PLD puede ofrecerle no es suficiente para ella.
La dirección del tráfico significa que puede dirigir el tráfico entre nodos como desee, sujeto a diversas restricciones.
Por ejemplo, en nuestra red, el cliente tiene dos puntos de conexión para sus nodos: en R1 y en R6. Y entre ambos pide que le proporcionen una VPN con un ancho de canal garantizado de 100 Mb/s. Pero al mismo tiempo, en nuestra red también tenemos usuarios habituales de banda ancha que transmiten vídeos de VKontakte y una docena más de clientes que alquilan VPN, pero no necesitan reservar el ancho de banda.
Si no interviene en esta situación, puede ocurrir una sobrecarga en algún lugar del R2 y 100 Mb/s para querido cliente no lo entenderé.

MPLS TE le permite atravesar toda la red desde el remitente hasta el receptor y reservar recursos en cada nodo. Si está familiarizado con el concepto de IntServ, entonces sí, eso es exactamente lo que es: proporcionar QoS a lo largo de toda la ruta, en lugar de permitir que cada enrutador tome sus propias decisiones sobre el paquete que pasa.
En realidad, el protocolo Confirmar asistencia (Protocolo de reserva de recursos ) inicialmente (en 1993) y fue concebido para organizar IntServ en redes IP. Tenía que transmitir información de QoS para un flujo de datos específico a cada nodo y obligarlo a reservar recursos.

En una primera aproximación, funciona de forma sencilla.

1) El nodo de origen quiere enviar un flujo de datos a una velocidad de 5 Mb/s. Pero antes de eso, envía una solicitud de confirmación de asistencia para reservar el ancho de banda al destinatario. Mensaje de ruta. Este mensaje contiene ciertos identificadores de flujo, mediante los cuales el nodo puede identificar la pertenencia al flujo de los paquetes IP recibidos y el ancho de banda requerido.
2) El mensaje Ruta se transmite de nodo a nodo hasta el destinatario. Dónde enviarlo se determina en función de la tabla de enrutamiento.
3) Cada enrutador, después de recibir la Ruta, verifica sus recursos. Si tiene suficiente ancho de banda libre, ajusta sus algoritmos internos para que los paquetes del flujo se procesen correctamente y ancho de banda siempre había suficiente.
4) Si no tiene los 5 Mb/s requeridos (ocupados por otros subprocesos), se niega a asignar recursos y devuelve el mensaje correspondiente al remitente.
5) El paquete Ruta llega al destinatario de la transmisión, quien devuelve un mensaje. resv, confirmando la asignación de recursos a lo largo de todo el camino.
6) El remitente original, al recibir la Resv, entiende que todo está listo para él y puede enviar datos.

De hecho, detrás de estos cuatro sencillos pasos se esconden procesos mucho más complejos, pero eso no nos interesa.

Pero lo que nos interesa es la ampliación Confirme su asistencia para ingeniería de tráfico, o más simplemente - Confirmar asistencia, que fue desarrollado específicamente para MPLS TE.
Su tarea es la misma que la de LDP: distribuir etiquetas entre LSR y, en última instancia, compilar el LSP del destinatario al remitente. Pero ahora, como ya comprenderá, aparecen matices: el LSP debe cumplir ciertas condiciones.

RSVP TE le permite crear un LSP primario y de respaldo, reservar recursos en todos los nodos, detectar fallas de red, crear soluciones alternativas con anticipación, redirigir rápidamente el tráfico y evitar canales que pasan físicamente por una ruta.
Pero todo esto lo discutiremos en un artículo sobre MPLS TE en un par de números. Hoy nos centraremos en los principios mediante los cuales RSVP TE construye un LSP.

Cambiar el protocolo no cambia el hecho de que el LSP es unidireccional y, en consecuencia, los recursos se reservarán solo en una dirección. Si quieres algo más, crea un LSP inverso.

Para empezar, descartaremos la funcionalidad de reserva de recursos; dejaremos que nuestra tarea sea solo crear un LSP, es decir, distribuir etiquetas entre LSR.

Para que esto sea posible, el RSVP estándar se amplía para incluir varios objetos. Consideremos la opción más sencilla.
0) R1 necesita LSP hasta FEC 6.6.6.6/32. Esto parece una interfaz de túnel en R1 con una dirección de destino 6.6.6.6 y tipo Ingeniería de tráfico.
1) Envía un mensaje RSVP Path en la dirección 6.6.6.6. Aparece un nuevo objeto en este mensaje: Solicitud de etiqueta. El mensaje Ruta hace que el nodo asigne una etiqueta para un FEC determinado; es decir, es una solicitud de etiqueta.
2) El siguiente nodo genera un nuevo mensaje de Ruta y también lo envía hacia 6.6.6.6. Etc.
3) El camino llega a la salida LSR. Ve que el paquete está dirigido a él, selecciona una etiqueta y envía un mensaje Resv a la fuente. Este ultimo tambien agrego un nuevo objeto: Etiqueta. En él, el Egress LSR pasa su etiqueta para este FEC al penúltimo, el penúltimo pasa su etiqueta al penúltimo, etc.
4) Resv llega a la fuente, distribuyendo etiquetas a lo largo del camino. Esto crea el LSP y notifica a la fuente que todo está listo.

Las etiquetas se solicitan en sentido descendente (mensaje de ruta del remitente al receptor) y se transmiten en sentido ascendente (mensaje Resv del receptor al remitente).
Al mismo tiempo, tenga en cuenta que este ya es el control ordenado más abajo bajo demanda +. La ruta actúa como una solicitud de etiqueta, y Resv proviene del destinatario paso a paso, y hasta que el LSR descendente haya enviado la etiqueta, el LSR ascendente no puede enviarla a sus vecinos.

¡Detener! Dijimos que RSVP TE, a diferencia de LDP, nos permite construir como queramos, sin estar atados a la tabla de enrutamiento ni a IGP, pero aquí por ahora está solo "en la dirección de 6.6.6.6".
Y aquí nos acercamos a la diferencia fundamental entre RSVP TE y LDP. RSVP TE está muy relacionado con los protocolos de enrutamiento dinámico; no solo se basa en los resultados de su trabajo, sino que los adapta y los explota en el sentido literal de la palabra.
En primer lugar, solo son adecuados los protocolos basados ​​​​en algoritmos de estado de enlace, es decir, OSPF e ISIS.
En segundo lugar, OSPF e ISIS se están ampliando mediante la introducción de nuevos elementos en los protocolos. Así aparece en OSPF nuevo tipo LSA - LSA opaco, y en ISIS - nuevo TLV ES Vecino Y Accesibilidad IP.
En tercer lugar, para calcular la ruta entre Ingress LSR y Egress LSR, se utiliza una modificación especial del algoritmo SPF: CSPF ( Ruta más corta restringida primero).

Ahora más detalles.

El mensaje Path se envía, en principio, mediante Unicast por dirección. Es decir, la dirección de su remitente es R1 y la dirección de su destinatario es 6.6.6.6. Y podría haber llegado simplemente a través de la tabla de enrutamiento.

Pero, de hecho, la ruta se transmite a través de la red, no como FIB per cápita en cada nodo, porque entonces no podremos proporcionar reservas ni buscar rutas de respaldo. No, sigue un camino determinado.
Esta ruta se determina en el LSR de Ingress con precisión nodo por nodo.
Para construir esta ruta, el RSVP TE necesita conocer la topología de la red. ¿Entiendes a qué nos acercamos? RSVP en sí no se molesta en estudiarlo, y ¿por qué debería hacerlo cuando se puede obtener de OSPF o ISIS? E inmediatamente resulta obvio por qué RIP, IGRP y EIGRP no son adecuados aquí; después de todo, no estudian la topología, lo máximo de lo que son capaces es el sucesor factible.
Pero el algoritmo SPF clásico tiene una topología de red en la entrada y en la salida solo puede producir la ruta más rápida teniendo en cuenta las métricas y, aunque puede calcular todas las rutas posibles.
Y aquí es donde CSPF entra en escena. Es este algoritmo el que puede calcular la mejor ruta, la ruta de segunda prioridad y, por ejemplo, alguna otra ruta de respaldo para llegar allí de alguna manera, incluso si .
Es decir, un RSVP TE puede pedirle al CSPF que calcule alguna ruta entre dos nodos.
Bueno, está bien, pero ¿por qué cambiar los protocolos IGP para esto? Guau. Y estas son Restricciones, restricciones. RSVP TE puede tener requisitos de ruta: ancho de banda, ancho mínimo disponible, tipo de línea o incluso los nodos a través de los cuales debe pasar el LSP. Entonces, para que CSPF tenga en cuenta las restricciones, debe conocer tanto sobre ellas como sobre recursos disponibles en nodos de toda la red. Los datos de entrada son las restricciones especificadas en el túnel y la topología de la red; sería lógico que la topología contuviera, además de prefijos y métricas, también información sobre los recursos disponibles.
Para ello, los enrutadores se comunican entre sí a través de mensajes OSPF e ISIS no sólo informacion basica, pero también las características de líneas, interfaces, etc. Es en nuevos tipos de mensajes donde se transmite esta información.
Por ejemplo, OSPF introdujo 3 tipos adicionales de LSA para esto:

• Tipo 9- alcance de enlace local
• Tipo 10- ámbito área-local
• Tipo 11- COMO alcance

Opaco significa opaco (para OSPF). Estos son tipos especiales de LSA que el propio OSPF no tiene en cuenta de ninguna manera al calcular la tabla de enrutamiento. Pueden ser utilizados por cualquier otro protocolo según sus necesidades. Entonces TE los usa para construir su topología (se llama TED - Base de datos de ingeniería de tráfico ). Pero, en teoría, no están asignados a TE; si escribe su propia aplicación para enrutadores, que requerirá el intercambio de cierta información sobre la topología, también puede usar Opaque LSA.
ISIS funciona de la misma manera. Nuevos mensajes: IS-IS TLV 22 (alcancebilidad de IS extendida), 134 (ID del enrutador de ingeniería de tráfico), 135 (alcanzabilidad de IP extendida).

Entonces, echemos un vistazo más detallado a todo este proceso.

0) En R1 habilitamos MPLS TE y configuramos ISIS (OSPF) para transportar datos para admitir TE. Los enrutadores intercambiaron información sobre los recursos disponibles. En este paso se forma el TED. RSVP guarda silencio.

1) Creamos una interfaz de túnel, donde indicamos su tipo (Ingeniería de Tráfico), dirección de destino (6.6.6.6) y requisitos necesarios por recursos. El LSR ejecuta CSPF: necesita calcular la ruta más corta desde R1 a 6.6.6.6, teniendo en cuenta las condiciones impuestas. En este paso, obtenemos la ruta óptima: una lista de nodos desde el origen hasta el destino (R2, R5, R6).

2) Resultado paso anterior alimentado a RSVP y transformado en un objeto ERO. R1 compila RSPV Path, donde naturalmente agrega ERO. El destino del paquete es 6.6.6.6. Además, también existe un objeto Solicitud de etiqueta, que indica que cuando se recibe un paquete, se debe asignar una etiqueta para este FEC (6.6.6.6/32).

ERO - Objeto de ruta explícita- objeto de mensaje de ruta RSVP especial. Contiene una lista de nodos a través de los cuales está destinado a pasar este mensaje.

3) El mensaje RSVP Path se transmite de una manera especial, no según la tabla de enrutamiento, sino según la lista ERO. En nuestro caso, la mejor ruta IGP y ERO son las mismas, por lo que el paquete se envía al R2.

4) R2, una vez recibida la ruta RSVP, verifica la presencia de los recursos necesarios y, si existen, asigna una etiqueta MPLS para FEC 6.6.6.6/32. El antiguo paquete Path se destruye, se crea uno nuevo y se cambia el objeto ERO: se elimina el R2. Esto se hace para que el siguiente nodo no intente devolver el paquete al R2. Es decir, el nuevo ERO ya tiene este aspecto: (R5, R6). De acuerdo con esto, R2 envía la ruta actualizada a R5.

5) R5 realiza operaciones similares: verifica recursos, asigna una etiqueta, se elimina de ERO, recrea el paquete Path y lo transfiere a la interfaz a través de la cual conoce el siguiente objeto ERO: R6.

6) R6, al recibir el paquete, se da cuenta de que él es el culpable de todo el alboroto. Destruye la ruta, asigna la etiqueta para FEC 6.6.6.6 y la inserta como un objeto. Etiqueta en el mensaje de respuesta Resv.
Tenga en cuenta que antes de este paso, las etiquetas solo se asignaban, pero no se distribuían, pero ahora comienzan a anunciarse a los LSR que las solicitaron.
7) El mensaje RESV avanza hasta R1 (Ingress LSR), dejando atrás una cola creciente del LSP. Resv debe pasar por los mismos nodos que Path, pero en orden inverso.

8) Finalmente se completa el LSP de R1 a 6.6.6.6. Los datos solo se pueden transferir del R1 al R6. Para permitir la transferencia de datos en la dirección opuesta, debe crear una interfaz de túnel en R6 con una dirección de destino 1.1.1.1; todas las acciones serán exactamente iguales.

Surge la pregunta: ¿por qué el destino del paquete es la ruta 6.6.6.6 si se transmite nodo por nodo y se conocen sus direcciones? Esta pregunta no es ociosa: nos lleva a una característica importante. Es posible que el objeto ERO no contenga en realidad todos los nodos desde el LSR de entrada hasta el LSR de salida; algunos pueden omitirse. Por lo tanto, cada LSR debe saber dónde se enruta finalmente el mensaje. Y esto puede suceder no porque Ingress LSR sea demasiado vago para calcular la ruta completa.
El problema está en las zonas IGP. Sabes que tanto OSPF como ISIS tienen este concepto para simplificar el enrutamiento. En redes grandes (cientos y miles de nodos), surge el problema de transmitir paquetes de servicios y calcular una gran cantidad de combinaciones utilizando el algoritmo SPF. Por lo tanto, un dominio global se divide en zonas de enrutamiento.
Y el problema es que si dentro de la zona IGP hay un protocolo de estado de enlace, entonces entre ellos hay un vector de distancia real: la topología de la red se construye solo dentro de la zona, los enrutadores internos no saben cómo están organizadas las demás zonas. Solo se les informa que para ingresar a una red en particular, deben enviar paquetes a una específica.
En otras palabras, si su red está dividida en zonas, entonces surgen dificultades con MPLS TE: CSPF no puede calcular la ruta completa, porque en su topología el destinatario de otra zona es una nube y no un nodo específico.

Y aquí viene al rescate. Ruta explícita(no confundir con el objeto ERO). Esta es la forma más directa de gestionar la construcción de un LSP: el administrador puede configurar de forma independiente y explícita los nodos a través de los cuales se debe enrutar el LSP. El Ingress LSR debe seguir dichas instrucciones exactamente. Esto añade un poco más de variedad a la vida del algoritmo CSPF.
¿Cómo ayuda Explicit Path a atravesar una zona? Usemos un ejemplo.

Tomaremos e indicaremos que debe haber puntos intermedios:
Ruta explícita: R1, R3, R5.

Cuando alimentamos esta ruta explícita a CSPF, construye la pieza que puede, es decir, dentro del Área 0: de R1 a R3.
Lo que contó se ingresa en ERO, además se le agrega otro nodo de ruta explícita, R5. Resulta: R1, R2, R3. La ruta se envía a través de la red según ERO y llega a R3. Ve que, en general, no es un destino, sino solo un punto de transferencia, toma las condiciones especificadas para los recursos requeridos y la dirección del nodo destinatario de la ruta explícita y ejecuta CSPF. Este último produce una lista completa de nodos hasta el destino (R3, R4, R5), que se convierte en ERO, y luego todo sucede según el escenario estándar.
Es decir, si el LSR de entrada y el LSR de salida están en zonas diferentes, el cálculo de la ruta se realiza por separado para cada zona, y punto de control es ABR.

Debe entenderse que la ruta explícita se utiliza no solo para este caso, sino en general. herramienta útil, porque puede indicar explícitamente cómo se debe enrutar el LSP o, por el contrario, a través de qué nodos no se debe enrutar el LSP.
Hablaremos de esto y mucho más en detalle en el número dedicado a MPLS TE.

Se me puede acusar de ser falso y decir que el IGP Link-State no es tan obligatorio. Bueno, quiero ejecutar EIGRP en una red de decisión única, pero no tengo la fuerza. O incluso los impulsos necrófilos te obligan a desenterrar RIP. ¿Y ahora qué? ¿Renunciar a TE?
En general, existe la salvación, pero solo en los equipos Cisco: se llama Verbatim.

Después de todo, ¿por qué necesitamos el protocolo Link-State? Recopila información de topología de TE y CSPF crea una ruta desde el LSR de entrada hasta el LSR de salida. Muuuuuy. Excelente. ¿Qué pasa si tomamos y elaboramos un camino explícito, donde enumeramos todos los nodos uno por uno? Después de todo, entonces no tienes que contar nada.
De hecho, no importa cuán detallada sea la ruta explícita, aún así se pasará a CSPF.
Pero este comportamiento se puede desactivar. Sólo para los casos descritos anteriormente.
El siguiente comando ayudará:
Router(config-if)# túnel mpls tráfico-eng ruta-opción 1 nombre explícito prueba literal

Es decir, este camino se considerará obviamente correcto sin realizar comprobaciones ni nuevos cálculos del CSPF.
Este escenario es muy cuestionable y sus ventajas son muy esquivas. Sin embargo, existe una oportunidad, y no digas después que no te lo conté.

Práctica de RSVP TE

Equipo mps ip necesitábamos para que el PLD funcionara. Ahora ya no es necesario: lo eliminamos y empezamos desde cero.
ahora necesitamos mpls tráfico-ing túneles. Incluye globalmente soporte para túneles TE y el propio RSVP TE:
R1(config)#mpls túneles de tráfico-eng
También necesitas habilitar lo mismo en las interfaces:

R1(config)# interfaz FastEthernet 0/0
R1(config-if)# túneles de tráfico-eng de mpls
R1(config)# interfaz FastEthernet 0/1
R1(config-if)# túneles de tráfico-eng de mpls
No pasa nada todavía. RSVP guarda silencio.

Ahora ampliaremos el IGP para transportar datos TE. En nuestro ejemplo usamos ISIS:
R1(config)#enrutador isis
R1(config-router)# estilo métrico ancho

R1(config-router)# mpls tráfico-eng nivel-2

Es necesario habilitar el modo de etiquetas extendidas; de lo contrario, TE no funcionará.
Configure el LSR-ID, como hicimos en LDP,
Es necesario establecer un nivel de ISIS específico; de lo contrario, TE no funcionará.

Si de repente estás usando OSPF

R1(config-router)# mpls tráfico-eng área 0
R1(config-router)# mpls tráfico-eng enrutador-id Loopback0

Estos pasos deben repetirse en otros enrutadores.

Inmediatamente después de esto, ISIS comienza a intercambiar información sobre TE:

Como puede ver, se transmite información sobre LSR-ID, información ampliada sobre vecinos (que admiten TE) e información ampliada sobre interfaces.

En esta etapa se formó TED.

Puedes ver la topología en sí en ISIS: #mostrar la base de datos isis detallada

RSVP guarda silencio por ahora.

Ahora configuremos un túnel TE.
R1(config)# interfaz Túnel1
R1(config-if)# ip sin numerar Loopback0
R1(config-if)# destino del túnel 6.6.6.6
R1(config-if)# modo túnel mpls tráfico-eng
R1(config-if)# túnel mpls tráfico-eng ruta-opción 10 dinámica
Las interfaces de túnel son algo muy universal en los enrutadores. Se pueden utilizar para L2TP, GRE, IPIP y, como puedes ver, para MPLS TE.
ip sin numerar Loopback0 significa que el punto de partida del túnel debe ser la dirección de la interfaz Loopback0.
destino del túnel 6.6.6.6- un comando universal para interfaces de túneles, determina el punto final, el final del túnel.
modo túnel mpls tráfico-eng- establece el tipo. Es aquí donde se determina el algoritmo de operación del túnel y cómo construirlo.
túnel mpls tráfico-eng opción-ruta 10 dinámica- este comando permite a CSPF crear una ruta dinámicamente, sin especificar nodos intermedios.

Si hiciste todo correctamente antes, la interfaz del túnel debería aparecer:
%LINEPROTO-5-UPDOWN: protocolo de línea en la interfaz Tunnel1, estado cambiado a arriba

¿Qué pasó?
R1 envió la ruta.

El volcado se realizó en la línea R1-R2.

Estamos interesados ​​en los objetos de dirección de destino, ERO y Solicitud de etiqueta.
Dirección de destino- 6.6.6.6, según lo configurado en el túnel.
Ruta explícita:
10.0.12.2 -> 10.0.25.2 -> 10.0.25.5 -> 10.0.56.5 -> 10.0.56.6.
Es decir, contiene la dirección de enlace de la interfaz de salida y la dirección de enlace del siguiente nodo. Por lo tanto, cada LSR sabe exactamente a qué interfaz enviar la ruta.
Este ERO no tiene 10.0.12.1 porque R1 ya lo eliminó antes de enviarlo.
Hecho de disponibilidad Solicitud de etiqueta indica que el LSR debe asignar una etiqueta para este FEC.
Sin embargo, no responde a este Camino de ninguna manera. Adiós- envía el actualizado más lejos.
El Resv descendente se envía después de que haya llegado el Resv del LSR descendente.

Lo mismo sucede en R5:

El volcado se realizó en la línea R2-R5.

El volcado se realizó en la línea R2-R5.

Entonces Path llega a R6. Devuelve RSPV Resv:

El volcado se realizó en la línea R5-R6.

El volcado muestra claramente que Resv se transmite de nodo a nodo.
en el objeto Etiqueta Se transmite la etiqueta asignada a este FEC.

Tenga en cuenta que R6 asignó la etiqueta 0 - Nulo explícito. En general, esta es una situación normal: esto se hace para que haya una etiqueta MPLS entre R5 y R6 (para procesar el paquete de acuerdo con el valor en el campo EXP, por ejemplo), pero R6 inmediatamente se dio cuenta de que la etiqueta 0 debe ser restablecer y procesar lo que hay debajo, en lugar de buscar en la tabla de etiquetas.
El problema es que puede haber más de una etiqueta en un paquete (por ejemplo, para una VPN), pero según RFC 3032 (y ya hablamos de esto antes), R5 debe eliminar toda la pila de etiquetas, sin importar cuántas. los hay y transmite el paquete con una etiqueta 0. En este caso, por supuesto, todo se romperá.
De hecho, el requisito de que la etiqueta 0 sea la única en la pila parece irrazonable: no sirve de nada. Por lo tanto, RFC 4182 eliminó esta restricción. Ahora bien, es posible que la etiqueta 0 no sea la única en la pila.
Una característica interesante es PHP. A pesar de que hay una etiqueta especial para esto - 3 - LSR enviará PHP incluso si recibe la etiqueta 0. Más detalles del mismo Pepelnyak.

R5 transmite Resv a R2 y R2 a R1.


El volcado se realizó en la línea R1-R2.

Aquí, como puede ver, la nota ya es normal: 16.

No importa qué tan de cerca mires Resv, no verás la ruta que debes seguir y la lista de nodos debe ser la misma para distribuir etiquetas con éxito y crear un LSP. ¿Cómo se resuelve esto?

Preguntas y respuestas

P1:¿Cuál es la diferencia entre RSVP TE LSP y LDP LSP?

Estrictamente hablando, desde el punto de vista tanto de los protocolos de nivel superior como del propio MPLS, no existen tales conceptos en absoluto. LSP: eso es lo que es LSP: es solo una ruta de cambio de etiquetas.
Puede resaltar el término CR-LSP (LSP basado en ConstRaint): está creado por RSVP TE. En este sentido, la diferencia es que CR-LSP satisface las condiciones especificadas en la interfaz del túnel.

P2:¿Cómo se comparan la ruta explícita y la ERO?

Si se especifica una ruta explícita para el túnel, RSVP genera un ERO basado en los requisitos de la ruta explícita. Además, incluso si registra cada nodo en Explicit-Path antes del LSR de salida, RSVP seguirá enviando los datos a CSPF.

P3: Si uno de los nodos intermedios no admite LDP (RSVP TE) o el protocolo está deshabilitado en la interfaz/plataforma, ¿se construirá el LSP para que, por ejemplo, vaya a IP en este nodo y luego nuevamente a MPLS en ¿el siguiente?

En el caso de RSVP, TE Ingress LSR no tendrá este nodo en TED y no podrá construir una ruta al Egress LSR, por lo que no enviará la ruta y, en consecuencia, no habrá etiquetas ni LSP.
El tráfico no podrá pasar por el túnel.

Si hablamos del PLD, la situación es más interesante. Por ejemplo, si en R2 desactiva LDP en la interfaz FE0/0 (hacia R5), entonces
1) R1 tendrá una etiqueta para FEC 6.6.6.6/32. Además, habrá 2 de ellos: uno a través de R2, el otro a través de R3, ya que según la tabla de enrutamiento el mejor es a través de R2, entonces el LSP se ubicará hacia R2.
2) habrá una marca en R2, pero solo una: hacia 1.1.1.1. Esta no es la mejor manera, por lo que no se utilizará. Es decir, aquí el LSP del R1 al FEC 6.6.6.6/32 deja de existir.
3) en R5 la etiqueta para FEC 6.6.6.6/32 será

Es decir, parece que obtenemos un LSP desgarrado: (R1-R2, R5-R6). Pero en realidad esto no es así. Es por eso que LSP tiene cambio de etiqueta, de modo que las etiquetas cambian a lo largo de toda la ruta, pero obtenemos de R1 a R2 MPLS, de R2 a R5 IP y de R5 a R6 MPLS nuevamente. LSP para FEC 6.6.6.6/32 no está aquí. Por aquí pasará tráfico normal, en principio, pero si hablamos de algunas Aplicaciones MPLS, como una VPN, entonces esto no funcionará.

P4: Bueno, por qué se necesita MPLS quedará claro en los siguientes artículos; por ahora, esto es generalmente una especie de tontería artificial para complicar la vida de un ingeniero, pero ¿por qué necesito MPLS TE? Después de todo, el tráfico se puede dirigir de la manera que necesito utilizando métricas IGP.

Para empezar, este es el tema de futuros números. Pero…
En términos generales, si desea determinar la ruta que tomará el tráfico, entonces esto se puede hacer ajustando inteligentemente el costo de los enlaces, interfaces, etc. Pero el mantenimiento de un sistema de este tipo le causará, por un lado, muchos problemas y, por otro lado, todavía no podrá dirigir dos flujos diferentes de diferentes maneras. Es decir, si la tarea es aliviar la red distribuyendo el tráfico, entonces con la ayuda de métricas simplemente transferirá el problema de un hombro a otro.
Pero si tiene varios LSP diferentes y puede enviarles tráfico, de nada. Aunque en términos de facilidad de soporte, TE también plantea dudas.

Bueno, en general, piénselo, si necesita canales garantizados de 40 Mb/s y 50 Mb/s para dos clientes, respectivamente, ¿cómo rastreará la utilización de las líneas? Bueno, bueno, una vez que has calculado y de alguna manera configurado milagrosamente el enrutamiento y la QoS para proporcionar el nivel de servicio requerido, pero de repente te cortan el acceso. tres lugares 3 kilómetros de óptica a la vez y no podrás arreglarlo durante una semana. E incluso tienes tres canales de respaldo de 50 Mb/s, pero el tráfico de ambos clientes se dirigió a un solo lugar, sin importarte todos los formales.

P5: Entonces, ¿cuál es la diferencia entre las etiquetas Nulo explícito e Nulo implícito? ¿Realmente necesito saber sobre ellos?

Necesito. Inicialmente, se supone que en la red MPLS el paquete siempre está cambiado por etiqueta desde el primero hasta el último LSR. Y en el último vuelo la marca será “0”, de modo que Egress LSR sabrá inmediatamente que es necesario eliminarlo. Esta etiqueta garantiza que no se pierda la prioridad especificada en el campo TC del encabezado MPLS, que se copia a medida que el paquete se transmite a través de la red. Como resultado, incluso el último enrutador procesará datos en las colas correctas.

En el concepto que utiliza la etiqueta "3", decidimos abandonar acciones innecesarias en el Egress LSR. Si no le importa la QoS (o copió la prioridad, por ejemplo, en el campo DSCP), entonces no es urgente colocar una etiqueta de transporte en el último salto; lo principal es enviarla a la interfaz correcta. , y Egress LSR lo solucionará allí. Si había un paquete IP puro, entréguelo al proceso IP, si había algo de E1, pase el flujo a la interfaz deseada si hay una pila de etiquetas, luego haga una búsqueda en LFIB y vea qué; acciones adicionales hay que hacer.

P6: Para un FEC, ¿el LSR siempre asignará la misma etiqueta a todos sus vecinos?

Existe un concepto de espacio de etiquetas:

• espacio de etiqueta de interfaz
• espacio de etiqueta de ranura


• espacio de etiqueta de plataforma

Si las etiquetas son específicas para cada interfaz, entonces para un FEC a diferentes puertos poder Se enviarán etiquetas diferentes.
Y viceversa: si las etiquetas son específicas de la plataforma (lea solo LSR), entonces el enrutador conecta todos los puertos con un FEC obligado enviar etiquetas idénticas.
En los ejemplos siguientes, verá que para un FEC enviamos las mismas etiquetas a diferentes vecinos, pero esto aún no indica cómo está organizado el espacio de etiquetas. Esto es algo puramente individual y está ligado al hardware.

Es importante entender que la tecnología MPLS no regula de ninguna manera el protocolo de distribución de etiquetas, pero resultados finales en una red particular puede variar cuando se utilizan diferentes protocolos. Los protocolos y aplicaciones ascendentes utilizan LSP independientemente de quién o cómo se hayan creado.
Por cierto, el escenario LDP sobre TE se encuentra a menudo en las redes modernas. En este caso, RSVP-TE se utiliza para organizar el transporte e implementar la ingeniería de tráfico, y LDP se utiliza para intercambiar etiquetas VPN, por ejemplo.
El LSR de ingreso, al escribir la primera etiqueta en el encabezado MPLS, determina la ruta completa del paquete. Los enrutadores intermedios simplemente cambian una etiqueta por otra. El contenido puede ser absolutamente cualquier cosa. Es esta naturaleza multiprotocolo la que permite que MPLS sirva como base para una variedad de servicios VPN.

Muchos de los que trabajan constantemente con redes de Internet probablemente hayan oído hablar de una tecnología tan maravillosa como MPLS.
MPLS nos abre nuevas oportunidades como AToM (Any Transport over Mpls), Ingeniería de Tráfico, etc.
AToM permite que el tráfico de protocolos de capa 2, como ATM, Frame Relay, Ethernet, PPP y HDLC, se transmita a través de una red IP/MPLS.
En este artículo me gustaría centrarme en la tecnología EoMPLS.

una pequeña teoría

MPLS- (inglés: conmutación de etiquetas multiprotocolo) - conmutación de etiquetas multiprotocolo.
En el modelo OSI, teóricamente se puede ubicar entre las capas dos y tres.

De acuerdo con la tecnología MPLS, a los paquetes se les asignan etiquetas para su transmisión a través de la red. Las etiquetas se incluyen en el encabezado MPLS que se inserta en el paquete de datos.

Estas etiquetas cortas y de longitud fija contienen información que le indica a cada nodo de conmutación (enrutador) cómo procesar y reenviar paquetes desde el origen al destino. Sólo tienen significado en la conexión local entre dos nodos. A medida que cada nodo transmite un paquete, reemplaza la etiqueta actual con la etiqueta correspondiente para garantizar que el paquete se enrute al siguiente nodo. Este mecanismo proporciona conmutación de paquetes de muy alta velocidad a través de la red central MPLS.

MPLS combina lo mejor del enrutamiento IP de capa 3 y la conmutación de capa 2.
Mientras que los enrutadores requieren inteligencia a nivel de red para determinar dónde reenviar el tráfico, los conmutadores solo necesitan reenviar los datos al siguiente salto, que es naturalmente más simple, rápido y económico. MPLS se basa en protocolos de enrutamiento IP tradicionales para anunciar y establecer la topología de la red. Luego, MPLS se superpone sobre esta topología. MPLS predetermina la ruta para que los datos viajen a través de una red y codifica esta información en forma de una etiqueta que los enrutadores de la red entienden.
Debido a que la planificación de rutas ocurre en sentido ascendente y en el borde de la red (donde se encuentran las redes del consumidor y del proveedor de servicios), los datos etiquetados con MPLS requieren menos capacidades informáticas desde los enrutadores para atravesar el núcleo de la red del proveedor de servicios.

Átomo
Para crear VPN de Capa 2 punto a punto, se ha desarrollado la tecnología Any Transport Over MPLS (AToM), que garantiza la transmisión de tramas de Capa 2 a través de una red MPLS. AToM es una tecnología integrada que incluye Frame Relay sobre MPLS, ATM sobre MPLS, Ethernet sobre MPLS.

EoMPLS encapsula Marcos Ethernet en paquetes MPLS y utiliza una pila de etiquetas para reenviar a través de la red MPLS.

Un canal creado con tecnología EoMPLS parece un cable de conexión virtual para el consumidor de los servicios del proveedor.

Entonces, allá vamos... ¿Cómo crear una VPN de Capa 2 usando EoMPLS?

Imaginemos que tenemos un cliente muy importante que necesita combinar dos sucursales (Moscú y Vladivostok) en un segmento de red, con una única dirección IP de extremo a extremo. Aquí es donde AToM viene al rescate.

Cómo lo ve el cliente

Cómo lo ve el proveedor

Antes de configurar VPN directamente, debe asegurarse de que MPLS esté funcionando.

Configurarlo es mucho más fácil de lo que parece a primera vista (estamos hablando de una configuración básica mínima).

1. Primero, habilitemos IP CEF y MPLS en entorno global nuestro enrutador.
   

   MSK-1#conf t
   MSK-1(config)#ipcef
   MSK-1(config)#mpls ip

   
   Si el enrutador se niega a comprender dicho comando, entonces versión actual IOS o el propio equipo no son compatibles con MPLS.
2. Creamos una interfaz loopback a través de la cual funcionará nuestro MPLS.
   

   MSK-1#conf t
   MSK-1(config)#int lo1
   MSK-1(config-if)#dirección IP 1.1.1.1 255.255.255.255
   

   
   Técnicamente, también puede funcionar directamente en las interfaces que proporcionan comunicación entre dos enrutadores. Pero un plan así sólo crea dificultades adicionales. Por ejemplo, cambiar la dirección IP en el área entre enrutadores.
3. Configuramos el enrutamiento para garantizar la comunicación entre enrutadores a través de interfaces loopback.
   Puede utilizar rutas estáticas o protocolos de enrutamiento dinámicos. Tomemos como ejemplo OSPF.
   

   MSK-1#conf t
   MSK-1(config)#enrutador ospf 100
   MSK-1(config-router)#log-adyacencia-cambios
   MSK-1(config-router)#red 1.1.1.1 0.0.0.0 área 0
   MSK-1(config-router)#red 1.0.0.0 0.0.0.3 área 0
   MSK-1(enrutador de configuración)#

   
   La red especifica la interfaz loopback y la red de interfaces para la comunicación entre enrutadores.

   De cheques comando ping que todo funcione.
   

   MSK-1#ping 1.1.1.3
   Escriba la secuencia de escape al aborto.
   Al enviar 5 ecos ICMP de 100 bytes a 1.1.1.3, el tiempo de espera es de 2 segundos:
   ! ! ! ! !
   La tasa de éxito es del 100 por ciento (5/5), ida y vuelta mín./promedio/máx. = 1/3/4 ms
   MSK-1#

4. Indiquemos a nuestro enrutador que la interfaz loopback se utilizará como “router-id”.
   

   MSK-1#conf t
   MSK-1(config)#mpls ldp router-id Loopback1 fuerza

5. Habilitamos MPLS en las interfaces que conectan los enrutadores entre sí.
   

   MSK-1#conf t
   MSK-1(config)#int gi0/2
   MSK-1(config-if)#mpls ip

6. Vemos que se establece la conexión vía MPLS.
   

   MSK-1#sh mpls ldp vecino Peer LDP Ident: 1.1.1.2:0; Identificación LDP local 1.1.1.1:0 Conexión TCP: 1.1.1.2.12817 - 1.1.1.1.646 Estado: Operativo; Mensajes enviados/rcvd: 36243/37084; Tiempo de actividad descendente: 01:39:49 Fuentes de descubrimiento de LDP: Hola objetivo 1.1.1.1 -> 1.1.1.2, activo, pasivo GigabitEthernet0/2, Dirección IP original: 1.0.0.2 Direcciones vinculadas a pares LDP Ident: 1.1.1.2 1.0. 0,2 1.1.1.6 Identificación de LDP del mismo nivel: 1.1.1.3:0; Identificación LDP local 1.1.1.1:0 Conexión TCP: 1.1.1.3.48545 - 1.1.1.1.646 Estado: Operativo; Mensajes enviados/rcvd: 347/127; Tiempo de actividad descendente: 01:39:49 Fuentes de descubrimiento de LDP: Hola objetivo 1.1.1.1 -> 1.1.1.3, activo, pasivo Direcciones vinculadas a pares LDP Ident: 1.0.0.5 1.1.1.3 MSK-1#

La configuración básica de MPLS ya está completa.
Aquí he presentado la configuración de un solo enrutador. Al final del artículo puedes ver las configuraciones de todos los enrutadores.

Pasemos a configurar un canal EoMPLS para nuestro cliente imaginario.

Toda la configuración se reduce a crear subinterfaces en ambos enrutadores.

Por un lado:

MSK-1#conf t
MSK-1(config)int gi0/1.100
MSK-1(config-subif)#encapsulación dot1Q 100
MSK-1(config-subif)#xconnect 1.1.1.3 123456789 encapsulación mpls

Allende:

Vladi-1#conf t
Vladi-1(config)intgi0/1.40
Vladi-1(config-subif)#encapsulación dot1Q 40
Vladi-1(config-subif)#xconnect 1.1.1.1 123456789 encapsulación mpls

Algunos puntos con más detalle:
encapsulación dot1Q 100 - especifique la etiqueta dot1Q. En pocas palabras, es el número de VLAN a través del cual viajará el tráfico del cliente desde el enrutador hasta su puerto en el conmutador. Este valor puede ser diferente en otro enrutador. Lo que nos permite combinar dos VLAN completamente diferentes.
xconectar 1.1.1.3 - cree un xconnect al enrutador requerido. Allí, donde se incluye el segundo punto de nuestro cliente.
123456789 - Valor del Circuito Virtual. Debería ser el mismo en ambos enrutadores. Es este valor el que identifica nuestro canal. Los valores de VC pueden oscilar entre 1 y 4294967295.

Ahora solo queda comprobar que nuestro canal está funcionando y disfrutar de la vida.

MSK-1#sh mpls l2transport vc 123456789 Local intf Circuito local Dirección de destino VC ID Estado Gi0/1.100 Eth VLAN 100 1.1.1.3 123456789 UP MSK-1#

Y información detallada:

MSK-1#sh mpls l2transport vc 123456789 detalle Interfaz local: Gi0/1.100 arriba, protocolo de línea arriba, Eth VLAN 100 arriba Dirección de destino: 1.1.1.3, ID de VC: 123456789, estado de VC: arriba Siguiente salto: 1.0.0.2 Interfaz de salida : Gi0/2, pila de etiquetas impuesta (599 17) Hora de creación: 02:33:18, hora del último cambio de estado: 02:33:14 Protocolo de señalización: LDP, par 1.1.1.3:0 en adelante Etiquetas MPLS VC: local 140, remoto 17 ID de grupo: local 0, remoto 0 MTU: local 1500, remoto 1500 Descripción de la interfaz remota: Secuenciación: recepción deshabilitada, envío deshabilitado Estadísticas de VC: totales de paquetes: recibir 1391338893, enviar 1676515662 totales de bytes: recibir 2765021070, enviar 3317727319 caídas de paquetes: recibir 0, enviar 0 MSK-1#

Problemas de MTU

Hay que recordar que cuando funciona MPLS, se añaden 12 bytes adicionales al paquete Ethernet.
Para evitar la fragmentación de paquetes, puede especificar "mpls mtu 1512" en las interfaces. Pero en este caso, todos los dispositivos a lo largo de la ruta deben admitir la transmisión de paquetes con Tamaño de MTU, más de 1500.

PD Configuraciones de todos los enrutadores según lo prometido.

Moscú
#mpls ip #enrutador ospf 100 cambios-de-adyacencia-de-registro red 1.1.1.1 0.0.0.0 área 0 red 1.0.0.0 0.0.0.3 área 0 #interfaz GigabitEthernet0/2 dirección IP 1.0.0.1 255.255.255.252 mps ip #interfazLoopback1 dirección IP 1.1.1.1 255.255.255.255 #interfaz GigabitEthernet0/1.100 encapsulación dot1Q 100 xconnect 1.1.1.3 123456789 encapsulación mpls

Es imposible describir absolutamente todos los aspectos en un solo artículo. Intenté contar lo más brevemente posible lo mínimo necesario para el trabajo.

Cisco https://cdn..png

Usando tecnología MPLS (Implementación de Cisco MPLS)

Fechas de los cursos online más cercanos

• Grupo diurno del 11 de julio (este es el jueves), dirigido por Ruslan Karmanov: regístrese para la lección

Resumen del curso MPLS (MPLS versión 2.3)

Este curso cubre cuestiones de diseño. soluciones de red, implementación y soporte de redes y tecnologías MPLS utilizando MPLS. El curso se centra en los desafíos tecnológicos de VPN sobre MPLS desde la perspectiva de un proveedor de servicios. El curso proporciona informacion basica sobre capacidades y funciones avanzadas de Ingeniería de Tráfico, Redireccionamiento Rápido y Cualquier Transporte sobre MPLS (AToM), que se presentan a nivel conceptual.

Profundizamos el material de nuestros cursos añadiendo trabajo practico, reemplazando demostraciones con laboratorios, cubriendo temas adicionales; es por eso que nuestro curso MPLS 2.3 es más adecuado para la preparación de exámenes que el MPLS estándar "minimalista" autorizado.

Ruslan V. Karmanov

Necesario para obtener estados

• Certificación CCIP: profesional certificado en redes de redes de Cisco

Se prepara para aprobar los exámenes de certificación.

• Examen 642-611

Costo de participación en el curso MPLS 2.3

El costo del curso para los titulares de una suscripción a Knowledge Assurance es de 5.400 rublos, en caso de ausencia, 9.200 rublos.

Para los participantes corporativos el precio será de 8.650 rublos. si la organización participa en el programa Knowledge Assurance, o 13.900 rublos en caso contrario.

Si planea capacitar a más de una persona de una organización, para aclarar el descuento.84 USD

Programa del curso MPLS 2.3

Módulo #1 - Conceptos MPLS

• Introducción a los conceptos básicos de MPLS. Terminología y arquitectura MPLS.
• Introducción a las etiquetas y pilas de etiquetas MPLS. Agregar etiquetas. Apilamiento de etiquetas MPLS
• Servicios MPLS. Enrutamiento y MPLS. ¿Qué es MPLS VPN? Tareas MPLS:TE (Ingeniería de Tráfico)
• Procesamiento e implementación de QoS en MPLS. Cualquier Transporte sobre MPLS - AToM. Interacción de varias tecnologías MPLS.

Módulo No. 2 - Finalidad y distribución de las etiquetas

• Cómo funcionan los protocolos de distribución de etiquetas. Configurar una sesión LDP. Descubrimiento de vecinos LDP. Gestión de sesiones LDP.
• Distribución de información de etiquetas por toda la red. Etiquetar rutas conmutadas. tecnología PHP. ¿Cómo afecta el procesamiento de IP a los LSP? Asignación de etiquetas en redes MPLS. Distribución y anuncio de etiquetas. Encontrar bucles en MPLS.
• ¿Qué es MPLS de estado estacionario? Convergencia de protocolos de enrutamiento dinámico después de una falla del túnel MPLS.

Módulo No. 3 - Implementación del modo de trama MPLS en la plataforma Cisco IOS 15.x

• ¿Qué es Cisco Express Forwarding? Mecanismos de conmutación exprés. Almacenamiento en caché y ip route-cache cef.
• Configuración del modo de trama MPLS en Cisco IOS. ID del enrutador MPLS, configuración MPLS en la interfaz, Configuración de MTU para MPLS, gestión IP TTL y distribución de etiquetas LDP condicional
• Monitoreo del modo de trama MPLS en la plataforma Cisco IOS (muestre los parámetros, interfaces y descubrimiento de mpls ldp; muestre el vecino de mpls ldp, enlaces; muestre la tabla de reenvío de mpls, muestre los detalles de ip cef)
• Depuración del modo de trama MPLS en la plataforma Cisco IOS. Problemas típicos de establecimiento de una sesión LDP, distribución de etiquetas, transmisión de tramas y CEF.

Módulo #4 - Tecnología MPLS VPN

• Introducción a las VPN MPLS. Modelos VPN superpuestos y VPN punto a punto. Pros y contras de MPLS VPN
• Arquitectura VPN MPLS. ¿Qué son los distintivos de ruta y los objetivos de ruta?
• El enrutamiento VPN MPLS funciona. Soporte de enrutamiento de Internet. Cómo funcionan las tablas FIB en enrutadores PE. Lógica del flujo de actualización de enrutamiento de un extremo a otro
• Promoción de paquetes en la red VPN MPLS. Reenvío de VPN de extremo a extremo. ¿Qué es el penúltimo salto de lúpulo? Intercambio de etiquetas VPN apiladas entre enrutadores PE. Impacto de MPLS VPN en el intercambio de etiquetas y la transmisión de paquetes de datos.

Módulo #5: Implementación de MPLS VPN

• Uso de mecanismos VPN MPLS en plataformas Cisco IOS
• Configuración de la tabla VRF
• Configuración de sesión MP-BGP entre enrutadores PE
• Configuración de protocolos de enrutamiento a baja escala entre dispositivos PE y CE.
• Monitoreo del funcionamiento de MPLS VPN
• Configuración de OSPF como protocolo de enrutamiento entre dispositivos PE y CE
• Configuración de BGP como protocolo de enrutamiento entre dispositivos PE y CE
• Depuración de VPN MPLS

Módulo #6: VPN MPLS complejas

• Uso de funciones avanzadas de importación y exportación de VRF
• Introducción a las VPN superpuestas
• Introducción a VPN con Servicios Centrales
• Introducción al servicio CE administrado

Módulo No. 7 - MPLS VPN y provisión de acceso a Internet

• Introducción a las topologías de acceso a Internet con MPLS VPN
• Implementación de servicios separados de acceso a Internet y VPN MPLS
• Implementar el acceso a Internet como una VPN dedicada

Módulo #8 - Descripción general de MPLS TE

• Introducción al concepto TE
• Comprensión de los componentes MPLS TE
• Configuración MPLS TE en plataformas Cisco IOS
• Escucha configuraciones básicas MPLS TE básico en plataformas Cisco IOS

Duración del curso

Restricciones de participación

No existen restricciones de participación (por ejemplo, tener una suscripción activa de Knowledge Assurance en la fecha de inicio).

Preparación preliminar

Disponibilidad preparación necesaria importante para el aprendizaje efectivo del material. Para realizar el curso MPLS 2.3 es necesario tener un conocimiento completo del material.

Propósito del trabajo

Introducir a los estudiantes a principios básicos Funcionamiento MPLS. En el trabajo se utilizan las siguientes tecnologías: IPv4, CEF, MPLS, OSPF y BGP.

El trabajo se realiza mediante el emulador GNS3. Se supone que el alumno ya conoce bien la parte teórica, la cual no se explica en este trabajo.

Diagrama de red

Descripción del trabajo

El diagrama anterior muestra una pequeña red de una determinada empresa (enrutadores R1-R6), conectada a dos proveedores de Internet (enrutadores ISP1 e ISP2). La red de la empresa en cuestión debe realizar las funciones de un sistema autónomo de tránsito para la comunicación entre redes de proveedores, es decir, transmitir tráfico entre los enrutadores ISP1 e ISP2. Utilice enrutadores de la serie 7200 y el último IOS estable.

1. Para el diagrama anterior, proponga un plan de direcciones y asigne direcciones IP a las interfaces utilizadas para la comunicación entre enrutadores. En cada enrutador, cree una interfaz Loopback 0 y asigne direcciones IP. En los enrutadores ISP1 e ISP2, cree también interfaces Loopback 0 que emularán ciertas redes en Internet.
2. En cada enrutador de la empresa, configure el protocolo OSPF para que funcione en todos los enlaces dentro de la red de la empresa y no funcione entre usted y el equipo del operador.
3. Transfiera información sobre redes conectadas a enrutadores de la empresa al protocolo de enrutamiento dinámico.
4. Asegúrese de que cada uno de los seis enrutadores tenga información sobre todos los prefijos de la empresa, así como las redes IP utilizadas entre la empresa y los operadores.
5. Configure BGP entre sus enrutadores fronterizos (R1 y R6) y el equipo de los proveedores.
6. Configure BGP entre sus dispositivos perimetrales (R1 y R6). Los enrutadores R2-R5 no participan en BGP. Para establecer una sesión iBGP entre R1 y R6, se deben utilizar interfaces Loopback 0.
7. Asegúrese de que cada operador vea los prefijos anunciados por el otro operador en sus tablas de enrutamiento.
8. Asegúrese de que las redes anunciadas por el enrutador del segundo operador no sean accesibles desde el enrutador del primer operador. Explique este efecto.
9. En los enrutadores R1 y R6, configure la transferencia de rutas desde el protocolo OSPF a BGP. Asegúrese de que los operadores reciban actualizaciones sobre los prefijos apropiados.
10. Asegúrese de que las rutas de BGP no terminen en OSPF.
11. Asegúrese de que cada operador pueda acceder redes locales su empresa, pero aún no tienen coherencia entre sí. Explique este efecto.
12. En los enrutadores R1-R6, habilite la compatibilidad con CEF con el comando ip cef . Los IOS modernos tienen una configuración predeterminada que usa CEF, pero no está de más asegurarse de que se utilice la tecnología Cisco Express Forwarding. Examinar la salida del comando sho ip cef , explica qué ves exactamente.
13. En los enrutadores R1-R6 usando el comando mps ip modo de configuración global, habilite la compatibilidad con MPLS en los enrutadores.
14. En las interfaces internas de los enrutadores R1-R6, es decir, no en los enlaces entre la empresa y los operadores, habilite el soporte MPLS usando el comando mps ip .
15. En los mismos enlaces que se configuraron en el párrafo anterior, configure el valor de MTU de MPLS usando el comando interfaz mpls mtu anulación 1540 . Esta acción debe realizarse debido al hecho de que el encabezado MPLS adicional ubicado entre los encabezados Ethernet e IP aumenta la longitud de la trama.
16. Verifique que el comando del párrafo anterior se haya aplicado correctamente llamando mostrar interfaz mpls nombre_interfaz detalle , mientras nombre_interfaz especifique los nombres de las interfaces que configuró.
17. Usando el comando mpls ldp enrutador-id loopback0 fuerza modo de configuración global, especifique el ID del enrutador para el protocolo LDP.
18. Asegúrese de que cada uno de los enrutadores R1-R6 pueda ver todos sus vecinos LDP usando el comando sho mpls ldp vecino .
19. En los enrutadores R1-R6, verifique el contenido de la tabla LIB usando el comando encuadernación sho mpls ldp . Explique qué prefijos están presentes o ausentes y por qué.
20. En los enrutadores R2-R5, asegúrese de que no haya prefijos externos (de dispositivos de operador ISP1 e ISP2) en la tabla LIB. Explique por qué no deberían estar allí.
21. En los enrutadores R1-R6, vea el contenido de la tabla LFIB usando el comando tabla de reenvío sho mpls .
22. Verifique que la transferencia de datos entre ISP1 e ISP2 haya comenzado a ocurrir.
23. Comience a interceptar el tráfico en los enlaces R1-R2, R2-R3 y R2-R4. Vea el contenido de los paquetes enviados entre ISP1 e ISP2. Compare las etiquetas utilizadas con las que vio en las tablas LIB y LFIB. Explique por qué algunos paquetes no tienen etiquetas.

Muchos de los que trabajan constantemente con redes de Internet probablemente hayan oído hablar de una tecnología tan maravillosa como MPLS.
MPLS nos abre nuevas oportunidades como AToM (Any Transport over Mpls), Ingeniería de Tráfico, etc.
AToM permite que el tráfico de protocolos de capa 2, como ATM, Frame Relay, Ethernet, PPP y HDLC, se transmita a través de una red IP/MPLS.
En este artículo me gustaría centrarme en la tecnología EoMPLS.

una pequeña teoría

MPLS- (inglés: conmutación de etiquetas multiprotocolo) - conmutación de etiquetas multiprotocolo.
En el modelo OSI, teóricamente se puede ubicar entre las capas dos y tres.

De acuerdo con la tecnología MPLS, a los paquetes se les asignan etiquetas para su transmisión a través de la red. Las etiquetas se incluyen en el encabezado MPLS que se inserta en el paquete de datos.

Estas etiquetas cortas y de longitud fija contienen información que le indica a cada nodo de conmutación (enrutador) cómo procesar y reenviar paquetes desde el origen al destino. Sólo tienen significado en la conexión local entre dos nodos. A medida que cada nodo transmite un paquete, reemplaza la etiqueta actual con la etiqueta correspondiente para garantizar que el paquete se enrute al siguiente nodo. Este mecanismo proporciona conmutación de paquetes de muy alta velocidad a través de la red central MPLS.

MPLS combina lo mejor del enrutamiento IP de capa 3 y la conmutación de capa 2.
Mientras que los enrutadores requieren inteligencia a nivel de red para determinar dónde reenviar el tráfico, los conmutadores solo necesitan reenviar los datos al siguiente salto, que es naturalmente más simple, rápido y económico. MPLS se basa en protocolos de enrutamiento IP tradicionales para anunciar y establecer la topología de la red. Luego, MPLS se superpone sobre esta topología. MPLS predetermina la ruta para que los datos viajen a través de una red y codifica esta información en forma de una etiqueta que los enrutadores de la red entienden.
Debido a que la planificación de rutas ocurre en sentido ascendente y en el borde de la red (donde se encuentran las redes del consumidor y del proveedor de servicios), los datos etiquetados con MPLS requieren menos potencia de procesamiento de los enrutadores para atravesar el núcleo de la red del proveedor de servicios.

Átomo
Para crear VPN de Capa 2 punto a punto, se ha desarrollado la tecnología Any Transport Over MPLS (AToM), que garantiza la transmisión de tramas de Capa 2 a través de una red MPLS. AToM es una tecnología integrada que incluye Frame Relay sobre MPLS, ATM sobre MPLS, Ethernet sobre MPLS.

EoMPLS encapsula tramas Ethernet en paquetes MPLS y utiliza una pila de etiquetas para reenviar a través de la red MPLS.

Un canal creado con tecnología EoMPLS parece un cable de conexión virtual para el consumidor de los servicios del proveedor.

Entonces, allá vamos... ¿Cómo crear una VPN de Capa 2 usando EoMPLS?

Imaginemos que tenemos un cliente muy importante que necesita combinar dos sucursales (Moscú y Vladivostok) en un segmento de red, con una única dirección IP de extremo a extremo. Aquí es donde AToM viene al rescate.

Cómo lo ve el cliente

Cómo lo ve el proveedor

Antes de configurar VPN directamente, debe asegurarse de que MPLS esté funcionando.

Configurarlo es mucho más fácil de lo que parece a primera vista (estamos hablando de una configuración básica mínima).

1. Primero, habilitemos IP CEF y MPLS en la configuración global de nuestro enrutador.
   

   MSK-1#conf t
   MSK-1(config)#ipcef
   MSK-1(config)#mpls ip

   
   Si el enrutador se niega a comprender dicho comando, entonces la versión actual de IOS o el equipo en sí no son compatibles con MPLS.
2. Creamos una interfaz loopback a través de la cual funcionará nuestro MPLS.
   

   MSK-1#conf t
   MSK-1(config)#int lo1
   MSK-1(config-if)#dirección IP 1.1.1.1 255.255.255.255
   

   
   Técnicamente, también puede funcionar directamente en las interfaces que proporcionan comunicación entre dos enrutadores. Pero un plan así sólo crea dificultades adicionales. Por ejemplo, cambiar la dirección IP en el área entre enrutadores.
3. Configuramos el enrutamiento para garantizar la comunicación entre enrutadores a través de interfaces loopback.
   Puede utilizar rutas estáticas o protocolos de enrutamiento dinámicos. Tomemos como ejemplo OSPF.
   

   MSK-1#conf t
   MSK-1(config)#enrutador ospf 100
   MSK-1(config-router)#log-adyacencia-cambios
   MSK-1(config-router)#red 1.1.1.1 0.0.0.0 área 0
   MSK-1(config-router)#red 1.0.0.0 0.0.0.3 área 0
   MSK-1(enrutador de configuración)#

   
   La red especifica la interfaz loopback y la red de interfaces para la comunicación entre enrutadores.

   Comprobamos con el comando ping que todo está funcionando.
   

   MSK-1#ping 1.1.1.3
   Escriba la secuencia de escape al aborto.
   Al enviar 5 ecos ICMP de 100 bytes a 1.1.1.3, el tiempo de espera es de 2 segundos:
   ! ! ! ! !
   La tasa de éxito es del 100 por ciento (5/5), ida y vuelta mín./promedio/máx. = 1/3/4 ms
   MSK-1#

4. Indiquemos a nuestro enrutador que la interfaz loopback se utilizará como “router-id”.
   

   MSK-1#conf t
   MSK-1(config)#mpls ldp router-id Loopback1 fuerza

5. Habilitamos MPLS en las interfaces que conectan los enrutadores entre sí.
   

   MSK-1#conf t
   MSK-1(config)#int gi0/2
   MSK-1(config-if)#mpls ip

6. Vemos que se establece la conexión vía MPLS.
   

   MSK-1#sh mpls ldp vecino Peer LDP Ident: 1.1.1.2:0; Identificación LDP local 1.1.1.1:0 Conexión TCP: 1.1.1.2.12817 - 1.1.1.1.646 Estado: Operativo; Mensajes enviados/rcvd: 36243/37084; Tiempo de actividad descendente: 01:39:49 Fuentes de descubrimiento de LDP: Hola objetivo 1.1.1.1 -> 1.1.1.2, activo, pasivo GigabitEthernet0/2, Dirección IP original: 1.0.0.2 Direcciones vinculadas a pares LDP Ident: 1.1.1.2 1.0. 0,2 1.1.1.6 Identificación de LDP del mismo nivel: 1.1.1.3:0; Identificación LDP local 1.1.1.1:0 Conexión TCP: 1.1.1.3.48545 - 1.1.1.1.646 Estado: Operativo; Mensajes enviados/rcvd: 347/127; Tiempo de actividad descendente: 01:39:49 Fuentes de descubrimiento de LDP: Hola objetivo 1.1.1.1 -> 1.1.1.3, activo, pasivo Direcciones vinculadas a pares LDP Ident: 1.0.0.5 1.1.1.3 MSK-1#

La configuración básica de MPLS ya está completa.
Aquí he presentado la configuración de un solo enrutador. Al final del artículo puedes ver las configuraciones de todos los enrutadores.

Pasemos a configurar un canal EoMPLS para nuestro cliente imaginario.

Toda la configuración se reduce a crear subinterfaces en ambos enrutadores.

Por un lado:

MSK-1#conf t
MSK-1(config)int gi0/1.100
MSK-1(config-subif)#encapsulación dot1Q 100
MSK-1(config-subif)#xconnect 1.1.1.3 123456789 encapsulación mpls

Allende:

Vladi-1#conf t
Vladi-1(config)intgi0/1.40
Vladi-1(config-subif)#encapsulación dot1Q 40
Vladi-1(config-subif)#xconnect 1.1.1.1 123456789 encapsulación mpls

Algunos puntos con más detalle:
encapsulación dot1Q 100 - especifique la etiqueta dot1Q. En pocas palabras, es el número de VLAN a través del cual viajará el tráfico del cliente desde el enrutador hasta su puerto en el conmutador. Este valor puede ser diferente en otro enrutador. Lo que nos permite combinar dos VLAN completamente diferentes.
xconectar 1.1.1.3 - cree un xconnect al enrutador requerido. Allí, donde se incluye el segundo punto de nuestro cliente.
123456789 - Valor del Circuito Virtual. Debería ser el mismo en ambos enrutadores. Es este valor el que identifica nuestro canal. Los valores de VC pueden oscilar entre 1 y 4294967295.

Ahora solo queda comprobar que nuestro canal está funcionando y disfrutar de la vida.

MSK-1#sh mpls l2transport vc 123456789 Local intf Circuito local Dirección de destino VC ID Estado Gi0/1.100 Eth VLAN 100 1.1.1.3 123456789 UP MSK-1#

E información detallada:

MSK-1#sh mpls l2transport vc 123456789 detalle Interfaz local: Gi0/1.100 arriba, protocolo de línea arriba, Eth VLAN 100 arriba Dirección de destino: 1.1.1.3, ID de VC: 123456789, estado de VC: arriba Siguiente salto: 1.0.0.2 Interfaz de salida : Gi0/2, pila de etiquetas impuesta (599 17) Hora de creación: 02:33:18, hora del último cambio de estado: 02:33:14 Protocolo de señalización: LDP, par 1.1.1.3:0 en adelante Etiquetas MPLS VC: local 140, remoto 17 ID de grupo: local 0, remoto 0 MTU: local 1500, remoto 1500 Descripción de la interfaz remota: Secuenciación: recepción deshabilitada, envío deshabilitado Estadísticas de VC: totales de paquetes: recibir 1391338893, enviar 1676515662 totales de bytes: recibir 2765021070, enviar 3317727319 caídas de paquetes: recibir 0, enviar 0 MSK-1#

Problemas de MTU

Hay que recordar que cuando funciona MPLS, se añaden 12 bytes adicionales al paquete Ethernet.
Para evitar la fragmentación de paquetes, puede especificar "mpls mtu 1512" en las interfaces. Pero en este caso, todos los dispositivos a lo largo de la ruta deben admitir la transmisión de paquetes con un tamaño de MTU superior a 1500.

PD Configuraciones de todos los enrutadores según lo prometido.

Moscú
#mpls ip #enrutador ospf 100 cambios-de-adyacencia-de-registro red 1.1.1.1 0.0.0.0 área 0 red 1.0.0.0 0.0.0.3 área 0 #interfaz GigabitEthernet0/2 dirección IP 1.0.0.1 255.255.255.252 mps ip #interfazLoopback1 dirección IP 1.1.1.1 255.255.255.255 #interfaz GigabitEthernet0/1.100 encapsulación dot1Q 100 xconnect 1.1.1.3 123456789 encapsulación mpls

Es imposible describir absolutamente todos los aspectos en un solo artículo. Intenté contar lo más brevemente posible lo mínimo necesario para el trabajo.