13｜网络配置

给一台机器配了 IP，用 ip 命令改完能通了，重启后却丢了——临时配置只改内存状态，不写盘。要持久化得写配置文件，但配置文件在哪、格式怎样，取决于发行版：RHEL 系用 NetworkManager 或老的 ifcfg，Ubuntu 18.04+ 用 netplan。同一套需求在不同发行版写法完全不同。

本篇先讲查看和临时配置的核心工具 ip 命令，再讲 RHEL 系和 Ubuntu 各自的持久化方式，最后讲远程改网络的保命流程和多网卡路由。

一、ip 命令:查看与临时配置

ip 命令是查看和配置网络的主力工具(取代了老的 ifconfig、route、arp)。它按 OSI 层次组织子命令,从三个视角看网络:

bash

ip link            # 链路层:网卡 UP/DOWN 状态、MAC 地址
ip addr            # 网络层:网卡上绑了哪些 IP、掩码多少
ip route           # 路由层:流量走哪个网卡、下一跳是谁
ip neigh           # 邻居层:ARP 表
ip -s link         # 加 -s 看统计信息:每个网卡的收发包数、错误数、丢包数

ifconfig 已不推荐使用

老脚本和文档里仍可见 ifconfig 和 route,这些工具来自 net-tools 包,在 RHEL 7+、Ubuntu 18.04+ 中默认未安装。即使手工装上,某些行为也已经不准:

一张网卡绑多个 IP 时,ifconfig 只显示主 IP 别名,ip addr 显示全部
不支持现代特性(策略路由、VRF、IPv6 邻居发现)

生产脚本和排查习惯统一用 ip 系列命令。

临时给网卡加 IP / 改路由

ip 命令改的是内核当前的运行时状态,不写入任何配置文件。重启网络服务或机器后丢失。临时配置仅适合抢修、验证、调试,正式环境必须做持久化。

bash

# 给 eth0 加一个 IP
ip addr add 192.168.1.10/24 dev eth0
ip link set eth0 up           # 把网卡 up 起来(如果还是 down 状态)

# 删 IP
ip addr del 192.168.1.10/24 dev eth0

# 加默认路由(网关)
ip route add default via 192.168.1.1

# 加针对特定网段的静态路由
ip route add 10.10.0.0/16 via 192.168.1.254 dev eth0

# 删路由
ip route del 10.10.0.0/16

静态路由的下一跳必须是本机能直接到达的地址(在同一二层网络内,即本机与下一跳之间不经过路由)。填一个本机网段外的 IP,内核会报 Nexthop has invalid gateway 拒绝添加。

ip route get:验证流量实际走向

多网卡机器排查"流量到底从哪个网卡出去",ip route get 比通读完整路由表快得多——直接告诉内核"如果发往这个 IP,你会走哪条路":

bash

$ ip route get 10.10.1.20
10.10.1.20 via 192.168.1.254 dev eth0 src 192.168.1.10 uid 1000
    cache

输出包含三个关键字段:走哪个网卡(dev eth0)、下一跳(via 192.168.1.254)、源 IP(src 192.168.1.10)。排查"我有内外网两张网卡,业务流量为什么走错"时,直接 ip route get 目标 IP,一行结果就能定位。

看网卡状态与统计

bash

ip -s link show eth0       # 看 eth0 的收发包统计、错误数、丢包数
ip -br addr                # -br 紧凑格式,适合一次扫所有网卡

ip -s link 的关键字段:

$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
    link/ether 52:54:00:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped overrun mcast
        123456    1234         0      0       0     5
    TX:  bytes  packets  errors  dropped carrier collsns
        654321    4321         0      0       0     0

RX/TX errors 持续增长 = 物理层有问题(线缆、网卡、对端接口);dropped 增长 = 内核缓冲区溢出或被防火墙丢弃。监控里要把这些指标采集起来,异常增长提前告警,比业务报错再排查早得多。

二、RHEL 系持久化:ifcfg 与 NetworkManager

RHEL 7 起,系统层面有两套并行的网络管理:传统的 ifcfg 文件配合 network 服务,新式的 NetworkManager 配合 nmcli。RHEL 8 起 network 服务被废弃,NetworkManager 成为默认。

