Recentemente, meu servidor doméstico e host de VMs começou, do nada, a perder a conectividade de rede. Por fora parecia que ele ainda estava funcionando, mas eu não conseguia acessá-lo remotamente de nenhuma forma. O adaptador ethernet parecia ligado, segundo o switch, então o problema devia estar em algum lugar do software.
Não seria a primeira vez que um driver causaria travamentos na conexão de rede. No passado, já me ferrei com drivers de WiFi bugados em computadores Linux e Windows.
Depois de fuçar um pouco nos logs do sistema, me deparei com o seguinte:
vmhost kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
vmhost kernel: TDH <0>
vmhost kernel: TDT <1>
vmhost kernel: next_to_use <1>
vmhost kernel: next_to_clean <0>
vmhost kernel: buffer_info[next_to_clean]:
vmhost kernel: time_stamp <10fbc2f81>
vmhost kernel: next_to_watch <0>
vmhost kernel: jiffies <10fbc3871>
vmhost kernel: next_to_watch.status <0>
vmhost kernel: MAC Status <40080083>
vmhost kernel: PHY Status <796d>
vmhost kernel: PHY 1000BASE-T Status <7800>
vmhost kernel: PHY Extended Status <3000>
vmhost kernel: PCI Status <10>
vmhost kernel: e1000e 0000:00:1f.6 eth0: Reset adapter unexpectedly
vmhost kernel: vmbr0: port 1(eth0) entered disabled state
Aí ele resetava o adaptador de rede e, depois de um tempo, fazia tudo de novo, até a máquina ficar completamente offline.
Procurando respostas na internet, encontrei esta thread no ServerFault.
Causa
Lendo várias fontes e listas de relatórios de bugs, parece que a melhor forma de reproduzir o problema é colocar o dispositivo numa situação de alta largura de banda, ou seja, transmitir grandes quantidades de dados que saturem a interface.
No meu caso, isso costumava acontecer quando eu estava transmitindo mídia do servidor Plex local para algum dispositivo. Pela forma como a rede está montada, a VM Windows que roda a instância do Plex precisa buscar o arquivo de mídia em um compartilhamento de rede NFS em outro dispositivo, transcodificá-lo na VM e só então enviá-lo ao dispositivo de reprodução.
Isso soma bastante tráfego de rede, geralmente ~40-100mbit/s, dependendo do dispositivo que reproduz o arquivo e da qualidade do arquivo de origem.
O mesmo problema apareceu ao transmitir jogos via Steam Link para a nossa Apple TV. A conexão é cabeada, mas não é incomum a rede cair. Acho que está relacionado ao mesmo problema, mas vou ficar de olho para ver se acontece de novo depois da correção.
Possível correção
Parece que uma possível correção seria desabilitar GSO (Generic Segmentation Offload), TSO (TCP Segmentation Offload) e GRO (Generic Receive Offload) na interface de rede*:
ethtool -K eth0 gso off gro off tso off
Apliquei isso na minha configuração e estou esperando para ver se realmente resolve o problema a longo prazo.
Notas de rodapé
* Essas opções têm a ver com delegar a segmentação de pacotes ao controlador da interface de rede para reduzir o uso de CPU da máquina. Mais detalhes podem ser encontrados neste artigo da Wikipédia.