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

无线网终端采用imc短信认证,但是每小时会掉线一次

  • 0关注
  • 0收藏,55浏览
粉丝:0人 关注:3人

问题描述:

华三无线网,ac和ap以及认证服务器imc v7均是华三产品.

网络中有2台ac,一台ac v5版本,集中转发模式,另外一个ac是v9版本,本地数据转发。

客户端采用基于imc的短信认证,设置为每7天重新认证一次的模式。

后来,在ac和客户端网络之间,增加了1台防火墙。

防火墙部署以后,基于v9 ac的客户端(本地转发)正常,采用v5 ac的客户端(集中转发),出现每小时被踢下线,需要重新认证的现象。

防火墙中放通了ac的ip地址,

如何检查问题的原因,解决被踢下线的问题?

4 个回答
粉丝:18人 关注:0人

这是一个非常典型的网络架构变更导致的故障,问题核心很可能出在防火墙与会话状态上。根据您的描述,我们可以按以下步骤进行排查和解决:
核心问题分析
故障现象明确指向了采用集中转发模式的V5版本AC在防火墙介入后出现周期性掉线。这强烈暗示防火墙中断了某种维持在线状态的关键会话。
详细排查与解决步骤
第一步:检查防火墙会话状态与策略
这是最可能的原因。集中转发模式下,所有用户数据流量都需经过AC,防火墙会看到并管理这些连接。
检查会话超时时间:登录防火墙,检查其 TCP/UDP会话老化时间。重点关注 udp和 other协议的超时设置。如果防火墙的会话表在1小时左右清除了不活跃的连接,而AC或认证系统恰好有每小时一次的心跳或状态更新,就会导致连接被重置。
临时验证:在防火墙上找到一条受影响用户的会话,观察其创建时间,看是否在接近1小时时被清除。
解决方案:适当延长防火墙的会话超时时间(例如,将UDP会话超时改为2-4小时),或启用 长连接​ 相关配置。
检查安全策略:确认放行的策略是否足够精确。除了AC的IP,还需要确保:
AP与AC之间的通信:CAPWAP隧道(通常使用UDP 5246、5247端口)流量必须双向通行无阻。这是集中转发的基础。
AC与IMC服务器之间的通信:确保RADIUS认证/计费端口(UDP 1812, 1813)的流量双向通行。特别要注意计费更新报文。
客户端与IMC之间:如果短信认证流程中有客户端直接与IMC服务器交互的步骤,也需放行相应流量。
第二步:在AC(V5)上检查关键日志与配置
查看用户掉线日志:在V5 AC上,当用户掉线时,查看系统日志或用户在线信息日志。关键信息是用户的 下线原因。常见原因有:
RADIUS Accounting Update Failure(RADIUS计费更新失败)
User Idle Timeout(用户空闲超时)
Connection Lost(连接丢失)
Administratively Reset(管理性重置)
明确下线原因能极大缩小排查范围。
检查RADIUS计费间隔:登录V5 AC,检查配置的RADIUS计费服务器(IMC)的 计费更新间隔。华三设备上通常有 accounting interim-interval配置项。这个值默认可能是3600秒(1小时)。如果AC每小时向IMC发送计费更新报文,但此报文被防火墙丢弃或IMC未正确响应,AC就会认为用户异常,将其踢下线。
解决方案:可以尝试在AC上调整此间隔(如改为1800秒),或确认IMC服务器端配置的静默超时时间与之匹配。
第三步:在IMC服务器上检查认证日志
登录IMC管理平台,找到认证日志或计费日志,筛选出故障用户。查看在用户掉线的时间点,IMC是否收到了AC发来的计费更新请求?是否发出了响应?响应是否正常?这里可以验证第二步的猜想。
第四步:对比V9 AC的配置与流量路径
既然V9 AC(本地转发)下的用户正常,这是一个很好的参照。
流量路径不同:本地转发模式下,用户的数据流量不经过AC,直接由AP通过防火墙转发。因此,防火墙看不到用户的数据会话,只管理AP到AC的控制流量和认证流量。这解释了为什么防火墙策略对V9 AC的用户影响小。
配置差异:对比两台AC上关于RADIUS服务器、计费、在线检测等方面的配置,看是否存在版本差异导致的默认配置不同。
总结与建议操作流程
立即检查:首先在防火墙上查看会话超时时间和拦截日志,同时在V5 AC上查看用户下线的具体原因日志。
重点配置:如果下线原因为计费更新失败,则同步检查AC的计费间隔、防火墙对此端口流量的放行情况、以及IMC服务器的响应。
策略调整:确保防火墙允许以下关键流量:AP <-> AC (CAPWAP), AC <-> IMC (RADIUS), 并且会话超时时间合理。
临时规避:如果急于恢复,可以尝试在防火墙上为来自V5 AC IP的流量设置更宽松的策略或更长的会话保持时间,作为临时措施。
根据经验,防火墙的UDP会话超时时间与AC的RADIUS计费更新间隔不匹配是导致此类周期性掉线的最常见原因。请优先从这两个方向入手排查。