工具	配置文件位置	状态
`network` 服务(传统)	`/etc/sysconfig/network-scripts/ifcfg-<网卡>`	RHEL 7 默认;RHEL 8+ 已废弃
NetworkManager	`/etc/NetworkManager/system-connections/<名称>.nmconnection` 或仍读 ifcfg	RHEL 7+ 可用,RHEL 8+ 默认

看清当前到底是谁在管网络

执行任何修改前,先确认本机网络由哪个工具管理——同时启用两套会互相覆盖:

bash

systemctl status NetworkManager     # 是否 active
systemctl status network 2>/dev/null  # RHEL 7 上看;RHEL 8+ 不存在该服务

# 看具体设备由谁管
nmcli device status
# DEVICE  TYPE      STATE      CONNECTION
# eth0    ethernet  connected  eth0
# eth1    ethernet  unmanaged  --        ← unmanaged 表示 NM 不管这块网卡

unmanaged 状态的网卡不会被 NetworkManager 操作,通常是因为 ifcfg 文件里写了 NM_CONTROLLED=no,或者 /etc/NetworkManager/conf.d/ 下有规则把该设备排除。这种网卡只能通过传统 ifcfg + ifup/ifdown 操作。

ifcfg 文件示例

ini

# /etc/sysconfig/network-scripts/ifcfg-eth0
TYPE=Ethernet
BOOTPROTO=none                  # none/static=静态IP,dhcp=动态获取
NAME=eth0
DEVICE=eth0
ONBOOT=yes                      # 开机自动启用,漏写则网卡不会自启
IPADDR=192.168.1.10
PREFIX=24                       # 等价于掩码 255.255.255.0(不要同时写 NETMASK)
GATEWAY=192.168.1.1
DNS1=223.5.5.5
DNS2=8.8.8.8
NM_CONTROLLED=yes               # 是否交给 NetworkManager 管理

修改后让配置生效:

bash

# RHEL 7 + 仅 network 服务
systemctl restart network

# RHEL 7/8/9 + NetworkManager
nmcli connection reload         # 让 NM 重新读 ifcfg 文件
nmcli connection up eth0        # 应用变更

nmcli 操作

NetworkManager 的核心概念是设备(Device)与连接(Connection)分离——一个设备(物理网卡)可以保存多套连接配置,通过 up/down 在不同配置之间切换。这在双网络环境(家用/办公、有线/Wi-Fi)中很有用,服务器场景一般一个设备对应一个连接。

bash

nmcli device status                  # 查看所有网卡的设备状态
nmcli connection show                # 查看所有连接配置
nmcli connection show eth0           # 查看 eth0 连接的详细参数

# 改静态地址(把整套参数一次性指定)
nmcli connection modify eth0 \
    ipv4.method manual \
    ipv4.addresses 192.168.1.10/24 \
    ipv4.gateway 192.168.1.1 \
    ipv4.dns "223.5.5.5 8.8.8.8" \
    connection.autoconnect yes
nmcli connection up eth0

# 改成 DHCP
nmcli connection modify eth0 ipv4.method auto
nmcli connection up eth0

# 添加额外 IP(不替换主 IP)
nmcli connection modify eth0 +ipv4.addresses 192.168.1.20/24

NetworkManager 接管后改 ifcfg 不生效的陷阱

NetworkManager 默认会把 ifcfg 文件的内容加载到内存,后续以内存中的连接配置为准。直接 vim 改 ifcfg 文件后不通知 NM,改动不会立即生效,甚至下次 nmcli connection up 会被 NM 用内存里的旧配置反向覆盖回 ifcfg 文件。

正确的流程:

bash

# 方式 1:改完 ifcfg 后让 NM 重读
vim /etc/sysconfig/network-scripts/ifcfg-eth0
nmcli connection reload                # 让 NM 重新加载 ifcfg
nmcli connection up eth0

# 方式 2(推荐):直接用 nmcli 改,不动 ifcfg 文件
nmcli connection modify eth0 ipv4.addresses 192.168.1.10/24
nmcli connection up eth0

RHEL 8+ 上,nmcli 是首选——避免文件改动与 NM 内存状态不一致。

