Linux 网络设备 | 可预测网络接口名称

注：关于 Linux 系统网络端口变更的译文。 机翻未校，如有内容异常，请看原文。

Predictable Network Interface Names

可预测网络接口名称

Starting with v197 systemd/udev will automatically assign predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces. This is a departure from the traditional interface naming scheme (eth0, eth1, wlan0, …), but should fix real problems. 从 v197 版本开始，systemd/udev 会为所有本地以太网、无线局域网以及无线广域网接口自动分配可预测、稳定的网络接口名称。该方式脱离了传统接口命名方案（eth0、eth1、wlan0……），但能够解决实际存在的问题。

Why?

为什么要这样设计？

The classic naming scheme for network interfaces applied by the kernel is to simply assign names beginning with eth0, eth1, … to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable for modern technology this means that as soon as multiple network interfaces are available the assignment of the names eth0, eth1 and so on is generally not fixed anymore and it might very well happen that eth0 on one boot ends up being eth1 on the next. This can have serious security implications, for example in firewall rules which are coded for certain naming schemes, and which are hence very sensitive to unpredictable changing names. 内核采用的经典网络接口命名方案，会按照驱动探测到接口的顺序，依次分配以 eth0、eth1……开头的名称。现代硬件环境下驱动探测顺序通常不可预测，这意味着系统存在多个网络接口时，eth0、eth1 这类名称的分配不再固定；某次启动时的 eth0，在下一次启动后可能变成 eth1。这会带来安全隐患，例如针对特定名称编写的防火墙规则，会对这种不可预测的名称变动十分敏感。

To fix this problem multiple solutions have been proposed and implemented. For a longer time udev shipped support for assigning permanent ethX names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems, among them: this required a writable root directory which is generally not available; the statelessness of the system is lost as booting an OS image on a system will result in changed configuration of the image; on many systems MAC addresses are not actually fixed, such as on a lot of embedded hardware and particularly on all kinds of virtualization solutions. The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same ethX namespace, a race condition with all kinds of weird effects, among them that assignment of names sometimes failed. As a result support for this has been removed from systemd/udev a while back. 为解决该问题，已有多种方案被提出并落地实现。很长一段时间内，udev 支持基于 MAC 地址为特定接口分配固定的 ethX 名称。但该方案存在诸多问题：它需要可写的根目录，而很多场景下并不具备；系统会失去无状态特性，同一操作系统镜像在不同主机启动后，镜像内配置会发生变更；在大量嵌入式硬件以及各类虚拟化方案中，MAC 地址本身并非固定不变。其中突出的问题是：用户态组件分配接口名称，和内核在同一个 ethX 命名空间内分配新名称会产生竞争，这类竞态条件会引发各类异常现象，有时会直接导致名称分配失败。因此 systemd/udev 早已移除该功能支持。

Another solution that has been implemented is biosdevname which tries to find fixed slot topology information in certain firmware interfaces and uses them to assign fixed names to interfaces which incorporate their physical location on the mainboard. In a way this naming scheme is similar to what is already done natively in udev for various device nodes via /dev/*/by-path/ symlinks. In many cases, biosdevname departs from the low-level kernel device identification schemes that udev generally uses for these symlinks, and instead invents its own enumeration schemes. 另一套已落地的方案是 biosdevname，它会从特定固件接口读取固定的插槽拓扑信息，以此为接口分配包含主板物理位置信息的固定名称。这套命名思路，在某种程度上和 udev 通过 /dev/*/by-path/ 符号链接为各类设备节点原生实现的位置命名方式相近。但多数情况下，biosdevname 并不沿用 udev 用于这类符号链接的底层内核设备识别规则，而是使用一套独立的枚举规则。

Finally, many distributions support renaming interfaces to user-chosen names (think: internet0, dmz0, …) keyed off their MAC addresses or physical locations as part of their networking scripts. This is a very good choice but does have the problem that it implies that the user is willing and capable of choosing and assigning these names. 除此之外，很多发行版在网络脚本中支持基于 MAC 地址或者物理位置，将接口重命名为用户自定义名称（例如 internet0、dmz0……）。这是一种可行方案，但它要求用户有意愿、有能力自行选定并分配接口名称。

We believe it is a good default choice to generalize the scheme pioneered by biosdevname. Assigning fixed names based on firmware/topology/location information has the big advantage that the names are fully automatic, fully predictable, that they stay fixed even if hardware is added or removed (i.e. no reenumeration takes place) and that broken hardware can be replaced seamlessly. That said, they admittedly are sometimes harder to read than the eth0 or wlan0 everybody is used to. Example: enp5s0 将 biosdevname 开创的方案通用化，是合适的默认选择。基于固件、拓扑、位置信息分配固定名称具备这些优势：分配过程全自动、名称可预测；增删硬件时名称保持不变，不会触发重新枚举；故障硬件可以直接替换，无需改动配置。不可否认，这类名称相比大家熟悉的 eth0、wlan0，可读性会稍差。示例：enp5s0

What precisely has changed in v197?

v197 版本具体做了哪些改动？

