Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Descripción del algoritmo utilizado para equilibrar la carga del tráfico en los enrutadores de la serie MX

Cuando se recibe un paquete en la interfaz de entrada de un dispositivo, el motor de reenvío de paquetes (PFE) realiza una búsqueda para identificar el siguiente salto de reenvío. Si hay varias rutas de igual costo (ECMP) al mismo destino del próximo salto, el PFE de entrada se puede configurar para distribuir el flujo entre los siguientes saltos. Del mismo modo, puede ser necesaria la distribución del tráfico entre los enlaces de miembro de una interfaz agregada, como Ethernet agregada. La selección del próximo salto de reenvío real se basa en el resultado del cálculo hash sobre campos de encabezado de paquete seleccionados y varios campos internos, como el índice de interfaz. Puede configurar algunos de los campos utilizados por el algoritmo hash.

  • Para los enrutadores de la serie MX con concentradores de puertos modulares (MPC) y FPC de tipo 5, configure el hash para los tipos de tráfico admitidos en el nivel jerárquico forwarding-options enhanced-hash-key . Los detalles sobre qué campos se incluyen de forma predeterminada para qué familia de tráfico se pueden encontrar a continuación.

    En Junos OS versión 18.3R1, el método predeterminado para calcular el hash mejorado se cambió para proporcionar una entropía mejorada para túneles IP, flujos IPv6 y cargas PPPoE transmitidas como multiservicio de familia. Estos valores predeterminados se pueden desactivar estableciendo sus respectivos comandos no.

  • Para los enrutadores de la serie MX con DPC, configure el hash para los tipos de tráfico admitidos en el nivel de forwarding-options hash-key jerarquía.

Junos admite diferentes tipos de equilibrio de carga.

  • Equilibrio de carga por prefijo : cada prefijo se asigna a un solo reenvío del próximo salto.

  • Equilibrio de carga por paquete: todas las direcciones del próximo salto para un destino de la ruta activa se instalan en la tabla de reenvío (el término equilibrio de carga por paquete en Junos es equivalente a lo que otros proveedores podrían denominar equilibrio de carga por flujo ). Consulte Configuración del equilibrio de carga por paquete para obtener más información.

  • Equilibrio de carga de paquetes aleatorio: los siguientes saltos se eligen aleatoriamente para cada paquete. Este método está disponible en enrutadores MX con tarjetas de línea MPC para interfaces Ethernet agregadas y rutas ECMP. Para configurar el equilibrio de carga de pulverización aleatoria por paquete, incluya la per-packet instrucción en el nivel de [edit interfaces aex aggregated-ether-options load-balance] jerarquía. ConsulteEjemplo: Configuración del equilibrio de carga Ethernet agregada para obtener más información.

  • Equilibrio de carga de pulverización aleatoria por paquete : cuando falla la opción de equilibrio de carga adaptativo, el equilibrio de carga de pulverización aleatoria por paquete sirve como último recurso. Garantiza que los miembros del ECMP estén igualmente cargados sin tener en cuenta el ancho de banda. Por paquete provoca la reordenación de paquetes y, por lo tanto, solo se recomienda si las aplicaciones absorben el reordenamiento. La pulverización aleatoria por paquete elimina el desequilibrio del tráfico que se produce como resultado de errores de software, excepto para el hash de paquete.

    A partir de Junos OS versión 20.2R1, puede configurar el equilibrio de carga aleatorio por paquete en enrutadores MX240, MX480 y MX960 con tarjeta de línea MPC10E (MPC10E-15C-MRATE y MPC10E-10C-MRATE) y enrutadores MX2010 y MX2020 con tarjeta de línea MX2K-MPC11E.

  • Equilibrio de carga adaptativo : el equilibrio de carga adaptativo (ALB) es un método que corrige un desequilibrio de tráfico genuino mediante el uso de un mecanismo de retroalimentación para distribuir el tráfico a través de los vínculos en un paquete Ethernet agregado y en los próximos saltos de ruta múltiple (ECMP) de igual costo. ALB optimiza la distribución del tráfico cuando los flujos de paquetes tienen tasas de tráfico muy variables. ALB utiliza un mecanismo de retroalimentación para corregir el desequilibrio de carga de tráfico ajustando el ancho de banda y las transmisiones de paquetes en los vínculos dentro de un paquete de AE.

    • ALB en varios motores de reenvío de paquetes para paquetes Ethernet agregados

      A partir de Junos OS versión 20.1R1, en MPC serie MX, en paquetes Ethernet agregados, ALB redistribuye el tráfico uniformemente a través de varios motores de reenvío de paquetes (PFE) de entrada múltiple en la misma tarjeta de línea. En versiones anteriores, ALB estaba limitado a un solo PFE mientras redistribuía el tráfico en un paquete de AE. Esto afectó la flexibilidad y la redundancia. ALB está deshabilitado de forma predeterminada.

      Puede configurar ALB estableciendo la adaptive instrucción en el nivel de [edit interfaces ae-interface aggregated-ether-options load-balance] jerarquía.

      Consulte Configuración del equilibrio de carga adaptable para obtener más información.

    • ALB en múltiples PFE para los siguientes saltos ECMP

      A partir de Junos OS versión 20.1R1, puede configurar ALB para los siguientes saltos ECMP a través de varios PFE de entrada en la misma tarjeta de línea para una distribución uniforme del tráfico y redundancia. En versiones anteriores, ALB para los siguientes saltos ECMP se limitaba a un solo PFE. Esta limitación afectó a la flexibilidad y la redundancia. ALB monitorea dinámicamente la carga de tráfico aportada por cada flujo en relación con los niveles generales de carga del vínculo ECMP y, luego, toma medidas correctivas cuando se alcanza el umbral.

      Puede configurar ALB para los próximos saltos ECMP configurando el ecmp-alb comando en el nivel de [edit chassis] jerarquía.

      Consulte ecmp-alb para obtener más información.

    Nota:

    ALB funcionará para varios PFE que residen en la misma tarjeta de línea. Esta función no se admitirá para PFE que residan en tarjetas de línea diferentes.

    Para los PFE que residen en tarjetas de línea diferentes, el tráfico de entrada puede causar una carga desigual en los puertos de salida, incluso si la ALB está habilitada.

