AD-Campus7.3平台openflow连接失败

AD-Campus 7.3设备纳管后显示未激活、提示OpenFlow连接失败，通常与控制器与设备间的OpenFlow通道建立异常有关。建议按以下步骤排查：
1. 检查基础连通性
确认设备管理IP与AD-Campus控制器（通常为SeerEngine或Director集群）之间路由可达。
在设备上执行 ping 控制器IP，确保无丢包。
检查中间防火墙是否放行OpenFlow端口（默认TCP 6633，若使用TLS则为6653）。
2. 核对OpenFlow配置
登录设备，执行 display openflow instance 查看实例状态。
确认控制器IP和端口配置正确：

openflow instance 1
controller 1 address ip port 6633 local address ip

若使用TLS，检查证书是否匹配且未过期。
3. 查看控制器侧状态
在AD-Campus平台“网络设备”页面确认设备序列号、管理IP与设备实际信息一致。
检查控制器日志（通常在/var/log/seerengine/或Director节点）中是否有该设备的OpenFlow握手失败记录，常见错误包括版本不匹配、证书错误或设备主动断开。
4. 验证设备侧日志
设备上执行 display logbuffer | include openflow 或 debug openflow event（注意debug需谨慎，建议先开terminal monitor）。
常见原因：设备时间与控制器偏差过大导致证书校验失败，建议配置NTP同步。
5. 其他检查
确认设备已开启OpenFlow功能且未被其他控制器占用。
若设备曾纳管成功，尝试在平台删除设备后重新添加，触发重新握手。
若以上步骤无法解决，建议收集设备display openflow instance、display current-configuration | include openflow及控制器相关日志，联系H3C技术支持进一步分析。

NETCONF 通道正常（平台能纳管、读取设备信息），但是 OpenFlow SDN 控制通道建链失败，Fabric 下发不了流表，所以状态停留在未激活。你截图里是两台 Spine，这个故障在 Spine 上非常典型。 核心区分：纳管走 NETCONF（830 端口）；SDN 控制面走 OpenFlow（默认 TCP 6633，SSL 加密场景为 6653），两条通道独立，通一条不代表另一条通。

一、第一步：设备侧命令行确认 OpenFlow 当前状态（必做）

登录 Spine 交换机，执行：

display openflow switch all display openflow switch 1 controller

• 看 Controller 状态：Connected= 正常；Trying/Down= 建链失败
• 重点核对：控制器 IP、端口、是否开启 SSL、绑定的 VRF 是否正确

AD-Campus7.3 自动化上线场景，OpenFlow 配置是平台自动下发；如果是手动添加设备，控制器 IP、SSL 策略容易配错。

额外检查：

display ip routing-table ping 控制器OpenFlowIP telnet 控制器OpenFlowIP 6633

telnet 不通 = 三层路由 / ACL / 防火墙拦截，优先解决连通性。

二、网络连通与放通排查（最高发）

1. 控制面 VRF 问题 AD-Campus 控制面一般单独 VRF（management-vrf），OpenFlow 的控制器配置必须指定vrf xxx；很多现场只在全局路由表 ping 通，但是控制 VRF 路由缺失，OpenFlow 用 VRF 去连，直接不通。

测试：ping vrf 管理VRF名 控制器IP

2. 中间设备 ACL / 防火墙拦截 TCP 6633/6653

• 明文 OpenFlow：TCP 6633
• SSL 加密 OpenFlow：TCP 6653（7.3 新版本默认 SSL 加密） 中间交换机、防火墙、控制器服务器本地 firewalld，都要放行设备→控制器方向的这两个端口，很多现场只放了 NETCONF 830，漏掉 OpenFlow 端口H3C。

3. 源 IP 匹配问题 OpenFlow 的local-address是设备发起连接的源 IP（管理 Loopback / 管理 VLANIP），平台上登记的设备管理 IP 必须和这个源 IP 一致；如果设备用 A 地址发起 OpenFlow，平台登记的是 B 地址，证书校验失败，直接断链。