With systemd 197 we have added native support for a number of different naming policies into systemd/udevd proper and made a scheme similar to biosdevname’s (but generally more powerful, and closer to kernel-internal device identification schemes) the default. The following different naming schemes for network interfaces are now supported by udev natively: 在 systemd 197 中，我们在 systemd/udevd 内部原生加入多种命名策略，并将一套和 biosdevname 思路相近（功能更强、更贴近内核内部设备识别规则）的方案设为默认。udev 现已原生支持下面这些网络接口命名方案：

By default, systemd v197 will now name interfaces following policy 1) if that information from the firmware is applicable and available, falling back to 2) if that information from the firmware is applicable and available, falling back to 3) if applicable, falling back to 5) in all other cases. Policy 4) is not used by default, but is available if the user chooses so. systemd v197 默认的命名优先级：优先使用策略 1，固件信息可用且合法时生效；策略 1 不可用时，回退到策略 2；策略 2 不可用时，回退到策略 3；其余所有情况回退到策略 5。策略 4 不作为默认方案，但用户可以手动启用。

This combined policy is only applied as last resort. That means, if the system has biosdevname installed, it will take precedence. If the user has added udev rules which change the name of the kernel devices these will take precedence too. Also, any distribution specific naming schemes generally take precedence. 这套组合策略仅作为兜底方案。也就是说：如果系统安装了 biosdevname，biosdevname 优先生效；用户自定义的、用于修改内核设备名称的 udev 规则同样优先级更高；发行版自带的专属命名方案一般也优先执行。

Come again, what good does this do?

再说明一下，这套方案能带来哪些好处？

With this new scheme you now get: 采用这套新方案，可以获得下面这些特性：

• Stable interface names across reboots 多次重启后接口名称保持稳定

• Stable interface names even when hardware is added or removed, i.e. no re-enumeration takes place (to the level the firmware permits this) 增删硬件时接口名称保持稳定，不会触发重新枚举（能力上限由固件决定）

• Stable interface names when kernels or drivers are updated/changed 更新、更换内核或驱动后接口名称保持稳定

• Stable interface names even if you have to replace broken ethernet cards by new ones 更换故障网卡后接口名称保持稳定

• The names are automatically determined without user configuration, they just work 名称自动生成，无需用户配置，开箱即用

• The interface names are fully predictable, i.e. just by looking at lspci you can figure out what the interface is going to be called 接口名称完全可预测，仅通过 lspci 命令就可以预判接口名称

• Fully stateless operation, changing the hardware configuration will not result in changes in /etc 完全无状态运行，修改硬件配置不会改动 /etc 目录下的文件

• Compatibility with read-only root 兼容只读根文件系统

• The network interface naming now follows more closely the scheme used for aliasing block device nodes and other device nodes in /dev via symlinks 网络接口命名规则和 /dev 下块设备节点、其他设备节点的符号链接别名规则保持一致

• Applicability to both x86 and non-x86 machines 同时支持 x86 架构与非 x86 架构主机

• The same on all distributions that adopted systemd/udev 在所有采用 systemd/udev 的发行版上行为一致

  It’s easy to opt out of the scheme (see below) 可以很方便地关闭这套命名方案（见下文）

Does this have any drawbacks? Yes, it does. Previously it was practically guaranteed that hosts equipped with a single ethernet card only had a single eth0 interface. With this new scheme in place, an administrator now has to check first what the local interface name is before they can invoke commands on it, where previously they had a good chance that eth0 was the right name. 这套方案存在缺点吗？是的。在旧机制下，单网卡主机的接口名称几乎一定是 eth0。启用新方案后，管理员需要先查询本机接口名称，再执行对应操作；而在旧机制下，直接使用 eth0 通常就能匹配目标网卡。

I don’t like this, how do I disable this?

我不想要这套命名机制，该如何关闭？

You basically have three options: 你主要有三种选择：

How does the new naming scheme look like, precisely?

新命名方案的具体编码规则是什么？

That’s documented in detail the systemd.net-naming-scheme(7) man page. Please refer to this in case you are wondering how to decode the new interface names. 相关详细规则记录在手册页 systemd.net-naming-scheme(7)。如果你需要解析新接口名称的含义，可以查阅该手册。

Name

名称

systemd.net-naming-scheme — Network device naming schemes systemd.net-naming-scheme — 网络设备命名方案

Description

描述

Network interfaces names and MAC addresses may be generated based on certain stable interface attributes. This is possible when there is enough information about the device to generate those attributes and the use of this information is configured. This page describes interface naming, i.e. what possible names may be generated. Those names are generated by the systemd-udevd.service(8) builtin net_id and exported as udev(7) properties (ID_NET_NAME_ONBOARD=, ID_NET_LABEL_ONBOARD=, ID_NET_NAME_PATH=, ID_NET_NAME_SLOT=). 网络接口名称与 MAC 地址可以基于某些稳定的接口属性生成。当设备具备足够信息用于生成这些属性，且已配置启用该信息时，即可实现。本页面介绍接口命名规则，即可生成的名称类型。这些名称由 systemd-udevd.service(8) 的内置工具 net_id 生成，并作为 udev(7) 属性对外导出（ID_NET_NAME_ONBOARD=、ID_NET_LABEL_ONBOARD=、ID_NET_NAME_PATH=、ID_NET_NAME_SLOT=）。