暂无评论

粉丝:2人 关注:0人

Portal认证的“7天重认证”机制依赖于客户端、AC、IMC三者之间的在线心跳维持。当防火墙介入后,很可能会拦截或阻断这些心跳报文,导致AC误认为客户端已离线,从而强制踢下线。

为什么V5集中转发受影响,而V9本地转发正常?

对比维度V5 AC(集中转发)V9 AC(本地转发)
转发模式客户端所有流量(包括认证报文)都通过CAPWAP隧道送到AC处理认证报文上送AC,数据报文在AP本地转发
报文路径Portal心跳报文:客户端 → AP(隧道封装)→ AC → 防火墙 → IMCPortal心跳报文:客户端 → AP(直接转发)→ 接入交换机 → 防火墙 → IMC
关键差异AC作为流量的集中处理点,所有报文都经过ACAP直接与认证服务器交互,路径更短

由于V5 AC承担了所有报文的集中处理,防火墙介入后,更容易影响从AC到IMC的回程路径AC与AP之间的隧道稳定性

1. 检查防火墙会话超时设置

这是最常见的原因。Portal认证的心跳报文通常是UDP报文,而防火墙默认的UDP会话超时时间可能小于1小时(通常是300秒或1800秒)。

检查方法

  • 登录防火墙,查看会话表老化时间配置

  • 重点关注 UDP会话超时时间ASPF策略中针对Portal端口(UDP 50100/50200等)的配置

2. 检查AC上的Portal心跳配置

V5老版本AC的Portal心跳机制可能不如V9完善,需要手动开启或调整。

# 登录V5 AC,检查Portal配置 system-view wlan service-template 你的模板名 display this # 确保开启了Portal客户端在线探测功能 portal client-probe interval 300 # 建议设置5分钟(300秒) portal client-probe enable # 检查Portal服务器配置 portal server imc ip 1.2.3.4 # IMC服务器IP port 50100 # Portal端口 detect interval 300 # 心跳探测间隔 detect times 3 # 失败3次判定下线

关键命令

  • portal client-probe interval:设置AC向客户端发送心跳探测的间隔

  • 建议将探测间隔设为小于防火墙会话超时时间(如300秒),确保会话不被老化

3. 检查ARP表项学习问题

V5平台在集中转发模式下,如果没有开启ARP侦听,可能会导致AC无法学习到客户端的ARP信息,从而影响Portal认证状态的维持

# 在V5 AC上开启ARP snooping system-view arp-snooping enable interface Vlan-interface 业务VLAN arp-snooping enable

4. 检查Remote AP功能是否被意外触发

根据华三官方文档,V5 AC在开启Remote AP功能时,当AP与AC之间的隧道断开,AP会自动切换为本地转发模式,但隧道重建后,所有客户端会被强制下线。这可能导致你看到的“每小时被踢”现象。

检查方法

# 查看AP是否频繁掉线又重连

如果发现AP注册状态频繁变化,说明AC与AP之间的隧道不稳定,需要检查防火墙是否放通了CAPWAP控制隧道(UDP 5246)和数据隧道(UDP 5247)。

display wlan ap all display wlan ap statistics

暂无评论

粉丝:43人 关注:1人

检查一下AC及IMC日志看一下下线的原因看

暂无评论

军刺 五段
粉丝:3人 关注:0人

  • V9 AC(本地转发)正常
  • V5 AC(集中转发)每小时被踢、重认证
  • 中间加了防火墙
原因只有一个:
防火墙把 AC ↔ IMC 之间的「在线用户心跳 / 会话保持报文」给断了 / 老化了

导致 IMC 收不到 V5 AC 上报的用户在线状态,认为用户离线,每小时强制踢下线。 
V5 集中转发依赖 RADIUS 计费心跳,防火墙把 UDP 会话老化 / 拦截了,IMC 以为用户离线,每小时踢一次。  

暂无评论

编辑答案

你正在编辑答案

如果你要对问题或其他回答进行点评或询问,请使用评论功能。

分享扩散:

提出建议

    +

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

确定

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

注册后可访问此模块

跳转hclhub

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

举报

×

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

侵犯我的权益

×

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

泄露了我的隐私

×

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

侵犯了我企业的权益

×

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

抄袭了我的内容

×

原文链接或出处

诽谤我

×

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

对根叔社区有害的内容

×

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

不规范转载

×

举报说明