CR16K 运营商BRAS场景下PPPOE用户IPv4无法获取地址，IPV6可以正常获取地址

 某地市城域网采用分布式 BRAS 设备（主控板 + 接入板 Slot 9 + NAT 业务板 Slot 2）作为 vBNG 接入网关。宽带家庭用户采用 PPPoE 私网双栈（IPv4 CGNAT + IPv6 公网）拨号上线。

近期在为 DHCP Server 扩容了一段新的宽带私网地址池（网段：X.X.X.0/18）后，部分用户反馈 IPv6 正常，但无法访问 IPv4 网络。 在 BRAS 上执行 display ppp access-user 检查，发现受影响用户的 IPv4 地址栏显示为 -。进一步抓包发现，用户的 IPv4 协议栈处于“不断请求 -> 短暂获取 -> 立即被踢”的死循环状态。

<SD-LC-SX-MSE-1.MAN>display ppp access-user username 用户名

Interface MAC address         IP address      Username

S/C-VLAN  IPv6 PDPrefix       IPv6 address

BAS41     MAC地址      -              用户名

491/305   V6地址

1. 抓取底层 Trace 日志，排查接入侧协商过程

针对故障用户的 MAC 地址开启 user-trace 进行信令追踪，观察 IPCP 的协商交互：

*Apr 29 19:52:49:651 2026 BRAS-A USER/7/USER_TRACEINFO:[objectID=1][slotID=9][PPP][user info:

MAC address: 989a-b916-e251

IP address: X.X.X.X

Access mode: PPPoE ]

[trace info:Assigned IP address X.X.X.X to a user]

*Apr 29 19:52:49:655 2026 BRAS-A USER/7/USER_TRACEINFO:[objectID=1][slotID=9][PPP]

[trace info:IPCP negotiation succeeded]

分析： 日志明确显示，接入板（Slot 9）的 DHCP 模块成功从新扩容的地址池中为用户分配了私网地址 X.X.X.X，并且 [trace info:IPCP negotiation succeeded] 表明 IPCP 状态机已协商成功。这排除了地址池耗尽或终端光猫不响应的可能。

2. 捕捉异常拆线动作，定位主动终结方

既然协商成功，终端却仍然无法获取 IPv4 路由，进一步查询地址释放原因：

*Apr 29 19:52:49:660 2026 BRAS-A USER/7/USER_TRACEINFO:[objectID=1][slotID=9][PPP]

[trace info:IPCP FSM close event]

*Apr 29 19:52:49:662 2026 BRAS-A USER/7/USER_TRACEINFO:[objectID=1][slotID=9][PPP]

[trace info:Sent an IPCP Termination Request packet

  ff 03 80 21 05 06 00 04 ]

分析： 在 IPCP 协商成功仅 5 毫秒后，BRAS 内部触发了 FSM close event（状态机关闭事件），并且是 BRAS 主动向终端发送了 Termination Request。这说明是 BRAS 控制平面强制掐断了刚刚建立的 IPv4 会话。

3. 捕捉跨板联动特征，锁定 NAT 申请失败

继续梳理拆线后的资源清理日志：

*Apr 29 19:52:49:935 2026 BRAS-A USER/7/USER_TRACEINFO:[objectID=1][slotID=9][PPP]

[trace info:Free ip address]

*Apr 29 19:52:50:210 2026 BRAS-A USER/7/USER_TRACEINFO:[objectID=1][slotID=2][PPP]

[trace info:Free ip address]

4. 排查 NAT 引流配置，确认故障根因

排查 Slot 2 绑定的 CGN 业务及引流 ACL 配置：

# 查看 CGN 业务板绑定关系

failover group cgn id 1

 bind slot 2 primary

#

# 查看 NAT 实例引流配置

nat-instance nat444-1

 nat outbound 2900 address-group 1

#

# 检查引流 ACL 2900

acl basic 2900 description pppoe-nat

 rule 5 permit source Y.Y.Y.0 0.0.127.255

分析： acl 2900 中目前仅放通了老私网地址池网段 Y.Y.Y.0/17。 而本次扩容的新网段是 X.X.X.0/18，引流 ACL 中未放通该网段。导致获取到新网段 IP 的用户无法命中 NAT 策略，申请不到端口块，进而被设备主动踢下线。

根因分析

在进行宽带私网地址池扩容时，仅配置了 DHCP Server，漏配了 CGNAT 侧对应的 NAT 引流 ACL。 导致新网段用户在接入板拿到私网 IP 后，向业务板申请 NAT 资源失败。BRAS 控制面出于资源保护，强制阻断了其 IPv4 连接，造成 IPCP 反复掉线。

在 NAT 引流的 acl 2900 中，补充一条 permit 规则，将新增的私网地址池网段 X.X.X.0/18 放通即可。

<BRAS-A> system-view

[BRAS-A] acl basic 2900

[BRAS-A-acl-ipv4-basic-2900] rule 10 permit source X.X.X.0 0.0.63.255

[BRAS-A-acl-ipv4-basic-2900] quit

处理结果： 配置下发后，观察 user-trace，获取到 X.X.X.X 网段的用户能够正常匹配 NAT 策略并成功获取端口块，未再出现 FSM close event，IPv4 恢复稳定在线，业务恢复正常。