Names and MAC addresses are derived from various stable device metadata attributes. Newer versions of systemd-udevd take more of these attributes into account, improving (and thus possibly changing) the names and addresses used for the same devices. Different versions of those generation rules are called “naming schemes”. The default naming scheme is chosen at compilation time. Usually this will be the latest implemented version, but it is also possible to set one of the older versions to preserve compatibility. This may be useful for example for distributions, which may introduce new versions of systemd in stable releases without changing the naming scheme. The naming scheme may also be overridden using the net.naming_scheme= kernel command line switch, see systemd-udevd.service(8). Available naming schemes are described below. 名称与 MAC 地址取自各类稳定的设备元数据属性。新版本 systemd-udevd 会纳入更多属性，对同一设备生成的名称与地址会得到优化，也因此可能发生变动。这套生成规则的不同版本称为“命名方案”。默认命名方案在编译阶段选定，通常为已实现的最新版本；也可指定旧版本以保持兼容性。该方式适合发行版场景：在稳定版中升级 systemd，同时不改动命名方案。命名方案也可通过内核启动参数 net.naming_scheme= 覆盖，详见 systemd-udevd.service(8)。可用命名方案见下文。

After the udev properties have been generated, appropriate udev rules may be used to actually rename devices based on those properties. See the description of NamePolicy= and MACAddressPolicy= in systemd.link(5). udev 属性生成完成后，可通过对应的 udev 规则，依据这些属性完成设备重命名。参见 [systemd.link(5)] 中 NamePolicy= 与 MACAddressPolicy= 的说明。

Note that while the concept of network interface naming schemes is primarily relevant in the context of systemd-udevd.service, the systemd-nspawn(1) container manager also takes it into account when naming network interfaces, see below. 请注意，网络接口命名方案主要用于 systemd-udevd.service，但容器管理器 systemd-nspawn(1) 在命名网络接口时同样遵循该规则，详见下文。

Policies

命名策略

All names start with a two-character prefix that signifies the interface type. 所有名称以两个字符的前缀开头，用于标识接口类型。

Table 1. Two character prefixes based on the type of interface 表 1. 按接口类型划分的双字符前缀

The udev(7) net_id builtin exports the following device properties: udev(7) 的内置工具 net_id 导出以下设备属性：

• ID_NET_NAME_ONBOARD=prefixonumber, ID_NET_NAME_ONBOARD=prefixdnumber This name is set based on the numeric ordering information given by the firmware for on-board devices. Different schemes are used depending on the firmware type, as described in the table below. 该名称基于固件为板载设备提供的序号信息生成。依据固件类型采用不同方案，见下表。

Table 2. On-board naming schemes 表 2. 板载设备命名方案

• ID_NET_LABEL_ONBOARD=label This property is set based on textual label given by the firmware for on-board devices. This is only available for PCI devices. Added in version 243. 该属性取自固件为板载设备提供的文本标签，仅适用于 PCI 设备，243 版本新增。
• ID_NET_NAME_MAC=prefixxAABBCCDDEEFF This name consists of the prefix, letter x, and 12 hexadecimal digits of the MAC address. It is available if the device has a fixed MAC address. Because this name is based on an attribute of the card itself, it remains “stable” when the device is moved (even between machines), but will change when the hardware is replaced. Added in version 243. 该名称由前缀、字母 x 以及 MAC 地址的 12 位十六进制数字组成。设备拥有固定 MAC 地址时可用。该名称依托网卡自身属性，因此设备迁移（跨主机也可）时保持稳定，但更换硬件后名称会改变，243 版本新增。
• ID_NET_NAME_SLOT=prefix[Pdomain]sslot[ffunction][nport_name|ddev_port], ID_NET_NAME_SLOT=prefixvslot, ID_NET_NAME_SLOT=prefixxslot, ID_NET_NAME_SLOT=prefix[Pdomain]sslot[ffunction][nport_name|ddev_port]bnumber, ID_NET_NAME_SLOT=prefix[Pdomain]sslot[ffunction][nport_name|ddev_port]uport…[cconfig][iinterface], ID_NET_NAME_SLOT=prefix[Pdomain]sslot[ffunction][nport_name|ddev_port]vslot, ID_NET_NAME_SLOT=prefix[Pdomain]sslot[ffunction][nport_name|ddev_port]rslot, ID_NET_NAME_SLOT=prefix[Pdomain]sslot[ffunction][nport_name|ddev_port]Ssfnum This property describes the slot position. Different schemes are used depending on the bus type, as described in the table below. In case of USB, BCMA, and SR-VIO devices, the full name consists of the prefix, PCI slot identifier, and USB or BCMA or SR-VIO slot identifier. The first two parts are denoted as “…” in the table below. 该属性描述插槽位置。依据总线类型采用不同方案，见下表。USB、BCMA、SR-VIO 设备的全名由前缀、PCI 插槽标识、USB/BCMA/SR-VIO 插槽标识拼接而成，下表中前两部分简写为“……”。

