华为交换机FTP配置：客户端/服务端、配置备份与镜像上传

半夜十一点，某园区网的运维群里消息还在跳。核心交换机第二天凌晨要做版本升级，割接清单上最后两项是"备份当前配置"和"把新版本镜像传上去"。结果翻遍跳板机才发现，之前一直用的那个简易文件传输小工具上周清理磁盘时被顺手删了，临时装又赶不上窗口期。这时候最省事的兜底方案，就是把华为交换机 FTP 配置拉起来——让交换机自己当客户端去取文件、传文件，或者干脆让交换机临时当个服务端，从笔记本上直接怼镜像进去。这篇就把华为交换机FTP配置这件事从头到尾讲透：FTP 在今天的网络运维里到底是什么位置、交换机当客户端和当服务端分别怎么配、每一步命令背后的意图是什么、哪里最容易翻车、翻车之后怎么三五分钟内定位。

先说清楚适合谁看。刚接手网络设备、只知道 Telnet 进去敲两行 display 命令的新人，看完能独立完成一次配置备份和镜像上传；干了几年但一直用 TFTP、没正经配过 FTP 的老手，能从里面的权限模型、主动被动模式、ACL 卡源这几块补齐盲区；负责割接方案评审的人，也能从安全加固那节拿到几条能直接写进方案里的限制条件。整篇不玩概念，全部围绕"我要传一个文件上去/下来"这个动作展开。

1. 把 FTP 放回它该在的位置

1.1 为什么这个三十年前的老协议在交换机上一直没被淘汰

很多人一提到 FTP 第一反应是"太老了，不安全，早该淘汰"。这话放在互联网业务侧没毛病，但放到交换机运维这个具体场景里，结论会打个折。原因很实在：交换机上的文件系统极小，要传的东西也就那么几类——配置文件vrpcfg.zip、系统软件包.cc、补丁文件.pat、有时还有 License 文件。这些文件动辄几十兆到几百兆，传输频率低，但是一旦需要，就必须一次成功。在这种"低频、大文件、强可靠"的组合下，FTP 的优势就出来了：它比 TFTP 多了身份认证、多了目录操作、多了断点续传的可能，传输过程有明确的状态码可以看；它又比 SFTP/SCP 在设备侧的实现要求低，老版本 VRP 上不一定有完整的 SSH 支持，但 FTP 客户端基本是标配。

更关键的一点是，TFTP 在很多版本上对文件大小有限制，传个几十兆的小补丁没问题，传几百兆的系统软件包就容易中途失败，而且失败之后你根本不知道是网络丢包还是服务端磁盘满了。FTP 至少会给你一句明确的返回码。所以我的实际做法是：小文件、一次性、临时用，TFTP 图快；正式备份、系统升级、批量分发，走 FTP 或者 SFTP。这也是为什么"华为交换机FTP配置"这个看起来老掉牙的话题，在各类运维群里还天天有人问。

1.2 交换机当客户端还是当服务端，选型逻辑完全不同

这是最容易搞混的一步。同样叫"FTP 配置"，交换机作为客户端和作为服务端，配置命令、权限模型、甚至故障表现都完全不一样。我见过不少人把两套命令混着敲，敲完发现ftp server enable配了但ftp 10.x.x.x登不上去，就是因为角色没分清。

判断逻辑其实很简单：文件在谁身上，谁就是服务端。你要把交换机上的配置备份到一台服务器上，那服务器是服务端，交换机是客户端；你要把笔记本上的新镜像推到交换机里，那笔记本是服务端，交换机还是客户端；只有当交换机上存着别人要的文件，比如多台设备要统一取同一个镜像，才考虑让交换机当临时服务端。

从这张表能看出来，客户端模式是日常主力，服务端模式属于应急手段。下面两章分别展开，但重心会放在客户端上，因为那才是九成以上场景的真实需求。

1.3 先把"要传什么文件"这件事定下来

配置之前先想清楚目标文件，这一步很多人跳过，结果配完发现传错了东西。交换机上跟传输相关的文件通常就这几类：vrpcfg.zip是当前配置的归档，save之后才会有最新版本，不save直接备份等于备份了个旧配置；.cc结尾的是系统软件包，升级时用；.pat是补丁；.cfg是文本格式的配置文件，导出后可以直接看内容。

这里有个细节值得单独提一句：vrpcfg.zip是压缩过的，你在服务器上打开看到的是一堆二进制；如果你想在服务器上直接对比两次配置的差异，得先导出文本格式，用display current-configuration抓到本地，或者用save configuration-file另存为.cfg。我个人的习惯是双份：vrpcfg.zip留作回滚用，文本配置留作人工比对用。这两份东西传完，一次割接的保险才算上齐。

