H3C交换机FTP固件升级全链路与故障排查

上周帮一个朋友收拾一台跑了快五年的接入层交换机，固件老到什么程度呢——新版客户端连SSH握手都直接被拒，只能临时开telnet进去。他本来打算用U盘拷贝，结果机器在机柜最底下，导轨卡死，人得趴地上操作。最后还是老老实实拉网线、架FTP服务端，二十分钟搞定。这件事让我想起一个现象：很多人第一次给交换机升级固件，默认想到的是TFTP，觉得命令短、不用装软件，可一旦碰上几十兆甚至上百兆的镜像包，TFTP那种小窗口、无校验、一丢包就从头来的脾气，能把人磨得没脾气。

FTP升级固件这件事本身不复杂，真正让人头大的是"卡在哪一步说不出原因"。现象是get命令一直转圈，报错五花八门：Connection timed out、Permission denied、No space left、传完重启进了BootWare、重启后版本号纹丝不动。这些报错背后对应的是完全不同的问题域——网络层、服务端配置、文件系统、启动项绑定。这篇就把H3C交换机通过FTP拉取固件、校验、指定启动文件、重启生效这条完整链路拆开讲，重点是每一环"为什么要这么设"，以及失败之后怎么一层层往下剥。适合刚接手网络运维的新人，也适合那些升过几次但每次都在某个坑里反复摔的老手。

1. 为什么偏偏是FTP：固件搬运通道的取舍逻辑

1.1 四种搬固件方式的实测差异

给交换机换固件，本质是把一个几十到两百多兆的二进制文件从外部送进设备的flash里，然后在boot阶段让引导程序去加载它。搬运通道就那么几种，但脾气差别很大。

TFTP之所以被大量教程推荐，是因为它实现极简——UDP 69端口，交换机侧一条tftp 1.1.1.1 get xxx.bin就完事，不需要用户名密码。代价是它基于UDP，每个数据块64到1468字节，收一块确认一块，链路稍有抖动就重传，重传到一定次数直接放弃。我在百兆链路上传过一个120MB的镜像，TFTP跑了将近四十分钟，中途因为对端服务端软件的超时设置断了两次。

FTP走TCP，有滑动窗口，链路质量一般的情况下吞吐也能顶上去。这就是为什么当固件包超过50MB、或者跨网段、或者链路上有防火墙设备时，我会直接选FTP。

1.2 FTP真正占优的三个场景

第一个是跨三层网段升级。交换机在核心机房，运维终端在办公区，中间隔着防火墙。TFTP的UDP会话很容易被状态防火墙的超时策略掐掉，而FTP的TCP长连接反而更容易被放行（前提是端口开对）。

第二个是批量升级。十几台设备排着队升，FTP服务端可以给每个型号建独立目录、独立账户，还能从服务端日志里看到谁拉了什么文件、拉了多少字节、有没有拉完。这个审计能力在出问题时价值极高——你不用猜，直接翻日志就知道传输是否完整。

第三个是镜像体积大且链路质量不确定。比如通过专线或者无线网桥连接的远端站点，TCP的重传和拥塞控制机制比TFTP那种"超时就放弃"的粗暴逻辑友好得多。

1.3 升级前必须盘点的四样东西

动手之前，有四件事必须先落地，缺一件都可能在最后一步翻车。

一是确认目标版本与当前硬件的匹配关系。同一系列交换机可能有多种子型号，内存大小、flash容量、支持的镜像后缀都不同。把A型号的包刷到B型号上，轻则启动失败，重则直接变砖。

二是确认flash剩余空间。新镜像加上旧镜像，再加上配置文件，flash必须放得下。一台flash只有128MB的设备，上面已经躺着一个90MB的旧版本，你还想再塞一个95MB的新版本，那就必须先删旧的——但删之前你得确保新版本已经完整传上来并且校验通过，否则就是自断后路。

三是准备好带外通道或备用登录方式。升级过程要重启，重启后如果新版本起不来，设备会停在BootWare菜单。这时候如果只有SSH，你是进不去的，必须靠Console线。所以升级前把Console线插上、终端软件开着，这是基本功。

四是确认升级窗口和回退方案。生产设备升级必须报备、必须有人值守、必须准备好旧版本镜像留在flash里或者旁边电脑上。别信"升级很快"这种话，我见过传文件传了半小时、重启又花了十分钟的。

2. 动手前的版本核对：别把固件包当成通用件

2.1 display version 里真正该看的三行

登录设备后第一件事不是敲dir，而是display version。输出很长，但真正决定你能不能升、该升什么的有三处。

<Switch>display version H3C Comware Software, Version 7.1.070, Release 1118P02 ... Switch uptime is 128 days, 3 hours, 12 minutes ... BOOT version is 1.02 ... flash: 128M bytes

