EN ESTA PÁGINA
Descripción general de la ingeniería de tráfico MPLS y los protocolos de señalización
Habilitación de la ingeniería de tráfico de interAS para LSP
Descripción general de la distribución de estado de vínculo mediante BGP
Ejemplo: Configuración de la distribución de estado de vínculo mediante BGP
Configuración de la distribución de estado de vínculo mediante BGP
Descripción general de los planos de transporte con clase BGP
Mejora de la precisión de la base de datos de ingeniería de tráfico con mensajes RSVP PathErr
Configuración de ingeniería de tráfico MPLS
MPLS e Ingeniería de Tráfico
La ingeniería de tráfico le permite controlar la ruta que siguen los paquetes de datos, sin pasar por el modelo de enrutamiento estándar, que utiliza tablas de enrutamiento. La ingeniería de tráfico mueve flujos de vínculos congestionados a vínculos alternativos que no serían seleccionados por la ruta más corta calculada automáticamente y basada en destino. Con la ingeniería de tráfico, puede:
Haga un uso más eficiente de las costosas fibras de larga distancia.
Controle cómo se redirige el tráfico frente a fallas únicas o múltiples.
Clasifique el tráfico crítico y regular por ruta.
El núcleo del diseño de ingeniería de tráfico se basa en la creación de rutas de conmutación de etiquetas (LSP) entre los enrutadores. Un LSP está orientado a la conexión, como un circuito virtual en Frame Relay o ATM. Los LSP no son confiables: Los paquetes que entran en un LSP no tienen garantías de entrega, aunque es posible un trato preferencial. Los LSP también son similares a los túneles unidireccionales en que los paquetes que entran en una ruta se encapsulan en una envolvente y se conmutan a través de toda la ruta sin ser tocados por nodos intermedios. Los LSP proporcionan un control detallado sobre cómo se reenvían los paquetes en una red. Para proporcionar confiabilidad, un LSP puede utilizar un conjunto de rutas primarias y secundarias.
Los LSP pueden configurarse solo para el tráfico del BGP (tráfico cuyo destino está fuera de un sistema autónomo [AS]). En este caso, el tráfico del AS no se ve afectado por la presencia de LSP. Los LSP también pueden configurarse tanto para el tráfico de BGP como para el tráfico del protocolo de pasarela interior (IGP); por lo tanto, los LSP afectan tanto al tráfico del intraAS como al del interAS.
Descripción general de la ingeniería de tráfico MPLS y los protocolos de señalización
La ingeniería de tráfico facilita operaciones de red eficientes y confiables y, al mismo tiempo, optimiza los recursos de red y el rendimiento del tráfico. La ingeniería de tráfico proporciona la capacidad de alejar el flujo de tráfico de la ruta más corta seleccionada por el protocolo de puerta de enlace interior (IGP) a una ruta física potencialmente menos congestionada a través de una red. Para admitir la ingeniería de tráfico, además del enrutamiento de origen, la red debe hacer lo siguiente:
Calcule una ruta en el origen teniendo en cuenta todas las restricciones, como el ancho de banda y los requisitos administrativos.
Distribuya la información sobre la topología de red y los atributos de vínculo en toda la red una vez calculada la ruta de acceso.
Reserve recursos de red y modifique los atributos del vínculo.
Cuando el tráfico de tránsito se enruta a través de una red IP, MPLS se utiliza a menudo para diseñar su paso. Aunque la ruta exacta a través de la red de tránsito es de poca importancia para el remitente o el receptor del tráfico, los administradores de red a menudo desean enrutar el tráfico de manera más eficiente entre ciertos pares de direcciones de origen y destino. Al agregar una etiqueta corta con instrucciones de enrutamiento específicas a cada paquete, MPLS conmuta paquetes de enrutador a enrutador a través de la red en lugar de reenviar paquetes basados en búsquedas de salto siguiente. Las rutas resultantes se denominan rutas de conmutación de etiquetas (LSP). Los LSP controlan el paso del tráfico a través de la red y aceleran el reenvío del tráfico.
Puede crear LSP manualmente o mediante el uso de protocolos de señalización. Los protocolos de señalización se utilizan dentro de un entorno MPLS para establecer LSP para el tráfico a través de una red de tránsito. Junos OS admite dos protocolos de señalización: LDP y el protocolo de reserva de recursos (RSVP).
La ingeniería de tráfico MPLS utiliza los siguientes componentes:
LSP MPLS para reenvío de paquetes
Extensiones de IGP para distribuir información sobre la topología de red y los atributos de vínculo
Ruta restringida más corta primero (CSPF) para cálculo y selección de rutas
Extensiones de RSVP para establecer el estado de reenvío a lo largo de la ruta y reservar recursos a lo largo de la ruta
Junos OS también admite ingeniería de tráfico en diferentes regiones de OSPF.
Capacidades de ingeniería de tráfico
La tarea de mapear flujos de tráfico en una topología física existente se denomina ingeniería de tráfico. La ingeniería de tráfico proporciona la capacidad de alejar el flujo de tráfico de la ruta más corta seleccionada por el protocolo de puerta de enlace interior (IGP) a una ruta física potencialmente menos congestionada a través de una red.
La ingeniería de tráfico proporciona las capacidades para hacer lo siguiente:
Enrute las rutas principales alrededor de cuellos de botella conocidos o puntos de congestión en la red.
Proporcione un control preciso sobre cómo se redirige el tráfico cuando la ruta principal se enfrenta a fallas únicas o varias.
Proporcionar un uso más eficiente del ancho de banda agregado disponible y la fibra de larga distancia asegurándose de que los subconjuntos de la red no se sobreutilicen mientras que otros subconjuntos de la red a lo largo de posibles rutas alternativas están infrautilizados.
Maximice la eficiencia operativa.
Mejore las características de rendimiento orientadas al tráfico de la red minimizando la pérdida de paquetes, minimizando los períodos prolongados de congestión y maximizando el rendimiento.
Mejore las características de rendimiento estadísticamente enlazadas de la red (como el índice de pérdidas, la variación del retraso y el retraso de transferencia) necesarias para admitir una Internet multiservicio.
Componentes de la ingeniería de tráfico
En el sistema operativo (SO) Junos®, la ingeniería de tráfico se implementa con MPLS y RSVP. La ingeniería de tráfico se compone de cuatro componentes funcionales:
Configuración de la ingeniería de tráfico para LSP
Cuando se configura un LSP, se instala una ruta de host (una máscara de 32 bits) en el enrutador de entrada hacia el enrutador de salida; la dirección de la ruta de host es la dirección de destino del LSP. La bgp
opción para la traffic engineering
instrucción en el nivel de [edit protocols mpls]
jerarquía está habilitada de forma predeterminada (también puede configurar explícitamente la bgp
opción), lo que permite que solo BGP use LSP en sus cálculos de ruta. Las otras traffic-engineering
opciones de instrucción permiten modificar este comportamiento en la instancia de enrutamiento maestra. Esta funcionalidad no está disponible para instancias de enrutamiento específicas. Además, sólo puede habilitar una de las traffic-engineering
opciones de instrucción (bgp
, bgp-igp
, bgp-igp-both-ribs
, o mpls-forwarding
) a la vez.
Al habilitar o deshabilitar cualquiera de las opciones de la traffic-engineering
instrucción, se quitan todas las rutas MPLS y, a continuación, se vuelven a insertar en las tablas de enrutamiento.
Puede configurar OSPF e ingeniería de tráfico para anunciar la métrica LSP en anuncios de estado de vínculo (LSA) de resumen, tal como se describe en la sección Publicidad de la métrica LSP en resumen LSA.
En las secciones siguientes se describe cómo configurar la ingeniería de tráfico para LSP:
- Uso de LSP para el reenvío de tráfico BGP e IGP
- Uso de LSP para reenvío en redes privadas virtuales
- Uso de rutas RSVP y LDP para reenvío, pero no para selección de rutas
- Publicidad de la métrica LSP en resumen LSA
Uso de LSP para el reenvío de tráfico BGP e IGP
Puede configurar BGP y los IGP para que usen LSP para reenviar el tráfico destinado a enrutadores de salida incluyendo la bgp-igp
opción para la traffic-engineering
instrucción. La bgp-igp
opción hace que todas las rutas inet.3 se muevan a la tabla de enrutamiento inet.0.
En el enrutador de entrada, incluya bgp-igp
la opción para la traffic-engineering
instrucción:
traffic-engineering bgp-igp;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols mpls]
[edit logical-systems logical-system-name protocols mpls]
Nota:La
bgp-igp
opción de latraffic-engineering
instrucción no se puede configurar para VPN). Las VPN requieren que las rutas estén en la tabla de enrutamiento inet.3.
Uso de LSP para reenvío en redes privadas virtuales
Las VPN requieren que las rutas permanezcan en la tabla de enrutamiento inet.3 para funcionar correctamente. En el caso de las VPN, configure la bgp-igp-both-ribs
opción de la traffic-engineering
instrucción para que el BGP y los IGP utilicen LSP para reenviar el tráfico destinado a los enrutadores de salida. La bgp-igp-both-ribs
opción instala las rutas de entrada tanto en la tabla de enrutamiento inet.0 (para rutas de unidifusión IPv4) como en la tabla de enrutamiento inet.3 (para información de ruta MPLS).
En el enrutador de entrada, incluya la traffic-engineering bgp-igp-both-ribs
instrucción:
traffic-engineering bgp-igp-both-ribs;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols mpls]
[edit logical-systems logical-system-name protocols mpls]
Cuando se utiliza la bgp-igp-both-ribs
instrucción, las rutas de la tabla inet.3 se copian en la tabla inet.0. Las rutas copiadas tienen señal LDP o RSVP, y es probable que tengan una preferencia inferior a otras rutas en inet.0. Las rutas con una preferencia inferior tienen más probabilidades de ser elegidas como rutas activas. Esto puede ser un problema porque las políticas de enrutamiento solo actúan sobre rutas activas. Para evitar este problema, utilice la mpls-forwarding
opción en su lugar.
Los LSP con el valor de preferencia numéricamente más bajo se eligen como la ruta preferida.
Por ejemplo:
user@host# show protocols mpls label-switched-path lsp1 { to 192.168.4.4; preference 1000; } label-switched-path lsp2 { to 192.168.4.4; preference 1001; } user@host# run show route table inet.3 inet.3: 2 destinations, 3 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 198.168.4.4/32 *[RSVP/1000/1] 00:17:23, metric 30 > to 192.168.2.18 via ge-0/0/1.0, label-switched-path lsp1 to 192.168.5.5 via ge-0/0/2.0, label-switched-path Bypass->192.168.2.18->192.168.3.3 [RSVP/1001/1] 00:17:23, metric 30 > to 192.168.2.18 via ge-0/0/1.0, label-switched-path lsp2 to 192.168.5.5 via ge-0/0/2.0, label-switched-path Bypass->192.168.2.18->192.168.3.3
El LSP con un valor de preferencia de 1000 es superior y, por lo tanto, se prefiere al LSP con un valor de preferencia de 1001.
Uso de rutas RSVP y LDP para reenvío, pero no para selección de rutas
Si configura las bgp-igp
opciones o bgp-igp-both-ribs
para la traffic-engineering
instrucción, los LSP de alta prioridad pueden reemplazar a las rutas IGP de la tabla de enrutamiento inet.0. Es posible que las rutas IGP ya no se redistribuyan porque ya no son las rutas activas.
Si configura la mpls-forwarding
opción para la instrucción, los LSP se utilizan para el reenvío, pero se excluyen de la traffic-engineering
selección de ruta. Estas rutas se agregan a las tablas de enrutamiento inet.0 e inet.3. Los LSP de la tabla de enrutamiento inet.0 tienen una preferencia inferior cuando se selecciona la ruta activa. Sin embargo, los LSP de la tabla de enrutamiento inet.3 tienen una preferencia normal y, por lo tanto, se utilizan para seleccionar el reenvío de los próximos saltos.
Cuando se activa la mpls-forwarding
opción, las rutas cuyo estado es ForwardingOnly
se prefieren para el reenvío incluso si su preferencia es inferior a la de la ruta actualmente activa. Para examinar el estado de una ruta, ejecute un show route detail
comando.
Para usar LSP para reenvío pero excluirlos de la selección de ruta, incluya la mpls-forwarding
opción para la traffic-engineering
instrucción:
traffic-engineering mpls-forwarding;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols mpls]
[edit logical-systems logical-system-name protocols mpls]
Al configurar la opción, las mpls-forwarding
rutas de acceso directo de IGP se copian únicamente en la tabla de enrutamiento inet.0.
A diferencia de la bgp-igp-both-ribs
opción, la mpls-forwarding
opción le permite usar las rutas señalizadas por LDP y RSVP para el reenvío, y mantener las rutas BGP e IGP activas con fines de enrutamiento para que las políticas de enrutamiento puedan actuar sobre ellas.
Por ejemplo, supongamos que un enrutador ejecuta BGP y tiene una ruta BGP de 10.10.10.1/32 que necesita enviar a otro altavoz BGP. Si utiliza la bgp-igp-both-ribs
opción y el enrutador también tiene una ruta de conmutación de etiquetas (LSP) a 10.10.10.1, la ruta MPLS para 10.10.10.1 se activa en la tabla de enrutamiento inet.0. Esto impide que el enrutador anuncie la ruta 10.10.10.1 al otro enrutador BGP. Por otro lado, si usa la mpls-forwarding
opción en lugar de la bgp-igp-both-ribs
opción, la ruta BGP 10.10.10.1/32 se anuncia al otro altavoz BGP y el LSP se sigue utilizando para reenviar tráfico al destino 10.10.10.1.
Publicidad de la métrica LSP en resumen LSA
Puede configurar MPLS y OSPF para tratar un LSP como un vínculo. Esta configuración permite que otros enrutadores de la red utilicen este LSP. Para lograr este objetivo, debe configurar la ingeniería de tráfico MPLS y OSPF para anunciar la métrica LSP en resumen de LSA.
Para MPLS, incluya las traffic-engineering bgp-igp
instrucciones y label-switched-path
:
traffic-engineering bgp-igp; label-switched-path lsp-name { to address; }
Puede incluir estas instrucciones en los siguientes niveles jerárquicos:
[edit protocols mpls]
[edit logical-systems logical-system-name protocols mpls]
Para OSPF, incluya la lsp-metric-into-summary
declaración:
lsp-metric-into-summary;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols ospf traffic-engineering shortcuts]
[edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]
Para obtener más información acerca de la ingeniería de tráfico OSPF, consulte la Biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.
Habilitación de la ingeniería de tráfico entre áreas
Junos OS puede señalar un LSP de ingeniería de tráfico contiguo en varias áreas de OSPF. La señalización de LSP debe realizarse mediante anidamiento o señalización contigua, como se describe en RFC 4206, Jerarquía de rutas conmutadas por etiquetas (LSP) con ingeniería de tráfico (TE) de conmutación de etiquetas multiprotocolo generalizada (GMPLS). Sin embargo, la compatibilidad con la señalización contigua se limita solo a la señalización básica. La reoptimización no se admite con la señalización contigua.
A continuación se describen algunas de las características de ingeniería de tráfico entre áreas:
La ingeniería de tráfico entre áreas se puede habilitar cuando los enrutadores de borde de área de salto suelto (ABR) se configuran en el enrutador de entrada mediante CSPF para el cálculo del objeto de ruta explícito (ERO) dentro de un área OSPF. La expansión de ERO se completa en los ABR.
La ingeniería de tráfico entre áreas se puede habilitar cuando CSPF está habilitado, pero sin ABR especificados en la configuración de LSP en el enrutador de entrada (los ABR se pueden designar automáticamente).
Se admite la ingeniería de tráfico de servicios diferenciados (DiffServ) siempre que las asignaciones de tipo de clase sean uniformes en varias áreas.
Para habilitar la ingeniería de tráfico entre áreas, incluya la expand-loose-hop
instrucción en la configuración de cada enrutador de tránsito LSP:
expand-loose-hop;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols mpls]
[edit logical-systems logical-system-name protocols mpls]
Habilitación de la ingeniería de tráfico de interAS para LSP
Generalmente, la ingeniería de tráfico es posible para los LSP que cumplen las siguientes condiciones:
Ambos extremos del LSP se encuentran en la misma área OSPF o en el mismo nivel IS-IS.
Los dos extremos del LSP se encuentran en diferentes áreas de OSPF dentro del mismo sistema autónomo (AS). No se admiten LSP que terminen en diferentes niveles de IS-IS.
Los dos extremos de un LSP de ruta explícita se encuentran en AS OSPF diferentes y los enrutadores de borde del sistema autónomo (ASBR) se configuran estáticamente como los saltos sueltos admitidos en el LSP de ruta explícita. Para obtener más información, consulte Configuración de LSP de ruta explícita.
Sin ASBR definidos estáticamente en los LSP, no es posible realizar ingeniería de tráfico entre un dominio de enrutamiento, o AS, y otro. Sin embargo, cuando los AS están bajo el control de un único proveedor de servicios, es posible en algunos casos que los LSP diseñados para el tráfico abarquen los AS y descubran dinámicamente los ASBR de OSPF que los vinculan (IS-IS no es compatible con esta característica).
Los LSP de ingeniería de tráfico entre AS son posibles siempre que se cumplan ciertos requisitos de red, no se aplique ninguna de las condiciones limitantes y el modo pasivo OSPF esté configurado con EBGP. Los detalles se proporcionan en las siguientes secciones:
- Requisitos de ingeniería de tráfico de Inter-AS
- Limitaciones de la ingeniería de tráfico de Inter-AS
- Configuración del modo TE pasivo de OSPF
Requisitos de ingeniería de tráfico de Inter-AS
El establecimiento y funcionamiento adecuados de los LSP diseñados para el tráfico interAS dependen de los siguientes requisitos de red, todos los cuales deben cumplirse:
Todos los AS están bajo el control de un único proveedor de servicios.
OSPF se usa como protocolo de enrutamiento dentro de cada AS y EBGP se usa como protocolo de enrutamiento entre los AS.
La información de ASBR está disponible dentro de cada AS.
OSPF distribuye la información de enrutamiento de EBGP y una malla completa de IBGP está en su lugar dentro de cada AS.
Los LSP de tránsito no se configuran en los vínculos interAS, sino que se configuran entre ASBR de punto de entrada y salida en cada AS.
El vínculo EBGP entre ASBR en diferentes AS es un vínculo directo y debe configurarse como un vínculo pasivo de ingeniería de tráfico bajo OSPF. La dirección del vínculo remoto en sí, no el circuito cerrado ni ninguna otra dirección de vínculo, se utiliza como identificador de nodo remoto para este vínculo pasivo. Para obtener más información acerca de la configuración del modo de ingeniería de tráfico pasivo de OSPF, consulte Configuración del modo TE pasivo de OSPF.
Además, la dirección utilizada para el nodo remoto del vínculo de ingeniería de tráfico pasivo OSPF debe ser la misma que la dirección utilizada para el vínculo EBGP. Para obtener más información acerca de OSPF y BGP en general, consulte la Biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.
Limitaciones de la ingeniería de tráfico de Inter-AS
Solo se admite la señalización jerárquica o anidada de LSP para los LSP diseñados para el tráfico interAS. Solo se admiten LSP punto a punto (no hay soporte punto a multipunto).
Además, se aplican las siguientes limitaciones. Cualquiera de estas condiciones es suficiente para hacer imposibles los LSP diseñados para el tráfico interAS, incluso si se cumplen los requisitos anteriores.
No se admite el uso de BGP de múltiples saltos.
No se admite el uso de políticas o topologías que impidan que las rutas BGP se conozcan dentro del AS.
No se admiten varios ASBR en una LAN entre pares EBGP. Solo se admite un ASBR en una LAN entre pares EBGP (otros ASBR pueden existir en la LAN, pero no se pueden anunciar).
No se admiten reflectores de ruta ni políticas que oculten información de ASBR o impidan que la información de ASBR se distribuya dentro de los AS.
No se admiten LSP bidireccionales (los LSP son unidireccionales desde la perspectiva de la ingeniería de tráfico).
No se admiten topologías con rutas interAS e intra-AS al mismo destino.
Además, varias características que son rutinarias con todos los LSP no son compatibles con la ingeniería de tráfico interAS:
No se admiten los colores de los vínculos del grupo de administradores.
No se admite el modo de espera secundario.
No se admite la reoptimización.
No se admite el crankback en enrutadores de tránsito.
No se admite el cálculo de rutas diversas.
No se admite el reinicio correcto.
Estas listas de limitaciones o características no compatibles con los LSP de ingeniería de tráfico interAS no son exhaustivas.
Configuración del modo TE pasivo de OSPF
Normalmente, los protocolos de enrutamiento interior, como OSPF, no se ejecutan en vínculos entre AS. Sin embargo, para que la ingeniería de tráfico interAS funcione correctamente, la información sobre el vínculo interAS, en particular, la dirección en la interfaz remota, debe estar disponible dentro del AS. Esta información normalmente no se incluye ni en los mensajes de accesibilidad del EBGP ni en los anuncios de enrutamiento de OSPF.
Para inundar esta información de dirección de vínculo dentro del AS y ponerla a disposición para cálculos de ingeniería de tráfico, debe configurar el modo pasivo OSPF para la ingeniería de tráfico en cada interfaz interAS. También debe proporcionar la dirección remota para que OSPF la distribuya e incluya en la base de datos de ingeniería de tráfico.
Para configurar el modo pasivo OSPF para la ingeniería de tráfico en una interfaz interAS, incluya la passive
instrucción para el vínculo en el nivel de [edit protocols ospf area area-id interface interface-name]
jerarquía:
passive { traffic-engineering { remote-node-id ip-address; /* IP address at far end of inter-AS link */ } }
OSPF debe estar configurado correctamente en el enrutador. En el ejemplo siguiente se configura el vínculo so-1/1/0
interAS para distribuir información de ingeniería de tráfico con OSPF dentro del AS. La dirección IP remota es 192.168.207.2
.
[edit protocols ospf area 0.0.0.0] interface so-1/1/0 { unit 0 { passive { traffic-engineering { remote-node-id 192.168.207.2; } } } }
Componente de reenvío de paquetes
El componente de reenvío de paquetes de la arquitectura de ingeniería de tráfico de Junos es MPLS, que es responsable de dirigir un flujo de paquetes IP a lo largo de una ruta predeterminada a través de una red. Esta ruta se denomina ruta de conmutación de etiquetas (LSP). Los LSP son simplex; es decir, el tráfico fluye en una dirección desde el enrutador de cabecera (entrada) a un enrutador de extremo final (salida). El tráfico dúplex requiere dos LSP: un LSP para transportar tráfico en cada dirección. Un LSP se crea mediante la concatenación de uno o más saltos conmutados por etiquetas, lo que permite reenviar un paquete de un enrutador a otro a través del dominio MPLS.
Cuando un enrutador de entrada recibe un paquete IP, agrega un encabezado MPLS al paquete y lo reenvía al siguiente enrutador del LSP. El paquete etiquetado es reenviado a lo largo del LSP por cada enrutador hasta que llega al final del LSP, el enrutador de salida. En este punto, se elimina el encabezado MPLS y el paquete se reenvía en función de la información de capa 3, como la dirección de destino IP. El valor de este esquema es que la ruta física del LSP no se limita a lo que el IGP elegiría como la ruta más corta para llegar a la dirección IP de destino.
- Reenvío de paquetes basado en el intercambio de etiquetas
- Cómo atraviesa un paquete una red troncal MPLS
- Componente de distribución de información
- Componente de selección de ruta
- Componente de señalización
Reenvío de paquetes basado en el intercambio de etiquetas
El proceso de reenvío de paquetes en cada enrutador se basa en el concepto de intercambio de etiquetas. Este concepto es similar a lo que ocurre en cada conmutador de modo de transferencia asíncrono (ATM) en un circuito virtual permanente (PVC). Cada paquete MPLS lleva un encabezado de encapsulación de 4 bytes que contiene un campo de etiqueta de longitud fija de 20 bits. Cuando un paquete que contiene una etiqueta llega a un enrutador, el enrutador examina la etiqueta y la copia como un índice a su tabla de reenvío MPLS. Cada entrada de la tabla de reenvío contiene un par de etiquetas de entrada de interfaz asignado a un conjunto de información de reenvío que se aplica a todos los paquetes que llegan a la interfaz específica con la misma etiqueta de entrada.
Cómo atraviesa un paquete una red troncal MPLS
En esta sección se describe cómo se procesa un paquete IP a medida que atraviesa una red troncal MPLS.
En el borde de entrada de la red troncal MPLS, el enrutador de entrada examina el encabezado IP. Sobre la base de este análisis, el paquete se clasifica, se le asigna una etiqueta, se encapsula en un encabezado MPLS y se reenvía hacia el siguiente salto en el LSP. MPLS proporciona un alto grado de flexibilidad en la forma en que un paquete IP puede ser asignado a un LSP. Por ejemplo, en la implementación de ingeniería de tráfico de Junos, todos los paquetes que llegan al enrutador de entrada y que están destinados a salir del dominio MPLS en el mismo enrutador de salida se reenvían a lo largo del mismo LSP.
Una vez que el paquete comienza a atravesar el LSP, cada enrutador utiliza la etiqueta para tomar la decisión de reenvío. La decisión de reenvío de MPLS se toma independientemente del encabezado IP original: la interfaz y la etiqueta entrantes se utilizan como claves de búsqueda en la tabla de reenvío de MPLS. La etiqueta antigua se sustituye por una nueva etiqueta y el paquete se reenvía al siguiente salto a lo largo del LSP. Este proceso se repite en cada enrutador del LSP hasta que el paquete llega al enrutador de salida.
Cuando el paquete llega al enrutador de salida, la etiqueta se quita y el paquete sale del dominio MPLS. Luego, el paquete se reenvía en función de la dirección IP de destino contenida en el encabezado IP original del paquete de acuerdo con la ruta más corta tradicional calculada por el protocolo de enrutamiento IP.
Componente de distribución de información
La ingeniería de tráfico requiere conocimientos detallados sobre la topología de red, así como información dinámica sobre la carga de la red. Para implementar el componente de distribución de información, se definen extensiones simples a los IGP. Los atributos de vínculo se incluyen como parte del anuncio de estado de vínculo de cada router. Las extensiones IS-IS incluyen la definición de nuevos valores de longitud de tipo (TLV), mientras que las extensiones OSPF se implementan con anuncios de estado de enlace (LSA) opacos. El algoritmo de inundación estándar utilizado por los IGP de estado de vínculo garantiza que los atributos de vínculo se distribuyan a todos los enrutadores del dominio de enrutamiento. Algunas de las extensiones de ingeniería de tráfico que se agregarán al anuncio de estado de vínculo IGP incluyen ancho de banda máximo de vínculo, ancho de banda máximo reservado, reserva de ancho de banda actual y coloreado de vínculos.
Cada enrutador mantiene los atributos de vínculo de red y la información de topología en una base de datos especializada en ingeniería de tráfico. La base de datos de ingeniería de tráfico se utiliza exclusivamente para calcular rutas explícitas para la colocación de LSP en la topología física. Se mantiene una base de datos separada para que el cálculo de ingeniería de tráfico posterior sea independiente del IGP y de la base de datos de estado de vínculo del IGP. Mientras tanto, el IGP continúa su operación sin modificaciones, realizando el cálculo tradicional de la ruta más corta basada en la información contenida en la base de datos de estado de enlace del enrutador.
Componente de selección de ruta
Después de que el IGP inunde los atributos del vínculo de red y la información de topología y la coloque en la base de datos de ingeniería de tráfico, cada enrutador de entrada utiliza la base de datos de ingeniería de tráfico para calcular las rutas de su propio conjunto de LSP en todo el dominio de enrutamiento. La ruta para cada LSP se puede representar mediante una ruta explícita estricta o suelta. Una ruta explícita es una secuencia preconfigurada de enrutadores que deben formar parte de la ruta física del LSP. Si el enrutador de entrada especifica todos los enrutadores del LSP, se dice que el LSP se identifica mediante una ruta explícita estricta. Si el enrutador de entrada especifica sólo algunos de los enrutadores del LSP, el LSP se describe como una ruta explícita suelta. El soporte para rutas explícitas estrictas y sueltas permite que el proceso de selección de rutas tenga una amplia libertad siempre que sea posible, pero que se limite cuando sea necesario.
El enrutador de entrada determina la ruta física de cada LSP aplicando un algoritmo de Restricted Shortest Path First (CSPF) a la información de la base de datos de ingeniería de tráfico. CSPF es un algoritmo de ruta más corta primero que se ha modificado para tener en cuenta restricciones específicas cuando se calcula la ruta más corta a través de la red. La entrada en el algoritmo CSPF incluye:
Información de estado de vínculo de topología aprendida del IGP y mantenida en la base de datos de ingeniería de tráfico
Atributos asociados con el estado de los recursos de red (como el ancho de banda total del vínculo, el ancho de banda del vínculo reservado, el ancho de banda del vínculo disponible y el color del vínculo) que llevan las extensiones IGP y se almacenan en la base de datos de ingeniería de tráfico
Atributos administrativos necesarios para admitir el tráfico que atraviesa el LSP propuesto (como los requisitos de ancho de banda, el recuento máximo de saltos y los requisitos de política administrativa) que se obtienen de la configuración del usuario
A medida que CSPF considera cada nodo candidato y vínculo para un nuevo LSP, acepta o rechaza un componente de ruta específico en función de la disponibilidad de recursos o de si la selección del componente infringe las restricciones de la política de usuario. El resultado del cálculo de CSPF es una ruta explícita que consiste en una secuencia de direcciones de enrutador que proporciona la ruta más corta a través de la red que cumple con las restricciones. A continuación, esta ruta explícita se pasa al componente de señalización, que establece el estado de reenvío en los enrutadores a lo largo del LSP.
Componente de señalización
No se sabe que un LSP sea viable hasta que sea realmente establecido por el componente de señalización. El componente de señalización, que es responsable de establecer el estado de LSP y distribuir etiquetas, se basa en una serie de extensiones para confirmar su asistencia:
El objeto Ruta explícita permite que un mensaje de ruta RSVP atraviese una secuencia explícita de enrutadores que es independiente del enrutamiento IP convencional de ruta más corta. La ruta explícita puede ser estricta o suelta.
El objeto Label Request permite que el mensaje de ruta RSVP solicite que los enrutadores intermedios proporcionen un enlace de etiqueta para el LSP que está estableciendo.
El objeto Label permite confirmar su asistencia para admitir la distribución de etiquetas sin cambiar sus mecanismos existentes. Dado que el mensaje RSVP Resv sigue la ruta inversa del mensaje de ruta RSVP, el objeto Label admite la distribución de etiquetas de los nodos descendentes a los nodos ascendentes.
Planificación y análisis de rutas sin conexión
A pesar de la reducción del esfuerzo de gestión resultante del cálculo de rutas en línea, todavía se requiere una herramienta de planificación y análisis fuera de línea para optimizar la ingeniería de tráfico a nivel mundial. El cálculo en línea tiene en cuenta las limitaciones de recursos y calcula un LSP a la vez. El desafío con este enfoque es que no es determinista. El orden en que se calculan los LSP juega un papel crítico en la determinación de la ruta física de cada LSP a través de la red. Los LSP que se calculan al principio del proceso tienen más recursos disponibles que los LSP calculados más adelante en el proceso, ya que los LSP calculados anteriormente consumen recursos de red. Si se cambia el orden en que se calculan los LSP, también puede cambiar el conjunto resultante de rutas físicas para los LSP.
Una herramienta de planificación y análisis fuera de línea examina simultáneamente las limitaciones de recursos de cada enlace y los requisitos de cada LSP. Aunque el enfoque sin conexión puede tardar varias horas en completarse, realiza cálculos globales, compara los resultados de cada cálculo y, a continuación, selecciona la mejor solución para la red en su conjunto. El resultado del cálculo sin conexión es un conjunto de LSP que optimiza la utilización de los recursos de red. Una vez completado el cálculo sin conexión, los LSP se pueden establecer en cualquier orden, ya que cada uno se instala de acuerdo con las reglas de la solución optimizada globalmente.
Cálculo y configuración flexibles de LSP
La ingeniería de tráfico implica mapear el flujo de tráfico en una topología física. Puede determinar las rutas en línea mediante el enrutamiento basado en restricciones. Independientemente de cómo se calcule la ruta física, el estado de reenvío se instala en toda la red a través de RSVP.
Junos OS admite las siguientes formas de enrutar y configurar un LSP:
Puede calcular la ruta completa del LSP sin conexión y configurar individualmente cada enrutador del LSP con el estado de reenvío estático necesario. Esto es análogo a la forma en que algunos proveedores de servicios de Internet (ISP) configuran sus núcleos de IP a través de ATM.
Puede calcular la ruta completa del LSP sin conexión y configurar estáticamente el enrutador de entrada con la ruta completa. A continuación, el enrutador de entrada utiliza RSVP como protocolo de señalización dinámica para instalar un estado de reenvío en cada enrutador a lo largo del LSP.
Puede confiar en el enrutamiento basado en restricciones para realizar cálculos dinámicos de LSP en línea. Las restricciones se configuran para cada LSP; Luego, la propia red determina la ruta que mejor cumple con esas restricciones. En concreto, el enrutador de entrada calcula todo el LSP en función de las restricciones y, a continuación, inicia la señalización en toda la red.
Puede calcular una ruta parcial para un LSP sin conexión y configurar estáticamente el enrutador de entrada con un subconjunto de los enrutadores en la ruta; A continuación, puede permitir el cálculo en línea para determinar la ruta completa.
Por ejemplo, considere una topología que incluye dos rutas este-oeste a través de los Estados Unidos: uno en el norte a través de Chicago y otro en el sur a través de Dallas. Si desea establecer un LSP entre un enrutador de Nueva York y otro de San Francisco, puede configurar la ruta parcial del LSP para que incluya un solo salto de ruta suelta de un enrutador en Dallas. El resultado es un LSP enrutado a lo largo del camino sur. El enrutador de entrada utiliza CSPF para calcular la ruta completa y RSVP para instalar el estado de reenvío a lo largo del LSP.
Puede configurar el enrutador de entrada sin restricción alguna. En este caso, se utiliza el enrutamiento de ruta más corta normal del IGP para determinar la ruta del LSP. Esta configuración no proporciona ningún valor en términos de ingeniería de tráfico. Sin embargo, es fácil y puede ser útil en situaciones en las que se necesitan servicios como redes privadas virtuales (VPN).
En todos estos casos, puede especificar cualquier número de LSP como copias de seguridad para el LSP principal, lo que le permite combinar más de un enfoque de configuración. Por ejemplo, puede calcular explícitamente la ruta principal sin conexión, establecer la ruta secundaria para que se base en restricciones y hacer que la ruta terciaria no tenga restricciones. Si falla un circuito en el que se enruta el LSP principal, el enrutador de entrada nota la interrupción debido a las notificaciones de error recibidas de un enrutador descendente o por la expiración de la información de estado suave del RSVP. A continuación, el enrutador reenvía dinámicamente el tráfico a un LSP de espera activa o llama a RSVP para crear un estado de reenvío para un nuevo LSP de respaldo.
Descripción general de la distribución de estado de vínculo mediante BGP
- Función de un protocolo de pasarela interior
- Limitaciones de un protocolo de puerta de enlace interior
- Necesidad de una distribución de estado de vínculo que abarque
- Uso de BGP como solución
- Características admitidas y no compatibles
- Extensiones de estado de vínculo BGP para el enrutamiento de paquetes fuente en redes (SPRING)
- Verificación del nodo NLRI aprendido a través de BGP con OSPF como IGP
- Verificación del prefijo NLRI aprendido a través de BGP con OSPF como IGP
Función de un protocolo de pasarela interior
Un protocolo de pasarela interna (IGP) es un tipo de protocolo que se usa para intercambiar información de enrutador entre dispositivos dentro de un sistema autónomo (AS). Según el método de cálculo de la mejor ruta a un destino, los IGP se dividen en dos categorías:
Protocolos de estado de vínculo: anuncia información sobre la topología de red (vínculos conectados directamente y el estado de esos vínculos) a todos los enrutadores mediante direcciones de multidifusión y actualizaciones de enrutamiento activadas hasta que todos los enrutadores que ejecutan el protocolo de estado de vínculo tengan información idéntica sobre la internetwork. La mejor ruta a un destino se calcula en función de restricciones como el retraso máximo, el ancho de banda disponible mínimo y la afinidad de clase de recurso.
OSPF e IS-IS son ejemplos de protocolos de estado de vínculo.
Protocolos de vector de distancia: anuncie la información completa de la tabla de enrutamiento a vecinos conectados directamente mediante una dirección de difusión. La mejor ruta se calcula en función del número de saltos a la red de destino.
RIP es un ejemplo de un protocolo de vector de distancia.
Como su nombre lo indica, la función de un IGP es proporcionar conectividad de enrutamiento dentro o interna de un dominio de enrutamiento determinado. Un dominio de enrutamiento es un conjunto de enrutadores bajo control administrativo común que comparten un protocolo de enrutamiento común. Un AS puede constar de varios dominios de enrutamiento, donde IGP funciona para anunciar y aprender prefijos de red (rutas) de enrutadores vecinos para crear una tabla de rutas que, en última instancia, contiene entradas para todas las fuentes que anuncian la accesibilidad de un prefijo determinado. IGP ejecuta un algoritmo de selección de ruta para seleccionar la mejor ruta entre el enrutador local y cada destino, y proporciona conectividad completa entre los enrutadores que forman un dominio de enrutamiento.
Además de anunciar la accesibilidad de la red interna, los IGP se utilizan a menudo para anunciar información de enrutamiento que es externa al dominio de enrutamiento de ese IGP a través de un proceso conocido como redistribución de ruta. La redistribución de ruta es un proceso que consiste en intercambiar información de enrutamiento entre distintos protocolos de enrutamiento para unir varios dominios de enrutamiento cuando se desea una conectividad de intraAS.
Limitaciones de un protocolo de puerta de enlace interior
Si bien cada IGP individual tiene sus propias ventajas y limitaciones, las mayores limitaciones del IGP en general son el rendimiento y la escalabilidad.
Los IGP están diseñados para manejar la tarea de adquirir y distribuir información de topología de red con fines de ingeniería de tráfico. Si bien este modelo ha funcionado bien, los IGP tienen limitaciones de escala inherentes cuando se trata de distribuir grandes bases de datos. Los IGP pueden detectar automáticamente a los vecinos, con los que adquieren información de topología de red dentro del área. Sin embargo, la base de datos de estado de vínculo o una base de datos de ingeniería de tráfico tiene el alcance de una sola área o AS, lo que limita las aplicaciones, como la ingeniería de tráfico de extremo a extremo, la ventaja de tener visibilidad externa para tomar mejores decisiones.
Para las redes de conmutación de etiquetas, como MPLS y MPLS generalizada (GMPLS), la mayoría de las soluciones de ingeniería de tráfico existentes funcionan en un único dominio de enrutamiento. Estas soluciones no funcionan cuando una ruta del nodo de entrada al nodo de salida sale del área de enrutamiento o el AS del nodo de entrada. En tales casos, el problema de cálculo de la ruta se complica debido a la falta de disponibilidad de la información de enrutamiento completa en toda la red. Esto se debe a que los operadores de telecomunicaciones normalmente optan por no perder información de enrutamiento más allá del área o AS de enrutamiento por limitaciones de escalabilidad y confidencialidad.
Necesidad de una distribución de estado de vínculo que abarque
Una de las limitaciones del IGP es su incapacidad para abarcar la distribución del estado de vínculos fuera de una sola área o AS. Sin embargo, la información que abarca el estado de vínculos obtenida por una IGP de varias áreas o AS requiere lo siguiente:
Cálculo de ruta de LSP: esta información se utiliza para calcular la ruta de los LSP MPLS en varios dominios de enrutamiento, por ejemplo, un LSP de TE entre áreas.
Entidades de computación de ruta externa: las entidades de informática de ruta externas, como la optimización de tráfico de la capa de aplicación (ALTO) y los elementos de cálculo de ruta (PCE), realizan cálculos de ruta basados en la topología de red y el estado actual de las conexiones dentro de la red, incluida la información de ingeniería de tráfico. Esta información suele ser distribuida por IGP dentro de la red.
Sin embargo, dado que las entidades de informática de ruta externa no pueden extraer esta información de los IGP, realizan la supervisión de la red para optimizar los servicios de red.
Uso de BGP como solución
Descripción general
Para satisfacer las necesidades de ampliar la distribución del estado de vínculo en varios dominios, se requiere un protocolo de puerta de enlace exterior (EGP) para recopilar información de ingeniería de tráfico y estado de vínculo de un área de IGP, compartirla con un componente externo y usarla para calcular rutas para LSP MPLS entre dominios.
El BGP es un EGP estandarizado diseñado para intercambiar información de enrutamiento y accesibilidad entre sistemas autónomos (AS). BGP es un protocolo probado que tiene mejores propiedades de escalado porque puede distribuir millones de entradas (por ejemplo, prefijos VPN) de manera escalable. BGP es el único protocolo de enrutamiento en uso hoy en día que es adecuado para transportar todas las rutas en Internet. Esto se debe en gran parte a que BGP se ejecuta sobre TCP y puede hacer uso del control de flujo TCP. Por el contrario, los protocolos de puerta de enlace interna (IGP) no tienen control de flujo. Cuando los IGP tienen demasiada información de ruta, comienzan a agitarse. Cuando BGP tiene un altavoz vecino que envía información demasiado rápido, BGP puede estrangular al vecino retrasando las confirmaciones de TCP.
Otro beneficio de BGP es que utiliza tuplas de tipo, longitud, valor (TLV) e información de accesibilidad de capa de red (NLRI) que proporcionan una extensibilidad aparentemente interminable sin la necesidad de alterar el protocolo subyacente.
La distribución de la información del estado del enlace entre dominios se regula mediante políticas para proteger los intereses del proveedor de servicios. Esto requiere un control sobre la distribución de la topología mediante políticas. BGP, con su marco de políticas implementado, sirve bien en la distribución de rutas entre dominios. En Junos OS, BGP se basa completamente en políticas. El operador debe configurar explícitamente los vecinos para emparejarse y aceptar explícitamente las rutas en BGP. Además, la política de enrutamiento se utiliza para filtrar y modificar la información de enrutamiento. Por lo tanto, las políticas de enrutamiento proporcionan un control administrativo completo sobre las tablas de enrutamiento.
Aunque dentro de un AS tanto el IGP-TE como el BGP-TE proporcionan el mismo conjunto de información, el BGP-TE tiene mejores funciones de escalabilidad que se heredaron del protocolo BGP estándar. Esto hace a la Ing-T de BGP una opción más escalable para adquirir información de topología de varias áreas o AS.
Al usar BGP como solución, la información adquirida por IGP se usa para su distribución en BGP. Los ISP pueden exponer selectivamente esta información con otros ISP, proveedores de servicios y redes de distribución de contenido (CDN) a través del emparejamiento BGP normal. Esto permite la agregación de la información adquirida por el IGP de varias áreas y AS, de manera tal que una entidad de informática de ruta externa pueda acceder a la información al escuchar de manera pasiva un reflector de ruta.
Implementación
En Junos OS, los IGP instalan información de topología en una base de datos denominada base de datos de ingeniería de tráfico. La base de datos de ingeniería de tráfico contiene la información de topología agregada. Para instalar información de topología de IGP en la base de datos de ingeniería de tráfico, utilice la instrucción de set igp-topology
configuración en los niveles de [edit protocols isis traffic-engineering]
jerarquía y [edit protocols ospf traffic-engineering]
. El mecanismo para distribuir información de estado de vínculo mediante BGP incluye el proceso de anunciar la base de datos de ingeniería de tráfico en BGP-TE (importación) e instalar entradas de BGP-TE en la base de datos de ingeniería de tráfico (exportación).
A partir de Junos OS versión 20.4R1, puede configurar la ingeniería de tráfico IS-IS para almacenar información IPv6 en la base de datos de ingeniería de tráfico (TED), además de las direcciones IPv4. BGP-LS distribuye esta información como rutas desde la base de datos de ingeniería de tráfico a la tabla de enrutamiento lsdist.0 mediante las políticas de importación de bases de datos de ingeniería de tráfico. Estas rutas se anuncian a los pares BGP-TE como información de accesibilidad de la capa de red (NLRI) con tipo, longitud y valor (TLV) de ID de enrutador IPv6. Además de la información sobre IPv6, puede beneficiarse de la obtención de la topología de red completa en la base de datos de ingeniería de tráfico.
![Implementación de Junos OS de la distribución de estado de vínculo BGP](../../bgp/topics/concept/../../images/g042423.png)
BGP-LS NLRI e ID de la Confederación
A partir de Junos OS versión 23.1R1, Junos OS habilita la información de accesibilidad de la capa de red (NLRI) de estado de vínculo BGP (BGP-LS) para llevar el ID de confederación en TLV 512 cuando la confederación BGP está habilitada. El NLRI lleva el ID de la confederación junto con el número del sistema autónomo miembro (número AS) en TLV 517 como se define en RFC 9086. El módulo de base de datos de ingeniería de tráfico de Junos OS realiza los cambios necesarios para codificar el ID de confederación y el número de AS miembro en TLV 512 y TLV 517 respectivamente, mientras origina el BGP-LS NLRI (que se inyecta en la tabla de enrutamiento lsdist.0). En versiones anteriores a Junos OS versión 23.1R1, BGP-LS NLRI solo lleva el número de AS miembro en TLV 512 y el ID de confederación no está codificado en la tabla de enrutamiento lsdist.0.
Importación de bases de datos de ingeniería de tráfico
Para anunciar la base de datos de ingeniería de tráfico en BGP-TE, las entradas de vínculo y nodo en la base de datos de ingeniería de tráfico se convierten en forma de rutas. Estas rutas convertidas son instaladas por la base de datos de ingeniería de tráfico en nombre del IGP correspondiente, en una tabla de enrutamiento visible por el usuario llamada lsdist.0
, en condiciones sujetas a políticas de ruta. El procedimiento de filtrar entradas de la base de datos de ingeniería de tráfico a lsdist.0
se denomina importación de bases de datos de ingeniería de tráfico, como se ilustra en Figura 1.
Existen políticas que rigen el proceso de importación de bases de datos de ingeniería de tráfico. De forma predeterminada, no se filtran entradas de la base de datos de ingeniería de tráfico a la lsdist.0
tabla.
A partir de Junos OS versión 17.4R1, la base de datos de ingeniería de tráfico instala información de topología del protocolo de puerta de enlace interior (IGP) además de información de topología RSVP-TE en la tabla de enrutamiento lsdist.0, como se ilustra en Figura 1. Antes de Junos OS versión 17.4R1, la base de datos de ingeniería de tráfico solo exportaba información de topología RSVP-TE. Ahora puede supervisar la información de topología de ingeniería de tráfico y de IGP. El BGP-LS lee entradas IGP de lsdist.0 y anuncia estas entradas a los pares BGP. Para importar información de topología de IGP en BGP-LS desde lsdist.0, utilice la instrucción configuration set bgp-ls
en el [edit protocols mpls traffic-engineering database import igp-topology]
nivel de jerarquía.
Exportación de bases de datos de ingeniería de tráfico
BGP se puede configurar para exportar o anunciar rutas desde la tabla, sujeto a la lsdist.0
política. Esto es común para cualquier tipo de originación de ruta en BGP. Para anunciar BGP-TE en la base de datos de ingeniería de tráfico, BGP debe configurarse con la familia de direcciones BGP-TE y una política de exportación que seleccione rutas para redistribuir en BGP.
BGP luego propaga estas rutas como cualquier otro NLRI. Los pares BGP que tienen la familia BGP-TE configurada y negociada reciben NLRI BGP-TE. BGP almacena las NLRI BGP-TE recibidas en forma de rutas en la lsdist.0
tabla, que es la misma tabla que almacena las rutas BGP-TE originadas localmente. Las rutas instaladas por BGP se distribuyen a otros pares como lsdist.0
cualquier otra ruta. Por lo tanto, el procedimiento estándar de selección de ruta se aplica a las NLRI BGP-TE recibidas de múltiples altavoces.
Para lograr la TE entre dominios, las rutas se lsdist.0
filtran a la base de datos de ingeniería de tráfico a través de una política. Este proceso se denomina exportación de bases de datos de ingeniería de tráfico, como se ilustra en Figura 1.
Existen políticas que rigen el proceso de exportación de bases de datos de ingeniería de tráfico. De forma predeterminada, no se filtran entradas de la lsdist.0
tabla a la base de datos de ingeniería de tráfico.
A partir de Junos OS versión 22.4R1, puede distribuir las políticas de ingeniería de tráfico (TE) que se originan desde el protocolo de enrutamiento de segmentos a la base de datos de ingeniería de tráfico (TED) y en el estado de vínculo BGP como rutas. BGP link-state recopila la información relacionada con las políticas de TE para que los controladores externos puedan realizar acciones como cálculo de rutas, reoptimización y visualización de red dentro de dominios y entre ellos.
Configure set protocols source-packet-routing traffic-engineering database
para permitir que las políticas de enrutamiento por segmentos (SR) se almacenen en TED.
Para aplicaciones SDN, como PCE y ALTO, la información anunciada BGP-TE no puede filtrarse a la base de datos de ingeniería de tráfico de un enrutador. En tales casos, se utiliza un servidor externo que se empareja con los enrutadores mediante BGP-TE para mover la información de topología hacia el cielo/sistema de orquestación que abarca la red. Estos servidores externos pueden considerarse consumidores de BGP-TE, donde reciben rutas BGP-TE, pero no las anuncian.
Asignación de valores de credibilidad
Una vez que las entradas se instalan en la base de datos de ingeniería de tráfico, la información aprendida de BGP-TE está disponible para el cálculo de la ruta CSPF. La base de datos de ingeniería de tráfico utiliza un esquema de preferencias de protocolo que se basa en valores de credibilidad. Se prefiere un protocolo con un mayor valor de credibilidad sobre un protocolo con un valor de credibilidad más bajo. BGP-TE tiene la capacidad de anunciar información aprendida de múltiples protocolos al mismo tiempo, por lo que además de las entradas instaladas por IGP en la base de datos de ingeniería de tráfico, puede haber entradas instaladas BGP-TE que correspondan a más de un protocolo. El componente de exportación de bases de datos de ingeniería de tráfico crea un protocolo de base de datos de ingeniería de tráfico y un nivel de credibilidad para cada protocolo compatible con BGP-TE. Estos valores de credibilidad se pueden configurar en la CLI.
El orden de credibilidad para los protocolos BGP-TE es el siguiente:
-
Desconocido: 80
-
OSPF—81
-
ISIS Nivel 1—82
-
ISIS Nivel 2—83
-
Estático: 84
-
Directo: 85
Cálculo de ruta de credibilidad cruzada
Después de asignar valores de credibilidad, cada nivel de credibilidad se trata como un plano individual. El algoritmo Restricted Shorted Path First comienza con la credibilidad asignada más alta a la más baja, encontrando una ruta dentro de ese nivel de credibilidad.
Con la Ing-T de BGP, es fundamental calcular las rutas en todos los niveles de credibilidad para calcular rutas de interAS. Por ejemplo, se ven diferentes configuraciones de credibilidad en un dispositivo desde el área 0 que calcula la ruta a través del área 1, porque las entradas del área 0 son instaladas por OSPF y las entradas del área 1 son instaladas por BGP-TE.
Para habilitar el cálculo de rutas en todos los niveles de credibilidad, incluya la cross-credibility-cspf
instrucción en los niveles , y [edit protocols rsvp]
jerárquicoedit protocols mpls
[edit protocols mpls label-switched-path lsp-name]
. En el nivel jerárquico, los impactos habilitantes cross-credibility-cspf
evitan los LSP y la [edit protocols rsvp]
expansión de saltos sueltos en tránsito.
La configuración cross-credibility-cspf
permite el cálculo de rutas en todos los niveles de credibilidad mediante el algoritmo Restricted Shortest Path First, en el que la restricción no se realiza credibilidad por credibilidad, sino como una restricción única que ignora los valores de credibilidad asignados.
BGP-TE NLRI y TLV
Al igual que otras rutas BGP, las NLRI BGP-TE también se pueden distribuir a través de un reflector de ruta que habla BGP-TE NLRI. Junos OS implementa la compatibilidad de reflexión de ruta para la familia BGP-TE.
La siguiente es una lista de NLRI compatibles:
-
Enlace NLRI
-
NLRI de nodo
-
Prefijo IPv4 NLRI (recibir y propagar)
-
Prefijo IPv6 NLRI (recepción y propagación)
-
Política de TE NLRI
Junos OS no proporciona compatibilidad con la forma de distinguir rutas de los NRLI anteriores.
A continuación se muestra una lista de campos admitidos en NLRI de vínculo y nodo:
-
Id. de protocolo: NLRI se origina con los siguientes valores de protocolo:
-
ISIS-L1
-
ISIS-L2
-
OSPF
-
PRIMAVERA-TE
-
-
Identificador: este valor es configurable. De forma predeterminada, el valor del identificador se establece en
0
. -
Descriptor de nodo local/remoto: incluyen:
-
Sistema autónomo
-
Identificador BGP-LS: este valor es configurable. De forma predeterminada, el valor del identificador BGP-LS se establece en
0
-
ID de área
-
ID de enrutador IGP
-
-
Descriptores de vínculo (solo para NLRI de vínculo): esto incluye:
-
Vincular identificadores locales/remotos
-
Dirección de interfaz IPv4
-
Dirección de vecino IPv4
-
Dirección de vecino/interfaz IPv6: las direcciones de vecino e interfaz IPv6 no se originan, sino que solo se almacenan y propagan cuando se reciben.
-
ID de varias topologías: este valor no se origina, sino que se almacena y propaga cuando se recibe.
-
A continuación se muestra una lista de TLV de atributos LINK_STATE compatibles:
-
Atributos del vínculo:
-
Grupo administrativo
-
Ancho de banda máximo del vínculo
-
Ancho de banda máximo reservable
-
Ancho de banda no reservado
-
Métrica predeterminada de TE
-
SRLG
-
Los siguientes TLV, que no se originan, sino que solo se almacenan y propagan cuando se reciben:
-
Atributos de vínculo opacos
-
Máscara de protocolo MPLS
-
Métrico
-
Tipo de protección de vínculo
-
Atributo de nombre de vínculo
-
-
-
Atributos del nodo:
-
ID de enrutador IPv4
-
Bits de indicador de nodo: solo se establece el bit de sobrecarga.
-
Los siguientes TLV, que no se originan, sino que solo se almacenan y propagan cuando se reciben:
-
Multitopología
-
Propiedades del nodo específico de OSPF
-
Propiedades del nodo opaco
-
Nombre del nodo
-
Identificador de área IS-IS
-
ID de enrutador IPv6
-
-
Atributos de prefijo: estos TLV se almacenan y propagan como cualquier otro TLV desconocido.
-
Características admitidas y no compatibles
Junos OS admite las siguientes funciones con la distribución de estado de vínculo mediante BGP:
Anuncio de la capacidad de reenvío asegurado multiprotocolo
Transmisión y recepción de NLRI BGP y BGP-TE de nodo y estado de enlace
Enrutamiento activo sin interrupciones para NLRI BGP-TE
Políticas
Junos OS admite not la siguiente funcionalidad para la distribución de estado de vínculo mediante BGP:
Topologías, vínculos o nodos agregados
Compatibilidad con el distinguidor de rutas para NLRI BGP-TE
Identificadores de varias topologías
Identificadores de varias instancias (excluyendo el ID de instancia predeterminado 0)
Anuncio del TLV de enlace y área de nodo
Publicidad de protocolos de señalización MPLS
Importación de información de nodos y vínculos con direcciones superpuestas
Extensiones de estado de vínculo BGP para el enrutamiento de paquetes fuente en redes (SPRING)
A partir de Junos OS versión 17.2R1, la familia de direcciones de estado de vínculo BGP se extiende para distribuir la información de topología del enrutamiento de paquetes de origen en redes (SPRING) a los controladores de redes definidas por software (SDN). BGP normalmente aprende la información del estado del vínculo de IGP y la distribuye a los pares de BGP. Además de BGP, el controlador SDN puede obtener información de estado de vínculo directamente de IGP si el controlador forma parte de un dominio IGP. Sin embargo, la distribución de estado de vínculo BGP proporciona un mecanismo escalable para exportar la información de topología. Las extensiones de estado de vínculo BGP para SPRING son compatibles con redes entre dominios.
- Enrutamiento de paquetes fuente en redes (SPRING)
- Flujo de datos SPRING de estado de enlace BGP
- Atributos y TLV de estado de enlace BGP compatibles, y características no compatibles con BGP Link-State con SPRING
Enrutamiento de paquetes fuente en redes (SPRING)
SPRING es una arquitectura de plano de control que permite a un enrutador de entrada dirigir un paquete a través de un conjunto específico de nodos y enlaces en la red sin depender de los nodos intermedios de la red para decidir la ruta real que debe tomar. SPRING involucra IGP, como IS-IS y OSPF, para segmentos de redes publicitarias. Los segmentos de red pueden representar cualquier instrucción, topológica o basada en servicios. Dentro de las topologías IGP, los segmentos IGP se anuncian mediante los protocolos de enrutamiento de estado de vínculo. Hay dos tipos de segmentos de IGP:
Adjacency segment |
Una ruta de un salto sobre una adyacencia específica entre dos nodos en el IGP |
Prefix segment |
Una ruta más corta con múltiples saltos, de igual costo y con reconocimiento de múltiples rutas a un prefijo, según el estado de la topología de IGP |
Cuando SPRING está habilitado en una red BGP, la familia de direcciones de estado de vínculo BGP aprende la información de SPRING de los protocolos de enrutamiento de estado de vínculo IGP y anuncia segmentos en forma de identificadores de segmento (SID). La familia de direcciones de estado del vínculo BGP se ha ampliado para transportar SID y otra información relacionada con SPRING a los pares BGP. El reflector de ruta puede dirigir un paquete a través de un conjunto deseado de nodos y enlaces anteponiendo el paquete con una combinación adecuada de túneles. Esta característica permite que la familia de direcciones de estado de vínculo BGP también anuncie la información de SPRING a los pares BGP.
Flujo de datos SPRING de estado de enlace BGP
Figura 2 representa el flujo de datos de los datos SPRING de estado de vínculo BGP que IS-IS envía a la base de datos de ingeniería de tráfico.
![Enrutamiento de paquetes fuente de estado de vínculo BGP en redes (SPRING)](../../bgp/topics/concept/../../images/g043722.png)
-
IGP inserta los atributos SPRING a la base de datos de ingeniería de tráfico.
-
Las capacidades de SPRING y la información del algoritmo se trasladan como atributos de nodo a la base de datos de ingeniería de tráfico.
-
La información SID adyacente y SID adyacente LAN se lleva como atributos de vínculo.
-
La información del SID del prefijo o del SID del nodo se lleva como atributos del prefijo.
-
Un nuevo conjunto o un cambio en los atributos existentes desencadena actualizaciones de IGP en la base de datos de ingeniería de tráfico con datos nuevos.
Precaución:Si la ingeniería de tráfico está deshabilitada en el nivel de IGP, ninguno de los atributos se inserta en la base de datos de ingeniería de tráfico.
-
Todos los parámetros de la NLRI de ingeniería de tráfico de BGP, incluidos los descriptores de vínculo, nodo y prefijo, se derivan de entradas en la base de datos de ingeniería de tráfico.
-
La base de datos de ingeniería de tráfico importa entradas de ruta en la
lsdist.0
tabla de enrutamiento desde IGP sujeto a directiva. -
La política predeterminada de BGP es exportar rutas, que solo conocen BGP. Puede configurar una directiva de exportación para rutas que no sean BGP en la tabla de
lsdis.0
enrutamiento. Esta política anuncia una entrada aprendida de la base de datos de ingeniería de tráfico.
Atributos y TLV de estado de enlace BGP compatibles, y características no compatibles con BGP Link-State con SPRING
El estado de vínculo BGP con SPRING admite los siguientes atributos y tipos, longitud y valores (TLV) que se originan, reciben y propagan en la red:
Node attributes
-
Capacidades de enrutamiento por segmentos
-
Algoritmo de enrutamiento de segmentos
Link attributes
-
SID adyacente
-
LAN adyacente-SID
Prefix descriptors
-
Información de accesibilidad IP
Prefix attributes
-
Prefijo SID
La siguiente lista admite TLV que no se originan, sino que solo se reciben y propagan en la red:
Prefix descriptors
-
ID de multitopología
-
Tipo de ruta OSPF
Prefix attributes
-
Gama
-
SID de enlace
Junos OS no admite las siguientes funciones con el estado de vínculo BGP con extensiones SPRING:
-
Originación del prefijo IPv6
-
Identificadores de multitopología
-
Exportación de bases de datos de ingeniería de tráfico para parámetros SPRING
-
Nuevos TLV con tcpdump (los TLV existentes tampoco son compatibles).
-
SPRING sobre IPv6
Verificación del nodo NLRI aprendido a través de BGP con OSPF como IGP
A continuación se muestra un resultado de ejemplo para comprobar el nodo NLRI aprendido a través de BGP con OSPF como IGP:
Propósito
Compruebe las entradas de la tabla de enrutamiento lsdist.0.
Acción
Desde el modo operativo, ejecute el show route table lsdist.0
comando.
user@host> show route table lsdist.0 te-node-ip 10.7.7.7 extensive lsdist.0: 216 destinations, 216 routes (216 active, 0 holddown, 0 hidden) NODE { AS:65100 Area:0.0.0.1 IPv4:10.7.7.7 OSPF:0 }/1536 (1 entry, 1 announced) TSI: LINK-STATE attribute handle 0x61d5da0 *BGP Preference: 170/-101 Next hop type: Indirect, Next hop index: 0 Address: 0x61b07cc Next-hop reference count: 216 Source: 10.2.2.2 Protocol next hop: 10.2.2.2 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State:<Active Int Ext> Local AS: 65100 Peer AS: 65100 Age: 30:22 Metric2: 2 Validation State: unverified Task: BGP_65100.10.2.2.2 Announcement bits (1): 0-TED Export AS path: I Accepted Area border router: No External router: No Attached: No Overload: No SPRING-Capabilities: - SRGB block [Start: 900000, Range: 90000, Flags: 0x00] SPRING-Algorithms: - Algo: 0 Localpref: 100 Router ID: 10.2.2.2 Indirect next hops: 1 Protocol next hop: 10.2.2.2 Metric: 2 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 10.11.1.2 via et-0/0/0.1 weight 0x1 Session Id: 0x143 10.2.2.2/32 Originating RIB: inet.0 Metric: 2 Node path count: 1 Forwarding nexthops: 1 Nexthop: 10.11.1.2 via et-0/0/0.1 Session Id: 143
Significado
Las rutas aparecen en la tabla de enrutamiento lsdist.0.
Verificación del prefijo NLRI aprendido a través de BGP con OSPF como IGP
A continuación se muestra un resultado de ejemplo para comprobar el prefijo NLRI aprendido a través de BGP con OSPF como IGP:
Propósito
Compruebe las entradas de la tabla de enrutamiento lsdist.0.
Acción
Desde el modo operativo, ejecute el show route table lsdist.0
comando.
user@host> show route table lsdist.0 te-ipv4-prefix-node-ip 10.7.7.7 extensive lsdist.0: 216 destinations, 216 routes (216 active, 0 holddown, 0 hidden) PREFIX { Node { AS:65100 Area:0.0.0.1 IPv4:10.7.7.7 } { IPv4:10.7.7.7/32 } OSPF:0 }/1536 (1 entry, 0 announced) *BGP Preference: 170/-101 Next hop type: Indirect, Next hop index: 0 Address: 0x61b07cc Next-hop reference count: 216 Source: 10.2.2.2 Protocol next hop: 10.2.2.2 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State: <Active Int Ext> Local AS: 65100 Peer AS: 65100 Age: 30:51 Metric2: 2 Validation State: unverified Task: BGP_65100.10.2.2.2 AS path: I Accepted Prefix Flags: 0x00, Prefix SID: 1007, Flags: 0x50, Algo: 0 Localpref: 65100 Router ID: 10.2.2.2 Indirect next hops: 1 Protocol next hop: 10.2.2.2 Metric: 2 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 10.11.1.2 via et-0/0/0.1 weight 0x1 Session Id: 0x143 10.2.2.2/32 Originating RIB: inet.0 Metric: 2 Node path count: 1 Forwarding nexthops: 1 Nexthop: 10.11.1.2 via et-0/0/0.1 Session Id: 143
Significado
Las rutas aparecen en la tabla de enrutamiento lsdist.0.
Ejemplo: Configuración de la distribución de estado de vínculo mediante BGP
En este ejemplo se muestra cómo configurar BGP para transportar información de estado de vínculo a través de varios dominios, que se usa para calcular rutas de acceso para LSP MPLS que abarcan varios dominios, como TE LSP entre áreas, y proporcionar un medio escalable y controlado por políticas para que entidades de informática de ruta externas, como ALTO y PCE, adquieran topología de red.
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
-
Cuatro enrutadores que pueden ser una combinación de enrutadores serie M, serie MX o serie T
-
Junos OS versión 14.2 o posterior ejecutándose en todos los enrutadores
Antes de empezar:
-
Configure las interfaces del dispositivo.
-
Configure los números de sistema autónomo y los ID de enrutador para los dispositivos.
-
Configure los protocolos siguientes:
-
Confirmación de asistencia (RSVP)
-
MPLS
-
protocolo de puerta de enlace de frontera (BGP)
-
SI-SI
-
OSPF
-
Descripción general
A partir de Junos OS versión 14.2, se introduce un nuevo mecanismo para distribuir información de topología entre varias áreas y sistemas autónomos (AS) mediante la extensión del protocolo BGP para transportar información de estado de vínculo, que inicialmente se adquirió mediante IGP. Los protocolos IGP tienen limitaciones de escalamiento cuando se trata de distribuir grandes bases de datos. El BGP no es solo un vehículo más escalable para llevar la información de varias áreas y topologías, sino que también proporciona controles de políticas que pueden ser útiles para la distribución topológica de varios AS. La información de topología de estado de vínculo BGP se utiliza para calcular rutas para rutas de conmutación de etiquetas (LSP) MPLS que abarcan varios dominios, como TE LSP entre áreas, y proporciona un medio escalable y controlado por políticas para que entidades de informática de ruta externas, como ALTO y PCE, adquieran topología de red.
A partir de Junos OS versión 17.1R1, la distribución de estado de vínculo mediante BGP se admite en conmutadores QFX10000.
Topología
![Distribución de estado de vínculo mediante BGP](../../bgp/topics/example/../../images/g042457.gif)
En Figura 3, los enrutadores R0 y R1 y los enrutadores R2 y R3 pertenecen a sistemas autónomos diferentes. Los enrutadores R0 y R1 ejecutan OSPF, y los enrutadores R2 y R3 ejecutan IS-IS.
Configuración
Configuración rápida de CLI
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, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit]
y, luego, ingrese commit
desde el modo de configuración.
R0
set interfaces ge-0/0/0 unit 0 family inet address 10.8.31.101/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.137/32 set routing-options router-id 10.255.105.137 set routing-options autonomous-system 65533 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database export policy accept-all set protocols mpls cross-credibility-cspf set protocols mpls label-switched-path to-R3-inter-as to 10.255.105.135 set protocols mpls label-switched-path to-R3-inter-as bandwidth 40m set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.137 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp neighbor 10.255.105.141 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 policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept
R1
set interfaces ge-0/0/0 unit 0 family inet address 10.8.31.103/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.8.42.102/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.141/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5501.8181 set routing-options router-id 10.255.105.141 set routing-options autonomous-system 65533 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.141 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp export nlri2bgp set protocols bgp group ibgp neighbor 10.255.105.137 set protocols bgp group ebgp type external set protocols bgp group ebgp family traffic-engineering unicast set protocols bgp group ebgp neighbor 10.8.42.104 local-address 10.8.42.102 set protocols bgp group ebgp neighbor 10.8.42.104 peer-as 65534 set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 set protocols isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.104 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 passive traffic-engineering remote-node-id 10.8.42.104 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.139 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept set policy-options policy-statement nlri2bgp term 1 from family traffic-engineering set policy-options policy-statement nlri2bgp term 1 then accept
R2
set interfaces ge-0/0/0 unit 0 family inet address 10.8.64.104/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.8.42.104/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.139/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5502.4211.00 set routing-options router-id 10.255.105.139 set routing-options autonomous-system 65534 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database import policy ted2nlri set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.139 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp export nlri2bgp set protocols bgp group ibgp neighbor 10.255.105.135 set protocols bgp group ebgp type external set protocols bgp group ebgp family traffic-engineering unicast set protocols bgp group ebgp export nlri2bgp set protocols bgp group ebgp peer-as 65533 set protocols bgp group ebgp neighbor 10.8.42.102 set protocols isis level 1 disable set protocols isis interface ge-0/0/0.0 set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 set protocols isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.102 set protocols isis interface lo0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.102 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.141 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept set policy-options policy-statement nlri2bgp term 1 from family traffic-engineering set policy-options policy-statement nlri2bgp term 1 then accept set policy-options policy-statement ted2nlri term 1 from protocol isis set policy-options policy-statement ted2nlri term 1 from protocol ospf set policy-options policy-statement ted2nlri term 1 then accept set policy-options policy-statement ted2nlri term 2 then reject
R3
set interfaces ge-0/0/0 unit 0 family inet address 10.8.64.106/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.135/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5502.4250 set routing-options router-id 10.255.105.135 set routing-options autonomous-system 65534 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database export policy accept-all set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.135 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp neighbor 10.255.105.139 set protocols isis interface ge-0/0/0.0 level 1 disable set protocols isis interface lo0.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 policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept
Procedimiento
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración.
Para configurar el enrutador R1:
-
Configure las interfaces del enrutador R1.
[edit interfaces] user@R1# set ge-0/0/0 unit 0 family inet address 10.8.31.103/24 user@R1# set ge-0/0/0 unit 0 family iso user@R1# set ge-0/0/0 unit 0 family mpls user@R1# set ge-0/0/1 unit 0 family inet address 10.8.42.102/24 user@R1# set ge-0/0/1 unit 0 family iso user@R1# set ge-0/0/1 unit 0 family mpls user@R1# set lo0 unit 0 family inet address 10.255.105.141/32 user@R1# set lo0 unit 0 family iso address 47.0005.0102.5501.8181
-
Configure el ID del enrutador y el sistema autónomo del enrutador R1.
[edit routing-options]
user@R1# set router-id 10.255.105.141 user@R1# set autonomous-system 65533 -
Active RSVP en todas las interfaces del enrutador R1 (excluyendo la interfaz de administración).
[edit protocols]
user@R1# set rsvp interface all user@R1# set rsvp interface fxp0.0 disable -
Habilite MPLS en todas las interfaces del enrutador R1 (excluyendo la interfaz de administración).
[edit protocols]
user@R1# set mpls interface all user@R1# set mpls interface fxp0.0 disable -
Configure el grupo BGP para que el enrutador R1 se empareje con el enrutador R0 y asigne la dirección local y la dirección del vecino.
[edit protocols]
user@R1# set bgp group ibgp type internal user@R1# set bgp group ibgp local-address 10.255.105.141 user@R1# set bgp group ibgp neighbor 10.255.105.137 -
Incluya la información de accesibilidad de la capa de red de señalización BGP-TE (NLRI) al grupo BGP de ibgp.
[edit protocols]
user@R1# set bgp group ibgp family traffic-engineering unicast -
Habilite la exportación de la directiva nlri2bgp en el enrutador R1.
[edit protocols]
user@R1# set bgp group ibgp export nlri2bgp -
Configure el grupo BGP para que el enrutador R1 se empareje con el enrutador R2 y asigne la dirección local y el sistema autónomo vecino al grupo BGP ebgp.
[edit protocols]
user@R1# set bgp group ebgp type external user@R1# set bgp group ebgp neighbor 10.8.42.104 local-address 10.8.42.102 user@R1# set bgp group ebgp neighbor 10.8.42.104 peer-as 65534 -
Incluya la NLRI de señalización BGP-TE al grupo BGP ebgp.
[edit protocols]
user@R1# set bgp group ebgp family traffic-engineering unicast -
Habilite la ingeniería de tráfico pasivo en el vínculo interAS.
[edit protocols]
user@R1# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 user@R1# set isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.104 -
Habilite OSPF en la interfaz que conecta el enrutador R1 con el enrutador R0 y en la interfaz de circuito cerrado del enrutador R1, y habilite las capacidades de ingeniería de tráfico.
[edit protocols]
user@R1# set ospf traffic-engineering user@R1# set ospf area 0.0.0.0 interface lo0.0 user@R1# set ospf area 0.0.0.0 interface ge-0/0/0.0 -
Habilite la ingeniería de tráfico pasivo en el vínculo interAS.
[edit protocols]
user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.104 user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.139 -
Configure políticas para aceptar tráfico de BGP-TE NLRI.
[edit policy-options]
user@R1# set policy-statement accept-all from family traffic-engineering user@R1# set policy-statement accept-all then accept user@R1# set policy-statement nlri2bgp term 1 from family traffic-engineering user@R1# set policy-statement nlri2bgp term 1 then accept
Resultados
Desde el modo de configuración, ingrese los comandos show interfaces
, show routing-options
, show protocols
y show policy-options
para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@R1# show interfaces ge-0/0/0 { unit 0 { family inet { address 10.8.31.103/24; } family iso; family mpls; } } ge-0/0/1 { unit 0 { family inet { address 10.8.42.102/24; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 10.255.105.141/32; family iso { address 47.0005.0102.5501.8181:00; } } }
user@R1# show routing-options router-id 10.255.105.141; autonomous-system 65533;
user@R1# show protocols rsvp { interface all; interface fxp0.0 { disable; } } mpls { interface all; interface fxp0.0 { disable; } } bgp { group ibgp { type internal; local-address 10.255.105.141; family traffic-engineering { unicast; } export nlri2bgp; neighbor 10.255.105.137; } group ebgp { type external; family traffic-engineering { unicast; } neighbor 10.8.42.104 { local-address 10.8.42.102; peer-as 65534; } } } isis { interface ge-0/0/1.0 { passive { remote-node-iso 0102.5502.4211; remote-node-id 10.8.42.104; } } } ospf { traffic-engineering; area 0.0.0.0 { interface lo0.0; interface ge-0/0/0.0; interface ge-0/0/1.0 { passive { traffic-engineering { remote-node-id 10.8.42.104; remote-node-router-id 10.255.105.139; } } } } }
user@R1# show policy-options policy-statement accept-all { from family traffic-engineering; then accept; } policy-statement nlri2bgp { term 1 { from family traffic-engineering; then { accept; } } }
Procedimiento
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración.
Para configurar el enrutador R2:
-
Configure las interfaces del enrutador R2.
[edit interfaces] user@R2# set ge-0/0/0 unit 0 family inet address 10.8.64.104/24 user@R2# set ge-0/0/0 unit 0 family iso user@R2# set ge-0/0/0 unit 0 family mpls user@R2# set ge-0/0/1 unit 0 family inet address 10.8.42.104/24 user@R2# set ge-0/0/1 unit 0 family iso user@R2# set ge-0/0/1 unit 0 family mpls user@R2# set lo0 unit 0 family inet address 10.255.105.139/32 user@R2# set lo0 unit 0 family iso address 47.0005.0102.5502.4211.00
-
Configure el ID del enrutador y el sistema autónomo del enrutador R2.
[edit routing-options]
user@R2# set router-id 10.255.105.139 user@R2# set autonomous-system 65534 -
Active RSVP en todas las interfaces del enrutador R2 (excluyendo la interfaz de administración).
[edit routing-options]
user@R2# set rsvp interface all user@R2# set rsvp interface fxp0.0 disable -
Habilite MPLS en todas las interfaces del enrutador R2 (excluyendo la interfaz de administración).
[edit routing-options]
user@R2# set mpls interface all user@R2# set mpls interface fxp0.0 disable -
Habilite la importación de parámetros de base de datos de ingeniería de tráfico mediante la política ted2nlri.
[edit protocols]
user@R2# set mpls traffic-engineering database import policy ted2nlri -
Configure el grupo BGP para que el enrutador R2 se empareje con el enrutador R3 y asigne la dirección local y la dirección del vecino.
[edit protocols]
user@R2# set bgp group ibgp type internal user@R2# set bgp group ibgp local-address 10.255.105.139 user@R2# set bgp group ibgp neighbor 10.255.105.135 -
Incluya la información de accesibilidad de la capa de red de señalización BGP-TE (NLRI) al grupo BGP de ibgp.
[edit protocols]
user@R2# set bgp group ibgp family traffic-engineering unicast -
Habilite la exportación de la directiva nlri2bgp en el enrutador R2.
[edit protocols]
user@R2# set bgp group ibgp export nlri2bgp -
Configure el grupo BGP para que el enrutador R2 se empareje con el enrutador R1.
[edit protocols]
user@R2# set bgp group ebgp type external -
Incluya la NLRI de señalización BGP-TE al grupo BGP ebgp.
[edit protocols]
user@R2# set bgp group ebgp family traffic-engineering unicast -
Asigne la dirección local y el sistema autónomo vecino al grupo BGP ebgp.
[edit protocols]
user@R2# set bgp group ebgp peer-as 65533 user@R2# set bgp group ebgp neighbor 10.8.42.102 -
Habilite la exportación de la directiva nlri2bgp en el enrutador R2.
[edit protocols]
user@R2# set bgp group ebgp export nlri2bgp -
Active IS-IS en la interfaz que conecta el enrutador R2 con el enrutador R3 y la interfaz de circuito cerrado del enrutador R2.
[edit protocols]
user@R2# set isis level 1 disable user@R2# set isis interface ge-0/0/0.0 user@R2# set isis interface lo0.0 -
Habilite solo la publicidad IS-IS en la interfaz que conecta el enrutador R2 con el enrutador R1.
[edit protocols]
user@R2# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 user@R2# set isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.102 -
Configure la capacidad de ingeniería de tráfico en el enrutador R2.
[edit protocols]
user@R2# set ospf traffic-engineering -
Active solo los anuncios OSPF en la interfaz que conecta el enrutador R2 con el enrutador R1.
[edit protocols]
user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.102 user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.141 -
Configure políticas para aceptar tráfico de la NLRI BGP-TE.
[edit policy-options]
user@R2# set policy-statement accept-all from family traffic-engineering user@R2# set policy-statement accept-all then accept user@R2# set policy-statement nlri2bgp term 1 from family traffic-engineering user@R2# set policy-statement nlri2bgp term 1 then accept user@R2# set policy-statement ted2nlri term 1 from protocol isis user@R2# set policy-statement ted2nlri term 1 from protocol ospf user@R2# set policy-statement ted2nlri term 1 then accept user@R2# set policy-statement ted2nlri term 2 then reject
Resultados
Desde el modo de configuración, ingrese los comandos show interfaces
, show routing-options
, show protocols
y show policy-options
para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@R2# show interfaces ge-0/0/0 { unit 0 { family inet { address 10.8.64.104/24; } family iso; family mpls; } } ge-0/0/1 { unit 0 { family inet { address 10.8.42.104/24; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 10.255.105.139/32; family iso { address 47.0005.0102.5502.4211.00; } family iso; } }
user@R2# show routing-options router-id 10.255.105.139; autonomous-system 65534;
user@R2# show protocols rsvp { interface all; interface fxp0.0 { disable; } } mpls { traffic-engineering { database { import { policy ted2nlri; } } } interface all; interface fxp0.0 { disable; } } bgp { group ibgp { type internal; local-address 10.255.105.139; family traffic-engineering { unicast; } export nlri2bgp; neighbor 10.255.105.135; } group ebgp { type external; family traffic-engineering { unicast; } export nlri2bgp; peer-as 65533; neighbor 10.8.42.102; } } isis { level 1 disable; interface ge-0/0/0.0; interface ge-0/0/1.0 { passive { remote-node-iso 0102.5501.8181; remote-node-id 10.8.42.102; } } interface lo0.0; } ospf { traffic-engineering; area 0.0.0.0 { interface ge-0/0/1.0 { passive { traffic-engineering { remote-node-id 10.8.42.102; remote-node-router-id 10.255.105.141; } } } } }
user@R2# show policy-options policy-statement accept-all { from family traffic-engineering; then accept; } policy-statement nlri2bgp { term 1 { from family traffic-engineering; then { accept; } } } policy-statement ted2nlri { term 1 { from protocol [ isis ospf ]; then accept; } term 2 { then reject; } }
Verificación
Compruebe que la configuración funciona correctamente.
- Comprobación del estado del resumen del BGP
- Comprobación del estado de LSP de MPLS
- Comprobación de las entradas de la tabla de enrutamiento lsdist.0
- Comprobación de las entradas de la base de datos de ingeniería de tráfico
Comprobación del estado del resumen del BGP
Propósito
Verifique que BGP esté funcionando en los enrutadores R0 y R1.
Acción
Desde el modo operativo, ejecute el show bgp summary
comando.
user@R0> show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending lsdist.0 10 10 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 10.255.105.141 65533 20 14 0 79 5:18 Establ lsdist.0: 10/10/10/0
Desde el modo operativo, ejecute el show bgp summary
comando.
user@R1> show bgp summary Groups: 2 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending lsdist.0 10 10 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 10.8.42.104 65534 24 17 0 70 6:43 Establ lsdist.0: 10/10/10/0 10.255.105.137 65533 15 23 0 79 6:19 Establ lsdist.0: 0/0/0/0
Significado
El enrutador R0 está emparejado con el enrutador R1.
Comprobación del estado de LSP de MPLS
Propósito
Verifique el estado del LSP MPLS en el enrutador R0.
Acción
Desde el modo operativo, ejecute el show mpls lsp
comando.
user@R0> show mpls lsp Ingress LSP: 1 sessions To From State Rt P ActivePath LSPname 10.255.105.135 10.255.105.137 Up 0 * to-R3-inter-as Total 1 displayed, Up 1, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
Significado
Se establece el LSP MPLS del enrutador R0 al enrutador R3.
Comprobación de las entradas de la tabla de enrutamiento lsdist.0
Propósito
Verifique las entradas de la tabla de enrutamiento lsdist.0 en los enrutadores R0, R1 y R2.
Acción
Desde el modo operativo, ejecute el show route table lsdist.0
comando.
user@R0> show route table lsdist.0 lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:8.42.1.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:02:03, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10. 8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0
Desde el modo operativo, ejecute el show route table lsdist.0
comando.
user@R1> show route table lsdist.0 lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.42.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:02:19, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10.8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0
Desde el modo operativo, ejecute el show route table lsdist.0
comando.
user@R2> show route table lsdist.0 lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152 *[IS-IS/18] 1d 00:24:39 Fictitious NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152 *[IS-IS/18] 00:20:45 Fictitious NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152 *[IS-IS/18] 00:20:45 Fictitious NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152 *[OSPF/10] 1d 00:24:39 Fictitious LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.42.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152 *[IS-IS/18] 00:20:58 Fictitious LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152 *[IS-IS/18] 00:02:34 Fictitious LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152 *[IS-IS/18] 00:20:45 Fictitious LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152 *[IS-IS/18] 00:20:45 Fictitious LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152 *[IS-IS/18] 00:20:45 Fictitious LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10.8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152 *[OSPF/10] 00:20:57 Fictitious
Significado
Las rutas aparecen en la tabla de enrutamiento lsdist.0.
Comprobación de las entradas de la base de datos de ingeniería de tráfico
Propósito
Verifique las entradas de la base de datos de ingeniería de tráfico en el enrutador R0.
Acción
Desde el modo operativo, ejecute el show ted database
comando.
user@R0> show ted database TED database: 5 ISIS nodes 5 INET nodes ID Type Age(s) LnkIn LnkOut Protocol 0102.5501.8168.00(10.255.105.137) Rtr 1046 1 1 OSPF(0.0.0.0) To: 10.8.31.101-1, Local: 10.8.31.101, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 ID Type Age(s) LnkIn LnkOut Protocol 0102.5501.8181.00 --- 1033 1 0 0102.5502.4211.00(10.255.105.139) Rtr 3519 2 3 Exported ISIS-L2(1) To: 0102.5502.4250.02, Local: 10.8.64.104, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 To: 0102.5501.8181.00, Local: 10.8.42.104, Remote: 10.8.42.102 Local interface index: 0, Remote interface index: 0 ID Type Age(s) LnkIn LnkOut Protocol Exported OSPF(2) To: 10.255.105.141, Local: 10.8.42.104, Remote: 10.8.42.102 Local interface index: 0, Remote interface index: 0 ID Type Age(s) LnkIn LnkOut Protocol 0102.5502.4250.00(10.255.105.135) Rtr 1033 1 1 Exported ISIS-L2(1) To: 0102.5502.4250.02, Local: 10.8.64.106, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 ID Type Age(s) LnkIn LnkOut Protocol 0102.5502.4250.02 Net 1033 2 2 Exported ISIS-L2(1) To: 0102.5502.4211.00(10.255.105.139), Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 To: 0102.5502.4250.00(10.255.105.135), Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 ID Type Age(s) LnkIn LnkOut Protocol 10.8.31.101-1 Net 1046 2 2 OSPF(0.0.0.0) To: 0102.5501.8168.00(10.255.105.137), Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 To: 10.255.105.141, Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 ID Type Age(s) LnkIn LnkOut Protocol 10.255.105.141 Rtr 1045 2 2 OSPF(0.0.0.0) To: 0102.5502.4211.00(10.255.105.139), Local: 10.8.42.102, Remote: 10.8.42.104 Local interface index: 0, Remote interface index: 0 To: 10.8.31.101-1, Local: 10.8.31.103, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0
Significado
Las rutas aparecen en la base de datos de ingeniería de tráfico.
Configuración de la distribución de estado de vínculo mediante BGP
Puede habilitar la distribución de información de topología entre varias áreas y sistemas autónomos (AS) extendiendo el protocolo BGP para transportar información de estado de vínculo, que se adquirió inicialmente mediante IGP. Los protocolos IGP tienen limitaciones de escalamiento cuando se trata de distribuir grandes bases de datos. El BGP no es solo un vehículo más escalable para llevar la información de varias áreas y topologías, sino que también proporciona controles de políticas que pueden ser útiles para la distribución topológica de varios AS. La información de topología de estado de vínculo BGP se utiliza para calcular rutas para LSP MPLS que abarcan varios dominios, como TE LSP entre áreas, y para proporcionar un medio escalable y controlado por políticas para que entidades de informática de ruta externas, como ALTO y PCE, adquieran topología de red.
Antes de empezar:
Configure las interfaces del dispositivo.
Configure el ID del enrutador y el número de sistema autónomo del dispositivo.
Configure los protocolos siguientes:
Confirmación de asistencia (RSVP)
MPLS
SI-SI
OSPF
Para habilitar la distribución de estado de vínculo mediante BGP:
Descripción general de los planos de transporte con clase BGP
- Beneficios de los aviones de transporte con clase BGP
- Terminología de los planos de transporte con clase BGP
- Descripción de los planos de transporte con clase BGP
- Implementación intra-AS de planos de transporte con clase BGP
- Implementación de Inter-AS de planos de transporte con clase BGP
- Descripción general del transporte con clase BGP (BGP-CT) con túneles SR-TE de colores subyacentes
- Beneficios de BGP-CT con túneles SR-TE de colores subyacentes
Beneficios de los aviones de transporte con clase BGP
-
División de red: las capas de servicio y transporte están desacopladas entre sí, sentando las bases para la división de red y la virtualización con la división de extremo a extremo en múltiples dominios, lo que reduce significativamente el CAPEX.
- Interoperabilidad entre dominios: extiende el despliegue de clases de transporte a través de dominios que cooperan para que los diferentes protocolos de señalización de transporte en cada dominio interoperen. Concilia cualquier diferencia entre los espacios de nombres de comunidad extendidos que pueden estar en uso en cada dominio.
-
Resolución coloreada con reserva: permite la resolución sobre túneles de color (RSVP, algoritmo flexible IS-IS) con opciones flexibles de reserva sobre túneles de mejor esfuerzo o cualquier otro túnel de color.
- Calidad de servicio: personaliza y optimiza la red para cumplir los requisitos de SLA de extremo a extremo.
- Aprovechamiento de las implementaciones existentes: admite protocolos de tunelización bien implementados, como RSVP, junto con protocolos nuevos, como el algoritmo flexible IS-IS, lo que preserva el retorno de la inversión y reduce los gastos operativos.
Terminología de los planos de transporte con clase BGP
En esta sección se proporciona un resumen de los términos más utilizados para comprender el plano de transporte con clase BGP.
-
Nodo de servicio: dispositivos perimetrales del proveedor de entrada (PE) que envían y reciben rutas de servicio (Internet y VPN de capa 3).
-
Nodo de borde: dispositivo en el punto de conexión de diferentes dominios (áreas IGP o AS).
-
Nodo de transporte: dispositivo que envía y recibe rutas de unidifusión etiquetada con BGP (LU).
-
BGP-VPN: VPN creadas con mecanismos de RFC4364.
-
Destino de ruta (RT): tipo de comunidad extendida que se utiliza para definir la pertenencia a VPN.
-
Diferenciador de ruta (RD): identificador utilizado para distinguir a qué VPN o servicio de LAN privada virtual (VPLS) pertenece una ruta. Cada instancia de enrutamiento debe tener asociado un diferenciador de ruta único.
- Esquema de resolución: se usa para resolver la dirección del protocolo del próximo salto (PNH) en las RIB de resolución que proporcionan respaldo.
Mapean las rutas a las diferentes RIB de transporte en el sistema basado en el mapeo de la comunidad.
-
Familia de servicios: familia de direcciones BGP que se usa para anunciar rutas para el tráfico de datos, en lugar de túneles.
-
Familia de transporte : familia de direcciones BGP utilizada para túneles publicitarios, que a su vez son utilizados por las rutas de servicio para la resolución.
-
Túnel de transporte: túnel sobre el cual un servicio puede colocar tráfico, por ejemplo, GRE, UDP, LDP, RSVP, SR-TE, BGP-LU.
-
Dominio de túnel: dominio de la red que contiene nodos de servicio y nodos de borde bajo un único control administrativo que tiene un túnel entre ellos. Se puede crear un túnel de extremo a extremo que abarca varios dominios de túnel adyacentes uniendo los nodos mediante etiquetas.
-
Clase de transporte: grupo de túneles de transporte que ofrecen el mismo tipo de servicio.
Clase de transporte RT: nuevo formato de destino de ruta que se utiliza para identificar una clase de transporte específica.
Un nuevo formato de Destino de ruta que se utiliza para identificar una clase de transporte específica.-
RIB de transporte: en el nodo de servicio y el nodo de borde, una clase de transporte tiene una RIB de transporte asociada que contiene sus rutas de túnel.
-
RTI de transporte: una instancia de enrutamiento; contenedor de RIB de transporte y clase de transporte asociada Route Target y Route Distinguisher.
-
Plano de transporte: conjunto de RTI de transporte que importan la misma clase de transporte RT. Estos, a su vez, se unen para abarcar los límites del dominio del túnel utilizando un mecanismo similar a la opción b de Inter-AS para intercambiar etiquetas en los nodos de borde (nexthop-self), formando un plano de transporte de extremo a extremo.
-
Asignación de comunidad: comunidad en una ruta de servicio que se asigna para resolver una clase de transporte.
Descripción de los planos de transporte con clase BGP
Puede usar planos de transporte con clase BGP para configurar clases de transporte para clasificar un conjunto de túneles de transporte en una red intra-AS en función de las características de ingeniería de tráfico y usar estos túneles de transporte para asignar rutas de servicio con el SLA deseado y la reserva prevista.
Los planos de transporte con clase BGP pueden extender estos túneles a redes entre dominios que abarcan varios dominios (áreas AS o IGP) conservando la clase de transporte. Para ello, debe configurar la familia BGP de capa de transporte de transdeporte con clase BGP entre los nodos de borde y servicio.
Tanto en implementaciones de interAS como intraAS, puede haber muchos túneles de transporte (MPLS LSP, IS-IS algoritmo flexible, SR-TE) creados a partir de los nodos de servicio y borde. Los LSP pueden señalizarse utilizando diferentes protocolos de señalización en diferentes dominios y pueden configurarse con diferentes características de ingeniería de tráfico (clase o color). El extremo del túnel de transporte también actúa como extremo de servicio y puede estar presente en el mismo dominio de túnel que el nodo de entrada del servicio, o en un dominio adyacente o no adyacente. Puede utilizar planos de transporte con clase BGP para resove servicios a través de LSP con ciertas características de ingeniería de tráfico, ya sea dentro de un único dominio o en varios dominios.
Los planos de transporte con clase BGP reutilizan la tecnología BGP-VPN, manteniendo los dominios de túnel débilmente acoplados y coordinados.
- La información de accesibilidad de la capa de red (NLRI) es RD:TunnelEndpoint que se utiliza para ocultar rutas.
- El destino de ruta indica la clase de transporte de los LSP y pierde rutas a la RIB de transporte correspondiente en el dispositivo de destino.
- Cada protocolo de tunelización de transporte instala una ruta de entrada en la tabla de enrutamiento transport-class.inet.3, modela la clase de transporte de túnel como destino de ruta VPN y recopila los LSP de la misma clase de transporte en la tabla de enrutamiento transport-class.inet.3 transport-rib.
-
Las rutas de esta instancia de enrutamiento se anuncian en el plano de transporte con clase BGP (transporte inet) AFI-SAFI siguiendo procedimientos similares a RFC-4364.
-
Al cruzar el límite del vínculo interAS, debe seguir los procedimientos de la opción b para unir los túneles de transporte en estos dominios adyacentes.
Del mismo modo, al cruzar regiones intra-AS, debe seguir los procedimientos de la opción b para unir los túneles de transporte en los diferentes dominios TE.
-
Puede definir esquemas de resolución para especificar la intención de la variedad de clases de transporte en un orden de reserva.
- Puede resolver rutas de servicio y rutas de transporte con clase BGP sobre estas clases de transporte, llevando la comunidad de mapas en ellas.
La familia de transporte con clase BGP se ejecuta junto con la familia de capas de transporte BGP-LU. En una red MPLS sin interrupciones que ejecuta BGP-LU, cumplir con los estrictos requisitos de SLA de 5G es un desafío, ya que las características de ingeniería de tráfico de los túneles no se conocen ni se conservan más allá de los límites del dominio. Los planos de transporte con clase BGP proporcionan medios operacionalmente fáciles y escalables para anunciar múltiples rutas para loopbacks remotos junto con la información de la clase de transporte en la arquitectura MPLS perfecta. En las rutas de la familia de transporte con clase BGP, las diferentes rutas de SLA se representan mediante la comunidad extendida Ruta de transporte-Destino, que lleva el color de la clase de transporte. Los enrutadores BGP receptores utilizan esta ruta de destino de transporte para asociar la ruta de transporte con clase BGP con la clase de transporte adecuada. Al volver a anunciar las rutas de transporte con clase BGP, MPLS intercambia rutas, interconecta los túneles intra-AS de la misma clase de transporte, formando así un túnel de extremo a extremo que conserva la clase de transporte.
Implementación intra-AS de planos de transporte con clase BGP
Figura 4 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.
![Dominio intra-AS: Escenarios antes y después para la implementación de planos de transporte con clase BGP](../concept/../../images/g301488.png)
![Dominio intra-AS: Escenarios antes y después para la implementación de planos de transporte con clase BGP](../concept/../../images/g301489.png)
Para clasificar túneles de transporte en clase de transporte BGP en una configuración intraAS:
- Defina la clase de transporte en el nodo de servicio (dispositivos de PE de entrada), por ejemplo, oro y bronce, y asigne valores de comunidad de colores a la clase de transporte definida.
Configuración de ejemplo:
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200;
- Asocie el túnel de transporte a una clase de transporte específica en el nodo de entrada de los túneles.
Configuración de ejemplo:
pe11# show protocols mpls label-switched-path toPE12-bronze { transport-class bronze; } label-switched-path toPE12-gold { transport-class gold; }
Funcionalidad del plano de transporte con clase del BGP intraAS:
- El transporte con clase BGP crea RIB de transporte predefinidas por clase de transporte con nombre (oro y bronce) y deriva automáticamente la comunidad de mapeo a partir de su valor de color (100 y 200).
- Las rutas de transporte intra-AS se rellenan en las RIB de transporte mediante el protocolo de túnel cuando está asociado a una clase de transporte.
En este ejemplo, las rutas RSVP LSP asociadas con la clase de transporte gold (color 100) y la clase de transporte bronze (color 200) se instalan en las RIB de transporte junos-rti-tc-<100>.inet.3 y junos-rti-tc-<200>.inet.3, respectivamente.
- El nodo de servicio (PE de entrada) hace coincidir la comunidad de colores extendida (color:0:100 y color:0:200) de la ruta de servicio con la comunidad de mapeo en las RIB de resolución predefinidas y resuelve el siguiente salto de protocolo (PNH) en las RIB de transporte correspondientes (junos-rti-tc-<100>.inet.3 o junos-rti-tc-<200>.inet.3).
- Las rutas BGP se enlazan a un esquema de resolución llevando la comunidad de mapeo asimilado.
- Cada clase de transporte crea automáticamente dos esquemas de resolución predefinidos y deriva automáticamente la comunidad de asignación.
Un esquema de resolución es para resolver rutas de servicio que usan Color:0:<val> como comunidad de mapeo.
El otro esquema de resolución es para resolver rutas de transporte que usan Transport-Target:0:<val> como comunidad cartográfica.
- Si el PNH de la ruta de servicio no se puede resolver mediante las RIB enumeradas en el esquema de resolución predefinido, puede recurrir a la tabla de enrutamiento inet.3.
- También puede configurar la reserva entre RIB de transporte de diferentes colores mediante esquemas de resolución definidos por el usuario en la jerarquía de [edit routing-options resolution scheme] configuración.
Implementación de Inter-AS de planos de transporte con clase BGP
En una red interAS, BGP-LU se convierte en una red de transporte con clase BGP después de configurar un mínimo de dos clases de transporte (oro y bronce) en todos los nodos de servicio o dispositivos PE y nodos de borde (ABR y ASBR).
Para convertir los túneles de transporte en transporte con clase BGP:
- Defina la clase de transporte en los nodos de servicio (dispositivos de PE de entrada) y los nodos de borde (ABR y ASBR), por ejemplo, oro y broze.
Configuración de ejemplo:
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200;
- Asocie los túneles de transporte a una clase de transporte específica en el nodo de entrada de los túneles (PE, ABR y ASBR de entrada).
Configuración de ejemplo:
Para RSVP LSP
abr23# show protocols mpls label-switched-path toASBR21-bronze { transport-class bronze; } label-switched-path toASBR22-gold { transport-class gold;
Para el algoritmo FLXIBLE IS-IS
asbr13# show routing-options flex-algorithm 128 { … color 100; use-transport-class; } flex-algorithm 129 { … color 200; use-transport-class; }
- Habilite una nueva familia para el transporte con clase BGP (transporte inet) y BGP-LU (unidifusión etiquetada con inet) en la red.
Configuración de ejemplo:
abr23# show protocols bgp group toAs2-RR27 { family inet { labeled-unicast { … } transport { … } cluster 172.16.2.3; neighbor 172.16.2.7; }
- Anuncie las rutas de servicio desde el dispositivo de PE de salida con la comunidad de color extendida adecuada.
Configuración de ejemplo:
pe11# show policy-options policy-statement red term 1 { from { route-filter 192.168.3.3/32 exact; } then { community add map2gold; next-hop self; accept; } } term 2 { from { route-filter 192.168.33.33/32 exact; } then { community add map2bronze; next-hop self; accept; } } community map2bronze members color:0:200; community map2gold members color:0:100;
Funcionalidad de plano de transporte con clase de InterAS BGP:
- Los planos de transporte con clase BGP crean RIB de transporte predefinidas por clase de transporte con nombre (oro y bronce) y derivan automáticamente la comunidad de mapeo de su valor de color.
-
Las rutas de transporte intra-AS se rellenan en las RIB de transporte mediante protocolos de tunelización cuando se asocian a una clase de transporte.
Por ejemplo, las rutas de túnel de transporte asociadas con la clase de transporte oro y bronce se instalan en las RIB de transporte junos-rti-tc-<100>.inet.3 y junos-rti-tc-<200>.inet.3, respectivamente.
- Los planos de transporte con clase BGP utilizan un diferenciador de ruta y un destino de ruta únicos cuando copia las rutas del túnel de transporte de cada RIB de transporte a la tabla de enrutamiento bgp.transport.3.
- Los nodos de borde anuncian rutas desde la tabla de enrutamiento bgp.transport.3 a sus pares en otros dominios si el transporte inet familiar se negocia en la sesión BGP.
- El nodo de borde receptor instala estas rutas bgp-ct en la tabla de enrutamiento bgp.transport.3 y copia estas rutas según el destino de ruta de transporte en las RIB de transporte adecuadas.
- El nodo de servicio compara la comunidad de colores de la ruta de servicio con una comunidad de asignación en los esquemas de resolución y resuelve PNH en la RIB de transporte correspondiente ( junos-rti-tc-<100>.inet.3 o junos-rti-tc-<200>.inet.3).
- Los nodos fronterizos utilizan esquemas de resolución predefinidos para la resolución de PNH de rutas de transporte.
- Predefinidos o definidos por el usuario, ambos esquemas de resolución admiten la resolución PNH de rutas de servicio. Predefinido usa inet.3 como reserva, y el esquema de resolución definido por el usuario permite usar la lista de RIB de transporte en el orden especificado al resolver PNH.
- Si el PNH de la ruta de servicio no se puede resolver mediante las RIB enumeradas en el esquema de resolución definido por el usuario, se descarta la ruta.
Descripción general del transporte con clase BGP (BGP-CT) con túneles SR-TE de colores subyacentes
Beneficios de BGP-CT con túneles SR-TE de colores subyacentes
- Resuelve problemas de escala que puedan surgir en el futuro a medida que la red crece.
- Proporciona interconectividad para dominios que usan diferentes tecnologías.
- Desacopla los servicios y las capas de transporte, lo que resulta en una red completamente distribuida.
- Proporciona administración independiente del ancho de banda mediante un controlador de ingeniería de tráfico dentro del dominio para SR-TE.
Las grandes redes que crecen y evolucionan continuamente requieren una arquitectura de enrutamiento de segmentos sin fisuras. A partir de Junos OS versión 21.2,R1, admitimos BGP-CT con transporte subyacente como túneles SR-TE de colores. BGP-CT puede resolver rutas de servicio utilizando las RIB de transporte y calcular el siguiente salto. Los servicios que actualmente son compatibles con BGP-CT también pueden usar los túneles de color SR-TE subyacentes para la resolución de rutas. Los servicios ahora pueden usar los túneles de color SR-TE subyacentes, como los túneles de color estáticos, BGP SR-TE, RPD programable y PCEP. BGP-CT utiliza la accesibilidad del salto siguiente para resolver rutas de servicio en la clase de transporte deseada.
Para habilitar la resolución de ruta del servicio BGP-CT sobre túneles de color SR-TE subyacentes, incluya la use-transport-class
instrucción en el nivel de [edit protocols source-packet-routing]
jerarquía.
- Habilitar la
use-transport-class
instrucciónen el
junto con la[edit protocols source-packet-routing]
nivel jerárquico.auto-create
instrucción en el[edit routing-options transport-class]
nivel jerárquico. - No se admiten grupos RIB para túneles SR-TE de color con
use-transport-class
túneles SR-TE de solo color con esta característica.
Mejora de la precisión de la base de datos de ingeniería de tráfico con mensajes RSVP PathErr
Un elemento esencial de la ingeniería de tráfico basada en RSVP es la base de datos de ingeniería de tráfico. La base de datos de ingeniería de tráfico contiene una lista completa de todos los nodos de red y vínculos que participan en la ingeniería de tráfico, y un conjunto de atributos que cada uno de esos vínculos puede contener. (Para obtener más información acerca de la base de datos de ingeniería de tráfico, vea Cálculo de LSP de ruta restringida). Uno de los atributos de enlace más importantes es el ancho de banda.
La disponibilidad de ancho de banda en los enlaces cambia rápidamente a medida que se establecen y terminan los LSP de RSVP. Es probable que la base de datos de ingeniería de tráfico desarrolle inconsistencias en relación con la red real. Estas inconsistencias no se pueden solucionar aumentando la tasa de actualizaciones de IGP.
La disponibilidad de vínculos puede compartir el mismo problema de incoherencia. Un vínculo que deja de estar disponible puede romper todos los LSP RSVP existentes. Sin embargo, es posible que la red no conozca fácilmente su falta de disponibilidad.
Cuando se configura la rsvp-error-hold-time
instrucción, un nodo de origen (entrada de un LSP RSVP) aprende de los errores de su LSP supervisando los mensajes de PathErr transmitidos desde los nodos posteriores. La información de los mensajes de PathErr se incorpora en cálculos posteriores de LSP, lo que puede mejorar la precisión y la velocidad de la configuración de LSP. Algunos mensajes PathErr también se usan para actualizar la información de ancho de banda de la base de datos de ingeniería de tráfico, lo que reduce las incoherencias entre la base de datos de ingeniería de tráfico y la red.
Puede controlar la frecuencia de las actualizaciones de IGP mediante la update-threshold
instrucción. Consulte Configuración del umbral de actualización de RSVP en una interfaz.
En esta sección se tratan los siguientes temas:
- Mensajes de PathErr
- Identificación del vínculo del problema
- Configuración del enrutador para mejorar la precisión de la base de datos de ingeniería de tráfico
Mensajes de PathErr
Los mensajes PathErr informan de una amplia variedad de problemas por medio de diferentes números de código y subcódigo. Puede encontrar una lista completa de estos mensajes de PathErr en RFC 2205, Protocolo de reserva de recursos (RSVP), versión 1, especificación funcional y RFC 3209, RSVP-TE: Extensiones de RSVP para túneles LSP.
Al configurar la rsvp-error-hold-time
instrucción, se examinan dos categorías de mensajes PathErr, que representan específicamente errores de vínculo:
El ancho de banda del vínculo es bajo para este LSP: Ancho de banda solicitado no disponible: código 1, subcódigo 2
Este tipo de mensaje PathErr representa un problema global que afecta a todos los LSP que transitan por el vínculo. Indican que el ancho de banda del vínculo real es inferior al requerido por el LSP, y que es probable que la información de ancho de banda en la base de datos de ingeniería de tráfico sea una sobreestimación.
Cuando se recibe este tipo de error, el ancho de banda del vínculo disponible se reduce en la base de datos de ingeniería de tráfico local, lo que afecta a todos los cálculos futuros de LSP.
Vínculo no disponible para este LSP:
Error de control de admisión: código 1, cualquier subcódigo excepto el 2
Errores de control de políticas: código 2
Servicio preferenciado: código 12
Problema de enrutamiento: no hay una ruta disponible hacia el destino: código 24, subcódigo 5
Estos tipos de mensajes PathErr suelen ser pertinentes al LSP especificado. El fallo de este LSP no implica necesariamente que otros LSP también puedan fallar. Estos errores pueden indicar problemas de unidad de transferencia máxima (MTU), preferencia sobre el servicio (iniciada manualmente por el operador o por otro LSP con una prioridad más alta), que un vínculo del próximo salto está inactivo, que un vecino del próximo salto está inactivo o rechazo del servicio debido a consideraciones de política. Es mejor enrutar este LSP en particular lejos del enlace.
Identificación del vínculo del problema
Cada mensaje PathErr incluye la dirección IP del remitente. Esta información se propaga sin cambios hacia el enrutador de entrada. Una búsqueda en la base de datos de ingeniería de tráfico puede identificar el nodo que originó el mensaje PathErr.
Cada mensaje de PathErr contiene suficiente información para identificar la sesión RSVP que desencadenó el mensaje. Si se trata de un enrutador de tránsito, simplemente reenvía el mensaje. Si este enrutador es el enrutador de entrada (para esta sesión RSVP), tiene la lista completa de todos los nodos y enlaces que debe atravesar la sesión. Junto con la información del nodo de origen, el enlace se puede identificar de forma única.
Configuración del enrutador para mejorar la precisión de la base de datos de ingeniería de tráfico
Para mejorar la precisión de la base de datos de ingeniería de tráfico, configure la rsvp-error-hold-time
instrucción. Cuando se configura esta instrucción, un nodo de origen (entrada de un LSP RSVP) aprende de los errores de su LSP supervisando los mensajes de PathErr transmitidos desde nodos descendentes. La información de los mensajes de PathErr se incorpora en cálculos posteriores de LSP, lo que puede mejorar la precisión y la velocidad de la configuración de LSP. Algunos mensajes PathErr también se usan para actualizar la información de ancho de banda de la base de datos de ingeniería de tráfico, lo que reduce las incoherencias entre la base de datos de ingeniería de tráfico y la red.
Para configurar cuánto tiempo MPLS debe recordar los mensajes RSVP PathErr y tenerlos en cuenta en el cálculo de CSPF, incluya la rsvp-error-hold-time
instrucción:
rsvp-error-hold-time seconds;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols mpls]
[edit logical-systems logical-system-name protocols mpls]
El tiempo puede ser un valor de 1 a 240 segundos. El valor predeterminado es de 25 segundos. La configuración de un valor de 0 deshabilita la supervisión de los mensajes PathErr.
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice Feature Explorer a fin de determinar si una función es compatible con la plataforma.