Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Descripción de interfaces de múltiples servicios agregadas para servicios de última generación

En este tema, se proporciona una descripción general del uso de la característica Interfaces de múltiples servicios agregadas con la tarjeta de servicios MX-SPC3 para servicios de próxima generación. Contiene las siguientes secciones:

Interfaz de múltiples servicios agregada

En Junos OS, puede combinar varias interfaces de servicios para crear un conjunto de interfaces de servicios que pueden funcionar como una sola interfaz. Dicho paquete de interfaces se conoce como ( aggregated multiservices interface AMS) y se indica como amsN en la configuración, donde N es un número único que identifica una interfaz AMS (por ejemplo, ams0). A partir de Junos OS versión 19.3R2, las interfaces AMS se admiten en la tarjeta de servicios MX-SPC3 de servicios de próxima generación.

La configuración de AMS ofrece mayor escalabilidad, rendimiento mejorado y mejores opciones de conmutación por error y equilibrio de carga.

Una configuración de AMS permite que los conjuntos de servicios admitan varias PIC de servicios mediante la asociación de un paquete AMS con un conjunto de servicios. Para servicios de próxima generación, la tarjeta de servicios MX-SPC3 admite hasta dos PIC y puede tener un máximo de ocho tarjetas de servicios MX-SPC3 en su chasis. Esto permite que un paquete de AMS de servicios de próxima generación tenga hasta 16 PIC de servicios como interfaces de miembro y puede distribuir servicios entre las interfaces miembro.

Las interfaces de miembro se identifican como mams en la configuración. El proceso de chasis en enrutadores compatibles con la configuración de AMS crea una entrada mams para cada interfaz multiservicio en el enrutador.

Cuando configure las opciones de servicios en el nivel de la interfaz ams, las opciones se aplican a todas las interfaces de miembro (mams) para la interfaz ams.

Las opciones también se aplican a los conjuntos de servicios configurados en interfaces de servicios correspondientes a las interfaces miembro de la interfaz ams. Todos los ajustes son por PIC. Por ejemplo, el límite de sesión se aplica por miembro y no a nivel agregado.

Nota:

No puede configurar opciones de servicios tanto a nivel de ams (agregado) como de interfaz de miembro. Si las opciones de servicios se configuran en vms-x/y/z, también se aplican a los conjuntos de servicios en mams-x/y/z.

Cuando desee que la configuración de opciones de servicios se aplique uniformemente a todos los miembros, configure las opciones de servicios en el nivel de interfaz ams. Si necesita configuraciones diferentes para miembros individuales, configure las opciones de servicios en el nivel de la interfaz de miembro.

Nota:

Se requiere una caída de tráfico por miembro y configuración del próximo salto por miembro para NAT64. Para NAPT44, esta especificación por miembro permite claves hash arbitrarias, lo que proporciona mejores opciones de equilibrio de carga para permitir que se realicen operaciones TDR dinámicas. Para NAT64, NAPT44 y NAT44 dinámico, no es posible determinar qué miembro asigna la dirección TDR dinámica. Para garantizar que los paquetes de flujo inverso lleguen al mismo miembro que los paquetes de flujo hacia adelante, se utilizan rutas basadas en direcciones de grupo para dirigir los paquetes de flujo inverso.

Nota:

Si modifica un conjunto TDR que está siendo utilizado por un conjunto de servicios asignado a una interfaz AMS, debe desactivar y activar el servicio establecido antes de que los cambios del conjunto TDR suban efecto.

La distribución de tráfico a través de las interfaces miembro de una interfaz AMS puede ocurrir de forma de round-robin o basado en hash. Puede configurar los siguientes valores de clave hash para regular la distribución del tráfico: source-ip, destination-ip y protocol. Para los servicios que requieren simetría de tráfico, debe configurar hash simétrico. La configuración de hash simétrica garantiza que el tráfico tanto hacia adelante como hacia atrás se enruta a través de la misma interfaz miembro.