También están disponibles varias opciones de configuración adicionales:

  • Configuración de la función hash por ranura : este método se basa en un valor hash único de equilibrio de carga para cada ranura PIC y solo es válido para enrutadores serie M120, M320 y MX con tarjetas de línea DPCE y MS-DPC.

  • Equilibrio de carga simétrico : este método proporciona equilibrio de carga simétrico en un LAG 802.3ad. El hash utilizado para el equilibrio de carga simétrico se establece en el interface nivel de la jerarquía. Garantiza que un flujo determinado de tráfico dúplex atraviese los mismos dispositivos en ambas direcciones, y está disponible en los enrutadores de la serie MX.

Especificaciones de FPC MX MPC y T-Series Type 5

El algoritmo de cálculo hash en las FPC MX MPC y T Series Type 5 produce resultados idénticos para paquetes con direcciones de capa 3 intercambiadas o puertos de transporte de capa 4. Por ejemplo, el resultado del cálculo hash para un paquete con la dirección de origen 192.0.2.1 y la dirección de destino 203.0.113.1 es idéntico al resultado del cálculo de hash para un paquete con la dirección de origen 203.0.113.1 y la dirección de destino 192.0.2.1.

Para evitar una posible reordenación de paquetes, los puertos del protocolo de transporte de capa 4 nunca se utilizan en el cálculo hash de paquetes IPv4 fragmentados. Esto es cierto para el primer fragmento del flujo, identificado por el more fragment bit en un encabezado, y todos los fragmentos subsiguientes, identificados por desplazamiento de fragmentos distintos de cero. El primer fragmento y los fragmentos subsiguientes siempre se reenvían en el mismo salto siguiente.

Algoritmo hash utilizado en Junos 18.3R1 y versiones posteriores