Table 3. Slot naming schemes 表 3. 插槽命名方案

The PCI domain is only prepended when it is not 0. All multi-function PCI devices will carry the ffunction number in the device name, including the function 0 device. For non-multi-function devices, the number is suppressed if 0. The port name port_name is used, or the port number ddev_port if the name is not known. PCI 域编号仅在非 0 时才添加到名称前缀。所有多功能 PCI 设备（包括功能 0）都会在名称中携带 ffunction；单功能设备的功能号为 0 时省略。优先使用端口名 port_name，端口名未知时使用端口编号 ddev_port。

For BCMA devices, the core number is suppressed when 0. BCMA 设备内核编号为 0 时省略。

For USB devices the full chain of port numbers of hubs is composed. If the name gets longer than the maximum number of 15 characters, the name is not exported. The usual USB configuration number 1 and interface number 0 values are suppressed. USB 设备会拼接集线器完整端口链路编号；若名称长度超过 15 字符上限，则不导出该名称。默认 USB 配置号 1、接口号 0 会省略。

SR-IOV virtual devices are named based on the name of the parent interface, with a suffix of v and the virtual device number, with any leading zeros removed. The bus number is ignored. SR-IOV 虚拟设备基于父接口名称命名，后缀为 v 加虚拟设备编号，编号前导零去除，总线编号忽略。

SR-IOV virtual device representors are named based on the name of the physical device interface, with a suffix of r and the number of the virtual device that is linked to the particular representor, with any leading zeros removed. The physical port name and the bus number are ignored. SR-IOV 虚拟设备表示器基于物理接口名称命名，后缀为 r 加该表示器绑定的虚拟设备编号，编号前导零去除，物理端口名与总线编号忽略。

Auxiliary sub-function (SF) network devices, where the network device’s parent is an auxiliary device exposing a sfnum sysfs attribute (currently mlx5_core SFs), are named based on the underlying PCI function (the PF, or for VF-SF the PF behind the VF), with a suffix of S and the user-defined sub-function number from sfnum. This is analogous to how SR-IOV virtual function devices are named with a v suffix. 辅助子功能（SF）网络设备，其父设备为暴露 sfnum sysfs 属性的辅助设备（当前为 mlx5_core SF），基于底层 PCI 功能（PF；VF-SF 场景取 VF 对应的 PF）命名，后缀为 S 加 sfnum 中用户定义的子功能编号，和 SR-IOV 虚拟功能使用 v 后缀的方式一致。

If the SF’s parent PCI function is itself an SR-IOV virtual function (VF-SF), the name is rooted at the PF and both suffixes are chained, with the v suffix preceding the S suffix (e.g. “enp193s0f0v0S88”). The PF, the VF, and the SF therefore form a stable, hierarchical sequence regardless of the VF’s underlying PCI bus/device/function numbering. 若 SF 的父 PCI 功能本身是 SR-IOV 虚拟功能（VF-SF），名称以 PF 为根基，两个后缀依次拼接，v 后缀在前，S 后缀在后（例如 enp193s0f0v0S88）。因此 PF、VF、SF 构成稳定层级序列，不受 VF 底层 PCI 总线/设备/功能编号影响。

In some configurations a parent PCI bridge of a given network controller may be associated with a slot. In such case we do not generate this device property to avoid possible naming conflicts. Added in version 243. 部分配置下，网卡的上级 PCI 桥会绑定插槽信息；此时不会生成该设备属性，避免命名冲突，243 版本新增。

• ID_NET_NAME_PATH=prefixcbus_id, ID_NET_NAME_PATH=prefixavendor**modeliinstance, ID_NET_NAME_PATH=prefixiaddressnport_name, ID_NET_NAME_PATH=prefixuport…, ID_NET_NAME_PATH=prefix[Pdomain]pbussslot[ffunction][nphys_port_name|ddev_port], ID_NET_NAME_PATH=prefix[Pdomain]pbussslot[ffunction][nphys_port_name|ddev_port]bnumber, ID_NET_NAME_PATH=prefix[Pdomain]pbussslot[ffunction][nphys_port_name|ddev_port]uport…[cconfig][iinterface], ID_NET_NAME_PATH=prefix[Pdomain]pbussslot[ffunction][nphys_port_name|ddev_port]Ssfnum This property describes the device installation location. Different schemes are used depending on the bus type, as described in the table below. For BCMA and USB devices, PCI path information must known, and the full name consists of the prefix, PCI slot identifier, and USB or BCMA location. The first two parts are denoted as “…” in the table below. 该属性描述设备安装位置。依据总线类型采用不同方案，见下表。BCMA、USB 设备需要已知 PCI 路径信息，全名由前缀、PCI 插槽标识、USB/BCMA 位置信息拼接而成，下表中前两部分简写为“……”。

Table 4. Path naming schemes 表 4. 路径命名方案

