CPSのサブスクリプション変更後のPPPoEセッションの非終了のトラブルシューティング

概要

このドキュメントでは、Radiusプロトコルを使用したCisco Policy Suite(CPS)のサブスクリプション変更後にPPPoEセッションが終了しない場合のトラブルシューティング手順について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Linux
• CPS
• RADIUS プロトコル

次の特権アクセス権が必要です。

• CPS CLIへのルートアクセス
• CPS GUIへの「qns-svn」ユーザアクセス（ポリシービルダーおよびコントロールセンター）

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• CPS 13.1
• UCS-B

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

CPSは、Point-to-Point Protocol over Ethernet(PPPoE)加入者をサポートする認証、許可、アカウンティング(AAA)サーバ/クライアントモデルとして機能するように設計されています。CPSはASR9KまたはASR1Kデバイスと通信して、PPPoEセッションを管理します。

問題

PPPoEセッションは、外部プロビジョニングシステムからのSimple Object Access Protocol(SOAP)アプリケーションプログラミングインターフェイス(API)要求を介してCPSで新しいサブスクリプションが選択された後に切断および再接続されません。

CPSはアクション変更(COA)要求を生成してASR9Kデバイスに送信できますが、これらの要求は「応答タイムアウトエラーなし」でASR9Kデバイスによってタイムアウトされます。

次にエラーメッセージの例を示します。

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

再生手順の発行

ステップ1:ASR9KまたはASR1KデバイスからPPPoEセッションを開始し、Control Center経由でCPSでこれらのセッションを確認します。

ステップ2:SOAP API要求を開始して、サブスクライバに関連付けられているサービスのサブスクリプションを更新します。

ステップ3:CPSはASR9KまたはASR1Kに対するCOA要求を開始します。CPSが同じCOAの重複した要求を使用して同じ要求の再試行を実行していることがわかります。

注：最初のパケットはピアデバイス(ASR9K)によって確認応答されないため、CPSの内部ロジックによって再試行メカニズムがトリガーされ、重複する要求が送信されます。

ステップ4：最初のセッションCOA要求とその再試行に対する応答がないため、CPSは他のすべてのセッション更新アクションをドロップします。

これにより、ASR9KでPPPoEセッションが引き続きアクティブであり、セッション更新のためにCPSに対してセッション切断要求が送信されていないことがわかります。CPSは、COA要求に関してASR9KからのAccounting Stop要求を想定しています。

COAとその退職者に関して注目すべき主なポイント

1. CPSは、特定のサブスクライバのデータベース内のすべてのセッションのアクティブ/存在要求を開始します。
2. CPSは、特定のCOA要求に対するACKまたはNACKを受信しない場合、ポリシービルダーの設定に基づいて再試行メカニズムを開始します。
3. 再試行の回数と間隔は設定可能です。

再試行設定の例

解決方法

この問題を解決するには、さらにASR9Kに対する分析を拡張し、COA要求とその再試行に対するCPSへの応答がない理由を調べる必要があります。

スニファトレースでは、CPSのロードバランサ(LB01)が<IP-1>からCOAを発信し、デフォルトルートであるeth1経由でパケットをルーティングしていることがわかります。

もう1つのロードバランサ(LB02)は<IP-2>からCOAを発信し、eth2経由の特定のルートを使用します。

ASR9Kには、COAが<IP-1>からではなく<IP-2>から送信された場合にのみ、COAを受け入れるアクセスリスト(ACL)があります。

そのため、CPSのLB01のルートテーブルを修正して、適切な送信元IP（特定のルートを経由する<IP-2>）を使用してCOAを送信する必要があります。

サブスクリプションの変更に関する正常なエンドツーエンドRADIUSトランザクションを確認できます。CPS LBルートテーブルで必要な修正を投稿してください。