第一处是Comware的大版本号，V5和V7的镜像完全不通用，命令体系也不一样，V5用boot-loader file flash:/xxx.bin，V7常见的是boot-loader file flash:/xxx.ipe all，这两个别搞混。

第二处是BOOT版本。主程序镜像和引导程序是两套东西，有些大版本跨越需要先升BOOT再升主程序，或者镜像包里本身就带BOOT需要一并更新。如果跳过这一步，会出现"主程序升上去了，但引导程序认不出新格式"的诡异现象。

第三处是flash容量。这决定了你后面能不能保留旧版本做回退。

2.2 固件包名的后缀含义

市面上流传的固件包主要是.bin和.ipe两类，还有些带-boot、-patch后缀。.bin一般是单独的启动文件，.ipe是打包文件，里面可能包含BOOT和主程序两部分。给V7设备升级，多数情况下用.ipe一次性刷完更省事，命令里加all参数让它把包内组件全部更新。

补丁包（后缀常带-patch或PXX）是另一回事，它是叠加在基础版本上的增量修正，必须先有对应基础版本才能装，不能当独立固件用。特征库文件更是完全不同的东西，那是给入侵检测、应用识别模块用的，跟系统固件不是一类，别混在一起传。

2.3 一个容易忽略的细节：文件名与路径

FTP传输时，路径里的中文字符、空格、特殊符号都是隐患。交换机侧的文件系统对某些字符处理不友好，传过去可能得到一个名字被截断的文件。我的习惯是：服务端目录名和文件名全部用纯英文、数字、下划线，路径层级不超过两级，文件名长度控制在40字符以内。

另外，把厂商原始文件名改短是个好习惯。原始包名动辄六七十个字符，敲命令时手一抖就错。可以改成v7r1118.ipe这种，但改完记得在笔记本上记清楚它对应哪个原始版本，别过两个月自己都不认识。

3. FTP服务端的配置细节：多数失败栽在这里

3.1 账户与目录权限的最小化配置

交换机作为FTP客户端登录服务端，本质是一次普通的用户名密码认证加目录读取。问题在于，很多人在服务端上要么直接用管理员账户、要么给个只读账户但目录权限没配对。

推荐做法是建一个专用账户，只授予"读取"和"列目录"权限，根目录锁定到存放固件的那个文件夹，禁止向上跳转。这样即使账户信息在传输中被截获，损失也可控。具体到不同服务端软件，勾选项名字各异，但核心就三条：能登录、能列目录、能读文件。

有个细节特别容易漏：被动模式（PASV）的端口范围。FTP协议分主动和被动两种模式，交换机作为客户端默认的行为取决于具体版本。如果链路上有防火墙或NAT设备，被动模式的数据连接端口是随机的高位端口，防火墙不放行就会卡在"列目录成功但传输不动"的状态——这个现象特别有迷惑性，因为登录明明成功了。

排查时看到"能登录、能cd、能ls，但get卡住"，八成是被动模式端口被拦。可以试着在交换机侧的FTP客户端视图里切换到主动模式，或者让服务端把被动端口范围固定成一个区间再放行。

3.2 二进制模式与传输完整性

FTP有ASCII和二进制两种传输模式。固件是二进制文件，必须用二进制模式传，否则换行符会被转换，文件就废了。有些服务端软件默认自动判断，有些则默认ASCII，需要在账户配置里显式指定。

交换机侧的FTP客户端通常是按二进制处理的，不会主动做ASCII转换，但服务端那一侧如果设错了，一样会出问题。判断方法很简单：传完之后在交换机上看文件大小，跟服务端上的原始文件对比，差一个字节都不行。差了几个字节的典型特征就是大小对不上，或者校验值对不上。

3.3 连通性预检的三条命令

在正式传文件之前，花三十秒做三件事，能省掉后面半小时的瞎猜。

<Switch>ping 192.168.1.100 <Switch>ftp 192.168.1.100 <Switch>dir flash:/

第一条确认三层可达。第二条手动登录一次FTP，确认用户名密码没问题、能列目录。第三条看flash剩余空间，顺便确认当前目录位置。

如果交换机有多个接口、多个网段，还要确认FTP流量从哪个接口出去。有些设备默认走管理口或者某个指定源地址，导致服务端看到的源IP跟你预想的不是一个，白名单直接把你挡了。这时候需要显式指定：

<Switch>system-view [Switch]ftp client source ip 192.168.1.1

V7里这个命令是ftp client source ip X.X.X.X或者ftp client source interface Vlan-interface 1，V5里写法略有差异，用之前先敲个问号看一眼。

4. 交换机侧的命令链路：从登录到重启

4.1 权限级别与文件系统确认

交换机登录后默认在用户视图，提示符是<Switch>。配置FTP客户端源地址、指定启动文件这类操作需要进系统视图[Switch]，所以得先有管理员权限。

