整个故障逻辑可能是这样的:
地址池冲突是根源:你的核心交换机和AC上配置了完全相同的DHCP地址池。这意味着网络中有两个DHCP服务器在为同一个网段分配IP地址。当AP插拔重启后,它可能会从核心交换机获取一个IP地址,这个IP地址可能恰恰是AC的管理IP地址,或者已经被AC上的某个虚拟接口占用了。
ARP双向学习受阻:
AP拿到IP后,会发送ARP请求来探测地址冲突或寻找网关。如你debug所见,AP的ARP请求能到达AC,AC也回复了。
问题出在核心交换机上。核心交换机上同时存在AC的ARP表项和AP的ARP表项。如果AP的IP地址与AC的某个接口IP(例如Vlan-interface4093)相同或冲突,核心交换机的ARP表就会紊乱。
核心交换机可能认为AC的MAC地址对应的是冲突的IP,或者对ARP报文的处理逻辑出现错误,导致它没有将AC的ARP回复报文正确地转发给AP。这就是你在核心上只能看到AP的请求,看不到AC回复的原因。根据H3C的经验案例,这种ARP地址冲突会导致核心交换机频繁报错 Duplicate address,并可能丢弃相关报文。
“过几小时又上线”与“IP地址变了”:
过几小时上线:这可能是因为ARP表项有老化时间(通常为20分钟)。当冲突的表项老化或被清除后,网络通信有可能暂时恢复。
IP地址变了:这正是IP地址冲突的典型后遗症。AP可能通过DHCP重新获取了一个新的IP地址,绕开了之前的冲突。这个行为与H3C官网案例中描述的,AP因地址冲突而发送DHCPDECLINE,然后重新进入DHCP流程获取新IP的过程高度吻合。
必须立即停止核心交换机和AC同时为同一网段分配IP地址。你需要选择一个作为唯一的DHCP服务器。
方案A:统一由核心交换机分配(推荐,如果你的AC地址也在此网段)。
在核心交换机上,配置dhcp server forbidden-ip,将AC的所有管理IP地址排除在DHCP地址池之外。例如,如果AC的地址是172.16.128.20,则配置 dhcp server forbidden-ip 172.16.128.20。
在AC上,删除或关闭用于该管理网段的DHCP服务。
方案B:统一由AC分配。
在核心交换机上,删除该网段的DHCP地址池配置,只保留一个指向AC的DHCP中继(如果AP在核心的另一个网段)。
确保AC上的DHCP地址池配置正确,且没有与其他重要设备(如核心交换机的管理地址)冲突。
清理ARP缓存:在核心交换机和AC上,清除可能存在的错误ARP表项。
重启AP:手动重启故障AP,观察其是否能正常获取IP并与AC建立隧道。
如果以上步骤未能完全解决问题,说明网络中还可能存在其他深层次原因:
检查交换机环路:搜索结果中提到,如果接入交换机端口配置了port bridge enable或存在物理环路,会导致AP发出的ARP报文经过环路后又回到AP自身,让AP认为IP地址冲突,从而拒绝使用DHCP分配的IP。请检查接入交换机(S6850_5)下联AP的端口配置。
检查AC上的AP模板:确认AC上没有为故障AP配置重复的模板。例如,同时通过序列号(SN)和MAC地址配置了两个不同的模板指向同一个物理AP,这会导致CAPWAP隧道建立失败。用 display wlan ap all 检查是否有状态为Conflict的AP。
能麻烦解释下为什么吗,感谢!
改下模式吧,多个同网段的dhcp服务器本身就不合理。原因无非就是dhcp,谁先提供ip,就找谁,搞不好还有ip冲突。你的应该是二层注册
建议改为三层注册上线+本地转发,dhcp全权由核心提供,ac只负责管理AP
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
抄袭了我的内容
×
原文链接或出处
诽谤我
×
对根叔社区有害的内容
×
不规范转载
×
举报说明
能麻烦解释下为什么吗,感谢!