Si el conjunto de servicios se aplica a la interfaz Gigabit Ethernet o 10 Gigabit Ethernet (conjunto de servicios de estilo de interfaz) que funciona como la interfaz TDR interior, es posible que las claves hash utilizadas para el equilibrio de carga se configuren de tal manera que la clave de entrada se establezca como dirección IP de destino y la clave de salida se establezca como dirección IP de origen. Dado que la dirección IP de origen se somete al procesamiento TDR, no está disponible para hashar el tráfico en la dirección inversa. Por lo tanto, el equilibrio de carga no ocurre en la misma dirección IP y el tráfico de reversa y reversa no se asigna a la misma PIC. Con las claves hash invertidas, el equilibrio de carga se produce correctamente.

Con los servicios de salto siguiente, para el tráfico de reenvío, la clave de entrada en la interfaz interna -equilibra la carga del tráfico y, para el tráfico inverso, la clave de entrada en la interfaz externa -equilibra el tráfico o los próximos saltos por miembro direccionan el tráfico de reversa. Con los servicios de estilo de interfaz, la clave de entrada equilibra el tráfico de reenvío y la clave de salida equilibra la carga de reenvío o los próximos saltos por miembro direccionan el tráfico inverso. El tráfico de reenvío es el tráfico que entra desde el lado interno de un conjunto de servicios y el tráfico de retroceso es el tráfico que ingresa desde el lado externo de un conjunto de servicios. La clave de reenvío es la clave hash que se utiliza para la dirección de avance del tráfico y la clave inversa es la clave hash utilizada para la dirección inversa del tráfico (depende de si se relaciona con los servicios de interfaz o con el estilo de servicios del próximo salto).

Con los firewalls con estado, puede configurar las siguientes combinaciones de claves hacia adelante e inverso para el equilibrio de carga. En las siguientes combinaciones presentadas para claves hash, FOR-KEY hace referencia a la clave de reenvío, REV-KEY indica la clave inversa, SIP significa dirección IP de origen, DIP significa dirección IP de destino y PROTO se refiere al protocolo como IP.

  • FOR-KEY: SIP, REV-KEY: DIP

  • CLAVE FOR-KEY: SIP, PROTO REV-KEY: DIP, PROTO

  • FOR-KEY: DIP, REV-KEY: SIP

  • CLAVE CLAVE: DIP, PROTO REV-KEY: SIP, PROTO

  • CLAVE FOR-KEY: SIP, DIP REV-KEY: SIP, DIP

  • CLAVE PARA: SIP, DIP, PROTO REV-CLAVE: SIP, DIP, PROTO

Con TDR estático configurado como NAT44 básico o NAT44 de destino, y con firewall de estado configurado o no, si la dirección de avance del tráfico debe someterse al procesamiento TDR, configure las claves hash de la siguiente manera:

  • FOR-KEY: DIP, REV-KEY: SIP

  • CLAVE CLAVE: DIP, PROTO REV-KEY: SIP, PROTO

Si la dirección inversa del tráfico debe someterse al procesamiento TDR, configure las claves hash de la siguiente manera:

  • FOR-KEY: SIP, REV-KEY: DIP

  • CLAVE FOR-KEY: SIP, PROTO REV-KEY: DIP, PROTO

Con TDR dinámico configurado y con firewall de estado configurado o no, solo el tráfico de dirección hacia adelante puede someterse a TDR. La clave hash reenviada puede ser cualquier combinación de SIP, DIP y protocolo, y la clave hash inversa se ignora.

Nota:

La configuración de Junos OS AMS admite tráfico IPv4 e IPv6.

Descripción general del tráfico IPv6 en interfaces AMS

Puede usar interfaces AMS para el tráfico IPv6. Para configurar la compatibilidad con IPv6 para una interfaz AMS, incluya la family inet6 instrucción en el [edit interfaces ams-interface-name unit 1] nivel de jerarquía. Cuando family inet y family inet6 se configuran para una subunidad de interfaz AMS, la se configura en el nivel de service-set para el hash-keys estilo de interfaz y en el nivel IFL para el estilo del salto siguiente.

