FreeBSD: Come risolvere "ping: sendto: spazio sul buffer non disponibile"?

Sto cercando di eseguire il ping di un host remoto, ma viene visualizzato un errore.

# ping 192.168.80.1
PING 192.168.80.1 (192.168.80.1): 56 data bytes
ping: sendto: No buffer space available
ping: sendto: No buffer space available
^C
--- 192.168.80.1 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

Funziona con altri host:

# ping 192.168.16.1
PING 192.168.16.1 (192.168.16.1): 56 data bytes
64 bytes from 192.168.16.1: icmp_seq=0 ttl=254 time=0.442 ms
64 bytes from 192.168.16.1: icmp_seq=1 ttl=254 time=0.402 ms
^C
--- 192.168.16.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.402/0.422/0.442/0.020 ms
#

Il messaggio "Nessuno spazio buffer disponibile" sembra indicare una sorta di errore di memoria. E infatti, quando controllo con Netstat, il numero di "cluster mbuf" sembra MOLTO sbagliato:

# netstat -m
11780 mbufs in use
4294966716/32768 mbuf clusters in use (current/max)
0/3/6656 sfbufs in use (current/peak/max)
1785 KBytes allocated to network
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines

Cosa sta succedendo qui? È possibile risolvere questo problema senza tempi di inattività o è necessario riavviare l'host o riavviare l'interfaccia di rete?

freebsd networking

— Stefan Lasiewski
fonte

Puoi pubblicare il tuo output di dmesg?

— Mike H

Ho incollato il mio. Nel mio caso, era un backup che stava ostruendo alcune code da qualche parte, non mi è chiaro il perché - ma sospendere quindi riprendere il backup (rsync --bwlimit = 40) ha risolto il problema per noi. Ho anche provato a raddoppiare net.inet.tcp.sendbuf_maxe net.inet.tcp.recvbuf_maxnon ho cambiato nulla.

— anarcat,

Dato che il problema sembra isolato su una sola interfaccia - suppongo che tu stia usando delle semplici maschere di classe C per queste due reti - lo rimbalzerei rapidamente:

# ifconfig en0 down
# ifconfig en0 up

Ovviamente devi sostituire qui il nome dell'interfaccia corretto en0.

Potrebbe essere necessario riavviare tutti i server in ascolto su tale interfaccia e qualsiasi connessione TCP stabilita che lo utilizza verrà interrotta quando si esegue questa operazione. È breve, tuttavia, quindi non vedo davvero un test come "downtime".

Assicurati di non farlo mentre sei nella casella sull'interfaccia che stai rimbalzando. È possibile accedere alla console quando si esegue questa operazione, se possibile. Se il server è remoto, è preferibile una connessione via modem, poiché il rimbalzo delle interfacce di rete non influirà sul Gys seriale. Se è necessario eseguire questa operazione durante l'accesso sulla rete, assicurarsi che la connessione arrivi su un'interfaccia diversa.

— Warren Young
fonte

Bene, risulta che questa interfaccia aveva un cavo Ethernet allentato. Ho stretto il cavo e l'errore "Spazio buffer non disponibile" è scomparso. Ora, devo capire se devo preoccuparmi del numero 'mbuf', o chiarirà da solo?

— Stefan Lasiewski,

Sfortunatamente, rimbalzare l'interfaccia non l'ha riparata (ci sono più interfacce su questa macchina, ho provato ognuna in sequenza e poi tutte in una volta, sperando che qualcosa liberasse lo spazio). Ho riavviato il box e spero che questo problema non si ripeta dopo aver riparato il cavo.

— Stefan Lasiewski,

Un aggiornamento 4 anni dopo. Sì, devo preoccuparmi dell'errore mbuf. Questo problema si presenta occasionalmente sulle mie scatole di FreeBSD ed è quasi sempre associato a un carico di rete elevato, e probabilmente a un cavo difettoso.

— Stefan Lasiewski,

Il rimbalzo l'ha riparato per me.

— gravitazione

Sono venuto qui appositamente per OpenBSD 5.8 AMD64 in esecuzione su Cloudstack con CentOS6.5 AMD64. Ogni volta che la scatola fisica viene interrotta, questa VM non può uscire. Ho provato a far rimbalzare l'interfaccia e non ha funzionato. Ho pensato di condividere qui nel caso in cui qualcun altro avesse intrapreso un percorso simile. AGGIORNAMENTO: meno di un minuto dopo funziona, quindi forse questo lo risolve.

— danno