En la mayoría de los casos, incluir información de campo de capa 3 y capa 4 en el cálculo del hash produce resultados lo suficientemente buenos para una distribución equitativa del tráfico. Sin embargo, en casos como la tunelización IP-in-IP o GRE, la información de campo de capa 3 y capa 4 por sí sola puede no ser suficiente para producir un hash con suficiente entropía para el equilibrio de carga. Por ejemplo, en una implementación en la que los enrutadores de la serie MX transitan flujos GRE, los túneles de encapsulación GRE suelen producirse como un único flujo con el mismo origen y destino, y la misma clave GRE. Los flujos gordos también pueden aumentar notablemente el desequilibrio en la utilización del enlace, ya que aumenta el volumen de tráfico sobre los túneles. Otro ejemplo es cuando los enrutadores MX PE se utilizan como dispositivos VPLS PE en una implementación perimetral de suscriptor en la que los enrutadores transportan el tráfico de suscriptores de banda ancha desde los dispositivos de acceso a una puerta de enlace de red de banda ancha (BNG) central. En tal caso, solo las direcciones MAC del suscriptor y las direcciones MAC del enrutador BNG están disponibles para hashing. Pero con pocas MAC BNG y relativamente pocas MAC de suscriptor, los campos típicos de capa 3 y capa 4 no son suficientes para crear un hash para un equilibrio de carga óptimo.

Por lo tanto, para los enrutadores de la serie MX con MPC Trio y que ejecutan Junos OS versión 18.3R1 o posterior, el cálculo predeterminado enhanced-hash-key ha cambiado. Aquí encontrará un resumen de los cambios:

  • Para los paquetes GRE, si el paquete IP externo no es un paquete fragmentado (primer fragmento o cualquier fragmento posterior) y el paquete interno es IPv4 o IPv6, las direcciones de origen y destino del paquete interno se utilizan en el cálculo hash además de las direcciones de origen y destino externas. Los puertos de capa 4 del paquete interno también se incluyen si el protocolo del paquete IP interno es TCP o UDP, y el paquete IP interno no es un fragmento (primer fragmento o cualquier fragmento posterior). Del mismo modo, si el paquete IP externo no es un paquete de fragmento y el paquete interno es MPLS, la etiqueta interna superior se incluye en el cálculo hash.

  • Para los paquetes PPPoE, si el paquete interno es IPv4 o IPv6, se incluyen las direcciones de origen y destino del paquete interno. Los puertos de capa 4 se incluyen si el protocolo del paquete IP interno es TCP o UDP, y el paquete IP interno no es un fragmento. La inclusión de los campos de paquetes internos PPPoE se puede deshabilitar configurando la no-payload opción en el nivel de forwarding-options enhanced-hash-key family multiservice jerarquía.

  • Para IPv6, el campo de etiqueta de flujo de encabezado IPv6 se incluye en el cálculo hash. RFC 6437 describe el campo de etiqueta de flujo de 20 bits en el encabezado IPv6. Establezca la no-flow-label opción en la forwarding-options enhanced-hash-key family inet6 jerarquía para deshabilitar el nuevo valor predeterminado.

Campos hash utilizados para el tráfico GRE enviado a través de IPv4