Cuando se produce un error en una interfaz miembro de un paquete de AMS, el tráfico destinado al miembro fallido se redistribuye entre los miembros restantes activos. El tráfico (flujos o sesiones) que atraviesa los miembros activos existentes no se ve afectado. Si los miembros M están activos actualmente, el resultado esperado es que solo una fracción de 1/M del tráfico (flujos/sesiones) se ve afectada porque esa cantidad de tráfico se cambia del miembro fallido a seguir siendo miembros activos. Cuando la interfaz de miembro con errores vuelve a estar en línea, solo una fracción del tráfico se redistribuye al nuevo miembro. Si los miembros N están activos actualmente, el resultado esperado es que solo una fracción aproximada de 1/(N+1) del tráfico (flujos/sesiones) se ve afectada porque esa cantidad de tráfico se mueve al nuevo miembro restaurado. Los valores 1/M y 1/(N+1) suponen que los flujos se distribuyen uniformemente entre los miembros, porque se utiliza un hash de paquete para equilibrar la carga y porque el tráfico suele contener una combinación aleatoria típica de direcciones IP (o cualquier otro campo que se utiliza como claves de equilibrio de carga).

De manera similar al tráfico IPv4, para los paquetes IPv6, un paquete AMS debe contener miembros de un solo tipo de PIC de servicios.

La cantidad de flujos distribuidos, en un entorno ideal, puede ser 1/N en el mejor de los casos cuando el Nth miembro sube o baja. Sin embargo, esta suposición considera que las claves hash equilibran la carga del tráfico real o dinámico. Por ejemplo, considere una implementación real en la que el miembro A solo atiende un flujo, mientras que el miembro B sirve a 10 flujos. Si el miembro B cae, la cantidad de flujos interrumpidos es de 10/11. El comportamiento TDR de división de conjuntos está diseñado para utilizar los beneficios de la función de minimización de rehash. La división de un conjunto de TDR se realiza para escenarios TDR dinámicos (TDR dinámico, NAT64 y NAPT44).

Si los flujos originales y redistribuidos se definen de la siguiente manera:

  • Flujos originales de miembro: el tráfico asignado a un miembro cuando todos los miembros están en activo.

  • Flujos redistribuidos por miembros: tráfico adicional asignado a un miembro cuando falla algún otro miembro. Es posible que sea necesario reequilibrar estos flujos de tráfico cuando las interfaces de los miembros suba y bajan.

Con las definiciones anteriores de los flujos originales y redistribuidos para interfaces de miembro, se aplican las siguientes observaciones:

  • Los flujos originales del miembro de un miembro permanecen intactos mientras ese miembro esté activo. Estos flujos no se ven afectados cuando otros miembros se mueven entre los estados ascendentes y descendentes.

  • Los flujos redistribuidos de un miembro pueden cambiar cuando otros miembros suban o bajan. Este cambio de flujos se produce porque es necesario reequilibrar estos flujos adicionales entre todos los miembros activos. Por lo tanto, el flujo redistribuido de miembros puede variar mucho según otros miembros que bajan o suban. Aunque pueda parecer que cuando un miembro cae, los flujos de los miembros activos se conservan y que cuando un miembro sube, los flujos de los miembros activos no se conservan de manera efectiva, este comportamiento se debe solo al reequilibrio estático o basado en hash del tráfico entre los miembros activos.

La función de minimización de rehash gestiona los cambios operativos solo en el estado de una interfaz de miembro (como un miembro sin conexión o un miembro de Junos OS restablecimiento). No maneja cambios en la configuración. Por ejemplo, la adición o eliminación, o la activación y desactivación de interfaces de miembros en el [edit interfaces amsN load-balancing-options member-interface mams-a/b/0] nivel jerárquico requiere que se reboten las PIC miembro. No se admiten dos veces TDR o hairpinning, similar a la compatibilidad con IPv4 para interfaces AMS.

Opciones de falla de miembro y configuración de alta disponibilidad

Dado que se configuran varias interfaces de servicio como parte de un paquete de AMS, la configuración de AMS también proporciona conmutación por error y soporte de alta disponibilidad. Puede configurar una de las interfaces de miembro como una interfaz de copia de seguridad que se activa cuando cualquiera de las otras interfaces miembro falla, o configurar la AMS de tal manera que cuando una de las interfaces miembro falla, el tráfico asignado a esa interfaz se comparta entre las interfaces activas.

