PPPoE认证方式中用户“挂死”现象分析及解决策略

1、pppoe认证方式中用户“挂死现象分析及解决策略近年来，随着宽带业务的蓬勃发展，原來用于圈地的包月制计费方式己经不 能满足用户的要求，宽带应用管理计费系统的建设己经成为电信运营商迫切的需 求。在这种情况下，各省地市电信运营商都将宽带应用管理计费平台的建设纳入 了计划日程。笔者在参与运营商宽带应用管理计费系统建设过程中，发现普遍存在用户挂 死现象，这需要引起运营商的注意，因为这个问题在运营商宽带应用管理计费系 统建设中关系重大。2 pppoe的认证过程为了更好地理解挂死现象产生的原因，下面先分析pppoe认证计费流程。图 1所示为典型的电信运营商认证计费系统pppoe认证计费流程。2.1 ppp

2、oe认证的发现阶段用户打开pppoe虚拟拨号程序，计算机通过在以太网上广 播 padt ( pppoe active discovery initiation )分组来发现宽带接入服务 器(bas ) , padi 分组一旦到达 bas , bas 回发 pado(pppoe active discovery offer)分组作为响应。此时，可以认为发现阶段已经完成。但是，人 们通常把lcp ( link control protocol )过程也视为发现阶段的一部分， 即计算机作为ppp终端发送lcp分组来配置和测试链路(在此过程中需要指 定认证的压缩方式等参数)，bas冋送双方确认的信息，

3、同吋指定本次计费 认证信息的session-id 。需要注意的是，该session-id在本次连接过程屮 是惟一的，计费中以这个1d号来惟一标识这次连接。至此，发现阶段结束。2. 2 pppoe认证 的连接阶段与bas建立链路之后，pppoe终端发出认证包请求认证，这种认证包 可以米用 pap (password authentication protocol )或者 chap ( chai 1 enge handshake authentication protocol )两种方式，基于对网络安全性的考虑，一 般采用chap方式。bas收到认证报文后，根据系统的设置判断如何处理该 报-文。b

4、as如果设置为本地认证，那么它就发给内置的认证服务器进行处理; 如果定义为radius认证，那么它将这个认证报文转发给系统设置的远 程radius server 。远程radius server 一，般是某数据库的客户端，该数据库 存储了所有用户的基本信息，包括用户名、密码、登录名以及账务信息等。远 程radius server根据登录名从数据库中检索岀密码数据进行对比，如果相符, 就取出相关的属性值发给bas ,这个属性包一般称为授权包。bas根据授 权包约束用户的会话，一般从带宽、空闲时长或最大连接时长等方面进行约束。 同吋，bas还要起到dhcp server的作用。在执行完这些功能以

5、后，bas在建立起连接的同时，向radius server发送一个计费开始包。这 样，一个连接就建立起来了，用户通过该链路收发数据，bas则负责对这些 数据流量进行计数。2.3 pppoe认证的断线阶段断线其实是一个比较复杂的问题。图1所示是正常情况下用户主动断线 过程。用户点击pppoe拨号程序的“断开连接”按钮，计算机就通过该程序发 送 padt(pppoe active discovery terminate) 分组，当 padt 分组到 达bas后，bas计算本次会话的流量等信息，并将这些信息封装在一个计 费结束报文屮发送给计费系统。正常情况下，计费系统根据这些信息产生一条账 单，账单

6、信息进入系统结算程序进行结算。但很多时候可能岀现沖止常断线，如 直接关机、断电等。非正常断线需要通过宽带bas的在线监测机制进行判定， 例如在bas和用户计算机之间建立一种连接，bas定期轮询用户计算机， 用户计算机做应答，如果多次收不到应答，则认为用户计算机非正常下 线，bas根据记录产生一个计费结束报文，发送本次会话信息给计费系统作 为账务处理依据。以上便是pppoe认证计费的整个流程。3 产牛“挂死”现象的原因在实际应用中我们发现，部分在计费系统中表现为在线的用户实际已经下 线，这种现象就是所谓的“挂死” o如果计费系统屮“允许账号同时在线的最大 用户数”设置为“1”，那么“挂死”的用户

