先说个实际场景上个月同事给我发来一张截图十几台华为AR路由器的接口IP配置他在ENSP里一条一条敲光undo shutdown就敲了十几遍问我有没有更快的办法。我说当然有Ansible一发Playbook的事。结果我自己上手一跑也花了整整一个晚上才跑通——不是Ansible的问题是ENSP的Cloud连接和模拟器的SSH服务在中间作妖。这篇文章就围绕“用Ansible 2.9自动化配置华为ENSP路由器”这件事展开核心是把Cloud连接里最容易踩的坑一个个拆开讲清楚然后带你从一个空拓扑走到用Playbook批量下发配置。我默认你已经有最基础的ENSP操作经验知道怎么拖设备、连线、启动但不需要你懂Ansible。这篇文章适合三类人备考华为认证但没有真机、想在模拟器里练自动化的学习党日常在ENSP里做综合实验的网工以及刚接触网络自动化的运维新人。我已经把能踩的坑都踩完了顺着下面的步骤走就行。1. 为什么要干这件事在模拟器里练自动化的真实价值1.1 真机不敢碰、模拟器嫌鸡肋问题出在练法上很多网工学自动化第一步就卡在“没有真机”。华为AR路由器的价格对一个自学者来说不算便宜实验室里也不可能堆几台真机让你随便折腾。有些同学退而求其次在ENSP里手动配置练手今天配个静态路由明天起个OSPF配完拍个照就结束了。但手动练习跟自动化完全是两码事手动配置是把命令“敲”进设备自动化是把命令“写”成数据再通过协议“推”进设备两者的工作模式和排错思路完全不同。ENSP最大的好处是设备形态跟真机VRP基本一致支持SSH、支持标准CLI、支持完整的接口逻辑这正好给了自动化一个很完整的练习场。做错配置大不了重启设备回到初始状态这种试错成本是真机给不了的。用模拟器跑自动化核心价值并不是“模拟”而是让你在零成本环境里把工作流跑熟包括批量下发的顺序、校验与回滚的思路。等你哪天真机在手这套流程完全可以直接迁移过去。1.2 Ansible为什么是网络自动化入门的首选工具网络设备自动化方案其实不少PythonNetmiko、Nornir、Expect脚本都可以做但我个人还是推荐新手先走Ansible原因有三点无需在设备上安装代理。网络设备没有通用的“Ansible agent”概念Ansible通过SSH、NETCONF这些设备原生协议去操作天然适合网络设备。Playbook是声明式的。你写的是“设备最终要达到什么状态”而不是每一步怎么敲。可读性强review起来比一堆脚本直观得多。生态成熟。华为设备有对应的官方模块社区也有大量现成Playbook不用从零发明轮子。Ansible 2.9这个版本特别值得提一下它至今仍是很多生产环境在用的稳定版本华为官方很多自动化资料和实验也基于它编写。网上搜“华为ENSP Ansible”的教程大部分还都是2.9环境所以从2.9入门有大量参考案例踩坑时也更容易查到解决办法。1.3 适合谁、不适合谁我说句实在话这套方案不是所有人都需要。如果你已经熟练使用Netmiko、Nornir完全可以继续用你趁手的工具本文的Cloud连接避坑内容对你参考意义有限。但如果你是下面这几种情况这篇文章对你就是“保姆级”正在准备华为HCIA/HCIP实验想顺便了解自动化以后面试多个技能点日常工作里有成批的AR/CE设备需要配置初始化想在模拟器里先演练刚入职的运维新人还没有生产设备操作权限想自己偷偷把自动化基本功练扎实。下面的内容默认你会打开ENSP、拖设备、连线和启动如果这些还生疏先找ENSP基础操作教程过一遍再回来。2. 搭环境从零装好ENSP并把第一台AR启动起来2.1 安装前必须处理的三件事ENSP对系统环境的挑剔是出了名的很多人连安装都没过去。根据网上大量“ENSP启动失败40”案例和我的实际排查经验安装前先把这三件事处理干净能避掉一半以上的坑电脑用户名和安装路径绝对不能有中文。很多人用“张三”这样的Windows用户名VirtualBox在生成虚拟机文件时会遇到编码问题导致设备起不来。卸载掉电脑上原有的VirtualBox。ENSP自带VirtualBox组件如果你机器上装过旧版本或残留版本启动AR时报40/400错误的概率极高。卸载干净后最好再检查C:\Program Files\Oracle目录是否还有残留有的话手动删掉。虚拟化开关必须打开。开机进BIOS/UEFI确认Intel VT-x或AMD-V处于开启状态。可以在任务管理器 → 性能 → CPU里看“虚拟化: 已启用”来判断。ENSP版本建议直接用官方最新的V100R003系列安装时右键安装包选择“以管理员身份运行”属性 → 兼容性里勾上“以兼容模式运行这个程序”选Windows 7。这一步很多教程不提但确实能避掉不少启动问题。安装路径不要改到默认C盘以外的地方省得后面VirtualBox找不到虚拟磁盘。2.2 拖一个最小拓扑AR Cloud装好之后打开ENSP左侧面板拖一台AR2220路由器到画布再拖一台Cloud设备云朵图标进来。用连接线把AR2220的GE 0/0/0和Cloud连起来这是自动化实验最基础、也是后面所有操作的核心拓扑。选AR2220的原因它是ENSP里资源占用和路由功能比较均衡的型号很多综合实验都以它为主。AR3260也能用但启动时间和内存占用更大做自动化实验没必要。连接完先别急着开其他设备双击AR2220把它启动起来这一步最容易出问题。2.3 “启动失败40”和启动后电脑重启的排查表“ENSP路由器无法启动40”几乎是全网最热的ENSP话题这东西绕不开。错误代码40的本质是VirtualBox无法正常创建或启动虚拟机。你可以直接用下面这张表对照排查比搜半天碎片答案高效报错/现象最常见原因快速处理方法错误代码40VT-x未开启 / VirtualBox残留 / 中文用户名BIOS开虚拟化彻底卸载重装VirtualBox换英文用户目录错误代码400端口被占用 / 虚拟机启动超时关闭一切占用VirtualBox的进程重启ENSP错误代码403内存不足关掉浏览器等大内存应用不要同时开太多AR设备启动后Windows直接重启VirtualBox与系统版本冲突用兼容模式安装回退VirtualBox版本更新ENSP启动时CPU占用100%首次启动在初始化等1到2分钟不要反复点启动按钮注意AR设备第一次启动本来就慢黑色CLI窗口可能要等30秒到2分钟。超过3分钟还是黑的再按上表排查不要一慢就重试反而可能把VirtualBox进程搞乱。AR的黑色CLI窗口弹出来后先敲几下回车看到AR提示符就算正式进了系统。到这一步环境层面的坑基本就绕过去了接下来进入最关键的Cloud连接环节。3. Cloud连接避坑指南连不通才是常态3.1 Cloud设备到底是个什么东西很多新手搞不懂Cloud这个云朵图标其实它的作用就是一截“虚拟网线转接头”。AR设备跑在VirtualBox虚拟机里它不知道外面的Windows网卡长什么样。Cloud设备的本质就是把AR的一个虚拟端口和Windows的某个真实网卡绑定起来数据包通过这个映射关系进出模拟器。配置Cloud时你会看到三块区域端口创建、绑定信息、端口映射表。“绑定信息”选择要绑定的网卡或协议方式“端口映射表”决定数据从哪个端口映射到哪个网卡方向分“入方向”和“出方向”同时要勾选UDP、TCP还是两者都要。很多人失败就失败在这三个概念的排列组合上尤其是协议勾选和映射增加这两步漏一个都白搭。3.2 手把手配置用回环网卡和AR互通我个人最推荐的方式是用Windows的“Microsoft KM-TEST Loopback Adapter”回环网卡来做Cloud的绑定目标而不是直接绑WiFi或以太网物理网卡。原因有两点回环网卡的IP完全由你控制不受路由器DHCP影响它不受物理网卡休眠、电源管理的影响更适合跑长时间实验而且这个方案天然避开了“物理网卡被其他服务占用”的坑。创建回环网卡的步骤打开设备管理器在顶部计算机名上点右键 → 添加过时硬件。手动选择 → 网络适配器 → 厂商选Microsoft → 型号选“Microsoft KM-TEST Loopback Adapter”。安装完成后给这个回环网卡设置静态IP比如192.168.28.1 / 255.255.255.0。然后配置ENSP里的Cloud设备双击Cloud设备打开配置面板。在“绑定信息”区域如果下拉框里看不到刚建的回环网卡就选择“绑定到本机”方式找到带Loopback字样的网卡可能显示为“本地连接* 12”之类点“添加”按钮。在“端口映射表”区域入方向勾选UDP出方向勾选UDP。保守起见可以把TCP一起勾上但模拟器环境UDP更稳定先勾UDP就够。点“增加”看到下方出现一条映射记录后再点确定关闭窗口。3.3 三个最容易翻车的细节回环网卡选对了、映射也增加了但ping不通AR的情况仍然非常常见。根据我的经验排查优先级如下不要跳过顺序第一个坑是Windows防火墙。Windows Defender默认会拦截来自ENSP模拟网卡的入站流量AR去ping真机用的是ICMP去连SSH用的是TCP 22。最省事的办法是先临时关闭Windows Defender防火墙测试通了之后再单独为ICMP和22端口添加入站放行规则。第二个坑是AR接口没有开启。华为VRP接口默认是shutdown状态很多教程配了IP但忘敲undo shutdown从真机自然ping不通模拟器。用display interface GigabitEthernet 0/0/0确认接口物理和协议状态都是UP再往上层排查。第三个坑是IP规划不在同一网段。回环网卡是192.168.28.1/24AR接口就必须配192.168.28.2/24两者要在同一个广播域内中间不经过任何路由。这个属于低级错误但在Cloud排错现场真的频繁发生。3.4 先手工打通SSHAnsible能连通的前提走到这里从Windows应该能ping 192.168.28.2通过了。但Ansible连接华为设备需要SSH而全新的AR默认没有开启SSH服务也没有创建SSH用户。这一步必须先手工用Console做完没有任何捷径。在AR的Console窗口里逐条敲下面的命令注释行不用敲system-view sysname AR1 # 关闭设备提示信息避免刷屏 undo terminal monitor # 进入GE0/0/0接口配好管理IP interface GigabitEthernet 0/0/0 ip address 192.168.28.2 255.255.255.0 undo shutdown quit # 创建SSH本地用户并赋予最高权限 aaa local-user admin password irreversible-cipher Admin123 local-user admin privilege level 15 local-user admin service-type ssh quit # 配置SSH用户和开启stelnet ssh user admin ssh user admin authentication-type password ssh user admin service-type stelnet stelnet server enable quit save save的提示直接输入y回车敲完后从Windows命令行验证ssh admin192.168.28.2第一次连接会提示确认指纹输入yes再输入密码Admin123如果看到类似AR1的提示符说明SSH通道已经打通。到这一步Cloud连接的价值才算真正落地Ansible才有管理这台设备的基础通道。4. Ansible 2.9控制端准备参数一个都不能少4.1 控制端装在哪里Ansible控制端我建议放在Linux环境里跑Windows原生跑Ansible在2.9时代体验很差还容易遇到编码和权限问题。两个选择如果你电脑有VMware或VirtualBox装一个Ubuntu 20.04虚拟机或者用Windows自带的WSL2装Ubuntu也完全够用。我自己是在Ubuntu虚拟机里跑的网络桥接到同一个物理网络到回环网卡、到AR的网络路径短少一层代理就少一个变量。安装Ansible 2.9直接用包管理就好。Ubuntu下执行sudo apt update sudo apt install software-properties-common sudo add-apt-repository --yes --update ppa:ansible/ansible sudo apt install ansible2.9.27-1ppa~focal装完验证版本ansible --version看到ansible 2.9.27就算环境OK。如果系统源里默认给你的Ansible版本比2.9高也不用慌核心用法差别不大只是2.9社区资料最丰富、最容易找到参考。4.2 inventory主机清单必须写对的六个参数Ansible连接华为设备inventory里最重要的不是IP而是告诉Ansible“你连的是一种网络设备”不是一台普通Linux服务器。直接看我用的这段配置[huawei_ar] ar1 ansible_host192.168.28.2 [huawei_ar:vars] ansible_connectionnetwork_cli ansible_network_oshuawei ansible_useradmin ansible_passwordAdmin123 ansible_becomeyes ansible_become_methodenable逐个解释一下这些参数一个都不能少ansible_connectionnetwork_cli核心中的核心。它告诉Ansible使用网络设备CLI连接方式而不是SSH到机器上跑Shell命令。不写这个Ansible会误以为你在管一台普通主机。ansible_network_oshuawei指定设备平台2.9里华为VRP对应这个名称。ansible_user和ansible_password就是我们在Console里创建的SSH用户名密码。ansible_becomeyesansible_become_methodenable华为VRP进入特权模式的机制和思科enable类似。虽然我们创建的admin用户权限级别是15不写也能操作但写上有助于适配不同环境的设备。4.3 huawei模块选型2.9内置模块就够用Ansible 2.9自带了以huawei为前缀的一组模块常用的有huawei_config批量执行配置命令最常用相当于把命令文本推给设备执行。huawei_command执行查询命令并获取结果适合做验证和巡检。huawei_interface、huawei_vlan、huawei_ospf、huawei_static_route等针对单一功能的专用模块。我的建议是刚入门先死磕huawei_config和huawei_command这两个模块。因为专用模块在2.9版本里对VRP V5/V8命令细节支持存在差异容易卡住。而huawei_config的本质就是“把一段命令文本推给设备”正好和我们在CLI里敲命令的方式完全对齐排错时思路最简单。4.4 第一次连通先跑一条查询命令写完inventory后用下面这条命令测试能否通过Ansible连上AR设备ansible huawei_ar -m huawei_command -a commandsdisplay version如果能看到设备型号、VRP版本、内存信息说明Ansible已经能正常操作设备。我第一次跑就触发了Timeout第一反应是SSH没通但明明手动SSH能连上。排查半天发现是ansible_password里带了特殊字符导致解析问题换成纯字母数字密码后正常了。Admin123这组密码在inventory里要加引号避免特殊字符被shell吃掉。有一点提前说明network_cli是持久连接第一次命令会创建一个后台连接进程所以第一条命令往往比手动SSH慢一些1到3秒都正常别急着判断超时。5. 实战用Playbook批量下发AR路由器配置5.1 实验拓扑与规划接下来做一个小而完整的实验帮你理解自动化配置的完整链路。拓扑如下AR1和AR2通过各自的GE 0/0/0接口直连业务网段10.0.12.0/24AR1的GE 0/0/1接Cloud管理网段192.168.28.0/24管理IP 192.168.28.2AR2暂时先不开SSH等第一轮配置跑通后再启动。这个规划的意义在于AR1是通过SSH能管到的“跳板”AR2是这次自动化要“养”起来的第二台设备。有读者会问AR2不开SSH怎么让Ansible配它答案很简单在ENSP里通过Console把AR2开机临时也开一个SSH方法跟3.4完全一样IP设为192.168.28.3。这样Ansible才有管理入口。等AR2跑完第一轮Playbook后续所有操作就都可以靠网络通道完成了。5.2 inventory和host_vars文件现在inventory里加一台AR2[huawei_ar] ar1 ansible_host192.168.28.2 ar2 ansible_host192.168.28.3 [huawei_ar:vars] ansible_connectionnetwork_cli ansible_network_oshuawei ansible_useradmin ansible_passwordAdmin123 ansible_becomeyes ansible_become_methodenable为每台设备建立host_vars变量文件把差异化数据放进去。host_vars/ar1.ymlhostname: AR1 loopback_ip: 1.1.1.1 255.255.255.255 interconnect_ip: 10.0.12.1 255.255.255.0 ospf_router_id: 1.1.1.1 ospf_network: 10.0.12.0host_vars/ar2.ymlhostname: AR2 loopback_ip: 2.2.2.2 255.255.255.255 interconnect_ip: 10.0.12.2 255.255.255.0 ospf_router_id: 2.2.2.2 ospf_network: 10.0.12.0变量的作用在于让Playbook变成一个模板同一份逻辑不同设备代入不同数据。以后扩展到AR3、AR4只需新增host_vars文件和inventory行Playbook一行都不用改。5.3 第一个Playbook初始化加OSPF创建init_ar.yml文件--- - name: 批量初始化华为AR路由器 hosts: huawei_ar gather_facts: false serial: 1 tasks: - name: 配置系统名称 huawei_config: commands: - sysname {{ hostname }} - name: 配置LoopBack接口 huawei_config: commands: - interface LoopBack0 - ip address {{ loopback_ip }} - name: 配置GE0/0/0互联接口 huawei_config: commands: - interface GigabitEthernet0/0/0 - ip address {{ interconnect_ip }} - undo shutdown - name: 配置OSPF huawei_config: commands: - ospf 1 router-id {{ ospf_router_id }} - area 0.0.0.0 - network {{ ospf_network }} 0.0.0.255 - name: 保存配置 huawei_config: commands: - save - y逐块拆解一下关键设计gather_facts: false网络设备不需要收集系统fact禁用这个步骤能明显加快执行。serial: 1同一时间只在一台设备上执行避免多台AR同时连底层VirtualBox时资源竞争导致命令超时。设备多了想提速再考虑并行。huawei_config的commands参数按顺序把命令推给设备相当于无人工参与的“粘贴配置”。save命令华为设备在CLI下执行save会有交互提示模块无法处理交互所以后面补一行y应答。运行ansible-playbook -i hosts init_ar.yml正常情况会看到每台设备各有一串ok或者changed最后执行save成功。如果哪一步报错先回到设备CLI里手动执行那一条命令看看设备给出的具体报错信息再调整。5.4 验证结果让设备“自证清白”配置下发成功不代表配置生效你得让设备自己把状态说出来。执行ansible huawei_ar -m huawei_command -a commandsdisplay current-configuration | include sysname\|ospf\|ip address更直观的办法是直接在ENSP里打开AR2的CLI窗口输入display current-configuration看OSPF进程、LoopBack0、GE0/0/0的地址是不是符合预期。如果两台AR直连没问题在AR2上还能看到display ospf peer brief显示邻居状态为Full说明OSPF已经彻底建邻。这组验证做完整套链路才算真正闭环。5.5 幂等性同样的Playbook再跑一次会怎样Ansible最核心的设计理念是“期望状态”不管设备当前是不是目标状态跑同一个Playbook最终结果都应该收敛到目标状态而且第二次跑不会产生额外改动。在huawei_config里如果设备已经存在sysname AR1模块会判断这条命令没有变化不会重新下发输出显示ok而不是changed。但这个机制有前提命令写法必须与设备当前存储的完全一致。比如IP地址的掩码格式你写10.0.12.1 255.255.255.0设备里也恰好是这个格式才算一致如果你写成前缀长度10.0.12.1/24模块可能会判定为不同命令从而重复下发。所以写Playbook时命令格式尽量和设备display current-configuration输出里的默认格式保持一致幂等性才有保障。6. 实测中踩过的坑和排查思路直接抄作业6.1 SSH能连但Ansible一直timeout这是我在模拟器环境遇到频率最高的问题。手动ssh admin192.168.28.2能进但跑ansible-playbook一直卡在connecting然后超时。排查链路按顺序走确认ansible_password里没有特殊字符先用纯字母数字密码跑通再换复杂密码。检查inventory里的ansible_connection是否真是network_cli。如果写成了sshAnsible会按普通Linux主机的逻辑去尝试那肯定失败。看ENSP里是否同时开了多台AR抢占VirtualBox资源。模拟器两端都开着AR并发跑两个连接很容易互相挤掉所以Playbook里用serial: 1手动跑ansible命令时加-f 1限制并发数。6.2 命令下了一半卡死部分场景下Playbook运行到一半卡住不动通常是某条命令在设备上产生了二次交互提示。最典型的例子就是save之后设备问[Y/N]还有reset、uninstall之类的确认。解决办法是不要在commands里放需要交互的命令如果必须放就在后面追加应答字符比如save后面接y。如果还是卡可以调大ansible_command_timeout但VRP设备默认30秒对普通配置命令足够用卡住多半是交互问题不是时间不够。6.3 VRP V5与V8的模块兼容差异ENSP里的AR存在VRP V5和V8两种系统版本命令语法有细节差异。比如老版本V5的SSH配置里没有stelnet server enable这种显式命令V8则必须有undo shutdown两种都能用但display输出格式不同会影响你在模块高级参数里写正则匹配。我的建议很直接实验环境统一用VRP V8的设备。如果非要兼容V5和V8就别在huawei_config里用复杂匹配参数老老实实把命令一次推完用huawei_command单独做验证。6.4 模拟器自动化的边界排坑排到最后我还是想说点实在的ENSP Ansible最大的价值是让你在低成本环境里把“批量下发 → 验证 → 重复执行”这条链路练熟它的终局是替换你日常重复敲命令的坏习惯。但它也有明显边界比如ENSP底层VirtualBox在高并发时不稳定模拟器里协议状态机的时序和真机有差异。真要上生产设备你必须重新考虑备份、变更窗口、回滚方案。我自己的经验是先在模拟器里把Playbook打磨到连续跑三遍不出任何报错再考虑真机。到了真机那一步切换成本其实很低主要就是改inventory里的管理IP和账号。前面所有在模拟器里练出来的逻辑、排错方法、模块用法全部复用。另外还有个小建议用Ansible管理网络设备一定要养成“先备份再变更”的习惯。哪怕是在模拟器里也建议每次操作前用huawei_command导出一份display current-configuration保存到本地。这个习惯带到生产环境能救你很多次。