Tuve este mismo problema en una caja física que ejecuta Centos 7.3 x86_64 y pude resolverlo moviendo primero el adaptador físico a una ranura PCI-X diferente en la placa base y luego haciendo todo lo siguiente:
Elimine el archivo de configuración de la interfaz del puente:
rm -f /etc/sysconfig/network-scripts/ifcfg-br0
Elimine el archivo de configuración de la interfaz esclava:
rm -f /etc/sysconfig/network-scripts/ifcfg-enp6s0f0
Donde enp6s0f0 era el nombre original de la interfaz esclava, y era la única interfaz esclava asignada al puente br0
Asegúrese de eliminar por completo el puente original, asegurándose de que todos los rastros del mismo hayan desaparecido (brctl show) no deberían incluir la interfaz del puente br0.
Apaga el puente:
ifconfig br0 down
Apaga al esclavo:
ifdown enp6s0f0
ifconfig enp6s0f0 down
Detenga el servicio de red:
systemctl stop network.service
Retire manualmente el puente si es necesario: (En mi caso, lo fue).
Antes de que se pueda quitar el puente, se deben quitar todas las interfaces esclavas. Puede usar la utilidad de control de puente para eliminarlos
brctl delif br0 enp6s0f0
Una vez que se han eliminado todas las interfaces esclavas, se puede eliminar el puente en sí.
brctl delbr br0
Confirme que no quedan archivos de configuración de referencia br0:
grep -i br0 /etc/sysconfig/network-scripts/ifcfg-*
No debería devolver resultados
En mi caso, el nuevo nombre de interfaz basado en mover la tarjeta hacia arriba una ranura ahora es enp5s0f0.
Inicie la interfaz y luego confirme con ethtool, o 'ip link', que debería informar que se detectó ese enlace para la interfaz.
[root@phaser ~]# ifconfig enp5s0f0 up
[root@phaser ~]# ethtool enp5s0f0
Settings for enp5s0f0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on (auto)
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Use nmcli para crear un nuevo puente.
nmcli escribirá los archivos de configuración de interfaz necesarios en / etc / sysconfig / network-scripts /
Cree la interfaz del puente:
nmcli conn add type bridge ifname br0 ip4 10.0.0.16/24 gw4 10.0.0.1
Agregue la interfaz esclava al puente:
nmcli conn add type bridge-slave ifname enp5s0f0 master bridge-br0
Deshabilite el protocolo de árbol de expansión si la red ya tiene un maestro de árbol de expansión:
nmcli con modify bridge-br0 bridge.stp no
Asegúrese de que el puente esté configurado para iniciarse en el arranque con nmcli:
nmcli con mod br0 connection.autoconnect yes
En este punto, puedo iniciar y detener el servicio de red con éxito, y al reiniciar, la interfaz del puente se inicia correctamente.
Notas de solución de problemas:
Sospecho que omite la línea:
TYPE=Bridge
desde mi archivo de configuración original para br0 puede haber llevado a este problema. También sospecho que no usar nmcli y crear manualmente los archivos de interfaz del puente también causó problemas. Esto puede deberse a que NetworkManager todavía está intentando administrar la interfaz. Esto se puede confirmar con:
nmcli dev status
Este comando mostrará una tabla que enumera todas las interfaces de red junto con su ESTADO. Si Network Manager no controla una interfaz, su ESTADO aparecerá como no administrado. Cualquier otro valor indica que la interfaz está bajo el control de Network Manager.
Si termina modificando manualmente un archivo ifcfg en / etc / sysconfig / network-scripts, asegúrese de informar al administrador de red de los cambios con una recarga.
nmcli con reload
Esto le indicará al administrador de red que vuelva a leer todos los archivos ifcfg y reconozca cualquier cambio.
Encontré la siguiente publicación:
¿Cómo evito que Network Manager controle una interfaz?
Para aquellos que no quieren usar NetworkManager en RHEL / CENTOS 7.x
Otra cosa menor que noté durante las pruebas fue que el contexto de selinux en los archivos de configuración de interfaz originales que había creado manualmente no era idéntico a los archivos de configuración generados automáticamente.
ls -lZ mostró que los archivos ifcfg generados automáticamente tenían el siguiente contexto:
system_u: object_r: net_conf_t: s0
Mientras que los archivos que creé tenían unconfined_u como usuario.
Usé chcon para configurar el usuario en system_u
chcon system_u:object_r:net_conf_t:s0 ifcfg-<filename>
Otra observación es que cuando se activa o desactiva la nueva interfaz del puente, systemd ahora informa correctamente que la interfaz está conectada y desconectada. Antes de hacer estos cambios, al usar mis propios archivos de configuración escritos por mí mismo, systemd parecía no tener conocimiento de la interfaz. Mostraría que la interfaz estaba configurada pero no conectada. A pesar de la detección de enlaces de informes de ethtool.