2. 动手前的准备：版本、地址、账号三件事

2.1 版本差异先核对，别拿新命令往老设备上敲

VRP 版本跨度很大，V200R003 和 V200R019 之间隔了不知道多少轮迭代，同一个功能命令形态可能完全不一样。最典型的就是本地用户密码这条：老版本用local-user xxx password simple 明文，新版本推荐irreversible-cipher，有些版本还强制要求密码复杂度。再比如源地址指定，早年的写法是ftp client source-ip，后来统一成ftp client source-interface，敲错一个词设备直接报"Unrecognized command"。

先做两件事：display version看版本，display current-configuration | include ftp看现网有没有已经配过的残留。第二件事特别重要，我曾经在一台设备上排查了半小时为什么 FTP 登不上，最后发现前任工程师配了个ftp server acl，规则里只放行了一个早就下线的网段。现网残留的 ACL、源地址绑定、VTY 限制，都是隐形地雷。

提示：不确定命令形态时，直接在 system-view 下敲到一半按?，设备会把这个版本支持的所有形态列出来，比查文档快，也比凭记忆敲靠谱。

2.2 管理地址与连通性，先把路打通再谈文件

FTP 是应用层协议，底下网络不通，上面配出花来也没用。配置前先确认三件事：交换机的管理地址（一般是某个 Vlanif 接口地址）能 ping 通服务端；服务端的 21 端口没有被本机防火墙拦；中间如果有安全设备，策略是否放行。这三条里最容易翻车的是第二条，Windows 上装个 FTP 服务端，装完自己 telnet 本机 21 通，但从交换机连过去就是不通，八成是系统防火墙默认只对本地放行。

华为交换机上验证连通性用ping -a 源地址 目的地址，注意这个-a参数，它让你指定从哪个地址发起。别小看这一步，交换机上有多个三层接口的时候，不加-a出去的可能是个业务地址，服务端 ACL 只放行了管理网段，于是就出现"我明明配了管理地址却连不上"的经典误会。这个坑我在第 6 章还会展开讲。

2.3 账号与权限，别拿管理员账号到处传文件

服务端侧建一个专用 FTP 账号，只给它一个目录的读写权限，这是基本操作。原因有两个：一是明文协议，账号密码在链路上裸奔，一旦被抓包,损失范围要可控；二是出了事故好追溯，看日志里这个账号传了什么东西一目了然。如果你在交换机上开服务端，本地用户的级别直接决定它能干什么，级别 15 基本等于全权限，级别 1 只能看，别图省事全给 15。

注意：交换机作为服务端时，本地用户必须配ftp-directory，不配的话登录能成功，但一执行dir或put就报错，这个错误信息往往很含糊，容易让人误以为是权限问题去折腾 ACL。

3. 交换机作为 FTP 客户端：备份与取镜像的主力姿势

3.1 最小可用配置：源地址这一条千万别省

先给结论：只要设备上有多个三层接口，ftp client source-interface就是必配项，不是可选项。命令形态是这样：

<HUAWEI> system-view [HUAWEI] ftp client source-interface Vlanif 10

这条命令的意思是：以后所有从这台交换机主动发起的 FTP 连接，源 IP 都固定用 Vlanif 10 的地址。为什么必须指定？因为交换机转发报文时默认用出接口的地址做源，管理流量从业务口出去的话，源地址就是个业务网段地址，服务端的 ACL 一看不认识，直接拒掉。更隐蔽的情况是服务端不设 ACL 但做连接审计，日志里记录的全是业务地址，事后根本对不上是哪台设备备的份。

配置完用display ftp client source之类的命令确认一下（不同版本确认命令略有差异，也可以在后续登录时看服务端日志里的源 IP）。这一步花不了一分钟，能省掉后面一小时的排查。

3.2 一次完整的交互式传输实录

配置好了就登录。交换机的 FTP 客户端是交互式的，登进去之后是一个[ftp]提示符，这个提示符跟system-view的[HUAWEI]长得像，但完全是两套东西，不要在[ftp]下面敲display，它会告诉你命令不存在。

<HUAWEI> save The current configuration will be written to the device. Are you sure to continue? [Y/N] y <HUAWEI> ftp 10.1.1.100 Trying 10.1.1.100 ... Press CTRL+K to abort Connected to 10.1.1.100. 220 FTP Server ready. User(10.1.1.100:(none)):netadmin 331 Password required for netadmin. Enter password: 230 Logged in successfully. [ftp] binary [ftp] dir [ftp] put vrpcfg.zip [ftp] bye

