EN ESTA PÁGINA
Configuración del equilibrio de carga basado en etiquetas MPLS
Configuraciones de enrutador para la red MPLS con equilibrio de carga
Configuración del equilibrio de carga basado en etiquetas MPLS en enrutadores serie ACX
Descripción general del equilibrio de carga de carga encapsulada MPLS
Configuración de la carga encapsulada de 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 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 el conjunto de próximos saltos de un destino cambia, la dirección del siguiente salto se vuelve a elegir 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 con etiquetas de igual costo (LSP).
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 la cantidad 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 son una fuente suficiente para la entropía. Como resultado, el equilibrio de carga puede volverse sesgado 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 (véase el cuadro 1, a continuación, para obtener las calificaciones). Las etiquetas superiores e inferiores no se pueden utilizar al mismo tiempo.
Las tarjetas MPC no admiten la configuración regular de clave hash. 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 uniformemente el tráfico cuando se aplican las siguientes condiciones:
Hay varios próximos saltos de igual costo a través de diferentes interfaces al mismo destino.
Hay un solo salto siguiente a través de una interfaz agregada.
Un LSP tiende a equilibrar la carga de su colocación mediante la selección aleatoria de uno de los próximos saltos de igual costo y su uso exclusivo. 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 o los niveles de congestión.
Esta función se aplica a interfaces Ethernet y SONET/SDH agregadas, así como a varios 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 mediante pseudocables Ethernet de capa 2. También puede configurar el equilibrio de carga para pseudocables de Ethernet según la información de IP. La opción de incluir información de IP en la clave hash admite conexiones de conexión cruzada de circuito 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 MPLS LSP.
Declaración |
Plataformas compatibles |
Opciones de equilibrio de carga de LSP de MPLS |
|---|---|---|
|
Serie MX y 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 singularidad de un flujo en el motor de reenvío de paquetes. En los enrutadores serie PTX, este valor se establece de forma predeterminada. A partir de Junos OS versión 19.1R1, para enrutadores serie MX con interfaces MPC y MIC, hasta dieciseis etiquetas MPLS entrantes se incluyen en la clave hash. |
|
Serie MX con DPC (I-Chip). No 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 suficiente variable para el nivel de entropía requerido. |
|
Serie MX con DPC (I-Chip). No compatible con 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 DPC (I-Chip). No compatible con 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, MX, Serie T |
Incluya la primera etiqueta en la clave hash. Utilice esta opción para paquetes de una sola etiqueta. |
|
Serie M, MX, Serie T |
Incluya la segunda etiqueta en la clave hash. También debe configurar la |
|
Serie M, MX, Serie T |
Incluya la tercera etiqueta en la clave hash. También debe configurar la |
|
Todo |
Excluye las etiquetas MPLS de la clave hash. |
|
Serie M, MX, Serie T |
Excluye el bit EXP de la etiqueta superior de la clave hash. También debe configurar la Para VPN de capa 2, el enrutador podría encontrar un problema de reordenación de paquetes. Cuando una ráfaga de tráfico empuja al ancho de banda del tráfico del cliente a superar sus límites, el tráfico puede verse afectado en el flujo medio. Como resultado, es posible que se reordenen los paquetes. 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 se incluirán en la clave hash. Para el enrutador de transporte de paquetes 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 |
Tráfico IPv4 de equilibrio de carga 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, MX, Serie T |
Incluya la información de campo de puerto de origen y destino. De forma predeterminada, se utilizan los bytes más significativos y los menos significativos de los campos de puerto de origen y destino en la clave hash. Para seleccionar bytes específicos que se usarán en la clave hash, incluya una o varias de las |
|
Serie M, 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, 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, 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, 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 |
En los siguientes ejemplos se muestran las formas en que puede configurar el equilibrio de carga de LSP MPLS:
Para incluir la dirección IP así como 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[edit forwarding-options hash-key family mpls]nivel de 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 payloadlas opciones se configuran de forma predeterminada, por lo que no es necesaria ninguna configuración.
(Solo enrutadores de la serie M320 y T) Para incluir la dirección IP, así como las etiquetas primera y segunda en la clave hash, configure las
label-1opciones ylabel-2la opción para laippayloadinstrucción en el[edit forwarding-options hash-key family mpls]nivel de jerarquía:[edit forwarding-options hash-key family mpls] label-1; label-2; payload { ip; }Nota:Solo puede incluir esta combinación de instrucciones en enrutadores M320 y T Series. Si los incluye en un enrutador de borde multiservicio serie M, solo se utilizan la primera etiqueta MPLS y la carga IP en la clave hash.
En el caso de los enrutadores serie T, asegúrese de un equilibrio de carga adecuado mediante la
label-1inclusión de ,label-2ylabel-3las opciones en el[edit forwarding-options hash-key family mpls]nivel jerárquico:[edit forwarding-options hash-key family mpls] label-1; label-2; label-3;
(Solo enrutadores serie M, MX y T) Para VPN de capa 2, el enrutador podría encontrar un problema de reordenación de paquetes. Cuando una ráfaga de tráfico empuja al ancho de banda del tráfico del cliente a superar sus límites, el tráfico puede verse afectado en el flujo medio. Como resultado, es posible que se reordenen los paquetes. 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[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 balanceada de carga
Cuando configure varios LSP RSVP en el mismo enrutador de salida, el LSP con la métrica más baja se selecciona 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 en 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 muestra una red MPLS con cuatro LSP configurados en el mismo enrutador de salida (R0). El equilibrio de carga está configurado en el enrutador R1de entrada. La red de ejemplo usa primero la ruta abierta más corta (OSPF) como protocolo de puerta de enlace interior (IGP) con área 0.0.0.0OSPF. Se requiere un IGP para el LSP de la ruta más corta restringida (CSPF), que es el valor predeterminado para Junos OS. Además, la red de ejemplo usa una política para crear tráfico de BGP.
La red que se muestra en Figura 1 se compone 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 envío estático en enrutadores R1 y R0 que permite anunciar una nueva ruta en la red
Cuatro LSP unidireccionales entre R1 y , y R0un LSP de dirección inversa entre R0 y R1, 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 de malla completa BGP. Dado que los reflector de ruta y las confederaciones no se utilizan para propagar rutas aprendidas del BGP, cada enrutador debe tener una sesión de BGP con todos los demás enrutadores que ejecutan BGP.
Configuraciones de enrutador para la red MPLS con equilibrio de carga
- Propósito
- Acción
- Salida de muestra 1
- Salida de muestra 2
- Salida de muestra 3
- Salida de muestra 4
- Salida de muestra 5
- Salida de muestra 6
- Significado
Propósito
Las configuraciones de este tema son para los seis enrutadores con equilibrio de carga en la red de ejemplo que se ilustra en topología de red de 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
Salida de muestra 1
La siguiente salida de configuración es para enrutador de R6borde.
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
}
}
}
}
Salida de muestra 2
La siguiente salida 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;
}
}
}
Salida de muestra 3
El siguiente resultado de configuración es para el 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
}
}
}
}
Salida de muestra 4
El siguiente resultado de configuración es para el 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
}
}
}
}
Salida de muestra 5
El siguiente resultado de configuración es para el 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
}
}
}
}
Salida de muestra 6
La siguiente salida de configuración es para el 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 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 con equilibrio de carga.
Todos los enrutadores de la red tienen habilitados MPLS, RSVP y BGP. El 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 del enrutador (RID) configurado manualmente en el [edit routing-options] nivel jerárquico para evitar problemas de RID duplicados. La passive instrucción se incluye en la configuración del 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.
Muestra los resultados 1, 3, 4 y 5 para R6, R2, R4y 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).
La salida de muestra 2 del enrutador R1 de entrada muestra la configuración base más cuatro LSP (lsp1 mediante lsp4) la configuración en R0. Los cuatro LSP están configurados con diferentes rutas principales que especifican un salto suelto para R4lsp1 , y lsp4mediante 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 send-statics en el [edit policy-options send statics] nivel jerárquico 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 política se exporta en el [edit routing-options forwarding-table] nivel de jerarquía.
La salida de muestra 6 del enrutador R0 de salida muestra un LSP (r0-r6) para R6 usar para crear tráfico bidireccional. El OSPF requiere la accesibilidad del 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 usa su copia local de la base de datos del IGP para verificar la accesibilidad bidireccional.
Además, R0 tiene una ruta estática (100.100.10.0/24) configurada en el [edit routing-options static route] nivel jerárquico. El prefijo se incluye en la política send-statics en el [edit policy-options send statics] nivel jerárquico para que las rutas puedan convertirse en rutas BGP.
Configuración del equilibrio de carga basado en etiquetas MPLS en enrutadores serie ACX
Tabla 2 proporciona información detallada sobre todas las posibles opciones de equilibrio de carga MPLS LSP.
Los enrutadores de la serie ACX pueden equilibrar la carga por paquete en MPLS. Se puede realizar un equilibrio de carga 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 próximos 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 a través de una interfaz agregada o un paquete LAG. El equilibrio de carga con etiquetas MPLS solo se admite para interfaces LAG y no para vínculos multiruta 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. Cuando el conjunto de próximos saltos para un destino cambia de cualquier manera, la dirección del siguiente salto se vuelve a elegir mediante el algoritmo hash. Puede configurar cómo se utiliza el algoritmo hash para equilibrar la carga del tráfico entre interfaces en una interfaz Ethernet (ae) agregada.
Un LSP tiende a equilibrar la carga de su colocación seleccionando aleatoriamente una de las interfaces en un ae- paquete de interfaz y utilizá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 o los niveles de congestión.
En los enrutadores serie ACX, no se admite el equilibrio de carga en 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 [edit forwarding-options hash-key] nivel de jerarquía.
Cuando se configura la ip de carga (user@host# set forwarding-options hash-key family mpls payload ip), la configuración layer-3-only y port-data es obligatorio.
La funcionalidad de equilibrio de carga, sin la configuración adecuada de claves hash, puede dar lugar a un comportamiento impredecible.
Para la terminación de túnel pseudocable/VPN de capa 2, se utilizan hasta dos etiquetas para hash y carga de destino MAC, y opcionalmente se pueden seleccionar direcciones de origen. Estos controles se pueden utilizar para admitir la perilla ether-pseudowire en mpls de familia bajo la configuración de clave hash que se muestra anteriormente. Sin embargo, dado que ACX2000 y ACX4000 también son compatibles con pseudocables TDM, las perillas de éter-pseudocables se deben usar 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 carga de 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 puerto ip de datos en familia mpls bajo la configuración de clave hash que se muestra anteriormente. Sin embargo, dado que los puertos MSB y LSB de capa 4 no se pueden seleccionar de forma individual, uno de las perillas de destino-lsb o destino-msb o uno de las perillas source-lsb o fuente-msb seleccionaría los puertos de destino o de origen de la capa 4, respectivamente.
Para el caso de LSR, se utilizan hasta tres etiquetas para hash. Si se observa un BOS al analizar las tres primeras etiquetas, el BCM examina el primer morbo de carga: si el nibble es 4, la carga se trata como IPv4 y si el primer nibble es 6, la carga se trata como IPv6 y, en tales casos, las direcciones IP de origen y destino de la carga se pueden usar especulativamente para el hash. Estos controles se pueden utilizar para admitir perillas ip port-data en mpls de familia bajo 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 el botón de 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 pseudocable no se lleva a cabo en caso de LSR, ya que todo el tráfico específico de esa sesión llevará el mismo conjunto de etiquetas MPLS.
Se puede lograr equilibrio de carga en interfaces LSR AE para un número mayor 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 por igual entre los vínculos 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 de LER, en el caso de ACX5048 y ACX5096, el hash basado en campos de capa 3 y capa 4 es posible mediante la configuración de la opción de carga en la jerarquía "familia mpls". El hash en el LER no se basa en etiquetas. Para el servicio de capa 3, es obligatorio mencionar la carga como "solo de capa 3" y especificar "puerto de datos" 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 LER y LSR es aplicable para CCC/VPLS/CAPA 3 VPN y otros escenarios de MPLS IP.
Esta característica se aplica a interfaces Ethernet 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 de Ethernet según la información de IP. La opción de incluir información de IP en la clave hash admite conexiones de conexión cruzada de circuito 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 una sola etiqueta. |
|
|
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. |
|
|
Permite configurar qué partes de la carga del paquete IP se incluirán en la clave hash. Para el conmutador de transporte de paquetes serie PTX, este valor se establece de forma predeterminada. |
|
|
Excluya la carga IP de la clave hash. |
|
|
Tráfico IPv4 de equilibrio de carga 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 campo de puerto de origen y destino. De forma predeterminada, se utilizan los bytes más significativos y los menos significativos de los campos de puerto de origen y destino en la clave hash. Para seleccionar bytes específicos que se usarán 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 así como 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 [edit forwarding-options hash-key family mpls] nivel de jerarquía:
[edit forwarding-options hash-key family mpls]
label-1;
payload {
ip;
}
Para incluir la dirección IP, así como las etiquetas primera y segunda en la clave hash, configure las label-1 opciones y label-2 la opción para la ippayload instrucción en el [edit forwarding-options hash-key family mpls] nivel de jerarquía:
[edit forwarding-options hash-key family mpls]
label-1;
label-2;
payload {
ip;
}
Asegúrese de un equilibrio de carga adecuado mediante la inclusión de label-1, label-2y label-3 las opciones en el [edit forwarding-options hash-key family mpls] nivel jerárquico:
[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. Se puede realizar un equilibrio de carga 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 próximos saltos.
El equilibrio de carga se utiliza para distribuir uniformemente el tráfico cuando se aplican las siguientes condiciones:
Hay varios próximos saltos de igual costo a través de diferentes interfaces al mismo destino.
Hay un solo salto siguiente a través de 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. Cuando el conjunto de próximos saltos para un destino cambia de cualquier manera, la dirección del siguiente salto se vuelve a elegir mediante el algoritmo hash.
En el caso de varias redes de capa 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 y hacia los encabezados internos para generar una distribución uniforme. Para determinar la encapsulación interna, el PFE depende de la presencia de ciertos códigos o números en cargas fijas defets; 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 de hash asume el inicio de una trama Ethernet al final de la palabra de control en un paquete MPLS ether-pseudowire.
Para tarjetas basadas en chip I DPC, configure la zero-control-word opción en el [edit forwarding-options hash-key family mpls ether-pseudowire] nivel de jerarquía; y para tarjetas MPC, configure la zero-control-word opción en el [edit forwarding-options enhanced-hash-key family mpls ether-pseudowire] nivel de jerarquía.
Configuración de la carga encapsulada de 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. Cuando el conjunto de próximos saltos para un destino cambia de cualquier manera, la dirección del siguiente salto se vuelve a elegir mediante el algoritmo hash. Configure la zero-control-word opción para indicar el inicio de una trama Ethernet en una carga de pseudocables de éter MPLS. Al ver esta palabra de control, cuatro bytes con un valor numérico de todos los ceros, el generador de 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 de 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 de pseudocables de éter MPLS. Para las tarjetas basadas en chip I de DPC, configure la
zero-control-wordopción en el[edit forwarding-options hash-key family mpls ether-pseudowire]nivel jerárquico.[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[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire]nivel de jerarquía.[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 rutas de LDP o RSVP sr-TE de enrutamiento por segmentos y rutas IP 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 selectiva mediante la ruta mutlipath a través de la configuración de políticas.
- Descripción de rutas de múltiples rutas basadas en políticas
- Beneficios de las rutas de varias rutas basadas en políticas
- Rutas de varias rutas basadas en políticas para la resolución de rutas
- Resolución de ruta de ejemplo mediante rutas multiruta basadas en políticas
- Mejora de la política de reenvío de clase de servicio (CoS)
- Mejoras del protocolo de coincidencia de políticas
- Impacto de la configuración de la ruta de varias rutas basada en políticas en el rendimiento de la red
Descripción de rutas de múltiples rutas basadas en políticas
Hay diferentes protocolos de transporte en una red, como IGP, IGP etiquetado, 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 se 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 varias rutas basadas en políticas, puede combinar rutas LDP o RSVP de enrutamiento por segmentos con rutas LDP o RSVP y rutas IP SR-TE para crear una ruta multiruta que se instala en la base de información de enrutamiento. Puede resolver rutas de servicio de BGP a través de la ruta mutlipath mediante la configuración de políticas y dirigir el tráfico de manera diferente para distintos prefijos.
Una ruta de varias rutas ha combinado los próximos saltos de entradas de ruta que se utilizan para el equilibrio de carga. Todas las rutas compatibles de la entrada de ruta de varias rutas deben estar en la misma base de información de enrutamiento. Cuando las rutas de soporte se encuentran bajo una base de información de enrutamiento diferente, puede usar 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 varias rutas 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 de varias rutas basada en políticas.
La función de varias rutas basadas en políticas es compatible con los protocolos IP e IPv6, y se puede configurar en el [edit routing-instances] nivel de 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 varias rutas 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 apply, 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 de varias rutas 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 política de varias rutas.
Beneficios de las rutas de varias rutas basadas en políticas
-
Ofrece flexibilidad para combinar protocolos de red central para dirigir el tráfico selectiva.
-
Optimiza el rendimiento de la red con varias rutas ponderadas de igual costo mediante rutas de varias rutas.
Rutas de varias rutas basadas en políticas para la resolución de rutas
Puede combinar rutas LDP o RSVP de enrutamiento por segmentos diseñadas por tráfico (SR-TE) con rutas IP de SR-TE e instalar una ruta multiruta en la base de información de enrutamiento. Las rutas de varias rutas basadas en políticas no son entradas activas en la base de información de enrutamiento. Cuando la configuración de la política genera una ruta de varias rutas, se utiliza para resolver los próximos saltos del protocolo en lugar de las rutas activas. Un salto siguiente de ruta de varias rutas se crea mediante la fusión de puertas de enlace de los saltos siguientes de cada ruta constituyente.
Tome en consideración lo siguiente al configurar rutas de varias rutas basadas en políticas para la resolución de rutas:
-
Si la ruta miembro de una ruta de varias rutas apunta a un salto siguiente distinto al siguiente salto del enrutador o a un salto siguiente indirecto con reenvío al salto siguiente del enrutador, dichos saltos se omiten.
-
Si las rutas constituyentes apuntan al siguiente salto indirecto, las puertas de enlace del reenvío-siguiente salto se fusionan y se ignora el salto siguiente indirecto.
-
Si el número total de puertas de enlace supera la
maximum-ecmpcompatible en el dispositivo, entonces 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 única de próximos saltos indirectos y cada uno de los saltos siguientes apunta a un siguiente 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 estos casos, el valor de peso de las puertas de enlace se actualiza para reflejar el efecto combinado de los pesos en ambos niveles.
Resolución de ruta 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, etiquetas de rutas IS-IS 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 laentrada de ruta activa al destino 1 0.1.1.1, y de forma predeterminada, solo esta ruta se utiliza para resolver cualquier servicio que se resuelva en 10.1.1.1.
Cuando se requiere usar más de un protocolo para resolver rutas de servicio, puede lograrlo configurando varias rutas de política para combinar los protocolos. Por ejemplo, si el enrutamiento por segmentos y las rutas LDP son necesarios para la resolución del servicio, debe configurar policy-multipath la combinación del enrutamiento de segmentos y las rutas LDP para elprefijo 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 de varias rutas basada en políticas para el prefijo 10.1.1.1/32 que usa entradas de ruta constituyentes del enrutamiento de segmentos y protocolos LDP.
Puede ver la ruta de varias rutas mediante el resultado del comando, de la show route 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)
Puede ver en el resultado del comando que la ruta de varias rutas combina los próximos saltos de enrutamiento de segmentos y rutas LDP. La ruta de varias rutas no está activa y, de forma predeterminada, la preferencia de ruta y la métrica son las mismas que la de la ruta activa.
Puede usar las siguientes combinaciones para la ruta multiruta basada en poilcy: Sin embargo, no podemos crear varias rutas de LDP/L-ISIS, ya que la ruta activa no forma parte de varias rutas.
-
LSP y LSP de LDP diseñados para enrutamiento por segmentos.
-
LSP de enrutamiento por segmentos diseñados para el tráfico y etiquetan rutas IS-IS.
-
LSP de enrutamiento por segmentos diseñados para tráfico, LSP de LDP y rutas DE ETIQUETA IS-IS.
Sin embargo, no puede crear una ruta de varias rutas de LDP y etiqueta IS-IS, ya que la ruta activa no forma parte de la ruta de varias rutas.
Con la misma configuración, suponiendo que haya una ruta estática 1.2.3.4/32 configurada con un próximo salto de protocolo de 10.1.1.1. esta ruta se resuelve mediante la ruta de varias rutas en los LSP diseñados por 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 de forwarding-policy next-hop-map configuración.
Antes de la versión 19.1R1 de Junos OS, las condiciones de coincidencia compatibles con el reenvío basado en clase de servicio incluían:
-
next-hop—Coincida el siguiente salto basado en la interfaz de salida o la dirección del siguiente salto.
-
lsp-next-hop—Coincida los LSP con la expresión regular de nombre de LSP.
-
non-lsp-next-hop— Hace coincidir todos los LSP sin un nombre LSP.
Con la función de ruta multiruta basada en políticas, también puede hacer coincidir todos los saltos siguientes sin una etiqueta para ciertos prefijos. Para ello, debe habilitar la opción en el non-labelled-next-hop[edit class-of-service forwarding-policy next-hop-map map-name forwarding-class forwarding-class-name nivel de jerarquía.
Por ejemplo:
[edit]
class-of-service {
forwarding-policy {
next-hop-map abc {
forwarding-class best-effort {
non-labelled-next-hop;
}
}
}
}
Mejoras del protocolo de coincidencia de políticas
Antes de La versión 19.1R1 de Junos OS, cuando se utilizaba una política para que coincida con el protocolo mediante la from protocol instrucción en el [edit policy-options policy-statement statement-name] nivel de jerarquía, se hacían coincidir todas las rutas de protocolo (etiquetadas y no etiquetadas). Con la función de ruta de varias rutas basada en políticas, puede hacer coincidir específicamente las rutas de protocolo etiquetadas.
Las opciones para hacer coincidir protocolos etiquetados son:
-
l-isis—Coincida con rutas IS-IS. La
isisopción coincide con las rutas IS-IS, excluyendo las rutas IS-IS de la etiqueta. -
l-ospf—Coincida con rutas OSPF con sangrado. La
ospfopción coincide con todas las rutas OSPF, incluidos OSPFv2, OSPFv3 y OSPF de etiqueta.
Por ejemplo:
[edit]
policy-options {
policy-statement abc {
from protocol [ l-ospf l-isis ];
}
}
Impacto de la configuración de la ruta de varias rutas basada en políticas en el rendimiento de la red
Cuando se configura una ruta de varias rutas 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 de varias rutas. Dado que esta característica requiere que las rutas de miembro estén en la misma base de información de enrutamiento, la rib-group instrucción se utiliza para combinar rutas de base de información de enrutamiento diferente. La configuración de la rib-group instrucción en el nivel de la 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 varias rutas. Esto podría afectar el rendimiento de la red. Se recomienda configurar la función de ruta de varias rutas 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 un máximo de hasta 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 duplicar en un puerto a un dispositivo de monitoreo para ofrecer servicios basados en red en la red central de MPLS.
- Filtrado basado en IP del tráfico MPLS
- Duplicación de puerto selectiva 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 era compatible con el filtro de la 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 por MPLS según 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 le 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. El tráfico MPLS selectiva puede entonces ser replicado por puerto a un dispositivo de monitoreo remoto 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 las capas 3 y 4 antes de aplicar los filtros adecuados.
La función de filtrado basado en IP solo se admite para paquetes IPv4 e IPv6 con etiquetas MPLS. En otras palabras, los filtros MPLS solo coinciden con los parámetros IP cuando la carga IP viene inmediatamente después de las etiquetas MPLS.
En otras situaciones, en las que la carga MPLS incluye pseudocables, protocolos distintos a 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 coincidencia para el filtrado basado en IP del tráfico MPLS:
Las direcciones de origen y destino coinciden con condiciones con listas de prefijoS IPv4 e IPv6.
Los tipos de protocolo y dirección de puerto de origen y destino coinciden con condiciones con listas de prefijos IPv4 e IPv6.
Duplicación de puerto selectiva del tráfico MPLS
La duplicación de puertos es la capacidad de duplicar 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 de puerto selectiva ofrece la capacidad de duplicar el tráfico MPLS, que se filtra según los parámetros de IP, a un destino reflejado mediante túneles lógicos.
Para habilitar la duplicación selectiva de puertos, se configuran acciones adicionales en el [edit firewall family mpls filter filter-nameterm term-name then] nivel jerárquico, además de las acciones existentescounteraccept, y discard las acciones:
port-mirrorport-mirror-instance
Port Mirroring
La port-mirror acción permite la duplicación de puertos globalmente en el dispositivo, lo que se aplica a todos los motores de reenvío de paquetes (PPE) y las interfaces asociadas.
Para el filtro de la familia MPLS, la port-mirror acción está habilitada para la duplicación de puerto global.
Port Mirroring Instance
La port-mirror-instance acción le permite personalizar cada instancia con diferentes propiedades para el muestreo de entrada y los destinos de salida de duplicación de puertos, en lugar de tener que usar una única configuración en todo el sistema para la duplicación de puertos.
Solo puede configurar dos instancias de duplicación de puertos por concentrador de PIC flexible (FPC) incluyendo la instance port-mirror-instance-name instrucción en el [edit forwarding-options port-mirror] nivel de jerarquía. A continuación, puede asociar instancias de duplicación de puerto individual con una FPC, PIC 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 puerto.
Para ambas port-mirror acciones port-mirror-instance , la interfaz de salida debe habilitarse con la familia de capa 2 y no con la familia MPLS (capa 3) para que funcione la función de duplicación de puerto selectiva.
Configuraciones de ejemplo
- Configuración de filtrado basado en IP
- Configuración de duplicación de puerto selectiva
- Configuración de destino duplicada
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 de puerto selectiva
[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 acciones port-mirror-instance , la interfaz de salida debe habilitarse con la familia de capa 2 y no con la familia MPLS (capa 3) para que funcione la función de duplicación de puerto selectiva.
Configuración de destino duplicada
[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;
}