Problema de NIC fantasma fazendo com que eth0 / 1 caia

Question

Estamos passando por um problema muito estranho e frustrante. Nossa empresa tem servidores aqui em Massachusetts, assim como na Califórnia. Os problemas que estamos vendo são apenas no hardware da CA. Na CA, temos várias centenas de servidores Dell R300 e Dell R310, todos conectados a quatro switches HP Procurve 4208vl. Existem dois switches para cada modelo, um para a rede front-end e um para a rede back-end. Esses sistemas são colocados em clusters e todos são usados em vários testes que testamos nosso SO de software que estamos desenvolvendo. Muitos desses testes exigem reinicializações sucessivas e / ou repetidas. Muitos, se não a maioria dos testes, reprovisionam os nós com o Os novamente. O problema é que, ao dar tempo suficiente, aparentemente, aleatoriamente, um (ou muitos) desses sistemas terá uma interface eth0 ou eth1 abatida.

O problema é que o nó inicializará intermitentemente sem conectividade em eth0 ou eth1, às vezes em ambos. A solução alternativa é SSH via backend (se eth0 estiver inativa) ou frontend (se eth1 estiver inativa) e executar ifdown / ifup na interface downed.

Lista de soluções alternativas: - reinicialização da rede de serviço - ifdown eth1 (ou eth0), então ifup eth1 (ou eth0) - recolocar os cabos de rede - reinicie o servidor

Isso é um grande problema para a equipe de desenvolvimento, pois impedirá que clusters inteiros executem seus testes até a intervenção manual.

A pior parte ocorre quando um nó inicializa o busybox para uma instalação do SO e a eth0 cai: neste caso, o nó é completamente inacessível, pois não temos eth1 no busybox, e a instalação do sistema operacional não pode continuar porque Não é possível falar com o servidor PXE para extrair a imagem mais recente do sistema operacional (já que a eth0 está inativa). Os nós que caírem nesse estado ficarão presos assim até a próxima vez que eu chamar alguém da CA no telefone e fazer com que ele reinicialize o nó manualmente.

O seguinte foi feito para tentar resolver esse problema aparentemente aleatório e irreproduzível:

• O Procurve Switch e o firmware do R310 foram atualizados para as revisões mais recentes possíveis.
• Ambos os Switches e Servidores configurados para Autonegotiate (1000 / FULL DUPLEX).
• Estamos vendo isso em quatro diferentes switches HP e em cerca de 200 a 400 servidores Dell (todos comprados em momentos diferentes, portanto, não é muito ruim).
• Não temos esse problema em outro hardware da CA, incluindo as Dell 860s e 750s conectadas ao seu próprio switch HP Procurve.
• Esse problema não parece acontecer quando os nós são conectados a um comutador diferente (embora não tenhamos o hardware para testar completamente em um comutador diferente).

Antes da atualização do firmware, os registros do switch HP Procurve mostram:

• transmissões excessivas detectadas na porta x
• alta colisão ou taxa de queda na porta x
• erros excessivos de CRC / alinhamento na porta x

Após a atualização do firmware, vemos menos desses erros, mas eles ainda persistem.

Para a solução de problemas, tenho registrado as informações usuais:

ifconfig ; for n in 0 1; do ethtool eth$n;ethtool -i eth$n;ethtool -k eth$n;ethtool 
-S eth$n; done; dmesg | egrep 'eth|bnx|e1000'; cat /var/log/messages > /tmp/eth_issues

Aqui estão alguns exemplos de saída:

# ethtool -i eth0
driver: bnx2
version: 2.1.6
firmware-version: 6.4.5 bc 5.2.3 NCSI 2.0.11
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes

# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on

 # ethtool -S eth0
 NIC statistics:
 rx_bytes: 0
 rx_error_bytes: 0
 tx_bytes: 5676016
 tx_error_bytes: 0
 rx_ucast_packets: 0
 rx_mcast_packets: 0
 rx_bcast_packets: 0
 tx_ucast_packets: 0
 tx_mcast_packets: 7
 tx_bcast_packets: 10495
 tx_mac_errors: 0
 tx_carrier_errors: 0
 rx_crc_errors: 0
 rx_align_errors: 0
 tx_single_collisions: 0
 tx_multi_collisions: 0
 tx_deferred: 0
 tx_excess_collisions: 0
 tx_late_collisions: 0
 tx_total_collisions: 0
 rx_fragments: 0
 rx_jabbers: 0
 rx_undersize_packets: 0
 rx_oversize_packets: 0
 rx_64_byte_packets: 0
 rx_65_to_127_byte_packets: 0
 rx_128_to_255_byte_packets: 0
 rx_256_to_511_byte_packets: 0
 rx_512_to_1023_byte_packets: 0
 rx_1024_to_1522_byte_packets: 0
 rx_1523_to_9022_byte_packets: 0
 tx_64_byte_packets: 1054
 tx_65_to_127_byte_packets: 7
 tx_128_to_255_byte_packets: 0
 tx_256_to_511_byte_packets: 0
 tx_512_to_1023_byte_packets: 9441
 tx_1024_to_1522_byte_packets: 0
 tx_1523_to_9022_byte_packets: 0
 rx_xon_frames: 0
 rx_xoff_frames: 0
 tx_xon_frames: 0
 tx_xoff_frames: 0
 rx_mac_ctrl_frames: 0
 rx_filtered_packets: 0
 rx_ftq_discards: 0
 rx_discards: 0
 rx_fw_discards: 0

Passamos incontáveis horas no telefone com a Dell e a HP e não conseguimos descobrir o que está causando esse problema. Inicialmente, pensamos que as atualizações de firmware iriam consertar isso, mas depois de ir a lugar nenhum, ambas as empresas afirmam que não podem suportar o hardware de nenhuma das partes e se recusam a ajudar mais do que isso.

Alguém pode me ajudar a rastrear esse problema até a causa raiz? Lembre-se de que nunca sei quando ou qual sistema será o culpado e o sistema operacional é muito recomprimido, portanto, instalar o software para ajudar a registrar isso é inútil, já que ele será perdido durante o próximo provisionamento do produto. Qualquer ajuda ou insight que você possa fornecer seria apreciado. Quaisquer palpites ou pensamentos são bem-vindos também. Por favor, deixe-me saber se você precisar de mais detalhes ou saída postada. Obrigado.

    

Answer 1

A resposta é: obtenha uma placa de rede melhor e observe para nunca mais comprar a Broadcom:

link

    

Answer 2

Honestamente, duvido que seja um problema com o hardware neste momento ... e mais um problema com o driver subjacente no sistema operacional que você está tentando inicializar. Em minha própria experiência, o driver bnx2 é notório por ser bastante terrível ... como foi escrito pela Broadcom para tentar fazer os usuários de opensource felizes, mas não muito mais que isso. Você já tentou baixar / construir drivers diretamente da broadcom? Seria mais interessante ver o que está na quantidade insana de pacotes de broadcast ... (leia isso como tente capturar pacotes entre o NIC e o Switch) e jogue isso na Boadcom para feedback. O (s) antigo (s) switch (es) pode (m) não ter reclamado, porque eles não se incomodaram em lidar com a inundação de pacotes ruins ... (grande quantidade de erros relatados no novo switch)

    

Answer 3

Temos vários R300 e R310 - e nunca tivemos um problema depois de inicializá-los. BTW - o que o suporte da Dell diz ao seu caso?

Então, meu palpite é que há algo errado no lado da rede do hardware (Procurve Switches). No entanto, se eu fosse você, escreveria uma solução simples:

Um script de inicialização que é executado em um estágio final e faz o ifdown / ifup se nenhum link for detectado em eth0 ou eth1.

BTW: eth0 e eth1 estão ambos a bordo? Então ambos devem ser capazes de fazer o PXE-boot (eu não estou trabalhando agora, então eu não tenho certeza sobre o número de interfaces onboard - eu costumo usar os irmãos maiores R510, R710, ...).