CCW and grouped CCW devices are found in IBM System Z mainframes. Any leading zeros and dots are suppressed. CCW 与分组 CCW 设备用于 IBM System Z 大型机，编号前导零与点号省略。

For PCI, BCMA, and USB devices, the same rules as described above for slot naming are used. Added in version 243. PCI、BCMA、USB 设备沿用上述插槽命名的同类规则，243 版本新增。

History

版本沿革

The following “naming schemes” have been defined (which may be chosen at system boot-up time via the net.naming_scheme= kernel command line switch, see above): 已定义以下命名方案（可在系统启动时通过内核参数 net.naming_scheme= 指定，见上文）：

• v238 This is the naming scheme that was implemented in systemd 238. Added in version 243. systemd 238 实现的命名方案，243 版本新增。

• v239 Naming was changed for virtual network interfaces created with SR-IOV and NPAR and for devices where the PCI network controller device does not have a slot number associated. 调整 SR-IOV、NPAR 虚拟网卡，以及 PCI 网卡自身无绑定插槽号设备的命名规则。 SR-IOV virtual devices are named based on the name of the parent interface, with a suffix of "vport", where *port* is the virtual device number. Previously those virtual devices were named as if completely independent. SR-IOV 虚拟设备基于父接口命名，后缀为 v加虚拟设备编号；旧版本中这类虚拟设备会被当作独立设备命名。 The ninth and later NPAR virtual devices are named following the scheme used for the first eight NPAR partitions. Previously those devices were not renamed and the kernel default ("eth*N*") was used. 第 9 号及以后的 NPAR 虚拟分区沿用前 8 个分区的命名规则；旧版本中这些设备不会重命名，使用内核默认 "eth*N*"。 Names are also generated for PCI devices where the PCI network controller device does not have an associated slot number itself, but one of its parents does. Previously those devices were not renamed and the kernel default was used. Added in version 243. 若网卡本身无插槽编号，但上级设备存在插槽编号，也会生成名称；旧版本这类设备不重命名，使用内核默认名称，243 版本新增。

• v240 The “ib” prefix and stable names for infiniband devices are introduced. Previously those devices were not renamed. 引入 ib 前缀，为无限带宽设备提供稳定名称；旧版本这类设备不重命名。

  The ACPI index field (used in ID_NET_NAME_ONBOARD=) is now also used when 0. 用于 ID_NET_NAME_ONBOARD= 的 ACPI 索引字段，取值为 0 时同样参与命名。

  A new naming policy NamePolicy=keep was introduced. With this policy, if the network device name was already set by userspace, the device will not be renamed again. Previously, this naming policy applied implicitly, and now it must be explicitly requested. Effectively, this means that network devices will be renamed according to the configuration, even if they have been renamed already, if keep is not specified as the naming policy in the .link file. See systemd.link(5) for a description of NamePolicy=. Added in version 243. 新增命名策略 NamePolicy=keep。启用该策略时，若用户态已经设置网卡名称，则不再二次重命名。旧版本该策略隐式生效，现在需要显式声明。也就是说：如果 .link 文件没有指定 keep，网卡即便已经被重命名，仍会按照配置再次改名。NamePolicy= 的说明见 systemd.link(5)，243 版本新增。

• v241 MACAddressPolicy=persistent was extended to set MAC addresses based on the device name. Previously addresses were only based on the ID_NET_NAME_* attributes, which meant that interface names would never be generated for virtual devices. Now a persistent address will be generated for most devices, including in particular bridges. 扩展 MACAddressPolicy=persistent，支持基于设备名称生成 MAC 地址。旧版本仅依靠 ID_NET_NAME_* 属性生成 MAC，虚拟设备无法生成稳定地址；现在大多数设备（包括网桥）都可生成持久化 MAC。

  Note: when userspace does not set a MAC address for a bridge device, the kernel will initially assign a random address, and then change it when the first device is enslaved to the bridge. With this naming policy change, bridges get a persistent MAC address based on the bridge name instead of the first enslaved device. Added in version 243. 注：用户态未指定网桥 MAC 时，内核初始分配随机地址，第一个设备加入网桥后 MAC 会变更。该策略改动后，网桥的持久化 MAC 基于网桥名称生成，不再取自第一个接入设备，243 版本新增。

• v243 Support for renaming netdevsim (simulated networking) devices was added. Previously those devices were not renamed. 新增 netdevsim（模拟网络设备）重命名支持；旧版本这类设备不重命名。

  Previously two-letter interface type prefix was prepended to ID_NET_LABEL_ONBOARD=. This is not done anymore. Added in version 243. 旧版本会在 ID_NET_LABEL_ONBOARD= 前追加双字符类型前缀，该行为已取消，243 版本新增。