三、Ubuntu netplan

Ubuntu 17.10+ 引入 netplan 统一配置接口,YAML 格式,文件位于 /etc/netplan/:

bash

$ ls /etc/netplan/
00-installer-config.yaml

netplan 不是网络管理工具本身,而是一个配置前端——它把 YAML 配置渲染为具体后端(NetworkManager 或 systemd-networkd)的配置。renderer 字段决定使用哪个后端:

yaml

network:
  version: 2
  renderer: networkd       # 或 NetworkManager
  ethernets:
    ens33:
      dhcp4: false
      addresses:
        - 192.168.1.10/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 223.5.5.5
          - 8.8.8.8

关键字段

字段	含义
`version`	netplan 配置格式版本,目前固定写 2
`renderer`	后端,服务器默认 `networkd`,桌面默认 `NetworkManager`
`dhcp4` / `dhcp6`	IPv4/IPv6 是否启用 DHCP
`addresses`	静态 IP 列表(可配多个)
`routes`	静态路由,`to: default` 即默认路由
`nameservers`	DNS 服务器列表
`mtu`	网卡 MTU,需要与上游交换机协商一致
`optional`	`true` 时,该网卡未配置成功不阻塞启动

应用配置:try 与 apply 的关键区别

netplan 提供两种应用配置的方式:

bash

netplan try         # 试应用,默认 120 秒内未确认则自动回滚
netplan apply       # 直接应用,不可回滚

远程改 Ubuntu 网络配置必须用 netplan try,不能用 apply。netplan try 应用新配置后会进入等待状态,要求用户在终端按回车确认:

Do you want to keep these settings?

Press ENTER before the timeout to accept the new configuration

Changes will revert in 113 seconds

如果新配置导致 SSH 断开,用户无法按回车,120 秒后 netplan 自动回滚到原配置——SSH 会自动恢复。apply 没有这个保护机制,一旦把自己的 SSH 路径配错,就只能去控制台救援。

netplan 配置文件的合并顺序

/etc/netplan/ 下可以有多个 YAML 文件,netplan 按文件名字典序读取,后读的覆盖先读的。常见的实践是给文件加数字前缀:

00-installer-config.yaml    # 安装时生成的默认配置
50-custom.yaml              # 自定义配置,覆盖默认值
99-emergency.yaml           # 应急配置,优先级最高

修改前先复制一份原配置作为应急备份:

bash

cp /etc/netplan/00-installer-config.yaml /root/netplan-backup-$(date +%Y%m%d).yaml

四、远程改网络的保命流程

远程通过 SSH 修改网络配置是高风险操作——配置错误会立即断开 SSH 连接,且新配置仍然生效,导致无法重新登录。失误的代价是去机房接 KVM 或调用云控制台 VNC,响应时间通常以小时计。

下面是一套适用于远程改网络的标准防护流程,在任何环境(物理机、虚拟机、云主机)都建议执行。

第 1 步:开 tmux 保持会话

bash

tmux new -s netcfg

tmux 会话在 SSH 断开后继续在后台运行,重新登录后用 tmux attach -t netcfg 重新接入会话。如果新网络配置导致 SSH 断开,但本机会话本身没断,会话内的恢复脚本会继续执行。

第 2 步:确认应急登录通道可用

在改配置之前,验证不依赖网络的应急通道可用:

物理机:确认 IPMI/iLO/iDRAC 控制台可登录,记录控制台 URL 和密码
虚拟机:确认 vCenter/Hyper-V 控制台可访问
云主机:在浏览器里打开云厂商控制台的 VNC,确认能看到登录界面

不要等到 SSH 断了再去找应急通道——这时候时间压力大、容易找错入口。

第 3 步:准备自动回退脚本

关键防护手段:用 at 或后台 sleep 定时执行恢复脚本,如果在指定时间内确认修改成功,就取消这个恢复任务;否则它会自动把网络恢复到原状态:

bash

# 备份当前配置
cp /etc/netplan/00-installer-config.yaml /tmp/netplan-backup.yaml

# 准备 10 分钟后自动恢复的任务
echo "cp /tmp/netplan-backup.yaml /etc/netplan/00-installer-config.yaml && netplan apply" | at now + 10 minutes
# atq 看到任务编号,例如 5