逐行拆一下。save必须在备份之前执行，不然你传过去的是上次保存的配置，这中间做的改动全丢，回滚的时候等于把自己坑了。binary是切换到二进制模式，对.zip和.cc这类文件必须要，文本模式下有些服务端会做换行符转换，传过去的镜像直接损坏，刷进去设备起不来，这是真的会出事故的。dir看一眼服务端目录，确认路径和文件名没写错。put是上传，get是下载，方向别搞反。

断点续传这块补一句：交换机侧的 FTP 客户端对续传的支持有限，put大文件中断了通常得从头再来。所以传几百兆的系统包之前，先用dir flash:看一眼剩余空间够不够，空间不够传到 90% 失败，白等半小时。

3.3 把备份做成可重复的动作

单次备份靠手敲没问题，但割接前前后后要备好几次，这时候值得把流程固定下来。交换机侧的配置备份实际上就三步：save、登录 FTP、put。文件名带上日期和设备名，方便日后翻找。

<HUAWEI> save <HUAWEI> dir flash: <HUAWEI> copy flash:/vrpcfg.zip flash:/backup/vrpcfg-20250612.zip

copy之前目录得存在，不存在先mkdir flash:/backup。注意 flash 空间本来就紧张，老设备上塞几个镜像就满了，做本地副本之前先看剩余空间，dir输出的最后一行会写剩余多少字节。

至于自动化的定时备份，交换机侧的scheduler在部分版本上能用，配上command序列定时执行脚本，但实话讲，跨版本兼容性一般，调试成本不低。我通常直接把这件事甩给外部：在跳板机上跑个脚本，用 Python 的 paramiko 走 SSH 连设备，display current-configuration抓下来按日期存盘，顺便还能做配置差异比对。这种方式跟设备版本解耦，换什么型号都能跑。FTP 留给"必须传文件"的场景就好。

3.4 客户端侧几个容易忽略的细节

第一个是超时。登录 FTP 之后长时间不操作，服务端会主动断连，你再敲命令就报"连接已关闭"。传大文件的时候不会有这个问题，因为数据通道一直活着。这个不算故障，重新登录就行。

第二个是文件覆盖。put vrpcfg.zip的时候如果服务端已经有同名文件，有的服务端直接覆盖，有的会拒绝，报错码是 550 或 553，看你用的服务端实现。我习惯在文件名里带时间戳，彻底绕开这个问题。

第三个是中文路径和空格。交换机侧的文件名一律用英文数字下划线，路径里别带空格，这些在 Windows 服务端上看着没事，到了传输环节就是一堆转义问题。别问我怎么知道的。

提示：[ftp]模式下的pwd显示的是服务端的当前目录，不是交换机本地的。想切服务端目录用cd 目录名，想切交换机本地文件用完整路径put flash:/xxx.zip。

4. 交换机作为 FTP 服务端：临时文件中转站

4.1 使能与本地用户，两步都不能少

这个模式用得少，但在"手头只有一台笔记本、不想装服务端软件"的场景下特别好用。整套配置就四块：开服务、建用户、指定目录、限来源。

<HUAWEI> system-view [HUAWEI] ftp server enable [HUAWEI] aaa [HUAWEI-aaa] local-user netadmin password irreversible-cipher 你的密码 [HUAWEI-aaa] local-user netadmin service-type ftp [HUAWEI-aaa] local-user netadmin privilege level 15 [HUAWEI-aaa] local-user netadmin ftp-directory flash:/ [HUAWEI-aaa] quit

这里每一行的意图值得说清楚。service-type ftp是关键，不写的话这个账号根本不允许走 FTP 登录，现象是密码对但一直提示认证失败，很多人卡在这一步。privilege level 15决定这个账号能执行哪些操作，级别低了能登录但传不了文件。ftp-directory flash:/指定登录后的默认根目录，不配这个大概率报"当前目录不存在"。

还有一个容易混淆的点：FTP 登录的身份校验走的是 AAA 本地用户，跟 VTY 的authentication-mode没有直接关系。也就是说，你只配了 VTY 没配本地用户，FTP 登不上去；你配了本地用户但 VTY 一个都没配，FTP 反而能登上去。这一点跟 Telnet/SSH 的逻辑不一样，配置的时候别类比着记。

4.2 目录与权限，别把整个 flash 敞开

ftp-directory flash:/意味着登录后能操作整个 flash，包括系统软件包。这在临时中转场景下风险偏大，万一客户端误操作删了.cc文件，设备重启直接起不来。更稳妥的做法是建个专门目录：

