EN ESTA PÁGINA
Descripción general de los planos de transporte con clase BGP
Ejemplo: Configuración de planos de transporte con clase (dentro del dominio)
Descripción general del transporte con clase BGP (BGP-CT) con túneles SR-TE de colores subyacentes
Descripción general de la asignación basada en colores de los servicios VPN
Configuración de ingeniería de tráfico basada en colores
SUMMARY
Descripción general de los planos de transporte con clase BGP
- Beneficios de los aviones de transporte con clase BGP
- Terminología de los planos de transporte con clase BGP
- Descripción de los planos de transporte con clase BGP
- Implementación intra-AS de planos de transporte con clase BGP
- Implementación de Inter-AS de planos de transporte con clase BGP
- Descripción general del transporte con clase BGP (BGP-CT) con túneles SR-TE de colores subyacentes
- Beneficios de BGP-CT con túneles SR-TE de colores subyacentes
Beneficios de los aviones de transporte con clase BGP
-
División de red: las capas de servicio y transporte están desacopladas entre sí, sentando las bases para la división de red y la virtualización con la división de extremo a extremo en múltiples dominios, lo que reduce significativamente el CAPEX.
- Interoperabilidad entre dominios: extiende el despliegue de clases de transporte a través de dominios que cooperan para que los diferentes protocolos de señalización de transporte en cada dominio interoperen. Concilia cualquier diferencia entre los espacios de nombres de comunidad extendidos que pueden estar en uso en cada dominio.
-
Resolución coloreada con reserva: permite la resolución sobre túneles de color (RSVP, algoritmo flexible IS-IS) con opciones flexibles de reserva sobre túneles de mejor esfuerzo o cualquier otro túnel de color.
- Calidad de servicio: personaliza y optimiza la red para cumplir los requisitos de SLA de extremo a extremo.
- Aprovechamiento de las implementaciones existentes: admite protocolos de tunelización bien implementados, como RSVP, junto con protocolos nuevos, como el algoritmo flexible IS-IS, lo que preserva el retorno de la inversión y reduce los gastos operativos.
Terminología de los planos de transporte con clase BGP
En esta sección se proporciona un resumen de los términos más utilizados para comprender el plano de transporte con clase BGP.
-
Nodo de servicio: dispositivos perimetrales del proveedor de entrada (PE) que envían y reciben rutas de servicio (Internet y VPN de capa 3).
-
Nodo de borde: dispositivo en el punto de conexión de diferentes dominios (áreas IGP o AS).
-
Nodo de transporte: dispositivo que envía y recibe rutas de unidifusión etiquetada con BGP (LU).
-
BGP-VPN: VPN creadas con mecanismos de RFC4364.
-
Destino de ruta (RT): tipo de comunidad extendida que se utiliza para definir la pertenencia a VPN.
-
Diferenciador de ruta (RD): identificador utilizado para distinguir a qué VPN o servicio de LAN privada virtual (VPLS) pertenece una ruta. Cada instancia de enrutamiento debe tener asociado un diferenciador de ruta único.
- Esquema de resolución: se usa para resolver la dirección del protocolo del próximo salto (PNH) en las RIB de resolución que proporcionan respaldo.
Mapean las rutas a las diferentes RIB de transporte en el sistema basado en el mapeo de la comunidad.
-
Familia de servicios: familia de direcciones BGP que se usa para anunciar rutas para el tráfico de datos, en lugar de túneles.
-
Familia de transporte : familia de direcciones BGP utilizada para túneles publicitarios, que a su vez son utilizados por las rutas de servicio para la resolución.
-
Túnel de transporte: túnel sobre el cual un servicio puede colocar tráfico, por ejemplo, GRE, UDP, LDP, RSVP, SR-TE, BGP-LU.
-
Dominio de túnel: dominio de la red que contiene nodos de servicio y nodos de borde bajo un único control administrativo que tiene un túnel entre ellos. Se puede crear un túnel de extremo a extremo que abarca varios dominios de túnel adyacentes uniendo los nodos mediante etiquetas.
-
Clase de transporte: grupo de túneles de transporte que ofrecen el mismo tipo de servicio.
Clase de transporte RT: nuevo formato de destino de ruta que se utiliza para identificar una clase de transporte específica.
Un nuevo formato de Destino de ruta que se utiliza para identificar una clase de transporte específica.-
RIB de transporte: en el nodo de servicio y el nodo de borde, una clase de transporte tiene una RIB de transporte asociada que contiene sus rutas de túnel.
-
RTI de transporte: una instancia de enrutamiento; contenedor de RIB de transporte y clase de transporte asociada Route Target y Route Distinguisher.
-
Plano de transporte: conjunto de RTI de transporte que importan la misma clase de transporte RT. Estos, a su vez, se unen para abarcar los límites del dominio del túnel utilizando un mecanismo similar a la opción b de Inter-AS para intercambiar etiquetas en los nodos de borde (nexthop-self), formando un plano de transporte de extremo a extremo.
-
Asignación de comunidad: comunidad en una ruta de servicio que se asigna para resolver una clase de transporte.
Descripción de los planos de transporte con clase BGP
Puede usar planos de transporte con clase BGP para configurar clases de transporte para clasificar un conjunto de túneles de transporte en una red intra-AS en función de las características de ingeniería de tráfico y usar estos túneles de transporte para asignar rutas de servicio con el SLA deseado y la reserva prevista.
Los planos de transporte con clase BGP pueden extender estos túneles a redes entre dominios que abarcan varios dominios (áreas AS o IGP) conservando la clase de transporte. Para ello, debe configurar la familia BGP de capa de transporte de transdeporte con clase BGP entre los nodos de borde y servicio.
Tanto en implementaciones de interAS como intraAS, puede haber muchos túneles de transporte (MPLS LSP, IS-IS algoritmo flexible, SR-TE) creados a partir de los nodos de servicio y borde. Los LSP pueden señalizarse utilizando diferentes protocolos de señalización en diferentes dominios y pueden configurarse con diferentes características de ingeniería de tráfico (clase o color). El extremo del túnel de transporte también actúa como extremo de servicio y puede estar presente en el mismo dominio de túnel que el nodo de entrada del servicio, o en un dominio adyacente o no adyacente. Puede utilizar planos de transporte con clase BGP para resove servicios a través de LSP con ciertas características de ingeniería de tráfico, ya sea dentro de un único dominio o en varios dominios.
Los planos de transporte con clase BGP reutilizan la tecnología BGP-VPN, manteniendo los dominios de túnel débilmente acoplados y coordinados.
- La información de accesibilidad de la capa de red (NLRI) es RD:TunnelEndpoint que se utiliza para ocultar rutas.
- El destino de ruta indica la clase de transporte de los LSP y pierde rutas a la RIB de transporte correspondiente en el dispositivo de destino.
- Cada protocolo de tunelización de transporte instala una ruta de entrada en la tabla de enrutamiento transport-class.inet.3, modela la clase de transporte de túnel como destino de ruta VPN y recopila los LSP de la misma clase de transporte en la tabla de enrutamiento transport-class.inet.3 transport-rib.
-
Las rutas de esta instancia de enrutamiento se anuncian en el plano de transporte con clase BGP (transporte inet) AFI-SAFI siguiendo procedimientos similares a RFC-4364.
-
Al cruzar el límite del vínculo interAS, debe seguir los procedimientos de la opción b para unir los túneles de transporte en estos dominios adyacentes.
Del mismo modo, al cruzar regiones intra-AS, debe seguir los procedimientos de la opción b para unir los túneles de transporte en los diferentes dominios TE.
-
Puede definir esquemas de resolución para especificar la intención de la variedad de clases de transporte en un orden de reserva.
- Puede resolver rutas de servicio y rutas de transporte con clase BGP sobre estas clases de transporte, llevando la comunidad de mapas en ellas.
La familia de transporte con clase BGP se ejecuta junto con la familia de capas de transporte BGP-LU. En una red MPLS sin interrupciones que ejecuta BGP-LU, cumplir con los estrictos requisitos de SLA de 5G es un desafío, ya que las características de ingeniería de tráfico de los túneles no se conocen ni se conservan más allá de los límites del dominio. Los planos de transporte con clase BGP proporcionan medios operacionalmente fáciles y escalables para anunciar múltiples rutas para loopbacks remotos junto con la información de la clase de transporte en la arquitectura MPLS perfecta. En las rutas de la familia de transporte con clase BGP, las diferentes rutas de SLA se representan mediante la comunidad extendida Ruta de transporte-Destino, que lleva el color de la clase de transporte. Los enrutadores BGP receptores utilizan esta ruta de destino de transporte para asociar la ruta de transporte con clase BGP con la clase de transporte adecuada. Al volver a anunciar las rutas de transporte con clase BGP, MPLS intercambia rutas, interconecta los túneles intra-AS de la misma clase de transporte, formando así un túnel de extremo a extremo que conserva la clase de transporte.
Implementación intra-AS de planos de transporte con clase BGP
Figura 1 muestra una topología de red con escenarios de antes y después de la implementación de planos de transporte con clase BGP en un dominio intraAS. Los dispositivos PE11 y PE12 utilizan RSVP LSP como túnel de transporte y todas las rutas del túnel de transporte se instalan en RIB inet.3. La implementación de planos de tranordenación con clase BGP permite que los túneles de transporte RSVP sean conscientes del color de manera similar a los túneles de enrutamiento de segmentos.
Para clasificar túneles de transporte en clase de transporte BGP en una configuración intraAS:
- Defina la clase de transporte en el nodo de servicio (dispositivos de PE de entrada), por ejemplo, oro y bronce, y asigne valores de comunidad de colores a la clase de transporte definida.
Configuración de ejemplo:
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200; - Asocie el túnel de transporte a una clase de transporte específica en el nodo de entrada de los túneles.
Configuración de ejemplo:
pe11# show protocols mpls label-switched-path toPE12-bronze { transport-class bronze; } label-switched-path toPE12-gold { transport-class gold; }
Funcionalidad del plano de transporte con clase del BGP intraAS:
- El transporte con clase BGP crea RIB de transporte predefinidas por clase de transporte con nombre (oro y bronce) y deriva automáticamente la comunidad de mapeo a partir de su valor de color (100 y 200).
- Las rutas de transporte intra-AS se rellenan en las RIB de transporte mediante el protocolo de túnel cuando está asociado a una clase de transporte.
En este ejemplo, las rutas RSVP LSP asociadas con la clase de transporte gold (color 100) y la clase de transporte bronze (color 200) se instalan en las RIB de transporte junos-rti-tc-<100>.inet.3 y junos-rti-tc-<200>.inet.3, respectivamente.
- El nodo de servicio (PE de entrada) hace coincidir la comunidad de colores extendida (color:0:100 y color:0:200) de la ruta de servicio con la comunidad de mapeo en las RIB de resolución predefinidas y resuelve el siguiente salto de protocolo (PNH) en las RIB de transporte correspondientes (junos-rti-tc-<100>.inet.3 o junos-rti-tc-<200>.inet.3).
- Las rutas BGP se enlazan a un esquema de resolución llevando la comunidad de mapeo asimilado.
- Cada clase de transporte crea automáticamente dos esquemas de resolución predefinidos y deriva automáticamente la comunidad de asignación.
Un esquema de resolución es para resolver rutas de servicio que usan Color:0:<val> como comunidad de mapeo.
El otro esquema de resolución es para resolver rutas de transporte que usan Transport-Target:0:<val> como comunidad cartográfica.
- Si el PNH de la ruta de servicio no se puede resolver mediante las RIB enumeradas en el esquema de resolución predefinido, puede recurrir a la tabla de enrutamiento inet.3.
- También puede configurar la reserva entre RIB de transporte de diferentes colores mediante esquemas de resolución definidos por el usuario en la jerarquía de [edit routing-options resolution scheme] configuración.
Implementación de Inter-AS de planos de transporte con clase BGP
En una red interAS, BGP-LU se convierte en una red de transporte con clase BGP después de configurar un mínimo de dos clases de transporte (oro y bronce) en todos los nodos de servicio o dispositivos PE y nodos de borde (ABR y ASBR).
Para convertir los túneles de transporte en transporte con clase BGP:
- Defina la clase de transporte en los nodos de servicio (dispositivos de PE de entrada) y los nodos de borde (ABR y ASBR), por ejemplo, oro y broze.
Configuración de ejemplo:
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200; - Asocie los túneles de transporte a una clase de transporte específica en el nodo de entrada de los túneles (PE, ABR y ASBR de entrada).
Configuración de ejemplo:
Para RSVP LSP
abr23# show protocols mpls label-switched-path toASBR21-bronze { transport-class bronze; } label-switched-path toASBR22-gold { transport-class gold;Para el algoritmo FLXIBLE IS-IS
asbr13# show routing-options flex-algorithm 128 { … color 100; use-transport-class; } flex-algorithm 129 { … color 200; use-transport-class; } - Habilite una nueva familia para el transporte con clase BGP (transporte inet) y BGP-LU (unidifusión etiquetada con inet) en la red.
Configuración de ejemplo:
abr23# show protocols bgp group toAs2-RR27 { family inet { labeled-unicast { … } transport { … } cluster 172.16.2.3; neighbor 172.16.2.7; } - Anuncie las rutas de servicio desde el dispositivo de PE de salida con la comunidad de color extendida adecuada.
Configuración de ejemplo:
pe11# show policy-options policy-statement red term 1 { from { route-filter 192.168.3.3/32 exact; } then { community add map2gold; next-hop self; accept; } } term 2 { from { route-filter 192.168.33.33/32 exact; } then { community add map2bronze; next-hop self; accept; } } community map2bronze members color:0:200; community map2gold members color:0:100;
Funcionalidad de plano de transporte con clase de InterAS BGP:
- Los planos de transporte con clase BGP crean RIB de transporte predefinidas por clase de transporte con nombre (oro y bronce) y derivan automáticamente la comunidad de mapeo de su valor de color.
-
Las rutas de transporte intra-AS se rellenan en las RIB de transporte mediante protocolos de tunelización cuando se asocian a una clase de transporte.
Por ejemplo, las rutas de túnel de transporte asociadas con la clase de transporte oro y bronce se instalan en las RIB de transporte junos-rti-tc-<100>.inet.3 y junos-rti-tc-<200>.inet.3, respectivamente.
- Los planos de transporte con clase BGP utilizan un diferenciador de ruta y un destino de ruta únicos cuando copia las rutas del túnel de transporte de cada RIB de transporte a la tabla de enrutamiento bgp.transport.3.
- Los nodos de borde anuncian rutas desde la tabla de enrutamiento bgp.transport.3 a sus pares en otros dominios si el transporte inet familiar se negocia en la sesión BGP.
- El nodo de borde receptor instala estas rutas bgp-ct en la tabla de enrutamiento bgp.transport.3 y copia estas rutas según el destino de ruta de transporte en las RIB de transporte adecuadas.
- El nodo de servicio compara la comunidad de colores de la ruta de servicio con una comunidad de asignación en los esquemas de resolución y resuelve PNH en la RIB de transporte correspondiente ( junos-rti-tc-<100>.inet.3 o junos-rti-tc-<200>.inet.3).
- Los nodos fronterizos utilizan esquemas de resolución predefinidos para la resolución de PNH de rutas de transporte.
- Predefinidos o definidos por el usuario, ambos esquemas de resolución admiten la resolución PNH de rutas de servicio. Predefinido usa inet.3 como reserva, y el esquema de resolución definido por el usuario permite usar la lista de RIB de transporte en el orden especificado al resolver PNH.
- Si el PNH de la ruta de servicio no se puede resolver mediante las RIB enumeradas en el esquema de resolución definido por el usuario, se descarta la ruta.
Descripción general del transporte con clase BGP (BGP-CT) con túneles SR-TE de colores subyacentes
Beneficios de BGP-CT con túneles SR-TE de colores subyacentes
- Resuelve problemas de escala que puedan surgir en el futuro a medida que la red crece.
- Proporciona interconectividad para dominios que usan diferentes tecnologías.
- Desacopla los servicios y las capas de transporte, lo que resulta en una red completamente distribuida.
- Proporciona administración independiente del ancho de banda mediante un controlador de ingeniería de tráfico dentro del dominio para SR-TE.
Las grandes redes que crecen y evolucionan continuamente requieren una arquitectura de enrutamiento de segmentos sin fisuras. A partir de Junos OS versión 21.2,R1, admitimos BGP-CT con transporte subyacente como túneles SR-TE de colores. BGP-CT puede resolver rutas de servicio utilizando las RIB de transporte y calcular el siguiente salto. Los servicios que actualmente son compatibles con BGP-CT también pueden usar los túneles de color SR-TE subyacentes para la resolución de rutas. Los servicios ahora pueden usar los túneles de color SR-TE subyacentes, como los túneles de color estáticos, BGP SR-TE, RPD programable y PCEP. BGP-CT utiliza la accesibilidad del salto siguiente para resolver rutas de servicio en la clase de transporte deseada.
Para habilitar la resolución de ruta del servicio BGP-CT sobre túneles de color SR-TE subyacentes, incluya la use-transport-class instrucción en el nivel de [edit protocols source-packet-routing] jerarquía.
- Habilitar la
use-transport-classinstrucciónen el
junto con la[edit protocols source-packet-routing]nivel jerárquico.auto-createinstrucción en el[edit routing-options transport-class]nivel jerárquico. - No se admiten grupos RIB para túneles SR-TE de color con
use-transport-classtúneles SR-TE de solo color con esta característica.
Ejemplo: Configuración de planos de transporte con clase (dentro del dominio)
- Antes de empezar
- Descripción general funcional
- Información general sobre la topología
- Ilustraciones de topología
- Pasos de configuración de PE1
- Verificar planos de transporte con clase
- Apéndice 1: Solución de problemas
- Apéndice 2: Establecer comandos en todos los dispositivos
- Apéndice 3: Mostrar salida de configuración en PE1
Antes de empezar
| Requisitos de hardware y software |
Junos OS versión 21.1R1 o posterior. Nota:
Solo los enrutadores perimetrales del proveedor (PE1 y PE2) requieren compatibilidad con la versión de Junos OS para la función BGP-CT. |
|
Tiempo estimado de lectura |
45 minutos |
|
Tiempo estimado de configuración |
1 hora |
|
¿Qué esperar? |
Una red BGP-CT en funcionamiento con tres niveles de servicio que se asignan a rutas de LSP enrutadas de forma diversa. Una configuración de Junos que asigna tráfico específico (rutas de cliente VPN) a la clase de transporte deseada mediante comunidades extendidas de atributo de color BGP. Ingeniería de tráfico LSP básica para forzar las clases de tráfico a diversas rutas en la red del proveedor |
|
Impacto en el negocio |
Utilice este ejemplo de configuración para configurar y comprobar la característica BGP Classful Transport (BGP-CT) dentro de una única red autónoma (intradominio). BGP-CT mapea las rutas del cliente a rutas de red que pueden diseñarse para proporcionar diferentes niveles de rendimiento. Un caso de uso típico para BGP-CT dentro del dominio es que un proveedor de servicios implemente BGP-CT para ofrecer niveles de servicio VPN por niveles a sus clientes. |
|
Recursos útiles: |
|
|
Saber más |
Para comprender mejor BGP-CT, consulte Descripción general de los planos de transporte con clase BGP |
|
vLabs de Juniper |
Visite los laboratorios virtuales de Juniper (vLabs) para reservar un entorno limitado preconfigurado. Utilice el espacio aislado para interactuar con la función BGP-CT y comprenderla. Encontrará la demostración "Planos de transporte con clase (escenario intradominio)" en la sección de enrutamiento. |
|
Seguir leyendo |
Clase de servicio de Junos (JCOS) bajo demanda |
Descripción general funcional
Tabla 1 Proporciona un resumen rápido de los componentes de configuración implementados en este ejemplo.
|
Protocolos de enrutamiento y señalización |
|
|
OSPF |
Todos los enrutadores ejecutan OSPF como IGP. Todos los enrutadores pertenecen al área 0 (también llamada área troncal). El dominio de enrutamiento OSPF único proporciona conectividad de circuito cerrado en la red del proveedor. |
|
BGP interno y externo |
Los dispositivos perimetrales del cliente (CE) usan el emparejamiento EBGP para intercambiar rutas con su dispositivo perimetral de proveedor como parte de un servicio VPN de capa 3. Los dispositivos PE utilizan IBGP para intercambiar rutas VPN IPv4 de capa 3 con el PE remoto. Estas rutas también llevan una comunidad de colores que se utiliza para asignar el tráfico al túnel de plano de datos correcto. Nuestro ejemplo no utiliza un reflector de ruta, sino que opta por el emparejamiento directo de PE-PE. Nota:
El enrutador del proveedor (enrutador P) no ejecuta BGP. Es parte de un núcleo libre de BGP para promover el escalado. El dispositivo P utiliza la conmutación basada en etiquetas MPLS para transportar el tráfico VPN del cliente entre los dispositivos PE. |
|
Confirmación de asistencia (RSVP) |
Cada dispositivo PE señala tres LSP al PE remoto. Estos LSP se asignan a las clases de servicio correspondientes de oro, bronce y mejor esfuerzo (BE). RSVP admite ingeniería de tráfico enriquecida para forzar el tráfico en las rutas deseadas en la red del proveedor. A su vez, estas rutas se pueden diseñar para proporcionar diferentes necesidades de manejo de clase de servicio (CoS) para aplicar el SLA para cada clase de transporte. Nuestra topología básica proporciona tres rutas entre los dispositivos PE. Utilizamos una ruta con nombre con un ERO para garantizar un enrutamiento diverso de los LSP sobre el núcleo. Junos admite un amplio conjunto de capacidades para la ingeniería de tráfico. Para obtener más información, consulte Configuración de ingeniería de tráfico MPLS Nota:
La función de transporte con clase también es compatible con los LSP establecidos a través de la ingeniería de tráfico de enrutamiento de segmentos (SR-TE) y los túneles de algoritmo flexible IS-IS. |
|
MPLS |
La red del proveedor utiliza un plano de datos de conmutación de etiquetas basado en MPLS. El uso de MPLS con rutas TE garantiza que cada clase de servicio se pueda enrutar a través de rutas separadas con los niveles de rendimiento deseados. Como se señaló anteriormente, MPLS también proporciona compatibilidad con un núcleo sin BGP. |
| Túneles de transporte | |
|
Se establecen tres túneles MPLS (LSP) entre los dispositivos PE: |
Cada túnel se asigna a las siguientes clases de transporte:
|
| Familia de servicios | |
|
VPN de capa 3 ( |
BGP-CT también funciona con otras familias de servicios, como BGP etiquetado como Unicast, Flowspec o VPN de capa 2. |
| Tareas de verificación primarias | |
|
Verifique el funcionamiento de IGP, RSVP, MPLS, BGP y L3VPN. |
|
Modifique la red para efectuar la dirección del tráfico entre túneles de clase de transporte para simular el error de un túnel de servicio y la posterior conmutación por error a la ruta o clase de BE. |
Información general sobre la topología
Este ejemplo de configuración se basa en una VPN simple de capa 3 basada en MPLS con dos dispositivos perimetrales de cliente (CE) que se comunican a través de la red del proveedor de servicios. El núcleo de la red tiene tres enrutadores de proveedor (P) que transportan el tráfico del cliente VPN mediante conmutación basada en etiquetas. Los dos dispositivos perimetrales de proveedor (PE) proporcionan un servicio VPN de capa 3 a sus CE conectados. Los PE utilizan LSP MPLS señalados RSVP para transportar el tráfico VPN a través del núcleo. Consulte Example: Configure a Basic MPLS-Based Layer 3 VPN para obtener información general sobre el funcionamiento y la configuración de una L3VPN basada en MPLS.
Nos centramos en el flujo de tráfico de izquierda a derecha de CE1 a CE2, y cómo PE1 utiliza una comunidad de colores BGP adjunta a las rutas aprendidas de PE2 para mapear el tráfico enviado al CE remoto a través de los siguientes saltos de reenvío de LSP deseados. En nuestro ejemplo, PE1 usa objetos de ruta explícitos (ERO) para forzar el enrutamiento de estos LSP en diversas rutas. Nos saltamos este paso en PE2, lo que permite que los LSP se enruten en función del equilibrio de carga del IGP. Para que el tráfico fluya de CE1 a CE2, CE1 debe tener una ruta para llegar a CE2. Las rutas para CE2 viajan en la dirección opuesta al tráfico que atrae desde CE1. Es decir, la ruta hacia el loopback de CE2 viaja de derecha a izquierda.
En nuestro ejemplo, la clase de servicio Gold LSP está restringida a la ruta PE1-P1-PE2. La clase de servicio bronce utiliza la ruta PE1-P2-PE2. El LSP de mejor esfuerzo se enruta a lo largo de la ruta PE1-P3-PE2. El diagrama de topología utiliza vínculos de colores para representar las tres rutas de acceso.
En nuestro ejemplo, agregamos la protocols mpls icmp-tunneling instrucción. Esto es para permitir que los dispositivos CE tracen la ruta a través de la red del proveedor, incluso cuando esa ruta implica conmutación MPLS, como es el caso del tráfico VPN de capa 3. Esta opción le ayuda a confirmar que se utiliza la ruta de reenvío esperada en función de la clase de transporte.
Tabla 2 Describe el rol y la funcionalidad de cada dispositivo en el contexto de esta topología. Haga clic en cualquier nombre de dispositivo para ver su configuración rápida.
| Nombre del dispositivo |
Función |
Función |
| CE1 | Dispositivo CE local (R1) . | Emparejamiento EBGP con enrutador PE1 para anunciar y aprender direcciones de bucle invertido de dispositivos CE. Pruebe la conectividad del servicio con pings a la dirección de circuito cerrado de CE2. |
| CE2 | Dispositivo CE remoto (R7) | Emparejamiento EBGP con enrutador PE2 para anunciar y aprender direcciones de bucle invertido de dispositivos CE. Configura y adjunta la comunidad de asignación de colores. |
| PE1 (DUT) | dispositivo de PE local (R2). | PE1 asigna las rutas de servicio etiquetadas por colores que se originan en CE2 a una clase de transporte (TC) copatrocinadora. PE1 recibe las rutas de etiquetas de color a través de su sesión de IBGP a PE2. En este ejemplo, PE1 utiliza restricciones basadas en ERO para forzar diversos enrutamientos de sus tres LSP sobre el núcleo del proveedor. |
| PE2 | Dispositivo de PE remoto (R6). | PE2 vuelve a anunciar las rutas etiquetadas por color recibidas por CE2 a PE1 mediante IBGP. Estas rutas utilizan la inet-vpn familia para admitir servicios VPN de capa 3 con TC mapeados por colores. |
| P1 P2 P3 | Dispositivos de proveedor P1, P2 y P3 (R3, R4 y R5). | Los dispositivos P1-P3 representan la red central del proveedor de servicios. Estos son dispositivos de tránsito puro que realizan conmutación de etiquetas MPLS para transportar el tráfico CE enviado a través de la VPN L3. |
Ilustraciones de topología
Pasos de configuración de PE1
Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración
Para obtener una configuración completa en todos los dispositivos, consulte:
En esta sección se destacan las principales tareas de configuración necesarias para configurar el dispositivo PE1 en este ejemplo. El primer paso es común a la configuración de un servicio VPN básico de capa 3. El siguiente conjunto de pasos es específico para agregar la función BGP-CT a su VPN de capa 3. Ambos dispositivos PE tienen una configuración similar, aquí nos centramos en PE1.
-
Primero, aprovisione la VPN general de capa 3:
-
Configure y numere las interfaces de circuito cerrado, núcleo y CE para IPv4. Asegúrese de habilitar la familia en las interfaces orientadas al núcleo que se conectan a los dispositivos P para admitir la
mplsconmutación MPLS. -
Configure un número de sistema autónomo.
-
Configure OSPF de área única en las interfaces de circuito cerrado y núcleo.
-
Configure RSVP en las interfaces de circuito cerrado y núcleo.
-
Configure la sesión de emparejamiento del IBGP con el dispositivo de PE remoto, PE2. Incluya la familia de
inet-vpndirecciones para admitir una VPN IPv4 de capa 3. -
Configure una instancia de enrutamiento basada en VRF para el dispositivo CE1. Utilice EBGP como protocolo de enrutamiento PE-CE.
[edit] set interfaces ge-0/0/1 unit 0 family inet address 10.1.23.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 description "Link from PE1 to P2" set interfaces ge-0/0/2 unit 0 family inet address 10.1.24.1/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 description "Link from PE1 to P3" set interfaces ge-0/0/3 unit 0 family inet address 10.1.25.1/24 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.1/32
[edit] set routing-instances CE1_L3vpn instance-type vrf set routing-instances CE1_L3vpn protocols bgp group CE1 type external set routing-instances CE1_L3vpn protocols bgp group CE1 peer-as 64510 set routing-instances CE1_L3vpn protocols bgp group CE1 neighbor 172.16.1.1 set routing-instances CE1_L3vpn interface ge-0/0/0.0 set routing-instances CE1_L3vpn route-distinguisher 192.168.0.1:12 set routing-instances CE1_L3vpn vrf-target target:65412:12
[edit] set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.1 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.2 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set protocols rsvp interface ge-0/0/3.0
[edit] set routing-options route-distinguisher-id 192.168.0.1 set routing-options autonomous-system 65412
-
-
Agregue planos de transporte con clase a la VPN de capa 3.
Configure las clases de transporte oro y bronce.
Este es un paso crítico en la configuración de la característica de transporte con clase. Estas clases de transporte se asignan a LSP señalizados RSVP (y posiblemente diseñados por ingeniería de tráfico) que atraviesan el núcleo del proveedor. Las rutas remotas aprendidas de CE2 se etiquetan con comunidades de color que se asignan a estas clases de transporte y, al hacerlo, al LSP deseado entre los dispositivos PE.
[edit] set routing-options transport-class name gold color 100 set routing-options transport-class name bronze color 200 set routing-options resolution preserve-nexthop-hierarchy
-
Configure tres LSP de PE1 a PE2 con un enrutamiento restringido que obligue a cada uno a atravesar un enrutador P diferente. Dos de estos LSP se asignan a las gold clases y bronze transporte. El LSP de oro se enruta a través de P1, el bronce a través de P2 y el mejor esfuerzo a través del dispositivo P3.
Una vez asignado a clases de transporte, el proveedor de servicios puede colocar tráfico de cliente específico, como lo indica una comunidad de colores BGP, en un LSP específico. Con este mapeo de color a LSP, el proveedor de servicios puede ofrecer un servicio escalonado con diferentes SLA.
En nuestro ejemplo, usamos un ERO estricto para garantizar que los tres LSP se enruten de manera diversa en las tres rutas disponibles en la topología.
[edit] set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path lsp_to_pe2 primary best-effort set protocols mpls label-switched-path gold_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path gold_lsp_to_pe2 preference 5 set protocols mpls label-switched-path gold_lsp_to_pe2 primary gold set protocols mpls label-switched-path gold_lsp_to_pe2 transport-class gold set protocols mpls label-switched-path bronze_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path bronze_lsp_to_pe2 preference 5 set protocols mpls label-switched-path bronze_lsp_to_pe2 primary bronze set protocols mpls label-switched-path bronze_lsp_to_pe2 transport-class bronze set protocols mpls path gold 10.1.23.2 strict set protocols mpls path bronze 10.1.24.2 strict set protocols mpls path best-effort 10.1.25.2 strict set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0
-
Para facilitar el respaldo al túnel predeterminado de clase de servicio (mejor esfuerzo), configuramos los túneles de clase de transporte Gold y Bronze con una preferencia global más baja. En este ejemplo, el valor de preferencia cambia de 7 a 5 predeterminado. Esto permite el uso del túnel de mejor esfuerzo como alternativa en caso de que los túneles de oro o bronce se vuelvan inutilizables. Establecer una preferencia más baja (más preferida) en los túneles de oro y bronce garantiza que se seleccionen para el reenvío, aunque la ruta de servicio pueda resolverse en el túnel de mejor esfuerzo.
Nota:Esta sección se centró en la configuración necesaria en el dispositivo PE1. Cabe señalar que para que la función de selección del próximo salto de transporte classful funcione en PE1, las rutas remotas del dispositivo CE2 deben estar etiquetadas con una comunidad de colores. Este etiquetado puede producirse en el dispositivo PE2 remoto o en el dispositivo CE2 remoto. Mostramos este último enfoque aquí para completar:
-
Haga coincidir las etiquetas de comunidad de colores agregadas en el CE2 remoto con las definiciones de clase de transporte para los TC bronce y oro.
[edit] set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then community add map2bronze set policy-options policy-statement adv_direct term 1 then accept set policy-options community map2bronze members color:0:200 set policy-options community map2gold members color:0:100
Verificar planos de transporte con clase
En esta sección nos centramos en los comandos que demuestran una característica de transporte de clase trabajadora. Véase el apéndice 1: Solución de problemas de los comandos usados para comprobar la funcionalidad subyacente que necesita la característica de transporte con clase.
Usará estos comandos para comprobar que el transporte con clase BGP funciona correctamente.
| Comando |
Tarea de verificación |
| mostrar enrutamiento de clase de transporte | Compruebe las clases de transporte y sus atributos asociados. Esto incluye la comunidad de asignación y la instancia de enrutamiento. |
| Mostrar esquema de resolución de rutas | Muestra cómo se resuelven las rutas de clase de servicio para los próximos saltos de LSP. Compruebe las tablas de enrutamiento de resolución para una ruta específica. |
| mostrar protocolo de recepción de rutas BGP pe2-loopback-address | Verifique que las rutas VPN recibidas por PE1 tengan una comunidad de colores BGP adjunta. |
| Mostrar ruta y Mostrar VPN de tabla de reenvío de rutasvpn | Compruebe la selección del túnel de transporte viendo el protocolo nexthop (PNH) para las rutas en PE1. |
| mostrar estadísticas de LSP de MPLS y show route forwarding-table | Compruebe el túnel de transporte utilizado por una ruta de clase de transporte específica. |
- Comprobar clases de transporte y túneles de transporte
- Comprobar esquemas de resolución del siguiente salto
- Verificar el etiquetado de color y la selección del siguiente salto para rutas CE2
- Verificar la conectividad de extremo a extremo
- Confirme la conmutación por error al máximo esfuerzo
Comprobar clases de transporte y túneles de transporte
Propósito
PE1 y PE2 utilizan túneles de transporte MPLS señalizados RSVP para admitir un servicio VPN de capa 3 capaz de ofrecer niveles de servicio diferenciados. Estas rutas de servicio tienen sus próximos saltos resueltos en un túnel MPLS específico basado en la clase de servicio correspondiente. La clase de servicio se señaliza adjuntando una comunidad de colores BGP a las rutas de cliente VPN.
En esta parte, confirmará que los tres LSP de PE1 estén operativos, que estén asignados a la clase de transporte correcta y que se enruten correctamente sobre el núcleo del proveedor.
Acción
Desde el modo operativo, ingrese el comando show route 192.168.0.2.
user@PE1 show route 192.168.0.2
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[OSPF/10] 00:27:20, metric 2
to 10.1.24.2 via ge-0/0/2.0
> to 10.1.25.2 via ge-0/0/3.0
to 10.1.23.2 via ge-0/0/1.0
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[RSVP/7/1] 00:13:09, metric 2
> to 10.1.25.2 via ge-0/0/3.0, label-switched-path lsp_to_pe2
junos-rti-tc-100.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[RSVP/5/1] 00:13:11, metric 2
> to 10.1.23.2 via ge-0/0/1.0, label-switched-path gold_lsp_to_pe2
junos-rti-tc-200.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[RSVP/5/1] 00:13:08, metric 2
> to 10.1.24.2 via ge-0/0/2.0, label-switched-path bronze_lsp_to_pe2Significado
El resultado confirma que PE1 ha aprendido tres rutas al circuito cerrado de PE2 a través de OSPF. Estas rutas están en la inet.0 tabla. También observa que los tres LSP se representan como próximos saltos viables para alcanzar PE2. Tenga en cuenta que cada uno de estos LSP está alojado en una tabla de enrutamiento diferente. La parte resaltada de los siguientes saltos IP (y el nombre de interfaz correspondiente) confirma el enrutamiento LSP diverso deseado sobre el núcleo. El tráfico asignado a la ruta dorada se envía a 10.1.23.2, mientras que el tráfico para bronce y BE se envía a 10.1.24.2 y 10.1.25.2, respectivamente.
Se crean las siguientes RIB y túneles de transporte.
-
junos-rti-tc-100.inet.3por gold_lsp_to_pe2 -
junos-rti-tc-200.inet.3por bronze_lsp_to_pe2 -
inet.3por lsp_to_pe2
Comprobar esquemas de resolución del siguiente salto
Propósito
Compruebe los esquemas de resolución de rutas de servicio, la comunidad de mapeo asociada y cómo se resuelve el siguiente salto en las tablas de enrutamiento contribuyentes.
Acción
Desde el modo operativo, ingrese el comando show route resolution scheme all.
user@PE1> show route resolution scheme all Resolution scheme: junos-resol-schem-tc-100-v4-service References: 1 Mapping community: color:0:100 Resolution Tree index 1, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet.3 inet.3 Resolution scheme: junos-resol-schem-tc-100-v4-transport References: 1 Mapping community: transport-target:0:100 Resolution Tree index 3, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet.3 Resolution scheme: junos-resol-schem-tc-100-v6-service References: 1 Mapping community: color:0:100 Resolution Tree index 2, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet6.3 inet6.3 Resolution scheme: junos-resol-schem-tc-100-v6-transport References: 1 Mapping community: transport-target:0:100 Resolution Tree index 4, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet6.3 Resolution scheme: junos-resol-schem-tc-200-v4-service References: 1 Mapping community: color:0:200 Resolution Tree index 5, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet.3 inet.3 Resolution scheme: junos-resol-schem-tc-200-v4-transport References: 1 Mapping community: transport-target:0:200 Resolution Tree index 7, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet.3 Resolution scheme: junos-resol-schem-tc-200-v6-service References: 1 Mapping community: color:0:200 Resolution Tree index 6, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet6.3 inet6.3 Resolution scheme: junos-resol-schem-tc-200-v6-transport References: 1 Mapping community: transport-target:0:200 Resolution Tree index 8, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet6.3
Significado
Centrándonos en las partes IPv4 de la salida, verá que la junos-tc-100 (gold) clase de transporte tiene dos esquemas de resolución ( junos-resol-schem-tc-100-v4-service y junos-resol-schem-tc-100-v4-transport ) utilizados para el servicio y las rutas de transporte, respectivamente.
El esquema de resolución para las rutas de servicio Gold (junos-resol-schem-tc-100-v4-service) proporciona resolución tanto en las junos-rti-tc-100.inet.3 tablas como en las inet.3 tablas de enrutamiento (resaltadas en la salida de muestra). La lista de las tablas de resolución de servicio y BE es cómo se produce la reserva cuando la clase de servicio está inactiva. Recuerde que esta es la razón por la que modificamos el valor de preferencia de los LSP de servicio (estableciendo la preferencia en 5 en lugar del valor predeterminado 7), para garantizar que siempre se prefiera la ruta de servicio sobre el respaldo de BE.
Verificar el etiquetado de color y la selección del siguiente salto para rutas CE2
Propósito
Confirme que PE2 anuncia la ruta de circuito cerrado para CE2 con una comunidad de colores que selecciona la clase de servicio bronce (color 200).
En nuestro ejemplo, configuramos el dispositivo CE2 para adjuntar la comunidad de colores. PE2 deja esta comunidad en su lugar cuando vuelve a anunciar la ruta a PE1. Esto significa que el cliente VPN puede efectuar sus propias asignaciones de clase de servicio. Cuando se desee, el enrutador de PE puede blanquear o eliminar cualquier comunidad recibida del CE. En este caso, el dispositivo PE debe configurarse para conectar la comunidad de mapeo de color deseada a las rutas CE antes de volver a anunciarlas en PE1.
Acción
Desde el modo operativo, ingrese el comando show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail.
user@PE1> show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
* 172.16.255.2/32 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 192.168.0.2:12
VPN Label: 299808
Nexthop: 192.168.0.2
Localpref: 100
AS path: 64520 I
Communities: target:65412:12 color:0:200
Muestre la entrada de la tabla de reenvío para el circuito cerrado CE2 en la instancia de enrutamiento VPN en PE1. Confirme que el siguiente salto de reenvío coincide con la clase de transporte deseada (bronce). Utilice el show route forwarding-table vpn CE1_L3vpn destination 172.16.255.2 extensive comando.
user@PE1> show route forwarding-table vpn CE1_L3vpn destination 172.16.255.2 extensive
Routing table: CE1_L3vpn.inet [Index 10]
Internet:
Destination: 172.16.255.2/32
Route type: user
Route reference: 0 Route interface-index: 0
Multicast RPF nh index: 0
P2mpidx: 0
Flags: sent to PFE, prefix load balance
Next-hop type: indirect Index: 1048574 Reference: 2
Nexthop:
Next-hop type: composite Index: 662 Reference: 2
Load Balance Label: Push 299808, None
Nexthop: 10.1.24.2
Next-hop type: Push 299872 Index: 653 Reference: 2
Load Balance Label: None
Next-hop interface: ge-0/0/2.0 Significado
Las entradas resaltadas confirman que el tráfico que coincide con la ruta de circuito cerrado CE2 se envía a 10.1.24.2 mediante la interfaz ge-0/0/2. Recuerde de los ERO utilizados para los LSP, esta interfaz y el siguiente salto están asociados con el LSP bronce y la clase de transporte. La 299808 etiqueta se utiliza para identificar el VRF del servicio. La etiqueta de transporte RSVP externa es 299872.
Confirme rápidamente que esta es la etiqueta de transporte RSVP correcta para la clase bronce con un show rsvp session detail name bronze_lsp_to_pe2 comando
root@PE1> show rsvp session detail name bronze_lsp_to_pe2 Ingress RSVP: 3 sessions 192.168.0.2 From: 192.168.0.1, LSPstate: Up, ActiveRoute: 0 LSPname: bronze_lsp_to_pe2, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 299872 Resv style: 1 FF, Label in: -, Label out: 299872 Time left: -, Since: Tue Aug 16 12:17:12 2022 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 2 receiver 23256 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.1.24.2 (ge-0/0/2.0) 1 pkts RESV rcvfrom: 10.1.24.2 (ge-0/0/2.0) 1 pkts, Entropy label: Yes Explct route: 10.1.24.2 10.1.46.2 Record route: <self> 10.1.24.2 10.1.46.2 Total 1 displayed, Up 1, Down 0
Las partes resaltadas indican que el LSP bronce se enruta a través del dispositivo P2 y está asociado con la etiqueta de transporte RSVP indicada (299856) que confirmó previamente en la tabla de reenvío VPN para la dirección de circuito cerrado CE2.
Verificar la conectividad de extremo a extremo
Propósito
Compruebe la conectividad de extremo a extremo en el dominio del proveedor haciendo ping entre CE1 y CE2. Examine las estadísticas de tráfico MPLS para proporcionar confirmación adicional de que se utiliza la clase de transporte bronce.
Acción
Desde el modo operativo, ingrese el comando ping.
user@CE1> ping 172.16.255.2 source 172.16.255.1 count 100 rapid PING 172.16.255.2 (172.16.255.2): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --- 172.16.255.2 ping statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.647/3.589/30.264/2.695 ms
Desde el modo operativo en PE1, introduzca el show mpls lsp statistics comando.
user@PE1> show mpls lsp statistics Ingress LSP: 3 sessions To From State Packets Bytes LSPname 192.168.0.2 192.168.0.1 Up 100 8400 bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 0 gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 0 lsp_to_pe2 Total 3 displayed, Up 3, Down 0 <output truncated for brevity>
Acción
Trace la ruta desde CE1 hasta el loopback de CE2. Nuestra configuración incluye la icmp-tunneling instrucción para admitir una ruta de rastreo basada en ICMP con saltos MPLS en el núcleo del proveedor.
user@CE1> traceroute no-resolve 172.16.255.2
traceroute to 172.16.255.2 (172.16.255.2), 30 hops max, 52 byte packets
1 172.16.1.2 2.174 ms 1.775 ms 1.917 ms
2 10.1.24.2 5.171 ms 5.768 ms 4.900 ms
MPLS Label=299872 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=1 S=1
3 10.1.46.2 4.707 ms 4.347 ms 4.419 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 172.16.255.2 5.640 ms 5.851 ms 44.777 ms
Significado
El intercambio de ping es exitoso y las estadísticas confirman el uso del túnel de transporte de bronce. Esto se espera dado que la ruta a CE2 tiene la comunidad de 200 colores adjunta. Los resultados de la ruta de seguimiento confirman que el tráfico se reenvía a través de un LSP y que este LSP se reenvía a través de 10.1.24.2. Esta es la dirección IP asignada al dispositivo P2. El siguiente salto de reenvío y el valor de la etiqueta externa confirman que este tráfico se envía en la clase de servicio bronce LSP.
Confirme la conmutación por error al máximo esfuerzo
Propósito
Baje el LSP de transporte bronce para comprobar que el tráfico enviado a CE2 conmuta por error a la ruta BE.
Acción
Ingrese al modo de configuración y especifique un siguiente salto no válido como ERO para el túnel de transporte bronce. La incapacidad de satisfacer el requisito de ERO reduce el LSP relacionado.
[edit] user@PE1# set protocols mpls path bronze 10.1.66.6 strict
Una vez que se confirma el cambio, el túnel de bronce se muestra hacia abajo:
root@PE1> show mpls lsp ingress Ingress LSP: 3 sessions To From State Rt P ActivePath LSPname 192.168.0.2 0.0.0.0 Dn 0 - bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * gold gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * best-effort lsp_to_pe2
Repita los ping comandos y trace route de CE1 al loopback de CE2.
root@CE1> ping 172.16.255.2 source 172.16.255.1 count 100 rapid
PING 172.16.255.2 (172.16.255.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--- 172.16.255.2 ping statistics ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.164/5.345/12.348/1.240 ms
root@CE1> traceroute no-resolve 172.16.255.2
traceroute to 172.16.255.2 (172.16.255.2), 30 hops max, 52 byte packets
1 172.16.1.2 2.493 ms 1.766 ms 1.913 ms
2 10.1.25.2 5.211 ms 5.016 ms 5.514 ms
MPLS Label=299808 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=1 S=1
3 10.1.56.2 4.216 ms 4.467 ms 4.551 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 172.16.255.2 5.492 ms 5.543 ms 5.112 msVuelva a mostrar las estadísticas MPLS en PE1.
user@PE1> show mpls lsp statistics root@PE1> show mpls lsp statistics Ingress LSP: 3 sessions To From State Packets Bytes LSPname 192.168.0.2 0.0.0.0 Dn NA NA bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 0 gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 100 8400 lsp_to_pe2 Total 3 displayed, Up 2, Down 1 . . .
Significado
El intercambio de ping aún tiene éxito, aunque ahora en un camino de mejor esfuerzo. En el PE, las estadísticas confirman el uso del túnel de transporte de mejor esfuerzo. La ruta de rastreo muestra que PE1 ahora reenvía al siguiente salto 10.1.25.2 a través de PE3. Esto confirma la conmutación por error de una clase de transporte coloreada a la clase de mejor esfuerzo en caso de que se produzca un error en el túnel de transporte.
En esta sección, efectuamos la conmutación por error a la clase BE bajando el LSP asignado a la clase de servicio bronce. Como alternativa, considere cambiar la política de exportación de EBGP en el dispositivo CE2 para que conecte la comunidad de color dorado (100). Con este enfoque, espera ver tráfico de ping de CE1 a CE2 tomando el LSP de oro en lugar de conmutar por error a BE. Lo siguiente hace el truco en CE2 si prefiere este enfoque. Asegúrese de confirmar los cambios en CE2.
[edit] root@CE2# delete policy-options policy-statement adv_direct term 1 then community add map2bronze root@CE2# set policy-options policy-statement adv_direct term 1 then community add map2gold
Apéndice 1: Solución de problemas
Nuestra sección de verificación se basa en la suposición de que tiene una red en funcionamiento, lo que permite centrarse en confirmar el funcionamiento de BGP-CT. La función BGP-CT, en un contexto VPN de capa 3 basado en MPLS, depende de una red con interfaces que funcionen, IGP, RSVP, MPLS y BGP.
Tabla 4 proporciona orientación sobre qué buscar si la solución BGP-CT no funciona como se esperaba. La tabla está estructurada de abajo hacia arriba, comenzando con la conectividad de interfaz básica y terminando con el intercambio de ruta BGP exitoso entre los dispositivos PE.
Como parte de este ejemplo, configure una dirección de circuito cerrado y un ID de enrutador. Si el dispositivo anteriormente tenía un RID diferente, puede tomar algún tiempo para que las cosas se estabilicen. Cambiar el RID es muy perjudicial y no es algo que suceda a menudo. Cuando se encuentre en un entorno de laboratorio, se sugiere que emita el comando de restart routing modo operativo en todos los dispositivos justo después de confirmar el nuevo RID.
| Capa funcional |
Enfoque de verificación |
| Interfaces y direccionamiento IP | Compruebe que todas las interfaces de la topología estén operativamente activas. Compruebe que puede hacer ping tanto al extremo local como al remoto de cada vínculo. Como la mayoría de las redes, los protocolos y servicios de este ejemplo requieren una infraestructura IPv4 que funcione.root@PE1> show interfaces terse | match "(ge-0/0/0|ge-0/0/1|ge-0/0/2|ge-0/0/3)"
ge-0/0/0 up up
ge-0/0/0.0 up up inet 172.16.1.2/30
ge-0/0/1 up up
ge-0/0/1.0 up up inet 10.1.23.1/24
ge-0/0/2 up up
ge-0/0/2.0 up up inet 10.1.24.1/24
ge-0/0/3 up up
ge-0/0/3.0 up up inet 10.1.25.1/24
root@PE1> ping 10.1.23.2 count 1
PING 10.1.23.2 (10.1.23.2): 56 data bytes
64 bytes from 10.1.23.2: icmp_seq=0 ttl=64 time=2.951 ms
--- 10.1.23.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.951/2.951/2.951/0.000 ms
root@PE1> ping 172.16.1.1 routing-instance CE1_L3vpn count 1
PING 172.16.1.1 (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.1: icmp_seq=0 ttl=64 time=2.755 ms
--- 172.16.1.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.755/2.755/2.755/0.000 ms
|
| Enrutamiento OSPF (IGP) | Confirme que todos los dispositivos del proveedor tengan todas las adyacencias OSPF esperadas. Utilice los comandos del show ospf interfaces modo operativo y show ospf neighbors . Mostrar las rutas de las direcciones de circuito cerrado del proveedor y confirmar rutas OSPF válidas para todas las direcciones de circuito cerrado remoto (show route protocol ospf | match 192.168.0). Ping desde el circuito cerrado local a las direcciones de circuito cerrado remoto de todos los enrutadores del proveedor.En este ejemplo se usan LSP basados en CSPF. Esto requiere que OSPF esté configurado con la root@PE1> show ospf interface Interface State Area DR ID BDR ID Nbrs ge-0/0/1.0 BDR 0.0.0.0 192.168.0.11 192.168.0.1 1 ge-0/0/2.0 BDR 0.0.0.0 192.168.0.12 192.168.0.1 1 ge-0/0/3.0 DR 0.0.0.0 192.168.0.1 192.168.0.13 1 lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0 root@PE1> show ospf neighbor Address Interface State ID Pri Dead 10.1.23.2 ge-0/0/1.0 Full 192.168.0.11 128 34 10.1.24.2 ge-0/0/2.0 Full 192.168.0.12 128 32 10.1.25.2 ge-0/0/3.0 Full 192.168.0.13 128 37 root@PE1> show route protocol ospf| match 192.168.0 192.168.0.2/32 *[OSPF/10] 00:10:15, metric 2 192.168.0.11/32 *[OSPF/10] 00:18:40, metric 1 192.168.0.12/32 *[OSPF/10] 00:18:35, metric 1 192.168.0.13/32 *[OSPF/10] 00:10:15, metric 1 root@PE1> ping 192.168.0.2 source 192.168.0.1 count 1 PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=63 time=3.045 ms --- 192.168.0.2 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.045/3.045/3.045/0.000 ms |
| MPLS y RSVP | Compruebe que todas las interfaces principales estén habilitadas para la mpls familia. con un show interfaces terse comando. Compruebe también que todas las interfaces de proveedor estén habilitadas en las protocols mpls jerarquías y protocols RSVP . Utilice los show mpls interfaces comandos y show rsvp interfaces . Nota:
Asegúrese de confirmar que aparecen los números de unidad de interfaz correctos para la familia MPLS y para cada protocolo. En este ejemplo se utiliza la unidad 0, que es el número de unidad predeterminado, en todas las interfaces. root@PE1> show rsvp interface
RSVP interface: 4 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
ge-0/0/1.0 Up 1 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/2.0 Up 1 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/3.0 Up 1 100% 1000Mbps 1000Mbps 0bps 0bps
lo0.0 Up 0 100% 0bps 0bps 0bps 0bps
root@PE1> show mpls interface
Interface State Administrative groups (x: extended)
ge-0/0/1.0 Up <none>
ge-0/0/2.0 Up <none>
ge-0/0/3.0 Up <none>En los enrutadores de PE, confirme que los LSP estén correctamente definidos para salir en la dirección de circuito cerrado del dispositivo de PE remoto. Verifique que las ERO y cualquier otra restricción de TE sean válidas. Utilice los Nota: En nuestros ejemplos se utilizan LSP basados en CSPF. Esto requiere que el IGP admita una base de datos TE (TED). Si OSPF es el IGP, asegúrese de incluir la instrucción de
traffic-engieering configuración. Como alternativa, considere usar la no-cspf instrucción en la definición de LSP para eliminar CSPF de la ecuación.root@PE1> show mpls lsp Ingress LSP: 3 sessions To From State Rt P ActivePath LSPname 192.168.0.2 192.168.0.1 Up 0 * bronze bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * gold gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * best-effort lsp_to_pe2 Total 3 displayed, Up 3, Down 0 Egress LSP: 3 sessions To From State Rt Style Labelin Labelout LSPname 192.168.0.1 192.168.0.2 Up 0 1 FF 3 - bronze_lsp_to_pe1 192.168.0.1 192.168.0.2 Up 0 1 FF 3 - gold_lsp_to_pe1 192.168.0.1 192.168.0.2 Up 0 1 FF 3 - lsp_to_pe1 Total 3 displayed, Up 3, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 |
| protocolo de puerta de enlace de frontera (BGP) | Utilice el show bgp summarycomando en los dispositivos de PE para confirmar que se han establecido tanto su sesión de EBGP en el CE como la sesión de IBGP en el PE remoto. Si BGP está inactivo a pesar de poder hacer ping, sospeche que la definición del par es incorrecta. Recuerde que el emparejamiento de circuito cerrado (para IBGP) requiere la local-address instrucción. Para el EBGP, especifique los próximos saltos conectados directamente y confirme que se especifican el número de AS local bajo edit routing-options y el número de AS remoto, en el grupo par EBGP.Confirme que la sesión de PE-PE tiene habilitada la root@PE1> show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
0 0 0 0 0 0
bgp.l3vpn.0
2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.1 64510 55 55 0 0 23:13 Establ
CE1_L3vpn.inet.0: 1/2/2/0
192.168.0.2 65412 57 56 0 0 23:11 Establ
inet.0: 0/0/0/0
bgp.l3vpn.0: 2/2/2/0
CE1_L3vpn.inet.0: 2/2/2/0Los comandos de protocolo de recepción y publicidad de ruta de mostrar son útiles para confirmar qué rutas anuncia o recibe un altavoz BGP determinado, respectivamente. root@PE1> show route advertising-protocol bgp 192.168.0.2 CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.1.0/30 Self 100 I * 172.16.255.1/32 Self 100 64510 I root@PE1> show route receive-protocol bgp 192.168.0.2 inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden) inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.2.0/30 192.168.0.2 100 I * 172.16.255.2/32 192.168.0.2 100 64520 I junos-rti-tc-100.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) junos-rti-tc-200.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 192.168.0.2:12:172.16.2.0/30 * 192.168.0.2 100 I 192.168.0.2:12:172.16.255.2/32 * 192.168.0.2 100 64520 I |
| VPN de capa 3 | Asegúrese de que la sesión de IBGP admita family inet-vpn rutas. Confirme que las rutas anunciadas por PE remoto se importan a la instancia correcta en función del destino de la ruta. Asegúrese de que la política de importación y exportación utilizada en la instancia de enrutamiento de cada PE coincida y anuncie las rutas correctas. Algunas de las pantallas de la sección de verificación de BGP confirman la recepción de rutas CE remotas y la importación de esas rutas en la instancia de VRF. root@PE1> show bgp neighbor 192.168.0.2 | match nlri
NLRI for restart configured on peer: inet-unicast inet-vpn-unicast
NLRI advertised by peer: inet-unicast inet-vpn-unicast
NLRI for this session: inet-unicast inet-vpn-unicast
root@PE1> show route table CE1_L3vpn.inet
root@PE1> show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail
. . .
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
* 172.16.255.2/32 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 192.168.0.2:12
VPN Label: 299776
Nexthop: 192.168.0.2
Localpref: 100
AS path: 64520 I
Communities: target:65412:12 color:0:200
root@PE1> show route table CE1_L3vpn.inet
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.0/30 *[Direct/0] 00:30:11
> via ge-0/0/0.0
[BGP/170] 00:29:57, localpref 100
AS path: 64510 I, validation-state: unverified
> to 172.16.1.1 via ge-0/0/0.0
172.16.1.2/32 *[Local/0] 00:30:11
Local via ge-0/0/0.0
172.16.2.0/30 *[BGP/170] 00:21:26, localpref 100, from 192.168.0.2
AS path: I, validation-state: unverified
> to 10.1.25.2 via ge-0/0/3.0, label-switched-path lsp_to_pe2
172.16.255.1/32 *[BGP/170] 00:29:57, localpref 100
AS path: 64510 I, validation-state: unverified
> to 172.16.1.1 via ge-0/0/0.0
172.16.255.2/32 *[BGP/170] 00:29:40, localpref 100, from 192.168.0.2
AS path: 64520 I, validation-state: unverified
> to 10.1.24.2 via ge-0/0/2.0, label-switched-path bronze_lsp_to_pe2Confirme que el dispositivo CE está recibiendo y anunciando las rutas esperadas utilizando los métodos descritos para la resolución de problemas de BGP. |
Apéndice 2: Establecer comandos en todos los dispositivos
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit].
CE1
set interfaces ge-0/0/0 unit 0 description "Link from CE1 to PE1 for Layer 3 VPN" set interfaces ge-0/0/0 unit 0 family inet address 172.16.1.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.1/32 set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then accept set protocols bgp group ToPE1 type external set protocols bgp group ToPE1 export adv_direct set protocols bgp group ToPE1 peer-as 65412 set protocols bgp group ToPE1 neighbor 172.16.1.2 set routing-options router-id 172.16.255.1 set routing-options autonomous-system 64510 set system host-name CE1
CE2
set interfaces ge-0/0/0 unit 0 description "Link from CE2 to PE2 for Layer 3 VPN" set interfaces ge-0/0/0 unit 0 family inet address 172.16.2.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.2/32 set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then community add map2bronze set policy-options policy-statement adv_direct term 1 then accept set policy-options community map2bronze members color:0:200 set policy-options community map2gold members color:0:100 set protocols bgp group PE2 type external set protocols bgp group PE2 export adv_direct set protocols bgp group PE2 peer-as 65412 set protocols bgp group PE2 neighbor 172.16.2.2 set routing-options router-id 172.16.255.2 set routing-options autonomous-system 64520 set system host-name CE2
PE1 (DUT)
set interfaces ge-0/0/0 unit 0 description "Link from PE1 to CE1" set interfaces ge-0/0/0 unit 0 family inet address 172.16.1.2/30 set interfaces ge-0/0/1 unit 0 description "Link from PE1 to P1" set interfaces ge-0/0/1 unit 0 family inet address 10.1.23.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 description "Link from PE1 to P2" set interfaces ge-0/0/2 unit 0 family inet address 10.1.24.1/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 description "Link from PE1 to P3" set interfaces ge-0/0/3 unit 0 family inet address 10.1.25.1/24 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set routing-instances CE1_L3vpn instance-type vrf set routing-instances CE1_L3vpn protocols bgp group CE1 type external set routing-instances CE1_L3vpn protocols bgp group CE1 peer-as 64510 set routing-instances CE1_L3vpn protocols bgp group CE1 neighbor 172.16.1.1 set routing-instances CE1_L3vpn interface ge-0/0/0.0 set routing-instances CE1_L3vpn route-distinguisher 192.168.0.1:12 set routing-instances CE1_L3vpn vrf-target target:65412:12 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.1 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.2 set protocols mpls icmp-tunneling set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path lsp_to_pe2 primary best-effort set protocols mpls label-switched-path gold_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path gold_lsp_to_pe2 preference 5 set protocols mpls label-switched-path gold_lsp_to_pe2 primary gold set protocols mpls label-switched-path gold_lsp_to_pe2 transport-class gold set protocols mpls label-switched-path bronze_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path bronze_lsp_to_pe2 preference 5 set protocols mpls label-switched-path bronze_lsp_to_pe2 primary bronze set protocols mpls label-switched-path bronze_lsp_to_pe2 transport-class bronze set protocols mpls path gold 10.1.23.2 strict set protocols mpls path bronze 10.1.24.2 strict set protocols mpls path best-effort 10.1.25.2 strict set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set protocols rsvp interface ge-0/0/3.0 set routing-options route-distinguisher-id 192.168.0.1 set routing-options resolution preserve-nexthop-hierarchy set routing-options router-id 192.168.0.1 set routing-options autonomous-system 65412 set routing-options transport-class name gold color 100 set routing-options transport-class name bronze color 200 set system host-name PE1
PE2
set interfaces ge-0/0/0 unit 0 description "Link from PE2 to P1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.36.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from PE2 to P2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.46.2/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 description "Link from PE2 to P3" set interfaces ge-0/0/2 unit 0 family inet address 10.1.56.2/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 description "Link from PE2 to CE2" set interfaces ge-0/0/3 unit 0 family inet address 172.16.2.2/30 set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set routing-instances CE2_L3vpn instance-type vrf set routing-instances CE2_L3vpn protocols bgp group CE2 type external set routing-instances CE2_L3vpn protocols bgp group CE2 peer-as 64520 set routing-instances CE2_L3vpn protocols bgp group CE2 neighbor 172.16.2.1 set routing-instances CE2_L3vpn interface ge-0/0/3.0 set routing-instances CE2_L3vpn route-distinguisher 192.168.0.2:12 set routing-instances CE2_L3vpn vrf-target target:65412:12 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.2 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.1 set protocols mpls icmp-tunneling set protocols mpls label-switched-path lsp_to_pe1 to 192.168.0.1 set protocols mpls label-switched-path gold_lsp_to_pe1 to 192.168.0.1 set protocols mpls label-switched-path gold_lsp_to_pe1 transport-class gold set protocols mpls label-switched-path gold_lsp_to_pe1 preference 5 set protocols mpls label-switched-path bronze_lsp_to_pe1 to 192.168.0.1 set protocols mpls label-switched-path bronze_lsp_to_pe1 transport-class bronze set protocols mpls label-switched-path bronze_lsp_to_pe1 preference 5 set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set routing-options route-distinguisher-id 192.168.0.2 set routing-options router-id 192.168.0.2 set routing-options autonomous-system 65412 set routing-options transport-class name gold color 100 set routing-options transport-class name bronze color 200 set system host-name PE2
P1
set interfaces ge-0/0/0 unit 0 description "Link from P1 to PE1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.23.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from P1 to PE2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.36.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.11/32 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set routing-options router-id 192.168.0.11 set system host-name P1
P2
set interfaces ge-0/0/0 unit 0 description "Link from P2 to PE1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.24.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from P2 to PE2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.46.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.12/32 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set routing-options router-id 192.168.0.12 set system host-name P2
P3
set interfaces ge-0/0/0 unit 0 description "Link from P3 to PE1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.25.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from P3 to PE2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.56.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.13/32 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set routing-options router-id 192.168.0.13 set system host-name P3
Apéndice 3: Mostrar salida de configuración en PE1
La configuración completa de PE1 en formato de llave
user@PE1# show | no-more
system {
host-name PE1;
}
interfaces {
ge-0/0/0 {
unit 0 {
description "Link from PE1 to CE1";
family inet {
address 172.16.1.2/30;
}
}
}
ge-0/0/1 {
unit 0 {
description "Link from PE1 to P1";
family inet {
address 10.1.23.1/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
description "Link from PE1 to P2";
family inet {
address 10.1.24.1/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
description "Link from PE1 to P3";
family inet {
address 10.1.25.1/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
}
routing-instances {
CE1_L3vpn {
instance-type vrf;
protocols {
bgp {
group CE1 {
type external;
peer-as 64510;
neighbor 172.16.1.1;
}
}
}
interface ge-0/0/0.0;
route-distinguisher 192.168.0.1:12;
vrf-target target:65412:12;
}
}
routing-options {
route-distinguisher-id 192.168.0.1;
resolution {
preserve-nexthop-hierarchy;
}
router-id 192.168.0.1;
autonomous-system 65412;
transport-class {
name gold {
color 100;
}
name bronze {
color 200;
}
}
}
protocols {
bgp {
group ibgp {
type internal;
local-address 192.168.0.1;
family inet {
unicast;
}
family inet-vpn {
unicast;
}
neighbor 192.168.0.2;
}
}
mpls {
label-switched-path lsp_to_pe2 {
to 192.168.0.2;
primary best-effort;
}
label-switched-path gold_lsp_to_pe2 {
to 192.168.0.2;
preference 5;
primary gold;
transport-class gold;
}
label-switched-path bronze_lsp_to_pe2 {
to 192.168.0.2;
preference 5;
primary bronze;
transport-class bronze;
}
path gold {
10.1.23.2 strict;
}
path bronze {
10.1.24.2 strict;
10.1.66.6 strict;
}
path best-effort {
10.1.25.2 strict;
}
icmp-tunneling;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
}
}
rsvp {
interface lo0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
}
}Descripción general del transporte con clase BGP (BGP-CT) con túneles SR-TE de colores subyacentes
Beneficios de BGP-CT con túneles SR-TE de colores subyacentes
- Resuelve problemas de escala que puedan surgir en el futuro a medida que la red crece.
- Proporciona interconectividad para dominios que usan diferentes tecnologías.
- Desacopla los servicios y las capas de transporte, lo que resulta en una red completamente distribuida.
- Proporciona administración independiente del ancho de banda mediante un controlador de ingeniería de tráfico dentro del dominio para SR-TE.
Las grandes redes que crecen y evolucionan continuamente requieren una arquitectura de enrutamiento de segmentos sin fisuras. A partir de Junos OS versión 21.2,R1, admitimos BGP-CT con transporte subyacente como túneles SR-TE de colores. BGP-CT puede resolver rutas de servicio utilizando las RIB de transporte y calcular el siguiente salto. Los servicios que actualmente son compatibles con BGP-CT también pueden usar los túneles de color SR-TE subyacentes para la resolución de rutas. Los servicios ahora pueden usar los túneles de color SR-TE subyacentes, como los túneles de color estáticos, BGP SR-TE, RPD programable y PCEP. BGP-CT utiliza la accesibilidad del salto siguiente para resolver rutas de servicio en la clase de transporte deseada.
Para habilitar la resolución de ruta del servicio BGP-CT sobre túneles de color SR-TE subyacentes, incluya la use-transport-class instrucción en el nivel de [edit protocols source-packet-routing] jerarquía.
- Habilitar la
use-transport-classinstrucciónen el
junto con la[edit protocols source-packet-routing]nivel jerárquico.auto-createinstrucción en el[edit routing-options transport-class]nivel jerárquico. - No se admiten grupos RIB para túneles SR-TE de color con
use-transport-classtúneles SR-TE de solo color con esta característica.
Consulte también
Descripción general de la asignación basada en colores de los servicios VPN
Puede especificar el color como una restricción de protocolo del próximo salto (además de la dirección IPv4 o IPv6) para resolver túneles de transporte sobre LSP de enrutamiento de segmentos BGP (SR-TE) y de color estático. Esto se denomina resolución de próximo salto del protocolo de IP de color, donde debe configurar un mapa de resolución y aplicarlo a los servicios VPN. Con esta función, puede habilitar la dirección de tráfico basada en color de los servicios VPN de capa 2 y capa 3.
Junos OS admite LSP SR-TE de color asociados a un solo color. La función de asignación basada en colores de los servicios VPN es compatible con LSP de colores estáticos y LSP SR-TE BGP.
- Coloración del servicio VPN
- Especificación del modo de asignación de servicios VPN
- Resolución de próximo salto del protocolo Color-IP
- Respaldo a la resolución del protocolo IP del próximo salto
- Mapeo basado en color de unidifusión etiquetado con BGP sobre la base SR-TE e IS-IS
- Funciones admitidas y no compatibles para la asignación basada en colores de servicios VPN
Coloración del servicio VPN
En general, a un servicio VPN se le puede asignar un color en el enrutador de salida donde se anuncia la NLRI VPN, o en un enrutador de entrada donde se recibe y procesa la NLRI VPN.
Puede asignar un color a los servicios VPN en diferentes niveles:
-
Por instancia de enrutamiento.
-
Por grupo BGP.
-
Por vecino de BGP.
-
Por prefijo.
-
Conjunto de prefijos.
Una vez que asigna un color, el color se adjunta a un servicio VPN en forma de comunidad extendida de color BGP.
Puede asignar varios colores a un servicio VPN, denominados servicios VPN multicolor. En tales casos, el valor de color más pequeño se considera el color del servicio VPN y se ignoran todos los demás colores.
Los dispositivos de salida o entrada asignan varios colores a través de varias políticas en el siguiente orden:
-
Política de exportación de BGP en el dispositivo de salida.
-
Política de importación de BGP en el dispositivo de entrada.
-
Política de importación de VRF en el dispositivo de entrada.
Los dos modos de coloración del servicio VPN son:
Asignación de color de salida
En este modo, el dispositivo de salida (es decir, el anunciante de la NLRI VPN) es responsable de colorear el servicio VPN. Para habilitar este modo, puede definir una política de enrutamiento y aplicarla en la instancia de enrutamiento vrf-export, exportación de grupo o exportación de vecino de grupo del servicio VPN en el nivel jerárquico [editar protocolos bgp]. BGP anuncia la NLRI VPN con la comunidad extendida de color especificada.
Por ejemplo:
[edit policy-options]
community red-comm {
members color:0:50;
}[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}[edit routing-instances]
vpn-X {
...
vrf-export pol-color ...;
}O
Cuando aplique la directiva de enrutamiento como una política de exportación de un grupo BGP o vecino de BGP, debe incluir la vpn-apply-export instrucción en el nivel de BGP, grupo BGP o vecino de BGP para que la directiva surta efecto en la NLRI VPN.
[edit protocols bgp]
group PEs {
...
neighbor PE-A {
export pol-color ...;
vpn-apply-export;
}
}Las políticas de enrutamiento se aplican a los NLRI de prefijo VPN de capa 3, NRLI de VPN de capa 2 y NLRI de EVPN. Todas las rutas VPN heredan la comunidad extendida por color, se importan y se instalan en los VRF de destino en uno o varios dispositivos de entrada.
Asignación de color de entrada
En este modo, el dispositivo de entrada (es decir, el receptor de la NLRI VPN) es responsable de colorear el servicio VPN. Para habilitar este modo, puede definir una política de enrutamiento y aplicarla a la instancia vrf-import de enrutamiento, la importación de grupo o la importación de vecinos de grupo del servicio VPN en el nivel jerárquico [edit protocols bgp] . Todas las rutas VPN que coincidan con la política de enrutamiento se adjuntan a la comunidad extendida de color especificada.
Por ejemplo:
[edit policy-options]
community red-comm {
members color:0:50;
}[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}[edit routing-instances]
vpn-Y {
...
vrf-import pol-color ...;
}O
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-color ...;
}
}Especificación del modo de asignación de servicios VPN
Para especificar modos de asignación de servicios VPN flexibles, debe definir una política mediante la instrucción resolution-map y hacer referencia a la política en la instancia de enrutamiento vrf-import, group import o group neighbor import de un servicio VPN en el nivel jerárquico [edit protocols bgp]. Todas las rutas VPN que coincidan con la política de enrutamiento se adjuntan con el mapa de resolución especificado.
Por ejemplo:
[edit policy-options]
resolution-map map-A {
<mode-1>;
<mode-2>;
...
}
policy-statement pol-resolution {
term t1 {
from {
[any match conditions];
}
then {
resolution-map map-A;
accept;
}
}
}Puede aplicar la política de importación a la instancia de enrutamiento del servicio VPN.
[edit routing-instances]
vpn-Y {
...
vrf-import pol-resolution ...;
}También puede aplicar la directiva de importación a un grupo BGP o vecino de BGP.
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-resolution ...;
}
}Cada modo de asignación de servicios VPN debe tener un nombre único definido en el mapa de resolución. Solo se admite una entrada de color IP en el mapa de resolución, donde las rutas VPN se resuelven utilizando un siguiente salto del protocolo IP coloreado en forma de dirección IP: color sobre las tablas de enrutamiento inetcolor.0 e inet6color.0.
Resolución de próximo salto del protocolo Color-IP
El proceso de resolución del protocolo del siguiente salto se ha mejorado para admitir la resolución del siguiente salto del protocolo IP de color. Para un servicio VPN coloreado, el proceso de resolución del protocolo del siguiente salto toma un color y un mapa de resolución, crea un siguiente salto del protocolo IP coloreado en forma de , y resuelve el siguiente salto del protocolo en las tablas de ip-address:colorenrutamiento inetcolor.0 e inet6color.0.
Debe configurar una política para admitir la resolución de múltiples rutas de servicios VPN de capa 2, VPN de capa 3 o EVPN de color sobre LSP de color. A continuación, la política debe aplicarse con la tabla RIB relevante como política de importación del solucionador.
Por ejemplo:
[edit policy-options]
policy-statement mpath {
then multipath-resolve;
}[edit routing-options]
resolution {
rib bgp.l3vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.l3vpn-inet6.0 {
inet6color-import mpath;
}
}
resolution {
rib bgp.l2vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib mpls.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.evpn.0 {
inetcolor-import mpath;
}
}Respaldo a la resolución del protocolo IP del próximo salto
Si un servicio VPN de color no tiene un mapa de resolución aplicado, el servicio VPN ignora su color y recurre a la resolución del protocolo IP del próximo salto. Por el contrario, si a un servicio VPN no coloreado se le aplica un mapa de resolución, el mapa de resolución se ignora y el servicio VPN utiliza la resolución del próximo salto del protocolo IP.
La reserva es un proceso sencillo que va desde los LSP SR-TE coloreados hasta los LSP LDP, mediante el uso de un grupo RIB para que LDP instale rutas en tablas de enrutamiento inet{6}color.0. Una coincidencia de prefijo más larga para el próximo salto de un protocolo IP de color garantiza que si no existe una ruta LSP SR-TE de color, se debe devolver una ruta LDP con una dirección IP coincidente.
Mapeo basado en color de unidifusión etiquetado con BGP sobre la base SR-TE e IS-IS
A partir de Junos OS versión 20.2R1, la unidifusión etiquetada como BGP (BGP-LU) puede resolver rutas IPv4 o IPv6 mediante ingeniería de tráfico de enrutamiento de segmentos (SR-TE) con base IS-IS para las familias de direcciones IPv4 e IPv6. BGP-LU admite la asignación de un color de comunidad BGP y la definición de a resolution map para SR-TE. Se construye un protocolo de color del siguiente salto y se resuelve en un túnel SR-TE de color en la inetcolor.0 tabla o inet6color.0 . Por lo tanto, BGP-LU resuelve el siguiente salto del protocolo sobre túneles SR-TE para el transporte de paquetes. BGP utiliza inet.3 y inet6.3 tablas para mapeo no basado en color.
Funciones admitidas y no compatibles para la asignación basada en colores de servicios VPN
Las siguientes características y funcionalidades son compatibles con la asignación basada en colores de los servicios VPN:
-
VPN BGP de capa 3
-
VPN BGP capa 2 (Kompella capa 2 VPN)
-
BGP EVPN
-
Mapa de resolución con una sola opción de color IP.
-
Resolución coloreada del próximo salto de los protocolos IPv4 e IPv6.
-
Base de información de enrutamiento (también conocida como tabla de enrutamiento) reserva basada en grupos a LDP LSP en tablas de enrutamiento inetcolor.0 o inet6color.0.
-
Coloreado SR-TE LSP.
-
Plataformas virtuales.
-
Junos OS de 64 bits.
-
Sistemas lógicos.
-
BGP etiquetado como unidifusión
Las siguientes características y funcionalidades no son compatibles con la asignación basada en colores de los servicios VPN:
-
LSP MPLS de color, como RSVP, LDP, BGP-LU, estáticos.
-
Circuito de capa 2
-
VPN de capa 2 con detección automática de BGP FEC-129 y señalizada por LDP.
-
VPLS
-
MVPN
-
IPv4 e IPv6 mediante resolution-map.