對CPS中訂閱更改後無法終止的PPPoE會話進行故障排除

簡介

本檔案介紹在透過Radius通訊協定變更思科原則套件(CPS)後，對不終止PPPoE作業階段進行疑難排解的程式。

必要條件

需求

思科建議您瞭解以下主題：

• Linux
• CPS
• Radius通訊協定

思科建議您必須具有許可權訪問許可權：

• 對CPS CLI的root訪問許可權
• 「qns-svn」使用者訪問CPS GUI（策略生成器和控制中心）

採用元件

本文中的資訊係根據以下軟體和硬體版本：

• CPS 13.1
• UCS-B

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

CPS設計為用作身份驗證、授權和記帳(AAA)伺服器/客戶端模型，以支援乙太網點對點協定(PPPoE)使用者。CPS與ASR9K或ASR1K裝置互動以管理PPPoE會話。

問題

PPPoE會話不會通過來自外部調配系統的簡單對象訪問協定(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會話，確保您通過控制中心在CPS中看到這些會話。

步驟2.啟動SOAP API請求以更新與訂戶關聯的服務的訂用。

步驟3. CPS向ASR9K或ASR1K啟動COA請求。您可以看到CPS對相同COA的重複請求執行相同請求的重試。

附註：對等裝置(ASR9K)未確認第一個資料包，因此CPS中的內部邏輯會觸發重試機制並傳送重複請求。

步驟4.觀察結果為，CPS丟棄所有其他會話更新操作，因為第一個會話COA請求及其重試沒有響應。

這樣，您可以看到PPPoE會話在ASR9K仍處於活動狀態，並且沒有向CPS傳送會話刷新會話斷開請求。CPS要求來自ASR9K的有關COA請求的記帳停止請求。

COA及其退休人員應注意的幾個問題

1. CPS為其資料庫中針對特定訂戶處於活動/存在狀態的所有會話發起COA請求。
2. 如果CPS沒有收到特定COA請求的ACK或NACK，它將根據策略生成器中的配置啟動重試機制。
3. 重試次數和重試之間的持續時間是可配置的。

重試配置示例

解決方案

為了解決此問題，您需要對ASR9K進行進一步的分析，並需要找出沒有對COA請求及其重試的CPS做出響應的原因。

您可以在監聽器追蹤中看到，CPS的負載均衡器(LB01)從<IP-1>發出COA並通過預設路由eth1路由資料包。

另一個負載平衡器(LB02)從<IP-2>中獲取COA，它通過eth2獲取特定路由。

ASR9K具有訪問清單(ACL)，只有來自<IP-2>（而不是來自<IP-1>）的COA才接受。

因此，您需要糾正CPS的LB01處的路由表，以使用正確的源IP（即<IP-2>）通過特定路由傳送COA。

在這裡，您可以看到訂閱更改的端到端成功RADIUS事務，並在CPS LB路由表中進行必要的更正。