<HUAWEI> mkdir flash:/ftp_tmp [HUAWEI-aaa] local-user netadmin ftp-directory flash:/ftp_tmp

这样客户端登录后只能在这个目录里活动，取文件得先copy进来，传上去的文件也隔离存放，用完delete /unreserved清干净。多花两分钟，换来的是"设备起不来"这个极端风险被掐掉。

4.3 从客户端侧验证，别只看设备侧显示成功

交换机侧敲完ftp server enable会立刻返回，但这不代表服务真的通了。从 PC 上用命令行验证最直接：

ftp 10.1.1.2

或者干脆用一个图形化 FTP 客户端连上去，先ls看目录，再传一个小文件试水。放一个小文件、传上去、ls确认大小一致，这三个动作走完，才说明整条链路是通的。直接上手传几百兆的镜像，中途失败你还得排查是链路问题还是文件问题。

传完记得核对文件大小，dir输出的字节数跟本地文件对比，一致才算成功。FTP 有个隐性毛病：传输中断的时候客户端可能报了个错误但文件已经部分写入，服务端不做校验的话你拿到的是个残缺文件，刷进去才知道坏，那就晚了。

4.4 用完就关，这是纪律不是建议

交换机开 FTP 服务端本质上是把管理面暴露了一个明文入口，密码在链路上裸奔，抓包工具几十秒就能还原。这个服务只应该存在于维护窗口的那几十分钟里。

[HUAWEI] undo ftp server enable [HUAWEI-aaa] undo local-user netadmin

关掉服务、删掉临时账号，两行命令的事。我在方案评审时会把这两条写成割接回退清单里的固定项，谁配的谁负责关，做完打勾。真出过事：某次割接完忘了关，两周后例行扫描扫出来一个开放 21 端口的设备，追查下来是本部门自己留的口子，场面相当难看。

5. 安全加固：把明文协议的风险压到最低

5.1 用 ACL 卡住来源，这是性价比最高的一条

既然协议本身安全不了，那就从网络层限制谁能连。交换机作为服务端时，一条基本 ACL 就能把来源锁死到一个网段：

[HUAWEI] acl number 2000 [HUAWEI-acl-basic-2000] rule 5 permit source 10.1.1.0 0.0.0.255 [HUAWEI-acl-basic-2000] rule 10 deny [HUAWEI-acl-basic-2000] quit [HUAWEI] ftp server acl 2000

注意rule 10 deny这条，ACL 默认对未匹配的报文是拒绝的，但显式写一条 deny 能让配置读起来意图明确，也避免某些版本上默认动作被改过导致放行。这个习惯值得养成，尤其在多人维护的环境里，后来的人读配置一眼就知道边界在哪。

如果是交换机作为客户端往外连，卡的是服务端侧，交换机这头能做的就是把ftp client source-interface固定在管理接口上，让所有出向 FTP 流量都从管理口走，业务口上不要出现 FTP 会话。

5.2 VTY 与协议限定，别让管理面四通八达

user-interface vty那一套管的是 Telnet/SSH 登录，虽然不直接影响 FTP 登录，但管理面的整体收紧是配套的：

[HUAWEI] user-interface vty 0 4 [HUAWEI-ui-vty0-4] authentication-mode aaa [HUAWEI-ui-vty0-4] protocol inbound ssh [HUAWEI-ui-vty0-4] acl 2000 inbound

protocol inbound ssh把 Telnet 关掉，acl 2000 inbound限定只有管理网段能连进来。这两条跟 FTP 的 ACL 是同一个 ACL 编号，一次配好两处受用。管理面收敛这件事，做一次管很久，值得在设备开局时就写进模板。

5.3 密码策略和账号生命周期

交换机上的本地用户密码，能用irreversible-cipher就用，别用simple。一个是新版本会对simple报警告，另一个是display current-configuration的时候simple的密码是明文展示的，随手截图发群里就泄露了。

账号要设有效期的话，部分版本支持local-user xxx expire，配置成维护窗口结束后自动失效。这个特性不是所有版本都有，有就用，没有就靠流程约束。我的做法是在割接脚本里把"删账号"和"关服务"写进最后的清理步骤，机器记着比人记着靠谱。

5.4 明文协议的先天短板，以及什么时候该换条路

FTP 的密码和数据都是明文，这个问题靠配置解决不了，只能靠网络隔离和窗口期控制来缓解。真有长期、高频的文件传输需求，就该考虑替代方案了。

