Eu tive esse mesmo problema em uma caixa física rodando o Centos 7.3 x86_64 e consegui resolvê-lo movendo primeiro o adaptador físico para um slot PCI-X diferente na placa-mãe e fazendo o seguinte:
Remova o arquivo de configuração da interface da ponte:
rm -f /etc/sysconfig/network-scripts/ifcfg-br0
Remova o arquivo de configuração da interface do escravo:
rm -f /etc/sysconfig/network-scripts/ifcfg-enp6s0f0
Onde enp6s0f0 era o nome da interface do escravo original e era a única interface escrava atribuída à bridge br0
Certifique-se de remover completamente a ponte original, assegurando-se de que todos os traços dela tenham sumido (brctl show) não devem listar a interface da bridge br0.
Desligue a ponte:
ifconfig br0 down
Desligue o escravo:
ifdown enp6s0f0
ifconfig enp6s0f0 down
Pare o serviço de rede:
systemctl stop network.service
Remova manualmente a ponte, se necessário: (no meu caso, foi.)
Antes que a ponte possa ser removida, todas as interfaces escravas devem ser removidas dela. Você pode usar o utilitário de controle de ponte para removê-los
brctl delif br0 enp6s0f0
Uma vez que todas as interfaces escravas tenham sido removidas, a ponte em si pode ser removida.
brctl delbr br0
Confirme que nenhum arquivo de configuração restante faz referência a br0:
grep -i br0 /etc/sysconfig/network-scripts/ifcfg-*
Não devolverá nenhum resultado
No meu caso, o novo nome da interface baseado em mover o cartão um slot agora é enp5s0f0.
Inicie a interface e, em seguida, confirme com ethtool ou 'ip link', que deve informar que o link foi detectado para a interface.
[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 o nmcli para criar uma nova ponte.
O nmcli irá gravar os arquivos de configuração de interface necessários em / etc / sysconfig / network-scripts /
Crie a interface de ponte:
nmcli conn add type bridge ifname br0 ip4 10.0.0.16/24 gw4 10.0.0.1
Adicione a interface do escravo à ponte:
nmcli conn add type bridge-slave ifname enp5s0f0 master bridge-br0
Desabilite o protocolo de árvore de abrangência se a rede já tiver um mestre de árvore de abrangência:
nmcli con modify bridge-br0 bridge.stp no
Verifique se a ponte está configurada para iniciar na inicialização com nmcli:
nmcli con mod br0 connection.autoconnect yes
Neste ponto, posso iniciar e interromper o serviço de rede com êxito e, na reinicialização, a interface da ponte é iniciada corretamente.
Notas de solução de problemas:
Suspeito que omitir a linha:
TYPE=Bridge
do meu arquivo de configuração original para br0 pode ter levado a esse problema.
Eu também suspeito que não usar nmcli e criar manualmente os arquivos de interface de ponte também causou problemas. Isso pode acontecer porque o NetworkManager ainda está tentando gerenciar a interface. Isso pode ser confirmado com:
nmcli dev status
Este comando exibirá uma tabela que lista todas as interfaces de rede junto com seu STATE. Se o Network Manager não estiver controlando uma interface, seu STATE será listado como não gerenciado. Qualquer outro valor indica que a interface está sob controle do Network Manager.
Se você acabar modificando manualmente um arquivo ifcfg sob / etc / sysconfig / network-scripts, certifique-se de informar o gerenciador de rede sobre as mudanças com um recarregamento.
nmcli con reload
Isto irá dizer ao gerenciador de rede para reler todos os arquivos ifcfg e reconhecer quaisquer mudanças.
Eu encontrei o seguinte post:
Como faço para impedir que o Network Manager controle um interface?
Para quem não deseja usar o NetworkManager no RHEL / CENTOS 7.x
Uma outra pequena coisa que notei durante o teste foi que o contexto do selinux nos arquivos de configuração da interface original que eu tinha criado manualmente não era idêntico aos arquivos de configuração gerados automaticamente.
ls -lZ mostrou que os arquivos ifcfg gerados automaticamente tinham o seguinte contexto:
system_u: object_r: net_conf_t: s0
Considerando que os arquivos que criei tinham unconfined_u como usuário.
Eu usei chcon para definir o usuário como system_u
chcon system_u:object_r:net_conf_t:s0 ifcfg-<filename>
Outra observação é que ao trazer a nova interface de ponte para cima ou para baixo, o systemd agora relata corretamente que a interface está conectada e desconectada. Antes de fazer essas alterações, ao usar meus próprios arquivos de configuração gravados, o systemd parecia não ter consciência da interface. Isso mostraria que a interface foi configurada, mas não conectada. Apesar da detecção de links no relatório da ethtool.