# 改配置 + 应用
vim /etc/netplan/00-installer-config.yaml
netplan apply

# 验证新配置工作正常(SSH 重新登录、ping 网关、ping 业务地址)
# 验证通过后,取消自动恢复任务
atrm 5

10 分钟内不取消,系统会自动把网络恢复为修改前的配置。即使 SSH 完全断开、且应急通道也无法访问,只要等够 10 分钟,网络会自动回到可用状态。

简化版本用 nohup + sleep:

bash

# 5 分钟后无条件恢复(除非这个进程被 kill)
nohup bash -c "sleep 300 && cp /tmp/netplan-backup.yaml /etc/netplan/ && netplan apply" &
ROLLBACK_PID=$!

# 改配置
vim /etc/netplan/00-installer-config.yaml
netplan apply

# 验证 OK 后取消回滚
kill $ROLLBACK_PID

第 4 步:Ubuntu 用 netplan try,RHEL 用 nmcli + 短超时

Ubuntu:直接用 netplan try 替代 netplan apply(见第三节)。

RHEL 上 nmcli connection up 没有内置超时回滚,因此第 3 步的 at 自动恢复任务必须做。或者用 nmcli 的临时连接特性,改完先在新连接上确认 OK,再持久化:

bash

# 临时建立一个新连接进行测试
nmcli connection add type ethernet ifname eth0 con-name eth0-test \
    ipv4.method manual ipv4.addresses 192.168.1.20/24 ipv4.gateway 192.168.1.1
nmcli connection up eth0-test

# 测试 OK 后,把它持久化为开机自启
nmcli connection modify eth0-test connection.autoconnect yes

# 测试不 OK,直接删除
nmcli connection delete eth0-test

五、DNS 客户端配置

/etc/resolv.conf 是 DNS 解析器的配置文件:

nameserver 192.168.1.1
nameserver 8.8.8.8
search example.com
options timeout:2 attempts:2

字段含义:

字段	含义
`nameserver`	DNS 服务器,可多行,按顺序尝试
`search`	短域名自动补全后缀,例如查 `web` 自动尝试 `web.example.com`
`options timeout:N`	单次查询超时(秒),默认 5
`options attempts:N`	重试次数,默认 2

resolv.conf 通常不能手动编辑

现代发行版的 /etc/resolv.conf 由网络管理工具自动生成——手动改完可能在网络重载、重启后被覆盖。具体由谁生成,看是否被符号链接接管:

bash

ls -l /etc/resolv.conf
# 如果是普通文件:可以手动改,但要确认没有工具会覆盖它
# 如果是 -> /run/systemd/resolve/stub-resolv.conf:由 systemd-resolved 管理
# 如果是 -> /run/NetworkManager/resolv.conf:由 NetworkManager 管理
# 如果是 -> /run/resolvconf/resolv.conf:由 resolvconf 管理

正确做法是改对应工具的配置:

bash

# NetworkManager 管理时:改连接配置
nmcli connection modify eth0 ipv4.dns "223.5.5.5 8.8.8.8"
nmcli connection up eth0

# netplan 管理时:改 YAML 的 nameservers 字段
vim /etc/netplan/00-installer-config.yaml

# systemd-resolved 管理时
resolvectl dns eth0 223.5.5.5 8.8.8.8
# 或改 /etc/systemd/resolved.conf

# 如果就是想手动 hold 住 /etc/resolv.conf 不被覆盖
chattr +i /etc/resolv.conf       # 加 immutable 属性
# 注意:其他工具改不了它会报错,记得自己知道为什么

调整解析超时:服务的"快失败"vs"慢成功"

options timeout 和 attempts 是高负载场景的关键参数。默认 timeout=5 attempts=2 意味着:如果第一个 DNS 服务器无响应,等 5 秒超时、再重试 2 次,然后才切换到第二个 nameserver——单次解析最坏情况下要 30 秒(5s × 2 attempts × 3 nameservers)。

对延迟敏感的服务(HTTP 网关、消息中间件)应当显式调短:

options timeout:2 attempts:1 rotate

