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 carga encapsulada MPLS
Configuración de la carga encapsulada MPLS para el equilibrio de carga
Descripción general de las rutas multiruta basadas en políticas
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 MPLS en 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 saltos siguientes para un destino, la dirección del salto siguiente se vuelve a seleccionar mediante el algoritmo hash. Puede configurar cómo se usa el algoritmo hash para equilibrar la carga del tráfico en un conjunto de rutas conmutadas por etiqueta (LSP) de igual costo.
Para garantizar la entropía del tráfico VPLS y VPWS, Junos OS puede crear un hash basado en los 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 utilizan etiquetas (como MPLS Fast Reroute y RFC 3107, RSVP y VPN), los datos de las tres etiquetas principales pueden volverse estáticos y, por lo tanto, no ser una fuente suficiente de entropía. Como resultado, el equilibrio de carga puede sesgarse o la incidencia de la entrega de paquetes fuera de orden puede aumentar. Para estos casos, se pueden utilizar etiquetas de la parte inferior de la pila de etiquetas (consulte la Tabla 1, a continuación para conocer las calificaciones). Las etiquetas superiores e inferiores no se pueden utilizar al mismo tiempo.
Las tarjetas MPC no admiten la configuración normal de claves hash. Para que la configuración de la clave hash basada en MPC sea eficaz, necesita una enhanced-hash-key configuración.
El equilibrio de carga se utiliza para distribuir uniformemente el tráfico cuando se cumplen las siguientes condiciones:
Hay varios próximos saltos de igual costo en diferentes interfaces hacia el mismo destino.
Hay un único salto siguiente sobre una interfaz agregada.
Un LSP tiende a equilibrar la carga de su colocación seleccionando aleatoriamente uno de los siguientes saltos de igual costo y usándolo exclusivamente. La selección aleatoria se realiza de forma independiente en cada enrutador de tránsito, que compara solo las métricas del Protocolo de puerta de enlace interior (IGP). No se tiene en cuenta el ancho de banda ni los niveles de congestión.
Esta función se aplica a las interfaces Ethernet agregadas y SONET/SDH agregadas, así como a múltiples próximos saltos MPLS de igual costo. Además, solo en los enrutadores serie T, MX, M120 y 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 la información IP. La opción de incluir información IP en la tecla hash proporciona compatibilidad con conexiones de conexión cruzada de circuitos Ethernet (CCC).
Para equilibrar la carga según 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 jerárquicos:
[edit forwarding-options hash-key]
Tabla 1 proporciona información detallada sobre todas las posibles opciones de equilibrio de carga de MPLS LSP.
Declaración |
Plataformas compatibles |
Opciones de equilibrio de carga de MPLS LSP |
|---|---|---|
|
Serie MX y PTX |
Antes de Junos OS versión 19.1R1, se incluían hasta ocho etiquetas MPLS en la clave hash para identificar la singularidad 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 Junos OS versión 19.1R1, para los enrutadores serie MX con interfaces MPC y MIC, se incluyen hasta dieciséis etiquetas MPLS entrantes en la clave hash. |
|
Serie MX con DPC (I-Chip). No es compatible con M10i, M7i y M120. |
Utiliza la etiqueta de la parte inferior para calcular la clave hash, por ejemplo, si las etiquetas superiores no proporcionan una variable suficiente para el nivel de entropía requerido. |
|
Serie MX con DPC (I-Chip). No es compatible con M10i, M7i y M120. |
Utiliza la segunda etiqueta de la parte inferior para calcular la clave hash, por ejemplo, si las etiquetas superiores no proporcionan una variable suficiente para el nivel de entropía requerido. |
|
Serie MX con DPC (I-Chip). No es compatible con M10i, M7i y M120. |
Utiliza la tercera etiqueta de la parte inferior para calcular la clave hash, por ejemplo, si las etiquetas superiores no proporcionan una variable suficiente 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 |
Incluye la tercera etiqueta en la clave hash. También debe configurar la |
|
Todo |
Excluye 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 Para 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 medio del flujo. Como resultado, es posible que los paquetes se reordenen. Al excluir el bit EXP de la clave hash, puede evitar este problema de reordenación. |
|
Todo |
Permite configurar qué partes de la carga del paquete IP incluir en la clave hash. Para el enrutador de transporte de paquetes de la serie PTX, este valor se establece de forma predeterminada. |
|
Serie PTX |
Excluya la carga IP de la clave hash. |
|
M120, M320, serie MX, serie T |
Equilibre la carga del tráfico IPv4 a través de pseudocables Ethernet de capa 2. |
|
Todo |
Incluya la dirección IPv4 o IPv6 en la clave hash. También debe configurar o |
|
Todo |
Incluya solo la información de IP de capa 3 en la clave hash. Excluye todos los |
|
Serie M, Serie MX, Serie T |
Incluya la información de los campos del puerto de origen y destino. De forma predeterminada, el byte más significativo y el byte menos significativo de los campos puerto de origen y destino se utilizan en la clave hash. Para seleccionar bytes específicos para usarlos 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 las formas en 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 para lapayloadinstrucció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 los enrutadores de transporte de paquetes de la serie PTX, las opciones y
ip payloadestán configuradas de forma predeterminada, por lo que no es necesaria ningunaall-labelsconfiguración.
(Solo enrutadores de las series M320 y 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 únicamente en los enrutadores de las series M320 y T. Si los incluye en un enrutador perimetral multiservicio de la serie M, solo se utilizan la primera etiqueta MPLS y la carga IP en la clave hash.
En el caso de los enrutadores de la serie T, garantice un equilibrio de carga adecuado incluyendo las opciones ,
label-1label-2, ylabel-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) Para 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 medio del flujo. Como resultado, es posible que los paquetes se reordenen. Al excluir el bit EXP de la clave hash, puede evitar este problema de reordenación. Para excluir el bit EXP de la primera etiqueta de los cálculos hash, incluya la
no-label-1-expinstrucción en el nivel de[edit forwarding-options hash-key family mpls]jerarquía:[edit forwarding-options hash-key family mpls] label-1; no-label-1-exp; payload { ip; }
Ejemplo: Red MPLS con equilibrio de carga
Cuando configura 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, uno de los LSP se selecciona 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 tránsito, según el tipo de equilibrio de carga configurado.
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 R1de entrada. La red de ejemplo utiliza Open Shortest Path First (OSPF) como protocolo de puerta de enlace interior (IGP) con área 0.0.0.0OSPF. Se requiere un IGP para el LSP de ruta restringida más corta primero (CSPF), que es el predeterminado para Junos OS. Además, la red de ejemplo utiliza una política para crear tráfico BGP.
La red que se muestra en Figura 1 consta de los siguientes componentes:
Una topología BGP interior de malla completa (IBGP), usando AS 65432
MPLS y RSVP habilitados en todos los enrutadores
Una política de estadísticas de envío en enrutadores R1 y R0 que permite anunciar una nueva ruta en la red
Cuatro LSP unidireccionales entre R1 y , R0y 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 Figura 1 es una red BGP de malla completa. Dado que los reflectores de ruta y las confederaciones no se utilizan para propagar las rutas aprendidas del BGP, cada enrutador debe tener una sesión de BGP con todos los demás enrutadores que ejecuten BGP.
Configuraciones de enrutador para la red MPLS de carga equilibrada
- Propósito
- Acción
- Ejemplo de salida 1
- Ejemplo de salida 2
- Ejemplo de salida 3
- Ejemplo de salida 4
- Ejemplo de salida 5
- Ejemplo 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 ilustrada en Topología de red de equilibrio de carga.
Acción
Para mostrar la configuración de un enrutador, utilice el siguiente comando del modo operativo de la CLI de Junos OS:
user@host> show configuration | no-more
Ejemplo de salida 1
El siguiente resultado de configuración es para enrutador perimetral 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
}
}
}
}
Ejemplo de salida 2
El siguiente resultado de configuración es para el enrutador R1de entrada.
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;
}
}
}
Ejemplo de salida 3
El siguiente resultado de configuración es para enrutador R2de tránsito.
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
}
}
}
}
Ejemplo de salida 4
El siguiente resultado de configuración es para enrutador R4de tránsito.
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
}
}
}
}
Ejemplo de salida 5
El siguiente resultado de configuración es para enrutador R9de tránsito.
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
}
}
}
}
Ejemplo de salida 6
El siguiente resultado de configuración es para enrutador R0de salida.
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 muestra del 1 al 6 muestran las interfaces base, las opciones de enrutamiento, los protocolos y las configuraciones de opciones de política para los seis enrutadores en la red de ejemplo ilustrada en el ejemplo: Red MPLS con equilibrio de carga.
Todos los enrutadores de la red tienen MPLS, RSVP y BGP habilitados. OSPF está configurado como 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 de OSPF para garantizar que los protocolos no se ejecuten en la interfaz de circuito cerrado (lo0) y que la interfaz de circuito cerrado (lo0) se anuncie correctamente en toda la red.
Muestre los resultados 1, 3, 4 y 5 para R6, R2, R4y R9 muestre 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 relevantes (RSVP, MPLS, BGP y OSPF).
La salida de muestra 2 del enrutador R1 de entrada muestra la configuración base más cuatro LSP (lsp1 a través lsp4) de configurado para R0. Los cuatro LSP están configurados con rutas principales diferentes que especifican un salto suelto para R4lsp1 y lsp4, y un salto R2 para lsp2 y lsp3.
Para crear tráfico, R1 tiene una ruta estática (100.100.1.0/24) configurada en el nivel de [edit routing-options static route] jerarquía. El prefijo se incluye en la política send-statics en el nivel jerárquico [edit policy-options send statics] para que las rutas puedan convertirse en rutas BGP.
Además, en el enrutador R1de entrada, el equilibrio de carga se configura mediante la per-packet opción y la directiva se exporta en el nivel de [edit routing-options forwarding-table] jerarquía.
La salida de muestra 6 del enrutador R0 de salida muestra un LSP (r0-r6) que R6 se utilizará 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 en el LSP, solo se envía tráfico de usuarios a través del LSP. El enrutador utiliza su copia local de la base de datos IGP para verificar 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 send-statics en el nivel jerárquico [edit policy-options send statics] para que las rutas puedan convertirse en rutas BGP.
Configuración del equilibrio de carga basado en etiquetas MPLS en enrutadores de la serie ACX
Tabla 2 proporciona información detallada sobre todas las posibles opciones de equilibrio de carga de MPLS LSP.
Los enrutadores de la serie ACX 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. Esta función 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 solo salto siguiente en una interfaz agregada o un paquete LAG. El equilibrio de carga mediante etiquetas MPLS solo se admite para interfaces LAG y no para vínculos de rutas múltiples 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 saltos siguientes para un destino cambia de alguna manera, la dirección del siguiente salto se vuelve a seleccionar mediante el algoritmo hash. Puede configurar cómo se usa el algoritmo hash para equilibrar la carga del tráfico entre interfaces en una interfaz Ethernet agregada (ae).
Un LSP tiende a equilibrar la carga de su ubicación seleccionando aleatoriamente una de las interfaces en un ae- paquete de interfaces y usándola exclusivamente. La selección aleatoria se realiza de forma independiente en cada enrutador de tránsito, que compara solo las métricas del Protocolo de puerta de enlace interior (IGP). No se tiene en cuenta el ancho de banda ni los niveles de congestión.
En los enrutadores de la serie ACX, no se admite el equilibrio de carga en las rutas conmutadas etiquetadas (LSP) para el servicio LAN privada virtual (VPLS), el circuito L2 y la red privada virtual de capa 2 (L2VPN).
Para equilibrar la carga según 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 jerárquico [edit forwarding-options hash-key] .
Cuando configura la carga ip (user@host# set forwarding-options hash-key family mpls payload ip), configurando layer-3-only y port-data es obligatorio.
La funcionalidad de equilibrio de carga, sin la configuración adecuada de las claves hash, puede dar lugar a un comportamiento impredecible.
Para la terminación de túnel VPN/pseudowire de capa 2, se utilizan hasta dos etiquetas para hashing y 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 MPLS de familia bajo la configuración de clave hash que se muestra arriba. Sin embargo, dado que ACX2000 y ACX4000 también admiten pseudocables TDM, las perillas de éter-pseudocable deben usarse solo cuando no se usan pseudocables TDM.
Para la terminación del túnel VPN de capa 3, se utilizan hasta dos etiquetas para tener y cargar direcciones IP de origen y destino, y opcionalmente se pueden seleccionar puertos de origen y destino de capa 4. Estos controles se pueden usar para admitir perillas de datos de puerto IP en MPLS de familia en la configuración de clave hash que se muestra arriba. Sin embargo, dado que el MSB y el LSB del puerto de capa 4 no se pueden seleccionar individualmente, una de las perillas de destino-lsb o destino-msb o una de las perillas fuente-lsb o fuente-msb seleccionaría los puertos de destino o origen de la capa 4, respectivamente.
Para el caso de LSR, se utilizan hasta tres etiquetas para hashing. Si se ve un BOS al analizar las tres primeras etiquetas, BCM examina el primer bocado de carga útil: si el mordisco es 4, la carga útil se trata como IPv4 y si el primer bocado 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 hashing. Estos controles se pueden usar para admitir perillas de datos de puerto IP en MPLS de familia bajo configuración de clave hash. Sin embargo, los puertos de capa 4 no se pueden usar para hashing en el caso de LSR, y solo se aplica la perilla de solo capa 3. BCM no afirma que admita hashing 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 el 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 interfaces LSR AE se puede lograr para un mayor número de sesiones MPLS, es decir, un mínimo de 10 sesiones. Esto es aplicable para CCC/VPLS/L3VPN. En el caso de VPN de capa 3, es posible que el tráfico no se distribuya equitativamente entre los enlaces de los miembros, 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 realizar hashing basado en campos de capa 3 y capa 4 configurando la opción de carga útil en la jerarquía "familia mpls". El hashing 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 las 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 MPLS IP.
Esta función se aplica a las 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 la información IP. La opción de incluir información IP en la tecla hash proporciona compatibilidad con conexiones de conexión cruzada de circuitos Ethernet (CCC).
|
Declaración |
Opciones de equilibrio de carga de MPLS LSP |
|---|---|
|
|
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 |
|
|
Incluye la tercera etiqueta en la clave hash. También debe configurar la |
|
|
Excluye etiquetas MPLS de la clave hash. |
|
|
Permite configurar qué partes de la carga del paquete IP incluir 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 a través de 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 de IP de capa 3 en la clave hash. Excluye todos los |
|
|
Incluya la información de los campos del puerto de origen y destino. De forma predeterminada, el byte más significativo y el byte menos significativo de los campos puerto de origen y destino se utilizan en la clave hash. Para seleccionar bytes específicos para usarlos 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 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;
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 opciones , label-1label-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 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 uniformemente el tráfico cuando se cumplen las siguientes condiciones:
Hay varios próximos saltos de igual costo en diferentes interfaces hacia el mismo destino.
Hay un único salto siguiente sobre una interfaz agregada.
De forma predeterminada, cuando se usa el equilibrio de carga para ayudar a distribuir el tráfico, se usa 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 saltos siguientes para un destino cambia de alguna manera, la dirección del siguiente salto se vuelve a seleccionar mediante el algoritmo hash.
En el caso de redes de múltiples capas de transporte, como Ethernet a través de MPLS o 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 ofertas de carga útil fijas; por ejemplo, la presencia del tipo de carga 0X800 o la presencia del protocolo número 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 MPLS ether-pseudowire. Al ver esta palabra de control, que son cuatro bytes con un valor numérico de todos los ceros, el generador hash asume el inicio de una trama Ethernet al final de la palabra de control en un paquete MPLS ether-pseudowire.
Para las tarjetas basadas en DPC I-chip, configure la zero-control-word opción en el nivel de [edit forwarding-options hash-key family mpls ether-pseudowire] jerarquía; y para las tarjetas MPC, configure la zero-control-word opción en el nivel de [edit forwarding-options enhanced-hash-key family mpls ether-pseudowire] jerarquía.
Configuración de la carga encapsulada MPLS para el equilibrio de carga
De forma predeterminada, cuando se usa el equilibrio de carga para ayudar a distribuir el tráfico, se usa 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 saltos siguientes para un destino cambia de alguna manera, la dirección del siguiente salto se vuelve a seleccionar mediante el algoritmo hash. Configure la zero-control-word opción para indicar el inicio de una trama Ethernet en una carga MPLS de éter-pseudocable. Al ver esta palabra de control, cuatro bytes con un valor numérico de todos los ceros, el generador hash asume el inicio de la trama 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 MPLS de éter-pseudocable. Para las tarjetas basadas en DPC I-chip, 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
Para tarjetas MPC, configure la
zero-control-wordopción en el nivel de[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire]jerarquía.[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire] user@host# set zero-control-word
Descripción general de las rutas multiruta basadas en políticas
Las redes de enrutamiento por segmentos pueden tener varios protocolos de transporte en el núcleo. Puede combinar rutas SR-TE LDP o RSVP de enrutamiento de segmentos y rutas IP de SR-TE, e instalar una ruta de varias rutas 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 mutlipath mediante la configuración de directivas.
- Descripción de las rutas multiruta basadas en políticas
- Beneficios de las rutas multiruta basadas en políticas
- Rutas multiruta 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 las rutas multiruta basadas en políticas
Existen diferentes protocolos de transporte en una red, como IGP, IGP, RSVP, LDP y 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 podía utilizar una combinación de protocolos de transporte para resolver el tráfico de servicio. Con la introducción de la función multiruta basada en políticas, puede combinar rutas LDP o RSVP de enrutamiento de segmentos diseñadas por tráfico (SR-TE) y rutas IP SR-TE para crear una ruta múltiple instalada en la base de información de enrutamiento. Puede resolver rutas de servicio BGP en la ruta multiruta mediante la configuración de políticas y dirigir el tráfico de manera diferente para distintos prefijos.
Una ruta multiruta ha combinado los siguientes saltos de entradas de ruta que se utilizan para el equilibrio de carga. Todas las rutas admitidas de la entrada de ruta múltiple deben estar en la misma base de información de enrutamiento. Cuando las rutas auxiliares se encuentran en una base de información de enrutamiento diferente, puede utilizar la instrucción configuration para agregar entradas de ruta a una base de rib-group información de enrutamiento determinada.
Puede configurar una ruta de varias rutas mediante una política para seleccionar la lista de rutas cuyos próximos saltos se van a combinar entre sí. Cuando se incluye la policy-multipath instrucción junto con la policy instrucción en el nivel de [edit routing-options rib routing-table-name] jerarquía, se crea una ruta de múltiples rutas basada en políticas.
La característica de múltiples rutas basada en políticas es compatible con los protocolos IP e IPv6, y se puede configurar 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 multiruta solo se crea cuando más de una ruta (incluida la ruta activa) pasa la política. Todos los comandos de acción configurados en la política, como apply, se evalúan mediante la ruta activa. Para rutas no activas, la política se aplica para comprobar si las rutas pueden participar en la ruta multiruta o no. Las rutas de varias rutas heredan todos los atributos de la ruta activa. Estos atributos se pueden modificar mediante la configuración de directiva de múltiples rutas.
Beneficios de las rutas multiruta basadas en políticas
-
Ofrece flexibilidad para combinar protocolos de red principales para dirigir el tráfico selectivo.
-
Optimiza el rendimiento de la red con múltiples rutas ponderadas y de igual costo mediante rutas múltiples.
Rutas multiruta basadas en políticas para la resolución de rutas
Puede combinar rutas LDP o RSVP de ingeniería de tráfico de enrutamiento de segmentos (SR-TE) y rutas IP de SR-TE, e instalar una ruta de varias rutas en la base de información de enrutamiento. Las rutas multiruta basadas en políticas no son entradas activas en la base de información de enrutamiento. Cuando se genera una ruta de varias rutas mediante la configuración de la directiva, se utiliza para resolver los siguientes saltos de protocolo en lugar de las rutas activas. El siguiente salto de una ruta múltiple se crea mediante la combinación de puertas de enlace de los siguientes saltos de cada ruta constituyente.
Tenga en cuenta lo siguiente al configurar rutas multiruta basadas en políticas para la resolución de rutas:
-
Si la ruta miembro de una ruta de varias rutas apunta a un siguiente salto distinto del siguiente salto del enrutador o a un salto siguiente indirecto con reenvío del siguiente salto al siguiente salto del enrutador, estos saltos siguientes se ignoran.
-
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 el número total de puertas de enlace supera el
maximum-ecmpadmitido en el dispositivo, solo se conservan lasmaximum-ecmppuertas de enlace y se ignoran 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 una lista de saltos indirectos siguientes y cada uno de los siguientes saltos apunta a un siguiente salto de reenvío, puede haber valores de peso tanto en el siguiente 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 las pesas en ambos niveles.
Resolución de rutas de ejemplo mediante rutas multiruta basadas en políticas
Tomando como ejemplo, supongamos que hay LSP diseñados por tráfico de enrutamiento de segmentos, rutas IS-IS etiquetadas y LSP LDP para un destino 10.1.1.1/32, como se muestra en la siguiente salida:
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 resuelva más de 10.1.1.1.
Cuando se requiere usar más de un protocolo para resolver rutas de servicio, puede lograrlo configurando policy-multipath para combinar los protocolos. Por ejemplo, si se requieren rutas de enrutamiento de segmentos y LDP para la resolución del servicio, debe configurar policy-multipath la combinación del enrutamiento de seleccióny las rutas 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 múltiple basada en políticas para el prefijo 10.1.1.1/32 que utiliza entradas de ruta constituyentes de enrutamiento de segmentos y protocolos LDP.
Puede ver la ruta de múltiples rutas mediante el resultado del show route comando, de la siguiente manera:
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)
En el resultado del comando, puede ver que la ruta multiruta combina los siguientes saltos de enrutamiento de segmentos y rutas LDP. La ruta multiruta 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 usar las siguientes combinaciones para la ruta multiruta basada en poilcy: Sin embargo, no podemos crear múltiples rutas de LDP/L-ISIS, ya que la ruta activa no forma parte de la ruta múltiple.
-
LSP y LSP de LDP diseñados para el tráfico de enrutamiento por segmentos.
-
Segmente los LSP diseñados por el tráfico de enrutamiento de segmentos y etiquete las rutas IS-IS.
-
Enrutamiento por segmentos de tráfico diseñado LSP, LSP LDP y etiquetas de rutas IS-IS.
Sin embargo, no puede crear una ruta de varias rutas de LDP ni etiquetar IS-IS, ya que la ruta activa no forma parte de la ruta de varias rutas.
Con la misma configuración, suponiendo que existe una ruta estática 1.2.3.4/32 configurada con un siguiente salto de protocolo de 10.1.1.1, esta ruta se resuelve utilizando la ruta multiruta sobre los LSP de ingeniería de tráfico de enrutamiento de segmentos y los 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 usar la instrucción configuration forwarding-policy next-hop-map .
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: hace coincidir el próximo salto según la interfaz saliente o la dirección del siguiente salto.
-
lsp-next-hop: hace coincidir los LSP con nombre mediante la expresión regular del nombre LSP.
-
non-lsp-next-hop: hace coincidir todos los LSP sin un nombre LSP.
Con la función de ruta múltiple basada en políticas, también puede hacer coincidir todos los saltos siguientes sin una etiqueta para ciertos prefijos. Para ello, debe habilitar la non-labelled-next-hop opción en el nivel de [edit class-of-service forwarding-policy next-hop-map map-name forwarding-class forwarding-class-name jerarquía.
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 utilizaba una política para hacer coincidir el protocolo mediante la from protocol instrucción en el nivel de jerarquía, todas las rutas de [edit policy-options policy-statement statement-name] protocolo (etiquetadas y sin etiquetar) coincidían. Con la función de ruta de múltiples rutas basada en políticas, puede hacer coincidir específicamente rutas de protocolo etiquetadas.
Las opciones para hacer coincidir los protocolos etiquetados) son:
-
l-isis: hace coincidir las rutas etiquetadas como IS-IS. La
isisopción coincide con las rutas IS-IS, excluyendo las rutas IS-IS etiquetadas. -
l-ospf: Hacer coincidir las rutas OSPF labladas. La
ospfopción coincide con todas las rutas de OSPF, incluidos OSPFv2, OSPFv3 y etiquetar 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 se configura una ruta múltiple basada en directivas, un cambio de ruta en la base de información de enrutamiento da como resultado la evaluación de la directiva para comprobar si es necesario crear una ruta multiruta. 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 combinar rutas de diferentes bases de información de enrutamiento. La configuración de la rib-group instrucción en el 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 rutas múltiples. Esto podría afectar el rendimiento de la red. Se recomienda configurar la función de ruta múltiple 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, donde se puede inspeccionar un máximo de ocho etiquetas MPLS de la carga interna para permitir el filtrado del tráfico MPLS basado en parámetros IP. El tráfico MPLS filtrado también se puede transferir a un dispositivo de monitoreo para ofrecer servicios basados en red en la red MPLS principal.
- Filtrado basado en IP del tráfico MPLS
- Duplicación selectiva de puertos del tráfico MPLS
- Configuraciones de ejemplo
Filtrado basado en IP del tráfico MPLS
Antes de Junos OS versión 18.4R1, el filtrado basado en parámetros IP no se admitía para 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 reflejar en 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 inspeccionar en profundidad los paquetes MPLS para analizar la carga interna con 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 MPLS incluye pseudocables, protocolos distintos de inet e inet6, u otras encapsulaciones como VPN de capa 2 o VPLS, no se admite la característica 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:
La dirección de origen y destino coincide con las condiciones con las listas de prefijos IPv4 e IPv6.
La dirección del puerto de origen y destino y los tipos de protocolo coinciden con las condiciones con las listas de prefijos IPv4 e IPv6.
Duplicación selectiva de puertos del tráfico MPLS
La duplicación de puertos es la capacidad de reflejar un paquete a 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 los parámetros IP, a un destino reflejado mediante túneles lógicos.
Para habilitar la creación selectiva de reflejo 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 discard las counteracceptexistentes:
port-mirrorport-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 creación de reflejo global de port-mirror puertos.
Port Mirroring Instance
La port-mirror-instance acción le permite personalizar cada instancia con propiedades diferentes para el muestreo de entrada y los destinos de salida de la duplicación de puertos, en lugar de tener que usar una única configuración de todo el sistema para la creación de reflejo de puertos.
Solo puede configurar dos instancias de creación de reflejo 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 creación de reflejo 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 se habilita para la instancia de creación de reflejo de puertos.
Para ambas port-mirrorport-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 la función de duplicación selectiva de puertos funcione.
Configuraciones de ejemplo
- Configuración de filtrado basado en IP
- Configuración de duplicación selectiva de puertos
- Configuración de destino reflejada
Configuración de filtrado basado 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 duplicació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-mirrorport-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 la función de duplicación selectiva de puertos funcione.
Configuración de destino reflejada
[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 Feature Explorer a fin de determinar si una función es compatible con la plataforma.