1. 课程导入与实验环境搭建

在开始写第一行自动化代码之前，有一个问题必须先想清楚：我要用 Netmiko，还是用 NAPALM？很多初学者把两者当成"同类工具的两种选择"，结果在项目里混用，导致代码结构混乱。实际上，它们解决的是两个不同层次的问题。

一、Netmiko 与 NAPALM 的定位差异

Netmiko 本质上是 Paramiko（SSH 库）的"网络设备增强版"。它封装了各家设备 CLI 的交互细节——登录提示符、分页符（--More--）、enable 模式、配置模式提示符、保存确认等，让你可以用 Python 直接"敲命令、读回显"。它操作的是命令行文本，返回的也是文本。

NAPALM 则站在更高的抽象层。它定义了一套统一的 API，比如 get_facts()、get_interfaces()、load_merge_candidate()、compare_config()、commit_config()，底层可以调用 NX-API、NETCONF、RESTCONF，也可以退化成通过 Netmiko 走 SSH。它操作的是结构化数据，返回的是 Python 字典或列表。

一句话概括：Netmiko 管"怎么连上去、怎么把命令发出去"，NAPALM 管"配置和状态用什么统一模型表达"。两者不是竞争关系，NAPALM 的 ios、eos 等驱动在需要时正是借助 Netmiko 完成 SSH 通信的。

选择原则可以这样把握：如果任务是"把这条命令在 50 台设备上跑一遍并保存回显"，Netmiko 更直接；如果任务是"采集全网接口状态并统一成 JSON 入库"或"先比对配置差异再决定是否提交"，NAPALM 的模型化能力会省掉大量解析工作。实际工程中常见组合是：NAPALM 负责结构化采集与配置比对，Netmiko 负责 NAPALM 覆盖不到的厂商私有命令。

二、实验环境：用 EVE-NG 还是 DevNet 沙箱

学习阶段最现实的问题是：没有真机怎么办？两条路可选。

EVE-NG（本地模拟）适合需要反复折腾、自由组网、甚至故意制造故障的场景。它本质是一台跑 KVM 的 Linux 虚拟机，导入厂商镜像后可以像搭积木一样拖出路由器、交换机、防火墙。典型部署要求：宿主机至少 16 GB 内存、开启 VT-x/AMD-V 虚拟化、分配 4 核以上 CPU，EVE-NG 社区版镜像约 2 GB，导入 IOSv、vEOS、NX-OSv 等镜像后每台设备约占 512 MB～2 GB 内存。它的优势是完全离线、拓扑随意、可快照回滚；代价是镜像获取和资源占用需要自己解决。

Cisco DevNet 沙箱（云端）适合快速验证、不想折腾虚拟化的场景。登录 developer.cisco.com 后可以预约 Always-On 或 Reservation 类型的沙箱，常见的有 IOS-XE、NX-OS、IOS-XR 等。沙箱会给出跳板机地址、用户名、密码和端口，通常通过 VPN 或直接 SSH 接入。它的优势是开箱即用、多厂商镜像齐全；限制是有预约时长、拓扑不可改、网络可能不稳定。

三、搭建一个多厂商实验拓扑

下面给出一个适合本课程的最小拓扑，覆盖三种主流平台，便于后续对比 Netmiko 与 NAPALM 的行为差异：

• R1：Cisco IOSv，管理地址 192.168.100.11，SSH 端口 22
• R2：Cisco IOS-XE（CSR1000v），管理地址 192.168.100.12，SSH 端口 22
• SW1：Arista vEOS，管理地址 192.168.100.21，eAPI 端口 443，SSH 端口 22
• SW2：Cisco NX-OSv，管理地址 192.168.100.31，NX-API 端口 443，SSH 端口 22

在 EVE-NG 中，把四台设备的 Management 接口接到同一个 pnet0（桥接到宿主机网卡），并给每台设备配置管理 IP 与默认网关。以 IOSv 为例，基础配置如下：

enable
configure terminal
hostname R1
interface GigabitEthernet0/0
 ip address 192.168.100.11 255.255.255.0
 no shutdown
exit
ip default-gateway 192.168.100.1
username admin privilege 15 secret Cisco123
line vty 0 4
 transport input ssh
 login local
exit
crypto key generate rsa modulus 1024
ip domain-name lab.local
end
write memory

vEOS 与 NX-OSv 的配置思路相同，只是命令语法不同。vEOS 需要额外开启 eAPI：

management api http-commands
   protocol https
   no shutdown
   vrf MGMT
      no shutdown

NX-OSv 则开启 NX-API：

feature nxapi
nxapi http port 80
nxapi https port 443

四、验证环境是否可用

配置完成后，先在宿主机上做连通性检查：

ping 192.168.100.11
ping 192.168.100.21
ssh admin@192.168.100.11
curl -k https://192.168.100.21/command-api

如果 ping 通、SSH 能登录、eAPI 返回 JSON 或 401（说明服务在监听），说明环境基本就绪。接下来安装 Python 依赖：

pip install netmiko napalm
python -c "import netmiko, napalm; print(netmiko.__version__, napalm.__version__)"

最后用一段最小脚本验证 Netmiko 能连上 R1：

from netmiko import ConnectHandler

dev = {
    "device_type": "cisco_ios",
    "host": "192.168.100.11",
    "username": "admin",
    "password": "Cisco123",
}
with ConnectHandler(**dev) as conn:
    print(conn.send_command("show ip interface brief"))

如果能看到接口列表回显，说明 Netmiko 链路打通。再用 NAPALM 验证结构化采集：

import napalm

driver = napalm.get_network_driver("ios")
dev = driver(
    hostname="192.168.100.11",
    username="admin",
    password="Cisco123",
)
dev.open()
print(dev.get_facts())
dev.close()

返回的字典里应包含 hostname、vendor、model、os_version、serial_number、uptime 等字段。到这里，你已经拥有了一个可用的多厂商实验环境，后续章节的所有示例都可以在这套拓扑上复现。