• v245 When systemd-nspawn(1) derives the name for the host side of the network interface created with –network-veth from the container name it previously simply truncated the result at 15 characters if longer (since that’s the maximum length for network interface names). From now on, for any interface name that would be longer than 15 characters the last 4 characters are set to a 24bit hash value of the full interface name. This way network interface name collisions between multiple similarly named containers (who only differ in container name suffix) should be less likely (but still possible, since the 24bit hash value is very small). Added in version 245. systemd-nspawn(1) 使用 –network-veth 创建虚拟网卡时，宿主机侧接口名称取自容器名。旧版本直接截断至 15 字符（网卡名称上限）；新版本中，若名称超出 15 字符，末尾 4 字符替换为全名的 24 位哈希值。该方式降低名称后缀相近的容器发生名称冲突的概率（但仍有可能冲突，24 位哈希空间较小），245 版本新增。

• v247 When a PCI slot is associated with a PCI bridge that has multiple child network controllers, the same value of the ID_NET_NAME_SLOT property might be derived for those controllers. This would cause a naming conflict if the property is selected as the device name. Now, we detect this situation and do not produce the ID_NET_NAME_SLOT property. Added in version 247. 若 PCI 插槽绑定一个 PCI 桥，桥下有多块网卡，这些网卡会生成相同的 ID_NET_NAME_SLOT，选该属性作为名称会引发冲突。新版本检测该场景，不再生成 ID_NET_NAME_SLOT，247 版本新增。

• v249 PCI hotplug slot names for the s390 PCI driver are a hexadecimal representation of the function_id device attribute. This attribute is now used to build the ID_NET_NAME_SLOT. Before that, all slot names were parsed as decimal numbers, which could either result in an incorrect value of the ID_NET_NAME_SLOT property or none at all. s390 PCI 驱动的 PCI 热插拔插槽名称是 function_id 属性的十六进制形式，现在直接使用该属性构造 ID_NET_NAME_SLOT。旧版本全部按十进制解析，会造成 ID_NET_NAME_SLOT 取值错误或无法生成。

  Some firmware and hypervisor implementations report unreasonably high numbers for the on-board index. To prevent the generation of bogus on-board interface names, index numbers greater than 16381 (2¹⁴−1) were ignored. For s390 PCI devices index values up to 65535 (2¹⁶−1) are valid. To account for that, the limit was increased to 65535. 部分固件与虚拟化管理程序上报的板载序号过大。此前为避免生成无效名称，大于 16381（2¹⁴−1）的序号会被忽略；s390 PCI 设备序号上限为 65535（2¹⁶−1），因此上限调整为 65535。

  The udev(7) rule NAME= replaces “:”, “/”, and “%” with an underscore (“_”), and refuses strings which contain only digits. Added in version 249. udev(7) 的 NAME= 规则将 :、/、% 替换为下划线 _，并且拒绝纯数字字符串，249 版本新增。

• v250 Added naming scheme for Xen netfront “vif” interfaces based on the guest side VIF number set from the Xen config (or the interface index in AWS EC2). Added in version 250. 新增 Xen netfront “vif” 接口命名规则，基于 Xen 配置里的客户机侧 VIF 编号（AWS EC2 中为接口索引）生成名称，250 版本新增。

• v251 Since version v247 we no longer set ID_NET_NAME_SLOT if we detect that a PCI device associated with a slot is a PCI bridge as that would create naming conflict when there are more child devices on that bridge. Now, this is relaxed and we will use slot information to generate the name based on it but only if the PCI device has multiple functions. This is safe because distinct function number is a part of the device name for multifunction devices. Note, this is reverted in v255. See below. Added in version 251. v247 版本规则：若绑定插槽的 PCI 设备是 PCI 桥，则不再生成 ID_NET_NAME_SLOT，防止桥下方多子设备冲突。 v251 放宽限制：仅当该 PCI 设备为多功能设备时，才允许使用插槽信息生成名称；多功能设备名称自带独立功能号，不会冲突。注意：该改动在 v255 中回退，见下文，251 版本新增。

• v252 Added naming scheme for platform devices with devicetree aliases. Added in version 252. 新增支持带设备树别名的平台设备命名方案，252 版本新增。

• v253 Set ID_NET_NAME_PATH for usb devices not connected via a PCI bus. Added in version 253. 为不经过 PCI 总线挂载的 USB 设备生成 ID_NET_NAME_PATH，253 版本新增。

