Alta disponibilidad para redes de acceso de suscriptores
Este tema es una descripción general de alto nivel de la alta disponibilidad para redes de acceso DHCP, L2TP y PPP.
ISSU unificado 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 interrupción en el plano de control y con una interrupción mínima del tráfico. Los enrutadores conservan las sesiones y los servicios de sesión del suscriptor activos durante la actualización, de modo que continúen después de que se haya completado la actualización.
La función ISSU unificada admite los modelos de acceso PPPoE, DHCP y L2TP para la administración de suscriptores. En la versión 14.1 de Junos OS, se agregó soporte ISSU unificado para los modelos de acceso DHCP y L2TP.
Para el acceso PPPoE estático y dinámico, ISSU unificado admite lo siguiente:
Conexiones PPPoE terminadas y no tunelizadas, 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 vínculo único
Conservación de estadísticas para contabilidad, filtros y CoS en interfaces MPC/MIC
Nota:ISSU unificado para la administración de suscriptores El modelo de acceso PPPoE no admite interfaces de agrupación de protocolo punto a punto multivínculo (MLPPP). Las interfaces de agrupación MLPPP requieren el uso de una PIC de servicios adaptativos o una PIC de multiservicios para proporcionar servicios de suscriptor PPP. Estas PIC no admiten la ISSU unificada.
Para el acceso DHCP, ISSU unificado admite lo siguiente:
Servidor local DHCPv4, relé DHCPv4, servidor local DHCPv6, relé DHCPv6 y proxy de relé DHCP
Preservación de estadísticas de contabilidad, filtro y clase de servicio (CoS) para suscriptores de DHCP en interfaces MPC/MIC en enrutadores de la serie MX
Para el acceso L2TP, la ISSU unificada admite tanto el LAC como el LNS. Cuando se inicia una actualización, el LAC completa las negociaciones L2TP que están 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 los suscriptores se registran durante la actualización y se completan después de que esta se haya completado.
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 la CLI y los procedimientos que usa para configurar e iniciar la ISSU unificada. Puede utilizar 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 show system subscriber-management summary comando para mostrar información sobre el estado unificado de ISSU.
Verificación y supervisión de la gestión de suscriptores Estado unificado de ISSU
Propósito
Muestra el estado de ISSU unificado para las funciones de administración de suscriptores.
Acción
El primer ejemplo indica que la inmovilización del plano de control como parte de una ISSU unificada no está en curso (por ejemplo, una ISSU unificada no se ha iniciado, ya se ha completado o no se ha iniciado la cola del plano de control). En el segundo ejemplo se muestra que la 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
Conmutación agraciada del motor de enrutamiento para redes de acceso de suscriptores
La característica de conmutación del motor de enrutamiento (GRES) de Junos OS permite que un enrutador con motores de enrutamiento redundantes continúe reenviando paquetes, aun 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 enrutadores de la serie MX, el servidor local DHCP extendido y las aplicaciones de 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 si se reinicia manualmente, lo que evita la pérdida de clientes DHCP activos en cualquiera de estas circunstancias. Sin embargo, el estado de las concesiones activas de clientes DHCP se pierde si se produce un corte de energía 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 el cambio normal del motor de enrutamiento para la aplicación DHCP extendida cuando el enrutador está configurado para admitir el cambio normal del motor de enrutamiento.
Para obtener más información sobre cómo usar el cambio normal del motor de enrutamiento, consulte Descripción del cambio normal del motor de enrutamiento.
L2TP
GRES se admite en 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 activo (RE) al RE en espera, L2TP GRES garantiza que ocurra lo siguiente:
LAC y LNS recuperan destinos, túneles y sesiones que ya se establecieron en el momento de la falla o el reinicio.
El LAC y el LNS responden a las solicitudes de keepalive de túnel recibidas durante la conmutación para túneles establecidos, pero no generan ninguna señal de mantenimiento hasta que se completa la conmutación.
LAC y LNS eliminan todos los túneles y sesiones que no estén en el estado Establecido.
El LAC y el LNS rechazan solicitudes para crear nuevos túneles y sesiones.
El LAC y el LNS envían otra notificación de desconexión al par para las sesiones y los túneles que ya están en estado Desconexión en el momento de la falla o el reinicio. Para las sesiones y los túneles que estaban surgiendo en ese momento, LAC y LNS envían una notificación de desconexión al par.
El LAC y el LNS reinician los temporizadores durante el período de tiempo de espera completo para los destinos, túneles y sesiones de L2TP recuperados.
Si un comando del modo operativo activa una conmutación normal del motor de enrutamiento (GRES), no se conserva 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 bien:
request chassis fpc restart
Minimice la pérdida de tráfico debido a la eliminación de rutas obsoletas después de un cambio agraciado del motor de enrutamiento
Durante una conmutación agraciada del motor de enrutamiento (GRES), las rutas de acceso y las rutas internas de acceso para la administración de suscriptores DHCP y PPP pueden volverse obsoletas. Después del GRES, el enrutador elimina estas rutas obsoletas de la tabla de reenvío. Parte del tráfico se pierde si se eliminan las rutas obsoletas antes de que se vuelvan a instalar las rutas.
En redes de suscriptores con protocolos de reinicio y enrutamiento correctos, como BGP y OSPF configurados, el enrutador purga las rutas de acceso obsoletas restantes y las rutas internas de acceso tan pronto como se complete la operación de reinicio normal, lo que puede ocurrir muy poco después de que se complete el cambio correcto del motor de enrutamiento.
En redes de suscriptores con enrutamiento activo sin paradas (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 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 sea suficiente para que el proceso de cliente DHCP (jdhcpd), el proceso de cliente PPP (jpppd) o el proceso de protocolo de enrutamiento (rpd) vuelvan a instalar 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 de DHCP y 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:
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.