☰

Error de RTNETLINK "el archivo existe" al intentar crear una interfaz que anteriormente era ficticia

tag-icon • tag-icon linux networking interface
Error de RTNETLINK "el archivo existe" al intentar crear una interfaz que anteriormente era ficticia

Linux menta 20.2

Utilicé este comando para crear una interfaz Ethernet ficticia llamada veth0:

sudo ip link add veth0 type dummy

Una vez terminado lo eliminé con:

sudo ip link delete veth0 type dummy

La interfaz fue definitivamente eliminada. Después de reiniciar, intenté crear una interfaz virtual de tipo Ethernet con:

sudo ip link add veth0 type veth

Pero cuando hago esto aparece el error "el archivo existe".

Me permite volver a crear una interfaz de tipo ficticia con el primer comando. ¿Dónde podría estar haciendo referencia al nombre de la interfaz para evitar que se reutilice como un tipo de Ethernet virtual?

Mi investigación ha arrojado muchas publicaciones similares, pero todas generalmente hacen referencia a un problema con las interfaces físicas que no pueden usar el comando ifup. La solución es vaciar las direcciones en la interfaz y asegurarse de que no haya más de una puerta de enlace listada en /etc/network/interfaces. Ninguna solución se aplica aquí. No encontré nada acerca de que los nombres de las interfaces virtuales no sean reutilizables para diferentes tipos de interfaces después de eliminar el tipo anterior.

Me doy cuenta de que podría usar un nombre de interfaz diferente, pero me gustaría solucionar este problema de configuración y entender qué lo ha causado.

Respuesta1

Este problema es reproducible pero se debe a la elección de un nombre que interfiere con la elección predeterminada realizada por el kernel.

Cuando no se especifica un nombre para la interfaz del par, se agrega el número entero más bajo posible para vethcrear el nombre del par.primero. Esto sucede primero, antes de que se cree la interfaz principal. Esto se puede ver cuando se especifica un nombre que no puede entrar en conflicto:

# ip link add name myveth type veth
# ip link show type veth
17: veth0@myveth: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 2a:93:f8:8e:bc:b6 brd ff:ff:ff:ff:ff:ff
18: myveth@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 8a:c3:1d:82:93:a6 brd ff:ff:ff:ff:ff:ff

el nombre del par se elige de la forma habitual: cree una interfaz con el tipo y el siguiente entero disponible añadido: veth+ 0: veth0. El índice más bajo (aquí 17 versus 18) significa que se crea primero.

Ahora bien, si uno especifica el mismo nombre que el kernel crea automáticamente primero, se produce un conflicto, la interfaz especificada no se crea y, por lo tanto, la interfaz del mismo nivel se elimina. No hay rastro excepto un RTNETLINK answers: File exists. Esto se puede ver claramente cuando se ejecuta en un shell separado ip link monitor:

caparazón 1:

$ ip link monitor

caparazón 2:

# ip link add name veth0 type veth
RTNETLINK answers: File exists

caparazón 1 nuevamente:

23: veth0@NONE: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether 72:2d:b8:9f:90:6c brd ff:ff:ff:ff:ff:ff
Deleted 23: veth0@NONE: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether 72:2d:b8:9f:90:6c brd ff:ff:ff:ff:ff:ff

Esto @NONEsignifica que no hay ningún índice de enlace de pares asociado... todavía. Una vethinterfaz tiene un índice de enlace entre pares: el otro lado del cable Ethernet virtual. Debería haber resuelto el índice de enlace de pares a la siguiente interfaz recién creada con el índice 24, pero luego esta interfaz no se pudo crear con el nombre veth0porque ya existía (incluso si eso se debe a su propia creación). Esto provoca la cancelación de toda la operación y la eliminación del efímero, veth0así como el mensaje de error enviado de vuelta File exists, de lo contrario no deja rastro del problema.

Conclusión: para evitar cualquier enfrentamiento,

  • no especifique ningún nombre y deje que el kernel los elija:

    ip link add type veth

    conseguir:

    24: veth0@veth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN group default 
    link/ether 2a:93:f8:8e:bc:b6 brd ff:ff:ff:ff:ff:ff
25: veth1@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN group default 
    link/ether 86:70:54:05:0f:75 brd ff:ff:ff:ff:ff:ff

  • especificar un nombre que no siga el esquema de nomenclatura predeterminado

    ip link add name myveth type veth

  • o especifique ambos nombres, incluso si no están en el orden predeterminado, el kernel los creará en su esquema de nombres predeterminado (peer as veth0y main as veth1):

    ip link add name veth0 type veth peer name veth1

  • No olvide que vethlas interfaces son la mayoría de las veces (pero no siempre) inútiles fuera de los entornos de espacios de nombres de red. La interfaz de pares se puede agregar directamente en otro lugar si es necesario:

    ip netns add othernamespace
ip link add name veth0 type veth peer netns othernamespace

    donde el par también se creará veth0sin ningún conflicto.

    # ip link show type veth
27: veth0@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 2a:93:f8:8e:bc:b6 brd ff:ff:ff:ff:ff:ff link-netns othernamespace
# ip -n othernamespace link show type veth
2: veth0@if27: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether fa:cb:bf:23:fc:a6 brd ff:ff:ff:ff:ff:ff link-netnsid 0

información relacionada