Por qué, en los GNU/Linux systemd, los nombres de las interfaces de red cambiaron, y se dejó de lado el clásico «eth0/eth1/wlan0/etc» por una nueva nomenclatura tipo enp3s0 o eno1.

Nombres predecibles en las interfaces de red - Predictable Network Interface Names

Desde la versión v197 de systemd/udev automáticamente se asignan nombres de interfaces de red predecibles y persistentes para todas las interfaces de red Ethernet, WLAN y WWAN, en contra del nombrado tradicional eth0, eth1, wlan0, etc… con la intención de solucionar problemas reales en la detección y configuración de interfaces.

¿Por qué se hace esto?

El esquema clásico para nombrar las interfaces de red aplicado por el kernel permitía asignar nombres del estilo eth0, eth1, eth2, wlan0, wlan1, etc a todas las interfaces de red que tienen drivers detectados.

Como el checkeo de todos los controladores no es generalmente predecible en las tecnologías modernas, esto significa que tan pronto como múltiples interfaces de red estén disponibles, se les asignarán nombres como eth0, eth1, etc, ni bien se detecten, y no hay seguridad de que estos nombres sean los mismos… lo que quiere decir que una interfaz que inicialmente se llama «eth0», al siguiente inicio del sistema puede llamarse «eth1».

Como se puede ver, esto puede causar graves inconvenientes de seguridad, por ejemplo, las reglas de un firewall que está codificada para cierto nombre de interfaz serán muy sensibles al cambio del nombre de dicha interfaz de red.

Nombre interfaz de red

• en: Este prefijo significaría que la interfaz de red es del tipo Ethernet (LAN)
• wl: En este caso se haría referencia a un interfaz del tipo inalámbrica (WLAN).
• ww: Aquí se haría referencia a una interfaz de red de área amplia inalámbrica (WWAN)

Para contruir este identificador SystemD puede utilizar hasta cinco estrategias distintas:

onboard (o)

para la que se utiliza un índice que asigna el firmware a los dispositivos integrados. Por ejemplo, eno1.

slot (s)

para la que se utiliza un número asociado a la ranura PCI utilizada. Por ejemplo, ens1.

path (p)

para la que se utiliza la localización física del conector. Por ejemplo, para las dos tarjetas antes detectadas los nombres serán wlp1s0 y enp2s0, puesto que la salida de lspci nos las ubica en 01:00.0 y 02:00.0 respectivamente.

mac (x)

para la que se utiliza la dirección MAC de la tarjeta. Por ejemplo, enx8c47be459a06 para la interfaz ethernet de nuestro ejemplo (véase la salida de ip link show)

nombre clásico

la cual no es en realidad una estrategia predecible: simplemente es el nombre clásico que asigna el kernel a la interfaz. Se nombrará así, si no ha habido forma de nombrarla mediante un nombre predecible.

Por mucho tiempo udev asignó nombres del estilo «ethX» a las interfaces de red, e intentó mantenerlos basándose en la dirección MAC del hardware. Esto ocasionó muchos problemas, entre ellos:

• Se requiere un directorio raíz (root) con permisos de escritura para algunos subdirectorios.
• El arranque de una imagen del sistema operativo en una computadora da como resultado una configuración cambiada de la imagen original, ya que los nombres de dispositivos deben asignarse al vuelo.
• En muchos sistemas, las direcciones MAC no son realmente fijas, como en dispositivos embebidos y equipos virtualizados.

No obstante, el mayor problema es que los componentes del espacio de usuario que requieren un nombre compiten contra el núcleo para obtener el suyo, siempre en el espacio de nombres «ethX», y esta «carrera» por obtener los nombres a veces falla. Como resultado, el soporte para este tipo de nomenclatura fue eliminado en systemd/udev.

