Probleemoplossing niet-beëindiging van PPPoE-sessie na abonnementswijziging in CPS

Inleiding

Dit document beschrijft de procedure om problemen op te lossen met de niet-beëindiging van PPPoE-sessies na een abonnementsverandering in Cisco Policy Suite (CPS) via het Radius-protocol.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Linux
• CPS
• Radius-protocol

Cisco raadt u aan bevoorrechte toegang te hebben:

• worteltoegang tot CPS CLI
• qns-svn toegang van gebruikers tot CPS GUI's (Policy building and Control Center)

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• CPS 13.1
• UCS-B

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.

Achtergrondinformatie

CPS is ontworpen om te werken als AAA-server/clientmodel (verificatie, autorisatie en accounting) ter ondersteuning van Point-to-Point Protocol over Ethernet (PPPoE)-abonnees. CPS interageert met ASR9K of ASR1K apparaten om PPPoE sessies te beheren.

Probleem

PPPoE-sessies ontkoppelen en opnieuw verbinden niet na een nieuwe abonnementsselectie in CPS via een API-verzoek (Simple Object Access Protocol) voor toepassingsprogrammeerinterface (API) van een extern voorzieningssysteem.

CPS kan het verzoek tot wijziging van de actie (COA) genereren en naar het ASR9K-apparaat sturen, maar deze verzoeken krijgen tijd door het ASR9K-apparaat met "Time-outfout Geen respons".

Hier is de foutmelding:

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

Reproductiestappen afgeven

Stap 1. Start PPPoE-sessies van ASR9K of ASR1K-apparaten, zorg ervoor dat u deze sessies in CPS via Control Center ziet.

Stap 2. Start een API-verzoek om het abonnement op services die bij de abonnee horen te uploaden.

Stap 3. CPS start COA-verzoeken naar ASR9K of ASR1K. U kunt zien dat CPS hetzelfde req opnieuw probeert met het dubbele verzoek van dezelfde COA.

Opmerking: Het eerste pakket wordt niet erkend door het peer apparaat (ASR9K), vandaar de interne logica in CPS veroorzaakt een herprobeert mechanisme en stuurt dubbele verzoeken.

Stap 4. De observatie is dat CPS alle andere sessieupdate actie onderdrukt, omdat er geen respons is op het eerste sessieverzoek en de opnieuw uitgevoerde sessies.

Hierdoor ziet u dat de PPPoE-sessie nog steeds actief is op ASR9K, en er is geen sessie afkoppelingsverzoek naar CPS verzonden voor de sessie. CPS verwacht dat ASR9K een verzoek om accounting stop indient met betrekking tot COA-aanvraag.

Belangrijkste punten die moeten worden opgemerkt met betrekking tot de COA en de bijbehorende banden

1. CPS initieert COA verzoeken voor alle sessies die actief zijn/bestaan in zijn database voor een bepaalde abonnee.
2. Als CPS geen ACK of NACK voor een bepaald COA-verzoek ontvangt, start het een herstartmechanisme op basis van de configuratie in de beleidsbouwer.
3. Het aantal herhalingen en de duur tussen de opnieuw proberen is configureerbaar.

Configuratie opnieuw proberen

Oplossing

Om dit probleem op te lossen moet u de analyse naar ASR9K verder uitbreiden en moet u de reden voor het verzoek van de COA en zijn herhalingen vinden om geen antwoord op CPS te geven.

U kunt in de sniffer sporen zien dat de taakverdeling (LB01) van CPS-bronnen COA van <IP-1> en de pakketten routeert via eth1, de standaardroute.

De andere taakverdeling (LB02) levert COA-bronnen van <IP-2> en neemt een specifieke route via eth2.

ASR9K heeft de Toegangslijst (ACL) om de COA te accepteren slechts als het van <IP-2> komt, niet van <IP-1>.

U moet dus de routetabel bij LB01 van CPS corrigeren om de COA met de juiste bron-IP te verzenden, dat is <IP-2> via een specifieke route.

Hier kunt u de succesvolle end-to-end RADIUS-transactie zien voor een verandering van abonnement, postnoodzakelijke correctie in de routetabel van CPS LB.