最后放弃了做绑定,修改grub,不再按照旧逻辑生成ethx,而是按照插槽生成网卡名才解决的
此处权当做记录
背景
问题
一台Ubuntu设备重启后丢失ip,发现是网卡名称变更导致netplan的配置对应错误。
设备
- 主板:SuperMicro
- CPU:Intel(R) Xeon(R) Platinum 8180 CPU @ 2.50GHz
- 操作系统:Ubuntu 22.04
- 网卡:
- Ethernet Connection X722 for 1GbE
- Ethernet Controller X710 for 10GbE SFP+
- I350 Gigabit Network Connection
# 查询硬件信息,储存到log文件中
lshw -short >> lshw.log
确认原因
网卡名称变动
- 发现重启的时候eth0, eth1, eth2, ... 对应的实际网卡可能会发生变化
- 查询得知,设备启动时是并行加载,网卡的获取时间有一定随机性,给的网卡名称命名也会变动
办法1:绑定网卡名称和mac地址(失败)
询deepseek,可以在udev中添加规则,绑定网卡名称和mac地址,这样每次重启就不会发生变动了。
原理
- 内核初始化
1.1 内核启动,监测所有硬件设备(包括网卡)生成临时命名(如eth0)
1.2 内核将sysfs和netlink接口将设备信息传递给用户空间 - systemd启动
2.1 systemd作为初始化系统(PID=1)启动,加载systemd-udevd(udev后台服务),负责管理设备事件 - udev处理设备事件
3.1 udevd接收内核发送设备事件后,根据规则文件(etc/udev/rules.d/*.rules)进行处理
3.1.1 设备命名:为设备生成持久化的可预测命名,覆盖内核临时命名
3.1.2 设备初始化:加载驱动,创建设备节点(/dev下的文件) - 设备由systemd执行初始化
- systemd运行udev,处理硬件时间,网卡命名在此处进行
操作
创建新规则文件
# 创建规则文件目录
cd /etc/udev/rules.d
# 创建规则文件
touch 70-netcard_name.rules
# 编辑规则文件
vim netcard_name.rules
写入网卡绑定配置
# netcard
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="3c:ec:ef:02:43:da", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="3c:ec:ef:02:43:db", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="68:91:d0:65:07:ea", NAME="eth2"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="68:91:d0:65:07:eb", NAME="eth3"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1b:21:b9:3f:c0", NAME="eth4"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1b:21:b9:3f:c2", NAME="eth5"
应用配置文件
# 重新加载udev规则
udevadm control --reload-rules
# 触发udev事件
udevadm trigger
# 重启设备
reboot
结论
并没有得到解决
- 甚至会出现网卡名称和udev名称冲突导致掉网卡的情况,需要手动重新启动网卡
- netplan的配置也不再生效,netplan apply不报错但是没有效果,需要手动重新配置临时ip和route
办法2:禁止grub使用旧式命名规则
原理
ifconfig发现每张网卡都有多个名字,除了eth0、eth1之外,还存在着类似下面的别名
ifconfig eth1
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 100000
link/ether 3c:ec:ef:02:43:da brd ff:ff:ff:ff:ff:ff
altname eno1
altname enp28s0f0
经过查询确认,这些命名方式是现代内核为了避免发生网卡加载冲突而使用的可预测命名方式。
影响:启用新的命名规则可以使网络接口名称更具可预测性,基于硬件路径和设备类型来命名,避免因设备识别顺序不同导致的名称变化。
——Kimi AI
因此,我应当使用这种命名方式,抛弃旧式的ethxx的命名方式,避免因加载顺序导致网卡命名发生变动。
实践
查看grub文件
less /etc/default/grub
发现了这么一行
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0 i915.force_probe=* pci=realloc=off i915.enable_guc=2"
经过确认,其中两个参数会导致当前设备使用旧式命名规则
net.ifname=0 #是否启用新式命名规则,0为不启用
biosdevname=0 #是否使用BIOS分配的名称来命名网络接口,0为不启用
将这两个参数都修订为1之后,更新grub再重新启动
# 更新grub配置
sudo update-grub
# 重启设备
sudo reboot
开机后发现,当前的网卡名称发生了变更,现在不再是ethxxx,而是:
ip addr | grep qlen
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 100000
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 100000
3: enp175s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 100000
4: eno2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 100000
5: enp175s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 100000
6: enp94s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 100000
7: enp94s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 100000
可以确认,当前的命名方式是按照插槽决定的,而非以加载顺序决定,只要插槽顺序不发生改变,那么这个配置名称和mac地址的对应关系就不会发生改变。
问题解决
- 重置netplan配置,修改网卡名为当前状态,netplan apply能够正常修改网络配置
- 多次重启,网卡命名和mac地址都不再发生变化
以上,问题圆满解决。