• v254 Naming was changed for SR-IOV virtual device representors, optionally settable at compilation time. The "rslot" suffix was added to differentiate SR-IOV virtual device representors attached to a single physical device interface. Because of a mistake, this scheme was *not the default scheme for systemd version 254*. Added in version 255. 修改 SR-IOV 虚拟设备表示器命名规则，编译时可选开启。新增 r*slot`* 后缀，区分绑定在同一个物理网卡上的多个 SR-IOV 表示器。因程序缺陷，该方案在 systemd 254 中并非默认，255 版本新增。

• v255 Naming was changed for SR-IOV virtual device representors to enable the change introduced in v254 by default. 修改 SR-IOV 虚拟设备表示器命名，默认启用 v254 引入的改动。 If we detect that a PCI device associated with a slot is a PCI bridge, we no longer set ID_NET_NAME_SLOT, reverting a change that was introduced in v251. Added in version 255. 若绑定插槽的 PCI 设备是 PCI 桥，不再生成 ID_NET_NAME_SLOT，回退 v251 的改动，255 版本新增。

• v257 PCI slot number is now read from firmware_node/sun sysfs file. PCI 插槽编号改为从 sysfs 文件 firmware_node/sun 读取。 The naming scheme based on devicetree aliases was extended to support aliases for individual interfaces of controllers with multiple ports. Added in version 257. 扩展基于设备树别名的命名方案，支持多端口网卡各个独立端口的别名，257 版本新增。

• v258 When no renaming is requested, ID_NET_NAME property is now equivalent to INTERFACE property. Added in version 258. 不执行重命名时，ID_NET_NAME 属性取值与 INTERFACE 属性一致，258 版本新增。

• v259 The naming scheme based on devicetree aliases was extended to support WLAN devices. Added in version 259. 扩展基于设备树别名的命名方案，支持无线局域网设备，259 版本新增。

• v260 MCTP interfaces are now assigned persistent names, using a mc prefix. Added in version 260. MCTP 接口分配持久化名称，使用 mc 前缀，260 版本新增。

• v261 Stable names are now generated for auxiliary sub-function (SF) network devices (such as “mlx5_core” SFs). The name is built from the parent PCI Physical Function’s path with an “Ssfnum" suffix, where *sfnum* is the user-defined SF number (the value passed to **devlink port add … sfnum \\*N\\***, exposed by the kernel as the sfnum sysfs attribute on the auxiliary device). This is analogous to the "v*N*” suffix used for SR-IOV virtual functions; for SFs hosted on SR-IOV VFs (VF-SF), the two suffixes are chained on top of the PF’s base name. Added in version 261. 为辅助子功能（SF）网络设备（例如 mlx5_core SF）生成稳定名称。名称由父级 PCI 物理功能路径拼接 Ssfnum 后缀构成；sfnum 为用户定义的子功能编号（由 devlink port add … sfnum *N* 指定，内核在辅助设备上以 sysfs 属性 sfnum 导出）。该方式和 SR-IOV 虚拟功能使用 vN 后缀一致；承载在 SR-IOV VF 上的 SF（VF-SF），两个后缀在 PF 基础名称上依次拼接，261 版本新增。

Note that latest may be used to denote the latest scheme known (to this particular version of systemd). 注意：latest 可用来指代当前 systemd 版本已知的最新命名方案。

Limiting the use of specific sysfs attributes

限制特定 sysfs 属性的使用

When creating names for network cards, some naming schemes use data from sysfs populated by the kernel. This means that although a specific naming scheme in udev(7) is picked, the network card’s name can still change when a new kernel version adds a new sysfs attribute. For example, if kernel starts setting the phys_port_name, udev will append the “nphys_port_name” suffix to the device name. 网卡命名时，部分方案会读取内核填充在 sysfs 中的数据。也就是说，即便选定固定命名方案，内核升级新增 sysfs 属性后，网卡名称仍可能变动。举例：若内核开始提供 phys_port_name，udev 会在设备名称后追加 nphys_port_name 后缀。

• ID_NET_NAME_ALLOW=BOOL This udev property sets a fallback policy for reading a sysfs attribute. If set to 0 udev will not read any sysfs attribute by default, unless it is explicitly allowlisted, see below. If set to 1 udev can use any sysfs attribute unless it is explicitly forbidden. The default value is 1. Added in version 256. 该 udev 属性设置读取 sysfs 属性的兜底策略。设为 0：默认不读取任何 sysfs 属性，仅使用显式加入白名单的属性（见下文）。设为 1：默认允许读取全部 sysfs 属性，显式拉黑的除外。默认值为 1，256 版本新增。
• ID_NET_NAME_ALLOW_*sysfsattr*=*BOOL* This udev property explicitly states if udev shall use the specified sysfsattr, when composing the device name. Added in version 256. 该 udev 属性单独控制 udev 在构建设备名称时是否使用指定的 sysfsattr 属性，256 版本新增。

With these options, users can set an allowlist or denylist for sysfs attributes. To create an allowlist, the user needs to set ID_NET_NAME_ALLOW=0 for the device and then list the allowed attributes with the ID_NET_NAME_ALLOW_*sysfsattr*=1 options. In case of a denylist, the user needs to provide the list of denied attributes with the ID_NET_NAME_ALLOW_*sysfsattr*=0 options. 借助上述参数，用户可以配置 sysfs 属性白名单或黑名单。配置白名单：为设备设置 ID_NET_NAME_ALLOW=0，再用 ID_NET_NAME_ALLOW_*sysfsattr*=1 列出允许的属性。配置黑名单：用 ID_NET_NAME_ALLOW_*sysfsattr*=0 列出禁止使用的属性。

Examples

示例

Example 1. Using udevadm test-builtin to display device properties 示例 1. 使用 udevadm test-builtin 查看设备属性

# 调用 udevadm 内置 net_id 工具，读取指定网卡路径的命名属性
$ udevadm test-builtin net_id /sys/class/net/enp0s31f6
…
Using default interface naming scheme 'v243'.
ID_NET_NAMING_SCHEME=v243
ID_NET_NAME_MAC=enx54ee75cb1dc0
ID_OUI_FROM_DATABASE=Wistron InfoComm(Kunshan)Co.,Ltd.
ID_NET_NAME_PATH=enp0s31f6
…

Example 2. PCI Ethernet card with firmware index “1” 示例 2. 固件索引号为 1 的 PCI 以太网卡

# 板载网卡固件索引生成名称
ID_NET_NAME_ONBOARD=eno1
ID_NET_NAME_ONBOARD_LABEL=Ethernet Port 1

Example 3. PCI Ethernet card in slot with firmware index number 示例 3. 带固件插槽索引号的 PCI 以太网卡

# /sys/devices/pci0000:00/0000:00:1c.3/0000:05:00.0/net/ens1
ID_NET_NAME_MAC=enx000000000466
ID_NET_NAME_PATH=enp5s0
ID_NET_NAME_SLOT=ens1

Example 4. PCI Ethernet multi-function card with 2 ports 示例 4. 双端口 PCI 多功能以太网卡

# /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/enp2s0f0
ID_NET_NAME_MAC=enx78e7d1ea46da
ID_NET_NAME_PATH=enp2s0f0

# /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/net/enp2s0f1
ID_NET_NAME_MAC=enx78e7d1ea46dc
ID_NET_NAME_PATH=enp2s0f1

Example 5. PCI WLAN card 示例 5. PCI 无线网卡

# /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlp3s0
ID_NET_NAME_MAC=wlx0024d7e31130
ID_NET_NAME_PATH=wlp3s0

Example 6. PCI IB host adapter with 2 ports 示例 6. 双端口 PCI 无限带宽主机适配器

# /sys/devices/pci0000:00/0000:00:03.0/0000:15:00.0/net/ibp21s0f0
ID_NET_NAME_PATH=ibp21s0f0

# /sys/devices/pci0000:00/0000:00:03.0/0000:15:00.1/net/ibp21s0f1
ID_NET_NAME_PATH=ibp21s0f1

Example 7. USB built-in 3G modem 示例 7. 内置 USB 3G 调制解调器

# /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.6/net/wwp0s29u1u4i6
ID_NET_NAME_MAC=wwx028037ec0200
ID_NET_NAME_PATH=wwp0s29u1u4i6

Example 8. USB Android phone 示例 8. USB 安卓手机

# /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/net/enp0s29u1u2
ID_NET_NAME_MAC=enxd626b3450fb5
ID_NET_NAME_PATH=enp0s29u1u2

Example 9. s390 grouped CCW interface 示例 9. s390 分组 CCW 接口

# /sys/devices/css0/0.0.0007/0.0.f5f0/group_device/net/encf5f0
ID_NET_NAME_MAC=enx026d3c00000a
ID_NET_NAME_PATH=encf5f0

Example 10. Set an allowlist for reading sysfs attributes for network card naming 示例 10. 配置网卡命名读取 sysfs 属性的白名单

# /etc/udev/hwdb.d/50-net-naming-allowlist.hwdb
# 匹配 virtio_net 设备，启用 sysfs 属性白名单模式
net:naming:drvirtio_net:*
ID_NET_NAME_ALLOW=0
ID_NET_NAME_ALLOW_ACPI_INDEX=1
ID_NET_NAME_ALLOW_ADDR_ASSIGN_TYPE=1
ID_NET_NAME_ALLOW_ADDRESS=1
ID_NET_NAME_ALLOW_ARI_ENABLED=1
ID_NET_NAME_ALLOW_DEV_PORT=1
ID_NET_NAME_ALLOW_FUNCTION_ID=1
ID_NET_NAME_ALLOW_IFLINK=1
ID_NET_NAME_ALLOW_INDEX=1
ID_NET_NAME_ALLOW_LABEL=1
ID_NET_NAME_ALLOW_PHYS_PORT_NAME=1
ID_NET_NAME_ALLOW_TYPE=1

Example 11. Set a denylist so that specified sysfs attribute are ignored 示例 11. 配置黑名单，忽略指定 sysfs 属性

# /etc/udev/hwdb.d/50-net-naming-denylist.hwdb
# 匹配 virtio_net 设备，禁用 dev_port 与 phys_port_name 属性
net:naming:drvirtio_net:*
ID_NET_NAME_ALLOW=1
ID_NET_NAME_ALLOW_DEV_PORT=0
ID_NET_NAME_ALLOW_PHYS_PORT_NAME=0

See Also

参见

udev(7), udevadm(8), systemd-udevd.service(8), Predictable Network Interface Names, systemd-nspawn(1) udev(7)、udevadm(8)、systemd-udevd.service(8)、Predictable Network Interface Names、systemd-nspawn(1)

Ref

• Predictable Network Interface Names https://systemd.io/PREDICTABLE_INTERFACE_NAMES/
• systemd.net-naming-scheme https://www.freedesktop.org/software/systemd/man/latest/systemd.net-naming-scheme.html