• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
  • 漏洞说明
  • 全部
  • 全部
  • 大数据引擎
  • 知了引擎
产品线
搜索
取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式
高级搜索

特定环境下交换机重发大量计费报文导致Radius服务器不可用预警

2008-05-13 发表
  • 0关注
  • 0收藏 846浏览
粉丝: 关注:

特定环境下交换机重发大量计费报文导致Radius服务器不可用预警

 

一、问题描述:

终端大面积认证失败,客户端上提示Radius服务器无响应。此时更改Radius服务器上的后台日志级别为调试,会发现即使将Radius服务器的网络断开,后台调试日志文件的大小仍然迅速增大,打开日志文件查看其内容会发现每秒钟打印出上百个Radius报文。

二、原因分析:

用户认证成功之后的在线状态下,交换机与Radius服务器(iMCCAMS)之间缺省每隔10分钟交互一次关于该用户的实时记费报文(又称计费更新报文)。用户下线时,交换机将发送关于该用户的计费结束报文至Radius服务器。

我司交换机缺省配置的情况下,当发送这两种报文时若与Radius服务器通讯不上(没有收到回应报文),则采取以下机制尝试重发:

实时计费报文的重发机制:

假设应答超时时长(timer response-timeout命令设置)为3秒,超时重传次数(retry命令设置)为3,设备的实时计费间隔(timer realtime-accounting命令设置)为10分钟(由Radius服务器决定),设备允许实时计费失败的最大次数为5次(retry realtime-accounting命令设置),则其含义为:设备每隔10分钟发起一次计费请求,如果3秒钟得不到回应就重新发起一次请求,如果3次发送都没有得到回应就认为该次实时记费失败,然后每隔10分钟再发送一次,5次均失败以后,设备将切断用户连接,同时发送计费结束给Radius服务器。50分钟内共重发计费更新15次。

计费结束报文的重发机制:

假设应答超时时长(timer response-timeout命令设置)为3秒,超时重传次数(retry命令设置)为3,通讯异常时缓存计费结束报文的功能使能(stop-accounting-buffer enable设置),计费结束报文缓存后重发次数为500次(retry stop-accounting 命令设置)。则其含义为:设备首先尝试重发3次计费结束报文,每隔3秒尝试一次,如果3次都失败则将报文缓存在buffer里,并立即开始不断重发,尝试500次,每隔3秒尝试一次,如果500次发送都没有得到回应就认为该次计费结束失败。立即开始第2次尝试,同样尝试500次,每次间隔3秒。3次尝试均失败后放弃不再重发。共不断重发1503次计费结束报文。

若某段时间内认证设备与Radius服务器通讯中断,则恢复通讯之后设备缺省配置的情况下将尝试重发大量的Radius报文至服务器。服务器短时间内收到大量的每隔3秒发送的重试报文(包括计费更新、计费结束,主要是计费结束报文),超出了服务器的处理能力导致后台瘫痪。服务器将来不及处理的报文存放在软件的处理队列中逐个处理并回应,而等到服务器回应某报文时,交换机上则认为该报文已经超时,于是继续不断重发,最终导致服务器上的软件处理队列被大量的重试报文塞满,无法及时处理新用户的认证请求。该问题发生后,经过一段时间当软件的队列处理完毕后服务器会自动恢复,问题现象会自动消失。

三、  解决方法:

以下两个方案可避免问题的发生,可根据实际情况选择:

1. 为避免问题发生,新版本的iMC/UAM以及CAMS版本对于软件处理队列的长度做了修改,将之前缓存10000个报文减少到512个报文。超出队列的报文服务器将丢弃,不会因为达到处理性能的瓶颈而造成后台瘫痪。对于认证用户数量较大(同时在线用户数量在500以上)的局点建议将CAMS服务器的版本升级为2.10-F0211P03及以后版本。iMC目前的版本不提供升级包,有条件的情况下建议将iMC/UAM服务器的版本重新安装为3.20-E0401及以后版本。

2. 修改交换机上的缺省参数,减少设备重发计费报文的次数。

system-view                       //进入系统视图

radius scheme sdu                 //进入radius scheme视图

retry realtime-accounting 3       //配置设备允许实时计费失败的最大次数,由缺省5次更改为3

retry stop-accounting 10          //配置计费结束报文发送失败并缓存后的最大重发次数,由缺省500次修改为10

若您有关于案例的建议,请反馈:

作者在2008-05-13对此案例进行了修订
0 个评论

该案例暂时没有网友评论

编辑评论

举报

×

侵犯我的权益 >
对根叔知了社区有害的内容 >
辱骂、歧视、挑衅等(不友善)

侵犯我的权益

×

泄露了我的隐私 >
侵犯了我企业的权益 >
抄袭了我的内容 >
诽谤我 >
辱骂、歧视、挑衅等(不友善)
骚扰我

泄露了我的隐私

×

您好,当您发现根叔知了上有泄漏您隐私的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您认为哪些内容泄露了您的隐私?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)

侵犯了我企业的权益

×

您好,当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱,我们会在审核后尽快给您答复。
  • 1. 您举报的内容是什么?(请在邮件中列出您举报的内容和链接地址)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
  • 3. 是哪家企业?(营业执照,单位登记证明等证件)
  • 4. 您与该企业的关系是?(您是企业法人或被授权人,需提供企业委托授权书)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

抄袭了我的内容

×

原文链接或出处

诽谤我

×

您好,当您发现根叔知了上有诽谤您的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您举报的内容以及侵犯了您什么权益?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔知了社区有害的内容

×

垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载 >
辱骂、歧视、挑衅等(不友善)
骚扰我
诱导投票

不规范转载

×

举报说明

提出建议

    +

亲~登录后才可以操作哦!

确定

亲~检测到您登陆的账号未在http://hclhub.h3c.com进行注册

注册后可访问此模块

跳转hclhub

你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作