Newsgroup: it.comp.os.linux.sys
Titolo: ethernet che si "addormenta"

Ho un cazzutissimo problema, su una singola VM.
Di punto in bianco, quando cessa il traffico, dopo X tempo (X ignoto e variabile)
la scheda di rete smette di rispondere.
 
Unica soluzione: generare traffico dall'interno della macchina verso l'esterno.
Un semplice ping è perfetto.
 
Mi era capitato, molto molto molto tempo fa su un altro server e sinceramente non
ricordo come avevo risolto (sempre che abbia risolto prima di dismettere il server)
 
La cosa buffa è che questa VPS è ospitata su un hypervisor assieme ad altre decine
di macchine, di conseguenza la porta sullo switch è la medesima.
 
Non ci sono VLAN.
Questa VM è l'unica ad avere problemi.
Visto che è virtuale, è connessa alla medesima interfaccia fisica del nodo,
nodo che è sempre bello reattivo e, come scritto sopra, nessun altra VM
che condivide la medesima interfaccia fisica (ed il medesimo switch) ha problemi.
 
Debian 9.2
 
Non ho la *minima* idea di cosa controllare. Quando il traffico si blocca,
come ad esempio adesso, la scheda risulta correttamente operativa, lato Debian.
 
Non è il firewall.
tcpdump mostra solo il traffico dello switch (quindi la scheda è viva), del tipo
BPDU e compagnia bella.
 
Lato hypervisor il bonding è OK, le due interfacce affasciate sono entrambe
OK, un bel tcpdump mostra sempre il solito traffico dello switch.
 
Se faccio partire un ping da qualunque altro server verso qualunque altro server
su questo nodo, lo vedo transitare. Se pingo la VM problematica, non c'è alcun
segno di vita, finchè non faccio l'operazione inversa da *dentro* la VM (un
banale ping verso google, ad esempio, sblocca tutto)

che scheda e che driver e' ?
 
ha il risparmio energetico attivo?

 ping verso google, ad esempio, sblocca tutto)
 
Il che mi lascia pensare che sia versamente una situazione
specifica di *quella* vm, ovviamente.
 
Dunque se fossi io andrei a controllare i logs di quella macchina
virtuale, magari a vedere se udev o systemd ci stanno mettendo lo
zampino… Anche se non mi pare di aver trovato nulla di rilevante
cercando "Debian network suspend" o simili…

 variabile) la scheda di rete smette di rispondere.
 
La butto li ...
Hai controllato i parametri della rete: NETMASK e co. ?
 
 

 Hai controllato i parametri della rete: NETMASK e co. ?
 
Bravissimo!
 
Avrebbe un sacco di senso! Se la Netmask è sbagliata, la VM
potrebbe essere irraggiungibile. Ma un ping andrebbe a generare
un Route Redirect. La macchina virtuale andrebbe a pingare
correttamente, e le ARP conterrebbero il suo indirizzo.  Per un
po'.
 
Poi quando le altre macchine dimenticano il MAC della virtuale,
ecco che torna ad essere irraggiungibile.
 
Sounds like a thing to check!

 ha il risparmio energetico attivo?
 
No, ed anche se fosse, sarebbe su tutto il nodo, non solo su una singola VM
 

 Hai controllato i parametri della rete: NETMASK e co. ?
 
Si

 Hai controllato i parametri della rete: NETMASK e co. ?
 
Ok, va bene, sono un coglione.
Typo nell'indirizzo, c'è un conflitto di IP :)
 


giuro stavo per scriverti di controllare.
sono sintomi che uno dei tanti coglioni che ci sono passati prima di te 
riconosce al volo :-)

Il Fri, 12 Jan 2018 09:17:39 -0800, gandalf.corvotempesta ha scritto:
 

tranqui', ho visto di peggio, proprio settimana scorsa. 
Il mio collega su una Ubuntu ha invertito le righe "address" e "gateway" 
e si e' assegnato l'IP del gateway. 
Noi abbiamo un floating gateway, che lavora contemporaneamente per 2 
datacenter, che andando in errore su datacenter A, faceva failover su B, 
e tutti i server in A, provavano a usare il suo server come gateway 
(anche se avesse avuto il forwarding abilitato, non avrebbe funzionato, 
perche' avendo invertito le righe, aveva a sua volta il suo IP come 
gateway). 
 
Risultato: uno dei due datacenter era misteriosamente KO. 
 
Io dal canto mio, ho aggiunto un controllo in Terraform (ma in quel caso 
si era trattato di una migrazione senza terraform). 
Il collega che si occupare delle configurazioni del router ha trovato un 
modo per bannare determinati IP. 
 
-- 
Massimiliano Adamo

 e si e' assegnato l'IP del gateway. 
 
Scusate la domanda sciocca, ma …non è per questo che esiste il
DHCP? :)


Usiamo IPAM. 
La risposta sciocca e' che usiamo sempre e solo configurazioni dual-stack 
IP (ipv6 e ipv4) pubblici e non e' salutare usare DHCP per servizi 
esterni. 
 
Quando uso i miei tool tutto funziona a meraviglia: attingo i dati da 
NIPAP (una implementazione di IPAM), li registro su Infoblox (un DNS) e 
li uso su terraform. 
Ovviamente IPAM non mi dara' mai l'IP del router. 
 
-- 
Massimiliano Adamo

 Usiamo IPAM.
 
p.s.: ovviamente sulla LAN dell'ufficio (Laptop, Workstation) usiamo DHCP
 
 
 
-- 
Massimiliano Adamo

 esterni. 
 
Ah ok. Scusa la domanda stupida ^_^


Lieto di essere stato utile a un "collega" :)
 
 
Dopo tanti anni di lavoro ancora non cessa di stupirmi
il casino che può fare un parametro di rete errato.
 
-- 
Stefano L.