Las listas muestran los campos utilizados en el cálculo del hash, para paquetes no fragmentados, en Junos 18.3R1 y versiones posteriores. De forma predeterminada, el campo se utiliza en el cálculo del hash, a menos que se indique lo contrario. Además, donde se indique, los campos IP y puerto utilizados en el hash son simétricos, es decir, el intercambio de los campos no cambia el resultado del hash.

  • IPv4, GRE

    • Clave GRE

    • Dirección de origen y destino; Simétrico

    • Protocolo

    • DSCP (deshabilitado)

    • Índice de la interfaz entrante (deshabilitado)

  • IPv4 en IPv4, GRE

    • Carga útil (IPv4 interno: puertos de origen y destino, direcciones IP); Simétrico

    • Clave GRE

      Protocolo GRE = IPv4

    • Dirección de origen y destino; Simétrico

    • Protocolo

    • DSCP (deshabilitado)

    • Índice de la interfaz entrante (deshabilitado)

  • IPv6 en IPv4, GRE

    • Carga útil (IPv6 interno: puertos de origen y destino, direcciones IP); Simétrico

    • Clave GRE

      Protocolo GRE = IPv6

    • Dirección de origen y destino; Simétrico

    • Protocolo

    • DSCP (deshabilitado)

    • Índice de la interfaz entrante (deshabilitado)

  • MPLS en IPv4, GRE

    • Carga útil (MPLS interna: etiqueta superior)

    • Clave GRE

      Protocolo GRE = MPLS

    • Dirección de origen y destino; Simétrico

    • Protocolo

    • DSCP (deshabilitado)

    • Índice de la interfaz entrante (deshabilitado)

  • IPv4, L2TPv2 usado en Junos 17.2 y versiones posteriores

    La inclusión del ID de túnel L2TPv2 y el ID de sesión se puede habilitar configurando la forwarding-options enhanced-hash-key family inet l2tp-tunnel-session-identifier opción. Tenga en cuenta que Juniper no recomienda habilitar esta opción de forma predeterminada. Esto se debe a que la identificación de sesión L2TP se basa en la coincidencia del puerto UDP de destino (1701) y es posible que este puerto no se use exclusivamente para el transporte L2TP, por lo que la extracción de los campos de túnel e ID de sesión del paquete puede no ser siempre precisa.

    • ID de sesión

    • ID de túnel

    • Puerto de origen y destino

    • Dirección de origen y destino; Simétrico

    • Protocolo (UDP)

    • DSCP (deshabilitado)

    • Índice de la interfaz entrante (deshabilitado)

Campos hash utilizados para el tráfico GRE enviado a través de IPv6

La lista muestra los campos utilizados en el cálculo de hash para paquetes no fragmentados. De forma predeterminada, el campo se utiliza en el cálculo del hash, a menos que se indique lo contrario. Además, donde se indique, los campos IP y puerto utilizados en el hash son simétricos, es decir, el intercambio de los campos no cambia el resultado del hash.

  • IPv6, GRE

    • Clave GRE

    • Dirección de origen y destino; Simétrico

    • Siguiente encabezado

    • Etiqueta de flujo (Junos 18.3 y versiones posteriores)

    • Clase de tráfico (deshabilitada)

    • Índice de la interfaz entrante (deshabilitado)

  • IPv4 en IPv6, GRE (Junos 18.3 y posterior)

    • Carga útil (IPv4 interno: puertos de origen y destino, direcciones IP); Simétrico

    • Clave GRE

      Protocolo GRE = IPv4

    • Dirección de origen y destino; Simétrico

    • Siguiente encabezado

    • Etiqueta de flujo (Junos 18.3 y versiones posteriores)

    • Clase de tráfico (deshabilitada)

    • Índice de la interfaz entrante (deshabilitado)

  • IPv6 en IPv6, GRE (Junos 18.3 y posteriores)

    • Carga útil (IPv6 interno: puertos de origen y destino, direcciones IP); Simétrico

    • Clave GRE

      Protocolo GRE = IPv6

    • Dirección de origen y destino; Simétrico

    • Siguiente encabezado

    • Etiqueta de flujo (Junos 18.3 y versiones posteriores)

    • Clase de tráfico (deshabilitada)

    • Índice de la interfaz entrante (deshabilitado)

  • MPLS en IPv6, GRE (Junos 18.3 y versiones posteriores)

    • Carga útil (MPLS interna: etiquetas superiores); Simétrico

    • Clave GRE

      Protocolo GRE = MPLS

    • Dirección de origen y destino; Simétrico

    • Siguiente encabezado

    • Etiqueta de flujo

    • Clase de tráfico (deshabilitada)

    • Índice de la interfaz entrante (deshabilitado)

Campos hash utilizados para IPv4

