企业官网建设流程全解析

简介：面向Linux系统下的网络设备维护与开发工程师，这份资源专门讲解利用eeupdate64工具对I210、I350、82575/6、XL710、E810等Intel网卡进行MAC地址修改与固件烧录的完整操作流程。文档内容覆盖前期软硬件准备、工具获取与权限适配，以及i350网卡单个/多个MAC地址修改、.eep固件制作与刷写、全新无固件网卡从零烧录到测试验证的完整路径；同时说明xl710网卡使用.bin或.eep文件烧录的差异，并给出推荐做法。文档还特别提醒i350固件修改只能使用.eep格式，xl710用.bin烧录耗时较长，建议优先采用.eep文件以提升效率，这些细节能帮助规避常见坑点。资源包共1个文件，为docx格式文档，大小1.09MB，内容按前期准备、软件适配、具体网卡操作和从零修改之路分模块展开，命令行示例配合结果截图，便于按步骤查阅操作。已有1788人学习浏览，适合从事服务器部署、网卡固件维护及网络环境变更的技术人员参考，能够帮助解决实际工作中的网卡底层配置难题，也可作为新网卡初始化的操作手册。

1. 为什么要把 eeupdate64 当作网卡维护的标配工具

拿到一批几百片的二手 i350 或 XL710 网卡，第一件事往往不是插上就用，而是要把板载 MAC 改成资产系统里登记好的地址。Linux 下这个操作不用开机箱、不用进 BIOS，靠 Intel 官方工具 eeupdate64 就能把“改 MAC”和“重烧固件”两道工序一次做完。很多运维第一次用这个工具就翻车：要么把-nic和-mac参数理解错，把网卡改成系统里已经存在的地址；要么在 XL710 上照搬 i350 的命令，把整个网卡刷成版本不匹配的黑匣子。这篇文章把 i350 和 XL710 在 Linux 下用 eeupdate64 改 MAC、烧固件的完整路径捋一遍，适合正在做网络硬件维护、服务器交付和网卡备件管理的工程师照着复现。

2. 准备阶段：驱动、工具和网卡识别，做错了后面全白搭

2.1 先识别芯片型号和驱动：igb 还是 i40e

eeupdate64 不能凭外观猜网卡型号，它依赖系统里加载的驱动来识别设备。所以动手前先确认芯片组对应的内核模块：i350 走的是 igb 驱动，XL710 走的是 i40e 驱动。一组 linux 常用命令就能把型号、驱动和总线信息一次看清楚：

lspci -nn | grep -Ei 'ethernet|igb|i40e' ethtool -i ens2f0 lsmod | grep -E 'igb|i40e'

lspci的输出里会直接出现 Intel Corporation I350 Gigabit Network Connection 或 XL710 的字样，后面的[8086:1521]这类编号是 PCI 设备 ID。ethtool -i返回的driver:字段如果显示 igb，说明当前网卡由 igb 驱动接管；显示 i40e 就是 XL710 系列。lsmod用来确认驱动模块已经加载，如果模块没挂上，eeupdate64 会报找不到设备。

这里有一个很常见的误判：系统里插了两张同型号网卡，但 eth0/ens2f0 这类接口名在重启后会变，直接按接口名操作容易烧错网卡。正确做法是把 lspci 的总线地址和 ethtool 的接口名对应起来，例如lspci -s 05:00.0 -v能看到该总线上的 MAC 地址，再和ip link show ens2f0对照。先确认“哪条总线对应哪个系统接口”，后面操作才能定位到具体的物理网卡。

2.2 eeupdate64 工具怎么拿、怎么确认它能用

eeupdate64 是 Intel 以太网驱动包里自带的命令行烧录工具，通常包含在驱动包解压后的util目录里。常见做法是去 Intel 下载中心找对应网卡型号的“完整驱动包”，而不是只下载内核模块。解压后能看到eeupdate64这个可执行文件，注意它是 64 位 x86 程序，拿到手先赋予执行权限并确认版本：