三、SSL 证书校验问题（AD-Campus7.3 高频坑）

7.3 默认开启 SSL 加密 OpenFlow，证书校验失败会出现：NETCONF 正常纳管，OpenFlow 一直重试、无法建立，状态未激活：

1. 控制器与设备之间时间不同步（NTP 时间偏差过大，证书失效）
2. 控制器证书过期、证书链不完整
3. 设备上的 ssl-policy 引用错误、证书没有导入
4. 自动化 POAP 上线时，证书推送失败

临时验证：在平台把该设备 OpenFlow 改成明文模式（关闭 SSL），如果改完立刻激活，就是证书问题。

四、Fabric、角色、版本匹配问题（你是 Spine 重点看）

1. 设备是否加入正确 Fabric、角色是否是 Spine 平台 Fabric 视图里，这两台设备必须归属同一个 Fabric，角色 Spine；如果角色错配、不在 Fabric 内，控制器不会发起 OpenFlow 建链。

检查：自动化→园区网络→Fabric，确认两台 Spine 在 Fabric 成员列表，角色正确。

2. 交换机固件版本和 AD-Campus7.3 控制器版本配套

• 交换机 Comware V7 版本过低，对 7.3 的 OpenFlow1.3/SSL 支持有缺陷；
• 部分 S7000/S68 系列早期版本存在 OpenFlow 实例异常、无法和 7.3 控制器建链的 bug；

核对 Release Notes，确认交换机版本在 AD-Campus7.3 兼容清单内。

3. 设备是否重复纳管、SN 冲突 同一台交换机被多次添加，平台存在两条设备记录，SN 重复，控制器 OpenFlow 会话紊乱。 处理：删除平台上该设备所有记录，交换机上清除 openflow 配置，重新添加 / 重新 POAP 上线。

五、设备侧 OpenFlow 实例基础配置检查

openflow switch 1 controller 1 address ip 控制器IP port 6653 ssl AD-CAMPUS-SSL vrf 管理VRF enable

• openflow switch 必须 enable；
• 控制器 ID、IP、端口、ssl 策略、vrf，和平台下发参数严格一致；
• 不要手工在设备上修改 openflow 配置，自动化场景以平台为准，手动配置会和平台下发冲突。

六、控制器侧检查

1. 登录 SeerEngine-Campus 控制组件，确认 OpenFlow 服务正常监听 6633/6653

netstat -tlnp | grep 66

2. 控制器集群场景：主备控制组件 IP 都要配置在设备 controller 列表（主备两个 controller），只配单台控制器，主备切换后 OpenFlow 断开。
3. 查看控制器告警日志：搜索openflow，日志会明确提示：链路超时 / SSL 证书校验失败 / 设备 SN 不匹配。

七、标准修复操作顺序（现场推荐）

1. 确认 NTP 同步：控制器、两台 Spine 时间一致
2. 在交换机管理 VRF 内 telnet 控制器 6653 端口，确认端口通
3. 平台核对：设备 SN、管理 IP、归属 Fabric、角色 Spine
4. 查看控制器日志，区分是连通性问题还是证书校验失败
5. 连通正常、证书报错：重新同步证书或者临时关闭 SSL 测试
6. 版本不兼容：升级交换机 Comware 版本到 AD-Campus7.3 适配基线
7. 最后手段：平台删除设备，交换机undo openflow switch 1清空配置，重新 POAP 上线

八、容易踩坑的总结

✅ NETCONF（830）能通 ≠ OpenFlow（6633/6653）能通，两条独立通道 ✅ Spine 角色必须加入 Fabric，不在 Fabric 不会激活 ✅ 7.3 默认 SSL OpenFlow，证书 + 时间是最高发故障点 ✅ 控制面 VRF 容易忽略，ping 全局通、VRF 内不通 ✅ 版本不配套，会出现纳管成功、OpenFlow 一直 down