进系统之前先确认一下当前工作目录：

<Switch>pwd flash:/ <Switch>dir

dir的输出里关注两件事：剩余空间够不够，以及当前目录是不是你想要的目标目录。有些设备根目录是flash:/，有些是cfcard:/，还有些双主控设备有chassis/结构，路径写错了文件就传到了奇怪的地方。

4.2 拉取镜像的两条路径

交换机侧拉文件有两条路子，一条是进FTP客户端视图用get，一条是直接在用户视图用copy。

方式一：交互式登录

<Switch>ftp 192.168.1.100 Trying 192.168.1.100 ... Press CTRL+K to abort Connected to 192.168.1.100. 220 FTP service ready. User(192.168.1.100:(none)):netops 331 Password required for netops. Password: 230 User logged in. [ftp]get v7r1118.ipe flash:/v7r1118.ipe

这种方式的好处是全程可见，传输过程中有字节进度，出问题能立刻看到。缺点是每次都要交互输入，不适合脚本化。

方式二：一条命令直达

<Switch>copy ftp://netops:Passw0rd@192.168.1.100/v7r1118.ipe flash:/v7r1118.ipe

用户名密码直接写在URL里，适合批量作业。缺点是密码会留在命令历史里，操作完记得清理，或者在实验环境用。

稍微提一句：如果设备版本支持，用SFTP会更安全一些，传输走加密通道，密码不会明文过网。命令形式类似，把ftp://换成sftp://，前提是服务端支持SSH。生产环境我倾向于优先考虑这条路。

4.3 传完之后的三重校验

文件传上去，别急着敲重启。先做三件事。

第一，看大小。

<Switch>dir flash:/v7r1118.ipe

把显示出来的字节数跟服务端上原始文件对比。服务端那边右键属性看一眼就知道。数字必须一模一样。

第二，算校验值。

<Switch>md5sum flash:/v7r1118.ipe

算出来的MD5跟服务端文件比对。这一步很多人跳过，但它能抓出"大小对了但内容坏了"这种隐蔽问题——比如传输过程中某几个数据块出错但TCP没检测到重传异常，概率低但存在。

第三，确认文件类型被正确识别。有些版本的dir输出会标注文件类型，正常的镜像会显示成特定类型，如果显示成未知或者普通文件，说明文件头可能已经损坏。

4.4 指定启动文件与重启的正确顺序

校验通过之后，才是绑定启动项这一步。

<Switch>system-view [Switch]boot-loader file flash:/v7r1118.ipe all main

这个命令里的all表示把包内的所有组件（BOOT、主程序）都更新，main表示设为主用启动文件。双主控设备还要加slot参数指定主控板，别只升了一块板子就重启，那样会出现主备版本不一致导致的主备切换异常。

设完之后确认一下：

<Switch>display boot-loader

输出里能看到当前主用、备用启动文件分别是什么。确认主用指向新版本、备用还指着旧版本（这是好事，留了后路），再往下走。

保存配置：

<Switch>save force

重启：

<Switch>reboot

重启过程中千万别断电。有条件的接UPS，没条件的至少确认机房供电正常。写到flash的过程中断电，是真正意义上的变砖，只能返厂或者上编程器。

5. 传不动、起不来：四段式排查链路

排错的核心思路是分段定位：把"从发起传输到业务恢复"这条链路切成四段，每一段有明确的成功标志，卡在哪一段一目了然，而不是对着一堆报错瞎试。

5.1 第一段：FTP连不上

现象是ftp 192.168.1.100之后卡在Trying...，或者提示Connection refused、Connection timed out。

先分层。物理层和链路层用display interface brief看一眼接口是不是up，MAC有没有学到。网络层用ping确认可达，ping不通就往回找路由。传输层确认21端口通不通——有些环境里21端口被策略挡了，但ICMP是放行的，表现出来就是ping得通但连不上FTP。

再看服务端。FTP服务有没有起来，监听地址是不是只绑了127.0.0.1，账户有没有被禁用，并发连接数是不是满了。这些在服务端日志里都有。

还有一个高频原因：源地址不对。交换机从哪个接口发出去的包，服务端看到的源IP是什么，白名单配的是不是这个。用display ip interface brief看接口地址，必要时用ftp client source强制指定。

5.2 第二段：登上了但传不动

现象是能登录、能ls、能cd，但get一敲就长时间无响应，最后超时。

这个现象几乎可以锁定在数据连接上，而不是控制连接。控制连接（21端口）通了，说明认证和命令通道没问题；数据连接建立不起来，就是端口和模式的事。