chmod +x eeupdate64 ./eeupdate64 -?

-?参数会列出当前工具支持的全部开关。不同版本工具可用的参数有差异，就以本机这份输出的帮助文本为准。这一步花两分钟，能避免后面因为参数写错而反复折腾，比如老版本不支持-j指定路径，新版又加了-nvmupdate等专用模式。工具运行需要 root 权限，因为要直接访问 PCI 配置空间和 flash 设备，普通用户执行会直接权限拒绝。

工具本身不挑发行版，CentOS、Ubuntu、Debian 都能跑，但有一个前提：必须是 x86_64 架构。遇到国产 ARM 平台（飞腾、鲲鹏）跑不起来时，别在原地耗，把网卡拆下来插到一台 x86 的测试机上改完再装回去，这比在 ARM 上交叉编译各种依赖现实得多。

2.3 动手前的备份：永久 MAC、EEPROM 快照和版本号

改 MAC 和烧固件都属于写硬件操作，一旦断电中断，网卡可能变成一块不认设备的砖。所以每次操作前，先把网卡的原始信息完整留档。三条命令各干一件事：

ethtool -P ens2f0 ethtool -e ens2f0 dump > i350_backup_eeprom.hex ethtool -i ens2f0

ethtool -P显示的是永久 MAC 地址（permanent address），这个地址来自网卡固件，和ip link里显示的当前 MAC 可能不同。ethtool -e把整个 EEPROM/flash 内容导出成十六进制文件，烧录失败时可以用它配合工具做恢复。ethtool -i里的fw-version记下来，升级完固件要拿这个值做前后对比。

备份文件建议按“机器名-网卡型号-日期”命名，存到独立目录而不是随手放 /tmp。多网卡机器每张卡导出一份，标签写清总线地址。这一步看着多余，但真遇到过批量交付时两张卡 EEPROM 数据互串的情况，有备份就能逐字节比对出问题。

3. i350 网卡改 MAC：查询、修改与固件烧录一次走通

3.1 查询 NIC 编号和当前 MAC：不要凭 eth 名猜

eeupdate64 对网卡的编号方式是按 PCI 总线扫描顺序排的-nic序号，不是系统里的 eth0 接口名。先用查询模式列出所有网卡编号：

./eeupdate64 -all

输出会显示每个-nic序号对应的设备型号、总线地址和当前 MAC。比如机器上插了两张 i350，可能显示NIC 1: Intel I350 ... MAC 00:1B:21:...，NIC 2是第二张卡。想确认 1 号到底是哪张物理卡，就对上一步备份时记录的总线地址，或者用-nic 1单独再看一眼详细信息：

./eeupdate64 -nic 1 -mac

这个命令不会改任何东西，只是把 1 号网卡当前固件里的 MAC 显示出来。养成先查再改的习惯，能避免把生产机器上正在用的网卡当成测试卡刷掉。另外，-all输出里 MAC 全为FF:FF:FF...或全零时，说明 flash 内容已经异常，这种卡建议先做固件重烧再改 MAC，顺序反了可能白改。

3.2 修改 MAC 的最小命令：一条命令的格式边界

确认好 NIC 编号后，改 MAC 就是一条命令的事：

sudo ./eeupdate64 -nic 1 -mac 001B21AABBCC

-nic 1指定第一张物理网卡，-mac后面跟 12 位十六进制字符，不带冒号、不带0x。这是 Intel 工具最多见的输入格式，部分版本也能识别-mac=00:1B:21:AA:BB:CC带冒号的写法，但我建议统一用无分隔格式，避免工具版本不一样导致解析出错。执行成功后工具会打印类似MAC Address updated successfully的信息。

命令执行完，固件里的永久 MAC 已经变了，但当前系统接口的 MAC 要重启或手动ip link set才会同步。这里有一个容易误解的点：ip link show看到的地址可能还是旧值，别急着判定命令没生效，用ethtool -P查永久地址，那个值变了才算写进固件。

如果机器上有多个端口且要分别改成不同地址，就用循环逐卡处理：

