51 06/04/2026 07/04/2026 3 min

Riparare l’unità hardware Proxmox sulle schede di rete Intel

Quando un nodo Proxmox mostra problemi sulla rete Intel, il sintomo può sembrare generico: interfacce che flappano, VM irraggiungibili, bridge che perdono connettività, latenza anomala o log pieni di messaggi del driver. La parte importante è non partire subito dal cambio di hardware: prima si isola il layer guasto, poi si decide se il problema è firmware, driver, offload, negoziazione del link, cablaggio o difetto fisico della NIC.

In pratica, su Proxmox il rischio maggiore è confondere un problema di origin hardware con un effetto a valle: il nodo sembra instabile, ma la causa può essere un modulo kernel non adatto, una porta switch con autonegotiation mal gestita, una feature offload incompatibile, oppure un transceiver SFP non supportato. La sequenza giusta è sempre: osservare, isolare, mitigare, poi correggere in modo strutturale.

Quale layer sta fallendo

Per prima cosa conviene classificare il guasto nel layer corretto: DNS, edge, origin, app, DB o storage. Qui il sospetto è quasi sempre nel layer origin, cioè il nodo Proxmox stesso, ma va confermato con evidenza minima.

  1. Se il problema è solo verso alcune VM o solo su alcune VLAN, il nodo è probabilmente sano e il guasto è nel bridge, nel tagging o nello switch.
  2. Se l’interfaccia fisica sparisce, flappa o passa da UP a DOWN, la causa è più probabile su driver, firmware, cavo, porta switch o alimentazione della NIC.
  3. Se il nodo risponde in console ma perde rete sotto carico, il sospetto va su offload, interrupt, driver o saturazione della scheda.

La prima verifica utile è leggere lo stato del link e i log kernel recenti:

ip link show
ethtool <interfaccia>
dmesg -T | egrep -i 'igb|ixgbe|i40e|ice|e1000e|link up|link down|firmware|reset|timeout|error'

Se la scheda Intel è una famiglia server recente, i driver più comuni sono igb, ixgbe, i40e o ice. Se i log mostrano reset, timeout, firmware mismatch o link down ripetuti, la diagnosi si sposta subito da “rete generica” a “stack NIC/firmware”.

Diagnosi probabile

Le ipotesi più plausibili, in ordine, sono queste:

  1. Driver o firmware non allineati: il kernel vede la NIC ma il modulo non gestisce bene quella revisione hardware. Si falsifica in pochi minuti confrontando versione kernel, modulo e messaggi in dmesg.
  2. Negoziazione link o compatibilità fisica: cavo, porta switch, speed/duplex, autonegotiation o transceiver non supportato. Si falsifica con ethtool, cambio cavo/porta e controllo dei contatori di errore.
  3. Offload o feature avanzate instabili: TSO, GSO, GRO, checksum offload, VLAN offload o LRO possono introdurre comportamenti intermittenti con alcuni switch o driver. Si falsifica disabilitando temporaneamente una feature alla volta e osservando se il problema sparisce.

Un quarto caso, meno frequente ma reale, è il difetto fisico della porta o della scheda. Qui i test software possono sembrare normali fino al momento del carico o del calore, quindi serve anche un controllo incrociato su porta diversa, cavo diverso e, se possibile, NIC diversa nello stesso nodo.

Verifiche immediate

L’obiettivo è raccogliere evidenza senza cambiare ancora nulla. Se hai accesso alla console locale o a IPMI/iDRAC/iLO, meglio: in caso di perdita rete non resti cieco.

  1. Controlla lo stato delle interfacce e del bridge Proxmox.
ip -br link
ip -br addr
bridge link

Atteso: l’interfaccia fisica è UP, il bridge principale è UP, l’IP del management è presente sulla bridge corretta. KO: interfaccia flapping, bridge senza slave attivi, IP mancante.