处理顺序：先确认被动模式端口范围，让服务端固定一个区间（比如50000-50100），然后在中间设备上放行。如果中间设备不方便改，试着让交换机侧切主动模式。主动模式下是服务端主动连客户端的某个端口，如果交换机前面有NAT，同样会失败——所以这种环境下更彻底的办法是把交换机和服务端放到同一个二层广播域里，绕开所有中间设备。

传了一部分之后断，是另一种情况。看传输了多少字节，如果每次都断在差不多的位置，怀疑链路MTU或者中间设备会话超时。如果断的位置随机，多半是链路质量问题，换根网线、换个交换机端口试试。

5.3 第三段：文件传完了但重启起不来

现象是重启后设备进了BootWare菜单，或者提示找不到启动文件，或者反复重启。

先看display boot-loader的输出。如果主用路径指向的文件不存在，说明路径写错了或者文件被删了。如果路径对但版本不对，说明绑定的时候选错了文件。

BootWare菜单里可以做几件事：查看flash里的文件列表、重新指定启动文件、从备用启动文件启动。这时候Console线就是救命稻草，所以前面反复强调要插上。

一个容易被忽略的点：.ipe文件和.bin文件的绑定命令不一样。.ipe用boot-loader file xxx.ipe all，让系统自己解包；.bin用boot-loader file xxx.bin，对应的是单一启动文件。搞混了会出现"命令执行成功但重启没变化"的诡异现象，因为系统根本没把你指定的那个当启动文件。

还有flash空间不足的情况。.ipe解包的时候需要额外的临时空间，空间刚好卡在边缘时会出现"传到一半提示空间不足"或者"绑定成功但重启失败"。这种情况下必须删掉旧镜像腾地方——但删之前务必确认新镜像已经完整传上来且校验通过。

5.4 第四段：起来了但业务异常

版本号变了，设备也起来了，但业务不通、接口起不来、某些功能报错。

这时候先看配置有没有丢。升级过程中如果配置文件的格式与新版不兼容，部分配置项可能被丢弃或者解析失败。用display current-configuration对比升级前的备份，逐段看差异。

再看接口状态和协议状态。有些版本升级后接口默认参数会变化，比如生成树模式、聚合组协商方式、默认VLAN行为，这些变化在实验室环境里不明显，上了生产就是大面积故障。

最稳的做法是升级前把完整配置导出来存好，升级后逐项对比。真出问题了，回退版本是最快的止血手段。

6. 回退方案与升级后的收尾动作

6.1 留一条能走回去的路

升级前把旧镜像保留在flash里，并且确认备用启动项指向它。这样万一新版本起不来，在BootWare里切一下就能回退。

[Switch]display boot-loader [Switch]boot-loader file flash:/old_version.ipe all backup

留旧版本要占空间，空间不够的时候怎么办？我的做法是把旧镜像拷一份到FTP服务端或者本地电脑上，flash里只留新的。回退的时候再从FTP拉一次旧的。代价是回退耗时翻倍，但空间紧张时这是唯一解。

配置文件同样要备份，而且要比镜像更勤快。配置是文本，几十KB，导出成本几乎为零。

<Switch>display current-configuration

把输出完整贴到本地文件里，文件名带上设备名和日期。

6.2 升级后的验证清单

重启完成后，按顺序过一遍这几项：

这一步别嫌烦。我见过升级后没检查，第二天业务部门反馈某条专线不通，一查是接口默认MTU变了导致分片被丢。这种问题在升级当天是看不出来的，等到业务高峰才暴露。

6.3 几个容易忽略的收尾动作

清理服务端账户。升级完成后把临时开的FTP账户停掉或者改密码。这个账户在升级窗口之外是纯粹的风险敞口。

清理flash里的临时文件。传输过程中产生的残片、解包临时文件，都会占空间。用dir看一眼，把不认识的文件确认清楚再删。

在设备上写备注。在配置里加一行描述，记录升级日期和目标版本，下次接手的人不用去翻工单。

[Switch]sysname Floor3-SW01 [Switch]header login %Upgraded to R1118P02 on 2024-05-12, backup image retained%

这行提示在每次登录时都会显示，比写在文档里管用得多。

更新资产记录。版本号变了，监控系统里的基线、漏洞扫描的规则、变更管理系统里的记录，都跟着更新。否则过几个月做合规检查，一堆设备报"版本与基线不符"，又是一轮解释。

我自己踩过的坑里，最冤的一次不是技术问题——是升级完忘了关掉服务端的FTP账户，两个月后被人用这个账户登进去放了东西。技术动作都做对了，就差最后那一下收尾。所以现在我的升级清单最后一行永远写着："关账户、删临时文件、写备注"。

另外分享一个小习惯：每次升级前，把整个操作步骤写成一份带命令的清单，打印出来放在手边。不是记不住，而是在机房里趴着、Console线和电源线缠在一起、电话还在响的时候，人是会跳步骤的。照着单子一条条打勾，比靠脑子可靠得多。