rotate 让多个 nameserver 轮询使用,而不是固定先用第一个——避免第一个 DNS 出故障时所有解析都先等它超时。

六、多网卡的路由控制

服务器经常同时配置多块网卡,例如一块连内网(管理 + 监控)、一块连业务网。这种环境下流量到底从哪块网卡出去,完全取决于路由表的匹配规则。

默认路由只能有一条生效

bash

$ ip route
default via 192.168.1.1 dev eth0 metric 100
default via 10.0.0.1 dev eth1 metric 200
192.168.1.0/24 dev eth0 ...
10.0.0.0/24 dev eth1 ...

两条 default 路由共存时,内核按 metric 值选择最优,metric 越小优先级越高。上面的配置中所有未匹配直连网段的流量都走 metric=100 的 eth0。eth1 的 default 仅在 eth0 down 时才能生效。

修改 metric:

bash

# 临时
ip route del default via 192.168.1.1
ip route add default via 192.168.1.1 dev eth0 metric 100

# 持久化(netplan)
network:
  version: 2
  ethernets:
    eth0:
      routes:
        - to: default
          via: 192.168.1.1
          metric: 100

非对称路由问题

多网卡机器最容易踩的陷阱:请求从 eth1 进来,但回包根据默认路由从 eth0 出去——来回路径不一致,反向数据包可能被防火墙、SNAT、状态防火墙(stateful firewall)拦截,业务表现为"对方收不到响应"。

判定:从客户端 ping 进来,在服务器上抓包看流向:

bash

# 假设客户端 IP 10.0.0.5,从 10.0.0.0/24 网段进来
$ tcpdump -i eth1 host 10.0.0.5 -nn
10:30:01.123 IP 10.0.0.5.34567 > 192.168.1.10.80: Flags [S], ...   ← 进来的 SYN
# 但在 eth0 上能看到回包,eth1 上看不到回包

$ ip route get 10.0.0.5
10.0.0.5 via 192.168.1.1 dev eth0 src 192.168.1.10   ← 回包走 eth0,跟 SYN 来的网卡不同

处理方式有两种:

方式 A:静态路由,把指定来源网段的回包钉到对应网卡

bash

ip route add 10.0.0.0/24 dev eth1

方式 B(更彻底):策略路由(policy routing)

为每张网卡建立独立的路由表,基于来源 IP 决定走哪张表:

bash

# 给 eth1 建立独立路由表(表号 101)
echo "101 eth1-table" >> /etc/iproute2/rt_tables
ip route add default via 10.0.0.1 dev eth1 table eth1-table

# 来源 IP 在 10.0.0.0/24 的流量,查 eth1-table
ip rule add from 10.0.0.0/24 lookup eth1-table

这样从 eth1 进来的请求,回包也会从 eth1 出去——路径对称,防火墙不会拦截。

七、bonding:网卡绑定

bonding 把多块物理网卡聚合成一个逻辑网卡,提供更高带宽或冗余保护。常见模式:

模式	名称	行为	交换机要求	适用场景
0	balance-rr	轮询发包	需配置 etherchannel(不带 LACP)	极少使用
1	active-backup	主备,一块工作另一块待命	无	物理服务器冗余,最常用
4	802.3ad / LACP	链路聚合,带宽叠加	必须开 LACP	高带宽场景
6	balance-alb	自适应负载均衡	无	桌面环境,不推荐生产用

mode 1 (active-backup) vs mode 4 (LACP) 的选择

实施难度与可靠性:

mode 1 在服务器侧单方面配置即可,交换机侧不需要任何特殊配置。两根线分别插入两台交换机能直接实现跨交换机冗余。
mode 4 要求服务器和交换机两端都启用 LACP 协议,且必须在同一台交换机或堆叠在一起的交换机上——跨独立交换机做 LACP 通常不支持。

带宽:

mode 1 带宽 = 单根线的带宽(始终只有一根线在工作)
mode 4 带宽 = 多根线带宽之和(理论上;实际取决于哈希算法分布)

生产推荐:

数据库、控制平面、不追求极致带宽的业务节点:mode 1,部署简单可靠
存储节点、高吞吐网关、有专门网络团队配 LACP 的场景:mode 4
跨独立交换机做冗余:必须用 mode 1,LACP 在这种拓扑下不支持