La lista muestra los campos utilizados en el cálculo de hash para paquetes no fragmentados, excepto donde se indique lo contrario. De forma predeterminada, el campo se utiliza en el cálculo del hash, a menos que se indique lo contrario. Además, donde se indique, el hash de los campos IP y puerto es simétrico, es decir, el intercambio de los campos no cambia el resultado del hash.

  • IPv4, no TCP o UDP, ni paquetes fragmentados

    • Dirección de origen y destino; Simétrico

    • Protocolo

    • DSCP (deshabilitado)

    • Índice de la interfaz entrante (deshabilitado)

  • IPv4, TCP y UDP, paquetes no fragmentados

    • Puerto de origen y destino; Simétrico

    • Dirección de origen y destino; Simétrico

    • Protocolo

    • DSCP (deshabilitado)

    • Índice de la interfaz entrante (deshabilitado)

  • IPv4, PPTP

    • 16 bits menos significativos de la clave GRE

    • Dirección de origen y destino; Simétrico

    • Protocolo

    • DSCP (deshabilitado)

    • Índice de la interfaz entrante (deshabilitado)

  • Tráfico IPv4, GTP, UDP al puerto de destino 2152

    La inclusión del identificador de punto final de túnel (TEID) del protocolo de túnel GPRS (GTP) se puede habilitar en la forwarding-options enhanced-hash-key family inet gtp-tunnel-endpoint-identifier opción. Tenga en cuenta que Juniper no recomienda habilitar esta opción de forma predeterminada. Esto se debe a que la identificación de la sesión GTP se basa en la coincidencia del puerto UDP de destino (2152) y es posible que este puerto no se utilice exclusivamente para el transporte GTP, por lo que la extracción del campo TEID del paquete puede no ser siempre precisa.

    • GTP TEID (deshabilitado)

    • Puerto de origen y destino

    • Dirección de origen y destino; Simétrico

    • Protocolo

    • DSCP (deshabilitado)

    • Índice de la interfaz entrante (deshabilitado)

Campos hash utilizados para IPv6

