FreeBSD: Jak naprawić „ping: sendto: Brak dostępnego miejsca w buforze”?

Próbuję wysłać polecenie ping do zdalnego hosta, ale pojawia się błąd.

# 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

Działa z innymi hostami:

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

Komunikat „Brak dostępnego miejsca w buforze” wydaje się wskazywać na jakiś błąd pamięci. I rzeczywiście, kiedy sprawdzam w Netstat, liczba „klastrów mbuf” wygląda BARDZO źle:

# 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

Co tu się dzieje? Czy jest to możliwe, aby rozwiązać ten problem bez przestojów, czy muszę ponownie uruchomić hosta lub ponownie uruchomić interfejs sieciowy?

freebsd networking

— Stefan Lasiewski
źródło

Czy możesz opublikować swoje wyjście z dmesg?

— Mike H

Wkleiłem własne. W moim przypadku była to kopia zapasowa, która zapychała gdzieś kolejkę, nie jest dla mnie jasne, dlaczego - ale zawieszenie, a następnie wznowienie tworzenia kopii zapasowej (rsync --bwlimit = 40) rozwiązało problem. Próbowałem również podwoić net.inet.tcp.sendbuf_maxi net.inet.tcp.recvbuf_maxnic nie zmieniłem.

— anarcat

Ponieważ problem wydaje się być odizolowany tylko od jednego interfejsu - zakładam, że używasz zwykłych starych masek klasy C dla tych dwóch sieci - po prostu szybko go odrzuć:

# ifconfig en0 down
# ifconfig en0 up

Oczywiście musisz zastąpić tutaj poprawną nazwę interfejsu en0.

Może być konieczne zrestartowanie serwerów nasłuchujących na tym interfejsie, a wszelkie ustanowione połączenia TCP, które z niego korzystają, zostaną zerwane. Jest to jednak krótkie, więc tak naprawdę nie uważam takiego testu za „przestój”.

Pamiętaj, aby tego nie robić, gdy ssh'd jest w polu na odbijanym interfejsie. Jeśli to możliwe, najlepiej zalogować się na konsoli. Jeśli serwer jest zdalny, połączenie modemowe jest najlepsze, ponieważ odbijanie interfejsów sieciowych nie wpłynie na pobieranie szeregowe. Jeśli musisz to zrobić podczas logowania przez sieć, upewnij się, że połączenie przychodzi przez inny interfejs.

— Warren Young
źródło

Okazuje się, że ten interfejs miał luźny kabel Ethernet. Po dokręceniu kabla zniknął błąd „Brak dostępnej przestrzeni buforowej”. Teraz muszę się zastanowić, czy muszę się martwić o numer „mbuf”, czy też sam się wyczyści?

— Stefan Lasiewski,

Niestety odbijanie interfejsu nie rozwiązało problemu (na tym komputerze jest wiele interfejsów, próbowałem każdy z nich kolejno, a potem naraz, mając nadzieję, że coś zwolni miejsce). Ponownie uruchomiłem pudełko i mam nadzieję, że ten problem nie powtórzy się po naprawieniu kabla.

— Stefan Lasiewski,

Aktualizacja 4 lata później. Tak, muszę się martwić o błąd mbuf. Ten problem czasami pojawia się na moich urządzeniach FreeBSD i prawie zawsze jest związany z dużym obciążeniem sieci i prawdopodobnie z wadliwym kablem.

— Stefan Lasiewski

Odbicie naprawiło to dla mnie.

— grawitacja

Przybyłem tutaj specjalnie dla OpenBSD 5.8 AMD64 na Cloudstack z CentOS6.5 AMD64. Za każdym razem, gdy fizyczne pudełko zostaje przerwane, ten vm nie może się wydostać. Próbowałem odbić interfejs i to nie działało. Pomyślałem, że podzielę się tutaj na wypadek, gdyby ktoś poszedł inną drogą. AKTUALIZACJA - mniej niż minuta później działa, więc może to naprawia.

— danno