Otra solución que se ha implementado es la denominada «biosdevname«, que trata de encontrar información de topología de «slot fijo» en ciertas interfaces de firmware, y utilizarlas para asignar nombres fijos a las interfaces que incorporan su ubicación física en la placa base. En cierto modo, este esquema de nombres es similar a lo que ya se hace de forma nativa en udev para varios nodos de dispositivos a través de los enlaces simbólicos de /dev/*/by-path/. En muchos casos, biosdevname se aleja de los esquemas de identificación de dispositivos de kernel de bajo nivel que generalmente utiliza udev para estos enlaces simbólicos, y en su lugar inventa sus propios esquemas de enumeración.

Finalmente, muchas distribuciones admiten el cambio de nombre de las interfaces a los nombres elegidos por el usuario (por ejemplo: «internet0«, «dmz0«, …) y descodifican sus direcciones MAC o ubicaciones físicas como parte de sus scripts de red. Esta es una muy buena opción, pero tiene el problema de que implica que el usuario esté dispuesto y sea capaz de elegir y asignar estos nombres.

Asignar nombres fijos basados ​​en información de firmware/topología/ubicación tiene la gran ventaja de que los nombres son completamente automáticos, totalmente predecibles, que permanecen fijos incluso si se agrega o quita hardware (es decir, no se realiza una nueva enumeración) y que el hardware dañado puede reemplazarse sin problemas. Dicho esto, es cierto que a veces son más difíciles de leer que los «eth0» o «wlan0» a los que todo el mundo está acostumbrado, que un nombre del tipo «enp0s3«… de eso no hay duda 

¿Qué es lo que cambió en la v197?

Con systemd v197 se ha agregado compatibilidad nativa para una serie de políticas de nombres diferentes en systemd/udevd propiamente dicho, y se hizo un esquema similar al de biosdevname, pero generalmente más potente y más cercano a los esquemas de identificación de dispositivos internos del núcleo.

Los siguientes esquemas de nombres diferentes para las interfaces de red ahora son compatibles con udev de forma nativa, y se se puede ver el orden de selección de las políticas de nombramiento de las interfaces de red.

1. Si los nombres que incorporan el Firmware/BIOS proporcionan los números de índices para los dispositivos conectados (ejemplo, en01), se aplica esa información. Si no, se utiliza el esquema 2.
2. Si los nombres que incorporan el Firmware/BIOS proporcionan los números de las ranuras PCI Express (ejemplo, ens1), se aplica esa información. Si no, se utiliza el esquema 3.
3. Si el hardware incorpora información de ubicación física del conector (ejemplo, enp2s0), se aplica esta política.
   En caso contrario, se aplica el esquema 5 para cualquier otro caso.
4. Los nombres que incorporan la dirección MAC no es utilizado por defecto, pero está disponible si se quiere implementar (ejemplo, enx78e7d1ea46da).
5. Si no se pueden aplicar ninguna de las políticas anteriores, se utiliza la nomenclatura tradicional del kernel (ejemplo, eth0, eth1, etc).

Esta política combinada solo se aplica como último recurso. Eso significa que, si el sistema tiene biosdevname instalado, tendrá prioridad. Si el usuario ha agregado reglas udev que cambian el nombre de los dispositivos kernel, estos tendrán prioridad también. Además, cualquier esquema de nomenclatura específico de distribución generalmente tiene prioridad.

¿Que ganamos con este nuevo esquema?

• Nombres fijos de interfaces de red entre reinicios del sistema.
• Nombres fijos de interfaces de red incluso si se agrega o remueve hardware, ya que nunca se lleva a cabo una re-enumeración.
• Nombres fijos de interfaces de red cuando se cambian o actualizan controladores o el mismo kernel.
• Nombres fijos de interfaces de red incluso si se ha removido una interfaz de red rota y se la cambia por una nueva.
• Los nombres son determinados automáticamente sin configuraciones adicionales de usuario.
• Los nombres de las interfaces de red son predecibles completamente… por ejemplo, solo mirando la salida de un lspci podrás saber los nombres que tendrán las interfaces de red en el sistema.
• Cambiando las configuraciones del hardware no se producirán cambios en el directorio /etc, lo que le da compatibilidad con un directorio «/» de solo lectura.
• Los nombres de las interfaces de red ahora siguen más de cerca el esquema utilizado por el bloque de alias de dispositivos de bloque (sda1, sda2, sdb6, etc) y otros dispositivos del /dev basados en enlaces simbólicos.
• Políticas de nombres aplicables tanto cualquier arquitectura, tanto x86 como no.
• Las mismas políticas para todas las distribuciones de GNU/Linux que adopten systemd/udev.
• Es fácil salirse de este esquema y configurar nombres a nivel de usuario.

Pero… no todas son rosas… y sí, hay algunos inconvenientes. Con las nomenclaturas previas, prácticamente se garantizaba que los ordenadores equipados con una sola interfaz de red tendrían un simple «eth0«. Con este nuevo esquema, en su lugar, un administrador tendrá que verificar primero el nombre de las interfaces locales antes de invocar comandos que previamente funcionaban con «eth0».

Y… ¿si quiero desactivar esto? Volver al eth0

Para algunos estos nuevos nombres de interfaces de red pueden parecer horribles… pero hay algunas opciones para cambiar los nombres de las interfaces:

• Deshabilita la asignación de nombres fijos, de modo que los nombres de kernel no predecibles se vuelvan a utilizar. Para esto, simplemente enmascare el archivo .link de udev para la política predeterminada: 

udevadm info --query=property --value --property=ID_NET_LINK_FILE /sys/class/net/eno1
/usr/lib/systemd/network/99-default.link

Por tanto, si escribiéramos:

# /etc/systemd/network/98-default.link
[Match]
OriginalName=*

[Link]
NamePolicy=mac

y, con todas las interfaces desactivas, forzásemos el renombrado:

systemctl restart systemd-udev-trigger

Las dos interfaces anteriores pasarían a formar el nombre a partir de su MAC. Podemos, por supuesto, dar un nombre concreto a una interfaz (a ser posible que no coincida con un nombre clásico para evitar problemas):

# /etc/systemd/network/70-cableada.link
[Match]
Path=pci-0000:02:00.0

[Link]
Name=cable0

Donde para referir la interfaz hemos preferido usar su path inmutable, el cual puede consultarse cuál es con:

udevadm info --query=property --value --property=ID_PATH /sys/class/net/eno1
pci-0000:02:00.0

Una alternativa sería mantener el nombre predecible y añadir como nombre alternativo el que gustemos[8], para lo cual podríamos hacer:

ln -s /lib/systemd/network/99-default.link /etc/systemd/network/98-cableada.link

mkdir /etc/systemd/network/98-cableada.link.d

cat > /etc/systemd/network/98-cableada.link.d/alternativo.conf
[Match]
Path=pci-0000:02:00.0

[Link]
AlternativeName=cable0

Detección interfaces en Linux

Con el comando:

 lspci | grep -i ethernet

 Ejemplo resultado:

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)

 

Conclusión

Ahora sabemos por qué los las nuevas implementaciones y distros GNU/Linux que están basadas en systemd tienen este importante cambio en los nombres de interfaces.

Se que a muchos les ha disgustado esta nueva forma de nomenclatura, y les resulta incómodo incluso para typear comandos y configuraciones… pero claro está que esta nueva forma de nombrar interfaces de red tiene sus propósitos, y soluciona algunos problemas de detección de hardware.

Esto me recuerda a los dispositivos de bloque, discos y particiones… en un momento un si teníamos un dispositivo solo no había problema, pero con, por ejemplo, dos discos, corríamos el riesgo de que en un inicio el disco sda pasara a llamarse sdb, y el sistema no arrancase… razón por la cual comenzamos a utilizar UUID’s en el archivo /etc/fstab… al final, la solución fue aceptada casi por todos.

 Para conocer el nombre de las interfaces de red, podemos utilizar varios comandos:

    Utilizando el comando ip

    $ ip addr
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host
           valid_lft forever preferred_lft forever
    2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000    link/ether 7c:05:07:10:1f:45 brd ff:ff:ff:ff:ff:ff
        inet 192.168.1.4/24 brd 192.168.1.255 scope global dynamic eno1
           valid_lft 81236sec preferred_lft 81236sec
        inet6 fe80::ee44:7f49:ca5b:b85d/64 scope link
           valid_lft forever preferred_lft forever

    La línea 8 indica que el nombre de la interfaz de red cableada del ejemplo es eno1.

    Utilizando el comando ifconfig

        

    $ sudo ifconfig
    [sudo] password for usuario:
    eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500        inet 192.168.1.4  netmask 255.255.255.0  broadcast 192.168.1.255
            inet6 fe80::ee44:7f49:ca5b:b85d  prefixlen 64  scopeid 0x20<link>
            ether 7c:05:07:10:1f:45  txqueuelen 1000  (Ethernet)
            RX packets 266871  bytes 323755934 (308.7 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 87242  bytes 15092450 (14.3 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 20  memory 0xf7100000-f7120000  
     
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1  (Local Loopback)
            RX packets 41660  bytes 16320629 (15.5 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 41660  bytes 16320629 (15.5 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

    La línea 3 indica que el nombre de la interfaz de red cableada del ejemplo es eno1.

    Utilizando el comando nmcli

    Con el comando nmcli connection show se obtiene una descripción general de los perfiles de conexión activos.

    $ nmcli connection show
    NOMBRE              UUID                                  TIPO             DISPOSITIVO
    Wired connection 1  0bc1e9cb-14c4-4839-99dc-c14c7a1ba654  802-3-ethernet   eno1

    La línea 3 indica que el nombre de la interfaz de red cableada del ejemplo es eno1.

 

 

Fuente:

https://juncotic.com/eth0-enp0s3-nombres-interfaces-red-linux/

https://wiki.gentoo.org/wiki/Handbook:X86/Full/Networking/es

https://www.zeppelinux.es/como-configurar-el-entorno-de-red-en-debian-desde-una-terminal/