Inbound packets discarded linux

Много dropped пакетов на интерфейсе.[linux]

Господа, подскажите чем может быть вызвано такое кол-во дропнутых пакетов? Я так понимаю что если бы была проблема в физической передаче сигнала (кабель хреновый то было бы много error`ов. Куда вообще копать?

ethtool более подробную статистику показывает

Решил проверить, у меня, оказывается, тоже куча dropped. Присоединяюсь к вопросу.
Из доп. инфы, на этом интерфейсе где-то неделю-две назад кольцо было в прилежащей к нему сети, возможно этим dropped и обусловлено.

Нашёл вроде баг в багзиле редхата. http://bugzilla.redhat.com/show_bug.cgi?id=484667
Но он пофикшен стопицот лет назад. Да и рядом у меня пачка таких же серверов на том же ядре работают без сбоев.
$ uname -a
Linux ***********.ru 2.6.32-220.7.1.el6.x86_64 SMP Wed Mar 7 00:52:02 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux

rx_filtered_packets: 25393
rx_fw_discards: 1086921

фильтеред это айпитэйблс. по дроппедам я бегло погуглил — нагуглил тот баг что привёл.

duplex одинаковый с двух сторон?

rx_fw_discards это человеческим языком «no buffers», то есть на момент прихода пакета, все дескрипторы уже были заполнены и не обслужены драйвером. Не справляется твоя машина с нагрузкой.

Странно. Нагрузка ничтожна для такого сервера. Сам видишь, что траффика пару десятков гигабайт. А могут какие-то пакеты создавать такой эффект? Проблема в том что каталист на другом в конце не в моей юриксдиции и посмотреть что там нельзя.

а ты крутил настройки, как по моей ссылке делать предлагали?
убедился, что твой драйвер с фиксом, про который там говорят?

Такая проблема может возникать и при load average 0.01, суть в том, что операционная система по какой-то причине не успевает разгребать дескрипторы. В современных ОС, где гонятся за производительностью, входящие пакеты обрабатываются непосредственно в контексте прерывания. В прошлом прерывание только перекладывало пакет из ринга сетевой карты в софтварную очередь и скедулило софтварное прерывание. Такая обработка гарантировала быструю отработку прерывания, однако перекладывание в очередь, её локинг и переключение в другой контекст всё это давало низкую производительность. Поэтому сейчас непосредственно прерывание заходит в сетевой стек и там работает. Если там оно блокируется на чём-то (а вариантов очень много) даже на непродолжительное время, то сетевая карта переполняется. Классическая проблема — пуржинг каких-то кешей, он может длиться значительное время и держать при этом мьютексы, которые также нужны и тредам осуществляющим обработку входящих пакетов. Это всё общие теории, но я думаю, что в линуксе, скорее всего всё так же.

Это всё общие теории, но я думаю, что в линуксе, скорее всего всё так же.

руки не дошли. завтра может попробую.

Это? http://en.wikipedia.org/wiki/New_API#NAPI_compliant_drivers Не вижу чем это отличается от обычного polling, который у нас был уже 10 лет как.
Если всё так, как написано в wikipedia, то вероятность получить no buffers ещё выше, чем с прерываниями. Если ядро по какой-то причине слишком редко поллит, то no buffers гарантированы.

Не вижу чем это отличается от обычного polling, который у нас был уже 10 лет как.

Если ядро по какой-то причине слишком редко поллит, то no buffers гарантированы.

При малой нагрузке причина проста — interrupt mitigations в железке, что и предлагается крутить.

Ты же сам выше говоришь что от прерываний вообще не зависит, да и wikipedia подтверждает.

Источник

Dropped packets Linux/Unix на интерфейсе в локальной сети

Добрый день. Существует проблема. Купили материнскую плату – X11SBA-LN4F. Вроде бы прекрасна для организации шлюза доступа в интернет, есть 4 гигабитных порта, BMC для IPMI, потребляет не больше 20 Ватт. На этом плюсы закончились. Ситуация: в первый порт у меня вставлен интернет, во второй локальная сеть. На порту с интернет все нормально, на порту локальной сети, какая-то ерунда. Может проработать день/два и отвалиться линк в локальную сеть, в логах тишина (помогает только рестарт службы). И регулярно я наблюдаю dropped packets в «ifconfig» или «netstat -i» и число этих пакетов регулярно растет.

Сетевая карточка Intel I210-AT

Поиски по решению моей проблемы, привели к этому сайту https://www.novell.com/support/kb/doc.php?id=7007165

Первое, что я сделал, это запустил tcpdump

Самое интересное, что когда я запускаю tcpdump, счетчик дропнутых пакетов не наблюдается. Но когда я останавливаю мониторинг tcpdump, пакеты дропаются опять.

Что я делал: — проверял vlan, у меня кинут на мой проблемный порт нетегированный VLAN и все; — отключал IPv6; — проверял /proc/net/softnet_stat

Как видно значения только в первой колонке, что есть хорошо

— проверял кабеля и коннекторы; — пробовал на разных портах и коммутаторах подымать интерфейс в локальную сеть; — включал promiscuous mode, пакеты все равно дропались; — устанавливал самые последние драйвера; — увеличивал ring caches size; — анализировал tcpdump (там идет ARP, Broadcats, Rip, IPX, IP6); — отключал jumbro frame везде и проверял mtu в tcpdump, не было размера фрейма больше 300; — проверял разные дистрибутивы (Zeroshell, Pfense, FreeBsd, Ubuntu Server (с родным ядром и собранным мною), CentOS (с родным ядром и собранным мною); — прошивал эту материнскую плату на последнюю что есть прошивку; — правил iptables нет вообще!

При чем на нашем другом шлюзе (и на других машинах в сети), через который я сижу и Вам сейчас пишу – все нормально. Подскажите пожалуйста, сижу уже не первую неделю, хочу заставить ее работать. Куда копать ? Может кто-то, если есть время захочет свежим взлядом взглянуть, могу даже доступ SSH дать, только с моим контролем =) Спасибо за Ваше внимание и терпение, что прочитали все это.

Раз сетевуха не говорит об ошибках, значит дропает ядро. посмотри на «netstat -s» — там где-то должны быть ненулевые счетчики ошибок.

Я бы отключит для начала sg gso tso gro lro через «ethtool -K»

Судя по версии драйвера у тебя интеловские драйвера. А с оригинальным драйвером igb из ядра не пробовал (только ядро нужно не 2.6, а что-нибудь свежее типа 3.18/4.4)?

А не пробовал гонять трафик через iperf3 в локалке ? Может проблема проявится более стабильно.

все пробовал

Ядро – 4.2.0-36-generic; Сделал ethtool -K em3 sg off gso off tso off gro off lro off; С оригинальным драйвером из ядра и пробовал; iperf3 прошел тест

в качестве апа

Спасибо за Ваше внимание и терпение, что прочитали все это.

спасибо за нетупую тему на ЛОРе.

гигабитная кароточка

кстати, на машине, где гигабитная карточка, выдает такую интересную картину

добавлю к iperf

кстати, после нескольких запусков iperf я смог вручную «положить» сетевой интерфейс. а не ждать как раньше сутки/двое. в логах есть такое:

а почему оно в режиме 100Mbit? Так и должно быть ?

Интересный рецепт «Please try booting the kernel with the pcie_aspm=off kernel parameter.»

Проблема встречается регулярно, но общего рецепта решения нет.

А в настройках биоса никто не ковырялся ? Нет ли разгона и не используется ли какие-нибудь режимы энергосбережения cpu/chpset ?

bios нет. пробовал

Конечно делал. В Bios ничего такого нет

я один раз столкнулся с проблемой, когда интеловская 10Г сетевушка не инитилась драйвером со странной диагностикой. И только после сброса настройки биоса в начальное состояние она стала работать.

Интересно то, что eth0 работает, а eth1 — глючит. А в чем разница ? Оба подключены на гигабит? Как распределены irq между ядрами? Если eth1 принудительно перевести в 100Мбит, то проявится ли проблема ?

Попробуй (используя iperf3 в режиме udp) постепенно повышать скорость начиная со 100Мбит. Если проблема начнет проявлятся с какой-то скорости, то вероятно это следствие проблемы нехватки производительности (N3700 6W TDP явно не шустрый)

устанавливал самые последние драйвера

1. Самые последние у них (intel) Date: 5/31/2016 — при учете перечисленного вами выше и того что прошло меньше двух дней, может те были еще не самые последние? 🙂
2. Самые последние != самые лучшие, у них там из предыдущих веток еще есть

проверял разные дистрибутивы (Zeroshell, Pfense, FreeBsd, Ubuntu Server (с родным ядром и собранным мною), CentOS (с родным ядром и собранным мною);

Версии дистров пробовали именно те которые «типа» должны работать согласно таблички сайта supermicro ?

проблема локализирована

проблема локализирована. поставив свою локалку в первый порт, и запустив iperf я убедился, что она не падает, даже после минуты теста. переставил свой интернет в порт 2 и запустил тест на iperf уже через внешний ip-адрес – упал через пять секунд.

причина: первый ehternet интерфейс на этой материнке идет на прямую от чипсета–проца (soc n3700) – согласно схемы официального мануала материнской платы, а другие 3 интерфейса идут от проца к так называемому Pericom Semiconductor Device, а дальше уже распределяются на три ehternet контролера и mPCI. почему они не работают как надо – будем разбираться.

Источник

How to show dropped packets per interface on Linux

H ow do I display dropped packets per interface on Linux operating systems from the command line option? How can I determine why a Linux server is dropping packets?

We can use the ip command or netstat command or ethtool command to show dropped packets statistics per network interface on Linux. Let us see how to use both commands list dropped packets per interface.

Tutorial details
Difficulty level	Advanced
Root privileges	Yes
Requirements	Linux with GCC compilers
Est. reading time	6 minutes (depends upon your skills & situation)

Displaying show dropped packets per interface on Linux using the netstat

The netstat command is mostly obsolete. Replacement for netstat is ss and ip command. However, netstat still available on older Linux distros, which are in productions. Hence, I will start with netstat but if possible, use the ip/ss tools. The syntax is:
netstat -i
netstat —interfaces

Displaying network stats per network interface on LInux

To display summary statistics for each protocol, run:

netstat -s
netstat —statistics
Outputs:

• No ads and tracking
• In-depth guides for developers and sysadmins at Opensourceflare✨
• Join my Patreon to support independent content creators and start reading latest guides:
  • How to set up Redis sentinel cluster on Ubuntu or Debian Linux
  • How To Set Up SSH Keys With YubiKey as two-factor authentication (U2F/FIDO2)
  • How to set up Mariadb Galera cluster on Ubuntu or Debian Linux
  • A podman tutorial for beginners – part I (run Linux containers without Docker and in daemonless mode)
  • How to protect Linux against rogue USB devices using USBGuard

Join Patreon ➔

Show tcp stats

netstat —statistics —tcp
netstat -s -t

Display udp stats

netstat —statistics —udp
netstat -s -u

Showing dropped packets statistics per network interface on Linux using the ip

Let us see how to see link device stats using the ip command. The syntax is:
ip -s link
ip -s link show
ip -s link show eth0

In this example display link stats for wg0:
ip -s link show wg0

It is clear that TX is Transmit and RX is Receive. Wireguard creates the wg0 interface. So either Wireguard or firewall dropping packets as per policy.

Queries the specified network device for NIC- and driver-specific statistics with ethtool

Pass the -S or —statistics option to display stats. Again the syntax is straightforward:
ethtool -S
ethtool -S eth0

Another option is to directly query the /proc/net/dev file either using the cat command or column command:
cat /proc/net/dev
column -t /proc/net/dev
And this is what we see:

Finding out why a Linux server is dropping packets

It is a project I started in an effort to improve the ability for developers and system administrator to diagnose problems in the Linux Networking stack, specifically in our ability to diagnose where packets are getting dropped.

Building dropwatch

Install required tools, libs and gcc compiler collection on Ubuntu or Debian Linux:
sudo apt-get install libpcap-dev libnl-3-dev libnl-genl-3-dev binutils-dev libreadline6-dev autoconf libtool pkg-config build-essential
Next, clone the repo and then compile it:
git clone https://github.com/nhorman/dropwatch
cd dropwatch
./autogen.sh
./configure
make
make install
Session:

Run it as follows:
# dropwatch -l kas

You see nf_hook_slow or icmpv6_rcv are Linux kernel functions. It means I need to search Linux kernel trees and see what is going on. Naturally, you must understand C programming and have a good understanding of Linux kernel internals including TCP/IP stack. Now, you know how to see if packets are dropped at the IP layer, the link layer, the UDP/TCP layer, or the application layer. If packets are dropped in TCP/IP, we need to look into the Linux kernel source code documentation. See man page and source code of dropwatch for futher information:
man dropwatch
I would also suggest trying out tcpdump to dump traffic on a network interface. Often it gives hints about packets and easily analyzed in wireshark tool:
man tcpdump

Conclusion

You learned about various Linux commands to see packet loss on Linux per-interface, including excellent tools such as dropwatch. We can also use Linux profiling with performance counters utility called perf. Check out perf examples for further information.

🐧 Get the latest tutorials on Linux, Open Source & DevOps via

Источник