华三AD-WAN服务器如何纳管新上线网络设备

# H3C AD‑WAN 设备纳管、配置下发原理解答

>
> 环境：分支路由器仅配置两条命令

```
cloud‑management server domain 10.3.232.36
cloud‑management keepalive 60
```

控制器页面手工录入**设备序列号**完成上线，疑问：纳管、配置下发不是 SNMP/SSH/Telnet。

## 1、设备是如何被 AD‑WAN 服务器纳管上线？

**不使用 SNMP、SSH、Telnet**。

1. 分支设备（CPE）作为**客户端主动向外发起连接**（call‑home 主动呼叫模式），目的端口默认 **TCP 19443（WSS 加密 WebSocket）**，走 HTTPS/TLS 加密通道H3C。
2. 流程：
① 设备向控制器 IP 发起 HTTPS 握手；
② 使用**硬件序列号做身份认证**：控制器 Web 界面预先录入该设备序列号；设备上报自身序列号，控制器校验序列号是否存在；序列号校验通过才允许注册；
③ 认证通过后升级为 **WSS（WebSocket Secure）长连接**，建立永久双向管理隧道（cloud‑management 云连接）；
④ `cloud‑management keepalive 60` 就是这条长连接的保活时间，心跳维持这条 TCP 长连接。

>
> 查看设备侧连接状态命令：

```
display cloud‑management connection
```

字段`Cloud connection state`看到`Established`，代表长连接建立成功，设备完成纳管上线H3C。

>
> 关键点：

- 是**设备主动连控制器**，不是控制器主动去 ssh/telnet/snmp 访问设备；分支 NAT 环境也可以纳管；
- 认证凭据是**硬件序列号**，不需要提前配置设备的用户名密码；
- 通道底层：**WSS WebSocket over TLS，TCP 19443**，防火墙必须放行分支→控制器方向 TCP19443 出站。

## 2、上线之后，IBGP、Tunnel、SD‑WAN VRF、LAN IP 等业务配置如何下发？

>
> 同样**不走 SSH、Telnet，不使用 SNMP 做配置下发**。

1. 在上面建立好的 **WSS WebSocket 长隧道内部封装 NETCONF 报文（YANG 模型）**，控制器作为 NETCONF 客户端，分支路由器作为 NETCONF 服务端，RPC 方式下发全部业务配置。
2. 控制器 Web 页面填写的 Router‑ID、System‑IP、VRF、IBGP、Tunnel、LAN 接口等，全部转为 NETCONF‑RPC XML 报文，通过已经建好的 cloud‑management wss 隧道推送到分支设备，设备解析 NETCONF 直接生效配置。
3. 同时设备把状态、告警、隧道状态、链路质量数据，同样通过这条 WebSocket‑NETCONF 通道上报给控制器。

### 各协议分工区分（非常重要）

表格

| 协议 / 通道 | 作用 | AD‑WAN 南向是否用于配置下发纳管 |
| --- | --- | --- |
| **WebSocket(WSS) TCP/19443 + NETCONF** | 设备 call‑home 注册纳管、业务配置下发、状态上报、告警上报 | ✅**主管理通道（就是 cloud‑management 这条连接）**H3C |
| SSH / Telnet | 人工登录设备 CLI 调试 | ❌控制器**不使用它做自动化下发配置**；人维护才用 |
| SNMP | 只做**性能采集、trap 告警上送给第三方网管**，**不能做配置下发**H3C | ❌不用于纳管、业务配置下发 |
| SSL 控制通道（RR‑CPE 之间） | CPE 与 RR 之间交换 SD‑WAN TTE、IBGP 路由条目，属于**控制平面**，不是控制器下发业务配置通道 | ❌负责 Overlay 路由，不负责管理配置 |

## 3、现场排障常用命令（分支设备执行）

```
#查看cloud‑management云连接注册状态，看是否Established
display cloud‑management connection

#查看云连接调试状态，可以看到CAS认证、Register注册过程
display cloud‑management status

#查看NETCONF会话
display netconf session

#debug观察注册流程
debugging cloud‑management all
```

## 4、部署 & 防火墙要点

1. 分支设备 WAN 口需要**路由可达控制器 10.3.232.36，放行分支 → 控制器 TCP 19443 出站**；
2. 不需要控制器能够主动访问分支设备的任何 SSH、SNMP 端口；因为是设备主动 call‑home；
3. 上线关键条件：**控制器页面必须预先录入正确硬件序列号**，否则序列号校验失败，Register 注册失败，无法建立 WebSocket 长连接；
4. `cloud‑management keepalive 60` 修改心跳，只影响 WebSocket 长连接保活，不改变协议本身。

## 5、容易混淆两个通道

1. **管理通道（cloud‑management WebSocket+NETCONF，TCP19443）**：控制器 ↔ 每台 CPE；**下发 VRF、接口、BGP、模板配置，设备注册纳管，上报设备状态告警**。
2. **SD‑WAN 控制通道（SSL 隧道，CPE ↔ RR 路由反射器）**：CPE 之间交互 Overlay 路由、TTE 隧道端点信息，由管理通道把 RR 地址推送给 CPE 之后，CPE 才会建立这条 SSL 控制隧道。

>
> 总结回答用户两个核心疑问：
> 1）纳管：分支设备主动发起 WSS (TCP19443) 长连接，用硬件序列号鉴权注册；**不是 SSH/Telnet/SNMP**。
> 2）业务配置下发：在已经建立的 WebSocket 长连接内部跑 NETCONF RPC 报文下发 IBGP/Tunnel/VRF 等全套业务配置，**同样不使用 SSH、Telnet、SNMP 下发业务配置**。

这些是基本配置，SDWAN联系办事处啊

都是办事处开局

netconf ssh server enable

我觉得  新设备通过硬件序列号跟AD-WAN服务器注册成功。注册成功后，应该是通过上述命令，AD-WAN服务器下发配置。那么AD-WAN服务器上和新设备上的就应该同时有一个用户名和密码。 ssh local user 用户名密码 就不能更改了。否则AD-WAN服务器就无法下发配置了。

不知道我的理解是否正确。