【AD-campus】一台接入交换机无法上线，ssh测试正常

导致交换机无法上线的直接原因是：控制器（Manager）与交换机（Agent）之间的NETCONF会话无法建立或频繁中断。SSH只是传输层通道，而NETCONF才是控制器对设备进行管理和配置的通信协议。
详细分析
下面我将三张图片的信息串联起来，解释问题的来龙去脉：
现象确认（来自第1张图）：
在控制器界面上，系统名称为 XY-ZGHDZX-YQGL-JR-S5560X-2、管理IP为 10.156.197.206的接入交换机，其 “设备状态”为“未激活”。
这直接表明控制器无法通过管理协议（NETCONF）与交换机进行正常通信，从而无法获取其状态、下发配置，即“无法上线”。
关键错误信息（来自第2张图）：
图片中的系统告警清晰地指出：“控制器与NETCONF服务器（即交换机）10.156.197.206 的会话已中断”。
这条信息是决定性的证据，它将“设备未激活”的状态与“NETCONF会话断开”这个具体事件直接关联起来。这意味着控制器尝试建立NETCONF管理会话失败了。
根本原因探查（来自第3张图 - 交换机本地日志）：
这张图是交换机的本地日志，它揭示了NETCONF会话建立失败的具体原因。日志内容比较复杂，但可以提炼出几个关键点：
认证与连接波动：日志中既有SSH连接成功的记录（User ... passed password authentication），也有大量连接失败或断开的记录（disconnected, login failed）。
核心错误代码：出现了如 CFGFILE_NOT_MATCH​ （配置文件不匹配）和 EDDEV_DISCONNECT​ 等错误信息。
分析：虽然您的SSH手动测试是成功的，但控制器的NETCONF连接尝试可能更频繁，或者在特定交互环节（如NETCONF能力集协商、配置数据模型验证时）触发了问题。CFGFILE_NOT_MATCH是一个非常关键的线索，强烈暗示交换机上为控制器开放NETCONF功能所需的特定配置可能存在错误或缺失。
问题原因总结与排查步骤
综合来看，最可能的原因是：交换机上没有正确配置或启用NETCONF功能，或者与控制器的NETCONF连接参数不匹配。
请按照以下步骤进行排查和解决：
首要排查点：检查交换机的NETCONF配置
通过SSH登录到该交换机（10.156.197.206），检查以下配置：
确认NETCONF服务已开启：
# 查看NETCONF服务状态
display netconf agent status
确保状态为 Active。如果没有，需要进入系统视图下执行 netconf agent enable。
确认NETCONF over SSH的监听端口：
默认端口通常是830。检查是否被防火墙阻挡。
# 查看NETCONF监听端口
display netconf agent tcp
检查用于NETCONF连接的SSH用户及其服务类型：
控制器使用的SSH用户（例如 campus）必须具有NETCONF权限。
# 查看用户campus的配置
display this system-view | include local-user campus
确保该用户的配置中包含 service-type ssh netconf。例如：
local-user campus class manage
service-type ssh netconf
# ... 其他配置如密码等
核对控制器侧配置：
登录控制器，检查添加此设备时填入的IP地址、端口、SSH用户名和密码是否与交换机上的配置完全一致。
辅助排查点：网络与安全策略
防火墙策略：确保控制器（10.156.199.26）到交换机（10.156.197.206）的NETCONF端口（默认830）​ 是开放的，而不仅仅是SSH端口（22）。
交换机的ACL：检查交换机上是否配置了访问控制列表（ACL），限制了来自控制器IP（10.156.199.26）对NETCONF端口的访问。
总结
您的诊断思路是正确的，先测试SSH连通性。但现在可以确定，问题出在SSH之上的NETCONF应用层。请您重点排查交换机上NETCONF服务的配置是否正确，特别是与控制器连接相关的用户权限和服务类型。完成配置修正后，在控制器上尝试“刷新”或重新“增加”该设备，通常问题即可解决。

问题已解决

1. 该设备fabric角色默认是leaf，需要手动改为access

2. 防火墙策略阻挡了