一种以太网宽带接入系统的用户认证管理方法
所属领域
本发明涉及一种城域网中用户接入的认证管理方法,属于宽带接入领域,特别是涉及一种以太网接入时,在以太网交换机上实现用户认证的方法。
背景技术
在目前的城域网建设中,大量采用FTTx+LAN的组网方式。其对接入用户的认证管理的实现主要采用宽带接入服务器(BAS)和PPPoE的方法。参考图1所示网络示意图:
1)宽带用户的计算机具有10/100M自适应网卡;
2)楼道交换机(BAN)为10/100M自适应的以太网交换机。
3)小区的中心交换机(ZAN)为下行100M,上行1000M的以太网交换机。
4)汇聚层网络通过宽带接入服务器连接各个小区的中心交换机,通过PPPoE的方式对用户进行认证,并对用户IP数据进行路由。
5)城域网中心有Radius服务器,完成用户实际的认证、鉴权功能。
宽带接入服务器BAS(Broadband Access Server)提供对用户计算机发来的PPPoE协议数据包的终结功能,并与Radius服务器通信,对用户进行必要的认证,最终,通过认证的用户数据包在宽带接入服务器上解开PPP封装,以纯IP包的形式路由到骨干网上;对于下行数据,由于从骨干网上下行到宽带接入服务器的数据是纯IP包,因此,宽带接入服务器需要对该IP包进行PPP和PPPoE协议封装,并发送给最终用户计算机。
但是,采用宽带接入服务器和PPPoE技术的用户管理方式也带来了一些问题:
1)由于宽带接入服务器要终结大量的PPP会话,并转发IP数据包,会造成BAS成为网络性能的巨大瓶颈;
2)宽带接入服务器通常放置在端局的位置,以下是巨大的广播域,从用户的安全性考虑,需要通过VLAN技术来实现用户的隔离,但是目前的设备标准只能支持最大4096个VLAN,无法支持端局以下巨大的用户群体(超过4096);
3)PPPoE+VLAN的方式实现用户隔离,由于PPPoE的点到点特性,使城域网主要的业务方向——组播视频业务的开展受到极大的限制;
4)由于宽带接入服务器是在通常数据网络设备之外额外增加的设备,采用宽带接入服务器和PPPoE方式无形之中增加了城域网建设的投资。
发明内容
本发明要解决的技术问题是提出一种基于以太网交换机的用户认证管理方法,具有组网结构简单,业务丰富,高性能,低成本的特点。
本发明提出的以太网宽带接入的用户管理认证方法,实现的过程如下:
在楼道交换机的每一个下行端口上建立一个管理通道和一个数据通道分别与最终用户相连;
1)数据通道:用来传送上/下行的Ethernet数据,该通道在用户未通过认证的情况下是关闭的。
2)管理通道:用来在楼道交换机和用户间传送协议信息,该通道始终是开启的。由于楼道交换机的每一个下行端口上有管理通道,因此,可以动态地控制该端口的数据通道上用户数据包的允许/拒绝传送。
楼道交换机的控制CPU通过管理通道获取用户的用户名/口令信息,并转换成标准的Radius协议发送到Radius服务器上,判断最终用户是否能够通过认证;
如果最终用户通过认证,则Radius服务器向该楼道交换机的CPU发送“分配给用户的地址信息”,该CPU转发该地址信息给用户,并开启数据通道,最终用户就能够访问宽带网络;
否则,用户的数据通道始终是关闭的,最终用户因未通过认证将无法访问宽带网络。
本方案可以解决用户认证、用户管理、地址浪费的问题,可以实现按时间或流量的计费方式。由于用户发送的数据包就是以太网包,不再需要局方购置价格昂贵的宽带接入服务器设备,也去掉了PPPoE和PPP协议的封装,加快可数据包处理的速度;同时可以更好地支持组播的业务,避免了在组播应用时,由于PPPoE的点到点特性,即使几个主机同属一个组播组,也要为每个主机复制一份数据流的问题。另外,本发明还具有以下的特点:
1.采用了路由器/L3交换机+L2交换机组网结构,网络结构简单;
2.各小区分散的路由方式,网络性能没有集中的瓶颈;
3.支持根据用户时长、用户端口流量的计费方式;
4.可以根据用户的ID在端口标识不同的优先级,实现对QoS的支持,并可对以太网端口进行访问速率的限制;
5.对组播的业务无任何影响;
6.只需对以太网交换机进行升级,成本低廉。
附图说明
图1是现有技术采用的宽带接入服务器和PPPoE方法的网络示意图;
图2是本发明以太网宽带接入用户认证管理方法的网络示意图;
图3是本发明以太网宽带接入用户认证管理方法的流程图;
图4是本发明以太网宽带接入用户认证管理方法的协议交互流程图。
具体实施方式
参考图2所示,本发明的以太网宽带接入方法在宽带接入网络的汇聚层采用通常的路由器实现各个小区流量的汇聚和路由,无需宽带接入服务器设备,所有的宽带接入功能在小区的楼道交换机(BAN)上分散实现,下面用具体实例展开介绍本发明的以太网宽带接入方法的实现过程。
假设可管理的楼道交换机(BAN)为25个端口,其中24个下行端口接用户计算机,1个上行端口接小区的中心交换机。对于所有的24个下行端口中的每一个端口,楼道交换机在逻辑上提供一个管理通道和一个数据通道与最终用户相连。
附图3所示的本发明以太网宽带接入用户认证管理方法流程在发明内容中已经做了详细的说明,这里就不再赘述。
参考附图4的协议流程图,由于楼道交换机的每一个下行端口上都有一个管理通道,可以动态地控制该端口的数据通道上用户数据包的允许/拒绝传送。用户的认证请求经过BAN中控制CPU的认证代理后成为Radius请求,经由ZAN、中心路由器到Radius服务器中进行Radius认证。控制的先决条件就是用户发送的认证包经过管理通道的代理后,发送到Radius服务器,是否被Radius服务器认证通过。经过Radius服务器认证判断后的Radius响应经由中心路由器、ZAN到BAN后,如果认证通过,开启该用户的数据通道,并通知用户认证成功,用户与BAN之间通过在线检测,即完成了该用户的认证管理过程。下面再针对认证过程中的报文设计等问题进行具体的说明。
1.BAN交换机上数据、管理通道的实现
缺省情况下,在楼道交换机(BAN)的所有24个下行端口的每一个端口上,设定MAC帧的过滤条件,如下:
序号 |
MAC源地址 |
MAC目的地址 |
动作 |
1 |
Any |
组播MAC地址01:00:5e:00:00:01(对应组播IP地址239.0.0.1) |
到BAN的以太网交换机控制CPU,做进一步协议处理 |
2 |
Any |
Any |
阻塞 |
序号1实现的是管理通道的功能,当用户向外发出目的地址为组播IP地址239.0.0.1(组播MAC地址为01:00:5e:00:00:01)的认证请求报文时,该报文被序号1的过滤条件截获,并送到BAN的控制CPU。认证请求报文为标准UDP报文,端口号为3080,其净荷部分的协议格式如下:
4 bytes
协议版本号,目前为1,协议类型标志符,对于认证请求报文,设定ID=0。
另外,以太网交换机的控制CPU还可以同时截获到该用户计算机的MAC地址,便于控制信息的回传。
2.代理认证过程
由于在BAN交换机的CPU配置了公网的IP地址,因此,BAN交换机的CPU作为Radius Client端,将用户侧发来的用户名/口令信息封装成Radius协议报文格式,通过ZAN和局方的路由器,最终发送给了Radius服务器。在Radius服务器上,如果该用户名/口令通过认证,则Radius服务器将通过Radius协议报文格式向认证代理(该楼道交换机)发送分配给用户的地址信息,该协议报文最终被该楼道交换机的控制CPU获取。
3.认证成功后的操作
楼道交换机(BAN)的控制CPU截获了Radius服务器发来的认证协议包,通过检验其内容,可以获知该用户是否通过了认证。如果:
1)认证失败:向用户发送认证失败消息,本机不做任何动作。
2)认证成功:开启该用户对应的数据通道,向用户PC发送分配给它的地址信息、DNS信息和缺省网关。
向用户发送的认证成功/失败报文同样采用UDP报文格式,端口号为3080,其净荷部分的格式如下:
a)认证失败报文
4 bytes
协议版本号,目前为1;协议类型标志符,对于认证失败报文,ID=1。
b)认证成功报文
4 bytes
协议版本号,目前为1,协议类型标志符,对于认证成功报文,ID=2
如果认证成功,用户的数据通道已经被打开,同时用户得到了IP地址信息,这样用户就能够访问宽带网络了。
4.用户下线检测
当用户上线后,为了检测用户是否下线,需要提供两种机制:
a)用户正常下线
在这种情况下,用户通过客户端向楼道交换机发送disconnect消息,告之用户下线,该协议包采用UDP报文格式,端口号为3080,其净荷部分的格式如下:
4 bytes
协议版本号,目前为1,协议类型标志符,对于disconnect报文,ID=3
b)用户异常下线
此情况是由于用户在上线的情况下突然关机等原因而引起的。为了检测用户是否异常下线,需要提供必要的keepalive机制。
在楼道交换机上,对于该交换机上的每一个上线用户,该交换机每隔HelloInterval,向该用户发送一个keepalive报文,如果在DeadInterval的时间内未收到该用户的回应keepalive报文,则认为用户已经下线。
下面是keepalive的报文格式:
4 bytes
协议版本号,目前为1,协议类型标志符,对于keepalive报文,ID=4。
无论通过哪种方式检测出用户已经下线,楼道交换机都要通知RadiusServer,该用户已经下线,完成IP地址回收和上网时间的计算;同时,还必须关闭该用户的数据通道。
5.用户端操作
用户端PC为了与楼道交换机进行协议交互,要求用户端能够完成以下功能的处理:
1)发送认证请求报文
2)接收认证成功/失败报文
3)如果认证成功,安装新分配的客户端地址、掩码、缺省网关、DNS Server地址等。
4)回应楼道交换机发来的keepalive报文
5)用户下线时发送disconnect报文
需要说明的是,用户PC初始发送认证请求包时,由于该用户还没有申请到地址,因此该认证请求包的源地址设定为用户PC上固定设置的地址(地址1)。当楼道交换机经过代理认证过程,确认用户通过/未通过认证,需要向用户计算机发送认证成功/失败报文时,该报文的目的IP地址设定为上面所说的地址1,而目的MAC地址设定为该用户PC的MAC地址,这样,用户PC就可以很好地接收和解释协议包了。
一旦用户PC安装了新分配的地址(地址2),用户PC与楼道交换机之间的协议交互以新分配的地址为源地址。