Introduzione
In questo documento viene descritta la procedura per risolvere i problemi di non interruzione delle sessioni PPPoE dopo una modifica della sottoscrizione in Cisco Policy Suite (CPS) su protocollo Radius.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- Linux
- CPS
- Protocollo Radius
Cisco consiglia di disporre dei privilegi di accesso:
- accesso root alla CLI di CPS
- Accesso utente "qns-svn" alle interfacce utente CPS (Policy Builder e Control Center)
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
CPS è progettato come modello server/client AAA (Authentication, Authorization, and Accounting) per supportare gli abbonati PPPoE (Point-to-Point over Ethernet). CPS interagisce con i dispositivi ASR9K o ASR1K per gestire le sessioni PPPoE.
Problema
Le sessioni PPPoE non si disconnettono e non si riconnettono dopo una nuova selezione di sottoscrizioni in CPS tramite una richiesta API (Application Programming Interface) SOAP (Simple Object Access Protocol) da un sistema di provisioning esterno.
L'osservazione è che CPS è in grado di generare la richiesta di modifica dell'azione (COA) e di inviarla al dispositivo ASR9K, ma queste richieste hanno un timeout da parte del dispositivo ASR9K con "No response Timeout Error" (Nessun errore di timeout di risposta).
Di seguito è riportato un esempio di messaggio di errore:
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
Fasi di riproduzione problemi
Passaggio 1. Avviare sessioni PPPoE da dispositivi ASR9K o ASR1K, accertarsi di visualizzare tali sessioni in CPS tramite Control Center.
Passaggio 2. Avviare una richiesta API SOAP per aggiornare la sottoscrizione dei servizi associati al sottoscrittore.
![Sample image for SOAP-API request](/c/dam/en/us/support/docs/wireless/policy-suite-mobile/217639-troubleshoot-non-termination-of-pppoe-se-00.png)
Passaggio 3. CPS avvia le richieste COA verso ASR9K o ASR1K. È possibile osservare che CPS esegue un nuovo tentativo della stessa richiesta con la richiesta duplicata dello stesso COA.
![CPS starts COA requests towards ASR9K](/c/dam/en/us/support/docs/wireless/policy-suite-mobile/217639-troubleshoot-non-termination-of-pppoe-se-01.png)
Nota: Il primo pacchetto non viene riconosciuto dal dispositivo peer (ASR9K), quindi la logica interna in CPS attiva un meccanismo di ripetizione e invia richieste duplicate.
Passaggio 4. L'osservazione è che CPS interrompe tutte le altre azioni di aggiornamento della sessione, in quanto non è disponibile alcuna risposta per la prima richiesta di COA della sessione e i relativi tentativi.
In questo modo è possibile verificare che la sessione PPPoE è ancora attiva in ASR9K e che non è stata inviata alcuna richiesta di disconnessione della sessione a CPS per l'aggiornamento della sessione. CPS prevede una richiesta di interruzione dell'accounting da ASR9K in relazione alla richiesta COA.
Punti principali da rilevare riguardo al Cacao e ai suoi ritiri
- CPS avvia le richieste COA per tutte le sessioni attive/esistenti nel relativo database per un determinato sottoscrittore.
- Se CPS non riceve ACK o NACK per una particolare richiesta COA, avvia un meccanismo di ripetizione dei tentativi in base alla configurazione nel generatore di criteri.
- È possibile configurare il numero di tentativi e la durata tra tentativi.
Configurazione dei tentativi di esempio
Soluzione
Per risolvere questo problema, è necessario estendere ulteriormente l'analisi verso ASR9K e scoprire il motivo per cui non è stata inviata una risposta a CPS per la richiesta COA e i relativi tentativi.
Nelle tracce dello sniffer potete vedere che il load balancer (LB01) di CPS origina il COA da <IP-1> e instrada i pacchetti su eth1, che è la route predefinita.
L'altro Load Balancer (LB02) genera il COA da <IP-2> e utilizza un percorso specifico tramite eth2.
ASR9K ha l'elenco degli accessi (ACL) per accettare il certificato di autenticità solo se proviene da <IP-2>, non da <IP-1>.
È quindi necessario correggere la tabella di routing in LB01 di CPS per inviare il COA con l'indirizzo IP di origine corretto, ovvero <IP-2> tramite un percorso specifico.
In questa schermata è possibile visualizzare la transazione RADIUS end-to-end riuscita per una modifica alla sottoscrizione e la successiva correzione necessaria alla tabella di route di CPS LB.
![Initiate a SOAP API request](/c/dam/en/us/support/docs/wireless/policy-suite-mobile/217639-troubleshoot-non-termination-of-pppoe-se-03.png)