CPS订用更改后PPPoE会话未终止故障排除

简介

本文档介绍在Cisco Policy Suite(CPS) over Radius协议订用更改后排除PPPoE会话未终止故障的过程。

先决条件

要求

Cisco 建议您了解以下主题：

• Linux
• CPS
• RADIUS协议

思科建议您必须具有权限访问：

• 对CPS CLI的根访问
• “qns-svn”用户对CPS GUI（策略构建器和控制中心）的访问

使用的组件

本文档中的信息基于以下软件和硬件版本：

• CPS 13.1
• UCS-B

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

CPS设计为作为身份验证、授权和记帐(AAA)服务器/客户端模型工作，以支持以太网点对点协议(PPPoE)用户。CPS与ASR9K或ASR1K设备交互以管理PPPoE会话。

问题

在CPS中通过来自外部调配系统的简单对象访问协议(SOAP)应用编程接口(API)请求进行新订用选择后，PPPoE会话不会断开和重新连接。

观察结果是，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只有来自<IP-2>而非来自<IP-1>时，才具有接入列表(ACL)接受COA。

因此，您需要更正CPS的LB01处的路由表，以便通过特定路由发送具有正确源IP（即<IP-2>）的COA。

在此，您可以看到订用更改的成功端到端RADIUS事务，在CPS LB路由表上进行必要的更正。