交换机侧开 SFTP 服务端的配置大概是这个形态：

[HUAWEI] rsa local-key-pair create [HUAWEI] sftp server enable [HUAWEI] stelnet server enable [HUAWEI] user-interface vty 0 4 [HUAWEI-ui-vty0-4] authentication-mode aaa [HUAWEI-ui-vty0-4] protocol inbound ssh

生成密钥对那一步在某些版本上要几十秒，屏幕上看着像卡住了，别急着 Ctrl+C。SFTP 客户端侧用交换机主动连出去也一样，sftp 10.1.1.100然后输账号密码，之后的putget命令跟 FTP 基本一致，唯一区别是不用敲binary，加密通道本身不做文本转换。

6. 排查实录与速查表

6.1 从现象到原因，一张表顶半小时

FTP 的报错信息普遍不友好，一个"连接失败"背后可能是六种原因。我把这些年遇到的情况整理成一张表，下次出问题先对着现象找一行，能省掉大量试错。

表里"put卡住不动"这一条最值得展开。FTP 有两条连接：控制连接走 21 端口，数据连接走另一个临时端口。主动模式下是服务端主动往客户端连，如果客户端在 NAT 后面或者中间有防火墙，这个反向连接就建不起来，现象是登录正常、ls正常，一到真正传数据就卡死。判断方法很简单：把交换机和服务器放到同一个网段直连试试，如果通了，就是中间设备的问题。解决思路要么是放行数据端口范围，要么改被动模式，但交换机侧的 FTP 客户端对被动模式的支持看版本，passive命令敲下去没反应就说明这个版本不支持，那就只能走网络侧调整。

6.2 几个印象深刻的坑

坑一：源地址选错，排查了半天 ACL。某次在核心交换机上配备份，服务端 ACL 只放行管理网段，交换机上ping -a通，但 FTP 死活登不上。最后display ftp client source一看，压根没配源接口，报文从业务口出去，源地址是个业务地址。加上ftp client source-interface Vlanif 10之后立刻通。这件事之后我形成了习惯：只要设备超过两个三层接口，配 FTP 客户端第一件事就是指定源。

坑二：忘了save，备份了个寂寞。事情是这样的：下午做了一堆策略调整，晚上割接前想着先备份一份，ftp登录传了vrpcfg.zip，传完还挺得意。结果第二天回滚的时候发现，备份里的配置停在当天早上，下午的改动一条没有。save这一步在压力大的时候特别容易漏，后来我在割接清单里把它单列成一行，前面加个复选框。

坑三：flash 空间不够，传到 95% 失败。老设备上堆了好几个历史镜像，dir看一眼剩余空间只有几十兆，传一个两百多兆的系统包，前面一路顺畅，最后关头报错。这时候心态最容易崩。正确做法是传输前先清理：delete /unreserved flash:/旧镜像.cc，注意要加/unreserved，普通delete只是把文件挪进回收站，空间并没有真正释放，还得再执行一次reset recycle-bin。

坑四：文件名字带空格。从 Windows 上拖了个文件到 FTP 服务端目录，名字里有个空格，交换机侧get的时候怎么都找不到。后来发现得用引号包起来或者干脆改名。这种问题没有任何技术含量，但就是能耗你二十分钟。规范做法是文件名只用英文、数字、下划线、短横线。

6.3 我个人在实际操作中的体会

这些年配下来，我对华为交换机 FTP 配置这件事的判断就一句话：它是个好用的应急工具，但不该成为常态流程。临时备份、割接窗口传镜像、手头没别的工具时救个急，FTP 又快又稳；但你要是把它做成每天定时跑的生产流程，明文传输这个短板迟早会变成审计报告上的一条。

所以我现在的基本打法是：日常配置备份走脚本 + SSH，把配置抓到跳板机按日期归档，顺带做差异比对；系统升级这种必须传大文件的场景，提前半小时把 FTP 服务端准备好，ACL 卡死来源，传完立刻关服务、删账号，一整套动作写进割接脚本里自动执行；实在遇到老设备不支持 SSH 的，才退回到 FTP，而且只在内网、只在窗口期。

还有个小技巧值得分享：传输完成后，别只看客户端提示的"传输成功"，一定回到设备上dir一下，比对文件字节数和本地是不是一模一样。这一步三十秒，但能在刷机之前挡住所有"文件传坏了"的悲剧。我见过一次系统包传到 99% 断了，客户端提示失败，但服务端已经写入了大部分内容，文件看着挺大，实际是坏的，如果直接刷进去，设备就变砖了。多看一眼，比事后救砖划算太多。