2. Comware设备访问与交互基础

自动化运维的第一步不是写脚本，而是让脚本能够"够得着"设备、并且"听得懂"设备的回应。Comware 设备对外提供了多条访问通道，每条通道的适用场景、交互方式和返回格式都不一样。理解这些差异，才能为后续的自动化任务选对入口。

四条访问通道的定位

Console 是带外管理通道，通过物理串口直连设备，不依赖网络配置，是设备首次上电、密码丢失恢复、网络不可达时的唯一救命通道。它的特点是"必须人到现场"，因此不适合批量自动化，但它是所有自动化流程的兜底保障。

SSH 是带内命令行通道，登录后进入与 Console 完全一致的 CLI 视图体系。自动化工具（如 Netmiko、Paramiko）通过 SSH 建立会话，发送命令字符串、读取回显文本，再用正则或文本解析提取结果。它的优点是兼容所有 Comware 版本、命令覆盖最全；缺点是返回的是"给人看的文本"，格式随版本和命令略有差异，解析脆弱。

NETCONF 是结构化配置通道，基于 SSH 传输（默认 830 端口），使用 XML 编码。它把设备配置抽象成一棵 YANG 数据树，读用 <get>、<get-config>，写用 <edit-config>，返回的是可被程序直接解析的 XML，不依赖屏幕回显。适合配置下发、配置比对、状态采集等需要精确性的场景。

RESTful 是 HTTP 接口通道，Comware 通过 RESTful API 把常用操作映射为 URL 和 JSON。例如 GET 获取资源、POST 创建、PUT 修改、DELETE 删除。它天然适合与上层运维平台、CMDB、监控系统集成，但对设备版本和功能模块有要求，且并非所有 CLI 能力都有对应的 REST 接口。

Comware 命令行视图与配置模式

无论走 SSH 还是 Console，登录后都进入同一套视图体系。理解视图，是自动化脚本能正确下发命令的前提。

登录后首先处于用户视图，提示符形如 <H3C>。此视图只能执行查看类命令（如 display version）和少量系统命令，不能直接修改配置。输入 system-view 进入系统视图，提示符变为 [H3C]，此时可以配置全局参数，如设备名、管理地址、用户账号。

从系统视图可以进入各类功能视图：interface GigabitEthernet1/0/1 进入接口视图，提示符变为 [H3C-GigabitEthernet1/0/1]；ospf 1 进入 OSPF 视图；line vty 0 4 进入 VTY 用户线视图。功能视图中的命令只对该对象生效。用 quit 逐级返回，用 return 或 Ctrl+Z 直接回到用户视图。

配置模式还涉及"提交"语义。Comware 默认在系统视图下输入的命令立即生效于 running-config，但不会自动保存到 startup-config。自动化脚本下发配置后，必须显式执行 save force 才能持久化，否则设备重启后配置丢失。这一点与 NETCONF 的 candidate + commit 两阶段提交不同，需要特别注意。

首次自动化连接实验

下面以 SSH 通道为例，完成一次最小可用的自动化连接。实验对象为一台已开启 SSH 的 Comware 设备，管理地址 192.168.1.1，账号 netadmin，密码 Admin@123。这些参数属于教学示例，实际使用时替换为真实环境值。

第一步，在设备上确认 SSH 服务已开启，并创建具有相应权限的本地用户：

system-view
ssh server enable
local-user netadmin class manage
 password simple Admin@123
 service-type ssh
 authorization-attribute user-role network-admin
quit
line vty 0 4
 authentication-mode scheme
 protocol inbound ssh
quit

第二步，在自动化主机上使用 Python 的 Netmiko 库建立连接并执行命令。Netmiko 封装了 SSH 会话的建立、提示符识别和分页处理，适合快速验证：

from netmiko import ConnectHandler

device = {
    "device_type": "hp_comware",
    "host": "192.168.1.1",
    "username": "netadmin",
    "password": "Admin@123",
}

with ConnectHandler(**device) as conn:
    print(conn.find_prompt())          # 预期输出: <H3C>
    out = conn.send_command("display version")
    print(out)
    conn.send_config_set(["sysname SW-Auto"])
    conn.save_config()

第三步，观察结果并判断是否成功。若 find_prompt() 返回 <H3C>，说明 SSH 登录成功且已进入用户视图；display version 的输出中应包含 Comware 版本号和设备型号；执行 send_config_set 后设备名变为 SW-Auto，提示符相应变化；save_config() 返回保存成功提示。若连接超时，优先检查管理地址可达性、SSH 服务状态和 VTY 认证模式；若登录后立即断开，检查用户角色是否为 network-admin 或具备足够权限。

通道选择与视图配合的实践原则

实际项目中，四条通道往往组合使用：日常批量配置下发优先用 NETCONF，因为它返回结构化数据、便于校验；兼容性要求高或设备版本较老时退回 SSH + CLI 文本解析；平台集成和状态查询用 RESTful；Console 仅用于开局和应急。无论走哪条通道，最终都作用于同一套视图体系和配置数据库，因此对视图层级和提交语义的理解是共通的。

首次连接实验的价值不在于脚本本身多复杂，而在于打通"认证—建链—执行—保存—验证"这条最小闭环。闭环跑通后，后续的多设备并发、配置模板、差异比对才有可靠的落脚点。