Descripción de las interfaces multiservicios agregadas para servicios de próxima generación
En este tema se proporciona información general sobre el uso de la característica Interfaces multiservicios agregadas con la tarjeta de servicios MX-SPC3 para servicios de próxima generación. Contiene las siguientes secciones:
Interfaz de multiservicios agregados
En Junos OS, puede combinar varias interfaces de servicios para crear un paquete de interfaces de servicios que pueden funcionar como una sola interfaz. Este paquete de interfaces se conoce como aggregated multiservices interface (AMS) y se denota 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 son compatibles con la tarjeta de servicios MX-SPC3 de servicios de próxima generación.
La configuración AMS proporciona una mayor escalabilidad, un 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 de AMS con un conjunto de servicios. Para los 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 el chasis. Esto permite que un paquete AMS de servicios de próxima generación tenga hasta 16 PIC de servicios como interfaces miembro y puede distribuir servicios entre las interfaces miembro.
Las interfaces miembro se identifican como mams en la configuración. El proceso de chasis en enrutadores que admiten la configuración AMS crea una entrada mams para cada interfaz multiservicios del enrutador.
Cuando se configuran opciones de servicios en el nivel de interfaz ams, las opciones se aplican a todas las interfaces 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. Todas las configuraciones son por PIC. Por ejemplo, el límite de sesión se aplica por miembro y no a nivel agregado.
No puede configurar las opciones de servicios tanto a nivel de ams (agregado) como de interfaz de miembro. Si las opciones de servicios están configuradas 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 de manera uniforme a todos los miembros, configure las opciones de servicios en el nivel de interfaz ams. Si necesita diferentes opciones para miembros individuales, configure las opciones de servicios en el nivel de interfaz de miembro.
Para NAT64 se requiere la caída de tráfico por miembro y la configuración del próximo salto por miembro. Para NAPT44, esta especificación por miembro permite claves hash arbitrarias, proporcionando mejores opciones de equilibrio de carga para permitir que se realicen operaciones NAT dinámicas. Para NAT64, NAPT44 y NAT44 dinámico, no es posible determinar qué miembro asigna la dirección NAT dinámica. Para garantizar que los paquetes de flujo inverso lleguen al mismo miembro que los paquetes de flujo directo, se utilizan rutas basadas en direcciones de grupo para dirigir los paquetes de flujo inverso.
Si modifica un grupo de NAT que está siendo utilizado por un conjunto de servicios asignado a una interfaz AMS, debe desactivar y activar el conjunto de servicios antes de que los cambios del grupo NAT surtan efecto.
La distribución del tráfico entre las interfaces miembro de una interfaz AMS puede producirse de forma rotativa o basada 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 el hash simétrico. La configuración de hash simétrico garantiza que el tráfico directo e inverso se enrute a través de la misma interfaz miembro.
Si el conjunto de servicios se aplica en la interfaz Gigabit Ethernet o 10 Gigabit Ethernet (conjunto de servicios de tipo interfaz) que funciona como NAT dentro de la interfaz, es posible que las claves hash utilizadas para equilibrar la 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. Debido a que la dirección IP de origen se somete a procesamiento NAT, no está disponible para hash del 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 directo e inverso no se asigna a la misma PIC. Con las teclas hash invertidas, el equilibrio de carga se produce correctamente.
Con los servicios del próximo salto, para el tráfico de reenvío, la tecla 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 la carga del tráfico o los siguientes saltos por miembro dirigen el tráfico inverso. Con los servicios de estilo de interfaz, la clave de entrada equilibra la carga del tráfico hacia adelante y la clave de salida equilibra la carga del tráfico hacia adelante o los próximos saltos por miembro dirigen el tráfico inverso. El tráfico directo es el tráfico que entra desde el lado interno de un conjunto de servicios y el tráfico inverso es el tráfico que entra desde el lado exterior de un conjunto de servicios. La tecla de avance es la clave hash utilizada 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 servicios de interfaz o con el estilo de servicios del próximo salto).
Con los firewalls con estado, puede configurar las siguientes combinaciones de teclas de avance y retroceso para el equilibrio de carga. En las siguientes combinaciones presentadas para claves hash, FOR-KEY se refiere a la clave de avance, REV-KEY denota la clave inversa, SIP significa dirección IP de origen, DIP significa dirección IP de destino y PROTO se refiere a protocolo como IP.
FOR-KEY: SIP, REV-KEY: DIP
FOR-KEY: SIP,PROTO REV-KEY: DIP, PROTO
CLAVE FOR: DIP, REV-KEY: SIP
CLAVE PARA: DIP,PROTO REV-KEY: SIP, PROTO
FOR-KEY: SIP,DIP REV-KEY: SIP, DIP
FOR-KEY: SIP,DIP,PROTO REV-KEY: SIP, DIP,PROTO
Con NAT estática configurada como NAT44 básica o NAT44 de destino, y con firewall de estado configurado o no, si la dirección directa del tráfico debe someterse a procesamiento NAT, configure las claves hash de la siguiente manera:
CLAVE FOR: DIP, REV-KEY: SIP
CLAVE PARA: DIP,PROTO REV-KEY: SIP, PROTO
Si la dirección inversa del tráfico debe someterse a procesamiento NAT, configure las claves hash de la siguiente manera:
FOR-KEY: SIP, REV-KEY: DIP
FOR-KEY: SIP,PROTO REV-KEY: DIP, PROTO
Con la NAT dinámica configurada y con el firewall de estado configurado o no, solo el tráfico de dirección directa puede someterse a NAT. La clave hash de reenvío puede ser cualquier combinación de SIP, DIP y protocolo, y se omite la clave hash inversa.
La configuración AMS de Junos OS admite tráfico IPv4 e IPv6.
Descripción general del tráfico IPv6 en las interfaces AMS
Puede utilizar 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 nivel de [edit interfaces ams-interface-name unit 1]
jerarquía. Cuando family inet
y family inet6
se establecen para una subunidad de interfaz AMS, se configuran en el nivel de conjunto de servicios para el estilo de interfaz y en el nivel IFL para el hash-keys
estilo del próximo salto.
Cuando se produce un error en una interfaz miembro de un paquete AMS, el tráfico destinado al miembro con error se redistribuye entre los miembros activos restantes. El tráfico (flujos o sesiones) que atraviesa los miembros activos existentes no se ve afectado. Si M miembros están activos actualmente, el resultado esperado es que solo alrededor de 1/M fracción del tráfico (flujos/sesiones) se ve afectada porque esa cantidad de tráfico se desplaza del miembro con errores a los miembros activos. Cuando la interfaz de miembro fallida vuelve a estar en línea, solo una fracción del tráfico se redistribuye al nuevo miembro. Si N miembros están activos actualmente, el resultado esperado es que solo alrededor de 1/(N+1) fracción del tráfico (flujos/sesiones) se vea 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 usa 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 use 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.
El número de flujos distribuidos, en un entorno ideal, puede ser 1/N en el mejor de los casos cuando el miembro N-ésimo 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 en el mundo real en la que el miembro A sirve solo un flujo, mientras que el miembro B sirve 10 flujos. Si el miembro B disminuye, entonces el número de flujos interrumpidos es 10/11. El comportamiento de división de grupo NAT está diseñado para aprovechar las ventajas de la función de minimización de refritos. La división de un grupo NAT se realiza para escenarios NAT dinámicos (NAT dinámico, NAT64 y NAPT44).
Si los flujos originales y redistribuidos se definen de la siguiente manera:
Member-original-flows: el tráfico asignado a un miembro cuando todos los miembros están activos.
Flujos redistribuidos de miembros: el tráfico adicional asignado a un miembro cuando falla otro miembro. Es posible que estos flujos de tráfico deban reequilibrarse cuando las interfaces miembro suben y bajan.
Con las definiciones anteriores de los flujos originales y redistribuidos para las interfaces miembro, se aplican las siguientes observaciones:
Los flujos originales de un miembro permanecen intactos mientras ese miembro esté activo. Tales flujos no se ven afectados cuando otros miembros se mueven entre los estados hacia arriba y hacia abajo.
Los flujos redistribuidos de miembros de un miembro pueden cambiar cuando otros miembros suben o bajan. Este cambio de flujos se produce porque estos flujos adicionales deben reequilibrarse entre todos los miembros activos. Por lo tanto, el flujo redistribuido de miembros puede variar mucho según que otros miembros bajen o suban. Aunque podría parecer que cuando un miembro disminuye, los flujos en los miembros activos se conservan, y que cuando un miembro sube, los flujos en 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 refrito solo gestiona los cambios operativos en el estado de una interfaz de miembro (como miembro sin conexión o restablecimiento de Junos OS de miembro). No controla cambios en la configuración. Por ejemplo, la adición o eliminación, o la activación y desactivación, de interfaces miembro en el [edit interfaces amsN load-balancing-options member-interface mams-a/b/0]
nivel jerárquico requiere que las PIC miembro sean rebotadas. No se admite dos veces NAT o hairpinning, similar a la compatibilidad con IPv4 para interfaces AMS.
Opciones de error de miembro y configuración de alta disponibilidad
Dado que se configuran varias interfaces de servicio como parte de un paquete AMS, la configuración de AMS también proporciona compatibilidad con la conmutación por error y la alta disponibilidad. Puede configurar una de las interfaces miembro como una interfaz de reserva que se activa cuando cualquiera de las otras interfaces miembro deja de funcionar, o configurar el AMS de tal manera que cuando una de las interfaces miembro deje de funcionar, 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 falla una interfaz miembro. Una opción es redistribuir el tráfico inmediatamente 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 elimine todo el tráfico asignado a la interfaz miembro con errores. Con esto, opcionalmente puede configurar un intervalo, , para que el AMS espere a que la interfaz fallida vuelva a estar en línea, rejoin-timeout
después de lo cual el AMS puede redistribuir el tráfico entre otras interfaces miembro. Si la interfaz miembro fallida vuelve a estar en línea antes del tiempo de espera configurado, el tráfico no se verá afectado en 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 member-failure-options
configuración, la interfaz con error no podrá volver a unirse al AMS cuando vuelva a estar en línea. En tales casos, puede volver a unirlo manualmente al AMS ejecutando el comando de request interfaces revert interface-name
modo operativo.
Las rejoin-timeout
instrucciones y enable-rejoin
permiten minimizar las interrupciones del tráfico cuando las interfaces miembro fallan.
Cuando member-failure-options
no están configurados, el comportamiento predeterminado es eliminar el tráfico de miembros 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 copia de seguridad. La interfaz de copia de seguridad no participa en las operaciones de enrutamiento mientras siga siendo una interfaz de copia de seguridad. Cuando se produce un error en una interfaz miembro, la interfaz de copia de seguridad controla el tráfico asignado a la interfaz fallida. Cuando la interfaz fallida vuelve a estar en línea, se convierte en la nueva interfaz de copia de seguridad.
En una configuración varios a uno (N:1), una única 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 demás interfaces miembro.
Cuando ambos member-failure-options
y high-availability-options
están 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 estar en línea para ser la nueva copia de seguridad, la member-failure-options
configuración surte efecto.
Redundancia de espera activa
A partir de Junos OS versión 19.3R2, la opción de espera semiactiva N:1 es compatible con MX-SPC3 si está ejecutando servicios de próxima generación. Cada interfaz AMS en espera semiactiva contiene dos miembros; Un miembro es la interfaz de servicio que desea proteger, denominada 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 produzca un error en la interfaz principal.
Para configurar el modo de espera semiactiva en una interfaz AMS, utilice la redundancy-options
instrucción. No puede utilizar la load-balancing-options
instrucción en una interfaz AMS en espera semiactiva.
Para cambiar de la interfaz principal a la secundaria, ejecute el request interface switchover amsN
comando.
Para revertir a la interfaz principal desde la interfaz secundaria, ejecute el request interface revert amsN
comando.
Tabla de historial de cambios
La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.