RTNETLINK responde: O arquivo existe depois de adicionar o endereço ipv6

Question

Eu tenho batido minha cabeça contra a parede por um tempo nisso e não fiz nenhum progresso.

Eu tenho um sistema com um endereço ipv4 e ipv6 atribuído estaticamente. Após a inicialização executando systemctl status networking , resulta isso:

● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
  Drop-In: /run/systemd/generator/networking.service.d
       └─50-insserv.conf-$network.conf
   Active: failed (Result: exit-code) since Sat 2016-08-27 14:48:50 MST; 8min ago
     Docs: man:interfaces(5)
  Process: 3301 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
  Process: 3275 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle (code=exited, status=0/SUCCESS)
 Main PID: 3301 (code=exited, status=1/FAILURE)

Aug 27 14:48:25 phoenix systemd[1]: Starting Raise network interfaces...
Aug 27 14:48:28 phoenix ifup[3301]: /sbin/ifup: waiting for lock on /run/network/ifstate.ens160
Aug 27 14:48:50 phoenix ifup[3301]: RTNETLINK answers: File exists
Aug 27 14:48:50 phoenix ifup[3301]: Failed to bring up ens160.
Aug 27 14:48:50 phoenix systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Aug 27 14:48:50 phoenix systemd[1]: Failed to start Raise network interfaces.
Aug 27 14:48:50 phoenix systemd[1]: networking.service: Unit entered failed state.
Aug 27 14:48:50 phoenix systemd[1]: networking.service: Failed with result 'exit-code'.

Mas a interface está ativa e funcionando corretamente.

Se eu executar systemctl restart networking , ele falhará. A execução de ifdown ens160 apenas diz que a interface não está configurada.

Se eu forçar a interface com ifdown --force ens160 , ela será desativada e retornará com ifup ens160 ou systemctl restart networking .

Se eu comentar a seção do ipv6, tudo bem após a inicialização.

Aqui está o meu arquivo de interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto ens160
iface ens160 inet static
    address XXX.XXX.XXX.3/24
    gateway XXX.XXX.XXX.1
    dns-search example.org
    dns-nameservers ::1 127.0.0.1

# This is an IPv6 interface
iface ens160 inet6 static
    address XXXX:XXXX:XXXX:XXXX::3/64
    gateway XXXX:XXXX:XXXX:XXXX::1

Isso é feito com uma instalação do servidor vanilla Ubuntu 16.04.1 em um cluster vmware com apenas o servidor bind9 e ssh instalado. As únicas alterações de configuração feitas são um bind9 configurado corretamente e as mudanças de IP estático.

Eu tenho mais de uma instalação fazendo a mesma coisa.

Fiz muita pesquisa e não encontrei nada que correspondesse a essa situação. Meu google-fu é geralmente strong, mas falhou comigo desta vez.

Qualquer ajuda que eu pudesse receber seria muito apreciada.

    

Answer 1

Como funciona quando você comenta a linha do gateway, você sofre de uma infeliz condição de corrida: assim que o link da interface é ativado, o Linux começa a fazer descobertas de vizinhança e aceitar propagandas de rotas, que podem colocar rotas IPv6 em seu caminho. tabela de roteamento, embora a interface ainda não esteja totalmente configurada. Quando o script tentar adicionar a rota padrão, você receberá RTNETLINK answers: File exists . Para contornar isso, você pode comentar a linha do gateway (que é a maneira recomendada desde que as rotas sejam anunciadas corretamente em sua rede) ou desabilitar a aceitação de RAs via sysctl -w net.ipv6.conf.device.accept_ra=0 (dispositivo sendo um dispositivo real, padrão ou todos) .