Alta disponibilidad para redes de acceso de suscriptores
Este tema es una descripción general de alto nivel de la alta disponibilidad para las redes de acceso DHCP, L2TP y PPP.
ISSU unificada para alta disponibilidad en redes de acceso de suscriptores
Una actualización de software en servicio unificada (ISSU unificada) le permite actualizar entre dos versiones diferentes de Junos OS sin interrupciones en el plano de control y con una interrupción mínima del tráfico. Los enrutadores conservan las sesiones de suscriptor activas y los servicios de sesión durante toda la actualización, de modo que continúen después de que se haya completado la actualización.
La característica ISSU unificada admite los modelos de acceso PPPoE, DHCP y L2TP para la administración de suscriptores. La compatibilidad con ISSU unificada para los modelos de acceso DHCP y L2TP se agregó en Junos OS versión 14.1.
Para el acceso PPPoE estático y dinámico, la ISSU unificada admite lo siguiente:
Conexiones PPPoE terminadas y sin túnel configuradas con interfaces lógicas PPP estáticas o dinámicas e interfaces subyacentes estáticas o dinámicas
Servicios de suscriptor en interfaces PPP de enlace único
Preservación de estadísticas para contabilidad, filtros y CoS en interfaces MPC/MIC
Nota:ISSU unificada para la administración de suscriptores El modelo de acceso PPPoE no admite interfaces de paquete de protocolo punto a punto multivínculo (MLPPP). Las interfaces de paquete MLPPP requieren el uso de una PIC de servicios adaptables o una PIC de multiservicios para proporcionar servicios de suscriptor de PPP. Estas PIC no admiten ISSU unificada.
Para el acceso DHCP, ISSU unificada admite lo siguiente:
Servidor local DHCPv4, relé DHCPv4, servidor local DHCPv6, relé DHCPv6 y proxy de relé DHCP
Conservación de estadísticas de contabilidad, filtros y clase de servicio (CoS) para suscriptores DHCP en interfaces MPC/MIC en enrutadores de la serie MX
Para el acceso L2TP, ISSU unificada admite tanto LAC como LNS. Cuando se inicia una actualización, LAC completa cualquier negociación L2TP que esté en curso, pero rechaza cualquier negociación nueva hasta que la actualización se haya completado. No se establecen nuevos túneles ni sesiones durante la actualización. Los cierres de sesión de suscriptor se registran durante la actualización y se completan después de que se haya completado la actualización.
Consulte Introducción a la actualización unificada de software en servicio para obtener una descripción de las plataformas y módulos compatibles, las instrucciones de CLI y los procedimientos que se usan para configurar e iniciar una ISSU unificada. Puede usar el indicador issu con la traceoptions instrucción para realizar un seguimiento de eventos ISSU unificados de administración de suscriptores. También puede utilizar el comando para mostrar información sobre el show system subscriber-management summary estado de ISSU unificado.
Verificación y supervisión de la administración de suscriptores Estado de ISSU unificado
Propósito
Muestra el estado de ISSU unificado para las características de administración de suscriptores.
Acción
El primer ejemplo indica que el modo inactivo del plano de control como parte de ISSU unificada no está en curso (por ejemplo, ISSU unificada no se ha iniciado, ya se ha completado o la cola del plano de control no se ha iniciado). El segundo ejemplo muestra que una ISSU unificada está en curso y que un demonio de administración de suscriptores participante requiere 198 segundos para poner en modo inactivo el plano de control.
user@host> show system subscriber-management summary
General:
Graceful Restart Enabled
Mastership Master
Database Available
Chassisd ISSU State IDLE
ISSU State IDLE
ISSU Wait 0
user@host> show system subscriber-management summary
General:
Graceful Restart Enabled
Mastership Master
Database Available
Chassisd ISSU State DAEMON_ISSU_PREPARE
ISSU State PREPARE
ISSU Wait 198
Cambio agraciado del motor de enrutamiento para las redes de acceso de suscriptores
La característica de cambio de motor de enrutamiento (GRES) de Junos OS permite que un enrutador con motores de enrutamiento redundantes continúe reenviando paquetes, incluso si falla un motor de enrutamiento. GRES conserva la información de la interfaz y del kernel. El tráfico no se interrumpe. Sin embargo, GRES no conserva el plano de control.
Para habilitar la compatibilidad con GRES en enrutadores de la serie MX, incluya la graceful-switchover instrucción en el nivel de [edit chassis redundancy] jerarquía.
DHCP
Para los enrutadores de la serie MX, el servidor local DHCP extendido y las aplicaciones del agente de retransmisión DHCP mantienen el estado de las concesiones de cliente DHCP activas en la base de datos de sesión. La aplicación DHCP extendida puede recuperar este estado si se produce un error en el proceso DHCP o se reinicia manualmente, evitando así la pérdida de clientes DHCP activos en cualquiera de estas circunstancias. Sin embargo, el estado de las concesiones de cliente DHCP activas se pierde si se produce un corte de alimentación o si el kernel deja de funcionar (por ejemplo, cuando se vuelve a cargar el enrutador) en un solo motor de enrutamiento.
No puede deshabilitar la compatibilidad con un cambio correcto de motor de enrutamiento para la aplicación DHCP extendida cuando el enrutador está configurado para admitir el cambio correcto de motor de enrutamiento.
Para obtener más información acerca del uso del cambio correcto del motor de enrutamiento, consulte Descripción del cambio correcto del motor de enrutamiento.
L2TP
GRES es compatible con los enrutadores de la serie MX que actúan como L2TP LAC o LNS. En caso de que L2TP (jl2tpd, el proceso de borde universal L2TP) se reinicie o que el enrutador conmute por error del motor de enrutamiento (RE) activo al RE en espera, L2TP GRES garantiza que ocurra lo siguiente:
El LAC y el LNS recuperan destinos, túneles y sesiones que ya estaban establecidos en el momento de la falla o el reinicio.
El LAC y el LNS responden a las solicitudes de mantenimiento de túneles recibidas durante el cambio para túneles establecidos, pero no generan ningún keepalives hasta que se completa el cambio.
LAC y LNS eliminan todos los túneles y sesiones que no están en el estado Establecido.
LAC y LNS rechazan las solicitudes para crear nuevos túneles y sesiones.
El LAC y el LNS envían otra notificación de desconexión al par para sesiones y túneles que ya están en el estado de desconexión en el momento de la falla o el reinicio. Para las sesiones y túneles que se estaban produciendo en ese momento, LAC y LNS envían una notificación de desconexión al par.
Los temporizadores de reinicio LAC y LNS para el período de tiempo de espera completo para destinos, túneles y sesiones L2TP recuperados.
Si un comando de modo operativo desencadena un cambio correcto de motor de enrutamiento (GRES), no se conservará el estado de las interfaces de servicios agregados (ASI). Por ejemplo:
request interface <switchover | revert> asi-interface
Sin embargo, si GRES se activa por una confirmación de CLI o un reinicio o bloqueo de FPC, el motor de enrutamiento de respaldo actualiza el estado de ASI. Por ejemplo:
set interface si-x/y/z disable commit
O:
request chassis fpc restart
Minimice la pérdida de tráfico debido a la eliminación de rutas obsoletas después de un cambio correcto del motor de enrutamiento
Durante un cambio de motor de enrutamiento ( GRES) elegante, las rutas de acceso y las rutas internas de acceso para la administración de suscriptores DHCP y PPP pueden quedar obsoletas. Después del GRES, el enrutador elimina cualquier ruta obsoleta de la tabla de reenvío. Parte del tráfico se pierde si las rutas obsoletas se eliminan antes de que se reinstalen las rutas.
En las redes de suscriptores con protocolos de reinicio y enrutamiento correctos, como BGP y OSPF configurados, el enrutador purga todas las rutas de acceso obsoletas restantes y las rutas internas de acceso tan pronto como se complete la operación de reinicio elegante, lo que puede ocurrir muy poco después de completar el cambio correcto del motor de enrutamiento.
En las redes de suscriptores con enrutamiento activo sin interrupciones (NSR) y protocolos de enrutamiento como BGP y OSPF configurados, el proceso de protocolo de enrutamiento (rpd) purga inmediatamente las rutas de acceso obsoletas y las rutas internas de acceso que corresponden a las rutas de suscriptor.
Puede reducir el riesgo de esta pérdida de tráfico configurando el enrutador para retrasar la eliminación de rutas obsoletas después de un GRES. El período de retraso es de 180 segundos (3 minutos) no configurables. El enrutador conserva las rutas obsoletas durante el período, que es el tiempo suficiente para que el proceso de cliente DHCP (jdhcpd), el proceso de cliente PPP (jpppd) o el proceso de protocolo de enrutamiento (rpd) reinstalen las rutas de acceso y las rutas internas de acceso antes de que el enrutador quite las rutas obsoletas de la tabla de reenvío. El riesgo de pérdida de tráfico se minimiza porque el enrutador siempre tiene rutas de suscriptor disponibles para suscriptores DHCP y suscriptores PPP.
Para configurar el enrutador para retrasar la eliminación (vaciado) de las rutas de acceso y las rutas internas de acceso después de un cambio correcto del motor de enrutamiento: