Solución de problemas de no terminación de la sesión PPPoE después de un cambio de suscripción en CPS

Introducción

Este documento describe el procedimiento para resolver problemas de no terminación de sesiones PPPoE después de un cambio de suscripción en el protocolo Cisco Policy Suite (CPS) sobre Radius.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Linux
• CPS
• Protocolo Radius

Cisco recomienda que tenga acceso privilegiado:

• acceso raíz a CPS CLI
• acceso de usuario "qns-svn" a las GUI de CPS (Policy Builder and Control Center)

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• CPS 13.1
• UCS-B

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

CPS está diseñado para funcionar como modelo de servidor/cliente de autenticación, autorización y contabilidad (AAA), para admitir suscriptores de protocolo punto a punto sobre Ethernet (PPPoE). CPS interactúa con los dispositivos ASR9K o ASR1K para administrar las sesiones PPPoE.

Problema

Las sesiones PPPoE no se desconectan ni se reconectan después de una nueva selección de suscripción en CPS a través de una solicitud de interfaz de programación de aplicaciones (API) de protocolo simple de acceso a objetos (SOAP) de un sistema de aprovisionamiento externo.

La observación es que CPS puede generar la solicitud de cambio de acción (COA) y enviarla al dispositivo ASR9K, pero esas solicitudes tienen tiempo de espera agotado para el dispositivo ASR9K con "Error de tiempo de espera sin respuesta".

Este es el ejemplo de mensaje de error:

dc1-lb01  dc1-lb01 2021-09-28 21:26:13,331 [pool-2-thread-1] ERROR c.b.p.r.jms.PolicyActionJmsReceiver - Error executing RemoteAction.  Returning Error Message response
com.broadhop.exception.BroadhopException: Timeout: No Response from RADIUS Server
        at com.broadhop.radius.impl.actions.AsynchCoARequest.execute(AsynchCoARequest.java:213) ~[com.broadhop.radius.service_13.0.1.r150127.jar:na]
        at com.broadhop.utilities.policy.remote.RemoteActionStub.execute(RemoteActionStub.java:62) ~[com.broadhop.utility_13.0.0.release.jar:na]
        at com.broadhop.policy.remote.jms.PolicyActionJmsReceiver$RemoteActionExecutor.run(PolicyActionJmsReceiver.java:98) ~[com.broadhop.policy.remote.jms_13.0.0.release.jar:na]
        at com.broadhop.utilities.policy.async.PolicyRemoteAsyncActionRunnable.run(PolicyRemoteAsyncActionRunnable.java:24) [com.broadhop.utility_13.0.0.release.jar:na]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_72]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_72]
        at com.broadhop.utilities.policy.async.AsyncPolicyActionExecutionManager$GenericThead.run(AsyncPolicyActionExecutionManager.java:301) [com.broadhop.utility_13.0.0.release.jar:na]
Caused by: net.jradius.exception.TimeoutException: Timeout: No Response from RADIUS Server
        at net.jradius.client.RadiusClientTransport.sendReceive(RadiusClientTransport.java:112) ~[na:na]
        at net.jradius.client.RadiusClient.changeOfAuth(RadiusClient.java:383) ~[na:na]
        at com.broadhop.radius.impl.actions.AsynchCoARequest.execute(AsynchCoARequest.java:205) ~[com.broadhop.radius.service_13.0.1.r150127.jar:na]
        ... 6 common frames omitted

Pasos de reproducción del problema

Paso 1. Inicie sesiones PPPoE desde dispositivos ASR9K o ASR1K, asegúrese de ver esas sesiones en CPS a través de Control Center.

Paso 2. Inicie una solicitud de API SOAP para actualizar la suscripción de servicios asociada al suscriptor.

Paso 3. CPS inicia las solicitudes de COA hacia ASR9K o ASR1K. Puede observar que CPS realiza un reintento de la misma solicitud con la solicitud duplicada del mismo COA.

Nota: El primer paquete no es reconocido por el dispositivo de par (ASR9K), por lo que la lógica interna en CPS activa un mecanismo de reintento y envía solicitudes duplicadas.

Paso 4. La observación es que CPS descarta todas las demás acciones de actualización de Sesión, ya que no hay respuesta para la primera solicitud de COA de Sesión y sus reintentos.

Con esto, puede ver que la sesión PPPoE sigue activa en ASR9K y no se envió ninguna solicitud de desconexión de sesión hacia CPS para la actualización de la sesión. CPS espera una solicitud de detención de contabilidad de ASR9K con respecto a la solicitud COA.

Principales aspectos que deben tenerse en cuenta con respecto al COA y sus jubilaciones

1. CPS inicia las solicitudes COA para todas las sesiones Active/Exist en su base de datos para un suscriptor determinado.
2. Si CPS no recibe ACK o NACK para una solicitud COA determinada, inicia un mecanismo de reintento basado en la configuración en el generador de políticas.
3. Se puede configurar el número de reintentos y la duración entre reintentos.

Ejemplo de configuración de reintento

Solución

Para resolver este problema, necesita analizar más a fondo ASR9K y encontrar la razón para no recibir respuesta a CPS para la solicitud de COA y sus reintentos.

Puede ver en los rastros del sabueso que el equilibrador de carga (LB01) de CPS origina COA desde <IP-1> y enruta los paquetes a través de eth1, que es la ruta predeterminada.

El otro equilibrador de carga (LB02) origina COA desde <IP-2> y toma una ruta específica a través de eth2.

ASR9K tiene la lista de acceso (ACL) para aceptar el COA sólo si procede de <IP-2>, no de <IP-1>.

Por lo tanto, debe corregir la tabla de rutas en LB01 de CPS para enviar el COA con la IP de origen adecuada, es decir <IP-2> a través de una ruta específica.

Aquí puede ver la transacción RADIUS de extremo a extremo correcta para un cambio de suscripción, publicar la corrección necesaria en la tabla de ruta CPS LB.