Erro "arquivo existe" RTNETLINK ao tentar criar a interface veth que anteriormente era fictícia

Erro "arquivo existe" RTNETLINK ao tentar criar a interface veth que anteriormente era fictícia

Linux Mint 20.2

Usei este comando para criar uma interface Ethernet fictícia chamada veth0:

sudo ip link add veth0 type dummy

Depois de terminar, removi-o com:

sudo ip link delete veth0 type dummy

A interface foi definitivamente removida. Após uma reinicialização, tentei criar uma interface do tipo Ethernet virtual com:

sudo ip link add veth0 type veth

Mas quando faço isso recebo o erro "arquivo existe".

Isso me permite recriar uma interface de tipo fictício com o primeiro comando novamente. Onde poderia estar referenciando o nome da interface para evitar que ela fosse reutilizada como um tipo de Ethernet virtual?

Minha pesquisa gerou muitas postagens semelhantes, mas todas geralmente fazem referência a um problema com interfaces físicas que não conseguem usar o comando ifup. A correção é liberar os endereços na interface e garantir que não haja mais de um gateway listado em /etc/network/interfaces. Nenhuma das correções se aplica aqui. Não encontrei nada sobre nomes de interfaces virtuais que não sejam reutilizáveis ​​para diferentes tipos de interface após a remoção do tipo anterior.

Sei que poderia usar um nome de interface diferente, mas gostaria de resolver esse problema de configuração e entender o que o causou.

Responder1

Este problema é reproduzível, mas se deve à escolha de um nome que interfere na escolha padrão feita pelo kernel.

Ao não especificar um nome para a interface de peer, o número inteiro mais baixo possível é anexado para vethconstruir o nome do peerprimeiro. Isso acontece primeiro, antes da criação da interface principal. Isso pode ser visto quando se especifica um nome que não pode entrar em conflito:

# 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

o nome do peer é escolhido da maneira usual: crie uma interface com o tipo e o próximo número inteiro disponível anexado a ela: veth+ 0: veth0. O índice mais baixo (aqui 17 versus 18) significa que é criado primeiro.

Agora, se alguém especificar o mesmo nome que o kernel cria automaticamente primeiro, ocorre um conflito, a interface especificada não é criada e a interface peer é excluída. Nenhum rastro, exceto um arquivo RTNETLINK answers: File exists. Isso pode ser visto claramente ao executar em um shell separado ip link monitor:

concha 1:

$ ip link monitor

casca 2:

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

casca 1 novamente:

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

Aqui @NONEsignifica que não há nenhum índice de link de peer associado... ainda. Uma vethinterface possui um índice de link de mesmo nível: o outro lado do fio Ethernet virtual. Deveria ter resolvido o índice de link de peer para a próxima interface recém-criada com o índice 24, mas essa interface não pôde ser criada com o nome veth0porque já existia (mesmo que seja por causa de sua própria criação). Isso aciona o cancelamento de toda a operação e a exclusão do efêmero, veth0bem como da mensagem de erro enviada de volta como File exists, caso contrário, não deixará nenhum rastro do problema.

Conclusão: para evitar qualquer conflito,

  • não especifique nenhum nome e deixe o kernel escolhê-los:

    ip link add type veth
    

    recebendo:

    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
    
  • especifique um nome que não siga o esquema de nomenclatura padrão

    ip link add name myveth type veth
    
  • ou especifique ambos os nomes, mesmo que não sejam a ordem padrão, eles seriam criados pelo kernel em seu esquema de nomenclatura padrão (peer as veth0e main as veth1):

    ip link add name veth0 type veth peer name veth1
    
  • não se esqueça que vethas interfaces são na maioria das vezes (mas nem sempre) inúteis fora dos ambientes de namespace de rede. A interface peer pode ser adicionada diretamente em outro lugar, se necessário:

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

    onde o par também será criado veth0sem qualquer conflito.

    # 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
    

informação relacionada