配置 mode 1 的 bond(NetworkManager)

bash

# 创建 bond
nmcli connection add type bond con-name bond0 ifname bond0 \
    mode active-backup miimon 100 ipv4.method manual \
    ipv4.addresses 192.168.1.10/24 ipv4.gateway 192.168.1.1

# 把两块物理网卡加入 bond
nmcli connection add type ethernet con-name bond0-port1 ifname eth0 master bond0
nmcli connection add type ethernet con-name bond0-port2 ifname eth1 master bond0

# 启动
nmcli connection up bond0

miimon 100 表示每 100ms 检测一次链路状态——网卡 link down 后多少毫秒切换到备用网卡。

bonding 状态查看

bash

cat /proc/net/bonding/bond0

输出包含每个 slave 网卡的状态、当前激活的网卡、链路状态、failover 次数。生产环境监控这个文件,任何一次 failover 都应当告警——它意味着至少一根线/一个端口出了问题,需要排查物理层。

LACP 配置不一致的隐蔽问题

mode 4 要求服务器和交换机两端 LACP 参数一致(rate fast/slow、ad_select 策略等)。两端不一致的常见表现:链路看起来 up、ping 通,但偶发丢包、吞吐上不去、TCP 重传率高。

排查时看 /proc/net/bonding/bond0 中的 Aggregator ID 和 Partner Mac Address——如果 partner 字段为空或 ID 匹配异常,基本能判定是 LACP 协商失败。这种状态下不会完全断网,但性能严重劣化,排查起来比"完全不通"困难得多——所以 LACP 配完一定要在 staging 环境压测一遍。

八、网卡硬件层信息:ethtool

ethtool 用于查看和调整网卡硬件层参数,排查物理层问题的核心工具。

bash

ethtool eth0
# 显示:Speed、Duplex、Auto-negotiation、Link detected 等

# 看网卡支持的所有速率
ethtool eth0 | grep "Supported link modes"

# 强制设置速率(谨慎,通常用自动协商)
ethtool -s eth0 speed 1000 duplex full autoneg off

# 看网卡硬件统计(比 ip -s link 更详细)
ethtool -S eth0

# 看驱动信息
ethtool -i eth0

# 看 ring buffer(收发队列大小)
ethtool -g eth0

# 调大 ring buffer(高吞吐场景常用)
ethtool -G eth0 rx 4096 tx 4096

几个关键排查场景

网卡 link detected = no

物理层不通——线缆、光模块、对端端口任一问题。优先检查:

bash

ethtool eth0 | grep -E "Speed|Duplex|Link detected"
# Speed: Unknown!
# Duplex: Unknown!
# Link detected: no

协商速率不符合预期

千兆口协商成百兆,通常是线缆质量问题(劣质 Cat5 线、距离过长)或对端端口配置异常:

bash

ethtool eth0 | grep -E "Speed|Advertised auto-negotiation"
# Speed: 100Mb/s         ← 但物理上应该是 1000Mb/s

ethtool -S 看到 rx_dropped 持续增长

网卡收到包但内核来不及处理,通常是因为 ring buffer 太小或 CPU 软中断处理瓶颈:

bash

ethtool -S eth0 | grep -iE "drop|error|missed"

调大 ring buffer 缓解(详见上面的 ethtool -G),根本解决需要调优 RPS/RSS 或更换更高规格网卡。

九、易踩的陷阱速查

前面各节已经讲过对应处理,这里集中列出便于回查:

