EN ESTA PÁGINA
-
Configuración del equilibrio de carga basado en etiquetas MPLS
-
Configuraciones de enrutador para la red MPLS de carga equilibrada
-
Configuración del equilibrio de carga basado en etiquetas MPLS en enrutadores de la serie ACX
-
Descripción general del equilibrio de carga de la carga encapsulada MPLS
-
Configuración de la carga encapsulada MPLS para el equilibrio de carga
-
Descripción del filtrado basado en IP y la duplicación selectiva de puertos del tráfico MPLS
Equilibrio de carga de tráfico MPLS
Configuración del equilibrio de carga basado en etiquetas MPLS
El equilibrio de carga se produce por paquete para los flujos de MPLS en las plataformas compatibles. La entropía, o distribución aleatoria, es esencial para la distribución uniforme de paquetes a sus próximos saltos. De forma predeterminada, cuando se utiliza el equilibrio de carga para ayudar a distribuir el tráfico, Junos OS emplea un algoritmo hash para seleccionar una dirección de salto siguiente para instalarla en la tabla de reenvío. Cada vez que cambia el conjunto de los siguientes saltos para un destino, la dirección del siguiente salto se vuelve a seleccionar por medio del algoritmo hash. Puede configurar cómo se utiliza el algoritmo hash para equilibrar la carga de tráfico en un conjunto de rutas conmutadas con etiquetas (LSP) de igual costo.
Para garantizar la entropía para el tráfico VPLS y VPWS, Junos OS puede crear un hash basado en datos del encabezado IP y hasta tres etiquetas MPLS (las llamadas etiquetas superiores).
En algunos casos, a medida que aumenta el número de funciones de red que usan etiquetas (como MPLS, reenrutamiento rápido y RFC 3107, RSVP y VPN), los datos en las tres etiquetas principales pueden volverse estáticos y, por lo tanto, no son una fuente suficiente de entropía. Como resultado, el equilibrio de carga puede volverse sesgado o puede aumentar la incidencia de entrega de paquetes fuera de servicio. Para estos casos, se pueden usar etiquetas de la parte inferior de la pila de etiquetas (consulte la Tabla 1, a continuación para conocer las calificaciones). Las etiquetas superior e inferior no se pueden usar al mismo tiempo.
Las tarjetas MPC no admiten la configuración de clave hash normal. Para que la configuración de clave hash basada en MPC sea efectiva, necesita una enhanced-hash-key configuración.
El equilibrio de carga se utiliza para distribuir el tráfico de manera uniforme cuando se dan las siguientes condiciones:
-
Existen varios próximos saltos de igual costo a través de diferentes interfaces hacia el mismo destino.
-
Hay un único salto siguiente sobre una interfaz agregada.
Un LSP tiende a equilibrar la carga de su ubicación seleccionando aleatoriamente uno de los próximos saltos de igual costo y usándolo exclusivamente. La selección aleatoria se realiza de forma independiente en cada enrutador de tránsito, lo que compara las métricas del Protocolo de puerta de enlace interior (IGP) por sí solas. No se tiene en cuenta el ancho de banda ni los niveles de congestión.
Esta función se aplica a interfaces Ethernet agregadas y SONET/SDH agregadas, así como a varios próximos saltos MPLS de igual costo. Además, solo en los enrutadores de la serie T, la serie MX, la M120 y la M320, puede configurar el equilibrio de carga para el tráfico IPv4 a través de pseudocables Ethernet de capa 2. También puede configurar el equilibrio de carga para pseudocables Ethernet en función de información IP. La opción de incluir información de IP en la clave hash proporciona compatibilidad con conexiones de conexión cruzada de circuitos Ethernet (CCC).
Para equilibrar la carga en función de la información de la etiqueta MPLS, configure la family mpls instrucción:
[edit forwarding-options hash-key] family mpls { all-labels; bottom-label-1; bottom-label-2; bottom-label-3; label-1; label-2; label-3; no-labels; no-label-1-exp; payload { ether-pseudowire; ip { disable; layer-3-only; port-data { destination-lsb; destination-msb; source-lsb; source-msb; } } } }
Puede incluir esta instrucción en los siguientes niveles de jerarquía:
-
[edit forwarding-options hash-key]
En la tabla 1 se proporciona información detallada sobre todas las posibles opciones de equilibrio de carga de LSP de MPLS.
| Declaración |
Plataformas compatibles |
Opciones de equilibrio de carga de LSP de MPLS |
|---|---|---|
|
|
Serie MX y serie PTX |
Antes de la versión 19.1R1 de Junos OS, se incluían hasta ocho etiquetas MPLS en la clave hash para identificar la unicidad de un flujo en el motor de reenvío de paquetes. En los enrutadores de la serie PTX, este valor se establece de forma predeterminada. A partir de la versión 19.1R1 de Junos OS, para enrutadores de la serie MX con interfaces MPC y MIC, se incluyen hasta dieciséis etiquetas MPLS entrantes en la clave hash. |
|
|
Serie MX con CPC (chip de aislamiento). No se admite en M10i, M7i y M120. |
Usa la etiqueta inferior para calcular la clave hash, por ejemplo, si las etiquetas superiores no proporcionan suficiente variable para el nivel de entropía requerido. |
|
|
Serie MX con CPC (chip de aislamiento). No se admite en M10i, M7i y M120. |
Usa la segunda etiqueta de la parte inferior para calcular la clave hash, por ejemplo, si las etiquetas superiores no proporcionan suficiente variable para el nivel de entropía requerido. |
|
|
Serie MX con CPC (chip de aislamiento). No se admite en M10i, M7i y M120. |
Usa la tercera etiqueta de la parte inferior para calcular la clave hash, por ejemplo, si las etiquetas superiores no proporcionan suficiente variable para el nivel de entropía requerido. |
|
|
Serie M , Serie MX , Serie T |
Incluya la primera etiqueta en la clave hash. Utilice esta opción para paquetes de etiqueta única. |
|
|
Serie M , Serie MX , Serie T |
Incluya la segunda etiqueta en la clave hash. También debe configurar la |
|
|
Serie M , Serie MX , Serie T |
Incluya la tercera etiqueta en la clave hash. También debe configurar la |
|
|
Todos |
Excluye las etiquetas MPLS de la clave hash. |
|
|
Serie M , Serie MX , Serie T |
Excluye el bit EXP de la etiqueta superior de la clave hash. También debe configurar la En el caso de las VPN de capa 2, el enrutador podría encontrar un problema de reordenación de paquetes. Cuando una ráfaga de tráfico empuja el ancho de banda del tráfico del cliente para superar sus límites, el tráfico puede verse afectado en el flujo medio. Como resultado, es posible que los paquetes se reordenen. Al excluir el bit EXP de la clave hash, puede evitar este problema de reordenamiento. |
|
|
Todos |
Le permite configurar qué partes de la carga del paquete IP se incluirán en la clave hash. Para el enrutador de transporte de paquetes de la serie PTX, este valor se establece de forma predeterminada.
Nota: En los enrutadores serie ACX5448, la
payload subopción no se admite y ahora está oculta para evitar configuraciones no compatibles. Si una configuración existente incluye el
set forwarding-options hash-key family mpls payload ip comando, la plataforma muestra la siguiente advertencia:
Warning: configuration block ignored: unsupported platform (acx5448) |
|
|
serie PTX |
Excluya la carga IP de la clave hash. |
|
|
M120, M320, serie MX, serie T |
Equilibre la carga del tráfico IPv4 mediante pseudocables Ethernet de capa 2. |
|
|
Todos |
Incluya la dirección IPv4 o IPv6 en la clave hash. También debe configurar o |
|
|
Todos |
Incluya solo la información IP de capa 3 en la clave hash. Excluye todos los |
|
|
Serie M , Serie MX , Serie T |
Incluya la información de los campos de puerto de origen y destino. De forma predeterminada, el byte más significativo y el byte menos significativo de los campos de puerto de origen y destino se utilizan en la clave hash. Para seleccionar bytes específicos que se van a usar en la clave hash, incluya una o varias de las |
|
|
Serie M , Serie MX , Serie T |
Incluya el byte menos significativo del puerto de destino en la clave hash. Se puede combinar con cualquiera de las otras |
|
|
Serie M , Serie MX , Serie T |
Incluya el byte más significativo del puerto de destino en la clave hash. Se puede combinar con cualquiera de las otras |
|
|
Serie M , Serie MX , Serie T |
Incluya el byte menos significativo del puerto de origen en la clave hash. Se puede combinar con cualquiera de las otras |
|
|
Serie M , Serie MX , Serie T |
Incluya el byte más significativo del puerto de origen en la clave hash. Se puede combinar con cualquiera de las otras |
Los siguientes ejemplos ilustran formas en las que puede configurar el equilibrio de carga de LSP de MPLS:
-
Para incluir la dirección IP y la primera etiqueta en la clave hash:
-
Para los enrutadores serie M , MX y T , configure la
label-1instrucción y laipopción de lapayloadinstrucción en el nivel de[edit forwarding-options hash-key family mpls]jerarquía:[edit forwarding-options hash-key family mpls] label-1; payload { ip; } -
Para los enrutadores de transporte de paquetes de la serie PTX, las
all-labelsopciones yip payloadestán configuradas de forma predeterminada, por lo que no es necesaria ninguna configuración.
-
-
(Solo enrutadores M320 y serie T) Para incluir la dirección IP, así como la primera y la segunda etiqueta en la clave hash, configure las
label-1opciones ylabel-2y laipopción para lapayloadinstrucción en el nivel jerárquico[edit forwarding-options hash-key family mpls]:[edit forwarding-options hash-key family mpls] label-1; label-2; payload { ip; }Nota:Puede incluir esta combinación de instrucciones solo en enrutadores M320 y serie T. Si los incluye en un enrutador de borde multiservicio de la serie M, solo se utilizan la primera etiqueta MPLS y la carga útil de IP en la clave hash.
-
En el caso de los enrutadores de la serie T, asegúrese de que el equilibrio de carga sea adecuado incluyendo las
label-1opciones ,label-2ylabel-3en el nivel jerárquico[edit forwarding-options hash-key family mpls]:[edit forwarding-options hash-key family mpls] label-1; label-2; label-3;
-
(Solo enrutadores serie M , MX y T ) En el caso de las VPN de capa 2, el enrutador podría encontrar un problema de reordenación de paquetes. Cuando una ráfaga de tráfico empuja el ancho de banda del tráfico del cliente para superar sus límites, el tráfico puede verse afectado en el flujo medio. Como resultado, es posible que los paquetes se reordenen. Al excluir el bit EXP de la clave hash, puede evitar este problema de reordenamiento. Para excluir el bit EXP de la primera etiqueta de los cálculos hash, incluya la
no-label-1-expinstrucción en el[edit forwarding-options hash-key family mpls]nivel de jerarquía:[edit forwarding-options hash-key family mpls] label-1; no-label-1-exp; payload { ip; }
Ejemplo: red MPLS de carga equilibrada
Cuando configure varios LSP RSVP en el mismo enrutador de salida, se selecciona el LSP con la métrica más baja y transporta todo el tráfico. Si todos los LSP tienen la misma métrica, se selecciona uno de los LSP al azar y todo el tráfico se reenvía a través de él. Para distribuir el tráfico por igual entre todos los LSP, puede configurar el equilibrio de carga en los enrutadores de entrada o de tránsito, según el tipo de equilibrio de carga configurado.
La figura 1 ilustra una red MPLS con cuatro LSP configurados en el mismo enrutador de salida (R0). El equilibrio de carga se configura en el enrutador de entrada R1. La red de ejemplo utiliza Abrir el camino más corto primero (OSPF) como el protocolo de puerta de enlace interior (IGP) con el área OSPF 0.0.0.0. Se requiere un IGP para el LSP de ruta restringida más corta primero (CSPF), que es el valor predeterminado para Junos OS. Además, la red de ejemplo utiliza una política para crear tráfico BGP.
de red de equilibrio de carga
La red que se muestra en la Figura 1 consta de los siguientes componentes:
-
Una topología de BGP interior de malla completa (IBGP) mediante el AS 65432
-
MPLS y RSVP habilitados en todos los enrutadores
-
Una política de send-statics en los enrutadores R1 y R0 que permite anunciar una nueva ruta en la red
-
Cuatro LSP unidireccionales entre R1 y R0, y un LSP de dirección inversa entre R0 y R1, lo que permite el tráfico bidireccional
-
Equilibrio de carga configurado en el enrutador de entrada R1
La red que se muestra en la Figura 1 es una red de malla completa BGP. Dado que los reflectores de ruta y las confederaciones no se usan para propagar rutas aprendidas de BGP, cada enrutador debe tener una sesión de BGP con cada otro enrutador que ejecute BGP.
Configuraciones de enrutador para la red MPLS de carga equilibrada
- Propósito
- Acción
- Resultado de muestra 1
- Prueba de salida 2
- Prueba de salida 3
- Prueba de salida 4
- Prueba de salida 5
- Prueba de salida 6
- Significado
Propósito
Las configuraciones de este tema son para los seis enrutadores con equilibrio de carga de la red de ejemplo que se ilustra en Topología de red con equilibrio de carga.
Acción
Para mostrar la configuración de un enrutador, utilice el siguiente comando de modo operativo de la CLI de Junos OS:
user@host> show configuration | no-more
Resultado de muestra 1
El siguiente resultado de configuración es para el enrutador de borde R6.
user@R6> show configuration | no-more
[...Output truncated...]
interfaces {
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.16.14/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
fe-1/3/0 {
unit 0 {
family inet {
address 10.10.12.1/24;
}
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.148/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.6.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.6.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
}
protocols {
rsvp {
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.6.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
neighbor 192.168.9.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/2.0;
interface fe-1/3/0.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
Prueba de salida 2
El siguiente resultado de configuración es para el enrutador de entrada R1.
user@R1> show configuration | no-more
[...Output truncated...]
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.12.13/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.16.13/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.143/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
route 100.100.1.0/24 reject; #Static route for send-statics policy
}
router-id 192.168.1.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
forwarding-table {
export lbpp; #Routes exported to forwarding table
}
}
protocols {
rsvp {
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path lsp 1 { #First LSP
to 192.168.0.1; # Destination of the LSP
install 10.0.90.14/32 active; # The prefix is installed in the
primary via-r4; # inet.0 routing table
}
label-switched-path lsp2 {
to 192.168.0.1;
install 10.0.90.14/32 active;
primary via-r2;
}
label-switched-path lsp3 {
to 192.168.0.1;
install 10.0.90.14/32 active;
primary via-r2;
}
label-switched-path lsp4 {
to 192.168.0.1;
install 10.0.90.14/32 active;
primary via-r4;
}
path via-r2 { #Primary path to spread traffic across interfaces
10.0.29.2 loose;
}
path via-r4 {
10.0.24.2 loose;
}
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
export send-statics; #Allows advertising of a new route
group internal {
type internal;
local-address 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
policy-options { #Load balancing policy
policy-statement lbpp {
then {
load-balance per-packet;
}
}
policy-statement send-statics { #Static route policy
term statics {
from {
route-filter 100.100.1.0/24 exact;
}
then accept;
}
}
}
Prueba de salida 3
La siguiente salida de configuración es para el enrutador de tránsito R2.
user@R2> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.0.24.1/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.0.29.1/30;
}
family mpls;
}
}
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.12.14/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.144/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.2.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.2.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
}
protocols {
rsvp {
interface so-0/0/1.0;
interface fe-0/1/0.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface fe-0/1/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.2.1;
neighbor 192.168.1.1;
neighbor 192.168.4.1;
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
Prueba de salida 4
La siguiente salida de configuración es para el enrutador de tránsito R4.
user@R4> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.0.24.2/30;
}
family mpls; # MPLS enabled on relevant interfaces
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.0.49.1/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.146/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.4.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.4.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
protocols {
rsvp {
interface so-0/0/1.0;
interface so-0/0/3.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface so-0/0/1.0;
interface so-0/0/3.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.4.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/1.0;
interface so-0/0/3.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
Prueba de salida 5
La siguiente salida de configuración es para el enrutador de tránsito R9.
user@R9> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/2 {
unit 0 {
family inet {
address 10.0.29.2/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.0.49.2/30;
}
family mpls;
}
}
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.90.13/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.69.206/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.9.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.9. 1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
protocols {
rsvp {
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fe-0/1/0.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fe-0/1/0.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.9.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
neighbor 192.168.0.1;
neighbor 192.168.6.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fe-0/1/0.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
Prueba de salida 6
La siguiente salida de configuración es para el enrutador de salida R0.
user@R0> show configuration | no-more
[...Output truncated...]
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.90.14/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
fe-1/3/0 {
unit 0 {
family inet {
address 10.10.11.1/24;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.69.207/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
route 100.100.10.0/24 reject; #Static route for send-statics policy
}
router-id 192.168.0.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
protocols {
rsvp {
interface fe-0/1/0.0;
interface fe-1/3/0.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path r0-r6 {
to 192.168.6.1;
}
interface fe-0/1/0.0;
interface fe-1/3/0.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.0.1;
export send-statics; #Allows advertising of a new route
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/0.0;
interface fe-1/3/0.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
policy-options {
policy-statement send-statics {
term statics {
from {
route-filter 100.100.10.0/24 exact;
}
then accept;
}
}
}
Significado
Los resultados de los ejemplos 1 a 6 muestran las interfaces básicas, las opciones de enrutamiento, los protocolos y las configuraciones de opciones de política para los seis enrutadores de la red de ejemplo que se ilustra en Ejemplo: Red MPLS de carga equilibrada.
Todos los enrutadores de la red tienen habilitados MPLS, RSVP y BGP. OSPF está configurado como el IGP y las interfaces relevantes tienen información IP básica y compatibilidad con MPLS.
Además, todos los enrutadores tienen el ID de enrutador (RID) configurado manualmente en el nivel de [edit routing-options] jerarquía para evitar problemas de RID duplicados. La passive instrucción se incluye en la configuración OSPF para garantizar que los protocolos no se ejecuten a través de la interfaz circuito cerrado (lo0) y que la interfaz circuito cerrado (lo0) se anuncie correctamente en toda la red.
Los resultados de ejemplo 1, 3, 4 y 5 para R6, R2, R4 y R9 muestran la configuración base para enrutadores conmutados por etiquetas de tránsito. La configuración base incluye todas las interfaces habilitadas para MPLS, el RID configurado manualmente y los protocolos pertinentes (RSVP, MPLS, BGP y OSPF).
El ejemplo de salida 2 del enrutador de entrada R1 muestra la configuración base más cuatro LSP (LSP1 a LSP4) configurados en R0. Los cuatro LSP están configurados con diferentes rutas principales que especifican un salto suelto a través de R4 para lsp1 y lsp4, y a través de R2 para lsp2 y lsp3.
Para crear tráfico, R1 tiene una ruta estática (100.100.1.0/24) configurada en el [edit routing-options static route] nivel de jerarquía. El prefijo se incluye en la política de send-statics en el nivel de [edit policy-options send statics] jerarquía, por lo que las rutas pueden convertirse en rutas BGP.
Además, en el enrutador de entrada R1, el equilibrio de carga se configura mediante la opción por paquete y la política se exporta en el [edit routing-options forwarding-table] nivel jerárquico.
El ejemplo de salida 6 del enrutador de salida R0 muestra un LSP (r0-r6) a R6 que se usa para crear tráfico bidireccional. OSPF requiere accesibilidad de LSP bidireccional antes de anunciar el LSP en el IGP. Aunque el LSP se anuncia en el IGP, no se producen mensajes de saludo ni actualizaciones de enrutamiento a través del LSP: solo se envía tráfico de usuario a través del LSP. El enrutador utiliza su copia local de la base de datos de IGP para comprobar la accesibilidad bidireccional.
Además, R0 tiene una ruta estática (100.100.10.0/24) configurada en el nivel de [edit routing-options static route] jerarquía. El prefijo se incluye en la política de send-statics en el nivel de [edit policy-options send statics] jerarquía, por lo que las rutas pueden convertirse en rutas BGP.
Configuración del equilibrio de carga basado en etiquetas MPLS en enrutadores de la serie ACX
En la tabla 2 , se proporciona información detallada sobre todas las posibles opciones de equilibrio de carga de LSP de MPLS.
Los enrutadores de la serie ACX pueden equilibrar la carga por paquete en MPLS. El equilibrio de carga se puede realizar tanto en la información del encabezado IP como en hasta tres etiquetas MPLS, lo que proporciona una distribución más uniforme del tráfico de MPLS a los siguientes saltos. Esta característica está habilitada en plataformas compatibles de forma predeterminada y no requiere configuración.
El equilibrio de carga se utiliza para distribuir uniformemente el tráfico cuando hay un único salto siguiente sobre una interfaz agregada o un paquete de LAG. El equilibrio de carga mediante etiquetas MPLS solo se admite para interfaces LAG y no para vínculos de multirruta de igual costo (ECMP).
De forma predeterminada, cuando se utiliza el equilibrio de carga para ayudar a distribuir el tráfico, Junos OS emplea un algoritmo hash para seleccionar una dirección de salto siguiente para instalarla en la tabla de reenvío. Cada vez que el conjunto de los siguientes saltos para un destino cambia de alguna manera, la dirección del siguiente salto se vuelve a seleccionar por medio del algoritmo hash. Puede configurar cómo se utiliza el algoritmo hash para equilibrar la carga del tráfico entre las interfaces de una interfaz de Ethernet agregada (ae).
Un LSP tiende a equilibrar la carga de su colocación mediante la selección aleatoria de una de las interfaces en un ae- paquete de interfaces y su uso exclusivo. La selección aleatoria se realiza de forma independiente en cada enrutador de tránsito, lo que compara las métricas del Protocolo de puerta de enlace interior (IGP) por sí solas. No se tiene en cuenta el ancho de banda ni los niveles de congestión.
Para equilibrar la carga en función de la información de la etiqueta MPLS, configure la family mpls instrucción:
[edit forwarding-options hash-key] family mpls { all-labels; label-1; label-2; label-3; no-labels; payload { ether-pseudowire; ip { layer-3-only; port-data { destination-lsb; destination-msb; source-lsb; source-msb; } } } }
Puede incluir esta instrucción en el nivel de [edit forwarding-options hash-key] jerarquía.
Cuando configure la carga útil ip (user@host# set forwarding-options hash-key family mpls payload ip), configurar layer-3-only y port-data es obligatorio.
La funcionalidad de equilibrio de carga, sin una configuración adecuada de hash-keys, puede dar lugar a un comportamiento impredecible.
La serie ACX7000 de dispositivos no admite port-data.
Para la terminación de túnel VPN/pseudocable de capa 2, se utilizan hasta dos etiquetas para el hash y la carga útil Las direcciones MAC de destino y origen se pueden seleccionar opcionalmente. Estos controles se pueden usar para admitir la perilla ether-pseudowire en la familia mpls bajo la configuración de hash-key que se muestra arriba. Sin embargo, dado que ACX2000 y ACX4000 también admiten pseudocables TDM, las perillas ether-pseudowire deben usarse solo cuando no se utilizan pseudocables TDM.
Para la terminación del túnel VPN de capa 3, se utilizan hasta dos etiquetas para tener y cargar las direcciones IP de origen y destino, y opcionalmente se pueden seleccionar los puertos de origen y destino de la capa 4. Estos controles se pueden usar para admitir perillas de datos de puerto IP en la familia MPLS bajo la configuración de clave hash que se muestra arriba. Sin embargo, dado que el puerto de capa 4 MSB y LSB no se pueden seleccionar individualmente, una de las perillas destination-lsb o destination-msb o una de las perillas source-lsb o source-msb seleccionaría los puertos de destino o fuente de capa 4, respectivamente.
En el caso de LSR, se utilizan hasta tres etiquetas para el hash. Si se ve un BOS al analizar las tres primeras etiquetas, BCM examina el primer nibble de la carga útil: si el nibble es 4, la carga útil se trata como IPv4 y si el primer nibble es 6, la carga útil se trata como IPv6 y, en tales casos, las direcciones IP de origen y destino de la carga útil se pueden usar especulativamente para hash. Estos controles se pueden usar para admitir perillas de datos de puerto IP en la familia MPLS bajo la configuración de clave hash. Sin embargo, los puertos de capa 4 no se pueden usar para hash en el caso de LSR, y solo se aplica la perilla de solo capa 3. BCM no reclama compatibilidad con hash en campos más allá de las tres etiquetas MPLS. El equilibrio de carga para una sola sesión de pseudocable no tiene lugar en caso de LSR, ya que todo el tráfico específico de esa sesión llevará el mismo conjunto de etiquetas MPLS.
El equilibrio de carga en las interfaces de AE LSR se puede lograr para un número mayor de sesiones MPLS, es decir, un mínimo de 10 sesiones. Esto es aplicable a CCC/VPLS/L3VPN. En el caso de VPN de capa 3, es posible que el tráfico no se distribuya de manera equitativa entre los vínculos de miembro, ya que las direcciones de capa 3 también se tienen en cuenta (junto con las etiquetas) para la función de entrada hash.
Para escenarios LER, en caso de ACX5048 y ACX5096, es posible aplicar hash basado en los campos de capa 3 y capa 4 configurando la opción de carga útil en la jerarquía "family mpls". El hash en el LER no se basa en etiquetas. Para el servicio de capa 3, es obligatorio mencionar la carga útil como "solo capa 3" y especificar "datos de puerto" en el caso del servicio de capa 4. También puede mencionar el recuento de etiquetas al configurar claves hash en enrutadores LER.
El comportamiento de equilibrio de carga de LER y LSR es aplicable para CCC/VPLS/VPN de capa 3 y otros escenarios de IP MPLS.
Esta función se aplica a interfaces Ethernet agregadas y SONET/SDH agregadas. Además, puede configurar el equilibrio de carga para el tráfico IPv4 a través de pseudocables Ethernet de capa 2. También puede configurar el equilibrio de carga para pseudocables Ethernet en función de información IP. La opción de incluir información de IP en la clave hash proporciona compatibilidad con conexiones de conexión cruzada de circuitos Ethernet (CCC).
| Declaración |
Opciones de equilibrio de carga de LSP de MPLS |
|---|---|
|
|
Incluya la primera etiqueta en la clave hash. Utilice esta opción para paquetes de etiqueta única. |
|
|
Incluya la segunda etiqueta en la clave hash. También debe configurar la |
|
|
Incluya la tercera etiqueta en la clave hash. También debe configurar la |
|
|
Excluye las etiquetas MPLS de la clave hash. |
|
|
Le permite configurar qué partes de la carga del paquete IP se incluirán en la clave hash. Para el conmutador de transporte de paquetes de la serie PTX, este valor se establece de forma predeterminada. |
|
|
Excluya la carga IP de la clave hash. |
|
|
Equilibre la carga del tráfico IPv4 mediante pseudocables Ethernet de capa 2. |
|
|
Incluya la dirección IPv4 o IPv6 en la clave hash. También debe configurar o |
|
|
Incluya solo la información IP de capa 3 en la clave hash. Excluye todos los |
|
|
Incluya la información de los campos de puerto de origen y destino. De forma predeterminada, el byte más significativo y el byte menos significativo de los campos de puerto de origen y destino se utilizan en la clave hash. Para seleccionar bytes específicos que se van a usar en la clave hash, incluya una o varias de las |
|
|
Incluya el byte menos significativo del puerto de destino en la clave hash. Se puede combinar con cualquiera de las otras |
|
|
Incluya el byte más significativo del puerto de destino en la clave hash. Se puede combinar con cualquiera de las otras |
|
|
Incluya el byte menos significativo del puerto de origen en la clave hash. Se puede combinar con cualquiera de las otras |
|
|
Incluya el byte más significativo del puerto de origen en la clave hash. Se puede combinar con cualquiera de las otras |
Para incluir la dirección IP y la primera etiqueta en la clave hash, configure la label-1 instrucción y la opción de ip la payload instrucción en el nivel jerárquico [edit forwarding-options hash-key family mpls] :
[edit forwarding-options hash-key family mpls]
label-1;
payload {
ip;
}
Para incluir la dirección IP, así como la primera y la segunda etiqueta en la clave hash, configure las label-1 opciones y label-2 y la ip opción para la payload instrucción en el nivel jerárquico [edit forwarding-options hash-key family mpls] :
[edit forwarding-options hash-key family mpls]
label-1;
label-2;
payload {
ip;
}
Garantice un equilibrio de carga adecuado incluyendo las label-1opciones , label-2y label-3 en el nivel jerárquico [edit forwarding-options hash-key family mpls] :
[edit forwarding-options hash-key family mpls] label-1; label-2; label-3;
Descripción general del equilibrio de carga de la carga encapsulada MPLS
Los enrutadores pueden equilibrar la carga por paquete en MPLS. El equilibrio de carga se puede realizar en la información tanto en el encabezado IP como en hasta tres etiquetas MPLS, lo que proporciona una distribución más uniforme del tráfico MPLS a los siguientes saltos.
El equilibrio de carga se utiliza para distribuir el tráfico de manera uniforme cuando se dan las siguientes condiciones:
-
Existen varios próximos saltos de igual costo a través de diferentes interfaces hacia el mismo destino.
-
Hay un único salto siguiente sobre una interfaz agregada.
De forma predeterminada, cuando se utiliza el equilibrio de carga para ayudar a distribuir el tráfico, se utiliza un algoritmo hash para seleccionar una dirección de salto siguiente para instalarla en la tabla de reenvío. Cada vez que el conjunto de los siguientes saltos para un destino cambia de alguna manera, la dirección del siguiente salto se vuelve a seleccionar por medio del algoritmo hash.
En el caso de redes de varias capas de transporte, como Ethernet a través de MPLS o un pseudocable Ethernet, el algoritmo hash debe mirar más allá del encabezado externo de la carga útil y dentro de los encabezados internos para generar una distribución uniforme. Para determinar la encapsulación interna, el PFE se basa en la presencia de ciertos códigos o números en las instalaciones de carga útil fija; por ejemplo, la presencia de un tipo de carga 0X800 o la presencia del número de protocolo 4 para un paquete IPv4. En Junos OS, puede configurar zero-control-word la opción para indicar el inicio de una trama Ethernet en una carga útil de MPLS ether-pseudowire. Al ver esta palabra de control, que son cuatro bytes con un valor numérico de todos ceros, el generador hash asume el inicio de una trama Ethernet al final de la palabra de control en un paquete MPLS ether-pseudowire.
En el caso de las tarjetas basadas en chip de I CPC, configure la zero-control-word opción en el nivel jerárquico; y en el caso de las [edit forwarding-options hash-key family mpls ether-pseudowire] tarjetas MPC, configure la zero-control-word opción en el [edit forwarding-options enhanced-hash-key family mpls ether-pseudowire] nivel jerárquico.
Configuración de la carga encapsulada MPLS para el equilibrio de carga
De forma predeterminada, cuando se utiliza el equilibrio de carga para ayudar a distribuir el tráfico, se utiliza un algoritmo hash para seleccionar una dirección de salto siguiente para instalarla en la tabla de reenvío. Cada vez que el conjunto de los siguientes saltos para un destino cambia de alguna manera, la dirección del siguiente salto se vuelve a seleccionar por medio del algoritmo hash. Configure la zero-control-word opción para indicar el inicio de una trama Ethernet en una carga útil de MPLS ether-pseudowire. Al ver esta palabra de control, cuatro bytes que tienen un valor numérico de todos ceros, el generador hash asume el inicio del marco Ethernet al final de la palabra de control en un paquete MPLS ether-pseudowire.
Antes de comenzar a configurar la carga encapsulada MPLS para el equilibrio de carga, configure los protocolos de enrutamiento y señalización.
Para configurar la carga encapsulada MPLS para el equilibrio de carga:
zero-control-word opción para indicar el inicio de una trama Ethernet en una carga útil de MPLS ether-pseudowire.
-
En el caso de las tarjetas basadas en chip de I CPC, configure la
zero-control-wordopción en el nivel jerárquico[edit forwarding-options hash-key family mpls ether-pseudowire].[edit forwarding-options hash-key family mpls ether-pseudowire] user@host# set zero-control-word
-
En el caso de las tarjetas MPC, configure la
zero-control-wordopción en el nivel jerárquico[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire].[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire] user@host# set zero-control-word
Descripción general de rutas multiruta basadas en políticas
Las redes de enrutamiento por segmentos pueden tener varios protocolos de transporte en el núcleo. Puede combinar enrutamiento por segmentos, rutas SR-TE LDP o RSVP y rutas IP SR-TE, e instalar una ruta multirruta en la base de información de enrutamiento (también conocida como tabla de enrutamiento). A continuación, puede dirigir el tráfico de servicio selectivo mediante la ruta multiruta a través de la configuración de políticas.
- Descripción de rutas multiruta basadas en políticas
- Beneficios de las rutas multiruta basadas en políticas
- Rutas de múltiples rutas basadas en políticas para la resolución de rutas
- Resolución de rutas de ejemplo mediante rutas multiruta basadas en políticas
- Mejora de la política de reenvío de clase de servicio (CoS)
- Mejoras en el protocolo de coincidencia de políticas
- Impacto de la configuración de rutas múltiples basadas en políticas en el rendimiento de la red
Descripción de rutas multiruta basadas en políticas
Hay diferentes protocolos de transporte en una red, como IGP, etiquetados como IGP, RSVP, LDP y los protocolos de ingeniería de tráfico de enrutamiento por segmentos (SR-TE), que se utilizan para resolver el tráfico de servicio. Sin embargo, no puede usar una combinación de los protocolos de transporte para resolver el tráfico de servicio. Con la introducción de la función de multirruta basada en políticas, puede combinar rutas LDP o RSVP de enrutamiento por segmentos con ingeniería de tráfico (SR-TE) y rutas IP de SR-TE para crear una ruta multirruta instalada en la base de información de enrutamiento. Puede resolver las rutas de servicio de BGP a través de la ruta multiruta mediante la configuración de políticas y dirigir el tráfico de manera diferente para distintos prefijos.
Una ruta multirruta tiene saltos siguientes combinados de entradas de ruta que se utilizan para el equilibrio de carga. Todas las rutas de soporte de la entrada de ruta multirruta deben estar en la misma base de información de enrutamiento. Cuando las rutas de soporte están en una base de información de enrutamiento diferente, puede utilizar la rib-group instrucción de configuración para agregar entradas de ruta a una base de información de enrutamiento determinada.
Puede configurar una ruta de multirruta mediante una política para seleccionar la lista de rutas cuyos próximos saltos se van a combinar. Cuando se incluye la policy-multipath instrucción junto con la policy instrucción en el [edit routing-options rib routing-table-name] nivel de jerarquía, se crea una ruta multirruta basada en políticas.
La función de multirruta basada en políticas es compatible con los protocolos IP e IPv6, y puede configurarse en el nivel de [edit routing-instances] jerarquía.
Por ejemplo:
[edit routing-options] user@host# set rib inet.3 policy-multipath policy example-policy [edit policy-options] user@host# set policy-statement example-policy from example-conditions user@host# set policy-options policy-statement example-policy then accept
La política configurada se aplica a cada entrada de ruta para un prefijo determinado. La ruta de multirruta solo se crea cuando más de una ruta (incluida la ruta activa) pasa la política. Cualquier comando de acción configurado en la política, como aplicar, se evalúa mediante la ruta activa. En el caso de las rutas no activas, la política se aplica para comprobar si las rutas pueden participar en la ruta multirruta o no. Las rutas de múltiples rutas heredan todos los atributos de la ruta activa. Estos atributos se pueden modificar mediante la configuración de política de multirruta.
policy-multipath de las rutas, Junos OS y Junos OS Evolved asignan el valor de preferencia de la ruta menos preferida (la numérica más alta) entre las rutas elegibles en lugar de usar la preferencia de la ruta activa. Ignora cualquier preferencia configurada por el usuario aplicada a través de la política de
policy-multipath rutas y siempre aplica el valor de preferencia más alto de las entradas de ruta elegibles.
Junos OS y Junos OS Evolved informan correctamente de los valores de la métrica 2 para las rutas de BGP configuradas con policy-multipath. Cuando el prefijo activo de la ruta es SR-TE y está en proceso de resolución, el sistema refleja con precisión el valor de la métrica 2 en las métricas de ruta. Esta modificación garantiza que las decisiones de enrutamiento se basen en métricas precisas, lo que mejora el rendimiento y la confiabilidad generales de la red.
Beneficios de las rutas multiruta basadas en políticas
-
Ofrece flexibilidad para combinar protocolos de red centrales para dirigir el tráfico selectivo.
-
Optimiza el rendimiento de la red con una multirruta ponderada de igual costo mediante rutas multirrutas.
Rutas de múltiples rutas basadas en políticas para la resolución de rutas
Puede combinar enrutamiento por segmentos con ingeniería de tráfico (SR-TE) y rutas IP de SR-TE e instalar una ruta multirruta en la base de información de enrutamiento. Las rutas de multirruta basadas en políticas no son entradas activas en la base de información de enrutamiento. Cuando se genera una ruta multirruta mediante la configuración de la política, se utiliza para resolver los siguientes saltos de protocolo en lugar de rutas activas. Un próximo salto de ruta multirruta se crea fusionando puertas de enlace de saltos siguientes de cada ruta constituyente.
Tenga en cuenta lo siguiente al configurar rutas de multirruta basadas en políticas para la resolución de rutas:
-
Si la ruta miembro de una ruta multirruta apunta a un próximo salto distinto del próximo salto del enrutador o a un próximo salto indirecto con reenvío del próximo salto al próximo salto del enrutador, dichos próximos saltos se ignorarán.
-
Si las rutas constituyentes apuntan al siguiente salto indirecto, las puertas de enlace del siguiente salto de reenvío se fusionan y se ignora el siguiente salto indirecto.
-
Si la cantidad total de puertas de enlace supera el
maximum-ecmpadmitido en el dispositivo, solo se conservarán lasmaximum-ecmppuertas de enlace y se ignorarán todas las demás puertas de enlace. -
Se da preferencia a las puertas de enlace con pesos más bajos. Cuando una de las rutas miembro tiene unilist de próximos saltos indirectos y cada uno de los siguientes saltos apunta a un próximo salto de reenvío, puede haber valores de peso tanto en el próximo salto indirecto como en el siguiente salto de reenvío. En tales casos, el valor de peso de las pasarelas se actualiza para reflejar el efecto combinado de los pesos en ambos niveles.
Resolución de rutas de ejemplo mediante rutas multiruta basadas en políticas
Tomando como ejemplo, supongamos que hay LSP de enrutamiento por segmentos diseñados para el tráfico, rutas SI-SI de etiqueta y LSP de LDP para un destino 10.1.1.1/32, como se muestra en el resultado a continuación:
10.1.1.1/32 *[SPRING-TE/8] 00:00:58, metric 1, metric2 30
> to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
[L-ISIS/14] 1w0d 00:15:57, metric 10
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[LDP/19] 1w0d 00:09:27, metric 1
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
Aquí, el LSP de enrutamiento por segmentos es la entrada de ruta activa al destino 10.1.1.1 y, de forma predeterminada, solo se usa esta ruta para resolver cualquier servicio que se resuelva a través de 10.1.1.1.
Cuando se requiere utilizar más de un protocolo para resolver rutas de servicio, puede lograrlo configurando policy-multirruta para combinar los protocolos. Por ejemplo, si se requieren rutas de enrutamiento por segmentos y LDP para la resolución de servicios, debe configurar policy-multipath la combinación del enrutamiento por segmentos y las rutas de LDP para el prefijo 10.1.1.1.
Por ejemplo:
[edit policy-options] user@host# set rib inet.3 policy-multipath policy example-policy user@host# set policy-statement abc term 1 from protocol spring-te user@host# set policy-statement abc term 1 from protocol ldp user@host# set policy-statement abc term 1 from route-filter 10.1.1.1/32 exact user@host# set policy-statement abc term 1 then accept
Con esta configuración, se crea una ruta multirruta basada en políticas para el prefijo 10.1.1.1/32 que utiliza entradas de ruta constituyentes de enrutamiento por segmentos y protocolos LDP.
Puede ver la ruta de multirruta utilizando el comando de salida siguiente show route :
10.1.1.1/32 *[SPRING-TE/8] 00:10:28, metric 1, metric2 30
> to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
[L-ISIS/14] 1w0d 00:25:27, metric 10
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[LDP/19] 1w0d 00:18:57, metric 1
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[Multipath/8] 00:03:13, metric 1, metric2 30
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
Puede ver en la salida del comando que la ruta de multirruta combina los siguientes saltos de enrutamiento de segmentos y rutas de LDP. La ruta multirruta no está activa y, de forma predeterminada, la preferencia de ruta y la métrica son las mismas que las de la ruta activa.
Puede utilizar las siguientes combinaciones para la ruta multirruta basada en poilcy: Sin embargo, no podemos crear una multirruta de LDP/L-SI-SI, ya que la ruta activa no forma parte de la multirruta.
-
LSP de enrutamiento por segmentos y LSP de LDP diseñados para el tráfico.
-
LSP de enrutamiento por segmentos diseñados para tráfico y rutas SI-SI de etiqueta.
-
LSP de enrutamiento por segmentos y LSP de LDP diseñados para el tráfico y rutas de etiqueta SI-SI.
Sin embargo, no puede crear una ruta multirruta de LDP ni etiquetar como SI-SI, ya que la ruta activa no forma parte de la ruta multirruta.
Con la misma configuración, suponiendo que existe una ruta estática 1.2.3.4/32 configurada con un protocolo de próximo salto de 10.1.1.1, esta ruta se resuelve mediante la ruta de multirruta tanto con LSP de enrutamiento de segmentos como con LSP de LDP.
Por ejemplo:
10.1.3.4/32 *[Static/5] 00:00:12, metric2 1
to 10.12.1.1 via ge-0/0/0.1
> to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
Mejora de la política de reenvío de clase de servicio (CoS)
Para el reenvío basado en clase de servicio, debe utilizar la forwarding-policy next-hop-map instrucción configuration.
Antes de Junos OS versión 19.1R1, las condiciones de coincidencia admitidas en el reenvío basado en clase de servicio incluían:
-
next-hop: hacer coincidir el siguiente salto según la interfaz de salida o la dirección del próximo salto.
-
lsp-next-hop: hacer coincidir los LSP con nombre mediante la expresión regular del nombre del LSP.
-
non-lsp-next-hop: hacer coincidir todos los LSP sin un nombre de LSP.
Con la función de ruta multirruta basada en políticas, también puede hacer coincidir todos los saltos siguientes sin una etiqueta para determinados prefijos. Para ello, debe habilitar la non-labelled-next-hop opción en el nivel jerárquico [edit class-of-service forwarding-policy next-hop-map map-name forwarding-class forwarding-class-name .
Por ejemplo:
[edit]
class-of-service {
forwarding-policy {
next-hop-map abc {
forwarding-class best-effort {
non-labelled-next-hop;
}
}
}
}
Mejoras en el protocolo de coincidencia de políticas
Antes de Junos OS versión 19.1R1, cuando se usaba una política para hacer coincidir el protocolo mediante la from protocol instrucción en el nivel de [edit policy-options policy-statement statement-name] jerarquía, todas las rutas de protocolo (etiquetadas y sin etiquetar) coincidían. Con la función de ruta multirruta basada en políticas, puede hacer coincidir rutas de protocolo etiquetadas específicamente.
Las opciones para hacer coincidir los protocolos etiquetados son:
-
l-isis: coincidir con rutas etiquetadas como SI-SI. La
isisopción coincide con las rutas SI-SI, excluyendo las rutas SI-SI de etiqueta. -
l-ospf: coincida con las rutas de OSPF. La
ospfopción hace coincidir todas las rutas de OSPF, incluidas OSPFv2, OSPFv3 y etiqueta de OSPF.
Por ejemplo:
[edit]
policy-options {
policy-statement abc {
from protocol [ l-ospf l-isis ];
}
}
Impacto de la configuración de rutas múltiples basadas en políticas en el rendimiento de la red
Cuando configure una ruta multirruta basada en políticas, un cambio de ruta en la base de información de enrutamiento da como resultado la evaluación de la política para comprobar si es necesario crear una ruta multirruta. Dado que esta característica requiere que las rutas miembro estén en la misma base de información de enrutamiento, la rib-group instrucción se utiliza para fusionar rutas de diferentes bases de información de enrutamiento. La configuración de la rib-group instrucción a nivel de aplicación aumenta el número de rutas en el sistema.
Cuando hay varias rutas en la base de información de enrutamiento, el cambio constante de rutas conduce a la reevaluación de la política de multirruta. Esto podría afectar el rendimiento de la red. Se recomienda configurar la función de ruta multirruta basada en políticas solo cuando sea necesario.
Descripción del filtrado basado en IP y la duplicación selectiva de puertos del tráfico MPLS
En un paquete MPLS, el encabezado IP viene inmediatamente después del encabezado MPLS. La función de filtrado basado en IP proporciona un mecanismo de inspección profunda, en el que se pueden inspeccionar hasta ocho etiquetas MPLS de la carga interna para habilitar el filtrado del tráfico MPLS según parámetros IP. El tráfico MPLS filtrado también se puede duplicar en un puerto de un dispositivo de monitoreo para ofrecer servicios basados en red en la red MPLS central.
- Filtrado basado en IP del tráfico MPLS
- Imitación selectiva de puertos del tráfico MPLS
- Configuraciones de muestra
Filtrado basado en IP del tráfico MPLS
Antes de Junos OS versión 18.4R1, el filtrado basado en parámetros IP no era compatible con el filtro de familia MPLS. Con la introducción de la función de filtrado basado en IP, puede aplicar filtros de entrada y salida para paquetes IPv4 e IPv6 etiquetados con MPLS en función de parámetros IP, como direcciones de origen y destino, tipo de protocolo de capa 4 y puertos de origen y destino.
La función de filtrado basado en IP permite filtrar paquetes MPLS en la entrada de una interfaz, donde el filtrado se realiza mediante condiciones de coincidencia en la carga interna del paquete MPLS. A continuación, el tráfico MPLS selectivo se puede duplicar en puerto a un dispositivo de supervisión remota mediante túneles lógicos.
Para admitir el filtrado basado en IP, se agregan condiciones de coincidencia adicionales que permiten que los paquetes MPLS se inspeccionen en profundidad para analizar la carga interna con los encabezados de capa 3 y capa 4 antes de aplicar los filtros adecuados.
La función de filtrado basado en IP solo se admite para paquetes IPv4 e IPv6 etiquetados con MPLS. En otras palabras, los filtros MPLS coinciden con los parámetros IP solo cuando la carga IP viene inmediatamente después de las etiquetas MPLS.
En otros escenarios, donde la carga de MPLS incluye pseudocables, protocolos distintos de inet e inet6, u otras encapsulaciones como VPN de capa 2 o VPLS, no se admite la función de filtrado basado en IP.
Se agregan las siguientes condiciones de coincidencia para el filtrado basado en IP del tráfico MPLS:
-
Dirección de origen IPv4
-
Dirección de destino IPv4
-
Dirección de origen IPv6
-
Dirección de destino IPv6
-
Protocolo
-
Puerto de origen
-
Puerto de destino
-
Lista de prefijos IPv4 de origen
-
Lista de prefijos IPv4 de destino
-
Lista de prefijos IPv6 de origen
-
Lista de prefijos IPv6 de destino
Se admiten las siguientes combinaciones de coincidencias para el filtrado basado en IP del tráfico MPLS:
-
Las condiciones de coincidencia de direcciones de origen y destino con listas de prefijos IPv4 e IPv6.
-
Los tipos de dirección y protocolo de puerto de origen y destino coinciden con condiciones con listas de prefijos IPv4 e IPv6.
Imitación selectiva de puertos del tráfico MPLS
La duplicación de puerto es la capacidad de reflejar un paquete en un destino configurado, además del procesamiento y reenvío normales de los paquetes. La duplicación de puertos se aplica como una acción para un filtro de firewall, que se aplica en la entrada o salida de cualquier interfaz. De manera similar, la función de duplicación selectiva de puertos proporciona la capacidad de reflejar el tráfico MPLS, que se filtra en función de parámetros IP, a un destino reflejado mediante túneles lógicos.
Para habilitar la duplicación selectiva de puertos, se configuran acciones adicionales en el nivel de [edit firewall family mpls filter filter-nameterm term-name then] jerarquía, además de las acciones y acciones existentesacceptcounterdiscard:
-
port-mirror -
port-mirror-instance
Port Mirroring
La port-mirror acción habilita la duplicación de puertos globalmente en el dispositivo, lo que se aplica a todos los motores de reenvío de paquetes (PFE) y las interfaces asociadas.
Para el filtro de familia MPLS, la acción está habilitada para la port-mirror duplicación de puerto global.
Port Mirroring Instance
La port-mirror-instance acción permite personalizar cada instancia con diferentes propiedades para el muestreo de entrada y los destinos de salida de la duplicación de puertos, en lugar de tener que utilizar una única configuración para todo el sistema para la duplicación de puertos.
Solo puede configurar dos instancias de duplicación de puerto por concentrador de PIC flexible (FPC) incluyendo la instance port-mirror-instance-name instrucción en el nivel de [edit forwarding-options port-mirror] jerarquía. A continuación, puede asociar instancias de duplicación de puertos individuales con una FPC, PIC o (Placa de motor de reenvío (FEB), según el hardware del dispositivo.
Para el filtro de familia MPLS, la port-mirror-instance acción solo está habilitada para la instancia de duplicación de puertos.
Para ambas port-mirror port-mirror-instance acciones, la interfaz de salida debe estar habilitada con la familia de capa 2 y no con la familia MPLS (capa 3) para que funcione la función de duplicación selectiva de puertos.
Configuraciones de muestra
- Configuración de filtrado basada en IP
- Configuración de imitación selectiva de puertos
- Configuración de destino reflejado
Configuración de filtrado basada en IP
[edit firewall family mpls filter mpls-filter]
term ipv4-term {
from {
ip-version {
ipv4 {
source-address {
10.10.10.10/24;
}
destination-address {
20.20.20.20/24;
}
protocol tcp {
source-port 100;
destination-port 200;
}
soure-prefix-list ipv4-source-users;
destination-prefix-list ipv4-destination-users;
}
}
exp 1;
}
then port-mirror;
then accept;
then count;
}
term ipv6-term {
from {
ip-version {
ipv6 {
source-address {
2000::1/128;
}
destination-address {
3000::1/128;
}
protocol tcp {
source-port 100;
destination-port 200;
}
source-prefix-list ipv6-source-users;
destination-prefix-list ipv6-destination-users;
}
}
exp 1;
}
then port-mirror-instance port-mirror-instance1;
then accept;
then count;
}
[edit policy-options]
prefix-list ipv4-source-users {
172.16.1.16/28;
172.16.2.16/28;
}
prefix-list ipv6-source-users {
2001::1/128;
3001::1/128;
}
[edit interfaces]
xe-0/0/1 {
unit 0 {
family inet {
address 100.100.100.1/30;
}
family mpls {
filter {
input mpls-filter;
}
}
}
}
Configuración de imitación selectiva de puertos
[edit forwarding-options]
port-mirroring {
input {
rate 2;
run-length 4;
maximum-packet-length 500;
}
family any {
output {
interface xe-2/0/2.0;
}
}
}
[edit forwarding-options]
port-mirroring {
instance {
port-mirror-instance1 {
input {
rate 3;
run-length 5;
maximum-packet-length 500;
}
family any {
output {
interface xe-2/0/2.0;
}
}
}
}
}
La interfaz xe-2/0/2.0 de salida está configurada para la familia de capa 2 y no para la familia MPLS.
Para ambas port-mirror port-mirror-instance acciones, la interfaz de salida debe estar habilitada con la familia de capa 2 y no con la familia MPLS (capa 3) para que funcione la función de duplicación selectiva de puertos.
Configuración de destino reflejado
[edit interfaces]
xe-2/0/2 {
vlan-tagging;
encapsulation extended-vlan-bridge;
unit 0 {
vlan-id 600;
}
}
[edit bridge-domains]
bd {
domain-type bridge;
interface xe-2/0/2.0;
}
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.