7、在下次登录时将无法上线。根据pppoe认证计费流程来分析，用户“挂死”的实质从计费系统角度来看 就是：系统未收到计费终止包，无法形成计费记录；用户下线，计费系统相对于 用户而言是被动的，如果没有原因促使其做出下线判断，就可能造成用户一直在 线的假象。结合在线测试，我们发现以下因素会引发“挂死”现象。(1) bas不稳定。这是引发“挂死”现象的主要原因。在实际应用中我们 发现，一般情况下挂死的用户以某一时间点为分界点，这意味着计费系统在这一 段吋间没有收到计费终止包，存在bas短吋间故障，造成当时在线用户全部非 正常下线，而bas未发出任何计费终止包，造成这批用户全部“挂死”。bas故 障导致用

8、户“挂死”这一结论在我们进行的bas割接中得到了证实：割接时， 所有的割接前在线用户全部挂死！此外，bas处理能力不够也会产生“挂死”现 象。通过测试与对比，我们发现：在用户规模相同的情况下，性能指标优越的 bas与一般国产的bas发生“挂死”现象的比例相差其远。(2) bas和计费系统radius server之间网络不稳定。radius server协 议采用的是udp,虽然bas每次会将计费终止包向radius server传送3次，且 radius server和bas之间采用了实时探测机制，但仍无法保证所有的计费终止 包被完整收到。我们通过查看计费终止包统计报告，得知：正常情况下，r

9、adius server的丢包率为3%,同一计费终止包3次全丢失的概率约为百万分之二十七, 即10 000个用户屮每天有1个用户正常挂死。网络异常情况下，显然会大大增 加这种概率。加之，目前许多运营商采用分散接入控制方式，计费系统离bas 距离较 远，网络状况比较复杂，从而增大了用户“挂死”的可能性。(3) 计费系统radius server处理能力不够。如果radius server处理能力不够，可以从系统的资源情况中得到查证，一旦系统资源不够，可能丢弃部分 计费终止包。4 “挂死"现象的解决方案如果是因bas不稳定和/或bas和计费系统radius server之间网络不稳定 造

10、成用户“挂死”，则比较难解决。这是因为运营商通常是批量部署bas的，出 于抢占市场考虑，当时主要是解决接入控制问题，对bas的性能要求和对较低 更没有进行与计费系统的互通测试。只有通过开发一些更好的检测用户在线的机 制来减少“挂死”现象。如是因radius server处理能力不够引起用户“挂死”，则相对而言比较容 易解决。现有的计费系统都支持多radius server,可以通过增加radius server 来缓解处理压力。通过对整个流程和radius协议的仔细分析，我们发现rfc 2869扩展的radius 协议中interim-accounting机制（也称keep al i ve功能

11、）可以加以开发利用， 以尽量避免"挂死”现彖的发生。interim-accounting机制是指bas对于在线 用户，每隔一定时间（可 设置，精度为分）向radius server发送 interim-accounting信息，表示用户在线。interim-accounting信息包中包含 有用户截止到当前的上网信息（主要指流量信息）。如果bas开启该功能，就 会向计费系统定吋发送interim-accounting信息，计费系统定义一个刷新间隔, 在间隔时间内未收到该信息，就认为用户下线，并将最后一个 interim-accounting信息包作为计费终止包来完成用户的下线操作。这

12、样，无 论什么原因造成 计费终止包丢失，都可以通过interim-accounting信息包来代 替，从而有效地避免“挂死”现象的发牛。在这种情况下，需避免误将木来在线 的用户强行断线，因为interim-accounting信息包同样存在着像计费终止包一 样丢失的可能性。一般应将计费系统的刷新间隔设置为bas发出 interim-accounting信息包的周期的3倍，只有系统连续3个 interim-accounting信息包都没有收到，才将没有计费终止包的用户强行下 线，从而减少错误判断的概率。当然，上述功能是通过增加系统负荷为代价来实现的。通常情况下，bas的 负荷理论上增加200%以上，计费系统的负荷也增加200%以上：假设用户平均每 次连续上网时间为30min（通常情况下宽带用户连续上网时间会大于这个数字）, bas按每5 min发出一次interim-accounting信息包，计费系统刷新时间为15 min,在启用interim-accounting功能以前，在30 min内,bas和计费系统都 只处理1个认证请求报文，1个计费开始报文，1个计费终止报文，而启用后， 正常情况下（绝大部分用户都是正常用户），增加了 6个interim-accounting 信息包，负荷增加了 200%。虽然现在计算机的处理能力越来越高，增加的负荷 基本不