现象	根因	修复
远程 `netplan apply` 后立刻 SSH 断开	新配置导致本机不可达,apply 无回滚机制	远程必须用 `netplan try`,或配合 `at` 定时恢复
改完 ifcfg 文件不生效	NetworkManager 接管设备后以内存状态为准,文件改动需 `nmcli connection reload` 通知 NM	RHEL 8+ 优先用 `nmcli connection modify`,不直接改 ifcfg
`/etc/resolv.conf` 手动改完被覆盖	文件被 NM / systemd-resolved / netplan 接管,会自动生成	改对应工具的配置,或 `chattr +i` 锁定文件
两条 default 路由都在,但流量只走其中一条	内核按 metric 选最优,只有 metric 最小的 default 生效	调整 metric,或用策略路由按来源决定
多网卡,客户端能 ping 通但 TCP 连不上	非对称路由,回包从错误的网卡出去被防火墙拦截	加直连静态路由或配置策略路由
bond 链路 up 但偶发丢包	LACP 两端协商不一致	看 `/proc/net/bonding/bond0` 中 Partner 字段,与交换机侧对齐参数
网卡 `ip -s link` 中 errors/dropped 持续增长	物理层问题或内核缓冲不足	`ethtool eth0` 看速率协商、`ethtool -S` 看详细计数、调大 ring buffer
主机名变了但部分服务仍用旧名	服务进程已经缓存了启动时的 hostname	重启相关服务,或确保 `/etc/hosts` 与新 hostname 一致
重启后某网卡没起来	ifcfg 缺 `ONBOOT=yes` 或 netplan 缺该网卡定义	检查对应配置,设置开机自启
`ifconfig` 看不到某个 IP,但服务能用	net-tools 版本旧或网卡绑了多 IP,`ifconfig` 不显示别名	改用 `ip addr`,这是唯一权威信息源

13｜网络配置 ​

一、ip 命令:查看与临时配置 ​

ifconfig 已不推荐使用 ​

临时给网卡加 IP / 改路由 ​

ip route get:验证流量实际走向 ​

看网卡状态与统计 ​

二、RHEL 系持久化:ifcfg 与 NetworkManager ​

看清当前到底是谁在管网络 ​

ifcfg 文件示例 ​

nmcli 操作 ​

NetworkManager 接管后改 ifcfg 不生效的陷阱 ​

三、Ubuntu netplan ​

关键字段 ​

应用配置:try 与 apply 的关键区别 ​

netplan 配置文件的合并顺序 ​

四、远程改网络的保命流程 ​

第 1 步:开 tmux 保持会话 ​

第 2 步:确认应急登录通道可用 ​

第 3 步:准备自动回退脚本 ​

第 4 步:Ubuntu 用 netplan try,RHEL 用 nmcli + 短超时 ​

五、DNS 客户端配置 ​

resolv.conf 通常不能手动编辑 ​

调整解析超时:服务的"快失败"vs"慢成功" ​

六、多网卡的路由控制 ​

默认路由只能有一条生效 ​

非对称路由问题 ​

七、bonding:网卡绑定 ​

mode 1 (active-backup) vs mode 4 (LACP) 的选择 ​

配置 mode 1 的 bond(NetworkManager) ​

bonding 状态查看 ​

LACP 配置不一致的隐蔽问题 ​

八、网卡硬件层信息:ethtool ​

几个关键排查场景 ​

九、易踩的陷阱速查 ​

13｜网络配置

一、ip 命令:查看与临时配置

ifconfig 已不推荐使用

临时给网卡加 IP / 改路由

ip route get:验证流量实际走向

看网卡状态与统计

二、RHEL 系持久化:ifcfg 与 NetworkManager

看清当前到底是谁在管网络

ifcfg 文件示例

nmcli 操作

NetworkManager 接管后改 ifcfg 不生效的陷阱

三、Ubuntu netplan

关键字段

应用配置:try 与 apply 的关键区别

netplan 配置文件的合并顺序

四、远程改网络的保命流程

第 1 步:开 tmux 保持会话

第 2 步:确认应急登录通道可用

第 3 步:准备自动回退脚本

第 4 步:Ubuntu 用 netplan try,RHEL 用 nmcli + 短超时

五、DNS 客户端配置

resolv.conf 通常不能手动编辑

调整解析超时:服务的"快失败"vs"慢成功"

六、多网卡的路由控制

默认路由只能有一条生效

非对称路由问题

七、bonding:网卡绑定

mode 1 (active-backup) vs mode 4 (LACP) 的选择

配置 mode 1 的 bond(NetworkManager)

bonding 状态查看

LACP 配置不一致的隐蔽问题

八、网卡硬件层信息:ethtool

几个关键排查场景

九、易踩的陷阱速查