Introduction
Este documento descreve o procedimento para solucionar problemas de não terminação de sessões PPPoE após uma alteração de assinatura no protocolo Cisco Policy Suite (CPS) sobre Radius.
Prerequisites
Requirements
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Linux
- CPS
- Protocolo Radius
A Cisco recomenda que você tenha acesso privilegiado:
- acesso raiz à CLI do CPS
- acesso de usuário "qns-svn" às GUIs do CPS (Policy Builder e Control Center)
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
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. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
O CPS foi projetado para funcionar como um modelo de servidor/cliente AAA (Authentication, Authorization, and Accounting - Autenticação, Autorização e Contabilidade), para suportar assinantes PPPoE (Point-to-Point Protocol over Ethernet - Protocolo Ponto a Ponto sobre Ethernet). O CPS interage com dispositivos ASR9K ou ASR1K para gerenciar sessões PPPoE.
Problema
As sessões PPPoE não desconectam e reconectam após uma nova seleção de assinatura no CPS por meio de uma solicitação de Interface de Programação de Aplicativos (API - Application Programming Interface) do Protocolo de Acesso a Objetos Simples (SOAP - Simple Object Access Protocol) de um sistema de provisionamento externo.
A observação é que o CPS é capaz de gerar a solicitação de alteração de ação (COA) e enviá-la para o dispositivo ASR9K, mas essas solicitações obtêm o tempo limite do dispositivo ASR9K com "No response Timeout Error" (Erro de tempo limite de resposta).
Aqui está um exemplo de mensagem de erro:
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
Etapas de Reprodução do Problema
Etapa 1. Inicie sessões PPPoE a partir de dispositivos ASR9K ou ASR1K, certifique-se de ver essas sessões no CPS através do Control Center.
Etapa 2. Inicie uma solicitação de API SOAP para atualizar a assinatura de serviços associados ao assinante.
Etapa 3. O CPS inicia solicitações COA para ASR9K ou ASR1K. Você pode observar que o CPS executa novamente a mesma solicitação com a solicitação duplicada do mesmo COA.
Note: O primeiro pacote não é confirmado pelo dispositivo peer (ASR9K), portanto, a lógica interna no CPS aciona um mecanismo de repetição e envia solicitações duplicadas.
Etapa 4. A observação é que o CPS descarta todas as outras ações de atualização da Sessão, pois não há resposta para a primeira solicitação de COA da Sessão e suas repetições.
Com isso, você pode ver que a sessão PPPoE ainda está ativa no ASR9K, e nenhuma solicitação de desconexão de sessão foi enviada ao CPS para a atualização da sessão. O CPS espera uma solicitação de parada de relatório do ASR9K em relação à solicitação COA.
Principais pontos a serem observados com relação ao COA e suas correções
- O CPS inicia solicitações COA para todas as sessões Ativas/Existentes em seu banco de dados para um assinante específico.
- Se o CPS não receber ACK ou NACK para uma solicitação de COA específica, ele iniciará um mecanismo de nova tentativa com base na configuração no construtor de políticas.
- O número de novas tentativas e a duração entre as novas tentativas é configurável.
Exemplo de configuração de nova tentativa
Solução
Para resolver esse problema, você precisa ampliar a análise para ASR9K e descobrir o motivo para não responder ao CPS para a solicitação de COA e suas novas tentativas.
Você pode ver no sniffer rastreios que o Load Balancer (LB01) do CPS origina o COA do <IP-1> e roteia os pacotes através do eth1, que é a rota padrão.
O outro Balanceador de Carga (LB02) origina o COA de <IP-2> e toma uma rota específica via eth2.
ASR9K tem a ACL (Access List, lista de acesso) para aceitar o COA somente se ele for proveniente de <IP-2>, não de <IP-1>.
Portanto, você precisa corrigir a tabela de rotas em LB01 do CPS para enviar o COA com o IP de origem apropriado, ou seja, <IP-2> através de uma rota específica.
Aqui você pode ver a transação RADIUS de ponta a ponta bem-sucedida para uma alteração de assinatura, após a correção necessária na tabela de rota LB do CPS.