搞Linux这块网卡配置算是绕不开的基本功。但也是很多新手甚至老手容易栽跟头的地方——不是命令不会敲而是没搞明白不同发行版、不同工具链背后那套“逻辑”。同一个DHCP在CentOS里改个文件就行到了Ubuntu又得写netplanRHEL 9直接改NetworkManager的keyfile版本一换老经验直接作废。这篇文章不打算讲大而全的网络原理就聚焦在“Linux网卡配置”这一件事上把命名规则、配置工具、静态IP、双网卡策略路由、常见故障排查这些东西拆开揉碎。涉及的发行版以CentOS/RHEL、Ubuntu/Debian、openSUSE为主命令以iproute2、NetworkManager系为主。适合刚接手Linux服务器运维的兄弟也适合那些被“系统重启之后网卡配置丢失”这类问题折磨过的人。1. 网卡配置前必须搞懂的底层逻辑1.1 网卡命名规则为什么你的网卡叫ens33而不是eth0很多新手上来就直接照抄配置抄来抄去发现网卡名字对不上最后一脸懵。这事的根源在于Linux网卡命名策略的演变。早年间CentOS 6及更早网卡就叫eth0、eth1按照内核识别顺序依次编号。这个规则虽然简单但有个致命问题如果机器上插了多块PCI网卡内核加载驱动的顺序变了eth0和eth1的身份就可能会互换。服务器重启之后IP地址对错网卡网络直接瘫痪这在生产环境是出过不少事故的。从CentOS 7 / RHEL 7开始默认采用基于硬件位置的命名方案网卡名变成了enp0s3、ens33、enx000c29xxxxxxxx这类看起来不太友好、但“一锤定音”的名字。en 表示以太网Ethernetp0 表示总线位置PCI bus 0s3 表示插槽位置PCI slot 3xxxxxx 表示网卡的MAC地址这种命名方案的核心价值在于网卡的名字跟物理位置绑死了不管驱动加载顺序怎么变同一块网卡永远是同一个名字。服务器加装网卡、换硬盘、调整BIOS设置都不会影响已有配置的稳定性。如果你手上的机器网卡名特别长或者带MAC尾缀不用慌这是可预测命名规则下的正常现象。查看当前系统识别到的网卡直接跑ip addr show # 或者老一点的命令 ifconfig -a1.2 从网卡驱动到链路状态配置之前先确认物理层是通的网卡配置这件事表面上改的是IP地址但实际上涉及底层的驱动、固件和链路协商。很多人配置完发现“网卡没起来”第一反应是配置文件写错了其实往往是物理层都没通。查看网卡驱动和总线信息用ethtool是最直接的ethtool eth0 # 换成你的实际网卡名重点关注两个字段Speed当前协商速率如1000Mb/sDuplex双工模式全双工Full、半双工Half如果Speed显示的是100Mb/s而你明明是千兆网卡那基本可以断定网线、交换机端口或者网卡本身有问题。这时候改IP配置没有任何意义物理层就限制了速度。再看看链路状态ip link show eth0输出里有state UP表示网卡管理状态是激活的state DOWN就是被down掉了。还有一种情况是NO-CARRIER意思是网卡虽然没被手动关闭但物理上没检测到对端信号——要么网线没插要么对端没通电。这个信息在排查“为什么网卡配置好了但ping不通”时价值极高。注意管理状态UP/DOWN和链路协商状态LOWER_UP是两码事。ip link set eth0 up只能保证网卡本身在工作不代表网线那头有设备响应。排查顺序永远是先看物理层再看链路层最后才看IP层。2. 静态IP配置实操三种主流配置方式逐一拆解2.1 CentOS / RHEL 系ifcfg 文件与 NetworkManager 的协作CentOS 7以上都是NetworkManager在统一管理网络但它仍然兼容老的ifcfg配置文件。系统启动时NetworkManager会去读/etc/sysconfig/network-scripts/ifcfg-*下的文件把这些配置转换成自身的管理对象。以配置ens33这块网卡为例静态IP为192.168.1.100/24网关192.168.1.1DNS分别为223.5.5.5和114.114.114.114。编辑/etc/sysconfig/network-scripts/ifcfg-ens33TYPEEthernet BOOTPROTOnone DEFROUTEyes NAMEens33 DEVICEens33 ONBOOTyes IPADDR192.168.1.100 PREFIX24 GATEWAY192.168.1.1 DNS1223.5.5.5 DNS2114.114.114.114几个关键项说明一下BOOTPROTOnone表示不使用DHCP手动指定IP。有些教程写BOOTPROTOstatic在大部分版本里也能生效但更规范的写法是none。ONBOOTyes必须写否则重启网络服务后网卡不会自动启用。这是配置文件派最常见的坑。PREFIX24等价于子网掩码255.255.255.0。如果你习惯写NETMASK255.255.255.0也可以二选一即可。DEFROUTEyes让这块网卡把默认路由接管过来。如果机器有多块网卡DEFROUTE的取舍直接决定了默认路由走哪块卡。改完文件生效方式有两种# 方式一重启网络服务CentOS 7/RHEL 7 systemctl restart network # 方式二让NetworkManager重新加载配置RHEL 8/9 推荐 nmcli connection reload nmcli connection up ens33CentOS 8之后network服务被标记为弃用部分最小化安装甚至不带这个脚本所以建议尽早过渡到nmcli体系。2.2 Ubuntu / Debian 系netplan 的 YAML 缩进陷阱Ubuntu从18.04开始默认用netplan管理网络底层渲染器是NetworkManager或systemd-networkd。netplan的配置文件放在/etc/netplan/目录下通常以.yaml结尾比如/etc/netplan/01-network-manager-all.yaml。配置固定IP的典型写法如下network: version: 2 renderer: networkd ethernets: ens33: dhcp4: no addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 223.5.5.5 - 114.114.114.114netplan最让人头疼的就是YAML缩进。YAML规定用空格缩进不能用Tab缩进级别错了直接导致配置解析失败。而且同一个层级的key必须对齐多一个少一个空格都不一样。判断配置语法是否正确用netplan的dry-run模式验证sudo netplan try这个命令会把新配置临时应用如果在一定时间内没确认会自动回滚到之前的网络状态。对远程操作服务器的人来说是道保命符——至少不会因为配置错误把自己锁在门外。确认没问题后再正式应用sudo netplan apply2.3 RHEL 9 / 高版本系统的keyfile体系与nmcli快速配置RHEL 9和Fedora较新版本中NetworkManager把连接配置存储为keyfile格式放在/etc/NetworkManager/system-connections/目录下。文件名就是连接名比如ens33.nmconnection。这种格式长这样[connection] idens33 typeethernet interface-nameens33 [ipv4] address1192.168.1.100/24 gateway192.168.1.1 methodmanual [ipv6] addr-gen-modedefault methodauto手动编辑这种文件很容易出错所以效率更高的方式是用nmcli直接操作。命令行指定静态IP、网关和DNSnmcli con mod ens33 ipv4.method manual \ ipv4.addresses 192.168.1.100/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns 223.5.5.5 114.114.114.114 nmcli con up ens33如果只想临时设置IP重启失效用ip命令就行ip addr add 192.168.1.100/24 dev ens33 ip route add default via 192.168.1.1临时设置的IP在网卡重启或系统重启后会被清掉适合测试场景不适合生产环境。3. Multi-NIC与路由策略从单网卡进阶到多网卡协同管理3.1 为什么多块网卡会“互相打架”服务器上只配一块网卡一般没太多讲究但一旦配上双网卡、四网卡问题就开始出现了默认路由冲突、内网外网流量串线、SSH断开。核心原因在于Linux的路由表设计。系统只有一张主路由表多个网卡各自拥有IP和网关时默认路由只能有一条。假设服务器有ens33192.168.1.100外网网关192.168.1.1和ens3710.10.10.10内网网关10.10.10.1配置完两块网卡后你去看ip route show大概率只会看到一条default路由另一条边的默认路由被覆盖了。这会导致原本走内网网卡的流量全被扔到外网网卡上。要么内网不通要么外网回包异常。解决思路有两个层面一是调整路由metric给内网网卡一个更高的优先级让去特定内网网段的流量走内网卡二是使用策略路由根据源IP或目标IP段动态选择路由表。3.2 策略路由用ip rule和多个路由表实现精细分流对于多网卡环境推荐使用策略路由policy routing来彻底解决。所谓策略路由就是让Linux不只看目标地址还看源地址、入口设备等信息来决定走哪张路由表。以实际场景为例ens33是运维管理网卡192.168.1.100/24只允许内网网段访问ens37是业务网卡10.10.10.10/24需要访问外网。默认路由交给业务网卡同时保证从管理网卡进来的回包也从管理网卡出去。首先在/etc/iproute2/rt_tables里增加一张自定义路由表命名随意但别和已有冲突100 mgmt然后给mgmt表添加默认路由ip route add default via 192.168.1.1 dev ens33 table mgmt再添加策略规则让源地址为192.168.1.100的流量走mgmt表ip rule add from 192.168.1.100/32 table mgmt最后确保主路由表中默认路由指向业务网卡ip route replace default via 10.10.10.1 dev ens37这套逻辑做完之后生效的是运行内存中的配置。要让它重启后依然保留需要把route和rule命令写进rc.local、network脚本的post-up钩子或者用NetworkManager的dispatch脚本。生产环境下建议用dispatch脚本因为它在网卡启动事件触发后有顺序保证比rc.local更可靠。3.3 长期稳定的多网卡方案绑定/聚合如果多块网卡是为了提高带宽或做冗余策略路由并不是最优解——把两块物理网卡绑定成一个虚拟网卡才是更常见的做法。Linux bonding驱动支持多种模式模式名称用途mode1active-backup主备冗余同一时间只有一块网卡工作mode2balance-xor负载均衡基于MAC或IP的XOR哈希mode4802.3ad动态链路聚合需交换机支持LACPmode6balance-alb自适应负载均衡无需交换机支持以mode1主备模式为例在CentOS/RHEL上创建一个bond0nmcli con add type bond con-name bond0 ifname bond0 mode active-backup nmcli con add type bond-slave ifname ens33 master bond0 nmcli con add type bond-slave ifname ens37 master bond0 nmcli con mod bond0 ipv4.method manual ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 nmcli con up bond0主备模式下任意一块物理网卡故障bond0自动切换流量到另一块不需要人工干预。很多生产服务器的网卡冗余就是用这个方式实现的。4. 网卡故障排查与常见问题速查4.1 排查思路按TCP/IP层次逐层确认网卡出问题最忌讳的就是直接去改配置。我的习惯是按层次排查物理层、链路层、网络层、应用层。先看物理层和链路层ethtool eth0 ip link show eth0确认Speed和Link detected后再看IP层ip addr show eth0 ip route show然后才轮到ping和抓包。ping不通网关先确认目标地址在同一网段ping通网关但不通外网排查DNS和NAT外网能通但域名解析慢重点查resolv.conf和systemd-resolved的配置。4.2 高频问题TOP5现象与根因对照问题现象可能原因解决动作网卡配置了IP重启后丢失ONBOOTno 或 netplan未apply检查ifcfg中的ONBOOTnetplan执行apply有IP但ping不通网关网线物理链路不通ethtool看Speed/Link换网线多网卡下外网时通时断默认路由冲突两块卡抢流量用策略路由或调整metric统一默认路由归属SSH连不上但控制台能操作管理网卡IP与业务网卡冲突查看ARP表调整IP避免冲突CentOS克隆虚拟机后网卡起不来克隆导致MAC地址和ifcfg绑定冲突删除ifcfg中MAC绑定项重新配置4.3 抓包定位tcpdump帮你判断数据有没有发出去有时候配置文件看起来完全正常就是不通。这时候tcpdump会告诉你问题的真正位置。比如ping网关不通分别抓一下出向和入向报文tcpdump -i ens33 icmp -nn如果只有出向报文request没有入向报文reply说明对端根本没收到或没回应——问题在二三层之间。如果出向和入向都有但ping还是超时那问题可能出在路由回包上需要用ip route get来验证ip route get 192.168.1.1这个命令会明确告诉你从哪个网卡出发、走哪条路由、下一跳是谁。比追着排查半天效率高多了。5. 一条少有人提的配置细节sysctl与网卡卸载特性5.1 为什么网卡在大流量下会丢包ring buffer与offload网卡实测大流量下莫名丢包配置本身没问题驱动也正常这是很多运维觉得诡异的地方。其实问题经常出在网卡的ring buffer和offload特性上。查看当前的ring buffer大小ethtool -g eth0如果rx队列的当前值Current只有512甚至256大流量下很容易丢包。调大它ethtool -G eth0 rx 4096 tx 4096同理网卡的checkSUM offload如果开启状态有缺陷也会导致收到的包直接被丢弃。典型表现为抓包能看到报文但应用层收不到数据。这种问题在部分虚拟化平台上尤其常见。临时关闭校验和卸载ethtool -K eth0 rx-checksumming off这些调整同样是临时生效生产环境要把ethtool命令做成开机自启脚本或者写入systemd service确保重启后配置还在。网上有些老运维直接把ethtool写进rc.local也能用但systemd的方式更现代化也更好管理。5.2 小心NetworkManager的“过度服务”行为最后想提醒一点NetworkManager在部分场景下会“好心办坏事”。比如它默认会在网卡连接激活时自动尝试DHCP哪怕你配置文件已经写死了静态IP某些版本的NM可能因为缓存问题覆盖你的手动配置。遇到“我明明改成了static重启后又变回DHCP”的情况可以试试清一下NM的连接缓存systemctl stop NetworkManager rm -rf /etc/NetworkManager/system-connections/* systemctl start NetworkManager然后重新用nmcli创建连接。当然这会清掉所有已有连接配置操作之前先备份。手动管理网络的老手如果被NM的自动行为搞烦了也可以直接禁用NM回归纯配置文件派systemctl disable NetworkManager systemctl enable network但这个方案在RHEL 9上已经不推荐了网络脚本服务已经移除。趋势摆在那里理解NetworkManager的配置逻辑比绕开它更实际。我个人在实际操作中的体会是网卡配置这件事最核心的不是记住各种文件名和命令而是理解系统里到底是谁在管理网络、它在什么时机读取配置、什么行为会导致配置被覆盖。把这些逻辑搞清楚换个发行版、换套命令行工具也只需要半天就能适应。Linux这种系统表面上是命令的堆积深一层是机制的串联。建议你手头备一台虚拟机把网卡配置从头到尾折腾几遍特别是策略路由那部分多网卡环境下实际跑一遍比看多少教程都有用。
Linux网卡配置全解析：命名规则、静态IP与策略路由
搞Linux这块网卡配置算是绕不开的基本功。但也是很多新手甚至老手容易栽跟头的地方——不是命令不会敲而是没搞明白不同发行版、不同工具链背后那套“逻辑”。同一个DHCP在CentOS里改个文件就行到了Ubuntu又得写netplanRHEL 9直接改NetworkManager的keyfile版本一换老经验直接作废。这篇文章不打算讲大而全的网络原理就聚焦在“Linux网卡配置”这一件事上把命名规则、配置工具、静态IP、双网卡策略路由、常见故障排查这些东西拆开揉碎。涉及的发行版以CentOS/RHEL、Ubuntu/Debian、openSUSE为主命令以iproute2、NetworkManager系为主。适合刚接手Linux服务器运维的兄弟也适合那些被“系统重启之后网卡配置丢失”这类问题折磨过的人。1. 网卡配置前必须搞懂的底层逻辑1.1 网卡命名规则为什么你的网卡叫ens33而不是eth0很多新手上来就直接照抄配置抄来抄去发现网卡名字对不上最后一脸懵。这事的根源在于Linux网卡命名策略的演变。早年间CentOS 6及更早网卡就叫eth0、eth1按照内核识别顺序依次编号。这个规则虽然简单但有个致命问题如果机器上插了多块PCI网卡内核加载驱动的顺序变了eth0和eth1的身份就可能会互换。服务器重启之后IP地址对错网卡网络直接瘫痪这在生产环境是出过不少事故的。从CentOS 7 / RHEL 7开始默认采用基于硬件位置的命名方案网卡名变成了enp0s3、ens33、enx000c29xxxxxxxx这类看起来不太友好、但“一锤定音”的名字。en 表示以太网Ethernetp0 表示总线位置PCI bus 0s3 表示插槽位置PCI slot 3xxxxxx 表示网卡的MAC地址这种命名方案的核心价值在于网卡的名字跟物理位置绑死了不管驱动加载顺序怎么变同一块网卡永远是同一个名字。服务器加装网卡、换硬盘、调整BIOS设置都不会影响已有配置的稳定性。如果你手上的机器网卡名特别长或者带MAC尾缀不用慌这是可预测命名规则下的正常现象。查看当前系统识别到的网卡直接跑ip addr show # 或者老一点的命令 ifconfig -a1.2 从网卡驱动到链路状态配置之前先确认物理层是通的网卡配置这件事表面上改的是IP地址但实际上涉及底层的驱动、固件和链路协商。很多人配置完发现“网卡没起来”第一反应是配置文件写错了其实往往是物理层都没通。查看网卡驱动和总线信息用ethtool是最直接的ethtool eth0 # 换成你的实际网卡名重点关注两个字段Speed当前协商速率如1000Mb/sDuplex双工模式全双工Full、半双工Half如果Speed显示的是100Mb/s而你明明是千兆网卡那基本可以断定网线、交换机端口或者网卡本身有问题。这时候改IP配置没有任何意义物理层就限制了速度。再看看链路状态ip link show eth0输出里有state UP表示网卡管理状态是激活的state DOWN就是被down掉了。还有一种情况是NO-CARRIER意思是网卡虽然没被手动关闭但物理上没检测到对端信号——要么网线没插要么对端没通电。这个信息在排查“为什么网卡配置好了但ping不通”时价值极高。注意管理状态UP/DOWN和链路协商状态LOWER_UP是两码事。ip link set eth0 up只能保证网卡本身在工作不代表网线那头有设备响应。排查顺序永远是先看物理层再看链路层最后才看IP层。2. 静态IP配置实操三种主流配置方式逐一拆解2.1 CentOS / RHEL 系ifcfg 文件与 NetworkManager 的协作CentOS 7以上都是NetworkManager在统一管理网络但它仍然兼容老的ifcfg配置文件。系统启动时NetworkManager会去读/etc/sysconfig/network-scripts/ifcfg-*下的文件把这些配置转换成自身的管理对象。以配置ens33这块网卡为例静态IP为192.168.1.100/24网关192.168.1.1DNS分别为223.5.5.5和114.114.114.114。编辑/etc/sysconfig/network-scripts/ifcfg-ens33TYPEEthernet BOOTPROTOnone DEFROUTEyes NAMEens33 DEVICEens33 ONBOOTyes IPADDR192.168.1.100 PREFIX24 GATEWAY192.168.1.1 DNS1223.5.5.5 DNS2114.114.114.114几个关键项说明一下BOOTPROTOnone表示不使用DHCP手动指定IP。有些教程写BOOTPROTOstatic在大部分版本里也能生效但更规范的写法是none。ONBOOTyes必须写否则重启网络服务后网卡不会自动启用。这是配置文件派最常见的坑。PREFIX24等价于子网掩码255.255.255.0。如果你习惯写NETMASK255.255.255.0也可以二选一即可。DEFROUTEyes让这块网卡把默认路由接管过来。如果机器有多块网卡DEFROUTE的取舍直接决定了默认路由走哪块卡。改完文件生效方式有两种# 方式一重启网络服务CentOS 7/RHEL 7 systemctl restart network # 方式二让NetworkManager重新加载配置RHEL 8/9 推荐 nmcli connection reload nmcli connection up ens33CentOS 8之后network服务被标记为弃用部分最小化安装甚至不带这个脚本所以建议尽早过渡到nmcli体系。2.2 Ubuntu / Debian 系netplan 的 YAML 缩进陷阱Ubuntu从18.04开始默认用netplan管理网络底层渲染器是NetworkManager或systemd-networkd。netplan的配置文件放在/etc/netplan/目录下通常以.yaml结尾比如/etc/netplan/01-network-manager-all.yaml。配置固定IP的典型写法如下network: version: 2 renderer: networkd ethernets: ens33: dhcp4: no addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 223.5.5.5 - 114.114.114.114netplan最让人头疼的就是YAML缩进。YAML规定用空格缩进不能用Tab缩进级别错了直接导致配置解析失败。而且同一个层级的key必须对齐多一个少一个空格都不一样。判断配置语法是否正确用netplan的dry-run模式验证sudo netplan try这个命令会把新配置临时应用如果在一定时间内没确认会自动回滚到之前的网络状态。对远程操作服务器的人来说是道保命符——至少不会因为配置错误把自己锁在门外。确认没问题后再正式应用sudo netplan apply2.3 RHEL 9 / 高版本系统的keyfile体系与nmcli快速配置RHEL 9和Fedora较新版本中NetworkManager把连接配置存储为keyfile格式放在/etc/NetworkManager/system-connections/目录下。文件名就是连接名比如ens33.nmconnection。这种格式长这样[connection] idens33 typeethernet interface-nameens33 [ipv4] address1192.168.1.100/24 gateway192.168.1.1 methodmanual [ipv6] addr-gen-modedefault methodauto手动编辑这种文件很容易出错所以效率更高的方式是用nmcli直接操作。命令行指定静态IP、网关和DNSnmcli con mod ens33 ipv4.method manual \ ipv4.addresses 192.168.1.100/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns 223.5.5.5 114.114.114.114 nmcli con up ens33如果只想临时设置IP重启失效用ip命令就行ip addr add 192.168.1.100/24 dev ens33 ip route add default via 192.168.1.1临时设置的IP在网卡重启或系统重启后会被清掉适合测试场景不适合生产环境。3. Multi-NIC与路由策略从单网卡进阶到多网卡协同管理3.1 为什么多块网卡会“互相打架”服务器上只配一块网卡一般没太多讲究但一旦配上双网卡、四网卡问题就开始出现了默认路由冲突、内网外网流量串线、SSH断开。核心原因在于Linux的路由表设计。系统只有一张主路由表多个网卡各自拥有IP和网关时默认路由只能有一条。假设服务器有ens33192.168.1.100外网网关192.168.1.1和ens3710.10.10.10内网网关10.10.10.1配置完两块网卡后你去看ip route show大概率只会看到一条default路由另一条边的默认路由被覆盖了。这会导致原本走内网网卡的流量全被扔到外网网卡上。要么内网不通要么外网回包异常。解决思路有两个层面一是调整路由metric给内网网卡一个更高的优先级让去特定内网网段的流量走内网卡二是使用策略路由根据源IP或目标IP段动态选择路由表。3.2 策略路由用ip rule和多个路由表实现精细分流对于多网卡环境推荐使用策略路由policy routing来彻底解决。所谓策略路由就是让Linux不只看目标地址还看源地址、入口设备等信息来决定走哪张路由表。以实际场景为例ens33是运维管理网卡192.168.1.100/24只允许内网网段访问ens37是业务网卡10.10.10.10/24需要访问外网。默认路由交给业务网卡同时保证从管理网卡进来的回包也从管理网卡出去。首先在/etc/iproute2/rt_tables里增加一张自定义路由表命名随意但别和已有冲突100 mgmt然后给mgmt表添加默认路由ip route add default via 192.168.1.1 dev ens33 table mgmt再添加策略规则让源地址为192.168.1.100的流量走mgmt表ip rule add from 192.168.1.100/32 table mgmt最后确保主路由表中默认路由指向业务网卡ip route replace default via 10.10.10.1 dev ens37这套逻辑做完之后生效的是运行内存中的配置。要让它重启后依然保留需要把route和rule命令写进rc.local、network脚本的post-up钩子或者用NetworkManager的dispatch脚本。生产环境下建议用dispatch脚本因为它在网卡启动事件触发后有顺序保证比rc.local更可靠。3.3 长期稳定的多网卡方案绑定/聚合如果多块网卡是为了提高带宽或做冗余策略路由并不是最优解——把两块物理网卡绑定成一个虚拟网卡才是更常见的做法。Linux bonding驱动支持多种模式模式名称用途mode1active-backup主备冗余同一时间只有一块网卡工作mode2balance-xor负载均衡基于MAC或IP的XOR哈希mode4802.3ad动态链路聚合需交换机支持LACPmode6balance-alb自适应负载均衡无需交换机支持以mode1主备模式为例在CentOS/RHEL上创建一个bond0nmcli con add type bond con-name bond0 ifname bond0 mode active-backup nmcli con add type bond-slave ifname ens33 master bond0 nmcli con add type bond-slave ifname ens37 master bond0 nmcli con mod bond0 ipv4.method manual ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 nmcli con up bond0主备模式下任意一块物理网卡故障bond0自动切换流量到另一块不需要人工干预。很多生产服务器的网卡冗余就是用这个方式实现的。4. 网卡故障排查与常见问题速查4.1 排查思路按TCP/IP层次逐层确认网卡出问题最忌讳的就是直接去改配置。我的习惯是按层次排查物理层、链路层、网络层、应用层。先看物理层和链路层ethtool eth0 ip link show eth0确认Speed和Link detected后再看IP层ip addr show eth0 ip route show然后才轮到ping和抓包。ping不通网关先确认目标地址在同一网段ping通网关但不通外网排查DNS和NAT外网能通但域名解析慢重点查resolv.conf和systemd-resolved的配置。4.2 高频问题TOP5现象与根因对照问题现象可能原因解决动作网卡配置了IP重启后丢失ONBOOTno 或 netplan未apply检查ifcfg中的ONBOOTnetplan执行apply有IP但ping不通网关网线物理链路不通ethtool看Speed/Link换网线多网卡下外网时通时断默认路由冲突两块卡抢流量用策略路由或调整metric统一默认路由归属SSH连不上但控制台能操作管理网卡IP与业务网卡冲突查看ARP表调整IP避免冲突CentOS克隆虚拟机后网卡起不来克隆导致MAC地址和ifcfg绑定冲突删除ifcfg中MAC绑定项重新配置4.3 抓包定位tcpdump帮你判断数据有没有发出去有时候配置文件看起来完全正常就是不通。这时候tcpdump会告诉你问题的真正位置。比如ping网关不通分别抓一下出向和入向报文tcpdump -i ens33 icmp -nn如果只有出向报文request没有入向报文reply说明对端根本没收到或没回应——问题在二三层之间。如果出向和入向都有但ping还是超时那问题可能出在路由回包上需要用ip route get来验证ip route get 192.168.1.1这个命令会明确告诉你从哪个网卡出发、走哪条路由、下一跳是谁。比追着排查半天效率高多了。5. 一条少有人提的配置细节sysctl与网卡卸载特性5.1 为什么网卡在大流量下会丢包ring buffer与offload网卡实测大流量下莫名丢包配置本身没问题驱动也正常这是很多运维觉得诡异的地方。其实问题经常出在网卡的ring buffer和offload特性上。查看当前的ring buffer大小ethtool -g eth0如果rx队列的当前值Current只有512甚至256大流量下很容易丢包。调大它ethtool -G eth0 rx 4096 tx 4096同理网卡的checkSUM offload如果开启状态有缺陷也会导致收到的包直接被丢弃。典型表现为抓包能看到报文但应用层收不到数据。这种问题在部分虚拟化平台上尤其常见。临时关闭校验和卸载ethtool -K eth0 rx-checksumming off这些调整同样是临时生效生产环境要把ethtool命令做成开机自启脚本或者写入systemd service确保重启后配置还在。网上有些老运维直接把ethtool写进rc.local也能用但systemd的方式更现代化也更好管理。5.2 小心NetworkManager的“过度服务”行为最后想提醒一点NetworkManager在部分场景下会“好心办坏事”。比如它默认会在网卡连接激活时自动尝试DHCP哪怕你配置文件已经写死了静态IP某些版本的NM可能因为缓存问题覆盖你的手动配置。遇到“我明明改成了static重启后又变回DHCP”的情况可以试试清一下NM的连接缓存systemctl stop NetworkManager rm -rf /etc/NetworkManager/system-connections/* systemctl start NetworkManager然后重新用nmcli创建连接。当然这会清掉所有已有连接配置操作之前先备份。手动管理网络的老手如果被NM的自动行为搞烦了也可以直接禁用NM回归纯配置文件派systemctl disable NetworkManager systemctl enable network但这个方案在RHEL 9上已经不推荐了网络脚本服务已经移除。趋势摆在那里理解NetworkManager的配置逻辑比绕开它更实际。我个人在实际操作中的体会是网卡配置这件事最核心的不是记住各种文件名和命令而是理解系统里到底是谁在管理网络、它在什么时机读取配置、什么行为会导致配置被覆盖。把这些逻辑搞清楚换个发行版、换套命令行工具也只需要半天就能适应。Linux这种系统表面上是命令的堆积深一层是机制的串联。建议你手头备一台虚拟机把网卡配置从头到尾折腾几遍特别是策略路由那部分多网卡环境下实际跑一遍比看多少教程都有用。