for n in 1 2 3 4; do sudo ./eeupdate64 -nic $n -mac 001B21AA00${n} done

循环里每次用${n}拼出唯一 MAC，避免手抖把两张卡改成同一个地址。实际环境里两张网卡同 MAC 会导致 ARP 表错乱，交换机上会看到 MAC 漂移告警，排查起来非常头疼。

3.3 i350 固件烧录：从 .hex 到验证

需要升级固件时，先去 Intel 官网下载对应 i350 型号的固件更新包，解压后通常能得到.hex或.flv格式的固件文件。烧录命令如下：

sudo ./eeupdate64 -nic 1 -up -j /opt/eee_fw/ -f i350_1_63_17.hex

-up表示执行 update 模式，-j指定依赖文件所在目录（工具运行时可能需要在同目录找配置或驱动文件），-f后跟实际的固件文件。注意-f和文件名之间可以不加等号，但文件路径不要包含中文或空格。

烧录过程中绝对不能断电，也不要执行重启操作。建议用带外管理（IPMI/iLO）或者物理终端执行命令，避免 SSH 断连后无法确认进度。烧录完成后工具一般会提示重新上电，此时关机、拔电源、再开机，让网卡用新固件重新初始化。

升级完验证三个值：ethtool -i的fw-version是否变成新版本、ethtool -P的永久 MAC 是否还是我们改过的地址、ip link里接口是否 UP。固件升级有时会连带 MAC 一起重置，所以先改 MAC 再升固件的顺序不可靠，每次升级完都要重新确认一遍 MAC。

4. XL710 网卡操作：固件结构不同，命令不能直接照搬

4.1 XL710 与 i350 的差别：NVM 和 DDP 是两套东西

XL710 是 i40e 系列，表面看都是 Intel 网卡，但固件结构和 i350 完全不一样。i350 的 flash 里存的是传统 NVM，改 MAC 和烧固件都走同一套 EEPROM 逻辑；XL710 除了基础 NVM，还多了一个 DDP（Dynamic Device Personalization）配置区，用于加载不同的包处理管线。这带来了两个直接后果：一是升级固件时要认准 XL710 专用的 NVM 更新包，拿 i350 的包强刷会直接报容量或校验错误；二是如果 DDP 配置和驱动版本不匹配，接口可能起来了但收发包异常。

所以在 XL710 上执行任何操作前，先查当前固件和 DDP 状态：

ethtool -i ens3f0 dmesg | grep -i ddp

ethtool -i的fw-version在 XL710 上通常长这样：7.21 0x80005e08 1.2709.0，三段含义分别是 NVM 版本、ETrack ID、DDP 包版本。dmesg里能看到 DDP 加载成功或失败的信息。这些值记录下来，和升级后的输出做对比。

4.2 用 eeupdate64 改 XL710 的 MAC：NIC 编号怎么找

XL710 改 MAC 的命令和 i350 完全相同，但设备多的时候-nic编号容易错位。比如一张 XL710 双口卡，在 lspci 里占两个 PCI 地址，工具扫描后可能把两个口编成 1 和 2，也可能跨卡连续编。先用./eeupdate64 -all把编号全部列出来：

sudo ./eeupdate64 -all sudo ./eeupdate64 -nic 1 -mac 001B21C0FF01

-all输出里会带每个 NIC 的 PCI 地址，对照 lspci 的结果就能确定 1 号口是哪个物理插槽。确认无误后再改。XL710 的 MAC 写入也是冲 flash 永久区，改完同样用ethtool -P验证。

有一点要注意：XL710 在部分服务器上启用了 Intel 的“可管理以太网”功能（比如 AMT 或 SMBus 接管），这种情况下工具可能报device in use或写入失败。遇到这个问题，进 BIOS 把网卡的 manageability 功能关掉再操作，改完再开回来，不要强行绕过锁。

4.3 XL710 固件与 DDP 配置升级的常见做法

