Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

  • 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.

Figura 1: Dominio intra-AS: Escenarios antes y después para la implementación de planos de transporte con clase BGPDominio intra-AS: Escenarios antes y después para la implementación de planos de transporte con clase BGPDominio intra-AS: Escenarios antes y después para la implementación de planos de transporte con clase BGP

Para clasificar túneles de transporte en clase de transporte BGP en una configuración intraAS:

  1. 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:

  2. 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:

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:

  1. 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:

  2. 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

    Para el algoritmo FLXIBLE IS-IS

  3. 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:

  4. Anuncie las rutas de servicio desde el dispositivo de PE de salida con la comunidad de color extendida adecuada.

    Configuración de ejemplo:

Funcionalidad de plano de transporte con clase de InterAS BGP:

  1. 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.
  2. 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.

  3. 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.
  4. 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.
  5. 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.
  6. 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).
  7. Los nodos fronterizos utilizan esquemas de resolución predefinidos para la resolución de PNH de rutas de transporte.
  8. 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.
  9. 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.

Nota:
  1. Habilitar la use-transport-class instrucción

    en el [edit protocols source-packet-routing] nivel jerárquico.

    junto con la auto-create instrucción en el [edit routing-options transport-class] nivel jerárquico.
  2. No se admiten grupos RIB para túneles SR-TE de color con use-transport-class tú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

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.

Tabla 1: Descripción funcional de los planos de transporte con clase

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:

  • Oro

  • Bronce

  • Mejor esfuerzo

    Esta es la clase de transporte predeterminada. Esta clase proporciona un servicio de nivel de mejor esfuerzo (BE). Los clientes que no están asignados a ninguna clase de transporte específica, o aquellos que están asignados a una clase de transporte que está inactiva, utilizan de forma predeterminada la clase de servicio BE y la ruta de LSP asociada.

Familia de servicios

VPN de capa 3 (family inet-vpn unicast

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
  • Confirme el funcionamiento general de la red.
Verifique el funcionamiento de IGP, RSVP, MPLS, BGP y L3VPN.
  • Compruebe la asignación del tráfico de clientes de VPN de capa 3 a una clase de transporte.

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.

Tabla 2: Descripción general de la topología de planos de transporte con clase dentro de dominio
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

Figura 2: Asignación de servicios mediante planos de transporte con clase dentro de un dominio de redAsignación de servicios mediante planos de transporte con clase dentro de un dominio de red

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

Nota:

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.

  1. Primero, aprovisione la VPN general de capa 3:

    1. 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 mpls conmutación MPLS.

    2. Configure un número de sistema autónomo.

    3. Configure OSPF de área única en las interfaces de circuito cerrado y núcleo.

    4. Configure RSVP en las interfaces de circuito cerrado y núcleo.

    5. Configure la sesión de emparejamiento del IBGP con el dispositivo de PE remoto, PE2. Incluya la familia de inet-vpn direcciones para admitir una VPN IPv4 de capa 3.

    6. Configure una instancia de enrutamiento basada en VRF para el dispositivo CE1. Utilice EBGP como protocolo de enrutamiento PE-CE.

  2. 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.

  3. 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.

  4. 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:

  5. 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.

Verificar planos de transporte con clase

Nota:

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.

Tabla 3: Comandos de verificación de planos de transporte con clase
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

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.

Significado

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.3 por gold_lsp_to_pe2

  • junos-rti-tc-200.inet.3 por bronze_lsp_to_pe2

  • inet.3 por 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.

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).

Nota:

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.

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.

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

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.

Desde el modo operativo en PE1, introduzca el show mpls lsp statistics comando.

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.

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.

Una vez que se confirma el cambio, el túnel de bronce se muestra hacia abajo:

Repita los ping comandos y trace route de CE1 al loopback de CE2.

Vuelva a mostrar las estadísticas MPLS en PE1.

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.

Nota:

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.

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.

Nota:

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.

Tabla 4: Pasos para la solución de problemas
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 traffic-engieering instrucción. Si IS-IS se utiliza como IGP, esta declaración no es necesaria.

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 show mpls lsp comandos y show rsvp session .

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 inet-vpn unicast familia. Utilice el comando para confirmar la show route recepción de la ruta CE remota en el PE local. Use el interruptor para confirmar el detail archivo adjunto adecuado de la comunidad de colores.

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/0

Los 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_pe2

Confirme 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

CE2

PE1 (DUT)

PE2

P1

P2

P3

Apéndice 3: Mostrar salida de configuración en PE1

La configuración completa de PE1 en formato de llave

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.

Nota:
  1. Habilitar la use-transport-class instrucción

    en el [edit protocols source-packet-routing] nivel jerárquico.

    junto con la auto-create instrucción en el [edit routing-options transport-class] nivel jerárquico.
  2. No se admiten grupos RIB para túneles SR-TE de color con use-transport-class túneles SR-TE de solo color con esta característica.

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

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:

O

Nota:

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.

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:

O

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:

Puede aplicar la política de importación a la instancia de enrutamiento del servicio VPN.

También puede aplicar la directiva de importación a un grupo BGP o vecino de BGP.

Nota:

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:

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.