La member-failure-options instrucción de configuración le permite configurar cómo controlar el tráfico cuando se produce un error en una interfaz miembro. Una opción es redistribuir el tráfico de inmediato entre las otras interfaces miembro. Sin embargo, la redistribución del tráfico implica volver a calcular las etiquetas hash y puede causar alguna interrupción en el tráfico en todas las interfaces miembro.

La otra opción es configurar el AMS para que suelte todo el tráfico que se asigna a la interfaz de miembro con error. Con esto, opcionalmente puede configurar un intervalo, rejoin-timeoutpara que ams espere a que la interfaz fallida vuelva a estar en línea, después de lo cual ams puede redistribuir el tráfico entre otras interfaces miembro. Si la interfaz de miembro con errores vuelve a estar en línea antes del tiempo de espera configurado, el tráfico continúa sin afectar a todas las interfaces miembro, incluida la interfaz que volvió a estar en línea y reanudó las operaciones.

También puede controlar la reincorporación de la interfaz fallida cuando vuelva a estar en línea. Si no incluye la enable-rejoin instrucción en la configuración, la member-failure-options interfaz fallida no puede volver a incorporarse a AMS cuando vuelva a estar en línea. En tales casos, puede volver a asociarlo manualmente al AMS ejecutando el comando de request interfaces revert interface-name modo operativo.

Las rejoin-timeout instrucciones y enable-rejoin le permiten minimizar las interrupciones de tráfico cuando las interfaces de miembro flap.

Nota:

Cuando member-failure-options no están configurados, el comportamiento predeterminado es soltar el tráfico de miembro con un tiempo de espera de reincorporación de 120 segundos.

La high-availability-options configuración le permite designar una de las interfaces miembro como interfaz de respaldo. La interfaz de copia de seguridad no participa en las operaciones de enrutamiento, siempre que siga siendo una interfaz de respaldo. Cuando se produce un error en una interfaz miembro, la interfaz de respaldo controla el tráfico asignado a la interfaz fallida. Cuando la interfaz con errores vuelve a estar en línea, se convierte en la nueva interfaz de respaldo.

En una configuración varios a uno (N:1), una sola interfaz de copia de seguridad admite todas las demás interfaces miembro del grupo. Si se produce un error en alguna de las interfaces miembro, la interfaz de copia de seguridad se hace cargo. En esta configuración sin estado, los datos no se sincronizan entre la interfaz de copia de seguridad y las otras interfaces miembro.

Cuando ambos member-failure-options están high-availability-options configurados para un AMS, la high-availability-options configuración tiene prioridad sobre la member-failure-options configuración. Si se produce un segundo error antes de que la interfaz fallida vuelva a conectarse para ser la nueva copia de seguridad, la member-failure-options configuración tendrá efecto.

Redundancia de espera caliente

A partir de Junos OS versión 19.3R2, la opción de espera caliente N:1 se admite en MX-SPC3 si está ejecutando servicios de última generación. Cada interfaz AMS en espera caliente contiene dos miembros; un miembro es la interfaz de servicio que desea proteger, llamada interfaz principal, y un miembro es la interfaz secundaria (copia de seguridad). La interfaz principal es la interfaz activa y la interfaz de copia de seguridad no controla ningún tráfico a menos que se produce un error en la interfaz principal.

Para configurar la espera caliente en una interfaz AMS, utilice la redundancy-options instrucción. No puede usar la load-balancing-options instrucción en una interfaz AMS en espera caliente.

Para cambiar de la interfaz principal a la secundaria, emita el request interface switchover amsN comando.

Para revertir a la interfaz principal desde la interfaz secundaria, emita el request interface revert amsN comando.

Tabla de historial de versiones
Lanzamiento
Descripción
19.3R2
A partir de Junos OS versión 19.3R2, las interfaces AMS se admiten en la tarjeta de servicios MX-SPC3 de servicios de próxima generación.
19.3R2
A partir de Junos OS versión 19.3R2, la opción de espera caliente N:1 se admite en MX-SPC3 si está ejecutando servicios de última generación.