XL710 的固件升级推荐用配套的 NVM 更新包，通常驱动包解压后会有nvmupdate_xxx目录，里面除了 eeupdate64 工具还有烧录脚本和配置文件。常见做法是进到该目录直接执行工具让它自动识别固件：

sudo ./eeupdate64 -nic 1 -up

工具默认会在当前目录找匹配的固件文件，找不到再用-f显式指定。相比 i350，XL710 升级失败的后果更严重，因为它的 NVM 区还包含管理固件和 DDP 包头，刷一半断电可能连 PCIe 设备都枚举不出来。所以 XL710 烧录严格走“先验证固件包 hash → 物理终端执行 → 烧写完成提示后再重启”的流程。

DDP 配置本身一般不需要用 eeupdate64 烧，它通常由驱动在接口 up 时自动加载。如果确认 DDP 版本不匹配，正确做法是下载对应驱动版本里的 DDP 包，替换/lib/firmware/i40e/下的文件后重新加载驱动。不要在 DDP 加载正常时去动固件，那属于给运行中的业务网卡找风险。

5. 常见问题与排查：改 MAC 和烧固件时最容易翻车的六个场景

5.1 系统接口名变了：eth0 变 ens2f0 不是玄学

现象：改完 MAC 重启，原来配置好 IP 的 eth0 找不到了，系统里出现一个新的接口名，IP 地址也没了。

原因：传统发行版通过 udev 规则或/etc/sysconfig/network-scripts/ifcfg-eth0里的HWADDR字段把某个 MAC 绑定到固定接口名。固件里的 MAC 一改，系统觉得“这是一张新网卡”，于是按新规则重新命名。

解决：改 MAC 前先记下原来的接口名和 MAC。如果确认新 MAC 就是要用的，可以直接改 ifcfg 文件里的HWADDR，或者删掉旧的 udev 规则文件后重启。养成一个习惯：每次改完 MAC 顺手执行ip link show确认接口名，网络不通时第一时间查这里。

5.2 重启后 MAC 回滚：哪些算正常，哪些算没写进去

现象：改完当时ethtool -P显示新 MAC，重启后ip link看到的当前 MAC 又变回旧的。

原因：这里要分两种。第一种是正常现象——驱动加载时会用固件里的永久 MAC 初始化接口，但 NetworkManager 或 systemd 网络配置里如果写了旧的MACAddress=覆盖项，系统会在接口启动后用旧值覆盖。第二种才是真异常——固件没写进去，重启后 flash 里的值又还原。

解决：先用ethtool -P看永久 MAC，如果永久 MAC 是新值，说明固件没问题，去查网络管理服务的配置覆盖；如果永久 MAC 是旧值，说明修改没真正落盘，重新执行一次改 MAC 命令，烧录过程中注意工具是否输出verify failed之类的警告。

5.3 管理网口的 IP 丢失：ifcfg 里藏着旧地址

现象：改了 MAC 后，这台机器的远程管理 IP ping 不通，控制台登录一看，网卡没配 IP。

原因：多数服务器网卡的 IP 配置在/etc/sysconfig/network-scripts/ifcfg-*或 Netplan 文件里，里面如果写了旧的 MAC，系统就不会把这份配置绑定到新 MAC 上。

解决：动手前先导出网卡配置文件列表，记下哪个配置文件对应哪个接口。改完 MAC 后同步更新配置文件里的 MAC 字段再重启网络服务。这也是为什么批量操作一定要做“机器-接口-MAC-配置文件”四联表，不然 20 台机器改完，能有两台直接断网失联。

5.4 固件升级后性能异常：DDP 和 NVM 版本不配套

现象：XL710 升级完 NVM 固件，接口能起来，但吞吐上不去，或者跑万兆只能到两三兆的水平，dmesg 里报 DDP 相关错误。

原因：NVM 和 DDP 是分开加载的，只升了 NVM 没升 DDP，或者 DDP 包版本太老，驱动加载时不认。

