Fehlerbehebung bei Nichtbeendigung einer PPPoE-Sitzung nach einer Abonnementänderung in CPS

Einleitung

In diesem Dokument wird das Verfahren zur Fehlerbehebung bei Nichtbeendigung von PPPoE-Sitzungen nach einer Abonnementänderung im Protokoll Cisco Policy Suite (CPS) über Radius beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Linux
• CPS
• Radius-Protokoll

Cisco empfiehlt, dass Sie über folgende Berechtigungen verfügen müssen:

• Root-Zugriff auf die CPS-CLI
• "qns-svn"-Benutzerzugriff auf CPS-GUIs (Policy Builder und Control Center)

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• CPS 13.1
• UCS B

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrundinformationen

CPS ist als AAA-Server-/Client-Modell (Authentication, Authorization, and Accounting) konzipiert, das Point-to-Point Protocol over Ethernet (PPPoE)-Abonnenten unterstützt. CPS interagiert mit ASR9K- oder ASR1K-Geräten, um PPPoE-Sitzungen zu verwalten.

Problem

PPPoE-Sitzungen trennen und schließen nach einer neuen Abonnementauswahl in CPS nicht über eine SOAP-Anfrage (Simple Object Access Protocol) Application Programming Interface (API) von einem externen Bereitstellungssystem ab.

Die Beobachtung ist, dass der CPS die Change of Action (COA)-Anfrage generieren und an das ASR9K-Gerät senden kann. Diese Anforderungen erhalten jedoch eine Zeitüberschreitung durch das ASR9K-Gerät mit dem Befehl "No response Timeout Error" (Keine Antwort-Timeout-Fehler).

Die Beispiel-Fehlermeldung ist wie folgt:

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

Schritte zur Reproduktion von Problemen

Schritt 1: Initiieren Sie PPPoE-Sitzungen von ASR9K- oder ASR1K-Geräten, und stellen Sie sicher, dass diese Sitzungen über das Control Center in CPS angezeigt werden.

Schritt 2: Initiieren Sie eine SOAP-API-Anfrage, um das Abonnement der Dienste zu aktualisieren, die dem Teilnehmer zugeordnet sind.

Schritt 3: CPS startet COA-Anfragen für ASR9K oder ASR1K. Sie können beobachten, dass CPS mit der doppelten Anforderung desselben COA einen Wiederholungsversuch derselben Aufgabe durchführt.

Anmerkung: Das erste Paket wird vom Peer-Gerät (ASR9K) nicht bestätigt, sodass die interne Logik im CPS einen Wiederholungsmechanismus auslöst und doppelte Anfragen sendet.

Schritt 4: Die Beobachtung ist, dass CPS alle anderen Session Update-Aktionen verwirft, da keine Antwort auf die erste Session COA-Anforderung und deren Wiederholungen vorliegt.

Dadurch ist zu sehen, dass die PPPoE-Sitzung bei ASR9K noch aktiv ist und dass keine Anfrage zur Unterbrechung der Sitzung an CPS für die Sitzungsaktualisierung gesendet wurde. CPS erwartet eine Anfrage zum Anhalten der Buchhaltung von ASR9K in Bezug auf COA Request.

Wichtigste Punkte in Bezug auf COA und seine Retrires

1. CPS initiiert COA-Anfragen für alle Sitzungen, die in der Datenbank für einen bestimmten Teilnehmer aktiv/vorhanden sind.
2. Wenn der CPS für eine bestimmte COA-Anforderung kein ACK oder NACK empfängt, initiiert er einen Wiederholungsmechanismus, der auf der Konfiguration im Richtlinien-Generator basiert.
3. Die Anzahl der Wiederholungen und die Dauer zwischen den Wiederholungen ist konfigurierbar.

Beispielkonfiguration für Wiederholungen

Lösung

Um dieses Problem zu beheben, müssen Sie die weitere Analyse auf ASR9K ausweiten und den Grund für die Nichtantwort an CPS für die COA-Anfrage und deren Wiederholungen herausfinden.

Sie können in den Sniffer-Traces sehen, dass der Load Balancer (LB01) von CPS-Quellen-COA von <IP-1> ausgibt und die Pakete über eth1 weiterleitet, das die Standardroute ist.

Der andere Load Balancer (LB02) leitet COA von <IP-2> ein und führt eine bestimmte Route über eth2.

ASR9K verfügt über die Zugriffsliste (ACL), um das COA nur zu akzeptieren, wenn es von <IP-2> und nicht von <IP-1> stammt.

Daher müssen Sie die Routing-Tabelle bei LB01 des CPS korrigieren, um das COA mit der richtigen Quell-IP zu senden, also <IP-2> über eine bestimmte Route.

Hier sehen Sie die erfolgreiche End-to-End-RADIUS-Transaktion für eine Abonnementänderung, die ggf. in der CPS LB-Routing-Tabelle korrigiert werden muss.