Endereços MAC em placas-mãe dual-NIC


9

Aqui está um problema estranho.

Temos vários dispositivos com placas-mãe com duas placas de rede. Algumas são placas de rede Realtek, que são péssimas. Alguns são Intel e1000s, o que não acontece.

Acabei de notar em duas máquinas, uma é uma placa de rede Intel, uma é uma Realtek, que quando coloco o endereço MAC de uma máquina no dhcpd.confarquivo em nosso servidor DHCP para fazer com que o PXE inicialize a máquina em um ambiente de reconstrução, inicialmente está tudo bem.

O servidor recebe uma alocação de DHCP e o PXE é inicializado no ambiente pré-configurado do Ubuntu.

Em uma ou duas máquinas, chega até a configuração de rede DHCP do Ubuntu e falha. Se eu puxar um shell do busybox (ligado tty2na máquina de instalação) e executar ip link, posso ver que o sinalizador UP está definido na outra NIC.

Aqui estão algumas coisas.

  host xeon16-ghz240-gb48-node1 {
        hardware ethernet BC:AE:C5:07:1F:18;
        filename "pxelinux.0";
        next-server 192.168.123.80;
  }

É isso que está dhcpd.conf

É assim que se parece o link ip na máquina do mal. saída de link ip

Somente uma NIC está realmente conectada (deliberadamente).

Como você pode ver, a NIC que está na configuração do dhcpd não está marcada como UP, e o link que está UP não é o DHCP.

Até agora, eu vi isso em duas marcas de configuração de placa de rede dupla.

Alguém sabe 1) o que está causando isso eb) O que podemos fazer sobre isso?


1. Ordem diferente de inicialização de dispositivos PCI. Portanto, o BIOS usa o MAC ": 18" e o sistema operacional usa o MAC ": 19" primeiro. 2. Nenhuma idéia =]
Chris S

Acrescentarei isso como um comentário, em vez de uma resposta, porque é bastante fraco, mas posso dizer que alguém antes de mim encontrou exatamente o mesmo problema e o resolveu adicionando MAC e MAC + 1 ao dhcpd.confarquivo ao configurar um Kickstart.
Kyle Smith

Como é o preseed? Especificamente, está netcfg/choose_interfacedefinido?
Shane Madden

./master/master_preseed.cfg:d-i netcfg/choose_interface select auto
Tom O'Connor

@ KyleSmith Sim. É um pouco estocástico.
Tom O'Connor

Respostas:


8

Sempre há mais de uma maneira de fazer qualquer coisa :)

Solução 1

Placas-mãe com uma de cada?

Coloque na lista negra qualquer módulo ( ethtool -i eth0) que suporte a placa Realtek.

O Ubuntu suporta module_name.blacklist=yes a lista negra na inicialização e você deve poder alterar as opções do modprobe no ambiente pré-configurado para que não seja testado mais tarde.


Solução 2

Deixe-me reformular o problema:

Temos placas-mãe com duas placas de rede e queremos que elas funcionem de maneira consistente, independentemente da interface conectada. Nem sempre podemos determinar qual interface (do ponto de vista do SO) será conectada.

Configure a ligação! Use uma configuração ativo-passivo ( mode=active-backup miimon=100) com ambas as interfaces como escravos. Dessa forma, ele sempre funcionará, independentemente da interface conectada.


Solução 3

As placas-mãe são consistentes o suficiente para que as placas de rede sempre apareçam no mesmo PCI ID? Use as regras do udev para sempre atribuir a placa em um endereço PCI específico a eth0 e a placa no outro endereço a eth1.

Observe que você pode ter duas regras diferentes do udev que atribuem um dispositivo a eth0 - isso permite que você lide com o caso Realtek e e1000 ao mesmo tempo.


Os dois são da Realtek, infelizmente. Vamos conseguir alguns e1000s para substituí-los e provavelmente os matarão na bios.
Tom O'Connor

1
Ooohhhh, incompreendido. Pensei que você tivesse placas-mãe com 1 x e1000 e 1 x Realtek.
MikeyB

Boas respostas .. Não tenho certeza do que é suportado, pois esse problema tende a se apresentar entre o carregador PXE e o DHCP do instalador do debian. Pessoalmente, acho que a melhor opção será desativar todos, exceto um Intel NIC decente
Tom O'Connor

Acabamos configurando a ligação e resolvendo o problema colocando os dois endereços no DHCP.
Tom O'Connor

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.