解决：到 Intel 下载中心找配套的 DDP 包，版本号要和 NVM 匹配（工具输出里通常会写对应关系），把 DDP 文件放到/lib/firmware/i40e/后执行rmmod i40e && modprobe i40e，重新拉起接口验证。

5.5 ARM 平台和国产 Linux 上跑不起来

现象：在飞腾/鲲鹏服务器上执行./eeupdate64 -?，报cannot execute binary file或段错误。

原因：eeupdate64 长期只有 x86_64 版本，不认 ARM 指令集；部分国产 Linux 的 32 位兼容层也没装，动态链接失败。

解决：不要浪费时间做各种兼容层折腾，把网卡插到 x86 的机器上用工具改完再装回去。这个方案几分钟就能完成，少走一个晚上的弯路。真正需要频繁改 MAC 的维护团队，备一台 x86 测试机专门干这事，比每台机器都装环境省心得多。

5.6 烧录中途断了：网卡变砖的补救思路

现象：烧录过程中 SSH 断连、机房断电或有人误触重启，之后系统里lspci都看不到网卡了。

原因：flash 写入是连续操作，中断后固件区数据不完整，PCIe 配置空间里可能连设备 ID 都是错的，系统自然枚举不到。

解决：先用另一张网卡或板载网卡把机器拉起，把备份的 EEPROM 文件和固件包复制到本地，用编程器（常见有 CH341A 这类 SPI flash 编程器）把备份写回 flash 芯片。i350 的 flash 芯片在板卡正反面，拆下来之前先用记号笔标好方向和位号。这一步不能保证 100% 救回来，但有备份和正确烧录器，多数情况能恢复。这才是每张卡都留 EEPROM 快照的真正价值。

6. 验证与收尾：改完怎么确认真生效，以及值得养成的维护习惯

6.1 用 ethtool 和 ip link 确认 MAC 真的写进固件

每次操作完，用一组命令做最终确认，顺序不要乱：

ethtool -P ens2f0 ip link show ens2f0 | grep ether ethtool -i ens2f0

先看ethtool -P的永久 MAC，这是固件里的真实值；再看ip link的当前 MAC，两者一致才说明当前接口用的就是新固件地址。ethtool -i里的fw-version和driver字段用于确认驱动版本和固件版本匹配。如果永久 MAC 是新值但当前 MAC 是旧的，说明有软件层覆盖，去排查网络管理服务；如果两个都是旧值，说明 flash 写入没成功，重新执行修改命令。

6.2 固件版本与 DDP 状态的验证

对 i350 来说，升级固件后看ethtool -i的 fw 版本号是否变成目标版本即可。对 XL710 要额外看 DDP 状态：

ethtool -i ens3f0 dmesg | grep -i ddp

如果 dmesg 里出现DDP package loaded且没有 error，说明配置加载正常。还要顺手跑一次ethtool -S ens3f0看 rx/tx 的 error 计数是否为 0。这些命令可以组成一个验证脚本放到维护库，以后每改一台机器都跑一遍，输出存档。

6.3 维护表：把 MAC、固件和网卡名写在同一张表里

我现在每次批量维护前都会先建一张表，字段包括：机器序列号、网卡型号、PCI 地址、系统接口名、修改前永久 MAC、修改后永久 MAC、固件版本、操作日期、操作人。这张表平时不觉得有用，一到排查“哪台机器地址不对”“谁把固件刷错版本”时就是救命的数据。改 MAC 和烧固件这种操作，最贵的是排查成本，一张表能省掉大半。

这些年我踩过最深刻的坑，是有一次给一台线上机改 MAC，没等烧录命令输出完成就手动重启，结果网卡从系统里彻底消失。后来靠编程器把备份写回去才救回来。从那以后我给自己定了两条规矩：第一，没有永久 MAC 和 EEPROM 备份不操作；第二，烧录命令必须在物理终端或带外 console 里执行。这两条规矩看起来只是流程繁琐，但每一次都避免了大问题。希望这篇笔记也能帮你少走一次弯路。

本文还有配套的精品资源，点击获取