EVE-NG部署与多厂商网络拓扑实验环境搭建指南

装了不下十次 EVE-NG我大概能算半个踩坑专业户。最早在一台退役的台式机上用裸金属方式装后来换到服务器、换到虚拟机、又换回裸金属中间经历过的现场包括但不限于装完重启进不了 Web 页面、镜像丢进去设备起不来、拓扑能连但 ping 不通、跑着跑着整台机器卡死。这套多厂商网络模拟环境的价值确实高——把路由、交换、防火墙、负载均衡的镜像塞进同一个拓扑里互联做跨体系的路由实验、做割接前的方案验证比单独开几个模拟器来回切窗口强太多。但它对宿主机的要求、对镜像的处理、对网络规划的要求也比单机模拟器高一截。这篇就把我从裸机装系统到第一张跨体系拓扑跑通的全过程拆开写包含每一步为什么这么做、哪些参数不能凑合、以及那几个我反复踩到的坑。适合手里有一台闲置机器、想认真搭一套长期实验环境的人看纯新手也能顺着走下来。1. 为什么我最终把实验环境落在了 EVE-NG 上1.1 从单机模拟器到多厂商同一张拓扑的跨越很多人做网络实验的起点是某个厂商自带的图形化模拟器拖两台路由器、连根线、配个静态路由学习基础命令足够了。但这套东西的天花板很明显它只认自己家的设备体系一旦你要做异构互联实验比如让一台跑 IOS 的路由器和一台跑 Junos 的设备做 OSPF 邻居或者验证一下不同体系对 BGP 属性的处理差异就完全没有办法。另一种常见选择是 GNS3它的定位其实和 EVE-NG 很接近早期我用得也不少但它在多设备并发规模、镜像管理规范性、Web 化操作这几个维度上长期使用下来体验还是差一档。EVE-NG 的核心思路是把所有设备都当成标准化的虚拟机和虚拟网卡来处理。你在浏览器里拖出来的每一台设备背后都是 QEMU 进程加若干张虚拟网卡设备之间的连线就是宿主机内核里的 vnet 接口对。这个抽象非常干净带来的直接好处是只要某个设备有可运行的虚拟化镜像理论上就能塞进这套环境里跟厂商是谁没有关系。所以你会看到同一张拓扑里能同时出现 IOS、IOS-XE、NX-OS、Junos、VRP、vEOS 这些完全不同体系的设备它们之间的连线方式、抓包方式、启动停止方式全都一致。维度厂商自带图形模拟器通用型单机模拟器EVE-NG设备体系覆盖仅单一体系较广依赖插件广镜像即插即用并发规模10 台以内20 台左右吃力视硬件30 台以上可行操作方式桌面客户端桌面客户端浏览器跨终端拓扑复用手工重建可导出完整导出导入含配置真实协议栈多为简化实现部分为真实镜像全部为真实镜像表格里最后一行是关键。厂商自带模拟器很多协议行为是简化过的你学到的现象和真机不完全一致做方案验证时容易被误导。EVE-NG 里跑的是真实的设备镜像启动过程、命令行、协议实现都是原生的这也是我愿意在这套东西上投入时间折腾的根本原因。1.2 硬件预算与能跑几台的真实换算部署之前必须先算一笔账因为 EVE-NG 是个纯资源吞金兽。它的资源消耗完全取决于你启动了什么设备不同镜像之间的差距能有十倍。我把自己实际用下来比较准的占用数据整理成表你可以按这张表倒推自己的机器够不够。镜像类型内存占用启动耗时备注传统 IOS 路由器镜像256 至 512 MB20 至 40 秒最轻适合大规模铺量IOL 二层三层混合镜像128 至 256 MB10 至 20 秒最省资源跑协议实验性价比最高IOS-XE 虚拟路由器3 至 4 GB3 至 6 分钟启动慢别频繁开关虚拟防火墙4 至 6 GB4 至 8 分钟内存给少了直接起不来虚拟数据中心交换机8 GB 起8 分钟以上单台就能吃掉半台机器的资源按这个表算一台 32 GB 内存的机器如果全部铺轻量镜像跑到 30 台以上没问题如果混着放几台 IOS-XE 和防火墙实际能同时开的大概就 12 到 15 台。这里有个很多人忽略的点EVE-NG 允许内存超分你开 40 GB 的虚拟机内存配额它也让你开但一旦物理内存被吃满内核的 OOM 机制会直接杀掉 QEMU 进程表现出来就是某台设备毫无征兆地消失了控制台黑屏日志里只有一条内核杀进程的记录。所以内存宁可留 25% 的余量别按物理内存顶格配。CPU 方面核心数比主频更重要。每台虚拟设备至少需要一到两个可调度的 vCPU设备一多核心数不够就会出现设备都在、但命令行敲一个字等半天的情况。我自己现在的机器是 16 核 32 线程配 64 GB 内存跑二十台混合拓扑时 CPU 占用在 40% 上下体验比较从容。1.3 部署前必须先定的三个取舍第一个取舍是裸金属还是虚拟机里套。我试过在虚拟化平台上再装 EVE-NG也就是常说的嵌套虚拟化能跑但代价是性能损耗明显尤其是设备启动阶段能慢一倍以上而且稳定性差偶尔会出现设备起不来的玄学问题。如果你只有一台主力机用虚拟化平台跑是没办法的办法只要有一台独立机器强烈建议裸金属装省下的调试时间远超你想象。第二个取舍是社区版还是专业版。社区版免费功能上做实验完全够用限制主要在并发运行的路由设备数量上以及一些高级功能比如多用户协作、拓扑热链接。个人学习和方案验证用社区版就行别一上来就掏钱。专业版的好处主要是多用户和更宽松的设备数量限制团队共用一台机器时才有意义。第三个取舍是镜像从哪来。这一点必须说清楚请使用你自己拥有合法授权的镜像文件。虚拟设备镜像本质上是厂商的软件产品很多需要有效的服务合同才能在官方渠道获取。自己想办法搞来的来源不明的镜像不仅可能带后门还可能在启动时因为文件损坏而反复失败排查起来极其浪费精力。我个人的做法是只保留手上真正有授权的那几套体系其余的用开源的路由软件套件替代做协议实验效果差不多。2. 宿主机准备那些装系统时容易埋雷的地方2.1 虚拟化开关、嵌套虚拟化与 IOMMU整个环境能跑起来的前提是 CPU 的硬件虚拟化功能必须是开的。这一步在 BIOS 里完成名字各家主板不一样通常叫虚拟化技术、SVM 模式或者 VT-x找一下就能看到。装完系统之后用一条命令验证最直接grep -E -c (vmx|svm) /proc/cpuinfo输出大于 0 就说明硬件虚拟化已经可用。如果输出是 0先去 BIOS 里把开关打开别急着往下走后面所有步骤都会失败。第二件事是网卡命名。新版系统默认启用可预测网卡命名你的第一块网卡可能叫ens33、eno1或者更奇怪的名字而 EVE-NG 的很多脚本和文档是按eth0、eth1这种传统命名来组织的。为了避免后面改配置文件时到处找网卡名我在装系统的时候就把它关掉。修改 GRUB 配置sed -i s/^GRUB_CMDLINE_LINUX.*/GRUB_CMDLINE_LINUXnet.ifnames0 biosdevname0/ /etc/default/grub update-grub重启之后网卡就固定叫eth0、eth1了。这个改动做在前面能省掉后面一堆麻烦我第二次部署时忘了做结果 Cloud 节点桥接死活绑不上排查了快两个小时。第三件事是 IOMMU。如果你不打算做网卡直通或者 PCI 设备直通这一项可以跳过。要做直通的话得在 GRUB 里加intel_iommuon或者amd_iommuon同时在 BIOS 里打开对应的虚拟化 IO 选项。对绝大多数做协议实验的人来说用不上别为了配置完整去折腾它直通配错了反而会让网卡在启动时被内核锁住。2.2 磁盘规划镜像目录千万别和系统盘挤在一起EVE-NG 的镜像目录在/opt/unetlab/addons/下面这个目录会随着你导入的镜像不断膨胀。一个 IOS-XE 镜像解开之后 2 到 3 GB一个数据中心交换机镜像 5 GB 以上再加上每台设备启动时生成的差异磁盘、快照、抓包文件几十 GB 是起步量。我的做法是单独挂一块盘到这个路径跟系统盘彻底分开。具体操作上先用lsblk确认新盘的设备名然后格式化和挂载mkfs.ext4 /dev/sdb mkdir -p /opt/unetlab/addons mount /dev/sdb /opt/unetlab/addons接着把挂载写进/etc/fstab用 UUID 而不是设备名避免以后加硬盘导致设备名漂移blkid /dev/sdb拿到的 UUID 填进 fstab加上defaults,noatime参数。noatime这一项值得加因为虚拟机的磁盘文件读写极其频繁禁用访问时间记录能减少一部分无谓的写入长时间跑实验对磁盘寿命友好一些。文件系统选 ext4 就行别用 btrfs 或者 zfs。EVE-NG 的差异磁盘机制本身已经做了类似快照的事情再叠一层文件系统级的快照容易出现两层快照互相打架的情况表现出来是设备回滚之后状态诡异。这个坑我踩过一次一台虚拟防火墙回滚后网卡配置和实际接口对不上删了重建才恢复。2.3 系统版本、内核与必要依赖系统版本这块我目前用的是 Ubuntu 22.04 LTS跑了半年多没出过兼容性问题。20.04 也能用但内核对新版 QEMU 的支持稍旧一些。不建议用最新的非 LTS 版本EVE-NG 的安装脚本对内核版本有一定假设太新的内核上偶尔会出现网桥模块加载顺序的问题。装完系统先更新一遍然后装基础依赖apt update apt upgrade -y apt install -y ssh curl wget git vim net-tools bridge-utils tcpdumpbridge-utils和tcpdump这两个是必须的前者用来管理网桥后者在排查拓扑连了但不通这类问题时是唯一有效的手段。别嫌它占地方真出问题时你会庆幸装了。还有一项容易被忽略的内核参数配置。Linux 网桥默认会把经过网桥的流量交给 iptables 处理这在普通服务器上是合理的安全策略但在 EVE-NG 这种环境里会造成严重的性能问题和莫名丢包。所以要把这几个开关关掉cat /etc/sysctl.conf EOF net.bridge.bridge-nf-call-iptables 0 net.bridge.bridge-nf-call-ip6tables 0 net.bridge.bridge-nf-call-arptables 0 net.ipv4.ip_forward 1 EOF sysctl -p前三行是让网桥流量绕开过滤规则最后一行是打开 IP 转发让你从宿主机能直接访问实验网段里的设备。这几行配置如果漏了症状是拓扑里的设备之间能通但从宿主机 ping 实验网段里的地址不通很多人会误以为是设备配置错了其实是宿主机这边把包拦了。3. 安装 EVE-NG 本体脚本执行完只是开始3.1 安装脚本到底改了哪些东西拿到安装脚本之后执行之前先看一眼它做了什么这个习惯能帮你后面排查问题时知道该去哪里找。脚本会检测当前系统版本问你装的是社区版还是专业版然后开始一系列动作。它主要做了这几件事把 EVE-NG 的全部程序文件解压到/opt/unetlab/其中html/是 Web 前端wrappers/是对外暴露的命令行工具addons/是镜像存放区templates/是每台设备的启动参数模板创建unetlab这个系统用户所有的 QEMU 进程都以这个身份运行配置 Apache 作为 Web 服务器把/opt/unetlab/html设为站点根目录默认监听 80 端口配置 MySQL 存拓扑和设备数据最后装一堆运行时依赖包括 QEMU、动态路由模拟器、各种图形库。安装过程会跑十几分钟中间会让你确认是否安装某些可选组件按默认走就行。装完之后要求重启这一步别跳过因为脚本改了内核参数和用户组不重启不生效。这里有个细节值得记住所有虚拟设备的进程都是unetlab用户跑的不是 root。这就解释了后面镜像权限问题的根源——如果你用 root 身份把镜像文件拷进去文件属主是 rootunetlab用户读不到设备起不来而且报错信息非常含糊只说启动失败不告诉你是权限问题。我在这个问题上浪费过整整一个下午。3.2 装完立刻要做的四项验证重启之后别急着拖拓扑按顺序做四项验证任何一项不过都别往下走。第一项是 Web 服务是否起来systemctl status apache2 curl -I http://127.0.0.1/返回 200 就正常。默认登录账号是admin密码是eve第一次登录进去之后立刻改掉这台机器如果在内网暴露着默认密码等于没设密码。第二项是数据库。EVE-NG 用 MySQL 存拓扑元数据连不上数据库的表现是 Web 页面能开但保存拓扑时报错。检查命令systemctl status mysql mysql -u root -p -e show databases;第三项是内核模块。KVM 模块必须加载成功否则所有设备会退化成纯软件模拟速度慢十倍以上lsmod | grep kvm应该同时看到kvm和kvm_intel或kvm_amd两个模块。只有kvm没有硬件加速的那个说明 BIOS 里的虚拟化开关没开或者被其他虚拟化软件占用了。第四项是网桥状态ip link show | grep -E pnet|vnet正常情况下应该能看到pnet0这个网桥它对应你的管理网卡。如果没有说明安装脚本里的网络配置那一步出了问题通常是它没识别到你的网卡名。这种情况手动补一个网桥就能解决但先确认一下/etc/network/interfaces里的配置有没有生成。3.3 安装中途失败的几种典型现场场景一脚本跑到一半卡在某个包的安装上。绝大多数原因是软件源不通或者源里的包版本冲突。换个源重试通常就能过注意别用那种镜像站已经下线的老源。场景二装完之后 Web 页面报 500 错误。这种八成是 PHP 模块没装全或者版本不匹配。翻一下 Apache 的错误日志/var/log/apache2/error.log里面会明确告诉你缺哪个模块。我遇到过一次是某个加密扩展版本对不上装上对应的包之后就正常了。场景三设备能创建但启动即失败。先看/opt/unetlab/data/Logs/下对应的日志文件那里有 QEMU 的完整启动命令和错误输出。九成的情况是镜像路径不对、文件缺一块、或者属主不是unetlab。日志里如果出现 Permission denied直接跳到第四章的权限处理部分。场景四装完之后宿主机完全没网了。这是因为安装脚本接管了网络配置把原来的网卡配置覆盖掉了。用ip addr看一下网卡有没有 IP没有的话手工在/etc/network/interfaces里补上静态地址或者用dhclient eth0临时拉一个地址先把 Web 界面访问通再慢慢修配置。4. 镜像导入多厂商环境真正的门槛4.1 三类镜像的运行机制与目录约定EVE-NG 支持三种不同的镜像运行机制它们的目录结构、文件命名规则、启动方式全都不一样。搞清楚这三类的区别是让多厂商环境真正跑起来的关键。机制适用镜像目录特点QEMU绝大多数虚拟化镜像/opt/unetlab/addons/qemu/通用性最强资源占用高IOL轻量级二层三层镜像/opt/unetlab/addons/iol/bin/极省资源启动秒级传统模拟早期路由器镜像/opt/unetlab/addons/dynamips/兼容老镜像性能一般QEMU 这一类是主力。它的目录规则是每个镜像一个独立子目录目录名就是你之后在设备列表里看到的名字比如vios-15.7、vsrx-20.4。目录内部的文件名有严格约定第一块硬盘必须叫virtioa.qcow2第二块叫virtiob.qcow2光驱镜像叫cdrom.iso。这套命名不能改改了系统就找不到盘设备启动时会卡在引导阶段反复提示找不到启动介质。IOL 这一类是性价比之王。它的镜像就是单个二进制文件直接丢进bin/目录加上可执行权限就行。这类镜像跑协议实验OSPF、BGP、ISIS 这些完全够用资源占用只有 QEMU 镜像的十分之一我一台机器上能同时开四十多台。缺点是它只模拟特定系列的设备功能覆盖不全做高级特性实验还是得靠 QEMU。传统模拟这一类的镜像是上一代技术现在新建实验基本不用了但如果你手上正好有老的镜像文件也可以塞进来用。目录规则比较简单文件放进去、改名成约定的格式就行。4.2 从原始文件到可启动镜像的完整处理流程以最常见的 QEMU 镜像为例完整流程是这样的。假设你拿到的是一个压缩包里面是原始磁盘文件。第一步创建目录。目录名建议带上版本号方便以后同型号多版本共存mkdir -p /opt/unetlab/addons/qemu/vios-15.7 cd /opt/unetlab/addons/qemu/vios-15.7第二步判断文件类型。这一步很多人直接跳过导致后面启动失败还不知道为什么。虚拟磁盘文件有可能是qcow2格式也有可能是vmdk或者vdi格式后者需要转换qemu-img info your-image-file看输出里 file format 那一行。如果是qcow2可以直接改名如果是别的格式先转换qemu-img convert -f vmdk -O qcow2 your-image-file virtioa.qcow2转换这一步的耗时取决于文件大小几个 GB 的文件大概几分钟。第三步改名为约定的文件名mv virtioa.qcow2 virtioa.qcow2如果是已经转换好的、名字不对的直接mv改名即可。第四步如果有光驱文件同样改名成cdrom.iso放进来。注意有些镜像启动需要光驱辅助缺了会卡在引导菜单。第五步处理权限。这是最容易漏的一步chown -R unetlab:unetlab /opt/unetlab/addons/qemu/vios-15.7 chmod -R 755 /opt/unetlab/addons/qemu/vios-15.7第六步跑一遍全量权限修复。EVE-NG 提供了一个专门的包装命令/opt/unetlab/wrappers/unl_wrapper -a fixpermissions这条命令会遍历所有镜像目录把属主和权限统一处理一遍。养成每次导入镜像后都跑一次的习惯能省掉大量设备起不来的排查时间。4.3 权限、属主与 fixpermissions 的正确用法关于权限这件事我想单独拉出来讲因为它是新手掉进去最多的坑而且报错信息完全误导人。现象是这样的镜像文件明明在目录里ls能看到文件大小也对但在 Web 界面里创建设备、点启动控制台一片黑或者过几秒钟设备状态变成红色。去看日志看到的是 QEMU 报错说无法打开磁盘文件。根本原因就一个文件属主是 root而 QEMU 进程以unetlab用户身份运行读不到文件。为什么属主会是 root因为你用cp、mv、scp或者解压命令往里拷文件时用的是 root 身份新文件的属主就跟着变成了 root。正确的处理顺序是先把文件拷进去然后统一改属主最后跑fixpermissions。别指望fixpermissions一次解决所有问题它处理的是标准路径下的标准文件如果你的目录名或者文件名不符合约定它可能扫不到。所以改属主这一步还是要自己做。另外有个特殊情况从其他地方直接复制过来的镜像目录里面可能带有扩展属性chown之后仍然读不了。这种情况用chmod -R 755把权限位也统一一遍通常就好了。如果还不行重新cp一份过去不要用mvmv会保留原文件的属性。还有一个细节值得提不要用chmod 777。有些人为了省事直接把权限拉满这样确实能跑但会把镜像文件变成所有人都能改跑实验过程中万一某个进程误写了镜像你的原始镜像就废了而且这种损坏是不可逆的。老老实实用755加属主unetlab就够了。5. 网络规划管理面、实验面与外部世界的接口5.1 为什么管理口和实验流量必须分开这套环境里其实存在三张网管理网也就是你访问 Web 界面的那张实验内的虚拟网设备之间互相连的那张以及连接物理世界的出口网。这三张网混在一起会出很多怪问题。管理网通常对应宿主机的一块物理网卡EVE-NG 装完之后会自动建一个pnet0网桥把它包起来。你从别的机器访问 Web 界面走的也是这张网。实验内的虚拟网是纯软件的由vnet接口对加网桥组成完全在宿主机内部跟物理网卡无关。为什么要强调分开因为如果你把实验网桥也桥接到管理网卡上实验里那些乱跑的广播包、协议报文会直接灌进你的实际网络。我做 OSPF 实验时踩过一次实验里的路由器和管理网段的网关做成了邻居结果宣告了一堆莫名其妙的路由出去本地网络的路由表一度混乱。从那以后我坚持一个原则实验用的网桥绝不接物理网卡除非是刻意要模拟实验环境连到外部的场景而且必须在一个隔离的交换机端口上做。如果你确实需要实验环境访问外部网络做软件升级之类的操作正确做法是单独拿一块网卡专门做这件事或者接到一个独立的隔离端口上通过 NAT 转发出去。别和管理口共用共用之后出问题你连 Web 界面都进不去只能到机器面前接显示器。5.2 Cloud 节点桥接物理网卡时的注意事项EVE-NG 有个叫 Cloud 的虚拟节点作用是把实验拓扑里的虚拟网络桥接到宿主机的物理网卡上。这个功能很有用但也最容易出问题。桥接之前先确认物理网卡是不是被pnet0占着。用brctl show pnet0看它下面挂了哪些接口如果挂的是你打算桥接的那块网卡那你再桥接一次会产生环路网络直接瘫痪。正确的做法是另找一块空闲网卡或者用虚拟接口加 NAT 的方式做。桥接配置写在/etc/network/interfaces里格式大概是给物理网卡建一个网桥、把网卡挂进去、网桥拉地址。改完用ifreload -a或者systemctl restart networking生效。这里有个风险如果你是远程连到这台机器上操作的网络配置改错就会把自己断开。所以改配置之前先挂个定时任务十分钟后自动重启网络服务这样万一断了也能自己恢复。桥接还有一项要注意物理网卡必须在混杂模式下工作否则虚拟设备发出的、目的地址不是宿主机的报文会被物理网卡丢掉。加到网桥上的网卡通常会自动进入混杂模式但偶尔会有例外检查一下ip link show eth1输出里应该能看到PROMISC标志。没有的话手动加ip link set eth1 promisc on5.3 从其他机器访问实验台面的几种做法最直接的方式是在局域网里用浏览器访问宿主机的 IP。这种方式简单但受限于必须在同一个网段里出门在外就用不了。第二种方式是在宿主机上开 SSH通过端口转发的思路把 Web 端口映射出来。这个方式我用了很久好处是不需要额外配置缺点是每次访问都要在本地建一条转发。具体的 SSH 命令格式是本地端口转发到远端 80 端口把-L参数用上就行。第三种方式是直接在宿主机的 Apache 配置里加访问控制允许特定网段访问。这个最省事但要确保宿主机本身没有直接暴露在不受控的网络里否则登录页面被暴力猜测密码只是时间问题。社区版的默认密码一定要改掉并且建议在 Apache 层再限制一下来源网段。我自己的做法是第二种加第三种组合平时在实验室内网直接访问外出时用 SSH 转发同时在防火墙上只放行自己常用的几个网段。6. 资源调度十几台设备同时在线的调优实录6.1 内存超分与 CPU 绑核的实际效果内存超分要不要开取决于你的实验规模。小规模实验十台以内轻量镜像完全不用管物理内存绰绰有余。规模上去之后超分能让你多开几台但风险是可能触发内核的杀进程机制。真正让我吃过亏的是一次跑十五台混合拓扑的实验两台虚拟防火墙各要 6 GB四台 IOS-XE 各要 4 GB剩下的轻量设备也要各占几百兆加起来对 32 GB 的机器来说刚刚好卡在临界点。跑到一半其中一台防火墙的进程被内核杀了控制台直接消失配置全丢。查日志看到Out of memory: Killed process这才知道是内存不够。解决方案有两个一是把部分不参与当前实验阶段的设备暂停用的时候再开二是给关键设备开启内存预留不让操作系统把它换出去。EVE-NG 里暂停设备很直接右键菜单里就有。我现在的习惯是拓扑搭好之后不一次性全启动按实验阶段分批开既省资源又减少心理负担。CPU 绑核这个功能在小规模场景下收益不明显但设备数量超过二十台之后效果很直观。它的作用是把某台虚拟设备的进程固定到几个物理核心上避免操作系统调度器把同一个进程在核心之间来回搬导致缓存命中率下降。具体做法是在设备配置里指定 CPU 亲和性把重型设备比如数据中心交换机绑到独占的几个核心上轻量设备让它们自由竞争剩下的核心。我实测下来二十台设备的拓扑在开绑核之后整体响应速度提升大概三成命令行敲进去的回显明显更跟手。6.2 镜像瘦身与快照链管理镜像文件占的空间会一直在涨尤其是那些你反复启动、配置过很多东西的设备。原因是启动时会基于原始镜像生成一层差异磁盘你做的所有配置改动都写在这一层里。一层不厚但架不住设备多、时间久。清理的思路是先看哪些镜像在涨。用du -sh扫一遍镜像目录找出体积异常的。通常涨得最厉害的是你经常用的那几台。这里要提醒一点不要直接删差异磁盘文件那样会让设备的配置完全重置。正确的做法是在 Web 界面上用擦除功能删掉设备的配置或者导出配置之后再清理。快照这个功能对做实验特别有用尤其是那些需要反复重来的实验。配好基础环境比如 IP 地址、路由协议基础配置之后打个快照之后每次做实验前恢复一下省得从头配。但快照链不能太长超过五六层之后设备启动会明显变慢因为需要逐层叠加。我一般每做完一个阶段的实验就把中间快照合并掉只留最新的一个基线。镜像本身的瘦身也要做。很多虚拟磁盘文件是用瘦分配方式创建的实际占用小于逻辑大小但随着使用会逐渐膨胀。可以用转换命令压缩一下qemu-img convert -O qcow2 virtioa.qcow2 virtioa-compact.qcow2转换出来的新文件体积通常能小一半但要注意转换之后必须重新设置属主和权限否则又会掉进前面说的权限坑里。这个操作我一般两三个月做一次挑一台不常用的镜像先试确认没问题再批量处理。6.3 卡顿、启动慢、控制台无响应的定位路径这一类问题排查起来最费时间因为它可能来自宿主机、可能来自虚拟设备本身、也可能来自浏览器。我整理了一套从外到内的排查顺序按这个走基本能定位到问题所在。现象第一嫌疑点验证方式设备启动超过十分钟无响应镜像文件损坏或缺文件看/opt/unetlab/data/Logs/对应日志所有设备都变慢宿主机内存或 CPU 打满top看 QEMU 进程占用单台设备卡顿该设备内存配额不够提高配额重启控制台输入有延迟浏览器渲染问题换个浏览器或清缓存设备能启动但连不通网桥或转发配置宿主机上用tcpdump抓包tcpdump这一项特别关键。拓扑里两台设备不通你怎么配都不通的时候先在宿主机的对应vnet接口上抓包。能看到包进来说明对方发出来了是接收端的问题一个包都看不到说明发送端就没发对地址。这一步能把排查范围缩小一半。浏览器侧的卡顿也不能忽视。EVE-NG 的控制台是基于网页终端实现的某些浏览器版本上会出现字符回显延迟、粘贴内容错位这类问题。我遇到过粘贴一长段配置进去只有前半段生效的情况一度以为是设备问题后来换浏览器就好了。所以遇到控制台表现诡异时先换个浏览器试试成本最低。7. 一次完整验证三套体系互联的拓扑实操7.1 拓扑与地址规划装完、导完镜像必须做一次完整的组网验证才算真正跑通。我用的验证场景是三套不同体系的设备互联一台用轻量镜像跑出的一台边界路由器一台 IOS-XE 体系的路由器一台 Junos 体系的路由器三台两两互联跑 OSPF 和 BGP 各一套。地址规划用 10.0.0.0/8 的私网段互联链路用 /30环回口用 /32。这个习惯建议养成无论什么实验互联链路都用 /30 加环回口模拟业务网段这样拓扑看起来干净路由表也好读。拓扑连接上边界路由器通过 Cloud 节点接到宿主机的管理网段其他两台只做内部互联。这样做的目的是验证虚拟设备能否通过 Cloud 节点和外部通信这是最容易被忽略的一环。7.2 逐台启动顺序与踩到的具体问题启动顺序很重要我的经验是先开轻量的、后开重的。原因是重型设备启动要吃掉大量内存和 CPU如果先开它们后开的轻量设备可能因为资源不足而起不来。所以顺序是先 start 轻量路由器等它进入命令行再 start IOS-XE最后 start Junos。实际操作中遇到的两个具体问题值得记录。第一个是 Junos 镜像启动之后控制台一直停在引导阶段等了三分钟没动静。查日志看到 QEMU 参数里内存配额是 2 GB而这个镜像官方建议 4 GB 起步。把配额调到 4096 之后重启四十秒就进系统了。这提醒我一点镜像的默认模板参数不一定适合你所用的版本导入新镜像之后最好先去查一下这个版本的资源要求。第二个是边界路由器通过 Cloud 节点访问不了宿主机所在网段的网关。现象是从设备上 ping 宿主机能通ping 网关不通而宿主机自己 ping 网关是通的。问题出在宿主机的 IP 转发和 NAT 链路上——ip_forward开了但转发的流量出去之后没有回程路由对方的网关不知道 10.x 这个网段怎么回来。解决方法是在宿主机上加一条源地址转换规则让实验网段的流量出去时被改写成宿主机地址。这条规则不持久重启之后会丢要写进开机脚本里。7.3 验证清单与收尾动作三台设备都起来之后按这个清单逐项验证。相邻设备互 ping 环回口验证链路连通性看 OSPF 邻居关系是否到 FULL 状态注意不同体系对 hello 间隔的默认值不一样Junos 和 IOS 都是 10 秒但某些配置下会不一致邻居就卡在 INIT看 BGP 会话是否 Established不同体系对 BGP 标识符的要求有差异没配 router-id 的设备可能不建会话。这些检查都在命令行里做看到想要的状态就说明这套环境真的能用了。验证通过之后有一件事必须做把整个拓扑导出成文件存档。EVE-NG 支持把拓扑和所有设备的配置一起打包导出这个文件在你换机器或者重装系统之后能原样恢复。很多人只在机器上存着一旦系统崩溃就全没了重新搭一遍的痛我经历过一次从那以后每次做完一个有价值的拓扑我都会导出存一份。8. 长期使用中的备份、升级与那些绕不开的坑8.1 备份该备哪些东西备份这件事只备镜像是不够的因为镜像可以重新导拓扑和配置丢了才是真的麻烦。我现在的备份清单包含三样东西一是拓扑导出文件包含所有设备的连接关系和配置二是/opt/unetlab/html/includes/config.php这个配置文件里面定义了 Cloud 节点、设备模板这些环境相关的设置三是自定义的设备模板如果你改过某个镜像的默认启动参数那个模板文件也要存一份。备份的节奏是每做完一个完整拓扑就存一次存放在另一台机器的目录里。拓扑导出文件一般不大几 MB但恢复的时候能省掉几天的工作量。镜像目录我单独用一块盘存两三个月做一次全量复制不追求频率因为镜像本身变动不频繁。8.2 升级内核/系统后网桥失效的处理这个问题我遇到过两次症状一模一样系统更新、重启之后Web 界面能打开设备也能启动但所有设备之间都不通了。查ip link看到pnet0还在但vnet接口对少了一半。原因是系统更新时把网络配置的格式或者网卡命名规则改了导致 EVE-NG 依赖的那些接口没有被正确创建。处理方式是把安装脚本里的网络配置部分重新跑一遍或者手工核对/etc/network/interfaces里pnet0的定义是否完整。更稳妥的做法是升级前先做一次快照或者备份系统盘。如果不是为了安全补丁我基本不做系统大版本升级这套环境跑起来就行没必要追新。内核小版本更新可以接受但每次更新之后要立刻做一遍连通性验证别等到下次做实验时才发现不通。8.3 我踩过的几个印象最深的坑第一个是网卡名漂移。装系统时没关可预测命名某次更新之后eth0变成了ens33pnet0绑不上整个管理网络断掉只能接显示器进去修。教训是装系统第一件事就把网卡命名固定住。第二个是权限。前面详细说过了导镜像之后忘了改属主设备起不来日志里报的是磁盘打不开完全不提权限。现在的习惯是每次导完镜像立刻跑一遍fixpermissions然后随便开一台设备验证一下。第三个是内存超分导致进程被杀。拓扑跑到一半某台设备凭空消失配置全丢。教训是内存留余量别顶格配重型设备分批启动。第四个是 Cloud 节点桥接造成广播风暴。把实验网桥接到了管理网卡上实验里的路由协议报文灌进实际网络把本地网络的交换机端口打满了。这件事之后我定了个铁律实验网桥永远不接物理网卡除非在一个物理上隔离的端口上做而且做完立刻拆掉。第五个是浏览器控制台粘贴丢内容。长配置粘进去只生效一半排查了半天设备问题最后换浏览器解决。之后我改成了分段粘贴每段不超过二十行中间停一下看回显虽然慢一点但不会出诡异问题。8.4 几个日常使用中的小习惯第一给每台设备起有意义的名字别用默认的R1、R2。一个三十台设备的拓扑默认名根本对不上号出问题时你连是哪台都找不到。我一般按位置-角色来命名比如核心-边界、分支-接入。第二每次开实验前先把不用的设备停掉。开着不用的设备纯粹浪费内存而且会让拓扑看起来乱。EVE-NG 的暂停功能很方便用完立刻暂停。第三抓包文件别一直留着。一次长时间的抓包能生成几百兆的文件堆在目录里没人管时间久了磁盘就满了。定期清一下抓包目录或者养成抓完立刻导出的习惯。第四遇到诡异问题先重启设备而不是重启整个环境。单台设备重启只要几十秒整套环境重启要好几分钟而且会打断其他正在做的实验。这个顺序反了会浪费大量时间。这套环境搭好之后真正花时间的就不再是装机而是设计实验和验证结论。前面这些配置和踩坑的过程看着琐碎但每一条都是为了让后面几百个小时的使用体验顺畅一点。我现在这台机器已经稳定跑了快两年中间只因为换硬盘重装过一次恢复的时候靠着拓扑导出文件和备份的配置半天就把环境还原回来了这就是前期把规范建好的回报。