Configuración de ingeniería de tráfico basada en colores
SUMMARY
Descripción general de los planos de transporte 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 clase BGP
- Implementación del intraAS de los planos de transporte con clase del BGP
- Implementación del interAS de los planos de transporte de clase del BGP
- Descripción general del transporte de clase BGP (BGP-CT) con túneles de SR-TE de color subyacentes
- Beneficios del BGP-CT con túneles de SR-TE de color subyacentes
Beneficios de los aviones de transporte con clase BGP
-
División de red: las capas de servicio y transporte se desacoplan entre sí, sentando las bases para la segmentación y la virtualización de red con la división de extremo a extremo en varios dominios, lo que reduce significativamente el CAPEX.
- Interoperabilidad entre dominios: extiende la implementación de clase de transporte a todos los dominios cooperativos, de modo que los diferentes protocolos de señalización de transporte en cada dominio interoperan. Reconcilia cualquier diferencia entre los espacios de nombres de comunidad extendidos que pueden estar en uso en cada dominio.
-
Resolución colorada con reserva: permite la resolución sobre túneles de color (RSVP, algoritmo flexible IS-IS) con opciones de reserva flexibles sobre túneles de mejor esfuerzo o cualquier otro túnel de color.
- Calidad del servicio: personaliza y optimiza la red para cumplir con los requisitos de SLA de extremo a extremo.
- Aprovechar las implementaciones existentes: admite protocolos de tunelización bien implementados, como RSVP, junto con protocolos nuevos, como el algoritmo flexible IS-IS, que preserva el retorno de la inversión y reduce la OPEX.
Terminología de los planos de transporte con clase BGP
En esta sección, se proporciona un resumen de los términos utilizados comúnmente para comprender el plano de transporte de clase del BGP.
-
Nodo de servicio: dispositivos de borde 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 (LU) del BGP.
-
BGP-VPN-VPN creadas con mecanismos RFC4364.
-
Destino de ruta (RT): tipo de comunidad extendida que se utiliza para definir la membresía de VPN.
-
Distinguidor de ruta (RD): identificador que se utiliza para distinguir a qué VPN o servicio LAN privada virtual (VPLS) pertenece una ruta. Cada instancia de enrutamiento debe tener un distinguidor de ruta único asociado con ella.
- Esquema de resolución: se utiliza para resolver la dirección del próximo salto de protocolo (PNH) en las RI de resolución que proporcionan reserva.
Asignan las rutas a las diferentes RB de transporte en el sistema según la comunidad de mapeo.
-
Familia de servicios: familia de direcciones BGP que se utiliza para anunciar rutas de tráfico de datos, en lugar de túneles.
-
Familia de transporte : familia de direcciones BGP utilizada para túneles de publicidad, que a su vez son utilizados por las rutas de servicio para la resolución.
-
Túnel de transporte: un 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: un grupo de túneles de transporte que ofrecen el mismo tipo de servicio.
RT de la clase de transporte: un nuevo formato de destino de ruta utilizado para identificar una clase de transporte específica.
Se utiliza un nuevo formato de destino de ruta 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 un RIB de transporte asociado que mantiene sus rutas de túnel.
-
Instancia de enrutamiento RTI-A de transporte; contenedor de transporte RIB, y el distinguidor de ruta y destino de ruta de la clase de transporte asociado.
-
Plano de transporte: conjunto de RT de transporte que importan la misma clase de transporte RT. Estas, a su vez, se unen para abarcar los límites de los dominios de túnel mediante un mecanismo similar a la opción b del interAS para intercambiar etiquetas en 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 sobre una clase de transporte.
Descripción de los planos de transporte clase BGP
Puede usar planos de transporte con clases del BGP para configurar clases de transporte para clasificar un conjunto de túneles de transporte en una red de intraAS según 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 clases del BGP pueden extender estos túneles a redes entre dominios que abarcan varios dominios (AS o áreas IGP) a la vez que conservan la clase de transporte. Para ello, debe configurar la familia BGP de transporte de transporte con clase BGP entre los nodos de borde y de servicio.
En las implementaciones tanto de interAS como de intraAS, puede haber muchos túneles de transporte (LSP MPLS, algoritmo flexible IS-IS, SR-TE) creados a partir de los nodos de borde y servicio. Los LSP se pueden señalizar mediante diferentes protocolos de señalización en distintos dominios y configurarse con diferentes características de ingeniería de tráfico (clase o color). El punto de conexión del túnel de transporte también actúa como el punto de conexión 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 usar planos de transporte de clase BGP para resove servicios a través de LSP con determinadas características de ingeniería de tráfico, ya sea dentro de un solo dominio o en varios dominios.
Los planos de transporte por clase BGP reutilizan la tecnología BGP-VPN, lo que mantiene los dominios de tunelización libremente acoplados y coordinados.
- La información de accesibilidad de la capa de red (NLRI) es RD:TunnelEndpoint usado para ocultar rutas.
- El destino de ruta indica la clase de transporte de los LSP y fuga rutas al 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 un destino de ruta VPN y recopila los LSP de la misma clase de transporte en la tabla de enrutamiento transport-rib transport-class.inet.3.
-
Las rutas en esta instancia de enrutamiento se anuncian en el plano de transporte de clase BGP (transporte inet) AFI-SAFI siguiendo procedimientos similares a los del RFC-4364.
-
Cuando cruce el límite del vínculo del interAS, debe seguir los procedimientos option-b para unir los túneles de transporte en estos dominios adyacentes.
De manera similar, al cruzar regiones de intraAS, debe seguir los procedimientos de opción b para unir los túneles de transporte en los distintos dominios de TE.
-
Puede definir esquemas de resolución para especificar la intención en la variedad de clases de transporte en un orden de reserva.
- Puede resolver rutas de servicio y rutas de transporte de clase BGP a través de estas clases de transporte, mediante la creación de la comunidad de mapeo en ellas.
La familia de transporte con clases BGP corre junto con la familia de capas de transporte BGP-LU. En una red MPLS sin problemas que ejecuta BGP-LU, cumplir con los estrictos requisitos de SLA de la 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 clases del BGP ofrecen medios operacionalmente fáciles y escalables para anunciar varias rutas para circuito cerrado remoto junto con la información de clase de transporte en la arquitectura MPLS sin problemas. En las rutas de la familia de tranportes con clases del BGP, se representan diferentes rutas de SLA mediante la comunidad extendida de objetivo de ruta de transporte, que lleva el color de la clase de transporte. Los enrutadores BGP receptores utilizan este objetivo de ruta de transporte para asociar la ruta de transporte con clase del BGP con la clase de transporte adecuada. Al volver a anunciar las rutas de transporte de clase del BGP, MPLS intercambia rutas, interconecta los túneles de intraAS de la misma clase de transporte, formando así un túnel de extremo a extremo que conserva la clase de transporte.
Implementación del intraAS de los planos de transporte con clase del BGP
Figura 1 muestra una topología de red con escenarios de antes y después de implementar planos de transporte de clase BGP en un dominio de intraAS. Los dispositivos PE11 y PE12 utilizan LSP RSVP como túnel de transporte y todas las rutas de túnel de transporte se instalan en RIB inet.3. La implementación de planos de transote de clase BGP permite que los túneles de transporte RSVP sean conscientes del color, de manera similar a los túneles de enrutamiento por segmentos.
Para clasificar los túneles de transporte en clase de transporte BGP en una configuración de 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 color 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 de plano de transporte de clase del BGP del Intra-AS:
- El transporte por clase del BGP crea RB de transporte predefinidos 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 de intraAS se completan en las RÍ de transporte mediante el protocolo de tunelización cuando se asocia con una clase de transporte.
En este ejemplo, las rutas LSP RSVP asociadas con la clase de transporte oro (color 100) y la clase de transporte bronce (color 200) se instalan en las RB de transporte junos-rti-tc-<100>.inet.3 y junos-rti-tc-<200>.inet.3, respectivamente.
- El nodo de servicio (PEs de entrada) coincide con la comunidad de color extendida (color:0:100 y color:0:200) de la ruta de servicio con la comunidad de asignación en RI de resolución predefinida y resuelve el salto siguiente del protocolo (PNH) en las RB de transporte correspondientes (ya sea junos-rti-tc-<100>.inet.3, o junos-rti-tc-<200>.inet.3).
- Las rutas del BGP se vinculan a un esquema de resolución mediante el transporte de la comunidad de mapeo unido.
- 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 utilizan Transport-Target:0:<val> como comunidad de mapeo.
- Si la PNH de la ruta de servicio no se puede resolver mediante las RIB enumeradas en el esquema de resolución predefinido, puede volver a la tabla de enrutamiento inet.3.
- También puede configurar la reserva entre RÍA de transporte de diferentes colores mediante el uso de esquemas de resolución definidos por el usuario en la [edit routing-options resolution scheme] jerarquía de configuración.
Implementación del interAS de los planos de transporte de clase del BGP
En una red de interAS, el BGP-LU se convierte en red de transporte de 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 de 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 (PEs de entrada, ABR y ASBR).
Configuración de ejemplo:
Para LSP de RSVP
abr23# show protocols mpls label-switched-path toASBR21-bronze { transport-class bronze; } label-switched-path toASBR22-gold { transport-class gold;Para algoritmos flxibles 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 de clases BGP (transporte de inet) y BGP-LU (inet labeled-unicast) 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 rutas de servicio desde el dispositivo PE de salida con una comunidad de colores 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 de clase del BGP del interAS:
- Los planos de transporte con clases del BGP crean RIB de transporte predefinidos por clase de transporte con nombre (oro y bronce) y derivan automáticamente la comunidad de mapeo a partir de su valor de color.
-
Las rutas de transporte de intraAS se completan en las RÍ 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 gold y bronze se instalan en las RB de transporte junos-rti-tc-<100>.inet.3 y junos-rti-tc-<200>.inet.3, respectivamente.
- Los planos de transporte con clases del BGP usan el distinguidor de ruta y el destino de ruta únicos cuando copian las rutas de túnel de transporte de cada RIB de transporte a la tabla de enrutamiento bgp.transport.3.
- Los nodos de borde anuncian rutas de la tabla de enrutamiento bgp.transport.3 a sus pares en otros dominios si el transporte de inet de familia se negocia en la sesión del 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 la ruta de transporte a las RB de transporte adecuadas.
- El nodo de servicio hace coincidir la comunidad de color de la ruta de servicio con una comunidad de mapeo en los esquemas de resolución y resuelve el PNH en el RIB de transporte correspondiente (ya sea junos-rti-tc-<100>.inet.3, o junos-rti-tc-<200>.inet.3).
- Los nodos de borde usan esquemas de resolución predefinidos para la resolución PNH de la ruta de transporte.
- Ambos esquemas de resolución, predefinidos o definidos por el usuario, admiten la resolución PNH de ruta de servicio. La predefinida usa inet.3 como reserva, y el esquema de resolución definido por el usuario permite usar una lista de RI de transporte en el orden especificado al resolver PNH.
- Si la PNH de la ruta de servicio no se puede resolver mediante LAS RIB enumeradas en el esquema de resolución definido por el usuario, la ruta se descarta.
Descripción general del transporte de clase BGP (BGP-CT) con túneles de SR-TE de color subyacentes
Beneficios del BGP-CT con túneles de SR-TE de color subyacentes
- Resuelve las preocupaciones de escala que pueden surgir en el futuro a medida que la red crece.
- Proporciona interconectividad para dominios que utilizan diferentes tecnologías.
- Desvincula los servicios y las capas de transporte, lo que da como resultado una red completamente distribuida.
- Ofrece administración independiente del ancho de banda a través de un controlador de ingeniería de tráfico intradominio para SR-TE.
Las grandes redes que crecen y evolucionan continuamente requieren una arquitectura de enrutamiento por segmentos sin problemas. A partir de Junos OS versión 21.2,R1, somos compatibles con BGP-CT con transporte subyacente como túneles DE SR-TE coloreados. El BGP-CT puede resolver rutas de servicio mediante las RI 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. Ahora, los servicios pueden usar los túneles de color sr-TE subyacentes, como los túneles de color estático, SR-TE BGP, rpd programable y PCEP de color. El BGP-CT utiliza la accesibilidad del salto siguiente para resolver rutas de servicio a través de la clase de transporte deseada.
Para habilitar la resolución de rutas de servicio BGP-CT sobre túneles de color SR-TE subyacentes, incluya la use-transport-class instrucción en el [edit protocols source-packet-routing] nivel de jerarquía.
- Habilitar la
use-transport-classinstrucciónen el
junto con la[edit protocols source-packet-routing]nivel de jerarquía.auto-createinstrucción en el[edit routing-options transport-class]nivel de jerarquía. - No admitemos grupos RIB para SR-TE de color con
use-transport-classtúneles SR-TE de color y solo color con esta función.
Ejemplo: Configuración de planos de transporte de clase (intradominio)
- Antes de empezar
- Descripción general funcional
- Descripción general de la topología
- Ilustraciones de topología
- Pasos de configuración de PE1
- Verificar los planos de transporte con clase
- Apéndice 1: Solución de problemas
- Apéndice 2: Configurar comandos en todos los dispositivos
- Apéndice 3: Mostrar la 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 de borde del proveedor (PE1 y PE2) requieren compatibilidad con la versión de Junos OS para la función BGP-CT. |
|
Tiempo de lectura estimado |
45 minutos |
|
Tiempo estimado de configuración |
1 hora |
|
¿Qué esperar? |
Una red de BGP-CT en funcionamiento con tres niveles de servicio que se asignan a rutas LSP enrutadas diversamente. 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 básica de LSP 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 función de transporte con clases del BGP (BGP-CT) dentro de una única red autónoma (intradominio). El BGP-CT asigna las rutas de los clientes a rutas de red que se pueden diseñar para ofrecer distintos niveles de rendimiento. Un caso de uso típico para el BGP-CT dentro del dominio es que un proveedor de servicios implemente el BGP-CT para ofrecer niveles de servicio vpn por niveles a sus clientes. |
|
Recursos útiles: |
|
|
Más información |
Para comprender mejor el BGP-CT, consulte Descripción general de los planos de transporte con clase del BGP |
|
Juniper vLabs |
Visite los laboratorios virtuales de Juniper (vLabs) para reservar un sandbox preconfigurado. Utilice el espacio de pruebas para interactuar con la función BGP-CT y comprenderla. Encontrará la demostración "Planos de transporte con clase (escenario de intradominio)" en la sección de enrutamiento. |
|
Más información |
Clase de servicio de Junos (JCOS) a pedido |
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 único dominio de enrutamiento de OSPF ofrece conectividad de circuito cerrado en la red del proveedor. |
|
BGP interno y externo |
Los dispositivos de borde del cliente (CE) usan el emparejamiento de EBGP para intercambiar rutas con el dispositivo de borde de su proveedor como parte de un servicio VPN de capa 3. Los dispositivos PE usan IBGP para intercambiar rutas VPN de capa 3 IPv4 con el PE remoto. Estas rutas también llevan una comunidad de colores utilizada para asignar tráfico al túnel de plano de datos correcto. Nuestro ejemplo no usa un reflector de ruta, sino que opta por el emparejamiento directo PE-PE. Nota:
El enrutador del proveedor (enrutador P) no ejecuta BGP. Es parte de un núcleo sin BGP para promover el escalamiento. El dispositivo P usa una conmutación basada en etiquetas MPLS para transportar el tráfico VPN del cliente entre los dispositivos PE. |
|
RSVP |
Cada dispositivo de 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 una ingeniería de tráfico enriquecida para forzar el tráfico a las rutas deseadas en la red del proveedor. Estas rutas, a su vez, se pueden diseñar para proporcionar un manejo variado de clase de servicio (CoS) que se necesita para aplicar el SLA para cada clase de transporte. Nuestra topología básica proporciona tres rutas entre los dispositivos de PE. Usamos una ruta designada con una ERO para garantizar el enrutamiento diverso de los LSP en 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 de MPLS Nota:
La función de transporte en clase también se admite con LSP establecidos mediante la ingeniería de tráfico de enrutamiento por segmentos (SR-TE) y 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 de TE garantiza que cada clase de servicio se pueda enrutar a través de rutas inconexas con los niveles de rendimiento deseados. Como se señaló anteriormente, MPLS también ofrece soporte para un núcleo sin BGP. |
| Túneles de transporte | |
|
Se establecen tres túneles MPLS (LSP) entre los dispositivos de PE: |
Cada túnel se asigna a las siguientes clases de transporte:
|
| Familia de servicios | |
|
VPN de capa 3 ( |
El BGP-CT también funciona con otras familias de servicios, como BGP etiquetado como Unicast, Flowspec o VPN de capa 2. |
| Tareas principales de verificación | |
|
Verifique el funcionamiento de IGP, RSVP, MPLS, BGP y L3VPN. |
|
Modifique la red para que el tráfico se dirija entre túneles de clase de transporte para simular la falla de un túnel de servicio y la posterior conmutación por error a la ruta o clase BE. |
Descripción general de la topología
Este ejemplo de configuración se basa en una VPN simple de capa 3 basada en MPLS con dos dispositivos de borde del 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 la conmutación basada en etiquetas. Los dos dispositivos de borde de proveedor (PE) proporcionan un servicio VPN de capa 3 a sus CEs adjuntos. Los PEs usan LSP MPLS señalizadas por RSVP para transportar tráfico VPN a través del núcleo. Consulte Example: Configure a Basic MPLS-Based Layer 3 VPN para obtener información 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 en cómo PE1 usa una comunidad de colores BGP adjunta a las rutas aprendidas de PE2 para mapear el tráfico enviado al CE remoto a través del reenvío de LSP deseados próximos saltos. En nuestro ejemplo, PE1 usa objetos de ruta explícita (ERO) para forzar el enrutamiento de estos LSP a través de diversas rutas. Omitemos este paso en PE2, lo que permite que los LSP se enrutan según el 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 del CE1. Es decir, la ruta al circuito cerrado de CE2 viaja de derecha a izquierda.
En nuestro ejemplo, la clase de servicio gold LSP está limitada a la ruta PE1-P1-PE2. La clase de servicio de 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 usa vínculos de color para representar las tres rutas.
En nuestro ejemplo, agregamos la protocols mpls icmp-tunneling instrucción. Esto es para permitir que los dispositivos CE rastreen 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 la ruta de reenvío esperada como función de la clase de transporte se utiliza.
Tabla 2 describe la función y la funcionalidad de cada dispositivo en el contexto de esta topología. Haga clic en el nombre de cualquier dispositivo para ver su configuración rápida.
| Nombre del dispositivo |
Función |
Función |
| CE1 | Dispositivo CE local (R1). | El EBGP se empareja al enrutador PE1 para anunciar y aprender las direcciones de circuito cerrado 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 de EBGP al enrutador PE2 para anunciar y aprender las direcciones de circuito cerrado del dispositivo CE. Configura y adjunta la comunidad de asignación de colores. |
| PE1 (DUT) | dispositivo pe local (R2). | PE1 asigna las rutas de servicio etiquetadas por color que se originan en CE2 a una clase de transporte (TC) de copatrocinación. PE1 recibe las rutas de las etiquetas de color a través de su sesión de IBGP a PE2. En este ejemplo, PE1 usa restricciones basadas en ERO para forzar el enrutamiento diverso de sus tres LSP sobre el núcleo del proveedor. |
| PE2 | Dispositivo de PE remoto (R6). | PE2 vuelve a anunciar las rutas etiquetadas en color recibidas por CE2 a PE1 mediante el IBGP. Estas rutas usan la inet-vpn familia para admitir servicios VPN de capa 3 con TCs asignados 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 puros 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 más 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 para este ejemplo. El primer paso es común configurar un servicio vpn básico de capa 3. El siguiente conjunto de pasos son específicos para agregar la función BGP-CT a su VPN de capa 3. Ambos dispositivos pe tienen una configuración similar, aquí nos enfocamos en PE1.
-
En primer lugar, aprovisione la VPN general de capa 3:
-
Configure y numerar las interfaces de circuito cerrado, de núcleo y de cara a ce para IPv4. Asegúrese de habilitar la
mplsfamilia en las interfaces de núcleo que se conectan a los dispositivos P para admitir la conmutación MPLS. -
Configure un número de sistema autónomo.
-
Configure el OSPF de un solo área en las interfaces de circuito cerrado y de núcleo.
-
Configure RSVP en las interfaces de circuito cerrado y de núcleo.
-
Configure la sesión de emparejamiento de IBGP en el dispositivo de PE remoto, PE2. Incluya la
inet-vpnfamilia de direcciones 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 de clase a la VPN de capa 3.
Configure las clases de transporte de oro y bronce.
Este es un paso fundamental para configurar la función de transporte de clase. Estas clases de transporte se asignan a LSP señalizadas (y posiblemente diseñadas por tráfico) RSVP que atraviesan el núcleo del proveedor. Las rutas remotas aprendidas de CE2 están etiquetadas con comunidades de color que se asignan a estas clases de transporte y, al hacerlo, al LSP deseado entre los dispositivos de 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 enrutamiento restringido que obliga a cada uno a atravesar un enrutador P diferente. Dos de estos LSP se asignan a las gold clases de transporte y bronze . El LSP dorado se enruta a través de P1, el bronce a P2 y el mejor esfuerzo a través del dispositivo P3.
Una vez asignado a las clases de transporte, el proveedor de servicios puede colocar tráfico de cliente específico, como lo indica una comunidad de color de BGP, en un LSP específico. Con este color a la asignación de LSP, el proveedor de servicios puede ofrecer un servicio por niveles con diferentes SLA.
En nuestro ejemplo, usamos una ERO estricta para garantizar que los tres LSP se enrutan de manera diversa a través de 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 la devolución al túnel predeterminado de clase de servicio (mejor esfuerzo), configuramos los túneles de clase de transporte oro y bronce con una preferencia global menor. En este ejemplo, el valor de preferencia cambia del valor predeterminado 7 a 5. Esto permite el uso del túnel del mejor esfuerzo como reserva 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 al 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 siguiente salto del transporteclasado funcione en PE1, las rutas de los dispositivos ce2 remotos deben etiquetarse 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 la integridad:
-
Hacer coincidir las etiquetas de comunidad de colores agregadas en el CE2 remoto con las definiciones de clase de transporte para las COT de 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 los planos de transporte con clase
En esta sección nos centramos en los comandos que muestran una función de transporte de clase laboral. Véase el Apéndice 1: Solución de problemas para comandos utilizados para verificar la funcionalidad subyacente que necesita la función de transporte de clase.
Utilizará estos comandos para comprobar que el transporte de clases del BGP funciona correctamente.
| Comando |
Tarea de verificación |
| muestra la clase de transporte de enrutamiento | Compruebe las clases de transporte y sus atributos asociados. Esto incluye la comunidad de asignación y la instancia de enrutamiento. |
| muestra el esquema de resolución de ruta | Muestra cómo se resuelven las rutas de clase de servicio a los próximos saltos de LSP. Compruebe las tablas de enrutamiento de resolución para una ruta específica. |
| muestra el bgp del protocolo de recepción de la rutape2-loopback-address | Verifique que las rutas VPN recibidas por PE1 tengan una comunidad de colores BGP adjunta. |
| muestra la ruta y muestra vpn de tabla de reenvío de rutavpn | Verifique la selección del túnel de transporte viendo el nexthop de protocolo (PNH) para las rutas en PE1. |
| muestra las 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. |
- Verificar las clases de transporte y los túneles de transporte
- Verificar los esquemas de resolución del próximo salto
- Verificar la selección del etiquetado de color y del salto siguiente para rutas CE2
- Verificar la conectividad de extremo a extremo
- Confirme la conmutación por error al mejor esfuerzo
Verificar las clases de transporte y los túneles de transporte
Propósito
PE1 y PE2 usan túneles de transporte MPLS señalados por RSVP para admitir un servicio VPN de capa 3 que es capaz de ofrecer niveles de servicio diferenciados. Estas rutas de servicio tienen sus próximos saltos resueltos a un túnel MPLS específico basado en la clase de servicio correspondiente. La clase de servicio se indica mediante la conexión de una comunidad de color BGP a las rutas de cliente de VPN.
En esta parte, confirma que los tres LSP de PE1 están operativos, que están asignados a la clase de transporte correcta y que se enrutan correctamente a través del núcleo del proveedor.
Acción
Desde el modo operativo, ingrese el show route 192.168.0.2 comando.
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 aprendió tres rutas hacia el circuito cerrado de PE2 mediante OSPF. Estas rutas se encuentran en la inet.0 tabla. También tenga en cuenta que los tres LSP se representan como próximos saltos viables para alcanzar PE2. Tenga en cuenta que cada uno de estos LSP se aloja en una tabla de enrutamiento diferente. La parte resaltada de los próximos saltos de 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 de bronce y BE se envía a 10.1.24.2 y 10.1.25.2, respectivamente.
Se crean las RÍ de transporte y los túneles de transporte siguientes.
-
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
Verificar los esquemas de resolución del próximo salto
Propósito
Verifique los esquemas de resolución de rutas de servicio, la comunidad de asignación asociada y cómo se resuelve el siguiente salto en las tablas de enrutamiento que contribuyen.
Acción
Desde el modo operativo, ingrese el show route resolution scheme all comando.
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ándose en las partes IPv4 de la salida, puede ver que la clase de junos-tc-100 (gold) transporte tiene dos esquemas de resolución ( junos-resol-schem-tc-100-v4-service y junos-resol-schem-tc-100-v4-transport - utilizados para las rutas de servicio y transporte, respectivamente.
El esquema de resolución para rutas de servicio gold (junos-resol-schem-tc-100-v4-service) proporciona resolución en las junos-rti-tc-100.inet.3 tablas de enrutamiento y inet.3 (resaltado en la salida de muestra). Enumerar las tablas de resolución de servicio y BE es cómo se produce la reserva cuando la clase de servicio está desactivada. 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 de 7 por defecto), para garantizar que siempre se prefiera la ruta de servicio sobre la reserva de BE.
Verificar la selección del etiquetado de color y del salto siguiente para rutas CE2
Propósito
Confirme que PE2 anuncia la ruta de circuito cerrado para CE2 con una comunidad de color que selecciona la clase de servicio de bronce (color 200).
En nuestro ejemplo, configuramos el dispositivo CE2 para conectar la comunidad de color. PE2 deja esta comunidad en su lugar cuando vuelve a anunciar la ruta a PE1. Esto significa que el cliente vpn puede realizar 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 adjuntar la comunidad de asignación de color deseada a las rutas CE antes de anunciarlas de nuevo a PE1.
Acción
Desde el modo operativo, ingrese el show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail comando.
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
Muestra la entrada de tabla de reenvío para el circuito cerrado CE2 en la instancia de enrutamiento VPN en PE1. Confirme que el siguiente salto del 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 coincide con la ruta de circuito cerrado CE2 se envía a 10.1.24.2 mediante la interfaz ge-0/0/2. Retirada de los ERE utilizados para los LSP, esta interfaz y el salto siguiente se asocian con el LSP y la clase de transporte de bronce. La 299808 etiqueta se utiliza para identificar el VRF de servicio. La etiqueta de transporte RSVP externa es 299872.
Usted confirma 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 destacadas señalan que el LSP de bronce se enruta a través del dispositivo P2 y está asociado con la etiqueta de transporte RSVP indicada (299856) que confirmó anteriormente en la tabla de reenvío de VPN para la dirección de circuito cerrado CE2.
Verificar la conectividad de extremo a extremo
Propósito
Verifique la conectividad de extremo a extremo en el dominio del proveedor haciendo ping entre CE1 y CE2. Usted examina las estadísticas de tráfico de MPLS para proporcionar una confirmación adicional de que se utiliza la clase de transporte de bronce.
Acción
Desde el modo operativo, ingrese el ping comando.
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, ingrese 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
Rastree la ruta desde CE1 hasta el circuito cerrado de CE2. Nuestra configuración incluye la icmp-tunneling instrucción para admitir una ruta de seguimiento basada en ICMP con saltos de 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 valor de la etiqueta externa y del salto siguiente del reenvío confirman que este tráfico se envía en el LSP de clase de servicio de bronce.
Confirme la conmutación por error al mejor esfuerzo
Propósito
Lleve el LSP de transporte de bronce hacia abajo para comprobar que el tráfico enviado a CE2 falla en la ruta BE.
Acción
Ingrese al modo de configuración y especifique un salto siguiente no válido como ERO para el túnel de transporte de bronce. La incapacidad de satisfacer el requisito de ERO hace que el LSP relacionado disminuya.
[edit] user@PE1# set protocols mpls path bronze 10.1.66.6 strict
Una vez comprometido el cambio, el túnel de bronce se muestra 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 de ruta y trace desde CE1 hasta el circuito cerrado 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 msMuestra de nuevo las estadísticas de 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 sigue teniendo éxito, aunque ahora se está haciendo el mejor esfuerzo. En el PE, las estadísticas confirman el uso del túnel de transporte de mejor esfuerzo. La ruta de seguimiento muestra que PE1 ahora se reenvía al salto siguiente 10.1.25.2 a través de PE3. Esto confirma la conmutación por error de una clase de transporte de color a la clase de mejor esfuerzo en caso de falla en el túnel de transporte.
En esta sección, realizamos un error en la clase BE al bajar el LSP asignado a la clase de servicio de bronce. Como alternativa, considere cambiar la política de exportación del EBGP en el dispositivo CE2 para que conecte la comunidad de color dorado (100). Con este enfoque, se espera que el tráfico de ping de CE1 a CE2 tome el LSP dorado en lugar de fallar 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 que funciona, lo que permite que el enfoque se centre en confirmar el funcionamiento del BGP-CT. La función BGP-CT, en un contexto de VPN de capa 3 basada en MPLS, depende de una red con interfaces que funcionen, IGP, RSVP, MPLS y BGP.
Tabla 4 proporciona orientación sobre qué buscar si su solución BGP-CT no funciona como se esperaba. La tabla se estructura de abajo hacia arriba, comenzando con la conectividad de interfaz básica y terminando con el intercambio de rutas del 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 una RID diferente, puede llevar algún tiempo para que las cosas se estabilicen. Cambiar la RID es muy perturbador y no es algo que suceda a menudo. Cuando se está en un entorno de laboratorio, se sugiere que emita el comando del restart routing modo operativo en todos los dispositivos justo después de confirmar el nuevo RID.
| Capa funcional |
Enfoque de verificación |
| Interfaces y direcciones IP | Verifique que todas las interfaces de su topología estén operativas. 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 en funcionamiento.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 tienen todas las adyacencias OSPF esperadas. Utilice los comandos del show ospf interfaces modo operativo y show ospf neighbors y. Muestra las rutas para las direcciones de circuito cerrado del proveedor y confirma 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 de proveedor.En este ejemplo, se usan LSP basados en CSPF. Esto requiere que el OSPF se configure 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. También verifique 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 se enumeran los números de unidad de interfaz correctos para la familia MPLS y para cada protocolo. En este ejemplo, se usa 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 la salida en la dirección de circuito cerrado del dispositivo pe remoto. Compruebe que los ERE y cualquier otra restricción de TE son válidas. Utilice los Nota: Nuestros ejemplos utilizan LSP basados en CSPF. Esto requiere que el IGP admita una base de datos de TE (TED). Si OSPF es el IGP, asegúrese de incluir la instrucción de
traffic-engieering configuración. Alternativamente, 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 |
| BGP | Utilice el show bgp summarycomando en los dispositivos de PE para confirmar que se establecen tanto su sesión de EBGP en el CE como la sesión del IBGP en el PE remoto. Si el BGP está inactivo a pesar de poder hacer ping, sospeche una mala definición del par. Recuerde que el emparejamiento de circuito cerrado (para el IBGP) requiere la local-address instrucción. Para el EBGP, especifique los próximos saltos conectados directamente y confirme el número de AS local, en edit routing-options y el número de AS remoto, en el grupo de pares del EBGP, se especifican.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 mostrar publicidad de ruta y protocolo de recepción son útiles a la hora de confirmar qué rutas anuncia o recibe un orador de 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 del IBGP admita family inet-vpn rutas. Confirme que las rutas anunciadas por PE remoto se importan a la instancia correcta según el 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 coincidencia de PE en y anuncie las rutas correctas. Algunas de las pantallas de la sección verificación del BGP confirman la recepción de rutas CE remotas y la importación de esas rutas a 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 mediante los métodos descritos para la resolución de problemas del BGP. |
Apéndice 2: Configurar 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 la salida de configuración en PE1
La configuración pe1 completa en formato Curly Brace
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 de clase BGP (BGP-CT) con túneles de SR-TE de color subyacentes
Beneficios del BGP-CT con túneles de SR-TE de color subyacentes
- Resuelve las preocupaciones de escala que pueden surgir en el futuro a medida que la red crece.
- Proporciona interconectividad para dominios que utilizan diferentes tecnologías.
- Desvincula los servicios y las capas de transporte, lo que da como resultado una red completamente distribuida.
- Ofrece administración independiente del ancho de banda a través de un controlador de ingeniería de tráfico intradominio para SR-TE.
Las grandes redes que crecen y evolucionan continuamente requieren una arquitectura de enrutamiento por segmentos sin problemas. A partir de Junos OS versión 21.2,R1, somos compatibles con BGP-CT con transporte subyacente como túneles DE SR-TE coloreados. El BGP-CT puede resolver rutas de servicio mediante las RI 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. Ahora, los servicios pueden usar los túneles de color sr-TE subyacentes, como los túneles de color estático, SR-TE BGP, rpd programable y PCEP de color. El BGP-CT utiliza la accesibilidad del salto siguiente para resolver rutas de servicio a través de la clase de transporte deseada.
Para habilitar la resolución de rutas de servicio BGP-CT sobre túneles de color SR-TE subyacentes, incluya la use-transport-class instrucción en el [edit protocols source-packet-routing] nivel de jerarquía.
- Habilitar la
use-transport-classinstrucciónen el
junto con la[edit protocols source-packet-routing]nivel de jerarquía.auto-createinstrucción en el[edit routing-options transport-class]nivel de jerarquía. - No admitemos grupos RIB para SR-TE de color con
use-transport-classtúneles SR-TE de color y solo color con esta función.
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 próximo salto de protocolo (además de la dirección IPv4 o IPv6) para resolver los túneles de transporte mediante LSP estáticos de color y BGP diseñados por tráfico de enrutamiento de segmentos (SR-TE). Esto se denomina resolución de próximo salto del protocolo color-IP, en el que se requiere que configure una asignación de resolución y se aplique a los servicios VPN. Con esta función, puede habilitar la dirección de tráfico basada en colores de los servicios VPN de capa 2 y capa 3.
Junos OS admite LSP DE SR-TE de color asociados con un solo color. La función de asignación basada en colores de los servicios VPN se admite en LSP estáticos de color y LSP de SR-TE del BGP.
- Coloración del servicio VPN
- Especificación del modo de asignación de servicio VPN
- Resolución de próximo salto del protocolo COLOR-IP
- Devolución a la resolución del próximo salto del protocolo IP
- BGP etiquetado con asignación unidifusión basada en color sobre las capas subyacentes SR-TE e IS-IS
- Funciones compatibles y no compatibles para la asignación basada en colores de los servicios VPN
Coloración del servicio VPN
En general, se puede asignar un color a un servicio VPN en el enrutador de salida donde se anuncia el NLRI VPN o en un enrutador de entrada donde se recibe y procesa el NLRI VPN.
Puede asignar un color a los servicios VPN en diferentes niveles:
-
Por instancia de enrutamiento.
-
Por grupo BGP.
-
Por vecino del BGP.
-
Por prefijo.
-
Conjunto de prefijos.
Una vez que asigne 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 de varios colores. En tales casos, el valor de color más pequeño se considera como el color del servicio VPN y todos los demás colores se ignoran.
Los dispositivos de salida o entrada asignan varios colores mediante varias políticas en el siguiente orden:
-
Política de exportación del BGP en el dispositivo de salida.
-
Política de importación del BGP en el dispositivo de entrada.
-
Política de importación de VRF en el dispositivo de entrada.
Los dos modos de coloración de servicio VPN son:
Asignación de color de salida
En este modo, el dispositivo de salida (es decir, el anunciantes de la VPN NLRI) 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, la exportación de grupo o la exportación de vecinos de grupo del servicio VPN en el nivel de jerarquía de [editar protocolos bgp]. BGP anuncia la VPN NLRI 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 política de enrutamiento como política de exportación de un grupo BGP o un vecino de BGP, debe incluir la instrucción en el vpn-apply-export nivel de BGP, grupo BGP o vecino de BGP para que la política tenga efecto en el NLRI vpn.
[edit protocols bgp]
group PEs {
...
neighbor PE-A {
export pol-color ...;
vpn-apply-export;
}
}Las políticas de enrutamiento se aplican al prefijo VPN de capa 3 NLRIs, NRLIs VPN de capa 2 y NLRIs de EVPN. La comunidad extendida de color es heredada por todas las rutas VPN, importados e instalados en las 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 VPN NLRI) 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 [edit protocols bgp] nivel jerárquico. 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 servicio VPN
Para especificar modos de asignación de servicio 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, la importación de grupo o la importación de vecinos de grupo de un servicio VPN en el nivel jerárquico de [editar protocolos 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 política de importación a un grupo BGP o un vecino de BGP.
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-resolution ...;
}
}Cada modo de asignación de servicio VPN debe tener un nombre único definido en el mapa de resolución. Solo se admite una sola entrada de color IP en el mapa de resolución, donde las rutas de VPN se resuelven mediante un siguiente salto de protocolo IP colored en forma de ip-address:color en 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 siguiente salto del protocolo se mejora para admitir la resolución del próximo salto del protocolo IP de color. Para un servicio VPN de color, el proceso de resolución del siguiente salto del protocolo toma un color y un mapa de resolución, crea un siguiente salto de protocolo IP colorada en forma de , y resuelve el siguiente salto de protocolo en las tablas de ip-address:colorenrutamiento inetcolor.0 e inet6color.0.
Debe configurar una política para admitir la resolución de varias rutas de vpn de capa 2, VPN de capa 3 o servicios EVPN de color mediante LSP de color. A continuación, la política se debe aplicar con la tabla RIB correspondiente como política de importación de resolver.
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;
}
}Devolución a la resolución del próximo salto del protocolo IP
Si un servicio VPN de color no tiene un mapa de resolución aplicado a él, el servicio VPN ignora su color y vuelve a pasar a la resolución del siguiente salto del protocolo IP. Por el contrario, si un servicio VPN sin color tiene un mapa de resolución aplicado a él, el mapa de resolución se omite y el servicio VPN usa la resolución del siguiente salto del protocolo IP.
La reserva es un proceso simple desde los LSP de SR-TE colorados hasta los LSP LDP, mediante el uso de un grupo RIB para LDP para instalar rutas en tablas de enrutamiento inet{6}color.0. Una coincidencia de prefijo más larga para un próximo salto del protocolo IP de color garantiza que si no existe una ruta LSP SR-TE colorada, se debe devolver una ruta LDP con una dirección IP correspondiente.
BGP etiquetado con asignación unidifusión basada en color sobre las capas subyacentes SR-TE e IS-IS
A partir de Junos OS versión 20.2R1, la unidifusión etiquetada (BGP-LU) puede resolver rutas IPv4 o IPv6 mediante ingeniería de tráfico de enrutamiento por segmentos (SR-TE) con base IS-IS para familias de direcciones IPv4 e IPv6. BGP-LU admite la asignación de un color de comunidad de BGP y la definición de un resolution map PARA SR-TE. Se construye un siguiente salto de protocolo de color y se resuelve en un túnel SR-TE colorado en la inetcolor.0 tabla o inet6color.0 . Por lo tanto, el BGP-LU resuelve el próximo salto de protocolo sobre túneles SR-TE para el transporte de paquetes. Usos inet.3 y inet6.3 tablas del BGP para la asignación no basada en colores.
Funciones compatibles y no compatibles para la asignación basada en colores de los servicios VPN
Se admiten las siguientes características y funcionalidades con la asignación basada en colores de los servicios VPN:
-
VPN de capa 3 BGP
-
VPN de capa 2 BGP (VPN de kompella de capa 2)
-
BGP EVPN
-
Mapa de resolución con una sola opción de color IP.
-
Resolución de próximo salto del protocolo IPv4 e IPv6 de color.
-
Grupo de base de información de enrutamiento (también conocido como tabla de enrutamiento) basado en reserva a LSP LDP en tablas de enrutamiento inetcolor.0 o inet6color.0.
-
LSP DE SR-TE color.
-
Plataformas virtuales.
-
Junos OS de 64 bits.
-
Sistemas lógicos.
-
BGP etiquetado como unidifusión
No se admiten las siguientes funciones y funcionalidades 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 de BGP descubierta automáticamente y señal de LDP.
-
VPLS
-
MVPN
-
IPv4 e IPv6 mediante el mapa de resolución.