faretesto > comp.os.* > comp.os.linux.sys

gandalf.corvotempesta (11.01.2018, 18:13)
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 ilserver)

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 fisicadel 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)
sacarde (11.01.2018, 18:21)
che scheda e che driver e' ?

ha il risparmio energetico attivo?
dacav (12.01.2018, 09:31)
On 2018-01-11, gandalf.corvotempesta
<gandalf.corvotempesta> wrote:
> Di punto in bianco, quando cessa il traffico, dopo X tempo (X
> ignoto e variabile)


Ah, per capire di che X si parla, prova con X -version :D :D :D
</joke>

> Unica soluzione: generare traffico dall'interno della macchina
> verso l'esterno. Un semplice ping Ŕ perfetto.


Il che mi lascia pensare a qualcosa che va in sleep, e viene
successivamente svegliato dal tuo ping.

> 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)


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?
Stefano L. (12.01.2018, 10:07)
gandalf.corvotempesta wrote:

> 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.


La butto li ...
Hai controllato i parametri della rete: NETMASK e co. ?
dacav (12.01.2018, 10:11)
On 2018-01-12, Stefano L. <nomail> wrote:
> La butto li ...
> 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!
gandalf.corvotempesta (12.01.2018, 19:15)
Il giorno giovedý 11 gennaio 2018 17:21:22 UTC+1, sacarde ha scritto:
> che scheda e che driver e' ?


E' virtual: VirtIO

> ha il risparmio energetico attivo?


No, ed anche se fosse, sarebbe su tutto il nodo, non solo su una singola VM
gandalf.corvotempesta (12.01.2018, 19:15)
Il giorno venerdý 12 gennaio 2018 09:07:34 UTC+1, Stefano L. ha scritto:
> La butto li ...
> Hai controllato i parametri della rete: NETMASK e co. ?


Si
gandalf.corvotempesta (12.01.2018, 19:17)
Il giorno venerdý 12 gennaio 2018 09:07:34 UTC+1, Stefano L. ha scritto:
> La butto li ...
> Hai controllato i parametri della rete: NETMASK e co. ?


Ok, va bene, sono un coglione.
Typo nell'indirizzo, c'Ŕ un conflitto di IP :)
rootkit (12.01.2018, 20:11)
Il Fri, 12 Jan 2018 09:17:39 -0800, gandalf.corvotempesta ha scritto:

> Il giorno venerdý 12 gennaio 2018 09:07:34 UTC+1, Stefano L. ha scritto:
>> La butto li ...
>> 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 :-)
Max_Adamo (14.01.2018, 15:58)
Il Fri, 12 Jan 2018 09:17:39 -0800, gandalf.corvotempesta ha scritto:

> Il giorno venerdý 12 gennaio 2018 09:07:34 UTC+1, Stefano L. ha scritto:
>> La butto li ...
>> Hai controllato i parametri della rete: NETMASK e co. ?

> Ok, va bene, sono un coglione.
> Typo nell'indirizzo, c'Ŕ un conflitto di IP :)


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.
dacav (14.01.2018, 16:59)
On 2018-01-14, Max_Adamo <maxadamo> wrote:
> 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.


Scusate la domanda sciocca, ma ?non Ŕ per questo che esiste il
DHCP? :)
Max_Adamo (14.01.2018, 19:05)
Il Sun, 14 Jan 2018 14:59:58 +0000, dacav ha scritto:

> On 2018-01-14, Max_Adamo <maxadamo> wrote:
> 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.
Max_Adamo (14.01.2018, 19:10)
Il Sun, 14 Jan 2018 17:05:53 +0000, Max_Adamo ha scritto:

>> Scusate la domanda sciocca, ma ?non Ŕ per questo che esiste il DHCP? :)

> Usiamo IPAM.


p.s.: ovviamente sulla LAN dell'ufficio (Laptop, Workstation) usiamo DHCP
dacav (15.01.2018, 09:20)
On 2018-01-14, Max_Adamo <maxadamo> wrote:
>> 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.


Ah ok. Scusa la domanda stupida ^_^
Stefano L. (15.01.2018, 09:32)
gandalf.corvotempesta wrote:

> Il giorno venerdý 12 gennaio 2018 09:07:34 UTC+1, Stefano L. ha scritto:
>> La butto li ...
>> Hai controllato i parametri della rete: NETMASK e co. ?

> Ok, va bene, sono un coglione.
> Typo nell'indirizzo, c'Ŕ un conflitto di IP :)


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.
Discussioni simili