最近在运维过程中应客户要求上架了一套Msater Redundancy Standalone架构，版本为8.7.0.0，因业务需求，终结了分支机构的AP-303使用本地转发模式，然而在使用过程中发现出现了同一局域网内两个AP-303下的终端无法文件共享以及VNC远程软件，在收到报障后，我检查了AC上的日志，并没有发现任何异常日志，且跟用户沟通发现上面提到的两个应用出现了问题，其他业务都是正常的，在初步确认了网络流量的情况下，我尝试更换其他型号的AP进行测试，发现除AP-303外其他的AP下并不会出现过这种情况。

最终尝试在终端以及控制器和AP上联口进行抓包未排查到问题后，我考虑将AC版本升到8.7.0.1（问题发生时较稳定的最新版本为8.7.0.1），但因这一套AC是生产设备且上面还另外终结了上百台集中转发的AP，所以最终决定用测试的控制器升级到8.7.0.0后进行问题复现并尝试升级解决，然而令人意想不到的情况发生了，在测试环境中两台控制器在我配置了无线配置后尝试问题复现时，同样是AP-303下两个终端居然可以互相访问共享和VNC业务了，在确认了配置一致后，问题又陷入了死角。

在根据TAC要求下将全部命令下载下来给TAC用于LAB 复现，最终发现当前调用的ap-system-prof下的session acl的值为空，跟TAC沟通后我尝试在生产环境中的AC上cd 到mynode下进行修改操作发现无法修改，跟TAC沟通后了解到修改该命令需要cd 到MM下进行修改，最终修改完成后发现问题仍旧存在，在对比了测试环境中的AC上的ap-uplink-acl发现缺少了一条允许所有acl，随即在生产AC上ap-uplink-acl中添加了一条允许所有的acl并放在第一条，随后测试问题解决。

编辑注：

跟Steven Liu沟通，是6.5升级8.7后出现的问题。实际上根据最佳实践，6升8最好是重新做配置。同样8.3升级8.5或者8.6等之类跨版本，极个别特殊配置都会有所变化，不能直接复制粘贴原有配置。例如：

基于MM+MD的部署场景下（Standalone模式例外）：
针对V8.3版本的默认系统，当md在mm上停靠组节点成功后，在设备节点下，自动会携带一条命令： uplink wired vlan xxx uplink-id link1（非手动配置的） ，用于uplink的健康检测设置，但是该设置需要结合uplink manager 的同时开启才能生效，而V8.3系统默认没开启uplink manager，但默认开启uplink health-check。
当系统升级到V8.5/8.6/8.7及以上版本时，这条cli会自动删除掉，我们也不需要在新系统上重新刷这条cli，如果一旦你重新输入了该cli，意味着你在新版本下手动开启了uplink manager（因为V8.5/8.6/8.7及以上版本使用该cli来开启uplink manager，同时新系统默认也是自动开启uplink health-check） ，那就意味着uplink health-check也会跟着生效，而系统默认的uplink health-check的IP地址指向的是mm，一旦mm失去通讯了，md就会认为该uplink检测失效，系统自动将该uplink对应的默认路由记录删除，导致ap和md失去通讯，从而导致整个无线网络down。所以在系统升级到V8.5/8.6/8.7及以上时，或者在V8.5/8.6/8.7的默认配置下，如果没有uplink的检测需求的话，请大家不要在设备节点下重新配置 uplink wired vlan xxx uplink-id link1