La lista muestra los campos utilizados en el cálculo de hash para paquetes no fragmentados, excepto donde se indique lo contrario. De forma predeterminada, el campo se utiliza en el cálculo del hash, a menos que se indique lo contrario. Además, donde se indique, el hash de los campos IP y puerto es simétrico, es decir, el intercambio de los campos no cambia el resultado del hash.

  • IPv6, paquetes no TCP y UDP, o paquetes TCP y UDP fragmentados por el originador

    • Dirección de origen y destino; Simétrico

    • Siguiente encabezado

    • Etiqueta de flujo (Junos 18.3 y versiones posteriores)

    • Clase de tráfico (deshabilitada)

    • Índice de la interfaz entrante (deshabilitado)

  • IPv6, TCP no fragmentado y paquete UDP

    • Puerto de origen y destino; Simétrico

    • Dirección de origen y destino; Simétrico

    • Siguiente encabezado

    • Etiqueta de flujo (Junos 18.3 y versiones posteriores)

    • Clase de tráfico (deshabilitada)

    • Índice de la interfaz entrante (deshabilitado)

  • IPv6, PPTP

    • 16 bits menos significativos de la clave GRE

    • Dirección de origen y destino; Simétrico

    • Siguiente encabezado

    • Etiqueta de flujo (Junos 18.3 y versiones posteriores)

    • Clase de tráfico (deshabilitada)

    • Índice de la interfaz entrante (deshabilitado)

  • IPv6, GTP

    La inclusión del identificador de punto de conexión de túnel (TEID) del protocolo de túnel GPRS (GTP) se puede habilitar en el nivel de forwarding-options enhanced-hash-key family inet gtp-tunnel-endpoint-identifier jerarquía. Tenga en cuenta que Juniper no recomienda habilitar esta opción de forma predeterminada. Esto se debe a que la identificación de la sesión GTP se basa en la coincidencia del puerto UDP de destino (2152) y es posible que este puerto no se utilice exclusivamente para el transporte GTP, por lo que la extracción del campo TEID del paquete puede no ser siempre precisa.

    • TEID de GTP (deshabilitado de forma predeterminada; habilite en el nivel de forwarding-options enhanced-hash-key family inet gtp-tunnel-endpoint-identifier jerarquía.

    • Puerto de origen y destino

    • Dirección de origen y destino; Simétrico

    • Siguiente encabezado

    • Etiqueta de flujo (Junos 18.3 y versiones posteriores)

    • Clase de tráfico (deshabilitada)

    • Índice de la interfaz entrante (deshabilitado)

Campos hash utilizados para multiservicio

La configuración de hash multiservicio familiar se aplica a los paquetes que ingresan al enrutador como family ccc, vpls, o bridge. La lista muestra los campos utilizados en el cálculo de hash para paquetes no fragmentados. De forma predeterminada, el campo se utiliza en el cálculo del hash, a menos que se indique lo contrario. Además, donde se indique, los campos IP y puerto utilizados en el hash son simétricos, es decir, el intercambio de los campos no cambia el resultado del hash.

  • Ethernet, no IP o no MPLS

    Si está configurado, la información de carga útil se extrae de paquetes sin etiquetar o paquetes con hasta dos etiquetas VLAN.

    • Exterior 802.1p (deshabilitado)

    • MAC de origen y destino; Simétrico

    • Índice de la interfaz entrante (deshabilitado)

  • Ethernet, IPv4

    • Carga útil (IPv4 interno: puertos de origen y destino, direcciones IP); Simétrico

    • Exterior 802.1p (deshabilitado)

    • MAC de origen y destino; Simétrico

    • Índice de la interfaz entrante (deshabilitado)

  • Ethernet, IPv6

    • Carga útil (IPv6 interno: puertos de origen y destino, direcciones IP); Simétrico

    • Exterior 802.1p (deshabilitado)

    • MAC de origen y destino; Simétrico

    • Índice de la interfaz entrante (deshabilitado)

  • Ethernet, MPLS

    • Carga útil (MPLS interna: etiquetas superiores más campos IPv4 e IPv6 internos); Simétrico. Consulte Campos hash utilizados para MPLS, Junos 18.3 y versiones posteriores, a continuación, para obtener información relacionada.

    • Exterior 802.1p (deshabilitado)

    • MAC de origen y destino; Simétrico

    • Índice de la interfaz entrante (deshabilitado)

  • IPv4 en PPPoE (paquete de datos)

    • Carga útil (IPv4 interno: puertos de origen y destino, direcciones IP); Simétrico

    • Protocolo PPP IPv4 versión 0x1, escriba 0x1

    • Exterior 802.1p (deshabilitado)

    • MAC de origen y destino; Simétrico

    • Índice de la interfaz entrante (deshabilitado)

  • IPv6 en PPPoE (paquete de datos)

    • Carga útil (IPv6 interno: puertos de origen y destino, direcciones IP); Simétrico

    • Protocolo PPP IPv6 versión 0x1, escriba 0x1

    • Exterior 802.1p (deshabilitado)

    • MAC de origen y destino; Simétrico

    • Índice de la interfaz entrante (deshabilitado)

Campos hash usados para MPLS, Junos 18.3 y versiones posteriores

La lista muestra los campos utilizados en el cálculo de hash para paquetes no fragmentados. De forma predeterminada, el campo se utiliza en el cálculo del hash, a menos que se indique lo contrario. Además, donde se indique, los campos IP y puerto utilizados en el hash son simétricos, es decir, el intercambio de los campos no cambia el resultado del hash.

  • MPLS, IPv4 encapsulado o IPv6

    • Carga útil (IPv4 interno: puertos de origen y destino, direcciones IP); Simétrico

    • Carga útil (IPv6 interno: puertos de origen y destino, direcciones IP, siguiente encabezado); Simétrico

    • Etiqueta 1..16 (20 bits)

    • Etiqueta exterior EXP (desactivado)

    • Índice de la interfaz entrante (deshabilitado)

  • MPLS, IPv4 o IPv6 en pseudocables Ethernet

    • Carga útil (IPv4/IPv6 en pseudocable Ethernet)

    • Etiqueta 2..16 (20 bits)

    • Etiqueta exterior EXP (desactivado)

    • Etiqueta 1 (20 bits)

    • Índice de la interfaz entrante (deshabilitado)

  • MPLS, MPLS en pseudocable Ethernet

    • Carga útil (dos etiquetas superiores de entrada de pila de etiquetas MPLS en pseudocable Ethernet)

    • Etiqueta 2..16 (20 bits)

    • Etiqueta exterior EXP (desactivado)

    • Etiqueta 1 (20 bits)

    • Índice de la interfaz entrante (deshabilitado)

  • MPLS, etiqueta de entropía

    Cuando se detecta una etiqueta de entropía, el campo de carga no se procesa y el indicador no se incluye en el cálculo del hash

    • Etiqueta 1..16 (20 bits)

    • Etiqueta exterior EXP (desactivado)

    • Índice de la interfaz entrante (deshabilitado)

Campos hash usados para MPLS de Junos 14.1 a Junos 18.3

La lista muestra los campos utilizados en el cálculo de hash para paquetes no fragmentados. De forma predeterminada, el campo se utiliza en el cálculo del hash, a menos que se indique lo contrario. Además, donde se indique, los campos IP y puerto utilizados en el hash son simétricos, es decir, el intercambio de los campos no cambia el resultado del hash.

  • MPLS, IPv4 encapsulado o IPv6

    • Carga útil (IPv4 interno: puertos de origen y destino, direcciones IP); Simétrico

      Carga útil (IPv6 interno: puertos de origen y destino, direcciones IP, siguiente encabezado); Simétrico

    • Etiqueta 2.8 (20 bits)

      Etiqueta exterior EXP (desactivado)

      Etiqueta 1 (20 bits)

    • Índice de la interfaz entrante (deshabilitado)

  • MPLS, IPv4 o IPv6 en pseudocables Ethernet

    • Carga útil (IPv4/IPv6 en pseudocable Ethernet)

    • Etiqueta 2.8 (20 bits)

      Etiqueta exterior EXP (desactivado)

      Etiqueta 1 (20 bits)

    • Índice de la interfaz entrante (deshabilitado)

  • MPLS, MPLS en pseudocable Ethernet

    • Carga útil (dos etiquetas superiores de entrada de pila de etiquetas MPLS en pseudocable Ethernet)

    • Etiqueta 2..16 (20 bits)

    • Etiqueta exterior EXP (desactivado)

    • Etiqueta 1 (20 bits)

    • Índice de la interfaz entrante (deshabilitado)

  • MPLS, etiqueta de entropía

    Cuando se detecta una etiqueta de entropía, el campo de carga no se procesa y el indicador no se incluye en el cálculo del hash

    • Etiqueta 2.8 (20 bits)

      Etiqueta exterior EXP (desactivado)

      Etiqueta 1 (20 bits)

    • Índice de la interfaz entrante (deshabilitado)

Lista de actualizaciones de Junos para el cálculo de hash y el equilibrio de carga para enrutadores de la serie MX con MPC

Tabla 1: Lista de actualizaciones para enrutadores de la serie MX

Junos Release

Change

18.3R1

Incluye etiqueta de flujo IPv6, encabezado GRE interno y PPPoE interno en el cálculo hash predeterminado.

Aumenta la profundidad de la pila de etiquetas MPLS a 16 etiquetas.

17.2R1

Equilibrio de carga para paquetes IPv4 e IPv6 encapsulados L2TP.

16.1R1

Incluye hash de carga EoMPLS con palabra de control.

Introduce hash basado en solo origen y solo destino.

15.1R1

Proporciona una distribución dirigida de interfaces estáticas a través de vínculos de miembros de AE.

Incluye el origen, el destino y MAC de la carga PPPoE encapsulada MPLS en el cálculo hash predeterminado.

14.2R3

Aumenta el escalado de LAG y MC-LAG.

14,2 R2

Ofrece un paquete Ethernet agregado con vínculos de 10G, 40G y 100G.

14.1R1

Desacopla la creación de la interfaz aeX de ch agg eth dev.

Aumenta el espacio agregado de nombres de interfaz Ethernet.

Proporciona equilibrio de carga adaptable para los próximos saltos del ECMP.

13.3R1

Incluye mejoras para un equilibrio de carga adaptable, aleatorio por paquete y de reequilibrio periódico.

11.4R1

proporciona un uso compartido de la carga entre los próximos saltos del ECMP.