CentOS 7 Vagrant VM pierde parcialmente la conectividad de red

Estoy usando una caja base Vagrant de construcción propia que ejecuta una instalación mínima de CentOS 7 (la creé siguiendo la documentación de Vagrant; si desea más información, describí el proceso en un artículo en mi sitio web y puede descargar la máquina desde aquí) .

Antes de aprovisionar la máquina con Ansible (que es irrelevante para esta pregunta), uso el siguiente archivo Vagrant para abrir la caja:

Vagrant.configure(2) do |config|
  config.vm.box = "relativkreativ/centos-7-minimal"
  config.vm.network "public_network", ip: "192.168.0.100", bridge: 'en0: WLAN (AirPort)'

  config.vm.provision "file", source: "~/.ssh/id_rsa.pub", destination: "~/id_rsa.pub"
  config.vm.provision "shell", inline: <<-END.gsub(/^\s{4}/, '')
    mkdir -m 0700 /root/.ssh
    mv /home/vagrant/id_rsa.pub /root/.ssh/authorized_keys
    chmod 0600 /root/.ssh/authorized_keys
    chown root:root /root/.ssh/authorized_keys
  END
end

No hay nada lujoso aquí, solo agrego una interfaz de red adicional y copie mi clave pública.

Al iniciar sesión en el servidor como root ( ssh root@192.168.0.100), a veces recibo una tubería rota después de unos segundos y el servidor no tiene ping (a veces incluso mientras se ejecuta el manifiesto Ansible). La mayoría de las veces puedo volver a conectarme después de algunos intentos, pero cuando esto no es posible, tengo que usar Vagrant para iniciar sesión ( vagrant sshesto siempre funciona) y reiniciar el servicio de red ( systemctl restart network.service). Después de eso, SSH funciona de nuevo por algún tiempo.

Las rutas del servidor:

[root@localhost ~]# ip route
default via 10.0.2.2 dev enp0s3 
10.0.2.0/24 dev enp0s3  proto kernel  scope link  src 10.0.2.15 
169.254.0.0/16 dev enp0s3  scope link  metric 1002 
169.254.0.0/16 dev enp0s8  scope link  metric 1003 
192.168.0.0/24 dev enp0s8  proto kernel  scope link  src 192.168.0.100

Las interfaces de red:

[root@localhost ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    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
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:c0:9e:5b brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 84324sec preferred_lft 84324sec
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:b6:45:8c brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.100/24 brd 192.168.0.255 scope global enp0s8
       valid_lft forever preferred_lft forever

Sus archivos de configuración:

[root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-lo 
DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
# If you're having problems with gated making 127.0.0.0/8 a martian,
# you can change this to something else (255.255.255.255, for example)
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback

[root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-enp0s3
HWADDR="08:00:27:C0:9E:5B"
TYPE="Ethernet"
BOOTPROTO="dhcp"
DEFROUTE="yes"
PEERDNS="yes"
PEERROUTES="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_PEERDNS="yes"
IPV6_PEERROUTES="yes"
IPV6_FAILURE_FATAL="no"
NAME="enp0s3"
UUID="957d70e5-1097-4952-b3a4-dc67b919b934"
ONBOOT="yes"

[root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-enp0s8
#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
NM_CONTROLLED=no
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.0.100
NETMASK=255.255.255.0
DEVICE=enp0s8
PEERDNS=no
#VAGRANT-END

Inhabilité IPv6 para solucionar problemas, pero esto no marcó la diferencia.

Esto también sucede cuando ejecuto exactamente el mismo flujo de trabajo con mi caja CentOS 6 Vagrant (que construí exactamente de la misma manera), y también con las cajas Vagrant que otras personas construyeron.

Estoy usando la última versión de Vagrant (1.7.2) así como VirtualBox (4.3.20). No cambié nada en la configuración de red predeterminada de VirtualBox.

¿Alguien tiene alguna idea de lo que está pasando aquí? No puedo rastrear este problema.

¡Muchas gracias!

Para mí, funcionó para deshabilitar el NetworkManager cuando tuve el mismo problema (pero con la red solo de host)