From 7b1e4518e0d5d9c68340cefa830bc7196ef05e20 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 20:38:43 +0000 Subject: [PATCH 01/38] --- docs/PredictableNetworkInterfaceNames.moin | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 docs/PredictableNetworkInterfaceNames.moin diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin new file mode 100644 index 0000000000..7a4ec4018f --- /dev/null +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -0,0 +1,39 @@ += 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 traditional interface naming ("eth0", "eth1", "wlan0", ...), but should fix real problems. + +== Why? == + +The classic naming scheme for network interfaces applied by the kernel is to simply assign names starting with "eth0", "eth1", ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable with modern technology this meant that as soon as multiple network interfaces are available the assignment of the names "eth0", "eth1" and so on is not fixed. This can have serious security implications, for example in firewall rules which are coded for certain naming schemes. + +To fix this problem multiple solutions have been proposed and implemented. For a longer time udev shipped support for assigning permanent "ethXXX" 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 availeble; 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 "ethXXX" namespace, a race condition with all kinds of weird effects. + +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 map to their physical location on the mainboard. (Unfortunately biosdevname did a lot of other stuff too). + +Assigning fixed names based on firmware/topology/location information has the big advantage that the names are fully predictable, that they stay fixed even if hardware is added or removed (i.e. no reenumeration takes place), that broken hardware can be replaced seamlessly. + +== What does v197 do? == + +With systemd 197 we have moved a scheme similar to biosdevname into systemd/udev proper. A number of different naming schemes for network interfaces are now supported by udev natively: + + 1. Firmware/BIOS provided index numbers for on-board devices + 2. Firmware/BIOS provided PCI Express hotplug slot index numbers + 3. Physical/geographical location of the hardware on the mainboard + 4. The interfaces's MAC address + 5. Classic, unpredictable kernel-native ethXXX naming + +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. + +This 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. + +== I don't like this, how do I disable this? == + +You basically have three options: + + 1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: {{{ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules}}} + 2. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own udev rules file and set the NAME property. Make sure to order it before the default policy file, for example by naming it {{{/etc/udev/rules.d/70-my-net-names.rules}}} + 3. You alter the default policy file, for picking a different naming scheme, for example for naming all interface names after their MAC address by default: {{{cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules}}}, then edit the file there and change the lines as necessary. + +== How does the new naming scheme look like precisely? == + +That's documented in detail in [[http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20|the sources of the net_id built-in]]. From 5536de5cc4442d8a098fb68511abedf0f2553765 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 20:41:17 +0000 Subject: [PATCH 02/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 7a4ec4018f..35a7ed4e82 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -4,7 +4,7 @@ Starting with v197 systemd/udev will automatically assign predictable, stable ne == Why? == -The classic naming scheme for network interfaces applied by the kernel is to simply assign names starting with "eth0", "eth1", ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable with modern technology this meant that as soon as multiple network interfaces are available the assignment of the names "eth0", "eth1" and so on is not fixed. This can have serious security implications, for example in firewall rules which are coded for certain naming schemes. +The classic naming scheme for network interfaces applied by the kernel is to simply assign names starting with "eth0", "eth1", ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable with 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 predicatble. 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 changing names. To fix this problem multiple solutions have been proposed and implemented. For a longer time udev shipped support for assigning permanent "ethXXX" 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 availeble; 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 "ethXXX" namespace, a race condition with all kinds of weird effects. From 6dbee95541bcd449658dd54aeb7e85e31dc7225a Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 20:43:36 +0000 Subject: [PATCH 03/38] --- docs/PredictableNetworkInterfaceNames.moin | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 35a7ed4e82..43af83b001 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -10,9 +10,11 @@ To fix this problem multiple solutions have been proposed and implemented. For a 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 map to their physical location on the mainboard. (Unfortunately biosdevname did a lot of other stuff too). -Assigning fixed names based on firmware/topology/location information has the big advantage that the names are fully predictable, that they stay fixed even if hardware is added or removed (i.e. no reenumeration takes place), that broken hardware can be replaced seamlessly. +Finally, many distributions supporting renaming interfaces to user-chosen names (think: "internet0", "dmz0", ...) keyed off their MAC addresses or physical locations. 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. -== What does v197 do? == +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), that broken hardware can be replaced seamlessly. + +== What has changed v197 precisely? == With systemd 197 we have moved a scheme similar to biosdevname into systemd/udev proper. A number of different naming schemes for network interfaces are now supported by udev natively: From 3c36dd1ca545118752156b262f9bbf251e00e8dc Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 20:45:16 +0000 Subject: [PATCH 04/38] --- docs/PredictableNetworkInterfaceNames.moin | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 43af83b001..8b99416913 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -18,10 +18,10 @@ Assigning fixed names based on firmware/topology/location information has the bi With systemd 197 we have moved a scheme similar to biosdevname into systemd/udev proper. A number of different naming schemes for network interfaces are now supported by udev natively: - 1. Firmware/BIOS provided index numbers for on-board devices - 2. Firmware/BIOS provided PCI Express hotplug slot index numbers - 3. Physical/geographical location of the hardware on the mainboard - 4. The interfaces's MAC address + 1. Names incorporating Firmware/BIOS provided index numbers for on-board devices + 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers + 3. Names incorporating Physical/geographical location of the hardware on the mainboard + 4. Names incorporating the interfaces's MAC address 5. Classic, unpredictable kernel-native ethXXX naming 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. From 6f99e67081408a188422c2e6a40ef1844cd6f3cb Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 20:54:53 +0000 Subject: [PATCH 05/38] --- docs/PredictableNetworkInterfaceNames.moin | 24 +++++++++++----------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 8b99416913..440442d282 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -1,41 +1,41 @@ = 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 traditional interface naming ("eth0", "eth1", "wlan0", ...), but should fix real problems. +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. == Why? == -The classic naming scheme for network interfaces applied by the kernel is to simply assign names starting with "eth0", "eth1", ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable with 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 predicatble. 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 changing names. +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. -To fix this problem multiple solutions have been proposed and implemented. For a longer time udev shipped support for assigning permanent "ethXXX" 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 availeble; 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 "ethXXX" namespace, a race condition with all kinds of weird effects. +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. As a result supporting for this has been removed from systemd/udev a while back. -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 map to their physical location on the mainboard. (Unfortunately biosdevname did a lot of other stuff too). +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. (Unfortunately biosdevname did a lot more than this which is more problematic). -Finally, many distributions supporting renaming interfaces to user-chosen names (think: "internet0", "dmz0", ...) keyed off their MAC addresses or physical locations. 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. +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. -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), that broken hardware can be replaced seamlessly. +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. == What has changed v197 precisely? == -With systemd 197 we have moved a scheme similar to biosdevname into systemd/udev proper. A number of different naming schemes for network interfaces are now supported by udev natively: +With systemd 197 we have moved a scheme similar to biosdevname (put generally more powerful) into systemd/udev proper. A number of different naming schemes for network interfaces are now supported by udev natively: 1. Names incorporating Firmware/BIOS provided index numbers for on-board devices 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers - 3. Names incorporating Physical/geographical location of the hardware on the mainboard + 3. Names incorporating physical/geographical location of the hardware on the mainboard 4. Names incorporating the interfaces's MAC address 5. Classic, unpredictable kernel-native ethXXX naming -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. +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.) -This 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. +This 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. == I don't like this, how do I disable this? == You basically have three options: 1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: {{{ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules}}} - 2. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own udev rules file and set the NAME property. Make sure to order it before the default policy file, for example by naming it {{{/etc/udev/rules.d/70-my-net-names.rules}}} + 2. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own udev rules file and set the NAME property for the devices. Make sure to order it before the default policy file, for example by naming it {{{/etc/udev/rules.d/70-my-net-names.rules}}} 3. You alter the default policy file, for picking a different naming scheme, for example for naming all interface names after their MAC address by default: {{{cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules}}}, then edit the file there and change the lines as necessary. == How does the new naming scheme look like precisely? == -That's documented in detail in [[http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20|the sources of the net_id built-in]]. +That's documented in detail in a comment block [[http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20|the sources of the net_id built-in]]. Please refer to this in case you are wondering how to decode the new interface names. From 93aae43890f94b423eac6cf116e7eefbcec80141 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 21:12:16 +0000 Subject: [PATCH 06/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 440442d282..1e9649e105 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -24,7 +24,7 @@ With systemd 197 we have moved a scheme similar to biosdevname (put generally mo 4. Names incorporating the interfaces's MAC address 5. Classic, unpredictable kernel-native ethXXX naming -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.) +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. This 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. From e13da0ac1e4ed6d8ad5b21b65e031a7715f8dd38 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 21:14:27 +0000 Subject: [PATCH 07/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 1e9649e105..7c1e74527f 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -26,7 +26,7 @@ With systemd 197 we have moved a scheme similar to biosdevname (put generally mo 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. -This 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. +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. == I don't like this, how do I disable this? == From 80b0c64bcf1d37c79de831f92a7cd7168c288214 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 21:29:02 +0000 Subject: [PATCH 08/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 7c1e74527f..da2776a42f 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -12,7 +12,7 @@ Another solution that has been implemented is "biosdevname" which tries to find 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. -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. +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 that the "eth0" or "wlan0" everybody is used to. Example: enp5s0 == What has changed v197 precisely? == From cd6c4dd5713fbd62d9d141c38b0a1f7c534ec48d Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 21:29:44 +0000 Subject: [PATCH 09/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index da2776a42f..e1405c7697 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -12,7 +12,7 @@ Another solution that has been implemented is "biosdevname" which tries to find 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. -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 that the "eth0" or "wlan0" everybody is used to. Example: enp5s0 +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" == What has changed v197 precisely? == From 0adad03eb89f1cba5a63704abf90d63e2ae12f26 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 21:30:57 +0000 Subject: [PATCH 10/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index e1405c7697..80f4640f60 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -20,7 +20,7 @@ With systemd 197 we have moved a scheme similar to biosdevname (put generally mo 1. Names incorporating Firmware/BIOS provided index numbers for on-board devices 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers - 3. Names incorporating physical/geographical location of the hardware on the mainboard + 3. Names incorporating physical/geographical location of the connector of the on the mainboard 4. Names incorporating the interfaces's MAC address 5. Classic, unpredictable kernel-native ethXXX naming From adb51bc84d8d60b7d5bb26c00c137ab3681a6e24 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 21:31:23 +0000 Subject: [PATCH 11/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 80f4640f60..2235a1e2b5 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -20,7 +20,7 @@ With systemd 197 we have moved a scheme similar to biosdevname (put generally mo 1. Names incorporating Firmware/BIOS provided index numbers for on-board devices 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers - 3. Names incorporating physical/geographical location of the connector of the on the mainboard + 3. Names incorporating physical/geographical location of the connector of the hardware 4. Names incorporating the interfaces's MAC address 5. Classic, unpredictable kernel-native ethXXX naming From 2d2111748fdf9e38ff033a4db1b687ba5a849099 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 21:33:19 +0000 Subject: [PATCH 12/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 2235a1e2b5..22eed72040 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -22,7 +22,7 @@ With systemd 197 we have moved a scheme similar to biosdevname (put generally mo 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers 3. Names incorporating physical/geographical location of the connector of the hardware 4. Names incorporating the interfaces's MAC address - 5. Classic, unpredictable kernel-native ethXXX naming + 5. Classic, unpredictable kernel-native ethX naming 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. From 648f251ff934fef0ef794ca3d4537d0bd5be8f53 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 21:36:45 +0000 Subject: [PATCH 13/38] --- docs/PredictableNetworkInterfaceNames.moin | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 22eed72040..db269df0e9 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -18,11 +18,11 @@ We believe it is a good default choice to generalize the scheme pioneered by "bi With systemd 197 we have moved a scheme similar to biosdevname (put generally more powerful) into systemd/udev proper. A number of different naming schemes for network interfaces are now supported by udev natively: - 1. Names incorporating Firmware/BIOS provided index numbers for on-board devices - 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers - 3. Names incorporating physical/geographical location of the connector of the hardware - 4. Names incorporating the interfaces's MAC address - 5. Classic, unpredictable kernel-native ethX naming + 1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: {{{eno1}}}) + 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: {{{ens1}}}) + 3. Names incorporating physical/geographical location of the connector of the hardware (example: {{{enp2s0}}}) + 4. Names incorporating the interfaces's MAC address (example: {{{enx78e7d1ea46da}}}) + 5. Classic, unpredictable kernel-native ethX naming (example: {{{eth0}}}) 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. From a5d1717c40779675f5a5615049846e5af77a6e9a Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 21:41:35 +0000 Subject: [PATCH 14/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index db269df0e9..69a1405354 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -6,7 +6,7 @@ Starting with v197 systemd/udev will automatically assign predictable, stable ne 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. -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. As a result supporting for this has been removed from systemd/udev a while back. +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. As a result support for this has been removed from systemd/udev a while back. 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. (Unfortunately biosdevname did a lot more than this which is more problematic). From 128faa63f25a5ca0f1ac4747fdb2d6271543c55b Mon Sep 17 00:00:00 2001 From: "127.0.0.1" Date: Mon, 7 Jan 2013 22:00:47 +0000 Subject: [PATCH 15/38] typo fix --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 69a1405354..840741396a 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -16,7 +16,7 @@ We believe it is a good default choice to generalize the scheme pioneered by "bi == What has changed v197 precisely? == -With systemd 197 we have moved a scheme similar to biosdevname (put generally more powerful) into systemd/udev proper. A number of different naming schemes for network interfaces are now supported by udev natively: +With systemd 197 we have moved a scheme similar to biosdevname (but generally more powerful) into systemd/udev proper. A number of different naming schemes for network interfaces are now supported by udev natively: 1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: {{{eno1}}}) 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: {{{ens1}}}) From ce7c9f453aa39c8148e1d356d1fe79cfee1740a8 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 22:19:48 +0000 Subject: [PATCH 16/38] --- docs/PredictableNetworkInterfaceNames.moin | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 840741396a..15e6aa89f3 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -8,7 +8,7 @@ The classic naming scheme for network interfaces applied by the kernel is to sim 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. As a result support for this has been removed from systemd/udev a while back. -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. (Unfortunately biosdevname did a lot more than this which is more problematic). +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 devices via /dev/*/by-path/ symlinks. biosdevname departs from the low-level kernel device identification schemes that udev generally uses for these symlinks, and instead invents its own enumeration schemes. 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. @@ -16,7 +16,7 @@ We believe it is a good default choice to generalize the scheme pioneered by "bi == What has changed v197 precisely? == -With systemd 197 we have moved a scheme similar to biosdevname (but generally more powerful) into systemd/udev proper. A number of different naming schemes for network interfaces are now supported by udev natively: +With systemd 197 we have moved a scheme similar to biosdevname (but generally more powerful, and closer to kernel-internal device identification schemes) into systemd/udev proper. A number of different naming schemes for network interfaces are now supported by udev natively: 1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: {{{eno1}}}) 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: {{{ens1}}}) From f47346c3aa361244af50d6bdc4195617e58396bc Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 22:21:36 +0000 Subject: [PATCH 17/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 15e6aa89f3..07a3471015 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -8,7 +8,7 @@ The classic naming scheme for network interfaces applied by the kernel is to sim 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. As a result support for this has been removed from systemd/udev a while back. -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 devices via /dev/*/by-path/ symlinks. biosdevname departs from the low-level kernel device identification schemes that udev generally uses for these symlinks, and instead invents its own enumeration schemes. +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. biosdevname departs from the low-level kernel device identification schemes that udev generally uses for these symlinks, and instead invents its own enumeration schemes. 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. From 1f6bee93283807c6e6bcd2cfe11be65cd631b5f0 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 22:23:47 +0000 Subject: [PATCH 18/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 07a3471015..abe5ede07a 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -8,7 +8,7 @@ The classic naming scheme for network interfaces applied by the kernel is to sim 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. As a result support for this has been removed from systemd/udev a while back. -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. biosdevname departs from the low-level kernel device identification schemes that udev generally uses for these symlinks, and instead invents its own enumeration schemes. +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. 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. From fb30e224e7f108828c2dcc57d2c6b86b43d15fe0 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 22:26:14 +0000 Subject: [PATCH 19/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index abe5ede07a..25a5df1e8b 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -16,7 +16,7 @@ We believe it is a good default choice to generalize the scheme pioneered by "bi == What has changed v197 precisely? == -With systemd 197 we have moved a scheme similar to biosdevname (but generally more powerful, and closer to kernel-internal device identification schemes) into systemd/udev proper. A number of different naming schemes for network interfaces are now supported by udev natively: +With systemd 197 we have added native support for a number of different naming schemes into systemd/udevd properer 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: 1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: {{{eno1}}}) 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: {{{ens1}}}) From 13f79279b21d618d120869df1ef21301a7ceaeaf Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 7 Jan 2013 22:27:04 +0000 Subject: [PATCH 20/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 25a5df1e8b..bd44756000 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -16,7 +16,7 @@ We believe it is a good default choice to generalize the scheme pioneered by "bi == What has changed v197 precisely? == -With systemd 197 we have added native support for a number of different naming schemes into systemd/udevd properer 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: +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: 1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: {{{eno1}}}) 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: {{{ens1}}}) From b1661148acb696da7cd5dfb95c2762bc34159945 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Tue, 8 Jan 2013 02:02:24 +0000 Subject: [PATCH 21/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index bd44756000..3468d1800e 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -14,7 +14,7 @@ Finally, many distributions support renaming interfaces to user-chosen names (th 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" -== What has changed v197 precisely? == +== What precisely has changed in 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: From ee83da3a755959a8fd51cbd4550470bd7b3420f4 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Tue, 8 Jan 2013 17:59:33 +0000 Subject: [PATCH 22/38] --- docs/PredictableNetworkInterfaceNames.moin | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 3468d1800e..f4313ed3e3 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -6,7 +6,7 @@ Starting with v197 systemd/udev will automatically assign predictable, stable ne 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. -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. As a result support for this has been removed from systemd/udev a while back. +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. 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. @@ -28,6 +28,22 @@ By default, systemd v197 will now name interfaces following policy 1) if that in 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. +== Come again, what good does this do? == + +With this new scheme you now get: + + * Stable interface names across reboots (obviously) + * Stable interface names even when hardware is added or removed, i.e. no re-enumeration takes place + * Stable interface names when kernels or drivers are updated/changed + * 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 + * Fully stateless operation, changing the hardware configuration will not result in changes in /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 + * Applicability to both x86 and non-x86 machines + * The same on all distributions that adopted systemd/udev + * It's easy to opt out of the scheme (see below) + == I don't like this, how do I disable this? == You basically have three options: @@ -36,6 +52,6 @@ You basically have three options: 2. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own udev rules file and set the NAME property for the devices. Make sure to order it before the default policy file, for example by naming it {{{/etc/udev/rules.d/70-my-net-names.rules}}} 3. You alter the default policy file, for picking a different naming scheme, for example for naming all interface names after their MAC address by default: {{{cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules}}}, then edit the file there and change the lines as necessary. -== How does the new naming scheme look like precisely? == +== How does the new naming scheme look like, precisely? == That's documented in detail in a comment block [[http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20|the sources of the net_id built-in]]. Please refer to this in case you are wondering how to decode the new interface names. From d363512c92850b127cb4453fbf8bba0b01badcbd Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Tue, 8 Jan 2013 18:21:59 +0000 Subject: [PATCH 23/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index f4313ed3e3..0635e4884d 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -32,7 +32,7 @@ This combined policy is only applied as last resort. That means, if the system h With this new scheme you now get: - * Stable interface names across reboots (obviously) + * Stable interface names across reboots * Stable interface names even when hardware is added or removed, i.e. no re-enumeration takes place * Stable interface names when kernels or drivers are updated/changed * The names are automatically determined without user configuration, they just work From afce8ff3af6f523dcd4fb322730155b42a1aae43 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Tue, 8 Jan 2013 18:29:30 +0000 Subject: [PATCH 24/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 0635e4884d..0fbad0db97 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -1,3 +1,5 @@ +[[http://www.freedesktop.org/wiki/docs/|Back to systemd]] + = 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. From e2f9b633c4636acd9592b6b5a5fb24febc196f2a Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Tue, 8 Jan 2013 18:41:55 +0000 Subject: [PATCH 25/38] --- docs/PredictableNetworkInterfaceNames.moin | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 0fbad0db97..80dd6544ec 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -37,6 +37,7 @@ 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 * 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 * Fully stateless operation, changing the hardware configuration will not result in changes in /etc From 3c31f15cdb34f8ef4f49f576f0f2bf5aebf5370c Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Tue, 22 Jan 2013 20:16:41 +0000 Subject: [PATCH 26/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index 80dd6544ec..cefd166cec 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -47,6 +47,8 @@ With this new scheme you now get: * The same on all distributions that adopted 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. An administrator now has to check first what the local interface name is before he can invoke commands on it where previously he had a good chance that "eth0" was the right name. + == I don't like this, how do I disable this? == You basically have three options: From 54313217c1f499550c20c38b19a18c5058f9e9ca Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Tue, 22 Jan 2013 20:22:48 +0000 Subject: [PATCH 27/38] --- docs/PredictableNetworkInterfaceNames.moin | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin index cefd166cec..08b6707cb7 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.moin @@ -47,7 +47,7 @@ With this new scheme you now get: * The same on all distributions that adopted 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. An administrator now has to check first what the local interface name is before he can invoke commands on it where previously he had a good chance that "eth0" was the right name. +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 he can invoke commands on it where previously he had a good chance that "eth0" was the right name. == I don't like this, how do I disable this? == From cedf08c7746dde4dcbc04bd5d31e8a5329c9a4cf Mon Sep 17 00:00:00 2001 From: Joe Rayhawk Date: Sat, 18 May 2013 01:08:42 -0700 Subject: [PATCH 28/38] moin2mdwn: convert page docs/PredictableNetworkInterfaceNames --- ... => PredictableNetworkInterfaceNames.mdwn} | 86 ++++++++++--------- 1 file changed, 45 insertions(+), 41 deletions(-) rename docs/{PredictableNetworkInterfaceNames.moin => PredictableNetworkInterfaceNames.mdwn} (57%) diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.mdwn similarity index 57% rename from docs/PredictableNetworkInterfaceNames.moin rename to docs/PredictableNetworkInterfaceNames.mdwn index 08b6707cb7..42d56a4c53 100644 --- a/docs/PredictableNetworkInterfaceNames.moin +++ b/docs/PredictableNetworkInterfaceNames.mdwn @@ -1,62 +1,66 @@ -[[http://www.freedesktop.org/wiki/docs/|Back to systemd]] -= Predictable Network Interface Names = +[[Back to systemd|http://www.freedesktop.org/wiki/docs/]] -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. -== Why? == +# Predictable Network Interface Names -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. +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. -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. -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. +## Why? -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. +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. -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" +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. -== What precisely has changed in v197? == +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. -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: +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. - 1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: {{{eno1}}}) - 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: {{{ens1}}}) - 3. Names incorporating physical/geographical location of the connector of the hardware (example: {{{enp2s0}}}) - 4. Names incorporating the interfaces's MAC address (example: {{{enx78e7d1ea46da}}}) - 5. Classic, unpredictable kernel-native ethX naming (example: {{{eth0}}}) +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" -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. -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. +## What precisely has changed in v197? -== Come again, what good does this do? == +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: -With this new scheme you now get: +1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: `eno1`) +1. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: `ens1`) +1. Names incorporating physical/geographical location of the connector of the hardware (example: `enp2s0`) +1. Names incorporating the interfaces's MAC address (example: `enx78e7d1ea46da`) +1. Classic, unpredictable kernel-native ethX naming (example: `eth0`) +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. - * Stable interface names across reboots - * Stable interface names even when hardware is added or removed, i.e. no re-enumeration takes place - * 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 - * Fully stateless operation, changing the hardware configuration will not result in changes in /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 - * Applicability to both x86 and non-x86 machines - * The same on all distributions that adopted systemd/udev - * It's easy to opt out of the scheme (see below) +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. -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 he can invoke commands on it where previously he had a good chance that "eth0" was the right name. -== I don't like this, how do I disable this? == +## Come again, what good does this do? -You basically have three options: - - 1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: {{{ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules}}} - 2. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own udev rules file and set the NAME property for the devices. Make sure to order it before the default policy file, for example by naming it {{{/etc/udev/rules.d/70-my-net-names.rules}}} - 3. You alter the default policy file, for picking a different naming scheme, for example for naming all interface names after their MAC address by default: {{{cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules}}}, then edit the file there and change the lines as necessary. +With this new scheme you now get: -== How does the new naming scheme look like, precisely? == +* Stable interface names across reboots +* Stable interface names even when hardware is added or removed, i.e. no re-enumeration takes place +* 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 +* Fully stateless operation, changing the hardware configuration will not result in changes in /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 +* Applicability to both x86 and non-x86 machines +* The same on all distributions that adopted 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 he can invoke commands on it where previously he had a good chance that "eth0" was the right name. -That's documented in detail in a comment block [[http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20|the sources of the net_id built-in]]. Please refer to this in case you are wondering how to decode the new interface names. + +## I don't like this, how do I disable this? + +You basically have three options: + + 1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: `ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules` + 1. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own udev rules file and set the NAME property for the devices. Make sure to order it before the default policy file, for example by naming it `/etc/udev/rules.d/70-my-net-names.rules` + 1. You alter the default policy file, for picking a different naming scheme, for example for naming all interface names after their MAC address by default: `cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules`, then edit the file there and change the lines as necessary. + +## How does the new naming scheme look like, precisely? + +That's documented in detail in a comment block [[the sources of the net_id built-in|http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20]]. Please refer to this in case you are wondering how to decode the new interface names. From f42be39a18bf2885f5b52a921d5c65b5776c04f0 Mon Sep 17 00:00:00 2001 From: ColinGuthrie Date: Wed, 22 May 2013 01:55:30 -0700 Subject: [PATCH 29/38] Document the net.ifnames kernel command line. --- docs/PredictableNetworkInterfaceNames.mdwn | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/PredictableNetworkInterfaceNames.mdwn b/docs/PredictableNetworkInterfaceNames.mdwn index 42d56a4c53..96808a290f 100644 --- a/docs/PredictableNetworkInterfaceNames.mdwn +++ b/docs/PredictableNetworkInterfaceNames.mdwn @@ -1,4 +1,3 @@ - [[Back to systemd|http://www.freedesktop.org/wiki/docs/]] @@ -55,11 +54,12 @@ Does this have any drawbacks? Yes, it does. Previously it was practically guaran ## I don't like this, how do I disable this? -You basically have three options: +You basically have four options: - 1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: `ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules` - 1. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own udev rules file and set the NAME property for the devices. Make sure to order it before the default policy file, for example by naming it `/etc/udev/rules.d/70-my-net-names.rules` - 1. You alter the default policy file, for picking a different naming scheme, for example for naming all interface names after their MAC address by default: `cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules`, then edit the file there and change the lines as necessary. +1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: `ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules` +1. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own udev rules file and set the NAME property for the devices. Make sure to order it before the default policy file, for example by naming it `/etc/udev/rules.d/70-my-net-names.rules` +1. You alter the default policy file, for picking a different naming scheme, for example for naming all interface names after their MAC address by default: `cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules`, then edit the file there and change the lines as necessary. +1. You pass the net.ifnames=0 on the kernel command line (since v199) ## How does the new naming scheme look like, precisely? From 56fbd5310f46a9bd5452c0677ee1c81a18928115 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 9 Sep 2013 18:50:49 -0700 Subject: [PATCH 30/38] --- docs/PredictableNetworkInterfaceNames.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.mdwn b/docs/PredictableNetworkInterfaceNames.mdwn index 96808a290f..5f8a4f95e4 100644 --- a/docs/PredictableNetworkInterfaceNames.mdwn +++ b/docs/PredictableNetworkInterfaceNames.mdwn @@ -27,7 +27,8 @@ With systemd 197 we have added native support for a number of different naming p 1. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: `ens1`) 1. Names incorporating physical/geographical location of the connector of the hardware (example: `enp2s0`) 1. Names incorporating the interfaces's MAC address (example: `enx78e7d1ea46da`) -1. Classic, unpredictable kernel-native ethX naming (example: `eth0`) +1. Classic, unpredictable kernel-native ethX naming (example: `eth0`) + 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. 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. From 8745120c9901be20f742dd78d5578d5f3d768df5 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 9 Sep 2013 18:52:06 -0700 Subject: [PATCH 31/38] --- docs/PredictableNetworkInterfaceNames.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.mdwn b/docs/PredictableNetworkInterfaceNames.mdwn index 5f8a4f95e4..8db4e1d8ad 100644 --- a/docs/PredictableNetworkInterfaceNames.mdwn +++ b/docs/PredictableNetworkInterfaceNames.mdwn @@ -49,7 +49,8 @@ With this new scheme you now get: * The network interface naming now follows more closely the scheme used for aliasing block device nodes and other device nodes in /dev via symlinks * Applicability to both x86 and non-x86 machines * The same on all distributions that adopted systemd/udev -* It's easy to opt out of the scheme (see below) +* 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 he can invoke commands on it where previously he had a good chance that "eth0" was the right name. From b4584342c0e88b6e7b4cec9bad44fbf2d94edea2 Mon Sep 17 00:00:00 2001 From: ColinGuthrie Date: Fri, 21 Feb 2014 07:36:45 -0800 Subject: [PATCH 32/38] Deal with 80-net-setup-link.rules introduced in 209. --- docs/PredictableNetworkInterfaceNames.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/PredictableNetworkInterfaceNames.mdwn b/docs/PredictableNetworkInterfaceNames.mdwn index 8db4e1d8ad..5f06561f15 100644 --- a/docs/PredictableNetworkInterfaceNames.mdwn +++ b/docs/PredictableNetworkInterfaceNames.mdwn @@ -58,9 +58,9 @@ Does this have any drawbacks? Yes, it does. Previously it was practically guaran You basically have four options: -1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: `ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules` +1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: `ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules` (since v209: this file was called `80-net-name-slot.rules` in release v197 through v208) 1. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own udev rules file and set the NAME property for the devices. Make sure to order it before the default policy file, for example by naming it `/etc/udev/rules.d/70-my-net-names.rules` -1. You alter the default policy file, for picking a different naming scheme, for example for naming all interface names after their MAC address by default: `cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules`, then edit the file there and change the lines as necessary. +1. You alter the default policy file, for picking a different naming scheme, for example for naming all interface names after their MAC address by default: `cp /usr/lib/udev/rules.d/80-net-setup-link.rules /etc/udev/rules.d/80-net-setup-link.rules`, then edit the file there and change the lines as necessary. 1. You pass the net.ifnames=0 on the kernel command line (since v199) ## How does the new naming scheme look like, precisely? From c8f2c6b122e8dc463b0464dd653d8bcfb7c46627 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Thu, 12 Nov 2015 01:28:06 -0800 Subject: [PATCH 33/38] --- docs/PredictableNetworkInterfaceNames.mdwn | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/PredictableNetworkInterfaceNames.mdwn b/docs/PredictableNetworkInterfaceNames.mdwn index 5f06561f15..901bfd56a3 100644 --- a/docs/PredictableNetworkInterfaceNames.mdwn +++ b/docs/PredictableNetworkInterfaceNames.mdwn @@ -58,10 +58,9 @@ Does this have any drawbacks? Yes, it does. Previously it was practically guaran You basically have four options: -1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: `ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules` (since v209: this file was called `80-net-name-slot.rules` in release v197 through v208) -1. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own udev rules file and set the NAME property for the devices. Make sure to order it before the default policy file, for example by naming it `/etc/udev/rules.d/70-my-net-names.rules` -1. You alter the default policy file, for picking a different naming scheme, for example for naming all interface names after their MAC address by default: `cp /usr/lib/udev/rules.d/80-net-setup-link.rules /etc/udev/rules.d/80-net-setup-link.rules`, then edit the file there and change the lines as necessary. -1. You pass the net.ifnames=0 on the kernel command line (since v199) +1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: `ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules` +1. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own .link files in /etc/systemd/network/, that choose an explicit name or a better naming scheme for one, some, or all of your interfaces. See [[systemd.link(5)|http://www.freedesktop.org/software/systemd/man/systemd.link.html]] for more information. +1. You pass the net.ifnames=0 on the kernel command line ## How does the new naming scheme look like, precisely? From 86db1e35321595063f69130a769f9709a81dc060 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Thu, 12 Nov 2015 01:29:35 -0800 Subject: [PATCH 34/38] --- docs/PredictableNetworkInterfaceNames.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.mdwn b/docs/PredictableNetworkInterfaceNames.mdwn index 901bfd56a3..3cbd41e7f1 100644 --- a/docs/PredictableNetworkInterfaceNames.mdwn +++ b/docs/PredictableNetworkInterfaceNames.mdwn @@ -64,4 +64,4 @@ You basically have four options: ## How does the new naming scheme look like, precisely? -That's documented in detail in a comment block [[the sources of the net_id built-in|http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20]]. Please refer to this in case you are wondering how to decode the new interface names. +That's documented in detail in a comment block [[the sources of the net_id built-in|https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L20]]. Please refer to this in case you are wondering how to decode the new interface names. From 27eaa1bc7a553c46889ebe1e9b3cb9279ad432d1 Mon Sep 17 00:00:00 2001 From: TanuKaskinen Date: Mon, 14 Nov 2016 13:27:59 +0000 Subject: [PATCH 35/38] fix typo --- docs/PredictableNetworkInterfaceNames.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.mdwn b/docs/PredictableNetworkInterfaceNames.mdwn index 3cbd41e7f1..948f86edc4 100644 --- a/docs/PredictableNetworkInterfaceNames.mdwn +++ b/docs/PredictableNetworkInterfaceNames.mdwn @@ -56,7 +56,7 @@ Does this have any drawbacks? Yes, it does. Previously it was practically guaran ## I don't like this, how do I disable this? -You basically have four options: +You basically have three options: 1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: `ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules` 1. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own .link files in /etc/systemd/network/, that choose an explicit name or a better naming scheme for one, some, or all of your interfaces. See [[systemd.link(5)|http://www.freedesktop.org/software/systemd/man/systemd.link.html]] for more information. From e90d48ae3815ead9a1764e65069c1228b4df5d52 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Mon, 14 Nov 2016 19:46:52 +0000 Subject: [PATCH 36/38] --- docs/PredictableNetworkInterfaceNames.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.mdwn b/docs/PredictableNetworkInterfaceNames.mdwn index 948f86edc4..e5b8129d96 100644 --- a/docs/PredictableNetworkInterfaceNames.mdwn +++ b/docs/PredictableNetworkInterfaceNames.mdwn @@ -58,7 +58,7 @@ Does this have any drawbacks? Yes, it does. Previously it was practically guaran You basically have three options: -1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: `ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules` +1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's .link file for the default policy: `ln -s /dev/null /etc/systemd/network/99-default.link` 1. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own .link files in /etc/systemd/network/, that choose an explicit name or a better naming scheme for one, some, or all of your interfaces. See [[systemd.link(5)|http://www.freedesktop.org/software/systemd/man/systemd.link.html]] for more information. 1. You pass the net.ifnames=0 on the kernel command line From 4368c49697a16440e5652ae1af649d044de4ab17 Mon Sep 17 00:00:00 2001 From: LennartPoettering Date: Thu, 17 Nov 2016 17:52:54 +0000 Subject: [PATCH 37/38] --- docs/PredictableNetworkInterfaceNames.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/PredictableNetworkInterfaceNames.mdwn b/docs/PredictableNetworkInterfaceNames.mdwn index e5b8129d96..ea11a0432c 100644 --- a/docs/PredictableNetworkInterfaceNames.mdwn +++ b/docs/PredictableNetworkInterfaceNames.mdwn @@ -39,7 +39,7 @@ This combined policy is only applied as last resort. That means, if the system h 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 +* 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 From f9e6d49904e06d2cba3871f6873d0519fe086d0f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Tue, 11 Dec 2018 11:02:06 +0100 Subject: [PATCH 38/38] Rename to follow the convention Also remove trailing whitespace. --- ...es.mdwn => PREDICTABLE_INTERFACE_NAMES.md} | 57 +++++++++---------- 1 file changed, 27 insertions(+), 30 deletions(-) rename docs/{PredictableNetworkInterfaceNames.mdwn => PREDICTABLE_INTERFACE_NAMES.md} (85%) diff --git a/docs/PredictableNetworkInterfaceNames.mdwn b/docs/PREDICTABLE_INTERFACE_NAMES.md similarity index 85% rename from docs/PredictableNetworkInterfaceNames.mdwn rename to docs/PREDICTABLE_INTERFACE_NAMES.md index ea11a0432c..73d60477cd 100644 --- a/docs/PredictableNetworkInterfaceNames.mdwn +++ b/docs/PREDICTABLE_INTERFACE_NAMES.md @@ -1,62 +1,59 @@ -[[Back to systemd|http://www.freedesktop.org/wiki/docs/]] - - # 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. +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. ## 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. +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. -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. +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. -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. +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. -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. +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. -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" +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" ## What precisely has changed in 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: +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: -1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: `eno1`) -1. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: `ens1`) -1. Names incorporating physical/geographical location of the connector of the hardware (example: `enp2s0`) -1. Names incorporating the interfaces's MAC address (example: `enx78e7d1ea46da`) +1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: `eno1`) +1. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: `ens1`) +1. Names incorporating physical/geographical location of the connector of the hardware (example: `enp2s0`) +1. Names incorporating the interfaces's MAC address (example: `enx78e7d1ea46da`) 1. Classic, unpredictable kernel-native ethX naming (example: `eth0`) -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. +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. -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. +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. ## Come again, what good does this do? -With this new scheme you now get: +With this new scheme you now get: -* Stable interface names across reboots +* 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 -* Fully stateless operation, changing the hardware configuration will not result in changes in /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 -* Applicability to both x86 and non-x86 machines -* The same on all distributions that adopted systemd/udev +* 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 +* Fully stateless operation, changing the hardware configuration will not result in changes in /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 +* Applicability to both x86 and non-x86 machines +* The same on all distributions that adopted 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 he can invoke commands on it where previously he had a good chance that "eth0" was the right name. +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 he can invoke commands on it where previously he had a good chance that "eth0" was the right name. ## I don't like this, how do I disable this? -You basically have three options: +You basically have three options: 1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's .link file for the default policy: `ln -s /dev/null /etc/systemd/network/99-default.link` 1. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own .link files in /etc/systemd/network/, that choose an explicit name or a better naming scheme for one, some, or all of your interfaces. See [[systemd.link(5)|http://www.freedesktop.org/software/systemd/man/systemd.link.html]] for more information. @@ -64,4 +61,4 @@ You basically have three options: ## How does the new naming scheme look like, precisely? -That's documented in detail in a comment block [[the sources of the net_id built-in|https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L20]]. Please refer to this in case you are wondering how to decode the new interface names. +That's documented in detail in a comment block [[the sources of the net_id built-in|https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L20]]. Please refer to this in case you are wondering how to decode the new interface names.